Módulo 2: Latencia y costo como arquitectura

4. El model cascade: barato primero, escalar solo si hace falta

Siguiente →

Descripción

Al terminar esta lección vas a saber diseñar y medir el patrón de mayor palanca sobre el costo de una feature de IA: el model cascade. La idea es simple y poderosa: no mandes todas las queries al modelo más caro; manda las fáciles al barato y solo las difíciles al caro. Para eso hace falta una pieza más —un clasificador que mire cada query y decida la dificultad, para enrutarla al modelo correcto—. Como la mayoría de las queries de un sistema real son fáciles, y como el modelo barato cuesta cerca de diez veces menos que el caro, enrutar bien ahorra una fracción enorme del costo sin perder calidad donde importa. Vas a construir un cascade ejecutado sobre 1000 búsquedas de Mercado y a medir el ahorro frente a "todo al caro": vas a ver bajar el costo y la latencia promedio de forma notable, y vas a ver un detalle honesto que casi nadie explica —por qué el p95 casi no baja—.

Esto importa porque "todo al modelo más caro por si acaso" es el error de costo más común y más caro al meter IA en un sistema. Se comete por una razón razonable —el modelo caro da mejor calidad— pero con una conclusión equivocada —"mejor para las difíciles" no implica "mejor para todo"—. La mayoría de las queries no necesitan la potencia del modelo grande: "iphone" o "laptop barata" las resuelve el modelo pequeño igual de bien, a una décima parte del costo. Pagar el precio premium por cada query trivial es exactamente lo que hace que la búsqueda semántica de Mercado cueste $25,200/mes en vez de una fracción. El cascade es la técnica que corrige eso: reserva el modelo caro para donde su calidad extra realmente vale, y cobra el barato por lo demás. Es la diferencia entre pagar tarifa de especialista por cada consulta y pagarla solo por los casos que la ameritan.

Conexión con el módulo: esta es la primera técnica para respetar el presupuesto de la lección 3. Allá viste que "todo al strong model" viola el cost budget ($25,200 contra $3,000); aquí lo atacas de frente, enrutando el tráfico fácil al barato. Es también la primera vez que aparece una pieza nueva de arquitectura —el clasificador— que vive antes del LLM y decide a cuál llamar: un componente determinista y barato que gobierna a los probabilísticos y caros. La lección 5 (caché) es la otra gran palanca de costo, y opera de forma complementaria: el cascade abarata cada llamada, la caché elimina llamadas repetidas. La lección 7 las compone y muestra que juntas —no una sola— meten la feature en su presupuesto. Y el detalle del p95 que verás aquí conecta directo con la lección 6: el cascade no arregla la latencia de cola, para eso hace falta el streaming.

El call center que atiende con el junior y escala al senior

Piénsalo así. Un call center bien montado recibe miles de llamadas al día, y tiene dos tipos de agente: juniors, muchos, baratos, rápidos con lo rutinario; y seniors, pocos, caros, expertos en lo complicado. La tentación del gerente novato es poner a los seniors a atender todo —"así garantizo la mejor atención en cada llamada"—. Es un desastre económico: la mayoría de las llamadas son fáciles ("¿cuál es su horario?", "¿cómo reseteo mi contraseña?"), y un senior resolviendo un horario es un especialista carísimo haciendo el trabajo de un principiante. El gerente serio hace otra cosa: todas las llamadas entran por los juniors, que resuelven la mayoría en segundos; y solo cuando el junior detecta un caso difícil —un reclamo complejo, algo que no puede resolver— escala al senior. La regla es "atiende con el barato, escala al caro solo cuando hace falta".

El model cascade es exactamente ese call center. El cheap model es el ejército de juniors: rápido, barato, perfectamente capaz con la mayoría del tráfico. El strong model es el puñado de seniors: lento, caro, reservado para lo difícil. Y hay una pieza que hace de recepcionista: el clasificador, que mira cada query entrante y decide si es un caso de junior (fácil → cheap) o de senior (difícil → strong). El clasificador es barato —una heurística o un modelo diminuto, no el modelo grande— porque su trabajo es solo enrutar, no responder.

