ai-dynamo/dynamo

▲ 91 stars today★ 8,087⑂ 1,588

A Datacenter Scale Distributed Inference Serving Framework

About ai-dynamo/dynamo

ai-dynamo/dynamo is an open-source project on GitHub, mainly written in Rust. A Datacenter Scale Distributed Inference Serving Framework It currently holds 8,087 stars and 1,588 forks with 0 open issues, and was last pushed on an unknown date (repository created unknown).

Project Overview

AI Homed tracks it on the Today's Trending board.

GitHub Repository Details

Repository ai-dynamo/dynamo · default branch - · size 0 KB · watchers 0 · source: GitHub REST API and repository README

README

Dynamo banner

License GitHub Release PyPI Ask DeepWiki Slack Community Contributors

| Docs | Roadmap | Recipes | Examples | Containers | Digest | Design Proposals | How to Contribute | Slack |

https://github.com/ai-dynamo/dynamo/blob/HEAD/简体中文

Dynamo

The open-source, datacenter-scale inference stack. Dynamo is the orchestration layer above inference engines — it doesn't replace SGLang, TensorRT-LLM, or vLLM, it turns them into a coordinated multi-node inference system. Disaggregated serving, intelligent routing, multi-tier KV caching, and automatic scaling work together to maximize throughput and minimize latency for LLM, reasoning, multimodal, and video generation workloads.

Built in Rust for performance, Python for extensibility.

Community Events

| Date | Event | Location | |:-----|:------|:---------| | Thu, Sep 10, 2026 | ~~Baseten x Dynamo x SGLang RL post training meetup~~ | Luma | | Mon, Aug 24, 2026 | ~~vLLM x Dynamo meetup~~ | Luma |

Events are updated automatically. Subscribe to our public calendar.

When to use Dynamo

If you're running a single model on a single GPU, your inference engine alone is probably sufficient.

Feature support at a glance:

| | SGLang | TensorRT-LLM | vLLM | |---|:----:|:----------:|:--:| | Disaggregated Serving | ✅ | ✅ | ✅ | | KV-Aware Routing | ✅ | ✅ | ✅ | | SLA-Based Planner | ✅ | ✅ | ✅ | | KVBM | 🚧 | ✅ | ✅ | | Multimodal | ✅ | ✅ | ✅ | | Tool Calling | ✅ | ✅ | ✅ |

Full Feature Matrix → — LoRA, request migration, speculative decoding, and feature interactions.

Key Results

| Result | Context | |--------|---------| | 7x higher throughput per GPU | DeepSeek R1 on GB200 NVL72 w/ Dynamo vs B200 without (InferenceX) | | 7x faster model startup | ModelExpress weight streaming (DeepSeek-V3 on H200) | | 2x faster time to first token | KV-aware routing, Qwen3-Coder 480B (Baseten benchmark) | | 80% fewer SLA breaches | Planner autoscaling at 5% lower TCO (Alibaba APSARA 2025 @ 2:50:00) | | 750x higher throughput | DeepSeek-R1 on GB300 NVL72 (InferenceXv2) |

What Dynamo Does

Most inference engines optimize a single GPU or a single node. Dynamo is the orchestration layer above them — it turns a cluster of GPUs into a coordinated inference system.

https://github.com/ai-dynamo/dynamo/blob/HEAD/Dynamo architecture overview

Architecture Deep Dive →

Core Capabilities

| Capability | What it does | Why it matters | |------------|-------------|----------------| | Disaggregated Prefill/Decode | Separates prefill and decode into independently scalable GPU pools | Maximizes GPU utilization; each phase runs on hardware tuned for its workload | | KV-Aware Routing | Routes requests based on worker load and KV cache overlap | Eliminates redundant prefill computation — 2x faster TTFT | | KV Block Manager (KVBM) | Offloads KV cache across GPU → CPU → SSD → remote storage | Extends effective context length beyond GPU memory | | ModelExpress | Streams model weights GPU-to-GPU via NIXL/NVLink | 7x faster cold-start for new replicas | | Planner | SLA-driven autoscaler that profiles workloads and right-sizes pools | Meets latency targets at minimum total cost of ownership (TCO) | | Grove | K8s operator for topology-aware gang scheduling (NVL72) | Places workloads optimally across racks, hosts, and NUMA nodes | | AISimulate | Predicts serving behavior and searches deployment configurations offline | Finds a strong serving configuration without bringing up a GPU cluster | | Fault Tolerance | Canary health checks + in-flight request migration | Workers fail; user requests don't |

