¿Qué es DeepInfer? El motor de inferencia de DeepSeek y las partes que no incluyó

DeepInfer es el framework de inferencia que DeepSeek publicó el 16 de octubre de 2026 bajo Apache-2.0, y sirve exactamente a un modelo: DeepSeek-V4.1-Flash, con DeepSeek-V4.1-Flash-1017 como checkpoint predeterminado. Ese alcance de modelo único es lo primero que hay que entender, porque explica casi todo lo demás sobre el repositorio. No se trata de un framework de servicio general que, por casualidad, incluya una configuración de DeepSeek. Es la ruta de código que DeepSeek ejecuta en producción, reducida a las partes generalizables, y es franco respecto al recorte: la propia lista del README sobre lo que necesita un servicio de inferencia completo, y sobre lo que esta versión no incluye, menciona un sistema de caché KV, la desagregación VE/Prefill/Decode y el balanceo de carga entre réplicas de paralelismo de datos. Lo que obtienes es la ruta de cómputo: kernels, paralelismo, decodificación especulativa, planificación y salida estructurada. Lo que no obtienes es la capa de almacenamiento y enrutamiento que hace que la ruta de cómputo sea barata de operar a escala. DeepSeek explica por qué: esos componentes están estrechamente acoplados a la infraestructura interna, así que el diseño se describe en un artículo publicado mientras que el código permanece interno.

¿Qué hay realmente en el repositorio?

La lista de características publicada se lee como un recorrido por los cuellos de botella de servir un modelo grande de mezcla de expertos. Están las bibliotecas de kernels que DeepSeek ha publicado antes —FlashMLA para la atención, DeepGEMM para las multiplicaciones de matrices, DeepEP para la comunicación de expertos en paralelo, además de TileKernels y DeepSelect—. Está el esquema de paralelismo: la atención se ejecuta como paralelismo de datos con paralelismo de contexto equilibrado, y la mitad de MoE se ejecuta como paralelismo de expertos con un balanceador de carga de expertos en paralelo. Está DSpark, la pila de decodificación especulativa, con longitudes de verificación que se programan en lugar de ser fijas. Está la reproducción acotada de SWA, que es el mecanismo que evita que una caché de atención de ventana deslizante obligue a una recomputación completa en cada fallo de caché. Está la programación asíncrona de lotes, la inferencia invariante por lotes con muestreo determinista y la salida estructurada restringida por regex, esquema JSON o EBNF.

El punto de entrada es deliberadamente pequeño. Después de establecer DEEPINFER_ACCELERATOR en nvidia o el equivalente de Ascend y ejecutar build.sh, el repositorio incluye examples/offline_inference.py, que ejecuta el checkpoint predeterminado de principio a fin. DEEPINFER_HF_MODEL_DIR lo apunta a un directorio de pesos diferente. Los benchmarks publicados se midieron en cuatro GPU SM100 para prefill y 64 GPU SM100 para decode, que es la escala del despliegue para el que se escribió el motor y no una demo pensada para un portátil.

El README también indica de dónde proviene el código, lo que conviene saber antes de leerlo. El motor se construyó originalmente, sobre todo, con vLLM, con inspiración de diseño tomada de SGLang y TensorRT-LLM. Ese linaje se refleja en la estructura —el planificador, la interfaz de atención paginada y la ruta de muestreo resultarán familiares para cualquiera que haya leído esos proyectos— y explica por qué la versión publicada es un fork de una pila de servicio en lugar de una arquitectura escrita desde cero. Lo que DeepSeek añadió es la parte específica de su propio modelo: el despliegue desagregado, el paralelismo amplio de expertos con su balanceador, la reproducción con ventana deslizante y DSpark.

Lo que no contiene, y por qué eso importa más

Las tres piezas faltantes no son omisiones menores. Cada una es un sistema que debe existir antes de que el motor atienda tráfico de producción, y cada una resulta costosa de una manera distinta.

• El sistema de caché KV.La reutilización de prefijos es donde está la mayor parte del ahorro en una carga de trabajo de chat, porque un acierto de caché sustituye un prefill. Sin un almacén de caché, cada solicitud recalcula su prompt. La propia documentación de DeepSeek describe el almacén que utiliza: un clúster 3FS dedicado en lugar de la memoria local del host, precisamente para que cualquier máquina de prefill pueda acceder a cualquier prefijo y la capacidad de caché pueda escalarse de forma independiente al cómputo.

