Glimpse vs Kolibri：為每個詞元購買更多算力的兩種方式

Elorian Glimpse 與 Kolibri 是同一道經濟問題的兩種答案——如何讓每單位運算取得更多能力——而它們正位於這個問題的兩端。Glimpse 由 Elorian 於 2026 年 10 月 16 日發布，它在推論時換取能力：先以約每秒 8 幀對一段短片跑第一遍，然後在回答前額外花費運算資源，以約每秒 14 幀重新掃描所選的十分之九秒。Kolibri 由 Aleph Alpha 於 2026 年 10 月 3 日發布，它在架構時換取能力：總參數 781 億，其中每個 token 僅約 34.6 億為活躍，因此模型中幾乎每一個參數都是你永遠不必付費評估的參數。

這兩者不能互換，原因不在品質。一個是託管的預覽版，沒有權重、沒有公布參數數量，也沒有公布上下文視窗。另一個是 Apache 2.0 授權的下載檔，其模型卡標明了專家數量、注意力排程、數值格式、分詞器的語言涵蓋範圍，以及其訓練執行確切的電費。比較它們其實是在比較兩種策略，而有趣的問題是：哪一種策略經得起你的工作負載的考驗。

22比1的比例，對比一個沒有人公布過的比例

K​olibri 是一款稀疏混合專家模型，而且其稀疏程度即使以現行標準來看也極為極端。五十層，每一層都是混合專家層，每層 384 位專家，其中一位為共享專家，六位為路由專家。換算下來，總參數與啟用參數的比例約為 22.6 比 1——一個擁有 780 億參數的模型，卻在任何給定的 token 上只運算其中約 35 億個。A​leph Alpha 以 4 比 1 的模式，將其與分組查詢注意力區塊交替排列，這正是讓 262,144 token 的原生上下文得以負擔得起的關鍵：百萬 token 的路径已通過驗證，而 KV 快取則以 FP8 保存，好讓這段上下文窗口的最長端能裝進記憶體，而不是只存在於試算表裡。

數值格式的選擇公開到一種不尋常的程度。權重以 128×128 的區塊採用 FP8。KV 快取為 FP8。嵌入層、語言模型頭、正規化層與路由器則維持 bfloat16——也就是量化損害會顯現在路由決策而非損失值上的那些部分。四種投入等級對外開放。工具呼叫遵循 Hermes 格式並搭配 vLLM 解析器，這意味著它能直接嵌入現有的代理堆疊，而不需要客製化的整合。

Glimpse 並未公開任何這些資訊。沒有參數數量。沒有所謂的專家結構，沒有上下文視窗，沒有量化方案，沒有具名的基礎模型——只有「在開放權重基礎模型上進行後訓練」這句話，而這句話並未說明是哪一個模型。它反而公開的是軌跡：第一遍以約每秒 8 幀進行，一個暫定的解讀，以約每秒 14 幀回到剪輯中 0.9 秒處，以及在第二個例子中，一個從剪輯約 2.2 秒處開始追蹤的視窗邊緣，直到它在 5.13 秒處幾乎停止。

那兩者都是關於算力的揭露。K​olibri 的揭露說明了模型載入時算力會用在何處。G​limpse 的揭露則說明了模型思考時算力會用在何處。只有其中一個附有數字。

已發佈的工作表，並排顯示

• 規模 — K​olibri：總參數 78,103,074,560 個，啟用參數 3,457,573,120 個。G​limpse：未公開，E​lorian 唯一提供的規模說明是「比它所對標的前沿系統小得多且便宜得多」。

• 取用 — 為 K​olibri 提供 Apache 2.0 授權的權重，可下載並自行架設。G​limpse 則無，僅提供 API 與聊天功能，註冊免費。

• 上下文 — K​olibri 原生支援 262,144 個 token，並已驗證可達 1,048,576 個。G​limpse 則未公布，而這是更令人尷尬的空白，因為它的招牌能力正是讀取影片。

• 語言 — K​olibri 提供德語和英語，A​leph Alpha 將其視為設計決策，而非限制。G​limpse 則完全未公布語言涵蓋範圍。

