Liquid AI d1-omni-600M giờ đã là một Ollama Pull: Một mô hình quyết định 600M có thể lắng nghe bạn

Liquid AI d1-omni-600M đã trở thành một gói Ollama lúc 22:32 UTC ngày 17 tháng 10 năm 2026. Dấu thời gian đó không phải là phỏng đoán: registry của Ollama trả về header ollama-push-time trên mọi manifest, và bốn tag đằng sau tên d1-omni đã được chấp nhận trong khoảng 22:31:25 đến 22:32:13 tối hôm đó, tức khoảng bốn giờ trước khi bài này được viết. Bản thân mô hình không mới — Liquid AI đã mở trọng số Liquid AI d1-omni-600M cùng với Liquid AI d1-3B vào ngày 5 tháng 10 năm 2026 và công bố cả hai trong bài "Open d1" của mình vào ngày 7 tháng 10 — nhưng cho đến đêm qua, những cách duy nhất để chạy mô hình có khả năng xử lý âm thanh này trên phần cứng của bạn là một môi trường transformers với trust_remote_code=True hoặc một bản dựng llama.cpp do bạn tự biên dịch. Giờ đây nó là ollama pull d1-omni. Không ai công bố điều đó: không phải blog của Liquid AI, cũng không phải của Ollama.

Phần đóng gói chính là câu chuyện, và đáng để nói chính xác những phần nào trong đó đã được ghi nhận. Các bài blog gần nhất của Liquid AI là d1-ultra vào ngày 15 tháng 10 và LFM2.5-24B-A2B vào ngày 13 tháng 10, và cả hai đều không nhắc đến Ollama; trang triển khai Ollama của chính phòng thí nghiệm vẫn hướng dẫn bạn chạy các kho GGUF của mình trực tiếp từ Hugging Face bằng ollama run hf.co/LiquidAI/... và không hề nêu tên một mô hình d1 nào. Blog của Ollama cũng im lặng như vậy — các mục mới nhất là Reflection's Beam vào ngày 16 tháng 10 và một tích hợp Fly.io vào ngày 13 tháng 10. Thay vào đó, những gì tồn tại là một mục trong registry, bốn thẻ, một digest có thể xác minh, và một trang thư viện vẫn đang được soạn khi bài viết này được viết: bản chụp sớm của trang đó trả về "No readme," và bản chụp bốn mươi phút sau trả về một mô tả đầy đủ do Liquid AI viết với bảng benchmark và một mục giấy phép. Nếu bạn muốn một sự kiện có ngày tháng, có thể kiểm tra được trong bảy ngày qua, thì phần tiêu đề đó chính là nó.

Những gì cơ quan đăng ký thực sự chấp nhận

Bốn tag tương ứng với hai image, và đó là điều đầu tiên cần hiểu trước khi bạn pull. d1-omni:latest, d1-omni:600m và d1-omni:600m-q8_0 là cùng một manifest — digest 1ba59f63e836 — trong khi d1-omni:600m-bf16 là image thứ hai, digest c1e95fce6627. Không có tag F16, mặc dù repository GGUF của chính nhà cung cấp có công bố một trunk F16.

• Các lớp trọng số (bản dựng Q8_0) — một phần thân 407 MB từ d1-omni-600M-Q8_0.gguf cùng với một bộ chiếu 442 MB từ mmproj-d1-omni-600M-BF16.gguf, với một khối giấy phép 10,5 KB và một khối tham số 18 byte, tổng cộng 849.659.968 byte.

• Kích thước được báo cáo — 850 MB cho tag mặc định và 1.2 GB cho 600m-bf16, cả hai đúng như in trên trang thư viện.

• Ngưỡng runtime tối thiểu — yêu cầu: 0.40.4 trong blob cấu hình, blob này cũng báo cáo model_family: lfm2, model_type: 380.73M và loại tệp Q8_0.

• Ngữ cảnh — khối tham số cố định num_ctx ở 16.384.

• Giấy phép — văn bản được nhúng là LFM Open License v1.0, ghi Liquid AI, Inc. là bên cấp phép, khớp với mã định danh lfm1.0 trên thẻ mô hình.

Projector đó đáng để xem xét kỹ hơn, vì nó còn lớn hơn cả mô hình mà nó được gắn vào. Đọc trực tiếp siêu dữ liệu GGUF từ blob trong registry cho thấy clip.has_vision_encoder = True và clip.has_audio_encoder = True trong cùng một tệp: 197 tensor thị giác trên 12 khối với embedding rộng 768 và đầu vào 256 pixel, cùng 641 tensor âm thanh trên 17 khối với embedding rộng 512 và 128 mel bin. Đó là tháp SigLIP2 và bộ mã hóa FastConformer cùng nằm trong gói đa phương thức, nên mới có chuyện một phần thân 381M tham số đi kèm một tệp đính kèm 442 MB. Năng lực âm thanh hiện diện về mặt vật lý trong gói bạn tải xuống; câu hỏi liệu endpoint có thể truy cập tới nó hay không sẽ đến sau.

