DSpark vs MTP trên DGX Spark — benchmark thực tế cho speculative decoding

📊 Nguồn: A/B DSpark vs MTP của MiaAI-Lab đo thực tế trên GB10 (18/08/2026, n=5, cùng weights NVFP4); benchmark FP8/NVFP4 + MTP của Kubesimplify (14–17/08/2026). Chi tiết nguồn ở cuối bài.

Nếu bạn từng tự hỏi vì sao một chiếc máy AI mạnh mẽ như DGX Spark vẫn thở hổn hển khi sinh từng token, câu trả lời nằm ở băng thông bộ nhớ. GB10 có khoảng 273 GB/s băng thông, nhưng mỗi token sinh ra đều phải đọc toàn bộ trọng số model. Decode vì thế bị chặn bởi băng thông, không phải tính toán. Đây chính là lý do speculative decoding tạo ra khác biệt lớn trên loại phần cứng này.

Speculative decoding là gì, và vì sao nó cần thiết trên GB10

Ý tưởng đơn giản: thay vì để model lớn tự sinh từng token một, bạn dùng một cơ chế dự đoán nhẹ hơn để đoán nhiều token cùng lúc, rồi để model lớn xác nhận cả khối trong một lần. Nếu dự đoán trúng phần lớn, bạn tiết kiệm được nhiều lượt đọc toàn bộ weights. Trên một con chip bị giới hạn bởi băng thông như GB10, đây là cách hiệu quả nhất để tăng token/s mà không cần đổi phần cứng.

Trong hệ sinh thái Qwen3.8-27B chạy trên GB10 bằng SGLang, có hai cơ chế phổ biến: DSpark và MTP. Cả hai cùng mục tiêu, nhưng khác nhau về cách dự đoán và cách vận hành, dẫn tới kết quả khác nhau tùy workload. Chúng tôi không tin lời quảng cáo, nên đã chạy A/B để đo.

Cấu hình A/B: n=5, cùng weights, chỉ khác cơ chế

Để kết quả đáng tin, chúng tôi giữ mọi thứ khác giống nhau và chỉ thay đổi đúng một biến: cơ chế speculative decoding. Cùng bộ weights NVFP4, cùng model Qwen3.8-27B, cùng cấu hình serve, mỗi workload chạy 5 lần (n=5).

• DSpark — chạy qua script start-dspark.sh, cấu hình block-7.
• MTP — chạy qua script start.sh, cấu hình EAGLE 3/1/4 (Multi-Token Prediction).

Ba loại workload được đo, đại diện cho ba nhóm bài toán thực tế: code sinh với test, chat ngắn có thinking, và văn bản dài sinh tự do.

Nguồn: MiaAI-Lab, repo Qwen3.8-27B-SGLang-DGX-Spark, đo thực tế 18/08/2026 trên GB10, n=5, cùng weights NVFP4.

Phân tích: agent và code thắng DSpark, essay dài thắng MTP

DSpark thắng hai trong ba workload, và thắng đậm nhất ở bài toán code — 51,5 so với 34,5 tok/s. Đây là điểm quan trọng với 5ac, vì workload chính của chúng tôi là agentic: code, tool-calling, và chuỗi hành động lặp đi lặp lại. DSpark theo sát phân bố token khi code có cấu trúc chặt chẽ, nên drafter dự đoán trúng nhiều hơn.

Chat ngắn có thinking là trận đấu sát: 23,2 so với 21,0 tok/s. DSpark vẫn thắng, nhưng lợi thế mỏng. Khi model ở chế độ suy luận, chuỗi token trở nên khó đoán hơn, nên lợi thế của speculative decoding bị thu hẹp.

Kết luận gọn của nguồn đo: "Dùng DSpark cho agents, code và chat thường; MTP chỉ nếu bạn viết essay dài." Với 5ac — workload chủ yếu là agentic, coding và tool-calling — DSpark là lựa chọn đúng. Điều này cũng trùng với hướng quyết định deploy của chúng tôi cho Qwen3.8 trên GB10: FP8 + DFlash, ổn định, không crash.

So sánh với benchmark Kubesimplify: FP8, NVFP4 và MTP

Kết quả trên không đứng một mình. Benchmark của Kubesimplify (đo trên GB10, 14–17/08/2026) với Qwen3.8-27B đưa ra một bức tranh bổ sung về toàn bộ hệ sinh thái quant và cơ chế decode, không chỉ riêng cặp DSpark vs MTP:

• BF16 (nguyên bản): ~3–4 tok/s — chậm nhất, chỉ để tham chiếu.
• FP8 (vLLM, không spec): 8,2 tok/s single, 57,9 tok/s tổng ở 10 luồng — sạch, ổn định.
• FP8 + DFlash: 17,2 tok/s free-gen, 45+ tok/s edit, 65,6 tok/s tổng — lựa chọn ổn định của chúng tôi.
• NVFP4 (vLLM): 11,5 tok/s single, 84,3 tok/s tổng — nhanh nhưng cần Marlin backend.
• NVFP4 + MTP: 22,0 tok/s single, 105,8 tok/s tổng — peak nhanh nhất, nhưng từng hard-reboot máy 2 lần ở long-ctx + concurrency.
• Ollama Q4 + MTP: 26,5 tok/s single — nhanh nhất cho một luồng đơn.

