Liquid AI ra mắt LFM2.5-DSpark với tốc độ suy luận nhanh hơn tới 3,2 lần

Liquid AI đã phát hành các checkpoint dự thảo giải mã dự đoán cho ba mô hình trong họ LFM2.5 vào ngày 20 tháng 8 năm 2026, báo cáo mức tăng thông lượng lên tới 3.18x trên một GPU H100 duy nhất và lên tới 2.87x trên MacBook Apple‑silicon, mà không làm thay đổi đầu ra của mô hình. Bản phát hành bản phát hành LFM2.5-DSpark bao gồm các trình dự thảo cho LFM2.5-1.2B-Instruct, LFM2.5-2.6B và mô hình hỗn hợp chuyên gia LFM2.5-8B-A1B, mỗi mô hình thêm khoảng 300 triệu tham số dự thảo lên trên mô hình mục tiêu.

Các checkpoint được cung cấp dưới định dạng Safetensors và GGUF với hỗ trợ ngay từ ngày đầu trong llama.cpp và SGLang, cả hai tích hợp đều đã đóng góp ngược lên các mã nguồn chính thức. Vì giải mã dự đoán chỉ phát ra các token mà mô hình mục tiêu đã xác nhận, công ty cho biết văn bản tạo ra hoàn toàn giống với kết quả mà mô hình mục tiêu sẽ tạo ra riêng khi sử dụng giải mã tham lam, do đó độ chính xác của các bài kiểm tra không thay đổi.

Các đo lường của Liquid AI, thực hiện với kích thước batch 1 và nhiệt độ 0 trên năm bộ dữ liệu, cho thấy tốc độ trung bình tăng 2.67x cho LFM2.5-2.6B trên một H100 (323 → 864 token mỗi giây) và 2.27x trên MacBook Pro M4 Max (61 → 139 token mỗi giây). Kết quả duy nhất lớn nhất đến từ LFM2.5-8B-A1B trên bộ dữ liệu MATH500, nơi thông lượng trên H100 tăng 3.18x, từ 428 → 1,362 token mỗi giây. Công ty cũng báo cáo rằng DSpark giảm độ trễ gọi hàm trung bình 57% cho LFM2.5-2.6B trong các kịch bản đa công cụ, là kết quả tiêu biểu cho các khối lượng công việc agentic trên thiết bị mà dòng LFM2.5 hướng tới.

How DSpark Speeds Up Decoding

Giai đoạn giải mã trong suy luận LLM bị ràng buộc bởi bộ nhớ: phần lớn độ trễ xuất phát từ việc truyền trọng số từ DRAM vào bộ nhớ trên chip thay vì từ tính toán, vì vậy kinh tế suy luận đã trở thành vấn đề kỹ thuật trung tâm của lĩnh vực.

Giải mã dự đoán giải quyết vấn đề này bằng cách để một mô hình dự thảo nhỏ đề xuất một khối token ứng cử, sau đó xác nhận toàn bộ khối trong một lần truyền tiến của mô hình mục tiêu, phân tán chi phí tải trọng số cho mỗi token được kiểm tra.

DSpark, được giới thiệu trong một bài báo tháng 7 năm 2026 của các nhà nghiên cứu DeepSeek và được triển khai trong hệ thống phục vụ DeepSeek‑V4 của công ty, kết hợp ba thành phần: một khung nền song song tạo ra các trạng thái ẩn cho tất cả các token dự thảo trong một lần truyền, một đầu tuần tự nhẹ nhàng mô hình hóa các phụ thuộc giữa các token lân cận để duy trì tỷ lệ chấp nhận không giảm ở cuối khối, và một bộ xác minh theo lịch trình độ tin cậy, loại bỏ các hậu tố có độ tin cậy thấp khi việc xác minh chúng tốn nhiều hơn lợi ích. Trong triển khai sản xuất của DeepSeek, bài báo báo cáo tốc độ tăng sinh cho mỗi người dùng từ 60% đến 85% so với chuẩn MTP‑1 trước đó ở mức thông lượng tương đương.

