NVIDIA Dynamo: otimizações full-stack para inferência agêntica

O problema: pressão extrema no KV cache

Agentes de código estão gerando código de produção em escala real. Os agentes da Stripe geram mais de 1.300 PRs por semana. A Ramp atribui 30% dos PRs mesclados a agentes. O Spotify reporta mais de 650 PRs gerados por agentes por mês. Ferramentas como Claude Code e Codex fazem centenas de chamadas de API por sessão de codificação, cada uma carregando o histórico completo da conversa. Por trás de todos esses fluxos de trabalho há uma stack de inferência sob pressão significativa de KV cache.

Tomando o Claude Code como exemplo: após a primeira chamada de API que grava o prefixo da conversa no KV cache, cada chamada subsequente ao mesmo worker atinge 85–97% de cache hit. Times de agentes (ou swarms) elevam isso ainda mais, com 97,2% de taxa de cache hit agregada em 4 companheiros Opus. Uma razão de leitura/escrita de 11,7x significa que o sistema lê do cache quase 12 vezes para cada token que escreve. Esse é um padrão de acesso WORM (write-once-read-many): o system prompt e o prefixo de conversa crescente são computados uma vez e depois servidos do cache em cada chamada subsequente.

Esses números vêm de infraestrutura de API gerenciada onde o provedor controla o prefix matching, o posicionamento do cache e a evicção. Para times rodando modelos open-source em suas próprias GPUs, nada disso existe out of the box. O Dynamo foi construído para fechar essa lacuna.

---

Terminologia usada no post

• Harness: framework de agente que conduz o fluxo de trabalho (Claude Code, Codex, OpenClaw, OpenCode, etc.)
• Orchestrator: camada de roteamento, scheduling e gerenciamento de KV cache do Dynamo
• Runtime: engine de inferência que executa o modelo e possui o gerenciador de KV cache (SGLang, vLLM, TRT-LLM)

---

Camada 1: O frontend

Suporte multi-protocolo

Harnesses de agentes estão adotando cada vez mais `v1/responses` e `v1/messages` em vez de `v1/chat/completions` para lidar com padrões novos como thinking intercalado e tool calls. A diferença-chave é estrutural: em `v1/chat/completions`, o conteúdo da mensagem é uma string plana e tool calls são acoplados como campo separado. Já as APIs `v1/responses` e `v1/messages` usam blocos de conteúdo tipados — um único turno do assistente pode conter thinking, tool calls e texto como objetos distintos. Isso importa para inferência porque o orchestrator consegue ver os limites dos blocos, realizar otimizações de prompt e aplicar políticas diferentes de cache e scheduling por tipo de bloco.

O Dynamo serve os três endpoints por meio de uma representação interna comum, então um único deployment pode funcionar como backend de inferência para qualquer harness.

Agent hints: a interface Harness–Orchestrator

Hoje, servidores de inferência veem apenas requisições tokenizadas anônimas. Mas harnesses de agentes têm contexto global que a infraestrutura nunca enxerga: quais agentes estão bloqueados em tool calls, quais acabaram de ser criados, quantos turnos restam em uma sessão, se a chamada atual é uma consulta rápida ou uma síntese longa.

A nova extensão agent hints do Dynamo foi projetada para fechar essa lacuna. Ela permite que qualquer harness anexe hints estruturados a uma requisição nos três endpoints de API, dando ao roteador e ao runtime o contexto necessário para decisões de scheduling e caching conscientes de agentes.

```json { "model": "MiniMaxAI/MiniMax-M2.5", "messages": [...], "tools": [...], "nvext": { "agent_hints": { "osl": 256, "speculative_prefill": true, "priority": 10 }, "cache_control": { "type": "ephemeral", "ttl": "1h" } } } ```

Os campos de `agent_hints`:

• `priority`: controla o scheduling tanto no roteador quanto na engine. Valores mais altos significam "mais importante"; o Dynamo traduz isso em ordenação de fila no roteador e prioridade de engine no backend.
• `osl` (output sequence length): estimativa do harness de quantos tokens a requisição vai gerar. O roteador usa isso para avaliar por quanto tempo um worker ficará ocupado, melhorando o balanceamento de carga.
• `speculative_prefill`: sinaliza ao orchestrator para começar a cachear o prefixo da requisição em um worker provável antes que a requisição completa esteja pronta — útil quando o harness sabe que uma tool call está prestes a retornar.

O campo `cache_control` instrui o orchestrator a fixar o prefixo computado no worker pelo TTL especificado, protegendo-o de evicção durante pausas de tool call.

---

Camada 2: O roteador

Um agente de codificação segue um padrão sequencial: prefill longo, tool call, extensão do prefixo, repetição. O roteamento round-robin padrão é cego a esses padrões — não consegue considerar localidade de cache, prioridade de requisição ou estrutura de sessão. O roteador do Dynamo fecha essa lacuna com três mecanismos:

Posicionamento KV-aware

Sem roteamento consciente de cache, o turno 2 de uma conversa tem ~1/N de chance de cair no mesmo worker que o turno 1. Cada miss é uma recomputação completa do prefixo. O roteador do Dynamo mantém um índice global de quais blocos de KV cache existem em quais workers (o Flash Indexer, que chegou a 170M ops/s). A cada requisição, o roteador consulta o índice para scores de sobreposição por worker e seleciona o worker que minimiza o custo combinado de cache miss e carga de decode atual.

Priority scheduling