Hay dos formas de montar el enrutamiento, las dos válidas y las dos presentes en el call center. La primera es clasificar y enrutar: la recepcionista escucha la primera frase y decide junior o senior antes de pasar la llamada. La segunda es probar barato y escalar: la llamada siempre va primero al junior, y el junior mismo, si ve que no puede, la pasa al senior. La primera es más limpia de medir y es la que ejecutamos en el ejemplo; la segunda tiene su propio matiz de costo (las difíciles pagan junior y senior) que veremos en la profundización. En los dos casos, el principio es el mismo, y es el corazón del ahorro: no pongas al senior a contestar en qué horario abres.

Ejemplo trabajado: el cascade que mide su ahorro

Vamos a montar el cascade sobre un workload realista y a medir cuánto ahorra frente a mandar todo al strong model. El workload son 1000 búsquedas, de las cuales el 30% son "difíciles" (necesitan el razonamiento del modelo grande) y el 70% fáciles. Un clasificador barato —que cuesta ~3 ms y $0 porque es una heurística, no una llamada al LLM— predice la dificultad y enruta. El clasificador es imperfecto: acierta el 92% de las veces (a veces manda una fácil al caro, o una difícil al barato), porque ningún clasificador real es perfecto y es honesto medir con esa imperfección incluida. Las queries difíciles piden respuestas más largas (300 tokens de salida) que las fáciles (120), lo que hace que las difíciles sean intrínsecamente más lentas y caras sin importar el modelo.

Todo con semilla fija para que los números sean reproducibles. Medimos dos estrategias: el baseline (todo al strong model) y el cascade (clasificar y enrutar).

# Leccion 04 — el model cascade (barato primero, escalar solo si hace falta)
# STUB del LLM: todo SIMULADO. Cero red, cero API, cero claves. Semilla fija.
import random

MODELS = {
    "cheap":  dict(usd_in=0.0008, usd_out=0.004, base_ms=90,  ms_per_tok=0.4),
    "strong": dict(usd_in=0.008,  usd_out=0.040, base_ms=300, ms_per_tok=3.0),
}

def call_llm(model, in_tokens, out_tokens):
    m = MODELS[model]
    latency_ms = m["base_ms"] + out_tokens * m["ms_per_tok"]
    cost_usd = (in_tokens / 1000) * m["usd_in"] + (out_tokens / 1000) * m["usd_out"]
    return latency_ms, cost_usd

# --- El workload: 1000 busquedas. El 30% son "dificiles" (necesitan razonamiento). ---
random.seed(7)
N = 1000
IN_TOK = 300
OUT_EASY, OUT_HARD = 120, 300      # las dificiles piden una respuesta mas larga

queries = []
for _ in range(N):
    true_hard = random.random() < 0.30
    queries.append(true_hard)

# --- El clasificador barato: predice la dificultad y enruta. Imperfecto (92% acierto). ---
CLASSIFIER_MS = 3          # una heuristica barata: ~3 ms
CLASSIFIER_COST = 0.0      # regla/heuristica: no cuesta llamada al LLM
def classify(true_hard):
    return true_hard if random.random() < 0.92 else (not true_hard)

def out_tokens_for(true_hard):
    return OUT_HARD if true_hard else OUT_EASY

def pct(sorted_vals, p):
    return sorted_vals[int(len(sorted_vals) * p)]

def measure(route_fn):
    """route_fn(true_hard) -> nombre de modelo. Devuelve (total_cost, avg_lat, p95_lat, extra_ms)."""
    total_cost, lats = 0.0, []
    for true_hard in queries:
        extra_ms, extra_cost, model = route_fn(true_hard)
        lat, cost = call_llm(model, IN_TOK, out_tokens_for(true_hard))
        total_cost += cost + extra_cost
        lats.append(lat + extra_ms)
    lats.sort()
    return total_cost, sum(lats) / len(lats), pct(lats, 0.95)

# Baseline: TODO al modelo caro.
def all_strong(true_hard):
    return 0.0, 0.0, "strong"

# Cascade: el clasificador enruta faciles->cheap, dificiles->strong.
def cascade(true_hard):
    pred_hard = classify(true_hard)
    return CLASSIFIER_MS, CLASSIFIER_COST, ("strong" if pred_hard else "cheap")

base_cost, base_avg, base_p95 = measure(all_strong)
casc_cost, casc_avg, casc_p95 = measure(cascade)

