Un modelo MoE de 2,8T en producción exige serving coordinado

El número de parámetros de 2,8 billones parece un problema de memoria. Al servir, es un problema de coordinación. El Kimi K3, presentado en julio de 2026, activa alrededor de 104 mil millones de parámetros por token, selecciona 16 de 896 expertos y aún necesita mantener dos tipos de estados de atención. La cuenta difícil no está en el titular. Está en el camino de cada token.

El anuncio técnico del Kimi K3, publicado en julio de 2026, explica la arquitectura. El informe técnico sobre arXiv detalla la escala. Lo que estos documentos por sí solos no resuelven es la pregunta operativa: ¿cómo se transforma una arquitectura de este tamaño en un servicio que preserva el rendimiento, la latencia y la utilización sin tratar la memoria de la GPU como un armario infinito?

La tesis es simple: los grandes modelos MoE llegan a producción cuando la infraestructura se transforma a escala completa en computación activa, memoria reutilizable y tráfico distribuido. Abrir las pesas es una decisión de disponibilidad. Hacerlos servibles es una decisión arquitectónica.

¿Qué cambia cuando se pone en producción un modelo MoE de 2,8T?

Servir un modelo MoE de 2,8T cambia el cuello de botella de una multiplicación aislada a una cadena de memoria, comunicación y programación. Los expertos activos reducen el cálculo por token, mientras que la distribución entre aceleradores, la ocupación del buffer y la consistencia del caché deciden la capacidad real del servicio.

En un modelo denso, cada token pasa por prácticamente el mismo conjunto de pesos. En un modelo MoE, el token pasa a través de un router de expertos, que elige a los expertos responsables de la siguiente parte del cálculo. En el caso técnico del Kimi K3, hay 16 expertos enrutados entre 896, además de los componentes compartidos.

Esta esparsidad explica cómo puede existir una escala total tan alta sin que cada token pague la factura completa. También crea el primer problema: una GPU silenciosa junto a una congestionada no es un detalle de implementación. Es throughput perdido.

La carga no se distribuye perfectamente y de manera uniforme. Una indicación de programación, una solicitud de contexto larga y una pregunta breve pueden producir diferentes patrones de selección. Si muchos tokens buscan a los mismos expertos, surgen colas y tráfico entre ranks incluso cuando el promedio del grupo parece cómodo. El promedio de la GPU es una fotografía tomada desde demasiado lejos.

El monitoreo debe observar, como mínimo, el uso por experto, el tiempo de envío, el tráfico entre ranks, la ocupación de la memoria, los tokens procesados, el tiempo hasta el primer token y el tiempo entre tokens. La arquitectura ya no es un cuadro que recibe texto y devuelve texto. Se convierte en una pequeña bolsa de valores, con activos muy diferentes compitiendo por la misma liquidez.

La vista previa de serving publicada por vLLM resume el conjunto de decisiones: 2,8T parámetros, 1 millón de contexto de token, 69 capas KDA, 24 capas MLA y 896 expertos enrutados. Cada número rompe una hipótesis de servicio común. Juntos rompen varios al mismo tiempo.

¿Por qué un modelo MoE de 2,8T necesita dos tipos de estados de memoria?

Un modelo MoE de 2,8T puede requerir dos tipos de estado porque Kimi Delta Attention, o KDA, mantiene un estado recurrente actualizado, mientras que Multi-head Latent Attention, o MLA, mantiene un KV cache asociado con posiciones de contexto. Un estado es mutable. El otro crece con los tokens y se puede paginar.

La diferencia parece académica hasta el primer prefijo compartido. En MLA, el servidor almacena claves y valores de bloques ya procesados. Una nueva solicitud que comparte el prefijo reutiliza estos bloques sin volver a calcular todo. La caché KV es append-only: el pasado no cambia cuando llega el siguiente token.

El estado KDA es otra criatura. Cada capa mantiene una estructura recurrente que se sobrescribe con cada token. Un estado compartido no se puede entregar directamente a dos continuaciones que lo actualizarán. Antes de seguir adelante, el servidor necesita restaurar el checkpoint en una ranura privada. Luego, debe capturar el nuevo estado en un punto seguro para que otra solicitud pueda reutilizarlo.

