Qwen3.8-27B 開源：SWE-bench Pro 61.7 贏過 Opus 4.6 Max，「那就用地端」第一次不是妥協

這是我看過大家敲碗最久的小模型。

三月林俊楊離職的時候，社群都在擔心千問即將閉源。Qwen 3.7 只出了 API-only 的 Max，沒有開源 27B，擔心變成了恐慌。結果這幾個月 Kimi、DeepSeek、GLM 齊力發力，千問在開源圈的領先被碾了一輪。被打到危機之後，Qwen 重新記起它最強的優勢在哪裡了。

8/14，Qwen3.8-27B 權重放出來。Apache 2.0，27B dense，原生多模態，262K context。

官方 benchmark 表裡最顯眼的一行：SWE-bench Pro 61.7。Claude Opus 4.6 Max 是 53.4。

SWE-bench Pro：Qwen3.8-27B 61.7 vs Claude Opus 4.6 Max 53.4

一個跑在自己腳下的 local AI，能力直逼我最喜歡的 Opus 4.6。天上掉餡餅。

今天是資安日。這個發布值得放在資安日講，因為過去企業想用地端模型，永遠繞不開同一個尷尬：地端是安全的，但也是降級的。Qwen3.8-27B 是第一次在官方數字上，27B 級距的開源模型在 agentic 任務贏過 frontier 閉源模型——「那就用地端」第一次不是妥協。

30 秒定位

項目	Qwen3.8-27B
架構	27B dense，64 層混合（48 Gated DeltaNet + 16 full attention）
模態	原生多模態：文字、圖片、影片輸入
Context	262K 原生，YaRN 可擴到 1M
License	Apache 2.0
權重大小	BF16 51.76 GiB / FP8 28.76 GiB / 第三方 Q4 約 17 GiB
同場發布	Qwen3.8-2.4T-A95B（Max 級）權重也已開源

贏輸分布比單一分數重要

把官方 benchmark 表攤開，跟 Opus 4.6 Max 的對戰結果有一個很清楚的結構。

27B 贏的項目：

Benchmark	Qwen3.8-27B	Opus 4.6 Max
SWE-bench Pro（agentic coding）	61.7	53.4
LiveCodeBench v6（競程）	90.3	88.8
CoWorkBench（長程辦公任務）	70.7	68.2
IFBench（指令遵循）	79.5	62.5
OSWorld-Verified（電腦操作）	84.3	72.7
AndroidWorld（手機操作）	81.9	62.0

27B 輸的項目：

Benchmark	Qwen3.8-27B	Opus 4.6 Max
Terminal Bench 2.1	73.0	78.2
GPQA Diamond（科學推理）	89.2	91.3
HLE（跨領域推理）	30.8	40.0
NL2Repo-Bench（整 repo 生成）	42.3	47.6

分布不是隨機的。贏的全是 agentic workflow 類：改 code、跑流程、操作電腦和手機、聽懂指令。輸的全是知識和推理天花板類：科學推理、跨領域難題、從零生成整個 repo。

贏輸分布：Agentic 任務全贏，知識天花板任務全輸

這個分布恰好對到企業內部部署的需求清單。企業 agent 的日常是「讀 ticket、改三個檔案、跑測試、填表單、操作內部系統」，不是解 GPQA 等級的科學題。天花板類能力輸 Opus 幾分，對這類 workload 的影響有限；agentic 類能力贏，才是每天都用得到的差異。

對比前代也能看出這次的重心：同一張表裡，SWE-bench Pro 從 Qwen3.6-27B 的 53.5 拉到 61.7，DeepSWE 從 13.3 拉到 42.2，OSWorld 從 63.9 拉到 84.3。這不是全面均勻進步，是對著 agent 場景集中火力。

架構沒變，變的是 agent 訓練

這個贏輸分布為什麼長這樣？把 Qwen3.8-27B 的 config.json、權重索引和 Transformers 實作翻一遍，答案很明確：底層架構跟 Qwen3.6-27B 幾乎沒有變化。

model_type 仍然是 qwen3_5。64 層 decoder、5120 hidden size、17408 FFN、48 層 Gated DeltaNet + 16 層 full attention、24 個 query heads、4 個 KV heads、262K context、同一套視覺塔、同一套 MTP 配置、同一個詞表——逐項對比，關鍵參數完全一樣。

這意味著 agentic benchmark 的跳升不是來自架構創新。更合理的判斷是：阿里已經把 Qwen3.5 這套 hybrid 架構穩定下來，集中火力優化權重、agent 軌跡訓練、coding 環境交互數據、強化學習和 tool calling 行為。