print(f"{'strategy':<14}{'total_cost':>12}{'avg_lat_ms':>12}{'p95_lat_ms':>12}")
print(f"{'all_strong':<14}{base_cost:>12.4f}{base_avg:>12.1f}{base_p95:>12.1f}")
print(f"{'cascade':<14}{casc_cost:>12.4f}{casc_avg:>12.1f}{casc_p95:>12.1f}")

print(f"\nAhorro de costo:   {(1 - casc_cost/base_cost)*100:>5.1f}%  "
      f"(${base_cost:.4f} -> ${casc_cost:.4f} por {N} busquedas)")
print(f"Ahorro de latencia avg: {(1 - casc_avg/base_avg)*100:>5.1f}%  "
      f"({base_avg:.1f} ms -> {casc_avg:.1f} ms)")

# Escala mensual: 100k busquedas/dia.
scale = 100_000 * 30 / N
print(f"\nA escala ({100_000:,}/dia): all_strong ${base_cost*scale:,.0f}/mes -> "
      f"cascade ${casc_cost*scale:,.0f}/mes")

Qué esperar. Al correrlo:

strategy        total_cost  avg_lat_ms  p95_lat_ms
all_strong          9.6192       841.4      1200.0
cascade             5.4137       506.7      1203.0

Ahorro de costo:    43.7%  ($9.6192 -> $5.4137 por 1000 busquedas)
Ahorro de latencia avg:  39.8%  (841.4 ms -> 506.7 ms)

A escala (100,000/dia): all_strong $28,858/mes -> cascade $16,241/mes

Aquí está el call center funcionando, con sus números. Léelos con cuidado, porque hay una buena noticia grande y un matiz honesto igual de importante.

La buena noticia: el ahorro es enorme. El cascade cuesta 43.7% menos que mandar todo al caro ($5.41 contra $9.62 por 1000 búsquedas) y su latencia promedio baja 39.8% (507 ms contra 841 ms). ¿De dónde sale? De que el 70% de las queries son fáciles y ahora las atiende el modelo barato en vez del caro: cada una de esas paga ~$0.00072 en vez de ~$0.0027, y tarda 150 ms en vez de 750. Setecientas queries que bajan de precio y de tiempo mueven el total muchísimo. A escala mensual, esto es la diferencia entre $28,858/mes (todo al caro) y $16,241/mes (cascade) —$12,600 al mes ahorrados con una sola decisión de arquitectura, sin tocar el modelo ni el hardware, solo enrutando—.

El matiz honesto: el p95 casi no baja. Mira la columna p95_lat_ms: el baseline tiene 1200 ms y el cascade 1203 ms —prácticamente iguales, incluso un pelín peor por los 3 ms del clasificador—. ¿Por qué la latencia de cola no mejora si el promedio bajó 40%? Porque el p95 —la latencia del peor 5%— la dominan las queries difíciles, y esas siguen yendo al strong model en las dos estrategias. El cascade abarata y acelera lo fácil, pero lo difícil sigue tardando lo que tardaba (300 + 300×3 = 1200 ms). Esto es crucial: el cascade arregla el costo y la latencia promedio, pero NO arregla la latencia de cola. El usuario cuya query es difícil sigue esperando 1.2 segundos. Y recuerda de la lección 3 que el latency budget serio se mide en la cola: el cascade solo, entonces, no basta para respetar un presupuesto de latencia estricto en las queries pesadas. Para eso hace falta otra técnica —el streaming (lección 6)—, que muestra la respuesta mientras se genera. El cascade y el streaming atacan problemas distintos: el cascade el costo y la latencia media, el streaming la latencia percibida en la cola.

Y un aviso que la lección 3 anticipó: el cascade a escala cuesta $16,241/mes, todavía por encima del presupuesto de $3,000. El cascade solo no mete la feature en su presupuesto de costo —recorta casi la mitad, pero no alcanza—. Falta la otra gran palanca: la caché (lección 5), que elimina el tráfico repetido. Ninguna técnica sola es bala de plata; se componen. Eso es lo que la lección 7 va a demostrar.

Profundización: clasificar-y-enrutar vs probar-y-escalar, y el riesgo de mal-enrutar

