Inferencia FP8: Qué significa para tu factura de la API

La inferencia FP8 puede reducir la memoria y el cómputo necesarios para servir un gran modelo de lenguaje. Eso no significa que cada modelo FP8 tenga un precio de API más bajo. Tu factura final seguirá reflejando el modelo seleccionado, la longitud de entrada, la longitud de salida, el uso de caché, los reintentos y la tasa de éxito de la tarea. Para estimar el coste real, los desarrolladores deben mirar más allá de la etiqueta de precisión.

¿Qué es la inferencia FP8?

La inferencia FP8 utiliza formatos de punto flotante de ocho bits para determinados pesos del modelo, activaciones u operaciones durante el servicio del modelo.

A diferencia de INT8, FP8 conserva una estructura de punto flotante con un signo, un exponente y una mantisa. Esto le permite representar valores en un rango numérico más amplio que un formato estándar de entero de ocho bits.

Dos formatos comunes de FP8 son:

· E4M3: un bit de signo, cuatro bits de exponente y tres bits de mantisa

· E5M2: un bit de signo, cinco bits de exponente y dos bits de mantisa

E4M3 proporciona más precisión de mantisa dentro de un rango más pequeño. E5M2 proporciona un rango mucho más amplio pero almacena los valores con menos precisión. Los métodos de escalado ayudan a mapear los valores del modelo en el rango que cada formato puede representar.

El término “modelo FP8” no siempre describe la misma implementación. Puede referirse a:

· Pesos FP8 con activaciones de mayor precisión

· Pesos y activaciones FP8, a menudo descritos como W8A8

· Un punto de control FP16 o BF16 convertido durante el despliegue

· Un sistema de precisión mixta que mantiene las operaciones sensibles en una precisión más alta

· Diferentes formatos de FP8 o métodos de escalado entre tensores individuales

Por lo tanto, la inferencia FP8 no significa que cada cálculo se ejecute en precisión de ocho bits. La configuración real depende del punto de control del modelo, el marco de servicio, el soporte de hardware, el método de calibración y los kernels de inferencia.

FP8 vs. FP16 vs. BF16

FP8, FP16 y BF16 representan valores de punto flotante, pero dividen sus bits disponibles de manera diferente.

BF16 utiliza la misma cantidad de bits de exponente que FP32, lo que le otorga un rango dinámico más amplio que FP16. FP16 utiliza más bits de mantisa, por lo que representa los valores de manera más precisa dentro de su rango disponible. El mejor formato depende del comportamiento numérico de la carga de trabajo más que de una clasificación de precisión universal.

Un valor FP8 requiere la mitad del almacenamiento bruto de un valor FP16 o BF16. Sin embargo, un servicio de inferencia completo también necesita memoria para:

· Datos de caché KV

· Tensores temporales

· Factores de escalado

· Estado de la solicitud

· Acumulaciones de mayor precisión

· Datos de enrutamiento MoE

· Sobrecarga de framework y comunicación

FP8 puede reducir sustancialmente los requisitos de memoria de los pesos del modelo, pero la memoria total de la GPU no disminuye automáticamente exactamente en un 50 %.

Por qué la precisión puede afectar al coste de la API

La precisión puede influir en el coste de la inferencia de LLM a través del uso de memoria, el movimiento de datos, el rendimiento informático y la capacidad de servicio.

Menor demanda de memoria del modelo

Los pesos del modelo ocupan una gran parte de la memoria de la GPU. Reducir su precisión puede permitir que un modelo quepa en menos aceleradores o dejar más memoria disponible para solicitudes activas.

Esa capacidad adicional puede admitir:

· Lotes más grandes

· Más solicitudes concurrentes

· Contextos más largos

· Una caché KV más grande

· Menos particionamiento del modelo en las GPU

Estas mejoras pueden aumentar el número de tokens servidos por los mismos recursos de hardware.

Menos movimiento de datos

