Primero la conclusión: en el 80% de los casos, el aumento descontrolado de los costes de la API de grandes modelos no se debe a un ataque, sino a unos cuantos hábitos de invocación poco visibles en el código que están quemando dinero a escondidas. En un proyecto de atención al cliente inteligente, la factura mensual pasó de 8000 a 30000, y la primera reacción del jefe fue "nos han hecho fraude". Estuve acompañándolos dos días en la investigación y descubrí que el volumen de solicitudes no había cambiado en absoluto; lo que había cambiado era la cantidad de Tokens que arrastraba cada turno de conversación. A continuación explico uno por uno estos cuatro hoyos, y para cada uno doy una solución directamente aplicable.
1. El historial de conversación se reenvía completo en cada turno, y los Tokens de entrada se inflan de forma lineal
Este es el más oculto. Muchos equipos, al escribir diálogos multiturno, tienen la costumbre de meter el historial completo de mensajes en el array messages de cada solicitud. En el turno 1 envían 100 Tokens, en el turno 10 ya envían 1000 Tokens, y en el turno 30 quizá tres o cuatro mil. Cuanto más tiempo conversa el usuario, más cara sale cada invocación, y además la mayor parte de ese historial son muletillas del tipo "vale", "recibido".
La acción de optimización es recortar la ventana de conversación más compresión mediante resumen. Se conservan los últimos N turnos textuales, y los anteriores se comprimen en un párrafo de resumen con una invocación a un modelo barato, para luego insertar ese resumen en el system prompt. En nuestro proyecto, medido en real, al cambiar la ventana de completa a "últimos 6 turnos + resumen", los Tokens de entrada bajaron entre un 60% y un 70%, y la calidad de respuesta en el escenario de atención al cliente prácticamente no cambió. Además, recuerda deduplicar los mensajes del historial y descartar directamente los saludos repetidos.
2. Usar el modelo insignia para trabajo pesado, y también poner lo más potente en la clasificación de intenciones
Otra gran partida de la factura es usar GPT-4o o Claude 4 Sonnet para ejecutar tareas como clasificación de intenciones, juicio de sentimiento o extracción de palabras clave. Estas tareas son de lógica simple y salida corta, así que usar el modelo insignia es matar moscas a cañonazos. En aquel momento hicimos las cuentas: detrás de una solicitud de atención al cliente había de media 3 invocaciones de clasificación, todas ejecutándose en el modelo insignia.
La solución es el enrutamiento por capas de modelos. El trabajo pesado se delega a modelos baratos como DeepSeek-V3, la versión ligera de Qwen o la API de grandes modelos de Doubao, y solo el paso final de generación de la respuesta pasa por el modelo insignia. Esto es precisamente lo que debe hacer una puerta de enlace de modelos: elegir automáticamente el modelo según el tipo de tarea. En nuestro proyecto comparamos la compra directa oficial con plataformas de agregación de API de IA; SiCore (token8341) factura por uso, y con compra por volumen más reducción de costes por energía verde la misma combinación de invocaciones sale más económica. Con una sola Key se puede invocar GPT-4o, Claude, DeepSeek, Qwen, Doubao y otros modelos principales, ahorrándose la molestia de integrar cinco SDK. La palabra clave aquí es la estructura de costes de la API de grandes modelos: si sale caro o no depende de a quién le haces hacer qué trabajo.
3. Reintentos por timeout en respuestas en streaming, sin control de idempotencia
Este hoyo no se refleja directamente en la cantidad de Tokens, sino en el número de invocaciones. Si la interfaz en streaming se corta por timeout del cliente, mucho código reintenta sin pensar, pero el servidor en realidad ya ha generado parte del contenido, y los Tokens se descuentan igual. Reintentar tres veces son tres veces el coste, y puede que el usuario solo vea una respuesta. Peor aún: si al sondeo del frontend le sumas los reintentos del backend, una misma solicitud puede dispararse cinco o seis veces.
Hay dos acciones aplicables. Primero, incluir una Key de idempotencia en cada solicitud, para que el servidor, al detectar una solicitud duplicada, devuelva directamente el resultado en caché sin volver a inferir. Segundo, cambiar la política de reintentos de "reintentar 3 veces fijas" a "retroceso exponencial + máximo 1 reintento", y solo reintentar cuando falla el establecimiento de la conexión; si ya se ha recibido el primer Token, nunca reenviar. Sumando estas dos cosas, el volumen de invocaciones anómalas de aquel proyecto cayó casi a la mitad.
4. Test y producción comparten Key, y los costes mezclados no se pueden aclarar
Lo más doloroso de cabeza al investigar fue en realidad esto. El entorno de test ejecuta pruebas de carga y regresión usando la misma API Key que producción, y en la factura es imposible distinguir qué partida la generaron usuarios reales. Para cuando se detecta la anomalía ya han pasado varias semanas, y los logs tampoco cuadran.
La solución es muy directa: separar las API Keys por entorno y por línea de negocio, y revisar el uso de cada Key por separado. Las plataformas de agregación de API de IA normalmente soportan gestión multi-Key y paneles de uso; si la gestión de API Keys se hace con detalle, quién está quemando dinero se ve de un vistazo. De paso, pon un límite diario a la Key de test, y así se evita de raíz que un script de pruebas de carga se conecte por error a la Key de producción.
Resumen en una frase
Cuando la factura de la API de grandes modelos se descontrola, normalmente no es un problema de precio unitario, sino de postura de invocación. Recortar la ventana de conversación, degradar el trabajo pesado, controlar los reintentos y separar las Keys: hechas estas cuatro cosas, no es difícil que el coste vuelva a un rango razonable. Si quieres seguir entendiendo cómo se calculan la integración unificada de múltiples modelos y la facturación por uso, puedes buscar más información en las direcciones de "agregación de API de IA" y "enrutamiento de modelos".