LFM3-1.7B trên vLLM: Chín ngày đã trôi qua, hỗ trợ native vẫn chỉ là hai PR đang mở

Liquid AILFM3-1.7B vào ngày 27 tháng 10 năm 2026 với một model card in ra lệnh vllm serve "LiquidAI/LFM3-1.7B" như thể đó là một lệnh thông thường. Chín ngày sau, vLLM thượng nguồn không có kiến trúc Lfm3ForCausalLM nào để chạy nó. Thay vào đó, những gì tồn tại là một yêu cầu tính năng được mở ngày 30 tháng 10, một pull request kernel mà mọi thứ khác đều được xếp chồng lên, và sáu PR mô hình đang mở — hai trong số đó triển khai cùng một mô hình văn bản LFM3-1.7B theo hai cách khác nhau, và cả hai đều chưa được hợp nhất.

Khoảng trống đó chính là toàn bộ câu chuyện ở đây, và đó là một khoảng trống hẹp. Mô hình là thật và có thể tải xuống; còn hỗ trợ runtime thì vẫn đang xếp hàng. Đây là bài tổng hợp những gì chúng ta biết đến nay về hàng đợi đó: những gì đang được triển khai, những gì thực sự chạy được hôm nay, và những gì sẽ phải thành hiện thực trước khi "works with vLLM" trên thẻ mô hình trở thành đúng theo nghĩa mà một kế hoạch triển khai cần.

Thẻ ghi vLLM. Bảng các mô hình được hỗ trợ ghi LFM2.

Tài liệu về các mô hình được hỗ trợ của chính vLLM liệt kê ba kiến trúc của Liquid AI: Lfm2ForCausalLM, Lfm2MoeForCausalLM và Lfm2VlForConditionalGeneration. Không có mục LFM3 nào. Trong khi đó, thẻ LFM3-1.7B nêu rằng checkpoint này "hoạt động với vLLM, SGLang và các bản build llama.cpp tương thích LFM3" và đưa ra một lệnh serving không kèm cờ nào.

Sự dung hòa nằm trong cấu hình của chính checkpoint. LFM3-1.7B mang một auto_map trỏ tới modeling_lfm3.py đi kèm, nên mã phía Hugging Face tồn tại và tự sao chép vào các loader cho phép mã từ xa. Issue theo dõi việc port của vLLM, #64645 — "[Feature]: Support LiquidAI LFM3 models", được mở ngày 30 tháng 10 bởi abhijithneilabraham — nói thẳng về hệ quả: "vLLM không có Lfm3ForCausalLM." Phương án thay thế được liệt kê là lối thoát mà hầu hết mọi người sẽ dùng trong tháng này: "Chạy LFM3 thông qua mã từ xa của checkpoint với backend Transformers. Điều đó từ bỏ paged attention và bộ nhớ đệm trạng thái conv."

Sự đánh đổi đó đáng được nói rõ, vì "chạy trên vLLM" và "chạy trên backend transformers của vLLM" là hai sản phẩm khác nhau. Paged attention là cơ chế cho phép vLLM gom lô các yêu cầu có độ dài rất khác nhau mà không lãng phí bộ nhớ KV; bộ đệm trạng thái tích chập là cùng ý tưởng đó được áp dụng cho các lớp tích chập ngắn của kiến trúc này. Bỏ cả hai đi thì bạn có một endpoint vẫn hoạt động nhưng đã từ bỏ hai lý do vLLM tồn tại. Với một mô hình 1.7B được phục vụ ở mức đồng thời thấp, đó có thể là một cuối tuần chấp nhận được, chứ không phải một cấu hình production chấp nhận được.

Tại sao một mô hình 1.7B lại cần đến công việc kernel chứ?

LFM3-1.7B không phải là một bản tinh chỉnh lại đơn giản của dòng LFM2 mà vLLM đã phục vụ. Đây là một mô hình lai hai mươi bốn lớp với ba loại lớp thay vì hai: 13 lớp tích chập ngắn có cổng, 5 lớp attention cửa sổ trượt với cửa sổ 256 token và 6 lớp attention đầy đủ. Config của checkpoint mô tả rõ cấu trúc hình học — conv_L_cache: 7, sliding_window: 256, từ vựng 128K — và danh sách khác biệt của chính issue vLLM bổ sung thêm QK RMSNorm, cổng đầu ra attention sigmoid theo từng head, chuẩn hóa sandwich và RoPE một phần (partial_rotary_factor: 0.5) trên các lớp attention đầy đủ, được bố trí theo cùng dạng zero-tail mà Gemma 4 sử dụng.

