Caché de prompts LLM #4: el mejor modelo para chat, RAG y agentes

TL;DR — Elegir el «mejor» LLM no es una sola pregunta de benchmark: depende de si vas a desplegar un chatbot, una API de RAG/batch o un agente de IA. Cada forma tiene una estructura de prompt, un perfil de tasa de aciertos, una idoneidad de TTL y una tolerancia a la latencia diferentes, lo que dicta un emparejamiento óptimo distinto de modelo + estrategia de caché. Esta guía se apoya en las cifras medidas en la Parte 3 — la misma pasarela, el mismo SDK de OpenAI, cambiando solo el campo model en cada llamada.

Serie: Parte 4 de 4 · Anteriormente: Parte 1 — Principios de la caché · Parte 2 — Comparación y evaluación de proveedores · Parte 3 — Tutorial de código funcional

0. La fórmula universal de coste

Antes de adentrarnos en los casos de uso, esta es la ecuación que toda decisión debería optimizar:

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

Cuatro palancas:

1. Bajar el precio unitario (P_in / P_out) → elegir un modelo más barato.
2. Subir la tasa de aciertos → reestructurar tu prompt; ajustar el TTL a la cadencia de tu tráfico.
3. Bajar el coeficiente de descuento de la caché → elegir un proveedor con una caché más potente.
4. Elegir un proveedor cuyo prefill en caché sea el más rápido → la latencia importa para la UX.

Cada caso de uso a continuación acciona estas palancas de forma diferente.

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

Perfil de tráfico

• Cada petición = prompt de sistema largo (persona + conocimiento + reglas) + historial multiturno + nuevo mensaje del usuario.
• Contexto medio: 4K–20K tokens.
• Los usuarios son extremadamente sensibles al tiempo hasta el primer token (>2 s da sensación de que está roto).
• Dentro de una sesión, las peticiones llegan con segundos o minutos de diferencia — holgadamente dentro del TTL de caché de cualquier proveedor.

Por qué el chat se cachea casi por sí solo

El chat es la carga de trabajo más propicia para la caché. Dentro de una sola 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 los intervalos entre mensajes se mantienen por debajo del TTL (unos minutos en todos los proveedores), la parte del prompt de sistema supera el 90 % de tasa de aciertos sin esfuerzo. No necesitas keep-alives.

Recomendaciones de modelos (medido 2026-05)

* Medido contra un prompt de sistema estable de 7.300 tokens, una sola ejecución secuencial, sin carga concurrente. Consulta la Parte 3 §6 para la tabla completa.

Código de producción mínimo

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
        ],
    )

Eso es todo. La caché es automática para todos los modelos listados arriba; no se requiere ningún marcador. Lee resp.usage.prompt_tokens_details.cached_tokens para confirmar los aciertos durante el desarrollo.

Errores comunes en chatbots

• ❌ No incrustes la marca de tiempo actual en el prompt de sistema ("Today is 2026-05-25 14:30:25"). La precisión al segundo invalida toda la caché.
• ❌ No vuelvas a recomponer el historial en cada turno — mantén el orden del array de mensajes idéntico byte a byte y en modo append-only.
• ✅ Pon los datos de persona del usuario en el primer mensaje del usuario, no en el prompt de sistema — así la variación por usuario no envenena el prefijo compartido.
• ✅ Para sesiones que se enfrían más allá del TTL, 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 trabajo de API (RAG, generación de contenido, procesamiento por lotes)

Perfil de tráfico

• Q&A de RAG: entrada = sistema estable + documentos recuperados variables + consulta variable.
• Generación de contenido (textos de marketing, código, traducción): plantilla estable, datos variables.
• Procesamiento por lotes (clasificación de documentos, limpieza de datos): la misma tarea a gran volumen.
• La latencia es secundaria; el coste por llamada domina.

El problema difícil: la recuperación reordena tu prefijo

El problema central de caché del RAG: los documentos recuperados cambian entre llamadas, rompiendo el prefijo a 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 ─────────↑

Tres correcciones, en complejidad creciente:

Corrección A — Empuja los documentos recuperados hacia atrás, no hacia delante.

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 system (los ~3,5K tokens estables) se cachea. Solo la parte de cara al usuario falla en cada llamada. Esto basta para la mayoría de RAG en producción. Tasa de aciertos medida en este patrón con gpt-5.4-mini: más del 80 % en los tokens de sistema.

