LLM cost optimization en empresa: recortar hasta 60%
TL;DR
LLM cost optimization empresa es el conjunto de prácticas técnicas y de gobierno que permite reducir entre un 40% y un 70% el gasto en APIs de modelos de lenguaje (Anthropic, OpenAI, Google, modelos open source) sin degradar la calidad percibida por el usuario. En Datalvar trabajamos sobre diez palancas concretas: compresión de prompts, retrieval más selectivo, router de modelos, prompt caching agresivo, batch API para cargas no urgentes, observabilidad granular por feature, control estricto de tokens de salida, deduplicación de system prompts, eliminación de retries silenciosos y negociación de tarifas enterprise. Aplicadas en orden, una factura mensual de 50.000 € suele bajar a 15.000-20.000 € en seis semanas.
¿Por qué la factura LLM de tu empresa está inflada?
En 2024 y 2025 vimos cómo los equipos de ingeniería españoles se lanzaron a producción con copilotos internos, asistentes de soporte, RAG sobre documentación corporativa y agentes verticales. La urgencia por entregar valor pesó más que cualquier consideración de coste, y eso fue lo correcto en ese momento: validar primero, optimizar después. El problema es que ese “después” no ha llegado para mucha gente, y nos encontramos clientes con facturas de Anthropic que pasaron de 4.000 € en enero de 2025 a 62.000 € en marzo de 2026 sin que el negocio creciera proporcionalmente. La factura LLM se infla por inercia, no por demanda real.
Anthropic, OpenAI y Google llevan dos años subiendo capacidades y precios efectivos por petición real, aunque el precio nominal por millón de tokens haya bajado en algunos modelos. La paradoja es la siguiente: los modelos son más baratos por token, pero las aplicaciones gastan más tokens por interacción porque hemos metido contexto más largo, system prompts inflados, RAG con top-k de 20 chunks y conversaciones multi-turno que arrastran historial completo. Una llamada media en producción que en 2024 consumía 1.500 tokens hoy consume 8.000-15.000 con facilidad. Aplicar LLM cost optimization empresa en este escenario no es opcional: es la diferencia entre que el producto sea viable o que el CFO pida cerrarlo.
El error más caro que vemos es promover un PoC a producción sin pasar por una fase de optimización. El PoC se diseña para demostrar que la idea funciona, no para escalar de forma eficiente, y suele incluir prácticas que en producción cuestan miles de euros al mes: un único modelo grande para todo, sin caché, sin batch, sin observabilidad granular, retries automáticos sin límite y system prompts copiados de notebooks de ejemplo. En Datalvar nos llaman cuando la factura ya duele, y el primer ejercicio siempre es de token economics: cuántos tokens entran, cuántos salen, qué modelo, qué feature lo consume, y cuál es el coste unitario por interacción de negocio. Sin esa foto, optimizar es disparar a ciegas.
¿Cuáles son los 10 principales drivers de coste en un sistema LLM?
Antes de tocar nada, hay que entender qué mueve la aguja. La factura de un sistema LLM en producción se explica por diez drivers que combinados generan el 95% del gasto. Identificarlos en tu propio stack es el paso cero de cualquier proyecto de optimización serio, y en Datalvar lo hacemos en la primera semana mediante un audit con Langfuse o Helicone que segmenta cada llamada por endpoint, feature y usuario. La distribución suele ser sorprendente: rara vez los tres features que el equipo cree “caros” son realmente los más caros.
Los drivers son: número de tokens de input por llamada, número de tokens de output generados, número de llamadas por usuario activo al mes, modelo elegido para cada tarea (Opus, Sonnet, Haiku, GPT-4o, GPT-4o-mini, Gemini Pro, Flash, etc.), contexto enviado en cada llamada (system prompt + chunks de RAG + historial conversacional), llamadas redundantes sin caché, uso de streaming versus batch, acumulación de tokens en conversaciones multi-turno, verbosidad del output y retries fallidos que pasan desapercibidos. Cada uno de estos drivers se ataca con técnicas distintas, y atacar el equivocado primero es lo que hace que muchos proyectos de optimización fracasen.
La regla empírica que aplicamos: en aplicaciones tipo chat enterprise el 60-70% del coste está en tokens de input (system prompt repetido, RAG, historial), no en tokens de output. En aplicaciones tipo generación de contenido el reparto se invierte. En agentes con tool use el coste se dispara por el número de llamadas internas que el modelo hace para completar una tarea, multiplicado por el contexto que arrastra entre pasos. Saber en qué categoría está tu sistema determina qué palancas mover primero. No hay un único playbook: hay un diagnóstico y luego un plan específico.
| Driver | % típico del coste | Palanca principal |
|---|---|---|
| Tokens input (system + RAG + history) | 45-60% | Compresión, caché, top-k bajo |
| Tokens output | 15-25% | max_tokens, formato estricto |
| Modelo elegido | 20-35% | Router por tarea, cascada |
| Llamadas redundantes | 5-15% | Prompt caching, dedup |
| Retries silenciosos | 2-10% | Circuit breaker, alertas |
| Multi-turn accumulation | 5-15% | Summarization, ventana rodante |
¿Cómo reducir tokens de input sin perder calidad?
El input es donde se esconde la mayor parte del gasto y, paradójicamente, donde casi nadie mira primero. Cuando auditamos un sistema típico de RAG empresarial encontramos system prompts de 3.000-5.000 tokens (instrucciones acumuladas durante meses de iteración), retrieval con top-k de 15-20 chunks de 500 tokens cada uno, e historial conversacional sin truncar. Eso son 15.000-25.000 tokens de input por llamada, mucho de ello redundante o irrelevante para la pregunta concreta del usuario. La primera optimización seria es reducir ese input a 4.000-6.000 tokens manteniendo o mejorando la calidad de respuesta.
La técnica más infravalorada es prompt compression mediante modelos pequeños que destilan el contexto. LLMLingua y su versión LongLLMLingua-2 permiten comprimir prompts hasta 20x con pérdida marginal de calidad en tareas de QA y razonamiento medio. La idea: un modelo pequeño (Llama-3-8B fine-tuneado) clasifica qué tokens del prompt son prescindibles y los elimina antes de enviar al modelo grande. En proyectos donde lo hemos aplicado, el coste de input baja un 40-60% con caídas de precisión menores al 2% en benchmarks internos. RECOMP es una alternativa cuando el contexto viene de RAG y quieres comprimir cada chunk individualmente antes de pasarlo.
La segunda palanca es deduplicación de system prompts. Muchos equipos tienen el mismo system prompt repetido en cada llamada porque no usan prompt caching, o porque tienen varios system prompts solapados entre features (uno para tono, otro para formato, otro para safety). Consolidar a un único system prompt versionado, marcarlo como cacheable en Anthropic, y eliminar duplicidades suele dar un 20-30% de ahorro adicional sin tocar nada más. La tercera es RAG más selectivo: bajar el top-k de 20 a 5 con reranking de calidad (Cohere Rerank o un cross-encoder propio) mantiene o mejora la precisión y divide el coste de retrieval entre 3-4. La cuarta, chunking optimizado: chunks de 300-400 tokens con solapamiento mínimo dan mejor recall que chunks de 1.000 tokens en la mayoría de bases de conocimiento corporativas.
¿Cómo reducir tokens de output sin perder calidad?
El output también pesa, sobre todo en aplicaciones tipo redacción, resumen o generación de informes. La buena noticia es que es la palanca más fácil de mover porque el control es directo: defines límites duros y los enforcas. La mala noticia es que muchos equipos no lo hacen porque “mejor que el modelo decida cuánto escribir”, y el modelo, generosamente, escribe siempre más de lo que el usuario necesita. En LLM cost optimization empresa, controlar el output es de las primeras cosas que tocamos porque el impacto es inmediato y el riesgo bajo.
Restringir el formato de salida es la palanca más rentable. Un mismo dato extraído puede devolverse como JSON estricto (200 tokens) o como markdown narrativo con explicaciones (1.200 tokens). En features donde la salida la consume otro sistema o se renderiza en UI con plantilla fija, exigir JSON minificado mediante response_format o tool use ahorra el 60-80% de tokens de output sin pérdida de información. Cuando la salida es para humanos, definir un formato máximo (por ejemplo “máximo 3 bullets de 1 línea”) y dárselo en el system prompt es suficiente para que el modelo se ciña.
El parámetro max_tokens debe estar siempre fijado de forma estricta. Dejarlo abierto o muy alto es una invitación a respuestas verborrágicas que cuestan dinero y que el usuario rara vez lee entera. Establecer límites por feature (200 tokens para clasificación, 500 para resumen ejecutivo, 1.500 para redacción larga) y monitorizar cuántas respuestas llegan al tope es la práctica básica. Si más del 5% de las respuestas tocan techo, hay que rediseñar el prompt para que el modelo sintetice mejor, no subir el tope. Las stop sequences completan el control: parar la generación en marcadores conocidos (</response>, \n\n---) evita las coletillas finales que el modelo añade por inercia y que pueden suponer 100-300 tokens de regalo en cada llamada.
¿Cómo elegir el modelo correcto para cada tarea?
Esta es la palanca de mayor impacto y la más infrautilizada. En la mayoría de sistemas que auditamos hay un único modelo grande (Claude Opus, GPT-4o o Gemini Pro) sirviendo todas las llamadas, incluidas las triviales. Eso es como pagar un consultor senior a 300 €/hora para que conteste si un email es spam: técnicamente funciona, financieramente es ridículo. Construir un router de modelos que asigne cada tarea al modelo más barato capaz de resolverla es de lo primero que hacemos en cualquier optimización seria, y suele dar entre un 30% y un 50% de ahorro.
La regla práctica que aplicamos en Datalvar:
| Tipo de tarea | Modelo recomendado | Coste relativo |
|---|---|---|
| Clasificación binaria, extracción de entidades simples, routing | Haiku 3.5 / GPT-4o-mini / Gemini Flash | 1x |
| Resumen, reescritura, QA sobre contexto pequeño | Sonnet / GPT-4o | 5-8x |
| Razonamiento complejo, generación creativa larga, agentes con tool use multi-paso | Opus / o1 / Gemini Pro 1.5 | 15-25x |
| Tareas masivas no críticas (clasificación de catálogo, enriquecimiento histórico) | Llama 3.3 / Mistral Large self-hosted | 0.2-0.5x |
La cascada de modelos lleva esta idea al siguiente nivel. La llamada empieza por Haiku con instrucción de devolver, además de la respuesta, una métrica de confianza (puede ser explícita en el prompt o derivada de logprobs). Si la confianza supera un umbral, la respuesta se sirve. Si no, se escala a Sonnet automáticamente. Solo un 10-20% de las llamadas llega al modelo caro, pero la calidad media percibida por el usuario es prácticamente la del modelo caro. En un cliente del sector legal pasamos de 100% de llamadas a Opus a un 8% de llamadas escaladas, con calidad medida (eval humana sobre 500 casos) idéntica.
Los modelos open source self-hosted entran cuando el volumen es muy alto y la tarea es repetitiva. Llama 3.3 70B en una GPU A100 cuesta del orden de 0,1-0,3 € por millón de tokens efectivos, frente a 0,8-3 € de los modelos cloud comparables. Para clasificación masiva de 50 millones de registros mensuales o enriquecimiento de catálogos de e-commerce con cientos de miles de SKUs, la diferencia es radical. La pega es la operación: alguien tiene que mantener la inferencia, monitorizar latencia y actualizar modelos. Si tu equipo no tiene MLOps maduro, mejor empezar con la cascada en cloud y dejar self-hosted para fase 2.
¿Cómo usar prompt caching de forma agresiva?
El prompt caching es, sin discusión, la palanca con mejor ratio esfuerzo/ahorro de toda la lista. Anthropic ofrece caché de prompt con descuento del 90% sobre los tokens cacheados y vida útil de 5 minutos (extensible a 1 hora desde 2025). OpenAI introdujo prompt caching automático en 2024 con descuento del 50% sobre los tokens repetidos. Google ofrece caché explícito en Vertex AI con descuento similar. Si tu aplicación tiene un system prompt estable o un contexto que se repite (documentación corporativa, base de conocimiento, ejemplos few-shot), no usar caché es regalar dinero.
En Anthropic la implementación es manual: marcas el bloque cacheable con cache_control: {"type": "ephemeral"} y la primera llamada crea la caché (con un sobrecoste del 25% sobre el precio normal de input para ese bloque). Las siguientes llamadas dentro de la ventana de 5 minutos pagan solo el 10% del coste normal por esos tokens. Si tu system prompt + base de conocimiento ocupan 30.000 tokens y haces 1.000 llamadas por hora, sin caché pagas 30 millones de tokens de input; con caché pagas 30.000 + 999 × 3.000 = 3 millones efectivos. El ahorro real ronda el 85-90% sobre los tokens cacheados, que suelen ser el 70-80% del input total.
El caché propio en Redis complementa al de los proveedores cuando hay prompts que se repiten literalmente (no solo prefijos comunes, sino prompts idénticos). Casos típicos: clasificaciones donde el mismo texto se procesa varias veces, FAQs donde la misma pregunta llega de varios usuarios, validaciones donde el input es discreto. Cachear el par (prompt → respuesta) durante 24 horas en Redis con hash SHA-256 como clave puede absorber el 20-40% de las llamadas en aplicaciones de soporte o moderación. La inversión es trivial y el ROI inmediato.
Cuándo no cachear: cuando el prompt cambia mucho entre llamadas (chat conversacional con historial muy variable), cuando los costes de almacenamiento de caché superan el ahorro (volúmenes muy bajos), cuando la latencia adicional de la primera escritura penaliza el SLA y no se puede pre-calentar la caché. En estos casos, otras palancas (router, batch, compresión) son prioritarias.
¿Cómo usar batch API para tareas no urgentes?
Tanto Anthropic como OpenAI ofrecen batch API con 50% de descuento sobre el precio normal a cambio de procesar las llamadas en una ventana de hasta 24 horas. Es la palanca más fácil de aplicar y la que menos equipos usan porque mentalmente asocian “LLM” con “respuesta en tiempo real”. En LLM cost optimization empresa, identificar qué cargas pueden esperar y moverlas a batch es de las primeras acciones del backlog porque el ahorro es lineal y el riesgo cero.
Los casos típicos donde batch tiene sentido: clasificación masiva de tickets de soporte del día anterior para alimentar dashboards, enriquecimiento de catálogo de producto con descripciones generadas por LLM, análisis de transcripciones de llamadas para extracción de insights semanales, traducción de documentación corporativa, generación nocturna de resúmenes ejecutivos sobre datos del día. Todo lo que se puede agrupar y procesar en una ventana nocturna o cada pocas horas es candidato. En un cliente con 2 millones de clasificaciones diarias movimos el 90% a batch y el coste de esa feature bajó de 18.000 € a 9.500 € al mes.
La implementación es trivial: subes un fichero JSONL con todas las peticiones, recibes un ID de batch, consultas estado periódicamente y descargas resultados cuando termina. Anthropic permite hasta 100.000 peticiones por batch; OpenAI hasta 50.000. La latencia real suele estar muy por debajo de las 24 horas máximas (en nuestra experiencia 1-6 horas para volúmenes medios). El único cuidado: gestionar errores parciales (algunas peticiones del batch pueden fallar) y tener un fallback síncrono para los registros que necesitan rehacerse.
| Carga | ¿Apta para batch? | Ahorro potencial |
|---|---|---|
| Clasificación nocturna de tickets | Sí | 50% |
| Enriquecimiento de catálogo | Sí | 50% |
| Chat de soporte en vivo | No | 0% |
| Generación de informes semanales | Sí | 50% |
| Moderación de contenido tiempo real | No | 0% |
| Análisis de logs históricos | Sí | 50% |
¿Cómo negociar tarifas enterprise con proveedores LLM?
A partir de ciertos volúmenes mensuales, los precios de lista dejan de aplicar. Anthropic, OpenAI y Google tienen equipos de ventas enterprise que negocian descuentos a cambio de compromiso de volumen o de exclusividad parcial. El umbral mental a partir del cual merece la pena pedir reunión comercial está en torno a los 20.000-30.000 €/mes de gasto sostenido; por debajo de eso es difícil obtener condiciones especiales más allá de créditos puntuales.
Las palancas típicas en una negociación: compromiso de volumen mensual mínimo (committed spend) a cambio de descuento del 10-25% sobre precio de lista, compromiso anual con descuento mayor (15-35%), compromiso multi-modelo (usar varios modelos del mismo proveedor en lugar de fragmentar), inclusión de servicios profesionales o soporte dedicado, créditos para evaluar modelos nuevos. En nuestra experiencia ayudando a clientes en estas negociaciones, llegar con datos detallados de consumo (segmentación por feature, proyección 12 meses, alternativas evaluadas) cambia radicalmente el resultado frente a llegar con un “queremos descuento”.
Azure OpenAI y Vertex AI son alternativas a OpenAI directo y Google AI Studio respectivamente, con un perfil de precio similar pero con varias ventajas para empresa: SLAs contractuales, residencia de datos en Europa, integración con descuentos cloud existentes (si la empresa ya gasta en Azure o GCP), facturación unificada, opciones de provisioned throughput con descuento. La migración no es trivial (cambian endpoints, autenticación y a veces formato de respuesta), pero para volúmenes altos y entornos regulados (banca, salud, sector público) el ROI suele justificarlo. Vertex AI además expone Claude y Llama además de Gemini, lo que permite multi-modelo bajo una única factura GCP.
¿Cómo montar observabilidad de coste (FinOps LLM)?
Sin observabilidad, optimizar es imposible. La regla en Datalvar es que cualquier sistema LLM en producción debe poder responder en menos de 30 segundos a estas preguntas: cuánto cuesta una respuesta media, cuánto cuesta un usuario activo al mes, qué feature concentra el gasto, qué endpoint tiene la peor relación coste/valor, y cuántos retries silenciosos hubo ayer. Si no puedes responder a eso, no estás haciendo LLM cost optimization empresa: estás adivinando.
Langfuse es nuestra recomendación por defecto para equipos que quieren control y open source. Permite instrumentar cada llamada con tags por feature/usuario/endpoint, calcular coste automáticamente a partir del modelo y tokens, montar dashboards de coste por dimensión y disparar alertas. La integración con SDKs de Anthropic, OpenAI y LangChain es directa. Helicone es alternativa cloud-first más sencilla de poner en marcha (proxy transparente), buena cuando el equipo no quiere mantener infraestructura. Arize Phoenix entra cuando se quiere unificar observabilidad de coste con evaluación de calidad y drift.
Los dashboards mínimos que dejamos montados en todo cliente:
- Coste diario por modelo, con desglose input/output/cached.
- Coste por feature/endpoint con tendencia 30 días.
- Coste medio por usuario activo (DAU/MAU) para detectar power users descontrolados.
- Coste por conversión de negocio (coste por ticket resuelto, coste por lead cualificado, coste por consulta atendida).
- Distribución de tokens input y output con percentiles p50/p95/p99 para detectar outliers que disparan el coste.
- Retries por endpoint, con alerta si superan el 2% del tráfico.
Las alertas son la red de seguridad. Una alerta a Slack si el gasto diario supera el percentil 95 de los últimos 30 días, otra si el ratio retries/llamadas se dispara, otra si un usuario individual consume más del 5% del gasto del día. Sin alertas, descubrirás el problema cuando llegue la factura, que es exactamente cuando ya no puedes hacer nada.
¿Caso real: cómo una empresa pasó de 50.000 €/mes a 18.000 €/mes manteniendo calidad?
Cliente del sector e-commerce europeo (anonimizado). En enero de 2026 tenían un asistente de soporte conversacional + un sistema de enriquecimiento de catálogo + un copiloto interno para el equipo comercial. Factura mensual de Anthropic: 47.800 €. Factura mensual de OpenAI (embeddings + algunos fallbacks): 4.900 €. Total: 52.700 €/mes con tendencia creciente. Calidad medida por CSAT del asistente: 4.1/5. Nos llaman porque el CFO les pidió bajar al menos un 40%.
Semana 1: audit completo con Langfuse instrumentado en los tres sistemas. Hallazgos: el asistente usaba Opus para todas las llamadas (incluida la clasificación de intención inicial), el system prompt tenía 4.200 tokens con instrucciones duplicadas acumuladas en seis meses, no había prompt caching, el retrieval usaba top-k=15 con chunks de 800 tokens, el enriquecimiento de catálogo corría en tiempo real durante el día en lugar de batch nocturno, y un bug en el cliente HTTP causaba un 11% de retries silenciosos. Diagnóstico claro: cinco palancas con impacto >5% cada una.
Semanas 2-6, implementación priorizada. Primero, prompt caching en el asistente (3 días de implementación, ahorro inmediato del 32% en el input del asistente). Segundo, router de modelos con Haiku para clasificación de intención y Sonnet para razonamiento, dejando Opus solo para escalado manual (1 semana, ahorro adicional del 28%). Tercero, batch API para todo el enriquecimiento de catálogo (3 días, ahorro del 50% en esa feature). Cuarto, deduplicación y compresión del system prompt de 4.200 a 1.400 tokens manteniendo todas las reglas críticas (1 semana de iteración con evals). Quinto, fix de los retries y alertas en Langfuse (2 días). Resultado tras 6 semanas: factura combinada de 18.200 €/mes. CSAT del asistente: 4.2/5 (subió ligeramente por menor latencia derivada del modelo más pequeño en clasificación).
Lecciones que nos llevamos y aplicamos en proyectos siguientes: la observabilidad es lo primero, no lo último; la palanca de mayor impacto suele ser el router de modelos, no la que el equipo cree; los retries silenciosos son un coste oculto en casi todos los sistemas que auditamos; y la compresión del system prompt requiere evals automatizadas o degradas calidad sin darte cuenta. En Datalvar hemos sistematizado este playbook en un servicio de auditoría y optimización de costes LLM que cierra en 4-6 semanas con garantía de resultado mínimo.
¿Cuáles son los próximos pasos para optimizar el coste LLM de tu empresa?
Si has llegado hasta aquí y reconoces tu sistema en al menos tres de los drivers que hemos descrito, el orden de actuación que recomendamos es: instrumenta primero (Langfuse o Helicone en 1 semana), audita el reparto real del gasto (no el que crees), aplica prompt caching y batch en las cargas evidentes, luego construye el router de modelos con evals para asegurar que no degradas calidad, y deja la compresión de prompts y la negociación enterprise para fase 2 cuando ya tengas baseline limpia.
El error más caro que vemos es intentar optimizar sin medir. Equipos brillantes se pasan tres semanas reescribiendo prompts para ahorrar el 15% en una feature que solo representa el 8% del gasto total, mientras la feature que se come el 40% sigue sin tocar. Sin la foto real de gasto por dimensión, las decisiones de optimización son intuición, no ingeniería. Por eso el primer paso es siempre observabilidad: una semana invertida ahí ahorra meses de trabajo mal dirigido.
Y la última recomendación, contraintuitiva: no busques bajar el coste al mínimo absoluto. El objetivo de LLM cost optimization empresa no es gastar lo menos posible, es gastar lo correcto para que el unit economics del producto funcione. Si tu asistente cuesta 0,40 € por conversación y genera un valor medio de 3 € por conversación atendida, optimizar a 0,10 € puede ahorrar dinero pero también puede degradar la experiencia y matar la conversión. El número que importa es coste por unidad de negocio (ticket resuelto, lead generado, venta cerrada), no coste por llamada. Diseña la optimización en torno a ese KPI, no en torno a la factura del proveedor.
Preguntas frecuentes
¿Cuánto se puede ahorrar realmente con LLM cost optimization en una empresa media?
En proyectos de auditoría y optimización completos vemos consistentemente reducciones del 40-70% sobre la factura mensual de partida, sin degradación de calidad medida en evals o métricas de negocio. El rango exacto depende de cuán “verde” esté el sistema: equipos que nunca optimizaron suelen estar en el extremo alto (60-70%), equipos que ya aplicaron palancas básicas (caché, max_tokens) se quedan en el 30-45%. En cualquier caso, recortar menos de un 30% en un sistema LLM no optimizado es muy raro: hay demasiada grasa acumulada en las prácticas por defecto.
El plazo típico para materializar el ahorro es de 4-8 semanas: una semana de observabilidad, dos de implementación de palancas rápidas (caché, batch, router) y dos a tres más para optimizaciones que requieren evals (compresión de prompts, modelos open source). El payback de un proyecto de optimización suele ser inferior a un mes desde que se aplican los primeros cambios.
¿Merece la pena migrar a modelos open source self-hosted para ahorrar coste LLM?
Depende del volumen y de la madurez MLOps del equipo. Por debajo de 30.000 €/mes de gasto LLM, casi nunca compensa: los costes operativos de mantener inferencia self-hosted (GPUs, monitorización, actualizaciones de modelo, on-call) superan el ahorro. Entre 30.000 y 100.000 €/mes, compensa para cargas masivas repetitivas (clasificación, enriquecimiento) pero no para chat conversacional o agentes complejos donde los modelos cerrados siguen superando claramente. Por encima de 100.000 €/mes, casi siempre compensa al menos para una parte del tráfico.
La aproximación pragmática que recomendamos: empezar siempre con cascada de modelos cloud (Haiku → Sonnet → Opus) y caché agresiva. Si tras esa optimización el gasto sigue siendo alto y hay cargas claramente identificadas como repetitivas, evaluar Llama 3.3 o Mistral self-hosted para esas cargas concretas, no para todo. Migrar todo el stack a open source de golpe es un error frecuente que termina costando más en operaciones de lo que ahorra en APIs.
¿Qué herramienta de observabilidad LLM recomendáis para FinOps?
Para equipos que quieren control y open source, Langfuse self-hosted es nuestra recomendación por defecto: instrumentación granular, dashboards de coste por dimensión, integración con SDKs nativos de Anthropic y OpenAI, evals integradas, comunidad activa. Para equipos que quieren cero infraestructura y aceptan SaaS, Helicone es la opción más rápida de poner en marcha como proxy transparente. Para empresas que ya tienen Arize o Datadog y quieren consolidar observabilidad de coste con calidad y drift, Arize Phoenix es la apuesta correcta.
Lo importante no es la herramienta concreta sino el modelo de datos. Antes de elegir, define qué dimensiones quieres poder cortar (feature, endpoint, usuario, tenant, versión de prompt, modelo) y asegúrate de que la herramienta soporta ese tagging. Cambiar de herramienta de observabilidad cuando ya tienes seis meses de datos es doloroso; elegir bien al principio ahorra mucho rework.
¿Cómo evito que un fix de coste degrade la calidad de respuesta?
Con evals automatizadas, sin excepciones. Cada palanca de optimización que toque el prompt, el modelo o el contexto debe validarse contra un dataset de evaluación representativo (mínimo 200-500 ejemplos cubriendo casos típicos y edge cases) antes de promocionar a producción. La métrica concreta depende de la tarea: exact match, F1, LLM-as-a-judge, eval humana sobre muestra. Sin evals, optimizar es ir a ciegas.
En la práctica, recomendamos montar el pipeline de evals antes de empezar a optimizar. Cada cambio se prueba en el dataset, se compara contra baseline y solo se promociona si la métrica está dentro del margen de tolerancia (típicamente -2% sobre baseline o mejor). Esto convierte la optimización en un proceso de ingeniería medible en lugar de un acto de fe. Herramientas como Langfuse, Promptfoo o Braintrust facilitan este workflow.
¿Tiene sentido el prompt caching si mi sistema tiene system prompts dinámicos?
Depende de cuánto cambien. El caché de Anthropic se basa en prefijos: si los primeros N tokens son idénticos entre llamadas, esos N tokens se cachean. Aunque el resto del prompt cambie por llamada, la parte estable (instrucciones generales, formato, ejemplos) se beneficia del descuento del 90%. La regla práctica: si el 60-70% del input es estable entre llamadas, el caché vale la pena; si menos del 30% lo es, probablemente no.
Una técnica que aplicamos cuando el system prompt parece “todo dinámico”: refactorizar para extraer la parte estable al inicio y mover lo dinámico al final, justo antes del mensaje del usuario. Sorprende cuánto contenido aparentemente variable es en realidad estable con un pequeño rediseño. En un cliente, refactorizar el orden del system prompt convirtió un 25% de input cacheable en un 78%, sin tocar la lógica de negocio.
¿Cuándo debería negociar tarifas enterprise con Anthropic, OpenAI o Google?
Por debajo de 15.000-20.000 €/mes de gasto sostenido es difícil obtener condiciones especiales más allá de créditos puntuales o acceso a programas de partner. Entre 20.000 y 50.000 €/mes empieza a tener sentido pedir reunión comercial: descuentos del 10-15% sobre lista son razonables, plus acceso prioritario a nuevos modelos. Por encima de 50.000 €/mes, la negociación es obligada: descuentos del 20-35% con compromiso anual son frecuentes, y los proveedores compiten activamente por la cuenta.
Lo que más impacta en una negociación: llegar con datos detallados (segmentación por feature, proyección 12 meses, alternativas evaluadas), tener una alternativa real evaluada (multi-proveedor o self-hosted parcial) y compromiso multi-año si el negocio lo permite. Negociar sin datos o sin alternativa real rara vez consigue más que el descuento estándar de la página de pricing enterprise.
¿Por dónde empiezo si tengo poca instrumentación y la factura está disparada?
Por la instrumentación, sí o sí. Una semana invertida en montar Langfuse o Helicone y taguear correctamente cada llamada por feature, endpoint y usuario es la inversión con mejor ROI de todo el proyecto. Sin esa foto, las decisiones de optimización son adivinanzas. Una vez tienes el reparto real del gasto, las dos palancas que rara vez fallan son prompt caching (si tienes system prompts estables) y batch API (si tienes cargas no urgentes). Aplicar esas dos en la primera quincena suele dar ya un 25-40% de ahorro y financia el resto del proyecto.
Después, en orden de impacto típico: router de modelos con cascada, control estricto de tokens de output, RAG más selectivo con reranking, compresión de prompts, fix de retries silenciosos y negociación enterprise. Cada palanca debe validarse con evals antes de promocionar. En seis semanas, un sistema típico está optimizado entre un 40% y un 60%, con observabilidad montada para evitar que el gasto se vuelva a disparar.
¿Quieres aplicar esto en tu negocio?
30 minutos. Sin compromiso. Salimos con un mapa de oportunidades concreto.