Solar Open 2 250B：前沿代理分數亮眼，卻無處可跑

的 Hugging Face 模型卡Solar Open 2 250B 250B會給你一個服務指令，但這個指令無法運作。它要求 vLLM 提供一個名為 solar_open2 的推理解析器、一個名為 solar_open2 的工具呼叫解析器，以及一個名為 SolarOpen2TemplateLogitsProcessor 的 logits 處理器——這三樣東西在任何已釋出的 vLLM 版本中都不存在。對該架構的支援直到 8 月 5 日才以未合併的 pull request 形式出現於主線，而 Upstage 早在 7 月 22 日就已發布權重，兩者相隔兩週。這個落差至今仍是 Solar Open 2 最有趣的事實，也是所有發布報導為了 benchmark 表格而略過的部分。所以這裡要講的是另一個版本：Upstage 實際上釋出了什麼、它自己的數據能證明與不能證明什麼、目前紀錄上唯一的外部評分改變了什麼，以及要讓這個東西吐出一個 token 需要什麼條件——相較於 DeepSeek V4 Flash，也就是 Upstage 選作主要標竿的模型。

Upstage 實際出貨的內容

以下內容皆出自該儲存庫自身的 config.json 與 Solar Open 2 技術報告（arXiv 2607.20062）——這些雖是主要來源，但卻是供應商自己的主要來源。目前尚無任何獨立實驗室發表過針對此模型的自行測量結果。如今有一項外部數據浮現：媒體所報導、出自政府第二輪評測的 Artificial Analysis Intelligence Index 分數 37。由於這項分數是經報導而非經重現得出的，因此在下方的基準測試章節中會以獨立段落加以說明。

• 規模 — 參數總數 250,287,794,944，每個 token 約有 15B 個活躍參數

• 稀疏性 — 320 個路由專家加上 1 個共享專家，每個 token 路由至前 8 個專家，且 first_k_dense_replace 設為 0，表示混合從第零層開始，沒有同類 MoE 設計通常保留的密集預熱層

形狀 — 48 層，隱藏層大小 4096，注意力頭維度 128，64 個查詢頭對應 8 個鍵/值頭

• 注意力 — 12 個 softmax（GQA）層，位於索引 0、4、8 依此類推至 44；其餘 36 層為線性注意力。整個堆疊中有四分之三沒有 softmax

• 位置 — use_rope 為 false。完全沒有位置編碼

• 上下文 — max_position_embeddings 為 1,048,576

• 詞彙 — 196,608 tokens，涵蓋英語、韓語和日語

• 權重 — bfloat16，換算為 500.6 GB。這正是 2502.9 億個參數乘以兩個位元組，也符合 Nota AI 對未量化模型所報告的佔用空間。

訓練 — 根據報告約 11.9T tokens：10T 一般預訓練、1T 精選高品質子集、0.9T 用於長度擴展，以 4:6 的真實與合成比例，英文佔 80% 以上，數學與程式碼各至少 15%

• 授權 — Upstage Solar License，附帶條件（如下）

其前身 Solar Open 1 是於一月發布的 100B 模型。Solar Open 2 與其說是它的更新版本，不如說是完全不同的存在。

架構本身才是真正的故事。

該層級模式是由一個 softmax 層後接三個線性注意力層所組成，重複十二次。這些已見諸報導。但尚未說明的是採用哪種線性注意力，以及其為何重要。

線性層是 KDA — Kimi Delta Attention，這是 Moonshot AI 為 Kimi Linear 引入的機制。Upstage 並非發明了一種新的線性注意力；而是採用了別人的成果並改動了一處。這個改動在 config 中表現為 kda_allow_neg_eigval 設為 true，報告並解釋了它帶來的好處：標準 KDA 將狀態轉移的特徵值限制在 [0,1] 區間，因此每一步只能對遞迴狀態進行累加或衰減。設定該旗標會把寫入強度擴展為 beta = 2·sigmoid(·)，範圍是 (0,2)，進而將特徵值推到 [-1,1]。如此一來，每一步都可以翻轉既有儲存內容的正負號。用白話說：狀態可以自我修正，而不只是持續累積，這就是 Upstage 所宣稱的、能在多次工具呼叫之間維持長代理軌跡的機制。

這十幾個 softmax 層是帶有逐元素 sigmoid 輸出閘的 GQA——在配置中 use_gqa_gate 為 true——報告認為這有助於增加非線性並抑制注意力匯集。

而之所以沒有 RoPE，原因出在線性層。由於遞歸狀態本質上就編碼了 token 的順序，該報告主張可以徹底移除位置編碼，從此不再受限於訓練時長度分布的束縛。在此框架下，RoPE 才是限制外推的元兇；一旦移除，天花板便不再由訓練數據所決定。