Qwen3.8 不是「架構上的 3.8」，是「agent 行為上的 3.8」。

底層架構 0 變化，飛躍的進步來自後訓練

這也解釋了為什麼 GPQA Diamond 只進步 1.4 分、HLE 幾乎沒動，而 OSWorld 跳了 20.4 分、DeepSWE 跳了 28.9 分——前者靠的是模型容量和預訓練知識，後者靠的是後訓練和環境交互數據。架構不變、後訓練集中火力，跳的自然是後者。

對生產系統來說，這反而是好消息。架構穩定意味著 vLLM、SGLang 等推理引擎不用重新適配算子，量化方案可以繼承，已有的 kernel 優化可以複用，企業遷移成本更低。

部署現實：Hybrid 架構天生省 KV cache

前面講了架構沒變，但這套 hybrid 架構本身對地端部署有一個很實際的好處：64 層裡只有 16 層需要存隨 context 線性增長的 KV cache。

混合架構記憶體優勢：48 Gated DeltaNet + 16 Full Attention

48 層 Gated DeltaNet 維護的是固定大小的遞迴狀態矩陣，不管 context 多長，記憶體佔用不變。傳統純 Transformer 的 64 層每層都要存 KV cache，Qwen3.8 只有 16 層要。這讓它比同規模的純 Transformer 天生更適合長會話、coding agent、多輪 tool calling 這類 context 越跑越長的場景。

但不能神化——那 16 層 full attention 的 KV cache 還是在的。BF16 下每個 token 約 64 KiB，262K 全開約 16 GiB，1M context 約 61 GiB。二次複雜度從 64 層降到 16 層，不是消除了二次複雜度。

資安日系列的老讀者知道，我七月借 RTX Pro 6000 跑過一週 Tier 1 地端實驗：GLM 5.2 那種 744B 級的模型，96GB VRAM 塞不下，得靠 MoE offload 到系統 RAM，天花板釘死在每秒十個 token 上下，互動式 agent 用起來是煎熬。

27B dense + hybrid cache 完全是另一個世界：

FP8 官方版 28.76 GiB：一張 48GB 級的卡，權重加上工作 context 的 KV cache 可以住得舒服
第三方 Q4 量化約 17 GiB：一張 24GB 消費卡就能跑中等 context
唯一要注意的是長 context 的帳：262K 全開時光 full-attention 那 16 層的 KV cache 就要約 16 GiB，24GB 卡跑的是「Q4 + 節制的 context」，不是規格表上的滿血狀態

兩天前我才在記憶體漲價那篇寫「先選模型，才決定買什麼硬體；27B 級距讓你避開整個為大模型而生的硬體採購」，當時 Qwen3.8-27B 權重還沒放出來，只能當期貨寫。現在權重在手，這條路線補上了最關鍵的一塊：27B 級距第一次有了官方數字上打贏 frontier 模型的選項。

但量化有一個舊帳要記得。Bonsai 27B 那篇的教訓：壓縮損失不均勻，前代 Qwen3.6-27B 壓到 1-bit 時 MATH 500 從 99.4 只掉到 98，TauBench（tool calling）卻從 82.9 掉到 61.3。官方 benchmark 是 BF16/FP8 測的，你在 24GB 卡上跑的 Q4 版折損多少、有沒有剛好折在 agentic 能力上——目前沒有人量過。拿到量化版之後，先測 tool calling，再決定信多少。

實測報告：RTX 5090 32GB 跑 Qwen3.8-27B

硬體與模型配置

項目	設定
GPU	NVIDIA RTX 5090 32 GB
模型	Qwen3.8-27B UD-Q4_K_XL
模型大小	17.92 GB
Context 上限	262,144 tokens
實際最長輸入	約 237,100 tokens
KV Cache	Q4_0（K／V）
Flash Attention	開啟
MTP	開啟，draft max 2、p-min 0.75
Parallel	1
CPU threads	8
Thinking	開啟
Thinking budget	1,536 tokens
Answer 上限	4,096 tokens
Temperature	0
Prompt cache	開啟
視覺投影	未載入；本次為純文字測試

VRAM 實際佔用

模型服務：約 26 GB
包含背景程序後：約 29 GB
長 context 運作時剩餘：約 3 GB
Q8_0 KV：長文預填約到 67K tokens 時 OOM
Q4_0 KV：可完成約 237K token 全文輸入

32GB 卡要跑滿 262K context，KV Cache 必須壓到 Q4——Q8 跑不完。

生成速度

