Cómo Reducir el Costo de Inferencia de LLMs: 5 Técnicas de Ingeniería

La factura de inferencia de un producto en producción sigue un arco predecible: se duplica antes de que alguien se dé cuenta de que podría haberse reducido a la mitad. Cinco técnicas de ingeniería pueden reducir entre un 30% y un 70% el costo de inferencia de LLMs sin cambiar de modelo. Ninguna exige reescribir la aplicación. La mayoría de los equipos que operan LLMs en producción no aplica tres de estas cinco. Lo que separa la factura que asusta de la que cabe en el presupuesto tiene menos que ver con la tecnología y más con el orden en que las técnicas llegan a producción.

Prerrequisitos: lo que necesitas antes de empezar

El lector necesitará tres cosas antes del primer paso. La primera es acceso a las APIs de los modelos que la aplicación consume, o a una infraestructura self-hosted con GPUs disponibles. Sin visibilidad del tráfico real, cualquier optimización es una apuesta. La segunda es una herramienta de observabilidad que registre tokens de entrada y salida por request, latencia y modelo utilizado. Langfuse, OpenLIT y el dashboard de consumo del Nexforce Router cumplen esta función. La tercera es una línea base de costo medida en la moneda local de la empresa.

Para las empresas que operan en América Latina, esa línea base en moneda local es especialmente relevante. Las empresas brasileñas pagan un multiplicador de hasta el 55% sobre cada dólar de costo de inferencia debido a la cadena de IRRF, CIDE, PIS, COFINS, ISS, IOF y spread cambiario que incide sobre cada remesa internacional. Las empresas mexicanas enfrentan su propia capa de IVA digital del 16% sobre servicios transfronterizos. Sin esa cifra en moneda local, el ahorro real de cada técnica queda subestimado.

El Nexforce Router factura en reales brasileños con documento fiscal e impuestos incluidos, eliminando el multiplicador en el origen y dándole al equipo una línea base única.

La cifra en dólares es la mitad de la historia. Finanzas ve la moneda local.

Paso 1: Diagnosticar hacia dónde se va el dinero

Antes de aplicar cualquier técnica, el equipo necesita saber qué porción de la factura de inferencia proviene de tokens de entrada, cuál de tokens de salida, y qué fracción de los requests son repetidos o casi repetidos. La mayoría de las implementaciones descubre que entre el 40% y el 60% del volumen de tokens de entrada es redundante: prompts largos con instrucciones de sistema idénticas, contexto de conversación reenviado en cada turno, documentos de RAG traídos completos cuando el modelo necesitaba dos párrafos.

El diagnóstico responde tres preguntas. Primera: ¿cuál es la proporción de tokens de entrada contra tokens de salida? Los modelos cobran más por output, así que una aplicación que genera respuestas largas tiene un perfil de costo diferente de una que procesa documentos extensos con salida corta. Segunda: ¿cuál es la tasa de repetición de requests? Cuanto más alta, más entrega el caché semántico. Tercera: ¿el modelo actual está sobredimensionado para la complejidad real de las tareas? La respuesta casi siempre es sí. Un modelo frontier llamado para clasificar intención de usuario es un auto de lujo repartiendo volantes.

Herramientas como Langfuse y OpenLIT proporcionan este desglose por request. El dashboard del Nexforce Router entrega la vista agregada por clave de API y por proyecto, con el costo ya convertido a la moneda que finanzas reconoce, lo que elimina la etapa separada de convertir factura en dólares a moneda local. El Benchmark de LLMs para CFOs cubre el ángulo de evaluación financiera; aquí el foco es la instrumentación para ingeniería.

Paso 2: Caché semántico: el ahorro que vive en la repetición

El caché semántico es la técnica de mayor retorno sobre esfuerzo para la mayoría de las aplicaciones. En lugar de enviar un request al modelo, el sistema verifica si una respuesta para un prompt semánticamente similar ya existe en caché. Si existe y está dentro del umbral de similitud, la respuesta se sirve sin costo de inferencia.

La implementación más común usa Redis como almacenamiento y un modelo de embeddings para generar el vector del prompt de entrada. El sistema consulta Redis por similitud de coseno contra los prompts en caché. Si la distancia es inferior al umbral (típicamente entre 0.05 y 0.15, dependiendo de la aplicación), la respuesta en caché es retornada. El Nexforce Router ofrece caché de respuestas y embeddings como funcionalidad nativa, sin exigir que el equipo arme la infraestructura de Redis y el pipeline de embeddings.

