LFM2.5-24B-A2B-DSpark so với LFM2.5-24B-A2B: Bạn có thực sự nên gắn mô hình nháp không?

Đây là quyết định trong một dòng: LFM2.5-24B-A2B-DSpark là một tệp 327.7M tham số mà bạn đặt bên cạnh LFM2.5-24B-A2B để mô hình 24B tạo ra cùng loại đầu ra nhanh hơn. Nó không phải là một lựa chọn thay thế cho mô hình và cũng không phải là thứ bạn chọn thay vì mô hình. Câu hỏi thực sự duy nhất mà hai cái tên đặt ra là một câu hỏi kỹ thuật — bạn gắn bộ tạo nháp vào triển khai của mình hay để nó tắt — và câu trả lời phụ thuộc ít vào mức tăng tốc được quảng cáo của Liquid AI hơn là vào hai con số không ai quảng cáo: lượng token mà bản nháp được chấp nhận trên lưu lượng của bạn, và mức độ đồng thời mà bạn đang chạy. Những lỗi AI và sự cố tác nhân được ghi nhận đằng sau các bản phát hành như bản này được tập hợp trong Kho lưu trữ sự cố AI OrcaRouter trong đó mỗi mục có nguồn riêng, mức độ nghiêm trọng, cấp độ tin cậy và cờ tranh chấp.

Liquid AI chưa công bố bài đăng ra mắt nào cho drafter. Kho lưu trữ đã công khai vào ngày 2026-10-19 cùng với trọng số, một tệp CSV benchmark và các cờ khởi chạy SGLang, trong khi model card của chính target vẫn ghi drafter là "sắp ra mắt" và trang tài liệu về giải mã suy đoán của Liquid chỉ liệt kê các target 1.2B, 2.6B, 8B và VL-3B. Vì vậy, đây là so sánh một artifact đã phát hành với một mô hình đã phát hành, được viết dựa trên kho lưu trữ thay vì từ thông cáo báo chí — nghĩa là mọi con số hiệu năng dưới đây đều do nhà cung cấp báo cáo và chưa có phần nào được tái lập độc lập.

Người soạn thảo thực sự thay đổi điều gì và không thay đổi điều gì

Cơ chế này đáng để dành ba mươi giây vì nó quyết định mọi thứ còn lại. Việc giải mã một token bị giới hạn bởi bộ nhớ: GPU dành phần lớn thời gian để truyền trọng số vào SRAM, chứ không phải để tính toán. Giải mã suy đoán tận dụng điều đó bằng cách cho một mô hình nhỏ đoán nhiều token tiếp theo cùng lúc, rồi cho mô hình thật kiểm tra toàn bộ dự đoán đó trong một lượt truyền xuôi duy nhất. Nếu dự đoán tốt, bạn tạo ra chín token với chi phí xấp xỉ một token. Nếu dự đoán tệ, mô hình đích giữ token riêng của nó và bạn phải trả thêm một chút.

Những gì thay đổi: số token mỗi giây và hình dạng mức sử dụng GPU của bạn. Những gì không thay đổi: trọng số của mô hình, cửa sổ ngữ cảnh, hành vi gọi công cụ hoặc giá bán của nó ở nơi nó được bán. LFM2.5-24B-A2B giữ nguyên 24.0B tổng tham số với 2.45B tham số hoạt động mỗi token, 40 lớp được chia giữa các tích chập ngắn có cổng và attention truy vấn nhóm, 64 chuyên gia mỗi khối với định tuyến top-4, cửa sổ ngữ cảnh 131,072 token và từ vựng 128,000 token. Bộ dự thảo bổ sung năm lớp attention, một đầu Markov hạng 256 và một đầu độ tin cậy, đồng thời tái sử dụng embedding và LM head của mô hình đích thay vì mang theo bộ của riêng nó.