• 價格 — 每百萬輸入權杖 $0.60，Glimpse 每百萬輸出權杖 $3.00——而這套機制意味著輸出權杖才是重新掃描顯現之處，因此追蹤紀錄就是收據。Kolibri 沒有費率表，因為成本就是硬體本身。

• 獨立評估—— 實際上兩者皆無。雙方都沒有第三方測試框架來重現其數據，而兩套已公布的數字均出自廠商自身。

A​leph Alpha 完整公開的訓練運行

這就是 Kolibri 與今年幾乎所有發行版不同的地方，值得深入探究，因為它揭示了打造稀疏性所付出的代價。

預訓練語料庫共有 20 兆個 token，大致拆分為 62.5% 英文、23.9% 德文與 13.6% 程式碼。中期訓練又新增了 3.44 兆個，而長上下文階段則貢獻了 2010 億個。這次訓練使用了 768 個 N​VIDIA B200 加速器，橫跨 96 個 HGX 節點，耗時 21 天、實際時間 511 小時，並消耗約 392,000 GPU 小時——6.4×10²³ 次浮點運算，能源預算約為 9.5×10² 兆瓦時。

那些數字如實呈現了一個擁有 34.6 億活躍參數、表現卻宛如規模大上許多的模型所付出的代價。對任何不屬於資金雄厚實驗室的人而言，這些數字也無法重現；而這正是支持開放權重的理由：訓練成本由發布模型卡的公司一次性支付，下游所有人則只需付出下載的代價，就能取得這個成品。

前身極具啟發性。Kolibri Origin 擁有 306 億個參數，其中 32.7 億為活躍參數，上下文長度為 65,536 個詞元，訓練詞元達 7.51 兆——而它從未正式發布。已發布的模型並非首次嘗試，而是第二次；兩者之間的差距，大致就等同於原型與產品之間的差距。

對 Glimpse 而言，並不存在可資比較的東西。Elorian 只說這個模型是由一個小型團隊以數百顆 GPU 進行後訓練。沒有指名基礎模型、沒有 token 數量、沒有資料描述、沒有算力揭露。發布檢查點與推出端點之間確實存在這樣的合理差異——你揭露的是你交出去的東西——但這意味著這兩次發布除了價目表之外，無法從經濟層面進行比較，因為只有其中一方公布了成本。

空的參數計數儲存格

這就是這項比較中的陷阱，而且它對 G​limpse 有利。

很容易讀到 K​olibri 的 34.6 億個活躍參數，就斷定 G​limpse——託管、每詞元便宜、針對狹隘能力——一定很小，或執行起來一定很便宜，或一定是某個規模不大之物的微調版本。這些都推論不出來。G​limpse 的參數數量從未公布。它的上下文視窗從未公布。它的基礎模型從未公布名稱。發布文章中唯一與規模有關的說法只是比較性的，且未經量化。在行為無法透露規模，而此模型的行為是一套取樣排程而非架構的情況下，參數數量幾乎可以是任何數字，且已公布的內容都不會與之矛盾。

所以參數數量儲存格仍保持空白，而任何人這個月引用來描述 G​limpse 規模的數字，都是包裝成規格的估算值。順帶一提，反過來也一樣：K​olibri 的 22.6 比 1 比例，無法告訴你它在你的硬體上的推論成本，因為 128×128 區塊的 FP8 權重需要特定的加速器支援，才可能划算，而不是只多出一道轉換步驟。

每個策略不足之處

K​olibri 的限制在於語言覆蓋範圍，而這是刻意為之的。德語和英語，別無其他。對於一家擁有德語流量的歐洲企業而言，這是一項優勢——訓練組合側重於一種大多數開放模型都視為微不足道的語言。對其他人來說，這則是絕對不行，再大的上下文視窗也無法彌補。

