Step 5 Preview vs Muse Glimmer：前沿 API 與筆電模型

在排行榜上，Step 5 Preview 與 Muse Glimmer 並不相近：在 Artificial Analysis Intelligence Index 上，44 對 17——在一個目前領先者落在五十幾分的量表上，相差二十七分——再怎麼調校都無法彌補。對於團隊真正必須回答的問題——我的 token 在哪裡運行——它們卻是直接競爭對手。Step 5 Preview 是 StepFun 的旗艦模型，於 2026 年 9 月 20 日發布，總參數量約 6,000 億，活躍參數 270 億，上下文長度 1M token，定價為每百萬輸入 token 1.00 美元、每百萬輸出 token 2.70 美元，且只能透過網路使用。Muse Glimmer 是 Meta Superintelligence Labs 的 300 億參數開放權重代理式模型，於 2026 年 8 月 10 日在 Apache 2.0 下發布，以 4-bit 量化出貨，因此能在 20 GB 記憶體以內運行，並在拔掉網路的情況下於單一消費級 GPU 上執行。解讀這組配對的正確方式不是「哪一個更聰明」，而是「能力與邊界這兩個限制條件中，哪一項是你的工作負載無法撼動的」。

這項比較也對這個市場沾染的一種習慣發揮了有用的矯正作用：把綜合指數分數當成模型價值的全部。二十七分的差距確實存在，而且它並不是檔案裡唯一的數字。在長上下文檢索上，同一個獨立評測榜單把 Muse Glimmer 放在與來自大得多權重級別的開放權重模型相差不到半分的範圍內，而 Meta 自家的代理式基準測試，對一個能在筆電上運行的模型來說也算體面。與此同時，Step 5 Preview 最常被提及的弱點根本不是能力，而是冗長，而且在它承諾的權重於10月15日到位之前，它仍處於閉源狀態。

兩個模型，兩個截然不同的物件

Step 5 Preview 是一套混合專家系統，由 StepFun 的基礎架構提供服務：總參數約 600B，每個 token 啟用 27B，支援文字與圖像輸入，具備 1M token 的上下文視窗，並在獨立的 Intelligence Index 上取得 44 分，而同級模型的中位數為 26 分。它的輸出速度為每秒 87 個 token，同一排行榜測得的平均值則為 78，且它在該索引任務套件中產生了約 1 億 6,000 萬個輸出 token，而中位數模型僅輸出約 8,200 萬個——每單位工作量所產出的文字量約為兩倍，收費為每百萬個 token 2.70 美元。BF16 權重原定於 2026 年 10 月 15 日發布，目前尚未進入儲存庫，因此時至今日，這個模型對你而言僅以 API 的形式存在。

Muse Glimmer 則是相反的物件。它是一個 300 億參數的模型，以 logit 蒸餾方式從 Meta 較大的教師模型 Muse Spark 訓練而成，接著以長脈絡代理式資料進行微調，並針對工具使用加以強化。Meta 以 4 位元量化形式推出它，使記憶體需求從全精度下的超過 55 GB 降至低於 20 GB——落在 24 GB 或 32 GB 的 VRAM 範圍內——而 Meta 也在 Nvidia RTX 5090 以及 Apple M4 Max 與 M5 Max 晶片上對它進行了測試。它接受超過一百種語言的文字與圖像輸入，支援 131,072 個 token 的脈絡，並可延伸至 262,144，且其設計是能接收一個目標、將其拆解成步驟、呼叫工具，並在呼叫失敗時重試，而非就此停下。它採用 Apache 2.0 授權，且可離線執行。

• 獨立評分 — Step 5 Preview：44，同級中位數為 26，對比 Muse Glimmer：在其高階配置下，同一指數為 17。

• 規模 — Step 5 預覽：總計約 600B，每個 Step 27B 活躍，相較於 Muse Glimmer：總計 30B，量化至 4 位元，低於 20 GB。

• 上下文視窗 — Step 5 Preview：100 萬個詞元對比 Muse Glimmer：131,072，可延伸至 262,144，根據 Meta。

• 價格 — Step 5 Preview：每百萬個 token 輸入 $1.00／輸出 $2.70，已公布；對比 Muse Glimmer：不按 token 收費；GPU 由你提供。

• 運行位置 — 步驟 5 預覽：供應商的伺服器，透過 HTTP，對比 Muse Glimmer：你自己的硬體，離線。

• 授權 — Step 5 Preview：封閉預覽，權重承諾於 2026 年 10 月 15 日釋出，對比 Muse Glimmer：Apache 2.0，現已可下載。

• 長上下文檢索 —— Muse Glimmer 在 index board 的長上下文推理評測中得分 80.0，與價格帶高出數倍的模型相差在半分以內，且與 Step 5 Preview 的讀數足夠接近，以至於此差異對查找事實型工作而言不具決策相關性。

二十七點，以及它們未能衡量的事物

