Capítulo 1.8 — Model serving

🎯 Objetivo

Cobrir as quatro modalidades de serving e seus trade-offs.

🧠 Modalidades

Modalidade	Quando usar	Trade-off
Batch	Recomendações diárias, scoring em massa	Latência alta, custo baixo
Online (request/response)	Aplicações interativas	Latência baixa, custo maior
Streaming	Eventos contínuos (fraude, alertas)	Latência baixa, complexidade alta
Edge / on-device	Mobile, IoT, restrições de privacidade	Modelo pequeno, sem dependência de rede

🏗️ Padrões

• Containerização com Docker e orchestration via Kubernetes/ECS.
• Servers especializados - TF Serving, TorchServe, Triton, ONNX Runtime, Ray Serve.
• API gateway com autenticação, rate limiting e métricas.
• Auto-scaling baseado em SLO (p95) e custo.
• Warm pools para reduzir cold start.

🚨 Modos de falha

• Latência aceitável em média, inaceitável em p95/p99.
• Cold start derrubando SLO em horários de pico.
• Modelo grande gerando OOM em produção.
• Versionamento inconsistente entre pesos, código e schema.

🛡️ Mitigações

• Definir SLO em p95/p99, não em média.
• Testes de carga com perfis realistas.
• Quantização e pruning para reduzir custo.
• Canary deploy.

🧰 Exemplo prático relacionado (planejado)

• EX-ML-04 - classificador scikit-learn servido via FastAPI com Docker e health checks.

📚 Referências

• BentoML - Prefill–decode disaggregation: https://bentoml.com/llm/inference-optimization/prefill-decode-disaggregation
• NVIDIA Triton Inference Server - docs: https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/
• Ray Serve - docs: https://docs.ray.io/en/latest/serve/index.html
• TensorFlow Serving - docs: https://www.tensorflow.org/tfx/guide/serving
• TorchServe - docs: https://pytorch.org/serve/

---