DeepSeek ha liberado parte de la tecnología con la que ejecuta sus modelos a gran escala. Se llama DeepInfer. Repasamos cómo funciona el motor de inferencia de DeepSeek, qué optimizaciones trae y por qué pesan tanto en el rendimiento y en el coste de la IA.
Cuando hablamos de DeepSeek, casi siempre acabamos hablando de sus modelos: cuántos parámetros tienen, cómo programan, qué resultados sacan frente a Claude, GPT o Gemini. Hay otra parte de su tecnología que me parece igual de interesante y que recibe mucha menos atención.
¿Cómo ejecutas un modelo de cientos de miles de millones de parámetros, atiendes miles de peticiones a la vez y mantienes un coste de inferencia competitivo? Entrenar el modelo es un trabajo, y hacer que funcione bien para miles de usuarios es otro bastante distinto.
El 20 de octubre de 2026, DeepSeek publicó DeepInfer , su framework de inferencia de alto rendimiento, con licencia Apache 2.0. Sale del sistema que usa en sus servicios de producción, aunque la versión liberada todavía no incluye toda la infraestructura necesaria para montar un servicio completo. Su interés va bastante más allá del repositorio.
Hace poco contamos por qué los modelos abiertos nunca habían sido tan buenos y cómo DeepSeek está compartiendo varias capas de su tecnología: los modelos, el motor de inferencia y el software para construir agentes alrededor de ellos. DeepInfer es una de esas capas, y ayuda a ver algo que se suele olvidar al comparar modelos: las capacidades del modelo y el rendimiento de la infraestructura que lo ejecuta son dos problemas diferentes.
Qué hace realmente un motor de inferencia
Imagina una aplicación que usa DeepSeek para analizar documentos. Un usuario sube un contrato de veinte páginas y pregunta qué obligaciones de pago contiene. Tu aplicación prepara el contexto, llama al modelo y recibe la respuesta. Visto desde fuera, poca cosa.
Entre la petición y la respuesta hay un sistema que procesa miles de tokens de entrada, reparte operaciones entre dispositivos, guarda información en memoria y genera tokens nuevos, casi siempre mientras atiende otras peticiones.
El motor de inferencia organiza buena parte de ese trabajo. Decide cómo corre el modelo sobre el hardware, cómo se agrupan las peticiones, cómo se usa la memoria y qué técnicas sacan más rendimiento de los mismos recursos. En esta categoría están proyectos conocidos como vLLM, SGLang o TensorRT-LLM.
DeepInfer entra en la misma familia, pero está muy adaptado a la arquitectura y a las necesidades operativas de DeepSeek V4.1 Flash . El propio laboratorio reconoce que lo construyó sobre una base importante de vLLM y que incorporó ideas de SGLang y TensorRT-LLM. Lo interesante está en cómo DeepSeek combina y especializa técnicas que ya existían.
Esto tiene una consecuencia económica: puedes mejorar el rendimiento de un modelo sin tocar sus pesos. Si procesas más peticiones con las mismas GPUs, reduces el tiempo que pasan esperando o aprovechas mejor la memoria, el sistema gana capacidad sin que nadie entrene un modelo más listo. Tu factura no baja automáticamente por eso, pero el coste de ofrecer inferencia puede cambiar mucho.
Prefill y decode: dos problemas diferentes
Volvamos al contrato.
Lo primero que hace el modelo es procesar el documento y la pregunta: leer el contexto y calcular las representaciones que usará al generar. Esa fase se llama prefill. Simplificando, el prefill procesa los tokens de entrada y construye información intermedia, entre ella la caché de claves y valores (KV cache), que permite reutilizar cálculos de atención durante la generación. Admite mucho paralelismo y, según el tamaño del contexto, suele pedir bastante cómputo.
Después llega el decode, donde el modelo escribe la respuesta token a token. Cada token depende de los anteriores, así que la salida no se puede calcular de golpe como el prompt.
Con eso cambian también las necesidades del hardware. En muchas configuraciones el prefill está limitado sobre todo por la capacidad de cálculo, y el decode por el acceso a memoria, el movimiento de datos y la concurrencia. No es una regla universal, pero explica por qué cada fase pide optimizaciones distintas.
Ahora piensa en cientos de usuarios a la vez. Unos mandan documentos enormes y otros preguntas de dos líneas. Unos esperan respuestas cortas y otros generan miles de tokens. Si gestionas mal esa mezcla, acabas con GPUs esperando datos, operaciones bloqueadas y usuarios aguantando latencias que sobran. Y las GPUs no son baratas.
Por eso una de las decisiones importantes en inferencia a gran escala es optimizar el prefill y el decode por separado y, cuando compensa, dedicarles recursos distintos. DeepSeek lo hace en su arquitectura de producción. DeepInfer incluye mecanismos relacionados, aunque la versión abierta todavía no trae el sistema completo de desagregación de fases ni el balanceo entre réplicas.
Tener clara esta distinción ayuda a leer el resto del repositorio. Unas optimizaciones buscan procesar más información, otras generar más tokens y otras reducir el tiempo que el hardware pasa parado. Cada una ataca un problema distinto.
Dónde actúa cada optimización: el prefill lee el prompt de una vez, el decode escribe token a token y el paralelismo de expertos atraviesa las dos fases.
Cómo ejecutar un modelo enorme sin que unas GPUs esperen a otras
DeepSeek V4.1 Flash usa una arquitectura Mixture-of-Experts (MoE). Tiene cientos de miles de millones de parámetros, pero en cada paso de inferencia solo activa algunos expertos especializados para procesar cada token. Así ofrece mucha capacidad sin usar todos sus parámetros en cada operación.
El problema aparece al repartir esos expertos entre GPUs. Si muchas peticiones tiran de los mismos expertos y otros apenas se usan, unas GPUs se saturan mientras otras esperan. Además, cada token tiene que viajar hasta el dispositivo donde está su experto, procesarse allí y volver al flujo del modelo. Ese viaje también cuesta tiempo.
DeepInfer usa Expert Parallelism para repartir los expertos entre dispositivos y Expert Parallel Load Balancing (EPLB) para equilibrar su uso. Según la documentación de despliegue de DeepSeek, cada GPU guarda además unos pocos expertos redundantes con réplicas de los más solicitados, y el reparto se recalcula periódicamente a partir de la carga observada. Integra también DeepEP, especializado en comunicación eficiente para modelos MoE, junto con DeepGEMM, FlashMLA, TileKernels y otros kernels optimizados para operaciones concretas. El objetivo es exprimir mejor el hardware y recortar el trabajo que no aporta nada a la respuesta.
Un matiz importante: que un modelo active una parte pequeña de sus parámetros por token no significa que baste con cargar esa parte en memoria. La infraestructura necesita tener disponibles todos los expertos que pueden salir seleccionados y decidir cómo se distribuyen. Ejecutar un MoE enorme sigue exigiendo mucha infraestructura, y por eso el paralelismo, la comunicación entre GPUs y el balanceo de carga pesan tanto.
Ejemplo simplificado: tres tokens eligen el experto E1, la GPU 1 se satura y el balanceo coloca una réplica de E1 en la GPU 4.
Tres formas de distribuir el trabajo
DeepInfer permite configurar distintas estrategias de paralelismo según el hardware y la carga. Los ejemplos oficiales incluyen estas tres:
python examples/offline_inference.py --ep 8
python examples/offline_inference.py --ep 2 --dp 8
python examples/offline_inference.py --ep 2 --cp 8Son tres ejemplos independientes, no una secuencia. Cada uno necesita un entorno compatible con suficientes aceleradores bien configurados.
El primero usa Expert Parallelism (EP) y reparte los expertos del modelo entre dispositivos. Es clave en arquitecturas MoE, donde cada token puede necesitar expertos distintos.
El segundo combina EP con Data Parallelism (DP), que reparte el trabajo entre réplicas o particiones de ejecución para atender cargas diferentes.
El tercero añade Context Parallelism (CP), que distribuye el procesamiento del contexto entre dispositivos. Viene especialmente bien con secuencias largas que consumen muchos recursos de atención.
Las tres estrategias se pueden combinar de muchas maneras según el hardware, el modelo y la carga. Lo difícil es dar con una configuración que aproveche los recursos sin añadir más comunicación y coordinación de la necesaria. Un mismo modelo puede rendir de forma muy distinta según cómo organices su ejecución, y esa es una de las partes más interesantes de la inferencia a gran escala.
Cómo conseguir que las GPUs pasen menos tiempo esperando
Hay otra optimización que me gusta especialmente: la planificación asíncrona.
Un motor de inferencia no se pasa todo el tiempo ejecutando el modelo. También organiza peticiones, prepara lotes, gestiona estados y coordina la ejecución, y parte de ese trabajo ocurre en CPU. En un paso de decode sin solapar, la GPU queda parada mientras la CPU procesa el resultado del paso actual y planifica el siguiente. Si la GPU tiene que esperar a que la CPU termine, estás tirando capacidad.
El planificador asíncrono de DeepInfer solapa la preparación de los siguientes lotes con la ejecución de los actuales. Mientras la GPU ejecuta el paso N, la CPU ya planifica el N+1 y post-procesa el anterior. DeepSeek dice que sigue el enfoque de implementaciones previas como SGLang y NanoFlow, y lo activa por defecto.
El repositorio lo llama zero-overhead batch scheduler. Yo leería el nombre como un objetivo de diseño, porque planificar siempre tiene algún coste. Lo que importa es reducir los tiempos muertos y mantener ocupados los dispositivos.
Para mejorar el rendimiento de un sistema no siempre hace falta una GPU más rápida: a menudo hay capacidad sin usar en los huecos en los que la GPU espera a la CPU. Con decenas de aceleradores, pequeñas pérdidas de eficiencia en cada paso suman mucha capacidad desaprovechada.
DSpark: generar varios tokens sin avanzar siempre de uno en uno
DeepInfer también incorpora decodificación especulativa.
En la generación convencional, el modelo produce un token, actualiza su estado y pasa al siguiente. Ese avance secuencial es una de las limitaciones del decode. La decodificación especulativa propone varios tokens candidatos de una vez y después los comprueba. Si se aceptan suficientes, el modelo avanza varios tokens en una misma iteración de verificación y necesita menos pasos.
DeepInfer lo hace con DSpark y un mecanismo de verificación que usa estimaciones de confianza para organizar el trabajo. La configuración de longitud variable se activa con DEEPINFER_ENABLE_MTP_VARLEN=1, y DEEPINFER_USE_NEXTN_DECODE controla la longitud máxima del borrador especulativo. El valor por defecto documentado es cinco.
¿Por qué importa la confianza? Porque proponer tokens también cuesta. Si adelantas demasiados y luego hay que descartarlos, ese trabajo se pierde. No todas las secuencias tienen la misma probabilidad de aceptarse ni siempre compensa especular lo mismo. Según la documentación de DeepSeek, una cabeza de confianza estima la probabilidad de aceptación de cada token del borrador, y el planificador elige qué prefijo merece verificarse para sacar el máximo rendimiento efectivo.
Las estimaciones de confianza ayudan a decidir cómo organizar la verificación, pero los tokens propuestos se siguen comprobando.
Ejemplo conceptual: tres tokens del borrador se aceptan, el cuarto se corrige y el quinto no llega a verificarse. Cuatro tokens en un paso.
La mejora real depende de cuántos tokens se aceptan, de lo que cuesta producirlos y verificarlos y del tipo de carga. Activar DSpark no hace que cualquier petición se genere el doble de rápido. Sí es un buen ejemplo de cómo atacar una limitación del proceso de generación sin tocar las capacidades del modelo.
SWA bounded replay: evitar repetir cálculos que ya no necesitamos
Una optimización menos conocida del repositorio es SWA bounded replay.
Para entenderla hay que saber qué es Sliding Window Attention. En vez de dejar que cada posición atienda siempre a todo el historial, algunos mecanismos de atención trabajan solo con una ventana de tokens recientes. Eso recorta parte del coste de los contextos largos, aunque el detalle depende de la arquitectura de cada modelo.
Ahora imagina que el decoder necesita reconstruir información durante el prefill. Una implementación poco cuidadosa podría repetir trabajo sobre una secuencia mucho más larga de lo necesario. Si la atención que hay que reconstruir está limitada a una ventana, no hace falta reproducir todo ese historial.
Bounded replay conserva y vuelve a procesar solo un sufijo acotado del contexto, lo bastante largo para cubrir las dependencias necesarias. DeepInfer lo documenta con dos variables:
DEEPINFER_YOCO_PREFILL_TRUNCATION_MODE=compact
DEEPINFER_YOCO_PREFILL_KEEP_TOKENS=140Los 140 tokens son el valor por defecto documentado para V4.1 y no sirven como recomendación general para cualquier arquitectura. DeepSeek avisa de que el sufijo retenido debe cubrir la ventana de atención y la longitud máxima de retroceso que pueda necesitar el sistema. Si guardas menos de lo necesario, puedes acabar alterando el comportamiento que esperas del modelo.
El ahorro no es menor. Según la documentación de despliegue de DeepSeek, reconstruir esa caché de forma exacta obligaría a pasar los últimos 2.560 tokens por las 20 capas del decoder; recalculando solo el final del prompt, el cómputo total de prefill baja casi a la mitad.
Esta técnica resuelve un problema distinto al de DSpark. La decodificación especulativa intenta avanzar más rápido durante la generación, y SWA bounded replay evita trabajo redundante al reconstruir el contexto que necesita el decoder. Se complementan, y las dos dejan claro que la eficiencia de la inferencia depende de conocer a fondo el modelo que ejecutas.
Que el resultado sea reproducible también importa
Algunas funcionalidades de DeepInfer buscan más control sobre los resultados, al margen de los tokens por segundo.
Permite restringir la generación con expresiones regulares, JSON Schema o gramáticas EBNF. Si extraes datos de facturas y tu aplicación espera un JSON con ciertos campos, estas restricciones evitan parte de los errores de formato. Los valores extraídos pueden seguir estando mal, porque un JSON válido puede contener información equivocada, pero al menos separas el problema del formato del problema de la calidad.
También incorpora batch-invariant inference y muestreo determinista. Cuando un servicio agrupa peticiones para aprovechar mejor las GPUs, algunas operaciones numéricas dan resultados ligeramente distintos según cómo esté compuesto el lote, y esas diferencias pueden acabar cambiando los tokens generados. En un chatbot casi da igual. Si estás reproduciendo un fallo, comparando dos configuraciones o corriendo una evaluación técnica, tener resultados consistentes ayuda mucho.
DeepInfer tiene modos para mantener los resultados invariantes respecto al lote y para controlar el muestreo con semillas. Según la documentación actual, funcionan bajo condiciones concretas y algunos solo en entornos NVIDIA: el muestreo determinista, por ejemplo, exige desactivar la verificación de longitud variable de DSpark. La reproducibilidad completa depende además del modelo, de los parámetros de generación y del entorno de ejecución. Aquí lo que se gana es un sistema más controlable.
Qué hace diferente a DeepInfer frente a vLLM o SGLang
Quien ya trabaje con infraestructura de inferencia se preguntará, con razón, para qué hace falta otro motor si ya existen vLLM, SGLang o TensorRT-LLM.
Mi respuesta es la especialización. vLLM y SGLang tienen ecosistemas amplios y soportan muchas familias de modelos. DeepInfer viene de una infraestructura diseñada para las necesidades concretas de DeepSeek, y eso le permite tomar decisiones muy pegadas a la arquitectura de sus modelos, al hardware que usan y a los patrones de ejecución que quieren optimizar. La combinación de kernels especializados, Expert Parallelism, balanceo de carga, DSpark, planificación asíncrona y SWA bounded replay sale de esa especialización.
Tampoco conviene presentar todo eso como inventos exclusivos de DeepInfer. Algunas piezas vienen de proyectos que DeepSeek ya había publicado por separado; otras usan técnicas conocidas o se apoyan en motores anteriores. El propio repositorio reconoce de forma explícita el papel de vLLM y las aportaciones conceptuales de SGLang y TensorRT-LLM.
A mí eso me parece un mérito. Así funciona el desarrollo abierto: unos equipos comparten tecnología, otros reutilizan componentes y cada uno construye lo que necesita. Más que preguntarse si DeepInfer sustituirá a vLLM o SGLang, merece la pena ver qué se puede aprender de sus decisiones y qué optimizaciones acabarán beneficiando al resto del ecosistema.
De momento no hay una comparación pública lo bastante controlada para afirmar que DeepInfer sea más rápido que esos motores en general. Haría falta ejecutar el mismo modelo, en el mismo hardware, con configuraciones equivalentes y cargas representativas. Los benchmarks que ha publicado DeepSeek no hacen esa comparación.
Los benchmarks de inferencia también necesitan contexto
El repositorio incluye pruebas de rendimiento de prefill y decode, con scripts para reproducir las mediciones en configuraciones compatibles. Las condiciones son exigentes: cuatro GPUs NVIDIA SM100 para prefill y 64 para decode, cada grupo dentro de un dominio de escalado. Eso no se monta con un servidor cualquiera.
Más que el hardware, me interesa cómo leer las cifras.
En prefill, el benchmark mide los tokens procesados por segundo y por GPU durante intervalos de ejecución estable. Antes descarta parte del calentamiento y usa una ventana de medición definida. Así se ve cómo responde el motor cuando cambia la cantidad de trabajo que recibe.
En decode, la documentación da más que pensar. El script de benchmark calcula el throughput a partir de la velocidad de los pasos de generación, el número de peticiones concurrentes, los tokens especulativos y el paralelismo de contexto:
throughput = avg_SPS × decode_num_requests × (1 + nextn) / cpavg_SPS son los pasos por segundo, decode_num_requests el tamaño del lote de decode, nextn la longitud especulativa configurada y cp el factor de paralelismo de contexto.
Y aquí está el detalle. El cálculo da por aceptados todos los tokens especulativos, sea cual sea la tasa de aceptación real. El repositorio lo llama full-acceptance accounting. Con 64 peticiones y cinco tokens especulativos, cada paso cuenta 384 tokens antes de aplicar el factor de paralelismo de contexto.
Es una convención útil para comparar ejecuciones en las mismas condiciones, pero esos tokens no tienen por qué haber acabado en la respuesta final. Para conocer el rendimiento efectivo de generación habría que contar cuántos se aceptan de verdad en la verificación.
La curva de decode que aparece en el README usa otra convención, y conviene no mezclarlas. Está dibujada con nextn=3 y una aceptación supuesta del 75 % por token, lo que da τ=3,25 tokens por paso y petición. Ese 75 % es un parámetro que se pasa al script que dibuja el gráfico, no una tasa medida durante la prueba. La curva describe cómo escalaría el sistema si la aceptación fuera esa.
Gráficos originales del repositorio de DeepInfer, recortados y en modo oscuro, sin cambiar valores ni escalas. La curva de decode asume un 75 % de aceptación por token.
Tampoco se puede trasladar la cifra del benchmark al throughput de una aplicación en producción. Ahí entran muchos más factores: peticiones de longitudes distintas, patrones de concurrencia cambiantes, una aceptación especulativa que varía, el procesamiento de entrada, la gestión de memoria y toda la infraestructura que rodea al motor.
Conviene separar tres cosas: el rendimiento de los pasos de generación, el throughput contabilizado y los tokens útiles que realmente se producen. Esta precisión no quita valor a los benchmarks de DeepInfer. Delimita su alcance. Es muy fácil ver una cifra de tokens por segundo y suponer que es la velocidad de una API, y muchas veces no lo es.
Throughput, latencia y utilización: tres métricas que no significan lo mismo
Al evaluar infraestructura de inferencia, una empresa se encuentra con cifras que parecen comparables pero responden a preguntas distintas.
| Métrica | Qué mide | Por qué importa |
|---|---|---|
| Throughput | Cantidad de trabajo procesada por unidad de tiempo | Determina la capacidad agregada del sistema |
| Latencia | Tiempo que tarda una petición en producir o completar su respuesta | Afecta directamente a la experiencia del usuario |
| Utilización | Proporción de los recursos disponibles que se aprovecha | Influye en la eficiencia económica de la infraestructura |
Puedes subir el throughput atendiendo más peticiones a la vez y empeorar al mismo tiempo la latencia de cada usuario. La curva de decode de DeepInfer lo enseña: al pasar de 8 a 256 peticiones por réplica, el throughput por GPU se multiplica y la velocidad que percibe cada usuario cae a cerca de un tercio. También puedes mejorar la utilización del hardware sin ahorrar en proporción, si el coste de las máquinas, su aprovisionamiento o la capacidad reservada no cambian.
Ninguna métrica sola dice qué infraestructura es mejor para todas las aplicaciones. Un sistema que procesa documentos en segundo plano querrá maximizar el trabajo total. Un asistente interactivo seguramente priorice el tiempo hasta el primer token y la velocidad de generación que percibe el usuario.
DeepInfer trae optimizaciones útiles para estos problemas, pero cuáles usar y cómo configurarlas depende de la carga. Por eso un benchmark técnico necesita ir acompañado de una explicación de qué mide.
DeepInfer todavía no es un servicio de inferencia completo
Antes de que alguien intente desplegarlo, conviene dejar algo claro. DeepInfer es open source, pero no puedes instalarlo y ofrecer al día siguiente un servicio equivalente a la API oficial de DeepSeek.
La versión pública está preparada para inferencia offline y soporta DeepSeek V4.1 Flash. Pide hardware y entornos concretos: la documentación menciona GPUs NVIDIA SM100 y aceleradores Huawei Ascend 950, con sus requisitos de CUDA o CANN.
DeepSeek también enumera componentes que no forman parte de esta liberación, entre ellos un sistema completo de KV cache, la desagregación operativa de prefill y decode y el balanceo de carga entre réplicas. Son piezas clave cuando pasas de ejecutar un modelo a atender tráfico real, con requisitos de disponibilidad, escalado y mantenimiento.
Liberar un motor queda lejos de liberar una plataforma de inferencia entera. Puedes tener los pesos, el código y optimizaciones muy avanzadas y seguir necesitando un equipo capaz de convertir todo eso en un servicio fiable. Lo digo sin ánimo de criticar a DeepInfer: sirve para hacerse una idea de cuánto trabajo hay detrás de una API de modelos.
Más allá de DeepInfer
Lo que más me gusta de DeepInfer es que enseña una parte del servicio que normalmente queda escondida detrás de una API: cómo se reparten los expertos entre aceleradores, qué pasa cuando intentas generar varios tokens en una sola iteración, cuándo compensa evitar cálculos repetidos o separar las fases de inferencia, y por qué conseguir que una GPU espere menos puede importar tanto como usar un modelo más pequeño.
DeepSeek no ha publicado una plataforma de inferencia completa, pero sí parte de las decisiones técnicas que la hacen posible. Y eso encaja con una tendencia más amplia. En los últimos años hemos tenido modelos abiertos extraordinariamente capaces, y ahora empiezan a compartirse también las herramientas para ejecutarlos y construir aplicaciones encima.
DeepSeek contribuye a varias de esas capas con sus modelos, con DeepInfer y con proyectos como DeepSeek Harness, que analizamos en nuestro microsite interactivo . Son piezas independientes y no hace falta usarlas juntas, pero muestran que el modelo, la infraestructura de ejecución y el software que lo convierte en agente pueden evolucionar cada uno por su lado.
En Helmcode trabajamos justo en la capa de infraestructura: ejecutamos modelos abiertos en Europa y los ofrecemos mediante una API, para que las empresas los usen sin gestionar GPUs ni mantener sus propios sistemas de inferencia. Eso no quiere decir que usemos DeepInfer internamente. Nos interesa porque proyectos así amplían el conocimiento y las herramientas de todo el ecosistema.
Durante años, la conversación sobre modelos abiertos ha girado en torno a quién sacaba mejor nota en un benchmark. Cada vez tiene más sentido mirar también cómo se consigue ese resultado, cuánto cuesta ejecutarlo y qué infraestructura necesita. Una parte de las próximas mejoras de los modelos abiertos vendrá de ahí, de ejecutar mejor los modelos que ya existen, y DeepInfer es uno de los primeros sitios donde se puede leer cómo se hace.
