Liquid AI d1-omni-600M 現已可透過 Ollama Pull 取得：一個能聽見你的 600M 決策模型

Liquid AI d1-omni-600M於 2026 年 10 月 17 日 22:32 UTC 成為 Ollama 套件。這個時間戳不是猜測：Ollama 的 registry 會為每個 manifest 提供 ollama-push-time 標頭，而 d1-omni 這個名稱背後的四個 tag 在當晚 22:31:25 到 22:32:13 之間被接受，大約是撰寫本文前四小時。模型本身並不新——Liquid AI以開放權重發布Liquid AI d1-omni-600M，與Liquid AI d1-3B一同於 2026 年 10 月 5 日發布，並在 10 月 7 日的「Open d1」文章中宣布兩者——但直到昨晚，要在自己的硬體上執行具備音訊能力的那個版本，唯一的方法是用設有 trust_remote_code=True 的 transformers 環境，或自行編譯的 llama.cpp 版本。現在只要 ollama pull d1-omni 即可。沒有人宣布這件事：Liquid AI 的部落格沒有，Ollama 也沒有。

包裝本身就是故事，而值得精確說明的是：其中哪些部分已有文件記載。Liquid AI 最近兩篇部落格文章分別是 10 月 15 日的 d1-ultra 與 10 月 13 日的 LFM2.5-24B-A2B，兩篇都未提及 Ollama；該實驗室自家的 Ollama 部署頁面至今仍教你用 ollama run hf.co/LiquidAI/... 直接從 Hugging Face 執行其 GGUF 儲存庫，且從未點名任何 d1 模型。Ollama 的部落格同樣隻字未提——其最新文章是 10 月 16 日的 Reflection's Beam 與 10 月 13 日的 Fly.io 整合。取而代之存在的，是一筆註冊表項目、四個標籤、一個可驗證的摘要，以及一個在這篇文章撰寫期間仍在編寫中的函式庫頁面：該頁面的早期擷取結果顯示「No readme」，四十分鐘後的擷取結果則顯示完整的 Liquid AI 撰寫說明，附有基準測試表與授權條款章節。如果你想要一個有日期、可查核、且落在過去七天內的事件，那個頁首就是。

註冊表實際接受的內容

四個標籤對應到兩個映像檔，這是你在拉取前首先要了解的事。d1-omni:latest、d1-omni:600m 和 d1-omni:600m-q8_0 是同一個 manifest——digest 1ba59f63e836——而 d1-omni:600m-bf16 是第二個，digest c1e95fce6627。雖然廠商自家的 GGUF 儲存庫有發布 F16 主幹，但沒有 F16 標籤。

• 權重層（Q8_0 建置）——來自 d1-omni-600M-Q8_0.gguf 的 407 MB 主幹，加上來自 mmproj-d1-omni-600M-BF16.gguf 的 442 MB 投影器，另有 10.5 KB 授權資料塊與 18 位元組參數資料塊，總計 849,659,968 位元組。

• 回報的大小 — 預設標籤為 850 MB，600m-bf16 為 1.2 GB，兩者皆與函式庫頁面上所列的一致。

執行階段最低需求 — 需要：設定區塊中的 0.40.4，該區塊同時回報 model_family: lfm2、model_type: 380.73M，以及檔案類型 Q8_0。

• 上下文 — 參數區塊會將 num_ctx 固定為 16,384。

• 授權 — 內嵌文字為 LFM Open License v1.0，指名 Liquid AI, Inc. 為授權方，與模型卡上的 lfm1.0 識別碼相符。

那個投影器值得再看一眼，因為它比它所附掛的模型還大。直接從 registry blob 讀取 GGUF 中繼資料會顯示，同一個檔案中有 clip.has_vision_encoder = True 和 clip.has_audio_encoder = True：12 個區塊中共有 197 個視覺張量，使用 768 維嵌入與 256 像素輸入；17 個區塊中共有 641 個音訊張量，使用 512 維嵌入與 128 個梅爾頻帶。這就是 SigLIP2 塔與 FastConformer 編碼器一同隨多模態套件傳遞的原因，也就是為什麼一個 381M 參數的主幹會附在 442 MB 的附件之後。音訊能力實際上就在你下載的套件裡；端點能否觸及它則是之後的問題。

模型有 587M 個參數，而 125K 標章比實際情況還大。

