LFM2.5-2.6B-DSpark: Mô hình nháp 328M giúp tác nhân trên thiết bị của Liquid chạy nhanh hơn 2,3 lần

Chưa ai bên ngoài Liquid AI chạy LFM2.5-2.6B-DSpark trên phần cứng của riêng mình và công bố số liệu nào. Đó là điểm khởi đầu trung thực khi đánh giá mô hình này, bởi toàn bộ vấn đề chỉ là một lời tuyên bố về hiệu năng: nó không phải là một phiên bản 2.6B tốt hơn, mà là một mô hình nháp 328M tham số nằm phía trước mô hình tác tử 2.6B LFM2.5-2.6B, đề xuất các token để mô hình chính xác minh, nhờ đó tác tử chạy nhanh khoảng gấp đôi mà không thay đổi đầu ra.

Phát hành ngày 20 tháng 8 năm 2026 kèm bài viết kỹ thuật trên Hugging Face và bài đăng đồng hành trên blog riêng của Liquid, LFM2.5-2.6B-DSpark là mẫu chủ lực trong một gia đình nhỏ các checkpoint drafter giải mã suy đoán (speculative decoding) mà Liquid công bố vào ngày hôm đó. Mọi số liệu trong cột tốc độ bên dưới đều do nhà cung cấp đo lường và chưa được xác nhận độc lập; mọi thứ trong repo, các định dạng và hỗ trợ framework chỉ đơn giản là ở đó để kiểm chứng.

DSpark là gì, chỉ trong một hơi thở.

Giải mã suy đoán{{1}} là thủ thuật chạy một mô hình nháp chi phí thấp trước mô hình thật: mô hình nháp đoán trước một loạt token tiếp theo,{{2}} mô hình đích kiểm tra toàn bộ batch trong một lần truyền xuôi duy nhất,{{3}} và giữ lại các token mà nó đồng tình. Khi các dự đoán đúng, bạn tiến được nhiều token với chi phí của một token,{{4}} nhờ đó thông lượng tăng lên mà không tác động đến trọng số của mô hình đích. DSpark — kỹ thuật do các nhà nghiên cứu DeepSeek đề xuất vào tháng 7 năm 2026 và đã được triển khai trong DeepSeek-V4 —{{5}} là một phiên bản của thủ thuật đó được tinh chỉnh cho các mô hình nhỏ chạy trên thiết bị. Liquid gọi nó là giải mã suy đoán theo lịch trình độ tin cậy,{{6}} và nó có ba bộ phận vận hành: một backbone song song tạo ra trạng thái ẩn cho tất cả token nháp trong một lần truyền,{{7}} một đầu tuần tự gọn nhẹ mô hình hóa sự phụ thuộc giữa các token liền kề để tỷ lệ chấp nhận không sụp đổ về cuối khối,{{8}} và một bộ xác minh cắt tỉa các hậu tố có độ tin cậy thấp khi việc kiểm tra chúng tốn kém hơn lợi ích mà nó mang lại.

Điểm cuối cùng đó chính là thứ khiến DSpark có cảm giác khác biệt so với một bộ soạn thảo nháp thông thường: nó không phải lúc nào cũng đẩy trọn một khối qua bước xác minh. Khi độ tin cậy của bản nháp cho thấy một hậu tố khó có khả năng được chấp nhận, nó sẽ cắt ngắn khối và tiết kiệm phần tính toán bị lãng phí. Khối nháp gồm chín token, nên mô hình đích xác minh tối đa mười token mỗi lần.

Người soạn thảo, qua những con số

Checkpoint LFM2.5-2.6B-DSpark là một mô hình nháp (draft model) chỉ dùng attention với 0,3 tỷ tham số: năm lớp attention đầy đủ (kích thước ẩn 2.048, grouped-query attention với 32 đầu và 8 đầu key-value), bộ từ vựng 128K token, một Markov head hạng 256 và một confidence head. Liquid đã huấn luyện nó trong 15 epoch trên tập dữ liệu hỗn hợp gồm hướng dẫn, hội thoại, mã nguồn và dữ liệu gọi hàm — trên phần cứng AMD — và chọn epoch dựa trên tỷ lệ chấp nhận cao nhất thay vì loss thấp nhất.

