Chạy GLM-5.2 trên 24 GPU NVIDIA B300 với vLLM

DaoCloud team triển khai GLM-5.2-NVFP4 trên ba máy chủ B300, mỗi máy có 8 GPU, tổng cộng 24 GPU, sử dụng kiến trúc 4-Prefill + 1-Decode (4P1D) theo mô hình disaggregated serving. Với các mục tiêu SLA production là mean TTFT ≤ 2,5 giây và mean TPOT ≤ 20 ms, DaoCloud team đo được các kết quả sau:

Trên cùng hệ thống phần cứng, điểm xuất phát của DaoCloud team là mean TPOT gần 40 ms với đầu vào 16K token, tức gần gấp đôi giới hạn SLA. Bài viết này ghi lại toàn bộ quá trình giảm TPOT từ 40 ms xuống 17 ms: DaoCloud team đã thay đổi gì ở từng bước, mỗi thay đổi đóng góp bao nhiêu và vì sao chiến lược parallelism được đưa vào production lại không phải cấu hình có raw throughput cao nhất. Cuối bài có đầy đủ các lệnh vllm serve để có thể tái tạo kết quả.

Trong mô hình serving colocated, các phần prefill được xen kẽ vào các batch decode. Vì vậy, mỗi prompt dài đi vào batch sẽ làm tăng inter-token latency của mọi request đang được decode. Do đó, tail latency của TPOT phụ thuộc vào phân bố độ dài prompt đầu vào, trong khi đây là yếu tố mà hệ thống serving không thể kiểm soát.

Disaggregation loại bỏ hoàn toàn phần prefill khỏi đường xử lý quan trọng của decode, khiến TPOT chỉ còn phụ thuộc vào thành phần của batch decode. Đây chính là điều giúp đạt được SLA TPOT chặt chẽ, và cũng là lý do DaoCloud team xem P/D là điểm khởi đầu thay vì chỉ coi nó là một trong nhiều bước tối ưu hóa.

Các dịch vụ production không thể chỉ được đánh giá dựa trên throughput cao nhất. Câu hỏi thực tế là hệ thống có thể duy trì bao nhiêu lưu lượng mà không vi phạm các mục tiêu về độ trễ. Yêu cầu của DaoCloud team rất rõ ràng:

• Độ dài context phổ biến: 16K đến 256K token
• Mean TTFT ≤ 2,5 giây: độ trễ tối đa có thể chấp nhận từ lúc người dùng thực hiện thao tác đến khi token đầu tiên xuất hiện.
• Mean TPOT ≤ 20 ms: tương đương khoảng 50 token/giây đối với output streaming. Khi thấp hơn mức này, trải nghiệm đọc bắt đầu giảm rõ rệt.
• Khi đáp ứng được hai giới hạn trên, mục tiêu là tối đa hóa throughput.

Về batch size: DaoCloud team không cố định một batch size cụ thể. Load được đưa vào dưới dạng request rate, còn concurrency được hình thành từ request rate đó trong điều kiện SLA, với mục tiêu cho phép concurrency tăng đến mức lớn nhất mà ngân sách độ trễ cho phép.

Do chi phí prefill tăng theo độ dài context, concurrency giảm khi độ dài đầu vào tăng. Cụ thể, hệ thống đạt khoảng 700 request đồng thời ở 8K, 300 ở 16K và 25 ở 256K, tất cả đều nằm dưới giới hạn –max-concurrency 1024.

Mục tiêu này chi phối toàn bộ phương pháp tối ưu của DaoCloud team: mọi quá trình tìm kiếm cấu hình đều phải xét đến các ràng buộc SLA. Một cấu hình giúp throughput tăng 30% nhưng khiến mean TPOT vượt quá SLA thì không có giá trị đối với DaoCloud team. Phần 4 sẽ đưa ra một ví dụ điển hình.

GLM-5.2 là một MoE model 744B tham số, trong đó có 40B tham số hoạt động. Model sử dụng DSA sparse attention và hỗ trợ native MTP speculative decoding. vLLM đã có khả năng hỗ trợ tương đối hoàn thiện cho cả ba thành phần này. Công việc của DaoCloud team là kết hợp chúng một cách hiệu quả với P/D disaggregation, sau đó tinh chỉnh các tham số, topology và cơ chế scheduling theo các mục tiêu SLA production.