Ollama 的頁面在每個標籤上都標示「125K context window」。但套件本身的 num_ctx 是 16,384，而 Liquid AI 的模型卡也用文字說了同一件事：16,384 個 token 是文字、影像與音訊位置合計，而且每當有影像時，狀態與問題文字會被截到 896 個 token。125K 這個數字有跡可循——主幹 GGUF 帶有 lfm2.context_length = 128000——但那是架構的上限，不是實際可用的視窗，也是最可能誤導正在為長上下文分類器評估替代方案的人之數字。請把 16,384 視為實務上可用的數字，並在狀態中包含影像時，把 896 個 token 的文字視為實務上可用的數字。

其餘的中繼資料印證的是模型卡，而不是行銷文案。主幹是 18 個區塊、1,024 寬的嵌入與 65,536 的詞彙表，而且它不是解碼器：lfm2.attention.causal 為 False。其逐層 KV 頭數讀值為 0、0、8、0、0、8、……，這表示其中大多數區塊根本不是注意力區塊，這是雙向編碼器淵源顯露出來的結果。決策頭是兩個區塊（lfm2.decision.block_count = 2），而廠商保存在 config.json 裡的校準常數也在這個 GGUF 中——選擇題在兩個選項時的溫度為 1.7465，三到五個選項時為 1.3999，六到十個選項時為 1.1751，十一個以上時為 1.3725；是/否為 1.6663；評分題在三到五個等級時為 1.7301，六到十個等級時為 1.0。這就是整體設計集於一處：一組固定的具名答案，一次完成評分，依題型校準，最後是 output_tokens: 0。

它不是聊天模型，也不撰寫文字。Liquid AI 列出十五種語言，但音訊訓練資料僅有英文——內容為講者與助理之間的請求——且片段長度上限為 30 秒。該說明卡也警告不要在 GPU 上使用 bfloat16：在供應商自家的檢測中，它改變了 0.8% 文字列與 1.7% 音訊列的首要答案，而 float16 則在所有項目上都與 float32 一致。

音訊存在於權重中，而未出現在有文件記載的 API 中。

在提交 bug 前，這是值得知道的差異。由 Liquid AI 撰寫的套件庫頁面 readme 說明音訊的方式，是把 base64 WAV 放進 /v1/systemone 請求的 images 陣列中。廠商針對同一個檢查點的 Hugging Face GGUF readme 則以不同方式說明：用 files 陣列將 data:audio/wav;base64,… 帶入 llama.cpp 伺服器。而 Ollama 公布的端點參考文件則兩者都沒記載：其請求結構描述包含 state、images、questions 與 keep_alive，並將 images 描述為「需要具備視覺能力的模型，例如 Clef」，且完全沒有 audio 欄位，也沒有 files 欄位。同時，Ollama 自己的決策模型指南將 Nimble、Tev1、Clef 與 Clef Flash 列為決策模型，並且只說 Clef 模型也能判讀影像。

所以，Ollama 目前對音訊最誠實的立場是：編碼器已驗證存在於 blob 中，廠商的 readme 說它可透過圖片運作，而已發布的 schema 並未納入它。同一模型的圖片輸入則有較穩固的依據——視覺是 System One 已有文件記載的能力，且 d1-omni 出現在 Ollama 的視覺分類清單中。還有兩個較小的文件落差與此並存：端點參考文件允許選擇題最多有 255 個選項鍵，而決策指南說的是 2 到 26；此外，套件的執行環境最低版本 0.40.4 高於端點文件所引用的 0.35.0。

歸類於願景，而非決策

Ollama 的模型搜尋會把決策模型歸入各自的分類。該分類包含九個項目——nimble-v3、pplx-decider、kev、tev1、nimble、clef-flash、clef、laya 和 strands-decider——而 d1 與 d1-omni 都不在其中。d1-omni 頁面被標記為 vision 和 600m，而且它確實出現在 vision 列表中，因此瀏覽「decision model」的讀者不會找到最新的那個。這是可發現性問題，而非能力問題，但如果你原本打算在 Ollama 自家目錄中比較各決策模型家族，並因此斷定這個模型不存在，這點就很重要。

這也意味著，d1-omni 是 Ollama 函式庫中第一個能夠接收語音的決策模型——音訊編碼器包含在套件裡，而那份九個模型的清單中，沒有其他模型帶有這樣的編碼器。端點是否會把你的 WAV 交給它，是上一節留下的未解問題，而且這是最有可能在你讀到這裡時已經改變的一件事。

這些數字，以及每一個數字分別是由誰產出的