El problema operativo tiene un nombre: copy-on-write. El servidor comparte el checkpoint hasta el momento en que una secuencia diverge, copia el estado en su propia área y permite la mutación. A continuación, el servidor debe conservar una copia privada del estado antes de permitir nuevas mutaciones. El material técnico de SGLang y Miles describe la gestión combinada de estos estados, con reutilización segura, memoria unificada y paralelismo de fases.

La distinción cambia la contabilidad de la memoria. Los pesos, el estado de KDA y el MLA KV cache no tienen el mismo ciclo de vida. Reservar un único bloque llamado “memoria de modelo” es la forma más rápida de saber, en producción, que el modelo cabe en el clúster, pero la segunda solicitud no cabe en la réplica.

¿Cómo cambian el servicio el estado de KDA y la MLA KV cache?

El planificador necesita alinear dos estados físicos diferentes en el mismo límite de prefijo lógico. El estado de KDA es mutable y requiere copia privada antes de continuar. La MLA KV cache crece con los tokens y se puede paginar. Esta diferencia determina cuándo una solicitud reutiliza trabajo y cuándo paga por la memoria y se recarga previamente.

El punto es simple. La caché no es un solo bloque.

El prefix caching tradicional comienza a partir de una unidad simple: bloques completos de tokens. Para KDA, almacenar un estado grande en cada bloque pequeño cuesta demasiada memoria. Guardar solo en bloques grandes ahorra espacio, pero reduce los puntos en los que se puede reutilizar un prefijo. Dos solicitudes que comparten casi todo el prompt pueden divergir antes del límite físico y perder una valiosa reutilización.

La implementación descrita en preview of Kimi K3 support in vLLM separa tres decisiones: el tamaño físico del bloque de estado, la alineación requerida por el scheduler y la granularidad utilizada para identificar el prefijo. El estado puede ocupar un bloque físico más grande, mientras que el hash reconoce un límite más fino.

Cuando hay un partial prefix-cache hit, es necesario copiar el estado de KDA correspondiente a un destino privado antes de poder continuar. La caché KV se puede seguir compartiendo hasta que se escriban nuevos tokens. Esta copia no es un cache miss. Es el precio justo para preservar una estructura mutable sin corromper el prefijo de otra solicitud.

El caching también cambia la economía del prefill. En una carga de codificación, en la que varias solicitudes reutilizan instrucciones, herramientas e historial, un acierto en el prefijo evita volver a calcular la parte más costosa del prompt. El anuncio de Kimi informa más del 90 % de aciertos de caché en la API oficial para cargas de trabajo de codificación. Ese número pertenece a esa arquitectura y esa carga de trabajo. No es una tasa que un operador pueda asumir para tráfico arbitrario.

¿Qué ahorra LatentMoE y qué lo hace más difícil?

Kimi K3 utiliza Stable LatentMoE para enrutar a 16 de 896 expertos en un espacio latente de 3584 dimensiones, según la descripción técnica de SGLang. La lectura de que esta representación más pequeña puede reducir el coste de trasladar y procesar expertos es una inferencia arquitectónica, no un resultado de coste medido en fuentes. La esparsidad reduce el cálculo. No elimina la necesidad de poner al experto adecuado en el acelerador adecuado en el momento adecuado.

Kimi K3 combina 896 expertos y 16 expertos activos por token. El runtime necesita calcular puntuaciones, seleccionar expertos, agrupar tokens y enviarlos a los ranks que tienen los pesos correspondientes. Luego, necesita reunir las salidas y restaurar el orden esperado por el resto de la red.

Este ciclo es sensible al formato del lote. En lotes pequeños, lanzar cientos de núcleos pequeños puede costar más que la aritmética. En un lote grande, el problema cambia: la comunicación y el equilibrio comienzan a dominar. El trabajo de servir deja de ser “usar la GPU” y pasa a no crear una procesión de microtareas que llegan tarde al siguiente colectivo.

La cuantificación MXFP4 ayuda a mantener los pesos dentro de un espacio de memoria manejable. El anuncio técnico también describe las activaciones de MXFP8 y la capacitación con reconocimiento de cuantificación. La configuración de implementación publicada por AWS muestra una ruta de referencia con pesos MXFP4, paralelismo tensorial en ocho aceleradores y un backend MoE compatible.

Esto documenta una configuración. No transforma toda la infraestructura en una fórmula universal.

La cuantización no es sinónimo de memoria libre. Los pesos comprimidos comparten espacio con copias de runtime, buffers temporales, activaciones, gráficos CUDA, estado de KDA, MLA KV cache y área de comunicación. Un servidor puede cargar los pesos y aún así no admitir una nueva cadena de contexto larga. El primer número dice que el modelo encaja. El segundo indica cuántas solicitudes caben en él.

