Mejor LLM según el caso de uso (2026): matriz de costes para chat, RAG y agentes

TL;DR — Elegir el «mejor» LLM no se reduce a una puntuación de benchmark. Depende de si vas a desplegar un chatbot, una API de RAG o procesamiento batch, o un agente de IA. Cada patrón tiene una estructura de prompt, una tasa de aciertos, un ajuste al TTL y una tolerancia a la latencia distintos. Por tanto, también cambia la combinación óptima de modelo y estrategia de caché. Esta guía parte de las mediciones de la Parte 3: mismo gateway, mismo SDK de OpenAI y solo hay que cambiar el campo model en cada llamada.

Serie: Parte 4 de 5 · Anteriormente: Parte 1 — Principios de caché · Parte 2 — Comparativa y evaluación de proveedores · Parte 3 — Tutorial con código funcional · Siguiente: Parte 5 — Integración con LangChain

0. La fórmula universal de costes

Antes de entrar en los casos de uso, esta es la ecuación que debe optimizar cualquier decisión:

per-call cost = (input_uncached × P_in)
              + (input_cached   × P_in × cache_discount)
              + (output × P_out)

per-call TTFT ≈ prefill_time × (1 - hit_rate)
              + decode_time

Hay cuatro palancas:

1. Reducir el precio unitario (P_in / P_out) → elegir un modelo más barato.
2. Aumentar la tasa de aciertos → reestructurar el prompt y ajustar el TTL al ritmo del tráfico.
3. Reducir el coeficiente de descuento de caché → elegir un proveedor con mejores condiciones de caché.
4. Elegir el proveedor con el prefill en caché más rápido → la latencia afecta a la experiencia de usuario.

Cada caso de uso combina estas palancas de forma distinta.

Caso de uso 1: chatbots, atención al cliente y asistentes

Perfil de tráfico

• Cada solicitud incluye un system prompt largo (personalidad + conocimiento + reglas), historial de varios turnos y un nuevo mensaje del usuario.
• Contexto medio: 4K–20K tokens.
• Los usuarios son muy sensibles al tiempo hasta el primer token (>2 s da la sensación de que algo falla).
• Dentro de una sesión, las solicitudes llegan con intervalos de segundos o minutos, muy por debajo del TTL de caché de cualquier proveedor.

Por qué el chat aprovecha la caché casi sin hacer nada

El chat es la carga que mejor encaja con la caché. Dentro de una misma sesión:

Request 1: [system: 8K] + [history: 0]   + [user: Q1]
Request 2: [system: 8K] + [history: 200] + [user: Q2]
Request 3: [system: 8K] + [history: 400] + [user: Q3]
           ↑──────── prefix is monotonically growing ────────↑

Si el intervalo entre mensajes no supera el TTL —unos minutos en todos los proveedores—, la parte del system prompt consigue una tasa de aciertos superior al 90% sin esfuerzo. No hacen falta keep-alives.

Modelos recomendados (mediciones de 2026-05)

* Medido con un system prompt estable de 7,300 tokens, una sola ejecución secuencial y sin carga concurrente. Consulta la Parte 3 §6 para ver la tabla completa.

Código mínimo para producción

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/v1",
)

def chat(history: list, user_msg: str):
    return client.chat.completions.create(
        model="gpt-5.4-mini",
        max_tokens=512,
        messages=[
            {"role": "system", "content": STABLE_SYSTEM_PROMPT},   # front
            *history,                                              # middle
            {"role": "user", "content": user_msg},                 # back
        ],
    )

No hace falta más. La caché es automática para todos los modelos de la tabla; no se requiere ningún marcador. Durante el desarrollo, consulta resp.usage.prompt_tokens_details.cached_tokens para confirmar los aciertos.

Errores habituales en chatbots

• ❌ No incluyas la fecha y hora actual en el system prompt ("Today is 2026-05-25 14:30:25"). La precisión de segundos invalida la caché en cada llamada.
• ❌ No reconstruyas el historial en cada turno. Mantén el orden del array de mensajes idéntico byte a byte y limítate a añadir elementos.
• ✅ Pon los datos de la personalidad del usuario en el primer mensaje del usuario, no en el system prompt. Así, las diferencias entre usuarios no invalidan el prefijo compartido.
• ✅ Si una sesión supera el TTL y la caché se enfría, envía un ping keep-alive de 1 token (consulta la Parte 3 §8.2) antes de que llegue el siguiente mensaje del usuario.

