一個 33B 的稠密模型、512K 上下文、Apache 2.0 授權。南北閣把它定位成老師，真正的目標是後面那顆 3B 小模型。
Nanbeige4.3-33B 是誰放出來的
Nanbeige LLM Lab 在 Hugging Face 上發布 Nanbeige4.3-33B，授權是 Apache 2.0。這個實驗室掛在求職平台 BOSS 直聘底下，先前在開源社群不算高調。
一起釋出的還有 Nanbeige4.3-33B-Base，給需要自己後訓練的人用。兩個版本同一天上架，模型卡把架構、訓練配方與建議參數都寫了出來。
模型卡裡有一句話很關鍵：這個 33B 是系列裡的教師模型，先把它練強，再蒸餾成即將發布的 Nanbeige4.3-3B。換句話說，33B 的任務不只是給人用，也要負責教出小模型。
求職平台養模型，外界第一個問題通常是資料。模型卡沒有交代訓練語料的組成，只寫了架構與後訓練配方。這在開源模型裡不算罕見，但對想放進企業內部的人，資料來源終究是個要自己評估的風險。
Nanbeige4.3-33B 的稠密架構跟 MoE 差在哪
稠密的意思是每個 token 都會跑過全部參數。現在主流的大模型多半用 MoE，靠路由把 token 分給少數專家，藉此在推論時省算力。稠密模型沒有這層調度，算力紮紮實實花在 33B 上。
這麼做有好處。行為比較可預測，部署也簡單，不必處理專家負載不均、批次內路由分歧這些問題。對做智慧代理的人，穩定比極致效率重要，因為多步驟任務只要中間一步歪掉，整個流程就得重跑。
代價是單位成本。同樣的推論預算，MoE 通常能換到更多有效參數。33B 稠密模型要跟 27B 到 31B 的對手比，靠的是訓練品質而不是架構偷懶。
對自己架模型的人，稠密還有一個實務上的好處：批次大小與延遲的關係比較線性，容量規劃容易抓。MoE 在低負載時很省，忙起來的尖峰反而難預測。
512K 上下文與 66 GB 權重意味著什麼
Nanbeige4.3-33B 的上下文長度是 524,288 個 token，也就是 512K。BF16 權重約 66 GB，架構是標準的 LlamaForCausalLM：52 層、hidden 維度 7,168、56 個查詢頭配 8 個 KV 頭的 GQA、詞表 166,912、RoPE theta 1.2e8。
512K 聽起來很猛，實際要配記憶體算。長上下文的 KV cache 大約每個 token 佔 208 KiB，塞滿 512K 就是 112 GB 左右。加上 66 GB 權重，這不是單張消費級顯示卡能舒服跑的量級。
社群的 Q8 量化 GGUF 約 35.2 GB，配 32K 上下文的 KV cache，可以在 48 GB 的單張卡上跑起來。想要完整 512K，就得回到多卡或高記憶體機器。
Nanbeige4.3-33B 的廠商自報成績：20 項裡贏 17 項
模型卡列了 20 項基準測試，對手是 Qwen3.8-27B、Meta 的 Muse-Glimmer-30B 與 Gemma4-31B，全部開到最高思考強度。南北閣說自己贏了其中 17 項。
幾個代表數字：測命令列操作的 Terminal-Bench 2.1 拿到 80.9，對手是 73.0；DeepSWE 65.5 對 42.5，差距最大；Automation Bench 54.2 對 38.3；JobBench 44.8 對 34.5。AIME 2026 是 95.2，AA-LCR 是 84.0。
這幾項測試的方向不太一樣。Terminal-Bench 考的是在終端機裡完成任務，DeepSWE 看的是修真實專案裡的多檔問題，Automation Bench 與 JobBench 模擬辦公室流程。全部偏向「動手做完」，而不是「回答得漂亮」，這跟它的智慧代理定位一致。
這些都是廠商自報，沒有第三方評測，也沒有獨立復現。基準測試的分數對測試框架、提示詞與評分腳本很敏感，換一套跑法結果就會動。
Nanbeige4.3-33B 落後的項目與對不上的兩行數字
模型卡沒有只挑好看的寫。SWE-Bench Pro 是 60.3，輸給 Qwen3.8-27B 的 61.7；GDPval 84.8 也落後對手的 86.4；Terminal-Bench 4.0 只拿到 23.8，是自家表格裡最低的一項。
更麻煩的是對照表本身有矛盾。Muse-Glimmer-30B 與 Gemma4-31B 在 SWE-Bench Pro 上的分數看起來寫反了，Meta 官方公布的是 51.2 與 36.9。GPQA Diamond 那欄給 Gemma4-31B 寫 91.3，Google 官方是 84.3。
不同的測試框架能解釋一部分落差，但 SWE-Bench Pro 那兩行不太像框架問題，比較像表格填錯。在看這份成績單時，把 17 比 3 當成方向，不要當成定論。
Nanbeige4.3-33B 怎麼部署
模型卡給了 Transformers、SGLang 與 vLLM 三種配方，範例用 4 路張量並行。跑代理任務建議 temperature 1.0、top_p 0.95、每次最多生成 65,536 個新 token；一般推理與聊天用 temperature 0.6、上下文開到 262,144。
4 路張量並行的意思，是把 66 GB 權重攤到四張卡上，每張約 16.5 GB，再加上自己的 KV cache。這個配置對企業機房不算過分，對個人工作站就是一筆開銷。
這些數值偏寬，代表模型在長流程任務上留了發揮空間，也代表它比較容易發散。實際接進產品前，建議先固定一組參數跑幾輪，確認行為穩定再放寬。
發布當下，Hugging Face 上沒有推論服務商託管這個模型。想用就得自己架，或是等社群把量化版本與推論服務配置補齊。
3B 版本才是這個系列的下一站
把 33B 當老師、蒸餾出 3B，這個路線在開源圈不新，執行得好卻不多。好處是推論成本可以壓到手機或筆電等級，同時保住大模型在多步驟任務上的判斷力。
真正的考驗在蒸餾後的落差。教師模型的 80.9 分，學生能留下多少，目前沒有數字。3B 版本一旦發布，社群第一件事一定是拿同一組基準重跑。
蒸餾也不是照抄答案。學生模型要學的是解題的步驟順序，資料品質比數量重要。這條路線能不能成立，三個月內大概就會有答案。
在那之前，Nanbeige4.3-33B 的意義有兩層：它是目前少見的 Apache 2.0 稠密 33B，也是觀察蒸餾技術的一個樣本。想自己跑的人，先確認手上的記憶體夠不夠，再決定要不要下載 66 GB 的權重。
