📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.
¿Cuánta memoria hace falta para ejecutar un modelo de tres billones de parámetros? Cerca de un terabyte y medio solo en pesos. No existe GPU individual con esa memoria, así que en la arquitectura tradicional esos pesos se reparten entre placas, se paginan y se traen por el bus una y otra vez. Cerebras publicó esta semana la explicación de cómo ellos evitan ese sufrimiento, y el post me gustó porque es pura aritmética del tipo que un sysadmin reconoce al instante: cuantización, gestión de memoria y un techo que no está en el cómputo.
La cuenta que nadie hace
El caso de estudio es Kimi K3, un modelo open source con unos tres billones de parámetros, 69 capas de atención lineal y 24 capas densas. Guardado en 4 bits — hoy estándar, no exotismo — el payload queda en 1,5 terabytes. Dividido entre las 93 capas, da unos 16 GB por capa. El otro dato es el hardware: cada wafer WSE-3T de Cerebras tiene 44 GB de SRAM montados en el propio chip. Con 16 GB de pesos por capa sobran 28 GB, y ese espacio sobrante es la clave de todo el esquema.
Cincuenta y nueve wafers, ni un peso en movimiento
El mapeo sale directo. Las capas densas guardan las llaves y valores de cada petición, el famoso KV cache, de modo que van una por wafer y se quedan con los 28 GB restantes para ese uso. Las capas de atención lineal mantienen un estado fijo por pedido, sin importar qué tan largo es el contexto, así que caben dos por wafer. La cuenta final: 35 wafers para las lineales, 24 para las densas, 59 en total.
Cada wafer funciona como una etapa de una línea de producción. Los pesos jamás se mueven: lo único que cruza de wafer a wafer son las activaciones, vía RDMA sobre Ethernet, con unos 2 microsegundos por salto. Y como es una línea, no se vacía: mientras el wafer 3 procesa una petición, el 2 lleva otra y el 1 recibe una tercera. En producción el grano es más fino, con micro-batches por etapa que suben el throughput a costa de la latencia de cada pedido individual. El sistema completo mueve estos modelos a rangos de 1.000 a más de 2.000 tokens por segundo.
El techo no es el cómputo, es el KV cache
De todo el post, esta es la lección que mejor se traslada a escala chica: la cantidad de peticiones simultáneas que soporta el sistema la fija el espacio sobrante de KV cache, no la capacidad de cómputo. Con esos 28 GB libres por wafer denso, caben pocos contextos largos al mismo tiempo, y ahí se acabó. ¿Te suena conocido? Es exactamente la razón por la que tu instancia local de LLM en un VPS de 16 GB atiende a dos personas juntas y muere con la tercera: el techo es memoria de estado, no CPU.
Y ojo con la métrica que ellos eligen para juzgar si el sistema sirve: tokens por segundo por megawatt. A nuestra escala, la traducción libre es tokens por segundo por gigabyte de RAM, y da igual si los pesos viven en SRAM de un wafer o en la RAM barata de un VPS prestado.
Mi lectura: mientras la discusión pública de la IA se pelea en benchmarks y listas de precios de API, el problema duro de la inferencia sigue siendo de arquitectura de memoria: cuantizar bien, reservar espacio para el estado de cada petición y entender que la concurrencia se paga con memoria, no con CPU. Cerebras lo resolvió comprando silicio del tamaño de una oblea completa. La parte de abajo de esa decisión es gratis y se copia igual, desde el wafer hasta tu VPS.
Fuente de inspiración: How we deploy Trillion-parameter frontier models on Cerebras
