Derpy
Intern Writer
Bạn có bao giờ cảm thấy khó chịu khi chờ đợi AI trả lời, cứ như thể nó đang "nhỏ giọt" từng chữ một không? Trong thế giới công nghệ đang tăng tốc chóng mặt, tốc độ phản hồi của các mô hình AI lớn (LLM) là yếu tố then chốt quyết định trải nghiệm người dùng. Và mới đây, DeepSeek, một cái tên đang rất tích cực trong việc tuyển dụng và phát triển AI, đã công bố một bước đột phá đáng chú ý, hứa hẹn sẽ thay đổi cách chúng ta tương tác với AI.
Hôm nay, DeepSeek cùng với đội ngũ từ Đại học Bắc Kinh đã công bố một nghiên cứu mang tên "DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation". Đây là một khung tăng tốc suy luận mới dành cho các mô hình ngôn ngữ lớn, và điều đặc biệt là nó đã được tích hợp vào hệ thống sản xuất của DeepSeek, cụ thể là DeepSeek-V4-Flash preview và DeepSeek-V4-Pro preview, thay thế cho giải pháp MTP-1 trước đây.
Kết quả thực tế từ lưu lượng người dùng trực tuyến cho thấy DSpark mang lại hiệu quả ấn tượng. Với cùng mức thông lượng hệ thống tổng thể, DSpark đã giúp tăng tốc độ tạo nội dung cho một người dùng của DeepSeek-V4-Flash lên từ 60% đến 85%. Đối với DeepSeek-V4-Pro, mức tăng này cũng đạt từ 57% đến 78%. Vậy DeepSeek đã "phù phép" gì cho công nghệ của mình để đạt được những con số đáng kinh ngạc này?
Để hiểu rõ hơn, chúng ta cần nhìn vào cách các mô hình ngôn ngữ lớn hoạt động. Hầu hết chúng tạo văn bản theo phương pháp tự hồi quy (autoregressive), nghĩa là mô hình sẽ tạo ra từng "token" (đơn vị văn bản nhỏ nhất) một. Mỗi khi một token mới được tạo ra, mô hình phải thực hiện một phép tính dựa trên toàn bộ văn bản đã có. Điều này có nghĩa là văn bản càng dài, số bước giải mã càng nhiều, và độ trễ càng dễ tích lũy. Đối với các ứng dụng tương tác cao như trò chuyện thời gian thực, quy trình làm việc của tác nhân thông minh (Agent workflow) hay trợ lý viết mã, tốc độ tạo nội dung ảnh hưởng trực tiếp đến trải nghiệm người dùng và cả hiệu suất sử dụng GPU.
Giải mã suy đoán (speculative decoding) ra đời để giải quyết vấn đề này. Ý tưởng của nó giống như việc có một "mô hình nháp" (draft model) nhỏ hơn viết trước một bản nháp, sau đó một "mô hình đích" (target model) lớn hơn sẽ nhanh chóng kiểm tra bản nháp đó. Hệ thống sẽ dùng mô hình nháp nhẹ để tạo ra một chuỗi các token ứng cử viên. Sau đó, mô hình đích, vốn chịu trách nhiệm về chất lượng đầu ra, sẽ xác minh các token này cùng một lúc. Những token được xác minh sẽ được chấp nhận. Nếu một token nào đó bị từ chối, tất cả các token ứng cử viên phía sau nó cũng sẽ bị loại bỏ, và mô hình đích sẽ tạo ra một token sửa chữa. Vì giai đoạn xác minh có thể diễn ra song song, giải mã suy đoán có thể tăng tốc độ tạo nội dung mà không làm thay đổi phân bố đầu ra của mô hình đích. Nói một cách đơn giản, nó giúp mô hình lớn xác nhận nhiều token hơn trong một lần tính toán, thay vì chỉ một token mỗi lần.
Tuy nhiên, các phương pháp giải mã suy đoán hiện có vẫn còn những hạn chế đáng kể. Loại đầu tiên là mô hình nháp tự hồi quy. Nó tạo ra các token ứng cử viên tuần tự, từng cái một, giống như một mô hình ngôn ngữ thông thường. Ưu điểm là mối quan hệ giữa các token tự nhiên hơn và chất lượng ứng cử viên cao. Nhưng nhược điểm là mô hình nháp cũng phải làm việc từng bước, nên càng nhiều token ứng cử viên thì giai đoạn nháp càng chậm.
Loại thứ hai là mô hình nháp song song (parallel draft model). Nó có thể tạo ra nhiều token ứng cử viên cùng lúc, rất nhanh và phù hợp để tạo ra các khối ứng cử viên dài. Vấn đề là các token bên trong khối ứng cử viên này thiếu mối quan hệ phụ thuộc lẫn nhau. Ví dụ, khi đối mặt với một ngữ cảnh, mô hình có thể có hai cách tiếp tục hợp lý là "of course" hoặc "no problem". Mô hình nháp song song, vì không thực sự tạo ra theo thứ tự, rất dễ trộn lẫn hai đường dẫn này, tạo ra những cụm từ không nhất quán như "of problem" hoặc "no course". Kết quả là, các token đầu tiên của mô hình nháp song song thường khá tốt, nhưng càng về sau, khả năng các token ứng cử viên được mô hình đích chấp nhận càng giảm nhanh. Hiện tượng này được gọi là suy giảm hậu tố (suffix decay).
Một vấn đề thực tế hơn nữa xảy ra trong các dịch vụ trực tuyến. Mô hình nháp song song dễ dàng tạo ra một chuỗi dài các token ứng cử viên, nhưng trong môi trường dịch vụ có độ đồng thời cao, việc gửi tất cả các token này cho mô hình đích để xác minh có thể không hiệu quả. Đối với các tác vụ có cấu trúc như toán học hay mã hóa, đường dẫn câu trả lời tương đối rõ ràng, nên các token ứng cử viên dễ được chấp nhận hơn. Ngược lại, các cuộc trò chuyện mở có tính không chắc chắn cao hơn, và các token sau đó dễ bị từ chối hơn. Khi hệ thống rảnh rỗi, việc xác minh thêm vài token không ảnh hưởng nhiều. Nhưng khi hệ thống bận rộn, việc xác minh những token có khả năng cao bị từ chối sẽ chiếm dụng dung lượng lô (batch capacity) của mô hình đích, ảnh hưởng đến các yêu cầu của người dùng khác. Nói cách khác, vấn đề của giải mã suy đoán không chỉ là liệu có thể tạo ra nhiều token hơn trong một lần hay không, mà còn là token nào đáng để mô hình đích xác minh.
DSpark giải quyết những thách thức này bằng cách kết hợp hai ý tưởng chính: bản nháp phải chất lượng hơn và quá trình kiểm duyệt phải thông minh hơn.
Về phía tạo nội dung, DSpark sử dụng kiến trúc bán tự hồi quy (semi-autoregressive architecture). Nó giữ lại phần cốt lõi của mô hình nháp song song, cho phép phần lớn các phép tính hoàn thành cùng lúc. Đồng thời, nó bổ sung một mô-đun tuần tự nhẹ ở đầu ra, giúp các token sau có thể tham chiếu đến các token đã được lấy mẫu trước đó. Chúng ta có thể hình dung nó như thế này: phần đầu tiên dùng phương pháp song song để nhanh chóng tạo ra các ứng cử viên, sau đó một mô-đun tuần tự rất nhẹ sẽ kiểm tra mối liên kết giữa các token liền kề. Nghiên cứu mặc định sử dụng Markov head, một phương pháp mô hình hóa mối quan hệ chuyển đổi giữa các token liền kề với chi phí tính toán thấp, dễ triển khai.
Về phía xác minh, DSpark giới thiệu xác minh theo lịch trình dựa trên độ tin cậy (confidence-scheduled verification). Hệ thống sẽ dự đoán một điểm số độ tin cậy (confidence score) cho mỗi vị trí ứng cử viên. Điểm số này cho biết khả năng token ở vị trí hiện tại tiếp tục được chấp nhận cao đến mức nào, với điều kiện các token trước đó đã được mô hình đích chấp nhận. Sau đó, một bộ lập lịch tiền tố nhận biết phần cứng (hardware-aware prefix scheduler) sẽ tự động quyết định số lượng token cần xác minh cho mỗi yêu cầu dựa trên ba yếu tố: tải hệ thống hiện tại, độ tin cậy của từng vị trí ứng cử viên, và đường cong thông lượng (throughput curve) của công cụ ở các kích thước lô khác nhau.
Nhờ vậy, DSpark không xác minh một cách máy móc các khối ứng cử viên có độ dài cố định. Khi tài nguyên hệ thống dồi dào, nó có thể xác minh một tiền tố (prefix) dài hơn, giúp một lần tính toán của mô hình đích tạo ra nhiều token hiệu quả nhất có thể. Khi tải hệ thống tăng cao, DSpark sẽ tự động rút ngắn độ dài xác minh của các yêu cầu có độ tin cậy thấp, giảm thiểu việc chiếm dụng dung lượng lô của mô hình đích. Đây chính là điểm khiến DSpark gần với môi trường sản xuất thực tế hơn so với các phương pháp giải mã suy đoán truyền thống: nó không chỉ theo đuổi việc tạo ra nhiều token ứng cử viên hơn trong một lần, mà còn điều chỉnh ngân sách xác minh dựa trên tải hệ thống.
Cuối cùng, chúng ta nhận ra rằng giới hạn của các mô hình lớn không chỉ nằm ở vấn đề kỹ thuật mô hình phức tạp, mà còn là một bài toán kỹ thuật hệ thống phức tạp.
Các thử nghiệm ngoại tuyến đã được thực hiện trên bốn mô hình đích: Qwen3-4B, Qwen3-8B, Qwen3-14B và Gemma4-12B, so sánh DSpark với hai giải pháp tiêu biểu là mô hình nháp tự hồi quy Eagle3 và mô hình nháp song song DFlash. Các đánh giá bao gồm suy luận toán học, tạo mã và trò chuyện hàng ngày, sử dụng các bộ dữ liệu chuẩn như GSM8K, MATH500, AIME25, MBPP, HumanEval, Live-CodeBench, MT-Bench, Alpaca và Arena-Hard.
Kết quả cho thấy, trên Qwen3-4B, Qwen3-8B và Qwen3-14B, DSpark đã cải thiện độ dài chấp nhận trung bình (macro-average accepted length) lần lượt là 30.9%, 26.7% và 30.0% so với Eagle3. So với DFlash, mức cải thiện là 16.3%, 18.4% và 18.3%. Trên Gemma4-12B, DSpark cũng duy trì vị trí dẫn đầu. Độ dài chấp nhận có thể hiểu là số lượng token trung bình được mô hình đích chấp nhận trong mỗi vòng giải mã suy đoán. Con số này càng cao, chứng tỏ bản nháp của mô hình nháp càng được mô hình lớn chấp nhận, và không gian tăng tốc suy luận càng lớn.
Nghiên cứu cũng chỉ ra sự khác biệt lớn giữa các loại nhiệm vụ. Ví dụ, với Qwen3-4B, độ dài chấp nhận trung bình của DSpark trong các nhiệm vụ toán học là 5.57, trong nhiệm vụ mã hóa là 5.12, và trong nhiệm vụ trò chuyện là 3.49. Điều này cho thấy toán học và mã hóa có cấu trúc rõ ràng hơn, đường dẫn tiếp tục ổn định hơn, trong khi trò chuyện mở hơn, mô hình có thể có nhiều cách trả lời hợp lý. Do đó, cùng một độ dài token ứng cử viên, giá trị của chúng trong các nhiệm vụ khác nhau là không giống nhau. Việc xác minh độ dài cố định sẽ lãng phí một phần tài nguyên tính toán.
Các thử nghiệm chi tiết hơn đã giải thích lý do DSpark hiệu quả. Các mô hình nháp song song như DFlash rất mạnh ở token ứng cử viên đầu tiên vì chúng có thể sử dụng mạng sâu hơn để tạo ra ứng cử viên cùng lúc. Nhưng từ token thứ hai trở đi, do thiếu sự phụ thuộc nội khối, tỷ lệ chấp nhận giảm rõ rệt hơn. Các mô hình nháp tự hồi quy như Eagle3 có tính nhất quán tốt hơn ở phần sau vì chúng thực sự tạo ra theo thứ tự. Tuy nhiên, để kiểm soát độ trễ trong giai đoạn nháp, chúng thường không thể làm quá sâu, do đó khả năng dự đoán của token đầu tiên bị hạn chế. DSpark nằm ở giữa hai loại này. Token đầu tiên kế thừa khả năng dự đoán mạnh mẽ của mô hình nháp song song, và các token sau đó giảm suy giảm hậu tố thông qua mô-đun tuần tự.
Các thử nghiệm cấu trúc cũng ủng hộ nhận định này. Nghiên cứu cho thấy DSpark 2 lớp đã vượt qua DFlash 5 lớp, chứng tỏ mô hình hóa tuần tự nhẹ hiệu quả hơn việc đơn thuần tăng số lớp song song. Khi độ dài đề xuất (proposal length) tăng từ 4 lên 16, lợi thế của DSpark so với DFlash tiếp tục mở rộng. Ở cài đặt dài nhất, DSpark dẫn trước DFlash lần lượt 30% trong nhiệm vụ toán học, 26% trong mã hóa và 22% trong trò chuyện.
Về độ trễ, mô-đun tuần tự chỉ mang lại chi phí bổ sung rất nhỏ. Trong thử nghiệm với kích thước lô 128, độ trễ một vòng của DSpark chỉ tăng từ 0.2% đến 1.3% so với DFlash, nhưng độ dài chấp nhận tăng tới 30%. Mô-đun độ tin cậy cũng đã được xác minh riêng. Nghiên cứu đã thực hiện quét ngưỡng độ tin cậy trên Qwen3-4B, tức là liên tục nâng cao ngưỡng độ tin cậy để quan sát hệ thống sẽ giữ lại những token nào. Kết quả rõ ràng: ngưỡng càng cao, hệ thống càng lọc bỏ nhiều token ứng cử viên giá trị thấp, và tỷ lệ chấp nhận tổng thể càng cao. Nhiệm vụ trò chuyện có sự thay đổi rõ rệt nhất, tỷ lệ chấp nhận tăng từ 45.7% lên 95.7%; nhiệm vụ toán học từ 76.9% lên 92.5%; nhiệm vụ mã hóa từ 67.6% lên 92.0%.
Phần triển khai trực tuyến còn quan trọng hơn. DeepSeek đã triển khai DSpark trong công cụ sản xuất của DeepSeek-V4-Flash preview và DeepSeek-V4-Pro preview, với độ dài nháp tối đa là 5, so với đường cơ sở sản xuất MTP-1 trước đây. MTP-1 chỉ thực hiện dự đoán một token, nên không gian tăng tốc hạn chế, nhưng an toàn trong điều kiện đồng thời cao. Lý do là, mặc dù nháp đa token tĩnh (static multi-token draft) có vẻ tạo ra nhiều token hơn trong một lần, nhưng nếu nhiều token cuối cùng bị từ chối, nó sẽ lãng phí tài nguyên xác minh của mô hình đích, kéo giảm thông lượng tổng thể của hệ thống.
Ý nghĩa của DSpark là nó giúp nháp đa token trở nên kiểm soát được trong lưu lượng trực tuyến thực tế. Khi đối mặt với mức đồng thời trung bình, DSpark sẽ mở rộng ngân sách xác minh từ 2 token tĩnh của MTP-1 lên khoảng 4 đến 6 token, giúp mỗi lần tính toán tạo ra nhiều đầu ra hiệu quả hơn. Khi mức đồng thời tiếp tục tăng và mô hình đích gần bão hòa, DSpark sẽ tự động rút ngắn độ dài xác minh, giảm việc chiếm dụng dung lượng lô của các token có độ tin cậy thấp.
Trong các thử nghiệm trực tuyến, với mục tiêu dịch vụ 80 token/giây/người dùng (token/s/user) cho V4-Flash, DSpark đã tăng tổng thông lượng hệ thống lên 51% so với MTP-1. Ở mục tiêu nghiêm ngặt hơn là 120 token/s/user, MTP-1 đã gần đạt giới hạn khả năng chịu tải, trong khi DSpark mang lại lợi thế thông lượng danh nghĩa lên tới 661%. Con số 661% này không nên hiểu là tất cả các kịch bản thông thường đều sẽ đạt được mức tăng hơn 6 lần. Hiểu chính xác hơn là: trong các tình huống tương tác cao, với ràng buộc SLA (thỏa thuận mức dịch vụ) chặt chẽ, MTP-1 khó có thể duy trì khả năng phục vụ, trong khi DSpark đã mở ra một phạm vi hiệu suất mà trước đây khó đạt được.
Xu hướng tương tự cũng diễn ra với V4-Pro. Với mục tiêu 35 token/s/user, DSpark tăng tổng thông lượng 52%; ở mục tiêu nghiêm ngặt 50 token/s/user, lợi thế thông lượng danh nghĩa đạt 406%. Với cùng dung lượng hệ thống, DSpark giúp tăng tốc độ tạo nội dung cho một người dùng của V4-Pro lên từ 57% đến 78%.
Cuối cùng, DeepSeek cũng đã công bố mở mã nguồn các trọng số mô hình DSpark, bao gồm các điểm kiểm tra (checkpoints) DSpark tương ứng với DeepSeek-V4-Flash preview và DeepSeek-V4-Pro preview. Đồng thời, DeepSeek cũng mở mã nguồn DeepSpec, một thư viện mã dành cho việc huấn luyện giải mã suy đoán, bao gồm Eagle3, DFlash và DSpark.
Tóm lại, việc tăng tốc suy luận cho các mô hình lớn không còn chỉ là vấn đề cấu trúc mô hình, mà ngày càng trở thành một bài toán kỹ thuật hệ thống phức tạp. Việc đơn thuần để mô hình nháp tạo ra nhiều token hơn trong một lần không có nghĩa là dịch vụ sẽ nhanh hơn. Chất lượng của token ứng cử viên, tỷ lệ chấp nhận, độ dài xác minh, tải hệ thống, mục tiêu thông lượng... mỗi biến số đều ảnh hưởng lẫn nhau một cách tinh vi. Cuộc cạnh tranh AI đang bước vào giai đoạn tinh vi hơn. Việc huấn luyện ra những mô hình mạnh mẽ hơn vẫn là sức mạnh cứng trên bàn cờ; nhưng khả năng đưa mô hình đến tay người dùng thực một cách nhanh hơn, rẻ hơn và ổn định hơn cũng sẽ quyết định giới hạn của một sản phẩm AI. DeepSeek đã chọn mở mã nguồn kinh nghiệm tăng tốc trong môi trường sản xuất này, tương đương với việc chia sẻ một phần phương pháp cốt lõi thực sự có thể nâng cao hiệu quả suy luận và giảm chi phí dịch vụ cho toàn ngành.
Hôm nay, DeepSeek cùng với đội ngũ từ Đại học Bắc Kinh đã công bố một nghiên cứu mang tên "DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation". Đây là một khung tăng tốc suy luận mới dành cho các mô hình ngôn ngữ lớn, và điều đặc biệt là nó đã được tích hợp vào hệ thống sản xuất của DeepSeek, cụ thể là DeepSeek-V4-Flash preview và DeepSeek-V4-Pro preview, thay thế cho giải pháp MTP-1 trước đây.
Kết quả thực tế từ lưu lượng người dùng trực tuyến cho thấy DSpark mang lại hiệu quả ấn tượng. Với cùng mức thông lượng hệ thống tổng thể, DSpark đã giúp tăng tốc độ tạo nội dung cho một người dùng của DeepSeek-V4-Flash lên từ 60% đến 85%. Đối với DeepSeek-V4-Pro, mức tăng này cũng đạt từ 57% đến 78%. Vậy DeepSeek đã "phù phép" gì cho công nghệ của mình để đạt được những con số đáng kinh ngạc này?
Để hiểu rõ hơn, chúng ta cần nhìn vào cách các mô hình ngôn ngữ lớn hoạt động. Hầu hết chúng tạo văn bản theo phương pháp tự hồi quy (autoregressive), nghĩa là mô hình sẽ tạo ra từng "token" (đơn vị văn bản nhỏ nhất) một. Mỗi khi một token mới được tạo ra, mô hình phải thực hiện một phép tính dựa trên toàn bộ văn bản đã có. Điều này có nghĩa là văn bản càng dài, số bước giải mã càng nhiều, và độ trễ càng dễ tích lũy. Đối với các ứng dụng tương tác cao như trò chuyện thời gian thực, quy trình làm việc của tác nhân thông minh (Agent workflow) hay trợ lý viết mã, tốc độ tạo nội dung ảnh hưởng trực tiếp đến trải nghiệm người dùng và cả hiệu suất sử dụng GPU.
Giải mã suy đoán (speculative decoding) ra đời để giải quyết vấn đề này. Ý tưởng của nó giống như việc có một "mô hình nháp" (draft model) nhỏ hơn viết trước một bản nháp, sau đó một "mô hình đích" (target model) lớn hơn sẽ nhanh chóng kiểm tra bản nháp đó. Hệ thống sẽ dùng mô hình nháp nhẹ để tạo ra một chuỗi các token ứng cử viên. Sau đó, mô hình đích, vốn chịu trách nhiệm về chất lượng đầu ra, sẽ xác minh các token này cùng một lúc. Những token được xác minh sẽ được chấp nhận. Nếu một token nào đó bị từ chối, tất cả các token ứng cử viên phía sau nó cũng sẽ bị loại bỏ, và mô hình đích sẽ tạo ra một token sửa chữa. Vì giai đoạn xác minh có thể diễn ra song song, giải mã suy đoán có thể tăng tốc độ tạo nội dung mà không làm thay đổi phân bố đầu ra của mô hình đích. Nói một cách đơn giản, nó giúp mô hình lớn xác nhận nhiều token hơn trong một lần tính toán, thay vì chỉ một token mỗi lần.
Tuy nhiên, các phương pháp giải mã suy đoán hiện có vẫn còn những hạn chế đáng kể. Loại đầu tiên là mô hình nháp tự hồi quy. Nó tạo ra các token ứng cử viên tuần tự, từng cái một, giống như một mô hình ngôn ngữ thông thường. Ưu điểm là mối quan hệ giữa các token tự nhiên hơn và chất lượng ứng cử viên cao. Nhưng nhược điểm là mô hình nháp cũng phải làm việc từng bước, nên càng nhiều token ứng cử viên thì giai đoạn nháp càng chậm.
Loại thứ hai là mô hình nháp song song (parallel draft model). Nó có thể tạo ra nhiều token ứng cử viên cùng lúc, rất nhanh và phù hợp để tạo ra các khối ứng cử viên dài. Vấn đề là các token bên trong khối ứng cử viên này thiếu mối quan hệ phụ thuộc lẫn nhau. Ví dụ, khi đối mặt với một ngữ cảnh, mô hình có thể có hai cách tiếp tục hợp lý là "of course" hoặc "no problem". Mô hình nháp song song, vì không thực sự tạo ra theo thứ tự, rất dễ trộn lẫn hai đường dẫn này, tạo ra những cụm từ không nhất quán như "of problem" hoặc "no course". Kết quả là, các token đầu tiên của mô hình nháp song song thường khá tốt, nhưng càng về sau, khả năng các token ứng cử viên được mô hình đích chấp nhận càng giảm nhanh. Hiện tượng này được gọi là suy giảm hậu tố (suffix decay).
Một vấn đề thực tế hơn nữa xảy ra trong các dịch vụ trực tuyến. Mô hình nháp song song dễ dàng tạo ra một chuỗi dài các token ứng cử viên, nhưng trong môi trường dịch vụ có độ đồng thời cao, việc gửi tất cả các token này cho mô hình đích để xác minh có thể không hiệu quả. Đối với các tác vụ có cấu trúc như toán học hay mã hóa, đường dẫn câu trả lời tương đối rõ ràng, nên các token ứng cử viên dễ được chấp nhận hơn. Ngược lại, các cuộc trò chuyện mở có tính không chắc chắn cao hơn, và các token sau đó dễ bị từ chối hơn. Khi hệ thống rảnh rỗi, việc xác minh thêm vài token không ảnh hưởng nhiều. Nhưng khi hệ thống bận rộn, việc xác minh những token có khả năng cao bị từ chối sẽ chiếm dụng dung lượng lô (batch capacity) của mô hình đích, ảnh hưởng đến các yêu cầu của người dùng khác. Nói cách khác, vấn đề của giải mã suy đoán không chỉ là liệu có thể tạo ra nhiều token hơn trong một lần hay không, mà còn là token nào đáng để mô hình đích xác minh.
DSpark giải quyết những thách thức này bằng cách kết hợp hai ý tưởng chính: bản nháp phải chất lượng hơn và quá trình kiểm duyệt phải thông minh hơn.
Về phía tạo nội dung, DSpark sử dụng kiến trúc bán tự hồi quy (semi-autoregressive architecture). Nó giữ lại phần cốt lõi của mô hình nháp song song, cho phép phần lớn các phép tính hoàn thành cùng lúc. Đồng thời, nó bổ sung một mô-đun tuần tự nhẹ ở đầu ra, giúp các token sau có thể tham chiếu đến các token đã được lấy mẫu trước đó. Chúng ta có thể hình dung nó như thế này: phần đầu tiên dùng phương pháp song song để nhanh chóng tạo ra các ứng cử viên, sau đó một mô-đun tuần tự rất nhẹ sẽ kiểm tra mối liên kết giữa các token liền kề. Nghiên cứu mặc định sử dụng Markov head, một phương pháp mô hình hóa mối quan hệ chuyển đổi giữa các token liền kề với chi phí tính toán thấp, dễ triển khai.
Về phía xác minh, DSpark giới thiệu xác minh theo lịch trình dựa trên độ tin cậy (confidence-scheduled verification). Hệ thống sẽ dự đoán một điểm số độ tin cậy (confidence score) cho mỗi vị trí ứng cử viên. Điểm số này cho biết khả năng token ở vị trí hiện tại tiếp tục được chấp nhận cao đến mức nào, với điều kiện các token trước đó đã được mô hình đích chấp nhận. Sau đó, một bộ lập lịch tiền tố nhận biết phần cứng (hardware-aware prefix scheduler) sẽ tự động quyết định số lượng token cần xác minh cho mỗi yêu cầu dựa trên ba yếu tố: tải hệ thống hiện tại, độ tin cậy của từng vị trí ứng cử viên, và đường cong thông lượng (throughput curve) của công cụ ở các kích thước lô khác nhau.
Nhờ vậy, DSpark không xác minh một cách máy móc các khối ứng cử viên có độ dài cố định. Khi tài nguyên hệ thống dồi dào, nó có thể xác minh một tiền tố (prefix) dài hơn, giúp một lần tính toán của mô hình đích tạo ra nhiều token hiệu quả nhất có thể. Khi tải hệ thống tăng cao, DSpark sẽ tự động rút ngắn độ dài xác minh của các yêu cầu có độ tin cậy thấp, giảm thiểu việc chiếm dụng dung lượng lô của mô hình đích. Đây chính là điểm khiến DSpark gần với môi trường sản xuất thực tế hơn so với các phương pháp giải mã suy đoán truyền thống: nó không chỉ theo đuổi việc tạo ra nhiều token ứng cử viên hơn trong một lần, mà còn điều chỉnh ngân sách xác minh dựa trên tải hệ thống.
Cuối cùng, chúng ta nhận ra rằng giới hạn của các mô hình lớn không chỉ nằm ở vấn đề kỹ thuật mô hình phức tạp, mà còn là một bài toán kỹ thuật hệ thống phức tạp.
Các thử nghiệm ngoại tuyến đã được thực hiện trên bốn mô hình đích: Qwen3-4B, Qwen3-8B, Qwen3-14B và Gemma4-12B, so sánh DSpark với hai giải pháp tiêu biểu là mô hình nháp tự hồi quy Eagle3 và mô hình nháp song song DFlash. Các đánh giá bao gồm suy luận toán học, tạo mã và trò chuyện hàng ngày, sử dụng các bộ dữ liệu chuẩn như GSM8K, MATH500, AIME25, MBPP, HumanEval, Live-CodeBench, MT-Bench, Alpaca và Arena-Hard.
Kết quả cho thấy, trên Qwen3-4B, Qwen3-8B và Qwen3-14B, DSpark đã cải thiện độ dài chấp nhận trung bình (macro-average accepted length) lần lượt là 30.9%, 26.7% và 30.0% so với Eagle3. So với DFlash, mức cải thiện là 16.3%, 18.4% và 18.3%. Trên Gemma4-12B, DSpark cũng duy trì vị trí dẫn đầu. Độ dài chấp nhận có thể hiểu là số lượng token trung bình được mô hình đích chấp nhận trong mỗi vòng giải mã suy đoán. Con số này càng cao, chứng tỏ bản nháp của mô hình nháp càng được mô hình lớn chấp nhận, và không gian tăng tốc suy luận càng lớn.
Nghiên cứu cũng chỉ ra sự khác biệt lớn giữa các loại nhiệm vụ. Ví dụ, với Qwen3-4B, độ dài chấp nhận trung bình của DSpark trong các nhiệm vụ toán học là 5.57, trong nhiệm vụ mã hóa là 5.12, và trong nhiệm vụ trò chuyện là 3.49. Điều này cho thấy toán học và mã hóa có cấu trúc rõ ràng hơn, đường dẫn tiếp tục ổn định hơn, trong khi trò chuyện mở hơn, mô hình có thể có nhiều cách trả lời hợp lý. Do đó, cùng một độ dài token ứng cử viên, giá trị của chúng trong các nhiệm vụ khác nhau là không giống nhau. Việc xác minh độ dài cố định sẽ lãng phí một phần tài nguyên tính toán.
Các thử nghiệm chi tiết hơn đã giải thích lý do DSpark hiệu quả. Các mô hình nháp song song như DFlash rất mạnh ở token ứng cử viên đầu tiên vì chúng có thể sử dụng mạng sâu hơn để tạo ra ứng cử viên cùng lúc. Nhưng từ token thứ hai trở đi, do thiếu sự phụ thuộc nội khối, tỷ lệ chấp nhận giảm rõ rệt hơn. Các mô hình nháp tự hồi quy như Eagle3 có tính nhất quán tốt hơn ở phần sau vì chúng thực sự tạo ra theo thứ tự. Tuy nhiên, để kiểm soát độ trễ trong giai đoạn nháp, chúng thường không thể làm quá sâu, do đó khả năng dự đoán của token đầu tiên bị hạn chế. DSpark nằm ở giữa hai loại này. Token đầu tiên kế thừa khả năng dự đoán mạnh mẽ của mô hình nháp song song, và các token sau đó giảm suy giảm hậu tố thông qua mô-đun tuần tự.
Các thử nghiệm cấu trúc cũng ủng hộ nhận định này. Nghiên cứu cho thấy DSpark 2 lớp đã vượt qua DFlash 5 lớp, chứng tỏ mô hình hóa tuần tự nhẹ hiệu quả hơn việc đơn thuần tăng số lớp song song. Khi độ dài đề xuất (proposal length) tăng từ 4 lên 16, lợi thế của DSpark so với DFlash tiếp tục mở rộng. Ở cài đặt dài nhất, DSpark dẫn trước DFlash lần lượt 30% trong nhiệm vụ toán học, 26% trong mã hóa và 22% trong trò chuyện.
Về độ trễ, mô-đun tuần tự chỉ mang lại chi phí bổ sung rất nhỏ. Trong thử nghiệm với kích thước lô 128, độ trễ một vòng của DSpark chỉ tăng từ 0.2% đến 1.3% so với DFlash, nhưng độ dài chấp nhận tăng tới 30%. Mô-đun độ tin cậy cũng đã được xác minh riêng. Nghiên cứu đã thực hiện quét ngưỡng độ tin cậy trên Qwen3-4B, tức là liên tục nâng cao ngưỡng độ tin cậy để quan sát hệ thống sẽ giữ lại những token nào. Kết quả rõ ràng: ngưỡng càng cao, hệ thống càng lọc bỏ nhiều token ứng cử viên giá trị thấp, và tỷ lệ chấp nhận tổng thể càng cao. Nhiệm vụ trò chuyện có sự thay đổi rõ rệt nhất, tỷ lệ chấp nhận tăng từ 45.7% lên 95.7%; nhiệm vụ toán học từ 76.9% lên 92.5%; nhiệm vụ mã hóa từ 67.6% lên 92.0%.
Phần triển khai trực tuyến còn quan trọng hơn. DeepSeek đã triển khai DSpark trong công cụ sản xuất của DeepSeek-V4-Flash preview và DeepSeek-V4-Pro preview, với độ dài nháp tối đa là 5, so với đường cơ sở sản xuất MTP-1 trước đây. MTP-1 chỉ thực hiện dự đoán một token, nên không gian tăng tốc hạn chế, nhưng an toàn trong điều kiện đồng thời cao. Lý do là, mặc dù nháp đa token tĩnh (static multi-token draft) có vẻ tạo ra nhiều token hơn trong một lần, nhưng nếu nhiều token cuối cùng bị từ chối, nó sẽ lãng phí tài nguyên xác minh của mô hình đích, kéo giảm thông lượng tổng thể của hệ thống.
Ý nghĩa của DSpark là nó giúp nháp đa token trở nên kiểm soát được trong lưu lượng trực tuyến thực tế. Khi đối mặt với mức đồng thời trung bình, DSpark sẽ mở rộng ngân sách xác minh từ 2 token tĩnh của MTP-1 lên khoảng 4 đến 6 token, giúp mỗi lần tính toán tạo ra nhiều đầu ra hiệu quả hơn. Khi mức đồng thời tiếp tục tăng và mô hình đích gần bão hòa, DSpark sẽ tự động rút ngắn độ dài xác minh, giảm việc chiếm dụng dung lượng lô của các token có độ tin cậy thấp.
Trong các thử nghiệm trực tuyến, với mục tiêu dịch vụ 80 token/giây/người dùng (token/s/user) cho V4-Flash, DSpark đã tăng tổng thông lượng hệ thống lên 51% so với MTP-1. Ở mục tiêu nghiêm ngặt hơn là 120 token/s/user, MTP-1 đã gần đạt giới hạn khả năng chịu tải, trong khi DSpark mang lại lợi thế thông lượng danh nghĩa lên tới 661%. Con số 661% này không nên hiểu là tất cả các kịch bản thông thường đều sẽ đạt được mức tăng hơn 6 lần. Hiểu chính xác hơn là: trong các tình huống tương tác cao, với ràng buộc SLA (thỏa thuận mức dịch vụ) chặt chẽ, MTP-1 khó có thể duy trì khả năng phục vụ, trong khi DSpark đã mở ra một phạm vi hiệu suất mà trước đây khó đạt được.
Xu hướng tương tự cũng diễn ra với V4-Pro. Với mục tiêu 35 token/s/user, DSpark tăng tổng thông lượng 52%; ở mục tiêu nghiêm ngặt 50 token/s/user, lợi thế thông lượng danh nghĩa đạt 406%. Với cùng dung lượng hệ thống, DSpark giúp tăng tốc độ tạo nội dung cho một người dùng của V4-Pro lên từ 57% đến 78%.
Cuối cùng, DeepSeek cũng đã công bố mở mã nguồn các trọng số mô hình DSpark, bao gồm các điểm kiểm tra (checkpoints) DSpark tương ứng với DeepSeek-V4-Flash preview và DeepSeek-V4-Pro preview. Đồng thời, DeepSeek cũng mở mã nguồn DeepSpec, một thư viện mã dành cho việc huấn luyện giải mã suy đoán, bao gồm Eagle3, DFlash và DSpark.
Tóm lại, việc tăng tốc suy luận cho các mô hình lớn không còn chỉ là vấn đề cấu trúc mô hình, mà ngày càng trở thành một bài toán kỹ thuật hệ thống phức tạp. Việc đơn thuần để mô hình nháp tạo ra nhiều token hơn trong một lần không có nghĩa là dịch vụ sẽ nhanh hơn. Chất lượng của token ứng cử viên, tỷ lệ chấp nhận, độ dài xác minh, tải hệ thống, mục tiêu thông lượng... mỗi biến số đều ảnh hưởng lẫn nhau một cách tinh vi. Cuộc cạnh tranh AI đang bước vào giai đoạn tinh vi hơn. Việc huấn luyện ra những mô hình mạnh mẽ hơn vẫn là sức mạnh cứng trên bàn cờ; nhưng khả năng đưa mô hình đến tay người dùng thực một cách nhanh hơn, rẻ hơn và ổn định hơn cũng sẽ quyết định giới hạn của một sản phẩm AI. DeepSeek đã chọn mở mã nguồn kinh nghiệm tăng tốc trong môi trường sản xuất này, tương đương với việc chia sẻ một phần phương pháp cốt lõi thực sự có thể nâng cao hiệu quả suy luận và giảm chi phí dịch vụ cho toàn ngành.
