d1-omni 對比 Liquid AI D1 Omni 600M：兩個名稱、同一個檢查點，以及一個無人能追溯來源的上下文數字

Liquid AI D1 Omni 600M 與 d1-omni 並不是兩個模型，也不是同一個模型的兩個檢查點。它們是同一組權重——Liquid AI 的 587M 參數多模態決策模型，建構於 Liquid AI LFM2.5-Encoder-350M 之上，並於 2026 年 10 月 5 日以 LiquidAI/d1-omni-600M 這個儲存庫名稱發佈於 Hugging Face——卻在兩個不同的目錄中帶有兩個不同的檔名。其中一個目錄是廠商的，告訴你這個模型是什麼。另一個是 Ollama 的，告訴你有人把它打包成了什麼，並在卡片上印出三個廠商文件並不支持的數字。這個落差正是這篇比較值得一讀的原因，因為對這麼小的模型而言，打包方式並非腳註——而是文字與圖像模型，和卡片所說你下載的模型之間的差別。

廠商尚未就 Ollama 條目發布任何公告，Ollama 頁面上也沒有維護者註記、變更記錄或 readme 可以解釋這一切。因此，以下所有內容的誠實框架是：權重是公開且可檢視的，封裝是公開且可檢視的，而本文對封裝的解讀是我們的，不是 Liquid AI 的。若某個數字無法追溯到來源，本文會如實說明，而不是重複它。

這兩個名字實際上究竟是什麼

Liquid AI 在 Hugging Face 上發布了該模型，建立時間戳為 2026 年 10 月 5 日，比它出現在廠商自家於 10 月 7 日發表的部落格文章〈Open d1: Edge decision models for text, vision, and audio〉早了兩天。權重依 Liquid 自家的 LFM 1.0 條款授權，標記為d1_omni、system-one、multimodal、vision、audio與decision-model，截至撰寫本文時已累積約 13,900 次下載與 135 個讚。量化版本則依各自的時程推出：10 月 6 日出現 GGUF 儲存庫，10 月 12 日推出適用於 Apple Silicon 的 MLX 版本。

這個 Ollama 條目並不是那些儲存庫中的任何一個。d1-omni，帶有「vision 600m」徽章、顯示四個標籤，且在此文撰寫前幾分鐘才更新過——這就是雷達會注意到它的原因。其中沒有任何內容提到 Liquid AI、LFM2.5-Encoder-350M，或這些位元組來源的 Hugging Face 儲存庫。

所以實務上的差別在於檔名和散布路徑，而不是模型本身。真正有差異、也真正重要的，是包在這些位元組外層的中繼資料。

Ollama 卡片上的三個數字，逐一檢查

Ollama 的頁面會為每個 tag 印出大小、上下文視窗和輸入清單。這三項都值得再仔細看一下，因為就這個模型而言，其中兩項在與原始碼對照後就站不住腳。

• 上下文視窗——模型卡上寫 125K，但各家廠商原始資料都是 16,384。 Liquid AI 的模型卡載明上限為 16,384 個 token，涵蓋文字、圖像與音訊位置合計，而廠商自家針對 d1-omni-600M 的文件頁面則寫「16K tokens」。125K 這個字串在兩處都沒出現。它可能是底層 LFM2.5-Encoder 架構的位置配置所造成的產物，也可能是 Ollama 回報快取上限的方式所致，但這不是 Liquid AI 公布的數字，也不是本文能歸因於任何人的數字。讓這項落差不止於吹毛求疵的，是再往下看到的那個數字。

• 在影像路徑上，你實際能通過的狀態上限是 896 個 token。Liquid 的卡片上寫著，當有影像存在時，「狀態與問題文字會依訓練方式裁切至 896 個 token」。因此，只要決策請求附帶一張照片，其文字預算大約就是這句話的長度，無論拉取頁面上印出的上下文數字是多少。如果你原本是依照 125K 來估算分診提示詞的規模，並預期要為冗長的狀態付出成本，那你其實是依照一個無法描述實際執行環境的數字在估算。16,384 這個數字才是真正的上限；896 這個數字才是多模態路徑真正的工作限制；125K 則是個沒有書面依據的數字。

• 大小 — 卡片上 850MB，登錄庫中有兩個檔案。 Ollama 標籤 d1-omni:latest 解析為一個 407MB、標示為 Q8_0 的量化權重檔，加上一個 442MB、標示為 BF16 的投影器檔案，而 407 + 442 = 849，頁面將其四捨五入為 850MB。兩者都誠實列出；這個算術只是混合精度配對的總和，而非單一檔案。d1-omni:600m-bf16 標籤是較簡潔的一個：764MB 的 BF16 權重加上相同的 442MB 投影器，磁碟上共 1.2GB，而且投影器在兩個標籤之間位元組完全相同。下一節值得留意，因為帶有自身權重的投影器可以改變有效參數數量。

還有一個細節值得記錄下來，而非加以解釋：Ollama 的 d1-omni 套件內的執行階段參數 blob，與 Ollama 另一個 d1 套件內的參數 blob 位元組長度完全相同——都是 18 位元組；後者搭載 Liquid AI d1-3B，內含 2.87GB 的 Q8_0 權重與 855MB 的投影器。兩套架構、兩種參數量、兩者之間的參數規模相差兩個數量級，卻有著相同的 18 位元組執行階段設定。這是封裝常數，並非對任一模型的宣稱。

權重本身怎麼說

