DeepInfer: el motor de inferencia abierto de DeepSeek

DeepInfer es el motor de inferencia que DeepSeek anunció el 20 de octubre de 2026 bajo Apache 2.0, y ejecuta un solo modelo, DeepSeek-V4.1-Flash. El paquete entrega kernels y paralelismo. No entrega la capa que convierte un motor en servicio.

El repositorio oficial, leído el 22/10/2026 y creado el 16 de octubre, distribuye el motor bajo Apache 2.0, con deepseek-recipe, un repositorio aparte, bajo MIT, y enumera, bajo el título "Required for a complete inference service (not included in this release)", tres elementos: KV cache, la desagregación entre vision encoder, prefill y decode, y el balanceo entre réplicas data-parallel. El título, traducido, dice lo necesario para un servicio de inferencia completo, fuera de este release.

Lo que llegó es el motor. Lo que quedó fuera es la especificación de una capa de serving.

Qué entrega DeepInfer

DeepInfer entrega el motor en kernels y paralelismo: FlashMLA, DeepGEMM, DeepEP, TileKernels, DeepSelect, atención en DP con CP balanceado, MoE en EP con EPLB, DSpark y salidas estructuradas en regex, JSON schema y EBNF. Es el framework de inferencia, no el servicio.

Una cláusula evita confusión: la atención en DP con CP balanceado es un recurso del motor, pero el Q&A dice que, en el servicio que DeepSeek opera con el V4.1-Flash, "TP and CP are not used for now": TP y CP no se usan por ahora. El release habilita lo que su producción no usa.

El alcance es estrecho. El README lista DeepSeek-V4.1-Flash como único modelo, con el checkpoint DeepSeek-V4.1-Flash-1017. La ventana de 1M y el max_tokens de al menos 256K vienen del model card.

El protocolo se completa con deepseek-recipe, en Rust con bindings de Python y licencia MIT, creado el 10/09/2026: traduce Messages, Chat Completions y Responses al formato de DeepSeek y devuelve respuesta completa o streaming.

El compromiso publicado es corto: el código de inferencia de los modelos siguientes sigue abierto en DeepInfer. El motor que llegó es cercano al interno, no idéntico: el kernel de decode interno de FlashMLA es de 5% a 10% más rápido, con un máximo de 5% de punta a punta.

El README declara que DeepInfer se construyó principalmente sobre vLLM, lo que cambia la cuenta del fork.

Qué no viene en el paquete

El README de DeepInfer dedica tres puntos a lo que falta, y el Q&A de deployment repite la lista: KV cache, la desagregación entre vision encoder, prefill y decode y el balanceo entre réplicas. Nada de eso está en el repositorio.

El subsistema de caché ocupa cerca de 100 PiB de SSD, con TTL de 3 días para agente y 7 para chatbot.

La salvedad está en el README: la desagregación entre vision encoder, prefill y decode no viene, y el README añade que "most required engine functionality is already implemented": la mayor parte de la funcionalidad que el motor exige ya está implementada. Falta sobre todo la capa de despliegue.

El EPLB viene incluido en el paquete y hace colocación de expertos, no admisión de peticiones entre réplicas. El Expert-Parallel Load Balancer que el Q&A lista entre los cuatro balanceadores internos es uno de los balanceadores de réplica que faltan: con #DP = #EP, la réplica EP es también la réplica que recibe peticiones. Tratar por qué el failover no es balanceo de carga y la admisión entre réplicas como la misma función es el mismo error de categoría.

El Q&A nombra cinco componentes internos: Prefill Load Balancer, Decode Load Balancer, Vision Encoder Load Balancer, Expert-Parallel Load Balancer y KVCache Storage. Y nombra un sexto, el Entrypoint del servicio, que hace match de prefijo por hash-chain sobre metadatos contra el kvcache-store local antes del enrutamiento.

La transferencia de KV cache entre modelos y agentes es el problema que resuelve ese clúster. Es plano de datos.

El número que dimensiona la brecha es una frase del Q&A: "we reach roughly 80% of a perfectly balanced offline benchmark", es decir, cerca del 80% de un benchmark offline perfectamente balanceado. Es DeepSeek midiendo su propio servicio contra el gráfico offline que publica, con sus balanceadores en su hardware. No es un piso de tercero ni algo que un gateway recupere.

Imagen: DeepSeek, documentación de DeepInfer (github.com/deepseek-ai/DeepInfer)

