Rò rỉ LFM3: Dòng sản phẩm kế tiếp của Liquid AI gồm bốn mô hình Omni nhỏ

Một pull request được mở trên GitHub vào ngày 27 tháng 10 năm 2026 muốn dạy SGLang cách phục vụ một họ mô hình không tồn tại công khai. Nó nêu tên bốn checkpoint — LFM3-1.7B, LFM3-VL-2B, LFM3-Audio-2B và LFM3-Omni-2B — và khi đặt cạnh các bản đã phát hành LFM2.5-2.6B và LFM2.5-24B-A2B, nó giống như một bản thiết kế cho thứ Liquid AI sẽ xây tiếp theo. PR chưa được hợp nhất. Cả ba kiểm tra CI của nó đều đang thất bại. Liquid AI chưa công bố bất cứ điều gì về nó. Bản diff chưa được hợp nhất đó là toàn bộ hồ sơ công khai về LFM3 tính đến hôm nay, và nó mang nhiều thông tin hơn hầu hết các bài đăng ra mắt — miễn là bạn đọc nó đúng như bản chất của nó.

Vậy hãy để chúng ta nói chính xác về bằng chứng, bởi vì nó mỏng manh theo một hướng và lại chi tiết một cách bất thường theo hướng khác. Ở đây không có gì là ngày phát hành, giá cả, điều khoản giấy phép hay điểm chuẩn đánh giá. Không có model card LFM3, không có kho lưu trữ Hugging Face, không có bài đăng blog, không có danh mục API. Thứ tồn tại là một đóng góp từ tugot17 — Piotr Mazurek, người trong hai tháng qua đã đưa hỗ trợ runtime LFM vào SGLang, llama.cpp và mlx-vlm — cùng với tài liệu do chính Liquid công bố về thế hệ LFM2.5 mà nó sắp thay thế. Mọi thứ dưới đây đều được gắn nhãn tương ứng.

Điều mà pull request thực sự đưa ra

Tiêu đề PR là [Feat] lfm3: Thêm hỗ trợ văn bản, thị giác, âm thanh và Omni, và nó mang hai nhãn cho biết đây là loại thay đổi gì: jit-kernel và Multi-modal. Nó bổ sung khả năng tạo văn bản gốc cho một họ gồm bốn mô hình, mỗi mô hình có đường dẫn checkpoint riêng:

• LFM3-1.7B — văn bản vào, văn bản ra, mô hình ngôn ngữ thuần túy ở nền tảng của dòng mô hình

• LFM3-VL-2B — đầu vào là văn bản, hình ảnh và video, đầu ra là văn bản

• LFM3-Audio-2B — nhận văn bản và âm thanh, xuất văn bản, đồng thời được kết nối với endpoint /v1/audio/transcriptions

• LFM3-Omni-2B — đầu vào gồm văn bản, hình ảnh, âm thanh và video, bao gồm cả âm thanh riêng của video; đầu ra là văn bản

Một chi tiết trong danh sách đó đáng để dừng lại. Mọi biến thể đều xuất ra văn bản. Không có đường xuất âm thanh nào trong toàn bộ PR, và khả năng phi trò chuyện của mô hình âm thanh là phiên âm — giọng nói vào, văn bản ra. Điều đó hẹp hơn dòng âm thanh hiện tại của Liquid, nơi LFM2.5-Audio-1.5B được ghi nhận là xử lý ASR, TTS và trò chuyện thoại xen kẽ trong một mô hình duy nhất. Hoặc bản SGLang đầu tiên chỉ bao phủ nửa tạo văn bản của LFM3-Audio, hoặc dòng omni thực sự loại bỏ tổng hợp giọng nói. PR không thể phân định điều nào, và bất kỳ ai nói với bạn rằng nó phân định được thì đang đoán. Hãy coi "LFM3 speaks" là chưa được chứng minh.

Phần còn lại của diff là chi tiết triển khai nhưng lại cho thấy thời điểm công trình được thực hiện. Các bộ mã hóa thị giác và âm thanh cùng các projector của chúng, một backbone dùng chung, tích hợp bộ nhớ đệm lai, các kernel tích chập CuTe DSL với phương án dự phòng PyTorch, và một ghi chú rằng FlashInfer mặc định dùng paged prefill để attention cửa sổ trượt hoạt động đúng. Quá trình kiểm chứng chạy trên các H100 ở FP16 bằng thứ mà phần mô tả gọi là checkpoint phát triển — bốn từ sẽ quan trọng về sau.