La inferencia de LLM mueve repetidamente pesos y otros tensores entre la memoria de la GPU y las unidades de cómputo. Los tensores más pequeños reducen la cantidad de datos transferidos durante las operaciones admitidas.

Esto es particularmente relevante durante la generación de tokens, donde el ancho de banda de la memoria puede convertirse en un factor limitante. Reducir la cantidad de bytes movidos por operación puede mejorar el rendimiento incluso cuando la arquitectura del modelo subyacente no cambia.

Mayor rendimiento informático

Los aceleradores modernos pueden ejecutar operaciones de matriz FP8 mediante soporte de hardware dedicado. Cuando el modelo, la GPU, los kernels y el framework de inferencia utilizan una configuración FP8 compatible, el sistema puede procesar más operaciones en el mismo período.

Para las configuraciones W8A8 compatibles, vLLM documenta una reducción de dos veces en los requisitos de memoria del modelo y una mejora del rendimiento de hasta 1,6 veces. Estas cifras describen condiciones específicas de hardware y software, no un resultado garantizado para cada modelo o carga de trabajo.

Los tensores de menor precisión por sí solos no son suficientes. El procesamiento por lotes, la gestión de la memoria, el diseño del kernel, la programación de solicitudes y la comunicación multi-GPU determinan si la eficiencia teórica de FP8 se convierte en un rendimiento de producción medible.

SiliconFlow combina un motor de inferencia de desarrollo propio con una optimización de extremo a extremo en una infraestructura de GPU de alto rendimiento. Los desarrolladores pueden acceder a estos despliegues optimizados a través de Serverless API o elegir opciones dedicadas y personalizadas para cargas de trabajo que requieren un mayor control de la capacidad. La API unificada y compatible con OpenAI también reduce el trabajo de integración necesario para probar modelos bajo la misma lógica de aplicación.

¿Hace FP8 que una API de LLM sea siempre más barata?

No. FP8 puede reducir parte del coste de infraestructura de servir un modelo, pero el precio de la API pública refleja mucho más que la precisión numérica.

Otros factores de precio incluyen:

· Arquitectura y tamaño del modelo

· Parámetros activados por token

· Requisitos de contexto y caché KV

· Velocidad media de salida

· Utilización de la GPU

· Comunicación entre dispositivos

· Requisitos de capacidad y fiabilidad

· Demanda del modelo

· Estrategia de precios de la plataforma

En SiliconFlow, las páginas de modelos Serverless presentan tarifas de entrada y salida por millón de tokens. Algunos modelos también tienen una tarifa de lectura de caché independiente. El desarrollador paga las tarifas publicadas para el despliegue seleccionado en lugar de recibir un descuento de FP8 por separado.

Los siguientes dos modelos muestran por qué la precisión del despliegue no puede predecir el precio final por sí sola:

Los precios se verificaron el 15 de julio de 2026 y pueden cambiar. Las páginas actuales de los modelos también muestran que Qwen3.6-27B tiene 27 mil millones de parámetros totales y activados, mientras que DeepSeek-V4-Flash activa 13 mil millones de parámetros por token.

Ambos despliegues están marcados como FP8, pero sus precios por token difieren significativamente. También tienen diferentes arquitecturas, capacidades, límites de contexto y cargas de trabajo esperadas.

Una tarifa de token más baja not siempre produce un coste menor por tarea completada. Un modelo puede resultar más costoso en la práctica cuando:

· Genera respuestas innecesariamente largas

· Requiere intentos repetidos

· Produce salidas estructuradas no válidas

· Falla en las llamadas a herramientas

· Necesita verificación adicional

· Activa un modelo alternativo

· Completa con éxito menos tareas

La pregunta útil no es simplemente si un modelo utiliza FP8. Es cuánto cuesta el flujo de trabajo completo una vez que se incluyen la calidad, la longitud de la salida, los reintentos y la fiabilidad.

Cómo se conecta FP8 con los modelos MoE

FP8 y Mixture-of-Experts abordan diferentes aspectos de la eficiencia de la inferencia.