Có một lưu ý đã thay đổi giữa hai bản phát hành và đáng được nêu một dòng. Vào tháng 8, bài viết về DSpark của Liquid nói rằng chuỗi được phát ra là “giống hệt với greedy cơ sở về mặt cấu trúc.” Trong khi đó, thẻ của drafter 24B lại nói rằng sự khác biệt 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, kể cả dưới lấy mẫu greedy.” Cả hai phát biểu đều có thể bảo vệ được — phát biểu đầu đúng trong số học chính xác — nhưng nếu bộ khung đánh giá của bạn so sánh đầu ra theo từng byte, hãy chuẩn bị để nó phát hiện ra.

Phía chi phí của sổ cái

Bộ dự thảo không hề miễn phí. Nó chiếm 655 MB ở BF16 trên GPU (hoặc 664 MB F16 GGUF trên CPU), nằm trong cùng bể bộ nhớ với mô hình đích, và mỗi bước nó đề xuất tốn một lượt truyền xuôi xác minh trên cả một khối token thay vì chỉ một token. Trên mô hình đích MoE, phần cuối đó tốn kém hơn vẻ ngoài của nó: xác minh chín token kích hoạt nhiều chuyên gia hơn so với giải mã một token, nên số byte phải di chuyển trên mỗi token được xác minh tăng lên chứ không giảm. Liquid đã nêu chính xác điều này là lý do bộ dự thảo 8B của họ chỉ đạt 1,18× trên M4 Max dù tỷ lệ chấp nhận cao.

Đổi lại, khoản tiết kiệm đủ lớn để đo bằng giờ GPU. Sử dụng chính các con số B300 của nhà cung cấp từ benchmarks/b300-fp8.csv, và chỉ cần làm mỗi việc chia một tỷ token đầu ra cho thông lượng quan sát được:

• MATH-500, độ đồng thời 1 — 324 tok/s khi chạy một mình (857 giờ GPU trên mỗi tỷ token) so với 853 tok/s khi có drafter (326 giờ GPU). Giảm 2.63× thời gian tính toán.

• MATH-500, độ đồng thời 256 — 15.423 tok/s khi chạy riêng (18,0 GPU-giờ) so với 27.579 tok/s khi có bộ dự thảo (10,1 GPU-giờ). Giảm 1,79×.

• GSM8K, độ đồng thời 256 — 4,491 tok/s khi chạy một mình (61.9 giờ GPU) so với 9,660 tok/s khi có drafter (28.8 giờ GPU). Giảm 2.15×.

• LiveCodeBench, độ đồng thời 256 — 18,812 tok/s khi chạy một mình (14,8 giờ GPU) so với 25,231 tok/s khi dùng drafter (11,0 giờ GPU). Chỉ cắt giảm 1,34×, ô yếu nhất trong bảng.

Những con số đó là tỷ lệ thông lượng được quy đổi thành thời gian, không phải tiền, vì tiền phụ thuộc vào mức bạn trả cho mỗi GPU-giờ và bài viết này sẽ không tự bịa ra một mức giá. Nhưng thứ tự vẫn đúng ở bất kỳ mức giá nào: gắn drafter đáng giá hai đến ba giờ trên mỗi mười giờ đối với lưu lượng suy luận và sinh mã ở mức đồng thời thấp, và đáng khoảng một phần ba con số đó ở mức đồng thời cao. Nếu triển khai 24B của bạn là một tác nhân đơn người dùng trên máy trạm, lập luận này rất mạnh. Nếu đó là một endpoint batch bão hòa, lập luận là có thật nhưng mỏng hơn nhiều so với con số tiêu đề 2,4× gợi ý.

Nơi công cụ soạn thảo chứng tỏ được giá trị của mình, xét về khối lượng công việc