¿Dónde divergen el prefill, la decodificación y el paralelismo?

El prefill y el decode presionan partes distintas del serving. El prefill procesa muchos tokens y favorece los lotes grandes, los chunks y la superposición de comunicaciones. El decode repite pasos pequeños, sensibles a la latencia, al lanzamiento de kernels, al estado recurrente y a la capacidad de cache por solicitud. El paralelismo debe respetar esta asimetría.

Son fases diferentes.

La arquitectura de paralelismo debe respetar esta diferencia. Usar la misma configuración para ambas fases porque el archivo de implementación acepta un único valor es una decisión administrativa, no una decisión de rendimiento.

1. Prefill: divide el prompt en chunks y mantiene los pasos ocupados, ocultando la transferencia entre etapas detrás del cálculo del siguiente chunk.
2. Decode: preserva el estado de KDA, accede al MLA KV cache y reduce el tiempo de cada paso. El throughput agregado no es suficiente.
3. Paralelismo de expertos: distribuye expertos entre ranks y paga la comunicación para enviar tokens al experto responsable, con ganancias cuando el balance compensa ese coste.
4. Paralelismo tensorial: en Kimi K3, no fragmenta el MLA KV cache porque hay un único cabezal KV; cada rank mantiene una copia completa, mientras que los GEMM se dividen en ocho y pagan un collective por capa, según el estudio de SGLang.
5. Servicio desglosado: separa a los trabajadores de prefill y decodificación, lo que permite que cada grupo escale según el perfil de tráfico al que atiende.

El estudio SGLang sobre la compatibilidad con Kimi K3 describe el prefill con pipeline paralelo en chunks y el decode con context parallelism. También registra una configuración desagregada que logró 2808 tokens por segundo por GPU con canalización paralela de fragmentos, paralelismo de contexto y la topología descrita en el estudio.

El número es una medición de esa topología, hardware y protocolo. No es una promesa para ningún cluster.

El throughput agregado puede ocultar una mala experiencia de usuario. Un clúster puede producir muchos tokens por segundo y aun así entregar el primer token lentamente si el prefill está congestionado. También puede tener un buen TTFT y una decodificación lenta, lo que convierte una respuesta larga en una cola de apariencia exitosa.

¿Cuánta infraestructura se necesita para albergar las pesas?

La infraestructura depende del formato de los pesos, la cantidad de réplicas, el contexto soportado, el caché y la topología de comunicación. Las fuentes confirman la escala de implementación con MXFP4 y ocho aceleradores en una instancia de referencia. Estos datos delimitan una configuración documentada, no una cifra fija para cada carga de trabajo.

La cuenta comienza con los pesos.

La capacidad debe leerse en seis sobres encadenados. Cada uno limita al siguiente, y la holgura desaparece cuando el tráfico combina un contexto prolongado, concurrencia y comunicación entre ranks.

1. Pesos: copia comprimida del modelo total, distribuida según la estrategia de paralelismo.
2. Memoria de runtime: buffers del kernel, espacio de trabajo, áreas de gráficos y comunicación.
3. Estado por solicitud: estado de KDA, que crece con el número de secuencias activas.

Los tres primeros indican cuánto cuesta desplegar el modelo. Los tres siguientes determinan la capacidad de serving en producción.

1. Contexto: MLA KV cache, que crece con los tokens almacenados y el tamaño del lote.
2. Replicación: copias adicionales por disponibilidad, regiones, picos o aislamiento de carga de trabajo.
3. Transferencia: red interna utilizada en paralelismo tensorial, paralelismo experto, transferencia de caché y servicio desagregado.

La suma define el límite para admitir contexto y concurrencia. Si la operación reserva casi toda la memoria para la caché larga, le falta espacio para el estado de las nuevas secuencias. Si reserva casi todo para los estados de KDA, la MLA KV cache se convierte en el límite máximo.

La propuesta de memoria unificada presentada en el material de SGLang intenta reducir esta apuesta: un único grupo permite que los estados KDA y los bloques MLA ocupen capacidad a medida que cambia la carga de trabajo. Esto es gestión de capacidad, no magia de hardware. La memoria unificada no reduce pesos y no hace que una GPU encaje donde no cabe. Simplemente evita que un grupo se llene mientras los bytes no utilizados permanecen atrapados en el otro.

