SGLang tích hợp DSpark: Đột phá suy luận LLM với giải mã dự đoán linh hoạt

Speculative decoding đánh đổi thêm tài nguyên tính toán để giảm số bước giải mã (decode steps), và sự đánh đổi này trở nên bất lợi khi tải tăng lên: với kích thước batch B và K speculative tokens, mô hình đích (target) phải xác thực B * K token mỗi bước, và vượt quá một ngưỡng nhất định, chi phí này sẽ lớn hơn lợi ích mang lại. DSpark giải quyết cả hai đầu bài toán — một trình soạn thảo khối bán tự hồi quy (semi-autoregressive block drafter - soạn thảo cả một khối mỗi lượt để duy trì tỷ lệ chấp nhận cao) và độ dài xác thực biến thiên theo từng yêu cầu dựa trên độ tin cậy của chính mô hình soạn thảo, giúp dừng xác thực các token mà workload khó có khả năng chấp nhận. Thuật toán và các cải tiến này được lấy từ bài báo DSpark.

SGLang hiện đã hỗ trợ DSpark trên cả mô hình dày đặc (dense) và thưa (sparse) (ví dụ: Qwen3 và DeepSeek-V4). Bài viết này nói về quá trình tích hợp. Chúng tôi tái hiện các kết quả cải thiện từ bài báo trên một engine phục vụ mã nguồn mở — tốc độ tăng trên mỗi người dùng và ngân sách xác thực giảm dần khi tải tăng — đồng thời mô tả kỹ thuật chuyển đổi lịch trình đó thành thời gian thực (wall-clock time): sử dụng toàn bộ CUDA graphs trên cơ chế xác thực phân mảnh (ragged) theo từng yêu cầu (để một batch đã cắt tỉa sẽ chạy lại một đồ thị thực sự nhỏ hơn, thay vì đồ thị có đệm); đường dẫn suy luận (speculative path) nhận biết sự chồng lấp giúp ẩn trình lập lịch phía sau quá trình forward; một bộ cấu hình bảng chi phí (cost-table profiler) cho phép trình lập lịch xác định ngân sách xác thực cho từng yêu cầu trực tuyến; và khả năng quan sát (observability) đối với ngưỡng chấp nhận mà việc cắt tỉa thường che giấu. Phần cứng, engine và lưu lượng truy cập đều khác với bài báo, vì vậy chúng tôi tái hiện cơ chế và đường cong thay vì các con số chính xác đến từng chữ số, và mọi từ "nhanh hơn" dưới đây đều được đo lường dựa trên các cấu hình kiểm soát của chính chúng tôi — giống hệt nhau ngoại trừ cấu hình speculation.

Tốc độ tăng so với MTP và không dùng speculation

Hình 1. Tổng thông lượng (y) so với tốc độ giải mã trên mỗi người dùng (x); mỗi đường cong quét độ đồng thời (concurrency) từ batch 1 đến 256, mỗi đường cong cho một phương pháp. Càng cao và càng về bên phải thì càng tốt.

DSpark mang lại sự cân bằng tốt nhất giữa thông lượng và độ trễ trên toàn bộ dải độ đồng thời, vượt trội rõ rệt so với cả MTP và mức nền không dùng speculation trong ví dụ ở Hình 1. Cả ba phương pháp đều chạy DeepSeek-V4-Flash trên H200 với DP-attention qua bốn rank, giống hệt nhau ngoại trừ cấu hình speculation — mức nền không dùng speculation, MTP (baseline kiểu EAGLE, phương pháp tốt nhất theo kích thước batch của các cấu hình 1-1-2 và 3-1-4), và DSpark.

Áp dụng DSpark trong SGLang

Thuật toán DSpark, được chuyển thể từ bài báo, bao gồm ba phần ở phía soạn thảo (draft-side):

Xung quanh đó, SGLang bổ sung bề mặt hỗ trợ phục vụ:

Các chế độ xác thực (Verify modes)

