vLLM đạt 25 nghìn TPS/GPU tổng trên Qwen3.5

Qwen3.5 được phát hành vào đầu năm 2026 và hiện vẫn là một trong những model được khách hàng sử dụng rộng rãi nhất. Do sở hữu kiến trúc attention lai mới, việc triển khai model ở chế độ disaggregated đặt ra thêm nhiều thách thức, đồng thời mở ra nhiều cơ hội để tối ưu hiệu năng.

Nhờ những đóng góp liên tục từ cộng đồng vLLM, quy trình disaggregated serving cho Qwen3.5 hiện đã khá hoàn thiện. Trong bài viết này, chúng ta sẽ xem xét những đóng góp quan trọng, hiệu năng mới nhất trên hệ thống GB200 NVL72, cùng các công thức triển khai và best practices để bạn có thể tái hiện kết quả. Bài viết cũng hướng dẫn cách đạt hiệu năng trên 25 nghìn TPS/GPU tổng.

Kiến trúc hybrid của Qwen3.5 kết hợp các full-attention layer với các Gated Delta Network (GDN) layer. Điều này tạo ra hai bài toán tối ưu riêng biệt: tăng tốc quá trình tính toán GDN trên GPU Blackwell và truyền chính xác trạng thái attention/GDN khác nhau giữa các worker prefill và decode.

Cộng đồng vLLM đã thúc đẩy việc hỗ trợ SSM cho P/D serving thông qua lộ trình NIXL disaggregation. Để tìm hiểu sâu hơn về cách tổ chức cache không đồng nhất, cơ chế ánh xạ giữa block logic và block vật lý, cũng như quá trình truyền trạng thái tensor parallel, có thể tham khảo bài viết chi tiết về hybrid SSM disaggregation.

Dưới đây là những đóng góp được đánh giá là đặc biệt quan trọng đối với hiệu năng của Qwen3.5.

FlashInfer: Bổ sung kernel GDN prefill cho Blackwell #3001

So với phiên bản triển khai trước đây dựa trên FLA/Triton, GDN kernel mới cải thiện hiệu năng khoảng 1,02 đến 5,78 lần trên nhiều kích thước model Qwen3.5, cấu hình tensor parallel, độ dài chuỗi và hình dạng batch khác nhau.

Sau đó, kernel này được tích hợp vào phía prefill của vLLM thông qua vLLM PR #40717. Trên hệ thống 8×B200 chạy Qwen3.5-397B-A17B-NVFP4, việc tích hợp vào vLLM mang lại:

• • • • Hiệu năng GDN kernel cao hơn tới 5,92 lần trong các bài kiểm thử microbenchmark.
      • Throughput prefill đầu cuối cao hơn 1,13 lần trong workload chỉ chạy prefill (ISL/OSL = 8192/1).
      • TTFT trung bình giảm 12% trong workload chỉ chạy prefill (8K/1).

Trên các cấu hình Blackwell được hỗ trợ, vLLM sẽ tự động chọn FlashInfer khi GDN backend được đặt thành auto. Bạn cũng có thể chỉ định trực tiếp bằng:

--gdn-prefill-backend flashinfer

Cơ chế disaggregated serving cho các model kết hợp SSM và attention được xây dựng dựa trên [Core][KVConnector] Support HMA+NixlConnector #35758 cùng một loạt thay đổi đối với connector, được trình bày trong bài viết về hybrid SSM disaggregation.

PR này là một thành phần nền tảng cần thiết. Nó ánh xạ các block logic của HMA vào đúng vùng bộ nhớ vật lý, nhờ đó NIXL chỉ cần truyền các vùng cache tương ứng với từng loại layer. Cách này giảm số lượng descriptor cần truyền từ 4.284 xuống còn 1.650, đồng thời cải thiện throughput tới khoảng 7% trong một hệ thống H100 quy mô nhỏ, chạy trong cùng một node.

Tuy nhiên, trạng thái kiểu Mamba có cách tổ chức bộ nhớ, kích thước và cơ chế truyền khác biệt đáng kể. Vì vậy, chỉ hỗ trợ HMA là chưa đủ để triển khai P/D serving một cách chính xác và hiệu quả.

PR chính cho hybrid SSM-FA disaggregation là [PD][Nixl] Add support for hybrid SSM-FA models #36687. PR này bổ sung hai cách biểu diễn descriptor và hỗ trợ homogeneous TP, cho phép các worker prefill và decode truyền cả KV cache của full-attention lẫn trạng thái SSM kiểu Mamba thông qua NIXL.

Các thay đổi liên quan trong cùng nhóm còn bao gồm:

• • • • [Kernel] Mamba support different layout for Conv state #37416
      • [NIXL][Mamba][3/N] Heterogeneous TP: 3-read conv state transfer #37635
      • [SSM/Mamba] Follow-up: N-1 prefill for P/D disaggregation #37310

Bài viết về hybrid SSM disaggregation giải thích chi tiết cách các descriptor kép, cơ chế kết nối giữa block vật lý và block logic, cùng quá trình truyền conv state phối hợp với nhau.

