Deriva de proveedor: cómo el enrutamiento por defecto infla el coste de los LLM

Activaste el almacenamiento en caché de prompts, el contador de aciertos sube de vez en cuando, pero tu factura apenas se movió. Antes de culpar a la estructura de tu prompt, mira algo que el panel oculta: qué upstream sirvió realmente cada solicitud.

Los gateways multiproveedor reparten un solo modelo entre varios proveedores upstream y eligen uno por solicitud. Las cachés de prompts son por proveedor (a menudo por nodo dentro de un proveedor). Así que cuando tu segunda solicitud idéntica aterriza en un upstream distinto al de la primera, es un fallo de caché, aunque tu prompt no haya cambiado ni un byte. Esto es la deriva de proveedor (provider drift), y en un modelo de pago por token multiplica silenciosamente tu coste.

Las dos condiciones que la desencadenan

Esto no es una mala configuración que elegiste. Es lo que obtienes de fábrica:

1. Enrutamiento automático por defecto. La solicitud se envía al modelo sin fijar un upstream, así que el gateway elige uno por llamada.
2. Orden de proveedores por defecto = “default (balanced)”. El gateway balancea la carga entre los upstreams elegibles en lugar de quedarse con uno.

Ambos son los valores de fábrica. No tienes que tocar nada para tener deriva; tienes que tocar la configuración para evitarla.

Cómo se ven 20 solicitudes idénticas

Enviamos el mismo prefijo de ~8K tokens 20 veces seguidas a un popular gateway multiproveedor, con los valores por defecto anteriores, pidiendo cada vez los campos de proveedor y caché reportados por el propio upstream. Para un modelo con caché en disco de la familia DeepSeek:

• 9 upstreams distintos sirvieron las 20 llamadas: N***a, S***w, M***h, D***a, A***L, P***l, S***e, V***e, A***d.
• Tasa de aciertos de caché: 4/20 (20%). Solo aciertas en las llamadas que casualmente aterrizaron en un upstream que ya había cacheado tu prefijo.

Ejecuta las mismas 20 llamadas contra un gateway de backend único (un modelo, un upstream, sin balanceo) y la tasa de aciertos es 19/20 (95%) con la carga de trabajo idéntica. Mismo modelo, mismo prompt, mismo número de llamadas. La única variable es si el enrutamiento deriva.

Como contraste, en ese mismo gateway multiproveedor un modelo de clase GPT fue enrutado a un upstream (A***e) en las 20 llamadas y acertó 19/20. La deriva no es uniforme; afecta a cualquier modelo que el gateway resulte repartir, y en esta ejecución fue el modelo de la familia DeepSeek.

Conclusión A: el coste que esperabas vs el coste que pagaste

El coste por llamada en el modelo con deriva se separa limpiamente según el resultado de caché:

Un fallo cuesta unas 4x un acierto en este modelo (sobre tokens de entrada brutos, la diferencia publicada es aún mayor, aproximadamente 50x). Ahora súmalo a lo largo de las 20 llamadas:

Mismo modelo, mismo prompt, mismas 20 solicitudes. La deriva de proveedor hizo que la ejecución costara ~3.9x más. El almacenamiento en caché estuvo “activado” todo el tiempo; la capa de enrutamiento simplemente facturó la mayoría de tus tokens a la tarifa de fallo. Escala eso a un endpoint de producción que reproduce un gran prefijo estable todo el día y la diferencia es el grueso de tu gasto en entrada.

Conclusión B: sin caché tampoco hay ganancia de latencia

El almacenamiento en caché no es solo una palanca de coste. Un prefill caliente devuelve el primer token antes. Cuando la deriva te niega la caché, también pierdes esa aceleración. Medimos el tiempo hasta el primer token (TTFT) en llamadas idénticas repetidas:

Modelo de clase GPT (enrutado a un upstream consistente, caché alcanzable):

El almacenamiento en caché compra aproximadamente un 36% de primer token más rápido, y es estable: cada llamada en caliente cae en una banda estrecha.

Modelo de la familia DeepSeek (deriva por defecto, caché rara vez alcanzable):

• Aciertos de caché en una repetición de 10 llamadas: 0.
• El TTFT osciló de ~1000 ms a ~4500 ms de llamada en llamada, con respuestas vacías ocasionales.

Como casi cada solicitud va a un upstream nuevo, te quedas en la latencia de prefill en frío y heredas la varianza de cualquier proveedor que respondiera. El modelo GPT obtuvo una mejora del 36% en TTFT de una caché alcanzable; el modelo con deriva no obtuvo ninguna, más una dispersión de 4.5x entre su llamada más rápida y la más lenta.