Las dos formas del cascade. El ejemplo usa clasificar-y-enrutar: un clasificador barato predice la dificultad y manda cada query a un solo modelo. Su costo es limpio: cada query paga un modelo (más el clasificador casi gratis). La otra forma es probar-y-escalar: la query va primero al cheap model, y si el cheap "no está seguro" (baja confianza en su propia respuesta), se escala al strong. Su ventaja es que no necesita un clasificador separado —el propio cheap model decide si escalar—. Su costo tiene un matiz: las queries que se escalan pagan dos llamadas (cheap + strong), no una. Si el 30% se escala, ese 30% cuesta más que en el enfoque de clasificar-primero. Cuál conviene depende de qué tan bueno es tu clasificador frente a qué tan barato es el cheap model: si el clasificador es caro o poco confiable, probar-y-escalar puede salir mejor; si el cheap model es barato pero la doble llamada se acumula, clasificar-primero gana. Los dos son cascade; los dos honran el principio "barato primero".

El costo de mal-enrutar, y por qué toca la calidad. El clasificador es imperfecto (92% en el ejemplo), y se equivoca de dos formas, con consecuencias distintas:

  • Manda una fácil al caro (falso positivo de dificultad): desperdicia dinero —paga premium por algo que el barato habría resuelto— pero no daña la calidad (el caro responde bien una fácil). Es un error de eficiencia, no de correctitud.
  • Manda una difícil al barato (falso negativo): ahorra dinero pero puede dañar la calidad —el cheap model quizá responde peor una query que necesitaba el strong—. Es un error de correctitud, y es el peligroso.

Aquí toca la frontera con el módulo 3. Este módulo mide el ahorro del cascade asumiendo que el enrutamiento es correcto; verificar que la calidad no se cae cuando abaratas —que las difíciles mal-enrutadas al barato no arruinan la experiencia— es trabajo del eval gate (módulo 3). Los dos van juntos: el cascade te da el ahorro, el eval te confirma que el ahorro no vino a costa de respuestas malas. Un cascade sin eval es optimizar el costo a ciegas; con eval, es optimizar el costo con red de seguridad. Por eso, en la práctica, se calibra el clasificador para que en la duda escale (prefiera el falso positivo barato-a-caro, que solo cuesta dinero, sobre el falso negativo difícil-a-barato, que cuesta calidad).

Más de dos niveles. El cascade no tiene por qué ser barato/caro: puede ser una escalera de tres o más modelos (diminuto → pequeño → grande), cada uno atendiendo su franja de dificultad. El principio es el mismo —cada query al modelo más pequeño que la resuelve bien— y el ahorro se compone. En el mundo real, esto mapea a familias de modelos: algo como Claude Haiku para lo trivial, algo como Claude Sonnet para lo intermedio, algo como Claude Opus para lo más difícil. Cuántos niveles poner es un trade-off entre el ahorro extra y la complejidad de mantener el enrutamiento —cada nivel más es otro umbral que afinar—.

Errores comunes

Mandar todo al modelo más caro "por si acaso" (de sobre-ingeniería del costo). Qué pasa: para garantizar la mejor calidad, el equipo enruta el 100% del tráfico al strong model. La calidad es buena pero el costo se dispara —pagas premium por cada query trivial, que es la mayoría—. Por qué pasa: se razona "el caro es mejor" y se salta el "…pero solo hace falta donde el barato no alcanza". Cómo detectarlo: si un solo modelo (el más caro) atiende todo tu tráfico, estás en el call center donde los seniors contestan los horarios. Cómo corregirlo: mete un clasificador y enruta —el 70% fácil al barato baja el costo casi a la mitad sin tocar la calidad de las difíciles—.

Confiar en un clasificador perfecto (de suposición irreal). Qué pasa: el diseño asume que el clasificador siempre acierta, y no planea para los errores de enrutamiento. En producción, el clasificador manda difíciles al barato y algunas respuestas salen peores, sin que nadie lo note hasta que un usuario se queja. Por qué pasa: en el diseño el clasificador se dibuja como una caja que "decide la dificultad", y es fácil olvidar que también se equivoca. Cómo detectarlo: si tu cascade no tiene un eval que verifique la calidad de las queries enrutadas al barato, estás confiando en un clasificador perfecto que no existe. Cómo corregirlo: calibra el clasificador para escalar en la duda (falso positivo barato, no falso negativo caro) y verifica la calidad con un eval-set (módulo 3).

