vLLM kết hợp AgentX: Tối ưu hóa toàn diện cho các tác vụ suy luận AI Agent thực tế

TL;DR: Các khối lượng công việc (workload) dạng tác nhân (agentic) đang trở thành nguồn lưu lượng truy cập chính của vLLM. Các phiên làm việc đa lượt, ngữ cảnh dài và việc tái sử dụng tiền tố (prefix) trên diện rộng đòi hỏi những tối ưu hóa trên toàn bộ hệ thống phục vụ. Bài viết này sẽ đi sâu vào cách tiếp cận phối hợp của vLLM: quản lý bộ nhớ đệm KV (KV cache), tối ưu hóa tính song song và công cụ (engine), cùng các phương pháp phân tách prefill/decode.

Được đo lường trên AgentX, một benchmark công khai về tác nhân của SemiAnalysis, vLLM đạt tới 130K token tổng cộng trên mỗi GPU-giây trên DeepSeek V4 Pro, và khả năng tương tác lên tới 376 token mỗi giây trên MiniMax M3. Trên các dòng DeepSeek V4 Pro, MiniMax M3 và Kimi K3, vLLM mang lại lợi thế về chi phí phục vụ từ 14,6 đến 106 lần so với giá API của Opus 5 (xem phần Hiệu năng).

Đặc điểm của các khối lượng công việc tác nhân: một cái nhìn cận cảnh hơn

Kể từ bài viết đầu tiên của chúng tôi về việc phục vụ các khối lượng công việc tác nhân vào tháng 5, tỷ trọng lưu lượng truy cập tác nhân vẫn tiếp tục tăng. Tính đến tháng 6 năm 2026, OpenAI báo cáo rằng Codex đã tạo ra 64% tổng số token đầu ra của cả Codex và ChatGPT trong nhóm khách hàng doanh nghiệp.

Mức tiêu thụ token ngày càng tăng này gây áp lực lên cơ sở hạ tầng phục vụ trên hai trục: chi phí và độ trễ. Hiệu quả chi phí quyết định số lượng tác nhân đồng thời có thể chạy trong một ngân sách phần cứng cố định; độ trễ quyết định tốc độ mỗi tác nhân hoàn thành các chu kỳ suy luận và sử dụng công cụ của mình. Do đó, tối ưu hóa việc phục vụ tác nhân đồng nghĩa với việc cải thiện biên độ chi phí-độ trễ tổng thể.

Để đánh giá biên độ đó dưới lưu lượng truy cập mang tính đại diện, SemiAnalysis gần đây đã phát hành AgentX, một benchmark công khai được xây dựng từ các dấu vết (trace) lập trình tác nhân trong thế giới thực. Những dấu vết này cung cấp cái nhìn cụ thể về các đặc điểm khối lượng công việc mà các hệ thống phục vụ phải đáp ứng:

Những thống kê này bắt nguồn từ cách một phiên làm việc tác nhân được xây dựng. Mỗi lượt sẽ thêm kết quả công cụ mới nhất vào ngữ cảnh đã tích lũy và gửi toàn bộ nội dung đó trở lại mô hình, vì vậy đầu vào liên tục tăng lên trong khi mỗi lượt chỉ thêm một phần prefill ngắn mới, và gần như toàn bộ yêu cầu là một tiền tố mà công cụ đã thấy trước đó. Các tác nhân phụ (subagent) hoặc là phân nhánh từ ngữ cảnh đó, hoặc bắt đầu mới hoàn toàn, và kết quả của chúng được hợp nhất trở lại tác nhân cha trước khi đưa ra câu trả lời cuối cùng. Hình 2 mô tả một phiên làm việc như vậy: sử dụng thanh trượt để chuyển từ lượt đầu tiên đến câu trả lời cuối cùng và xem bao nhiêu phần của mỗi yêu cầu là tiền tố được tái sử dụng so với prefill mới.

Những thách thức trong việc phục vụ khối lượng công việc tác nhân

