LFM2.5-VL-3B-DSpark vs LFM2.5-VL-3B: Bạn không chọn một cái, mà gắn một cái

Tìm kiếm đưa mọi người đến đây là một sự so sánh, nhưng câu trả lời trung thực là LFM2.5-VL-3B-DSpark và LFM2.5-VL-3B không phải là hai thứ để bạn lựa chọn giữa chúng. Mô hình thứ hai là một mô hình thị giác-ngôn ngữ 3.1B mà bạn có thể tải về và phục vụ. Mô hình thứ nhất là một mô hình nháp 279.5M tham số, chỉ tồn tại để đứng trước mô hình thứ hai và giúp nó giải mã nhanh hơn. Rút mô hình nháp ra khỏi ngăn xếp thì nó chẳng tạo ra gì cả; bạn không thể đánh giá riêng nó, bởi vì "một mình" không phải là một cấu hình mà nó hỗ trợ. So sánh thực sự là LFM2.5-VL-3B chạy một mình so với cùng mô hình đó chạy với mô hình nháp được gắn kèm.

Đọc theo cách đó thì quyết định thu gọn lại thành một câu hỏi: liệu bộ nhớ tăng thêm và độ phức tạp runtime tăng thêm có đem lại cho bạn đủ độ trễ để có ý nghĩa với khối lượng công việc của bạn không? Số liệu của chính Liquid AI nói có cho công việc nặng về decode và nói rõ là không khi prefill chiếm ưu thế. Không bên nào trong số đó đã được tái lập bên ngoài công ty.

Hai trạm kiểm soát, nằm cạnh nhau

Điều khác biệt giữa chúng mới là toàn bộ câu chuyện, nên đáng để đặt hai kho lưu trữ cạnh nhau trước khi cuộc tranh luận về tốc độ bắt đầu.

• Vai trò — LFM2.5-VL-3B tạo văn bản và trả lời về hình ảnh; LFM2.5-VL-3B-DSpark đề xuất token để nó xác minh và tự nó không tạo ra gì dùng được

• Tham số — 3,1B cho mô hình đích, 279,5M BF16 cho mô hình nháp, mà Liquid cho là mức tăng 8,9% đối với số tham số được triển khai

• Kiến trúc — mục tiêu là một mô hình lai được xây dựng trên backbone LFM2.5-2.6B với bộ mã hóa thị giác SigLIP2 NaFlex; drafter gồm 4 lớp attention đầy đủ ở kích thước ẩn 2.048 với grouped-query attention cùng một Markov head và một confidence head

• Cửa sổ ngữ cảnh — 32.768 token cho mục tiêu; trình soạn nháp không mang ngữ cảnh riêng và kế thừa ngữ cảnh của mục tiêu

• Bộ mã hóa thị giác — SigLIP2 NaFlex 400M trên mô hình đích; mô hình nháp không có bộ này và không bao giờ nhìn thấy hình ảnh trực tiếp

• Từ vựng — 128.000, và embedding cùng LM head của drafter được gắn với mô hình đích thay vì bị nhân bản, đó là lý do vì sao chi phí bộ nhớ nhỏ hơn mức mà 279,5 triệu tham số sẽ gợi ý

• Giấy phép — cả hai đều được phát hành theo giấy phép LFM1.0 của Liquid, được xếp là "other" trên Hugging Face chứ không phải giấy phép OSI, vì vậy hãy đọc các điều khoản trước khi triển khai thương mại

• Định dạng — mô hình đích được phát hành dưới dạng các bản lượng tử hóa safetensors, GGUF, ONNX và MLX; mô hình nháp được phát hành dưới dạng safetensors và một GGUF F16 duy nhất khoảng 567 MB

Một dòng trong danh sách đó đáng được nhấn mạnh vì đó chính là lý do mang tính cơ học khiến sự kết hợp này có thể hoạt động ngay từ đầu: bộ dự thảo không phải là một mô hình thị giác nhỏ. Nó không có bộ mã hóa thị giác và không bao giờ chạm vào hình ảnh. Khi các token đi đến những lớp ẩn mà từ đó nó dự thảo, một mảnh ảnh và một token văn bản đều chỉ là tensor, nên phương thức trở nên vô hình đối với phép tính dự thảo. Đó là điều đã cho phép Liquid chuyển một kỹ thuật được phát triển cho các mô hình văn bản sang một VLM mà không cần thiết kế lại nó.

Những gì người soạn thảo thay đổi, và những gì nó giữ nguyên

