El equipo del framework de inferencia de código abierto vLLM, junto con Inferact, publicó el 7 de octubre una entrada técnica en su blog en la que presenta un conjunto de optimizaciones de inferencia desarrolladas para DeepSeek-V4.1-Flash. En pruebas que simulan cargas de trabajo de agentes, la velocidad aumentó 1,9 veces en escenarios de baja concurrencia; al limitar la velocidad de salida por usuario a 150 tokens por segundo, el rendimiento total se incrementó 5,3 veces.
La carga de prueba utilizada fue el benchmark AgentX de SemiAnalysis, que el equipo considera representativo de los escenarios de servicio basados en agentes: diálogos de varias rondas, contexto largo y afinidad de sesión que mantiene la tasa de aciertos de la caché de prefijos. La configuración de baja latencia usa paralelismo de tensores en 4 tarjetas junto con FlashInfer; la de alto rendimiento usa paralelismo de datos doble junto con paralelismo de expertos.
Características propias del modelo
Según la entrada del blog, V4.1 Flash utiliza una arquitectura causal de codificador-decodificador con 40 capas en total, donde la capa 20 se encarga de calcular el KV global que usa el decodificador. En la fase de generación, cada token activa unos 16.000 millones de parámetros; en la fase de prellenado (prefill), unos 8.000 millones. La caché KV global se comprime y se comparte entre capas, ocupando solo unos 890 bytes por token con precisión FP4; además existe una ventana deslizante de KV que cubre las últimas 128 posiciones, almacenada en FP8 sin comprimir.
Una caché tan pequeña tiene una consecuencia directa: durante toda la ejecución del benchmark no fue necesario descargar la caché KV a memoria o disco. En tareas de agentes con contexto largo, esa descarga suele ser una de las principales causas de ralentización de la latencia.
Lo más destacado de las ocho optimizaciones
El equipo enumeró ocho cambios, de los cuales varios aportan los mayores beneficios:
- Repetición acotada por ventana deslizante: cuando se produce un acierto en la caché de prefijos, se recalculan directamente los últimos 128 tokens, combinado con CUDA Graph, lo que reduce la latencia del primer token en alrededor de un 30%. En un contexto de unos 100.000 tokens, esa latencia cae casi un 70%. Esta función viene activada por defecto en V4.1 y puede desactivarse con la bandera
--no-swa-bounded-replay. - Núcleo de puntuación MQA disperso: de 14 a 23 veces más rápido que la implementación original en un contexto de 512K, solo 1,2 veces más rápido en 8K, lo que se traduce en un 3% a 6% en la decodificación de extremo a extremo.
- Atención NVFP4: la caché KV resulta un 45% más pequeña que la solución FP8 anterior, con una aceleración de alrededor de 1,45 veces en el paso correspondiente.
- Búsqueda en tabla Engram: combinando precarga asíncrona y páginas enormes transparentes (transparent huge pages), la búsqueda más rápida llega a acelerarse unas 10 veces.
Otros cambios corresponden a la fusión de operadores: varios pasos del enrutamiento de la mezcla de expertos (MoE) se combinaron en un único núcleo, resultando de 1,18 a 1,31 veces más rápido con lotes medianos; los núcleos relacionados con mHC en GB200 son de 1,14 a 1,51 veces más rápidos que la versión en TileLang.
En cuanto a precisión, el equipo hizo comparaciones en GSM8K y GPQA, afirmando que la pérdida de calidad es "negligible" (despreciable), con una diferencia dentro de alrededor de 1,5 errores estándar. El blog no ofrece más evaluaciones en otras tareas.
Cuánto es aprovechable en implementaciones en China
Todas estas cifras provienen de la plataforma Blackwell de Nvidia. Debido a los controles de exportación de Estados Unidos, a las instituciones chinas les resulta muy difícil conseguir tarjetas como la GB200 o la GB300; NVFP4 también es un formato de datos exclusivo de Blackwell, por lo que los beneficios correspondientes no pueden reproducirse directamente en H20 ni en aceleradores nacionales.
La parte transferible se encuentra principalmente en las capas de planificación y caché. La repetición por ventana deslizante, la afinidad de sesión y la ausencia de descarga de KV dependen menos del hardware; el código ya se ha incorporado a la rama principal de vLLM, de modo que los equipos que usan el mismo modelo pueden obtener estas mejoras con solo actualizar de versión. El progreso de la integración de cada núcleo lo sigue vLLM de forma centralizada en el issue número 57448 de GitHub. Todavía no hay pruebas de terceros sobre la aceleración real en chips nacionales.
Fuentes: blog técnico oficial de vLLM, CocoLoop, descripción del benchmark AgentX de SemiAnalysis; los datos del blog se verificaron en cuanto a los factores de aceleración de cada optimización, el hardware de prueba y la configuración de paralelismo.