A corrida para construir modelos maiores parece estar desacelerando um pouco. O que está acelerando é a demanda por servir esses modelos de forma eficiente — e o custo de inferência é onde muita empresa está quebrando a cabeça agora.

O NVIDIA Dynamo foi anunciado no GTC 2025, em março daquele ano, como resposta direta a esse problema. Não é um novo motor de inferência. É uma camada de orquestração que senta em cima do vLLM, SGLang ou TensorRT-LLM e cuida do que esses frameworks não fazem: distribuir o trabalho entre múltiplas GPUs de forma inteligente, eliminar recomputações desnecessárias e separar fisicamente as fases de prefill e decode.

Em testes com DeepSeek-R1 em GPUs NVIDIA Blackwell, o Dynamo entregou até 30x mais throughput comparado a um cluster de workers sem disaggregação (prefill e decode no mesmo processo). Com Llama 2 70B em Hopper, o ganho foi de 2x. Esses números vêm das publicações oficiais da NVIDIA — vale entender o que está por trás deles.

O gargalo real não é o treinamento

Treinar um LLM custa muito, mas acontece uma vez. Servir esse modelo em produção acontece bilhões de vezes. É aqui que está o problema real.

A inferência de um LLM tem duas fases com perfis computacionais muito diferentes. A fase de prefill processa o prompt inteiro de uma vez: é compute-bound, usa pesado a capacidade de multiplicação de matrizes da GPU e gera os KV caches para todos os tokens de entrada simultaneamente. A fase de decode gera um token por vez, de forma autoregressiva: é memory-bandwidth-bound, fica lendo o KV cache a cada passo, mas a computação propriamente dita é relativamente leve.

O problema de colocar as duas fases no mesmo worker é que elas brigam pelos mesmos recursos. Durante o prefill de uma requisição longa, os tokens do decode de outras requisições esperam. O TTFT (Time To First Token) e o ITL (Inter-Token Latency) sobem. Para modelos de raciocínio como DeepSeek-R1, que geram longas chains of thought antes de responder, isso é especialmente ruim: o prompt processado pode ter centenas de tokens, bloqueando tudo enquanto o prefill termina.

Dynamo: um orquestrador, não um motor de inferência

Uma distinção que vai te poupar confusão: o Dynamo não substitui o vLLM, o SGLang ou o TensorRT-LLM. Ele senta em cima deles.

A analogia que faz mais sentido é a de um gerente de cozinha em um restaurante grande. Os cozinheiros (os backends de inferência) sabem cozinhar. O que o gerente faz é receber os pedidos, decidir qual cozinheiro está mais preparado para aquela tarefa agora, e garantir que os insumos cheguem na hora certa. O Dynamo é esse gerente.

Tecnicamente, o framework resolve três problemas que os motores de inferência individuais não abordam: quando desagregar prefill e decode em workers separados, para qual worker rotear cada requisição (com base no estado do KV cache), e como transferir o KV cache entre GPUs sem bloquear os passes do modelo. O núcleo foi escrito em Rust para baixa latência no plano de controle, segundo a documentação técnica do projeto, com a camada de extensibilidade em Python para facilitar integração com o ecossistema existente.

Como funciona o disaggregated serving

A ideia de separar prefill e decode não é nova na pesquisa. Artigos acadêmicos como o Splitwise já exploravam isso antes do Dynamo. O que o Dynamo traz é uma implementação de larga escala com suporte simultâneo a múltiplos backends (vLLM, SGLang, TensorRT-LLM) disponível como open source — diferencial não presente em frameworks anteriores de disaggregação como DistServe.

Com disaggregated serving ativado, existem dois pools de workers. Um pool é dedicado ao prefill: recebe o prompt, processa todos os tokens de entrada em paralelo e gera o KV cache. O outro pool é dedicado ao decode: recebe o KV cache transferido e gera os tokens de saída um a um. Cada pool pode ser escalado independentemente. Se a maioria das requisições tem prompts longos, adiciona-se capacidade de prefill. Se a demanda é por geração rápida de respostas curtas, escala-se o decode.

O Dynamo Planner decide dinamicamente se usa disaggregação ou não para cada requisição, monitorando métricas de SLO (Service Level Objective) como TTFT e ITL em tempo real. Nem toda requisição vale a latência adicional da transferência de KV cache. Requisições com prompts curtos muitas vezes são mais rápidas no modo acoplado.

