Apilar tres palancas (enrutado entre modelos, cache y procesamiento por lotes) reduce una factura de inferencia entre un 60 y un 80 por ciento sin ningun cambio en la experiencia de usuario. Solo la cache de prompts factura los tokens repetidos a alrededor del 10 por ciento de la tarifa base de entrada, lo que significa hasta un 90 por ciento de descuento sobre la parte fija, y ademas mejora el tiempo hasta el primer token entre un 13 y un 31 por ciento. El procesamiento por lotes quita otro 50 por ciento aproximado a todo lo que no necesita respuesta inmediata. Apiladas, la factura aterriza cerca de un cuarto del precio de lista.
Donde se quema el dinero de verdad
Antes de optimizar hay que saber que es caro. Tres hechos estructurales explican la mayor parte de la factura, y se cumplen practicamente en todos los proveedores.
Los tokens de salida cuestan entre cinco y ocho veces mas que los de entrada. En GPT-5.2, por ejemplo, la tarifa es de 1,75 dolares por millon de tokens de entrada frente a 14,00 dolares por millon de salida. La consecuencia practica es que acortar la respuesta vale mucho mas que acortar el prompt, y la mayoria de los equipos invierte justo al reves.
La distancia entre el modelo caro y el barato es un orden de magnitud, no un porcentaje. El nivel barato ronda los 0,10 dolares por millon de tokens de entrada. Cuando el modelo insignia cuesta quince veces eso, cada peticion que le mandas sin necesidad es desperdicio que ya no recuperas.
La parte fija del prompt se repite en cada peticion. Instrucciones de sistema, el esquema, los ejemplos, las reglas de negocio: normalmente miles de tokens enviados una y otra vez a precio completo. Esa es la parte que la cache elimina casi por entero.
Seis palancas, ordenadas por retorno sobre esfuerzo
| Palanca | Ahorro tipico | Esfuerzo | Riesgo de calidad |
|---|---|---|---|
| Cache de prompts | 45 a 80 por ciento sobre la parte repetida | Bajo. Reordenar el prompt | Ninguno |
| Enrutado entre modelos | 40 a 85 por ciento | Medio. Exige clasificador y set de evaluacion | Medio sin medicion |
| Procesamiento por lotes | Alrededor del 50 por ciento en trabajo no urgente | Bajo-medio. Exige una cola | Ninguno |
| Acortar salida y esquema estructurado | 20 a 40 por ciento | Bajo | Bajo |
| Cache semantica | Parte del 47 por ciento al combinarla con enrutado | Medio. Exige embeddings y umbral | Medio. Respuesta obsoleta a una situacion nueva |
| Destilacion de modelo | Hasta cerca del 90 por ciento en la tarea entrenada | Alto. Exige datos y mantenimiento | Bajo en la tarea, alto fuera de ella |
Fijate en la columna de esfuerzo. Las tres primeras filas entregan la mayor parte del ahorro en semanas, no en trimestres. La destilacion y la cuantizacion son pasos reales, pero pertenecen a una etapa posterior, cuando el volumen los justifica.
Enrutado entre modelos: el movimiento de mayor retorno
El supuesto de que cada peticion necesita el modelo mas potente es el supuesto mas caro de la arquitectura. En la practica, la mayor parte del trafico de cualquier producto es simple: clasificar, extraer campos, reescribir, preguntas que ya se han respondido mil veces. Todo eso funciona perfectamente en el nivel barato.
El enrutado por complejidad quita entre el 40 y el 85 por ciento de la factura, y combinado con una cache semantica se ha medido una reduccion del gasto del 47 por ciento incluso en sistemas que ya parecian optimizados. La forma segura de implementarlo tiene tres pasos.
Primero, construye un set de evaluacion antes de tocar el enrutado. De cien a doscientos ejemplos reales de trafico en vivo, con una respuesta correcta pactada. Sin el no hay forma de saber si el enrutado rompio algo, y te enteraras por los clientes.
Segundo, enruta solo lo facil. Empieza por una categoria clara de peticiones simples, muevela al modelo barato y compara contra el set de evaluacion. Si la diferencia es despreciable, amplia a la siguiente categoria.
Tercero, anade escalado automatico. Cuando el modelo barato devuelve confianza baja o una respuesta que falla la validacion de esquema, manda la peticion al modelo fuerte. Incluso con una tasa de escalado del 15 por ciento, el ahorro sobre el 85 por ciento restante lo cubre con holgura.
Cache: dos capas completamente distintas
La palabra cache describe aqui dos cosas que se confunden entre si y que resuelven problemas distintos.
La cache de prompts es el mecanismo del proveedor. Reconoce que el prefijo de una peticion coincide con un prefijo anterior y lo factura a alrededor del 10 por ciento de la tarifa de entrada. La condicion es que la parte fija aparezca al principio del prompt y la variable al final: el orden inverso anula la cache por completo. Casi siempre es la primera mejora que merece la pena, porque cuesta una hora y ademas mejora el tiempo hasta el primer token entre un 13 y un 31 por ciento.
La cache semantica es tu mecanismo. Una pregunta nueva se convierte en un embedding, se compara con preguntas anteriores y, si la similitud supera un umbral definido, se devuelve la respuesta guardada sin llamar al modelo. Es potente en productos con preguntas repetidas, pero es tambien el unico elemento de esta lista capaz de devolver una respuesta equivocada con plena confianza.
Lotes, acortar la salida y arquitectura
Procesamiento por lotes. Todos los grandes proveedores ofrecen alrededor de un 50 por ciento de descuento en peticiones dispuestas a esperar. Resumenes nocturnos, enriquecimiento de registros, etiquetado historico, generacion de descripciones: nada de eso necesita respuesta en un segundo. El unico obstaculo es que hace falta una cola, y la mayoria de los equipos sencillamente nunca la construyo. Son dias de trabajo que devuelven la mitad del coste de todo lo que pase por ahi.
Acortar la salida. Como la salida cuesta entre cinco y ocho veces mas, poner techo a la longitud de la respuesta es la palanca mas directa disponible. Pedir la salida en un esquema estructurado en lugar de texto libre ahorra entre un 20 y un 40 por ciento y produce respuestas mas faciles de validar. Si tu sistema genera razonamientos largos que nadie lee, los estas pagando a precio completo.
Cuantizacion y destilacion, cuando el volumen las justifica. Ejecutar un modelo con precision INT8 o INT4 recorta alrededor del 50 por ciento del coste conservando entre el 95 y el 99 por ciento de la precision. Destilar un modelo pequeno para una tarea concreta llega hasta cerca del 90 por ciento de ahorro en esa tarea. Ambas exigen infraestructura y mantenimiento continuo, asi que son correctas cuando el volumen es estable y grande, no antes.
El orden de trabajo, y lo que no hay que hacer
El orden importa porque cada palanca cambia la linea base de la siguiente. Medir, luego las tres faciles, luego el resto.
| Paso | Que haces | Cuando parar |
|---|---|---|
| 1. Medir | Desglosar la factura por tipo de peticion, modelo y volumen | Cuando conoces los dos tipos de peticion mas caros |
| 2. Cache de prompts | Reordenar: contenido fijo primero, variable al final | Cuando la tasa de acierto de cache es estable y se reporta |
| 3. Esquema y longitud de salida | Salida estructurada, techo de longitud, sin razonamiento que nadie consume | Cuando la calidad del set de evaluacion no se ha movido |
| 4. Lotes | Mover todo lo no urgente a una cola | Cuando lo que queda sincrono es de verdad interactivo |
| 5. Enrutado | Una categoria cada vez, con escalado automatico | Cuando los escalados se asientan por debajo del 20 por ciento |
| 6. Destilacion o cuantizacion | Solo para una tarea estable y de volumen alto | Cuando el ahorro mensual supera el coste de mantenimiento |
Y tres cosas que no hay que hacer. No cambies calidad por coste sin un set de evaluacion que ensene exactamente que se degrado: un ahorro que genera un contacto mas de soporte es una perdida. No optimices antes de tener volumen, porque optimizar trafico pequeno gasta tiempo caro de ingenieria para un retorno trivial. Y no escondas el ahorro: si el coste por unidad de trabajo cayo un 60 por ciento, eso cambia tu precio y cambia el ROI del piloto, y suele ser lo que convierte un piloto marginal en uno justificado.
Preguntas frecuentes
Cuanto se puede reducir el coste de inferencia?
Apilar enrutado entre modelos, cache y procesamiento por lotes recorta entre un 60 y un 80 por ciento de la factura sin degradar la experiencia de usuario. Solo la cache de prompts factura los tokens repetidos a alrededor del 10 por ciento de la tarifa de entrada, los lotes anaden cerca de un 50 por ciento de descuento en trabajo no urgente, y el enrutado quita otro 40 a 85 por ciento.
Cual es el primer paso para reducir el coste?
La medicion, seguida de la cache de prompts. Desglosa la factura por tipo de peticion, modelo y volumen: en la mayoria de las organizaciones dos tipos de peticion producen mas del 70 por ciento del coste. Despues reordena el prompt para que la parte fija vaya primero y la variable al final. Es una hora de trabajo que devuelve entre un 45 y un 80 por ciento sobre la parte repetida.
El enrutado entre modelos perjudica la calidad?
No si construyes un set de evaluacion antes de enrutar. Prepara de cien a doscientos ejemplos reales con una respuesta correcta pactada, enruta una categoria de peticiones simples cada vez y compara contra el set. Anade escalado automatico al modelo fuerte cuando la confianza sea baja o la respuesta falle la validacion de esquema.
Cuando merece la pena destilar un modelo dedicado?
Solo cuando la tarea es estable, el volumen es alto y el ahorro mensual supera el coste de mantenimiento. La destilacion llega hasta cerca del 90 por ciento de ahorro en la tarea entrenada, y la cuantizacion a INT8 o INT4 recorta alrededor del 50 por ciento conservando entre el 95 y el 99 por ciento de la precision. Ambas exigen datos, infraestructura y cuidado continuo.
Por que importan mas los tokens de salida que los de entrada?
Porque cuestan entre cinco y ocho veces mas. En GPT-5.2 la tarifa es de 1,75 dolares por millon de tokens de entrada frente a 14,00 dolares por millon de salida. Poner techo a la longitud de la respuesta y pasar a salida con esquema estructurado ahorra entre un 20 y un 40 por ciento del coste, y ademas suele facilitar la validacion.