一個被蒸餾成可在 20 GB 記憶體中運作的 30B 模型，在通用智慧指數上本來就會輸給 600B 的旗艦模型，而 Meta 自家的資料也沒有聲稱相反的情況——其中一種說法直言，Glimmer 並非設計來匹敵完整規模雲端模型的原始推理能力。因此，17 分並不是對這項工程的評判；它是權衡不同目標後的預期結果。真正的問題在於，這個差距實際上涵蓋了你哪些任務。

長上下文閱讀是兩者最接近的地方，也是直覺失靈的地方。Muse Glimmer 在該排行榜的長上下文推理評測中拿下 80.0 分——這個分數對前沿模型來說平平無奇，對一個在消費級 GPU 上執行的模型卻很了不起。如果你的工作負載是長文件的檢索、摘要或擷取，那麼具備這種水準的本機模型顯然不是錯誤的工具，而且請求永遠不離開你的機器，這是無論花多少錢都無法從 API 買到的特性。

接著是 Meta 的數據未顯示的比較部分。一項針對多代理協作編排的同儕審查研究，在受控環境中測試了 Muse-Glimmer-30B——相同任務、相同測試框架、相同顧問——並發現它未能找回任何由更大前沿模型產生的候選項目，在每種設定下三次嘗試全數失敗。那是針對單一組態的單一研究，而這是模型頁面從不會揭露的那類證據。對於較弱協調器必須從較強模型失敗中復原的代理式流程而言，這是本文中最與決策相關的結果，且值得在任何 Meta 供應商報告的基準之前先閱讀。

為求完整，這些基準測試是 Meta 自家的，且未經重現：SWE-Bench Verified 上 76.0%、SWE-Bench Pro 上 51.2%、TerminalBench 2.1 上 51.7%、OSWorld-Verified 上 65.9%、GPQA Diamond 上 83.5%、Humanity's Last Exam 上 22%，以及 MCP-Atlas 上 75.5。它們是相對於 Meta 自家同尺寸級別的模型進行測量，且描述的是一個有能力的本地代理，而非前沿推理模型。

邊界實際上落在哪裡

Step 5 Preview 的結構性優勢在於，它能完成你無法在本地完成的工作。1M token 的上下文、影像輸入、經實測且接近前沿的評分，以及每秒 87 個輸出 token，而且無需購買任何硬體：無論是草擬、規劃、在大型儲存庫中進行程式碼審查，或是任何以模型能力上限為瓶頸的用途，API 都勝出，而那 27 分就是全部的論據。其代價則與 Muse Glimmer 相反：提示會離開你的邊界，價格會按每個 token 重新計算，而模型的冗長程度會讓長輸出工作負載比 $2.70 費率所暗示的更昂貴。

Muse Glimmer 的優勢在於，它做的是無法離開本地的工作。如果資料受到監管，如果延遲預算只有幾毫秒，如果機器離線，或者第一百萬次呼叫的邊際成本必須為零，那麼沒有任何 API 會是候選方案——不是這個，也不是任何一個。這件事的代價是能力：你是在有 44 可選的情況下選擇 17，而在代理式協調中，你可能選到的是一個無法從更強模型錯誤中復原的協調器。

對大多數團隊而言，答案不是二選一，而是分流，而這個分流需要有個地方落腳。OrcaRouter 會將超過 200 個模型置於單一 API 金鑰與單一帳單之後，0% 加成，並直接沿用供應商的定價，再加上自動容錯移轉，以及一套可依任務、成本或延遲來分派流量的路由 DSL。Step 5 Preview 和 Muse Glimmer 都不在那份目錄中——StepFun 的模型並非由我們路由，而 Glimmer 是本地下載——因此這裡提供的價值並不是取得這兩個模型的管道，而是你會用來與它們對照評測的那一組模型，今天就能用同一把金鑰呼叫，讓你對本地與遠端的抉擇由自己的任務分布來決定，而不是取決於你最後讀到的是哪一家廠商的頁面。

如何決定

選擇 Step 5 Preview，前提是上限本身就是限制條件。如果你的任務是開放式的、多模態的、長脈絡的，或是屬於需要有能力規劃器的那種代理型任務，那麼兩者之中只有 API 模型做得到，而它的價格就其所屬級別而言夠低，低到試行它只是一筆預算項目，而不是一個專案。要為輸出冗長程度編列預算，並預期 10 月 15 日的權重日期會延後，同時把絕對不能離開此處的工作負載排除在外。

當邊界就是限制條件時，請選擇 Muse Glimmer。如果你的資料不能外送、如果你需要在飛機上或工廠裡執行，或者你的用量讓按 token 計價顯得荒謬，那麼一個能塞進 20 GB、採 Apache-2.0 授權的 30B 模型就是務實的選擇，而且它的長脈絡檢索結果已夠好，能力落差不會在每一種工作負載中都顯現出來。在信任它能用於編排之前，先在編排中測試它，因為那正是獨立證據最薄弱的地方。

如果這兩項限制同時成立，就兩個都跑：不能外移的資料走本地端，需要更大模型的任務走 API，並讓路由決策成為一項設定變更，而不是一次遷移。真正重要的比較不是 44 對 17，而是你的哪些請求負擔得起離開這台機器，而這個問題只有你自己的流量能回答。