El ahorro típico oscila entre el 30% y el 70% de las llamadas, pero depende directamente del perfil de tráfico. Aplicaciones con alto volumen de requests similares (chatbots de soporte, asistentes de documentación, sistemas de clasificación de tickets) son las que más ganan. Aplicaciones con prompts altamente variables, como generación de código a medida o análisis de datos no estructurados, tienen hit rate bajo y el caché no se paga.

El principal trade-off está en el riesgo de respuestas stale. Las respuestas envejecen rápido. Si el modelo subyacente fue actualizado o si el contexto de negocio cambió, el caché sirve una respuesta desactualizada. La mitigación es un TTL agresivo (entre 1 y 24 horas, definido por experimento) combinado con invalidación manual para dominios sensibles.

Paso 3: Compresión de prompts: menos contexto, misma respuesta

Si el caché semántico ataca la repetición entre requests, la compresión de prompts ataca el volumen dentro de cada request. La técnica reduce el número de tokens de entrada sin perder la información que el modelo necesita para responder.

El blanco más común es el contexto inyectado por sistemas de RAG. Un pipeline típico recupera cinco documentos de la base vectorial, concatena los textos completos y envía todo al modelo. De esos cinco, dos son relevantes y tres son ruido, pero el modelo pagó por todos. Herramientas como LLMLingua y prompt pruning mediante modelos menores aplican compresión selectiva: remueven tokens de baja perplejidad, cortan párrafos con baja similitud a la query y preservan entidades nombradas, números y términos técnicos.

El ahorro típico alcanza entre el 50% y el 70% de reducción en tokens de entrada para pipelines de RAG. En aplicaciones que no inyectan contexto externo, como un asistente de código que recibe solo el archivo actual, la compresión tiene poco efecto y no justifica la latencia adicional del compresor.

La compresión no es gratuita. Cada request pasa por un modelo compresor antes de llegar al LLM principal.

El trade-off está en la frontera entre compresión y pérdida de precisión. Para tareas de razonamiento complejo, un corte agresivo de contexto puede remover el matiz que el modelo habría usado para llegar a la respuesta correcta. La recomendación: aplicar compresión de prompts primero en tareas de extracción y resumen, donde la información relevante está localizada, y probar con un conjunto de evaluación antes de activarla en tareas analíticas.

Un párrafo de una sola frase.

Paso 4: Cuantización y self-hosting: el camino estructural

La cuantización es la técnica de mayor ahorro absoluto, pero también la que exige más infraestructura. Reduce la precisión numérica de los pesos del modelo (de FP16 a INT8 o INT4), disminuyendo el uso de memoria y acelerando la inferencia. Para equipos que ejecutan modelos propios en GPUs, el ahorro puede alcanzar hasta el 80% en relación al costo equivalente vía API.

Herramientas como vLLM con AWQ (Activation-aware Weight Quantization) entregan inferencia en INT4 con pérdida de calidad inferior al 1% en benchmarks estándar para la mayoría de los modelos open-source. El Llama 3.1 70B cuantizado a INT4 cabe en una sola GPU A100 y entrega throughput comparable al doble del modelo en FP16, por el mismo costo de hardware.

La decisión de self-hosting no es solo técnica. Implica adquirir o alquilar GPUs, mantener la infraestructura y asumir la responsabilidad por uptime y latencia. Para volúmenes bajos, por debajo de aproximadamente 50 millones de tokens por mes, el costo de mantener GPUs ociosas supera el ahorro de no pagar la API. Para volúmenes altos y predecibles, por encima de 200 millones de tokens por mes, el self-hosting se paga en semanas.

El Nexforce Router sirve como capa de enrutamiento sobre modelos self-hosted y modelos de API con la misma clave: el equipo comienza vía API, migra gradualmente a self-hosting en los modelos de mayor volumen y mantiene la API como fallback. El cambio es transparente para la aplicación.

Paso 5: Enrutamiento inteligente: el modelo correcto para cada request

