Caché de LLM de Pesos Abiertos: Por Qué el Tuyo Es una Ruleta de Proveedores

Con un modelo cerrado, el caché de prompts es un contrato documentado. Claude tiene puntos de corte cache_control; OpenAI y Gemini cachean automáticamente por encima de un umbral de tokens; los descuentos están publicados y son estables. Lees una página y listo.

Los pesos abiertos rompen esa suposición. El mismo checkpoint de Qwen o Llama es servido por una docena de hosts, y el caché no es una propiedad del modelo — es una propiedad de dónde se ejecuta el modelo. Para mostrar hasta qué punto llega eso, aquí hay una solicitud medida — un prompt idéntico de ~4.700 tokens enviado al mismo modelo Qwen a través de un router multi-proveedor seis veces, sin upstream fijado:

Mismo modelo, mismo router, mismo prompt: la factura osciló entre $0.0141 y $0.000286 — una diferencia de 49× — puramente según qué upstream eligió el router y si ese upstream tenía el prefijo caliente.

Resumen

• El caché de prompts para modelos de pesos abiertos es un resultado del enrutamiento, no una característica del modelo. Se implementa — de forma gratuita y automática — en el motor de inferencia, y luego se preserva o destruye en cada capa superior.
• Cinco capas: una provee el caché, tres pueden romperlo. El modelo (establece la cacheabilidad, no sirve caché) → el motor de inferencia (caché, gratuito) → el host de cómputo (lo convierte en producto, de forma desigual) → el gateway (enrutamiento multi-clúster) → el router (dispersa entre proveedores con cachés disjuntos).
• Medido. Una solicitud idéntica, dispersada por un router, costó 49× más en una elección que en otra; en un modelo, un host entregó 59,6% de descuento y otro 0%; los descuentos de caché publicados abarcan 0% a ~98% entre modelos.
• Qué hacer. Fija tu ruta para que los prefijos repetidos lleguen al mismo caché caliente; audita por el delta de costo, no por el campo cached_tokens (que frecuentemente muestra 0 en un hit real); evalúa la latencia por separado — los prefills calientes son 2–10× más rápidos incluso con un descuento de costo de ~0%.

Las cifras en vivo fueron medidas el 2026-06-14 contra un router multi-proveedor y nuestro propio gateway, con un prompt fijo en inglés de ~4.700 tokens, max_tokens pequeño, ejecuciones secuenciales. Los precios documentados fueron verificados contra la documentación primaria de los proveedores el mismo día y validados de forma cruzada de manera adversarial. Los ratios (porcentaje de descuento, cambio de latencia) son la parte portable; los dólares absolutos dependen del proveedor, tu prompt y la carga. Reproduce antes de citar.

Los tipos de caché que encontrarás en la práctica

Antes del stack, el vocabulario. Entre los hosts de modelos de pesos abiertos existen cuatro formas distintas de caché, y cada una se factura de manera diferente.

1. Caché de prefijo automático (sin marcadores). El patrón dominante. El servidor calcula un hash del prefijo de tu prompt, reutiliza el estado KV si coincide con una solicitud anterior y aplica el descuento por su cuenta — sin cache_control, sin cambios en el código, y a menudo imposible de deshabilitar. DeepSeek, Zhipu GLM y la mayoría de los hosts de pesos abiertos funcionan así. Las escrituras son gratuitas; la caché puede vivir desde la VRAM (minutos) hasta el disco (DeepSeek mantiene los prefijos “unas pocas horas hasta unos pocos días”).

2. Caché con punto de corte explícito (cache_control). El esquema de Anthropic, que algunos hosts de pesos abiertos también ofrecen. El Model Studio de Alibaba acepta "cache_control": {"type": "ephemeral"} en un bloque de mensaje de Qwen; algunas plataformas de servicio exponen un marcador equivalente. Tú defines el límite, pagas un recargo por escritura y obtienes a cambio un descuento más profundo en la lectura.

