Caché de LLM de pesos abiertos: depende de la ruleta del proveedor

Con un modelo cerrado, la caché de prompts se rige por un único contrato documentado. Claude usa puntos de corte con cache_control; OpenAI y Gemini almacenan automáticamente en caché a partir de un mínimo de tokens; los descuentos están publicados y son estables. Basta con leer una página.

Con pesos abiertos, esa suposición deja de valer. Una docena de proveedores puede servir el mismo checkpoint de Qwen o Llama, y la caché no es una propiedad del modelo, sino del entorno donde se ejecuta. Para mostrar hasta dónde llega esta diferencia, medimos una misma solicitud: enviamos seis veces un prompt idéntico de unos 4.7K tokens al mismo modelo Qwen mediante un router multiproveedor, sin fijar el upstream.

Mismo modelo, mismo router y mismo prompt: el coste osciló entre $0.0141 y $0.000286, una diferencia de 49×, solo por el upstream elegido por el router y por si ese upstream ya tenía el prefijo caliente.

Resumen

• En modelos de pesos abiertos, la caché de prompts depende del routing, no es una función del modelo. El motor de inferencia la implementa de forma automática y gratuita, pero cualquiera de las capas superiores puede conservarla o romperla.
• Cinco capas: una aporta la caché y tres pueden romperla. El modelo (determina la capacidad de cacheo, pero no sirve ninguna caché) → el motor de inferencia (caché gratuita) → el proveedor de cómputo (la convierte en producto, con resultados desiguales) → el gateway (routing entre varios clústeres) → el router (dispersa las solicitudes entre proveedores con cachés independientes).
• Resultados medidos. Una solicitud idéntica, distribuida por un router, costó 49× más con una elección que con otra; para un mismo modelo, un proveedor ofreció un 59.6% de descuento y otro un 0%; los descuentos publicados por caché van del 0% a ~98% según el modelo.
• Qué hacer. Fija la ruta para que los prefijos repetidos lleguen a la misma caché caliente; audita la diferencia de coste, no el campo cached_tokens, que muchas veces muestra 0 incluso cuando hubo un hit real; evalúa la latencia por separado: los prefills calientes son entre 2 y 10 veces más rápidos incluso con un descuento de coste de ~0%.

Las cifras en vivo se midieron el 2026-06-14 contra un router multiproveedor y nuestro propio gateway, con un prompt fijo en inglés de unos 4.7K tokens, un max_tokens pequeño y ejecuciones secuenciales. Ese mismo día comprobamos los precios documentados en las fuentes primarias de cada proveedor y los contrastamos de forma adversarial. La parte extrapolable son las proporciones —porcentaje de descuento y cambio de latencia—; las cifras absolutas dependen de la plataforma, el prompt y la carga. Reproduce las pruebas antes de citar los datos.

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

Antes de entrar en las capas, aclaremos la terminología. Los proveedores de modelos de pesos abiertos usan cuatro modalidades de caché, cada una con una facturación distinta.

1. Caché automática de prefijos (sin marcadores). Es la modalidad dominante. El servidor calcula un hash del prefijo del prompt, reutiliza el estado KV si coincide con una solicitud anterior y aplica el descuento por su cuenta: no requiere cache_control ni cambios de código y, a menudo, no puede desactivarse. DeepSeek, Zhipu GLM y la mayoría de los proveedores de modelos de pesos abiertos funcionan así. Las escrituras son gratuitas; la caché puede durar desde unos minutos en VRAM hasta varias horas o días en disco. DeepSeek conserva los prefijos «entre unas horas y unos días».

2. Caché con puntos de corte explícitos (cache_control). Es el modelo de Anthropic, disponible también en algunos proveedores de pesos abiertos. Model Studio de Alibaba acepta "cache_control": {"type": "ephemeral"} en un bloque de mensaje de Qwen; algunas plataformas de serving exponen un marcador equivalente. Marcas el límite, pagas un recargo de escritura y, a cambio, obtienes un descuento de lectura mayor.

3. Objetos de caché alquilados (con coste de almacenamiento). Esta modalidad exige especial atención. En la familia antigua moonshot-v1 de Moonshot hay que ejecutar POST /v1/caching para crear una caché. Después se factura la escritura, una tarifa de almacenamiento por token y minuto y una tarifa por hit en cada llamada. La caché explícita de Gemini de Google sigue el mismo modelo: coste de entrada más almacenamiento, aproximadamente $1.00–$4.50 por 1M-tokens y hora. La caché es un recurso alquilado que debes eliminar cuando ya no lo necesites.