Con số làm hỏng bản port là số bảy. Tích chập ngắn của LFM2 rộng ba tap; LFM3 đã mở rộng nó lên bảy. Các kernel Triton causal_conv1d của vLLM triển khai vòng lặp cho một tập độ rộng cố định, và như issue theo dõi đã nêu: "Kernel prefill Triton causal_conv1d triển khai vòng lặp cho các độ rộng từ 2 đến 4 và kernel decode từ 2 đến 6, nên một mô hình độ rộng 7 hiện không thể chạy trên CUDA."

Vậy PR đầu tiên trong chuỗi PR hoàn toàn không phải là một mô hình. #64647, "[Kernel] Hỗ trợ causal conv1d độ rộng 7", được mở ngày 30 tháng 10 bởi abhijithneilabraham, chạm tới hai tệp và 186 dòng được thêm: nó mở rộng kernel prefill từ độ rộng 2–4 lên 2–7 và kernel decode từ 2–6 lên 2–7, đồng thời khiến cả hai wrapper ném ValueError cho bất kỳ giá trị nào ngoài phạm vi đó. Phần mô tả của chính PR giải thích vì sao việc từ chối quan trọng không kém việc mở rộng: trước thay đổi, "một trọng số rộng hơn chạy mà không có nhánh khớp và trả về giá trị sai." Sai lệch số âm thầm là lỗi tệ hơn việc từ chối, và đó là kiểu vấn đề chỉ xuất hiện trên mô hình mà bạn tình cờ thử.

Một lưu ý cần đi kèm với PR đó. Tác giả của nó nói thẳng rằng họ không có máy CUDA: đường tham chiếu CPU vượt qua 96 bài kiểm tra, các kernel Triton đã được kiểm tra bằng phân tích tĩnh trên AST của kernel, và việc xác thực GPU được để cho CI. Đó là một tiết lộ trung thực chứ không phải là một khiếm khuyết, nhưng điều đó có nghĩa là thay đổi duy nhất mà mọi PR LFM3 khác phụ thuộc vào vẫn chưa được chạy thử trên phần cứng mà hầu hết độc giả sẽ chạy nó.

Hai cách triển khai của cùng một mô hình văn bản

Trong vòng sáu ngày, hai nhóm riêng biệt đã viết hỗ trợ LFM3 gốc cho vLLM. Chúng không phải là các biến thể của cùng một bản vá; chúng là những thiết kế độc lập mà tình cờ cài đặt cùng một tên kiến trúc.

PR #64959, "[Model] Add LiquidAI LFM3 (Lfm3ForCausalLM)", được mở ngày 1 tháng 11 bởi atmikshetty, là phương án thận trọng: bảy tệp, và theo mô tả của chính nó, tái sử dụng ShortConv ở độ rộng 7, Lfm2MLP, bộ ánh xạ trọng số LFM2 và RoPE tỷ lệ hiện có, không thay đổi thành phần lõi nào. Nó đăng ký mô hình trong registry, thêm mô hình vào bộ kiểm thử mô hình lai và bảng mô hình được hỗ trợ, và — hữu ích cho bất kỳ ai chạy được nó — ghi lại các cờ phục vụ mà nó đã xác thực: --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice. Phần xác thực của nó báo cáo 324 bài kiểm thử kernel đạt trên A100-SXM4-40GB ở BF16, các bài kiểm thử registry và khởi tạo đạt, cùng so sánh log-probability với tham chiếu remote-code của Hugging Face.

PR #65826, "[Model] Add LFM3-Text", được mở vào ngày 5 tháng 11 bởi paulpak58 — người thuộc Liquid AI — là phiên bản của chính nhà cung cấp: mười tệp và 829 dòng được thêm, bao gồm lớp config riêng của nó trong transformers_utils/configs/lfm3.py và mô-đun kiểm thử riêng. Nó được mở dưới tên "[Model] Add LFM3" và được đổi tiêu đề cùng ngày khi dòng mô hình này được tách thành bốn PR xếp chồng: #65826 cho văn bản, #65827 cho ngôn ngữ - thị giác, #65828 cho âm thanh và #65829 cho omni, mỗi PR được xây dựng dựa trên PR trước đó.

Hai việc này không hẳn xung đột mà đúng hơn là song song, và cuộc thảo luận cho thấy rõ mạng lưới phụ thuộc. Trên PR của kernel, paulpak58 viết ngày 4 tháng 11: "Chúng tôi có các PR nội bộ riêng cho các mô hình LFM3, nhưng đây là một bổ sung gọn gàng mà chúng tôi có thể hậu thuẫn." Trên PR văn bản của cộng đồng, abhijithneilabraham gợi ý rằng việc hợp nhất có thể cần phần việc transformers của Liquid được hợp nhất trước — "Tôi tin rằng việc hợp nhất PR này cần PR transformers từ @paulpak58" — và atmikshetty trả lời rằng Lfm3Config chưa có trong bản phát hành transformers nào, nên nhánh này "tải cấu hình qua trust_remote_code từ checkpoint, và việc thực thi dùng mô hình vLLM gốc." Đó là rào cản thứ hai mà hầu hết độc giả sẽ không nghĩ tới: ngay cả một PR vLLM đã được hợp nhất vẫn cần một lớp cấu hình được phát hành ở đâu đó.

