Liquid AI d1 視覺更新：決策模型省下聊天，19–200 倍成本宣稱怎麼看？（2026）

2026 年 10 月 5 日，Liquid AI 在官方部落格發布了〈Introducing d1: The most capable decision model, now with vision〉，讓 Liquid AI d1 的決策介面加入影像。此前已有文字版；OpenRouter 模型頁把上架日期列為 10 月 1 日。這次值得追的是：看完圖片之後，模型能否把結果直接交給程式，而少走一段聊天生成？

先看原文提出的能力，再核對決策格式與成本條件，最後判斷什麼工作值得試。重點不是讓 AI 少說話，而是把「判斷」與「解釋」分成不同的工作。

Liquid AI d1 更新：照片進來，機率出去

now supporting both text and images.

中文：現在同時支援文字與影像。

Liquid AI，d1 發布原文

這段原文的改變可以在 Liquid 決策模型文件核對：付費 d1 可接收影像，免費 d1:free 仍限文字。輸入是情境、問題與選項；回傳是結構化判斷，usage.output_tokens 為零。這表示模型不以逐 token 生成文字來作答，不表示傳輸回應沒有 JSON，也不表示推論不耗運算。

官方定義三種問題：Noul 問是或否、Choice 在列出的選項中選一個、Score 依有序評分尺給出機率加權位置。把「正常／缺件／刮傷」先寫清楚，程式便能按回傳機率分流；要求寫一份維修說明，則是另一種輸出需求。

圖中的電路板很能說明這個介面的價值：你交給模型的不是「聊聊這張照片」，而是一個有答案空間的問題。答案空間若漏掉「無法辨認」或某種新缺陷，程式就得另外設置拒絕或轉交的規則；固定選項讓接線更清楚，也把選項設計的責任交回開發者。

原文以六種應用展示方向，數字仍屬公司測試

Liquid 展示視覺檢測；文字任務則讓模型篩客服、逐資料夾找程式、分層歸檔文件、替網頁代理選下一步，以及決定工具回傳要保留、縮短或刪去。遊戲示範呈現兩種視覺作用：補充判斷資訊、直接讀畫面而省去轉寫文字狀態。公司稱，在六種應用中有四種追平或超過 GPT-6.1 Sol，成本比兩款比較模型低 19–200 倍；視覺檢測正確率為 85–97%。這些是 Liquid 的自報成績，本文未獨立重跑。原文另稱文字決策約 200–300 毫秒；這是文字呼叫的公司描述，不能推成影像或整趟代理流程的延遲。原文要推廣的是：有些生成式模型呼叫，本來只需要一個決定。

視覺樣本取自 Amazon Science 公開的 VisA 專案；該專案收錄 12 類物件、10,821 張影像，包含正常與異常樣本，並提供不同評測設定。這能核對資料集的來源，不能替 Liquid 的選樣、正確率或泛化結論背書。資料公開與測試獨立，是兩種不同的證據。

原文檢測時給各模型同一產線的正常品作參照。因此，較準確的理解是「拿待檢品與正常參照做判斷」，不能直接讀成「看任何陌生產線的一張照片，就有相同準確率」。

19–200 倍便宜，先看比較尺上的刻度

Costs use list prices, without prompt-cache discounts.

中文：成本使用公開牌價，未納入提示詞快取折扣。

Liquid AI，d1 發布原文

原文方法學寫明：2026 年 10 月 5 日，每種應用、每款模型各跑一次；比較模型使用預設推理設定、以 JSON 作答，共用輸入的多題會批次處理。d1 採每百萬輸入 token 0.04 美元。這個單次、無快取折扣的條件，必須跟著倍數一起讀。

單次跑完能展示流程，卻不能告訴我們換一批題目後的波動；牌價可以算帳，但若你的既有系統大量讀取快取，自己的成本比例就會不同。同樣地，把模型設定成預設推理，是一個可描述的比較條件，並非每種工作都已找到最省的對照組。

截至 2026 年 10 月 7 日，Vercel d1 價格頁與 OpenRouter d1 價格頁也列出每百萬輸入 token 0.04 美元。這兩個服務能交叉核對牌價；這些頁面不能拿來獨立驗證原文的六項應用成績。若只需要處理固定欄位，也應把規則或你已在用的分類器放進自己的比較，才能知道新模型省掉的究竟是哪一筆費用。

