Qwen 3.8 27B 發行說明

Qwen 3.8 27B 在緊湊的 27B 密集模型中提供前沿級的程式碼撰寫與代理能力

Qwen 3.8 27B 是截至目前為止 Qwen 開源模型家族中最強大的一代,基於 Qwen 3.5 的架構基礎打造。它在程式碼撰寫、專業研究以及長遠目標的代理任務上實現了顯著提升,同時保持了部署友善的規模。值得注意的是,它是一個原生的視覺語言模型,能夠理解圖片與小時級的影片。

核心技術規格

Qwen 3.8 27B 是一個因果語言模型,內建視覺編碼器。它是一個密集模型(非 MoE),具有以下架構:

  • 參數數量:270 億
  • 隱藏維度:5120
  • 層數:64
  • 上下文長度:原生支援 262,144 個 token,透過 RoPE 擴展可達 1,000,000 個 token(例如使用 YaRN)。
  • 架構佈局:16 × (3 × (Gated DeltaNet → FFN) → 1 × (Gated Attention → FFN))
  • MTP(多 token 預測):透過多步訓練提升推理效率。

主要功能增強

靈活的思考控制

Qwen 3.8 引入了「思考模式」,預設啟用。此模式允許模型在產生最終答案前生成內部推理過程(以 </tool_call> 標籤標示)。使用者可透過以下方式控制此行為:

  • reasoning_effort:調整推理深度,提供三個等級:xhigh(預設,適用於複雜分析)、medium(平衡)、low(優化速度/成本)。
  • preserve_thinking:預設啟用,保留歷史訊息中的推理區塊,以維持上下文連續性並提升 KV 快取利用率。
  • 指令模式:可完全關閉思考模式,以取得直接回應。

原生多模態智慧

該模型支援原生的影像與影片理解,涵蓋從 STEM 圖表與文件到小時級影片的各種場景。它在「電腦使用」情境中表現出色,包括 OSWorld、WebArena 與 AndroidWorld。

基準性能

Qwen 3.8 27B 相較於 Qwen 3.6 27B 有顯著提升,並與更大的前沿模型(如 Opus 4.6 Max)競爭激烈。

文字與程式碼性能

基準測試 Qwen 3.8 27B Qwen 3.6 27B Opus 4.6 Max
SWE-bench Pro (代理程式碼) 61.7 53.5 53.4
QwenSWEBench (軟體工程) 79.0 49.3 63.8
CoWorkBench (辦公工作) 70.7 61.0 68.2
LiveCodeBench v6 (競技程式碼) 90.3 83.9 88.8
IFBench (指令遵循) 79.5 69.1 62.5

視覺語言(VL)性能

基準測試 Qwen 3.8 27B Qwen 3.6 27B Opus 4.6 Max
OSWorld-Verified (電腦使用) 84.3 63.9 72.7
WebArena-Verified (瀏覽器使用) 64.8 48.8 --
AndroidWorld (行動裝置使用) 81.9 70.3 62.0
MathVision (視覺數學) 94.6(含 CI) 85.1 65.5

部署與服務最佳實務

推薦框架

針對生產工作負載,Qwen 團隊建議使用專用的服務引擎:

  • SGLangvLLMTokenSpeed
  • FP8 量化:釋出的 FP8 量化權重採用細粒度量化(區塊大小 128),性能幾乎與原始模型相同。

採樣參數

  • 思考模式temperature=1.0top_p=0.95top_k=20min_p=0.0presence_penalty=0.0repetition_penalty=1.0
  • 指令模式temperature=0.7top_p=0.80top_k=20min_p=0.0presence_penalty=1.5repetition_penalty=1.0

長上下文處理

為將上下文擴展至 1M token,使用者應修改 config.json 中的 rope_parameters,將 rope_type 設為 "yarn",並設定 factor 為 4.0。團隊提醒,靜態 YaRN 可能影響短文本的表現,建議根據典型應用長度調整 factor 值。

社群洞察與觀察

社群反饋來自 Hacker News,揭示了多項實務部署經驗:

  • 硬體表現:使用者報告在多種硬體上成功部署,包括 RTX 3090 與 M5 Max MacBooks。有使用者指出,在 RTX 5090 上使用 ninfer 引擎可達約 138 tokens/秒。
  • 推理行為:部分使用者觀察到 xhigh 推理模式可能導致「過度思考」或「枝節式程式碼」,建議簡單任務使用 mediumlow 效力。
  • 與 MoE 的比較:部分開發者表示更偏好混合專家(MoE)模型(如 35B A3B)以在低階硬體(如 M1 Max)上獲得更好效率,指出 27B 密集模型可能較耗記憶體。
  • 實際應用價值:多位使用者表示,該模型在實務上「感覺像 Opus 4.5/4.6」,特別是在複雜程式碼撰寫與 SVG 生成方面。

"我給它一張圖片和一個廣泛的構想,它從頭到尾完成了整個專案。" — @swalsh

Sources

相關