Mô hình đích không thay đổi. Đó không phải là chiêu tiếp thị — mà là tính chất đảm bảo tính đúng đắn của giải mã suy đoán. Trong giải mã tham lam, mọi token nháp đều được mô hình đích kiểm chứng, nên đầu ra đúng chính xác như khi chỉ mình mô hình đích tạo ra. Với các thiết lập lấy mẫu khớp nhau ở nhiệt độ khác không, phân phối đầu ra khớp với phân phối của mô hình đích. Bộ phác thảo đánh đổi bộ nhớ lấy thời gian và không đụng đến bất cứ thứ gì khác.

Điều đó có nghĩa là mọi chỉ số chất lượng bạn có thể tìm thấy cho LFM2.5-VL-3B đều áp dụng nguyên vẹn cho cấu hình được ghép cặp. Theo đánh giá của chính Liquid, mô hình đích đạt 80.7 trên ScreenSpot-v2, 61.5 trên BLINK, 58.3 trên MuirBench, 73.1 trên MME, 63.3 trên MMStar, 81.3 trên ChartQA và 88.7 trên POPE — tất cả đều do nhà cung cấp báo cáo, không có chỉ số nào được tái lập độc lập, và tất cả đều đúng như nhau bất kể có gắn drafter hay không. Ở đây không có sự đánh đổi giữa chất lượng và tốc độ để cân nhắc, và bất kỳ trang so sánh nào thể hiện một sự đánh đổi như vậy đều đã hiểu sai về mô hình.

Điều thay đổi là chi phí của một token tính theo thời gian thực. Liquid đo được mức tăng tốc giải mã từ 2,04× đến 2,66× trên một H100 trong BF16 thông qua SGLang ở kích thước khối 9, từ 2,30× đến 3,13× trên Apple M5 Max thông qua MLX-VLM ở kích thước khối 8, và từ 1,57× đến 2,14× trên M3 Ultra thông qua llama.cpp. Xét đầu-cuối, chính những lượt chạy đó đạt mức 1,64×–2,27×, 1,56×–2,62× và 1,30×–1,77× tương ứng. Những cặp số đó chính là toàn bộ lập luận: giải mã cải thiện gần gấp đôi so với đầu-cuối, và khoảng cách đó chính là phần khối lượng công việc mà drafter không thể chạm tới.

Vấn đề prefill, do nhà cung cấp nêu ra

Câu hữu ích nhất trong chính thông báo của Liquid là câu lập luận chống lại cách hiểu vô hạn về tiêu đề của 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 đi qua một bộ mã hóa thị giác, và sau đó phần xương sống ngôn ngữ xử lý hàng trăm token thị giác mà bộ mã hóa đó phát ra. Trên một thiết bị biên, prefill đó chiếm một tỷ lệ lớn trong độ trễ đầu-cuối. Giải mã suy đoán chỉ tăng tốc giai đoạn giải mã — mã hóa thị giác và prefill không thay đổi. Ở nơi prefill chiếm ưu thế, mức tăng tốc giải mã gấp 3× chuyển thành một lợi ích đầu-cuối nhỏ hơn nhiều.

Đó là định luật Amdahl được nhà cung cấp áp dụng cho chính sản phẩm của mình, và nó nên định hình việc ai sẽ đọc trang này. Một bản chép lại dài của một trang được quét duy nhất, một chú thích ảnh, một cuộc hội thoại nhiều lượt mang một hình ảnh đi xuyên suốt — nặng về giải mã, và mô hình drafter mới xứng đáng với 279,5M tham số của nó. Một câu hỏi ngắn về một hình ảnh lớn có độ phân giải cao — nặng về prefill, và nó thì không. Đặt cùng mục tiêu đó trên một máy chủ ở mức đồng thời cao thì bức tranh lại thay đổi: Liquid đo một đường biên giữa thông lượng và tính tương tác thay vì một con số đơn lẻ, và báo cáo rằng DSpark giữ được lợi thế ở mọi mức đồng thời được thử nghiệm trong khi khoảng cách thu hẹp dần khi mức đồng thời tăng lên.

Hai ghi chú phạm vi nhỏ hơn từ cùng một nguồn. Tất cả các phép đo đều dùng xử lý 16-bit cho cả bộ mã hóa thị giác lẫ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ếu kế hoạch của bạn là ghép một bản xuất mục tiêu 4-bit với drafter vì toàn bộ sức hút của một VLM 3B là vừa vặn trong vài gigabyte, thì tổ hợp đó không phải là thứ đã được đo.

Cái giá thực sự của việc gắn nó đối với bạn

