Implantação de modelos ML

(Secção Tecnologia e Infraestrutura)

Resumo curto

A implantação de produção confiável da ML é um conjunto de artefatos repetíveis (modelo/tocenizer/config), serving normalizado (Triton/KServe/vLLM), processo de lançamento seguro (canários/blue-green/shadow), observabilidade (latência, qualidade, deriva) e runbook-ov para incidentes. Para iGaming, o atraso baixo (antifrod/personalização), SLO rigoroso, PII/complacência e controle de custo são críticos.

1) Modos de implantação

Batch (offline): tarefas noturnas/horas (mapear retrospectivas, atualizar segmentos). Barato, previsível.
Online (API sincronizada): antifrode, personalização, recomendações, dicas LLM. Exige p95 SLA (por exemplo, ≤ 100-300 ms).
Stream (near-real-time): janelas de 1-60 segundos (Flink/Spark/Kafka Streams) para sinais e desencadeadores CRM.
Híbrido: escrutínio rápido e rude online + revezamento offline/calibragem.

2) Artefatos e embalagens

Artefatos de modelo: peso, tocador, configs de pré-processamento/pós-processamento, versão dataset/código.
Formatos: PyTorch/TF SavedModel, ONNX para compatibilidade, TensorRT-engine para aceleração, GGUF/awq/gptq para quantidade LLM.
Contêineres: Imagens Docker OCI com dependências pinned; Marcas múltiplas (CPU/GPU).
Lançamentos imutáveis: formatação 'model: fraud-v3. 2. 1`, `image: fraud:3. 2. 1`.

3) Plataforma de Serving

Triton Inference Server: batching multimodal, dinâmico, conjunto-pipelines.
KServe (K8s-nativo): skale automático (HPA/KPA), canários/shadow, runtime próprio.
vLLM/TGI (LLM): Contínuo batching, KV, decodificação especulativa.
Fichestor: online (ms-SLA) + offline para coerência de fic (função parity).

yaml apiVersion: serving. kserve. io/v1beta1 kind: InferenceService metadata: { name: fraud }
spec:
predictor:
canaryTrafficPercent: 15 model:
modelFormat: { name: triton }
storageUri: s3://models/fraud/v3. 2. 1/
resources: { limits: { nvidia. com/gpu: "1" } }

4) Estratégias de lançamento

Blue-Green: duas pilhas idênticas, mudança de tráfego instantânea, simples reversão.
Canary: aumento gradual do tráfego (1% → 5% → 25% → 100%) em gays SLO/qualidade.
Shadow: o novo modelo recebe uma cópia do tráfego, as respostas não afetam nada - uma avaliação segura.
Testes A/B: Medimos as métricas de negócios (conversão, retenção), a importância estatística.

map $request_id $route {
default old;
"~ canary" new; # 5-15% by flag/cook/feature-toggle
}

5) SLO e orçamentos de trabalho

Online antifrod/personalização: p95 ≤ 100-150 ms, p99 ≤ 250-400 ms.
Dicas LLM (128-512 tokens): p95 ≤ 300-800 ms de geração dos primeiros tocens, tocens/s ≥ alvo.
Disponibilidade: ≥ 99. 9% para caminhos críticos.
Qualidade: AUC/PR-AUC/Top-K @ N ≥ limiar;% das respostas tóxicas/incorretas ≤ X.
Valor: $/1k solicitações ou $/1k tokens - dentro do orçamento.

6) CI/CD para modelos

1. Trem/finetune → o modelo no registro (metadados: dados/código/métricas/licenças).

2. Pack & Validate: testes de prol unit/pós-teste., API compatível, testes de carga (latency/tocens/s).

3. Canary Deploy: 1-5% de tráfego; observabilidade (SLO/qualidade/custo).

4. Promote/Rollback de critérios gays.

yaml jobs:
build-serve:
steps:
- run: make export_onnx && make docker_build
- run: pytest tests/serve --maxfail=1
- run: python perf_check. py --p95 120 --fail-on-regress
- run: kubectl apply -f kserve-canary. yaml

7) Otimizar atrasos e passagens

Batching/microatching (Triton/vLLM), paralelismo de consultas, pré/post-processing para CPU.
Quantificação (INT8/FP8/INT4) com calibração; Compilação de runtime.
Armazenamento em dinheiro: Ficheiro (online )/Redis, resultados e dinheiro KV para LLM.
Warmup: Aquecimento da balança/dinheiro no pouso; «quentes» para o skate automático.
Tempo-orçamento: paragem precoce, limitação de tokens/beam, adaptação de temperatura.

