SubQ Snap 1.1 對比 Granite 4.2 3B：每 Token 價格是錯誤的帳單

IBM 的Granite 4.2 3B標價為每百萬輸入 token 0.03 美元。SubQ Snap 1.1標價為 0.04 美元。如果每 token 費率就是帳單，這個 30 億參數的 Apache-2.0 模型就會擊敗在 Artificial Analysis Decision Index v1.0 上並列第一的決策模型，而這篇文章就會很短。費率不是帳單。一旦你計價的是一次決策，而不是一個 token——包括每個模型為了產生一次決策必須輸出什麼——排名就會翻轉，又會因單一組態設定翻轉回來，最後落在兩家廠商都沒有宣傳的地方。

Granite 4.2 3B 是 IBM 的小型稠密推理模型，於 2026 年 8 月 25 日與 8B、30B 同系列模型一同推出，卻異常低調——只有一篇技術部落格文章，而非發表會。Snap 1.1 是 Subquadratic 的決策模型，自 2026 年 10 月 22 日起上線，會從固定答案集中回傳一個選項，而非生成文字。它們恰好只在一項工作負載上重疊：接收一段文字並判定它是什麼。除此之外，它們的一切都不同，包括「便宜」所指的意思。

首先，這兩個模型實際上究竟是什麼

Granite 4.2 3B 是一款三十億參數的稠密解碼器，建構於 Granite-4.1-3B-Base 之上。它是一款推理模型，具備三種模式：會輸出思維鏈的思考模式、低投入模式，以及直接作答的非思考模式。IBM 公布 AIME 2025 為 78.33、GPQA 為 54.80、LiveCodeBench v6 為 69.71、MMLU-Pro 為 67.84、IFBench 為 74.3、τ³-Bench 為 45.8——以上皆為廠商數據，均未經獨立復現。在長上下文方面，其公布 RULER 在 64K 為 67.52，在 128K 為 55.30。Artificial Analysis 將其智慧指數評為 9，以絕對值而言並不突出，但高於同尺寸級別的中位數。

硬體部分才是有趣的地方。它在 bf16 下佔用六到八 GB，量化後則低於兩 GB，這意味著一部筆電、一張消費級 GPU，或是一顆記憶體足夠的 CPU 就能執行。它僅支援文字，涵蓋十二種語言，支援 OpenAI 相容的工具呼叫，並提供 vLLM、SGLang、Transformers、GGUF、llama.cpp、MLX 與 Ollama 版本。如果你的限制是「必須在我能掌控的地方運行」，這個模型完全符合。

SubQ Snap 1.1 幾乎在各個層面都是相反類型的產品。它沒有權重。它僅透過 Subquadratic 的 API 執行。它可接收最多 384K 個 token 的文字與圖像，外加一組包含 2 到 255 個選項的答案集，並回傳一個附有校準機率的選擇結果。它無法寫出一個句子，而這正是重點：沒有輸出需要解析，也沒有輸出需要付費。

輸出 Token 陷阱

這就是逐 token 比較所掩蓋的算術。假設有一百萬次路由決策，每次讀取 6,000 個 token 的工單文字——對中型支援營運來說，這是合理的每月量；對大型營運來說，則是一個忙碌下午的量。那就是六十億個輸入 token。

• Granite 4.2 3B 在非思考模式下 — 600 萬個輸入 token，每百萬 $0.03，共 $180；再加上每次決策約五個輸出 token，也就是 500 萬個輸出 token，每百萬 $0.12，共 $0.60。總計：約 $180.60。

• Granite 4.2 3B 在思考模式下 — 6B 輸入為 $180，加上每次決策可能 800 個推理 token，或 800M 輸出 token、每百萬 $0.12，共 $96。總計：約 $276。

• SubQ Snap 1.1 — 6B 輸入 token 以每百萬 $0.04 計算為 $240，而且完全沒有輸出項目。

所以誠實的答案是三個不同的答案。設定為直接回答時，Granite 比 Snap 便宜 25%，文章真的可以到此為止。設定為思考時，Granite 比 Snap 貴 15%，因為推理 token 是整條管線中最昂貴的東西，而且沒有人為它們編列預算。Snap 的優勢從來不是它的輸入費率——它比 Granite 高 33%——而是其架構根本沒有辦法把 token 花在深思熟慮上。

這不是理論上的風險。Artificial Analysis 對 Granite 4.2 3B 的獨立剖析稱該模型「非常冗長」，並記錄到它在 Intelligence Index 上接受評估時產生了 9,200 萬個輸出 token，而可相比模型的輸出 token 中位數為 6,700 萬個。這種冗長程度是該模型在推理模式下經測量得出的特性，而這項特性決定每 token 的價格優勢在面對路由工作負載時是否仍能成立。

Artificial Analysis 將 Snap 1.1 估算為每百萬個任務約 30 美元，而 Elephant 9B 則是 8.4 美元。每百萬個任務 30 美元意味著平均任務非常短，大約只有數千個 token。Decision Index 的基準組合偏短。你的工單、合約與日誌則不然，而且成本會從此隨著輸入長度呈線性增長。請將每任務數字視為該基準的特性，而非報價。