Ba chế độ xác thực là trục chính mà phần còn lại của bài viết này xoay quanh. static xác thực toàn bộ khối đã soạn thảo mỗi bước (baseline). compact chỉ xác thực cửa sổ theo từng yêu cầu mà trình lập lịch đã chọn — đường dẫn sản xuất (production path). cap-accept xác thực toàn bộ khối nhưng chỉ cam kết (commit) đến cửa sổ đó: đầu ra giống như compact, đồng thời phơi bày những gì mà một quá trình xác thực đầy đủ sẽ chấp nhận — đây là cách chúng tôi đo lường ngưỡng trần (ceiling) dưới tác động của việc cắt tỉa.

Xác thực phân mảnh (Ragged verify) dưới các CUDA graphs đầy đủ

Các cửa sổ theo từng yêu cầu không khớp với một CUDA graph có hình dạng cố định: một batch mà một yêu cầu xác thực hai token và yêu cầu khác xác thực sáu token không có độ dài truy vấn duy nhất, và việc đệm tất cả lên độ rộng khối đầy đủ sẽ làm mất đi hiệu quả cắt tỉa. Vì vậy, chúng tôi giữ batch ở dạng phân mảnh (ragged) và khóa đồ thị theo tổng số token — đóng gói các yêu cầu có độ dài biến thiên vào một bộ đệm compact và làm tròn lên bậc (tier) đã chụp gần nhất. Khi ngân sách cắt tỉa, tổng số lượng đóng gói giảm xuống một bậc nhỏ hơn và DSpark chạy lại một đồ thị thực sự rẻ hơn (ít hàng attention và MLP hơn, không phải là một forward full-width có mặt nạ); dưới DP attention, các rank chia sẻ chung một bậc (bậc lớn nhất mà bất kỳ rank nào cần) và cùng bước xuống.

Bộ đệm đóng gói là đầu vào varlen kiểu cu_seqlens, vì vậy xác thực compact tái sử dụng các nhân (kernel) attention mà backend đã có sẵn — trên DeepSeek-V4 là đường dẫn sparse-MLA (flash_mla) của chính mô hình, không cần nhân mới; mỗi backend được hỗ trợ chỉ cần xây dựng lại metadata varlen từ bố cục đóng gói khi chạy lại đồ thị.

Hình 2. Khớp một batch với độ dài xác thực biến thiên theo từng yêu cầu vào một CUDA graph đã chụp. Một đồ thị hình dạng cố định đệm mọi yêu cầu đến độ rộng khối đầy đủ (N x W); đường dẫn phân mảnh đóng gói các token đã lập lịch và chỉ làm tròn tổng số lên bậc đã chụp gần nhất, tính toán ít ô đệm hơn nhiều cho cùng số lượng token được chấp nhận.

Khả năng quan sát (Observability)

Việc cắt tỉa che giấu ngưỡng trần: chế độ compact chỉ xác thực một vài vị trí đầu tiên của khối — cửa sổ của trình lập lịch — vì vậy không bao giờ quan sát được có bao nhiêu token mà một quá trình xác thực toàn khối sẽ chấp nhận tại bước đó — và nếu không có nó, bạn không thể phân biệt được một lần cắt tỉa tốt với một lần cắt tỉa gây mất mát. Một lần chạy cap-accept sẽ khôi phục lại điều đó: nó xác thực toàn bộ khối nhưng chỉ cam kết đến cửa sổ, vì vậy nó cam kết chính xác những gì compact cam kết trong khi vẫn phơi bày ngưỡng trần. Chúng tôi cũng hiển thị độ tin cậy theo từng yêu cầu và các chỉ số hiệu chuẩn (ví dụ: ECE) để phân tích hậu kiểm.

Ước tính ngưỡng trần khi cắt tỉa

