Tối ưu song song hóa ngữ cảnh cho quá trình giải mã với vLLM trong các tác vụ có ngữ cảnh dài

Inference ngữ cảnh dài đang ngày càng trở nên cần thiết đối với agentic AI, khi các trợ lý AI có thể cần suy luận trên những code repository lớn và lịch sử trò chuyện dài. Các agent-trace benchmark hiện đã mở rộng từ 64 nghìn lên tới 1 triệu tokens, và KV cache tương ứng cũng trở nên rất lớn. Trong một thiết lập tensor-parallel (TP) cơ bản, KV cache được phân vùng theo attention head, từ đó tạo ra một giới hạn cứng đối với mức độ mà cache có thể được thu nhỏ.

Các model hiện đại sử dụng một trong hai cơ chế attention, và cả hai đều gặp phải giới hạn này. Các model sử dụng Grouped-Query Attention (GQA) lưu trữ một số lượng nhỏ KV head, và TP chỉ có thể chia KV cache xuống mức một head trên mỗi GPU. Khi TP vượt quá số lượng KV head, cache bắt đầu được nhân bản trên các GPU. Với các model sử dụng Multi-Head Latent Attention (MLA), vấn đề còn nghiêm trọng hơn. MLA nén Key/Value thành một vector latent có rank thấp, được chia sẻ giữa tất cả query head, vì vậy về cơ bản nó chỉ có một KV head. Với TP thông thường, không có head nào để tiếp tục phân chia, đồng nghĩa với việc toàn bộ latent KV cache được sao chép trên mọi TP rank.

Trong cả hai trường hợp, KV cache bị nhân bản sẽ chiếm dụng bộ nhớ GPU, khiến hệ thống còn rất ít dung lượng để phục vụ thêm các request. Điều này giới hạn số lượng request đồng thời mà hệ thống có thể xử lý, làm giảm throughput và tăng chi phí trên từng token.

Decode Context Parallelism (song song hóa ngữ cảnh cho giải mã) giải quyết vấn đề này bằng cách phân chia KV cache trên nhiều GPU, để mỗi GPU chỉ lưu trữ và đọc một phần của KV cache. Nhờ đó, GPU được giải phóng thêm bộ nhớ, cho phép mỗi GPU xử lý nhiều request hơn và hoạt động với batch size lớn hơn. Trên các hệ thống có kết nối GPU-to-GPU băng thông cao, phương pháp này giúp duy trì khả năng phản hồi tốt trong tương tác, ngay cả khi hệ thống phải phục vụ đồng thời nhiều agent ngữ cảnh dài.

Để đánh giá cụ thể lợi ích của Decode Context Parallelism (DCP), vLLM so sánh cách triển khai tensor parallelism (TP) cơ bản với DCP trên cùng một hệ thống GPU. Model, phần cứng và khối lượng công việc đều được giữ nguyên. Yếu tố duy nhất được thay đổi là cách KV cache được phân chia trong quá trình giải mã.

Bộ dữ liệu được sử dụng là một tập dữ liệu công khai về các tác vụ agent có ngữ cảnh dài, được xây dựng theo định dạng Mooncake trace và được công bố tại đây. Bạn có thể xem phần này để tìm hiểu thêm về bộ dữ liệu.

Dữ liệu được cung cấp dưới dạng JSONL, trong đó mỗi dòng tương ứng với một yêu cầu và chứa các trường input_length, output_length và hash_ids. Vì vậy, dữ liệu có thể được chạy lại trực tiếp bằng các công cụ tương thích với Mooncake, chẳng hạn như aiperf –custom-dataset-type mooncake_trace. Trường hash_ids mô tả các khối tiền tố được dùng chung, nhờ đó bộ dữ liệu phù hợp để đánh giá khả năng tái sử dụng KV cache và lưu đệm tiền tố.

Đây là một khối lượng công việc gồm nhiều lượt tương tác của tác nhân AI, trong đó đầu vào dài nhưng phần nội dung được tạo ra tương đối ngắn. Cách thiết kế này nhằm mô phỏng hành vi thực tế của các tác nhân AI phải xử lý thông tin trong thời gian dài.