Độ phân tán tám bộ dữ liệu trong bảng của nhà cung cấp không phải là nhiễu; nó ánh xạ tới các loại lời nhắc, và ánh xạ đó là thứ hữu ích nhất trong bản phát hành. Tỷ lệ chấp nhận dao động từ 6.70 token mỗi bước trên MBPP xuống 4.02 trên LiveCodeBench. Các bộ dữ liệu đạt điểm cao là những bộ mà đầu ra của mô hình bị ràng buộc bởi lời nhắc — các hàm ngắn kiểu kiểm thử đơn vị, số học với một đường đi có thể kiểm tra, câu trả lời trắc nghiệm. Những bộ đạt điểm thấp là những bộ mà mô hình phải tự nghĩ ra một lời giải dài, không bị ràng buộc: các bài toán lập trình thi đấu và toán kiểu AIME.

Đó là trực giác cần mang theo vào quá trình đánh giá của chính bạn. Một mô hình suy luận 24B được bán cho công việc tác tử dành phần lớn token đầu ra bên trong một chuỗi suy nghĩ, trông giống LiveCodeBench hơn là MBPP. Một mô hình được dùng để trích xuất có cấu trúc, phân loại với một schema, hoặc một định dạng gọi công cụ cố định trông giống các hàng có tỷ lệ chấp nhận cao hơn nhiều. Nếu khối lượng công việc của bạn thuộc loại trước, hãy kỳ vọng rơi gần mức đáy 1,34× của khoảng hơn là mức đỉnh 3,28×. Chưa ai công bố tỷ lệ chấp nhận theo từng khối lượng công việc cho drafter này, và tám bộ dữ liệu trên thẻ mô hình là thứ gần nhất với một hướng dẫn.

Đặt ngược lại với điều đó: 24B là một mô hình chỉ suy luận. Liquid nói rằng nó luôn suy nghĩ trước khi trả lời — mẫu chat chèn thẻ <think> một cách tự động. Đó là hình dạng tệ nhất có thể cho việc suy đoán, bởi vì đoạn suy luận chính xác là đoạn dài, có tỷ lệ chấp nhận thấp. Mô hình soạn thảo vẫn sẽ hữu ích; nó sẽ giúp nhiều nhất ở câu trả lời cuối cùng và ít nhất ở phần tốn nhiều thời gian nhất.

Cách nhận biết, trên phần cứng của chính bạn, trong một buổi chiều

Bạn không cần phải tin bất kỳ điều nào ở trên. Cả hai đường suy luận đều hiển thị bộ đếm chấp nhận, và đây là con số duy nhất quyết định liệu bộ dự thảo có tự bù đắp chi phí trên lưu lượng của bạn hay không.

Trên SGLang, hãy khởi chạy mục tiêu với drafter được gắn kèm, kích thước khối 9 và mười token nháp, rồi đọc các số liệu giải mã suy đoán mà máy chủ báo cáo theo từng yêu cầu. Tỷ lệ chấp nhận trong bảng của nhà cung cấp nằm trong khoảng từ 0,33 đến 0,65 tùy theo bộ dữ liệu; một lần chạy thấp hơn hẳn dòng tương ứng nghĩa là drafter đang đoán sai và bạn đang phải trả chi phí xác minh mà không đạt được tốc độ tăng. Trên llama.cpp với sidecar F16 GGUF, thời gian của từng phản hồi mang draft_n và draft_n_accepted trực tiếp. Hãy lấy số này chia cho số kia.

Hai chi tiết vận hành sẽ khiến bạn tốn một giờ nếu bỏ lỡ. Máy chủ SGLang cần một bản build có bao gồm đường dẫn LFM2-MoE DSpark được hợp nhất vào 2026-08-31 — trên bất kỳ bản nào cũ hơn, kiến trúc drafter đơn giản là không được biết đến. Và kích thước khối là một thuộc tính của checkpoint, không phải tham số tự do: llama.cpp giới hạn --spec-draft-n-max theo giá trị 9 trong metadata của sidecar, nên yêu cầu 12 cũng chẳng được gì.

Câu hỏi mà sự so sánh này không thể trả lời

