Glimpse vs Granite 4.2 3B：一個揭露一切，一個揭露一種行為

把兩份規格表並排放在一起，比較起來會以一種不尋常的方向嚴重失衡。G​ranite 4.2 3B由 I​BM 於 2026 年 8 月 25 日以 Apache 2.0 授權發布，隨附的模型卡列出了層數、注意力頭幾何、RoPE 基底、正規化 epsilon、激活函數、嵌入權重共享、隱藏維度、建議取樣溫度，以及團隊選擇公布的每一列基準測試成績。E​lorian G​limpse於 2026 年 10 月 16 日發布，隨附的是一段 0.9 秒的影片軌跡。它沒有公布參數量、沒有上下文視窗、沒有指名基礎模型，也沒有架構說明。這兩者之中，一個告訴你一切，唯獨沒說它是用來做什麼的；另一個則明確告訴你它是用來做什麼的，卻對它是什麼隻字未提。

那才是這項比較真正的軸線，而這並不是這兩場發布所引你去關注的軸線。G​ranite 4.2 3B 是一款可自行託管的推理模型，其規格讓你在下載之前就能先行審核。G​limpse 則是一項託管式研究預覽，其對外公布的全部能力就是一種行為——回到它已經看過的某段影片中的某個時刻，以更密集的影格率重新掃描，並依據在那裡所見的內容作答。兩者都不在我們的產品目錄上，而這一點在這裡的重要性不如往常，因為在它們之間做選擇，主要並不是一個路由決策。

兩次發布，兩種截然不同的披露策略

IBM 的 Granite 4.2 系列以三種規模提供密集推理——3B、8B 與 30B——其中 3B 是三者中最小的。它是從 Granite-4.1-3B-Base 後訓練而來，採用模型卡所述的三階段流程，並保留該系列原生的 128,000 詞元上下文視窗，且有文件記載可擴展至 512,000。模型卡列出十二種經測試的語言。模型卡公布了完整架構：40 層、嵌入維度 2,560、隱藏維度 8,192 的 SwiGLU 前饋網路、40 個查詢頭與 8 個鍵值頭、頭部大小 64 的分組查詢注意力、RoPE 基底一千萬、RMSNorm 的 epsilon 為 1e-5、未綁定的嵌入、bfloat16 權重，服務類別為 GraniteForCausalLM。建議的取樣參數為 temperature 1.0 搭配 top-p 0.95。

Elorian 的 Glimpse 貼文並未公布其中任何內容。它反而公布了一套機制。在隨模型發布的詳細追蹤記錄中，Glimpse 以約每秒 8 幀對一段影片進行第一遍處理，形成初步判讀，接著以約每秒 14 幀回到該片段中十分之九秒的區間，以解決第一遍無法確定的問題——在公布的範例中，就是攝影機是平移還是切換鏡頭。第二條追蹤記錄從約 2.2 秒處開始追蹤某個視窗邊緣，直到它在 5.13 秒時幾乎停止。該公司將這個顯示介面稱為視覺暫存空間，並表示該模型已接受端到端訓練，以使用多模態工具，並會衍生出交換文字、圖像與內部表徵的子代理。

這兩者都是合理的發布策略，而它們以相反的方式失敗。一張把所有資訊都公開的模型卡，仍可能對模型擅長什麼判斷錯誤。一篇公開機制的文章，仍可能只是在描述一個展示。

已發布的規格，逐維度

• 參數 — G​ranite 4.2 3B 是一個稠密的 30 億參數模型，若把嵌入表計入，以 bfloat16 計算約為 4B。E​lorian 從未公布 G​limpse 的參數量；發表文中唯一提及規模的說法，是聲稱它比其所對標的前沿系統「小得多、也便宜得多」的模型。

• 上下文視窗 — Granite 4.2 3B 原生支援 128,000 個 token，並有文件記載可擴展至 512,000。Glimpse 則尚未公布；由於其主打能力是讀取影片，這是規格表上最關鍵的一項空白。

• 權重 — G​ranite 4.2 3B 在 Hugging Face 上以 Apache 2.0 授權：下載它、在自己的硬體上執行、微調它、發布它。G​limpse 則沒有。它是一個 API 與聊天介面，可免費註冊，而這則貼文完全沒有暗示權重即將推出。

• 託管可用性 — IBM 在 3B 發佈時並未推出第一方託管 API；卡片就是交付項目。Glimpse 則相反：僅提供託管服務，沒有可保留的產物。

• 價格 — Glimpse 每百萬個輸入 token 為 0.60 美元，每百萬個輸出 token 為 3.00 美元。至於 Granite 4.2 3B，則完全沒有價目表，因為成本就是電費，以及你已經擁有的硬體。