3B 真正勝出之處

更便宜的 token 只是最不重要的一點。Granite 4.2 3B 可在 Apache 2.0 下自架，這意味著一旦硬體成本付清，就完全沒有每次呼叫的費用、資料不會離開你的網路、沒有速率限制，也沒有廠商能背著你更改價格或模型。對於受合規約束的工作流程，這不是偏好，而是必要條件，而 Snap 1.1 根本無法進入那個場域。

它還能做更多事。它會在路由決策之後撰寫摘要。它能處理帶有結構定義的工具呼叫。它支援可選擇啟用的 512K 上下文擴展，這是在第五個預訓練階段加入的；帳面上比 Snap 的 384K 更長。不過，它的 RULER 分數從 64K 時的 67.52 下降到 128K 時的 55.30，這對那個上下文窗口有多少比例真正可用，是個合理的警示。而且它小到可在邊緣執行，放在應用程式旁的容器中，決策與動作之間不必經過任何網路跳轉。

Snap 1.1 真正勝出之處

3B 生成式模型在構造上不擅長的三件事。

首先是校準。Snap 1.1 回報的預期校準誤差為 0.014，低於預覽版的 0.108；對於無法回答的問題，拒答率為 86%——相較之下，其自家 1.0 版本在廠商代理指標上的非幻覺分數為 0.7%。這些是廠商提供的數字，也應如此解讀，但它們描述的是一個以拒答作為明確目標來訓練的模型。3B 推理模型沒有這樣的目標。問它一張工單是否可答覆，無論哪種情況，它都會產出一句看似合理的句子。

長上下文單次處理行為是第二點。Snap 在一次前向傳遞中處理 384K 個 token，且每個 token 的計算量固定，而這正是 Subquadratic Sparse Attention 的全部依據。Granite 的 RULER 衰減，是稠密模型在其舒適長度十倍時的正常行為。如果你的決策取決於某個埋在日誌包中第 200,000 個位置的內容，那麼這項架構差異可不是紙上談兵。

輸出形狀的確定性是第三點，而且它被低估了。Snap 會在你的選項清單中回傳一個數字。Granite 則回傳文字，讓你之後再解析，而每個解析器都是格式錯誤的答案可能變成服務中斷的地方。受限解碼縮小了大部分落差，這點值得說明——它不是根本上的優勢，而是你得寫多少輔助程式碼的差別。

沒有人會問的設定問題

如果你正將 Granite 4.2 3B 當作路由器使用，你能做的最有價值的一項變更，就是關閉思考模式。IBM 正是為此推出該模式，而上面的算術說明了原因：當要求推理模型從五個標籤中挑選一個時，它往往會花八百個 token 來論證一個非思考模式一次就能做對的決定。在假設思考模式更好之前，請先用你自己的資料對兩種模式進行基準測試。在答案集固定的任務上，思考模式經常並非更好。

Snap 的對應手段正好相反：你要給它更少、更犀利的選項。其 API 將問題上限設為十六個，每題的備選項上限為 255 個，而它在 Decision Index 上的準確率是 20%——低於 d1-ultra 的 32%——且其指數分數是靠棄權撐起來的。縮小答案集，準確率問題就會隨之縮小；交給它一項開放式判斷，它就會拒絕，而且拒絕得正確、也經常拒絕。

我實際會打造的東西

對於具一定規模的支援或文件處理流程，最便宜且站得住腳的設計是兩階段架構。Granite 4.2 3B 以非思考模式運行，作為第一道分類器，處理容易的大多數情況——那些明顯是退款、明顯是服務中斷、明顯是垃圾訊息的工單——在這些情境中，3B 模型準確，且邊際成本為零。Snap 1.1 處理剩餘部分：長串對話、模糊案例，以及正確答案可能是「升級處理」，而自信猜測比拒答更糟的情況。你只需為需要它的那一小部分支付每百萬個 token 0.04 美元，並且在真正需要校準的決策上，得到經過校準的機率。

兩家供應商都不販售那樣的設計，因為各自都想包辦整個層級。Granite 4.2 3B 不在 OrcaRouter 的目錄中——它是 Apache 2.0，因此自行託管是常規做法，而且也有多家推論供應商提供。Snap 1.1 也不是我們的；它透過 Subquadratic 自家的 API 執行。OrcaRouter 對這類設計的貢獻，在於其背後的生成層級：用單一金鑰即可存取 200+ 個模型、供應商牌價以 0% 加成直接轉嫁，以及自動容錯移轉，因此負責撰寫升級摘要的模型，與負責決定是否升級的模型，不會是同一個相依項目。

值得關注的是，當由其他人來執行 Snap 1.1 時，它的校準是否仍站得住腳。它 20% 的準確率是其自家發布資料中最弱的數字，而這正是決定上述兩階段設計是否比表面上看起來更便宜的那個數字——Snap 越常棄答，就有越多工作回落給必須真正給出答案的那個階段。