情境	生成速度
7K–28K context（日常對話、短文）	100–126 tok/s
Thinking 全部題目平均	106.7 tok/s
Thinking 關閉平均	112.8 tok/s
237K context（接近滿載）	49–55 tok/s
MTP 關閉基準	~72 tok/s

237K 首次 prompt 預填約 238 秒
Prompt cache 命中後約 12–83 秒／題
全部題目平均總時間約 20 秒

Thinking 對生成速度的影響不算大（106.7 vs 112.8），主要成本來自額外的思考 tokens。Context 超過 200K 後，attention 計算才是主要瓶頸——從 100+ tok/s 掉到 49–55 tok/s。

上個月同一台機器跑 GLM 5.2 offload 是十幾 tok/s 的煎熬，27B dense 在日常 context 跑 100+ tok/s——即時對話、長文摘要、高頻推論都沒問題，互動式 agent 完全可以用。

啟動參數

伺服器端（llama.cpp）：

llama-server \
  -m Qwen3.8-27B-UD-Q4_K_XL.gguf \
  -ngl 99 \
  --flash-attn on \
  --cache-type-k q4_0 \
  --cache-type-v q4_0 \
  --ctx-size 262144 \
  --spec-type draft-mtp \
  --spec-draft-p-min 0.75 \
  --spec-draft-n-max 2 \
  --parallel 1 \
  --reasoning on \
  --reasoning-format deepseek \
  --reasoning-budget 1536 \
  --host 0.0.0.0 \
  --port 8001 \
  -t 8

API 參數：

{
  "temperature": 0,
  "max_tokens": 4096,
  "cache_prompt": true,
  "reasoning_effort": "medium",
  "chat_template_kwargs": {
    "enable_thinking": true
  }
}

真正限制思考長度的是伺服器端的 --reasoning-budget 1536；單獨設定 reasoning_effort 不足以避免 Thinking 用盡輸出額度。

RTX 5090 vs DGX Spark

社群在 DGX Spark 上跑同一顆模型的數字也出來了，放在一起看差距很直觀：

硬體	量化 / 引擎	速度	來源
RTX 5090 32GB	Q4_K_XL + MTP（日常 context）	100–126 tok/s	我的實測
RTX 5090 32GB	Q4_K_XL + MTP（237K context）	49–55 tok/s	我的實測
RTX 5090	SGLang NVFP4	206.1 tok/s	SGLang
DGX Spark	SGLang NVFP4	38.28 tok/s	SGLang
DGX Spark	Q4 基本配置	~40 tok/s	sudoingX
DGX Spark	256K context	~19 tok/s	ivanfioravanti

同一顆模型、同一個推理引擎，5090 對 Spark 是 206 對 38——差 5.4 倍。原因不是算力，是記憶體頻寬：5090 的 GDDR7 約 1,792 GB/s，Spark 的 LPDDR5X 約 273 GB/s。Dense 模型每生成一個 token 要把全部權重讀一遍，頻寬不夠就是慢。MoE 每 token 只讀一小部分專家權重，統一記憶體的低頻寬還撐得住；dense 27B 剛好塞得進獨顯 VRAM，Spark 的大容量優勢用不上，只剩頻寬劣勢。27B dense 選獨顯，大 MoE 才選統一記憶體——選硬體要看模型架構，不是看參數量。

「地端模型比較安全」的誠實版本

「地端模型比較安全」——這句話現在工程師可以理直氣壯地講了，而且不用心虛能力差太多。

但今天是資安日，這句話本身也要過一次資安檢驗。

地端部署真正解掉的是資料出境風險：prompt、程式碼、客戶資料不離開機房，沒有供應商的資料保留條款要審，沒有跨境傳輸的合規問題要處理。對台灣的金融、醫療、政府標案場景，這一類風險經常是「一票否決」級的，地端把它整個拿掉，這是真的。

但地端沒有解掉 agent 行為風險。一個能改 code、跑指令、操作內部系統的 agent，跑在你自己的機器上，prompt injection 一樣打得進來，權限給太大一樣刪得掉資料庫。這一類風險跟模型放在哪裡無關，跟 harness 怎麼設計有關。

資安邊界：地端解決資料出境，但 agent 行為風險仍在

所以誠實版本是：地端解掉的是「資料流向誰」的問題，不是「agent 會做什麼」的問題。 前者是採購和合規層級，後者是工程層級。「地端比較安全」這句話成立，但只成立一半——權限收斂和工具鏈隔離的工還是一樣多。

反方：這些是 Qwen 自己測的

先把最強的反駁擺出來：整張 benchmark 表是 Qwen 發的。