El enrutamiento inteligente opera en la capa de decisión: para cada request, el sistema elige qué modelo atiende esa llamada con base en complejidad, latencia requerida y costo. Es la técnica que captura el ahorro que las otras cuatro dejan pasar, porque actúa sobre requests que no son repetidos, no son comprimibles y no justifican self-hosting.

Es la más subestimada de las cinco.

La arquitectura típica clasifica cada request por intención y complejidad. Una clasificación de sentimiento o una extracción de entidad va a un modelo liviano y barato. Un análisis jurídico o una generación de informe complejo va a un modelo frontier. El diferencial está en el clasificador: si el sistema envía el 5% de los requests simples al modelo caro, el ahorro cae del 60% al 45%.

El ahorro típico oscila entre el 40% y el 60% de la factura de inferencia para aplicaciones con perfil de tráfico heterogéneo, que describe a la mayoría de las aplicaciones reales. Cuando todo el tráfico es complejo, el enrutamiento no tiene hacia dónde desviar y el ahorro es cero. Cuando es predominantemente simple, la ganancia puede superar el 70%.

El Nexforce Router implementa enrutamiento inteligente como funcionalidad nativa: clasificación de intención, selección de modelo por costo y rendimiento, y failover automático entre proveedores. El equipo define reglas por clave de API. Por ejemplo, requests de clasificación van a un modelo liviano, requests de razonamiento van a un modelo frontier, y el presupuesto está controlado por límite de gasto por clave. El post Model Router: el middleware que falta en tu stack de IA detalla la arquitectura; el AI Gateway Corporativo cubre la capa de seguridad y gobernanza.

Cómo saber si funcionó: verificación de impacto

El impacto de cada técnica se mide contra la línea base establecida en el Paso 1. Cuatro métricas son esenciales. Costo total por período, comparado con la línea base en dólares y en la moneda local relevante. Hit rate del caché semántico, expresado como porcentaje de requests servidos sin inferencia. Distribución de requests por nivel de modelo, mostrando la migración del modelo caro al barato a lo largo del tiempo. Reducción de tokens de entrada tras la compresión de prompts, medida como delta porcentual sobre la línea base.

Un equipo que aplica las cinco técnicas en el orden correcto (diagnóstico, caché, compresión, enrutamiento, y self-hosting solo si el volumen lo justifica) típicamente ve una reducción del 50% al 70% en la factura total en 90 días. La ganancia no es lineal: las dos primeras técnicas entregan el 60% del ahorro con el 20% del esfuerzo.

Tabla de decisión: qué técnica aplicar primero

El orden de aplicación importa más que la elección de las técnicas. La tabla a continuación organiza las cinco técnicas por perfil de carga y ahorro estimado, para que el equipo decida por dónde empezar.

La recomendación para la mayoría de los equipos: empezar por el diagnóstico, aplicar caché semántico y compresión de prompts en paralelo, activar enrutamiento inteligente a continuación, y evaluar self-hosting solo cuando el volumen mensual justifique la inversión en hardware. Las tres primeras técnicas no exigen infraestructura adicional y entregan la mayor parte del ahorro.

Empieza por lo que es gratis. Después invierte.

Lo que puede salir mal (y cómo corregirlo)

Tres modos de falla aparecen consistentemente cuando los equipos implementan estas técnicas por primera vez.

Primero: el caché sirviendo respuestas stale. El síntoma es el usuario recibiendo una respuesta que cita una versión antigua de la API o un precio que cambió la semana anterior. La corrección es reducir el TTL del caché e implementar invalidación basada en eventos: cada vez que el dominio de conocimiento cambia (una nueva versión de documentación, una alteración de política de precios), el caché se limpia selectivamente por patrón de prompt.

El segundo es la compresión de prompts degradando la calidad en tareas de razonamiento. El síntoma es el modelo entregando respuestas correctas pero incompletas, porque el matiz que conectaba dos párrafos fue removido por el compresor. La corrección es aplicar compresión solo en tareas de extracción y resumen, y usar un umbral de similitud más conservador en el compresor (por encima de 0.85) para tareas analíticas.

El tercero es el enrutador enviando requests complejos a modelos simples. El síntoma es el modelo liviano respondiendo con alucinaciones o rechazos en tareas que exigen razonamiento en múltiples etapas. La corrección es calibrar el clasificador de intención con un conjunto de ejemplos representativos e implementar una regla de escape: si el modelo liviano retorna baja confianza o rechaza la respuesta, el request se reencamina al modelo frontier.