Câu về kiến trúc, và con số mà mọi người sẽ đọc sai.

PR mô tả LFM3 là một xương sống dùng chung gồm các tích chập ngắn có cổng với attention toàn phần và attention cửa sổ trượt. Đó là dòng LFM2 được tiếp nối, không phải bị thay thế: LFM2.5-24B-A2B được ghi nhận là một dạng kết hợp giữa tích chập ngắn có cổng và attention truy vấn nhóm trên 40 lớp. Điều có vẻ mới trong thông tin rò rỉ là thành phần cửa sổ trượt rõ ràng nằm cạnh attention toàn phần.

Các ghi chú xác thực có nhắc đến một prompt chạy vượt quá cửa sổ trượt 256 token, và đây là con số sẽ bị trích dẫn lệch ngữ cảnh suốt cả tuần. Đây không phải độ dài ngữ cảnh của LFM3. Trong một thiết kế lai, các lớp attention chỉ cần nhìn cục bộ vì các lớp convolution mang tín hiệu tầm xa — đó chính là toàn bộ tiền đề của kiến trúc, và là lý do dòng mô hình này có thể giữ 131.072 token ngữ cảnh trên LFM2.5-24B-A2B trong khi hầu hết các lớp của nó hoàn toàn không thực hiện attention bậc hai. Cửa sổ attention 256 token là một phát biểu về nơi mô hình nhìn trong một lớp, không phải lượng văn bản mà nó có thể nhận. Thông cáo PR không nêu tổng ngữ cảnh của LFM3, và chưa ai ngoài Liquid biết được điều đó.

Tại sao pull request runtime lại là tín hiệu, chứ không phải nhiễu

Thật hợp lý khi hoài nghi việc đọc chiến lược sản phẩm từ một diff hạ tầng. Trong trường hợp cụ thể này, mô thức quá nhất quán để có thể bỏ qua, bởi Liquid phát hành hỗ trợ enginecùng với trọng số thay vì sau chúng. LFM2.5-2.6B liệt kê llama.cpp, MLX, vLLM, SGLang, ONNX và Transformers 5.0+ là các mục tiêu ngay từ ngày đầu. LFM2.5-24B-A2B đã được hỗ trợ trong llama.cpp, MLX, vLLM, SGLang và ONNX ngay khi ra mắt. Một họ mô hình ra mắt với năm runtime đã sẵn sàng thì ắt hẳn phải có các kernel được viết trước khi công bố, nghĩa là các PR được hợp nhất trước và bài blog theo sau.

Tác giả khớp chính xác với trình tự thời gian đó. Lịch sử công khai của Mazurek là một chuỗi công việc tích hợp LFM: giải mã suy đoán DSpark cho LFM2-VL trong SGLang vào tháng 9, các bản sửa lỗi mô hình nháp LFM2.5-VL-3B và DSpark trong llama.cpp cùng tháng, giải mã suy đoán kế thừa từ mô hình văn bản trong mlx-vlm, và tái sử dụng cấu hình LFM2-MoE trong SGLang vào ngày 13 tháng 10. LFM3 là mục tiếp theo trong chuỗi đó, được ghi nhận vào cuối tuần dòng mô hình đổi tên.

Có hai sự vắng mặt cũng đáng chú ý không kém sự hiện diện. Không có pull request tương ứng nào trong Hugging Face Transformers dành cho LFM3 — tìm kiếm trong kho lưu trữ đó không trả về kết quả nào — và PR của SGLang tải các checkpoint của nó thông qua Transformers 5.19.0 nguyên bản với --trust-remote-code, đúng là cách bạn làm khi kiến trúc chưa được hỗ trợ gốc trong thư viện. Ngoài ra còn có một commit từ chối rõ ràng việc giải mã suy đoán cho LFM3, vì vậy phần việc DSpark đã được phát hành cho thế hệ 2.5 vẫn chưa được chuyển sang. Còn sớm, và chưa hoàn chỉnh theo thiết kế.

Câu hỏi về kích thước mà chưa ai trả lời

Ở đây, vụ rò rỉ và tham vọng được tuyên bố kéo theo hai hướng ngược nhau, và sự căng thẳng chính là điều thú vị nhất trong tài liệu.

Maxime Labonne, Trưởng bộ phận Tiền huấn luyện của Liquid, đã mô tả mục tiêu của LFM3 là kiểm tra liệu cách tiếp cận tích chập ngắn vốn hiệu quả ở quy mô từ 350M đến 1,2B tham số có thể duy trì được khi vượt quá 10B tham số hay không — vùng mà các kiến trúc attention từ trước đến nay vẫn có lợi thế. Đó là một câu hỏi về mở rộng quy mô, và nó hàm ý một mô hình lớn.