Tỷ lệ chấp nhận đó là con số quyết định giá trị của bộ soạn thảo. Trên năm điểm chuẩn với kích thước lô 1 và nhiệt độ 0, LFM2.5-2.6B-DSpark đạt trung bình 4,83 token được chấp nhận mỗi bước giải mã trên H100 và 4,42 trên M4 Max — khoảng một nửa khối được chấp nhận, đây chính là nguồn gốc của mức tăng tốc gấp đôi.

Các tốc độ tăng tốc, được gắn nhãn

Tất cả các số liệu sau đây đều đến từ phép đo của chính Liquid AI — SGLang trên một chiếc H100 80GB ở định dạng BF16, và llama.cpp với backend Metal trên MacBook Pro M4 Max ở định dạng FP16 GGUF, batch size 1, temperature 0 — và tính đến thời điểm viết bài này, chưa có con số nào được một bên độc lập tái lập lại:

• H100 trung bình — 2.67×, từ 323 lên 864 tokens/s. Theo benchmark: MATH500 3.06×, HumanEval 2.56×, MBPP 2.64×, GSM8K 2.22×, MT-Bench 2.87×.

• M4 Max trung bình — 2.27×, từ 61 đến 139 token/s. Theo benchmark: MATH500 2.25×, HumanEval 2.63×, MBPP 2.11×, GSM8K 2.36×, MT-Bench 1.99×.

• Gọi công cụ — trong các tình huống gọi hàm đa công cụ, độ trễ trung bình đã giảm 57%.

• Bối cảnh gia đình — drafter lớn nhất trong gia đình, LFM2.5-8B-A1B-DSpark, đạt tới 3.18× trên H100 và drafter 1.2B đạt tới 2.87× trên M4 Max; các con số 2.6B ở trên nằm ở mức trung bình của nhóm.

Hai điều về những con số này quan trọng hơn các giá trị trung bình. Thứ nhất, chúng được đo ở nhiệt độ 0 và batch size 1 — cấu hình có lợi cho suy đoán và cũng là cấu hình mà công việc tác tử tương tác trên thiết bị hầu hết đang sử dụng. Đảm bảo về tính đồng nhất cũng vẫn đúng ở đây: giải mã suy đoán xác minh từng token được đề xuất, nên với giải mã tham lam, văn bản phát ra chính xác là những gì mô hình mục tiêu sẽ tự tạo ra nếu chạy một mình. Thứ hai, khoảng cách thu hẹp khi độ đồng thời tăng lên: trên một H100, Liquid báo cáo lợi thế của DSpark hội tụ quanh batch size 128, vì vậy mô hình dự thảo là một lợi thế về độ trễ cho các khối lượng công việc tương tác và sử dụng nhiều công cụ, chứ không phải là viên đạn bạc về thông lượng thô cho một máy chủ chạy ở công suất tối đa.

Điều gì đã được xác nhận, và điều gì chưa được xác nhận?

{{1}}Xác nhận là có, vì repo được công khai và có thể kiểm tra được:{{/1}} {{2}}mô hình nháp phát hành dưới dạng Safetensors (BF16) và GGUF;{{/2}} {{3}}nó đi kèm với LFM2.5-2.6B đã qua huấn luyện bổ sung, không phải với mô hình gốc;{{/3}} {{4}}hỗ trợ ngay ngày đầu ra mắt đã được đưa vào upstream trong llama.cpp (với nhân Metal thử nghiệm) và trong SGLang;{{/4}} {{5}}nó được cấp phép theo LFM Open License v1.0 của Liquid;{{/5}} {{6}}và — quan trọng cho bất kỳ ai đang lên kế hoạch dựa trên nó —{{/6}} {{7}}thẻ mô hình nêu rõ rằng không có nhà cung cấp dịch vụ suy luận nào phục vụ nó,{{/7}} {{8}}vì vậy đây là một thành phần bạn phải tự chạy.{{/8}}

