Các tác nhân lập trình đang ngày càng được sử dụng rộng rãi để tạo mã nguồn, nhưng điều này đặt ra áp lực lớn lên bộ nhớ đệm KV của hệ thống suy luận. NVIDIA Dynamo ra đời để giải quyết thách thức này, cung cấp các tối ưu hóa toàn diện ở ba lớp: API frontend, bộ định tuyến và quản lý bộ nhớ đệm KV, nhằm nâng cao hiệu suất và khả năng tái sử dụng bộ nhớ đệm cho các mô hình mã nguồn mở.

Các tác nhân lập trình và áp lực bộ nhớ đệm KV

Các tác nhân lập trình đang bắt đầu viết mã nguồn sản xuất ở quy mô lớn. Ví dụ, các tác nhân của Stripe tạo ra hơn 1.300 yêu cầu kéo (PR) mỗi tuần. Ramp cho biết 30% các PR được hợp nhất là do tác nhân tạo ra. Spotify báo cáo hơn 650 PR do tác nhân tạo ra mỗi tháng. Các công cụ như Claude Code và Codex thực hiện hàng trăm lệnh gọi API trong mỗi phiên lập trình, mỗi lệnh gọi đều mang theo toàn bộ lịch sử hội thoại. Đằng sau mỗi quy trình làm việc này là một hệ thống suy luận đang chịu áp lực lớn về bộ nhớ đệm KV.

Lấy Claude Code làm ví dụ. Sau lệnh gọi API đầu tiên ghi tiền tố hội thoại vào bộ nhớ đệm KV, mỗi lệnh gọi tiếp theo đến cùng một worker sẽ đạt tỷ lệ truy cập bộ nhớ đệm từ 85-97%. Các nhóm tác nhân (hoặc cụm tác nhân) còn đẩy tỷ lệ này lên cao hơn với tỷ lệ truy cập bộ nhớ đệm tổng hợp là 97,2% trên 4 đồng đội Opus. Tỷ lệ đọc/ghi 11,7 lần có nghĩa là hệ thống đọc từ bộ nhớ đệm gần 12 lần cho mỗi token mà nó ghi. Đây là một mô hình truy cập ghi một lần, đọc nhiều lần (WORM): lời nhắc hệ thống và tiền tố hội thoại đang phát triển được tính toán một lần, sau đó được phục vụ từ bộ nhớ đệm trong mỗi lệnh gọi tiếp theo. Việc tối đa hóa tỷ lệ tái sử dụng bộ nhớ đệm trên tất cả các worker và giữ cho các khối KV luôn sẵn sàng và có thể định tuyến là mục tiêu tối ưu hóa trọng tâm cho suy luận tác nhân.

Những con số này đến từ cơ sở hạ tầng API được quản lý, nơi nhà cung cấp kiểm soát việc khớp tiền tố, vị trí bộ nhớ đệm và việc loại bỏ. Đối với các nhóm chạy các mô hình mã nguồn mở trên GPU của riêng họ, không có điều nào trong số này có sẵn ngay lập tức. Chúng tôi đã xây dựng Dynamo để lấp đầy khoảng trống đó. Bài đăng này sẽ trình bày cách chúng tôi đang làm cho Dynamo tối ưu cho tác nhân ở ba lớp: API frontend, bộ định tuyến và quản lý bộ nhớ đệm KV. Trong suốt bài đăng này, chúng tôi sử dụng ba thuật ngữ một cách nhất quán: các bộ điều khiển tác nhân (Agent harnesses).

API Frontend: v1/responses và v1/messages

Các bộ điều khiển tác nhân đang ngày càng áp dụng v1/responses và v1/messages thay vì v1/chat/completions để xử lý gọn gàng các mẫu mới bao gồm tư duy xen kẽ và các lệnh gọi công cụ. Sự khác biệt chính trong các API này là về cấu trúc. Trong v1/chat/completions, nội dung tin nhắn là một chuỗi phẳng và các lệnh gọi công cụ được gắn vào như một trường riêng biệt. Ví dụ, hãy lưu ý cách API của GLM và MiniMax xử lý tư duy xen kẽ khác nhau khi lưu trữ mô hình của họ đằng sau điểm cuối v1/chat/completions.

Các API v1/responses và v1/messages sử dụng các khối nội dung có kiểu dữ liệu, vì vậy một lượt trả lời của trợ lý có thể chứa tư duy, lệnh gọi công cụ và văn bản dưới dạng các đối tượng riêng biệt. Điều này quan trọng đối với suy luận vì bộ điều phối có thể nhìn thấy ranh giới khối, thực hiện tối ưu hóa lời nhắc và áp dụng các chính sách bộ nhớ đệm và lập lịch khác nhau cho từng loại khối. Dynamo phục vụ cả ba điểm cuối thông qua một biểu diễn nội bộ chung, vì vậy một triển khai duy nhất có thể hoạt động như backend suy luận cho bất kỳ bộ điều khiển nào.