撇開包裝不談，這款模型的文件記載得異常詳盡。Liquid AI D1 Omni 600M 總共有 587M 個參數，分成三部分：381M 的共用主幹與決策頭、94M 的視覺編碼器，以及 112M 的音訊編碼器。主幹是雙向的——這是編碼器，不是解碼器——而且每種模態都共用同一個主幹，再外掛模態專屬的塔狀結構。

• 視覺來自承襲自 Liquid AI LFM2.5-VL-450M 的 SigLIP2 塔，搭配僅在影像輸入時啟用的適配器與 LoRA 更新，而編碼器本身則維持凍結。

• 音訊來自一個 17 層的 FastConformer，它擁有專屬的適配器，先在文字主幹凍結的階段進行微調，接著對整個堆疊進行微調，合併 LoRA，並將權重與先前的檢查點取平均。

• 詞彙量為 65,536 個 token，涵蓋 15 種語言：英文、德文、西班牙文、法文、義大利文、荷蘭文、波蘭文、葡萄牙文、阿拉伯文、印地文、日文、俄文、土耳其文、越南文及中文。

• 模態不能混用。單次請求只能接受文字加圖片，或文字加上最多 30 秒的語音——不能兩者兼具。音訊預期為 16kHz 單聲道，長度介於 0.5 到 30 秒，且是以英語使用者與助理之間的交流訓練而成，這對任何多語言或吵雜環境的應用是一項實際限制。

那些內容都沒有出現在 Ollama 頁面上，而這項遺漏有個後果，你可以直接在使用範例中看到。Ollama 的程式碼片段是聊天呼叫——一個模型字串、一個 messages 陣列、「Hello!」這個詞——而底層檢查點無法回答這些呼叫。它不是聊天模型，也不會撰寫文字。它回傳的是具型別的答案：是/否機率、一個標籤及每個標籤各自的機率，或是有序尺度上的一個位置，全都直接從輸出分佈讀取，且不生成任何輸出 token。已發佈的介面反映了這點：system_one 與 probabilities 透過 Transformers，或一個 /v1/systemone 端點（透過 llama.cpp 0.7.0 及更新版本）。對決策模型發出聊天形式的呼叫，正是這個命名落差所招致的錯誤。

那些數字中的每一個都附帶兩項注意事項。

首先，Liquid 是用官方評分器為自己的資料列評分，而不是將它們提交進行公開排名；且尚無第三方重現任何 d1-omni-600M 結果——廠商在模型卡上明白表示，由於此檢查點是仍在積極開發中的早期研究發布，因此不報告其推論數字。其次，兩個頭條數字彼此不一致：32 點指數差距與 4.5 點基準平均差距描述的是同一個模型，這就是為什麼有用的是子分數，而非總分。Retrieval 為 35.0、Tools 為 15.1，而 Arts 為 6.8，這告訴你這個檢查點已準備好與尚未準備好哪些工作。Audio 完全沒有基準欄位；Liquid 稱專門的音訊決策基準是未解問題。

Liquid AI D1 Omni 600M 也在這七項中的兩項上領先其自家家族：Civil Comments 達 95.8，PAWS-X 達 79.5。這兩列正是 587M 編碼器直接擊敗 3B 解碼器的兩個項目，而兩者都屬於文字分類型任務，而非推理型任務——這與該架構相符，而非與之矛盾。

依你想要什麼來選。如果你想在 Ollama 底下於本機執行，d1-omni 是可行的名稱——Q8_0 版本為 850MB，BF16 為 1.2GB，與 Liquid 文件記載的相同映像路徑，而且兩個標籤都不含音訊投影器。如果你想要廠商描述的那個模型，Liquid AI D1 Omni 600M 才是要搜尋的名稱，而透過 Hugging Face 儲存庫的 Transformers 途徑，其上下文長度、模態清單與參數量都與文件相符。

無論哪種方式，這都是流程中較便宜的一半。決策模型負責分類；還需要其他東西根據分類採取行動。這正是 OrcaRouter 所處的邊界，也是值得精確說明的一點：我們的目錄中沒有 Liquid AI 模型，因此 d1-omni 呼叫本身會前往你目前執行它的地方——將這些權重放在你自己的硬體上，或針對託管版模型使用廠商自家 API 與第三方平台。以單一 OpenAI 相容金鑰存取 200+ 個模型的用途，在於處理下游的一切；費用則以各供應商標價原樣轉嫁、0% 加價，並具備跨供應商自動容錯移轉，當經分流的請求被分發到某個當天狀況不佳的模型時就會啟動。

什麼能解決這個懸而未決的問題？

有三件事可以為這件事收尾，而且其中沒有一件需要廠商發布公告。只要有人把 850MB Ollama tag 的輸出，與 Hugging Face checkpoint 在相同輸入下的結果相比，就能告訴我們封裝方式是否改變了答案。一則 llama.cpp commit 或 Ollama changelog 條目若能解釋這個上下文數字，就能告訴我們 125K 是錯誤，還是模型卡尚未跟上的一項能力。而一個已發布的音訊結果——任何音訊結果——都會讓這個 checkpoint 脫離它目前所在的類別：一個文件記載完備的模型，搭配一層沒有文件說明的封裝層，以及一個完全屬於廠商自己的計分板。

像這次發布背後有紀錄的 AI 失敗與代理事件，都收錄於 OrcaRouter AI Incident Archive，其中每一筆條目都附有各自的來源、嚴重程度、信心評級與爭議標記。