NVIDIA Dynamo führt Session-IDs ein, damit Inferenzserver KI-Agenten folgen können

Warum Agenten-Traffic das anfragebasierte Serving unter Druck setzt

Der Beitrag argumentiert, dass agentische Workloads den Traffic verändert haben, den ein Inferenzserver sieht. Eine Coding-Session beginnt mit einem großen Prefill, oft Zehntausende Token aus Systemprompt, Tool-Definitionen und nutzerspezifischen Vorgaben. Jede weitere Runde hängt etwas an einen Kontext an, den die Session vollständig erneut sendet. Eine einzige Aufgabe kann sich in Dutzende solcher Aufrufe verzweigen, wobei kurz- und langlebige Subagenten parallel laufen.

Der größte Teil der Laufzeit einer Session vergeht zwischen den Tool-Aufrufen, während ihr Kontext im KV-Cache liegt und nichts generiert wird. Laut dem Beitrag hängt gutes Serving davon ab, wie viel dieses Kontexts ein System vorhält und wiederverwendet und wie viele Sessions es gleichzeitig halten kann, ohne die Latenzziele zu verfehlen.

Die Autoren sagen, die meisten Open-Source-Serving-Stacks seien weiterhin auf Single-Turn-Chat ausgelegt. Sie routen, lassen zu und cachen jede Anfrage für sich, ohne Kenntnis des Harness oder der Session, die sie mit früheren Runden verbindet.

Eine Kennung für die gesamte Aufrufkette

Eine Dynamo-Session-ID ist eine stabile Kennung für eine einzelne agentische Kette aus Denkschritten und Tool-Aufrufen. Jede LLM-Anfrage einer Trajektorie teilt dieselbe session_id, und untergeordnete Sessions tragen in der Regel eine parent_session_id, sodass Traces und Replay-Werkzeuge Agenten mit den von ihnen gestarteten Subagenten oder Teilaufgaben verbinden können. Der Beitrag betont, dass jede darin beschriebene Optimierung diese Information nur auf Opt-in-Basis nutzt.

Dynamo liest Identitäts-Header, die gängige Coding-Agenten bereits senden, und bildet sie auf einen internen agent_context ab. Laut dem Beitrag funktionieren Claude Code, Codex und OpenCode ohne Konfiguration:

• Claude Code: x-claude-code-session-id für die Wurzel, x-claude-code-agent-id für untergeordnete Agenten und x-claude-code-parent-agent-id als Parent-Header.
• Codex: thread-id, mit x-codex-parent-thread-id als Parent-Header.
• OpenCode: x-opencode-session-id, mit x-opencode-parent-session-id als Parent-Header.

Für Harnesses, die keinen kompatiblen Header senden, bietet das Repository agent-plugins drei Integrationen, die die native Session-Identität in x-dynamo-session-id übersetzen: einen Pi-Provider, eine Hermes-Middleware und einen OpenClaw-Provider. Eigene Harnesses können mit einem einzigen Header, X-Dynamo-Session-ID, teilnehmen und X-Dynamo-Parent-Session-ID ergänzen, wenn sie Subagenten unterstützen. Das Beispiel im Beitrag ist ein curl-Aufruf an einen Chat-Completions-Endpunkt mit dem Header-Wert research-run-42:researcher; eine proprietäre API sei nicht nötig.

Traces und Replay ohne gespeicherte Prompts

Die Autoren beschreiben eine Lücke, die sie Harness-Inference-Codesign nennen. Observability-Werkzeuge für Agenten erfassen, was auf Harness-Ebene geschieht, zeigen aber nicht, wie der Inferenz-Stack unter jedem Schritt abgeschnitten hat. Dynamos Antwort ist ein schlanker Trace, der über die Session-ID verschlüsselt wird und neben anderen Trace-Formaten wie Harbors ATIF oder Letta-Trajectory bestehen kann.

Das Tracing wird mit DYN_REQUEST_TRACE=1 aktiviert. Standardmäßig speichert Dynamo weder Prompt-, Antwort- noch Tool-Call-Inhalte, auch wenn sich diese aktivieren lassen. Nach dem Ende jedes Antwort-Streams schreibt es einen request_end-Eintrag mit den Session-Feldern, der Zahl der Ausgabetoken, dem Abschlussgrund, KV-Cache-Metriken, den Namen der Tool-Aufrufe und einem Replay-Block mit der Eingabelänge und Sequenz-Hashes pro Block, ähnlich dem Mooncake-Trace-Format.

Da ein Trace die vom Agenten gesendete Last aufzeichnet und nicht dessen Entscheidungen, lässt sich eine Aufzeichnung beliebig oft abspielen, ohne Modell, Tools oder externe APIs erneut auszuführen. Sequenz-Hashes werden zu synthetischen Block-IDs, die das gemeinsame Prompt-Präfix über Runden und Sessions hinweg erhalten, ohne die ursprünglichen Token preiszugeben. Offline lässt AISimulate den Anfragegraphen gegen Dynamos simulierten Scheduler, Router und KV-Cache laufen, sodass Teams Worker-Zahlen, Topologien, Routing-Richtlinien und Cache-Kapazität vergleichen können, ohne GPU-Zeit zu verbrauchen. Live spielt AIPerf denselben Graphen gegen einen echten Dynamo-Endpunkt auf echten GPUs ab.

Das Team gibt an, aufgezeichnete Traces als Backtesting-Daten für eigene Deployments genutzt zu haben. Die Daten speisen zudem interne Autoresearch-Harnesses, in denen KI Routing-Strategien erzeugt und proaktives KV-Cache-Offloading erforscht.

Scheduling- und Cache-Funktionen auf Basis der ID

Der Beitrag nennt weitere Bausteine, die auf der Session-ID aufbauen. Session-bewusstes Scheduling lässt Routing und Admission Control die Working Sets der Sessions berücksichtigen und an Tool-Grenzen Backpressure anwenden, um Cache-Thrashing zu verringern. Ein experimenteller Shared-Pool-Indexer erlaubt dem Router, wiederverwendbaren KV-Cache in externen Speichern bei der Platzierung von Anfragen mitzuzählen. Ein Session-Prefix-Indexer und eine vorgeschlagene KvHint-Schnittstelle sollen session-bewusste Cache-Richtlinien über Speicherebenen hinweg unterstützen, wobei Dynamo die Richtlinienabsicht liefert und die Inferenz-Engines die Ausführung steuern.

Was das für Anwender bedeutet

Für Teams, die Coding-Agenten auf eigener Infrastruktur betreiben, liegt der praktische Nutzen im geringen Einrichtungsaufwand: Die drei genannten Agenten brauchen keine Konfiguration, andere Harnesses können mit einem einzigen Header teilnehmen. Die Autoren sagen, sie arbeiteten mit Harness-Anbietern daran, dies überall zum Standard zu machen, und Dynamos CI verfolge jeden erstklassig unterstützten Harness bei Änderungen.

Der hier vorliegende Teil des Beitrags enthält keine Benchmark-Zahlen zu den Scheduling- oder Cache-Funktionen, ihre Wirkung auf Latenz oder Kapazität ist also nicht beziffert. Belegt wird vor allem das Fundament: eine gemeinsame Session-Kennung, mit der Serving-Infrastruktur über Agentenprogramme statt über isolierte Anfragen nachdenken kann.