A Datacenter Scale Distributed Inference Serving Framework
8,032
stars
6,877
commits
Rust
primary language
Sep 11, 2026
updated

| Docs | Roadmap | Recipes | Examples | Containers | Digest | Design Proposals | How to Contribute | Slack |
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.
| Date | Event | Location |
|---|---|---|
| Fri, Sep 4, 2026 | Dynamo Community Demos | – |
| Thu, Sep 10, 2026 | Baseten x Dynamo x SGLang RL post training meetup | Luma |
| Mon, Aug 24, 2026 | Luma | |
| Thu, Jul 30, 2026 | Luma |
Events are updated automatically. Subscribe to our public calendar.
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.
| 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) |
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.
| 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 |
| AIConfigurator | Simulates 10K+ deployment configs in seconds | Finds optimal serving config without burning GPU-hours |
| Fault Tolerance | Canary health checks + in-flight request migration | Workers fail; user requests don't |
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.
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.
# Pull a prebuilt container (SGLang example)
docker run --gpus all --network host --rm -it nvcr.io/nvidia/ai-dynamo/sglang-runtime:1.4.1
# 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.1 and vllm-runtime:1.4.1.
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
pipwith--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.
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
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
.devcontainerfor a pre-configured dev environment.
Dynamo is built in the open with an OSS-first development model. We welcome contributions of all kinds.
dep:* labeled GitHub issuesDynamo provides comprehensive benchmarking tools:
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.
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-eventsfor prediction-based routing without external event infrastructure.
For Slurm or other distributed deployments that choose etcd or NATS JetStream-backed modes:
To quickly setup both: docker compose -f dev/docker-compose.yml up -d
(top 30 of 373)
Rust
52.2%
Python
34.2%
Go
11.4%
A Datacenter Scale Distributed Inference Serving Framework
8,032
stars
6,877
commits
Rust
primary language
Sep 11, 2026
updated

| Docs | Roadmap | Recipes | Examples | Containers | Digest | Design Proposals | How to Contribute | Slack |
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.
| Date | Event | Location |
|---|---|---|
| Fri, Sep 4, 2026 | Dynamo Community Demos | – |
| Thu, Sep 10, 2026 | Baseten x Dynamo x SGLang RL post training meetup | Luma |
| Mon, Aug 24, 2026 | Luma | |
| Thu, Jul 30, 2026 | Luma |
Events are updated automatically. Subscribe to our public calendar.
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.
| 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) |
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.
| 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 |
| AIConfigurator | Simulates 10K+ deployment configs in seconds | Finds optimal serving config without burning GPU-hours |
| Fault Tolerance | Canary health checks + in-flight request migration | Workers fail; user requests don't |
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.
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.
# Pull a prebuilt container (SGLang example)
docker run --gpus all --network host --rm -it nvcr.io/nvidia/ai-dynamo/sglang-runtime:1.4.1
# 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.1 and vllm-runtime:1.4.1.
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
pipwith--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.
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
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
.devcontainerfor a pre-configured dev environment.
Dynamo is built in the open with an OSS-first development model. We welcome contributions of all kinds.
dep:* labeled GitHub issuesDynamo provides comprehensive benchmarking tools:
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.
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-eventsfor prediction-based routing without external event infrastructure.
For Slurm or other distributed deployments that choose etcd or NATS JetStream-backed modes:
To quickly setup both: docker compose -f dev/docker-compose.yml up -d
(top 30 of 373)
Rust
52.2%
Python
34.2%
Go
11.4%