Độ dài đầu vào có giá trị trung vị khoảng 67 nghìn token, trong khi đầu ra trung bình chỉ khoảng 400 token. Tuy nhiên, độ dài đầu vào không phân bố đồng đều. Khoảng 53% yêu cầu có từ 64 nghìn token trở lên, trong đó một số yêu cầu có thể lên tới khoảng 1 triệu token. Khoảng 47% còn lại thuộc nhóm ngắn đến trung bình, và khoảng 18% có dưới 8 nghìn token. Khoảng 8% yêu cầu vượt quá 128 nghìn token, trong khi khoảng 3 đến 4% vượt quá 256 nghìn token.

vLLM thực hiện thử nghiệm trên một máy chủ duy nhất sử dụng 8 GPU B200, chạy Kimi K2.6 ở chế độ NVFP4 với vLLM. Số lượng yêu cầu xử lý đồng thời được tăng dần từ 16 lên 512. Kết quả cho thấy DCP có thể duy trì số lượng yêu cầu đồng thời cao hơn đáng kể, đồng thời đạt tốc độ xử lý trên mỗi GPU cao hơn trong toàn bộ quá trình thử nghiệm.

Sự khác biệt chủ yếu nằm ở cách lưu trữ KV cache. Với TP cơ bản, KV cache được sao chép trên tất cả GPU, khiến bộ nhớ nhanh chóng bị sử dụng hết. Khi số lượng yêu cầu đồng thời đạt 64, bộ nhớ đạt mức 100% và hệ thống không thể tiếp nhận thêm yêu cầu. Tốc độ xử lý cũng dừng ở khoảng 1.863 token/giây/GPU vì không còn đủ bộ nhớ để xử lý thêm.

DCP hoạt động theo cách khác. KV cache được chia theo chiều dài chuỗi, vì vậy mỗi GPU chỉ cần lưu trữ một phần KV cache của từng yêu cầu. Nhờ đó, GPU có thêm bộ nhớ trống để tiếp nhận các yêu cầu mới.

Kết quả là khi số lượng yêu cầu đồng thời tăng cao, DCP vẫn có thể tiếp tục mở rộng khả năng xử lý trong khi TP đã chạm giới hạn. Ở mức 512 yêu cầu đồng thời, DCP đạt 6.091 token/giây/GPU, trong khi mức sử dụng KV cache mới chỉ khoảng 82%.

Giá trị lớn nhất của DCP là khả năng xử lý nhiều yêu cầu đồng thời hơn, đặc biệt với các tác vụ có ngữ cảnh rất dài. Đây cũng chính là nhóm tác vụ mà cách phân chia TP truyền thống dễ gặp giới hạn bộ nhớ nhất do KV cache bị sao chép trên nhiều GPU.

vLLM cũng biểu diễn hiệu năng theo tổng độ dài của chuỗi, bao gồm cả đầu vào và đầu ra. Biểu đồ cho thấy một đường biên Pareto duy nhất giữa tốc độ xử lý và khả năng tương tác, trong đó các yêu cầu được chia thành năm nhóm độ dài: dưới 32 nghìn, 32 đến 64 nghìn, 64 đến 128 nghìn, 128 đến 200 nghìn và trên 200 nghìn token. Cách phân nhóm này giúp chúng ta quan sát rõ hơn hiệu năng thay đổi như thế nào khi độ dài ngữ cảnh tăng lên.

DCP vẫn duy trì hiệu năng cao và ổn định ngay cả ở nhóm trên 200 nghìn token. Các đường biểu diễn của nhóm chuỗi ngắn và chuỗi dài gần như chồng lên nhau. Khi số lượng yêu cầu đồng thời tăng, tốc độ xử lý cũng tăng theo, trong khi tốc độ phản hồi trên mỗi người dùng vẫn ở mức có thể sử dụng được, ngay cả với ngữ cảnh rất dài. Đây là điểm mà phương pháp TP với KV cache được sao chép bắt đầu hết bộ nhớ và không thể tiếp tục mở rộng khả năng xử lý.

Trong tensor parallelism, KV cache được phân chia theo attention head. Mỗi KV head có các tensor K và V riêng, và head là đơn vị nhỏ nhất có thể phân bổ cho một GPU. TP thông thường không có cơ chế chia nhỏ KV cache bên trong một head.