• Desagregación de VE/Prefill/Decode. El README señala que la mayor parte de la funcionalidad del lado del motor ya existe en la versión; lo que falta es el despliegue. Desagregar el codificador visual, el prefill y el decode permite dimensionar cada etapa según su propio cuello de botella y controlar el tiempo hasta el primer token por separado del tiempo entre tokens. Eso es una decisión de infraestructura, no un flag.

• Balanceo de carga entre réplicas de datos paralelos. DeepSeek ejecuta cuatro balanceadores —prefill, decode, vision encoder y expert-parallel— y describe los cuatro en el informe. Nada de la lógica de enrutamiento se publica. Sin ella, una flota de réplicas vale tanto como el router que le pongas delante, y un router round-robin ingenuo destruirá la tasa de aciertos de caché que el almacén fue diseñado para proteger.

Leídas en conjunto, la omisión te indica qué tipo de artefacto es este. DeepInfer es una implementación de referencia de la ruta de cómputo, publicada para que el trabajo sobre el kernel y la planificación pueda inspeccionarse y reutilizarse, no una distribución que se instala y a la que se dirige el tráfico.

La barrera del hardware es el filtro real

DeepInfer está dirigido a NVIDIA SM100 y Huawei Ascend 950. No existe una vía para Ampere ni para Hopper, lo que excluye la mayoría de las GPU de la mayoría de los clústeres actuales. El resto del conjunto de herramientas es igual de específico: solo Linux, GCC 13 o superior, Python 3.12, CUDA 13 para NVIDIA o CANN 9.2 para Ascend. Y no hay versiones publicadas en absoluto —el repositorio tenía cero versiones publicadas cuando se consultó el 21 de octubre de 2026—, así que no hay nada que descargar ni nada que fijar. Lo clonas y lo compilas con tu propio conjunto de herramientas.

Esa combinación es inusual para una publicación de código abierto con tanta atención, y lo mejor es interpretarla como una declaración precisa del alcance y no como un descuido. Los kernels del repositorio están escritos para un conjunto de instrucciones y una interconexión específicos; las cifras del README provienen de ese hardware. Adaptar la ruta de cómputo a una generación anterior es justo el tipo de trabajo que una comunidad hace rápidamente y que una organización de ingeniería no puede prometer. A los pocos días de la publicación, apareció en GitHub una adaptación de terceros dirigida a piezas NVIDIA más antiguas, lo cual es una señal útil sobre la demanda y ninguna señal sobre si las cifras de rendimiento publicadas sobreviven a la adaptación.

La forma de despliegue que DeepSeek realmente ejecuta

El documento de arquitectura es donde los supuestos del repositorio se vuelven legibles. El sistema está desagregado en un codificador de visión, prefill y decode, además de nodos de almacenamiento dedicados. Prefill usa paralelismo de expertos de 2 a 8 con paralelismo de datos equivalente, eligiendo la configuración más pequeña que HBM permite. Decode va por otro camino: paralelismo de expertos y paralelismo de datos de 64 a 128, lo que DeepSeek llama Wide-EP, usando la configuración más grande que permiten las GPU disponibles. El paralelismo de tensores y el paralelismo de contexto no se usan en absoluto. El codificador de visión se ejecuta en una GPU por instancia, con GPUs más económicas recomendadas, porque el codificador no es donde se gasta el dinero.

El despliegue más pequeño que tiene sentido se deduce de esas cifras. Se ejecutarán una GPU de prefill y una GPU de decode, y en la práctica la proporción entre los dos grupos es de aproximadamente uno a uno. Pero como decode necesita 64 GPU o más para obtener el beneficio del paralelismo de expertos, la unidad eficiente más pequeña es 64 GPU de prefill más 64 GPU de decode. Ese es el número que hay que retener al leer cualquier afirmación sobre la eficiencia de DeepInfer: las cifras describen un despliegue de 128 GPU, y la mitad de él es una etapa.