而且測法不對等。官方註明，SWE-bench Pro 上除了 Opus 4.6 Max 用官方報告分數，其他模型都是 Qwen 用 Claude Code harness、temp=1.0、256K context 自己測的——這不是同一套條件下的對照實驗。分差最大的兩項（QwenSWEBench 79.0 對 63.8、CoWorkBench 70.7 對 68.2）恰好都是 Qwen 自家出的 benchmark。發布隔天，還沒有任何第三方獨立復現。輸掉的四項倒是不用懷疑，那是官方表自己承認的。

這些折扣都打完之後，剩下什麼？

剩下的其實還夠。這個論點不需要「27B 全面超越 Opus 4.6 Max」才成立——那個宣稱本來就不成立，天花板類的四項輸得清清楚楚。它只需要「27B 在企業 agent workload 上夠接近 frontier，讓能力差距不再是否決地端的理由」。SWE-bench Pro 是公開 benchmark，53.5 到 61.7 的世代進步是同 harness 同條件測出來的；OSWorld 從 63.9 到 84.3 的跳幅，就算打七折也還是換了一個級距。方向的可信度，比單點數字的精確度高。

坦白說

全部數字來自官方發布，發布隔天沒有第三方復現。這篇是「官方宣稱的拆解」，不是實測報告。
速度我自己跑出來了（RTX 5090 + Q4_K_XL + MTP，日常 context 100–126 tok/s、237K 長文 49–55 tok/s；Q8 KV 在 67K 就 OOM，32GB 卡要吃滿 262K 必須用 Q4 KV），但 agent 品質的系統性評測還沒做——尤其是 Q4 量化後的 tool calling 折損。benchmark 判斷仍掛著「如果官方數字可信」的前提。
「贏的都是 agentic 類」這個分布，也可以反過來解讀成「Qwen 挑了對自己有利的項目放進表格」。OSWorld 和 AndroidWorld 的對比數字來自官方公布，Opus 那一側的測試條件我查不到公開細節。
社群第一批實測反饋最一致的抱怨是「想太多」。 官方預設 reasoning_effort=xhigh，有人拿同一個 Tetris 任務測，3.6 想了約 3,000 字就動手，3.8 想到 15,000 字還在想。成品確實更精緻（自己加了暫停、高分榜、復古音效），但牆鐘時間差了好幾倍。從開源 chat template 來看，reasoning_effort 本質上是 prompt steering（system prompt 裡加不同強度的「仔細想」指示），不是動態網路深度。調成 medium 或關掉 thinking 之後問題會小很多，但這表示官方 benchmark 大概率是 xhigh 跑出來的分數，日常使用如果調低 effort 來換速度，能力是否打折還不知道。
27B 打的是 Opus 4.6 Max 這一代。frontier 模型也在動，這個「夠接近」的窗口能開多久，沒人知道。

關鍵洞察

「那就用地端」第一次不是妥協。 過去選地端等於接受降級。現在 27B 在 agentic 任務的官方數字贏過 Opus 4.6 Max，能力差距這個反對理由接不下去了。
看 benchmark 先看贏輸分布，再看單一分數。 27B 贏在 agentic workflow，輸在知識天花板。你的 workload 落在哪一類，決定這張表對你是利多還是雜訊。企業內部 agent 多數落在前者。
量化之後先測 tool calling。 官方數字是 BF16/FP8 的，24GB 卡上跑的 Q4 是另一顆沒人測過的模型。Bonsai 的教訓還熱著：壓縮最先傷的就是 agent 能力。
「地端比較安全」只解一半。 資料出境風險歸零，agent 行為風險原封不動。會議打贏之後，harness 的權限設計才是資安工作的開始。

Wisely Chen｜AI Agent、地端 LLM 與企業 AI 架構實戰筆記

Qwen3.8-27B 開源：SWE-bench Pro 61.7 贏過 Opus 4.6 Max，「那就用地端」第一次不是妥協

Qwen3.8-27B 開源：SWE-bench Pro 61.7 贏過 Opus 4.6 Max，「那就用地端」第一次不是妥協

30 秒定位

贏輸分布比單一分數重要

架構沒變，變的是 agent 訓練

部署現實：Hybrid 架構天生省 KV cache

實測報告：RTX 5090 32GB 跑 Qwen3.8-27B

硬體與模型配置

VRAM 實際佔用

生成速度

啟動參數

RTX 5090 vs DGX Spark

「地端模型比較安全」的誠實版本

反方：這些是 Qwen 自己測的

坦白說

關鍵洞察

延伸閱讀

一手來源

我之前寫過的相關文章