Chưa được xác nhận: việc mức tăng tốc có tái lập được trên các phần cứng và cấu hình khác hay không (chưa ai ngoài Liquid công bố phép đo nào), mô hình dự thảo hoạt động thế nào khi lấy mẫu thay vì giải mã tham lam, và liệu con số độ trễ gọi công cụ 57% có giữ vững trên các bộ khung tác nhân thực tế ngoài bộ khung điểm chuẩn mà Liquid đã dùng hay không. Không điều nào trong số đó là cáo buộc — bản phát hành mới chỉ vừa tròn một ngày — nhưng chúng chính là thứ tạo nên sự khác biệt giữa một con số đầy hứa hẹn và một con số đã được kiểm chứng.

Đang chạy nó

Trong SGLang bạn dùng một bản build có hỗ trợ DSpark, khởi chạy server với mô hình đích, và đặt tên cho drafter: thuật toán speculative là DSPARK, đường dẫn mô hình draft trỏ tới LiquidAI/LFM2.5-2.6B-DSpark, và kích thước khối được đọc từ config.json của draft. Trong llama.cpp bạn nạp GGUF đích với GGUF draft làm mô hình draft và đặt loại spec là draft-dspark, kích thước khối được đọc từ siêu dữ liệu sidecar. Cả hai tích hợp đều đã được hợp nhất lên upstream, nên không cần fork — chỉ cần một bản build đủ mới để chứa chúng.

Khi nào đáng để thêm

LFM2.5-2.6B-DSpark chiếm thêm khoảng 0,3GB bộ nhớ khi bạn thực sự triển khai tác nhân 2.6B đúng nơi Liquid thiết kế — trên điện thoại, laptop hoặc thiết bị biên — cho các khối lượng công việc tương tác hoặc gọi công cụ, vốn bị giới hạn bởi độ trễ và chạy theo kiểu tham lam. Đó chính xác là bối cảnh mà con số 2,27× trên thiết bị và mức cắt giảm 57% độ trễ gọi công cụ phát huy tác dụng. Nó kém thú vị hơn nếu bạn phục vụ với batch lớn trên máy chủ (tốc độ hội tụ về 1×), hoặc nếu khối lượng công việc của bạn chạy ở nhiệt độ trên 0, nơi các con số được báo cáo không còn áp dụng. Và nếu bạn dùng biến thể 8B-A1B của dòng này, hãy lưu ý trường hợp đặc biệt: tốc độ trên thiết bị hiện chỉ khoảng 1,18×, vì việc xác minh mã thông báo dự thảo kích hoạt nhiều chuyên gia hơn trong backend Metal của llama.cpp — Liquid gắn cờ điều này là đã biết.

DSpark không thay đổi gì về nơi agent 2.6B chạy — về bản chất, đây là câu chuyện tự lưu trữ (self-host), và nó sẽ nằm cạnh các mô hình lưu trữ mà bạn vẫn đang gọi. Sự kết hợp giữa một drafter cục bộ và hàng chục endpoint API chính là loại hạ tầng kết nối mà một lớp định tuyến tồn tại để thu gọn: một khóa API cho hơn 200 mô hình, tự động chuyển đổi dự phòng khi nhà cung cấp suy yếu, và giá niêm yết của nhà cung cấp được truyền thẳng qua với mức phụ phí 0%, để việc so sánh chi phí giữa cục bộ và lưu trữ cho một agent hạng 2.6B luôn rõ ràng thay vì phải nằm trong bảng tính.

Cách đọc đúng về LFM2.5-2.6B-DSpark ngày hôm nay là xem nó như một tuyên bố về tốc độ đầy hứa hẹn, do nhà cung cấp đo lường, chưa được kiểm chứng độc lập, gắn với một checkpoint thực sự có thể tải xuống và chạy được. Nếu bạn triển khai agent 2.6B trên thiết bị, mô hình nháp sẽ không tốn kém để thử và dễ dàng gỡ bỏ — chỉ cần thêm hai cờ speculative vào lệnh SGLang, giữ nguyên giải mã tham lam, và đo lường trên khối lượng công việc của riêng bạn trước khi tin vào con số 2.3×. Repo đã có sẵn; việc kiểm chứng độc lập vẫn là hạng mục còn bỏ ngỏ.