Dividir el prefill y el decode entre centros de datos es técnicamente posible porque DeepSeek-V4.1-Flash comprime sustancialmente su caché KV, y el propio despliegue de DeepSeek sitúa nodos de inferencia en centros de datos distintos pero adyacentes. El presupuesto es de unos 400 Gbps de interconexión por cada ocho GPU, y el documento es franco sobre el coste en fiabilidad: la fibra entre edificios es fácil de cortar.

¿Por qué la decodificación está tan extendida?

El paralelismo de expertos amplio es la decisión más determinante del diseño, y es fácil malinterpretarla como un truco de escalado. En una capa de mezcla de expertos, cada token toca un número reducido de expertos, por lo que el coste de un paso de decodificación está dominado por el movimiento de los pesos de los expertos y las activaciones, más que por la intensidad aritmética. Distribuir los expertos entre 64 o 128 GPU reduce el tráfico de memoria por paso que aporta cada GPU, lo que aumenta los tokens por segundo si —y esta es la condición— la carga entre expertos se mantiene equilibrada. Para eso está el balanceador de carga de expertos en paralelo.

Los ajustes de DeepSeek son lo suficientemente específicos como para copiarlos. Para prefill, cada GPU mantiene cuatro expertos redundantes además de los que posee, las estadísticas se recopilan en una ventana de 100 pasos y los expertos se reasignan cada 1000 pasos, con los pesos barajados dentro del grupo a través de la memoria compartida NVLink. El desequilibrio medido —el rango más lento dividido por la media— resultó ser de 1.074 para una configuración EP4/DP4 y de 1.045 para EP2/DP2. Para decode, los ajustes se extienden: un experto redundante por GPU, una ventana de estadísticas de 1000 pasos, reasignación cada 10 000 pasos y un desequilibrio medido de 1.090. La diferencia entre ambos es lo importante. Prefill ve trabajo en ráfagas y heterogéneo y necesita un reequilibrio rápido; decode ve un flujo constante y puede permitirse una ventana larga, por lo que se reequilibra rara vez y casi no paga nada por ese privilegio.

El lado del enrutamiento tiene el mismo carácter. Las solicitudes de prefill se agrupan por longitud total del contexto en cuatro niveles —menos de 16K, de 16 a 64K, de 64 a 256K, y 256K o más— y los motores se asignan a los niveles según la proporción de la demanda de cómputo de cada nivel en la ronda anterior. Dentro de una GPU, el tamaño de fragmento de cada paso de prefill no es fijo: un modelo de coste cuadrático ajustado predice cuánto tardará un paso dado el número de tokens de la secuencia y el prefijo ya calculado, y el planificador determina el fragmento más grande que cabe en un presupuesto de 32.768 tokens dentro del tiempo restante. El balanceador de decode equilibra dos dimensiones a la vez, el número de solicitudes y la longitud total de la caché KV, enviando solicitudes cortas a GPUs con baja concurrencia y caché larga, y solicitudes largas a GPUs con caché pequeña. El propio resumen de DeepSeek de cuánto aporta todo esto: aproximadamente el 80 por ciento de un benchmark offline perfectamente equilibrado.

La caché, y la pregunta de los tres días

La caché KV reside en un clúster 3FS dedicado, no en la memoria local del host, y esa decisión determina el resto del diseño de almacenamiento. Los datos se almacenan con codificación de borrado 10+2, por lo que cada grupo de codificación sobrevive a dos fallos simultáneos de nodos; una lectura envía solicitudes a los 11 nodos del grupo y cualesquiera 10 respuestas bastan para decodificar. Un worker de recolección de basura se ejecuta en cada nodo de almacenamiento y desaloja según LRU una vez superado un umbral. El servidor recomendado tiene 20 unidades de estado sólido de 30,73 TB cada una y sostiene al menos 40 GB/s de lectura y 5 GB/s de escritura, dimensionado para retener aproximadamente 24 horas de datos por servidor. En la práctica, el clúster funciona con alrededor de 14,4 TB de caché lógica por GPU en línea, con una capacidad física mayor que esa.