Về phía transformers, PR tương đương là #50322, "[Model] LFM3 Family: LFM3-Text", được mở ngày 3 tháng 11 và vẫn đang mở, được tách ra từ một PR họ mô hình lớn hơn. Ghi chú của chính PR đó về tích chập khớp với issue của vLLM: conv ngắn là "chỉ dùng torch trong LFM3 (các kernel causal_conv1d trên Hub phục vụ độ rộng 2-4, LFM3 dùng 7)".

Vision-language cũng đang bị trùng lặp. Ngoài #65827 của Liquid, một PR LFM3-VL độc lập (#65450, mở ngày 3 tháng 11) vẫn còn mở và phụ thuộc vào PR văn bản của cộng đồng. Như vậy, tính đến hôm nay, có sáu PR LFM3 đang mở thuộc hai phe, và chưa có PR nào được hợp nhất.

Hôm nay thực sự có gì đang chạy?

Gạt bỏ những suy đoán sang một bên, bức tranh thực tế vào ngày 5 tháng 11 trông như thế này.

• vLLM, bản gốc — không khả thi trên một bản build tiêu chuẩn. Không có Lfm3ForCausalLM trong registry, không có dòng LFM3 nào trong bảng các mô hình được hỗ trợ, và PR để bổ sung nó vẫn chưa được hợp nhất.

• vLLM, backend transformers — cách xử lý được tài liệu hóa, sử dụng mã từ xa đi kèm của checkpoint và trust_remote_code. Bạn mất paged attention và bộ nhớ đệm trạng thái conv; bạn vẫn giữ máy chủ tương thích OpenAI.

• SGLang — đường dẫn máy chủ riêng của nhà cung cấp. Bài đăng ra mắt của Liquid đo các con số thông lượng trên một NVIDIA B300 duy nhất ở BF16 với SGLang, bao gồm 3,6 tỷ token mỗi ngày ở 1.024 yêu cầu đồng thời. vLLM chỉ xuất hiện trong bài đăng đó với tư cách là runtime mà các mô hình cạnh tranh được phục vụ trên đó.

• llama.cpp — thẻ này đề cập đến "các bản dựng llama.cpp tương thích LFM3", đây là một điều kiện thực sự chứ không phải câu rập khuôn; các con số trên thiết bị của Liquid là llama.cpp ở Q4_0 với ngữ cảnh 32K.

• MLX — ghi chú phát hành 0.33.0 của dự án vLLM-Metal riêng biệt có liệt kê các checkpoint MLX văn bản LFM3, đằng sau cờ --trust-remote-code. Đó là một cơ sở mã khác với vLLM gốc và không ngụ ý hỗ trợ CUDA.

• Dịch vụ lưu trữ — API và playground của chính Liquid. Thẻ này không cung cấp bảng giá, vì vậy chi phí mỗi token không phải là điều bạn có thể lập ngân sách từ tài liệu công khai.

Hai con số giúp nhìn rõ hơn trường hợp tự triển khai. Trọng số đủ nhỏ để bộ nhớ không phải là ràng buộc — Liquid cho biết khoảng 1 GB ở 4-bit — và nhà cung cấp nói rằng ngữ cảnh 128K token tốn khoảng 1,6 GB KV cache. Ràng buộc nằm ở ngăn xếp phục vụ, không phải GPU.

Điều gì sẽ thay đổi điều này, theo thứ tự

Chuỗi phụ thuộc này sạch một cách bất thường, khiến thứ đáng theo dõi trở nên cụ thể một cách bất thường. Đầu tiên #64647 phải được merge, vì mọi PR LFM3 khác hoặc bao gồm commit đó hoặc được xếp chồng lên nó. Sau đó, một trong hai PR văn bản phải thắng vòng review — bản của cộng đồng có hồ sơ kiểm chứng đầy đủ hơn, bản của Liquid có tác giả đồng thời phụ trách phía transformers. Tiếp theo, Lfm3Config phải được đưa vào một bản phát hành transformers, nếu không mọi triển khai sẽ tiếp tục phải truyền trust_remote_code. Chỉ sau đó LFM3-VL-2B, LFM3-Audio-2B và LFM3-Omni-2B mới trở nên khả thi, và chúng còn nằm sau các PR tiếp theo vốn giả định mô hình văn bản đã được đưa vào.