8) Observabilidade: telemetria, deriva, qualidade

Métricas SRE: RPS, p50/p95/p99, erros (5xx/4xx), GPU/CPU util, memória, fila, batch-fill.
Métricas ML: AUC/PR-AUC, errador calibrado, coverage, tocens/s, comprimento de resposta, dinheiro-hit.
À deriva: PSI/JS divergência em entradas/fichas, monitoramento de deslocamento de distribuição; Alertas.
Qualidade online: exemplos dourados de controle, respostas sempling, RAG-score/toxicidade automática para LLM.
Registro: prompt/resposta (com anonimato), trace _ id, versão do modelo.

inference_latency_ms_bucket{model="fraud-v3. 2. 1",le="100"} 12345 inference_qps{model="fraud-v3. 2. 1"} 450 tokens_per_second{model="llm-help-v1"} 210

9) Gerenciamento de fichas e coerência

Função-paridade: as mesmas transformações em offline/online; versionalize os fici como um código.
Fichestor online: ms-SLA, TTL, upsert, idempotency; O dinheiro está mais perto do Serving.
Backfill/refresh: um plano para garantir que o mapeamento online não se espalhe com métricas offline.

10) Segurança, PII e licenças

PII: Toquenização/camuflagem, segmentação por região (EU/TR/LATAM), criptografia em paz/transito.
Segredos/chaves: KMS/Secret Gerente, sem segredos em imagens.
Políticas LLM: filtros de conteúdo, estopers seguros, red-teaming.
Licenças: verifique os termos de dataset/peso, proibições de redistrução/comércio.
Isolamento: namespace-RBAC, quotas, taants/tolerações para pool GPU.

11) Scale automático e QoS

Autoscaling: RPS/filas/latency/GPU-util; min-ready-pods para linhas quentes.
Classe QoS: criterioso online (anti-fraud)> bate-papo LLM> experiências. Preempition a favor dos críticos.
Multiregião: latency-based routing, cachês de peso aquecidos, replicação de fichas.

12) Runbooks e incidentes

Crescimento p99: verificar batch-fill, fila, GPU-util, cash-miss; incluir batching agressivo/rebaixar beam/tokens.
A qualidade caiu: reversão para a versão anterior, ativação do shadow, fixação de fontes à deriva.
O custo aumenta: incluir a quantificação/TensorRT, aumentar o batch, otimizar o fici/dinheiro, reduzir a frequência das gerações LLM através do RAG/resultado-em-dinheiro.
Incidente PII, imediato stop-the-line, levantamento de artefatos, auditoria de acesso, relatório do regulador sobre o procedimento.

13) Exemplos de modelos

text dynamic_batching { preferred_batch_size: [4, 8, 16, 32]
max_queue_delay_microseconds: 2000 }
instance_group { kind: KIND_GPU count: 2 }

--tensor-parallel-size 2
--max-num-seqs 512
--gpu-memory-utilization 0. 9

python resp = client. score({"features": f}) # v3. 2. 1 assert set(resp. keys()) >= {"score","version","latency_ms"}

14) Folha de cheque de implementação

1. Defina o SLO/SLA (latency/availability/quality/cost).
2. Normalize os artefatos e o registro de modelos (versões, metadados).
3. Selecione a pilha de serving (Triton/KServe/vLLM) e o fichestor.
4. Configure canários/blue green/shadow e gates automáticos.
5. Construa CI/CD: testes de compatibilidade, perf regressão, promoção segura.
6. Ative a observabilidade (SRE + ML-métricas), monitoramento à deriva e alertas.
7. Forneça PII/segurança/licenças e auditoria.
8. Configure o scale automático/QoS e políticas multi-regionais.
9. Prepare o runbook-e e realize o game-day.
10. Digite o controle de custo: batching, quantização, cachê, RAG.

15) Antipattern

Deplom «como é» sem canaleta/observabilidade → incidentes inesperados.
Fici inconformados offline/online → uma discrepância de métricas.
Nenhum teste de perf ou limite p99 flutua.
Logar prompt/respostas sem anonimato → risco PII.
Um GPU-pool comum para tudo sem QoS → crítico online sofre.
Não há retalhos, nem artefatos.

Resumo

A implantação de modelos ML com sucesso são artefatos de contêiner, servining normalizado, processo de lançamento seguro (canary/blue-green/shadow), SLO rígido e observabilidade qualidade/deriva/custo. Adicione fichestor, CI/CD com perf-gates, higiene PII, skale automático e QoS - e seus serviços de antifrod/personalização/LLM manterão estáveis as cargas de pico de iGaming, permanecendo previsível em p99 e orçamento.