El 80-90% del costo de IA va a inferencia, según datos de la industria. Y la mayoría de los equipos está pagando 50-90% más de lo que necesitaría, según benchmarks de FinOps. No por falta de herramientas, por falta de orden. Existen cinco palancas medibles para recortar ese desperdicio. El orden en que las aplicas importa más que cualquiera de ellas individualmente. Esta es la guía que usamos en Tech86.
Palanca 1: Prompt/KV Caching, hasta 90% de reducción, cero riesgo
Cada request de un LLM carga un bloque repetido: system prompt, instrucciones de tool calling, contexto de RAG, ejemplos few-shot. Esos tokens se procesan desde cero en cada llamada. El prompt caching elimina esa redundancia.
Los números son inequívocos. En Anthropic Sonnet 4.6, las lecturas de cache cuestan US$ 0,30/MTok frente a US$ 3,00/MTok sin cache. 90% de reducción. El punto de equilibrio para cache de 1 hora: menos de 3 reuses/hora. La mayoría de los workloads supera trivialmente ese umbral, un chatbot corporativo con system prompt de 2K tokens y contexto RAG de 5K tokens reprocesa 7K tokens idénticos en cada interacción.
Esfuerzo: bajo. Es un flag en la API call o una configuración de endpoint. Cero impacto en calidad, el output es idéntico al sin cache. Es el primero por una razón obvia: elimina costo sin tocar la arquitectura.
Palanca 2: Semantic Caching, 61-69% menos llamadas a la API
El prompt caching resuelve el exact match. El semantic caching resuelve la equivalencia semántica. "¿Cuál es el precio del plan Pro?" y "¿Cuánto cuesta el plan Pro?" generan llamadas distintas a la API, pero piden la misma respuesta. El semantic cache lo entiende.
La investigación lo confirma: 61-69% de reducción en llamadas a la API, según estudios de caso, con 97%+ de precisión preservada. El mecanismo es un embedding pipeline que convierte cada query en vector, lo compara con el cache existente por similitud coseno, y devuelve la respuesta cacheada cuando el score supera el threshold.
El esfuerzo es medio porque requiere infraestructura: embedding model, vector store, pipeline de ingesta y, principalmente, threshold tuning. El threshold define el trade-off entre ahorro y precisión. Demasiado agresivo devuelve respuestas erradas. Demasiado conservador no cachea lo suficiente. Cada dominio necesita su propia calibración.
Palanca 3: Async Batching, 50% de descuento garantizado
No toda llamada de LLM necesita respuesta en tiempo real. Clasificación de tickets, enriquecimiento de datos, generación de embeddings, análisis de sentimiento en batch, estos workloads toleran latencia de horas. La OpenAI Batch API ofrece 50% de descuento con ventana de 24 horas. No es una promesa, es un precio publicado.
La implementación es mínima: empaqueta los requests en JSONL, súbelos vía API, recibe resultados en hasta 24h. Para workloads que ya corren en pipelines asincrónicos, la migración es trivial. El ahorro es incondicional, no depende del volumen, ni de la distribución de prompts, ni del benchmark.
Esfuerzo: bajo. Cero impacto en calidad, el modelo es el mismo, el output es el mismo, solo cambia el timing. La única restricción es que no sirve para nada interactivo. Si el usuario está esperando una respuesta, no es batch.
Palanca 4: Model Routing/Cascade, 30%+ de ahorro + 5%+ de precisión
Un único modelo para todo es desperdicio. Queries simples, "¿cuál es el horario de atención?", "resume este texto", "extrae entidades", no necesitan un modelo de punta. El model routing dirige cada query al modelo más adecuado según su complejidad.
Los routers inteligentes predicen el mejor modelo por query. Datos de vendors: 30%+ de ahorro de costo y 5%+ de ganancia de precisión frente a un modelo único. La ganancia de precisión, contra-intuitiva, viene de que los modelos pequeños frecuentemente superan a los grandes en tareas simples, menos alucinación, menos reasoning innecesario, respuestas más directas.
El esfuerzo es medio porque requiere benchmark contra tu distribución real de prompts. No basta confiar en benchmarks públicos, necesitas correr tu tráfico real contra múltiples modelos, medir costo y calidad por rango de complejidad, y calibrar el router. Sin ese benchmark, el routing es puro criterio personal.
Palanca 5: Cuantización FP8, prácticamente sin pérdida, solo hosting local
FP8 es el punto seguro de la cuantización. Estudio con 500 mil+ evaluaciones en la familia Llama-3.1: cero degradación de precisión. INT8 añade 1-3% de pérdida. INT4 es variable y depende del modelo y de la tarea. FP8 reduce el consumo de memoria y aumenta el throughput, es performance gratuita en el hardware que lo soporta.
Pero esta palanca solo existe para inferencia alojada localmente. Para APIs administradas (OpenAI, Anthropic, Google), no controlas la cuantización. La decide el provider. Si tu inferencia corre en GPUs propias u on-prem, FP8 es el primer paso de optimización de hardware. Si corre en API, salta esta palanca.
Esfuerzo: alto. Requiere infraestructura de serving (vLLM, TensorRT-LLM), validación de compatibilidad de hardware y tests de regresión. El ROI aparece en escala, para pocas GPUs, el esfuerzo de implementación puede no compensar.
La métrica que alinea ingeniería con resultados
El costo por token es una métrica de entrada. El costo por resultado exitoso es la métrica que alinea ingeniería con resultados. Optimizar el costo por token a costa de tasas de retry, tasas de alucinación o tasas de conclusión de tareas recorta la factura de tokens mientras aumenta el costo real por resultado.
Un modelo que cuesta 50% menos por token pero genera 3x más retries no está más barato, está más caro por resultado útil. Un cache agresivo que devuelve respuestas erradas en 10% de los casos no está ahorrando, está transfiriendo costo de la API al soporte. Mide ambos: costo por token y costo por resultado exitoso. La diferencia entre los dos es tu desperdicio real.
El orden no es estilístico
Empezar por la palanca 3 significa optimizar un modelo cuyo costo no puedes cuantificar, porque no aplicaste cache a los prompts repetidos. Empezar por la palanca 5 significa cuantizar antes de eliminar llamadas innecesarias. Es como cambiar el motor del auto antes de cerrar la ventanilla: el esfuerzo es real, el ahorro es marginal.
El camino: cache primero (riesgo cero, ahorro máximo) → batch (50% garantizado) → route (benchmark) → quantize (solo hosting local). Cada palanca reduce el volumen que la siguiente necesita procesar. El caching reduce tokens. El batch reduce el costo de los que quedan. El routing dirige lo que resta al modelo correcto. La cuantización optimiza lo que efectivamente corre en hardware propio.
En Tech86, diseñamos arquitecturas de inferencia con FinOps integrado, desde la elección del modelo hasta el pipeline de caching y routing. Si tu factura de IA escala más rápido que tu revenue, estas palancas existían desde el día 1. Bastaba aplicarlas en el orden correcto.