Phase 17 - Lesson 20

Tráfego Shadow, Canary Rollout e Implantação Progressiva para LLMs

Lançamentos (rollouts) de LLMs combinam as partes mais difíceis da implantação de software: ausência de testes unitários tradicionais, modos de falha difusos e sinais atrasados. A sequência recomendada é: (1) modo shadow — duplica as requisições de produção para o modelo candidato, registra em log e compara sem qualquer impacto para o usuário; detecta problemas óbvios de distribuição, mas não é uma garantia de qualidade; (2) canary rollout — desvio progressivo de tráfego (10% → 25% → 50% → 75% → 100%) com portas de qualidade (gates) a cada etapa, monitorando percentis de latência, custo por requisição, taxa de erro/recusa, distribuição de comprimento de saída e taxa de feedback dos usuários; (3) testes A/B para alternativas distintas após a confirmação de estabilidade. O não determinismo é irredutível — até 15% de variação na acurácia entre execuções com entradas idênticas devido à não associatividade de pontos flutuantes na GPU combinada com a variação no tamanho do lote (batch size). O custo é uma variável, não uma constante — um modelo 20% melhor pode custar 3x mais por chamada. A velocidade de rollback é decisiva: se o rollback exigir uma nova implantação (redeploy), seu processo é lento demais. As políticas residem em flags de configuração; o modelo reside em um registro com pinned digests; o rollback consiste em alterar a flag da política + reverter o limite de tráfego + fixar o modelo anterior em segundos.

Type: Learn Languages: Python (stdlib, simulador simples de progressão de canary) Prerequisites: Phase 17 · 13 (Observability), Phase 17 · 21 (A/B Testing) Time: ~60 minutos

Objetivos de Aprendizado

• Diferenciar os modos shadow (comparação sem impacto), canary (progressão de tráfego em produção) e testes A/B (comparação após estabilização).
• Enumerar as cinco métricas de canary específicas de LLMs (latência, custo por requisição, erro/recusa, distribuição de tamanho de saída, feedback do usuário).
• Explicar por que o não determinismo das LLMs (de até 15%) altera a definição de um estado "estável" no lançamento.
• Projetar um processo de rollback que leve segundos (mudança de flag de política) em vez de horas (reimplantação).

O Problema

Você lança um novo modelo. Evals offline indicam um ganho de 3% de acurácia. Você o ativa em produção. Em 24 horas, os custos aumentam em 40%, os feedbacks negativos (thumbs-down) crescem 8% e três clientes abrem chamados relatando "respostas estranhas". Você decide reverter. A reimplantação (redeploy) leva 3 horas. Seu fim de semana foi arruinado.

Todos esses problemas eram evitáveis. O modo shadow teria detectado o aumento de 40% nos custos antes de qualquer usuário interagir com o modelo. O canary teria interrompido a distribuição em 10% de tráfego quando os feedbacks negativos começaram a subir. Um rollback por flag de política teria levado 30 segundos. É a disciplina operacional que preenche a lacuna entre "os evals offline parecem bons" e "os usuários reais estão satisfeitos".

O Conceito

Modo shadow

O modelo candidato recebe as mesmas requisições que a produção; as saídas são registradas, mas não são enviadas aos usuários. Zero impacto no usuário. Registros em log:

• Conteúdo da saída (diferença em relação à produção).
• Contagem de tokens (diferença de custo).
• Latência.
• Recusas e erros.

Detecta: aumentos inesperados de custo, regressões de comprimento, alterações óbvias de recusa e erros fatais. NÃO detecta: diferenças de qualidade perceptíveis pelos usuários. O modo shadow é um teste de fumaça (smoke test), não um teste de qualidade.

Canary rollout

Desvio progressivo de tráfego com portas de qualidade (gates). Progressão típica: 1% → 10% → 25% → 50% → 75% → 100%. Avaliação baseada em 5 métricas em cada etapa:

1. Percentis de latência — P50, P95, P99. Violação: canary apresenta P99 > 1,5x em relação ao baseline.
2. Custo por requisição — valor médio cobrado. Violação: >20% acima do baseline.
3. Taxa de erro / recusa — erros 5xx somados a recusas explícitas. Violação: 2x em relação ao baseline.
4. Distribuição do comprimento de saída — média + P99. Violação: mudança na distribuição.
5. Taxa de feedback de usuários — avaliações negativas (thumbs-down) / abertura de chamados. Violação: 1,5x em relação ao baseline.

