LFM2.5-24B-A2B-DSpark đã chính thức có mặt trên Hugging Face — Liquid AI vẫn chưa công bố.

Thẻ mô hình của mô hình lớn nhất của Liquid AI vẫn ghi rằng drafter giải mã suy đoán của nó sắp ra mắt. Drafter này sẽ không ra mắt. LFM2.5-24B-A2B-DSpark đã có kho lưu trữ công khai từ 2026-10-19, một checkpoint BF16 655 MB, một bảng benchmark đầy đủ, một tệp sidecar GGUF được công bố vào tối hôm sau, và các cờ khởi chạy cho SGLang được ghi trong thẻ của nó. Điều mà nó không có là một thông báo. LFM2.5-24B-A2B, mô hình mixture-of-experts 24B mà nó được tạo ra để tăng tốc, đã có một bài đăng blog, một buổi ra mắt có ghi ngày, một bảng giá và một liên kết playground vào 2026-10-13. Drafter của nó có một repo và một thẻ mô hình, còn trang tài liệu của chính Liquid AI về giải mã suy đoán vẫn chỉ liệt kê các mục tiêu 1.2B, 2.6B, 8B và VL-3B là được hỗ trợ. Các thất bại AI và sự cố agent đã được ghi nhận đằng sau những bản phát hành như bản này được tập hợp trong OrcaRouter AI Incident Archive, nơi mỗi mục đều mang nguồn riêng, mức độ nghiêm trọng, xếp hạng độ tin cậy và cờ tranh chấp.

Khoảng trống đó chính là câu chuyện ở đây, và đáng để nói chính xác nó có nghĩa gì và không có nghĩa gì. Một kho lưu trữ có trọng số mở, có benchmark tái lập được từ một tệp CSV nằm ngay cạnh mô hình, và có đường suy luận đã được hợp nhất vào upstream là một bản phát hành thực sự, không phải một vụ rò rỉ. Nhưng chưa có gì về nó được nhà cung cấp xác nhận bằng lời văn, chưa bên thứ ba nào đo đạc nó, và các con số trong thẻ mô hình là số của chính cùng nhóm đó, được đo trên đúng phần cứng mà họ đã chọn. Bài viết này tách bạch hai điều: những gì kho lưu trữ xác lập, và những gì vẫn chỉ là tuyên bố.

Thực sự có gì trong kho lưu trữ?

Checkpoint nhỏ đến mức bản thân phần liệt kê tệp đã mang nhiều thông tin. Toàn bộ chỉ gồm một model.safetensors ở 655.421.522 byte — 327,7M tham số ở BF16 — cộng với một tệp cấu hình, một giấy phép và một thư mục benchmark. Không có gì khác. Không có tokenizer, không có ma trận embedding và không có LM head, vì kiến trúc tái sử dụng cả ba từ mô hình đích khi tải. Đó chính là thiết kế: mô hình soạn thảo chỉ cần biết cách đoán khối token tiếp theo trong từ vựng của mô hình đích, chứ không cần biết cách biểu diễn thế giới.

Cấu hình xác nhận đúng hình dạng mà bài viết về DSpark tháng 8 đã mô tả. Năm lớp full-attention với kích thước ẩn 2,048 và kích thước trung gian 6,144 dùng SiLU/SwiGLU; grouped-query attention với 32 head và 8 KV head ở chiều head 64; một Markov head hạng 256 và một head độ tin cậy riêng; kích thước block 9; từ vựng 128,000; và embedding vị trí tối đa 131,072, khớp chính xác với cửa sổ ngữ cảnh của target. Trường duy nhất đặc trưng cho drafter này là target_layer_ids: [2, 10, 18, 26, 34] so với num_target_layers: 40 — năm lớp của mô hình 24B mà drafter đọc trạng thái ẩn của chúng làm ngữ cảnh. Chính các chỉ số đó là lý do một drafter được huấn luyện cho một mô hình LFM2.5 không thể chỉ đơn giản trỏ sang một mô hình khác.

Giấy phép là lfm1.0, cùng loại giấy phép tùy chỉnh như phần còn lại của dòng sản phẩm, điều này đáng lưu ý cho bất kỳ ai dự định phân phối lại một gói kết hợp target cộng drafter thay vì sử dụng nội bộ.

Bảng benchmark, được đọc như một bảng của nhà cung cấp

Thẻ này công bố thông lượng cho tám bộ dữ liệu ở mức đồng thời 1, 32 và 256, trên một NVIDIA B300 duy nhất với target FP8, KV cache BF16 và temperature 0. Mọi con số dưới đây đều là của chính Liquid AI và chưa được tái lập bên ngoài công ty; các hàng dữ liệu thô nằm trong tệp benchmarks/b300-fp8.csv của repo nếu bạn muốn tự kiểm tra phép tính.