Requisições de maior prioridade entram em uma `BinaryHeap<QueueEntry>` ordenada por tempo de chegada efetivo — prioridade mais alta faz a requisição parecer que chegou mais cedo, colocando-a à frente de trabalho de menor prioridade. Abaixo de um threshold de carga configurável, as requisições ignoram a fila completamente e vão direto para seleção de worker.

Estratégias de roteamento customizadas

O roteador expõe bindings Python para implementar estratégias customizadas. A classe `KvRouter` fornece `best_worker()`, `get_potential_loads()` e `generate()`. O time do NeMo Agent Toolkit (NAT) usou essas APIs para construir um roteador agêntico com aprendizado online usando um bandit estilo Thompson Sampling que aprende quais workers performam melhor para quais padrões de prefixo sob carga. Comparado ao roteamento padrão do Dynamo, eles mediram:

• Redução de 4x no p50 TTFT
• Aumento de 1,5x no p50 tokens-per-second
• Redução de até 63% no p50 TTFT para requisições latency-sensitive sob pressão moderada de memória

---

Camada 3: Gerenciamento de KV cache

Workloads agênticos produzem blocos com valores de reuso vastamente diferentes — system prompts reutilizados a cada turno, tokens de reasoning nunca reutilizados — mas a evicção LRU padrão trata todos os blocos de forma idêntica. Uma pausa de 2–30 segundos em uma tool call pode envelhecer o prefixo inteiro de um agente, forçando recomputação completa quando ele retoma.

O problema da evicção uniforme

| Tipo de bloco | Padrão de reuso | Valor | |---|---|---| | System prompt + definições de tools | A cada turno | Altíssimo | | Histórico de conversa | Turnos subsequentes, crescendo monotonicamente | Alto | | Tokens de thinking/reasoning | Tipicamente zero reuso após o loop de reasoning fechar | Quase zero | | KV de subagente | Múltiplos turnos e depois o agente morre | Quase zero |

Hierarquia de memória em 4 camadas

Soluções como o HiCache do SGLang e o KV Block Manager (KVBM) do Dynamo estão construindo uma hierarquia de memória de 4 camadas: GPU → CPU → NVMe local → armazenamento remoto.

Blocos seguem um caminho write-through: quando um worker computa KV para um prefixo, os blocos fluem de GPU para CPU para disco automaticamente. Cada bloco é deduplicado por hash de sequência em um registro global. Uma vez registrado, o bloco é imutável e endereçável por qualquer worker que consiga alcançar a camada de armazenamento.

Isso resolve diretamente o problema de cold-start de subagentes: quando o agente líder computa definições de tools e system prompt, esses blocos são gravados no armazenamento compartilhado. Quando o subagente 1 é criado em um worker diferente, o roteador consulta o Flash Indexer, encontra os blocos no armazenamento compartilhado e o worker os carrega via NIXL (RDMA read) em vez de recomputar do zero. Quatro computações redundantes de prefill se tornam uma computação e três carregamentos.

Em análise de sessões de time do Claude Code, foi medido diretamente: companheiros de time tiveram em média 79,4% de cache hit rate vs. 91,3% para os subagentes explore do agente líder (razão de leitura/escrita de 5,0x vs. 11,7x), com a diferença impulsionada quase inteiramente por cold-start writes na primeira chamada de cada companheiro.

Retenção seletiva de cache

• SGLang e vLLM suportam evicção baseada em prioridade via priority heap
• TensorRT-LLM vai além com `TokenRangeRetentionConfig`, que permite controle por região dentro de uma única requisição

O harness pode expressar: "blocos do system prompt são evictados por último (prioridade: 100); contexto de conversa sobrevive a uma tool call de 30 segundos (duração: 45s); tokens de decode são os primeiros a sair (prioridade: 1)" — sem que a engine precise entender o porquê.

A API `cache_control` do Dynamo traz a mesma semântica do prompt caching da Anthropic para inferência self-hosted.

Consciência do ciclo de vida do agente

Em uma sessão típica do Claude Code, o agente líder roda por 20+ turnos, acumulando um prefixo crescente. Ao longo do caminho, ele cria subagentes explore que rodam 1–3 turnos e terminam. Pode criar um time de 4 especialistas que trabalham em paralelo e depois terminam. No meio do caminho, o agente pode atingir um limite de contexto e resumir seu histórico, comprimindo ~175K tokens para ~40K. Cada um desses eventos produz KV efêmero que nunca será referenciado novamente.

Modelos de reasoning amplificam isso: blocos `<think>...</think>` respondem por ~40% dos tokens gerados mas se tornam efêmeros no momento em que o loop de reasoning fecha.

A engine pode detectar limites `<think>` durante a geração e marcar esses blocos como efêmeros no momento da inserção, para que pulem o write-back para L2 e sejam evictados antes de blocos normais sem nenhum sinal externo.

---

Fechando a lacuna

A maior superfície de otimização em inferência agêntica é a lacuna entre o que o harness sabe e o que a infraestrutura consegue ver. `nvext.agent_hints` é a primeira versão dessa ponte: um pequeno conjunto de sinais estruturados que permitem ao orchestrator tomar decisões informadas de roteamento, scheduling e gerenciamento de cache em vez de tratar cada requisição como tokens anônimos.

A NVIDIA está ativamente co-desenvolvendo essa API v1 com a comunidade e busca feedback de times que constroem harnesses de agentes. Contato via GitHub ou X: @0xishand, @KranenKyle, @flowpow123.