Mô hình có 587M tham số và huy hiệu 125K còn lớn hơn sự thật.

Trang của Ollama quảng cáo "cửa sổ ngữ cảnh 125K" trên mọi thẻ. num_ctx của chính gói là 16.384, và thẻ mô hình của Liquid AI cũng nói điều tương tự bằng lời: 16.384 token trải trên các vị trí văn bản, hình ảnh và âm thanh cộng lại, với văn bản trạng thái và câu hỏi bị cắt còn 896 token mỗi khi có hình ảnh. Con số 125K có thể truy ngược được — GGUF phần thân mang lfm2.context_length = 128000 — nhưng đó là mức trần của kiến trúc, không phải cửa sổ bạn thực sự có, và là con số dễ khiến người ta hiểu nhầm nhất khi chọn kích thước một mô hình thay thế cho bộ phân loại ngữ cảnh dài. Hãy coi 16.384 là con số làm việc, và 896 token văn bản là con số làm việc khi có hình ảnh trong trạng thái.

Phần còn lại của metadata xác nhận thẻ mô hình chứ không phải câu quảng cáo. Phần thân gồm 18 khối, embedding rộng 1,024 và bộ từ vựng 65,536, và đây không phải bộ giải mã: lfm2.attention.causal là False. Số head KV theo từng lớp đọc là 0, 0, 8, 0, 0, 8, …, nghĩa là phần lớn các khối đó hoàn toàn không phải khối attention, điều này cho thấy nguồn gốc encoder hai chiều đang lộ ra. Đầu quyết định gồm hai khối (lfm2.decision.block_count = 2), và các hằng số hiệu chỉnh mà nhà cung cấp giữ trong config.json cũng có trong GGUF này — câu hỏi lựa chọn mang nhiệt độ 1.7465 khi có hai lựa chọn, 1.3999 khi có ba đến năm lựa chọn, 1.1751 khi có sáu đến mười lựa chọn và 1.3725 khi trên mười một lựa chọn; có/không là 1.6663; câu hỏi tính điểm là 1.7301 ở ba đến năm mức và 1.0 ở sáu đến mười mức. Đó là toàn bộ thiết kế gói gọn trong một chỗ: một tập câu trả lời có tên cố định, được tính điểm trong một lượt, được hiệu chỉnh theo từng dạng câu hỏi, với output_tokens: 0 ở cuối.

Đây không phải là mô hình trò chuyện và không viết văn bản. Liquid AI liệt kê mười lăm ngôn ngữ, chỉ đưa dữ liệu huấn luyện âm thanh bằng tiếng Anh — các yêu cầu giữa người nói và trợ lý — và giới hạn clip ở 30 giây. Thẻ này cũng cảnh báo không nên dùng bfloat16 trên GPU: trong các kiểm tra của chính nhà cung cấp, nó đã thay đổi câu trả lời hàng đầu trên 0,8% hàng văn bản và 1,7% hàng âm thanh, trong khi float16 khớp với float32 ở mọi nơi.

Âm thanh nằm trong các trọng số và không có trong API được ghi tài liệu

Đây là điểm khác biệt đáng biết trước khi bạn gửi báo cáo lỗi. Tệp readme của trang thư viện, do Liquid AI viết, ghi tài liệu về âm thanh bằng cách đặt một WAV dạng base64 bên trong mảng images của một yêu cầu /v1/systemone. Tệp readme GGUF trên Hugging Face của nhà cung cấp cho cùng checkpoint lại ghi tài liệu theo cách khác, với một mảng files mang data:audio/wav;base64,… vào máy chủ llama.cpp. Và tài liệu tham chiếu endpoint do Ollama công bố lại không ghi tài liệu cho cả hai: lược đồ yêu cầu của nó có state, images, questions và keep_alive, mô tả images là "Yêu cầu một mô hình có thị giác, chẳng hạn như Clef," và hoàn toàn không chứa trường audio hay trường files nào. Trong khi đó, hướng dẫn về mô hình quyết định của chính Ollama nêu Nimble, Tev1, Clef và Clef Flash là các mô hình quyết định và chỉ nói rằng các mô hình Clef cũng có thể phán đoán hình ảnh.