• Trung bình cộng trên tám bộ dữ liệu — 2,38× ở mức đồng thời 1, 2,69× ở mức đồng thời 32, 1,71× ở mức đồng thời 256.

• Ô đơn tốt nhất — MBPP ở mức đồng thời 32, đạt 3,28×, với MATH-500 bám sát ngay sau ở 3,04×.

• Ô đơn tệ nhất — LiveCodeBench ở mức đồng thời 256, 1,34×, và AIME ở 256, 1,36×.

• Số token được chấp nhận mỗi bước — trung bình 5,16, so với mức trần là 10 do kích thước khối cộng với token thưởng của mục tiêu đặt ra.

• Tỷ lệ chấp nhận cao nhất — MBPP ở 6,70 token mỗi bước; thấp nhất — LiveCodeBench ở 4,02.

Có hai điều về bảng đó thú vị hơn tiêu đề. Điều thứ nhất là hệ số tăng tốc trung bình cao hơn ở mức đồng thời 32 so với mức đồng thời 1 — 2,69× so với 2,38× — điều này ngược lại với câu chuyện speculative decoding thông thường, nơi việc gom batch làm mất đi lợi ích. Điều thứ hai là nó sụp đổ ở 256. Ở 256 yêu cầu đồng thời, chỉ riêng target đã tạo ra khoảng 15.000 token mỗi giây trên GPU đó cho MATH-500, và đóng góp của drafter giảm xuống còn 1,79×. Một nhóm serving chỉ đọc "2,4×" sẽ định cỡ cụm sai; con số quan trọng đối với một endpoint được batch là 1,71×, và ngay cả con số đó cũng là con số của B300 với một cấu hình đồng thời mà hầu hết các triển khai sẽ không khớp.

Câu đã thay đổi kể từ tháng Tám

Khi Liquid AI phát hành các drafter DSpark cho các target 1.2B, 2.6B và 8B-A1B vào ngày 20-08-2026, bài đăng blog của công ty đã đưa ra một tuyên bố mạnh mẽ: bởi vì target xác minh mọi token được đề xuất và thay thế các token bị từ chối bằng lựa chọn của chính nó, nên "chuỗi được phát ra do đó giống hệt với baseline greedy theo đúng thiết kế." Thẻ model của drafter 8B lặp lại tinh thần đó, cam kết "đầu ra hoàn toàn giống hệt."

Thẻ của drafter 24B không nói như vậy. Nó nói rằng mô hình đích xác minh từng token được đề xuất, và sau đó: "Sự khác biệt về dấu phẩy động giữa xác minh theo lô và giải mã thông thường có thể tạo ra văn bản khác nhau, kể cả khi lấy mẫu tham lam." Nó bổ sung rằng các phép đo đánh giá hiệu năng chứ không phải độ chính xác của tác vụ.

Đây là một câu cẩn trọng hơn, và nó là câu đúng. Xác minh theo lô không thực hiện các phép toán dấu phẩy động giống nhau theo cùng thứ tự như giải mã tuần tự, vì vậy tính đồng nhất bit là một giả định đúng trong số học chính xác và không phải lúc nào cũng đúng trên phần cứng thực tế. Việc card mới hơn nói như vậy trong khi card cũ hơn thì không có thể là một chỉnh sửa tài liệu hoặc một phát hiện trong quá trình huấn luyện drafter này — kho lưu trữ không cho bạn biết là trường hợp nào, và Liquid chưa công bố lời giải thích. Điều đó có ý nghĩa thực tế hẹp nhưng có thật: nếu bộ kiểm thử hồi quy của bạn so sánh đầu ra mô hình từng byte một, việc thêm drafter này có thể làm nó báo lỗi, và đó là một đặc tính của số học chứ không phải lỗi trong bản draft.

Tại sao Drafter lại xuất hiện sáu ngày sau mô hình của chính nó

Cần trình bày rõ dòng thời gian vì nó giải thích sự im lặng tốt hơn bất kỳ suy đoán nào về chiến lược.

• 2026-08-20 — Liquid công bố dòng DSpark: các mô hình nháp cho LFM2.5-1.2B-Instruct, LFM2.5-2.6B và LFM2.5-8B-A1B. Hiện vẫn chưa có mô hình đích 24B nào.

• 2026-08-31 — SGLang hợp nhất PR #31041, bổ sung hỗ trợ giải mã suy đoán DSpark cho LFM2 và LFM2-MoE. Nhánh MoE mà 24B cần đã có mặt ở đây, một tháng rưỡi trước khi mô hình mà nó sẽ phục vụ xuất hiện.

