LFM2.5-VL-3B-DSpark: Drafter 279,5M của Liquid AI đã được phát hành sáu ngày trước khi bất kỳ ai công bố nó

Có một phiên bản của câu chuyện này trong đó LFM2.5-VL-3B-DSpark là một mô hình mới. Không phải vậy. Nó là một mô hình nháp giải mã suy đoán 279,5 triệu tham số, tồn tại chỉ vì đúng một mục đích — giúp mô hình ngôn ngữ-thị giác LFM2.5-VL-3B của chính Liquid AI giải mã nhanh hơn — và nó không thể tự tạo ra một câu trả lời dùng được. Lý do nó vẫn đáng để đọc là ở dòng thời gian: các trọng số được đăng lên Hugging Face vào ngày 18 tháng 9 năm 2026, không kèm bất kỳ thông báo nào, nằm đó sáu ngày, và chỉ đến ngày 24 tháng 9 mới có một bài đăng blog của nhà cung cấp. Radar đã bắt gặp repo trong khoảng trống đó.

Khoảng cách đó cũng chính là ranh giới của những gì có thể biết được ở thời điểm hiện tại. Mọi thứ trong kho lưu trữ — bảng phân tích tham số, kích thước khối, các tích hợp framework, giấy phép — đều là một tệp trên đĩa mà bạn hoặc tôi có thể mở. Mọi con số tăng tốc đều do nhà cung cấp đo lường, từ chính bộ công cụ đánh giá chuẩn của Liquid, và chưa có ai bên ngoài công ty công bố một bản tái lập. Bài viết này cố ý tách riêng hai nhóm đó.

Kho lưu trữ thực sự chứa những gì

Mở model card ra và hình dạng của thứ này là rõ ràng không thể nhầm lẫn. LFM2.5-VL-3B-DSpark là một mô hình nháp mà target của nó được cố định trong metadata: base_model: LiquidAI/LFM2.5-VL-3B. Bạn không trỏ nó vào một model khác và bạn không phục vụ nó một mình.

• Tổng số tham số nháp — 279,5M, BF16, trong đó 193,0M là ngăn xếp bộ giải mã 4 lớp, 65,5M là đầu Markov, 21,0M là phép chiếu trạng thái ẩn, và 6,4k là các lớp chuẩn hóa cộng với một đầu độ tin cậy

• Backbone — 4 lớp attention đầy đủ, kích thước ẩn 2.048, kích thước trung gian 6.144 với SiLU/SwiGLU, grouped-query attention với 32 đầu attention và 8 đầu key-value, kích thước đầu 64

• Các head bổ sung — một head Markov ở rank 256 và một head độ tin cậy, đây chính là điều phân biệt DSpark drafting với một drafter song song thông thường

• Kích thước khối — 9 trong quá trình huấn luyện; 8 hoặc 9 khi suy luận tùy thuộc vào phần cứng, và cụ thể là 8 trên Apple silicon

• Từ vựng — 128.000, gắn với bản đích thay vì được bản nháp mang theo

• Trọng số trong stack được triển khai — Liquid cho biết drafter làm tăng số lượng tham số được triển khai thêm 8,9%

8,9% là con số cần bám lấy. Lời chào hàng cho lớp mô hình này chưa bao giờ là "suy luận nhanh hơn là miễn phí"; mà là "suy luận nhanh hơn khiến bạn tốn khoảng một phần mười lượng bộ nhớ của một mô hình." Với 279,5M tham số tăng thêm trên nền một mô hình đích 3,1B, đó là một khoản thuế nhỏ hơn mức mà chỉ kích thước của mô hình nháp sẽ gợi ra, bởi vì embedding và LM head được gắn với mô hình đích và không bị nhân bản.

DSpark là một kỹ thuật của DeepSeek trước khi nó là một mô hình Liquid

