Model Serving

O serviço de modelos consiste em alojar um modelo de aprendizagem automática treinado por trás de um endpoint de rede, normalmente HTTP ou gRPC, para que as aplicações possam enviar entradas e receber previsões. Um sistema de serviço carrega os pesos uma vez, mantém-nos na memória em CPUs ou GPUs, aceita muitos pedidos simultâneos, agrupa-os em lotes, adiciona ou remove réplicas conforme o tráfego muda, troca versões do modelo e comunica o seu estado. A Google publicou o TensorFlow Serving como código aberto em fevereiro de 2016 para executar modelos TensorFlow em produção, e o serviço de modelos é atualmente a parte de execução das operações de aprendizagem automática (MLOps), entre o empacotamento de um modelo e a monitorização das respetivas previsões.

Como um sistema de serviço processa pedidos#

Cada pedido passa pela validação, pelo pré-processamento — como descodificar e redimensionar uma imagem —, por uma fila, pelo próprio modelo e pelo pós-processamento, que gera um formato de resposta como JSON. É na fila que se tomam a maioria das decisões de serviço. O processamento dinâmico em lotes retém os pedidos durante alguns milissegundos para que o acelerador processe várias entradas numa única passagem direta, aumentando o débito com um pequeno custo de latência de inferência. Quando a fila está cheia, o servidor rejeita novos pedidos com o código HTTP 429 para que os clientes reduzam o ritmo.

As equipas responsáveis pelo serviço acompanham percentis de latência como p95 e p99, o débito em pedidos por segundo, a utilização do acelerador, a taxa de erros e o tempo de arranque a frio, ou seja, o atraso até uma réplica aumentada a partir de zero poder responder. As versões são implementadas gradualmente: uma versão canário envia uma pequena parte do tráfego para o novo modelo, e uma implementação em sombra envia-lhe cópias dos pedidos em tempo real sem devolver as respetivas respostas.

Esta aplicação FastAPI carrega o YOLO26 uma vez no arranque e devolve as deteções como JSON. O TestClient do FastAPI envia um pedido através de toda a pilha HTTP no mesmo processo, pelo que o exemplo é executado sem iniciar um servidor:

from fastapi import FastAPI
from fastapi.testclient import TestClient
from ultralytics import YOLO

app = FastAPI()
model = YOLO("yolo26n.pt")  # carrega os pesos uma vez, quando o servidor arranca


@app.get("/predict")
async def predict(url: str):
    """Detect objects in the image at `url` and return them as JSON."""
    results = model(url)
    return results[0].summary()


client = TestClient(app)
response = client.get("/predict", params={"url": "https://ultralytics.com/images/bus.jpg"})
print(response.status_code, response.json()[0])

O resultado apresenta o estado 200 e a primeira deteção como um dicionário com o nome da classe, a confiança e as coordenadas da caixa, a estrutura que summary() produz para cada objeto detetado. Como o gestor é async def, o FastAPI executa-o num único ciclo de eventos, pelo que o modelo partilhado nunca processa dois pedidos em simultâneo. Os servidores que precisam de paralelismo executam vários processos de trabalho, cada um a carregar o seu próprio modelo.

Padrões e software para servir modelos#

A forma de servir um modelo depende do momento em que as respostas são necessárias, desde a inferência em tempo real em transmissões de câmaras até às tarefas noturnas:

• Serviço em linha: Cada pedido recebe uma resposta enquanto o utilizador aguarda, através de REST ou gRPC, como acontece em aplicações para utilizadores e transmissões de câmaras em direto.
• Serviço em lotes: Uma tarefa agendada avalia um conjunto de dados grande offline, como uma execução noturna sobre um dia de imagens, e otimiza o débito em detrimento da latência.
• Transmissão em contínuo: Os resultados são enviados continuamente à medida que chegam fotogramas de vídeo ou leituras de sensores.
• IA de periferia: O modelo é executado no próprio dispositivo, muitas vezes após a exportação para um formato otimizado, sem comunicação de ida e volta pela rede.

O software de serviço para fins gerais inclui o NVIDIA Dynamo-Triton, anteriormente Triton Inference Server, bem como o TensorFlow Serving, Ray Serve, BentoML e KServe no Kubernetes. O TorchServe do PyTorch está em manutenção limitada, sem atualizações futuras previstas. Os servidores de LLM, como vLLM, SGLang e TensorRT-LLM, acrescentam processamento contínuo em lotes e gestão paginada da cache KV para a geração token a token. A maioria destes sistemas é executada em contentores, para que o modelo, o ambiente de execução e as dependências sejam distribuídos numa única imagem.

Serviço de modelos, implementação e motores de inferência#

O serviço de modelos está estreitamente ligado a alguns termos próximos. A implementação de modelos é o processo mais abrangente de colocar um modelo em produção, incluindo o empacotamento, a infraestrutura e a implementação gradual; o serviço de modelos é a parte que responde aos pedidos depois de o modelo ficar ativo. Um motor de inferência, como o TensorRT, o ONNX Runtime ou o OpenVINO, executa os cálculos do modelo, e um sistema de serviço integra um ou mais motores com funcionalidades de rede, filas e escalabilidade.

A Ultralytics Platform serve modelos YOLO através de endpoints dedicados, cada um deles um serviço de inquilino único numa das 42 regiões, com rotas /predict, /health e /docs geradas automaticamente. O tamanho predefinido reduz a escala a zero quando está inativo e pode demorar cerca de um minuto a arrancar; ao substituir o modelo, o URL do endpoint mantém-se, enquanto o modelo anterior continua a servir pedidos até o novo estar pronto.