Análisis de Costes de 3 APIs
Calcular y comparar el coste mensual real de tres proveedores de LLM para un caso de uso de negocio.
Empresa: plataforma B2B SaaS de gestión de proyectos.
Funcionalidad: asistente de IA que genera resúmenes automáticos de reuniones.
- Volumen: 2.000 reuniones/mes
- Input por reunión: transcripción de 60 min ≈ 12.000 tokens
- Output deseado: resumen ejecutivo ≈ 800 tokens
- Distribución: 70% simples · 25% medias · 5% complejas
| Proveedor | Input $/1M tok | Output $/1M tok |
|---|---|---|
| Gemini 3.5 Flash-Lite | $0.30 | $2.50 |
| Claude Sonnet 5 | $2.00 | $10.00 |
| GPT-5.6 Sol | $5.00 | $30.00 |
El volumen de tokens se calcula igual para los tres proveedores — lo único que cambia es la tarifa que se le aplica a ese mismo volumen.
| Segmento | Reuniones | Input tokens | Output tokens |
|---|---|---|---|
| Simples (70%) | 1.400 | 16.8M | 1.12M |
| Medias (25%) | 500 | 6M | 0.4M |
| Complejas (5%) | 100 | 1.2M | 0.08M |
| Total mensual | 2.000 | 24M | 1.6M |
| Proveedor | Input | Output | Total |
|---|---|---|---|
| Gemini 3.5 Flash-Lite | $7.20 | $4.00 | $11.20 |
| Claude Sonnet 5 | $48.00 | $16.00 | $64.00 |
| GPT-5.6 Sol | $120.00 | $48.00 | $168.00 |
- Elegido
- Gemini 3.5 Flash-Lite
- Razón
- El 95% del volumen (simples + medias) es abordable por un modelo económico. Ahorro del 82.5% frente a Sonnet ($52.80/mes) y del 93.3% frente a GPT-5.6 Sol ($156.80/mes).
- Trade-off
- Se esperan desviaciones de calidad en reuniones de complejidad media y, sobre todo, en las complejas (5% del volumen).
- Mitigación
- Monitorizar el segmento complejo con datos reales de las primeras semanas antes de decidir si conviene derivar parte del volumen a un modelo superior.
- Asignar un proveedor por segmento en vez de calcular el total por proveedor. Repartir Gemini→simples, Sonnet→medias, GPT→complejas y sumar da un número que no representa contratar a ningún proveedor real — son preguntas de negocio distintas (routing vs. baseline de proveedor único).
- Confundir % de ahorro con $ ahorrados. "93.3% de ahorro (168$)" se lee como si se ahorraran $168, cuando esa cifra es el coste del proveedor caro — el ahorro real es $156.80. Al escribir una recomendación de negocio, esta ambigüedad es justo lo que un revisor señala primero.
Durante el ejercicio surgió una idea válida: repartir el volumen por complejidad (Gemini para simples+medias, Sonnet para complejas) en vez de usar un único proveedor. Queda anotada como ejercicio de seguimiento: cuantificar cuánto ahorraría — o costaría — ese routing frente al baseline de $11.20/mes calculado aquí, y si compensa la complejidad de integración añadida.
¿Por qué se calcula el coste de cada proveedor usando el volumen TOTAL de reuniones, en vez de asignar cada segmento a un proveedor distinto?
Porque el objetivo es un baseline comparable — "¿cuánto costaría este proveedor sirviendo todo el volumen?" — antes de poder justificar si vale la pena la complejidad añadida de repartir por proveedor (routing).
Al aplicar un precio "por millón de tokens", ¿cuál es el error de escala más común y cómo se detecta?
Dividir por 1.000 en vez de por 1.000.000, lo que produce un coste final mucho menor de lo esperado — un resultado sospechosamente bajo es la primera señal a revisar.
Si el proveedor A cuesta $64/mes y el B cuesta $11.20/mes, ¿cómo se calcula el % de ahorro y cómo el ahorro en dólares?
% de ahorro = (1 − 11.20/64) × 100 = 82.5%. Ahorro en $ = 64 − 11.20 = $52.80. Son dos cifras distintas — no confundirlas al comunicar una decisión.
¿Qué es "model routing" y qué compra frente a usar un único proveedor para todo el volumen?
Asignar dinámicamente cada tarea al modelo más adecuado según su complejidad (barato para lo simple, caro para lo complejo) para reducir coste sin perder demasiada calidad — a cambio de más complejidad de integración y de lógica de decisión.