Liquid AI d1 的多題計費：一個請求不等於只付一份影像

官方影像用量文件列出每個 32×32 像素區塊計 1.5 個輸入 token，向上取整。一張 1024×1024 圖片，每題是 1,536 個影像 token；兩題是 3,072，還要加各題文字。每一題都重新計入全部影像，不能因為放在同一 HTTP 請求就當成只付一次。

以 0.04 美元／百萬 token 換算，單題、單張上述圖片的影像部分約 0.00006144 美元；這是按文件公式計算的示例，未含文字、第二張參照圖、重試與其他服務費。若加一張同尺寸正常參照，影像部分會再加一份。真正該量的是每個成功判斷的總費用，而不是把最低一筆影像費當成完整流程價格。

同一請求可以同時回傳數個答案，對程式設計仍有好處；但「少一趟網路往返」和「少一份計費輸入」應分開理解。要做大量照片的多題檢查，先算圖片數 × 題數，再決定哪些問題真的需要模型。

AlphaLab 的判讀：三件事決定它是否有用

一、便宜的判斷，價值取決於錯判往哪裡流

假設客服分錯類，代價可能是多轉一個隊列；工廠把有缺陷的零件放行，代價就完全不同。我的判斷是，d1 適合先放在可回查、可回退的分流位置：保存圖片、選項與回傳結果，讓低把握案例流向既有檢查。不要先用價格決定它的處置權限。

這不是替視覺能力潑冷水，而是挑一個能證明價值的起點。當原本每次都要請生成式模型輸出一段說明，最後只取一個標籤，直接決策值得比較；當產品需要解釋缺陷位置或給修理步驟，就要保留能產出那些內容的後段。模型分工比全套替換更容易驗收。

二、回傳 0.9，還需要知道「九成」代表什麼

機率比單一標籤多了資訊，但不是天然保證。Guo 等人的 ICML 2017 原始校準研究在其研究模型上觀察到：分類正確率較好，仍可能伴隨不準的信心估計。這不是 d1 的測試結果；它提醒我們，拿到機率之後還有校準這一關。

例如在自己的留出樣本裡，整理對所選標籤給約 0.9 機率的判斷，看看它們實際有多少答對；再分開看新光線、新相機與新物件。如果某個子群的高信心錯判特別多，就調整使用範圍或分流門檻。整體平均準確率不能代替這種檢查。

三、視覺更新降低了輸入工程，沒有替你定義成功

以前若要把畫面改寫成文字，開發者得決定描述哪些區域、哪些物件和哪些變化。現在可以直接送圖，這條輸入路徑值得關注；但模型仍須知道要問什麼、可選什麼、什麼算答對。跨產線的泛化，需要用你的資料證明；圖片壓縮、拍攝角度與正常參照，也要固定才能比較。

我同意原文的核心方向：有明確選項的工作，值得測試更直接的決策介面。我存疑的是把公司展示的成本與準確率移植成每個系統的保證。輸出格式解決了一段接線，任務品質與拒絕策略則需要另一份成績單。

現在怎麼試，以及下一個證據該等什麼

先選一個已經有人工答案的窄任務，例如把零件照片分成三類。把同一批輸入留給 d1 與現有流程：固定圖片、參照、題目、選項和成功條件，分別記錄缺陷放行率、正常品誤攔率、低信心比例、完成時間與完整帳單。樣本應同時包含容易題、邊界題與未知類別；先訂失敗門檻，再開始跑。

截至 10 月 7 日，影像入口可從 Liquid Console與 d1 Playground開始核對；Liquid API 文件明列付費 d1 的影像格式。OpenRouter 當前模型頁則明列文字輸入；若你正在走轉接服務，請先確認那條端點的格式，別把原廠影像支援推到每一條路由。

若你想把這份比較做成可維護的驗收，AI Evals 入門能幫你定義題集；Agent 回歸測試能補上禁止動作；模型身分查核則教你保存服務交付收據。最值得追的後續證據，是不同團隊在相同設定的重複結果，以及更換拍攝條件後的錯判與校準表現。

原文另表示，計劃為後續模型開放權重。把它留作可對帳的承諾即可：要看的是實際檔案、模型卡和可執行評測。今天能做的，是先挑一個答案明確的判斷，把每個可驗收結果的成本算出來；若更省、錯判也符合你的要求，再增加範圍。