每一項附在Liquid AI d1-omni-600M上的準確率數字，都是 Liquid AI 自家的；就我們所能查到，目前存在的任何 d1 模型都沒有獨立評測——沒有排行榜上的列名、沒有第三方跑分，也沒有任何已公布的對廠商評分方式的駁斥。廠商是用官方的 Decision Index 評分器自行為兩個 d1 checkpoint 打分，而不是把它們提交到公開排行榜，並在模型卡上如此說明；其表格中每一個競爭對手的列都來自 leaderboard v0.2.1，這意味著這項比較是把一個自評分數擺在外部分數旁邊。

• 決策指數 0.2.1 — d1-omni-600M 為 15.95（知識 8.3、語言 12.9、檢索 35.0、工具 15.1、藝術 6.8），相較於 d1-3B 的 48.57。

• 以基準測試作為決策依據，七項平均 — d1-omni-600M 為 78.4，d1-3B 為 82.9；600M 模型在 Civil Comments（95.8 對 93.0）與 PAWS-X（79.5 對 76.9）上領先，在 BoolQ（77.7 對 86.7）與 SQuAD 2.0（74.0 對 85.3）上落後。

Fast Decisions，dev split — 76.9，由廠商自行回報，未公布比較列。

• 速度——無。模型卡明確指出，由於這是仍在積極開發中的早期研究版本，因此未報告推論數值，所以你在其他地方看到的任何延遲聲稱，都是他人自行測量的結果。

• Ollama 頁面上的範例數字 —— readme 的實作範例顯示 urgent 以 0.998 作答、technical 為 0.995。這些只是單次請求的示意輸出，由執行環境所公布，並非基準測試。

15.95 與 48.57 之間的差距是這張卡上最有用的資訊，因為它用廠商自己的說法解決了選購問題：README 告訴你，當文字與影像的準確度是重點時就用 d1；當模型大小是重點，或你需要音訊時，就選 d1-omni。一個在七項公開基準上得分 78.4 的 587M 模型，若改從決策角度來看，是合理的邊緣分類器。它不是 3B 的縮小版。

OrcaRouter 適合的地方，以及不適合的地方

我們不提供此模型。我們在 10 月 18 日檢查目錄，傳回 208 個模型 ID，其中沒有一個來自 Liquid AI，因此這裡並非可用性聲明，我們這邊也沒有任何途徑可以取得它。若你想要Liquid AI d1-omni-600M，本地路徑就是上述的方式，而託管路徑則是供應商自家的 API，以及任何採用它的第三方平台。

封裝所改變的是其周邊系統的形態，而這正是我們有用武之地。決策模型幾乎從來不是整條管線：它所標記的工單、所標示的影格，以及它所路由的逐字稿，仍然必須由某個能撰寫文字的元件來回覆、摘要或升級處理。這些生成式呼叫位於一個與 OpenAI 相容的金鑰之後，即可使用 200+ 個託管模型，並依供應商牌價、以 0% 加價轉供，因此供應商價格變動當天就能反映到你這裡，而不是等到簽新合約。而且，由於 d1-omni-600M 出貨時沒有獨立的準確度證據，也沒有公布延遲數據，要讓它面對真實流量，正確做法是把它放在跨供應商的自動容錯移轉之後——讓它處理它有把握的呼叫，並在沒有把握時保留一條退路，而不是讓 587M 個參數成為你分診步驟的單一故障點。決策留在本地；備援則不必如此。

什麼會改變這個讀數？

四件事，任何一件都會讓一篇封裝筆記變成另一篇不同的文章。Ollama 在 System One 請求結構描述中記錄音訊，這會把 readme 裡「把 WAV 放進 images」的技巧變成受支援的輸入，並讓它成為第一個用一個指令就能執行、具備語音能力的決策模型。兩家公司中任一間承認這個移植——Liquid AI 在其部署文件中把 d1-omni 加到 Ollama 頁面，或 Ollama 把它列在決策模型而非視覺模型之下。來自任何人（無論是不是廠商）的速度數字，因為目前完全不存在。以及任一 d1 模型的獨立 Decision Index 資料列，這仍是整個系列中唯一缺少的一塊。

在那之前，決定很直接。如果你已經在 0.40.4 或更新版本上執行 Ollama，pull 只要一個指令，下載量是 850 MB，而你得到的是一個 587M 分類器，能在單次前向傳遞中，針對文字與影像回答以文字輸入的問題——而且，如果 readme 沒錯的話，還能處理超過 30 秒的英語語音。如果你的狀態很長，請記住 16,384 token 的視窗與 896 token 的文字預算，而不是 125K 徽章。而且，如果你需要在它標記任何顧客會看到的內容之前，先取得它準確的證據，那麼這種證據目前還不存在，對這個模型或它的任何同系列模型都一樣。

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