FP8 cambia la forma en que se almacenan y procesan determinados valores. MoE cambia la forma en que se activan los parámetros del modelo para cada token.

Un modelo denso normalmente utiliza todos sus parámetros durante cada paso hacia adelante. Un modelo MoE contiene múltiples redes de expertos pero enruta cada token a un grupo más pequeño de expertos.

DeepSeek-V3 proporciona un ejemplo claro. Contiene 671 mil millones de parámetros totales pero activa aproximadamente 37 mil millones para cada token.

Esto crea dos capas de eficiencia independientes:

1. MoE reduce la cantidad de parámetros involucrados en el cómputo de cada token.

2. FP8 reduce el almacenamiento y el cómputo admitido requeridos para muchos de esos tensores.

DeepSeek-V4-Flash ilustra aún más la relación. La tarjeta oficial del modelo lo identifica como un modelo MoE con 284 mil millones de parámetros totales y 13 mil millones de parámetros activados. Su punto de control Instruct lanzado combina parámetros de expertos FP4 con FP8 para la mayoría de los demás parámetros, mientras que el despliegue actual de SiliconFlow está marcado como FP8 en la página del modelo.

Un modelo MoE no es equivalente a un modelo denso con el mismo número de parámetros activados. El sistema de servicio aún debe gestionar:

El conjunto completo de pesos de expertos

· Enrutamiento de expertos

· Equilibrio de carga

· Paralelismo de expertos

· Comunicación entre GPUs

· Demanda desigual de expertos en un lote

MoE reduce el cómputo activo, mientras que FP8 puede reducir los requisitos de memoria y cómputo. El resultado final depende de qué tan bien operen juntos la arquitectura, el hardware y el sistema de servicio.

Qué deben comprobar los desarrolladores antes de elegir un modelo

La precisión es solo una parte de la evaluación de un modelo de producción. Los desarrolladores deben comparar los modelos utilizando indicaciones, parámetros, conjuntos de datos y criterios de éxito consistentes.

Cada página de modelo de SiliconFlow proporciona información sobre el despliegue, como la arquitectura, la precisión, la longitud del contexto, los precios y las funcionalidades admitidas. Los desarrolladores pueden utilizar estos campos para crear una lista inicial de candidatos antes de realizar pruebas específicas de la aplicación.

La plataforma ofrece actualmente acceso a más de 200 modelos de lenguaje y multimodales optimizados a través de una API unificada. Esto hace que sea práctico probar varios candidatos sin tener que reconstruir toda la integración para cada modelo. El acceso Serverless admite la experimentación basada en el uso, mientras que las opciones de despliegue dedicadas y personalizadas se adaptan a cargas de trabajo que necesitan un control de capacidad o infraestructura más predecible.

Una prueba de rendimiento útil debe medir algo más que la precisión. Registra:

· Tokens de entrada promedio

· Tokens de salida promedio

· Tasa de éxito de la tarea

· Tasa de reintentos

· Éxito de las llamadas a herramientas

· Latencia de respuesta

· Coste por solicitud

· Coste por tarea exitosa

Este enfoque muestra si un modelo de menor precio realmente reduce el coste de ejecución de la aplicación.

Cómo estimar su factura real de la API

Comience con las tarifas actuales para el modelo seleccionado.

Para un modelo con precios de entrada y salida independientes:

Coste de entrada = tokens de entrada ÷ 1.000.000 × tarifa de entrada

Coste de salida = tokens de salida ÷ 1.000.000 × tarifa de salida

Coste total del token = coste de entrada + coste de salida

Para un modelo con una tarifa de lectura de caché independiente:

Coste total de tokens = coste de entrada no almacenado en caché + coste de lectura de caché facturado + coste de salida

Esto genera un coste nominal por solicitud. Una estimación de producción necesita varios pasos adicionales.

Registrar el uso real de tokens

La respuesta de SiliconFlow Chat Completions incluye prompt_tokens, completion_tokens y total_tokens. Utilice estos valores en lugar de estimar el volumen de tokens a partir de caracteres o palabras.

