d1-omni so với Liquid AI D1 Omni 600M: Hai cái tên, một checkpoint, và một con số ngữ cảnh không ai truy được nguồn

Liquid AI D1 Omni 600M và d1-omni không phải là hai mô hình, và cũng không phải là hai checkpoint của cùng một mô hình. Chúng là một bộ trọng số — mô hình quyết định đa phương thức 587 triệu tham số của Liquid AI, được xây dựng trên Liquid AI LFM2.5-Encoder-350M và được công bố trên Hugging Face vào ngày 5 tháng 10 năm 2026 dưới tên repo LiquidAI/d1-omni-600M — mang hai tên tệp khác nhau trong hai danh mục khác nhau. Một trong hai danh mục đó, của nhà cung cấp, cho bạn biết mô hình là gì. Danh mục còn lại, của Ollama, cho bạn biết ai đó đã đóng gói nó thành gì, và in ba con số trên thẻ mà tài liệu của nhà cung cấp không hề xác nhận. Khoảng cách đó chính là toàn bộ lý do so sánh này đáng đọc, bởi vì với một mô hình nhỏ như thế này, việc đóng gói không phải là chú thích phụ — đó là sự khác biệt giữa một mô hình văn bản và hình ảnh với mô hình mà thẻ nói rằng bạn đã tải xuống.

Nhà cung cấp chưa công bố bất cứ điều gì về mục Ollama, và không có ghi chú nào từ người bảo trì, không có mục changelog và không có readme trên trang Ollama để giải thích bất kỳ điều nào trong số đó. Vì vậy, cách diễn đạt trung thực cho mọi điều dưới đây là thế này: các trọng số là công khai và có thể kiểm tra, phần đóng gói là công khai và có thể kiểm tra, và cách diễn giải phần đóng gói được đưa ra ở đây là của chúng tôi, không phải của Liquid AI. Khi một con số không thể truy nguyên về nguồn, bài viết này nói rõ điều đó thay vì lặp lại nó.

Hai cái tên đó thực sự là gì

Liquid AI đã công bố mô hình trên Hugging Face với dấu thời gian tạo là ngày 5 tháng 10 năm 2026, hai ngày trước khi mô hình xuất hiện trong bài đăng blog của chính nhà cung cấp "Open d1: Các mô hình quyết định biên cho văn bản, thị giác và âm thanh" vào ngày 7 tháng 10. Các trọng số được cấp phép theo các điều khoản LFM 1.0 của chính Liquid, được gắn thẻ d1_omni, system-one, multimodal, vision, audio và decision-model, và tính đến thời điểm viết bài đã thu hút khoảng 13.900 lượt tải xuống và 135 lượt thích. Các biến thể lượng tử hóa tiếp nối theo lịch trình riêng của chúng: một kho lưu trữ GGUF vào ngày 6 tháng 10, các bản dựng MLX cho Apple Silicon vào ngày 12 tháng 10.

Mục Ollama không phải là bất kỳ kho lưu trữ nào trong số đó. Đó là một trang thư viện Ollama có tên d1-omni, mang huy hiệu "vision 600m", hiển thị bốn thẻ và đã được cập nhật vài phút trước khi bài này được viết — đó là lý do radar phát hiện ra nó. Không có gì trong đó nhắc đến Liquid AI, LFM2.5-Encoder-350M, hay kho lưu trữ Hugging Face mà các byte đến từ đó.

Vậy khác biệt thực tế chỉ là tên tệp và đường dẫn phân phối, chứ không phải một mô hình. Điều khác biệt, và điều quan trọng, chính là siêu dữ liệu được bao quanh các byte.

Ba con số trên thẻ Ollama, được kiểm tra lần lượt từng cái một

Trang của Ollama in ra một kích thước, một cửa sổ ngữ cảnh và một danh sách đầu vào cho mỗi tag. Cả ba đều đáng để xem lại, bởi vì trên mô hình này, hai trong số đó không đứng vững khi đối chiếu với nguồn.

• Cửa sổ ngữ cảnh — 125K trên thẻ mô hình, 16.384 trong mọi nguồn của nhà cung cấp. Thẻ mô hình của Liquid AI nêu giới hạn trần 16.384 token áp dụng chung cho vị trí văn bản, hình ảnh và âm thanh, còn trang tài liệu của chính nhà cung cấp cho d1-omni-600M ghi "16K tokens". Chuỗi 125K không xuất hiện ở cả hai nơi. Đây có thể là sản phẩm phụ từ cấu hình vị trí của kiến trúc LFM2.5-Encoder bên dưới hoặc từ cách Ollama báo cáo giới hạn bộ nhớ đệm, nhưng đó không phải con số do Liquid AI công bố và cũng không phải con số mà bài viết này có thể gán cho bất kỳ ai. Điều khiến sự chênh lệch này không chỉ là chuyện vụn vặt chính là con số tiếp theo ngay bên dưới.