Những đặc điểm khối lượng công việc này tạo ra ba thách thức cho việc phục vụ hiệu quả.

Cách tiếp cận của vLLM: tối ưu hóa trên toàn bộ hệ thống

Hình 3 tóm tắt ba mặt phẳng (plane). Phần còn lại của mục này sẽ đi sâu vào từng mặt phẳng, bắt đầu từ mặt phẳng dữ liệu (data plane).

Quản lý bộ nhớ đệm KV lai: nền tảng không ngừng phát triển

Quản lý bộ nhớ đệm KV đã là trọng tâm của vLLM kể từ khi có PagedAttention, và các khối lượng công việc tác nhân với ngữ cảnh dài gây áp lực lớn hơn lên dung lượng bộ nhớ đệm KV. Các mô hình lai hiện đại làm phức tạp thêm việc phân bổ bằng cách kết hợp cơ chế chú ý cửa sổ trượt (sliding-window) và chú ý tuyến tính (linear attention) với cơ chế chú ý đầy đủ (full attention), vốn có các khối bộ nhớ đệm khác nhau về kích thước và vòng đời.

Trình quản lý bộ nhớ đệm KV lai của vLLM giải quyết sự phức tạp này bằng một ý tưởng cốt lõi đơn giản: một trang bộ nhớ đồng nhất làm đơn vị phân bổ cơ bản, được quản lý thông qua một nhóm khối (block pool) dùng chung (Hình 4).

Một nhóm dùng chung cho phép vLLM phân bổ lại bộ nhớ linh hoạt theo nhu cầu thay vì phân vùng dung lượng tĩnh theo loại chú ý. Điều này rất quan trọng vì bộ nhớ đệm KV của full-attention tăng theo độ dài chuỗi, trong khi sliding-window và trạng thái tái phát (recurrent state) tuân theo các vòng đời và quy tắc mở rộng khác nhau. Do đó, phân vùng tối ưu sẽ thay đổi theo tính đồng thời, độ dài ngữ cảnh và các mô hình tái sử dụng tiền tố.

Sự trừu tượng hóa này tiếp tục phát triển khi các kiến trúc mới bộc lộ sự phân mảnh và kém hiệu quả trong truyền tải. Ví dụ, bố cục bộ nhớ đệm KV ban đầu của DeepSeek V4 đã phân mảnh các loại bộ nhớ đệm khác nhau thành ba nhóm kích thước và phân bổ 92 tensor riêng biệt. Như Hình 5 cho thấy, sự phân mảnh này gây lãng phí bộ nhớ do đệm (padding) và không hiệu quả cho việc truyền tải P/D cũng như giải phóng bộ nhớ đệm KV (offloading).

Bố cục bộ nhớ đệm KV đóng gói (packed) mới lưu trữ tất cả các nhóm bộ nhớ đệm và lớp trong một phân bổ liên tục trên mỗi khối thay vì 92 phân mảnh. Điều này giúp giảm chi phí truyền tải bộ mô tả và P/D, đồng thời cho phép đơn vị phân bổ nhỏ hơn khi bật trình lập chỉ mục FP4, tiết kiệm khoảng 10% bộ nhớ đệm KV.

Giải phóng bộ nhớ đệm KV phân cấp: nhóm bộ nhớ đệm KV phân tán với các chính sách lưu giữ thông minh

Để bảo toàn bộ nhớ đệm tiền tố vượt quá dung lượng bộ nhớ GPU và trên mỗi engine, vLLM đã tích hợp Mooncake Store như một nhóm bộ nhớ đệm KV phân tán, với thiết kế đã được đề cập trong bài blog trước của chúng tôi. Việc áp dụng đã tăng trưởng ổn định kể từ đó, và chúng tôi liên tục phát hành các tính năng mới cũng như cải tiến hiệu năng về dung lượng, hiệu quả và khả năng lưu giữ trên các khối lượng công việc tác nhân.