Ví dụ, nếu một model có K KV head, bạn có thể phân bổ các head khác nhau cho từng GPU, nhưng chỉ có thể chia đến mức mỗi GPU giữ một head. Khi số lượng GPU trong TP vượt quá K, số head có sẵn không đủ để phân bổ riêng cho từng GPU. Khi đó, hai hoặc nhiều GPU phải giữ bản sao của cùng một KV head thay vì mỗi GPU chỉ lưu một phần dữ liệu.

Khác với phương pháp chỉ sử dụng TP, DCP có thể chia KV cache giữa các GPU theo chiều dài chuỗi, hay còn gọi là chiều ngữ cảnh. Mỗi GPU sẽ chịu trách nhiệm lưu trữ KV cache của một đoạn vị trí token trong cùng một chuỗi.

Ví dụ, với một yêu cầu dài 200 nghìn token và sử dụng 4 GPU, GPU 0 có thể lưu KV cache cho token từ 0 đến 50 nghìn, GPU 1 lưu từ 50 nghìn đến 100 nghìn, GPU 2 lưu từ 100 nghìn đến 150 nghìn và GPU 3 lưu từ 150 nghìn đến 200 nghìn.

Nhờ chia nhỏ KV cache như vậy, lượng KV cache mà mỗi GPU phải lưu trữ sẽ tiếp tục giảm khi bổ sung thêm GPU. Phần bộ nhớ được giải phóng có thể dùng để tăng batch size, từ đó cho phép hệ thống xử lý nhiều yêu cầu đồng thời hơn.

Decode Context Parallelism tiêu chuẩn giữ cho mô hình giao tiếp giữa các GPU ở mức đơn giản, theo trình tự AllGather Q → Tính toán → AllGather + ReduceScatter.

• AllGather Q: Mỗi GPU chỉ tính toán một phần của vector truy vấn (query), trong khi cơ chế attention cần toàn bộ vector query để tính điểm với mọi key. Vì vậy, các GPU trong nhóm DCP thực hiện all-gather để tập hợp đầy đủ query trên mỗi GPU. Quá trình này khá nhẹ khi decode vì query chỉ chứa một token.
• Với MLA, bạn cũng có thể chọn một phương án khác. Theo vLLM #45964, phần chiếu query nhỏ có thể được sao chép vào từng nhóm DCP ngay khi model được tải. Nhờ vậy, quá trình decode không cần thực hiện all-gather query nữa (VLLM_DCP_Q_REPLICATE=1).
• Compute: Mỗi GPU thực hiện phép tính attention giữa query đã được tập hợp và phần KV cache mà GPU đó đang lưu trữ. Trong vLLM, quá trình này sử dụng k_up đối với MLA hoặc tensor_broadcast đối với GQA.
• AllGather + ReduceScatter (cp_lse_ag_out_rs): Các kết quả một phần từ từng GPU được kết hợp để tạo thành kết quả cuối cùng. AllGather chia sẻ kết quả từng phần và giá trị LSE của mỗi GPU. Các giá trị LSE được sử dụng để điều chỉnh trọng số và kết hợp các kết quả này thông qua cơ chế online softmax. Sau đó, ReduceScatter cộng các kết quả lại và chỉ trả về cho mỗi GPU phần head mà GPU đó phụ trách.

Để bật DCP, bạn chỉ cần thêm một tham số decode_context_parallel_size bên cạnh thiết lập tensor parallel hiện có.

from vllm immaroport LLM, SamplingParams
prompts = [
"The future of AI is",
] sampling_params = SamplingParams(temperature=0.8, top_p=0.95)
llm = LLM(
model="deepseek-ai/DeepSeek-V2-Lite",
tensor_parallel_size=2,
decode_context_parallel_size=2,
)
outputs = llm.generate(prompts, sampling_params)

vllm serve deepseek-ai/DeepSeek-V2-Lite \ 
   --tensor-parallel-size 2 \ 
   --decode-context-parallel-size 2

Các model: DeepSeek-V2 / V3 / R1 và Kimi K2.6 sử dụng Multi-head Latent Attention (MLA).

