NVIDIA lleva NVFP4 a DeepSeek V4.1-Flash: costo por GPU

NVIDIA publicó el 30 de octubre de 2026 una variante NVFP4 de DeepSeek-V4.1-Flash-1017, un MoE con 552 mil millones de parámetros en el backbone y contexto de hasta 1 millón de tokens. La tarjeta compara checkpoints de aproximadamente 400 y 475 GiB. En GPQA Diamond, el cálculo editorial apunta +0,16 puntos porcentuales. Menos almacenamiento no garantiza ahorro en GPU.

El checkpoint es el conjunto de datos que registra los pesos y otros componentes del modelo. La diferencia entre los tamaños equivale a aproximadamente 16% del checkpoint de origen. La tarjeta publica los dos totales y no descompone esa diferencia ni la atribuye a la conversión de los expertos. La capacidad liberada solo tiene valor operativo cuando hay carga compatible y espacio dentro del límite de latencia. En GPQA Diamond, la tarjeta informa 92,77% para el origen y 92,93% para la variante; la diferencia es un cálculo editorial, sin conclusión de significancia estadística.

Antes de alterar una ruta de producción, la operación necesita medir la calidad de las respuestas y el costo de mantener el motor compatible.

¿Qué publicó NVIDIA sobre NVFP4 el 30 de octubre?

NVIDIA publicó una versión cuantizada de DeepSeek-V4.1-Flash-1017 que usa NVFP4, un formato numérico de baja precisión, en los expertos enrutados, y la preparó con el Model Optimizer de NVIDIA. La conversión no fue uniforme: la tarjeta describe rutas de conversión diferentes para componentes diferentes.

La tarjeta usa la palabra cuantización para dos operaciones distintas. Las tablas Engram perdieron ancho en bits, de FP8 a MXFP4. Los expertos cambiaron un formato de 4 bits por otro de 4 bits con escala más fina, de MXFP4 a NVFP4. Solo la primera quita bits.

En la mezcla de expertos, o MoE, la ejecución selecciona expertos, pero los demás pesos siguen en el checkpoint. Según la tarjeta, los 384 expertos enrutados por capa en las 40 capas pasaron de MXFP4 a NVFP4, con pesos y activaciones W4A4 y grupos de cuantización de 16 valores.

Las tablas Engram pasaron de FP8 a MXFP4; otros componentes mantuvieron la precisión de origen. Según la tarjeta, los pesos de los expertos preservaron valores desquantizados, con canonicalización del cero con signo. La conversión Engram tuvo pérdida; la preservación de los pesos no garantiza respuestas idénticas.

La autoría también tiene fronteras claras. La tarjeta del modelo de origen es de DeepSeek AI, y NVIDIA afirma que no desarrolló ni posee el modelo. NVIDIA publicó la variante cuantizada, construida para requisitos de un tercero, y declara licencia MIT y uso comercial y no comercial.

¿Cuánto espacio ocupa el checkpoint y por qué eso afecta el costo por GPU?

Consultada el 2 de noviembre de 2026, la tarjeta de NVIDIA compara cerca de 400 GiB en el checkpoint cuantizado con 475 GiB en el origen. La diferencia de aproximadamente 75 GiB equivale a cerca de 16% del tamaño de origen y puede reducir gastos si el despliegue usa menos hardware pagado. El tamaño en disco no prueba ahorro.

La tarjeta publica los dos totales y no publica la descomposición de los 75 GiB. La cuenta que hicimos muestra por qué la conversión de los expertos no puede explicar esa diferencia: MXFP4 y NVFP4 son formatos de 4 bits con el mismo elemento E2M1, y el NVFP4 usa escala FP8 E4M3 cada 16 elementos, contra escala E8M0 cada 32 en el MXFP4. Esa escala más frecuente cuesta 4,5 bits por elemento en el NVFP4 contra 4,25 en el MXFP4, o cerca de 6% más por elemento (4,5 dividido por 4,25), y no menos. Aplicada a los 552 mil millones de parámetros del backbone, la misma cuenta da cerca de 293 GB en MXFP4 contra cerca de 310 GB en NVFP4, es decir aproximadamente 17 GB más en los expertos, y nunca 75 GiB menos. Esos volúmenes están en GB decimales; los tamaños de checkpoint publicados en la tarjeta están en GiB.

La única conversión que quita bits es la de las tablas Engram, de FP8 a MXFP4, y es también la que la tarjeta declara con pérdida. Esa es la explicación plausible para la reducción publicada.