Có một phiên bản của câu hỏi "có nên gắn drafter hay không" chẳng liên quan gì đến GPU, và đó chính là phiên bản mà hầu hết các đội thực sự gặp phải. Nếu bạn gọi LFM2.5-24B-A2B qua một API được lưu trữ, quyết định về drafter không thuộc về bạn. Ngăn xếp phục vụ hoặc gắn một bộ giải mã suy đoán, hoặc không; bạn chỉ thấy một con số token mỗi giây và một mức giá, và cả hai đều đã được quyết định ở thượng nguồn. Console của chính Liquid liệt kê mô hình 24B ở mức $0,10 cho mỗi triệu token đầu vào, $0,05 cho đầu vào được lưu trong bộ nhớ đệm và $1,00 cho mỗi triệu token đầu ra — một mức giá đã công bố phản ánh bất kể đường giải mã nào họ đang chạy, và là mức giá có thể thay đổi mà không cần thông báo.

Đó chính là điểm giao thoa nơi định tuyến giúp ích thay vì làm phức tạp mọi thứ. Một lệnh gọi tới dịch vụ được lưu trữ và một triển khai tự lưu trữ không hẳn là những phương án cạnh tranh mà đúng hơn là hai nấc chỉnh của cùng một núm chi phí: tự lưu trữ cộng với mô hình drafter giảm thiểu chi phí trên mỗi token nếu lưu lượng của bạn giữ GPU luôn bận, còn endpoint được lưu trữ giảm thiểu công sức để có được câu trả lời. OrcaRouter được xây dựng cho hướng thứ hai — một khóa duy nhất cho hơn 200 mô hình với mức tăng giá 0% so với giá niêm yết của nhà cung cấp, nên khi giá của nhà cung cấp thay đổi, thay đổi đó sẽ xuất hiện ở phía chúng tôi ngay trong ngày, với tính năng tự động chuyển đổi dự phòng nếu một nhà cung cấp bị suy giảm và một DSL định tuyến để phân tách lưu lượng thay vì mã hóa cứng một backend. Hiện chúng tôi không phục vụ dòng LFM2.5, vì vậy với mô hình cụ thể này, phía được lưu trữ nghĩa là API riêng của Liquid hoặc GPU của bạn; phép so sánh đáng để thực hiện là với các mô hình mà chúng tôi thực sự cung cấp, chẳng hạn như Qwen3.6-35B-A3B — mô hình mà Liquid dùng để đánh giá so sánh trên các tác vụ agentic — hoặc Gemma 4 26B-A4B.

Vậy: gắn nó hay không

Hãy gắn nó nếu bạn tự phục vụ LFM2.5-24B-A2B ở mức đồng thời khiêm tốn, đặc biệt với đầu ra có cấu trúc hoặc dạng trích xuất, và nếu bạn có 655 MB dư dung lượng bên cạnh mô hình đích. Số liệu của nhà cung cấp cho thấy bạn sẽ giảm khoảng một nửa hoặc còn một phần ba thời gian giải mã ở đó, và nhược điểm thì có giới hạn: một mô hình nháp tồi chỉ tốn một lượt xác minh, chứ không tạo ra câu trả lời sai.

Hãy tắt nó nếu endpoint của bạn đã bão hòa ở mức hàng trăm, nếu đầu ra của bạn là suy luận tự do dài, hoặc nếu bạn cần số liệu Apple-silicon trước khi cam kết — card không có số liệu nào, và mẫu tương tự gần nhất từ cùng dòng sản phẩm đã ra mắt đạt 1.18× trên MacBook. Và rõ ràng là hãy tắt nó nếu bạn hoàn toàn không chạy mô hình: drafter là một tối ưu hóa cho một triển khai, và không có gì để tối ưu cho đến khi triển khai đó tồn tại.

Điều có thể giải quyết phần còn lại là một bài đăng từ nhà cung cấp và một phép đo trên Mac. Cả hai đều không tồn tại tính đến ngày 2026-10-21, một trạng thái kỳ lạ đối với một bản phát hành mà trọng số đã có thể tải xuống — và, đối với bất kỳ ai sẵn lòng tự chạy bộ đếm chấp nhận, là một cơ hội rẻ bất thường để trở thành con số độc lập đầu tiên trên bảng.