Esperar que el cascade arregle la latencia de cola (de expectativa equivocada). Qué pasa: el equipo mete un cascade esperando que baje el p95, y se sorprende cuando el p95 sigue igual —las queries difíciles siguen tardando lo mismo en el strong model—. Concluye erróneamente que "el cascade no sirvió". Por qué pasa: el cascade baja el promedio de forma visible, y es intuitivo (pero falso) suponer que baja también la cola. Cómo detectarlo: si tu métrica de éxito del cascade era el p95 y no bajó, mediste la técnica contra el problema equivocado. Cómo corregirlo: entiende qué arregla cada técnica —el cascade baja costo y latencia media; la latencia de cola la ataca el streaming (lección 6)— y usa cada una para su problema.

Ejercicios

Ejercicio 1 — Recalcula con un clasificador mejor. Supón que mejoras el clasificador de 92% a 100% de acierto (perfecto). ¿Sube o baja el ahorro de costo del cascade? Razona qué queries cambian de enrutamiento al pasar de 92% a 100% y en qué dirección mueven el costo. (No necesitas correr el código; razona con la lógica.)

Ver solución

Con 92%, el clasificador mal-enruta el 8% de las queries en dos direcciones:

  • Algunas fáciles las manda al caro (falso positivo): esas pagan de más. Con un clasificador perfecto, volverían al barato → ahorra.
  • Algunas difíciles las manda al barato (falso negativo): esas pagan de menos (el barato es más barato). Con un clasificador perfecto, subirían al caro → cuesta más.

Los dos efectos se oponen. Pero como en el workload hay más fáciles (70%) que difíciles (30%), y como el clasificador se equivoca en ambas direcciones, el efecto neto sobre el costo es pequeño y depende del balance exacto. La lección importante no es el signo exacto del cambio de costo, sino esto: la precisión del clasificador afecta más a la CALIDAD que al costo. Un clasificador perfecto no cambia dramáticamente el ahorro (el grueso del ahorro viene de que el 70% fácil va al barato, y eso pasa con 92% o con 100%), pero sí elimina los falsos negativos —las difíciles mal-enrutadas al barato que salían con peor calidad—. Por eso invertir en un mejor clasificador se justifica sobre todo por calidad, no por costo: el costo ya lo captura casi entero un clasificador mediocre.

Ejercicio 2 — El cascade de probar-y-escalar. En vez de clasificar primero, montas el otro cascade: toda query va al cheap model, y el 30% difícil se escala al strong (pagando las dos llamadas). Con las tarifas del stub, calcula el costo por 1000 búsquedas de esta variante y compáralo con el all_strong del ejemplo ($9.6192). Usa: fácil = 120 tokens salida, difícil = 300 tokens salida, entrada 300. (Asume que el cheap model acierta en detectar las difíciles.)

Ver solución
  • 700 fáciles, solo cheap (in 300, out 120): costo por una = 0.3×0.0008 + 0.12×0.004 = 0.00024 + 0.00048 = $0.00072. Total: 700 × 0.00072 = $0.504.
  • 300 difíciles, cheap y strong (pagan las dos):
    • cheap (in 300, out 120, el intento fallido): $0.00072 cada una.
    • strong (in 300, out 300, la respuesta final): 0.3×0.008 + 0.3×0.040 = 0.0024 + 0.012 = $0.0144 cada una.
    • por una difícil: 0.00072 + 0.0144 = $0.01512. Total: 300 × 0.01512 = $4.536.
  • Total probar-y-escalar: 0.504 + 4.536 = $5.04 por 1000 búsquedas.

Comparación: probar-y-escalar cuesta $5.04, un poco menos que el clasificar-y-enrutar del ejemplo ($5.41) y bastante menos que all_strong ($9.62). ¿Por qué sale un poco más barato que clasificar-primero aquí? Porque en el ejemplo el clasificador imperfecto (92%) mandaba algunas fáciles al caro (desperdicio), mientras que aquí las fáciles nunca tocan el strong. Pero ojo con el matiz: esta variante paga la doble llamada en las difíciles (el intento cheap más el strong), lo que la haría más cara si el porcentaje de difíciles fuera alto, o si el cheap model tardara mucho (la latencia de las difíciles suma el tiempo del cheap fallido + el strong). El trade-off entre las dos variantes vive en esos números: fracción de difíciles, costo de la doble llamada, y confiabilidad del clasificador. No hay una que gane siempre —hay que medir con TU workload—.