El total de parámetros explica el tamaño del archivo. La tarjeta declara 552 mil millones de parámetros en el backbone, 8 mil millones activados en el prefill, 16 mil millones en el decode y 196 mil millones en memoria condicional Engram. El tráfico de pesos por token sigue los expertos enrutados activados; la memoria residente sigue el total más la caché. Por eso 552 mil millones de parámetros a 4,5 bits por elemento ocupan cerca de 289 GiB, y los 196 mil millones de la Engram en MXFP4 suman cerca de 97 GiB, valores coherentes con los aproximadamente 400 GiB publicados. En el promedio del archivo, eso da cerca de 0,78 byte por parámetro del backbone, en nuestra cuenta.

La comparación separa tamaño de checkpoint de precio por token: las tarjetas consultadas no publican costo por millón de tokens, y el tamaño no determina el hardware necesario.

La tabla reúne los formatos y tamaños declarados en las tarjetas, además de la ventana de contexto del modelo de origen; no informa consumo en ejecución ni precio contratado.

Otra medida es la memoria de GPU en ejecución. Además de los componentes del modelo cargados en el dispositivo, el motor reserva espacio para caché, búferes y estructuras necesarias para las solicitudes; la distribución de los pesos, las copias y el desplazamiento a la CPU alteran la cuenta. Por eso, dividir el tamaño del checkpoint por la memoria nominal de una GPU no determina una configuración de producción.

Para el gasto, importa el límite de capacidad. Cuando el despliegue medido logra usar menos hardware reservado, hay una posibilidad de reducción de costo; cuando mantiene el mismo conjunto de GPUs, el espacio liberado puede servir otras cargas o aumentar la concurrencia, siempre que la configuración soporte el uso y la latencia exigida. Si no hay uso para esa capacidad, la reducción en disco no se convierte necesariamente en ahorro.

Incluso cuando la carga no aprovecha toda la memoria disponible, el hardware reservado compone el gasto. La comparación necesita incluir el tiempo de procesamiento y las tareas concluidas con calidad; la tarjeta no cuantifica ahorro para una operación específica.

¿Se mantuvo la precisión en los benchmarks?

Los números de la tarjeta de NVIDIA fueron reportados por el publicador en seis evaluaciones y no demuestran equivalencia estadística, pues faltan márgenes de error para determinar la relevancia de las diferencias. Los resultados de los checkpoints de origen y cuantizado son cercanos, pero no se presentaron como medición independiente.

Fuente: tarjeta del modelo de NVIDIA, consultada el 2 de noviembre de 2026. Los resultados suben o bajan. Las pruebas cubren ciencia, contexto largo, código, instrucciones, visión y tareas de terminal, sin sustituir la validación de la aplicación.

La metodología varía. La tarjeta informa cantidades distintas de repeticiones y configuración separada para el Terminal-Bench 2.1; no hay soporte para atribuir la misma variabilidad a las pruebas.

La tarjeta también informa que 24 de 46.080 entradas de proyección usaron escalas de activación de fallback. La conversión necesitó escala de fallback en entradas de proyección reales, y son exactamente esas entradas las que impiden tratar el resultado como copia fiel del origen.

El equipo necesita probar las dos variantes en tareas representativas. Los criterios de aceptación deben ser iguales. Correcciones humanas o nuevas llamadas alteran el costo por tarea; el publicador no mide ese efecto.

¿Cuál es el costo operacional del build corregido de vLLM?

La tarjeta indica un build de vLLM con los cambios del pull request de soporte para cargar las tablas Engram en MXFP4. La operación necesita probar el build, seguir las actualizaciones y planificar correcciones de seguridad. El publicador no cuantifica ese trabajo, y el requisito documentado no anticipa el soporte de versiones futuras.

Mantener ese build requiere trabajo. Los resultados reportados usan la imagen vllm/vllm-openai:v0.31.0 con el pull request aplicado, y el checkpoint viene en 48 shards; el pull request estaba abierto y no fusionado el 2 de noviembre de 2026. El equipo necesita obtener o construir una imagen compatible, registrar dependencias, probar actualizaciones y definir cómo recibir correcciones de seguridad; también necesita una ruta de retorno si una actualización impide la carga del checkpoint o cambia el comportamiento de la aplicación. La tarjeta no atribuye un valor financiero a esas actividades.

La referencia publicada usa cuatro GPUs NVIDIA GB300 Blackwell, vLLM con atención dispersa MLA de FlashInfer y desplazamiento de las tablas Engram a la CPU. Esa es la configuración de los resultados reportados, no una recomendación universal de capacidad. Tampoco permite atribuir todo el tamaño del checkpoint a la memoria de las GPUs.

La tarjeta declara compatibilidad de microarquitectura con NVIDIA Blackwell y no declara soporte a ninguna otra. Fuera de ella, la comparación no se aplica sin cambio de hardware; la tarjeta no describe comportamiento en otras arquitecturas, y este artículo no infiere ninguno.

SGLang, otro motor citado en la tarjeta, no fue validado con el checkpoint. Eso no prueba incompatibilidad, pero exige que el operador verifique carga, respuesta bajo carga y recuperación de fallas antes de asumir soporte.

