DeepSeek Mở Nguồn DSpark: Tăng Tốc Suy Luận LLM Lên Đến 85% – Thay Đổi Cuộc Chơi AI Toàn Cầu! 🚀💡

DeepSeek, "ngôi sao" mã nguồn mở từ Trung Quốc, tiếp tục gây bão trong giới phát triển AI toàn cầu với việc phát hành DSpark – một hệ thống mới được cấp phép MIT, giúp các mô hình ngôn ngữ lớn (LLM) phản hồi nhanh hơn đáng kể mà không làm thay đổi bản chất thông điệp. 🌍✨ Hãy hình dung đơn giản: hầu hết các chatbot AI hoạt động như người đang dò dẫm từng bước qua một con sông. Chúng chọn một đoạn văn nhỏ, rồi đoạn tiếp theo, cứ thế. DSpark thì khác, nó cử một "trinh sát" chạy trước vài bước, dự đoán con đường có khả năng nhất, sau đó để mô hình lớn kiểm tra nhanh các bước đó có an toàn không. Khi các dự đoán chính xác, mô hình sẽ di chuyển nhanh hơn. Nếu dự đoán kém, DSpark sẽ không lãng phí thời gian kiểm tra chúng. 🌉⚡ DeepSeek đã công bố nghiên cứu này cùng một báo cáo kỹ thuật chi tiết, các checkpoint mô hình và DeepSpec – một codebase để đào tạo và đánh giá các hệ thống giải mã suy đoán. Mã nguồn có sẵn trên GitHub và Hugging Face của DeepSeek, đều dưới giấy phép MIT, giúp các nhà phát triển, nghiên cứu và doanh nghiệp dễ dàng tiếp cận và điều chỉnh phương pháp này. Hệ thống này nhằm giải quyết một trong những vấn đề tốn kém nhất trong triển khai AI: phục vụ các mô hình lớn đủ nhanh cho người dùng thực, đồng thời sử dụng phần cứng hiệu quả để đảm bảo yếu tố kinh tế. Điều này cực kỳ quan trọng đối với các chatbot tiêu dùng, trợ lý viết mã, quy trình làm việc tự động và hệ thống AI doanh nghiệp, nơi người dùng mong đợi các câu trả lời dài được truyền tải nhanh chóng chứ không phải "bò" từng chữ một. 💸🚀 DeepSeek đang áp dụng DSpark cho mô hình tiên tiến nhất của mình, DeepSeek-V4. Cụ thể, DSpark đã được triển khai trên DeepSeek-V4-Flash (mô hình Mixture-of-Experts 284 tỷ tham số, tối ưu hóa tốc độ) và DeepSeek-V4-Pro (mô hình 1.6 nghìn tỷ tham số mạnh mẽ hơn). Điều quan trọng hơn cả là DSpark không chỉ giới hạn cho DeepSeek-V4! Các thử nghiệm của DeepSeek và các checkpoint đã phát hành cho thấy nó còn hoạt động trên các họ mô hình mở khác, bao gồm Qwen của Alibaba và Gemma của Google. Điều này có nghĩa là các nhóm doanh nghiệp đang vận hành các mô hình mã nguồn mở có thể, về nguyên tắc, đào tạo hoặc tinh chỉnh các module dự thảo theo kiểu DSpark cho các mô hình mục tiêu của riêng họ. ### Tốc Độ Tạo Token Vượt Trội Khi Suy Luận 💨📈 Trong các thử nghiệm sản xuất thực tế của DeepSeek, DSpark đã cải thiện thông lượng tổng hợp lên 51% cho DeepSeek-V4-Flash (với mục tiêu 80 token/giây/người dùng) và 52% cho DeepSeek-V4-Pro (với mục tiêu 35 token/giây/người dùng). Ở cùng một công suất hệ thống, DeepSeek báo cáo tốc độ tạo token cho mỗi người dùng tăng từ 60% đến 85% cho V4-Flash và từ 57% đến 78% cho V4-Pro so với baseline sản xuất MTP-1 trước đây. Các con số về tốc độ này đo lường những khía cạnh khác nhau. Con số 60% đến 85% cho V4-Flash và 57% đến 78% cho V4-Pro mô tả mức độ nhanh hơn mà người dùng cá nhân nhận được token khi DeepSeek so sánh DSpark với MTP-1 ở cùng công suất hệ thống thực tế. Đây là những con số "tốc độ tạo" rõ ràng hơn. DeepSeek cũng báo cáo mức tăng lớn hơn nhiều, lên đến 661% và 406%, nhưng những con số này đo lường thông lượng tổng hợp dưới các mục tiêu tốc độ rất nghiêm ngặt: 120 token/giây/người dùng cho V4-Flash và 50 token/giây/người dùng cho V4-Pro. Ở các mục tiêu này, baseline MTP-1 cũ của DeepSeek gần như đạt đến giới hạn hoạt động, có nghĩa là nó chỉ có thể xử lý một số lượng nhỏ yêu cầu đồng thời mà vẫn duy trì mức độ phản hồi đó. DSpark tránh được sự sụp đổ hiệu suất này, do đó sự khác biệt phần trăm trong tổng sản lượng hệ thống trở nên lớn hơn nhiều. Nói một cách đơn giản: con số 85% gần với "người dùng cảm thấy nhanh hơn bao nhiêu" trong điều kiện tương đương, trong khi các con số 661% và 406% gần với "con đường có thể chở thêm bao nhiêu lưu lượng" khi hệ thống cũ đã bị tắc nghẽn. ### Tại Sao Giải Mã Suy Đoán Lại Quan Trọng? 🤔💡 Các LLM thường tạo văn bản từng token một. Mỗi token mới phụ thuộc vào văn bản đã được tạo ra, vì vậy mô hình phải liên tục tạm dừng, kiểm tra toàn bộ ngữ cảnh và chọn mảnh tiếp theo. Cách này chính xác nhưng rất chậm. Giống như có một tổng biên tập duyệt từng từ trước khi người viết có thể chuyển sang từ tiếp theo – quy trình này tạo ra nút thắt cổ chai. 🐢✍️ Giải mã suy đoán (speculative decoding), được phát triển từ thời Transformer đầu tiên, nhằm khắc phục nút thắt này. Thay vì yêu cầu mô hình lớn tạo từng token một, hệ thống sử dụng một thành phần dự thảo nhỏ hơn hoặc nhẹ hơn để gợi ý một vài token tiếp theo có khả năng. Sau đó, mô hình lớn kiểm tra đồng thời loạt dự đoán đó. Nếu bản nháp đoán đúng, hệ thống sẽ tiến lên vài token cùng lúc. Nếu bản nháp đoán sai, hệ thống sẽ từ chối token sai và mọi thứ sau nó, thêm một token đã sửa và thử lại. Mục đích là đạt được tốc độ mà không làm thay đổi đầu ra dự kiến của mô hình lớn. Trong thiết lập giải mã suy đoán tiêu chuẩn, mô hình dự thảo không thay thế mô hình mục tiêu. Nó hoạt động giống như một trợ lý chuẩn bị một câu nháp để tổng biên tập duyệt hoặc từ chối. Ý tưởng này không phải tự nhiên xuất hiện. Tiền thân quan trọng là vào năm 2018 với đề xuất giải mã song song theo khối. Sau đó, vào năm 2022, SpecDec được giới thiệu, và cuối năm đó, "Fast Inference from Transformers via Speculative Decoding" đã định nghĩa phiên bản hiện đại cho các mô hình ngôn ngữ dựa trên Transformer. Các nhà nghiên cứu DeepMind cũng theo sau vào năm 2023 với phương pháp tương tự gọi là speculative sampling. Kể từ đó, lĩnh vực này đã phát triển nhanh chóng với nhiều biến thể, bao gồm các mô hình dự thảo riêng biệt, đầu dự đoán đa token, xác minh dựa trên cây, và các phương pháp cấp tính năng như EAGLE, tự suy đoán, hoặc các drafter song song/theo khối như DFlash. Chỉ số quan trọng không phải là số lượng token mà mô hình dự thảo có thể đoán, mà là số lượng dự đoán đó được mô hình lớn chấp nhận. Các khối suy đoán dài chỉ hữu ích nếu đủ số token được đề xuất vượt qua quá trình xác minh. Nếu không, hệ thống sẽ tốn công sức kiểm tra những dự đoán mà cuối cùng bị loại bỏ. Đó là bối cảnh cho DSpark. Giải mã suy đoán đã là một kỹ thuật suy luận được thiết lập, nhưng vẫn chưa phải là một vấn đề đã được giải quyết hoàn toàn. Tốc độ tăng phụ thuộc nhiều vào mô hình dự thảo, khối lượng công việc, thiết lập phục vụ và mức độ lưu lượng hiện tại. Đóng góp của DSpark là cải thiện cả hai mặt của sự đánh đổi: nó cố gắng dự thảo các khối token mạch lạc hơn và sau đó chỉ xác minh những phần của các khối đó có khả năng mang lại lợi ích trong điều kiện phục vụ thực tế. ### DSpark Đã Thay Đổi Điều Gì? 🛠️✨ DSpark giải quyết hai vấn đề liên quan: dự đoán kém chất lượng và lãng phí kiểm tra. 1. Tạo văn bản bán tự động (Semi-autoregressive generation): Hệ thống sử dụng điều mà DeepSeek gọi là tạo văn bản bán tự động. Điều này có nghĩa là DSpark cố gắng kết hợp tốc độ với nhận thức tốt hơn về trình tự. * Một trình tạo nháp song song hoàn toàn có thể đoán vài token cùng lúc (nhanh), nhưng các dự đoán sau đó có thể kém mạch lạc hơn vì mỗi vị trí được dự đoán quá độc lập. * Một trình tạo nháp từng bước thuần túy có thể theo dõi tốt hơn mối liên hệ giữa các token, nhưng lại mất đi phần lớn lợi thế về tốc độ. DSpark cố gắng giữ lại những gì tốt nhất của cả hai. Nó sử dụng một xương sống song song cho hầu hết công việc dự thảo, sau đó thêm một đầu tuần tự nhẹ giúp bản nháp tính đến mối quan hệ giữa các token lân cận. Trong ví dụ của bài báo, một trình tạo nháp song song có thể nhầm lẫn các cụm từ kết thúc có khả năng như "of course" và "no problem," tạo ra các kết hợp khó hiểu vì nó đoán các vị trí quá riêng biệt. Thành phần tuần tự của DSpark giúp hệ thống làm cho các token sau phù hợp với các token trước đó. 2. Xác minh theo lịch trình tin cậy (Confidence-scheduled verification): Thay vì luôn yêu cầu mô hình mục tiêu kiểm tra cùng một số lượng token dự thảo, DSpark ước tính tiền tố nào của bản nháp có khả năng được chấp nhận. Một bộ lập lịch nhận biết phần cứng sau đó điều chỉnh mức độ của mỗi bản nháp cần được xác minh dựa trên cả độ tin cậy của mô hình và tải phục vụ hiện tại. Một ví dụ đơn giản: khi nhà hàng vắng khách, đầu bếp trưởng có thể kiểm tra nhiều công việc của đầu bếp phụ hơn. Khi bếp đang bận rộn, đầu bếp chỉ tập trung vào những món ăn có khả năng sẵn sàng nhất. DSpark áp dụng ý tưởng tương tự cho việc phục vụ AI. Khi lưu lượng nhẹ, hệ thống có thể kiểm tra các tiền tố dự thảo dài hơn. Khi lưu lượng nặng hơn, nó cắt bỏ các dự đoán đuôi có độ tin cậy thấp trước khi chúng tiêu tốn dung lượng batch có thể được sử dụng cho người dùng khác. DeepSeek coi đây là một giải pháp cho sự đánh đổi phổ biến trong sản xuất. Việc dự thảo đa token tĩnh có vẻ hấp dẫn khi đứng riêng lẻ, nhưng có thể làm giảm thông lượng khi có nhiều yêu cầu đồng thời vì hệ thống liên tục kiểm tra các token có khả năng bị từ chối. Bộ lập lịch của DSpark làm cho ngân sách xác minh trở nên linh hoạt thay vì cố định. ### Kết Quả Thử Nghiệm Ngoại Tuyến: Tỷ Lệ Chấp Nhận Bản Nháp Tốt Hơn Trên Qwen và Gemma 📊✅ DeepSeek đã thử nghiệm DSpark ngoại tuyến trên các mô hình mục tiêu Qwen3-4B, Qwen3-8B, Qwen3-14B và Gemma4-12B trên các benchmark về toán, lập trình và trò chuyện. Trong các thử nghiệm đó, nhóm đã so sánh DSpark với DFlash (một trình tạo nháp song song) và Eagle3 (một trình tạo nháp tự động hồi quy). Bài báo báo cáo độ dài được chấp nhận trên mỗi vòng giải mã – một thước đo số lượng token được chấp nhận trung bình sau xác minh. Trên ba kích thước mô hình Qwen3, DSpark đã cải thiện độ dài chấp nhận trung bình macro so với Eagle3 lần lượt là 30.9%, 26.7% và 30.0%. So với DFlash, nó đã cải thiện độ dài chấp nhận lên 16.3%, 18.4% và 18.3%. Bài báo cũng cho biết các cải tiến này được tổng quát hóa sang Gemma4-12B. Điều này ủng hộ quan điểm của nhà phát triển Daniel Han, người đã nhấn mạnh trên X rằng DeepSeek đã chứng minh DSpark hoạt động không chỉ trên các mô hình V4 của DeepSeek, mà còn cả Gemma và Qwen. Các kết quả ngoại tuyến cũng cho thấy tầm quan trọng của khối lượng công việc. Các tác vụ có cấu trúc như toán học và mã hóa có xu hướng có độ dài chấp nhận cao hơn so với trò chuyện mở. Điều này có ý nghĩa trực quan: một đoạn mã hoàn chỉnh hoặc một bước toán học thường có ít "nước đi" tiếp theo hợp lý hơn một cuộc trò chuyện tự do. Đối với các doanh nghiệp, điều này có nghĩa là các phương pháp kiểu DSpark có thể đặc biệt hấp dẫn cho các trợ lý viết mã, các tác nhân phân tích dữ liệu, tự động hóa quy trình làm việc có cấu trúc và các cài đặt khác nơi đầu ra tuân theo các mẫu dễ đoán hơn. 💼🤖 ### Doanh Nghiệp Có Thể Dùng DSpark Như Thế Nào Mà Không Cần DeepSeek-V4? 🏭💡 Một trong những câu hỏi quan trọng nhất là liệu DSpark có phải là một tối ưu hóa chỉ dành riêng cho DeepSeek hay là một phương pháp rộng hơn có thể áp dụng cho các mô hình khác. Câu trả lời là: phương pháp rộng hơn, nhưng không phải là một "plug-in" tự động. Đối với các mô hình mã nguồn mở (open-weight models), con đường tương đối rõ ràng. Một doanh nghiệp đang chạy Qwen, Gemma, Llama, Mistral, Granite, Command-style open weights hoặc một mô hình khác mà họ tự host, có thể đào tạo hoặc tinh chỉnh một module dự thảo kiểu DSpark dựa trên mô hình mục tiêu đó. Sau đó, nhóm sẽ đo lường mức độ chấp nhận trên khối lượng công việc của riêng họ và tích hợp bộ lập lịch xác minh vào hệ thống suy luận của mình. Điều này khác với việc chỉ đơn giản tải xuống module DSpark của DeepSeek và gắn nó vào bất kỳ mô hình nào. Giải mã suy đoán phụ thuộc vào sự phù hợp giữa module dự thảo và mô hình mục tiêu. Module dự thảo phải học cách dự đoán những gì mô hình mục tiêu có khả năng chấp nhận. Một trình tạo nháp được đào tạo cho DeepSeek-V4 sẽ không tự động trở thành trình tạo nháp phù hợp cho một mô hình khác, đặc biệt là một mô hình đã được tinh chỉnh trên dữ liệu nội bộ của công ty hoặc được cấu hình cho các hành vi suy luận khác nhau. Quy trình của DeepSpec phản ánh điều này. Quá trình bao gồm chuẩn bị dữ liệu, tạo lại các câu trả lời của mô hình mục tiêu, xây dựng bộ nhớ cache mục tiêu, đào tạo mô hình dự thảo và đánh giá mức độ chấp nhận giải mã suy đoán. Đối với việc sử dụng theo miền cụ thể, mô hình dự thảo có thể cần tinh chỉnh bổ sung, đặc biệt nếu mô hình mục tiêu chạy ở chế độ tư duy hoặc suy luận. Đối với các mô hình độc quyền, câu trả lời phụ thuộc vào những gì doanh nghiệp kiểm soát. Nếu một công ty sở hữu hoặc tự host hoàn toàn trọng số mô hình và hệ thống phục vụ, họ về mặt lý thuyết có thể đào tạo và triển khai một trình tạo nháp kiểu DSpark. Nếu mô hình chỉ có sẵn thông qua API được host từ một nhà cung cấp, khách hàng không thể trực tiếp thêm DSpark từ bên ngoài. Nhà cung cấp API có thể triển khai tối ưu hóa tương tự nội bộ, nhưng khách hàng thường không thể truy cập vòng lặp xác minh token, logits, hành vi batching hoặc bộ lập lịch phục vụ cần thiết để DSpark hoạt động. Sự khác biệt này quan trọng đối với người mua doanh nghiệp. DSpark củng cố trường hợp cho cơ sở hạ tầng AI mở hoặc tự host vì nó cung cấp cho các nhóm tiên tiến một đòn bẩy khác để cải thiện tốc độ và chi phí. Nhưng nó cũng cho thấy tại sao việc phục vụ mô hình đang trở thành một lĩnh vực chuyên môn hóa. Giá trị không chỉ nằm ở việc chọn một mô hình, mà còn ở việc vận hành mô hình đó một cách thông minh như thế nào. ### Các Nhà Phát Triển Nhận Được Gì Từ DeepSpec? 👨‍💻🎁 Đối với các nhà phát triển, DeepSpec cung cấp một con đường triển khai cụ thể để đào tạo và đánh giá các mô hình dự thảo giải mã suy đoán. Nó bao gồm các bước chuẩn bị dữ liệu, đào tạo và đánh giá benchmark, cùng với các checkpoint đã phát hành cho một số họ mô hình mở. Điều này làm cho bản phát hành hữu ích không chỉ để chạy DeepSeek-V4 với DSpark, mà còn cho các nhà nghiên cứu và nhóm hạ tầng đang nghiên cứu cách thêm giải mã nhanh hơn vào các mô hình mở khác. Có những lưu ý thực tế về việc triển khai. README của DeepSpec cho biết thiết lập chuẩn bị dữ liệu Qwen3-4B mặc định có thể yêu cầu khoảng 38 TB bộ nhớ cache mục tiêu, và các script mặc định giả định một node đơn với tám GPU. Điều này làm cho bản phát hành phù hợp hơn ngay lập tức với các phòng thí nghiệm AI, nhóm đám mây và các nhóm hạ tầng AI doanh nghiệp tinh vi, hơn là các nhà phát triển ứng dụng thông thường. Tuy nhiên, việc phát hành quy trình đào tạo là rất quan trọng. Nhiều tối ưu hóa suy luận chỉ xuất hiện dưới dạng bài báo, benchmark mơ hồ hoặc tuyên bố sản xuất đóng. DeepSpec cung cấp cho các nhà phát triển một cái gì đó gần hơn với một bộ bản thiết kế: không phải một sản phẩm doanh nghiệp hoàn chỉnh, mà là một cách để tái tạo, điều chỉnh và đánh giá phương pháp. ### Cộng Đồng Đã Thử Nghiệm Sớm Ra Sao? 🧪🔥 Bản phát hành này đã nhanh chóng thu hút sự chú ý của các nhà phát triển. Nhà phát triển Rafael Caricio đã công bố một pull request trên GitHub ghi lại công việc DeepSeek-V4-Flash DSpark luồng đơn, báo cáo các điểm neo benchmark đã được làm nóng là 26.33 token/giây không có giải mã suy đoán, 39.88 token/giây với MTP-1 và khoảng 60 token/giây với DSpark – tức là nhanh hơn khoảng 1.5 lần so với MTP-1 và 2.3 lần so với giải mã không suy đoán. Một commit sau đó trong cùng chuỗi đã ghi lại mức trung bình 5 lần chạy là 60.31 token/giây, với mức tăng 1.51 lần so với MTP-1 và 2.29 lần so với giải mã không suy đoán. Công việc này cũng chỉ ra một giới hạn thực tế quan trọng: trong các phiên lập trình nhiều lượt thực tế, hiệu suất có thể giảm sút khi tỷ lệ chấp nhận bản nháp giảm theo ngữ cảnh ngày càng tăng. Nói cách khác, DSpark có thể làm cho việc giải mã nhanh hơn, nhưng chất lượng chấp nhận vẫn quyết định hệ thống thực sự đạt được tốc độ bao nhiêu. Đây là một lời nhắc nhở thực tế hữu ích. DSpark không phải là phép màu. Nó vẫn phụ thuộc vào mức độ dự đoán được của các token tiếp theo và mức độ liên kết của trình tạo nháp với mô hình mục tiêu. Nhưng những công việc triển khai ban đầu cho thấy những tuyên bố của DeepSeek không hoàn toàn mang tính học thuật. Các nhà phát triển đang thử nghiệm phương pháp này trong môi trường phục vụ thực tế và báo cáo mức tăng gần với kỳ vọng luồng đơn của bài báo. ### Điểm Mấu Chốt 🎯✨ DSpark cho thấy còn rất nhiều tiềm năng hiệu suất trong lớp suy luận, ngay cả khi kiến trúc mô hình cơ bản vẫn giữ nguyên. Khi các công ty AI cạnh tranh về chất lượng mô hình, độ dài ngữ cảnh và giá cả, hiệu quả giải mã đang trở thành một chiến trường lớn khác. Tạo ra câu trả lời nhanh hơn có nghĩa là độ trễ thấp hơn cho người dùng, thông lượng cao hơn cho nhà cung cấp và kinh tế hơn cho các nhóm phục vụ mô hình mở ở quy mô lớn. Bản phát hành của DeepSeek đáng chú ý vì nó kết hợp một phương pháp đã được thử nghiệm trong sản xuất, mã nguồn mở, các checkpoint công khai và một bài báo chi tiết. Đổi mới chính không chỉ là dự thảo nhiều token hơn, mà là làm cho hệ thống có chọn lọc hơn về việc nên xác minh những công việc suy đoán nào. Đối với các nhóm doanh nghiệp, bài học rộng hơn là làn sóng tăng hiệu suất AI tiếp theo sẽ không chỉ đến từ các mô hình lớn hơn. Nó còn đến từ những cách thông minh hơn để vận hành các mô hình mà các công ty đã có – đặc biệt khi các công ty đó kiểm soát đủ các lớp để tinh chỉnh mô hình, đào tạo một module dự thảo tương thích và tối ưu hóa công cụ phục vụ xung quanh khối lượng công việc thực tế.