• Trạng thái mà bạn thực sự có thể truyền bị giới hạn ở 896 token trên nhánh hình ảnh.Thẻ mô hình của Liquid cho biết rằng khi có hình ảnh, "văn bản trạng thái và câu hỏi được cắt xuống 896 token, đúng như khi huấn luyện". Vì vậy, một yêu cầu ra quyết định có kèm ảnh có ngân sách văn bản xấp xỉ kích thước của câu này, bất kể con số ngữ cảnh nào được in trên trang pull. Nếu bạn đang định cỡ một prompt sàng lọc dựa trên 125K và kỳ vọng phải trả cho một trạng thái dài, thì bạn đang định cỡ theo một con số không mô tả runtime. Con số 16,384 là mức trần thực sự; con số 896 là giới hạn làm việc thực tế cho nhánh đa phương thức; 125K là một con số không có hồ sơ chứng minh.

• Kích thước — 850MB trên thẻ, hai tệp trong registry. Thẻ Ollama d1-omni:latest phân giải thành một tệp trọng số lượng tử hóa 407MB được chỉ định là Q8_0 cộng với một tệp projector 442MB được chỉ định là BF16, và 407 + 442 = 849, mà trang làm tròn thành 850MB. Cả hai đều được liệt kê một cách trung thực; phép tính chỉ là tổng của một cặp độ chính xác hỗn hợp chứ không phải một tệp. Thẻ d1-omni:600m-bf16 là thẻ gọn hơn: 764MB trọng số BF16 cộng với cùng một projector 442MB, 1.2GB trên đĩa, và projector giống hệt từng byte giữa hai thẻ. Đáng chú ý cho phần tiếp theo, vì một projector mang trọng số riêng của nó có thể làm thay đổi số lượng tham số hiệu dụng.

Một chi tiết nữa đáng ghi lại hơn là giải thích: khối tham số runtime bên trong gói d1-omni của Ollama có cùng độ dài chính xác từng byte — 18 byte — như khối bên trong gói d1 riêng của Ollama, gói này đi kèm Liquid AI d1-3B với 2.87GB trọng số Q8_0 và một projector 855MB. Hai kiến trúc, hai số lượng tham số, chênh nhau hai bậc về quy mô tham số, và cùng một cấu hình runtime 18 byte. Đó là một hằng số đóng gói, không phải một khẳng định về bất kỳ mô hình nào.

Bản thân các trọng số nói lên điều gì

Bóc lớp đóng gói ra thì mô hình được tài liệu hóa một cách hiếm thấy. Liquid AI D1 Omni 600M có tổng cộng 587M tham số, chia làm ba phần: một trunk dùng chung kiêm đầu quyết định 381M, một bộ mã hóa thị giác 94M và một bộ mã hóa âm thanh 112M. Trunk này có tính hai chiều — đây là bộ mã hóa, không phải bộ giải mã — và nó là cùng một trunk cho mọi phương thức, với các tower chuyên biệt theo từng phương thức được gắn thêm vào.

• Thị giác đến từ một tháp SigLIP2 được kế thừa từ Liquid AI LFM2.5-VL-450M, với một bộ chuyển đổi và các cập nhật LoRA chỉ hoạt động cho đầu vào hình ảnh trong khi bản thân bộ mã hóa vẫn được giữ đóng băng.

• Âm thanh đến từ một FastConformer 17 lớp với adapter riêng, được tinh chỉnh trong một giai đoạn mà backbone văn bản bị đóng băng, sau đó toàn bộ stack được tinh chỉnh, LoRA được hợp nhất, và các trọng số được lấy trung bình trở lại so với checkpoint trước đó.

• Từ vựng gồm 65.536 token trên 15 ngôn ngữ: tiếng Anh, tiếng Đức, tiếng Tây Ban Nha, tiếng Pháp, tiếng Ý, tiếng Hà Lan, tiếng Ba Lan, tiếng Bồ Đào Nha, tiếng Ả Rập, tiếng Hindi, tiếng Nhật, tiếng Nga, tiếng Thổ Nhĩ Kỳ, tiếng Việt và tiếng Trung.

• Không thể trộn lẫn các phương thức. Một yêu cầu duy nhất sẽ nhận văn bản kèm hình ảnh, hoặc văn bản kèm tối đa 30 giây giọng nói — không phải cả hai. Âm thanh được mong đợi ở dạng 16kHz mono, trong khoảng từ 0,5 đến 30 giây, và được huấn luyện trên các cuộc trao đổi giữa một người nói tiếng Anh và một trợ lý, đây là một hạn chế thực sự đối với bất kỳ nội dung đa ngôn ngữ hoặc nhiễu nào.

Không có điều nào trong số đó xuất hiện trên trang Ollama, và việc bỏ sót này có một hệ quả mà bạn có thể thấy trực tiếp trong các ví dụ sử dụng. Các đoạn mã mẫu của Ollama là những lệnh gọi trò chuyện — một chuỗi mô hình, một mảng messages, từ "Hello!" — và checkpoint bên dưới không thể trả lời chúng. Nó không phải là mô hình trò chuyện và không viết văn bản. Nó trả về các câu trả lời được định kiểu: xác suất có/không, một nhãn kèm xác suất cho từng nhãn, hoặc một vị trí trên một thang đo có thứ tự, tất cả đều được đọc trực tiếp từ phân phối đầu ra mà không sinh ra token đầu ra nào. Các giao diện được công bố phản ánh điều đó: system_one và probabilities thông qua Transformers, hoặc một điểm cuối /v1/systemone thông qua llama.cpp 0.7.0 và các phiên bản sau. Một lệnh gọi dạng trò chuyện đối với một mô hình quyết định chính là lỗi mà khoảng trống đặt tên này dễ dẫn đến.