New in 1.0

Request Routing Topologies

Dynamo can expose traffic through two Kubernetes request routing topologies. Both expose an OpenAI-compatible API and support the same backends, disaggregated serving, and KV-aware routing.

| Topology | What it is | When to use | |------|------------|-------------| | Dynamo-native Frontend routing | The Dynamo Frontend serves HTTP and the integrated Dynamo Router makes worker-selection decisions. No external gateway is required. | Local development, single-cluster deployments, and environments where Dynamo should own the request entry point end to end. | | Gateway API routing with GAIE | A Kubernetes Gateway API Inference Extension gateway calls the Dynamo Endpoint Picker Plugin (EPP) before forwarding to the selected worker's Frontend sidecar in --router-mode direct. | Kubernetes platforms that standardize on Gateway API, or deployments where gateway-level policy, auth, rate limiting, and observability should sit at the cluster edge. |

Request flow for the Dynamo-native path is client → Frontend → Router → workers. Request flow for the Gateway API path is client → Gateway → EPP → Frontend sidecar (direct) → workers.

See the Gateway API Inference Extension (GAIE) guide for the Gateway API setup, supported features, and configuration.

Quick Start

This repo ships agent skills: if you work with an AI coding agent (Claude Code, Codex,
Cursor), clone the repo and ask it to deploy, troubleshoot, benchmark, or optimize a Dynamo
deployment. The skills activate automatically; no setup required.

Option A: Container (fastest)

# Pull a prebuilt container (SGLang example)
docker run --gpus all --network host --rm -it nvcr.io/nvidia/ai-dynamo/sglang-runtime:1.4.2

Inside the container — start frontend and worker

python3 -m dynamo.frontend --http-port 8000 --discovery-backend file > /dev/null 2>&1 & python3 -m dynamo.sglang --model-path Qwen/Qwen3-0.6B --discovery-backend file &

Send a request

curl -s localhost:8000/v1/chat/completions -H "Content-Type: application/json" -d '{ "model": "Qwen/Qwen3-0.6B", "messages": [{"role": "user", "content": "Hello!"}], "max_tokens": 100 }' | jq

Also available: tensorrtllm-runtime:1.4.2 and vllm-runtime:1.4.2.

Option B: Install from PyPI

