Capítulo 11 — A Camada de Plataforma e Orquestração

Décimo primeiro post do passeio capítulo a capítulo pelo LLM Primer VI: Escalando Sistemas de IA. O capítulo que sustenta que a escolha de plataforma não é sobre features, mas sobre qual modelo operacional se encaixa na cultura de ops que o time já tem.

Por que este capítulo existe

Um engine encapsula um modelo em uma GPU e produz tokens. Essa é sua descrição de cargo por completo. No momento em que a produção precisa de duas réplicas atrás de um load balancer, ou de dois engines diferentes sob um único endpoint, ou de um pipeline que rode embed→retrieval→rerank→geração como uma única chamada lógica, ou de um sistema de cotas para impedir que um tenant afogue os demais, ou de um autoscaler que adiciona réplicas conforme cresce a fila, o engine acabou de esgotar suas respostas. O capítulo 11 percorre as quatro plataformas que dominam esse papel em 2026 — Ray Serve, KServe, BentoML, Triton Inference Server — e defende que a escolha entre elas é uma pergunta de encaixe com a cultura de ops do time, não uma pergunta de features.

11.1 Ray Serve é Python-first; KServe é Kubernetes-first

Ray Serve é a plataforma que emerge quando a pergunta inicial é "como seria um framework de serving se eu nunca precisasse sair de Python para compor, escalar e implantar um pipeline de modelo?" A resposta é: classes Python decoradas como atores, ligadas por chamadas de função Python, replicadas, alocadas e autoescaladas pelo runtime do Ray. Deployments compõem pipelines chamando os métodos uns dos outros; o pipeline é Python, a observabilidade é Python, a história de ops é Python. É a escolha natural quando o mesmo cluster já roda Ray para treinamento. KServe emerge do ponto de partida oposto: Kubernetes-first, vendor-neutral, declarativo. Um InferenceService do KServe é um CRD que captura onde vivem os pesos, qual runtime os serve e como o autoscaling deve se comportar. A plataforma conecta os pods pelo Knative para scale-to-zero e pelo Istio para roteamento de tráfego, expondo um endpoint HTTP estável. O trade-off é expressividade — a composição de pipeline no KServe é mais dirigida por YAML do que no Ray Serve — em troca de portabilidade e padronização.

11.2 BentoML empacota; Triton faz batching de modelos heterogêneos

O BentoML adota uma terceira postura: o papel primário da plataforma é transformar modelo + código + dependências em um artefato único e coerente — um Bento — e tornar o deploy desse artefato em qualquer lugar (Kubernetes, Lambda, Cloud Run, uma VM comum) uma operação de um comando. É o que a imagem Docker é para aplicações em geral, aplicado à camada de serving de modelos. A experiência de autoria é Python no formato FastAPI; a história de deploy é a movida artifact-first. Melhor encaixe: pegada operacional pequena e um time que quer o caminho mais rápido entre "classe Python" e "endpoint implantado que roda em qualquer lugar". O Triton Inference Server é o batcher dinâmico de nível corporativo que historicamente dominou o serving alinhado à NVIDIA. Ele hospeda TensorFlow, PyTorch, ONNX, TensorRT, TensorRT-LLM e backends Python lado a lado, aplica seu batcher dinâmico a cargas não-LLM (recomendadores, classificadores, embedders) e usa o scheduler de batching contínuo para LLMs sob seu backend TensorRT-LLM. Melhor encaixe: cargas heterogêneas ou um time já embebido na pilha NVIDIA.

11.3 As quatro escolhas se dividem pela afinidade com a cultura de ops

As quatro plataformas se dividem de forma limpa. Python e Ray como centro de gravidade → Ray Serve. Kubernetes, manifestos declarativos, portabilidade multi-cloud, isolamento multi-tenant → KServe. Pegada de ops pequena, caminho mais rápido de classe a endpoint → BentoML. Cargas heterogêneas ou casa NVIDIA-first → Triton. Elas não são mutuamente exclusivas no nível organizacional: um padrão comum em orgs maiores é Triton para os LLMs de produção de maior volume, Ray Serve para os pipelines de RAG e agente que compõem várias chamadas de modelo, KServe como o guarda-chuva que impõe multi-tenancy, e BentoML dentro dos ambientes de desenvolvedor. O exercício útil na hora de escolher é listar três propriedades operacionais das quais o time absolutamente precisa e três das quais absolutamente pode abrir mão, e então ordenar as plataformas contra essa lista. Resista à plataforma que "suporta tudo" — cada plataforma suporta bem seu núcleo e mal sua periferia, e aquela cujo núcleo sobrepõe os itens obrigatórios é a que o time terá prazer em operar.

O que o capítulo 11 prepara

A fronteira engine/plataforma é limpa quando a unidade de replicação é um pod dono de um modelo em uma GPU num nó. Ela deixa de ser limpa no instante em que honramos o fato do capítulo 1 de que prefill e decodificação são cargas contraditórias. O capítulo 12 as separa em pools de GPU distintos, transporta a KV cache entre os pools pelo fabric de rede e expressa a divisão em primitivas de Kubernetes — LeaderWorkerSet, PodCliqueSet do Grove, sensibilidade topológica do KAI Scheduler. A camada de plataforma é o que torna a divisão operável; a camada de plataforma é o motivo pelo qual a divisão é sequer expressável.

Próximo — Capítulo 12: Serving Desagregado e Kubernetes. Separar prefill e decodificação em pods distintos e as primitivas de Kubernetes que expressam a divisão.