Nhóm của chúng tôi đã chạy một triển khai Dynamo của GLM-5 và MiniMax2.5 nội bộ để cung cấp năng lượng cho các bộ điều khiển Codex và Claude Code của chúng tôi. Điều này cho phép chúng tôi đánh giá các triển khai backend của mình so với suy luận mã nguồn đóng, nhắm mục tiêu đạt được hiệu suất tái sử dụng bộ nhớ đệm tương đương. Chúng tôi sẽ chia sẻ một bài viết đầy đủ và một số công thức tối ưu hóa để triển khai cả hai mô hình trong những tuần tới. Chúng tôi cũng đã đầu tư vào hỗ trợ phân tích lệnh gọi công cụ và suy luận ngay từ đầu cho các mô hình mã nguồn mở khác nhau. Nếu bạn thấy một mô hình không được hỗ trợ, vui lòng mở một vấn đề hoặc sử dụng kỹ năng tool-call-parser-generator để tạo nó với bộ điều khiển bạn chọn.

Bộ định tuyến: Tiện ích gợi ý tác nhân

Ngày nay, các máy chủ suy luận nhìn thấy các yêu cầu được mã hóa ẩn danh. Nhưng các bộ điều khiển tác nhân có ngữ cảnh toàn cầu mà cơ sở hạ tầng không bao giờ thấy: tác nhân nào đang bị chặn bởi các lệnh gọi công cụ, tác nhân nào vừa được tạo, còn bao nhiêu lượt trong một phiên và liệu lệnh gọi hiện tại là một tra cứu nhanh hay một tổng hợp dài. Khi sử dụng các tác nhân lập trình, người dùng chờ đợi kết quả cuối cùng, không phải các luồng token riêng lẻ, vì vậy bộ điều phối có thể sắp xếp lại và ưu tiên các yêu cầu giữa các tác nhân mà không ảnh hưởng đến trải nghiệm người dùng cuối. Các phiên chạy trong vài phút đến thậm chí vài ngày với các khoảng dừng lệnh gọi công cụ dài. Điều này đủ để tối ưu hóa lập lịch suy luận theo những cách mà việc phục vụ truyền thống không thể làm được.

Tiện ích gợi ý tác nhân mới của Dynamo được thiết kế để lấp đầy khoảng trống này. Nó cho phép bất kỳ bộ điều khiển nào đính kèm các gợi ý có cấu trúc vào một yêu cầu trên cả ba điểm cuối API, cung cấp cho bộ định tuyến và thời gian chạy ngữ cảnh cần thiết để đưa ra các quyết định lập lịch và lưu trữ có nhận biết tác nhân. Đây là một API v1 mà chúng tôi đang tích cực đồng thiết kế với cộng đồng và rất mong nhận được phản hồi từ các nhóm đang xây dựng bộ điều khiển tác nhân về những tín hiệu nào hữu ích nhất. Vui lòng liên hệ với chúng tôi nếu bạn có bất kỳ ý tưởng hoặc phản hồi nào.

Trường cache_control sẽ quen thuộc với bất kỳ ai đã sử dụng API lưu trữ lời nhắc của Anthropic. Nó yêu cầu bộ điều phối ghim tiền tố đã tính toán trên worker trong thời gian sống (TTL) đã chỉ định, bảo vệ nó khỏi bị loại bỏ trong các khoảng trống lệnh gọi công cụ. Hiện tại, ephemeral là loại duy nhất được hỗ trợ (để khớp với API của Anthropic). Chúng tôi sẽ thảo luận về cách thức hoạt động này trong phần giữ lại bộ nhớ đệm bên dưới. Bạn có thể tìm thấy tài liệu đầy đủ về gợi ý tác nhân tại đây.

Bộ định tuyến: Đặt vị trí có nhận biết KV, lập lịch ưu tiên và chiến lược định tuyến mở rộng

Một tác nhân lập trình tuân theo một mẫu tuần tự: tiền nạp dài, lệnh gọi công cụ, mở rộng tiền tố, lặp lại. Một bộ điều khiển đa tác nhân phân tán công việc trên các tác nhân phụ song song với các ngữ cảnh ngắn, độc lập. Định tuyến luân phiên mặc định không nhận biết cả hai mẫu này – nó không thể tính đến tính cục bộ của bộ nhớ đệm, ưu tiên yêu cầu hoặc cấu trúc phiên.

Bộ định tuyến của Dynamo lấp đầy khoảng trống này bằng ba cơ chế:

1. Đặt vị trí có nhận biết KV: Không có định tuyến có nhận biết bộ nhớ đệm, lượt 2 của một cuộc hội thoại có ~1/N cơ hội rơi vào cùng một worker với lượt 1. Mỗi lần bỏ lỡ là một lần tính toán lại tiền tố đầy đủ, đây là một nút thắt hiệu suất đáng kể và cực kỳ tốn kém cho người dùng cuối. Bộ định tuyến của Dynamo duy trì một chỉ mục toàn cầu về các khối bộ nhớ đệm KV tồn tại trên worker nào. Bài đăng Flash Indexer bao gồm sáu lần lặp lại đã đưa chỉ mục này lên 170 triệu hoạt động/giây (định tuyến KV quy mô toàn cầu). Trên mỗi yêu cầu, bộ định tuyến truy vấn chỉ mục để tìm điểm chồng chéo trên mỗi worker và chọn worker giảm thiểu chi phí kết hợp của việc bỏ lỡ bộ nhớ đệm và tải giải mã hiện tại. Hàm chi phí này có thể điều chỉnh được, và chúng tôi sẽ trình bày bên dưới cách các nhóm có thể xây dựng các chiến lược định tuyến có nhận biết tác nhân tùy chỉnh dựa trên nó.

   

2. Lập lịch ưu tiên: priority là nút điều khiển lập lịch hướng người dùng duy nhất. Giá trị cao hơn có nghĩa là “quan trọng hơn” ở cấp độ API Dynamo. Dynamo sử dụng gợi ý đó ở cả hai lớp.

Nguon tham khao

Full-Stack Optimizations for Agentic Inference with NVIDIA Dynamo | NVIDIA Technical Blog – developer.nvidia.com

Coding Agents and KV Cache Pressure

Coding agents are increasingly writing production code at scale, with companies like Stripe, Ramp, and Spotify reporting thousands of agent-generated pull requests monthly. These workflows, exemplified by tools like Claude Code and Codex, involve hundreds of API calls per session, each carrying full conversation history, leading to significant KV cache pressure. The system exhibits a write-once-read-many (WORM) access pattern, where conversation prefixes are computed once and then served from cache repeatedly, often with cache hit rates exceeding 97% and a read/write ratio of 11.7x. Maximizing cache reuse across workers is the primary optimization goal for agentic inference.

While managed API infrastructures handle prefix matching and cache management, teams running open-source models on their own GPUs lack these out-of-the-box capabilities. NVIDIA Dynamo is designed to bridge this gap by offering full-stack optimizations for agent-native inference across three layers: the frontend API, the router, and KV cache management.

Frontend API: v1/responses and v1/messages

Agent harnesses are shifting from v1/chat/completions to v1/responses and v1/messages. The latter APIs use typed content blocks, allowing a single assistant turn to contain distinct objects for thinking, tool calls, and text. This structural difference enables the orchestrator to see block boundaries, perform prompt optimizations, and apply specific cache and scheduling policies per block type. Dynamo supports all three endpoints through a common internal representation, allowing a single deployment to serve as the inference backend for various harnesses. NVIDIA internally uses Dynamo with GLM-5 and MiniMax2.5 to power Codex and Claude Code harnesses, benchmarking against closed-source inference for cache reuse performance. Dynamo also provides day-0 tool call and reasoning parsing support for open-source models.

Router: Agent Hints Extension

Traditional inference servers lack the global context that agent harnesses possess, such as agent status, session length, or call type. This context is crucial for optimizing inference scheduling, especially for coding agents where users await a final result, allowing the orchestrator to reorder and prioritize requests without impacting user experience. Agent sessions can last minutes to days, with long tool-call pauses, creating opportunities for advanced scheduling.

Dynamo’s new agent hints extension addresses this by allowing harnesses to attach structured hints to requests across all API endpoints. These hints provide the router and runtime with the necessary context for agent-aware scheduling and caching decisions. The cache_control field, similar to Anthropic’s prompt caching API, instructs the orchestrator to pin computed prefixes on workers for a specified TTL, preventing eviction during tool call gaps. Currently, ephemeral is the only supported type.

Router: KV-aware Placement, Priority Scheduling, and Extensible Routing Strategies

Coding agents often follow sequential patterns (long prefill, tool call, extend prefix, repeat), while multi-agent harnesses fan out work across parallel subagents. Default round-robin routing is inefficient as it’s blind to cache locality, request priority, and session structure. Dynamo’s router overcomes this with three mechanisms:

1. KV-aware placement: The router maintains a global index of KV cache blocks across workers (the Flash Indexer, capable of 170M ops/s). For each request, it queries this index to determine per-worker overlap scores and selects the worker that minimizes the combined cost of cache miss and current decode load. This cost function is tunable, allowing for custom agent-aware routing strategies.

2. Priority scheduling: A single user-facing priority knob at the Dynamo API level is used by Dynamo at both routing and runtime layers to prioritize requests.

Reference

Full-Stack Optimizations for Agentic Inference with NVIDIA Dynamo | NVIDIA Technical Blog – developer.nvidia.com