Phase 17 - Lesson 20

Tráfico Shadow, Canary Rollout y Despliegue Progresivo para LLMs

Los lanzamientos (rollouts) de LLMs combinan las partes más difíciles del despliegue de software: sin pruebas unitarias tradicionales, modos de fallo difusos y señales tardías. La secuencia es: (1) modo shadow — duplicar solicitudes de producción al modelo candidato, registrar en logs y comparar sin ningún impacto para el usuario; detecta problemas obvios de distribución, pero no es una garantía de calidad; (2) canary rollout — desvío progresivo del tráfico (10% → 25% → 50% → 75% → 100%) con puertas de calidad (gates) en cada etapa, monitoreando percentiles de latencia, costo por solicitud, tasa de error/rechazo, distribución de longitud de salida y tasa de feedback de los usuarios; (3) pruebas A/B para alternativas distintas después de confirmar la estabilidad. El no determinismo es irreducible — hasta un 15% de variación en la precisión entre ejecuciones con entradas idénticas debido a la no asociatividad de puntos flotantes en la GPU combinada con la variación en el tamaño del lote (batch size). El costo es una variable, no una constante — un modelo un 20% mejor puede costar 3 veces más por llamada. La velocidad de rollback es decisiva: si el rollback requiere un nuevo despliegue (redeploy), su proceso es demasiado lento. Las políticas residen en flags de configuración; el modelo reside en un registro con pinned digests; el rollback consiste en cambiar la flag de la política + revertir el límite de tráfico + fijar el modelo anterior en segundos.

Type: Learn Languages: Python (stdlib, simulador simple de progresión de canary) Prerequisites: Phase 17 · 13 (Observability), Phase 17 · 21 (A/B Testing) Time: ~60 minutos

Objetivos de Aprendizaje

• Diferenciar entre el modo shadow (comparación sin impacto), canary (progresión de tráfico en producción) y pruebas A/B (comparación tras estabilización).
• Enumerar cinco métricas de canary específicas de LLMs (latencia, costo por solicitud, error/rechazo, distribución de tamaño de salida, feedback del usuario).
• Explicar por qué el no determinismo de los LLMs (de hasta un 15%) altera la definición de un estado "estable" en el lanzamiento.
• Diseñar un proceso de rollback que lleve segundos (cambio de flag de política) en lugar de horas (redespliegue).

El Problema

Lanza un nuevo modelo. Los evals offline indican una ganancia del 3% en precisión. Lo activa en producción. En 24 horas, los costos aumentan en un 40%, los feedbacks negativos (thumbs-down) crecen un 8% y tres clientes abren incidencias informando de "respuestas extrañas". Decide revertir. El redespliegue (redeploy) lleva 3 horas. Su fin de semana está arruinado.

Todos esos problemas eran evitables. El modo shadow habría detectado el aumento del 40% en los costos antes de que cualquier usuario interactuara con el modelo. El canary se habría detenido al 10% del tráfico cuando los comentarios negativos comenzaron a subir. Un rollback por flag de política habría tomado 30 segundos. Es la disciplina operativa la que llena el vacío entre "los evals offline se ven bien" y "los usuarios reales están contentos".

El Concepto

Modo shadow

El modelo candidato recibe las mismas solicitudes que producción; las salidas se registran en logs, pero no se envían a los usuarios. Cero impacto en el usuario. Registro en logs:

• Contenido de la salida (diferencia en relación con producción).
• Conteo de tokens (diferencia de costo).
• Latencia.
• Rechazos y errores.

Detecta: aumentos inesperados de costo, regresiones de longitud, cambios obvios de rechazo y errores graves. NO detecta: diferencias de calidad perceptibles por los usuarios. El modo shadow es una prueba de humo (smoke test), no una prueba de calidad.

Canary rollout

Desvío progresivo de tráfico con puertas de calidad (gates). Progresión típica: 1% → 10% → 25% → 50% → 75% → 100%. Evaluación basada en 5 métricas en cada paso:

1. Percentiles de latencia — P50, P95, P99. Infracción: el canary presenta un P99 > 1.5x en relación con la línea base.
2. Costo por solicitud — valor medio cobrado. Infracción: >20% por encima de la línea base.
3. Tasa de error / rechazo — errores 5xx sumados a rechazos explícitos. Infracción: 2x en relación con la línea base.
4. Distribución de longitud de salida — media + P99. Infracción: cambio en la distribución.
5. Tasa de feedback de usuarios — evaluaciones negativas (thumbs-down) / apertura de incidencias. Infracción: 1.5x en relación con la línea base.