Cách đặt tên này dễ gây nhầm lẫn, nên cần nói cho thật chính xác. DSpark không phải là phát minh của Liquid AI và cũng không phải một họ mô hình. Nó là một khung giải mã suy đoán đến từ một hướng nghiên cứu riêng, được mô tả trong một bài báo tháng 7 năm 2026 là giải mã suy đoán theo lịch độ tin cậy với sinh bán tự hồi quy. Ba ý tưởng của nó: một xương sống song song phác thảo cả một khối trong một lượt truyền xuôi, một mô-đun tuần tự nhẹ khôi phục phần nào sự phụ thuộc giữa các token nháp lân cận để tỷ lệ chấp nhận không sụp đổ ở cuối khối, và một bộ xác minh rút ngắn cửa sổ xác minh cho mỗi yêu cầu khi độ tin cậy của chính bản nháp cho thấy phần đuôi sẽ bị từ chối.

Điều Liquid đã làm là áp dụng công thức đó cho các mô hình thị giác-ngôn ngữ và phát hành một checkpoint. Thẻ mô hình nói thẳng rằng việc chuyển giao này không ngoạn mục như nghe có vẻ: từ góc nhìn của mô hình nháp, phương thức không hề quan trọng, vì vào lúc token đi đến các lớp ẩn, một patch ảnh và một token văn bản đều chỉ là tensor. Đó là lý do một kỹ thuật được phát triển trên các mô hình văn bản có thể chuyển sang VLM mà không cần phải phát minh lại — và cũng là lý do mô hình nháp không thể được bán như một năng lực mới.

Liquid đã phát hành các drafter văn bản DSpark từ trước — các bản companion 2.6B, 8B-A1B và 1.2B-Instruct đã được đăng tải vào tháng 8 năm 2026, với các bản xuất GGUF theo sau vào ngày 19 tháng 8. Drafter thị giác là cùng ý tưởng được mở rộng sang nhánh đa phương thức, và là mục thứ tư hoặc thứ năm trong một dòng, chứ không phải một màn ra mắt.

Các con số tăng tốc, và ai đã đo chúng

Mọi số liệu dưới đây đều là của chính Liquid, được thu thập trên hạ tầng đánh giá hiệu năng của Liquid, và không có số liệu nào được tái lập độc lập. Hãy coi chúng là mức trần của nhà cung cấp, chứ không phải kết quả kỳ vọng. Thẻ này tách mức tăng tốc giải mã khỏi mức tăng tốc đầu-cuối, điều quan trọng hơn con số tiêu đề.

• Tăng tốc giải mã tốt nhất — 3.13× trên COCO, được đo bằng MLX-VLM trên Apple M5 Max ở kích thước khối 8, FP16, kích thước lô 1, nhiệt độ 0

• Mức tăng tốc giải mã GPU tốt nhất — 2,66× trên COCO, SGLang trên một H100 80GB, BF16, kích thước khối 9

• Tăng tốc giải mã llama.cpp tốt nhất — 2.14× trên COCO, Apple M3 Ultra, kích thước block 8

• Dải giải mã H100 trên sáu tác vụ thị giác — từ 2,04× đến 2,66×, với end-to-end ở mức 1,64× đến 2,27×

• Dải giải mã M5 Max — từ 2,30× đến 3,13×, từ đầu đến cuối từ 1,56× đến 2,62×

• Dải giải mã M3 — 1,57× đến 2,14×, từ đầu đến cuối 1,30× đến 1,77×

• Mức chấp nhận bản nháp — khoảng 3,2 đến 4,5 token được chấp nhận cho mỗi lượt xác minh mục tiêu, trên cả ba ngăn xếp

Quy luật trong các khoảng đó chính là phần trung thực. Mức tăng end-to-end luôn là nửa nhỏ hơn trong mỗi cặp, vì drafter tăng tốc việc giải mã chứ không gì khác. Cũng lưu ý rằng cùng một drafter ở cùng kích thước block đạt 3,13× trên một stack và 1,57× trên một stack khác — tỷ lệ chấp nhận là thuộc tính của drafter và khối lượng công việc, nhưng mức tăng thời gian thực là thuộc tính của phần cứng và độ phụ trội của runtime. Một tuyên bố "nhanh hơn 2,66×" mà không gắn với stack nào không phải là tuyên bố bạn có thể hành động dựa trên đó.