La residencia es donde la compensación se vuelve visible. No hay lógica de caducidad en el lado de la caché; el TTL se establece en el lado del almacenamiento en tres días para el tráfico de agentes y siete días para el tráfico de chatbots, en un clúster que contiene aproximadamente 100 petabytes de almacenamiento de estado sólido. La división existe porque el tráfico de chatbots tiene una cola larga de aciertos mucho más pesada: una pequeña cantidad de caché se lee muchas veces, por lo que perderla cuesta más tasa de aciertos global de lo que sugiere el volumen. El costo medido por DeepSeek de reducir la retención de chatbots a tres días es del 0,5 al 1 por ciento de la tasa de aciertos de caché. Ese es un número pequeño que resulta representar una gran cantidad de prefill recalculado.

La atención de ventana deslizante tiene una caché separada con reglas diferentes. La caché SWA no entra en los bloques paginados; cada secuencia ocupa una ranura de tamaño fijo en la memoria del host y, para DeepSeek-V4.1-Flash, las capas almacenadas son las primeras 20. Solo esa región persiste: 20 capas por 134 tokens por 528 bytes, lo que son 1.415.040 bytes por secuencia en un formato MXFP8. Nada va al clúster de almacenamiento; permanece en la memoria de la máquina que lo produjo, con un directorio en memoria que registra qué máquina contiene qué, y un acierto entre máquinas lo recupera a través de una VLAN de 400 Gbps.

Los dos mecanismos que producen las cifras principales

El replay acotado es el más interesante de los dos porque toma un coste ilimitado y lo convierte en constante. Normalmente, un fallo de caché de ventana deslizante implica recalcular la ventana desde el principio, y el coste crece con la longitud del contexto y el número de capas. En cambio, DeepSeek solo recalcula los 128 tokens más recientes y trunca la ventana de atención a ese segmento, lo que produce una caché SWA aproximada a un coste fijo. En el lado del codificador, esto desacopla por completo la longitud de acierto de la caché de prefijos de la caché SWA: si falta la caché SWA, se reproducen los últimos 128 tokens del prefijo acertado mientras la caché de bloques se reutiliza intacta.

El lado del decodificador es donde el ahorro es elevado. En esta arquitectura, la caché de bloques de las capas del decodificador se proyecta a partir del estado oculto de la última capa del codificador, por lo que solo la caché SWA del decodificador debe calcularse por capa, y reconstruirla exactamente implicaría pasar los últimos 2.560 tokens por 20 capas del decodificador en cada prellenado. Reproducir 128 tokens en su lugar y usar el resultado solo para la decodificación, en vez de dejarlo entrar en la caché de prefijos, casi reduce a la mitad el cómputo total del prellenado. Ese único cambio vale más que la mayoría de las optimizaciones de kernel, y es el tipo de cosa que solo puede hacer un equipo que controla la arquitectura del modelo.

La contribución de DSpark es menor y más convencional. Los tokens de borrador tienen distintas probabilidades de aceptación según la solicitud y la posición, por lo que verificar un número fijo de cinco borradores por paso desperdicia cómputo en tokens que serán rechazados. Una cabeza de confianza predice la tasa de aceptación de cada token de borrador, y el planificador ordena los borradores por retorno esperado y verifica solo el prefijo que maximiza el rendimiento. En producción, el modelo de borrador sigue generando cinco tokens por paso; el número verificado baja de 5,00 a entre 3,2 y 4,4, una reducción de alrededor del 30 por ciento, mientras que la longitud aceptada apenas cambia: 3,29 frente a 3,20. Según los datos de referencia de EP64/DP64, eso equivale a entre un 4 y un 7 por ciento más de rendimiento con alrededor de 60 secuencias concurrentes por rango. Con exactamente 60, el rendimiento por rango pasa de 13.730 a 14.466 tokens por segundo. Por debajo de unas 16 secuencias concurrentes, la técnica supone una pequeña pérdida neta, algo que conviene saber antes de adoptarla para un despliegue de bajo tráfico.

Qué significa la cifra de 155 billones

La cifra más citada asociada a este lanzamiento es un único clúster que sirve 155 billones de tokens al día con unos ingresos totales de 38 dólares estadounidenses por GPU-hora a precios de valle. Ambas partes están reportadas por el proveedor y ninguna es un benchmark que se pueda reproducir, lo que no las hace poco interesantes: una cifra de ingresos por GPU-hora es un tipo de afirmación genuinamente distinto al de una cifra de rendimiento, porque integra la utilización, el precio y la tasa de aciertos de caché en una sola línea. También es la cifra que más probablemente se cite sin sus matices, así que los matices merecen quedar por escrito: un único clúster, precios de valle, ingresos en lugar de coste y un agregado de prefill, decode y codificador de visión.