Đọc bảng này cùng với A/B DSpark vs MTP, một bài học xuyên suốt hiện ra: con số peak và độ ổn định là hai thứ khác nhau. NVFP4 + MTP cho tốc độ tổng cao nhất (105,8 tok/s), nhưng chính nó lại là cấu hình từng làm máy reboot. Khi workload của bạn là agent chạy liên tục, một lần crash giữa ca vận hành còn đắt hơn mức chênh lệch vài tok/s trên bảng.

Tuning đã đo: spec steps, pin lõi X5 và GDN bf16

Chọn đúng cơ chế mới là một nửa. Nửa còn lại là tuning để đẩy nó lên đỉnh. Ba tuning đã được đo trên GB10 và đáng áp dụng:

Spec steps 3/1/4 là peak. Head MTP được huấn luyện 3 bước, và cấu hình 3/1/4 cho kết quả cao nhất. Trong sweep từ 2 đến 6 bước, tốc độ thinking đo được lần lượt 12,8 / 17,2 / 16,8 / 16,3 / 15,8 tok/s — 17,2 tok/s (cấu hình 3/1/4) là điểm đỉnh.

Pin 10 lõi Cortex-X5. Dùng cờ --cpuset-cpus 5-9,15-19 để ghim scheduler và tokenizer vào 10 lõi X5, tránh chúng chạy chung với các lõi hiệu năng khác. Kết quả: decode tăng thêm 2–7%.

GDN state bf16. Cookbook mặc định dùng float32, nhưng chuyển state GDN sang bf16 nhanh hơn khoảng 3%. Cùng với đó, decode thực đo trên GB10 đạt 17,2–20,5 tok/s (thinking) và 21,6–22,7 tok/s (non-thinking), với TTFT khoảng 8,3 giây cho prompt 16K đã warm.

Khi nào tránh DSpark: giới hạn context 262K

Một lưu ý quan trọng, không thể bỏ qua. DSpark ở bản build này không dùng YaRN, và context bị giới hạn quanh mốc ~262K token. Nếu bạn cần context 1 triệu token — ví dụ xử lý tài liệu dài, hồ sơ khách hàng khổng lồ — thì phải chuyển sang MTP.

Ngoài ra, có một bài học về độ ổn định đáng ghi nhận. Trong benchmark của Kubesimplify (14–17/08/2026), cấu hình NVFP4 + MTP từng khiến máy hard-reboot 2 lần ở mức long-context và concurrency cao. Đây là lý do chúng tôi thận trọng với MTP và ưu tiên DSpark/DFlash cho các workload có độ tin cậy cao, dù tốc độ peak của MTP có thể cao hơn.

Khuyến nghị cho 5ac: agentic và coding → DSpark/DFlash

Trên cơ sở benchmark này, quyết định deploy của chúng tôi cho Qwen3.8 trên GB10 là rõ ràng: FP8 + DFlash speculative decoding, chạy trên vLLM stable, không dùng MTP. Lý do không chỉ là tốc độ, mà là sự ổn định và khớp với workload thật.

• Đúng workload: agentic, coding, tool-calling — nơi DSpark thắng.
• Ổn định: DFlash chạy vLLM stable không crash; MTP trên vLLM nightly từng hard-reboot máy 2 lần (nguồn Kubesimplify).
• Đơn giản: không vướng gotcha SM121 FP4 — FP8 chạy native sạch, mất mát chất lượng blockwise dưới 1%.

Tốc độ thực đo của FP8 + DFlash: 17,2 tok/s cho free-gen và 45+ tok/s cho trường hợp edit, với ~65,6 tok/s tổng ở mức 10 luồng đồng thời. So với FP8 thường (~8,2 tok/s), DFlash cho khoảng 2–5× tốc độ.

Kết luận: không có thuốc chữa bách bệnh, hãy đo workload của bạn

Bài học rút ra từ benchmark này không phải "DSpark tốt hơn MTP", mà là: speculative decoding phải được chọn theo workload, và được đo trên chính phần cứng của bạn. Cùng một chiếc GB10, code thắng với DSpark nhưng essay dài lại thắng với MTP. Con số trong bảng chỉ có giá trị nếu bạn hiểu mình đang chạy nhóm bài toán nào.

Với 5ac, câu trả lời là rõ ràng: workload chủ yếu là agentic và coding, nên chúng tôi chốt DSpark/DFlash và dành MTP cho những bài toán viết nội dung dài nếu phát sinh. Mọi con số ở trên đều đo thật trên GB10, và bạn có thể chạy lại toàn bộ bằng recipe mở của chúng tôi.

Nếu bạn đang vận hành một cụm AI local và phân vân giữa hai cơ chế, lời khuyên của chúng tôi rất thẳng: fork recipe, chạy benchmark n=5 với chính workload của bạn, rồi mới tin vào con số. Đừng chọn theo bảng thông số in sẵn.

Còn bạn thì sao? Workload chủ yếu của bạn là code, chat, hay văn bản dài? Hãy để lại bình luận hoặc fork repo của chúng tôi — chúng tôi đọc hết và sẽ chia sẻ thêm kinh nghiệm tuning thực tế trên GB10 trong các bài tới.