DFlash: Đột phá giới hạn tốc độ của Speculative Decoding với Block Diffusion

Một kỹ sư phục vụ mô hình (serving engineer) thường nhìn các token (ký tự) xuất hiện với tốc độ nhỏ giọt: đủ nhanh để demo, nhưng đủ chậm để cảm thấy như mô hình vẫn đang gõ phím từng cái một. DFlash quan trọng vì nó đề xuất một lối thoát khỏi nhịp điệu chậm chạp đó.

Mệnh đề chính của DFlash có thể tóm gọn trong một câu: DFlash là con đường khả thi đầu tiên biến Speculative Decoding từ một thủ thuật tối ưu hóa thành một kiến trúc phục vụ, bởi nó loại bỏ giả định ngầm rằng mô hình dự thảo (drafter) phải hoạt động tuần tự.

Về mặt kỹ thuật, Z Lab’s DFlash thay thế mô hình dự thảo tự hồi quy (autoregressive drafter) truyền thống trong Speculative Decoding bằng một mô hình block diffusion nhẹ nhàng, có thể dự thảo cả một khối token song song dựa trên các tính năng ẩn từ mô hình mục tiêu. Các tác giả báo cáo mức tăng tốc hơn 6× không mất mát dữ liệu (lossless acceleration) trên một số cấu hình, cùng với tốc độ nhanh hơn EAGLE-3 tới 2,5× trên Qwen3-8B. Thư viện đã được tích hợp vào SGLang và có hỗ trợ sơ bộ cho vLLM. Tuy nhiên, con số không phải là toàn bộ câu chuyện.

Câu chuyện nằm ở cấu trúc chi phí. Khi việc dự thảo không còn là "một token nữa, một bước nữa", trần giới hạn của Speculative Decoding không còn trông giống như một quy luật tự nhiên nữa, mà trở thành hệ quả của những lựa chọn thiết kế cũ kỹ.

Tại sao Speculative Decoding lại gặp trần tốc độ

Bức tranh thông thường rất đơn giản. Một mô hình dự thảo nhỏ chạy trước và đề xuất các token; mô hình mục tiêu lớn kiểm tra chúng song song và chấp nhận bao nhiêu tùy khả năng. Khi các dự đoán chính xác, bạn tiết kiệm thời gian.

Tuy nhiên, mô hình dự thảo thường bị mắc kẹt ở việc leo cầu thang.

Mỗi token dự thảo thêm vào nghĩa là một bước tuần tự tiếp theo. Đó là lý do các hệ thống thực tế như EAGLE-3 có thể cải thiện tình hình nhưng vẫn bị giới hạn quanh mức 2–3× trong sử dụng thực tế: bộ xác minh (verifier) hoạt động song song, nhưng mô hình dự thảo vẫn phải trả chi phí độ trễ từng token một. Để giữ chi phí thấp, mô hình dự thảo bị ép buộc phải có thiết kế rất nông (shallow). Z Lab chỉ ra rõ ràng vấn đề này—một mô hình dự thảo một lớp đủ nhanh để hữu ích, nhưng lại quá mỏng manh đến mức chất lượng dự thảo trở thành nút thắt cổ chai.

Vậy giới hạn này không bao giờ chỉ là "GPU khó sử dụng" hay "kernel cần tinh chỉnh". Nó đến từ sự kết hợp cơ bản hơn: nhanh cộng với tự hồi quy (autoregressive). Kỹ thuật tốt hơn có thể mài mòn cạnh sắc này, nhưng không thể loại bỏ nó.

Đó là lý do DFlash cảm thấy khác biệt. Nó không cố nén chặt đường ống cũ kỹ hơn. Nó thay đổi bản thân của bộ phận tốn kém nhất.

DFlash thay đổi sự đánh đổi trong Speculative Decoding như thế nào