1M 這個數字是設計宣稱，而非測量值。

這個論點很優雅，同時也是「1M-token」這個標題的全部依據。技術報告中沒有發布 RULER，沒有大海撈針（needle-in-a-haystack）測試，也沒有任何長上下文評測套件。這個視窗是從架構上推導出來的，而非在基準測試中得到驗證。與此同時，我們能找到的唯一一份公開部署報告——Backend.AI 在兩台 DGX Spark 系統上提供量化模型服務——將 max-model-len 設定為 200,000，而不是 1,048,576。架構上的上限也許確實存在，但在 500K 或 1M token 下究竟還能保留多少品質，論文裡就是隻字未提。

效率聲明也帶有同樣的星號：報告指出，混合堆疊在1M上下文下所需的記憶體和運算量約為全softmax堆疊的四分之一；另外，混合設計在MMLU上達到目標損失所用的訓練token數比全softmax少了約3.2倍。兩者皆為Upstage自身的數據。完全沒有公佈任何吞吐量或延遲數據。

如實解讀的基準卡

在英語測試集上，與 DeepSeek V4 Flash 相比，Solar Open 2 250B 在 MMLU-Pro 取得 86.2 分（對方 85.9 分），在 LiveCodeBench v6 取得 92.4 分（對方 92.3 分）——這些差異小到只能算是評分誤差。接著它在 APEX-Agents 取得 16.6 分（對方 13.2 分），這才是真正的差距，而且毫不意外，正是 Upstage 領先的數字。

The losses are in the same report and get less airtime. SWE-Bench Verified: 70.4 against 73.8. GDPval-AA v2, on ELO: 1128 against 1187. Terminal Bench Hard: 28.3, against 41.7 for MiMo-V2.5. ArtifactsBench: 55.9, behind both frontier baselines. To Upstage's credit the report names these gaps and where they point — repository- and terminal-level software engineering, and numerical precision in office deliverables — rather than burying them. 這些失利也出現在同一份報告中，但獲得的關注較少。SWE-Bench Verified：70.4，對比 73.8。GDPval-AA v2 的 ELO 為 1128，對比 1187。Terminal Bench Hard：28.3，對比 MiMo-V2.5 的 41.7。ArtifactsBench：55.9，落後於兩個前沿基準。值得肯定的是，Upstage 在報告中如實點出這些差距及其所指涉的面向——儲存庫與終端層級的軟體工程，以及辦公室文件產出的數值精確度——而非加以掩飾。

真正令人印象深刻的比較是內部的。對比 Solar Open 1：LiveCodeBench v6 從 56.5 提升至 92.4，SWE-Bench Verified 從 15.4 提升至 70.4，APEX-Agents 從 2.4 提升至 16.6。無論你如何看待這些正面交鋒，這都是六個月內真正的世代級躍進。

在韓語方面，整個套件的平均分數為 85.4，而 DeepSeek V4 Flash 則為 84.9——但平均數在這裡起了作用。Solar Open 2 250B 在 KMMLU-Pro（78.4 對 78.9）與 Ko-AIME'25（97.7 對 98.0）上落敗，但在 Ko-GDPval（86.8 對 85.0）上勝出。這項領先來自於可交付基準，而非知識或數學。

這就帶我們到了走得最遠的那條線：Solar Open 2 250B 能匹配一個體積是其六倍以上的模型。基礎是 Ko-GDPval，它在其中得到 86.8 分，而 DeepSeek-V4-Pro 是 86.9 分。那是一個韓文基準，而且是平手而非勝出——而在英文套件上，V4-Pro 的較小版本已經在 SWE-Bench Verified 上擊敗 Solar Open 2 250B。單一基準不能概括成規模效率法則。一個相關的提醒：APEX-Agents 的基線數據在論文和次要報導之間略有差異（相同模型是 13.2 對 13.4），因此請將排序視為方向性而非精確。

在偏好方面，針對835段韓語對話進行的盲測成對比較中，Solar Open 2 250B以44.1%對26.6%勝出，報告將其對齊與誠實方面的勝利歸因於文化根基，而非額外的安全訓練。值得注意的是其缺失之處：報告中完全沒有任何形式的量化危害、拒絕或越獄評估。

Hugging Face 卡片上的評估結果區塊後來又多了幾個數字——GPQA Diamond 86.3、HLE 28.8，以及 MathArena AIME 2026 95.7——但這些是從模型卡片本身擷取出來的，而非來自獨立執行的評測，因此它們與上面所有內容掛著相同的標籤：Upstage 自行提供的數據，未經重現驗證。