3. Objetos de caché en alquiler (con tarifa de almacenamiento). El que hay que vigilar. La familia legacy moonshot-v1 de Moonshot te obliga a hacer POST /v1/caching para crear una caché, y luego cobra una tarifa de escritura, una tarifa de almacenamiento por token por minuto y una tarifa por llamada exitosa. El caché explícito de Gemini de Google sigue la misma idea — costo de entrada más almacenamiento a aproximadamente $1.00–$4.50 por 1M de tokens por hora. La caché es un recurso que alquilas y debes gestionar para liberar.

4. Reutilización de KV en autoalojamiento (gratuita). Ejecuta los pesos tú mismo y el motor de inferencia cachea de forma gratuita y automática. Sin tarifa de escritura, sin tasa de lectura, sin alquiler de almacenamiento — un acierto simplemente omite el prefill.

Qwen en Model Studio ofrece ambos modos, automático y explícito, con una compensación real: el modo implícito factura un acierto al 20% del input con escrituras gratuitas; el explícito factura un acierto al 10% del input, pero cobra el 125% en la escritura y limita la entrada a un TTL de 5 minutos. Descuento más profundo, pero pagas para poblar la caché y vuelves a pagar cada vez que expira.

Dónde vive el caché en el stack

Esta es la idea clave. El caché de prompts para pesos abiertos se resuelve en exactamente una capa y está en riesgo en cada capa superior. Recorre el stack desde los pesos hacia arriba y, en cada capa, pregúntate: ¿esta capa provee caché, o simplemente lo reenvía — y puede romper lo que la capa inferior ya hizo?

  request
     |
     v
  +--------------------------------------------------+
  | L5  router             scatters across vendors   |  can break it
  | L4  gateway            multi-cluster routing     |  can break it
  | L3  compute host       uneven delivery           |  can break it
  |==================================================|
  | L2  inference engine   CACHING LIVES HERE, free  |  <-- the cache is born here
  |==================================================|
  | L1  model              cacheability: MLA / GQA   |  sets the ceiling
  +--------------------------------------------------+

  A cache hit is born at L2 and must survive L3-L5 routing to reach you;
  every layer above L2 is a chance to land where your prefix isn't.

Capa 1 — El modelo: cacheabilidad, no una caché

Esta es la capa en la que la mayoría de la gente cree que vive el caché — “DeepSeek tiene caché” — así que es la primera sobre la que conviene ser preciso. Un checkpoint es un conjunto de pesos; ejecuta la misma atención independientemente de si existe una caché KV o no. No incluye ninguna caché, ningún descuento, ningún TTL, ningún marcador cache_control — esas son características de la capa de servicio. En ese sentido estricto, los pesos no proporcionan ningún producto de caché.

Pero los pesos no son neutrales, y DeepSeek es el ejemplo perfecto de por qué. La arquitectura de atención del modelo decide qué tan grande es la caché KV y, por tanto, qué tan barato puede llegar a ser el caché:

• La Multi-head Latent Attention (MLA) de DeepSeek comprime la caché KV en un latente de bajo rango — a aproximadamente el 4–14% de una caché multi-head estándar. Esa compresión es exactamente lo que permite que la API de DeepSeek persista prefijos en disco y fije el precio de una lectura de caché en ~2% del input. La arquitectura es el habilitador; la caché en disco es un producto construido sobre ella.
• La Grouped-Query Attention (GQA) — usada por Llama, Qwen, Mistral y DeepSeek — comparte cabezas KV para reducir la caché por el factor de grupo (≈8× en Llama-3).

Así que la contribución de la Capa 1 es cacheabilidad, no una caché: la arquitectura establece el techo de qué tan barato puede hacer el caché cada capa superior, pero los pesos nunca sirven un token cacheado por sí mismos. Y “DeepSeek tiene caché” fusiona silenciosamente dos cosas distintas que llevan el mismo nombre — los pesos (esta capa, que te dan MLA) y el stack de API y servicio de DeepSeek (Capas 2–3, que te dan la caché en disco, el descuento y los campos de uso). Descarga los pesos abiertos y ejecútalos tú mismo y conservas la pequeña caché KV de MLA, pero el producto de caché en disco se queda en los servidores de DeepSeek — heredas cualquier Capa 2 que despliegues en su lugar. Así que la conclusión operativa sigue siendo válida: deja de preguntar si un modelo cachea y empieza a preguntar dónde se sirve — solo no confundas eso con que la arquitectura no importe. Ella establece el techo; el camino determina lo que realmente obtienes.