Offline no es serving

El README de DeepInfer describe el release como "offline inference with the core features needed for serving at scale", inferencia offline con las funciones centrales que exige servir a escala, y el código lo confirma: los ejemplos son scripts de inferencia, benchmark y barrido de concurrencia. El único módulo con "server" en el nombre expone /profile. No atiende peticiones.

El Q&A quita la ambigüedad: el prefill se dimensiona por tokens no cacheados, el decode por peticiones en ejecución. Un engine de decode recibe aviso de apagado y tiene 1 minuto para traspasar peticiones y KV cache, y el despliegue mantiene cuota redundante y prohíbe la reducción cuando la utilización pasa de 0,8.

"1P + 1D is deployable", es decir, un prefill más un decode es desplegable, con una razón de aproximadamente 1:1 y decode recomendado en EP64 o superior; la unidad eficiente más pequeña es 64 GPUs de prefill más 64 de decode. El benchmark usa 4 GPUs SM100 para prefill y 64 para decode: la distancia entre los dos es la distancia entre un gráfico y una factura. Una GPU con falla vuelve inutilizable la instancia completa, y la elección de pesos abiertos frente a modelos hospedados cambia con eso.

Los números que publicó DeepSeek y qué miden

Ninguno de los números de desempeño de este artículo fue medido por un tercero. Los de throughput del motor son autoinformados por DeepSeek y viven en los gráficos de Pareto del repositorio, transcritos por MarkTechPost el 20/10/2026: por encima de 25.000 tokens de salida por segundo por GPU, en EP64DP64, nextn=3, 75% de aceptación y 256 peticiones por rank. El 80%, los 155 billones y la tabla de DSpark vienen del Q&A, no de los gráficos.

Sin ese recorte, el número no existe: vale para 64 GPUs de decode y 131.072 tokens de contexto, con cerca de 100 tokens por segundo por usuario y más de 300 con 8 peticiones. En Ascend no hay medición: los benchmarks son en SM100.

La única cifra en dólares es de otra naturaleza: un clúster sirve 155 billones de tokens por día, con ingresos de US$ 38 por GPU-hora a precio fuera de pico, el "valley pricing" del Q&A leído el 22/10/2026. Ingreso no es costo. Precio fuera de pico no es precio de lista, y un framework abierto no tiene precio por token. Quien quiere reducir el costo de inferencia necesita su propia carga medida.

Dos máquinas, dos conjuntos de recursos

DeepInfer cubre dos plataformas y ninguna tercera: NVIDIA SM100 y Huawei Ascend 950 NPU, con build en Linux, GCC 13 o superior, Python 3.12, CUDA 13 en un camino y CANN 9.2 en el otro. Generaciones anteriores de NVIDIA, incluida Hopper, quedan fuera.

La paridad se detiene en el build. La inferencia batch-invariant y el muestreo determinista vienen marcados como "(NVIDIA only)", con variables de entorno y seed fija propias. En el camino Ascend ninguna de las dos existe, y la paridad de producción es una afirmación que la fuente no sostiene.

El número también existe de un solo lado: 25.000 tokens por GPU y 80% del benchmark son de SM100, y el camino Ascend entrega build, no curva. Paridad el día uno allí es ejecutar el V4.1-Flash.

Qué tiene que construir o comprar el operador

DeepInfer necesita tres capas, no dos: modelo, clúster y gateway. Un gateway de LLM cubre elección de modelo, proveedor y endpoint, failover, techo de gasto, trace y la elección de la réplica con menos trabajo en vuelo. No cubre el storage de 100 PiB, el tejido P/D, la admisión dentro del engine ni el drain con traspaso de caché.

El trade-off cierra el argumento. El Q&A escribe que "since any engine can hit any prefix, there is no prefix-affinity routing": como cualquier engine puede alcanzar cualquier prefijo gracias al tier 3FS, no hay enrutamiento por afinidad de prefijo. Afinidad sin tier compartido es un acuerdo peor que el pull por cuota.

Cinco piezas, con dueño y costo:

1. Tier de KV cache: clúster 3FS, TTL de 3 y 7 días. Dueño: plataforma y storage. Equivocarse cuesta prefill repetido.
2. Tejido P/D: mueve KV entre etapas a 400 Gbps por 8 GPUs. Dueño: plataforma y red. Equivocarse junta las etapas en la misma máquina.
3. Admisión entre réplicas: lee la cola real del engine. Dueño: serving. Equivocarse cuesta GPU ociosa.
4. Drain: aviso de 1 minuto con traspaso de KV. Dueño: plataforma. Equivocarse cuesta una petición perdida.
5. Cuota y EP size: capacidad redundante y EP redefinido después de una falla. Dueño: SRE. Equivocarse cuesta la instancia completa.

El Nexforce Router entra aquí como categoría: plano de control, enruta entre modelos y proveedores, y no guarda el caché del engine, no separa prefill de decode ni ejecuta DeepInfer. El costo operativo de un gateway de IA en producción es la cuenta de lo que cubre.

El criterio de decisión antes del primer clone

Cuatro respuestas deciden si descargar el repositorio de DeepInfer ahorra trabajo: el piso de hardware en tu carga, quién guarda el KV cache, quién admite peticiones entre réplicas y el costo real de mantener un fork. Ninguna de las cuatro está en el README.

1. Piso de hardware: no son 4 GPUs, sino la unidad de 64 más 64, o una fracción en 1P+1D.
2. Dueño del KV cache: si es tu clúster, el trabajo es el tier de 100 PiB; si es el proveedor, consumes un endpoint.
3. Admisión entre réplicas: el release no la trae; si nadie en el equipo ya construyó una, es la que define el plazo.
4. Costo del fork: Apache 2.0 permite cerrar, y la cuenta llega en la primera actualización por portar.

Preguntas frecuentes

¿Qué es DeepInfer?

DeepInfer es el motor de inferencia que DeepSeek anunció el 20 de octubre de 2026 bajo Apache 2.0, con kernels, paralelismo, decodificación especulativa y salidas estructuradas para DeepSeek-V4.1-Flash. Es el framework de inferencia, no el servicio: los ejemplos del repositorio son scripts offline, y la capa de serving, con KV cache, la desagregación entre vision encoder, prefill y decode y el balanceo, quedó fuera.

¿DeepInfer reemplaza la API de DeepSeek?

No. DeepInfer entrega el código que ejecuta el modelo en el hardware del operador; la API de DeepSeek entrega inferencia como servicio, con el clúster, el KV cache y los balanceadores que el release no incluye. Ejecutar el motor significa asumir storage, red y admisión de peticiones, además del drain que el propio Q&A describe. Los US$ 38 por GPU-hora son ingresos, no costo.

¿Qué falta para correr en producción?

DeepInfer llega sin tres elementos que el README lista como necesarios para un servicio completo: KV cache, la desagregación entre vision encoder, prefill y decode y el balanceo entre réplicas data-parallel. El Q&A de deployment añade autoscaling, cuota redundante, drain con traspaso de KV y el Entrypoint que casa prefijos por hash-chain. El engine, el paralelismo y el EPLB ya están en el paquete; lo que falta es la capa de operación.

¿Cuál es la licencia y se puede usar comercialmente?

DeepInfer usa Apache 2.0, confirmada en el README y en el campo de licencia de GitHub, y deepseek-recipe, un repositorio aparte, usa MIT, confirmada en el LICENSE. Las dos permiten uso comercial y modificación, sin obligación de publicar lo que se construye encima. Lo que la licencia no entrega es el código que falta: los balanceadores y el KVCache Storage quedaron en la infraestructura de DeepSeek.

Referencias

Fuentes leídas el 22/10/2026.

• Repositorio oficial de DeepInfer, README y doc/inference_deployment_qa.md, https://github.com/deepseek-ai/DeepInfer, 20/10/2026.
• deepseek-ai/deepseek-recipe, LICENSE (MIT), creado el 10/09/2026.
• Model card de DeepSeek-V4.1-Flash-1017, huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017.
• DeepSeek, documento sobre la apertura del motor de inferencia, abril de 2025.
• Post de DeepSeek en X, 20/10/2026, vía The New Stack.
• MarkTechPost, DeepSeek Open-Sources DeepInfer, 20/10/2026.
• The New Stack, DeepSeek open-sources the inference engine behind its API, 20/10/2026.

Próximo paso

La prueba cuesta menos que el fork. Correr el mismo prompt en más de un modelo, medir qué cambia en calidad, latencia y costo por tarea y elegir dónde cae cada petición responde en una tarde lo que el repositorio no responde. El Nexforce Router existe para esa etapa, con una API, una key y techo de gasto por key.