Các checkpoint bị rò rỉ là 1.7B và ba checkpoint ở 2B. Không cái nào trong số đó vượt ngưỡng mà câu hỏi đang nói tới.

Có hai cách lý giải vẫn đứng vững. Cách thứ nhất là đây là làn sóng đầu tiên nhỏ gọn — một dòng omni dành cho điện thoại và ô tô trước khi một người anh em lớn hơn xuất hiện, điều này khớp với cách Liquid vẫn luôn dẫn đầu bằng các mô hình nhỏ và cách PR mô tả chúng là các mốc phát triển thay vì bản phát hành cuối cùng. Cách thứ hai là 1.7B và 2B chỉ đơn giản là những kích thước thuận tiện để kiểm chứng kernel, và không cho chúng ta biết gì về những gì sẽ được phát hành. Quan điểm trung thực là rò rỉ này chứng minh dòng mô hình tồn tại và chứng minh hình dạng của nó; nó không chứng minh giới hạn trên của nó. Nếu bạn đang chờ một mô hình Liquid >10B, PR này không hứa hẹn một mô hình như vậy cũng không loại trừ khả năng đó.

LFM3 thừa hưởng những gì, cả tốt lẫn xấu

Mốc cơ sở mà nó phải vượt qua là mới và được ghi chép đầy đủ. LFM2.5-24B-A2B đã ra mắt vào ngày 13 tháng 10 năm 2026 với tổng 24B tham số, trong đó 2B hoạt động, 40 lớp, 64 chuyên gia và định tuyến top-4, ngữ cảnh 131.072 token, từ vựng 128K và 33T token tiền huấn luyện. LFM2.5-2.6B, từ đầu tháng 8, nằm gọn trong dưới 2.5GB với ngữ cảnh 128K. LFM2.5-VL-3B kết hợp phần nền 2.6B với bộ mã hóa thị giác SigLIP2.

Cần nói rõ ràng: mọi benchmark Liquid công bố cho các mô hình này đều do nhà cung cấp tự chạy trên các harness của chính Liquid, không kèm đánh giá độc lập nào. Các con số nổi bật của LFM2.5-24B-A2B — AutomationBench 27.69, BFCLv4 65.01, ToolSandbox 80.71, IFEval 96.75 — là số liệu của Liquid, và chính bảng đó cho thấy mô hình thua Qwen3.6-35B-A3B trên WebArena Verified (26.75 so với 37.62), GPQA Diamond và SWE-Bench Verified. Các bảng của nhà cung cấp có nêu cả những điểm thua kém thì đáng tin hơn những bảng không nêu, nhưng đáng tin không đồng nghĩa với đã được kiểm chứng. Chưa có bất kỳ con số LFM3 nào thuộc bất kỳ loại nào, nên hiện chưa có gì để so sánh.

Việc cấp phép cũng sẽ được tiếp tục áp dụng. Các checkpoint LFM gần đây của Liquid trên Hugging Face đều được gắn thẻ license: other — một giấy phép LFM riêng, không phải Apache-2.0 hay MIT. Dù LFM3 được phát hành theo giấy phép nào, hãy giả định các điều khoản tùy chỉnh tương tự cho đến khi thẻ mô hình nói khác, và hãy đọc chúng trước khi bạn xây dựng sản phẩm dựa trên các trọng số.

Khi nào nó thực sự có thể hạ cánh

Không ai biết một mốc ngày cụ thể, kể cả những người chuyên đưa ra dự đoán. Một câu hỏi trên Manifold Markets về thời điểm LiquidAI LFM3 sẽ được phát hành đặt Q4 2026 ở mức 40%, Q1 2027 ở mức 21%, Q2 2027 ở mức 21%, Q3 2026 ở mức 11% và Q2 2026 ở mức 7% — trên tổng khối lượng khoảng Ṁ160, đủ nhỏ để các tỷ lệ phần trăm phản ánh một vài nhà giao dịch thay vì một sự đồng thuận. Hãy hiểu đây là “đại khái vào một lúc nào đó trong hai quý tới”, và không chính xác hơn thế.