• 獨立評估 — 兩者都沒有值得一提的。Granite 4.2 3B 的數字出自 IBM 自己；Glimpse 的數字出自 Elorian 自己。在這個特定面向上，這兩個發布版本同樣未經獨立驗證，這一點值得直說，以免有人把其中一方當成可信的那一半。p>img src="3.png" alt="一張標題為「Glimpse 對比 Granite 4.2 3B — 資訊揭露落差」的計分板，副標題為「六個面向，雙方並列，相同標籤」。兩個欄位共用相同的六個列標籤。左欄標題為「Elorian Glimpse」，內容為「參數：未公布」、「上下文：未公布」、「權重：無；僅提供 API 與聊天介面」、「基礎模型：未具名；僅描述為開放權重」、「已發布產物：一篇附有實例推導的發布文章」、「可在你的硬體上驗證：否」。右欄標題為「Granite 4.2 3B」，內容為「參數：稠密 3B，bfloat16 下約 4B」、「上下文：原生 128,000，擴展後 512,000」、「權重：Apache 2.0，於 Hugging Face 上」、「基礎模型：Granite-4.1-3B-Base，已具名」、「已發布產物：完整模型卡、架構、取樣預設值」、「可在你的硬體上驗證：是」。頁尾一行寫著「Glimpse 的數字為廠商自行報告且未經重現。Granite 4.2 3B 的數字依 IBM 公布的模型卡；3B 未公布代理式基準測試。」OrcaRouter 標誌位於右下角。" />

為什麼這兩者不是替代品

有一種誘惑，是將 30 億參數的模型與一款規模成謎的預覽版對立起來，比作大衛對抗歌利亞——但這種框架在兩個方向上都是錯的。

Granite 4.2 3B 是一個推理與指令遵循模型。其已公布的評估結果為 AIME 2025 達 78.33、HMMT February 2025 達 66.67、GPQA 達 54.80、LiveCodeBench v6 達 69.71、MMLU-Pro 達 67.84、IFBench 達 74.33、BFCL v4 達 52.41，以及 RULER 在 64K 輸入下達 67.52，並在 128K 時降至 55.30。注意那份清單少了什麼：在 3B 規模下沒有 SWE-Bench 那一列，也沒有 Terminal-Bench 那一列，儘管該系列中較大的成員帶有一個代理式強化學習階段。IBM 選擇不為最小的同系列成員公布代理式程式編寫數字，而不是加以估算；這種誠實比硬塞一列數字更有資訊價值。

G​limpse 並未在任何這些軸線上競爭。E​lorian 自家的比較表將它排在 GPT-6 Astra 之前，領先於 WGO Bench（42.70 對 39.42）、CharXiv-R（92.90 對 92.10）、UGC-VideoCap（82.66 對 80.32）與 FSC-147（83.36 對 82.02），而在 BabyVision（95.36 對 97.68）、DREAM-1K（76.04 對 79.05）、TOMATO（93.60 對 96.02）、Video-MME v2（56.68 對 64.06）、CountQA（82.66 對 86.42）與 Humanity's Sixth Sense（46.36 對 53.6）上則落後。上述每一列皆為廠商自行回報、未經重現，並在 G​limpse 的最高思考強度設定下、以其原生代理框架執行，且附註披露若干競爭對手是在低於其最高設定的情況下接受評估。G​ranite 4.2 3B 從未在上述任何一項基準上受測過。

所以，誠實的情況是：並沒有共用的計分板，因為並沒有共同的任務。3B 文字模型無法重新掃描一段影片區間，而影片倒轉預覽也無法下載到筆電上。

當規模論點反其道而行時

在這項比較中，Granite 4.2 3B 最有力的理由並非效能，而是 30 億稠密參數本身就是一種真實可行的部署形態。以 4B bfloat16 而言，權重只佔幾 GB，這意味著量化版本可跑在單一消費級加速器上，或在低精度下跑在近期的筆電上。十二種受測語言對於歐洲或印度的部署已經足夠——在那些場景裡，十二種語言的支援路徑是硬性要求，而非可有可無的加分項。Apache 2.0 徹底免除了授權方面的顧慮。而 128K 視窗搭配 512K 擴充是有文件記載的，這意味著據此進行容量規劃是算術問題，而不是憑空猜測。

Glimpse 最強而有力的理由，在於一件沒有小型模型等效方案的事：固定排程取樣無法回答的問題。攝影機是平移還是切換。第 12 秒畫面中的物件，是否就是第 4 秒離開畫面的同一個物件。某個事件前後半秒內發生了什麼。這些問題之所以困難，不是因為它們需要大型模型，而是因為那些資訊從未被取樣，而每秒 8 幀下增加更多參數也無法找回。在整段影片看過之後，對某一個時間區間額外投入運算，是真正不同的答案，而 3B 套件中再多的開放權重也無法取代它。