Bộ nhớ là chi phí hữu hình và thẻ định lượng nó: nhiều hơn 8.9% tham số trong ngăn xếp được triển khai. Độ phức tạp thời gian chạy là chi phí vô hình. SGLang cần v0.5.19 trở lên và một dòng khởi chạy mang --speculative-algorithm DSPARK, đường dẫn mô hình nháp và kích thước khối; ví dụ của chính thẻ cũng vô hiệu hóa bộ đệm radix và ghim một phần bộ nhớ tĩnh, đây là những quyết định phục vụ mà bạn phải lý giải. MLX-VLM cần v0.7.2 trở lên và nhận mô hình nháp thông qua --draft-model, nhưng giải mã DSpark ở đó hiện đang sử dụng lấy mẫu tham lam, vì vậy nhiệt độ phải bị buộc về 0 — một ràng buộc thực sự nếu ứng dụng của bạn dựa vào sự đa dạng lấy mẫu. llama.cpp hoạt động thông qua mô hình nháp GGUF được ghép với mục tiêu GGUF, không phải với điểm kiểm tra safetensors gốc.

Còn một chi phí nữa chỉ xuất hiện trong môi trường production chứ không phải trong benchmark: mô hình nháp và mô hình đích phải đi cùng nhau. Lệch phiên bản giữa chúng là một kiểu lỗi không tồn tại trong triển khai chỉ một mô hình, và việc cuốn chiếu triển khai từng cái một cách độc lập giờ đây là bài toán hai artifact.

Đây là một cặp kết hợp tự vận hành. OrcaRouter không định tuyến LFM2.5-VL-3B hay drafter của nó — bạn tự tải cả hai về và tự phục vụ chúng — nên câu hỏi về định tuyến liên quan đến mọi thứ mà mô hình nhỏ bàn giao lại. Hầu hết các triển khai kết hợp một VLM biên 3B với drafter vẫn có những truy vấn mà mô hình nhỏ không nên trả lời, và việc gửi những truy vấn đó đến một endpoint duy nhất bao phủ hơn 200 mô hình ở mức giá niêm yết của từng nhà cung cấp, với tính năng chuyển đổi dự phòng tự động nếu một nhà cung cấp bị suy giảm, chỉ là một tích hợp thay vì mỗi nhà cung cấp phải làm một tích hợp riêng. Điều đó cũng có nghĩa là ngay khi một nhà cung cấp giảm giá, mức giá của bạn sẽ phản ánh điều đó trong cùng ngày thay vì phải đợi đến kỳ gia hạn hợp đồng tiếp theo.

Tải cái nào

Nếu khối lượng công việc của bạn thiên về giải mã và phần cứng của bạn thuộc một trong ba loại mà Liquid đã thử nghiệm, hãy gắn trình soạn nháp — nhược điểm là có giới hạn, vì đầu ra chắc chắn là của mô hình đích và chi phí bộ nhớ chưa bằng một phần mười của một mô hình. Nếu độ trễ của bạn bị chi phối bởi giai đoạn nạp trước, hoặc bạn đang chạy một mô hình đích đã lượng tử hóa, hoặc bạn phụ thuộc vào việc lấy mẫu không tham lam trong một runtime chưa gỡ bỏ hạn chế đó, hãy chạy một mình LFM2.5-VL-3B. Nó nhanh theo đúng nghĩa của nó: 228 token mỗi giây trên M5 Max, 116 trên AMD Ryzen AI Max+ 395, và 20 trên Galaxy S26 Ultra, tất cả đều là số liệu của nhà cung cấp, trong khoảng 3 GB bộ nhớ.

Điều mà chưa ai có thể nói với bạn lúc này là liệu những con số của Liquid có đứng vững trên phần cứng của bạn hay không. Tại thời điểm viết bài, drafter có 37 lượt tải xuống trên Hugging Face và không có bất kỳ bản tái lập độc lập nào cho bất kỳ số liệu nào trong các bảng của nó. Phần kỹ thuật là vững chắc và lập luận về tính đúng đắn là một chứng minh chứ không phải một lời khẳng định, nhưng độ lớn lại là một phép đo — và những phép đo từ một phòng thí nghiệm trên một bộ máy cụ thể đúng là kiểu con số bạn nên tự mình kiểm chứng trước khi đưa chúng vào một kế hoạch công suất.

OrcaRouter truy cập hơn 200 mô hình chỉ qua một khóa duy nhất, với giá niêm yết của từng nhà cung cấp được chuyển nguyên vẹn ở mức 0% markup và tự động chuyển đổi dự phòng giữa các nhà cung cấp. giá niêm yết của nhà cung cấp được chuyển nguyên vẹn ở mức 0% markup Cặp kết hợp trên trang này dù theo cách nào cũng đều là self-hosted - router dành cho mọi thứ mà mô hình nhỏ bàn giao lại, và điều đó nghĩa là khi nhà cung cấp giảm giá, mức giá của bạn sẽ thấy ngay trong cùng ngày.