NIXL e a transferência eficiente do KV cache

Transferir KV cache entre GPUs parecia um gargalo óbvio até o Dynamo resolver isso de forma elegante.

O NIXL (NVIDIA Inference Xfer Library) usa RDMA (Remote Direct Memory Access) para mover tensores diretamente de VRAM para VRAM, sem passar pela CPU. A transferência é assíncrona e não bloqueia o GPU forward pass. Enquanto os dados viajam entre workers, as GPUs continuam servindo outras requisições.

O KV Cache Manager do Dynamo é agnóstico de backend: funciona com TensorRT-LLM, SGLang, vLLM e PyTorch, o que significa que você não precisa trocar de engine de inferência para ganhar os benefícios da disaggregação.

# NIXL é desenvolvido como projeto separado
# Repositório oficial para quem quiser explorar a implementação
git clone https://github.com/ai-dynamo/nixl

O NIXL expõe uma API de transferência que o Dynamo usa internamente. Times que desenvolvem backends customizados podem integrá-lo diretamente para transferências GPU-to-GPU de alta performance.

Roteamento inteligente e Dynamo Planner

O roteamento do Dynamo vai além do round-robin tradicional. Ao receber uma requisição, o Planner verifica qual worker tem o maior KV cache hit rate para aquela sequência de tokens.

Isso faz diferença em cenários de conversação onde partes do contexto se repetem entre requisições. Se um worker já processou o system prompt antes, ele já tem parte do KV cache disponível. O Dynamo roteia para lá, evitando recomputação do início.

O Planner monitora continuamente a capacidade disponível em cada GPU, as métricas de TTFT e ITL por worker, a taxa de cache hit e os SLOs configurados pela aplicação. Quando um worker está saturado ou as métricas de latência ultrapassam os SLOs, o Planner pode acionar autoscaling de GPUs com integração nativa ao Kubernetes.

Primeiros passos com o Dynamo

A forma mais rápida de testar é via pip com o backend de sua preferência:

# Instalar com suporte a SGLang
pip install uv
uv pip install "ai-dynamo[sglang]"

# Ou com vLLM
uv pip install "ai-dynamo[vllm]"

# Ou com TensorRT-LLM
uv pip install "ai-dynamo[trtllm]"

Os comandos abaixo são para o v0.8.1. A partir do v0.9.0 (fevereiro de 2026), NATS e etcd foram removidos da arquitetura em favor de ZMQ e service discovery nativo do Kubernetes. Para o v0.8.1, o Docker Compose do repositório sobe os serviços necessários:

git clone https://github.com/ai-dynamo/dynamo
cd dynamo
git checkout v0.8.1
docker compose -f deploy/docker-compose.yml up -d

Depois de subir os serviços de infraestrutura, inicia-se o frontend OpenAI-compatível e um worker de inferência:

# Frontend com API compatível com OpenAI
python -m dynamo.frontend

# Worker SGLang com um modelo disponível no Hugging Face
python -m dynamo.sglang.worker deepseek-ai/DeepSeek-R1-Distill-Llama-8B

Com isso, o endpoint em localhost:8000 aceita as mesmas requisições da API da OpenAI:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="local")

response = client.chat.completions.create(
    model="deepseek-ai/DeepSeek-R1-Distill-Llama-8B",
    messages=[{"role": "user", "content": "Explique disaggregated serving em uma frase."}],
)
print(response.choices[0].message.content)

A troca de backend (SGLang por vLLM, por exemplo) não muda o contrato da API. O frontend do Dynamo abstrai isso.

Conclusão

O que o Dynamo representa é uma separação de responsabilidades que o ecossistema de LLM serving precisava. Motores como vLLM e SGLang são excelentes em extrair performance de uma GPU ou de um nó. O que faltava era uma camada que pensasse em termos de cluster: como distribuir o trabalho, quando desagregar, como transferir estado entre workers sem desperdiçar banda.

O fato de ser open source e agnóstico de backend reduz o risco de adoção. Você não troca seu stack de inferência para adotar o Dynamo; você adiciona uma camada acima. Para times que estão começando a escalar LLMs além de um único nó, a versão 0.8.1 já está estável para testes em staging, e a integração com Kubernetes melhora a cada release.

Referências pesquisadas nesta publicação