Corrección B — Orden de recuperación determinista. Ordena los chunks recuperados por una clave estable (doc_id ascendente) en lugar de por la puntuación de relevancia. Los chunks de alta frecuencia se mantienen en posiciones consistentes y el prefijo coincide más a menudo. Cuesta una pequeña pérdida de precisión en el ranker; normalmente irrelevante.

Corrección C — Marcadores de caché explícitos nativos vía SDK directos del proveedor. Si estás directamente sobre Anthropic Claude (no a través de esta pasarela), el patrón multi-cache_control permite cachear «nunca cambia» + «rara vez cambia» + «cambia por tarea» como puntos de ruptura separados. Excelente para RAG complejos cuando puedes cargar un SDK adicional.

Consideraciones de TTL para cargas de trabajo de API

• Tráfico continuo (endpoint de RAG 24/7): los TTL de 5 min funcionan bien — siempre hay una siguiente petición dentro de la ventana.
• A ráfagas / cron (batch diario a las 09:00): usa un proveedor con TTL largo (deepseek-v4-flash es el más longevo de nuestro conjunto de pruebas) o ejecuta un ping keep-alive de 1 token cada TTL/2 durante la ventana de ejecución. Patrón en la Parte 3 §8.2.

Recomendaciones de modelos por tarea

† Los marcadores multi-cache_control de Claude no tienen rival para RAG por capas — usa el SDK anthropic apuntando a la pasarela, consulta la Parte 3 §2.

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

3K de sistema + 5K de documentos recuperados + consulta de 200 tokens + salida de 300 tokens. Las cifras están escaladas a partir de los costes por llamada única medidos en la Parte 3 §6 — single-tenant, sin carga concurrente.

Trátalo como orden de magnitud. La producción real tiene llamadas concurrentes, ráfagas, y la distribución de la longitud de tus documentos recuperados dominará el cálculo.

Errores comunes de RAG / API

• ❌ No ordenes los chunks recuperados por puntuación de relevancia dinámica — cada petición obtiene un prefijo único.
• ❌ No pierdas los logs de uso al hacer streaming — tu atribución de costes se desmorona. Pasa stream_options={"include_usage": True} y almacena prompt_tokens_details.cached_tokens y usage.cost.
• ✅ Para tareas por lotes, apila las Batch API de los proveedores (OpenAI Batch, Anthropic Message Batches) sobre la caché para otro ~50 % de descuento — fuera de esta pasarela, llamando al proveedor directamente.

Caso de uso 3: agentes de IA (razonamiento multipaso, uso de herramientas, cadenas largas)

Perfil de tráfico

• Una tarea de agente = muchas llamadas LLM, intercaladas con resultados de herramientas.
• Contexto muy largo (sistema + herramientas + historial acumulado): típicamente 30K–100K tokens en el paso 10.
• Prompts muy estructurados: prefijo estable largo, pequeña cola variable.
• Tanto la latencia como el coste importan — cada segundo extra de prefill añade una espera visible, y un agente de 15 pasos lo multiplica por 15.

Por qué los agentes dependen de la caché

Cada paso se añade a la llamada de herramienta y al resultado del paso anterior. Sin caché, cada paso vuelve a pagar el prefill sobre 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 de herramientas y sus resultados deben ser append-only e idénticos byte a byte a lo largo de los pasos. Cualquier reescritura o reordenación mata la caché a partir de ese punto. El bug de agente más común con diferencia es «limpié el resultado de la herramienta antes de reenviarlo» → la tasa de caché cae a cero → el coste y la latencia se multiplican.

Ajuste de TTL — el único caso de uso donde importa

Una tarea de agente típica dura de 10 a 60 segundos; dentro de una sola tarea, los TTL por defecto de 5 min están bien. Pero los agentes que esperan una aprobación humana («revisa este plan y responde») pueden quedarse inactivos durante minutos. Si el humano hace una pausa de 10 minutos y la caché se ha enfriado, tu paso siguiente vuelve a pagar el prefill sobre 50K tokens. Para esos flujos de trabajo, o bien:

• Usa un proveedor con TTL más largo (deepseek-v4-flash es el más longevo de nuestro conjunto de pruebas), o bien
• Envía un ping keep-alive cada TTL/2 mientras esperas (consulta la Parte 3 §8.2).

