8 Min. de lectura
Los costos de entrenamiento de un modelo se incurren una sola vez, los costos de inferencia cada día. Aquí es donde la cuenta está cambiando actualmente: Con los núcleos tensor FP4 nativos de NVIDIA Blackwell y una capa de servicio como vLLM que aprovecha estos formatos, se pueden reducir significativamente las horas de GPU y la latencia, sin volver a entrenar el modelo. Quien ejecuta cargas de trabajo de IA ya no decide solo sobre la elección del modelo, sino también sobre el formato numérico en el que se realiza el cálculo.
Lo más importante en resumen
- La cuantización es la palanca de costos: Al pasar de FP16 a FP8 o FP4, se reduce a la mitad o a un cuarto el requisito de memoria por parámetro y se alivia el ancho de banda de memoria, el verdadero cuello de botella de la inferencia.
- El hardware y el software deben ser compatibles: Blackwell aporta núcleos tensor FP4 nativos, pero solo una capa de servicio con los núcleos adecuados hace que la ventaja sea utilizable. Sin una pila alineada, el formato permanece sin usar.
- La ganancia es medible, el riesgo controllable: Se ha documentado un aumento de hasta cuatro veces el rendimiento a latencia comparable, y la pérdida de calidad se puede limitar mediante cuantización selectiva y suites de evaluación.
Relacionado:FinOps lo ve todo, pero no puede hacer nada / Madurez cloud-native: Knative y Kubernetes 1.34
¿Por qué la cuenta de inferencia se convierte en un tema de arquitectura?
Un modelo de lenguaje utilizado productivamente consume sus horas de GPU no durante el entrenamiento único, sino en cada solicitud individual. Cuando un servicio se escala de cien a cien mil llamadas al día, la inferencia se convierte en la partida más grande de la factura en la nube, y crece linealmente con el uso. Esto la convierte en un tema de arquitectura y no en una cuestión que pueda resolverse simplemente con un mayor descuento por reserva.
El cuello de botella rara vez se encuentra en el rendimiento computacional puro. En la generación de tokens, suele ser el ancho de banda de memoria el factor limitante: el modelo debe volver a leer sus pesos desde la memoria de la GPU para cada token generado. Cuanto más compactos estén almacenados los pesos, menos ancho de banda consume cada paso. Es precisamente aquí donde entra en juego la cuantización.
¿Qué es la cuantización? La cuantización reduce la precisión numérica con la que se almacenan y calculan los pesos y las activaciones del modelo, por ejemplo de 16 bits (FP16) a 8 bits (FP8) o 4 bits (FP4). Esto disminuye el requisito de memoria y la carga de ancho de banda, y acelera las multiplicaciones de matrices, idealmente sin una pérdida de calidad perceptible.
FP8 y FP4: Qué cambian los formatos numéricos en Blackwell
Las GPUs Hopper de la generación anterior manejan FP8 de forma nativa. Blackwell da un paso más y lleva los Tensor Cores FP4 directamente al hardware, junto con un mayor ancho de banda de memoria. Así, se vuelve práctico un formato que comprime los pesos a un cuarto del tamaño de FP16. Según NVIDIA, el GB200 alcanza un rendimiento significativamente mayor en operaciones FP4 y FP8 que el H200 más antiguo.
| Formato | Memoria por parámetro | Hardware nativa | Clasificación |
|---|---|---|---|
| FP16 | 2 Byte | Todas las GPUs comunes | Referencia, máxima fidelidad, mayor ancho de banda |
| FP8 | 1 Byte | Hopper, Blackwell | Estándar robusto con bajo riesgo de calidad |
| FP4 | 0,5 Byte | Blackwell | Máximo ahorro, requiere calibración cuidadosa |
Valores de memoria redondeados, comportamiento de calidad dependiente del modelo.
Lo decisivo es que el formato por sí solo no aporta nada. Primero, la capa de servicio debe incluir kernels que aprovechen FP4 y FP8 en el hardware. vLLM ha integrado para ello la biblioteca FlashInfer y utiliza, entre otras cosas, atención FP8 y rápidas multiplicaciones de matrices FP8 y FP4, además de kernels GEMM adaptados al GB200. El resultado es un rendimiento cercano al límite teórico de FP4 manteniendo la calidad del modelo.
Estos saltos no son un efecto puntual. Solo una ronda de optimización de kernels dirigida aportó recientemente un 38 % más de rendimiento en el máximo y un 13 % menos de latencia en el mínimo, distribuido a lo largo de toda la curva de Pareto. Quien mantenga la pila actualizada obtiene estas mejoras sin necesidad de trabajo de desarrollo propio.
Qué deben aclarar los equipos antes del cambio
El cambio a menor precisión no es un interruptor que se pueda activar sin pensarlo. FP4 puede reducir la calidad de la respuesta en capas sensibles o ciertas tareas. Por eso la práctica separa: la atención y las capas sensibles suelen permanecer en FP8, mientras que la mayor parte de los pesos se mueve a FP4. Sin una suite de evaluación propia que mida las consultas reales frente a la versión cuantizada, la pérdida de calidad sigue siendo un punto ciego.
Qué falla
- Cuantizar a ciegas todas las capas reduce la calidad de la respuesta
- Sin una suite de evaluación, la pérdida pasa desapercibida hasta la queja
- Las ventajas de FP4 se pierden en hardware sin núcleos tensor nativos
Qué aporta
- Cuantización selectiva: capas sensibles en FP8, el resto en FP4
- Mantener actualizada la capa de servicio y llevar consigo las mejoras del kernel
- Costo por token en lugar de la utilización de la GPU como métrica de control
Económicamente, el esfuerzo vale la pena donde hay volumen. En un servicio con carga constantemente alta, el precio por token decide el margen, no la utilización nominal de la GPU. Esta métrica pertenece al monitoreo, junto con la latencia y la calidad de acierto. Quien no la mide, optimiza a ciegas.
Para la arquitectura, esto significa que la elección del modelo, el formato numérico y el stack de servicio son una decisión conjunta, no tres decisiones separadas. La inferencia más económica no surge del modelo más pequeño por sí solo, sino del modelo adecuado en el formato correcto en hardware afinado.
Preguntas frecuentes
¿Pierde un modelo calidad notable al usar FP4?
Puede ser, pero no tiene por qué. Cuantificar de forma indiscriminada todas las capas reduce la fidelidad de forma medible. Con un enfoque selectivo que deja las capas sensibles en FP8, la pérdida suele ser pequeña. Solo se puede evaluar de forma fiable con un propio conjunto de evaluación en consultas reales.
¿Necesito obligatoriamente hardware Blackwell?
Para FP8 no, también lo dominan nativamente las GPUs Hopper. El beneficio completo de FP4 con núcleos Tensor nativos solo lo ofrece Blackwell. En hardware más antiguo, FP8 sigue siendo el compromiso sensato entre ahorro y calidad.
¿Qué aporta la capa de servicio si el hardware soporta el formato?
El hardware proporciona las unidades de cómputo, pero solo los kernels adecuados las invocan. vLLM utiliza a través de la biblioteca FlashInfer kernels FP8 y FP4 adaptados a cada GPU. Sin esta capa, la ventaja del hardware queda desaprovechada.
¿Cuán grande es la ganancia real de rendimiento?
Se documenta un aumento de hasta cuatro veces el rendimiento en Blackwell frente a Hopper con latencia comparable para modelos habituales. Además, las optimizaciones continuas de los kernels aportan mejoras porcentuales de dos dígitos que se incorporan con cada actualización.
¿Qué métrica regula mejor los costos de inferencia?
El precio por token generado. Une la hora de GPU, el formato y el tamaño del modelo en una magnitud que incide directamente en el margen de un servicio. El uso aislado de la GPU oscurece si una llamada fue barata o cara.
Más del MBF Media Netzwerk
Fuente de la imagen titular: generada por IA (junio de 2026), certificado C2PA incorporado en la imagen