La cifra de aproximadamente 5 TB no se incluye en este análisis como un hecho. La lista de fuentes del informe no admite una descomposición verificable de este total entre pesos, memoria de runtime, estados, réplicas y comunicación. Sin esta descomposición, la cifra impresiona más de lo que informa.

¿Qué cambia esta arquitectura para el enrutamiento de modelos?

Para una capa de enrutamiento, la capacidad de destino se convierte en una variable operativa. El enrutador no aloja el Kimi K3, no controla sus núcleos y no administra la memoria física de las GPU. Puede enrutar cada solicitud según el coste, la latencia, el contexto, el rendimiento, la disponibilidad y la carga observada. La arquitectura del punto final ahora informa la decisión de tráfico.

El nombre del modelo no es suficiente.

Una solicitud con un prefijo largo y alta probabilidad de reutilización no tiene el mismo coste operativo que una pregunta corta sin caché. Una solicitud que requiere el contexto de 1 millón de tokens no debería competir por la misma ruta que una solicitud simple simplemente porque ambas usan el mismo nombre de modelo. El nombre del modelo no es información suficiente para tomar una decisión.

El Nexforce Router actúa como puerta de enlace y capa de enrutamiento entre aplicaciones y modelos. Sus reglas pueden considerar el coste, el rendimiento, la latencia y el contexto, distribuir la carga, aplicar límites por clave y conmutación por error. El límite es importante: el enrutador gobierna el tráfico que llega a un punto final. El proveedor u operador del punto final sigue siendo responsable de la arquitectura de servicio físico.

Una política de enrutamiento para modelos grandes debe observar cuatro señales antes de reenviar:

1. Elegibilidad: ¿El destino admite la ventana de contexto, la modalidad y el formato de salida requeridos?
2. Estado probable: ¿la solicitud tiene un prefijo reutilizable o llega como un cache miss que requerirá un prefill completo?
3. Carga: ¿el destino tiene capacidad de decode, memoria para nuevos estados y margen para el lote actual?
4. Economía: ¿La ganancia de calidad justifica el coste de activar una ruta de gran huella cuando aumenta la latencia?

La ruta con el precio más bajo por sí sola es una trampa. El modelo más barato por token puede producir más tokens, perder el prefijo, sufrir una cola de expertos o devolver una respuesta demasiado lenta para el SLA. La variable que importa es el coste por resultado dentro del contrato de latencia, no el precio aislado en la tabla.

La comparación de costes LLM en 2026 se vuelve más precisa cuando el coste del servicio se incluye en la cuenta. La decisión no elige el modelo de menor precio por token. Pregunta qué destino ofrece el resultado requerido con la combinación aceptable de caché, latencia, carga y calidad.

¿Cuáles son las limitaciones del análisis?

El análisis separa tres capas: hechos arquitectónicos confirmados, configuraciones de infraestructura documentadas e implicaciones de enrutamiento. Las fuentes respaldan la arquitectura KDA y MLA, los números de Kimi K3 y las rutas de servicio descritas. No admiten un coste universal, una capacidad fija por réplica ni un SLA para ningún clúster.

La frontera importa.

Se confirma lo siguiente: 2,8T de parámetros, alrededor de 104B activos, 896 expertos, 16 expertos activos por token, contexto de 1 millón de tokens, combinación de KDA y MLA, pesos MXFP4 y cambios específicos en la caché y los kernels. También están documentados los desafíos del estado mutable, la memoria unificada, el paralelismo de fases y el servicio desagregado.

No está confirmado por una única fuente universal: el coste exacto para cada empresa, el número final de GPU para cada SLA, la tasa de caché en una carga de trabajo sin codificación, el uso medio de expertos en su propio tráfico o la capacidad por réplica en otro hardware. Estos números requieren una evaluación comparativa con indicaciones, longitudes, simultaneidad y SLO reales.

La conclusión editorial es más estrecha y útil: cuanto más grande es el modelo disperso, menos sentido tiene medir el servicio solo por la cantidad de parámetros o el precio por token. El sistema necesita medir el estado, la caché, la comunicación, la fase y el destino.

El mejor argumento a favor de un MoE abierto también es condicional