Một bộ ước tính chấp nhận khối (block-accept estimator), được thiết kế cho các lần chạy sản xuất hoặc các tình huống khác mà không muốn chạy thêm một lần chạy đồng hành, sẽ khôi phục ngưỡng trần bị che giấu ước tính ngay bên trong một lần chạy compact. Nó được triển khai bằng cách sử dụng các token đích trong các bước tương lai với logprobs của chúng, và tính toán các khoảng ước tính cho phần đuôi phản thực tế (counterfactual tail), giả định sự tương đồng về đặc tính của các token neo trong quỹ đạo đã cắt tỉa so với không cắt tỉa.

Cái nhìn sơ bộ về lập lịch động so với cố định

Trình lập lịch độ tin cậy là phiên bản đầu tiên, cơ bản, và chúng tôi coi nó như vậy — một bằng chứng cho thấy cơ chế hoạt động từ đầu đến cuối, không phải là một kết quả đã được tinh chỉnh cao. Chúng tôi so sánh compact (ngân sách SPS-argmax theo từng bước) với no-trim — lịch trình full-block tĩnh chạy qua cùng một đường dẫn phân mảnh — trên hai ví dụ workload khác nhau về tỷ lệ chấp nhận.

Hình 3. compact (cắt tỉa động) so với no-trim (khối đầy đủ), batch 1 đến 256 tại DP4, trên hai ví dụ khác nhau về tỷ lệ chấp nhận. Càng cao và càng về bên phải thì càng tốt.

Lợi thế của ngân sách động chủ yếu là hiệu ứng ở batch lớn. Tại kích thước batch 1, việc xác thực đích không chậm lại nhiều với nhiều token hơn, vì vậy cắt tỉa tiết kiệm được rất ít và hai phương pháp ngang nhau. Khi độ đồng thời tăng và thông lượng bắt đầu đạt ngưỡng, việc cắt tỉa làm ngắn bước và compact vượt lên. Khoảng cách lớn hơn và xuất hiện sớm hơn ở ví dụ có tỷ lệ chấp nhận thấp hơn — tỷ lệ chấp nhận thấp hơn để lại nhiều phần đuôi hơn để cắt tỉa, chính xác như mô hình chi phí dự đoán.

Mỗi bảng là một so sánh A/B sạch giữa compact và no-trim (thiết lập giống hệt nhau trong một bảng), nhưng hai ví dụ không phải là một cặp đơn biến nghiêm ngặt: ngoài tỷ lệ chấp nhận, chúng còn khác nhau một chút về thiết lập (định dạng prompt và số vòng lặp trên mỗi phương pháp), vì vậy chúng tôi đọc xu hướng trên chúng, không phải các con số tuyệt đối giữa các bảng.

Những ngân sách này cũng chỉ tốt như các bảng chi phí đằng sau chúng. Việc khớp SPS (và hiệu chuẩn) hiện tại của chúng tôi là một phép xấp xỉ đầu tiên, và nó có thể chưa tính đến đầy đủ cách chi phí bước thay đổi theo độ dài ngữ cảnh — vì vậy điểm vận hành chính xác mà trình lập lịch đạt tới có khả năng cải thiện được, và chúng tôi trình bày cơ chế ở đây thay vì một con số đã tinh chỉnh.

Phân biệt theo từng yêu cầu trên lưu lượng hỗn hợp

Các lần quét đồng nhất che giấu điểm thực sự của lập lịch độ tin cậy. Hai yêu cầu trong cùng một batch không nên nhận được cùng một cửa sổ xác thực nếu một yêu cầu dễ dự đoán hơn nhiều so với yêu cầu kia. Lưu lượng hỗn hợp là nơi điều đó quan trọng.

Hình 4. Ngân sách theo workload (trái) và phân phối độ dài xác thực theo từng bước (phải).

Ví dụ, chúng tôi trộn ba workload theo độ khó chấp nhận: gsm8k (cao), arena-hard (trung bình), và poetry (thấp). Cửa sổ co lại theo độ khó — 5.24, 3.78, 2.91 token — trong khi mức sử dụng so với ngưỡng trần (những gì khối sẽ chấp nhận nếu không cắt tỉa) vẫn ở mức cao (0.88–0.97). Trình lập lịch đang định cỡ từng yêu cầu, không áp dụng một mức trung bình cho cả batch. Bảng bên phải cho thấy điều đó từng bước: khoảng 55% các bước của gsm8k lấp đầy cửa sổ tối đa là sáu, trong khi khoảng 80% các bước của poetry sử dụng ba hoặc ít hơn.