Capa 2 — El motor de inferencia: donde se construye el caché, y es gratuito

Un nivel más arriba, el caché no solo está presente — está resuelto, y es gratuito. Los motores de inferencia modernos cachean prefijos automáticamente:

• vLLM — Automatic Prefix Caching: hashea cada bloque KV, reutiliza cualquier bloque cuyo hash de prefijo ya haya visto, desaloja por LRU. Activado por defecto en V1.
• SGLang — RadixAttention: almacena la caché KV en un árbol radix para que cualquier prefijo compartido sea reutilizado, con planificación consciente de la caché.
• TensorRT-LLM — reutilización de bloques (enable_block_reuse, activado por defecto), con descarga opcional de bloques KV a memoria del host.

Proyectos como LMCache extienden esto aún más — descargando KV a CPU/disco y compartiéndolo entre instancias, lo cual es la semilla para resolver el problema de enrutamiento que está por llegar. El punto: si te autoalojas, ya terminaste. El caché es automático, no cuesta nada más allá de las GPUs que ya ejecutas, desaloja por LRU, y tú lo posees — un hit simplemente omite el prefill, reduciendo el TTFT y aumentando el throughput. No existe un campo de facturación cached_tokens porque nada se factura; el beneficio aparece en tus propias métricas de latencia. Para un modelo cerrado alquilas el caché; para uno abierto puedes poseerlo por completo. La trampa es la inversa del mundo alojado: la caché es efímera (VRAM, LRU), por lo que sobrevive solo mientras el prefijo permanezca caliente — que es precisamente lo que las capas superiores deben preservar.

Capa 3 — El host de cómputo: productizándolo de forma desigual

Los hosts de inferencia comerciales envuelven la Capa 2 y ejecutan flotas de réplicas. Heredan el caché automático gratuito — la pregunta es si lo implementan bien, y la respuesta es mixta en dos ejes.

Primero, la exposición y el precio varían enormemente. Entre los principales hosts de modelos open-weight: uno aplica un 50% plano al input cacheado y permite que los tokens cacheados omitan los límites de tasa; otro aplica por defecto un 50% de descuento en serverless; un tercero cobra el input cacheado por modelo (p. ej., un nivel de Qwen con ~80% de descuento) y expone un hint de cache-key para mejorar la afinidad; un cuarto hace que el caché esté siempre activo y no sea revelable en endpoints dedicados. El mismo motor subyacente, cuatro filosofías de precios.

Segundo — y aquí es donde el caché falla por primera vez — el problema de las múltiples réplicas. Tu prefijo caliente vive en la VRAM de la única réplica que atendió la solicitud fría. El propio balanceador de carga del host puede enviar tu siguiente solicitud a una réplica diferente con el caché frío. Observamos exactamente esto: fijando el mismo modelo Qwen a un upstream a la vez y ejecutando frío→caliente:

El Proveedor A cacheó correctamente y lo reportó. El Proveedor B — que anuncia un precio de lectura de caché para este modelo — no devolvió ningún descuento en una llamada fría y dos llamadas calientes en nuestra prueba. Ya sea por elegibilidad, distribución entre réplicas o un calentamiento más largo que dos solicitudes, el resultado medido en este camino fue cero. La capacidad está resuelta en la Capa 2; si realmente la recibes es un detalle de ejecución de la Capa 3, y difiere según el host.

Capa 4 — El gateway: el problema multi-clúster