Vậy nên quan điểm trung thực về âm thanh trong Ollama hiện nay là: bộ mã hóa đã được xác minh là có mặt trong blob, readme của nhà cung cấp nói rằng nó hoạt động thông qua hình ảnh, còn lược đồ đã công bố thì không thừa nhận điều đó. Đầu vào hình ảnh trên cùng mô hình có cơ sở vững chắc hơn — thị giác là một năng lực đã được tài liệu hóa của System One và d1-omni xuất hiện trong danh mục thị giác của Ollama. Có hai khoảng trống tài liệu nhỏ hơn nằm cạnh khoảng trống đó: tài liệu tham chiếu endpoint cho phép tối đa 255 khóa tùy chọn trong một câu hỏi lựa chọn, trong khi hướng dẫn quyết định nói từ 2 đến 26, và mức tối thiểu runtime của gói là 0.40.4 cao hơn 0.35.0 mà tài liệu endpoint trích dẫn.

Được xếp vào mục tầm nhìn, không phải mục quyết định

Tính năng tìm kiếm mô hình của Ollama lọc các mô hình quyết định vào một danh mục riêng. Danh mục này có chín mục — nimble-v3, pplx-decider, kev, tev1, nimble, clef-flash, clef, laya và strands-decider — và không có d1 lẫn d1-omni trong số đó. Trang của d1-omni được gắn thẻ vision và 600m, và nó có xuất hiện trong danh sách vision, nên người đọc đang duyệt tìm "decision model" sẽ không tìm thấy mô hình mới nhất. Đó là vấn đề về khả năng khám phá chứ không phải về năng lực, nhưng điều đó có ý nghĩa nếu bạn định so sánh các họ mô hình quyết định trong chính danh mục của Ollama và kết luận rằng mô hình này không tồn tại.

Điều đó cũng có nghĩa là d1-omni là mô hình quyết định đầu tiên trong thư viện của Ollama có thể tiếp nhận giọng nói — bộ mã hóa âm thanh nằm trong gói, và không có mô hình nào khác trong danh sách chín mô hình đó sở hữu một bộ như vậy. Liệu endpoint có đưa tệp WAV của bạn cho nó hay không chính là câu hỏi còn bỏ ngỏ từ phần trên, và đây là thứ duy nhất dễ có khả năng đã thay đổi nhất vào lúc bạn đọc bài này.

Những con số, và ai đã tạo ra từng con một trong số đó

Mọi con số độ chính xác gắn với Liquid AI d1-omni-600M đều là của Liquid AI, và theo những gì chúng tôi có thể tìm được, không có đánh giá độc lập nào về bất kỳ mô hình d1 nào đang tồn tại — không có dòng nào trên bảng xếp hạng, không có lần chạy thử nào của bên thứ ba, không có phản bác nào được công bố đối với cách chấm điểm của nhà cung cấp. Nhà cung cấp đã tự chấm điểm cả hai checkpoint d1 bằng công cụ chấm điểm Decision Index chính thức thay vì gửi chúng lên bảng xếp hạng công khai, và nói rõ điều đó trên thẻ mô hình; mọi hàng đối thủ trong bảng của nó đều đến từ bảng xếp hạng v0.2.1, nghĩa là phép so sánh đặt một con số tự chấm bên cạnh những con số được chấm từ bên ngoài.

• Decision Index 0.2.1 — 15,95 cho d1-omni-600M (kiến thức 8,3, ngôn ngữ 12,9, truy xuất 35,0, công cụ 15,1, nghệ thuật 6,8) so với 48,57 cho d1-3B.

• Điểm chuẩn đóng vai trò quyết định, trung bình của bảy — 78.4 cho d1-omni-600M so với 82.9 cho d1-3B, với mô hình 600M dẫn trước ở Civil Comments (95.8 so với 93.0) và PAWS-X (79.5 so với 76.9) và xếp sau ở BoolQ (77.7 so với 86.7) và SQuAD 2.0 (74.0 so với 85.3).

• Fast Decisions, tập dev — 76,9, do nhà cung cấp báo cáo, không có dòng so sánh nào được công bố.

• Tốc độ — không có gì. Thẻ mô hình nêu rõ rằng các con số suy luận không được báo cáo vì đây là một bản phát hành nghiên cứu sớm đang trong quá trình phát triển tích cực, nên bất kỳ tuyên bố nào về độ trễ mà bạn thấy ở nơi khác đều là do chính ai đó tự đo.

• Các con số fixture trên trang Ollama — ví dụ minh họa trong README cho thấy mục khẩn cấp được trả lời ở 0.998 và mục kỹ thuật ở 0.995. Đó là các đầu ra minh họa của một yêu cầu, do runtime công bố, và chúng không phải là một benchmark.