4. Reutilización de KV con self-hosting (gratuita). Si ejecutas los pesos por tu cuenta, el motor de inferencia almacena los prefijos en caché de forma automática y gratuita. No hay tarifa de escritura, lectura ni almacenamiento: un hit se limita a omitir el prefill.

Qwen ofrece en Model Studio los modos automático y explícito, con una contrapartida real: el modo implícito factura un hit al 20% del coste de entrada y no cobra las escrituras; el explícito factura el hit al 10% del coste de entrada, pero cobra el 125% por la escritura y limita la entrada a un TTL de 5 minutos. El descuento es mayor, pero pagas por llenar la caché y vuelves a pagar cada vez que caduca.

Dónde vive la caché dentro del stack

Esta es la idea central: en los modelos de pesos abiertos, la caché de prompts está resuelta en una sola capa y queda expuesta a romperse en todas las capas superiores. Recorre el stack desde los pesos hacia arriba y, en cada capa, pregunta si aporta la caché o se limita a reenviarla, y si puede romper lo que ya hizo la capa inferior.

  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: capacidad de cacheo, no una caché

Esta es la capa donde mucha gente cree que vive la caché —«DeepSeek tiene caché»—, así que conviene ser precisos desde el principio. Un checkpoint es un conjunto de pesos; ejecuta el mismo mecanismo de atención exista o no una caché KV. No incluye una caché, un descuento, un TTL ni un marcador cache_control: todo eso pertenece a la capa de serving. En sentido estricto, los pesos no proporcionan ningún producto de caché.

Los pesos, sin embargo, sí influyen. DeepSeek ilustra bien por qué. La arquitectura de atención del modelo determina el tamaño de la caché KV y, por tanto, hasta qué punto puede abaratarse el cacheo:

• Multi-head Latent Attention (MLA) de DeepSeek comprime la caché KV en una representación latente de bajo rango, hasta aproximadamente un 4–14% del tamaño de una caché multi-head convencional. Esta compresión permite que la API de DeepSeek conserve prefijos en disco y cobre la lectura de caché a ~2% del precio de entrada. La arquitectura es el facilitador; la caché en disco es un producto construido sobre ella.
• Grouped-Query Attention (GQA) —usado por Llama, Qwen, Mistral y DeepSeek— comparte las cabezas KV para reducir la caché según el factor de agrupación (≈8× en Llama-3).

La aportación de la capa 1 es, por tanto, la capacidad de cacheo, no la caché: la arquitectura fija el límite de cuánto pueden abaratarla las capas superiores, pero los pesos nunca sirven por sí mismos un token almacenado. La afirmación «DeepSeek tiene caché» mezcla dos cosas distintas con el mismo nombre: los pesos —esta capa, que aporta MLA— y la API y el stack de serving de DeepSeek —las capas 2 y 3, que aportan la caché en disco, el descuento y los campos de uso—. Si descargas los pesos abiertos y los ejecutas por tu cuenta, conservas la pequeña caché KV de MLA, pero el producto de caché en disco se queda en los servidores de DeepSeek. En su lugar, tendrás las capacidades de la capa 2 que despliegues. La conclusión operativa no cambia: deja de preguntar si un modelo usa caché y pregunta dónde se sirve. Eso no significa que la arquitectura sea irrelevante. La arquitectura fija el límite; la ruta determina lo que recibes.

Capa 2 — El motor de inferencia: donde se implementa la caché, gratis

En la siguiente capa, la caché no solo existe: está resuelta y es gratuita. Los motores de inferencia modernos almacenan prefijos automáticamente:

• vLLM — Automatic Prefix Caching: calcula el hash de cada bloque KV, reutiliza cualquier bloque cuyo hash de prefijo ya haya visto y aplica desalojo LRU. Está activado por defecto en V1.
• SGLang — RadixAttention: guarda la caché KV en un árbol radix para reutilizar cualquier prefijo compartido, con scheduling consciente de la caché.
• TensorRT-LLM — reutilización de bloques (enable_block_reuse, activada por defecto), con descarga opcional de bloques KV a la memoria del host.

Proyectos como LMCache llevan esta idea más lejos: descargan KV a CPU o disco y lo comparten entre instancias. Ahí está el germen de una solución al problema de routing que veremos a continuación. La conclusión es sencilla: con self-hosting, el problema está resuelto. La caché es automática, no cuesta nada más allá de las GPU que ya ejecutas, aplica desalojo LRU y te pertenece. Un hit simplemente omite el prefill, lo que reduce el TTFT y aumenta el throughput. No existe un campo de facturación cached_tokens porque no se factura nada; el beneficio aparece en tus propias métricas de latencia. Con un modelo cerrado alquilas la caché; con uno abierto puedes tenerla bajo tu control. La contrapartida es la inversa del entorno alojado: la caché es efímera —VRAM y LRU—, así que solo sobrevive mientras el prefijo siga caliente. Las capas superiores deben preservar precisamente eso.

