Cómo bajar la factura de tu API de LLM
Sergio Jimenez21 de octubre de 20266 min de lectura
La mayoría de equipos que pagan de más por llamadas a LLM no están pagando por inteligencia. Están pagando por reenviar el mismo texto miles de veces al día.
Estas son las palancas, ordenadas por lo que suelen devolver frente al esfuerzo. Las tres primeras normalmente explican todo el problema.
La respuesta corta
| Palanca | Ahorro típico | Esfuerzo |
|---|---|---|
| Caché de prompt sobre un prefijo estable | 50 a 90 por ciento en entrada | Horas |
| Enrutar turnos fáciles a un modelo pequeño | 40 a 70 por ciento del total | Días |
| Dejar de reenviar historial y documentos | 30 a 60 por ciento | Días |
| Limitar reintentos y bucles | Evita el pico, no la base | Horas |
| Acortar las salidas | 10 a 30 por ciento | Horas |
| Procesar en lote lo no interactivo | Alrededor del 50 por ciento de ese tráfico | Días |
Mide antes de tocar nada
No puedes optimizar una factura que no has desglosado. Registra, por petición: tokens de entrada, de salida, en caché, modelo, latencia y qué función hizo la llamada.
Casi todo equipo que hace esto encuentra lo mismo, y nunca es lo que suponía: una función que nadie consideraba importante hace el 70 por ciento de las llamadas, normalmente algo que corre en un temporizador o en cada carga de página. Encuentra eso antes de escribir cualquier optimización, porque la mayor victoria suele ser eliminar una llamada, no abaratarla.
Caché de prompt, la victoria grande más barata
Si tus peticiones comparten un prefijo largo y estable, un prompt de sistema, un esquema de herramientas, un conjunto de ejemplos, el caché permite que el proveedor cobre una fracción por esa parte en las llamadas siguientes.
El requisito es que el prefijo sea idéntico byte a byte y vaya primero. Lo que significa: todo lo estable arriba y todo lo variable abajo. Una marca de tiempo o un nombre de usuario inyectados arriba del prompt de sistema invalidan el caché en cada llamada, y ese error es bastante común como para revisarlo primero.
Enruta por dificultad, no por costumbre
Los equipos eligen un modelo capaz y le mandan todo. Pero la mayor parte del tráfico de un producto real no es difícil: clasificación, extracción, enrutado, reescrituras cortas, respuestas simples desde texto recuperado. Un modelo pequeño hace eso igual de bien y cuesta una fracción.
El patrón que funciona es un clasificador barato que decide la ruta, con escalada: si la respuesta del modelo pequeño falla una comprobación de validación o de confianza, se reintenta con el grande. Pagas el precio del modelo grande solo en la minoría de turnos que lo necesitan. En la práctica esto cae entre el 40 y el 70 por ciento del gasto total, y es el mayor ahorro estructural disponible.
Deja de reenviarlo todo
Tres hábitos lo provocan, y los tres son valores por defecto que nadie eligió a propósito.
Historial completo en cada turno. El turno 30 reenvía los turnos 1 al 29. Conserva los últimos turnos completos y un resumen rodante del resto. La calidad rara vez baja y la factura cae mucho.
Recuperar veinte pasajes cuando bastaban tres. Más contexto no es mejor contexto. Pasado un puñado de pasajes relevantes estás pagando tokens que además diluyen la atención del modelo, así que este es uno de los pocos cambios que es más barato y más preciso.
Documentos enteros en vez de secciones relevantes. Si pegas un PDF de 40 páginas para responder sobre una cláusula, estás pagando 39 páginas de nada.
Acota los bucles
Esto no reduce tu factura media; evita la factura que arruina un mes. Un agente reintentando una llamada que falla lo hará felizmente cientos de veces.
Fija un máximo de llamadas a herramientas por turno, un máximo de tokens totales por conversación, y una alerta sobre el gasto diario. Las tres cosas son una tarde de trabajo. Los equipos las añaden después del primer incidente, y el incidente siempre cuesta más que la tarde.
Acorta la salida
Los tokens de salida cuestan varias veces más que los de entrada en casi todos los modelos, así que la verborrea sale cara de una forma fácil de pasar por alto.
Si necesitas datos estructurados, pide datos estructurados y pon un límite de tokens. Un modelo que produce un párrafo amable explicando el JSON que está a punto de producir está quemando el tipo caro de token en algo que vas a descartar.
Procesa en lote lo que nadie está esperando
La mayoría de proveedores ofrecen un modo por lotes a aproximadamente mitad de precio para trabajo que tolera un retraso. Resúmenes nocturnos, enriquecimiento, clasificar una cola, generar embeddings: nada de eso es interactivo, y casi siempre corre por la vía de tiempo real porque así se construyó al principio.
Qué haríamos en la primera semana
- Añadir registro de tokens por petición, etiquetado por función.
- Mirar qué está haciendo las llamadas de verdad. Eliminar lo que no debería estar.
- Mover toda instrucción estable al principio del prompt y encender el caché.
- Limitar reintentos, bucles y gasto diario.
- Después, y solo después, plantear enrutado y cambios de modelo.
Los pasos uno a cuatro son días de trabajo y recortan la factura a más de la mitad de forma rutinaria. El paso cinco es donde está el ahorro estructural restante, y es mucho más fácil de justificar cuando ya puedes medir el efecto. Nuestras notas sobre guardrails y evals cubren el lado de la medición, que es lo que te deja cambiar de modelo sin adivinar el costo en calidad.
Preguntas frecuentes
¿Cómo reduzco el costo de mi API de LLM?
Por orden de retorno: enciende el caché de prompt sobre un prefijo estable, enruta los turnos fáciles a un modelo más pequeño con escalada cuando falle la validación, deja de reenviar historial completo y documentos enteros, limita reintentos y bucles, acorta las salidas, y mueve el trabajo no interactivo a modo por lotes. Las tres primeras suelen explicar casi toda la factura.
¿Por qué mi factura de OpenAI o Anthropic es tan alta?
Normalmente volumen de tokens de entrada, no dificultad del trabajo. Las causas habituales son un prompt de sistema largo reenviado sin caché en cada llamada, historial completo en cada turno, recuperar muchos más pasajes de los necesarios, y una función en segundo plano que nadie consideró haciendo la mayoría de llamadas. Registra tokens por petición y por función y la causa suele ser obvia en un día.
¿El caché de prompt funciona de verdad?
Sí, y es la victoria grande más barata disponible, normalmente entre 50 y 90 por ciento de descuento sobre la parte cacheada de la entrada. La trampa es que el prefijo debe ser idéntico byte a byte e ir primero. Inyectar una marca de tiempo o un nombre de usuario cerca del inicio del prompt de sistema invalida el caché en silencio en cada llamada.
¿Debería usar un modelo más pequeño para ahorrar?
Para la mayoría del tráfico, sí. Clasificación, extracción, enrutado, reescrituras cortas y responder desde texto recuperado no necesitan un modelo de frontera. Usa un modelo barato por defecto y escala al grande solo cuando falle una comprobación de validación o de confianza. Ese patrón recorta el gasto total entre 40 y 70 por ciento.
¿Los tokens de salida cuestan más que los de entrada?
Sí, varias veces más en casi todos los modelos. Eso hace que la verborrea sea desproporcionadamente cara. Pide salida estructurada, fija un límite máximo de tokens, e impide que el modelo narre lo que está a punto de hacer antes de hacerlo.
¿Qué es el modo por lotes y cuándo lo uso?
Un modo del proveedor que procesa peticiones a aproximadamente mitad de precio a cambio de un retraso. Úsalo para todo lo que nadie espera: resúmenes nocturnos, clasificación de colas, trabajos de enriquecimiento y generación de embeddings. Buena parte de ese trabajo corre por la vía interactiva solo porque así se escribió al principio.
Por dónde empezar
Añade registro de tokens etiquetado por función y mira los tres mayores emisores al cabo de un día. La respuesta casi siempre sorprende, y casi siempre es donde está el dinero.
Si la factura ya es un problema y quieres que la miremos directamente, mándanos la forma de tu tráfico y te decimos cuál de estas palancas aplica antes de que cambies nada.