Hai điểm đúng đắn từ thẻ đáng được nói rõ, vì chúng chính là điều khiến một bộ dự thảo trở nên chấp nhận được trong sản xuất xét cho cùng. Trong giải mã tham lam, giải mã suy đoán là chính xác: mô hình đích xác minh mọi token được đề xuất, nên văn bản đúng bằng những gì mô hình đích sẽ tạo ra nếu đứng một mình. Trong các thiết lập lấy mẫu khớp ở nhiệt độ khác 0, nó bảo toàn phân phối đầu ra của mô hình đích. Cách diễn đạt của Liquid — bạn nhận được tốc độ nhanh hơn, chứ không phải một mô hình khác — là chính xác trong phạm vi nó nói tới, và thẻ trung thực rằng việc tăng nhiệt độ làm giảm tỷ lệ chấp nhận và do đó bào mòn lợi ích thông lượng.

Điều mà bài đăng của chính Liquid thừa nhận

Bài đăng blog ngày 24 tháng 9 hữu ích hơn thẻ mô hình vì một lý do: nó gọi tên giới hạn. Suy luận thị giác-ngôn ngữ phải trả một chi phí prefill mà suy luận văn bản không có — hình ảnh phải đi qua một bộ mã hóa thị giác, và sau đó xương sống ngôn ngữ phải xử lý hàng trăm token thị giác do bộ mã hóa đó tạo ra. Trên một thiết bị, prefill này chi phối độ trễ đầu-cuối. Giải mã suy đoán chỉ tăng tốc được phần giải mã. Phần thị giác và prefill vẫn không được đụng đến. Nó viện đến định luật Amdahl để chống lại chính sản phẩm của mình và chỉ ra rằng khi prefill chiếm phần lớn thời gian thực tế, một mức tăng tốc giải mã lớn chỉ đem lại cải thiện đầu-cuối khiêm tốn.

Đó là một ràng buộc thực sự đối với quyết định mua, và nó giải thích vì sao thời gian đến token đầu tiên không nằm trong danh sách những thứ mà bộ dự thảo này cải thiện. Nó cũng ngụ ý rằng những khối lượng công việc hưởng lợi nhiều nhất là những khối lượng tạo ra đầu ra dài từ một hình ảnh khiêm tốn — một chú thích, một bản chép OCR dài, một cuộc hội thoại nhiều lượt với một hình ảnh được mang theo xuyên suốt — chứ không phải những khối lượng trả lời một câu hỏi ngắn về một hình ảnh lớn.

Bài đăng bổ sung thêm hai giới hạn phạm vi. Tất cả các con số đều sử dụng xử lý 16-bit cho cả bộ mã hóa thị giác và phần xương sống ngôn ngữ, và việc tăng tốc các mô hình lượng tử hóa nằm ngoài phạm vi của bản phát hành này. Xét rằng toàn bộ điểm bán hàng của một VLM biên 3B là chạy trong vài gigabyte, “các tốc độ tăng được đo ở FP16” là một lưu ý quan trọng đối với bất kỳ ai dự định kết hợp nó với bản xuất 4-bit. Liquid cũng lưu ý rằng bộ dự thảo đã được huấn luyện hoàn toàn trên phần cứng AMD.

Đang chạy nó

Hỗ trợ ngay từ ngày đầu là có thật và bao trùm ba runtime, nhiều hơn mức mà hầu hết các drafter nhận được. SGLang trên NVIDIA yêu cầu v0.5.19 trở lên và đưa drafter đi qua --speculative-algorithm DSPARK cùng với draft path và block size là 9. MLX-VLM trên Apple silicon yêu cầu v0.7.2 trở lên và tự phát hiện drafter khi nó được truyền kèm --draft-model; có một điểm cần đặc biệt lưu ý — giải mã DSpark trong MLX-VLM hiện dùng greedy sampling, nên temperature phải được đặt bằng 0. Với llama.cpp thì có một repository GGUF riêng, với một bản export F16 duy nhất khoảng 567 MB, và model card nói rõ rằng bạn nên ghép drafter đã lượng tử hóa với target đã lượng tử hóa, chứ không phải với checkpoint safetensors gốc.