DFlash giữ nguyên vòng lặp bên ngoài của Speculative Decoding. Mô hình lớn vẫn xác minh. Hệ thống vẫn phụ thuộc vào tỷ lệ chấp nhận cao. Điều thay đổi là loại mô hình thực hiện việc dự thảo.

Thay vì tạo ra token từng cái một, DFlash sử dụng block diffusion để tạo ra cả một khối token song song. Trên trang dự án, cấu hình được trình bày sử dụng kích thước khối là 16 với một bước khử nhiễu (denoising step). Điều này nghe có vẻ như một chi tiết triển khai nhỏ. Nhưng thực tế không phải vậy.

Hãy lấy một ví dụ về ngân sách độ trễ. Một mô hình dự thảo tự hồi quy đề xuất 8 token sẽ cần 8 bước tạo tuần tự trước khi xác minh. Một mô hình dự thảo kiểu DFlash có thể tạo ra khối 16 token chỉ trong một lần truyền tiến (forward pass), sau đó chuyển khối đó cho bộ xác minh. Ngay cả trước khi nhìn vào các biểu đồ benchmark, điều này đã thay đổi cách một stack phục vụ phân bổ thời gian. Câu hỏi cũ là "Tôi có thể chịu đựng bao nhiêu bước tuần tự trước khi người dùng nhận ra?". Câu hỏi mới là "Tôi có thể đóng gói bao nhiêu chất lượng dự thảo vào một lần truyền song song?".

Đó là một bài toán phân bổ ngân sách hoàn toàn khác.

Và nó mang lại một lợi ích cụ thể: độ sâu (depth). Nếu chi phí dự thảo gần như phẳng bất kể độ dài khối, thì một mô hình dự thảo sâu hơn trở nên khả thi về mặt chi phí. Z Lab so sánh trực tiếp: một DFlash đa lớp có thể tạo ra 16 token với độ trễ thấp hơn một EAGLE-3 một lớp tạo ra 8 token. Nhiều không gian hơn để suy nghĩ, nhiều token dự thảo hơn, ít đau đầu hơn về thời gian thực.

Đây là phần khiến câu chuyện trở nên kỳ lạ. Diffusion từ lâu đã trông có vẻ hơi sai lầm khi áp dụng cho văn bản, giống như mang bình sơn đến một buổi học thư pháp. Ngôn ngữ muốn trật tự từ trái sang phải; diffusion lại thích tinh chỉnh song song. DFlash hoạt động vì nó không yêu cầu diffusion trở thành mô hình ngôn ngữ chính. Nó giao cho diffusion một công việc hệ thống hẹp: dự thảo một khối dữ liệu để mô hình thực sự có thể xác minh một cách rẻ tiền.

Bước đi này khiến việc dự thảo token song song trông ít giống một thủ thuật trên giấy hơn và giống một bản thiết kế cho việc phục vụ (serving) hơn.

Tại sao Block Diffusion lại đánh bại Autoregressive Drafting

Điểm thông minh không chỉ là tính song song. Nó nằm ở chỗ mô hình dự thảo nhận được gợi ý từ đâu.

DFlash điều kiện hóa (condition) mô hình dự thảo dựa trên các tính năng ẩn (hidden features) được lấy từ chính mô hình mục tiêu. Cụ thể hơn: sau khi mô hình mục tiêu đã thực hiện công việc trên câu lệnh (prompt)—trong quá trình prefill, và một lần nữa quanh đường dẫn xác minh—hệ thống lấy mẫu các trạng thái ẩn từ nhiều lớp của mô hình mục tiêu, chiếu các tính năng đó xuống một biểu diễn nhỏ hơn và đưa chúng vào mô hình dự thảo diffusion làm điều kiện.

Chi tiết này quan trọng vì tỷ lệ chấp nhận (acceptance rate) là toàn bộ cuộc chơi.

