Nanbeige4.3-33B：20 項中勝出 17 項、512K 上下文，且完全未經獨立測試

2026年10月24日 02:49 UTC，一個名為Nanbeige/Nanbeige4.3-33B的 Hugging Face 儲存庫公開上線，時間就在其同名基礎檢查點發布的四分鐘後。沒有上線貼文。沒有部落格文章、沒有廠商公告、沒有新聞稿——模型卡就是這項 331 億參數開放權重發布的全部第一方紀錄，其頭條宣稱是：它在 20 項基準測試中的 18 項上擊敗 Qwen3.8-27B。該宣稱並非虛假。但它目前也無法查核，而此後的報導大多只是重複那張表格，並未閱讀其下方的註腳。

所以這些數字同時說明了兩件事。Nanbeige4.3-33B 在自家表格的 20 行中領先 17 行，並且對 Qwen3.8-27B 在其中 18 行上勝出。這兩個計數不同，但都準確：它未領先的三行是 SWE-Bench Pro，Qwen3.8-27B 以 61.7 比 60.3 勝出；GDPval，Qwen3.8-27B 以 86.4 比 84.8 勝出；以及 GPQA Diamond，Gemma4-31B 的 91.3 擊敗兩者。輸給 Qwen3.8-27B 兩行、輸給 Gemma4-31B 一行，就得出對 Qwen 模型是 20 行中勝 18 行、對上其他所有模型是 20 行中勝 17 行。多數評測文章只挑一個數字、略過另一個，這是件小事，卻能看出其餘內容被讀得多仔細。

這個儲存庫確立了什麼，以及它沒有確立什麼

先從實際打開檔案可查證的內容著手，而不是引用文字描述，因為這兩者之間的落差正是這裡的重點所在。

• 已確認：權重存在。十四個 safetensors 分片，總計 66,259,989,086 位元組，bfloat16，位於一個於 2026 年 10 月 24 日 02:49:18Z 建立、最後異動於 10 月 25 日 11:11Z 的儲存庫中。另一個獨立的基礎檢查點，Nanbeige4.3-33B-Base，是在三分鐘前、02:46:52Z 建立。

• 確認：授權條款為 Apache 2.0，已在儲存庫中繼資料與卡片的前置資料中宣告。八個非權重檔案中沒有 LICENSE 檔案，這是文書作業缺口而非法律缺口——Hub 與大多數掃描器讀取的是中繼資料欄位。

• 確認：此架構是單純的 Llama 堆疊，並非混合專家模型，也不是該系列小型模型所採用的循環式 Transformer 設計。設定細節見下文。

• 已確認：沒有廠商代管的端點。此儲存庫在 Hub 的推論供應商對應為空，而卡片本著同樣精神提供 vLLM、SGLang 與 Transformers：自備 GPU。

• 未確認：關於其訓練方式的任何資訊。沒有預訓練 token 數量、沒有資料混合、沒有運算量數據、沒有後訓練配方，也沒有侷限性或安全性章節。該卡片的引用區塊只有四行。

• 尚未確認：任何已公布的數字是否可重現。儲存庫中沒有評估測試框架——沒有腳本、沒有任務設定、沒有日誌——而且截至10月26日，尚無第三方針對此模型公布分數、競技場評分或指數排名。

• 未經證實：這次發布是悄悄進行的。事實並非如此。它其實是由實驗室在未事先公告的情況下釋出，這是更狹義也更精確的描述：這張模型卡是一份完整的發布文件，附有二十列的基準測試表，而彙整站不到一天就收錄了。真正欠缺的，是由官方親自撰寫、說明 Nanbeige 認為自己打造了什麼的文章。

這項區別對任何要決定如何處理這次發布的人來說都很重要。一個什麼都不說的實驗室，等於沒告訴你任何關於其意圖、支援或下一個檢查點的資訊。一個只發布模型卡卻沒有發布貼文的實驗室，已經告訴你很多關於該模型的資訊，卻讓策略隱而不明——而在這個案例中，只要你注意到，策略就明明白白地寫在模型卡的第二段。

這張卡稱它為老師，而這重新詮釋了整個發行。

Nanbeige4.3-33B 被描述為 Nanbeige4.3 系列的「旗艦教師模型」，先被打造出來，以便實驗室能將代理行為蒸餾到較小的模型中，「例如供 Nanbeige4.3-3B 使用」。該卡片將「在約 30B 參數級別的開放模型中達到最先進的代理效能」列為目標，隨後立即將 33B 描述為蒸餾流程的基礎，而非最終產品。

