Costes de API de IA: tokens y grupos

El control de costes de una API de IA resulta útil cuando cada cargo puede vincularse a una petición, un modelo, un grupo y una unidad de trabajo medida. El total mensual muestra que el gasto cambió; el registro por petición explica por qué.

Modelflare combina precio del modelo, uso medido, política del grupo y registros de petición para revisar el coste sin estimarlo a partir del texto que se ve en pantalla.

Las cuatro capas del coste de una petición

1. Precio del modelo

Cada modelo tiene su propia unidad de facturación. Muchos modelos de texto cobran tokens de entrada y salida; imagen, audio, reranking y otras API pueden usar unidades diferentes. Algunas funciones requieren además reglas de precio avanzadas y versionadas que no caben en una tarifa plana por token.

Consulta Modelos y precios para conocer el contrato vigente del modelo y el formato de API; no copies una tarifa dentro del código de la aplicación.

2. Uso medido

La pasarela registra el uso devuelto o calculado para la petición completada. En modelos de texto, entrada y salida se conservan por separado porque pueden tener precios distintos.

El texto que aparece durante el streaming no es una referencia fiable para facturar. Herramientas, razonamiento, entrada en caché, tokens normalizados o campos específicos del proveedor pueden contar aunque no aparezcan como texto del asistente.

3. Multiplicador del grupo

El grupo seleccionado puede aplicar un multiplicador comercial al coste base. Por ejemplo, una ratio de 0.9 aplica el 90 % del cargo base del modelo a esa petición.

El multiplicador afecta al consumo. No cambia el saldo que añade una recarga al monedero.

4. Registro final de la petición

El registro de uso vincula el importe calculado con modelo, grupo, estado, tokens, tiempos y otros metadatos operativos seguros. Las peticiones fallidas o canceladas pueden seguir rutas de liquidación diferentes; el resultado persistido es más fiable que una estimación del cliente.

Qué comparar en los registros de uso

Si el gasto cambia, compara:

• Modelo: ¿se movió el tráfico a un modelo con otro precio de entrada, salida o funciones?
• Grupo: ¿se eligió un grupo principal o de respaldo con otro multiplicador?
• Protocolo: ¿cambió entre Chat Completions y Responses y con ello la forma del uso?
• Tamaño de entrada: ¿crecieron prompts, contexto recuperado, archivos o resultados de herramientas?
• Tamaño de salida: ¿aumentaron los límites de respuesta o las iteraciones del agente?
• Estado y reintentos: ¿los fallos provocaron intentos adicionales que sí terminaron?
• Tiempos: ¿la generación más larga produjo más salida o solo hubo espera?

Filtra por un ID estable o por una clave específica de la aplicación; no compares cargas de trabajo distintas mezcladas en la misma cuenta.

Establecer límites prácticos

Separar claves por carga de trabajo

Usa claves distintas para producción, desarrollo, automatizaciones y herramientas personales. Cada una puede tener nombre, caducidad, política de grupo y una cuota finita o ilimitada.

Elegir los grupos con intención

No te quedes con la etiqueta. Comprueba disponibilidad en vivo, multiplicador, requisitos de acceso, RPM y política de respaldo. Un grupo principal más económico con un respaldo aceptable puede ser más predecible que una decisión implícita difícil de justificar.

Reducir la entrada antes de recortar la salida

Los prompts de sistema extensos, el historial repetido, los documentos recuperados y los resultados de herramientas suelen dominar el consumo de entrada. Elimina contexto que ya no afecte a la respuesta y evita reenviar datos sin cambios cuando el cliente pueda referenciarlos o almacenarlos en caché de forma segura.

Revisar los bucles de agentes

Una sola acción del usuario puede generar varias peticiones al modelo. Cuenta cada ronda de herramientas y cada reintento; la respuesta visible final no equivale necesariamente a una única llamada.

Por qué se desvían las estimaciones del cliente

Un tokenizador local o un recuento de caracteres ayuda a planificar, pero puede diferir del uso facturado porque:

• cada proveedor puede normalizar y contar el contenido de forma distinta;
• caché, razonamiento, imagen, audio y herramientas pueden tener tarifas separadas;
• la liquidación utiliza el modelo y el grupo realmente seleccionados;
• fallos y reembolsos dependen del ciclo real de la petición;
• los precios pueden cambiar mientras las peticiones antiguas conservan su resultado registrado.

Para una revisión financiera, concilia los registros persistidos de uso y monedero; no reconstruyas el saldo a partir de un único campo de la interfaz.

Proceso de revisión repetible

1. Filtra los registros por una clave y un intervalo de tiempo.
2. Agrupa por modelo y grupo seleccionado.
3. Compara entrada, salida, estado y coste de cada petición.
4. Inspecciona valores atípicos: reintentos, contexto largo, bucles de herramientas o respaldos.
5. Confirma el precio y la política vigentes antes de cambiar el enrutamiento.
6. Define una cuota finita si la carga necesita un límite duro de gasto.
7. Vuelve a medir las mismas métricas después del cambio.

El control empieza por la atribución. Mientras modelo, grupo, uso y resultado sigan conectados, el equipo podrá optimizar la causa real del gasto en lugar de adivinar a partir de totales agregados.