Không điều nào trong số này nên bị hiểu là lời chỉ trích về tốc độ. Chín ngày từ lúc ra mắt đến một chồng PR gồm kernel và model hoàn chỉnh, đã được kiểm thử là nhanh, và việc hai nhóm độc lập tạo ra các bản triển khai hoạt động được trong chưa đầy một tuần nói lên nhiều hơn về mức độ gần nhau giữa LFM3 và LFM2 so với bất kỳ sự chậm trễ nào. Nhưng model card là một tuyên bố về khả năng tương thích, và cách đọc trung thực về LFM3-1.7B hôm nay là “tương thích với vLLM thông qua backend transformers”, chứ không phải “được vLLM hỗ trợ”.

Nếu tuần này bạn cần một mô hình nhỏ có khả năng gọi công cụ

LFM3-1.7B là một thứ hấp dẫn đáng để ao ước. Các con số do nhà cung cấp báo cáo đều mạnh đúng ở những chỗ mà các mô hình nhỏ thường thất bại — 71,39 trên BFCL V4, 80,36 trên ToolSandbox, 96,66 trên IFEval, 43,40 trên SWE-bench Verified — so với mức trung bình tổng thể 49,37 mà Liquid đặt cao hơn cả LFM2.5-2.6B của chính họ ở mức 31,55. Đó là các đánh giá của chính nhà cung cấp, do công ty đã xây dựng mô hình thực hiện, không có tái lập độc lập và không có mục Artificial Analysis nào mà chúng tôi tìm thấy tính đến hôm nay; hãy coi thứ tự xếp hạng là một giả thuyết và từng con số riêng lẻ là những tuyên bố. Lời cảnh báo đi kèm cũng đến từ cùng nguồn: thẻ mô hình khuyến nghị không nên dùng cho lập trình tác tử và suy luận đa bước phức tạp, và các benchmark kiến thức cũng đồng tình với khuyến nghị đó — 63,37 trên GPQA Diamond và 65,56 trên RULER ở 128K không phải là những con số của một mô hình đa dụng.

Vậy nên quyết định không thực sự nằm ở mô hình. Mà ở việc liệu bạn có đủ khả năng xây dựng trên một đường phục vụ hiện đang là một pull request mở hay không. Nếu bạn có thể chạy SGLang hoặc llama.cpp, bạn có thể dùng LFM3-1.7B ngay hôm nay và câu hỏi về vLLM chỉ là chuyện lý thuyết. Nếu stack của bạn bắt buộc phải dùng vLLM theo chính sách, bạn đang phải chọn giữa việc backend transformers thiếu paged attention và việc chờ đợi.

Có một lựa chọn thứ ba đáng để gọi tên cho những khối lượng công việc không thể chờ đợi: định tuyến một thứ khác. OrcaRouter không có LFM3-1.7B — việc kiểm tra danh mục của chúng tôi hôm nay trả về hơn 200 ID mô hình và không có cái nào là của Liquid — vì vậy đây không phải là lời chào mời gọi nó qua chúng tôi. Điểm đơn giản hơn là một PR kernel chưa được hợp nhất là một điểm lỗi đơn lẻ tồi tệ cho một đường dẫn sản xuất. Đặt một mô hình được lưu trữ phía sau một API và tự động chuyển đổi dự phòng chỉ tốn của bạn một thay đổi cấu hình, và cho phép bạn thay bằng LFM3-1.7B vào ngày hỗ trợ gốc của nó được hợp nhất thay vì ngày bạn đặt cược xong vào nó. Nếu bạn đang sửa đổi mô hình thay vì chỉ gọi nó, bản phát hành của riêng chúng tôi LFM3-1.7B-abliterated là một ablation theo hướng từ chối của cùng checkpoint đó, và nó thừa hưởng chính xác tình huống phục vụ này.

Bản tóm tắt ngắn gọn

LFM3-1.7B đã ra mắt, nhỏ, và rất phù hợp với các công việc gọi công cụ một lượt mà nó được huấn luyện. Hỗ trợ vLLM của nó đang được viết ngay lúc này, bởi hai nhóm, dựa trên một tiện ích mở rộng kernel mà người viết ra nó chưa từng chạy trên CUDA. Hãy theo dõi #64647 trước — khi phép tích chập độ rộng 7 được hợp nhất, phần còn lại của ngăn xếp sẽ tiến triển nhanh, và "hoạt động với vLLM" trên thẻ mô hình sẽ không còn là tuyên bố về mã từ xa mà bắt đầu là tuyên bố về paged attention và batching. Cho đến lúc đó, bất kỳ ai trích dẫn "hỗ trợ vLLM ngay ngày đầu" cho mô hình này đều đang trích dẫn thứ mà kho lưu trữ chưa có.