El no determinismo es la nueva varianza

Entradas idénticas producen salidas distintas. Causas:

• No asociatividad de puntos flotantes en la GPU (el orden de reducción de punto flotante varía según el lote).
• Variación en el tamaño del lote (mismo prompt en lote de 128 vs lote de 16).
• Muestreo (temperatura > 0).

Métrica observada: variación de precisión de hasta un 15% entre ejecuciones en conjuntos de evaluación idénticos. El término "estable" en un despliegue progresivo significa que las métricas están dentro de la varianza esperada, no que sean idénticas a la línea base. Ajuste las puertas de calidad por encima del nivel de ruido.

El costo es una variable

Un modelo un 20% mejor puede costar 3 veces más por llamada. El costo por solicitud es uno de los cinco gates de liberación. Lanzar un modelo "mejor" que rompa la viabilidad económica del producto exige rollback.

El rollback es su defensa

• Flags de política (sistema de feature flags): altera el porcentaje en la configuración; toma segundos.
• Pinned models (digest del registro): el modelo fijado no realiza actualizaciones automáticas.
• Rollback = revertir flag + definir digest fijado para la versión anterior. Toma segundos, no horas.

Si su stack exige redespliegue para revertir, corrija eso antes de realizar nuevos lanzamientos.

Herramientas

Argo Rollouts / Flagger — controladores de entrega progresiva nativos de Kubernetes. Se integran con enrutamiento ponderado mediante Istio/Linkerd.

Enrutamiento ponderado Istio — división de tráfico en el nivel de service mesh.

KServe / Seldon Core — plataformas de servicio de modelos con soporte nativo a canary.

Feature flags — LaunchDarkly, Flagsmith, Unleash. Cambios a nivel de política, sin redespliegues.

Cadencia de métricas

Los gates de canary se verifican cada 5-15 minutos, variando según el volumen de tráfico. Un tráfico del 1% con 10 req/min genera 50-150 puntos de datos por ventana — suficiente para análisis de latencia, pero inestable para feedback de usuario. Un 10% genera ~10x más datos. Las progresiones deben pausar el tiempo necesario para consolidar muestras estadísticas en cada paso.

La etapa de A/B es opcional

Si el nuevo modelo tiene diferencias marcadas (comportamiento distinto, curva de costos diferente, tono diferenciado), realice pruebas A/B al 50% de tráfico después de que se aprueben los gates de canary. Si es solo una versión mejorada, avance directamente al 100% cuando se superen los gates de canary.

Números que debe recordar

• Progresión de canary: 1% → 10% → 25% → 50% → 75% → 100%.
• Límite de no determinismo: hasta un 15% de variación entre ejecuciones con entradas idénticas.
• Cinco métricas de canary: latencia, costo, tasa de error/rechazo, longitud de salida y feedback de usuarios.
• Gate de costos: >20% por encima de la línea base genera una infracción.
• Rollback: realizado en segundos, no en horas.

Uso

code/main.py simula un canary rollout con inyección de regresiones. Informa en qué etapa se interrumpió la distribución y qué gate disparó la alerta.

Puesta en Producción

Esta lección produce outputs/skill-rollout-runbook.md. Dado el modelo candidato, línea base y tolerancia a riesgos, diseña el plan shadow→canary→100%.

Ejercicios

1. Ejecute code/main.py. Inyecte una regresión de costo del 25%. ¿En qué etapa se detiene el canary?
2. Su nuevo modelo presenta una ganancia de precisión offline del 3%, pero el costo/solicitud es +18%. ¿Debe lanzarse? Depende de las reglas establecidas — planifique el flujo para ambos caminos.
3. Diseñe un proceso de rollback que lleve menos de 60 segundos de principio a fin. Enumere las infraestructuras necesarias.
4. El no determinismo indica ±7% de variación en su evaluación. Defina los límites de los gates para evitar alarmas falsas. ¿Qué multiplicadores utilizó?
5. El modo shadow identifica un pico de costo del 40% antes del canary. Cree la regla de alerta que se activará en el modo shadow.

Términos Clave

Lecturas Adicionales

• TianPan — Releasing AI Features Without Breaking Production
• MarkTechPost — Safely Deploying ML Models
• APXML — Advanced LLM Deployment Patterns
• Argo Rollouts docs
• Flagger docs