Các trình dự thảo của Liquid AI tuân theo công thức này với thiết kế chỉ dựa trên attention đơn giản: năm lớp, kích thước khối chín token dự thảo mỗi bước, và một đầu Markov trên từ vựng 128.000 token, theo thẻ mô hình LFM2.5-2.6B-DSpark. Mỗi trình dự thảo được huấn luyện trong 15 epoch trên sự kết hợp của fine‑tuning có giám sát, trò chuyện, mã và dữ liệu gọi hàm, với checkpoint được chọn dựa trên tỷ lệ chấp nhận cao nhất thay vì mất mát thấp nhất. Cam kết chính xác thực hiện công việc chất lượng: “Giải mã dự đoán là chính xác: mô hình mục tiêu xác nhận mọi token được đề xuất, vì vậy đầu ra tham lam bằng với mô hình mục tiêu khi hoạt động độc lập,” thẻ mô hình GGUF ghi, kèm thời gian phản hồi cho thấy có bao nhiêu token dự thảo đã được đề xuất và chấp nhận.

LFM2.5-DSpark by the Numbers

• 3.18x — tốc độ tăng GPU tốt nhất được báo cáo (LFM2.5-8B-A1B, MATH500, H100: 428 → 1,362 tok/s)
• 2.87x — tốc độ tăng trên thiết bị tốt nhất được báo cáo (LFM2.5-1.2B-Instruct, HumanEval, M4 Max: 136 → 389 tok/s)
• 2.67x / 2.27x — tốc độ trung bình H100 / M4 Max cho LFM2.5-2.6B trên năm bộ dữ liệu
• 57%: giảm độ trễ gọi hàm trung bình cho LFM2.5-2.6B trong các kịch bản đa công cụ
• 295.7M–327.7M (số tham số mô hình dự thảo, so với mục tiêu từ 1.2B đến 8B)
• 4.81 trên 10, số token dự thảo trung bình được chấp nhận mỗi bước cho LFM2.5-2.6B với kích thước khối 9

Where the Reported Speedups Narrow

Các bảng của Liquid AI cho thấy mức tăng không đồng đều, và công ty đã nêu lý do. Đối với LFM2.5-8B-A1B, cải thiện trên thiết bị trung bình chỉ 1.18 lần mặc dù có tỷ lệ chấp nhận cao nhất trong ba mô hình, khoảng cách này công ty quy cho việc triển khai hiện tại của mixture‑of‑exets trong backend Metal của llama.cpp và lưu lượng trọng số bổ sung mà việc xác nhận một khối token kích hoạt trên các chuyên gia. Đối với LFM2.5-1.2B-Instruct, tỷ lệ chấp nhận thay đổi đáng kể theo bộ dữ liệu khiến tốc độ tăng dao động tới 52% tùy vào phân bố văn bản, từ 1.66 lần trên MT‑Bench lên đến 2.56 lần trên MATH500 trên H100.

Tất cả các con số đều được báo cáo bởi nhà cung cấp từ bộ công cụ nội bộ của Liquid AI: SGLang trên một H100 80GB ở chế độ BF16 cho các số liệu GPU, llama.cpp với các kernel Metal thử nghiệm trên một M4 Max sử dụng trọng số GGUF FP16 cho các số liệu trên thiết bị, giới hạn ở 256 token đầu ra. Đường dẫn SGLang yêu cầu biên dịch có hỗ trợ DSpark cho các mục tiêu LFM2, và đường dẫn llama.cpp cũng cần biên dịch tương ứng, vì vậy mức tăng tốc phụ thuộc vào các tích hợp này chứ không phải được cung cấp trong bản phát hành ổn định của bất kỳ engine nào.

Liquid AI’s On-Device Push So Far

Bản phát hành DSpark là bản cập nhật thứ ba của họ LFM2.5 trong vòng hơn một tuần. Vào ngày 12 tháng 8 năm 2026, công ty đã ra mắt LFM2.5-VL-3B, một mô hình thị giác-ngôn ngữ cho thiết bị biên, và vào ngày 19 tháng 8 năm 2026 họ đã công bố checkpoint Q4_0 được tinh luyện có nhận thức lượng tử cho họ. Dòng chảy chung vẫn như cũ: công ty cho biết tốc độ tăng DSpark của mô hình 2.6B trên MacBook đẩy khả năng tương tác vượt qua thông lượng mà hầu hết các mô hình đám mây độc quyền cung cấp, ước tính khoảng 140 token mỗi giây.

Ba trình dự thảo đều có sẵn ngay trên Hugging Face: LFM2.5-1.2B-Instruct-DSpark, LFM2.5-2.6B-DSpark, và LFM2.5-8B-A1B-DSpark, kèm theo các bản build GGUF cho việc triển khai trên llama.cpp.