Một mô hình dự thảo tự hồi quy nhỏ bé chỉ làm việc từ câu lệnh sẽ phải đoán tương lai gần như mù quáng. Một mô hình dự thảo diffusion được điều kiện hóa bởi các tính năng của mô hình mục tiêu đang làm một việc hoàn toàn khác. Nó mượn tầm nhìn nội bộ một phần của mô hình mục tiêu về những gì sẽ đến tiếp theo. Mô hình lớn đã xây dựng một biểu diễn phong phú về chuỗi; DFlash biến một phần cấu trúc nội bộ đó thành hướng dẫn để dự thảo cả một khối dữ liệu cùng lúc.

Các tính năng ẩn là các kích hoạt trung gian của mô hình—giàn giáo đang xây dở trước khi token hiển thị tiếp theo rơi xuống. Lấy mẫu từ nhiều lớp, bạn nhận được các tín hiệu ở các cấp độ trừu tượng khác nhau: cú pháp cục bộ, cụm từ tầm trung, hướng ngữ nghĩa rộng hơn. Chiếu chúng, nén chúng, chuyển cho mô hình dự thảo, và mô hình dự thảo sẽ bắt đầu từ một điểm khởi đầu tốt hơn nhiều.

Đó là lý do việc điều kiện hóa được gắn trực tiếp với tỷ lệ chấp nhận. Các dự thảo rẻ tiền là vô dụng nếu quá trình xác minh từ chối hầu hết chúng. Cược của DFlash là việc dự thảo được thông tin bởi mục tiêu có thể giữ tỷ lệ chấp nhận đủ cao để chi phí khối tương đối phẳng thực sự biến thành tăng tốc độ đầu cuối.

Và đó là điểm kiến trúc sâu sắc hơn. Chúng ta thường coi mô hình mục tiêu như một hộp kín có sản phẩm hữu dụng duy nhất là token tiếp theo. DFlash coi nội bộ của mô hình là cơ sở hạ tầng có thể tái sử dụng. Một khi bạn thấy điều đó, stack phục vụ trông khác đi. Mô hình mục tiêu không chỉ là bộ tạo. Nó là nguồn hướng dẫn cho các mô hình phụ trợ.

Các con số benchmark chứng minh và không chứng minh điều gì

Hãy nói rõ ràng đây: đây là kết quả hứa hẹn do chính tác giả chạy, chưa phải là phán quyết cuối cùng của toàn ngành.

Các con số được báo cáo rất mạnh mẽ. Tóm tắt bài báo tuyên bố tăng tốc hơn 6× không mất mát trên một loạt cài đặt. Trang dự án báo cáo tăng tốc tốt hơn gần 2,5× so với EAGLE-3 trên Qwen3-8B. Kho lưu trữ (repo) cho thấy đủ chi tiết triển khai—tích hợp SGLang, ghi chú hỗ trợ mô hình, vLLM qua các đường dẫn nightly build—để làm cho điều này nhiều hơn một ý tưởng mơ hồ.

Nhưng vẫn có những ranh giới rõ ràng quanh những gì chúng ta biết.

Thứ nhất, lợi ích cụ thể theo phần phụ trợ (backend). Thứ hai, cụ thể theo họ mô hình. Thứ ba, các câu lệnh benchmark sạch sẽ không giống với lưu lượng truy cập sản xuất, nơi độ dài chuỗi thay đổi hoang dã, batching trở nên lộn xộn và một yêu cầu xấu xí có thể làm tắc nghẽn dòng.

Việc xác thực độc lập sẽ cần phải chứng minh bốn điều:

• Mô hình lớn hơn: không chỉ là vùng an toàn lớp 8B, mà liệu phương pháp có giữ hoạt động khi các mô hình mục tiêu trở nên đắt đỏ hơn hay không.
• Bối cảnh dài hơn (Longer contexts): vì hành vi độ trễ thay đổi khi prefill và áp lực cache chiếm ưu thế.
• Khối lượng công việc thực tế hỗn hợp: các cuộc trò chuyện ngắn, các vết lý luận dài, thành phần batch không đồng đều, không chỉ là các nhiệm vụ benchmark gọn gàng.
• Khả năng tái tạo trên các stack và phần cứng khác nhau: SGLang, vLLM, cài đặt GPU khác nhau và lợi ích nhất quán bên ngoài môi trường của chính tác giả.

