DeepSeek abre DeepInfer: 155 billones de tokens al día y un margen del 80%

DeepSeek ha publicado en abierto DeepInfer, el motor sobre el que funciona V4.1 Flash. Junto con el código ha aparecido un informe de ingeniería con cifras de producción: 155 billones de tokens al día en un solo clúster, un 96% de aciertos en la caché de entrada, un time to first token medio de 400 ms y una generación de 230 tokens/s (hasta 300 para código). Según los cálculos de Latent Space, con precios extraordinarios de $0,15 por millón de tokens de entrada y $0,60 por millón de tokens de salida, esto supone unos $22 millones de ingresos diarios y alrededor de $38 por acelerador y hora.

De dónde sale el margen del 80%

La aritmética es esta. 155 millones de millones de tokens a un precio mixto de unos $0,14 dan aproximadamente $1 millón por hora. El coste total de una tarjeta, según la estimación del autor del análisis, es de $5–8 por hora. De ahí resulta un margen de inferencia superior al 80% y un plazo de amortización del clúster de unos 81 días. Es una estimación de Latent Space; la propia DeepSeek prevé amortizar el clúster en 10 meses.

Hay una salvedad importante: 155 billones de tokens servidos no equivalen a 155 billones de tokens generados. Con un 96% de aciertos de caché, casi toda la entrada se lee del almacenamiento y solo una pequeña parte se vuelve a calcular. Las cifras son primarias, no hay auditoría independiente, y el resultado es sensible a la composición de la carga, a cómo se contabiliza la caché y a qué costes se incluyen.

Cómo está construido el stack

DeepInfer separa vision encoding, prefill y decode, y cada etapa se escala según su propio cuello de botella. Para prefill se recomiendan máquinas convencionales de ocho aceleradores; para decode, supernodos de 64–128 aceleradores con wide expert parallelism para MoE.

• El planificador de prefill estima el coste de attention y recorta los chunks según un presupuesto de tiempo, no según un tamaño fijo.
• El enrutamiento de prefill no depende de la caché: los prefijos están en un almacenamiento compartido y la petición va a cualquier worker libre.
• El enrutamiento de decode tiene en cuenta el número de peticiones activas y la longitud de la caché KV.
• Los expertos más populares se replican y se redistribuyen periódicamente, a costa de memoria HBM.
• El planificador de CPU trabaja de forma asíncrona y elimina las pausas entre pasos de decode.
• En la configuración divulgada para Blackwell no hay tensor parallelism, según el análisis.

La caché reside en un clúster 3FS con unos 100 PiB de SSD. El almacenamiento dura 3 días para agentes y 7 para chats. El estado de sliding-window attention se queda en la memoria del host. El método SWA Bounded Replay restaura el estado efímero que falta a partir de los últimos 128 tokens y, según DeepSeek, reduce casi a la mitad el cómputo de prefill. La verificación especulativa adaptativa DSpark aporta un +6% de rendimiento en producción frente a una verificación fija de cinco tokens borrador.

El componente deepseek-recipe cubre la capa de interfaz: las API Chat Completions, Responses y Messages, la tokenización paralela y la distinción entre tokens de control reales y cadenas idénticas en el texto del usuario. No es una protección completa contra la prompt injection.

Qué está abierto y qué no

El equipo califica el lanzamiento de totalmente abierto, pero la descripción técnica indica que la gestión de la caché KV y el balanceador de carga aún no se han publicado por completo. Dependen de la infraestructura interna. Algo parecido ocurre con 3FS, publicado con anterioridad. La orquestación a nivel de servicio sigue siendo tarea de quien despliegue el stack.

Las estimaciones de la comunidad son secundarias: 196B de parámetros de Engram, 552B de parámetros de expertos, DP64/EP64, pesos mayoritariamente de 4 bits y compresión de KV de 400 veces respecto a GQA. La fuente primaria no confirma estos detalles.

vLLM ha respondido con benchmarks. DeepInfer se construyó desde el principio sobre vLLM, y el equipo del proyecto mostró un decode-throughput a menos de un 6% del publicado por DeepSeek en GB200, con una configuración comparable, y publicó las recetas y los resultados de AgentX. Es paridad en una sola etapa, no la reproducción de todo el servicio: la caché de 100 PiB, el enrutamiento y la disponibilidad no entran en ese resultado.

Al mismo tiempo, OpenAI anunció el almacenamiento en caché de prompts durante 12 horas en su API, frente a los 30 minutos por defecto. Los productos son distintos, pero el objetivo es el mismo: agentes que vuelven a un contexto largo al cabo de varias horas.

Un equipo que construya un servicio de agentes debería llevarse del lanzamiento tres ideas. Primera: calcular la economía según la proporción de aciertos de caché y el tiempo de conservación de los prefijos, no según el precio por token. Segunda: separar prefill y decode en pools distintos y balancear prefill según la estimación de cómputo. Tercera: probar vLLM con la carga propia, porque su decodificación ya se acerca a los resultados de DeepSeek y la brecha principal está en la capa de caché y en la orquestación.