Sự tương đương về kiến trúc mô hình. Việc giải phóng bộ nhớ đệm KV vẫn là ưu tiên hàng đầu trong vLLM, với sự hỗ trợ đầy đủ cho các kiến trúc mô hình mới bao gồm chú ý thưa (sparse attention), chú ý nén (compressed attention) và chú ý tuyến tính (linear attention). Điều này được thực hiện trong khi vẫn giữ cho các tính năng khác của engine hoạt động đầy đủ và hiệu quả, bao gồm lập lịch bất đồng bộ, phân tách P/D, giải mã suy đoán (speculative decoding) và tính song song.

Giải phóng bộ nhớ đệm KV phân cấp. vLLM hỗ trợ các tầng phân cấp cho nhóm bộ nhớ đệm KV phân tán để mở rộng dung lượng hơn nữa với ổ đĩa và các nút chỉ dùng CPU bổ sung. Điều này đạt được nhờ chế độ lưu trữ độc lập của Mooncake Store trong vLLM, cho phép một client Mooncake bên ngoài quản lý nhóm CPU và tầng đĩa, đồng thời biến các worker của vLLM thành các thực thể chỉ gửi yêu cầu. Bằng cách khởi chạy một client Mooncake độc lập trên mỗi nút, chúng ta có thể tự do mở rộng nhóm bộ nhớ đệm KV bằng bộ nhớ CPU và ổ đĩa. Chúng tôi cũng đã tích hợp nhóm bộ nhớ đệm KV dùng chung phân tán với các bộ định tuyến như Dynamo và llm-d, giúp đơn giản hóa chính sách định tuyến vì các yêu cầu có thể đạt được tỷ lệ cache hit trên bất kỳ instance nào.

Tối ưu hóa hiệu năng. Các mô hình lai phải xây dựng các khóa và thực hiện tra cứu riêng biệt cho từng loại chú ý, điều này làm tăng chi phí CPU. Chúng tôi đã giảm chi phí này thông qua các cấu trúc dữ liệu hiệu quả hơn, tra cứu bất đồng bộ, chuyển công việc ra khỏi đường dẫn quan trọng (critical path) của bộ lập lịch, và các thao tác gửi/nhận song song. Chi tiết triển khai nằm trong PR#46188, PR#45444, PR#45659 và PR#47317.

Lưu giữ bộ nhớ đệm tiền tố theo phiên. Đối với các mô hình lai có các lớp tuyến tính hoặc sliding-window bên cạnh full-attention, việc tái sử dụng tiền tố đòi hỏi phải bảo toàn trạng thái tuyến tính hoặc bộ nhớ đệm sliding-window tại ranh giới tái sử dụng. Việc giữ các bản chụp (snapshot) này tại mỗi token rất tốn kém, vì vậy chúng tôi kết hợp hai chính sách bổ sung:

Lưu giữ dựa trên khoảng thời gian (Interval-based retention) tự động bảo toàn các bộ nhớ đệm cuối lời nhắc/trạng thái tuyến tính tại mỗi lượt. Các lượt tiếp theo và các tác nhân phụ được phân nhánh, vốn thường phát lại và mở rộng ngữ cảnh của lượt trước đó, sau đó có thể tái sử dụng ngữ cảnh đã lưu trong bộ nhớ đệm.

Tuy nhiên, các tiền tố dùng chung thường kết thúc trong một lượt, vì vậy việc lưu giữ dựa trên khoảng thời gian có thể không bảo toàn được điểm kiểm tra (checkpoint). Để nắm bắt việc tái sử dụng này, chúng tôi giới thiệu chính sách thứ hai:

Lưu giữ chọn lọc kiểu Marconi (Marconi-style selective retention) giữ lại một điểm kiểm tra khi một tiền tố được quan sát lần thứ hai. Khi một yêu cầu gặp một tiền tố đã quan sát trước đó mà không có điểm kiểm tra được lưu giữ, vLLM sẽ tính toán lại trạng thái bị thiếu và lưu một điểm kiểm tra tại ranh giới đó. Các yêu cầu tiếp theo chia sẻ tiền tố đó sau đó có thể tái sử dụng nó.