Đó là sự khác biệt giữa "kết quả thú vị" và "mặc định mới".

Tuy nhiên, tôi sẽ không đánh giá thấp những gì đã xảy ra. DFlash cung cấp cho các kỹ sư phục vụ một lý do cụ thể để ngừng coi Speculative Decoding là một bước tối ưu hóa hẹp. Nếu mô hình dự thảo của bạn có thể song song, được điều kiện hóa bởi các tính năng mục tiêu và được đánh giá như một thành phần ngân sách độ trễ thay vì một mô hình ngôn ngữ nhỏ bé đứng riêng lẻ, thì chính kiến trúc sẽ mở ra.

Các stack phục vụ thực sự có thể tái sử dụng điều gì từ đây? Khá nhiều, ngay cả trước khi áp dụng hoàn toàn. Các nhóm SGLang và vLLM có thể mượn ý tưởng tổ chức này:

• giữ mô hình mục tiêu làm bộ xác minh
• lộ các đường dẫn tính năng ẩn như các tín hiệu hạng nhất
• coi việc dự thảo như một hệ thống con song song
• tối ưu hóa tỷ lệ chấp nhận và hành vi lập lịch cùng nhau

Đó là cách một thủ thuật tối ưu hóa trở thành một kiến trúc phục vụ.

Hình ảnh mở đầu vẫn là hình ảnh đúng đắn: một màn hình đầy các token đến trong một cơn mưa nhỏ gọn gàng. Với các hệ thống suy đoán cũ hơn, mưa vẫn rơi từng giọt một, chỉ nhanh hơn một chút. DFlash gợi ý một mô hình thời tiết khác. Không phải một người đánh máy giỏi hơn. Một cỗ máy khác.

Các điểm chính

• Speculative Decoding gặp trần giới hạn thực tế vì mô hình dự thảo vẫn tuần tự, khiến độ trễ tăng lên từng token một.
• DFlash thay đổi cấu trúc chi phí này bằng cách sử dụng block diffusion để dự thảo cả một khối token song song.
• Bước di chuyển kỹ thuật quan trọng là điều kiện hóa mô hình dự thảo trên các tính năng ẩn được lấy mẫu từ nhiều lớp mô hình mục tiêu và chiếu thành tín hiệu hướng dẫn nhỏ gọn.
• Các lợi ích được báo cáo ấn tượng nhưng vẫn là kết quả do tác giả chạy, cụ thể theo phần phụ trợ và chưa được thiết lập độc lập trên các điều kiện sản xuất.
• Ý nghĩa lớn hơn là về mặt kiến trúc: DFlash là tín hiệu khả thi đầu tiên cho thấy Speculative Decoding có thể trở thành một thiết kế phục vụ mô-đun, không chỉ là một mẹo tăng tốc.

Đọc thêm

• DFlash: Block Diffusion for Flash Speculative Decoding — Z Lab — Trang dự án chính với luận điểm của các tác giả, tuyên bố benchmark và ghi chú triển khai.
• z-lab/dflash — GitHub — Kho lưu trữ với cài đặt, các phần phụ trợ được hỗ trợ, ghi chú đánh giá và chi tiết trích dẫn.
• DFlash: Block Diffusion for Flash Speculative Decoding — arXiv — Tóm tắt bài báo chính và khung kỹ thuật của phương pháp và kết quả.
• z-lab/dflash collection — Hugging Face — Bộ sưu tập mô hình được dự án tham chiếu cho các trọng số và demo có sẵn.
• EAGLE-3: Speculative Decoding with Autoregressive Drafting — arXiv — Điểm so sánh hữu ích cho đường cơ bản Speculative Decoding hiện tại được DFlash thảo luận.