Tối ưu hóa hiệu suất và lập lịch không chi phí (ZOS)

Hai loại kỹ thuật chuyển đổi lịch trình thành thời gian thực: cắt giảm chi phí của mỗi bước và ẩn trình lập lịch phía sau quá trình forward. Cùng nhau, chúng đạt 383.7 tok/s ở độ dài chấp nhận ~5 tại kích thước batch 1 trên DeepSeek-V4-Pro, TP=8, B300.

Chúng tôi đã viết lại các cụm toán tử nhỏ thành các nhân Triton hợp nhất (fused), chẳng hạn như compact scatter, SWA page-index, lịch trình top-k theo độ dài xác thực, và đóng gói ragged-window. Đường dẫn lấy mẫu của trình soạn thảo khối được gộp vào các nhân hợp nhất, và phép nhân ma trận của nó được phân mảnh (sharded). Trong một cấu hình ví dụ, các thành phần bên ngoài xác thực đích giảm 1.7 ms, so với 7.3 ms của quá trình xác thực.

DSpark đi thẳng vào trình lập lịch không chi phí (chồng lấp) của SGLang với hầu như không cần xử lý đặc biệt, bổ sung thêm cơ chế chuyển tiếp độ tin cậy hai bước của bài báo. Rất ít trong số này là hệ thống ống dẫn cụ thể của DSpark. Runtime spec-v2 của SGLang đã chồng lấp việc lập lịch của bước tiếp theo với quá trình forward hiện tại trên các luồng riêng biệt, và DSpark tham gia như một worker hạng nhất: đầu ra forward quay lại dưới dạng các async futures, thứ tự giữa các lần lặp chạy trên rào cản phía thiết bị của runtime, và bảng trang trên thiết bị có nghĩa là không cần đồng bộ host theo từng bước. Việc chuyển tiếp độ tin cậy sử dụng cùng một kênh, đọc lùi lại hai bước. Vòng lặp giải mã sau đó chạy mà không có bong bóng (bubble) theo từng bước — nhanh hơn khoảng 1.5 lần so với khi tắt trình lập lịch.

Hình 5. Giải mã ở kích thước batch 1, trình lập lịch chồng lấp tắt (trên) so với bật (dưới). Khi bật, không có bong bóng giữa các lần lặp run_batch hoặc giữa các giai đoạn block-draft-generate và target-verify bên trong một bước.

Lập hồ sơ bảng chi phí

Hình 6. Mô hình chi phí cộng dồn — thô so với khớp (a) và thông lượng (b) — và thời gian bước dự đoán so với đo lường (c).

Chúng tôi thể hiện ước tính của trình lập lịch về thời gian bước T(bs, K) — K là các token xác thực thêm của batch — với một mô hình cộng dồn: T(bs, K) = bias + alpha(bs) + theta(M), M = bs + K, trong đó alpha(bs) là mức nền mở rộng yêu cầu (lượt soạn thảo cộng với một phần attention), không bị ảnh hưởng bởi cắt tỉa; theta(M) là chi phí token xác thực của đích, thuật ngữ duy nhất mà việc cắt tỉa khôi phục được. Argmax của trình lập lịch đánh đổi các token được chấp nhận dự kiến với chi phí biên thực tế, vì vậy khoảng trống cắt tỉa chỉ xuất hiện ở nơi theta lớn. Hình 6(c) xác nhận các dự đoán của mô hình so với một máy chủ thực tế.

Tiếp theo là gì

DSpark hiện đã có trong SGLang. Tiếp theo là gì:

Cảm ơn các tác giả DSpark và DeepSeek vì thuật toán và các mô hình.

Phụ lục: Tái hiện