它的第二項限制是長脈絡的運算。一條百萬 token 的路徑已通過驗證，這確實很大。但通過驗證的路徑並不等於未劣化的路徑；在這樣的長度下，幾乎所有模型的檢索準確率都會在視窗結束前很久就開始下滑，而目前沒有任何已發表的評估說明 Kolibri 的曲線在哪裡轉折。請把視窗當成可分配的容量，而不是可假設的準確度。

G​limpse 的局限正好是相反的形狀：一種狹窄的能力，周圍什麼都沒有。如果問題是某段影片不到一秒內發生了什麼，G​limpse 正是直接瞄準這一點。如果問題是某個場景暗示了什麼，而不是它明說了什麼，倒帶也幫不上忙——在 Humanity's Sixth Sense 上，也就是 E​lorian 與 Scale AI 在該模型出貨前九天發布的基準，G​limpse 得分 46.36，而 GPT-6 Astra 得分 53.6，且該基準自身的失敗分析將 94% 的標記錯誤歸因於觀看與推斷，而非推理。看得更多並不等於理解更多，而供應商自己的表格就是證據。

還有一類問題是兩者都未處理的：答案必須是一個閾值的那一類。G​limpse 撰寫散文。K​olibri 能讀能寫。兩者都不是為了針對每個選項回傳一個經過校準的數字而打造；如果這正是管線所需要的，那麼這個工具就是一種完全不同形態的模型。

路由層在哪些情況下值得存在——以及在哪些情況下不值得

這兩個模型位於兩道邊界的兩側：一道路由可以移動，另一道它不能。

它挪動的那條界線，是混用不同通道時的成本與韌性。一個團隊若以自家加速器跑 Kolibri 處理德語流量，其餘全部交給託管模型，就會有兩套程式路徑、兩種失效模式，以及兩組憑證。OrcaRouter 把這些收攏成置於兩百多個模型之前的一把金鑰，並以一套路由 DSL 決定哪個請求走哪條通道，以及自動容錯移轉機制，讓自家部署的通道滿載或中斷時請求仍能存活。供應商牌價原樣直通，每個 token 都不加收任何費用，因此這個混合架構中託管的那一半，成本就是供應商實際收取的價格，而且供應商調價當天就跟著變動。

它不會移動的那條界線是保管權，而在這裡，K​olibri 擁有任何路由層都無法製造出來的優勢。它的權重可供下載。如果語料庫不能離開這棟建築，Apache 2.0 檢查點就是這兩者中唯一能在資料所在之處運行的，而無論對哪個模型進行評估，都改變不了這一點。這兩個模型也都不在我們的型錄中——K​olibri 是可下載的，而 G​limpse 是 E​lorian 自家的 API 與聊天介面——所以這是一項關於我們如何路由的陳述，而不是聲稱要提供它們。

如何在沒有共享基準的情況下做決定

沒有排行榜能為這兩者排名，而這並不是因為其中一個是新的。E​lorian 的表格以 GPT-6 Astra 為對照，衡量影片與圖像感知；A​leph Alpha 的卡則衡量常見的學術評測範圍，外加長上下文檢索。它們沒有共同任務，因此唯一重要的比較，是對照你自己的工作量。

三個問題比任何表格都更快搞定。

資料是否必須留在您控制的硬體上？如果是，K​olibri 是這裡唯一的候選方案，授權條款是 Apache 2.0，而德英涵蓋範圍不是符合您的部署需求，就是會立刻將它排除。

這個失效模式是時間性的嗎——跨遮蔽前後的物件身分、平移運鏡與剪接之別、落在不到一秒視窗內的事件？若是，Glimpse 是兩者中唯一其所述機制能處理此問題的模型，免費註冊讓試用成本很低，而追蹤紀錄告訴你的比分數更多：用你自己的片段跑一遍，並檢查模型是否曾回頭查看那個決定了答案的區間。

如果工作負載是長上下文、而非長影片——例如文件語料、申報文件集、稽核軌跡——呢？若是，K​olibri 的 262,144-token 原生視窗，搭配已驗證的百萬-token 路徑，就是相關數字；而兩個模型已發表的評估，都無法斷定它在那些長度下能否撐過衰減曲線。這必須在你的資料上實際測量，之後任一決定才安全。

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