Qwen

Qwen3.5 小模型補齊戰線:9B 在多項基準超越 gpt-oss-120b

阿里巴巴 2 月底補上 Qwen3.5 的 0.8B–9B 四款小模型:Apache-2.0 開源、原生 262K 情境、支援影像影片輸入。9B 以 9.65B 密集參數在 MMLU-Pro、GPQA Diamond 超越 gpt-oss-120b,目標是手機與筆電上的本地多模態。

Qwen3.5 小模型補齊戰線:9B 在多項基準超越 gpt-oss-120b — 文章封面
本頁內容6 個段落
  1. 從 397B 到 0.8B:半個月補完整條戰線
  2. 9B:用 9.65B 參數做 120B 級的事
  3. 基準測試:贏在哪裡、輸在哪裡
  4. 邊緣部署的現實條件
  5. 對開發者與產品團隊的意義
  6. 參考來源

2 月 27 日起,阿里巴巴 Qwen 團隊把 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:半個月補完整條戰線

Qwen3.5 在 2 月 17 日的官方部落格裡定位為「原生多模態 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。架構是混合式線性注意力——每 4 個 block 一組,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,同樣原生 262K context、同樣支援影像與影片輸入——這個尺寸的視覺輸入支援,過去很少見。

架構選擇對邊緣部署有直接意義。線性注意力(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 週報

參考來源

本文由 AI 協助自上述來源整理,經人工審核後發布。

分享X電郵