Install uv (curl -LsSf https://astral.sh/uv/install.sh | sh), then:

uv pip install --prerelease=allow "ai-dynamo[sglang]"   # or [vllm]
Note: TensorRT-LLM requires pip with --extra-index-url https://pypi.nvidia.com. See the install guide for TRT-LLM-specific instructions.

Then start the frontend and a worker as shown above. See the full installation guide for system dependencies and backend-specific notes.

Option C: Kubernetes (recommended)

For production multi-node clusters, install the Dynamo Platform and deploy with a single manifest:

# Zero-config deploy: specify model + SLA, Dynamo handles the rest
apiVersion: nvidia.com/v1beta1
kind: DynamoGraphDeploymentRequest
metadata:
  name: my-model
spec:
  model: Qwen/Qwen3-0.6B
  backend: vllm
  sla:
    ttft: 200.0   # ms
    itl: 20.0     # ms
  autoApply: true

Pre-built recipes for common models:

| Model | Framework | Mode | Recipe | |-------|-----------|------|--------| | Qwen3-32B-FP8 | TensorRT-LLM | Aggregated | View | | DeepSeek-R1 | SGLang | Disaggregated | View | | Kimi-K3 | vLLM | Aggregated | View |

See recipes/ for the full list. Cloud-specific guides: AWS EKS · Google GKE · Azure AKS · Amazon ECS

Building from Source

For contributors who want to build and develop locally. See the full build guide for details.

# Install system deps (Ubuntu 24.04)
sudo apt install -y build-essential libhwloc-dev libudev-dev pkg-config libclang-dev protobuf-compiler python3-dev cmake

Install Rust

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh && source $HOME/.cargo/env

Create venv and build

uv venv dynamo && source dynamo/bin/activate uv pip install pip 'maturin[patchelf]' cd lib/bindings/python && maturin develop --uv && cd $PROJECT_ROOT uv pip install -e lib/gpu_memory_service uv pip install -e .
VSCode/Cursor users: see the .devcontainer for a pre-configured dev environment.

Community and Contributing

Dynamo is built in the open with an OSS-first development model. We welcome contributions of all kinds.

Latest News

Older news

Dynamo provides comprehensive benchmarking tools:

Frontend OpenAPI Specification

The OpenAI-compatible frontend exposes an OpenAPI 3 spec at /openapi.json. To generate without running the server:

cargo run -p dynamo-llm --bin generate-frontend-openapi

This writes to docs/reference/api/openapi.json.

Service Discovery and Messaging

Dynamo uses TCP for inter-component communication. On Kubernetes, native resources (CRDs + EndpointSlices) handle service discovery. External services are optional for most deployments:

| Deployment | etcd | NATS | Notes | |------------|------|------|-------| | Local Development | ❌ Not required | ❌ Not required | Pass --discovery-backend file; vLLM also needs --kv-events-config '{"enable_kv_cache_events": false}' | | Kubernetes | ❌ Not required | ❌ Not required | K8s-native discovery; TCP request plane |

Note: KV-aware routing does not require NATS. Enable KV events when you need event-backed cache-state tracking, or use --no-router-kv-events for prediction-based routing without external event infrastructure.

For Slurm or other distributed deployments that choose etcd or NATS JetStream-backed modes:

  • etcd can be run directly as ./etcd.
  • nats needs JetStream enabled: nats-server -js.
To quickly setup both: docker compose -f dev/docker-compose.yml up -d

More News

Reference

[disagg]: docs/design-docs/disagg-serving.md [kv-routing]: docs/components/router/README.md [planner]: docs/fern/pages/developer-guide/knowledge-base/modular-components/planner/planner-guide.md [kvbm]: docs/components/kvbm/README.md [migration]: docs/fault-tolerance/request-migration.md [lora]: examples/backends/vllm/deploy/lora/README.md [tools]: docs/fern/pages/use-cases/tool-calling-and-reasoning/tool-call-parsing.mdx

GitHub Stars & Activity

8,087Stars
1,588Forks
0Open issues
RustLanguage

GitHub Popularity

GitHub stars8,087
Forks1,588
Open issues0
Primary languageRust
License-
Stars gained today91
Created-
Last pushed-

Trending History

Weekly boardrank #80 · ▲ 91 stars
Monthly boardrank #71 · ▲ 329 stars

Related AI Projects

1

openai / codex

Rust★ 124,542⑂ 19,253▲ 314 stars
2

rtk-ai / rtk

Rust★ 80,633⑂ 5,111▲ 190 stars
3

cjpais / Handy

Rust★ 31,729⑂ 2,882▲ 83 stars
4

RightNow-AI / openfang

Rust★ 18,238⑂ 2,291▲ 7 stars
5

max-sixty / worktrunk

Rust★ 7,866⑂ 272▲ 128 stars
6

pacifio / atlas

Rust★ 4,734⑂ 282▲ 91 stars
7

alphaXiv / OpenResearch

Rust★ 3,638⑂ 237▲ 531 stars
8

git-ai-project / git-ai

Rust★ 2,784⑂ 294▲ 23 stars

More AI Rankings