Recomendaciones de modelos para agentes

Los agentes exigen capacidad de razonamiento — elige primero por calidad y luego optimiza el coste.

† El patrón de 4 marcadores cache_control de Claude sigue siendo la configuración más fuerte para la caché de agentes (descuento acumulativo de prefijo a lo largo de más de 10 pasos). Usa el SDK anthropic apuntando a la pasarela — consulta la Parte 3 §2 para la forma exacta del payload y las opciones de TTL.

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

Supón 5K de sistema + 3K de herramientas + ~3K añadidos por paso, 15 pasos en total. Coste por llamada de la Parte 3 §6 escalado a la forma del agente:

Una vez más, cifras orientativas. La variable dominante es si realmente mantienes el prefijo idéntico byte a byte de un paso a otro.

Errores comunes de agentes

• ❌ No reconstruyas la lista de mensajes en cada paso — mantén el array idéntico byte a byte, solo añadiendo.
• ❌ No recortes ni reformatees los resultados de herramientas — cualquier cambio de byte invalida la caché aguas abajo.
• ❌ No compartas una clave de caché entre instancias de agentes concurrentes — sus secuencias de pasos divergen y se contaminan entre sí.
• ✅ Monitoriza cache_creation_tokens : cache_read_tokens por tarea — una proporción saludable es 1:50 o mejor en el paso 10.

La matriz maestra 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 y qué no hace esta pasarela

Para fijar las expectativas con honestidad:

Si hoy necesitas alguno de los elementos del lado derecho, hazlo en tu capa de aplicación o directamente contra el SDK del proveedor. La pasarela es un proxy ligero más una capa de precios; todo lo relacionado con la caché ocurre en la capa del modelo, upstream.

Conclusión final

La serie de cuatro partes se condensa en cuatro líneas:

La caché aporta dos victorias, no una. Coste Y latencia. Contenido estable primero, contenido volátil al final. La disciplina de prefijo es gratis, aplícala en todas partes. Ajusta modelo + comportamiento de caché al caso de uso. Chat ≠ RAG ≠ Agentes. Mide sobre tu propio tráfico. Los benchmarks de una sola ejecución son un punto de partida, no la respuesta.

El camino más rápido desde aquí: elige de la matriz anterior el caso de uso más cercano al tuyo, aplica los cambios estructurales (prefijo estable primero, recuperación determinista, estado de agente idéntico byte a byte), registra cached_tokens y usage.cost durante una semana, y luego reevalúa.

Preguntas frecuentes

¿Qué LLM es el más barato para un chatbot en idioma chino? deepseek-v4-flash y qwen3.5-flash son un orden de magnitud más baratos que los modelos afinados para inglés en texto en chino dentro de nuestro conjunto de pruebas, igualando a gpt-5.4-mini en calidad en cargas de chat típicas.

¿Cuál es el mejor LLM para RAG en 2026? Para inglés: gpt-5.4-mini con la disposición de prompt de la Corrección A (tokens de sistema al frente, referencias abajo) da más del 80 % de tasa de aciertos en la porción estable. Para chino: deepseek-v4-flash. Para documentos muy largos consultados con frecuencia: gemini-2.5-pro (maneja de forma nativa contextos de más de 1 millón de tokens).

¿Debería usar GPT o Claude para agentes? Ambos son sólidos; la elección depende de cuánta disciplina de caché quieras invertir. El patrón de 4 marcadores cache_control de Claude (vía el SDK anthropic contra la pasarela) es excepcionalmente potente para prefijos acumulativos de agentes — ~90 % de reducción del coste de entrada una vez que el prefijo está caliente, a lo largo de más de 10 pasos. Si prefieres quedarte con el cliente con forma de OpenAI y aceptar ~50 % de ahorro en caché sin ningún marcador, gpt-5.4-mini o gpt-5.5-pro es la opción de menor fricción.

¿Cuánto puedo ahorrar de forma realista pasando de un uso «ingenuo» a uno «optimizado» del LLM? En las ejecuciones medidas en esta serie: 50–88 % de reducción de coste y 30–60 % de reducción de TTFT con el mismo modelo. La mayor parte de la victoria viene de llevar tu tasa de aciertos por encima del 80 %, no de elegir un modelo diferente.

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

Fuentes y verificación: cifras medidas 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