• 2026-10-13 — LFM2.5-24B-A2B ra mắt cùng một bài đăng blog và một mức giá. Cùng ngày hôm đó, SGLang hợp nhất PR #43939, cho phép máy chủ sử dụng trực tiếp cấu hình LFM2-MoE của Hugging Face.

• 2026-10-19 — kho lưu trữ LFM2.5-24B-A2B-DSpark xuất hiện, cùng với trọng số và các kết quả đánh giá.

• 2026-10-20 — sidecar GGUF ra mắt: một tệp F16 664 MB duy nhất dành cho llama.cpp.

• 2026-10-21 — thẻ mô hình đích có thêm một hàng drafter. Nó vẫn ghi là Sắp ra mắt.

Đọc trình tự đó thì cách lý giải khả dĩ nhất lại chính là cách nhàm chán nhất. Hạ tầng đã được phát hành trước sản phẩm; sản phẩm được phát hành khi quá trình huấn luyện hoàn tất; còn thông báo chỉ là một việc tiếp thị chưa diễn ra. Không có gì trong kho mã gợi ý về một màn ra mắt cố ý im ắng — tấm card mô hình đã hoàn chỉnh, các benchmark được ghi chép chi tiết đến tận giao thức, và các lệnh gọi SGLang và llama.cpp được viết ra đầy đủ. Im ắng ở đây nghĩa là chưa được thông báo, chứ không phải bị giấu đi.

Những gì chưa thể biết được

Ranh giới trung thực của bài viết này là một danh sách ngắn, và mỗi mục là một khoảng trống thực sự chứ không phải là một thủ tục hình thức.

Không có đo lường độc lập. Không có mục Artificial Analysis nào, không có lần chạy nghiệm thu nào của bên thứ ba, không có việc tái tạo bảng thông lượng. Tính đến 2026-10-21, kho lưu trữ hiển thị bảy lượt tải xuống và một lượt thích. Mọi mức tăng tốc trong bài viết này đều là của nhà cung cấp, trên GPU do nhà cung cấp lựa chọn, với độ chính xác mục tiêu do nhà cung cấp lựa chọn.

Không có thông báo, nên không có định khung. Chúng tôi không biết liệu Liquid có ý định đây là khuyến nghị sản xuất cho 24B hay là một sản phẩm nghiên cứu. Giọng điệu của thẻ — đầy đủ cờ ra mắt, bảng dòng mô hình, liên kết liên hệ — gợi ý khả năng đầu tiên, nhưng đó là suy luận.

Không có giá, vì không thể có giá. Drafter không phải là một mô hình được phục vụ. Nó không có mức giá trên mỗi triệu token và sẽ không bao giờ xuất hiện trên danh mục mô hình như một endpoint có thể gọi được. Chi phí của nó là 655 MB VRAM hoặc bộ nhớ hợp nhất mà nó chiếm bên cạnh mô hình đích, cộng với phần tính toán thêm để xác minh một khối thay vì một token.

Không có số liệu Apple-silicon. Đây là khoảng trống lớn nhất, và phần tiếp theo giải thích vì sao nó quan trọng hơn những khoảng trống khác.

Số Mac bị thiếu chính là điểm bỏ sót đáng chú ý.

Mô hình 24B được bán như một mô hình chạy trên thiết bị. Bài đăng ra mắt của Liquid mở đầu bằng 184 token mỗi giây trên Apple M5 Max và gọi nó được xây dựng cho các tác nhân nhanh, riêng tư trên thiết bị. Ngược lại, thẻ thông số của drafter chỉ báo cáo số liệu B300. Với drafter 8B vào tháng 8, Liquid đã công bố cả kết quả H100 và M4 Max và thẳng thắn về khoảng cách giữa chúng: mức tăng tốc trung bình 2,54× trên H100 trở thành 1,18× trên MacBook. Lý do được nêu mang tính cơ học — việc xác minh k token kích hoạt nhiều chuyên gia hơn một bước giải mã đơn lẻ, nên một mục tiêu MoE phải trả nhiều lưu lượng trọng số hơn trên mỗi token được xác minh, và backend Metal của llama.cpp khiến điều đó còn tệ hơn.

LFM2.5-24B-A2B cũng là một hỗn hợp chuyên gia: 64 chuyên gia mỗi khối với định tuyến top-4. Cơ chế tương tự cũng áp dụng, và 24B là một mô hình lớn hơn với tập chuyên gia lớn hơn để duyệt qua. Điều đó không chứng minh mức tăng tốc trên thiết bị là nhỏ — mô hình phác thảo được huấn luyện riêng cho mục tiêu này, và tỷ lệ chấp nhận tốt hơn nhiều so với mức ban đầu của 8B — nhưng điều đó có nghĩa là con số duy nhất mà người dùng laptop cần lại chính là con số mà thẻ không chứa. Hãy coi mọi giả định rằng tỷ lệ B300 áp dụng sang Mac là chưa được xác minh.