El argumento más fuerte a favor de servir un modelo MoE abierto es sencillo: la empresa obtiene control sobre la ubicación del modelo, puede adaptar la pila de servicio a su propia carga de trabajo y deja de depender de una capacidad externa cuyo precio, disponibilidad y política pueden cambiar. La activación escasa hace que la escala completa sea menos desalentadora por token. La cuantificación reduce la presión de los pesos. La caché convierte los prefijos repetidos en trabajo ya remunerado.

Este argumento es sólido. Sería un error tratarlo como una fantasía.

El problema es que el control no elimina los costes. Él lo redistribuye. La empresa comienza a pagar por la distribución de expertos, la interconexión, la ingeniería del kernel, el diseño de grupos de memoria, la observabilidad y la capacidad inactiva necesaria para sobrevivir a los picos. Un modelo que parece barato en la hoja de pesos puede volverse costoso cuando la réplica necesita mantener un contexto prolongado, reservas de conmutación por error y margen para prefill congestionada.

La conclusión condicional es la siguiente: los pesos abiertos son una ventaja de infraestructura cuando la carga de trabajo tiene suficiente volumen, repetición de prefijos y requisitos de control para pagar la complejidad. Para el tráfico irregular o de poco uso, la misma libertad puede convertirse en capacidad ociosa.

La decisión madura no pregunta si el MoE es barato. Se pregunta qué parte de la cuenta está dispuesta a poseer la operación.

Preguntas frecuentes sobre el modelo 2.8T MoE en producción

Un modelo MoE de 2.8T no aplica todos los parámetros a cada token, pero la operación todavía necesita distribuir los pesos totales y coordinar a los expertos, el estado de KDA, la MLA KV cache, la memoria de runtime y la comunicación. La decisión de serving depende de la carga, la topología y el contrato de latencia, no solo del número principal.

¿Un modelo MoE de 2,8T utiliza parámetros de 2,8T en cada token?

No. En el caso técnico de Kimi K3, 16 de los 896 expertos enrutados se activan por token, con alrededor de 104 mil millones de parámetros activos. Los pesos totales aún deben distribuirse y mantenerse disponibles para que el enrutador pueda elegir a los expertos correctos.

¿KDA reemplaza completamente la MLA KV cache?

No. KDA y MLA tienen diferentes roles y estados en la arquitectura híbrida. El serving debe mantener el estado recurrente de KDA y el MLA KV cache alineados en el mismo límite de prefijo lógico.

¿El prefix caching funciona de la misma manera en KDA y MLA?

No. La MLA KV cache es solo para agregar y puede paginarse por bloques de tokens. El estado de KDA es mutable y requiere puntos de control, copy-on-write y copias ordenadas antes de que la continuación cambie el estado compartido.

¿MXFP4 resuelve el problema de la memoria?

MXFP4 resuelve parte del problema de los pesos, pero no cierra la cuenta de memoria. El serving también reserva el tiempo de runtime, el estado de KDA, el MLA KV cache, los buffers, las réplicas y la comunicación. Por lo tanto, la carga exitosa del modelo no prueba que la réplica mantenga la simultaneidad esperada.

El peso es solo la entrada.

¿El enrutador Nexforce aloja el Kimi K3?

No. Nexforce Router es una puerta de enlace y una capa de enrutamiento. Distribuye solicitudes entre destinos y puede aplicar reglas de coste, latencia, contexto, carga y conmutación por error, sin controlar los núcleos o la memoria física del servidor.

Referencias y lecturas adicionales

• Kimi K3: Open Frontier Intelligence, anuncio técnico de Moonshot AI, julio de 2026.
• Kimi K3: Open Frontier Intelligence, informe técnico, presentado el 27 de julio de 2026.
• Una vista previa de la compatibilidad con Kimi K3 a escala de producción en vLLM, 22 de julio de 2026.
• SGLang y Miles agregan soporte del día 0 para Kimi K3, 27 de julio de 2026.
• Implementación de Kimi K3 en Amazon SageMaker HyperPod y Amazon EKS, 30 de julio de 2026.
• Repositorio de Kimi K3, archivos de implementación y despliegue.

La próxima evaluación del serving

La próxima evaluación de un modelo de este tamaño no debe empezar preguntando cuántos parámetros tiene. Debería preguntarse cuántos estados caben, cuántos prefijos se reutilizan y qué parte de la comunicación se encuentra en la ruta crítica. La escala es impresionante en la presentación. El serving decide si se convierte en un producto o simplemente en una fotografía muy cara de una GPU ocupada.