Capa 3 — El proveedor de cómputo: convertirla en producto, con resultados desiguales

Los proveedores comerciales de inferencia envuelven la capa 2 y operan flotas de réplicas. Heredan una caché automática y gratuita. La cuestión es si la implementan bien, y los resultados varían en dos dimensiones.

En primer lugar, la exposición y el precio cambian radicalmente. Entre los principales proveedores de modelos de pesos abiertos, uno aplica un 50% fijo al input almacenado y excluye esos tokens de los rate limits; otro aplica por defecto un 50% de descuento en serverless; un tercero fija el precio del input cacheado por modelo —por ejemplo, un nivel de Qwen con ~80% de descuento— y expone una pista de cache key para mejorar la afinidad; un cuarto mantiene la caché siempre activa y no permite deshabilitarla en endpoints dedicados. El motor subyacente es el mismo, pero hay cuatro políticas de precios distintas.

En segundo lugar aparece el primer punto donde la caché se rompe: el problema de las múltiples réplicas. El prefijo caliente vive en la VRAM de la réplica que atendió la solicitud fría. El load balancer del proveedor puede enviar la siguiente solicitud a otra réplica con la caché fría. Vimos exactamente ese comportamiento al fijar el mismo modelo Qwen a un upstream cada vez y ejecutar una secuencia fría→caliente:

El proveedor A almacenó correctamente el prefijo y lo notificó. El proveedor B, que anuncia un precio de lectura de caché para este modelo, no aplicó ningún descuento entre una llamada fría y dos calientes durante nuestra prueba. Puede deberse a los requisitos de elegibilidad, a la distribución entre réplicas o a que necesite más de dos solicitudes para calentarse. El resultado medido en esta ruta fue cero. La capacidad está resuelta en la capa 2; recibirla de verdad depende de la ejecución en la capa 3, y cambia según el proveedor.

Capa 4 — El gateway: el problema de los múltiples clústeres

Un gateway se sitúa delante de uno o varios upstreams y convierte el problema de las réplicas en un problema de clústeres. Si distribuye solicitudes por round-robin entre clústeres o proveedores sin afinidad de caché, la caché caliente pasa a ser estructuralmente inaccesible: cada solicitud llega a un lugar donde el prefijo no existe. Un gateway consciente de la caché debe enrutar por el hash del prefijo para que los prefijos idénticos permanezcan asociados al mismo upstream, igual que la capa 2 los asocia a los mismos bloques KV. Esto se aplica tanto a software operado por tu equipo, como LiteLLM, como a un servicio alojado; LiteLLM frente a un gateway gestionado explica las contrapartidas operativas.

Ejecutamos una batería de pruebas fría→caliente con varios modelos de pesos abiertos en un gateway externo, leyendo directamente el cost de cada solicitud:

DeepSeek-V4 alcanzó un 97–99% —la afinidad funcionó de extremo a extremo—; qwen3.5-plus y qwen3-max ofrecieron ~0% en la llamada caliente, aunque el catálogo incluyera un precio de lectura de caché. La tabla muestra otras dos lecciones sobre gateways:

• El campo de uso engaña; el coste no. cached_tokens mostró 0 en todas las llamadas, incluidas las que redujeron el coste un 99%. Muchos gateways compatibles con OpenAI no rellenan el campo de tokens cacheados cuando el upstream usa caché automática. Audita la diferencia de cost entre una llamada fría y otra caliente, no el campo de tokens. Es la misma lección que al auditar las afirmaciones de un gateway sobre su caché.
• La latencia mejora aunque el coste no cambie. Todas las llamadas calientes fueron entre 2 y 10 veces más rápidas: qwen3.5-flash pasó de 10.2s→1.0s. Esto también ocurrió en los casos con ~0% de descuento. Un hit omite el prefill independientemente del precio fijado por el proveedor, así que la caché puede mejorar el TTFT aunque el gateway no reduzca la factura.

Un gateway que no preserve la afinidad te ofrece una caché a la que no puedes llegar; si tampoco muestra el coste de caché, te ofrece una caché que no puedes verificar.

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