Khoảng cách giữa 15.95 và 48.57 là điều hữu ích nhất trên thẻ, vì nó giải đáp câu hỏi mua hàng bằng chính lời của nhà cung cấp: readme bảo bạn dùng d1 khi độ chính xác trên văn bản và hình ảnh là điều quan trọng, và chọn d1-omni khi kích thước là quan trọng hoặc bạn cần âm thanh. Một mô hình 587M đạt 78.4 điểm trên bảy bộ đánh giá công khai, khi được diễn giải thành các quyết định, là một bộ phân loại biên hợp lý. Nó không phải là một phiên bản nhỏ hơn của 3B.

OrcaRouter phù hợp ở đâu, và ở đâu thì không

Chúng tôi không phục vụ mô hình này. Việc kiểm tra danh mục của chúng tôi vào ngày 18 tháng 10 trả về 208 ID mô hình và không có một ID nào đến từ Liquid AI, vì vậy không có gì ở đây là tuyên bố về tính sẵn có và không có cách nào từ phía chúng tôi để lấy nó về. Nếu bạn muốn Liquid AI d1-omni-600M, đường dẫn cục bộ là đường được mô tả ở trên, và đường dẫn được lưu trữ là API riêng của nhà cung cấp và bất kỳ nền tảng bên thứ ba nào đón nhận nó.

Điều mà việc đóng gói thay đổi là hình dạng của hệ thống xung quanh nó, và đó là nơi chúng ta hữu ích. Một mô hình ra quyết định hầu như không bao giờ là toàn bộ quy trình: phiếu yêu cầu mà nó gắn nhãn, khung hình mà nó gắn cờ và bản ghi thoại mà nó định tuyến vẫn phải được trả lời, tóm tắt hoặc chuyển cấp bởi một thứ gì đó viết văn bản. Những lệnh gọi sinh tạo đó nằm sau một khóa tương thích OpenAI cho hơn 200 mô hình được lưu trữ theo giá niêm yết của nhà cung cấp, được chuyển qua với mức cộng giá 0%, vì vậy thay đổi giá từ nhà cung cấp đến với bạn ngay trong ngày thay vì vào một hợp đồng mới. Và vì d1-omni-600M được phát hành mà không có bằng chứng độ chính xác độc lập và không có độ trễ được công bố, cách đúng để đưa nó ra trước lưu lượng thực là đặt sau cơ chế chuyển đổi dự phòng tự động giữa các nhà cung cấp — hãy để nó xử lý những lệnh gọi mà nó đủ tự tin, và giữ một tuyến thoát khi nó không đủ tự tin, thay vì biến 587M tham số thành điểm lỗi đơn lẻ cho bước phân loại ưu tiên của bạn. Quyết định vẫn ở cục bộ; cơ chế dự phòng không nhất thiết phải như vậy.

Điều gì sẽ thay đổi cách đọc này?

Bốn điều, mà bất kỳ điều nào trong số đó cũng sẽ biến một ghi chú đóng gói thành một bài viết khác. Ollama ghi tài liệu về âm thanh trong lược đồ yêu cầu của System One, điều này sẽ biến mẹo WAV-trong-ảnh của readme thành một đầu vào được hỗ trợ và khiến đây trở thành mô hình quyết định có khả năng xử lý giọng nói đầu tiên mà bạn có thể chạy bằng một lệnh. Một trong hai công ty công nhận bản port — Liquid AI thêm d1-omni vào trang Ollama trong tài liệu triển khai của mình, hoặc Ollama liệt kê nó dưới mục mô hình quyết định thay vì thị giác. Một con số tốc độ từ bất kỳ ai, dù là nhà cung cấp hay không, vì hiện nay chưa có con số nào. Và một dòng Decision Index độc lập cho bất kỳ mô hình d1 nào, thứ vẫn là mảnh ghép còn thiếu duy nhất trong toàn bộ dòng mô hình.

Cho đến lúc đó, quyết định vẫn rõ ràng. Nếu bạn đã chạy Ollama 0.40.4 trở lên, lệnh pull chỉ là một lệnh, bản tải xuống là 850 MB, và thứ bạn nhận được là một bộ phân loại 587M trả lời các câu hỏi được gõ trong một lượt truyền xuôi duy nhất trên văn bản và hình ảnh — và, nếu readme đúng, trên 30 giây tiếng Anh nói. Nếu trạng thái của bạn dài, hãy ghi nhớ cửa sổ 16.384 token và ngân sách văn bản 896 token thay vì huy hiệu 125K. Và nếu bạn cần bằng chứng rằng nó chính xác trước khi nó gắn nhãn bất cứ thứ gì khách hàng nhìn thấy, bằng chứng đó chưa tồn tại, đối với mô hình này hay bất kỳ mô hình anh em nào của nó.

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.