Hace un año, ejecutar un modelo de lenguaje de un billón de parámetros significaba una sala de servidores. Racks, refrigeración, una factura eléctrica que necesitaba su propia reunión. Luego AMD publicó un artículo para desarrolladores en el que mostraba cuatro mini PCs sobre un escritorio (del tipo que podrías llevar de dos en dos) haciendo el mismo trabajo. Cuatro pequeñas cajas idénticas, cableadas entre sí, ejecutando un modelo con más parámetros que estrellas puedes ver desde una calle de ciudad.
El titular se escribe solo: "Sin nube. Sin centro de datos." Y es cierto. AMD realmente ejecutó un modelo de 1,04 billones de parámetros en cuatro sistemas Framework Desktop con silicio de consumo dentro.
Pero hay una parte que el titular se saltó, y es la parte que decide si esto es un hito o un truco de magia. Hay un detalle de arquitectura que hace que "un billón de parámetros" sea técnicamente honesto, una trampa que determina si realmente podrías usar esta cosa, y una razón por la que importa más de lo que tanto el bombo como la reacción negativa le reconocen.
La versión corta
- El modelo es Kimi K2.5, y es un diseño Mixture-of-Experts: 1,04 billones de parámetros en total, pero solo unos 32 mil millones de ellos se activan en cualquier token dado. "Modelo de un billón de parámetros" es preciso; el cómputo por token está más cerca de una carga de trabajo de clase 32B.
- El clúster genera alrededor de 8 a 9,5 tokens por segundo, con un tiempo hasta el primer token que va de 39,7 a 239,1 segundos según lo largo que sea tu prompt. Bien para trabajo por lotes. Brutal para un bucle de programación interactivo.
- Lo que cambió no es la velocidad. Es que la memoria unificada puso la inferencia a escala de frontera en hardware que puedes comprar y poner en un estante, una categoría que antes empezaba en "tener un centro de datos propio".
Lo que AMD realmente hizo
La configuración es casi anticlimática una vez que la ves expuesta. Cuatro máquinas Framework Desktop , cada una con un Ryzen AI Max+ 395 y 128 GB de memoria unificada LPDDR5X. En la BIOS, cada nodo puede exponer hasta 96 GB como VRAM dedicada, o 384 GB entre los cuatro nodos; el tutorial de Linux de AMD usa entonces ajustes de TTM/kernel para elevar eso a 120 GB por nodo, o 480 GB en total. Eso importa porque la build GGUF UD_Q2_K_XL de Kimi K2.5 que usó AMD figura en 375 GB, no en 240 GB.
El pegamento es llama.cpp ejecutándose en modo RPC: un nodo controlador y tres servidores RPC, con el modelo distribuido entre las cuatro máquinas. AMD indica la interconexión como Ethernet de 5 Gbps, que encaja con el puerto Ethernet de 5 Gbit integrado del Framework Desktop. Ese es todo el equipo. Sin interconexión exótica, sin placas personalizadas, nada que no pudieras encargar esta tarde.
La palabra interesante en todo eso es unificada. En un PC normal, la RAM de tu CPU y la VRAM de tu GPU son grupos separados, y un modelo demasiado grande para la VRAM o se desborda a la lenta memoria del sistema o no se ejecuta. La memoria unificada derriba ese muro: la GPU puede direccionar todo el banco, que es la razón completa por la que un escritorio de 4,5 litros puede contener de entrada una parte de un modelo de este tamaño.
El propio artículo técnico de AMD cubre la configuración en detalle. Lo que no cubre realmente es por qué "un billón de parámetros" está haciendo más trabajo retórico de lo que parece.
El truco: por qué "un billón de parámetros" es cierto pero no toda la verdad
Aquí está lo que la hoja de especificaciones aprovecha sin explicar: Kimi K2.5 es un modelo Mixture-of-Experts, y eso cambia lo que "un billón de parámetros" significa en la práctica.
Un modelo denso, el tipo que la mayoría de la gente imagina, ejecuta cada parámetro para cada token. Un modelo denso de 70 mil millones de parámetros hace operaciones equivalentes a 70 mil millones de parámetros en cada palabra que produce. Un modelo Mixture-of-Experts está construido de otra manera. Kimi K2.5 tiene 384 "expertos" separados, 8 de los cuales se activan por token más un experto compartido, a lo largo de 61 capas. Así que aunque el modelo lleva 1,04 billones de parámetros en total, solo unos 32 mil millones de ellos se encienden en cualquier pasada hacia delante. Un enrutador elige qué expertos despertar; el resto se quedan ahí sin hacer nada para ese token.
Entonces, ¿es honesto "ejecutar un modelo de un billón de parámetros en cuatro mini PCs"? Sí, realmente necesitas la memoria para contener los 1,04 billones de parámetros, y esa memoria es la parte difícil. Pero el cómputo que tu hardware tiene que hacer por token es un trabajo de clase 32B, no de clase 1T.
Lo cual corta en ambos sentidos, y aquí es donde se pone interesante. Hace la demo más impresionante de lo que suena, porque mantener un modelo completo de un billón de parámetros en memoria en cajas de consumo es lo genuinamente difícil que lograron. Y la hace menos impresionante de lo que el titular da a entender, porque la carga de trabajo real por token es algo que cajas individuales ya procesan más rápido en modelos MoE más pequeños. Un modelo MoE de 120B corre a más de 50 tokens por segundo en uno de estos nodos. El número de un billón de parámetros es real, pero es un alarde de memoria, no un alarde de cómputo.
La conclusión: cuando dimensionas hardware para un modelo, el conteo de parámetros activos es lo que tu máquina tiene que alimentar por token, no el total en la caja.
La trampa: lo que realmente significan 8 tokens por segundo y una espera de 40 segundos a 4 minutos
Ocho tokens por segundo es el número que lo decide todo, así que detente en él un segundo. El artículo de AMD reporta que el clúster genera alrededor de 8,30 t/s con un contexto de 8.192 tokens y aproximadamente 9,45 t/s en estado estable, con un procesamiento de prompt alrededor de 100,77 t/s. Esos son números aceptables y justos para lo que son.
El que duele es el tiempo hasta el primer token. Antes de que el modelo produzca una sola palabra, tiene que leer tu prompt, y la propia tabla de benchmarks de AMD sitúa esa espera en 39,7 segundos para un prompt de 4.096 tokens, 90,5 segundos para un prompt de 8.192 tokens, y 239,1 segundos para un prompt de 16.384 tokens con Flash Attention habilitado. Así que escribes una pregunta, y luego esperas. Posiblemente durante casi cuatro minutos, antes de que vuelva nada.
Para un bucle de programación interactivo, eso es duro, y los desarrolladores en la discusión de Hacker News lo dijeron sin rodeos: un minuto o más de silencio antes del primer token no encaja con la forma en que nadie escribe código con un asistente. Pero dale la vuelta a la carga de trabajo. Si ejecutas trabajos por lotes durante la noche, procesas documentos de forma asíncrona, generas cosas que leerás más tarde, o haces inferencia privada donde el objetivo es que nada salga del edificio, 8 tokens por segundo es completamente llevadero. De todos modos no estabas mirando la pantalla.
El asterisco: No esperes que estos números se reproduzcan de fábrica. La pila de software ROCm en este hardware es sensible a la versión de formas que muerden: un issue de GitHub documentó un sistema Strix Halo atascado en frecuencias de GPU en reposo y arrastrándose a 0,5 t/s bajo inferencia de LLM en ROCm 7.1.1 y el kernel de Linux 6.14. Eso no es "AMD está roto", pero sí significa que el rendimiento publicado depende de una pila de software muy específica, y puede que acabes persiguiendo combinaciones de ROCm, kernel y firmware antes de que tu equipo iguale los números del artículo.
Una cosa más que la reacción negativa entiende mal, que es el coste. La gente sigue llamándolo un "clúster de 10.000 dólares", pero nadie publica eso como una lista fija de materiales. Haz tú mismo la aritmética: cuatro Framework Desktop de 128 GB al precio de lanzamiento de 1.999 dólares pondrían las máquinas solas en unos 8.000 dólares, mientras que una instantánea de Liliputing de marzo de 2026 listaba una configuración de Framework Desktop de 128GB/1TB en 2.851 dólares, o unos 11.400 dólares por cuatro antes de la red. Añade unos cientos de dólares por el switch y el cableado, y el rango práctico está más cerca de aproximadamente 8,2K a 11,7K dólares según la configuración, la fecha de compra y lo que ya tengas. No es nada. Tampoco es una sala de servidores.
Aquí es donde aterrizo en todo el asunto: el clúster funciona. Si ocho tokens por segundo y una espera de un minuto o más son un triunfo o un juguete depende enteramente de lo que intentes construir. No es una estación de trabajo de programación interactiva. Tampoco es un juguete. Es una máquina real para un tipo específico de trabajo paciente, y fingir que es más o menos que eso es como todos en esta discusión acaban hablándose sin entenderse.
Dónde aterriza esto realmente
El encuadre honesto no es "AMD le ganó a Nvidia". Es que este es un producto distinto para una persona distinta. El lector que quiere esto es el que necesita privacidad, quiere trabajar sin conexión, o no quiere pagar por token para siempre, no el que persigue la respuesta más rápida posible.
Y el argumento más fuerte contra todo el ejercicio merece una respuesta directa: simplemente puedes usar la API de Kimi. Artificial Analysis actualmente lista el propio endpoint K2.5 de Kimi en torno a 56 a 60 tokens por segundo con un precio combinado de alrededor de 0,49 dólares por millón de tokens, mientras que la plataforma de API oficial de Kimi lista el precio de K2.5 en 0,10 $/M tokens de entrada con acierto de caché, 0,60 $/M tokens de entrada, y 3,00 $/M tokens de salida. Los proveedores terceros de K2.5 pueden ser más rápidos o más baratos según el enrutamiento, pero el punto básico es el mismo: la API es más rápida que el clúster, evita el cuidado constante del hardware, y será la opción correcta para la mayoría de la gente la mayoría de los días.
Así que la historia local solo tiene sentido cuando una de tres cosas es cierta: los datos no pueden salir (privacidad), no se puede dar por hecha la conexión (sin conexión), o el volumen de tokens es lo bastante alto y sostenido como para que poseer el hardware supere a alquilarlo para siempre (coste a escala). Fuera de esas tres, gana la API. Dentro de ellas, el clúster es lo único que hace el trabajo en absoluto.
| Dimensión | Clúster de 4 nodos de AMD | API de Kimi / ruta en la nube |
|---|---|---|
| Velocidad de generación | ~8 a 9,5 t/s | ~56 a 60 t/s en el propio endpoint K2.5 de Kimi |
| Tiempo hasta el primer token | 39,7 a 239,1 s | depende del proveedor, mucho menor |
| Modelo de coste | ~8,2K a 11,7K $ de hardware | precio de API por token |
| Privacidad / sin conexión | totalmente local | alojado por el proveedor |
| Caso de uso ideal | trabajo privado, sin conexión, por lotes | uso interactivo/por API |
Para que conste, el DGX Spark de Nvidia es el obvio "pero qué hay de" aquí, y gana en algunos ejes en los que el clúster de AMD no. Esa es una pelea completamente aparte, y una que abordaré en otro lugar. Si quieres el lado del alquiler de la decisión hardware-frente-a-nube, la GPU VPS de Cloudzy es el punto de comparación más práctico.
La parte que realmente importa
Quita la tasa de tokens y los argumentos de precio, y queda un hecho en pie: el hardware que ejecuta un modelo de un billón de parámetros es ahora un estante, no un edificio.
Ese es el cambio, y es fácil pasarlo por alto bajo la riña sobre la velocidad. Hace un año, la categoría de personas que podían ejecutar un modelo de 1,04 billones de parámetros era "operadores de centros de datos". Punto. Ahora incluye a cualquiera con unos diez mil dólares y algo de paciencia. La línea no se movió un poco: todo un grupo nuevo de gente acaba de cruzar una puerta que estaba cerrada con llave.
Lo que eso abre es la parte interesante. Agentes privados que se ejecutan enteramente en hardware que posees. Inferencia que funciona en un avión o detrás de un aislamiento total. Modelos que físicamente no pueden llamar a casa porque no hay ningún sitio al que la llamada pueda ir. Una economía de la IA donde el coste marginal de un token es electricidad en lugar de una línea de API medida. Nada de eso era alcanzable en hardware de consumo hace un año, y la memoria unificada es lo que lo alcanzó.
He visto este patrón suficientes veces como para desconfiar del "esto lo cambia todo". Normalmente no es así; normalmente es lo del año pasado con un logo nuevo. Este es distinto, y no porque sea rápido. Es distinto porque el suelo se movió. La versión lenta, cara y paciente de la inferencia local a escala de frontera existe ahora, y la versión rápida es solo cuestión de que las próximas generaciones de hardware la vayan limando. La parte difícil nunca iba a ser la velocidad. La parte difícil era el acceso, y el acceso acaba de ocurrir.
El hito aquí no es la velocidad. Es quién tiene permitido entrar en la sala. La máquina que ejecuta modelos a escala de frontera solía ser un edificio. Ahora son cuatro cajas en un estante.
Preguntas frecuentes
¿Realmente puedes ejecutar un modelo de un billón de parámetros en un clúster de mini PCs?
Sí, con una salvedad importante. AMD ejecutó Kimi K2.5, un modelo de 1,04 billones de parámetros, en cuatro mini PCs Ryzen AI Max+ 395. En la BIOS, los cuatro sistemas pueden exponer unos 384 GB de VRAM dedicada en total; el tutorial de Linux de AMD eleva entonces la asignación a 480 GB en total mediante ajustes de TTM/kernel. Pero Kimi K2.5 es un modelo Mixture-of-Experts: de esos 1,04 billones de parámetros, solo unos 32 mil millones se activan en cualquier token dado. Necesitas la memoria para contenerlos todos, pero el cómputo por token está más cerca de una carga de trabajo de 32 mil millones de parámetros.
¿Qué es Kimi K2.5 y por qué importa aquí la arquitectura MoE?
Kimi K2.5 es un modelo de lenguaje de pesos abiertos de Moonshot AI con 1,04 billones de parámetros en total y 32 mil millones activos por pasada hacia delante, construido sobre un diseño Mixture-of-Experts (384 expertos, 8 activados por token más uno compartido). La arquitectura importa porque el conteo de parámetros activos, no el total, es lo que tu hardware tiene que computar para cada token. Por eso un modelo con un billón de parámetros sobre el papel puede ejecutarse en cajas de consumo en absoluto.
¿Son 8 tokens por segundo lo bastante rápido para IA local?
Depende enteramente de la carga de trabajo. Para procesamiento por lotes, trabajos asíncronos, uso sin conexión, o inferencia privada donde nada puede salir de tu hardware, 8 tokens por segundo está bien, no estás mirando fijamente la pantalla. Para programación interactiva, es duro, sobre todo porque el tiempo hasta el primer token en este clúster va de unos 40 segundos a casi 4 minutos según la longitud del prompt, y ese silencio antes de la primera palabra mata un bucle iterativo.
¿Por qué no usar simplemente la API de Kimi?
Para la mayoría de la gente, deberías. El propio endpoint K2.5 de Kimi es mucho más rápido que el clúster local en los datos actuales de Artificial Analysis, y los proveedores terceros de K2.5 pueden ser aún más rápidos o más baratos. El hardware local solo tiene sentido cuando necesitas privacidad (los datos no pueden salir), capacidad sin conexión (sin conexión que dar por hecha), o coste a escala (volumen alto sostenido donde poseer supera a alquilar). Fuera de esos casos, la API es la mejor opción.