Caso de uso 2: cargas de API (RAG, generación de contenido y procesamiento batch)

Perfil de tráfico

• Preguntas y respuestas con RAG: entrada = sistema estable + documentos recuperados variables + consulta variable.
• Generación de contenido (textos de marketing, código, traducción): plantilla estable y datos variables.
• Procesamiento batch (clasificación de documentos, limpieza de datos): la misma tarea a gran volumen.
• La latencia es secundaria; el coste por llamada es lo principal.

El problema principal: la recuperación reordena el prefijo

El problema central de la caché en RAG es que los documentos recuperados cambian entre llamadas y rompen el prefijo en mitad del prompt.

Request 1: [system: 3K] + [doc_A, doc_B, doc_C] + [user: Q1]
Request 2: [system: 3K] + [doc_B, doc_D, doc_A] + [user: Q2]
           ↑─ hits ─────↑  ↑──── miss ─────────↑

Hay tres soluciones, de menor a mayor complejidad:

Solución A — Coloca los documentos recuperados al final, no al principio.

messages = [
    {"role": "system", "content": SYSTEM_PROMPT},          # ~3K, stable
    {"role": "system", "content": INSTRUCTION_TEMPLATE},   # ~500, stable
    {"role": "user",   "content": f"References:\n{retrieved_docs}\n\nQuestion: {q}"},
]

Resultado: toda la parte de system —los ~3.5K tokens estables— queda en caché. Solo falla la parte destinada al usuario en cada llamada. Esto basta para la mayoría de sistemas RAG en producción. Con este patrón y gpt-5.4-mini, medimos una tasa de aciertos superior al 80% en los tokens del sistema.

Solución B — Orden determinista de los resultados recuperados. Ordena los fragmentos recuperados por una clave estable (doc_id ascendente), no por la puntuación de relevancia. Los fragmentos más frecuentes permanecen en posiciones fijas y el prefijo coincide más a menudo. La precisión del ranker baja ligeramente, pero suele ser irrelevante.

Solución C — Marcadores nativos de caché explícita mediante los SDK de cada proveedor. Si usas Anthropic Claude directamente —no a través de este gateway—, el patrón con varios cache_control permite almacenar como puntos de corte independientes el contenido que «nunca cambia», el que «cambia poco» y el que «cambia en cada tarea». Es una opción excelente para sistemas RAG complejos si puedes mantener un SDK adicional.

Consideraciones sobre el TTL en cargas de API

• Tráfico continuo (endpoint RAG 24/7): un TTL de 5 minutos funciona bien; siempre llega otra solicitud dentro de la ventana.
• Tráfico por ráfagas o cron (batch diario a las 09:00): usa un proveedor con TTL largo (deepseek-v4-flash fue el más duradero de las pruebas) o envía un keep-alive de 1 token cada TTL/2 durante la ventana de ejecución. El patrón está en la Parte 3 §8.2.

Modelos recomendados por tarea

† Los marcadores múltiples cache_control de Claude no tienen rival en RAG por capas. Usa el SDK anthropic apuntando al gateway; consulta la Parte 3 §2.

Estimación de costes de RAG (100K consultas/día)

3K de sistema + 5K de documentos recuperados + consulta de 200 tokens + salida de 300 tokens. Las cifras se han escalado a partir de los costes por llamada medidos en la Parte 3 §6, con un único tenant y sin carga concurrente. Para tu propia carga, calcula la factura con la calculadora de costes de LLM y consulta las tarifas actuales en la comparativa de precios de modelos.

Son cifras orientativas. En producción habrá llamadas concurrentes y ráfagas, y la distribución de longitud de los documentos recuperados dominará el cálculo.

Errores habituales en RAG y API

• ❌ No ordenes los fragmentos recuperados por una puntuación de relevancia dinámica. Cada solicitud producirá un prefijo distinto.
• ❌ No descartes los logs de uso al hacer streaming o perderás la atribución de costes. Envía stream_options={"include_usage": True} y guarda prompt_tokens_details.cached_tokens y usage.cost.
• ✅ En tareas batch, combina la caché con las Batch APIs del proveedor (OpenAI Batch, Anthropic Message Batches) para obtener otro descuento de aproximadamente el 50%. Esto se hace fuera del gateway, llamando directamente al proveedor.

Caso de uso 3: agentes de IA (razonamiento en varios pasos, uso de herramientas y cadenas largas)

Perfil de tráfico