Un gateway se sitúa frente a uno o más upstreams y multiplica el problema de las réplicas en un problema de clúster. Si distribuye las solicitudes en round-robin entre clústeres o proveedores sin afinidad de caché, la caché caliente se vuelve estructuralmente inalcanzable — cada solicitud aterriza en un lugar donde el prefijo no existe. Un gateway con conciencia de caché debe enrutar por hash de prefijo para que los prefijos idénticos se dirijan siempre al mismo upstream, de la misma manera que la Capa 2 los fija a los mismos bloques KV.

Ejecutamos una batería frío→caliente sobre modelos de pesos abiertos en un gateway de terceros, leyendo el cost por solicitud directamente:

DeepSeek-V4 alcanzó un 97–99% (afinidad funcionando de extremo a extremo); qwen3.5-plus y qwen3-max devolvieron ~0% en la llamada caliente a pesar de tener un precio de lectura de caché en el catálogo. Dos lecciones más sobre gateways se esconden en esta tabla:

• El campo usage miente; el cost no. cached_tokens devolvió 0 en cada llamada aquí, incluyendo las caídas de coste del 99%. Muchos gateways compatibles con OpenAI no rellenan el campo de tokens en caché para upstreams que cachean automáticamente. Audita por el delta de cost entre una llamada fría y una caliente, no por el campo de tokens — la misma lección que auditar las afirmaciones de caché de un gateway.
• La latencia mejora incluso cuando el coste no lo hace. Cada llamada caliente fue 2–10× más rápida — qwen3.5-flash pasó de 10.2s a 1.0s — incluyendo las que tienen ~0% de descuento. Un acierto omite el prefill independientemente de cómo lo facture el proveedor, por lo que el cacheo puede ser rentable en TTFT en un gateway que no te da nada en la factura.

Un gateway que no preserva la afinidad te entrega una caché a la que no puedes acceder; uno que no expone el coste de caché te entrega una que no puedes verificar.

Capa 5 — El enrutador: distribución aleatoria entre proveedores

En la cima, un enrutador multi-proveedor balancea la carga de un mismo ID de modelo entre clústeres de diferentes empresas — cada uno con una caché separada. Ahora ni siquiera la afinidad perfecta dentro de un proveedor puede salvarte: si la llamada 1 va a un proveedor y la llamada 2 a otro, no hay caché compartida que pueda ser aprovechada. Esta es la dispersión mencionada al inicio de este artículo, y se suma a la Capa 4 — no solo múltiples clústeres, sino múltiples proveedores con estado de caché disjunto y precios disjuntos (la opción más cara facturada a 20× la tarifa base del upstream más barato). La caché solo se activaba cuando el enrutamiento casualmente se mantenía en un mismo proveedor.

La solución es eliminar la aleatoriedad — hacer que el enrutamiento sea determinista para que los prefijos repetidos aterricen siempre en la misma caché caliente:

# Pin the upstream; otherwise load-balancing scatters you across disjoint caches.
# (field names follow a common multi-provider router's API)
import requests

requests.post(f"{ROUTER_BASE}/chat/completions",
  headers={"Authorization": f"Bearer {API_KEY}"},
  json={
    "model": "qwen/qwen3.5-35b-a3b",
    "messages": messages,
    "usage": {"include": True},              # return cost + cached_tokens
    "provider": {                            # the part that makes caching work
        "order": ["<your-chosen-upstream>"],
        "allow_fallbacks": False,
    },
  })

En su favor, el enrutador sí reportó cached_tokens (4.224 en el acierto) y un cost por solicitud, por lo que puedes verificar ambos — mejor que el gateway de la Capa 4 que devolvía 0. Pero el enrutamiento es tuyo para restringir. El caché es un problema de enrutamiento disfrazado de característica de precios: la caché es gratuita en la Capa 2, y las Capas 3, 4 y 5 son tres formas escaladas de enrutarte lejos de ella.

¿Qué tan profundo es el descuento? Varía enormemente

Cuando el enrutamiento sí se alinea, ¿cuánto ahorras? Para modelos cerrados, el descuento en lecturas de caché se agrupa cerca del 90%. Para pesos abiertos, el precio publicado de lectura de caché va desde un gesto simbólico hasta casi total, incluso dentro de la oferta de un mismo proveedor. Tarifas publicadas de primera parte:

La caché de disco automática de DeepSeek es la más profunda del sector — deepseek-v4-flash lee la entrada en caché a $0.0028/M frente a un fallo de $0.14/M, una relación de 1:50, que nuestra prueba de Capa 4 reprodujo al 97,9%. Los hosts de terceros de estos mismos pesos abiertos fijan el precio de la entrada en caché de forma independiente — algunos aplican un ~50% fijo, otros varían por modelo entre ~50% y ~90% — por lo que el descuento que obtienes depende del host en el que aterrices, no solo del modelo. El mismo nombre de característica, una diferencia de 48 puntos.

Dado que el descuento es una propiedad del proveedor, un mismo modelo tiene diferentes economías de caché en cada lugar donde se sirve. deepseek-v4-pro, de cuatro maneras:

“DeepSeek-V4-Pro soporta caché” es verdad y casi inútil; la pregunta operativa es “soporta caché dónde, a qué tasa, reportado cómo.”

Una lista de verificación para tomar decisiones

• ✅ El modelo establece el techo, no la caché (Capa 1). Su arquitectura de atención (MLA, GQA) decide qué tan barato puede ser el almacenamiento en caché, pero nunca sirve un token cacheado — así que sigue preguntando dónde se sirve y qué hace el stack de ese host.
• ✅ ¿Auto-hospedaje? Ya lo tienes gratis (Capa 2). Confirma que el prefix caching automático esté activado (lo está por defecto en vLLM/SGLang) y monitorea tu tasa de aciertos de prefijo.
• ✅ En un host de cómputo, verifica la entrega, no la columna de precios (Capa 3). Un precio de lectura de caché es una afirmación; mide el delta de costo frío→caliente. Usa una pista de afinidad de cache-key donde el host la ofrezca.
• ✅ A través de un gateway, exige enrutamiento con afinidad de caché e informes de costos (Capa 4). Si prefijos idénticos no se fijan a un upstream, o cost no baja en una llamada caliente, la caché es inalcanzable o inverificable.
• ✅ En un router, fija el upstream (Capa 5). Restringe el enrutamiento (p. ej., un campo de orden de proveedor con fallbacks desactivados), o perderás aciertos por balanceo de carga entre cachés disjuntas — y arriesgas un upstream entre 20 y 50× más caro.
• ✅ Evalúa la latencia por separado del costo. Los prefills calientes son entre 2 y 10× más rápidos incluso cuando el descuento en dinero es ~0.
• ✅ Presta atención a los tipos de caché con tarifa de almacenamiento. Las cachés rentadas (Moonshot moonshot-v1, Gemini explícita) cobran por token-tiempo para una caché inactiva; las cachés de prefijo automáticas no lo hacen.

Conclusión

Para modelos cerrados, “¿tiene caché?” tiene una sola respuesta. Para pesos abiertos, la capacidad se resolvió hace años en la capa del motor de inferencia — vLLM y SGLang cachean cada prefijo, gratis, automáticamente. Todo lo que está por encima de esa capa es plomería que o bien preserva el acierto o te aleja de él: el balanceador de réplicas de un host de cómputo, el enrutamiento de clúster de un gateway, la distribución aleatoria de un router entre proveedores. La arquitectura del modelo establece el techo de qué tan barato puede ser el almacenamiento en caché — MLA y GQA son ganancias reales a nivel de modelo — pero el camino que toma tu solicitud decide lo que realmente obtienes. Trata el comportamiento de la caché como una propiedad de enrutamiento — mídelo en términos de costo en la ruta exacta que vas a usar, fija la ruta para que la caché que calentaste sea la que impactas, y recuerda que el descuento más profundo del mundo no vale nada si la segunda solicitud llega a un lugar que la primera nunca tocó.

Para entender la mecánica de por qué existe una KV cache y cómo funcionan los TTL, comienza con How KV Cache & TTL Work; para auditar las afirmaciones de caché de un gateway, consulta Does Your LLM Gateway Lie About Cache?.