Có hai lưu ý đi kèm với mỗi con số trong số đó.

Đầu tiên, Liquid tự chấm điểm các dòng kết quả của chính mình bằng bộ chấm điểm chính thức thay vì nộp chúng để xếp hạng công khai, và không bên thứ ba nào đã tái tạo bất kỳ kết quả d1-omni-600M nào — nhà cung cấp nói rõ trên thẻ mô hình rằng họ không báo cáo số liệu suy luận cho checkpoint này vì đây là bản phát hành nghiên cứu sớm đang được phát triển tích cực. Thứ hai, hai con số nổi bật mâu thuẫn với nhau: khoảng cách chỉ số 32 điểm và khoảng cách trung bình chuẩn 4,5 điểm mô tả cùng một mô hình, đó là lý do vì sao các điểm thành phần, chứ không phải tổng số, mới là cách đọc hữu ích. Truy xuất ở 35,0 và Công cụ ở 15,1 so với Nghệ thuật ở 6,8 cho bạn biết checkpoint này đã sẵn sàng và chưa sẵn sàng cho những công việc nào. Âm thanh hoàn toàn không có cột chuẩn nào; Liquid gọi các chuẩn đánh giá quyết định chuyên biệt cho âm thanh là một vấn đề mở.

Liquid AI D1 Omni 600M cũng dẫn đầu trong chính gia đình của mình ở hai trong số bảy hạng mục: Civil Comments với 95,8 và PAWS-X với 79,5. Đó là hai hàng mà một encoder 587M đánh bại decoder 3B một cách dứt khoát, và cả hai đều mang dạng phân loại văn bản chứ không phải dạng suy luận — điều này phù hợp với kiến trúc chứ không hề mâu thuẫn với nó.

Hãy chọn theo điều bạn muốn. Nếu bạn muốn chạy nó cục bộ dưới Ollama, d1-omni là tên khả dụng — 850MB cho bản dựng Q8_0, 1.2GB cho BF16, cùng đường dẫn image mà Liquid ghi trong tài liệu, và không tag nào mang audio projector. Nếu bạn muốn mô hình mà nhà cung cấp mô tả, Liquid AI D1 Omni 600M là tên cần tìm, và hướng Transformers qua kho lưu trữ Hugging Face là hướng có độ dài ngữ cảnh, danh sách modality và số lượng tham số khớp với tài liệu.

Dù thế nào, đây là nửa rẻ hơn của một pipeline. Mô hình quyết định phân loại; một thứ khác phải hành động dựa trên kết quả phân loại. Đó là ranh giới mà OrcaRouter đứng trên đó và là ranh giới đáng được nói rõ: không có mô hình Liquid AI nào trong danh mục của chúng tôi, nên bản thân lệnh gọi d1-omni sẽ diễn ra ở bất cứ nơi nào bạn vốn đã chạy nó — các trọng số này trên phần cứng của bạn, hoặc API riêng của nhà cung cấp và các nền tảng bên thứ ba cho các phiên bản được lưu trữ. Điều mà 200+ mô hình sau một khóa tương thích OpenAI dùng để làm là mọi thứ ở hạ nguồn, ở mức giá niêm yết của từng nhà cung cấp được chuyển nguyên với mức cộng thêm 0%, với tự động chuyển đổi dự phòng giữa các nhà cung cấp khi một yêu cầu đã được sàng lọc tỏa đến một mô hình đang gặp trục trặc.

Điều gì sẽ giải đáp câu hỏi còn bỏ ngỏ

Ba điều sau sẽ khép lại việc này, và không điều nào cần đến một thông báo từ nhà cung cấp. Việc ai đó so sánh đầu ra của tag 850MB của Ollama với checkpoint Hugging Face trên cùng những đầu vào sẽ cho chúng ta biết liệu cách đóng gói có làm thay đổi câu trả lời hay không. Một commit của llama.cpp hoặc một mục trong changelog của Ollama giải thích con số ngữ cảnh sẽ cho chúng ta biết liệu 125K là một sai sót hay là một năng lực mà thẻ mô hình chưa cập nhật kịp. Và một kết quả âm thanh được công bố — bất kỳ kết quả âm thanh nào — sẽ đưa checkpoint này ra khỏi danh mục mà nó hiện đang thuộc về, đó là một mô hình được ghi chép đầy đủ với một lớp đóng gói chưa được ghi chép và một bảng điểm hoàn toàn do nhà cung cấp tự đưa ra.

Các lỗi AI và sự cố tác nhân được ghi nhận đằng sau những bản phát hành như bản này được tập hợp trong OrcaRouter AI Incident Archive, trong đó mỗi mục đều có nguồn, mức độ nghiêm trọng, xếp hạng độ tin cậy và cờ tranh chấp riêng.