Chạy nó, và cái cờ duy nhất sẽ khiến bạn gặp rắc rối

Trên GPU, công thức đã được công bố là SGLang với target FP8 và drafter được đính kèm, block size 9 và mười draft token. Bản SGLang đã cài đặt phải đủ mới để bao gồm đường dẫn LFM2-MoE DSpark từ PR #31041 và việc tái sử dụng cấu hình từ PR #43939; trên một bản build cũ hơn, máy chủ sẽ hoàn toàn không nhận diện được kiến trúc drafter. Lưu ý rằng các số liệu benchmark giả định target FP8 — target BF16 sẽ hành xử khác, và không nhất thiết tốt hơn, vì drafter được huấn luyện dựa trên một phân phối cụ thể của logits target.

Trên CPU và Apple silicon, đường đi là llama.cpp với sidecar F16 GGUF. Sidecar đọc kích thước khối của chính nó từ metadata riêng và kẹp --spec-draft-n-max theo đó, nên đặt độ dài bản nháp thành 12 không có nghĩa là bạn được 12. Thông số thời gian theo từng phản hồi cho thấy draft_n và draft_n_accepted, đây là trường cần theo dõi trên khối lượng công việc của riêng bạn: nếu tỷ lệ chấp nhận trên lưu lượng của bạn thấp hơn nhiều so với mức trung bình 5,16 của card, thì drafter đang khiến bạn tốn một lượt forward mà đổi lại chẳng được bao nhiêu, và việc làm trung thực là tách nó ra.

Điều này có nghĩa gì nếu bạn đang chọn một mô hình trong tuần này

Với hầu hết các đội ngũ, hệ quả thực tế là không đáng kể, vì bộ drafter chỉ thay đổi tốc độ chứ không thay đổi năng lực. LFM2.5-24B-A2B là thứ trả lời các prompt; bộ drafter chỉ thay đổi số lượng câu trả lời đó mà bạn nhận được mỗi giây. Nếu 24B chưa nằm trong danh sách rút gọn của bạn tuần trước, thì một phiên bản nhanh hơn của nó cũng không đưa nó vào đó.

Nếu nó nằm trong danh sách rút gọn của bạn, mô hình nháp cải thiện phương án tự vận hành và không có tác dụng gì với phương án API. Sự khác biệt đó đáng được nói rõ: một checkpoint giải mã suy đoán là vô hình đối với bất kỳ ai gọi endpoint được lưu trữ, vì ngăn xếp phục vụ quyết định có gắn nó hay không. Điều bạn có thể so sánh trên cùng một cơ sở là chính mô hình với các lựa chọn thay thế mà bạn sẽ định tuyến đến — và nếu bạn đang đánh giá nó với thứ gì đó như Qwen3.6-35B-A3B, mô hình mà Liquid dùng làm đối chuẩn trên năm trong tám tác vụ agentic, OrcaRouter cung cấp mục tiêu so sánh đó qua một khóa duy nhất với mức phụ trội 0% trên giá niêm yết của nhà cung cấp, cùng khả năng chuyển đổi dự phòng tự động giữa các nhà cung cấp. Hiện tại chúng tôi không phục vụ dòng LFM2.5, nên bản thân mô hình 24B phải đến từ API của chính nhà cung cấp hoặc từ GPU của bạn; thứ chúng tôi cung cấp là phía còn lại của phép so sánh mà không cần hợp đồng thứ hai.

Điều gì sẽ thay đổi bức tranh này

Ba điều, theo thứ tự mức độ chúng có thể làm thay đổi câu chuyện. Một bài đăng blog từ Liquid sẽ chốt lại cách định khung — đây là một cặp kết hợp được khuyến nghị cho môi trường sản xuất hay một bản phát hành nghiên cứu. Một phép đo Mac đã công bố sẽ chốt lại tuyên bố quan trọng đối với nhóm người dùng mà 24B được tạo ra. Và một lượt chạy nghiệm thu độc lập trên lưu lượng thực tế, thay vì tám bộ dữ liệu benchmark ở temperature 0, sẽ cho bạn biết liệu 5.16 token mỗi bước có chịu được khi tiếp xúc với những prompt dài, lộn xộn, gọi công cụ mà mô hình này thực sự được bán cho hay không.

Cho đến lúc đó, kho lưu trữ vẫn công khai, các trọng số có thể tải xuống, tệp CSV nằm ngay đó, và model card của chính nhà cung cấp là nơi cuối cùng bạn nên tìm tin tức về nó. Đó là một trạng thái bất thường đối với một bản phát hành — nhưng đó là trạng thái có thật, và artifact không trở nên kém thật hơn chỉ vì không ai viết bài blog.