Durante años, la forma en que los grandes modelos lingüísticos manejan la inferencia ha estado atrapada dentro de una caja, literalmente. Las redes RDMA de alto ancho de banda que hacen que el servicio LLM moderno funcione han confinado tanto el precarga como la decodificación al mismo centro de datos, a veces incluso al mismo rack. Un equipo de investigadores de Moonshot AI y la Universidad de Tsinghua defiende que esta limitación está a punto de desaparecer y que la arquitectura adecuada ya puede aprovechar ese cambio.
El equipo de investigación presenta Prefill-as-a-Service (PrfaaS), una arquitectura de servicio entre centros de datos que descarga selectivamente el prefill de contexto largo a clústeres de prefill independientes y con gran densidad de computación y transfiere el KVCache resultante a través de Ethernet básico a clústeres de PD locales para su decodificación. El resultado, en un estudio de caso que utiliza un modelo híbrido interno de parámetros 1T, es un rendimiento de servicio un 54 % mayor que una línea base de PD homogénea y un 32 % mayor que una configuración heterogénea ingenua, mientras consume solo una fracción del ancho de banda disponible entre centros de datos. El equipo de investigación señala que, en comparación con el mismo costo de hardware, la ganancia de rendimiento es de aproximadamente el 15 %, lo que refleja que la ventaja total del 54 % proviene en parte de combinar GPU H200 de mayor capacidad de procesamiento para precarga con GPU H20 para decodificación.
Por qué la arquitectura existente se ha topado con un muro
Para comprender lo que resuelve PrfaaS, es útil comprender por qué el servicio LLM se divide en dos fases en primer lugar. El precompletar es el paso en el que el modelo procesa todos los tokens de entrada y genera el KVCache; requiere un uso intensivo de computación. La decodificación es donde el modelo genera tokens de salida uno a la vez; consume mucho ancho de banda de memoria. La desagregación de decodificación previa (PD) separa estas dos fases en hardware diferente, lo que mejora la utilización y permite optimizar cada fase de forma independiente.
El problema es que separar el prellenado de la decodificación crea un problema de transporte. Una vez que el prellenado se ejecuta en un conjunto de máquinas y la decodificación se ejecuta en otro, el KVCache producido por el prellenado debe transferirse al lado de decodificación antes de que pueda comenzar la generación de resultados. En los modelos convencionales de atención densa, aquellos que utilizan Atención de consultas agrupadas (GQA), este KVCache es enorme. El equipo de investigación compara MiniMax-M2.5, un modelo denso representativo con GQA, que produce KVCache a aproximadamente 60 Gbps para una solicitud de 32 000 tokens en una única instancia de 8 × H200. Ese volumen de datos requiere interconexiones de clase RDMA para transferirse sin detener la computación, razón por la cual la desagregación de PD convencional está estrechamente ligada a una única estructura de red a escala de centro de datos. Mover el precarga y la decodificación a clústeres separados, y mucho menos a través de centros de datos, simplemente no ha sido factible.
La atención híbrida cambia las matemáticas
Lo que hace que PrfaaS sea oportuno es un cambio arquitectónico que se produce a nivel de modelo. Una clase cada vez mayor de modelos, incluidos Kimi Linear, MiMo-V2-Flash, Qwen3.5-397B y Ring-2.5-1T, adoptan pilas de atención híbridas que intercalan una pequeña cantidad de capas de atención total con una mayor cantidad de capas de complejidad lineal o de estado acotado, como Kimi Delta Attention (KDA), Multi-head Latent Attention (MLA) y Sliding Window Attention (SWA). En estas arquitecturas, solo las capas de atención total producen KVCache que escala con la longitud de la secuencia. Las capas de complejidad lineal mantienen estados recurrentes de tamaño fijo cuya huella es insignificante en un contexto prolongado.
Las cifras de rendimiento de KV, definidas como el tamaño de KVCache dividido por la latencia de precarga, cuentan la historia claramente. Con 32.000 tokens, MiMo-V2-Flash produce KVCache a 4,66 Gbps frente a 59,93 Gbps para MiniMax-M2.5, una reducción de 13 veces. El Qwen3.5-397B alcanza los 8,25 Gbps frente a los 33,35 Gbps del Qwen3-235B, una reducción de 4 veces. Específicamente para Ring-2.5-1T, el documento descompone los ahorros: MLA aporta aproximadamente una compresión de 4,5 veces sobre GQA, y la relación híbrida 7:1 contribuye con otra reducción de aproximadamente 8 veces, lo que produce un ahorro general de memoria KV de aproximadamente 36 veces. Para el modelo interno de 1T utilizado en el estudio de caso, el rendimiento de KV en tokens de 32K es de solo 3,19 Gbps, un nivel que los enlaces Ethernet entre centros de datos modernos realmente pueden sostener.
Pero el equipo de investigación tiene cuidado de hacer una distinción que es importante para los desarrolladores de IA que crean sistemas reales: un KVCache más pequeño es necesario, pero no suficiente, para que la desagregación de PD entre centros de datos sea práctica. Las cargas de trabajo reales están en ráfagas, las longitudes de las solicitudes están sesgadas, los cachés de prefijos se distribuyen de manera desigual entre los nodos y el ancho de banda entre clústeres fluctúa. Un diseño ingenuo que enruta cada llenado previo a un clúster remoto aún genera congestión y colas inestables.
Qué hace realmente PrfaaS
La arquitectura PrfaaS-PD se asienta sobre tres subsistemas: computación, red y almacenamiento. El subsistema de cómputo separa los clústeres en dos tipos: clústeres de PD locales que manejan la inferencia de un extremo a otro para solicitudes cortas y clústeres de PrfaaS con aceleradores de alto rendimiento de cómputo dedicados al llenado previo de contexto largo. El subsistema de red utiliza RDMA dentro del clúster para transferencias locales rápidas y Ethernet básico para el transporte KVCache entre clústeres. El subsistema de almacenamiento crea un grupo de caché de prefijo híbrido distribuido que maneja estados recurrentes de atención lineal (nivel de solicitud, tamaño fijo, solo coincidencia exacta) y bloques KVCache de atención total (nivel de bloque, que crece linealmente con la longitud de entrada, admite coincidencia de prefijo parcial) en grupos separados respaldados por un grupo de bloques unificado.
El mecanismo de enrutamiento clave es el enrutamiento por umbral basado en la longitud. Sea l la longitud incremental de precarga de una solicitud después de restar cualquier prefijo almacenado en caché y el umbral de enrutamiento ta. Si l > t, la solicitud va al clúster PrfaaS y su KVCache se envía a través de Ethernet a un nodo de decodificación. Si l ≤ t, permanece en la ruta PD local. En el estudio de caso, el umbral óptimo es t = 19,4 000 tokens, que enruta aproximadamente el 50 % de todas las solicitudes (las más largas) al clúster PrfaaS.
Hacer que la ruta Ethernet sea confiable en la práctica requiere algo más que un bajo rendimiento de KV. El equipo de investigación especifica tres mecanismos de transporte concretos: canalización de precarga por capas para superponer la generación de KVCache con la transmisión, transporte TCP multiconexión para utilizar completamente el ancho de banda disponible y monitoreo de congestión integrado con el programador para detectar señales de pérdida y retransmisión temprana y evitar la acumulación de congestión.
Además de esto, el equipo de investigación presenta un programador de doble escala de tiempo. En escalas de tiempo cortas, monitorea la utilización de salida de PrfaaS y la profundidad de la cola, ajustando el enrutamiento cuando el enlace se acerca a su límite de ancho de banda. También maneja el enrutamiento afín a la caché: cuando el ancho de banda es escaso, la caché de prefijo de cada clúster se evalúa de forma independiente; cuando el ancho de banda es abundante, el programador considera el mejor prefijo almacenado en caché en todos los clústeres y realiza una transferencia de caché entre clústeres si reduce el cálculo redundante. En escalas de tiempo más largas, el programador reequilibra los recuentos de nodos de precarga y decodificación dentro del clúster de PD local a medida que cambian los patrones de tráfico, manteniendo el sistema cerca del punto operativo de rendimiento óptimo.
Los números
En el estudio de caso, un clúster PrfaaS de 32 GPU H200 se combina con un clúster PD local de 64 GPU H20, conectados por una red VPC que proporciona aproximadamente 100 Gbps de ancho de banda entre clústeres. La carga de salida agregada de PrfaaS bajo la configuración óptima es de aproximadamente 13 Gbps (solo el 13% de la capacidad de Ethernet disponible) y el documento señala que el clúster de PrfaaS permanece vinculado a la computación con un importante margen de ancho de banda de sobra. La investigación también proyecta esto para implementaciones más grandes: incluso en la escala de un centro de datos de 10,000 GPU, el ancho de banda de salida agregado requerido para la transferencia KVCache totaliza solo alrededor de 1,8 Tbps, muy dentro de la capacidad de los enlaces modernos entre centros de datos.
El tiempo medio hasta el primer token (TTFT) cae un 50 % y el TTFT P90 cae un 64 % en comparación con la línea de base homogénea. La ingenua configuración heterogénea (todo precargado en H200, todo decodificado en H20, sin enrutamiento ni lógica de programación) logra solo 1,16 veces el rendimiento sobre la línea de base homogénea, en comparación con 1,54 veces para el sistema PrfaaS-PD completo. La brecha entre 1,16× y 1,54× aísla la contribución de la capa de programación y muestra que representa la mayor parte de la ganancia práctica.
El equipo de investigación posiciona a PrfaaS no como un concepto de futuro cercano, sino como un diseño que es viable hoy en día para modelos de arquitectura híbrida, y sostiene que a medida que las ventanas de contexto crecen, las técnicas de compresión KVCache maduran y el hardware especializado en fases, como el Rubin CPX de NVIDIA para precarga y chips estilo LPU para decodificación, se vuelven más ampliamente disponibles, el argumento a favor de la desagregación de PD entre centros de datos solo se fortalecerá.
Consulte el documento aquí. Además, no dude en seguirnos en Twitter y no olvide unirse a nuestro SubReddit de más de 130.000 ML y suscribirse a nuestro boletín. ¡Esperar! estas en telegrama? Ahora también puedes unirte a nosotros en Telegram.
¿Necesita asociarse con nosotros para promocionar su repositorio de GitHub O su página principal de Hugging O su lanzamiento de producto O seminario web, etc.? Conéctate con nosotros