Các lý lẽ vận hành cho thấy nên sớm hơn là muộn. Việc đưa công việc kernel vào một runtime lớn là kỹ thuật ở giai đoạn muộn, không phải giai đoạn đầu — bạn không viết kernel convolution CuTe và nối bộ nhớ đệm lai cho một mô hình còn cả năm nữa mới ra. Tên dòng đã ổn định thành LFM3 trên bốn biến thể và bốn đường dẫn checkpoint. Nhưng PR chưa được hợp nhất với cả ba kiểm tra đều đỏ, cần một đánh giá phê duyệt mà nó chưa có, và 2 trong 22 kiểm tra xác thực omni cùng 2 trong 16 kiểm tra thị giác vẫn không đạt so sánh ROUGE của chúng. Đó là một nhánh đang giữa chừng, không phải ứng viên phát hành.

Đ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

Không có gì về LFM3 nên thay đổi quyết định bạn đưa ra hôm nay. Nó không khả dụng, không có giá, không được đánh giá chuẩn và không được cấp phép công khai. Nếu bạn cần một mô hình đa phương thức nhỏ ngay bây giờ, thế hệ LFM2.5 là câu trả lời thực sự, và những hạn chế của nó — điểm số do nhà cung cấp báo cáo, giấy phép tùy chỉnh, và hồ sơ lập trình mà cả bảng của chính Liquid lẫn các nguồn đưa tin bên ngoài đều đánh dấu là điểm yếu — là những điều cần cân nhắc.

Điều mà bản rò rỉ thực sự hữu ích là để lập kế hoạch. Nó cho bạn biết rằng một dòng omni nhỏ gọn đang đến, rằng nó có khả năng sẽ ra mắt trên nhiều runtime cùng lúc, và rằng biến thể âm thanh của nó có thể không tổng hợp được giọng nói. Nếu lộ trình của bạn giả định bước đi tiếp theo của Liquid là một mô hình văn bản lớn hơn, thì bằng chứng cho đến nay không ủng hộ giả định đó.

Sự phân mảnh runtime là vấn đề thực tế mà dòng mô hình này sẽ tạo ra. Thói quen phát hành đồng thời lên llama.cpp, MLX, vLLM, SGLang và ONNX của Liquid thì tốt cho tính di động nhưng lại bất tiện cho bất kỳ ai muốn một endpoint duy nhất: năm engine đồng nghĩa với năm dạng triển khai, năm bộ đặc thù tiền xử lý và năm thời điểm khác nhau để một bản sửa được đưa vào. Danh mục của OrcaRouter gồm hơn 200 mô hình hiện không bao gồm một checkpoint LFM nào, vì vậy không có cách nào gọi LFM3 qua đó và không nội dung nào ở đây nên được hiểu là lời hứa rằng sẽ có. Điều mà một lớp định tuyến thực sự dùng để làm trong tình huống này là mối nối giữa một mô hình chưa được chứng minh và một đường dẫn sản xuất — gửi một phần lưu lượng đến một thứ mới trong khi một mô hình đã biết vẫn ở phía sau, với cơ chế chuyển đổi dự phòng bắt lấy khoảng trống, là cách bạn đánh giá mô hình kế nhiệm của một dòng chưa phát hành mà không đặt cược một tính năng hướng tới khách hàng vào một thị trường dự đoán 40%.

Những câu hỏi mở đáng theo dõi

Bốn điều sẽ giải quyết việc này nhanh hơn bất kỳ suy đoán nào nữa. Liệu bốn đường dẫn checkpoint có trở thành các kho Hugging Face thật sự, có thể tải xuống được hay không — hiện tại, tìm kiếm trong tổ chức LiquidAI không trả về gì dưới LFM3, và các kho được nêu tên trong PR không thể được phân giải công khai. Liệu một PR Transformers có xuất hiện hay không, điều này sẽ báo hiệu rằng kiến trúc đang được đưa lên upstream đúng cách thay vì chạy qua remote code. Liệu các kiểm tra xác thực đang thất bại có được khép lại hay không, vì 2 trong số 22 lỗi omni chính là khác biệt giữa một bản demo và một lần merge. Và liệu một thành viên >10B của dòng mô hình này có xuất hiện hay không, đó chính là câu hỏi mà Labonne nói rằng LFM3 tồn tại để trả lời.

Cho đến lúc đó, câu chính xác nhất mà bất kỳ ai có thể viết về LFM3 chính là câu mà bài viết này đã mở đầu: có một pull request, nó chưa được hợp nhất, và nó nêu tên bốn mô hình omni nhỏ mà Liquid AI chưa công bố. Đó là một tín hiệu thật — chỉ là một tín hiệu sớm, và những tín hiệu sớm xứng đáng được đọc đúng như bản chất đó.