Điểm mà một lớp định tuyến thực sự chứng minh được giá trị của nó ở đây không nằm ở mô hình này — OrcaRouter không định tuyến LFM2.5-VL-3B-DSpark hay LFM2.5-VL-3B, và đây là một cặp drafter tự lưu trữ mà bạn tự tải về và tự vận hành. Mà nằm ở phần còn lại của ngăn xếp xung quanh nó. Cùng một ứng dụng chạy một mô hình thị giác trọng số mở nhỏ ngay trên thiết bị thường có một đường dự phòng cho những truy vấn mà mô hình nhỏ không thể xử lý, và việc hướng đường đó tới một endpoint duy nhất bao phủ hơn 200 mô hình — tính phí theo giá niêm yết của từng nhà cung cấp, không cộng thêm phụ phí, với tính năng chuyển đổi dự phòng tự động khi một nhà cung cấp gặp sự cố — là một tích hợp nhỏ hơn so với việc dựng lên một hợp đồng nhà cung cấp thứ hai. Drafter cải thiện một chân của kiến trúc đó; router chính là thứ giữ cho chân còn lại không biến thành một dự án thứ hai.

Điều gì vẫn chưa được biết

Tại thời điểm viết bài, kho lưu trữ có 37 lượt tải xuống và 6 lượt thích. Không có mục nào cho drafter này trên bất kỳ trang tổng hợp benchmark công khai nào, không có bản tái tạo nào từ bên thứ ba đối với bất kỳ phạm vi tăng tốc nào, và cũng không có đo lường độc lập nào về tỷ lệ chấp nhận trên phần cứng mà Liquid chưa kiểm thử. Ngoài ra cũng không có benchmark chất lượng nào trên card vì những lý do hiển nhiên — drafter này bảo toàn đầu ra theo thiết kế, nên các con số chất lượng thuộc về LFM2.5-VL-3B, và card trỏ đến benchmark của mô hình đó thay vì tự tạo ra benchmark riêng.

Một chi tiết trong metadata là một dấu hiệu nhỏ cho thấy điều này mới đến mức nào: mô hình mang một thẻ thư viện SGLang và một cờ thuật toán SGLang tồn tại đặc biệt để gọi nó. Hỗ trợ framework phải được đưa vào trước khi thông báo được đăng, điều này nhất quán với khoảng cách sáu ngày giữa repository và bài đăng blog.

Vậy thì: một sản phẩm kỹ thuật chân thực, hữu ích và có phạm vi hẹp, được công bố một tuần sau khi ra mắt, với toàn bộ giá trị đề xuất nằm ở một con số do nhà cung cấp đo trên phần cứng mà bạn có thể không sở hữu. Nếu bạn đang chạy LFM2.5-VL-3B trên H100 hoặc Mac dòng M và khối lượng công việc của bạn nặng về giải mã, thì chi phí bộ nhớ là 8,9% và nhược điểm gần như bằng không vì đầu ra chứng minh được là của mô hình mục tiêu. Nếu độ trễ của bạn bị chi phối bởi prefill, hoặc bạn đang trông cậy vào bản xuất 4-bit, thì bài đăng của chính Liquid cho bạn biết nó sẽ không giúp ích gì. Bản tái lập, khi nó xuất hiện, là thứ đáng để chờ đợi.

OrcaRouter đưa hơn 200 mô hình vào sau một khóa duy nhất với đúng giá niêm yết của nhà cung cấp, mức markup 0%, và thể hiện đường dự phòng dưới dạng một lớp định tuyến thay vì mã ứng dụng. Dù theo cách nào thì mô hình nháp vẫn được tự vận hành - chính bộ định tuyến là thứ giữ cho chặng mà mô hình nhỏ của bạn chuyển tiếp sang không biến thành một dự án thứ hai.