Dos revelaciones más pequeñas son más directamente útiles. Al kernel de decodificación FlashMLA del repositorio público le falta una optimización de ensamblador ajustada a mano que sí tiene la versión interna, lo que lo hace entre un 5 y un 10 por ciento más lento de forma aislada; DeepSeek afirma que el rendimiento de extremo a extremo difiere como máximo en un 5 por ciento. Y el modelo borrador interno para decodificación especulativa es más reciente que el publicado, y la diferencia de rendimiento se describe como pequeña. Ambas afirmaciones establecen una expectativa sobre cuánto del rendimiento publicado puede alcanzar un tercero copiando el código, y la respuesta es: la mayor parte, siempre que el hardware coincida.

El repositorio, tal como está

La captura de arriba se tomó el 21 de octubre de 2026 y muestra que la página indica 16,3 k estrellas. La API de GitHub, consultada ese mismo día, devolvió 16.590 estrellas, 1.649 forks y 176 issues abiertos, con los issues desactivados y las discusiones canalizadas a GitHub Discussions. El número de estrellas ha seguido creciendo desde entonces, así que interpreta cada cifra de aquí como una marca temporal y no como una propiedad del código. Un tráfico de ese calibre en menos de una semana habla más del interés por la pila de servicio de DeepSeek que de la preparación del código, y el recuento de cero releases dice lo demás.

Si estás pensando en ejecutarlo tú mismo

El resumen honesto es que DeepInfer merece una lectura atenta y es difícil de operar. Cuatro preguntas te dirán si encaja.

• ¿Tienes SM100 o Ascend 950? Todo lo demás en la cadena de herramientas se deriva de esto. Sin el acelerador adecuado, las cifras publicadas no se transfieren, y los ports de la comunidad no están validados a escala de producción.

• ¿Se pueden ejecutar 64 GPU de decodificación en un solo dominio de comunicación? El paralelismo de expertos amplio no es una optimización que puedas omitir; es la configuración en torno a la cual se diseñó la ruta de decodificación. Por debajo de esa escala, estás ejecutando un sistema diferente con el mismo nombre.

• ¿Ya tienes una caché de prefijos? Si no, estás comparando la ruta de cómputo de DeepInfer con un stack de la competencia que ya incluye una, y la comparación parecerá peor de lo que el diseño merece.

• ¿Puedes permitirte escribir la capa de enrutamiento? El agrupamiento en cubos de prefill, el balanceo de decode y la reasignación de expertos están descritos con suficiente detalle como para reimplementarlos, y reimplementarlos supone semanas de trabajo que el repositorio no hace por ti.

Si prefiere no poseer ninguno de los anteriores

Para la mayoría de los equipos, la pregunta práctica no es cómo desplegar DeepSeek-V4.1-Flash, sino dónde llamarlo. El modelo está disponible a través de una API compatible sin necesidad de construir un clúster de 128 GPU ni de reimplementar un equilibrador de carga, y es el mismo modelo cuya arquitectura ha venido describiendo este artículo: el mismo manejo de contexto, el mismo comportamiento de salida estructurada, sin el trabajo de desagregación.

La comparación que hay que hacer no es qué motor es más rápido en abstracto, porque las cifras publicadas son mediciones reportadas por el proveedor en hardware que la mayoría de los lectores no tiene. Sino si la carga de trabajo es una en la que un TTL de caché de 3 días y un grupo de decodificación de 64 GPU cambian el precio, o una en la que una solicitud cada pocos segundos a través de una API es simplemente más barata que cualquiera de las operaciones descritas anteriormente. Para el segundo caso —que es la mayoría de los casos—, la cantidad correcta de DeepInfer que se debe usar es ninguna, y la cantidad correcta que se debe leer es toda. Empiece por la página del modelo DeepSeek V4.1 Flash si quiere el endpoint; comience por el README del repositorio si quiere saber qué está haciendo el endpoint.