En la capa superior, un router multiproveedor balancea un mismo ID de modelo entre clústeres de empresas distintas, cada uno con una caché independiente. Ni siquiera una afinidad perfecta dentro de un proveedor puede resolverlo: si la llamada 1 va a un proveedor y la 2 a otro, no existe una caché compartida que pueda producir un hit. Esta es la dispersión que vimos al principio del artículo y agrava el problema de la capa 4. Ya no hay solo varios clústeres, sino varios proveedores con estados de caché y precios distintos; la opción más cara facturó 20× la tarifa base del upstream más barato. La caché solo entró en juego cuando el routing se mantuvo por casualidad en el mismo proveedor.

La solución consiste en eliminar el azar: haz que el routing sea determinista para que los prefijos repetidos lleguen a 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,
    },
  })

El router sí informó de cached_tokens —4,224 en el hit— y del cost de cada solicitud, así que permite verificar ambos datos. En esto mejora al gateway de la capa 4, que mostraba 0. Pero debes restringir tú mismo el routing. La caché es un problema de routing presentado como una función de precios: es gratuita en la capa 2, mientras que las capas 3, 4 y 5 ofrecen tres formas cada vez más amplias de alejar las solicitudes de ella.

¿Hasta dónde llega el descuento? Depende por completo del proveedor

Cuando el routing sí coincide, ¿cuánto se ahorra? En los modelos cerrados, el descuento por lectura de caché suele rondar el 90%. En los de pesos abiertos, el precio publicado va desde un descuento testimonial hasta uno casi total, incluso dentro del catálogo de un mismo proveedor. Estas son las tarifas oficiales publicadas:

La caché automática en disco de DeepSeek ofrece el mayor descuento: deepseek-v4-flash lee el input cacheado a $0.0028/M frente a $0.14/M cuando hay miss, una relación de 1:50. Nuestra prueba de la capa 4 reprodujo un 97.9%. Los proveedores externos que sirven estos mismos pesos abiertos fijan de forma independiente el precio del input cacheado: algunos aplican un ~50% fijo y otros varían entre ~50% y ~90% según el modelo. El descuento depende del proveedor al que llegue la solicitud, no solo del modelo. La misma función presenta una diferencia de 48 puntos.

Como el descuento pertenece a la plataforma, un mismo modelo tiene una economía de caché distinta en cada lugar donde se sirve. deepseek-v4-pro, de cuatro formas:

«DeepSeek-V4-Pro admite caché» es cierto, pero apenas sirve para operar el sistema. La pregunta útil es: «¿admite caché dónde, a qué precio y cómo se informa del uso?».

Checklist para decidir

• ✅ El modelo fija el límite, no aporta la caché (capa 1). Su arquitectura de atención —MLA, GQA— determina cuánto puede abaratarse el cacheo, pero nunca sirve un token cacheado. Debes seguir preguntando dónde se sirve y qué hace el stack del proveedor.
• ✅ ¿Usas self-hosting? Ya la tienes gratis (capa 2). Confirma que la caché automática de prefijos esté activa —lo está por defecto en vLLM/SGLang— y monitoriza el hit rate de prefijos.
• ✅ En un proveedor de cómputo, verifica la entrega, no la columna de precios (capa 3). Un precio de lectura de caché es una afirmación comercial; mide la diferencia de coste entre una llamada fría y otra caliente. Usa una pista de afinidad basada en cache key si el proveedor la ofrece.
• ✅ Si pasas por un gateway, exige routing con afinidad de caché e información de costes (capa 4). Si los prefijos idénticos no permanecen en un upstream o el cost no baja en una llamada caliente, la caché es inaccesible o no puede verificarse.
• ✅ En un router, fija el upstream (capa 5). Restringe el routing —por ejemplo, con un campo de orden de proveedores y los fallbacks desactivados— o perderás los hits por el balanceo entre cachés independientes, además de arriesgarte a usar un upstream entre 20 y 50 veces más caro.
• ✅ Evalúa la latencia por separado del coste. Los prefills calientes son entre 2 y 10 veces más rápidos incluso cuando el descuento monetario es ~0.
• ✅ Presta atención a las cachés con tarifa de almacenamiento. Las cachés alquiladas —Moonshot moonshot-v1, Gemini explícito— facturan según el tiempo y la cantidad de tokens aunque estén inactivas; las cachés automáticas de prefijos no.

Conclusión

En los modelos cerrados, «¿usa caché?» tiene una sola respuesta. Para los pesos abiertos, la capacidad quedó resuelta hace años en la capa del motor de inferencia: vLLM y SGLang almacenan automáticamente todos los prefijos en caché y lo hacen gratis. Todas las capas superiores son infraestructura que conserva el hit o desvía la solicitud: el balanceador de réplicas del proveedor de cómputo, el routing entre clústeres del gateway y la distribución aleatoria del router entre proveedores. La arquitectura del modelo fija el límite de cuánto puede abaratarse la caché —MLA y GQA aportan ventajas reales en el propio modelo—, pero la ruta de la solicitud determina lo que recibes. Trata el comportamiento de la caché como una propiedad del routing: mídelo en términos de coste sobre la ruta exacta que usarás, fija esa ruta para que la solicitud llegue a la caché que has calentado y recuerda que el mayor descuento del mundo no sirve de nada si la segunda solicitud llega a un lugar por el que nunca pasó la primera.

