Hugging Face ra mắt dòng mô hình DSpark: Tăng tốc suy luận lên đến 3,18 lần

Quay lại các bài viết

Hôm nay, chúng tôi phát hành các checkpoint mô hình dự thảo DSpark cho ba mô hình thuộc dòng LFM2.5 của chúng tôi: LFM2.5-1.2B-Instruct, LFM2.5-2.6B và LFM2.5-8B-A1B. Các mô hình này bổ sung một lộ trình giải mã suy đoán (speculative decoding), giúp tăng tốc độ giải mã đáng kể với mức tăng bộ nhớ tối thiểu mà không làm thay đổi chất lượng đầu ra:

DSpark hoạt động như thế nào

Giai đoạn giải mã trong suy luận LLM theo truyền thống bị giới hạn bởi bộ nhớ (memory-bound). Phần lớn độ trễ đến từ việc truyền tải trọng số từ DRAM sang SRAM, chứ không phải từ các tính toán chuyên sâu. Giải mã suy đoán giải quyết vấn đề này bằng cách sử dụng một mô hình dự thảo nhẹ để tạo ra các token ứng viên, sau đó để mô hình mục tiêu xác minh tất cả chúng trong một lần truyền tiến (forward pass) duy nhất, giúp chia sẻ chi phí tải trọng số cho tất cả các token được xác minh.

Qua nhiều năm, nhiều phương pháp suy đoán đã được đề xuất, trong đó nổi bật nhất là EAGLE-3, DFlash và gần đây nhất là DSpark, phương pháp kết hợp ba thành phần:

Đào tạo và Kiến trúc

Chúng tôi tuân theo công thức DSpark với hỗn hợp dữ liệu lớn hơn và đa dạng hơn, bao gồm dữ liệu SFT, trò chuyện, mã nguồn và gọi hàm (function-calling). Dựa trên các thử nghiệm cắt bỏ (ablations) của chúng tôi, các phiên bản đầu tiên của mô hình dự thảo là các mô hình dự thảo chỉ sử dụng attention đơn giản hóa, với 5 lớp và một khối (block) kích thước 9. Đối với mỗi mô hình dự thảo, chúng tôi đã chạy 15 epoch trên toàn bộ tập dữ liệu và chọn epoch có tỷ lệ chấp nhận cao nhất thay vì epoch có độ mất mát (loss) thấp nhất.

Các mô hình dự thảo thu được tương đối nhỏ, mỗi mô hình có khoảng ~300 triệu tham số.

Sự tương đương về chất lượng

Trong giải mã tham lam (greedy decoding), một token dự thảo chỉ được chấp nhận nếu nó khớp với phân phối của mô hình mục tiêu. Khi bị từ chối, token của chính mô hình mục tiêu sẽ thay thế nó. Do đó, chuỗi được tạo ra giống hệt với phương pháp tham lam cơ sở theo cấu trúc, vì vậy độ chính xác của benchmark (pass@1 hoặc khớp chính xác) không thay đổi.

Tăng tốc độ suy luận trên CPU và GPU

Các mô hình dự thảo DSpark cho LFM2.5 của chúng tôi hỗ trợ ngay từ ngày đầu trên llama.cpp (triển khai xây dựng dựa trên codebase chính thức, chạy với các kernel metal thử nghiệm) và SGLang (triển khai xây dựng dựa trên bản triển khai DSpark chính thức của SGLang).

Chúng tôi đo lường thông lượng trên thiết bị với llama.cpp và Metal trên MacBook Pro chip M4 Max, sử dụng trọng số FP16 GGUF và tối đa 256 token đầu ra. Chúng tôi đo lường thông lượng GPU với SGLang trên một card H100 80 GB ở định dạng BF16. Cả hai cấu hình đều sử dụng kích thước khối DSpark là 9, kích thước batch là 1 và nhiệt độ (temperature) là 0. Chúng tôi đánh giá chúng trên năm tập dữ liệu benchmark.

Cả ba mô hình dự thảo đều mang lại sự cải thiện thông lượng đáng kể trên cả bộ tăng tốc quy mô lớn (H100) và thiết bị triển khai biên (MacBook M4 Max).

Đối với LFM2.5-2.6B, tốc độ tăng trên MacBook đặc biệt đáng chú ý, vì nó đẩy mức độ tương tác mà người dùng có thể trải nghiệm vượt xa thông lượng được cung cấp bởi hầu hết các mô hình đám mây độc quyền (khoảng ~140 token/giây, tùy thuộc vào tập dữ liệu).

Trên nhiều kịch bản đa công cụ, DSpark giảm độ trễ trung bình 57% cho LFM2.5-2.6B.

Đối với LFM2.5-1.2B-Instruct, chúng tôi thấy sự biến động lớn hơn trong tỷ lệ chấp nhận tập dữ liệu, vì vậy tốc độ tăng thay đổi tới 52% tùy thuộc vào phân phối văn bản cơ sở.

Đối với LFM2.5-8B-A1B, tỷ lệ chấp nhận tăng lên so với hai mô hình dày đặc (dense models), tuy nhiên trên thiết bị, chúng tôi chỉ đạt được mức cải thiện trung bình 18%. Khoảng cách này là do cách triển khai MoE hiện tại trong backend Metal của llama.cpp, và do việc xác minh k token kích hoạt nhiều chuyên gia (experts) hơn, dẫn đến lưu lượng trọng số lớn hơn so với một bước giải mã đơn lẻ.

Cách sử dụng LFM2.5-DSpark

Chạy các mô hình dự thảo DSpark với SGLang yêu cầu bản dựng SGLang có hỗ trợ DSpark cho các mục tiêu LFM2 (PR #31041). Khởi chạy mục tiêu với mô hình dự thảo được đính kèm:

Sau đó truy vấn endpoint tương thích với OpenAI tại http://localhost:30000/v1. Kích thước khối được đọc từ tệp config.json của mô hình dự thảo; cấu hình cơ sở là cùng một lệnh nhưng không có ba cờ --speculative-*.

Chạy chúng với llama.cpp yêu cầu bản dựng llama.cpp tương ứng (PR#27383).

Kích thước khối được đọc từ siêu dữ liệu sidecar (n-max được giới hạn theo đó). Giải mã suy đoán là chính xác: mô hình mục tiêu xác minh mọi token được đề xuất, vì vậy đầu ra tham lam bằng với đầu ra của mô hình mục tiêu đơn lẻ; thời gian mỗi phản hồi báo cáo draft_n / draft_n_accepted.

Bắt đầu

Các checkpoint mô hình dự thảo DSpark có sẵn trên Hugging Face dưới định dạng Safetensors và GGUF:

Chúng tôi rất nóng lòng chờ xem bạn sẽ xây dựng những gì.

Trích dẫn

Để trích dẫn, vui lòng sử dụng tài liệu tham khảo hoặc BibTeX sau:

Liquid AI, "LFM2.5-DSpark: Up to 3.2x Faster Inference from H100 to MacBook", Liquid AI Blog, tháng 8 năm 2026.