Cùng với nhau, các chính sách này duy trì tỷ lệ cache hit cao mà không gây ra chi phí lưu trữ quá mức trên các khối lượng công việc tác nhân quy mô lớn. Blog vLLM Kimi K3 của chúng tôi giải thích chi tiết về các khía cạnh kỹ thuật này.

Tính song song đặc thù theo mô hình

Các hệ thống suy luận hiện đại bộc lộ nhiều trục song song, chẳng hạn như song song tensor (TP), song song dữ liệu (DP), song song chuyên gia (EP), song song đường ống (PP) và song song ngữ cảnh (CP).

Tuy nhiên, tính song song tối ưu phụ thuộc vào kiến trúc mô hình, cấu trúc liên kết phần cứng, mô hình khối lượng công việc và các SLO về độ trễ. Trong phần này, chúng tôi kiểm tra hai mô hình đại diện trên GPU NVIDIA dòng GB và dòng B cùng các đối tác AMD của chúng, đồng thời thảo luận về các tối ưu hóa và phát hiện của chúng tôi.

Kimi K3

Kimi K3 có tính năng chú ý tiềm ẩn đa đầu (MLA) và Kimi Delta Attention (KDA). Vì MLA nén KV vào một không gian tiềm ẩn duy nhất với một đầu, nên song song tensor (TP) thông thường, vốn sao chép bộ nhớ đệm tiềm ẩn đó trên các rank, không thực sự hiệu quả.

Như một giải pháp thay thế cho TP, chúng tôi đã tìm thấy hiệu suất tăng đáng kể từ song song ngữ cảnh giải mã (DCP), giúp phân mảnh bộ nhớ đệm theo chiều chuỗi, để lại cho mỗi rank 1/N trạng thái KV. Cụ thể, DCP mang lại hai lợi ích cho các khối lượng công việc tác nhân (Hình 6):

Đánh đổi của DCP là giao tiếp bổ sung: bộ nhớ đệm KV được phân mảnh theo chuỗi, vì vậy mỗi lớp giải mã MLA cần một thao tác thu thập truy vấn (query gather) trước khi chú ý và giảm thiểu đầu ra một phần (partial-output reduction) sau đó.

Chúng tôi đã tối ưu hóa cẩn thận đường dẫn tính toán DCP để bỏ qua các thao tác NCCL và tránh những chi phí này. Chúng tôi sử dụng các bộ đệm bộ nhớ đối xứng mà các GPU ngang hàng có thể đọc và ghi trực tiếp. Các truy vấn được phát đa hướng (multicast) thẳng vào các bộ đệm được tiêu thụ bởi các nhân chú ý (attention kernels). Sau đó, mỗi GPU ghi các đầu ra chú ý một phần và các thống kê log-sum-exp (LSE) của nó trực tiếp vào các khe nhận của các GPU ngang hàng, nơi mỗi rank hợp nhất kết quả cục bộ với softmax trực tuyến. Các thao tác ghi GPU-to-GPU này được hợp nhất với tính toán vào cùng các nhân (Hình 7), giúp giảm độ trễ khoảng 13% mỗi lớp so với triển khai DCP mặc định.

Một miền mở rộng quy mô lớn hơn có thể thay đổi chiến lược tốt nhất. Ví dụ, trên hệ thống cấp NVL72, EP rộng với song song dữ liệu (DEP) có thể mở rộng tốt hơn DCP và mang lại thông lượng cao hơn ở cùng SLO độ trễ giải mã (Hình 8). Ở quy mô DCP đa nút lớn hơn, chi phí giao tiếp của chú ý phân mảnh vượt xa khả năng tính toán mà nó tiết kiệm được. DEP gán các yêu cầu và bộ nhớ đệm KV của chúng cho các rank song song dữ liệu khác nhau, tránh các tập hợp chú ý (attention collectives) của DCP trong khi vẫn phân mảnh các chuyên gia MoE trên các rank.

DeepSeek V4

Bài gốc còn tiếp — xem tiếp tại bài gốc ↗