照字面解讀，這次發布就是一個恰好可交付的訓練產物。它就是你用來為 3B 學生模型生成軌跡的模型，而其基準測試套件之所以大量聚焦於長時程代理任務——Terminal-Bench、DeepSWE、JobBench、Toolathlon——是因為那些正是有人想遷移的行為。Nanbeige4.3-3B 尚未推出。等它推出後，它將成為大多數人實際運行的模型，而這個 33B 將是解釋其分數的關鍵。

有個值得指出的副作用：教師模型的最佳化目標，是在寬裕的 token 預算下產出良好的軌跡，而不是在推論時便宜。卡片上的建議設定正印證了這點——代理式工作為 65,536 個最大新增 token，推理與聊天為 262,144 個，且預設開啟思考。一個被提示要輸出二十五萬個 token 的模型，不是你能不設預算就放在聊天框後面的模型。

設定檔所描述的 33B

閱讀 config.json，其架構相當常規，而行銷說辭則不然。52 層、隱藏大小 7,168、56 個查詢頭對上 8 個鍵值頭——7:1 的分組查詢比例——頭維度 128、FFN 寬度 22,016，以及 166,912 個詞元的詞彙表。RoPE 基底為 120,000,000，未套用任何縮放，且 max_position_embeddings 設為 524,288。檔案中標示的 transformers 版本為 4.51.1。

參數量可由這些數字推得。注意力投影每層共有 1.174 億個參數，三層 MLP 則有 4.734 億個，這使得每個區塊有 5.909 億個，橫跨 52 個區塊：307 億。兩個未共享的嵌入矩陣尺寸為 166,912 乘 7,168，再加 24 億。總計為 331 億，這正是名稱所承諾的數量，也是 66.3 GB 的 bfloat16 所佔的重量。

面對它花整張表來抨擊的模型，差異比比分所顯示的更為明顯。

• 規模 — Nanbeige4.3-33B 為 33.1B 稠密模型，而 Qwen3.8-27B 為 27.78B 稠密模型。兩者皆為稠密模型；皆非混合專家模型。

• 模態 — Nanbeige4.3-33B 僅支援純文字、英文與中文；Qwen3.8-27B 則原生支援文字、圖像與影片輸入。若你的流程需要讀取螢幕截圖，那麼在基準測試開始之前，勝負就已分曉。

• 注意力 — Nanbeige4.3-33B 在 52 層中一律採用完整注意力，而 Qwen3.8-27B 則採用混合堆疊，以 3:1 的比例運行 48 個門控 DeltaNet 線性層與 16 個完整注意力層。這就是為何 Qwen 模型在長上下文下成本低廉，而這個模型則不然。

• 上下文 — Nanbeige4.3-33B 原生支援 524,288 個 token，而 Qwen3.8-27B 原生支援 262,144 個 token，並可透過 YaRN 擴展至約 1M。

• 授權 — 兩者皆採用 Apache 2.0，這消除了通常偏好其中之一的理由。

注意力差異不是註腳。這正是下一節存在的全部理由。

512K 是設定檔中的一個值，不是工作上下文。

每一次關於這個版本的摘要，開頭都在講那五十萬個 token 的視窗。幾乎沒有一次去算那筆帳，而這筆帳並不好看。

在 52 層、8 個維度為 128 的鍵值頭，以及 bfloat16 儲存的情況下，快取中的每個 token 耗費 2 × 52 × 8 × 128 × 2 位元組——212,992 位元組，即 208 KiB。由此可直接得出三個後果。

• 在完整的 524,288 個 token 下，光是 KV 快取就達到 111.7 GB，約 104 GiB。這比 66.3 GB 的權重還多，而且放不進現今市面上販售的任何單一加速器。

• 在 131,072 個 token 時——也就是宣稱視窗的四分之一——快取為 27.9 GB，約 26 GiB。再加上權重，在激活值之前就已達到 92 GB，這就是為什麼該卡自身的範例採用四路張量並行。

• 在 32,768 個 token 時，快取為 6.98 GB，約 6.5 GiB。這是實務上真正重要的數字，而這也是社群 GGUF 儲存庫的 llama.cpp 範例實際設定的上下文長度。

這些都不會讓 512K 的說法變得不誠實。這個視窗是原生支援的——沒有 YaRN、沒有縮放因子，rope base 為 1.2 億——而且在記憶體足夠的四 GPU 節點上，你確實可以運行它。但這也意味著標題上的數字是你擁有的硬體上達不到的上限，而任何把「512K 上下文」當作購買理由的人，都沒有把快取成本算進去。把這點跟 Qwen3.8-27B 的設計相比，後者有四分之三的層維護的是固定大小的遞迴狀態，而不是持續增長的高速快取，因此每個長上下文 token 的成本差距是結構性的，而不是調校與否的問題。