• Una tarea de agente implica muchas llamadas al LLM intercaladas con resultados de herramientas.
• Contexto muy largo (sistema + herramientas + historial acumulado): normalmente 30K–100K tokens al llegar al paso 10.
• Prompts muy estructurados: prefijo estable largo y cola variable pequeña.
• Importan tanto la latencia como el coste. Cada segundo adicional de prefill añade una espera visible, y un agente de 15 pasos la multiplica por 15.

Por qué los agentes dependen de la caché

Cada paso añade la llamada y el resultado de una herramienta al paso anterior. Sin caché, cada paso vuelve a pagar el prefill de decenas de miles de tokens.

Step 1: [system: 5K] + [tools: 3K]
Step 2: [system: 5K] + [tools: 3K] + [call_1: 1K] + [result_1: 2K]
Step 3: [system: 5K] + [tools: 3K] + [call_1: 1K] + [result_1: 2K]
                                   + [call_2: 1K] + [result_2: 5K]
        ↑──── prefix grows monotonically — perfect for caching ────↑

Regla crítica: las llamadas y los resultados de las herramientas deben ser append-only e idénticos byte a byte entre pasos. Si los reescribes o reordenas, la caché queda invalidada desde ese punto. El fallo más habitual en agentes es «limpié el resultado de la herramienta antes de volver a enviarlo»: la tasa de aciertos cae a cero y tanto el coste como la latencia se multiplican.

Ajuste del TTL: el único caso de uso donde resulta crítico

Una tarea de agente suele durar entre 10 y 60 segundos; dentro de una sola tarea, el TTL predeterminado de 5 minutos basta. Sin embargo, los agentes que esperan aprobación humana («revisa este plan y responde») pueden quedarse inactivos durante varios minutos. Si la persona tarda 10 minutos y la caché ya se ha enfriado, el siguiente paso vuelve a pagar el prefill de 50K tokens. Para estos flujos, puedes:

• Usar un proveedor con un TTL más largo (deepseek-v4-flash fue el más duradero de las pruebas), o
• Enviar un ping keep-alive cada TTL/2 mientras esperas (consulta la Parte 3 §8.2).

Modelos recomendados para agentes

Los agentes necesitan capacidad de razonamiento. Elige primero por calidad y optimiza después el coste.

† El patrón de Claude con 4 marcadores cache_control sigue siendo la mejor configuración de caché para agentes: aplica descuentos acumulativos sobre el prefijo durante más de 10 pasos. Usa el SDK anthropic apuntando al gateway. La Parte 3 §2 muestra la estructura exacta del payload y las opciones de TTL.

Estimación de coste real: una tarea de agente de 15 pasos

Supongamos 5K de sistema + 3K de herramientas + unos 3K añadidos por paso, durante 15 pasos. Coste por llamada de la Parte 3 §6 escalado al patrón del agente:

De nuevo, son cifras orientativas. La variable principal es que el prefijo se mantenga realmente idéntico byte a byte entre pasos.

Errores habituales en agentes

• ❌ No reconstruyas la lista de mensajes en cada paso. Mantén el array idéntico byte a byte y limítate a añadir elementos.
• ❌ No recortes ni reformatees los resultados de las herramientas. Cualquier cambio de bytes invalida la caché posterior.
• ❌ No compartas una clave de caché entre instancias concurrentes de agentes. El orden de sus pasos acaba divergiendo y se contaminan entre sí.
• ✅ Monitoriza la proporción cache_creation_tokens : cache_read_tokens por tarea. En el paso 10, una proporción saludable es de 1:50 o mejor.

Matriz general de decisión

                            ┌─ Chinese-heavy ─→ deepseek-v4-flash + auto cache
                  ┌─ High ─→│
                  │          └─ Global users ──→ gpt-5.4-nano / claude-haiku-4-5
   Chatbot ──────→│
                  │          ┌─ Quality-first ─→ gpt-5.4-mini / claude-sonnet-4-5
                  └─ Mid ──→│
                            └─ Balanced ──────→ gemini-2.5-flash / qwen3-max

                            ┌─ Chinese RAG ───→ deepseek-v4-flash / qwen3-max
                  ┌─ Live ─→│
                  │          └─ English RAG ───→ gpt-5.4-mini / claude-sonnet-4-5†
   API ──────────→│
                  │          ┌─ Translation ───→ gpt-5.4-nano (template caches)
                  └─ Batch →│
                            └─ Doc review ────→ qwen3.5-flash + Batch APIs

                            ┌─ Simple ────────→ deepseek-v4-flash / qwen3-max
                  ┌─ China ─→│
                  │          └─ Complex ───────→ qwen3-max (plan) + deepseek (execute)
   Agent ────────→│
                  │          ┌─ Simple ────────→ gpt-5.4-mini + auto
                  └─ Global →│
                            └─ Complex ───────→ claude-sonnet-4-5† / gpt-5.5-pro

  † Claude with multi-`cache_control` breakpoints via the `anthropic` SDK pointed at the gateway (see Part 3 §2)