¿Qué cambia en el enrutamiento de inferencia?

Un checkpoint menor solo cambia el costo para el comprador si el despliegue o las condiciones del servicio convierten esa reducción en una ventaja medible. Para el operador de las GPUs, la comparación incluye recursos reservados, uso efectivo y mantenimiento. Para quien contrata inferencia, depende del cobro y de las llamadas necesarias para concluir la tarea.

La restricción de hardware viene antes de la cuenta de memoria. La tarjeta declara soporte solo para NVIDIA Blackwell, así que una flota de generación anterior, como Hopper o Ada, solo aprovecha esta variante después de decidir sobre renovación de hardware, no de cambiar el checkpoint.

El traslado no es automático.

Una ruta con costo menor por llamada puede exigir más intentos o correcciones para entregar el mismo resultado. En ese caso, el costo por tarea aceptada puede subir, a pesar del tamaño menor del checkpoint. Si la calidad se mantiene y la operación aprovecha la capacidad liberada, el equipo tiene un motivo para reevaluar la distribución del tráfico, respetando los límites de latencia.

La comparación de producción exige registros para las dos variantes:

1. Medir memoria de GPU y CPU, tiempo de ejecución y utilización bajo la misma carga.
2. Evaluar respuestas con los mismos criterios y registrar fallas, repeticiones y correcciones necesarias.
3. Dividir el costo de servir o contratar las llamadas por el número de tareas aceptadas, incluyendo el mantenimiento del build cuando la operación controla el motor.

Lectura complementaria: lanzamiento de DeepSeek-V4.1-Flash-1017; DeepInfer. La comparación es el costo de recursos por tarea aceptada.

La comparación entre rutas exige costo por tarea aceptada, calidad y latencia medidos bajo la misma carga. La disponibilidad de esta variante y su precio deben confirmarse con el proveedor. No se demuestra ningún ahorro para el cliente.

Preguntas frecuentes

¿Qué es NVFP4?

NVFP4 es un formato numérico de baja precisión usado en los pesos y activaciones de los expertos enrutados de la variante publicada por NVIDIA. La conversión no abarcó todos los componentes del modelo; la tarjeta describe formatos diferentes para las tablas Engram y los demás componentes.

¿Los 400 GiB son la memoria necesaria para ejecutar el modelo?

No. Los aproximadamente 400 GiB corresponden al tamaño del checkpoint declarado en la tarjeta de NVIDIA, consultada el 2 de noviembre de 2026. La memoria en ejecución incluye otras reservas, como caché y búferes, y depende de la distribución de los componentes entre GPU y CPU.

¿La reducción de 16% garantiza ahorro en la misma proporción?

No. El cerca de 16% deriva de los tamaños aproximados de 400 GiB contra 475 GiB para los checkpoints, no de una medición de costo. Hardware reservado, utilización, cobro, calidad de las tareas y mantenimiento del build influyen en el resultado financiero en producción.

¿La variante funciona con cualquier instalación de vLLM?

La tarjeta dice que las imágenes estándar de vLLM no cargan las tablas Engram en MXFP4 de ese checkpoint e indica un build con soporte específico. El equipo debe validar la instalación elegida; esa declaración no permite anticipar el soporte de versiones futuras.

¿Cómo confirmar la disponibilidad y el precio de la variante?

La disponibilidad y el precio de esta variante deben confirmarse con el proveedor. Antes de incluirla en una política de enrutamiento, el comprador necesita verificar si existe una ruta disponible, cuáles son las condiciones comerciales correspondientes y el costo por tarea aceptada.

Referencias y lectura complementaria

El repositorio del NVIDIA Model Optimizer documenta la herramienta usada en la cuantización. Las tarjetas vinculadas al inicio del artículo describen, respectivamente, la variante publicada por NVIDIA y el modelo de origen de DeepSeek AI; la consulta para este artículo ocurrió el 2 de noviembre de 2026.

Las tarjetas no sustituyen pruebas propias. La configuración y el requisito de build deben evaluarse bajo la carga y los criterios de aceptación de la aplicación.

¿Dónde se cruza el ahorro en GPU con el costo de CPU?

En la configuración de referencia descrita en la tarjeta de NVIDIA, las tablas Engram se desplazan a la CPU. La factura no termina en la GPU. Así, para quien paga por la capacidad de GPU, una reducción en ese gasto puede ser compensada por el costo de la capacidad de CPU necesaria para la inferencia, según la contratación y la carga.

Si la reducción de 16% viene de la conversión Engram, se realiza en memoria de host y en disco. La tarjeta demuestra un checkpoint menor; no demuestra una cuenta de HBM menor. Y la cuenta que sobra empieza en la arquitectura: según la tarjeta, sin Blackwell ese checkpoint no entra.