設定裡還有一件事，而這正是那種會耗掉一個下午的細節：use_cache 被設為 false，在config.json與generation_config.json兩者中都是如此。透過模型卡上的 Transformers 程式碼片段載入模型，並在呼叫 generate 時不覆寫該設定，就會在每一步重新計算前綴。vLLM 與 SGLang 路徑會自行管理快取，因此不受影響。如果你第一次基準測試跑起來慢得莫名其妙，先檢查這一點，再怪罪權重。

照著腳註的要求來讀基準表

這張表的說明比大多數廠商表格更完整，而各種注意事項就藏在這些說明裡。二十列資料底下附了十二則註腳，它們對可比性的交代，比那些分數還多。

• Terminal-Bench 2.1 使用 Terminus 2 執行。Terminal-Bench 4.0 與 DeepSWE 則使用 mini-swe-agent v2.4.6 執行。

• NL2Repo 是使用 Claude Code 執行框架運行；JobBench 則使用 Claude Code 加上搜尋工具。

• SWE-Atlas-QnA 的答案是以 GPT-6 Sol 作為評判者、在中等推理強度下，依據 1,304 項任務專屬評分標準進行評分。評分標準評判者是迴路中的第二個模型，並非受測模型。

• Toolathlon-Verified 不對個別請求設定 max_tokens 上限。Claw-Eval 僅以 General 子集計分，該子集包含 157 個單輪任務。YC-bench 在每次呼叫前，只保留最近十輪對話作為歷史紀錄。GDPval 採用修訂後的評分標準。

• Nanbeige4.3-33B 本身是以 preserve_thinking=true 進行評估的，此設定會保留先前的助理推理內容，並延續至後續輪次。模型卡針對多輪工具使用所建議的正是這種做法，而對一般聊天則建議完全相反的做法。

綜合來看，這些筆記描述了一套旨在以充裕預算衡量長時程代理行為的評測套件。這是值得衡量的事——這正是模型的用途——但也是在這種情況下，評測框架的選擇對分數影響最大。表中最大差距是 DeepSWE 的 65.5 對上 Qwen3.8-27B 的 42.5，這是在由代理腳手架驅動的基準測試上達到 23 分的差距。最小差距出現在腳手架影響最小的列：AIME 2026 的 95.2 對 94.5，Tau3-Bench 的 48.8 對 48.5，EnterpriseOps-Gym 的 41.0 對 40.2。

這種模式與兩種解釋相符。要麼該模型在代理式編碼上確實遠優於同儕，要麼代理式列正是實驗室針對自家模型調校自家 scaffold 時獲益最大的那些列。儲存庫中沒有任何內容能區分這兩者，而在有人重跑整套測試之前，誠實的立場是兩者都仍有可能。模型以一分或更少差距勝出的那些列——Tau3-Bench、EnterpriseOps-Gym、AIME、Claw-Eval 以 78.3 對 75.2——最不可能在獨立測試框架下依然成立。

截至10月26日，完全不存在任何外部數字。沒有 Artificial Analysis 指數條目，沒有 arena 評分，也沒有任何人重現。該模型卡自身的 AA-LCR 數值 84.0，是 Nanbeige 執行 Artificial Analysis 基準測試所得的結果，而不是 Artificial Analysis 執行 Nanbeige 的結果。

迄今為止唯一的實測，以及它說明了什麼

只有一個人發表了實際執行權重所得的結果，而這個結果正因為內容單薄才值得報導。一位日本開發者在具備 80 GB 的 Colab A100 上載入了完整的 bfloat16 checkpoint，使用單純的 Transformers 搭配自動 dtype 與裝置對映，並測得約 63 GB 的 VRAM 使用量。第一次回覆的上限設為 1,024 個新 token，花了約十一秒。並未給出每秒 token 數；給人的印象是，33B 稠密模型在 bfloat16 下很慢，而這正是算術所預測的。

隨後有三個提示。9.11 與 9.8 的比較結果正確，並有清楚的小數說明。關於動漫角色的問題主觀上尚可，但名字出現錯亂。關於日本首相的問題產生了錯誤答案、聲稱知識截止日期為 2024 年 6 月，以及一個捏造的名字。英文思維鏈在結尾的 think 標籤之前外洩。

三個隨意提示並不是一項評估，也不應被當作評估來解讀。它們實際上是一個資料點，與廠商表格所呈現的樣貌相符：一個為了英語代理式工作而大力調校的模型、世界知識落後兩年，且在其第二語言上表現平平。該模型卡聲稱支援英語和中文；也沒有人發表過中文測試。

量化版本從何處開始不再是同一個模型

大多數執行這個模型的人不會跑 66 GB 的 bfloat16。他們會用單張顯示卡跑 4-bit 量化，而發布後一天內出現的量化報告顯示，這比平常的降級幅度更大。