Referencia rápida de TTL por caso de uso

Qué hace este gateway y qué no

Para dejar claras las expectativas:

Si hoy necesitas alguna de las funciones de la columna derecha, impleméntala en la capa de aplicación o usa directamente el SDK del proveedor. El gateway es un proxy ligero con una capa de precios; toda la lógica de caché se ejecuta en la capa del modelo del proveedor.

Conclusión

Toda la serie se resume en cuatro líneas:

La caché aporta dos ventajas, no una. Coste Y latencia. Contenido estable al principio; contenido variable al final. Mantener bien el prefijo no cuesta nada: hazlo siempre. Ajusta el modelo y la caché al caso de uso. Chat ≠ RAG ≠ agentes. Mide con tu propio tráfico. Un benchmark de una sola ejecución es un punto de partida, no la respuesta.

El camino más rápido es elegir en la matriz el caso de uso que más se parezca al tuyo, aplicar los cambios estructurales —prefijo estable primero, recuperación determinista y estado del agente idéntico byte a byte—, registrar cached_tokens y usage.cost durante una semana y volver a evaluar.

Preguntas frecuentes

¿Cuál es el LLM más barato para un chatbot en chino? deepseek-v4-flash y qwen3.5-flash son un orden de magnitud más baratos que los modelos optimizados para inglés al procesar texto en chino dentro del conjunto probado, y alcanzan la calidad de gpt-5.4-mini en cargas de chat habituales.

¿Cuál es el mejor LLM para RAG en 2026? Para inglés, gpt-5.4-mini con la estructura de prompt de la solución A —tokens del sistema al principio y referencias al final— consigue una tasa de aciertos superior al 80% en la parte estable. Para chino, deepseek-v4-flash. Para documentos muy largos que se consultan a menudo, gemini-2.5-pro, que admite de forma nativa contextos de más de 1M tokens.

¿Debo usar GPT o Claude para agentes? Ambos ofrecen buen rendimiento. La elección depende de cuánto quieras invertir en optimizar la caché. El patrón de Claude con 4 marcadores cache_control —mediante el SDK anthropic conectado al gateway— es especialmente potente para los prefijos acumulativos de los agentes: una vez caliente el prefijo, reduce aproximadamente un 90% el coste de entrada durante más de 10 pasos. Si prefieres mantener el cliente con formato OpenAI y aceptar un ahorro de caché de aproximadamente el 50% sin marcadores, gpt-5.4-mini o gpt-5.5-pro requieren menos trabajo.

¿Cuánto puedo ahorrar realmente al pasar de un uso «ingenuo» a uno «optimizado» del LLM? En las ejecuciones medidas para esta serie: reducción de costes del 50–88% y reducción del TTFT del 30–60% con el mismo modelo. La mayor parte del ahorro procede de superar una tasa de aciertos del 80%, no de cambiar de modelo.

¿Por dónde empiezo? Elige en la matriz el caso de uso más parecido al tuyo. Aplica los cambios estructurales al prompt. Mide cached_tokens y usage.cost durante una semana de tráfico de producción. Solo entonces plantéate cambiar de modelo.

¿Cómo comparo los precios de las APIs de LLM entre proveedores? La página de modelos de Synthorai ofrece una comparativa de precios en tiempo real. Puedes filtrar por proveedor y ordenar por precio de entrada o salida por millón de tokens; los datos siempre coinciden con las tarifas vigentes del gateway. La matriz anterior te ayuda a elegir el tipo de modelo adecuado para tu caso de uso; la página de modelos indica cuánto cuesta hoy.

Fuentes y verificación: Mediciones de la Parte 3 §6, https://synthorai.io/v1 el 2026-05-25, SDK openai 2.38.0. Páginas de precios de los proveedores: OpenAI · Anthropic · Google Gemini · DeepSeek · Alibaba Bailian.

← Volver al blog