Với cấu hình ban đầu, phía Prefill đã đạt mục tiêu và vẫn còn nhiều dư địa về TTFT. Nút thắt nằm ở Decode: với đầu vào 16K token và đầu ra 1K token, mean TPOT gần 40 ms và có mức dao động P99 khá lớn.

Speculative decoding đã trở thành một phương pháp tối ưu phổ biến ở thời điểm inference đối với các MoE model lớn, và các hệ thống Decode production ngày càng thường bật tính năng này mặc định. Qua profiling, DaoCloud team phát hiện một vấn đề nằm chính tại điểm giao nhau giữa P/D disaggregation và speculative decoding.

Sau khi một request chuyển prompt KV cache sang node Decode thông qua KVConnector, bước Decode đầu tiên của request đó chỉ cần tính một token. Trong khi đó, các request đã tồn tại trên node Decode được lập lịch với 1 + N token mỗi bước khi MTP được bật.

Do hai loại request có hình dạng khác nhau, bước xử lý tạo thành một batch hỗn hợp. Khi đó, hệ thống không thể sử dụng đường xử lý nhanh full-CUDA-Graph với Decode đồng nhất, mà phải chuyển sang cơ chế piecewise execution hoặc eager execution, vốn tốn chi phí hơn.

Data parallelism (DP) làm tác động này lớn hơn. Khi sử dụng DP, CUDA Graph và padding cần được phối hợp giữa các rank. Vì vậy, nếu bất kỳ DP rank nào nhận một request mới được chuyển sang, các rank còn lại cũng phải chuyển sang cùng đường thực thi.

Trong trạng thái P/D hoạt động ổn định, request mới liên tục được đưa vào instance Decode, nên đường xử lý chậm liên tục bị kích hoạt.

Cách khắc phục về mặt ý tưởng khá đơn giản. Ở bước Decode đầu tiên sau khi request đến, các dummy speculative token được thêm vào để đưa kích thước request lên 1 + N, đồng nhất với những request khác đang được xử lý trên Decode worker.

Nhờ vậy, quá trình Decode vẫn giữ được hình dạng đồng nhất và workload tiếp tục chạy trên đường xử lý nhanh full-CUDA-Graph.

Giải pháp này không yêu cầu chuyển generated token hoặc draft token từ node Prefill. Tối ưu hóa này đã được cộng đồng vLLM tích hợp thông qua PR #45237.

Sau khi loại bỏ hiện tượng suy giảm hiệu năng do batch hỗn hợp làm thay đổi đường thực thi, mean TPOT end-to-end giảm từ khoảng 40 ms xuống khoảng 22 ms. Đây là cải thiện lớn nhất trong toàn bộ quá trình tối ưu.

Kết quả này cho thấy một điểm quan trọng đối với các hệ thống kết hợp P/D disaggregation và speculative decoding: tổn thất hiệu năng lớn nhất không nhất thiết nằm ở một kernel cụ thể.

Vấn đề có thể xuất hiện ngay tại ranh giới giữa các subsystem, nơi những khác biệt nhỏ về trạng thái request, hình dạng scheduling và chế độ thực thi CUDA Graph bị khuếch đại khi hệ thống sử dụng DP ở quy mô lớn và phải xử lý traffic liên tục.

Ở mức 22 ms, DaoCloud team đã khá gần với SLA nhưng vẫn chưa có đủ dư địa an toàn, vì vậy DaoCloud team tiếp tục thực hiện thêm một vòng tìm kiếm cấu hình.

vLLM Model Runner V2 (MRV2) tái cấu trúc đường thực thi của runtime. Từ v0.25.0, MRV2 trở thành mặc định cho tất cả dense model. GLM-5.2 là MoE model nên chưa được bật mặc định và cần kích hoạt rõ ràng bằng VLLM_USE_V2_MODEL_RUNNER=1.

Trên cấu hình Decode của DaoCloud team, MRV2 giúp TPOT giảm khoảng 11% so với MRV1. Ngoài đường thực thi ngắn hơn, MRV2 còn mang đến một số khả năng quan trọng đối với việc duy trì độ trễ ổn định trong production:

1. 1. 1. 1. PR #47285 bổ sung kernel tạo metadata cho prefill của GLM-5.2 DSA indexer vào quá trình warmup khi khởi động. Nhờ đó, request production đầu tiên không còn phải kích hoạt Triton JIT compilation và gây ra một đợt tăng độ trễ. Vấn đề này dễ bị bỏ qua khi benchmark vì warmup đã xử lý trước chi phí đó, nhưng trong production, nó có thể xuất hiện dưới dạng cold-start spike sau mỗi lần rolling deployment.
         2. PR #46448 bổ sung local argmax reduction cho MTP trên nhiều GPU. Khi bật use_local_argmax_reduction, quá trình tạo draft token không còn phải AllGather toàn bộ logits của vocabulary. Nhờ đó, lượng communication giữa các TP giảm từ mức tỷ lệ thuận với kích thước vocabulary xuống còn khoảng 2 × TP size. MTP, EAGLE, DFlash và các speculative decoder khác chạy trên MRV2 đều được hưởng lợi.
         3. PR #45953 cho phép dynamic speculative length hoạt động với full CUDA Graph, từ đó giảm số lần graph bị miss và phải fallback sang eager execution khi độ dài draft thay đổi.

Vì GLM-5.2 là một MoE model, phía Decode sử dụng DEP8, trong đó communication phục vụ expert dispatch và combine nằm trực tiếp trên đường xử lý quan trọng. DaoCloud team thay backend EP mặc định dựa trên AllGather/ReduceScatter bằng backend FlashInfer NVLink A2A. Trong các phép đo của DaoCloud team, flashinfer_nvlink_two_sided giúp TPOT giảm thêm 4%.

vLLM hiện cũng cung cấp backend mới hơn là flashinfer_nvlink_one_sided, được kỳ vọng có hiệu năng tốt hơn. Tuy nhiên, bài viết này sử dụng backend two-sided vì đây là cấu hình DaoCloud team đã trực tiếp đo lường. Việc đánh giá backend one-sided trên cùng workload Decode vẫn nằm trong kế hoạch tiếp theo.

Instance Decode sử dụng –compilation-config ‘{“cudagraph_mode”:”FULL_DECODE_ONLY”}’ cùng với –max-num-batched-tokens 1024.

Phía Decode không cần biên dịch graph cho các shape của prefill. Vì vậy, FULL_DECODE_ONLY cung cấp đầy đủ graph coverage cho đường xử lý Decode, đồng thời giảm đáng kể thời gian compilation khi khởi động.

DaoCloud team sử dụng num_speculative_tokens=3 ở phía Decode và 1 ở phía Prefill. MTP chỉ trở nên hiệu quả về chi phí trên GLM-5.2 khi kết hợp với IndexerCache, nội dung sẽ được trình bày ở Phần 5.

Sự khác biệt này là có chủ đích. Các node Prefill cần tạo và chuyển giao KV cache nhanh nhất có thể, vì vậy việc sử dụng speculation sâu hơn mang lại rất ít lợi ích. Trong khi đó, node Decode nằm trên đường xử lý nhạy cảm với độ trễ, nên speculation sâu hơn có thể phân bổ chi phí thực thi trên mỗi token hiệu quả hơn, miễn là acceptance rate vẫn ở mức cao.

Ở phía Prefill, DaoCloud team so sánh nhiều chiến lược parallelism với đầu vào 8K và 32K token. Vì các cấu hình sử dụng số lượng GPU khác nhau, TGS (throughput per GPU) là chỉ số có ý nghĩa hơn để so sánh.

Xét về throughput tuyệt đối, TP1 DP4 EP là instance nhanh nhất, đạt 47.806 tok/s với đầu vào 8K. Tuy nhiên, cấu hình này nhanh hơn chủ yếu vì sử dụng số GPU gấp đôi các cấu hình còn lại. Nếu tính trên mỗi GPU, nó chỉ đứng thứ hai. Có hai kết luận đáng chú ý:

• • • • TP2 + EP có hiệu năng kém hơn TP2 thuần túy. Với quy mô chỉ hai GPU, chi phí all-to-all communication do EP tạo ra lớn hơn lợi ích mà EP mang lại. EP cần đủ nhiều expert được phân bổ trên đủ số thiết bị để bù đắp chi phí communication.
      • TP1 DP2 EP đạt TGS tốt nhất, nhưng DaoCloud team chọn TP1 DP4 EP để đưa vào production.

Điểm thứ hai cho thấy sự khác biệt giữa kỹ thuật production và việc chỉ chạy theo benchmark. TP1 DP2 EP đạt hiệu quả trên mỗi GPU tốt nhất, nhưng mỗi instance chỉ có hai GPU, khiến dung lượng KV cache quá nhỏ so với khả năng hỗ trợ context dài tới 1M token của GLM-5.2.

DaoCloud team không muốn đánh đổi một trong những tính năng quan trọng nhất của model chỉ để lấy thêm 8% TGS. Vì vậy, DaoCloud team chọn TP1 DP4 EP, chấp nhận giảm khoảng 8% hiệu quả trên mỗi GPU để đổi lấy dung lượng KV cache tương đương bốn GPU cho mỗi instance.

vLLM đã được kiểm chứng rộng rãi trong môi trường production với các cấu hình thông thường. Tuy nhiên, hệ thống này đồng thời sử dụng ba khả năng tương đối mới là P/D disaggregation, MTP và MRV2, tạo thành một tổ hợp ít được sử dụng hơn trong thực tế. Quá trình tuning vì vậy đã phát hiện một số vấn đề nằm ở các trường hợp ít phổ biến.

Phần lớn các bản sửa lỗi được chuyển từ lúc báo cáo đến khi phát hành chỉ trong vài ngày. Người dùng v0.26.0 hiện đã có đầy đủ các bản sửa lỗi này. Phần này ghi lại quá trình từng bước ổn định MTP acceptance.