O não determinismo é a nova variância

Entradas idênticas produzem saídas distintas. Causas:

• Não associatividade de pontos flutuantes na GPU (a ordem de redução de ponto flutuante varia de acordo com o lote).
• Variação no tamanho do lote (mesmo prompt em lote de 128 vs lote de 16).
• Amostragem (temperatura > 0).

Métrica observada: variação de acurácia de até 15% entre execuções em conjuntos de avaliação idênticos. O termo "estável" em um lançamento progressivo significa que as métricas estão dentro da variância esperada, e não idênticas ao baseline. Ajuste as portas de qualidade acima do nível de ruído.

O custo é uma variável

Um modelo 20% melhor pode custar 3x mais por chamada. O custo por requisição é um dos cinco gates de liberação. Lançar um modelo "melhor" que inviabiliza a economia unitária do produto exige rollback.

O rollback é a sua defesa

• Flags de política (sistema de feature flags): altera a porcentagem na configuração; leva segundos.
• Pinned models (digest do registro): o modelo fixado não realiza atualizações automáticas.
• Rollback = reverter flag + definir digest fixado para a versão anterior. Executado em segundos, não em horas.

Se sua stack exige reimplantação para reverter, corrija isso antes de realizar novos lançamentos.

Ferramentas

Argo Rollouts / Flagger — controladores de entrega progressiva nativos do Kubernetes. Integram-se com enrutamento ponderado via Istio/Linkerd.

Roteamento ponderado Istio — divisão de tráfego no nível de service mesh.

KServe / Seldon Core — plataformas de serviço de modelos com suporte nativo a canary.

Feature flags — LaunchDarkly, Flagsmith, Unleash. Mudanças no nível de política, sem redeploys.

Cadência das métricas

Os gates do canary são verificados a cada 5-15 minutos, variando com o volume de tráfego. Um tráfego de 1% com 10 req/min gera 50-150 pontos de dados por janela — suficiente para análise de latência, mas instável para feedback de usuário. 10% geram ~10x mais dados. As progressões devem pausar pelo tempo necessário para consolidar amostras estatísticas em cada etapa.

A etapa de A/B é opcional

Caso o novo modelo possua diferenças acentuadas (comportamento distinto, curva de custos diferente, tom diferenciado), realize testes A/B a 50% de tráfego após a validação do canary. Se for apenas uma versão melhorada, avance diretamente para 100% assim que os gates do canary forem superados.

Números que você deve lembrar

• Progressão do canary: 1% → 10% → 25% → 50% → 75% → 100%.
• Teto de não determinismo: até 15% de variação entre execuções com entradas idênticas.
• Cinco métricas de canary: latência, custo, taxa de erro/recusa, comprimento da saída e feedback de usuários.
• Gate de custos: >20% acima do baseline gera violação.
• Rollback: realizado em segundos, não em horas.

Use

code/main.py simula um canary rollout com injeção de regressões. Relata em qual etapa a distribuição foi interrompida e qual gate disparou o alerta.

Coloque em Produção

Esta lição produz outputs/skill-rollout-runbook.md. Dado o modelo candidato, baseline e tolerância a riscos, desenha o plano shadow→canary→100%.

Exercícios

1. Execute code/main.py. Injete uma regressão de custo de 25%. Em qual estágio o canary é interrompido?
2. Seu novo modelo apresenta ganho de acurácia offline de 3%, mas o custo/requisição é +18%. Deve ser lançado? Depende das regras estabelecidas — planeje o fluxo para ambos os caminhos.
3. Projete um processo de rollback que leve menos de 60 segundos do início ao fim. Liste as infraestruturas necessárias.
4. O não determinismo indica ±7% de variação na sua avaliação. Defina os limites dos gates de forma a evitar alarmes falsos. Quais multiplicadores você utilizou?
5. O modo shadow identifica um pico de custo de 40% antes do canary. Crie a regra de alerta a ser acionada no modo shadow.

Termos-Chave

Leituras Adicionais

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