El equipo de LMSYS publicó una serie de datos de optimización del lado del servidor para DeepSeek-V4-Pro, con la H20 como plataforma de prueba y la B300 de Nvidia como referencia comparativa. Los autores son Tianyu Zhang, Yusong Gao y Yun Zhang, y todo el trabajo se ejecuta sobre el framework de código abierto SGLang.
Primero, dos cifras centrales. En la fase de prefill, la configuración PP2-CP8-TP8 con un contexto de 4K alcanza 16900 tokens por segundo; al pasar a PP4-CP8-TP8 con un contexto largo de 512K, el throughput sube a 25860 tokens por segundo, y procesar 1 millón de tokens toma 43,7 segundos. En la fase de decodificación, en el escenario de baja latencia, un solo lote en la H20 entrega 271 tokens por segundo, frente a 383,7 en la B300, una razón de 1,42 veces.
Para escenarios de alto throughput existe otro conjunto de configuraciones. DP32-EP32, con contexto de 4K y 32 solicitudes concurrentes, logra 703,15 tokens por segundo por GPU; DP16-EP16 es aún más alto, con 759,73. Al extender el contexto a 1 millón de tokens, cada GPU mantiene entre 66 y 67 tokens por segundo.
Qué significa ese 1,42 veces
La H20 es la versión que Nvidia diseñó para cumplir con las restricciones de exportación al mercado chino, y la distancia de potencia de cómputo sobre el papel frente a la B300 es más que un simple escalón. Reducir la brecha de decodificación en lote único a 1,42 veces demuestra que el cuello de botella no está en el rendimiento máximo, sino en el ancho de banda de memoria, la sobrecarga de comunicación y los tiempos muertos de programación.
Esto también explica la composición de la lista de optimizaciones. Las ganancias más grandes no provienen de la precisión de los operadores: la fusión del camino crítico de cuantización, que combina la activación SwiGLU con la cuantización y elimina búferes intermedios, eleva el throughput un 44,0% por sí sola; sustituir el producto escalar de los pesos del vocabulario por una operación GEMM transpuesta reduce las lecturas repetidas bajo alta concurrencia y aporta otro 22,8%; reorganizar el balanceo de carga según la preferencia real de los expertos, medida empíricamente, suma otro 13,5%.
En el lado del prefill aplica la misma lógica. Fusionar 7 operadores en 3 grupos de ejecución reduce la latencia hasta el primer token en un 3,5%; extraer las formas de mayor frecuencia de histogramas reales de enrutamiento en producción y optimizar específicamente los dos grupos de pesos de expertos reduce otro 11,35% esa misma latencia. Este último punto es especialmente pragmático porque no asume una distribución uniforme de las solicitudes, sino que sigue el patrón real y sesgado del tráfico en producción.
Hay además una sustitución estructural: en la fase de prefill se usa paralelismo de tensores en lugar de paralelismo de expertos para dividir el MoE. La razón es que una carga desigual entre expertos genera colas largas de latencia, y vale la pena pagar algo más de comunicación para recortar esa cola.
La memoria es lo que se cambia por capacidad
Más rígida que la velocidad es la restricción de capacidad. Dos medidas apuntan directamente a la memoria: Humming MXFP4AFP8 almacena los pesos de los expertos en MXFP4 combinado con activación FP8 en línea, ganando de 1,71 a 4,47 veces más capacidad respecto a la línea base; la compresión de KV C128 en línea mantiene un estado agregado compacto en lugar de un estado indexado elemento por elemento, aportando 2,268 veces. Combinadas, ambas alcanzan un rango de 3,88 a 10,14 veces.
Para quienes operan la infraestructura, esta es la cuenta más fácil de hacer. En la misma máquina de 8 GPUs, el número de solicitudes concurrentes o la longitud de contexto que se puede atender se multiplica, y el costo por token baja en la misma proporción. Cuando no se puede aumentar el número de GPUs, el multiplicador de capacidad es la única variable que el equipo todavía controla.
La contribución de DSpark se contabiliza aparte: al coordinar la ejecución objetivo y los pasos de verificación entre etapas del pipeline, el tiempo de salida por token mejora entre un 74,8% y un 78,0%.
Traducir esto a costos lo hace más intuitivo. Suponiendo que el costo mensual de mantener una máquina de 8 GPUs H20 se mantenga fijo, un multiplicador de capacidad de 4 veces permite que la misma factura atienda el cuádruple de concurrencia, y el costo de máquina por token cae a aproximadamente una cuarta parte (es un cálculo aproximado que ignora el cómputo adicional que generan los contextos largos y las fluctuaciones de enrutamiento). Para los proveedores que cobran por token y cuyo margen ya está apretado por la guerra de precios, este margen de maniobra suele valer más que cambiar de generación de GPU, sobre todo porque tampoco siempre es posible conseguir GPUs nuevas.
Lo que se entrega, al final, es una tabla de configuraciones
El resultado final de este trabajo no es una única solución óptima, sino una tabla de configuraciones organizada por escenario: en el prefill se usa PP2 hasta 32K de contexto y se pasa a PP4 a partir de 128K; en la decodificación se busca baja latencia con PP2-TP8, alto throughput con DP32-EP32, y DP16-EP16 queda como referencia de eficiencia.
Esta forma de presentar los datos ya es en sí una señal. Las tablas de benchmark quieren una sola cifra; los entornos de producción necesitan saber cómo es su propio tráfico y en qué categoría encaja. Para los equipos que solo disponen de H20 y aun así deben poner en producción un modelo de 1,6 billones de parámetros, esta tabla resulta más útil que cualquier récord de pico aislado.
Fuentes: blog técnico de LMSYS, CocoLoop, documentación del proyecto SGLang; las cifras de throughput, latencia y multiplicador de capacidad provienen de la tabla de configuraciones medidas publicada en ese blog, y los datos comparativos de la B300 tienen el mismo origen.