Preguntas Frecuentes

¿Cuánto tiempo toma implementar las cinco técnicas?

Entre dos y seis semanas, dependiendo de la madurez de la infraestructura. Caché semántico y compresión de prompts pueden estar en producción en días. El enrutamiento inteligente toma de una a dos semanas si la capa de gateway ya existe. El self-hosting exige de cuatro a ocho semanas para aprovisionamiento, configuración y migración gradual del tráfico.

¿Qué técnica entrega el mayor retorno sobre esfuerzo?

Caché semántico para aplicaciones con tráfico repetitivo. Enrutamiento inteligente para aplicaciones con tráfico heterogéneo. Las dos combinadas cubren la mayoría de los perfiles de carga y entregan entre el 50% y el 70% de ahorro con esfuerzo moderado.

¿Necesito aplicar las cinco técnicas?

No. La mayoría de los equipos obtiene del 50% al 70% del ahorro posible con las tres primeras: caché, compresión y enrutamiento. Cuantización y self-hosting son para equipos cuyo volumen justifica la inversión en hardware. El batching continuo es relevante solo para modelos self-hosted.

¿Cómo afecta el multiplicador tributario brasileño a estas cuentas?

Cada dólar de costo de inferencia pagado mediante facturación internacional carga un multiplicador de hasta el 55% en Brasil. La cadena está compuesta por IRRF (15% a 25%), CIDE del 10% sobre SaaS como servicio técnico (clasificación de la SC Cosit 191/2017, confirmada por la 99/2018, con exención del §1°-A del art. 2° de la Ley 10.168/2000 restringida a licencias puras sin transferencia de tecnología), PIS del 1,65%, COFINS del 7,6%, ISS del 2% al 5% según el municipio, IOF del 3,5% y spread cambiario del 5% al 10%. Un ahorro del 50% en dólares mediante optimización de ingeniería se convierte en un ahorro del 50% sobre una base que ya era un 55% mayor en moneda local. El Nexforce Router elimina el multiplicador en el origen al facturar en BRL con documento fiscal e impuestos incluidos.

¿Qué es lo primero que un equipo debería hacer mañana?

Instrumentar la aplicación para saber exactamente cuántos tokens están siendo consumidos, por cuál modelo, y cuál es la tasa de repetición de requests. Sin ese diagnóstico, cualquier técnica aplicada es optimización a ciegas. El dashboard del Nexforce Router entrega esta visibilidad en minutos, con el costo ya expresado en la moneda local.

El multiplicador que hace que cada técnica valga más

La Comparación de Costos de LLMs en 2026 mostró el precio por token de cada modelo. Este artículo mostró cómo reducir el número de tokens que la aplicación consume. Las dos cosas se multiplican.

Para las empresas que operan en América Latina, existe un tercer factor que ninguna técnica de ingeniería resuelve por sí sola: el multiplicador tributario y cambiario sobre cada dólar gastado en inferencia. En Brasil, IRRF, CIDE, PIS, COFINS, IOF y spread cambiario apilan hasta el 55% sobre el costo del token. Una aplicación que gasta USD 100 mil por mes en inferencia desembolsa el equivalente de hasta USD 155 mil en moneda local. Aplicar caché semántico, compresión de prompts y enrutamiento inteligente reduce el gasto en dólares. Facturar mediante Nexforce Router en BRL elimina el multiplicador en el origen, porque el documento fiscal ya incluye los impuestos y el tipo de cambio está resuelto, y el ahorro de las cinco técnicas de ingeniería pasa a calcularse sobre el costo real en la moneda que finanzas realmente ve.

Las cinco técnicas de ingeniería son el cómo. La facturación en moneda local es el por dónde. Juntos, transforman una factura que se duplica silenciosamente en una factura que cabe en el presupuesto y que finanzas puede leer.

Referencias y Lectura Complementaria

• Comparación de Costos de LLMs en 2026: Enrutamiento Inteligente con Nexforce Router
• Benchmark de LLMs para CFOs: lo que importa es el costo
• Model Router: el middleware que falta en tu stack de IA
• AI Gateway Corporativo: enrutamiento y seguridad para LLMs
• Nexforce Router