現在出現了一個並非來自 Upstage 實驗室的外部數字。8月13日，韓國金融媒體——Edaily、《首爾經濟日報》、ITDaily 和 iNews24，均發布了相同數據——報導了政府主權 AI 計劃第二輪評估分數，以 Artificial Analysis 的 Intelligence Index（AAII v4.1.1）衡量：Motif 3 為 47 分，Solar Open 2 250B 為 37 分，SK Telecom 的 A.X-K2 為 35 分，LG AI Research 的 K-EXAONE 2.0 0803 為 31 分。這個 37 分使 Solar Open 2 250B 在四名韓國入圍者中位居第二，落後 Motif 3 十分。精確地說：這是媒體報導的分數——該分數尚未出現在 Artificial Analysis 自己的排行榜上，該排行榜對此模型仍然查無資料——而且同一篇報導指出，AAII 不包含韓語基準測試，對於一個以國內表現為核心賣點的模型來說，這確實是盲點。但這是 Solar Open 2 250B 第一個不是源自 Upstage 的評測數據，而且與本文其餘部分一致：智能體與可交付成果分數亮眼，但其餘大部分仍有待供應商以外的人士驗證。

為什麼沒人能使用原廠軟體來伺服它？

這張模型卡比任何評論都更能說明故事。上個月下載次數已突破 26,000 次，加上 743 個讚、十六個社群量化版和三個微調模型——而在「推論提供者」欄位中，「此模型尚未由任何推論提供者部署」這行字依然不變，目前已有十幾人列名在卡片上請求提供者支援。真實的關注，零託管的端點。

追蹤能正常運作的部署，最後都會導向同一個 fork。Nota AI 的 NVFP4 建置把安裝釘在 git+https://github.com/UpstageAI/vllm.git 的 v0.22.0-solar-open2 標籤上——也就是 Upstage 自家的 vLLM。Backend.AI 的 DGX Spark 技術文章需要那個 fork 加上修補過的 FlashInfer，因為上游的 FlashInfer 沒有 expert-parallel 支援，也無法接受 compressed-tensors 格式。

Mainline 支援是針對 vllm-project/vllm 的 pull request 51129，於 8 月 5 日由一位名為 oesni 的貢獻者開啟。該 PR 目前仍處於開啟狀態：8 月 10 日 mergify 標記了合併衝突，因此該 PR 現在帶有 needs-rebase 標籤，且仍在等待審查。那個 PR 必須建置的內容，是公開場合中對這個模型難度最誠實的描述：

• 一個Solar專用的KimiGatedDeltaAttention層，位於新的solar_open2.py中，承載來自負特徵值變化的2·sigmoid(b) beta。

vllm::solar_open2_kda_attention 操作已註冊為 CUDA 圖形分割操作

• 在設定檔時期加入的 KDA prefill 暖身，上限為 2048 個 token，之所以特別加入，是因為沒有它的話，實際 prefill 執行速度會慢約 23%。

• 適用於串流與非串流模式的推理輸出與工具呼叫解析器

• 在 8×B200 上進行服務驗證，回報每個 rank 的 KV 快取為 107.02 GiB，以及 463 個通過的單元測試。

那些是 PR 作者的數據，沒有其他人複現過，而且程式碼在合併之前仍可能變更。但只要把那份清單對照架構章節來讀，問題的輪廓就很明顯：讓 Solar Open 2 250B 在長上下文下能以低成本運行的兩個選擇——四分之三的層採用 KDA，以及不使用 RoPE——恰恰正是通用推論技術棧沒有現成程式碼路徑的選擇。權重的開放與運行權重的路徑開放是兩回事，而其中只有一者在 7 月 22 日發布了。

挺身而出的代價

先從記憶體下限開始。以 H200 的 141 GB 對比 500.6 GB 的 bfloat16 權重，四張 GPU 可提供 564 GB——在單一請求到達之前，整個節點約剩 63 GB 給 KV cache 和激活值。這正是為什麼規格表將四張 H200 列為最低配置並建議八張，也是為什麼 FlexAI 以專用 8×H100 端點提供此服務，採洽詢報價制，而非共享的 per-token API。