Riêng với Qwen3.5, PD disagg with NIXL Connector: GDN support (Qwen3.5) #41869 mở rộng cơ chế này để hỗ trợ các GDN layer.

Hai bản vá này xử lý các race condition trong quá trình truyền các block của KV cache, vốn khiến async scheduling không thể sử dụng được. Khi bật tính năng này, độ chính xác của hệ thống giảm xuống gần như bằng 0.

Qua quá trình tối ưu, async scheduling được xác định là một trong những tính năng quan trọng giúp hệ thống vượt mốc 25 nghìn token/giây/GPU, vì vậy cả hai lỗi race condition đều cần được xử lý triệt để.

• [KV Connector] Fix PD async scheduling race condition for hybrid attn models #48481
• [Bugfix] Defer block freeing until in-flight steps finish under async scheduling + PD KV consumer #45357

Các phép đo được thực hiện trên một cụm máy GB200 kết nối với nhau qua NVLink72. vLLM sử dụng ISL/OSL = 8192/1024. Model được đánh giá là Qwen3.5-397B-A17B-NVFP4.

Hiệu năng được đo trên một topology decode cố định và với số lượng endpoint decode không đổi. Trong thiết lập này, phía decode sử dụng một endpoint với DEP8 (Data Parallel + Expert Parallel trên 8 GPU). Ở phía prefill, vLLM đánh giá các cấu hình từ 4 đến 8 endpoint, trong đó mỗi endpoint sử dụng topology DEP2 cố định.

Để tái hiện kết quả, hãy sử dụng Docker image vLLM mới nhất, vllm/vllm-openai:nightly-d223c90, cùng Dynamo 1.2.0.dev20260526 và srt-slurm v1.0.32. Toàn bộ recipe được sử dụng trong bài viết này có trong repository srt-slurm-recipes.

Trước tiên, vLLM đo độ chính xác trên tất cả các cấu hình serving để đảm bảo rằng các kết quả hiệu năng là đáng tin cậy. Để thực hiện việc này, vLLM sử dụng benchmark GSM8K (Grade School Math 8K).

Chạy GSM8K với srt-slurm khá đơn giản. Để bật benchmark này, thêm block sau vào file recipe:

benchmark:  
    type: "gsm8k"

Kết quả độ chính xác trên cả năm cấu hình đều đạt 88%, tương đương với mức độ chính xác quan sát được khi chạy Qwen3.5 ở chế độ tổng hợp.

Để đo hiệu năng, vLLM sử dụng benchmark với độ dài chuỗi đầu vào và đầu ra cố định, trên một dataset ngẫu nhiên với random_range_ratio=0.8.

Các recipe cũng như những thiết lập có ảnh hưởng lớn nhất được trình bày trong phần Recipes & best practices bên dưới.

Các đường cong Pareto của từng cấu hình được trình bày trong Hình 1, trong khi đường biên Pareto cuối cùng, được tổng hợp từ tất cả các cấu hình, nằm trong Hình 2.

Tổng TPS trên mỗi GPU đạt 25.000 token/giây. vLLM thử nghiệm mức độ đồng thời từ 64 đến 5.120 request.

vLLM không đo ở mức độ đồng thời thấp từ 1 đến 32, vì mục tiêu của phần này là tập trung vào phía bên trái của đường cong Pareto, nơi cần tối đa hóa chỉ số tổng TPS trên mỗi GPU.

Ở phía ngược lại, vLLM cũng không thử vượt quá mức 5.120 request, vì đây là ngưỡng mà hệ thống bắt đầu thiếu dung lượng KV cache ở phía decode. Trong toàn bộ quá trình đo, phía decode được cố định ở một endpoint duy nhất với 8×GB200.

Việc tăng mức độ đồng thời lên cao hơn hoàn toàn có thể thực hiện được, nhưng khi đó cần bổ sung thêm GPU cho phía decode.

Toàn bộ recipe được sử dụng trong bài viết này nằm trong repository srt-slurm-recipes. Mỗi recipe có thể được khởi chạy chỉ bằng một lệnh:

srtctl run --file <recipe>.yaml

Quy ước đặt tên là NxDEP2-1xDEP8, trong đó N là số lượng endpoint prefill chạy DEP2 kết nối với một endpoint decode chạy DEP8. Có năm cấu hình cơ bản, từ 4×DEP2 đến 8×DEP2. Mỗi cấu hình có thêm ba biến thể:

• • • • File cơ bản chạy sa-bench với mức độ đồng thời từ 64 đến 3072.
      • Biến thể -acc chạy GSM8K năm lần trên cùng topology.
      • -cc4096 và -cc5120 lần lượt ghi nhận một điểm có mức độ đồng thời cao, trong đó max-cudagraph-capture-size ở phía decode được tăng lên lần lượt 640 và 768.

Phần lớn thiết lập trong các recipe là tiêu chuẩn và được dùng chung cho tất cả cấu hình, nhưng một số thiết lập đáng chú ý gồm:

VLLM_SSM_CONV_STATE_LAYOUT=DS