Audita tu propia configuración en cinco minutos

No confíes en estos números, ni en los de nadie. Envía el mismo prefijo largo varias veces y observa dos campos. No hay dominios codificados; apúntalo a tu propio gateway con variables de entorno.

import os, uuid
from openai import OpenAI

client = OpenAI(api_key=os.environ["GW_KEY"], base_url=os.environ["GW_BASE"])
SYS = f"[probe {uuid.uuid4().hex}]\n\n" + ("You are a support assistant. " * 300)

seen, hits = {}, 0
for i in range(20):
    r = client.chat.completions.create(
        model=os.environ["GW_MODEL"], max_tokens=16,
        messages=[{"role": "system", "content": SYS},
                  {"role": "user", "content": f"q{i}"}],
        extra_body={"usage": {"include": True}})
    d = r.model_dump()
    det = r.usage.prompt_tokens_details
    cached = (getattr(det, "cached_tokens", 0) or 0) if det else 0
    seen[d.get("provider")] = seen.get(d.get("provider"), 0) + 1   # populated when exposed
    hits += 1 if cached else 0

print(f"hit rate {hits}/20; upstreams seen: {len(seen)}")

Más de un upstream para el mismo modelo significa deriva. Una tasa de aciertos muy por debajo de la estabilidad de tu prompt significa que te está cobrando de más. El método más completo está en ¿Tu gateway de LLM miente sobre la caché?.

Qué buscar

La cura para la deriva es estructural: enruta un modelo dado a un backend consistente para que una caché caliente sea realmente alcanzable en la siguiente solicitud, en lugar de balancear cada llamada hacia un upstream nuevo que nunca ha visto tu prefijo. Cuando evalúes un gateway, envía el mismo prefijo 20 veces y cuenta los upstreams. Uno es lo que quieres. Nueve es un impuesto.

Una salvedad justa: el almacenamiento en caché de prompts es de mejor esfuerzo en todas partes, y en modelos con caché en disco la tasa de aciertos aún se ablanda tras largos periodos inactivos, incluso con un único backend. Eliminar la deriva no te entrega una caché infinita. Elimina la fuente de fallos más grande y derrochadora, la que nunca aceptaste y no puedes ver.

Cierre

“Soporta almacenamiento en caché de prompts” y “tu caché es alcanzable” son afirmaciones distintas. Un gateway que dispersa un modelo entre un elenco rotatorio de upstreams puede reportar soporte de caché de forma veraz mientras entrega una tasa de aciertos del 20%, una factura ~4x mayor y una latencia de primer token que oscila 4.5x. El número a vigilar no es si el almacenamiento en caché se anuncia. Es tu tasa de aciertos medida y cuántos upstreams tocan tus solicitudes idénticas. Ejecuta la sonda y deja que los datos lo resuelvan.

Para el método de auditoría más amplio, ver ¿Tu gateway de LLM miente sobre la caché?; para entender por qué existen las cachés, ver Cómo funcionan la KV Cache y el TTL.

Preguntas frecuentes

¿Es esto una mala configuración por mi parte? No. Ocurre con los valores de fábrica: enrutamiento automático con el orden de proveedores dejado en “default (balanced)”. Evitar la deriva requiere fijar activamente un upstream, no al revés.

¿Fijar un upstream lo soluciona? Elimina la deriva entre proveedores, pero un único upstream a menudo ejecuta múltiples réplicas sin afinidad de prefijo, así que los aciertos aún pueden alternar. Mide después de fijar en vez de suponer.

¿Por qué el modelo de clase GPT no tuvo deriva? En esta ejecución el gateway resultó enrutarlo a un único upstream. La deriva es por modelo y depende de cuántos upstreams elegibles balancea el gateway; no es uniforme.

¿La diferencia de coste es realmente de ~4x? En los totales por llamada que medimos, un fallo fue ~4x un acierto; en el precio por token de entrada bruto para esta clase de modelo, la diferencia publicada entre acierto y fallo se acerca a 50x. De cualquier forma, convertir aciertos esperados en fallos es la parte cara.

¿Qué métrica única debería monitorizar? La tasa de aciertos de caché por modelo a lo largo del tiempo, junto con el recuento de upstreams distintos por modelo. Si la tasa de aciertos cae o el recuento de upstreams sube, tu coste efectivo por token acaba de subir.

← Volver al blog