量化把這條底線大幅下移。Nota AI 的 NVFP4 版本（4 位元權重與激活值、群組大小 16、採用 compressed-tensors 格式）將模型從 500.6 GB 降至 153.3 GB；他們自己的評測顯示，四個基準平均下來準確度成本為 0.22 分——81.57 降至 81.35，其中 Tau2-Bench 從 75.20 降至 75.08，GPQA-Diamond 從 86.26 降至 85.45，MMLU-Pro 從 86.19 降至 86.15，而 LiveCodeBench 則反向變動，從 87.03 升至 88.55，這比較像是量化噪音而非實質改進。關鍵在於硬體：NVFP4 需要 Blackwell 導入的 FP4 張量核心，因此只限 B200 或 GB200，Hopper 上完全無法使用。如果你用的是 H100，你要的版本是他們的 INT4 全域剪枝版本——剪枝後規模為 117.8 GB，剛好能塞進兩張 H100。

現在，來算算這筆決定性的帳。DeepSeek V4 Flash——再說一次，這是 Upstage 選擇作為對照基準的模型——在 OrcaRouter 上每百萬輸入 token 收費 0.15 美元、每百萬輸出 token 收費 0.29 美元；OrcaRouter 以 0% 加成直接照搬 DeepSeek 的牌價。以 3:1 的輸入對輸出比例混合後，大約是每百萬 token 0.185 美元。假設每個 GPU 小時 2 美元、放在一個八 GPU 節點上，在任何人發出請求前，你每月就要支付約 11,700 美元——相當於每月約 630 億混合 token 的 API 流量，也就是每天 21 億 token、天天如此，才能剛好達到損益平衡。縮小到雙 GPU 節點，損益平衡點就降到每月約 160 億 token。你可以代入自己的 GPU 價格；整體形狀不會改變。自行託管一個 250B 模型，是關於使用率與掌控權的決定，而不是關於折扣。

精確說明哪些可用、哪些不可用：Solar Open 2 250B 不在 OrcaRouter 上，而且根據其自身的模型卡，它也不在任何推論供應商上。OrcaRouter 上的是與它進行對標的模型群——DeepSeek V4 Flash、Qwen3.8-Max 以及其他數百個模型，共用一把金鑰，按供應商列表價格計費；若某個供應商故障，便會在各供應商之間自動容錯切換。這在一個狹窄而實際的層面上很重要：如果你真正想回答的問題是「經過代理調校的模型是否勝過我們在生產環境中已在用的模型」，你今天下午就能透過更改模型字串來執行那一半的比較，而另一半所需的 GPU 報價仍在採購流程中。

許可證上的兩個字串

Upstage Solar 授權條款允許商業使用、微調與蒸餾，Upstage 將其描述為以 Apache-2.0 為基礎並附加品牌條款。有兩項新增的義務需要仔細閱讀：衍生模型的名稱必須帶有「Solar」前綴，且你必須顯示「Built with Solar」的署名。

對於內部部署而言，這不是什麼大事。如果你打算將此提煉成以自家產品品牌出貨的東西，命名條款是披著授權條款外衣的品牌決策，在開始訓練之前值得花律師二十分鐘。請閱讀 repo 上的條款，而非相信對它的報導——對這個授權的報導一直不嚴謹，至少有一篇文章直接將其描述為 Apache 2.0。

現在誰應該行動，誰應該等待？

如果韓語或日語的交付品質就是你的產品，而且你能把權重部署在自己既有的硬體上——這種組合正是「開放權重、無端點」模式所擅長的；Upstage 自己的說法也明確表示，主權意味著你能自行部署並驗證模型，而不只是它在國內訓練而已。如果你有空置的 GPU，且有足夠流量的 agent 工作負載能填滿它們，那就行動吧，因為在實際利用率下，每 token 的成本計算會反轉過來。如果稽核或資料落地要求代表 API 從來就不在選項之列，那就行動吧。

等等，如果你想要一個按 token 計費的端點。Upstage 已表示打算在第三方平台上架 Solar Open 2 250B；截至撰寫本文時，這尚未發生——Playground 試用僅持續到 7 月 31 日，且模型卡仍未顯示任何提供者。等等，如果你使用的是 Hopper，並指望 4-bit 版本，因為 NVFP4 版本需要 Blackwell。還有，在圍繞 1M 上下文數字設計任何東西之前，請等等——這個數字目前是架構的特性，而非實測結果。

值得關注的是 pull request 51129；8 月 10 日，mergify 標記出合併衝突後，它就被貼上了 needs-rebase 標籤。當 Solar Open 2 250B 出現在已標記版本的 vLLM 發行版中，就是它不再是基礎設施專案、而成為任何人都能直接試用的模型的那一天。媒體報導的 AAII 37 只是個開端——這是第一個外部評測結果，儘管只是暫時性的，而且它仍未出現在 Artificial Analysis 自己的排行榜上。真正的考驗是能在現成軟體上運行的測試，而這還沒有確定的日期。