Bắt buộc đối với các model SSM khi sử dụng serving phân tách. Nếu không có thiết lập này, việc truyền conv-state sẽ không hoạt động. Các recipe ban đầu cũng sử dụng –no-disable-hybrid-kv-cache-manager, nhưng HMA hiện đã được bật mặc định trong nhiều phiên bản vLLM, nên không còn cần thêm flag này.

--async-scheduling

Một trong những tính năng quan trọng giúp đạt mức 25K token/giây trên mỗi GPU. Tính năng này yêu cầu bản build vLLM đã bao gồm các bản sửa lỗi race condition được đề cập ở phần trên.

--mamba-ssm-cache-dtype bfloat16

Giúp tăng đáng kể dung lượng KV cache hiệu dụng ở endpoint decode.

--language-model-only

Qwen3.5 là một model đa phương thức. Với workload chỉ sử dụng văn bản, flag này không chỉ tắt đầu vào đa phương thức mà còn kích hoạt đường xử lý hợp nhất QK-norm + RoPE + gate trong các lớp attention.

--max-num-batched-tokens 16384

Ở phía prefill, tương đương 2× ISL. Với các cấu hình có ít endpoint prefill hơn, cụ thể là {4, 5, 6}×DEP2, prefill trở thành nút thắt và khiến phía decode không thể duy trì mức thông lượng tối đa. Vì vậy, mỗi bước prefill được phép gom hai prompt đầy đủ vào cùng một batch thay vì một prompt, giúp tổng TPS trên mỗi GPU tăng khoảng 8% ở mức độ đồng thời cao.

--max-cudagraph-capture-size 

Ở phía decode được tăng lên cc/8 + 128 cho hai mức độ đồng thời cao nhất, gồm 640 tại cc=4096 và 768 tại cc=5120. Trong công thức này, 8 là số lượng DP rank trên endpoint decode. Mặc định của vLLM giới hạn số lượng graph được capture ở mức 512, đủ cho cc=3072. vLLM chưa chắc thiết lập này thực sự cần thiết để đạt các con số Pareto được báo cáo, nhưng đã tăng giới hạn này như một biện pháp phòng ngừa.

Prefix caching được tắt vì nó không mang lại lợi ích trên dataset ngẫu nhiên.

--stream-interval 100

Giúp giảm overhead ở frontend khi mức độ đồng thời cao. Tuy nhiên, thiết lập này gom output được stream thành từng nhóm 100 token, vì vậy nó cũng ảnh hưởng đến độ trễ trên mỗi token được đo. Điều này cần được lưu ý nếu mục tiêu tối ưu là ITL/TPOT thay vì tổng thông lượng.

Cuối cùng, có một vài thiết lập thực tế đã giúp vLLM tiết kiệm rất nhiều thời gian.

–api-server-count 1 rất hữu ích khi bạn đang kiểm tra một cấu hình cụ thể. Trên một endpoint sử dụng data parallelism, vLLM mặc định đặt số lượng API server bằng với kích thước data parallel. Khi có nhiều hơn một API server, vLLM sẽ tắt hoàn toàn việc ghi thống kê mặc định để tránh báo cáo các số liệu không đầy đủ. Việc đặt cố định giá trị này thành 1 sẽ bật lại cơ chế ghi thống kê. Cứ sau 10 giây, khoảng thời gian này có thể điều chỉnh thông qua VLLM_LOG_STATS_INTERVAL, server sẽ in ra throughput của prompt và phần sinh văn bản, cùng với mức sử dụng KV cache. Nếu không có các số liệu này, vLLM gần như không thể xác định bottleneck của từng cấu hình hoặc hiểu được vì sao một tùy chọn cụ thể lại cải thiện hiệu năng trên workload của mình.

Ngoài ra, nên thiết lập ba biến môi trường: DYN_LOG=error, DYN_SDK_DISABLE_ANSI_LOGGING=1 và VLLM_LOGGING_COLOR=0. Biến đầu tiên giúp giảm đáng kể lượng log từ Dynamo, trong khi hai biến còn lại loại bỏ một phần, không phải toàn bộ, các ANSI escape sequence khỏi nội dung log. Nếu không thiết lập chúng, file log rất dễ trở nên khó đọc đối với con người, chủ yếu vì Dynamo mặc định tạo ra một lượng log cực lớn.

Các phép đo của vLLM cho đến nay chủ yếu tập trung vào phần bên trái của đường cong Pareto, nhằm tối đa hóa tổng TPS trên mỗi GPU. Tiếp theo, vLLM dự định thử nghiệm các cấu hình PD để tối đa hóa Gen TPS trên mỗi người dùng. Để đạt được vùng hiệu năng này, cần chuyển từ topology DEP sang TEP (Tensor Parallel + Expert Parallel), hoặc chỉ sử dụng TP, vì các cấu hình này thường mang lại hiệu năng trên mỗi người dùng tốt hơn. Việc tăng số lượng GPU được sử dụng cũng là một hướng mà vLLM kỳ vọng sẽ mang lại hiệu quả trong trường hợp này.

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