Trate los ahorros por caché con cautela

Una indicación repetida no califica necesariamente para la tarifa de lectura de caché más baja. Aplique esa tarifa solo a la entrada que realmente se factura como un acierto de caché.

Cuando los datos de aciertos de caché no estén disponibles, estime la entrada repetida con la tarifa de entrada estándar. Esto evita que se sobreestimen los ahorros esperados.

Incluya cada llamada facturable al modelo

Una acción del usuario puede desencadenar varias solicitudes. Los flujos de trabajo de los agentes pueden planificar, llamar a herramientas, corregir errores, verificar resultados y generar una respuesta final.

Incluya costes de:

· Reintentos facturables

· Bucles de corrección de llamadas a herramientas

· Reparaciones de salida estructurada

· Solicitudes de verificación

· Respuestas regeneradas

· Llamadas a modelos alternativos

Estas solicitudes adicionales pueden importar más que una pequeña diferencia en la tarifa de entrada indicada.

Medir el coste por tarea exitosa

La métrica de producción más útil suele ser:

Coste por tarea exitosa =

gasto total en API ÷ tareas completadas con éxito

Por ejemplo, un modelo puede tener un precio de salida más bajo pero requerir reintentos frecuentes. Otro puede costar más por token pero completar la misma tarea correctamente en el primer intento.

El segundo modelo aún puede tener el coste real más bajo.

Controlar la longitud de la salida

Los precios de salida pueden diferir sustancialmente de los precios de entrada. Un modelo que genera respuestas largas puede crear una factura más alta incluso cuando su tarifa de entrada es baja.

Utilice:

· Requisitos de respuesta claros

· Límites de salida adecuados

· Campos JSON definidos

· Condiciones de parada explícitas

· Conteos controlados de iteración de agentes

· Contexto de recuperación enfocado

Estos ajustes reducen los tokens innecesarios sin depender de cambios de precisión.

Probar una carga de trabajo representativa

Evalúe los modelos utilizando entradas de aplicaciones reales, incluidos casos cortos, largos, ambiguos y propensos a fallos.

Dado que la API es compatible con OpenAI y está unificada en todos los modelos admitidos, los desarrolladores pueden cambiar el identificador del modelo conservando gran parte de la lógica de la aplicación circundante. Esto facilita comparar el uso de tokens, la calidad, la latencia y la fiabilidad en condiciones similares.

Preguntas frecuentes sobre la inferencia FP8 y el coste de la API

P1. ¿Reduce automáticamente la inferencia FP8 los precios de las API?

No. FP8 puede mejorar la eficiencia del servicio, pero las tarifas de la API también reflejan la arquitectura del modelo, la utilización del hardware, la capacidad, el rendimiento y los precios de la plataforma.

P2. ¿Es FP8 menos preciso que BF16?

Puede serlo. FP8 representa menos valores numéricos, por lo que el escalado, la calibración, el manejo de precisión mixta y el diseño del modelo afectan la precisión. Pruebe cada despliegue con su propia carga de trabajo.

P3. ¿Pueden los desarrolladores seleccionar FP8 en cada solicitud de API?

No en el flujo de trabajo Serverless estándar. Los desarrolladores seleccionan un despliegue de modelo disponible en lugar de cambiar su precisión de servicio para cada solicitud.

P4. ¿Son los modelos FP8 MoE siempre la opción más barata?

No. MoE reduce el cómputo activo, mientras que FP8 reduce el almacenamiento y el cómputo de tensores admitidos. El enrutamiento, la comunicación, la longitud de la salida y los precios de los tokens siguen afectando la factura.

P5. ¿Cuál es la mejor métrica para comparar el coste de inferencia de LLM?

El coste por tarea exitosa es más útil que el precio del token por sí solo. Incluye la longitud de la salida, los reintentos, los bucles de herramientas, la fiabilidad y la cantidad de llamadas necesarias para completar el trabajo real.