社群 GGUF 儲存庫發布了相對於 bfloat16 模型的 KL 散度與 top-1 一致率，這些數據是在標準文字測試平台上測得，而其自身的 README 警告該模型「對量化異常敏感」。

• Q8_0，35.2 GB — KL 0.0032，top-1 一致率 98.0%。

• 重要性矩陣 Q5_K_M，24.7 GB — KL 0.0213，94.7% top-1。

• 重要性矩陣 Q4_K_M，21.2 GB — KL 0.0380，top-1 92.6%。

• 一般 llama.cpp Q4_K_M，20.1 GB — KL 0.0693，89.9% top-1。與上一列的位元寬度相同，漂移幾乎是兩倍。

• 重要性矩陣 IQ3_S，17.1 GB — KL 0.1019，87.5% top-1。README 指出，低於 4-bit 的檔案會明顯損失更多準確度。

一份 8 位元 MLX 轉換在 KL 0.015 時回報 98.6% top-1，並比較了 4 位元 AWQ 路徑在 KL 0.181 時的 92.1% top-1——這比相同名目寬度下的重要性矩陣 GGUF 下降幅度陡峭得多。

實際解讀是：如果你在單張 40 或 48 GB 顯示卡上以 4-bit 評估這個模型，而它無法完成你的代理任務，那麼你評估的模型，與已發表版本在大約每十個 token 中有九個一致。對散文而言，這看不出來。對工具呼叫而言，只要一個格式錯誤的參數就會結束該輪，7% 的分歧率就是另一種產品。如果你感興趣的是其代理式能力宣稱，誠實的最低標準是搭配重要性矩陣的 Q5，或在租用硬體上以 bfloat16 進行評估執行。

嘗試它需要付出什麼代價，以及如何在不押注於它的情況下嘗試

南北閣（Nanbeige）並未公布價格，因為根本無從定價：這個模型是權重，不是服務，而 Hub 上也沒有為它列出任何推理供應商。如此一來便剩下三條路徑——用四張 80 GB GPU 跑 bfloat16、用一張 48 GB 顯卡跑 Q5，或者等供應商上架。

相較之下，它聲稱要擊敗的模型可隨需使用。Qwen3.8-27B 在 OrcaRouter 上運行，每百萬輸入 token 收費 0.33 美元，每百萬輸出 token 收費 2.40 美元，具備 262K 上下文視窗，p50 首個 token 時間約為 2.95 秒。一個 65,536 token 的代理式提示加上 8,000 token 的輸出，成本約為四美分。這就是自架的 33B 模型必須超越的數字，而且它必須在承擔 GPU 閒置時間、量化風險以及缺乏備援路徑的情況下超越它。

我們不託管 Nanbeige4.3-33B，且此處任何內容都不應被解讀為我們有託管。我們能做的是讓反方向的比較變得便宜：Orca Connect 將你自己的 GPU 置於與託管目錄相同的金鑰之下，因此自託管的 Nanbeige 端點與 Qwen3.8-27B 可以位於同一個端點與同一條路由規則之後，讓你做決定。將一部分流量導向新的檢查點，將託管模型保留為備援，並讓請求日誌——評分、延遲、每次呼叫成本——來解決供應商表格無法解決的爭論。0% 加價在這裡有其特定意義：供應商定價原樣傳遞，因此當供應商降價時，你上週建立的比較仍保持誠實。

誰應該對此採取行動，而誰應該等待？

如果你正在建構蒸餾管線，這是本月最值得關注的開放檢查點。一個 33B 稠密教師模型，搭配寬鬆授權、有文件記錄的取樣設定，以及一組精心挑選、用來精確衡量你想轉移之行為的基準測試套件，是很有用的資產；而實驗室表示會先打造教師模型，這件事也透露了該系列的發展方向。下載它、執行你自己的評估，並把模型卡上的測試框架筆記放在你的結果旁邊。

如果你這週就要把模型推上生產環境，先緩一緩。目前沒有獨立評分、沒有託管端點，只有一份實測報告、裡面測了三個提示詞，還有一份量化表現概況——在多數人負擔得起的位元寬度下，它的劣化速度比一般情況更快。這些都不是足以判它出局的理由，只是還算不上證據。

如果你需要視覺能力，勝負早已分明：Qwen3.8-27B 能讀取圖像和影片，而這個模型只能讀取兩種語言的文字。

值得關注的事情很具體。蒸餾目標 Nanbeige4.3-3B，它會告訴你這個教師模型是否值得打造。Terminal-Bench 4.0 的首次獨立執行，也就是差距最大、對腳手架最敏感的那一列。以及供應商是否根本會列出 33B——因為一旦有人這麼做，512K 上下文就不再只是配置值，而會變成帳單上的單獨項目，本文裡的算術也就會變成某人的帳單。