Preguntas frecuentes

¿Los modelos de pesos abiertos admiten caché de prompts? Los pesos determinan cuán económico puede ser el almacenamiento en caché — las arquitecturas de atención como MLA y GQA reducen el KV cache — pero la caché en sí, el descuento y la API provienen de la capa de servicio. El almacenamiento en caché se implementa en el motor de inferencia (vLLM, SGLang, TensorRT-LLM), lo heredan los hosts de cómputo y lo reenvían (o dispersan) los gateways y routers. Despliega el mismo checkpoint en tres hosts y puedes obtener caché automático gratuito, ninguno, o solo explícito.

¿Por qué el mismo modelo costó 49× más en una llamada que en otra? En un router multi-proveedor, una solicitud sin fijar se balancea entre clústeres de distintos proveedores con precios base diferentes y estado de caché disjunto. Una llamada llegó a un proveedor costoso en frío; otra llegó a uno barato en caliente. Fija el upstream (restringe el orden de proveedores, desactiva los fallbacks) para controlar ambos factores.

Si me auto-hospedo, ¿necesito pagar por el almacenamiento en caché? No. El caché automático de prefijos en vLLM, SGLang y TensorRT-LLM está activado por defecto y es gratuito — un acierto simplemente omite el prefill. Solo pagas por las GPUs que ya ejecutas, y la caché es tuya, desalojada por LRU cuando se necesita VRAM.

La API indica cached_tokens: 0 pero mi factura bajó — ¿funcionó el caché? Probablemente sí. Muchos gateways no rellenan cached_tokens para upstreams que almacenan en caché automáticamente. Confía en el campo cost: una caída grande entre una llamada en frío y una idéntica en caliente significa que hubo un acierto de caché.

¿Qué modelo de pesos abiertos tiene el mayor descuento de caché? El caché automático en disco de DeepSeek: deepseek-v4-flash lee la entrada en caché a ~$0.0028/M frente a $0.14/M sin caché (~98% de descuento), reproducido entre 97.9–99.2% en toda la línea V4 en nuestras pruebas frío→caliente. Muchos hosts de terceros aplican un ~50% fijo en su lugar.

¿Hay alguna trampa con los cachés que cobran tarifa de almacenamiento? Sí — el caché explícito moonshot-v1 de Moonshot y el caché explícito de Gemini facturan por token-tiempo para mantener la caché activa (Gemini ~$1–4.50 / 1M-tokens / hora). Una caché inactiva que olvidaste eliminar sigue generando cargos. Los cachés automáticos de prefijos no tienen tarifa de almacenamiento.

Verificación: las cifras de costo/latencia en vivo se midieron el 2026-06-14 contra un router multi-proveedor y nuestro propio gateway, usando un prompt fijo de ~4.7K tokens, max_tokens pequeño, ejecuciones secuenciales frío→caliente; los descuentos se calcularon a partir del cost por solicitud devuelto. Los precios documentados y la mecánica de caché se verificaron contra la documentación primaria de los proveedores el mismo día y se comprobaron de forma adversarial; algunas cifras de proveedores (en particular las tarifas de caché explícito de Moonshot) cambian con frecuencia — confirma los valores actuales antes de citarlos. Tus cifras variarán según el proveedor, el prompt, la región y la carga.

Fuentes

• DeepSeek — Pricing
• DeepSeek — KV cache / Context Caching guide
• DeepSeek-V3 Technical Report — MLA (KV-cache compression)
• GQA: Training Generalized Multi-Query Transformer Models (Ainslie et al.)
• Alibaba Cloud Model Studio — context cache & pricing
• Moonshot AI — Context Caching
• Zhipu / Z.AI — pricing & caching
• vLLM — Automatic Prefix Caching
• SGLang — RadixAttention / cache
• LMCache — KV cache offloading & sharing
• Google — Gemini context caching

Todo verificado el 2026-06-14. No constituye asesoramiento financiero; verifica los precios actuales antes de basarte en ellos.

← Volver al blog