託管預覽唯一無法觸及的地方

有一個出於合規考量的理由值得關注這種不對稱，而這與任一模型的品質無關。

Granite 4.2 3B 的交付物是一個檔案。如果影片、文件或客戶紀錄無法離開你的基礎架構——而在多數受監管的部署中確實無法——那麼模型就在資料所在之處執行，供應商可用性、速率限制、區域與保留等整個問題便不復存在。Glimpse 沒有這種選項。它的能力只存在於 Elorian 的端點之後，這意味著影像素材會送往 Elorian，且沒有任何已發布文件另有說法。

這正是路由層值得用一句話交代的地方，也是它不值得的地方。OrcaRouter 讓你在 200 多個模型前面只用一把金鑰，以供應商定價原樣傳遞，每個 token 不加收任何費用，因此同一條程式碼路徑上的工作負載，可以把跑在自家硬體上的自架 G​ranite 4.2 3B 與託管模型混用，而且當其中一個掛掉時，自動容錯移轉能讓路由維持運作。路由 DSL 決定哪個模型處理哪個請求，應用程式無須改寫。它做不到的，是改變保管權的問題：路由層只是在端點之間移動請求，而如果某個端點不在你的機房裡，路由也沒辦法把它搬進去。我們今天的目錄上既沒有 G​ranite 4.2 3B 也沒有 G​limpse——G​ranite 4.2 3B 是一個下載項目，而 G​limpse 是 E​lorian 自家的 API——所以這是在陳述我們如何路由與定價，而不是聲稱能提供其中任何一個。

以同樣的懷疑閱讀兩份基準表

有兩個習慣值得沿用到這兩個版本中，因為兩者都擺脫不了它們。

第一點是，供應商的基準測試表是一種選擇，而非一種測量。Elorian 的表格不尋常之處在於，它公佈了自己模型落敗的列——這是一個可信度信號，而且它仍然是供應商彙編的表格，任務是供應商選擇的，配置是供應商設定的。IBM 的 Granite 模型卡更狹窄且更傳統：標準的學術基準，在指定的配置下公佈，而在 3B 時，代理行只是缺失，而不是被一些美化的東西取代。

第二點是，缺失的那個數字往往才是真正撐起全局的關鍵。以 G​ranite 4.2 3B 來說，真正重要的數字根本不在規格表上：I​BM 以外沒有人發表過 3B 在 128K 上下文下的吞吐量或實際任務準確率，而 RULER 在 64K 與 128K 之間從 67.52 掉到 55.30，正是一記警訊——這個視窗早在結束之前就已劣化。至於 G​limpse，真正關鍵的缺失數字是上下文視窗，因為一項影片推理功能，若其視窗裝不下真實工作流程交給它的素材，那就只是示範，而不是工具。

什麼能讓這件事有個了結，以及在此期間該怎麼做

有三件事會改變這個比較結果，而它們全都還沒發生。

一套能重現任一組數據的獨立評估框架將是首例。E​lorian 的 G​limpse 表格與 I​BM 的 G​ranite 4.2 3B 模型卡都是自我報告，且針對不同任務；而這兩次發布在恰好一個維度上完全相同：缺乏外部驗證。

Glimpse 公布其上下文視窗、參數數量或基礎模型，會是第二件事。目前流傳關於 Glimpse 規模的任何數字都是估計值，而非正式揭露；把估計值當成規格，正是容量規劃出錯的原因。

G​ranite 4.2 3B 若獲得 agentic-RL 階段，或取得第一方託管端點，那會是第三個。任一項都會改變 3B 所處的賽道。

在那之前，決策規則很短。如果工作是文字、如果它必須跑在你掌控的硬體上、如果授權必須是 Apache 2.0，或者如果資料不能跨越網路邊界，G​ranite 4.2 3B 就是答案，而 G​limpse 的問題根本不會出現——把它下載下來、自己跑一次評估，並把規格卡上缺漏的 agentic 列當成一條界線，而不是一個缺口。如果工作是影片，而失效模式是時間性的而非語意性的，G​limpse 就是兩者之中唯一其所述機制以此為目標的那一個，免費註冊讓試用變得很便宜，而軌跡本身就是測試：跑一段短片、讀取視覺暫存區，然後檢查模型是否曾經回到那個決定了答案的區間。目前，兩者都尚未經過驗證。而只有其中一個能在你自己的硬體上被驗證。

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