Para entender por qué existe una caché KV y cómo funcionan los TTL, empieza por Cómo funcionan la caché KV y el TTL; para auditar las afirmaciones de un gateway sobre su caché, consulta ¿Miente tu gateway de LLM sobre la caché?.

Preguntas frecuentes

¿Los modelos de pesos abiertos admiten caché de prompts? Los pesos determinan cuánto puede abaratarse: arquitecturas de atención como MLA y GQA reducen la caché KV. Sin embargo, la propia caché, el descuento y la API proceden del stack de serving. El motor de inferencia —vLLM, SGLang, TensorRT-LLM— implementa la caché; los proveedores de cómputo la heredan; los gateways y routers la reenvían o dispersan. Sirve el mismo checkpoint en tres proveedores y puedes obtener caché automática gratuita, ninguna caché o solo caché explícita.

¿Por qué el mismo modelo costó 49× más en una llamada que en otra? En un router multiproveedor, una solicitud sin upstream fijado se balancea entre clústeres de distintos proveedores, con precios base y estados de caché diferentes. Una llamada llegó fría a un proveedor caro; otra llegó caliente a uno barato. Fija el upstream —restringe el orden de proveedores y desactiva los fallbacks— para controlar ambas variables.

Si uso self-hosting, ¿tengo que pagar por la caché? No. La caché automática de prefijos de vLLM, SGLang y TensorRT-LLM está activada por defecto y es gratuita: un hit simplemente omite el prefill. Solo pagas por las GPU que ya ejecutas, la caché te pertenece y se desaloja mediante LRU cuando hace falta VRAM.

La API muestra cached_tokens: 0, pero mi factura bajó. ¿Funcionó la caché? Probablemente sí. Muchos gateways no rellenan cached_tokens para upstreams con caché automática. Confía en el campo cost: una bajada considerable entre una llamada fría y otra caliente idéntica indica un hit de caché.

¿Qué modelo de pesos abiertos ofrece el mayor descuento de caché? La caché automática en disco de DeepSeek: deepseek-v4-flash lee el input cacheado a ~$0.0028/M frente a $0.14/M sin caché, un descuento de ~98%. En nuestras pruebas fría→caliente reproducimos un 97.9–99.2% en la gama V4. Muchos proveedores externos aplican en su lugar un ~50% fijo.

¿Tienen alguna contrapartida las cachés con tarifa de almacenamiento? Sí. La caché explícita de moonshot-v1 de Moonshot y la caché explícita de Gemini facturan por token y tiempo mientras se mantienen activas —Gemini cobra ~$1–4.50 / 1M-tokens / hora—. Una caché inactiva que olvides eliminar seguirá generando costes. Las cachés automáticas de prefijos no cobran almacenamiento.

Verificación: las cifras en vivo de coste y latencia se midieron el 2026-06-14 contra un router multiproveedor y nuestro propio gateway, con un prompt fijo de unos 4.7K tokens, un max_tokens pequeño y ejecuciones secuenciales fría→caliente; los descuentos se calcularon a partir del cost devuelto para cada solicitud. Ese mismo día comprobamos los precios y mecanismos de caché documentados en las fuentes primarias de los proveedores y los contrastamos de forma adversarial. Algunas cifras —sobre todo las tarifas de caché explícita de Moonshot— cambian con frecuencia: confirma los valores actuales antes de citarlos. Tus resultados variarán según el proveedor, el prompt, la región y la carga.

Fuentes

• DeepSeek — Precios
• DeepSeek — Guía de caché KV y caché de contexto
• Informe técnico de DeepSeek-V3 — MLA (compresión de la caché KV)
• GQA: entrenamiento de modelos Transformer Multi-Query generalizados (Ainslie et al.)
• Alibaba Cloud Model Studio — caché de contexto y precios
• Moonshot AI — Caché de contexto
• Zhipu / Z.AI — precios y caché
• vLLM — Caché automática de prefijos
• SGLang — RadixAttention y caché
• LMCache — descarga y uso compartido de caché KV
• Google — Caché de contexto de Gemini

Todo se comprobó el 2026-06-14. Esto no es asesoramiento financiero; verifica los precios actuales antes de tomar decisiones basadas en ellos.

← Volver al blog