摘要： 阿里巴巴Qwen團隊從2月27日起把Qwen3.5系列的0.8B、2B、4B與9B四款密集小模型放上Hugging Face,採Apache-2.0授權,並在3月2日完成最後更新。9B支援原生262K context與影像、影片輸入,官方自報成績宣稱在MMLU-Pro與GPQA Diamond等項目壓過OpenAI gpt-oss-120b。不過競賽級程式仍明顯落後,實際部署還要為KV cache預留記憶體,0.8B也警示預設取樣下可能陷入思考迴圈。
阿里巴巴 Qwen 團隊從 2 月 27 日起,陸續把 Qwen3.5 系列還缺的成員補上 Hugging Face:0.8B、2B、4B、9B 四款密集(dense)小模型,採 Apache-2.0 授權,並於 3 月 2 日完成最後一輪更新。半個月前的 2 月 17 日,官方部落格才剛宣告系列開張、推出 397B-A17B 旗艦。9B 模型卡上的自報基準替這批小模型定了調:在 MMLU-Pro、GPQA Diamond 等多項測試壓過 OpenAI 的 gpt-oss-120b——以 9.65B 的參數量,扛下 120B 級模型的活。
開發者該看的不是榜上排名,而是這些模型能塞進哪些機器:原生 262K context、影像與影片輸入、Apache-2.0 授權,體積還小到放得進消費級硬體。四款清一色是 Reasoning 變體,與系列旗艦走同一套 thinking/non-thinking 混合設計。
從 397B 旗艦到 0.8B:半個月補齊全系列
2 月 17 日的官方部落格把 Qwen3.5 定位為「原生多模態 agent 模型」,打頭陣的 Qwen3.5-Plus 採 397B-A17B 稀疏 MoE。旗艦衝性能上限,小模型拚實際落地,0.8B 到 9B 填的正是光譜的另一端:能在手機、筆電與邊緣裝置上跑起來的多模態模型。Hugging Face 的 repo 紀錄顯示,9B 建立於 2 月 27 日、0.8B 建立於 2 月 28 日,兩者都在 3 月 2 日完成最後更新。
9B:以 9.65B 參數扛 120B 級任務
Qwen3.5-9B 本體是配備視覺編碼器的因果語言模型:參數量 9.65B(精確值 9,653,104,368)、32 層、hidden dim 4096。注意力採混合式線性設計:block 每 4 個一組,組內 3 個 Gated DeltaNet 搭配 1 個 Gated Attention,並訓練了 MTP(multi-token prediction)頭供投機解碼使用。原生 context 262,144 token,搭配 YaRN 最長可延伸到 1,010,000;輸入端接受文字、影像、影片,輸出端產生文字;覆蓋 201 種語言與方言。0.8B 則把同一套架構縮小一號:873M 參數、24 層、hidden 1024,原生 context 同樣是 262K,同樣支援影像與影片輸入——這個量級還吃得下視覺輸入,過去並不多見。
架構上的取捨對邊緣部署的影響很直接。採線性注意力(Gated DeltaNet)之後,長情境解碼不必對整段歷史做 full attention,吞吐、延遲與記憶體用量隨序列拉長只溫和上升;摻入少量 Gated Attention 則保住全局檢索能力,避開純線性模型在召回類任務上常見的退化。MTP 頭讓投機解碼能一次驗證多個 token,把每 token 的有效成本再往下壓。說白一點,這套組合不是把大模型按比例縮小了事,而是針對「在有限硬體上跑長情境」重新設計出來的組合。
基準成績:強項與短板各在哪
9B 模型卡挑對照組毫不客氣,直接放上 GPT-OSS-120B 與 GPT-OSS-20B:
- MMLU-Pro 一項,9B 得分 82.5,壓過 GPT-OSS-120B 的 80.8 與 GPT-OSS-20B 的 74.8;4B 也有 79.1 的水準。
- GPQA Diamond 拿下 81.7,對手分別是 80.1 與 71.5;IFEval 得分 91.5,兩個對照組為 88.9 與 88.2。
- 最搶眼的是 agent 與工具呼叫:TAU2-Bench 79.1(Qwen3-Next-80B-A3B 為 57.4)、BFCL-V4 66.1(49.7);4B 在 TAU2-Bench 甚至衝到 79.9。
- 中文與長情境方面,C-Eval 88.2、LongBench v2 55.2,皆高過兩個 GPT-OSS 對照組。
綜觀整組數字,9B 的長處集中在知識廣度、指令遵循與 agent 工具呼叫,數學競賽與高難度程式題並非所長——而這樣的能力分布,恰好對上裝置端應用最常見的需求組合。
缺點也得攤開講:LiveCodeBench v6 僅 65.6,GPT-OSS-120B 則有 82.7;OJBench 為 29.2 對 41.5。競賽級程式設計仍是明顯短板。另外,0.8B 的模型卡特別註記:thinking 模式若搭配預設取樣設定,模型容易陷入「思考迴圈」。
邊緣部署前,先算現實帳
記憶體這筆帳先算:9B 的 BF16 權重約 18 GB,換成 4-bit 量化後約 5–6 GB,中階筆電跑得動,旗艦手機略嫌勉強;0.8B 的 BF16 權重約 1.75 GB,量化後連輕薄裝置都裝得下。要留意的是,這些數字尚未計入 KV cache——想把 262K context 的優勢用滿,就得另外騰出空間給 cache,而這正是混合線性注意力派上用場之處:它的 cache 隨長度增長的曲線,比 full attention 平緩許多。
落到實際場景:有了 0.8B,穿戴式與 IoT 級裝置都能認真考慮跑一個看得懂圖、讀得動長文的模型;9B 則把「本地多模態助理」的入場門檻降到一台中階筆電。適用的任務輪廓相當明確:文件密集型應用(合約、報告、手冊)、裝置端多媒體理解,以及必須全程離線的隱私敏感流程——資料留在裝置內,傳輸與雲端成本自然無從談起。
開發者與產品團隊該怎麼看
提出三點判斷。其一,9B 的價值在於「多模態 + 262K context + Apache-2.0」三個條件同時到位:以往這個量級的模型,不是少了視覺,就是 context 停在 32K,如今一次補滿,裝置端應用可發揮的設計空間明顯擴大。其二,它在 agent 工具呼叫上的表現,說明小模型的可用邊界正持續外推——當 9B 能在 TAU2-Bench 繳出 79.1,把規劃與呼叫留在裝置、只將必要步驟送上雲端,便成了一種行得通的成本架構。其三,別只盯著贏的項目:程式競賽基準的落差提醒我們,選模型仍要按任務畫線,而不是迷信單一排行榜;自報數字也永遠值得換成自己的工作負載重測一次。同一週產業層級的大事,可參考我們的 AI 週報。