Điểm khác biệt: MLA nén Key/Value thành một vector latent có số chiều thấp và được dùng chung cho tất cả query head. Vì vậy, về cơ bản MLA chỉ có một KV head. Với tensor parallelism thuần túy, không có nhiều head để chia nhỏ, nên toàn bộ KV cache dạng latent được sao chép đầy đủ trên mọi TP rank. TP không giúp giảm kích thước KV cache trong trường hợp này, khiến MLA trở thành đối tượng rất phù hợp với DCP: toàn bộ KV cache đang bị lặp lại, nên toàn bộ cache có thể được chia theo chiều dài chuỗi.

Cách DCP xử lý: DCP chia KV cache dạng latent theo chiều dài chuỗi, vì vậy mỗi rank chỉ lưu phần latent tương ứng với mình. Khi thực hiện attention, mỗi rank sẽ chuyển phần latent của mình lên lại không gian ban đầu, thông qua bước k_up, để khôi phục các Key/Value cần thiết.

Do số lượng KV head hiệu dụng chỉ là 1, chuỗi có thể được chia theo toàn bộ mức độ song song của TP. Vì vậy, có hai điều kiện:

• • • • tensor_parallel_size >= decode_context_parallel_size

• • • • tensor_parallel_size % decode_context_parallel_size == 0

vllm serve deepseek-ai/DeepSeek-R1 \ 
   --tensor-parallel-size 8 \ 
   --decode-context-parallel-size 8

Ví dụ model: Qwen3-235B và các model sử dụng Grouped-Query Attention (GQA) khác, chẳng hạn như dòng Llama.

Điểm khác biệt: GQA có num_key_value_heads KV head, và TP trước tiên chia KV cache theo các head này. Cách phân chia này hoạt động hiệu quả cho đến khi số GPU trong tensor_parallel_size vượt quá num_key_value_heads. Khi đó, KV cache bắt đầu bị sao chép, với tp // num_key_value_heads bản sao giống nhau trên các rank.

Cách DCP xử lý: DCP tận dụng những phần KV cache đáng lẽ sẽ bị sao chép và thay thế chúng bằng các đoạn khác nhau của chuỗi. Trong khi đó, các KV head dùng chung được phát tới các query head tương ứng thông qua bước tensor broadcast cho GQA.

Vì vậy, mức độ chia chuỗi tối đa sẽ bị giới hạn bởi hệ số sao chép tp // num_key_value_heads:

• • • • (tensor_parallel_size // num_key_value_heads) >= decode_context_parallel_size
        

• • • • (tensor_parallel_size // num_key_value_heads) % decode_context_parallel_size == 0
        

# Qwen3-235B has num_key_value_heads = 4; tp=8 gives 8//4 = 2 redundant copies, 
# so dcp can be up to 2. 
vllm serve Qwen/Qwen3-235B-A22B \ 
   --tensor-parallel-size 8 \ 
   --decode-context-parallel-size 2

Trong thời gian tới, vLLM dự định mở rộng DCP theo một số hướng chính. Trước tiên, vLLM sẽ hỗ trợ các mức độ song song chi tiết hơn cho cả TP và DCP. Điều này giúp người dùng kiểm soát chính xác hơn cách bố trí song song và giảm phần hiệu năng bị mất do phân chia tài nguyên quá mức cần thiết.

vLLM cũng đang phát triển các kernel giao tiếp All-to-All (A2A) tốt hơn cho DCP, cả trong hệ thống nhiều node và một node. Mục tiêu là giảm lượng giao tiếp cần thực hiện và tăng khả năng chồng lấp giữa giao tiếp và tính toán khi độ dài ngữ cảnh cũng như số lượng thiết bị tăng lên.

Ngoài ra, vLLM đang cải thiện khả năng hỗ trợ MTP và speculative decoding, để DCP có thể mang lại hiệu quả xử lý cao hơn mà không làm mất lợi thế về độ trễ của các phương pháp suy đoán. vLLM cũng tiếp tục hoàn thiện hỗ trợ phân tách prefill/decode (P/D disaggregation) nhằm giúp DCP hoạt động ổn định trong các hệ thống phục vụ được phân tách.

Cuối cùng, mục tiêu là mở rộng DCP đến nhiều backend hơn, đồng thời tích hợp với các model lai và Dynamic Chunked Pipeline Parallelism. Nhờ đó, nhiều loại workload hơn có thể tận dụng lợi ích về hiệu quả xử lý từ việc song song hóa theo ngữ cảnh.

Cộng đồng cũng đang mở rộng DCP sang các model khác như GLM-5.2 và Kimi K3, đồng thời xây dựng lộ trình dài hạn cho Prefill Context Parallelism (PCP). vLLM đang thực hiện benchmark hiệu năng DCP trên Kimi K3 và sẽ chia sẻ kết quả khi quá trình nghiên cứu hoàn thiện hơn. Để xem hướng dẫn triển khai và các ghi chú trước đây về DCP, bạn có thể tham khảo tài liệu Decode Context Parallel của vLLM.

Decode Context Parallelism mang đến một cách tiếp cận mới trong việc tổ chức GPU cho suy luận với ngữ cảnh dài. Thay vì để các GPU lưu trùng KV cache hoặc không được tận dụng hết, DCP phân chia chuỗi trong quá trình attention để tất cả GPU cùng tham gia xử lý. Sau đó, các GPU này có thể tiếp tục được tổ chức lại để chia sẻ chi phí tải trọng số FFN trên toàn bộ hệ thống.

Kết quả là hệ thống có thể mở rộng ổn định hơn khi độ dài ngữ cảnh tăng, thay vì suy giảm hiệu năng nhanh chóng.

Với hỗ trợ gốc trong vLLM, Decode Context Parallelism đã sẵn sàng cho thế hệ ứng dụng AI tác vụ dài tiếp theo, từ xử lý tài liệu đến các quy trình agent nhiều phiên, với tốc độ và độ trễ phù hợp cho môi trường sản xuất.

DCP cũng nằm trong xu hướng rộng hơn của ngành về việc song song hóa theo ngữ cảnh trong giai đoạn decode. NVIDIA cũng đang theo đuổi hướng tiếp cận tương tự với Helix Parallelism trong TensorRT-LLM.

vLLM cũng đang thực hiện benchmark hiệu năng DCP trên model Kimi K3 và sẽ chia sẻ kết quả khi nghiên cứu hoàn thiện hơn.

Hiện nay có rất nhiều tùy chọn cho AI/Học máy với vLLM trong và ngoài nước. Tuy nhiên, những dịch vụ đó thường khá khó sử dụng đối với những người mới bắt đầu. Việc tính toán giá cả cũng phức tạp với nhiều chi phí ẩn mà bạn cần các khóa học để giúp bạn hiểu nó hoạt động thế nào, làm sao để không bị mất tiền vô nghĩa.

iRender AI áp dụng chính sách giá trọn gói cố định minh bạch theo giờ hoặc theo ngày. Doanh nghiệp hoàn toàn kiểm soát được dòng tiền và ngân sách vận hành dự án AI mà không lo sợ bất kỳ khoản chi phí phát sinh bất ngờ nào.

Tham khảo thêm chi phí và cấu hình của iRender tại đây.

Ngoài ra, iRender còn cung cấp cho bạn nhiều hỗ trợ khác, không chỉ những cấu hình mạnh.

1. 1. 1. 1. Hiệu năng thô đạt 100% — Giải quyết triệt để hao hụt tài nguyên do ảo hóa
         2. Băng thông PCIe độc quyền — Triệt tiêu nghẽn cổ chai (I/O Bottleneck) khi chạy RAG
         3. Bảo mật Data Isolation tuyệt đối — Nền tảng cho AI Chủ Quyền
         4. Hạ tầng đặt tại Data Center chuẩn Tier III — Cam kết Uptime 99.98%
         5. Toàn quyền Root Access — Tự do làm chủ môi trường MLOps và Scale Module linh hoạt bằng cách thêm máy
         6. Zero Cold Start — Phản hồi tức thì cho Voice AI và AI Agent
         7. Minh bạch chi phí — Loại bỏ hoàn toàn phí ẩn (Hidden Fee)

Bạn có thể đăng ký tài khoản qua link này ngay hôm nay để trải nghiệm dịch vụ của iRender. Hoặc liên hệ qua Zalo 0916806116 để được tư vấn và hỗ trợ.

Trân trọng cảm ơn!

Nguồn: vllm.ai