Ejercicio 3 — Diseña el cascade del agente de soporte. El agente de soporte de Mercado recibe preguntas como "¿dónde está mi pedido?" (fácil, plantilla), "¿cómo devuelvo esto?" (fácil, FAQ) y "me llegó roto, pagué con dos tarjetas, quiero reembolso parcial a una de ellas y el resto a saldo" (difícil, razonamiento). Describe cómo montarías un cascade para este agente: qué clasifica el clasificador, qué va al barato, qué al caro, y una consideración de calidad específica del soporte que te haría calibrar el clasificador para escalar en la duda.

Ver solución

El cascade del agente de soporte:

  • Clasificador: mira cada mensaje del cliente y estima si es una consulta rutinaria (rastreo de pedido, política de devoluciones, horarios) o compleja (múltiples condiciones, reembolsos con lógica, reclamos con contexto). Puede ser una heurística (palabras clave, longitud, número de entidades mencionadas) o un modelo diminuto —barato, porque solo enruta—.
  • Al cheap model: las rutinarias. "¿Dónde está mi pedido?" se resuelve consultando el estado y respondiendo con una plantilla —el modelo pequeño lo hace perfecto—. Estas son la mayoría del volumen, y abaratarlas es donde está el grueso del ahorro (recuerda que el costo del agente se acumula por turno).
  • Al strong model: las complejas. El reembolso parcial a dos tarjetas necesita entender varias condiciones y proponer una acción coherente —eso amerita el modelo grande—.

La consideración de calidad que empuja a escalar en la duda: en soporte, una respuesta mala tiene consecuencias directas y visibles —un cliente enojado, un reembolso mal calculado, una promesa que el sistema no puede cumplir—. El costo de un falso negativo (mandar una consulta compleja al barato y que responda mal) es mucho mayor que el costo de un falso positivo (mandar una fácil al caro y pagar unos centavos de más). Por eso el clasificador del agente de soporte se calibra conservador: ante la duda, escala al strong. Es la misma lógica del call center —un junior que no está seguro pasa la llamada al senior, no arriesga—. Y todo esto rinde cuentas al eval gate (módulo 3): el ahorro del cascade solo es aceptable si un eval confirma que las consultas enrutadas al barato se responden bien.

Resumen y siguiente paso

En esta lección diseñaste el model cascade, la técnica de mayor palanca sobre el costo: enrutar las queries fáciles al modelo barato y solo las difíciles al caro, con un clasificador barato de recepcionista. Con el call center junior→senior viste la lógica —no pongas al senior a contestar horarios— y con el cascade ejecutado sobre 1000 búsquedas de Mercado mediste el ahorro: 43.7% menos costo y 39.8% menos latencia promedio frente a mandar todo al caro ($28,858/mes → $16,241/mes a escala). Y aprendiste el matiz honesto que casi nadie explica: el p95 casi no baja, porque las queries difíciles siguen yendo al modelo lento —el cascade arregla el costo y la latencia media, no la latencia de cola, que es problema del streaming—. Viste las dos formas del cascade (clasificar-y-enrutar vs probar-y-escalar), el costo de mal-enrutar (el falso negativo difícil-a-barato daña la calidad, y por eso se calibra para escalar en la duda), y la frontera con el módulo 3 (el eval confirma que abaratar no rompió la calidad).

Antes de avanzar deberías poder: diseñar un cascade con clasificador para una feature; medir su ahorro de costo y latencia frente a "todo al caro"; explicar por qué el p95 no baja y qué técnica sí lo ataca; distinguir clasificar-y-enrutar de probar-y-escalar; y calibrar el clasificador para que el error barato (falso positivo) sea preferible al error caro (falso negativo).

Lo que sigue es la otra gran palanca de costo, complementaria al cascade. El cascade abarata cada llamada; la lección 5 elimina llamadas enteras: muchas queries se repiten, y no tiene sentido volver a pagar (ni al barato) una respuesta que ya calculaste. Vas a construir una caché, medir su hit-rate —qué fracción de queries se sirven de lo ya calculado— y el ahorro que produce, y a comparar la caché exacta (que atrapa la misma query literal) con la semántica (que atrapa la misma intención escrita distinto). Y vas a ver que a alto volumen, no repagar es el ahorro más grande de todos.

Recursos

← Anterior3. El presupuesto de latencia y de costoSiguiente →5. Caché: muchas queries se repiten