IndexerCache (PR #44420) không phải là một KV cache thông thường. Cơ chế này tái sử dụng các Top-K sparse index được tạo bởi DSA indexer.

Một cách triển khai đơn giản sẽ chạy lại indexer ở mỗi MTP draft step. Vì chi phí sparse retrieval tăng theo độ dài context, việc này có thể tiêu tốn phần lớn lợi ích mà speculative decoding mang lại.

PR #44420 giới thiệu index_share_for_mtp_iteration, cho phép draft step đầu tiên tính Top-K index, sau đó các draft step tiếp theo tái sử dụng những index này. Đây là điều kiện cần để MTP thực sự mang lại lợi ích trên GLM-5.2.

Sau đó, cộng đồng tiếp tục hoàn thiện ba cải tiến xung quanh cơ chế này. Kết hợp lại, chúng giúp ổn định acceptance rate khi hệ thống xử lý concurrency cao:

• • • • PR #45895 cải thiện quá trình khởi tạo indexer khi một số Top-K layer bị bỏ qua, đồng thời sửa vòng lặp chuẩn hóa MTP của GLM-5.2. Theo kết quả được báo cáo trong PR, với GLM-5.2-FP8 và TP=8, độ dài token được chấp nhận trung bình tăng từ khoảng 3 lên khoảng 4, với acceptance rate trung bình khoảng 60%, trong khi IFBench vẫn đạt 74,62.
      • PR #47238 tối ưu layout của shared index buffer cho các request được xử lý theo batch. Sau draft step đầu tiên, hệ thống chỉ giữ lại các Top-K index tương ứng với token query cuối cùng của từng request. Đây là bước quan trọng giúp mở rộng index sharing từ xử lý từng request sang batching với concurrency cao.
      • PR #47448 đảm bảo vòng lặp MTP tái sử dụng hidden state sau final norm.

Nhìn tổng thể, IndexerCache không chỉ là một tối ưu giúp giảm chi phí tính toán. Nó còn là một cơ chế quan trọng giúp duy trì MTP acceptance rate khi hệ thống hoạt động với concurrency cao.

Phân loại scheduling trong MRV2. Sau khi chuyển sang MRV2, DaoCloud team nhận thấy TPOT dao động quá lớn trong một dạng benchmark cụ thể và đã báo cáo vấn đề tại Issue #47239. Cộng đồng nhanh chóng xác định nguyên nhân nằm ở cơ chế sắp xếp uniform-decode: các bước speculative decoding bị phân loại nhầm là prefill, vì vậy phải đi qua đường thực thi chậm hơn. PR #47381 đã khắc phục vấn đề này.

Xử lý lookahead khi tải KV bất đồng bộ trong hệ thống P/D. PR #46694 cải thiện thời điểm cấp phát slot cho cấu hình kết hợp GLM-5.2 + NIXL P/D + MTP. Decoder hiện chờ cho đến khi quá trình truyền KV từ xa hoàn tất rồi mới cấp phát slot cho speculative token, đồng thời xử lý chính xác trường hợp biên khi KV block cuối chỉ chứa một phần dữ liệu.

Cơ chế chuyển giao partial block này xuất hiện do sự tương tác giữa P/D disaggregation và speculative decoding. Việc khắc phục nó là thêm một bước quan trọng để đưa toàn bộ đường xử lý này đến trạng thái sẵn sàng cho production.

Cả hai bản sửa lỗi đều đã được tích hợp trong v0.25.0 và các phiên bản phát hành sau đó.

DaoCloud team chạy một loạt benchmark công khai trên cấu hình cuối cùng để xác nhận rằng việc kết hợp NVFP4 quantization, MTP và P/D disaggregation không làm giảm chất lượng đầu ra:

Các kết quả này phù hợp với những con số GLM-5.2 được cộng đồng công bố. LongBench V2 đặc biệt quan trọng đối với DaoCloud team vì benchmark này trực tiếp kiểm tra DSA sparse attention và cơ chế IndexerCache index sharing trong các workload có context dài.

Điểm số 64,01 cho thấy index sharing vẫn hoạt động ổn định trên các workload long-context, đồng thời lợi ích về tốc độ từ speculative decoding không phải đánh đổi bằng chất lượng đầu ra.

Các khả năng được sử dụng trong hệ thống này dựa trên một loạt tối ưu rộng hơn do cộng đồng vLLM phối hợp thực hiện trong issue theo dõi tối ưu GLM-5.2, Issue #46654. Ngoài những PR đã đề cập ở trên, có hai phát triển đặc biệt đáng chú ý.

Tầng trung gian cho P/D disaggregation. PR #42285 giới thiệu một CPU KV-cache layout thống nhất đóng vai trò tầng trung gian. TieringManager điều phối giữa tầng cache chính và P/D connector, qua đó giảm sự phụ thuộc lẫn nhau giữa backend truyền dữ liệu và đường thực thi của model. Thay đổi này đã được tích hợp từ v0.25.0.

PCP virtual batching cho Prefill với context dài. PR #46570 chia request thành nhiều virtual batch row, được xử lý song song trên các context-parallel rank, trong khi chỉ tổng hợp MLA latent cache và DSA indexer cache.

Trong thử nghiệm ban đầu với GLM-5.2-NVFP4, 4 GPU và Prefill 32K, cấu hình TP=2 với PCP=2 đã tăng prompt throughput từ khoảng 20,1K tok/s lên 27,3K tok/s.

PR này đã được merge vào main ngày 19/7/2026 và sẽ được phát hành trong phiên bản tiếp theo. Vì dung lượng KV cache chính là lý do khiến DaoCloud team loại bỏ cấu hình có TGS tối ưu ở Phần 4, PCP có thể làm thay đổi sự đánh đổi này. Do đó, đây sẽ là một trong những trọng tâm chính của giai đoạn kiểm chứng tiếp theo.

Vượt qua một benchmark không có nghĩa là hệ thống đã sẵn sàng cho production. Việc observability khó hơn đối với hệ thống P/D disaggregation so với một instance đơn lẻ, vì độ trễ của request được phân chia giữa hai nhóm tài nguyên: TTFT chủ yếu do cụm Prefill quyết định, TPOT chủ yếu do cụm Decode quyết định, và ở giữa là quá trình truyền KV. Khi bất kỳ giai đoạn nào suy giảm, người dùng chỉ nhìn thấy một biểu hiện duy nhất: dịch vụ trở nên chậm hơn.

DaoCloud team xây dựng hệ thống giám sát cho topology P/D bằng Prometheus và Grafana. Trong production, DaoCloud team theo dõi các nhóm metric sau:

• • • • Phân vị TTFT và TPOT theo từng pool, thay vì chỉ xem số liệu tổng thể từ đầu đến cuối. Đây là nơi đầu tiên cần kiểm tra để xác định vấn đề nằm ở Prefill hay Decode.
      • MTP acceptance rate và độ dài token được chấp nhận trung bình. Đây là những tín hiệu cảnh báo sớm nhưng rất dễ bị bỏ qua. Khi acceptance rate giảm, hệ thống không báo lỗi; TPOT chỉ từ từ tăng lên. Trên thực tế, đây là dashboard đầu tiên DaoCloud team mở khi phát hiện bất thường ở phía Decode. Vì vậy, DaoCloud team khuyến nghị coi MTP acceptance rate là một metric cảnh báo quan trọng.
      • Mức sử dụng KV cache so với mức sử dụng GPU, ở cả phía Prefill và Decode. Lợi ích cốt lõi của P/D disaggregation là hai loại tài nguyên này có thể được scale độc lập; mức chênh lệch giữa hai đường biểu diễn chính là tín hiệu quan trọng để quyết định cách scale hệ thống.
      • Độ trễ truyền KV và độ sâu hàng đợi, nhằm xác định liệu mạng giữa các node có trở thành nghẽn cổ chai hay không.

Benchmark ngắn chỉ kiểm chứng hiệu năng, chứ không cho biết hệ thống có ổn định trong thời gian dài hay không. Quy trình nghiệm thu production của DaoCloud team bao gồm các phiên chạy liên tục trong nhiều ngày, và chính bước này đã phát hiện hiện tượng host memory tăng liên tục: RSS của tiến trình vLLM tăng tuyến tính trong hàng chục giờ mà không đạt đến trạng thái ổn định.

Có một số đặc điểm giải thích vì sao vấn đề này cần đến production monitoring mới phát hiện được, thay vì chỉ chạy benchmark:

• • • • Mức tăng rất chậm và chỉ có thể nhìn thấy sau nhiều giờ. Một lần chạy vllm bench serve chỉ kéo dài vài giây hoặc vài phút sẽ không thể phát hiện vấn đề.
      • Mức tăng xảy ra ở host memory, không phải GPU memory. Vì vậy, tất cả metric ở phía GPU vẫn trông hoàn toàn bình thường.
      • Các công cụ phân tích memory thông thường cũng không phát hiện được. EngineCore gọi gc.freeze() trong quá trình khởi động, khiến các object bị leak không xuất hiện trong gc.get_objects() hoặc tracemalloc; hiện tượng này vì thế trông giống như memory allocator fragmentation.

DaoCloud team đã báo cáo hiện tượng này cùng với chẩn đoán ban đầu cho cộng đồng trong PR #47723, sau đó một maintainer đã đưa bản sửa vào PR #44490.

Nguyên nhân gốc nằm ở việc điều kiện kiểm soát (gating) giữa producer và consumer không nhất quán. PR #35219 đã giới thiệu SingleTypeKVCacheManager.new_block_ids để xóa trạng thái cache của Mamba SSM.

Các entry được ghi lại dựa trên kiểu KV-cache spec – chẳng hạn FullAttentionSpec, MLAAttentionSpec – nhưng chỉ được xóa khi model có các layer Mamba. Với những model không có Mamba, bao gồm phần lớn các model sử dụng attention thông thường và GLM-5.2 với MLA, mọi lần cấp phát block đều được ghi lại nhưng danh sách không bao giờ được giải phóng. Vì vậy, danh sách tăng không giới hạn khi số lượng request tăng.

Cách sửa là gọi take_new_block_ids() để luôn drain danh sách ở mỗi scheduling step, sau đó chỉ sử dụng kết quả khi thực sự cần xóa cache. Hành vi của Mamba không thay đổi.

export VLLM_USE_V2_MODEL_RUNNER=1
 
vllm serve /mnt/model/glm/GLM-5.2-NVFP4 \
    --trust-remote-code \
    --kv-transfer-config '{"kv_connector":"NixlConnector","kv_role":"kv_producer"}' \
    --chat-template-content-format=string \
    -ep \
    -tp 1 \
    -dp 4 \
    --tool-call-parser glm47 \
    --enable-auto-tool-choice \
    --reasoning-parser glm45 \
    --gpu-memory-utilization 0.92 \
    --enable-prompt-tokens-details \
    --speculative-config='{"method":"mtp","num_speculative_tokens":1}' \
    --shutdown-timeout 300 \
    --fingerprint-mode=none

export VLLM_USE_V2_MODEL_RUNNER=1
 
vllm serve /mnt/model/glm/GLM-5.2-NVFP4 \
    --trust-remote-code \
    --chat-template-content-format=string \ 
    --kv-transfer-config '{"kv_connector":"NixlConnector","kv_role":"kv_producer"}' \
    --compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY"}' \
    --max-num-batched-tokens 1024 \
    -ep \
    -tp 1 \
    -dp 8 \
    --tool-call-parser glm47 \
    --enable-auto-tool-choice \
    --reasoning-parser glm45 \
    --gpu-memory-utilization 0.90 \
    --enable-prompt-tokens-details \
    --all2all-backend=flashinfer_nvlink_two_sided \
    --speculative-config='{"method":"mtp","num_speculative_tokens":3}' \
    --shutdown-timeout 300 \
    --fingerprint-mode=none

Toàn bộ dữ liệu hiệu năng được thu thập bằng random dataset trong vllm bench serve.
Không có request nào nhận được prefix-cache hit, vì vậy các số liệu TTFT phản ánh độ trễ trong trường hợp xấu nhất, khi chỉ tính chi phí tính toán.
Request được gửi vào hệ thống với –request-rate cố định. Giá trị này được tính theo công thức:
TPS mục tiêu / (input_len + output_len) × hệ số điều chỉnh

vllm bench serve \
  --backend openai-chat \
  --model /mnt/model/glm/GLM-5.2-NVFP4 \
  --endpoint /v1/chat/completions \
  --dataset-name random \
  --random-input-len 16384 \
  --random-output-len 1000 \
  --request-rate <target TPS / (input + output) × tuning factor> \
  --percentile-metrics ttft,tpot,itl,e2el \
  --metric-percentiles 50,90 \
  --save-result

Đối với GLM-5.2 và các model MoE lớn hơn trong tương lai, DaoCloud team nhận thấy hai hướng chính để tiếp tục tối ưu phía Decode. Những nhận định dưới đây mang tính định hướng cho tương lai, chứ chưa phải các kết luận đã được kiểm chứng bằng số liệu trong bài viết này.

Thứ nhất, giảm chi phí của mỗi lần target forward pass.

Bên cạnh các kernel cốt lõi như GEMM, Attention và Indexer, hướng này bao gồm việc nghiên cứu PDL, persistent kernels, localized megakernels, cũng như phối hợp tính toán và truyền dữ liệu giữa MoE Dispatch, Expert GEMM và Combine.

Khi hệ thống được mở rộng trên nhiều node, WideEP, hierarchical all2all, cùng khả năng chồng lấp (overlap) truyền dữ liệu giữa các node với quá trình tính toán sẽ ngày càng trở nên quan trọng.

Mục tiêu là rút ngắn critical path đầu-cuối của một Decode step hoàn chỉnh.

Thứ hai, đẩy mạnh đồng tối ưu model–runtime cho speculative decoding.

Ở phía model, có thể huấn luyện các draft model mạnh hơn như DSpark trên những tập dữ liệu lớn và đa dạng hơn để cải thiện độ chính xác của các token được dự đoán liên tiếp.

Ở phía runtime, dynamic speculative decoding, độ dài proposal theo từng request và cơ chế verification gọn nhẹ có thể giúp kiểm soát chi phí xác minh trên các workload khác nhau.

Nói cách khác, draft model quyết định hệ thống có thể dự đoán xa đến đâu; serving runtime quyết định việc dự đoán xa đến đâu là thực sự hiệu quả về mặt chi phí.

Ngoài ra, công việc về PCP virtual batch được mô tả ở Phần 6 hiện đã được tích hợp vào main. DaoCloud team sẽ đánh giá liệu cơ chế này có thể loại bỏ sự đánh đổi giữa dung lượng KV cache và hiệu quả tính toán trên mỗi GPU được đề cập ở Phần 4 hay không.

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