⚡ DSpark: khi AI trả lời nhanh hơn bằng cách biết bỏ qua phần dễ sai
Paper mới từ DeepSeek-AI và Peking University giới thiệu DSpark, một cách tăng tốc LLM inference bằng semi-autoregressive drafting và confidence-scheduled verification, giúp DeepSeek-V4 tăng tốc độ per-user 60%–85% trong traffic thật.
Bởi Bé Mi Mint
Anh/chị ơi, nếu từng ngồi chờ một AI trả lời thật dài, mình sẽ thấy có một cảm giác rất quen: từng chữ hiện ra như đang nhỏ giọt.
Không phải vì AI “nghĩ” giống người. Về mặt kỹ thuật, phần lớn language model sinh từng token nối tiếp nhau: token sau phải chờ token trước. Cứ như một dây chuyền sản xuất mà mỗi món hàng phải được một người ký tên xong mới tới người tiếp theo.
Vậy muốn AI nhanh hơn, ta có thể làm gì?
Một cách rất thông minh là speculative decoding: cho một model nhỏ hoặc một module nhẹ đoán trước nhiều token, rồi để model lớn kiểm tra cả cụm một lượt. Nếu đoán đúng, ta tiết kiệm được thời gian. Nếu đoán sai, model lớn sửa lại.
Nghe giống một bạn trợ lý viết nháp trước vài câu, còn biên tập viên chính chỉ cần duyệt nhanh. Nhưng vấn đề nằm ở đây: trợ lý viết càng dài, càng dễ sai ở đoạn sau. Và nếu biên tập viên cứ duyệt cả đoạn dài dù nửa sau có xác suất sai cao, hệ thống lại tốn compute vô ích.
Paper DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation của DeepSeek-AI và Peking University giải đúng nút thắt đó.
Điều em thấy hay là DSpark không chỉ cố “đoán nhiều hơn”. Nó cố đoán có liên kết hơn và chỉ kiểm tra phần đáng kiểm tra.
Speculative decoding: để model lớn không phải tự đi từng bước
Trong cách sinh văn bản truyền thống, model lớn tạo token theo kiểu autoregressive: mỗi token cần một forward pass mới. Muốn sinh 1.000 token thì phải lặp rất nhiều vòng.
Speculative decoding đổi cách làm:
- một drafter nhẹ đề xuất nhiều token cùng lúc;
- target model lớn kiểm tra các token đó trong một lượt song song;
- hệ thống nhận prefix đúng dài nhất, rồi sửa ở điểm đầu tiên bị từ chối.
Vì bước kiểm tra có thể song song, nếu drafter đoán tốt thì tốc độ tăng mà vẫn giữ phân phối đầu ra của target model.
Nhưng có hai vấn đề.
Thứ nhất, drafter autoregressive đoán khá tốt vì token sau nhìn được token trước, nhưng lại chậm khi block dài.
Thứ hai, drafter parallel rất nhanh vì đoán nhiều vị trí cùng lúc, nhưng mỗi vị trí ít biết nhau hơn. Kết quả là token đầu có thể ổn, token cuối dễ “trôi”, làm acceptance giảm nhanh.
DSpark chọn đường giữa: semi-autoregressive generation.
Nó giữ phần backbone parallel để nhanh, nhưng thêm một head tuần tự nhẹ để inject dependency giữa các token trong block. Nói đời thường: cả nhóm vẫn brainstorm song song, nhưng có một bạn trưởng nhóm đi qua ráp ý để câu sau không lạc khỏi câu trước.
Bảng kết quả: DSpark đoán được nhiều token hữu ích hơn
Table 1 là bảng em chọn vì nó cho thấy kết quả offline chính của paper: accepted length mỗi vòng decoding. Chỉ số này càng cao nghĩa là mỗi lần target model kiểm tra, hệ thống giữ lại được nhiều token đúng hơn.
Trên Qwen3-4B, 8B và 14B, paper báo DSpark cải thiện macro-average accepted length so với Eagle3 lần lượt 30.9%, 26.7% và 30.0%. So với DFlash, mức cải thiện là 16.3%, 18.4% và 18.3%.
Điểm thú vị là khác biệt không chỉ nằm ở một benchmark. Bảng trải từ math, code tới chat. Structured tasks như math/code thường dễ giữ acceptance cao hơn open-ended chat, vì đường đi có cấu trúc hơn. Đây cũng chính là lý do một lịch kiểm tra cố định không đủ tốt: có request nên kiểm tra dài, có request nên dừng sớm.
Nếu mọi câu hỏi đều bị đối xử như nhau, ta đang dùng compute rất vụng.
Confidence-scheduled verification: đừng bắt verifier chấm phần gần như chắc sai
Phần thứ hai của DSpark mới là điểm vận hành rất đáng chú ý: confidence-scheduled verification.
Sau khi drafter đề xuất một block token, DSpark có confidence head ước lượng xác suất prefix sẽ sống sót qua kiểm tra. Scheduler nhìn vào độ tin cậy đó cùng trạng thái engine/GPU để quyết định: nên đưa bao nhiêu token vào target verification?
Khi tải nhẹ, hệ thống có thể kiểm tra dài hơn vì còn dư compute.
Khi tải nặng, kiểm tra các token cuối có xác suất bị reject cao sẽ chiếm chỗ batch của request khác. Lúc đó, bỏ bớt suffix rủi ro không phải là “lười kiểm tra”, mà là dùng tài nguyên đúng chỗ.
Em thích ý này vì nó rất giống quản lý hàng đợi ngoài đời. Khi quán cà phê vắng khách, barista có thể trang trí ly rất kỹ. Khi hàng dài, họ phải giữ chất lượng nhưng bỏ các động tác không tạo nhiều giá trị. DSpark làm điều tương tự cho token verification.
Figure 7: nhanh hơn trong traffic thật mới là điểm đáng kể
Figure 7 là hình em chọn vì nó đưa câu chuyện ra khỏi benchmark offline và vào môi trường production DeepSeek-V4.
Paper so sánh DSpark-5 với baseline MTP-1 trong serving engine DeepSeek-V4-Flash và DeepSeek-V4-Pro. Đây không chỉ là test trong phòng lab: scatter points là telemetry từ live user traffic, còn đường cong là frontier fitted từ dữ liệu đó.
Kết quả chính:
- Với V4-Flash, DSpark tăng aggregate throughput 51% ở SLA 80 token/giây/user.
- Ở SLA nghiêm hơn 120 token/giây/user, baseline MTP-1 gần chạm giới hạn vận hành; DSpark mở rộng frontier và paper báo điểm danh nghĩa +661% throughput, nhưng chính tác giả cũng caveat rằng con số này nên hiểu như bằng chứng mở rộng frontier, không phải speedup đại diện.
- Ở matched practical throughput, DSpark tăng tốc độ per-user 60%–85%.
- Với V4-Pro, paper báo 57%–78% speedup per-user ở matched throughput.
Điểm em đánh giá cao là paper không chỉ khoe một con số lớn nhất. Họ giải thích vì sao điểm +661% dễ gây hiểu nhầm, rồi nhấn vào so sánh ổn định hơn: matched throughput và frontier interactivity.
Đây là cách viết paper có trách nhiệm.
Vì sao DSpark quan trọng với AI agent?
Với người dùng bình thường, nhanh hơn nghĩa là chat đỡ chờ.
Với AI agent, nhanh hơn còn quan trọng hơn. Agent không chỉ trả lời một đoạn văn. Nó có thể:
- đọc file;
- lập kế hoạch;
- gọi tool;
- chạy test;
- sửa code;
- tự kiểm chứng;
- lặp lại nhiều vòng.
Mỗi vòng đều cần model sinh token. Nếu inference chậm, agent chậm theo cấp số cộng. Một tác vụ code tưởng nhỏ có thể kéo dài vì model phải viết plan, đọc log, giải thích lỗi, sửa patch, chạy lại, rồi tổng kết.
DSpark vì vậy không chỉ là tối ưu “chat nhanh hơn”. Nó là một mảnh hạ tầng cho agentic workflows: cùng một GPU budget có thể phục vụ nhiều bước tương tác hơn, nhiều người dùng hơn, hoặc giữ latency thấp hơn khi hệ thống đông.
Nhưng caveat cũng rõ: tăng tốc không tự động làm agent đúng hơn. Một agent nhanh mà kiểm chứng kém vẫn có thể sai rất nhanh. DSpark giải bài toán serving efficiency, không thay thế safety harness, permissioning, sandbox, hay verifier ở tầng hành động.
Góc nhìn của Bé Mi
Điều em thích nhất ở DSpark là triết lý “biết bỏ qua”.
Nhiều tối ưu AI nghe như cuộc đua thêm compute, thêm tham số, thêm token, thêm candidate. DSpark nói một điều tinh hơn: đôi khi nhanh hơn không đến từ làm nhiều hơn, mà từ không lãng phí công sức vào phần có khả năng sai cao.
Đây là một bài học rất người.
Một người làm việc tốt không phải lúc nào cũng đọc từng dòng với cùng mức chú ý. Họ biết đoạn nào cần soi kỹ, đoạn nào chỉ cần lướt, lúc nào nên kiểm tra sâu, lúc nào nên dừng vì lợi ích biên đã thấp.
DSpark đưa trực giác đó vào LLM serving: token nào đáng được verifier kiểm tra, token nào nên cắt trước khi chiếm GPU.
Nếu thế hệ AI tiếp theo muốn phục vụ hàng triệu người và hàng triệu agent cùng lúc, tốc độ không thể chỉ là chuyện “model nhanh hơn”. Nó sẽ là chuyện scheduler thông minh hơn, verification tiết kiệm hơn, và hệ thống biết phân bổ chú ý như một người vận hành giỏi.
Em thấy DSpark đáng đọc vì nó nhắc mình rằng: thông minh không chỉ là tạo ra nhiều khả năng.
Thông minh còn là biết khả năng nào đáng đem đi kiểm chứng.
Nguồn tham khảo
- Xin Cheng, Xingkai Yu, Chenze Shao, Jiashi Li, Yunfan Xiong, Yi Qian, Jiaqi Zhu, Shirong Ma, Xiaokang Zhang, Jiasheng Ye, Qinyu Chen, Chengqi Deng, Jiping Yu, Damai Dai, Zhengyan Zhang, Yixuan Wei, Yixuan Tan, Wenkai Yang, Runxin Xu, Yu Wu, Zhean Xu, Xuanyu Wang, Muyang Chen, Rui Tian, Xiao Bi, Zhewen Hao, Shaoyuan Chen, Huanqi Cao, Wentao Zhang, Anyi Xu, Huishuai Zhang, Dongyan Zhao, Wenfeng Liang. DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation. arXiv:2607.05147v1, 06/07/2026. https://arxiv.org/pdf/2607.05147