Qwen 3.8 27B リリースノート

Qwen 3.8 27B はコンパクトな 27B デンスモデルで、最先端レベルのコーディングおよびエージェント機能を実現

Qwen 3.8 27B は、これまでの Qwen オープンモデルファミリーで最も高性能なモデルであり、Qwen 3.5 のアーキテクチャを基盤として構築されています。コーディング、専門的リサーチ、長期間のエージェントタスクにおいて大幅な向上を達成しつつ、デプロイに優しいサイズを維持しています。特に、画像および時間単位の動画を理解できるネイティブな視覚言語モデルである点が特徴です。

コア技術仕様

Qwen 3.8 27B は、統合された視覚エンコーダを備えた因果言語モデルです。非 MoE の密度型モデル（dense model）であり、以下のアーキテクチャを持ちます：

パラメータ数: 270億
隠れ層次元: 5120
レイヤー数: 64
コンテキスト長: ネイティブで 262,144 トークン、RoPE スケーリング（例：YaRN）により最大 1,000,000 トークンまで拡張可能
アーキテクチャレイアウト: 16 × (3 × (ゲート付き DeltaNet → FFN) → 1 × (ゲート付きアテンション → FFN))
MTP（マルチトークン予測）: 複数ステップで訓練され、推論効率の向上を図っています。

主な機能強化

柔軟な思考制御

Qwen 3.8 はデフォルトで有効な「思考モード」を導入しています。このモードにより、最終的な回答を出力する前に内部の推論プロセス（` タグで示される）を生成できます。ユーザーは以下のパラメータでこの挙動を制御できます：

reasoning_effort: 推論の深さを3段階で調整可能：xhigh（デフォルト、複雑な分析向け）、medium（バランス）、low（速度/コスト最適化向け）。
preserve_thinking: デフォルトで有効。過去のメッセージからの推論ブロックを保持することで、コンテキストの連続性を維持し、KVキャッシュの利用効率を向上させます。
Instruct モード: 直接的な応答を求める場合、思考モードを完全に無効化できます。

ネイティブなマルチモーダル知能

このモデルは、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 チームは専用のサービングエンジンの使用を推奨しています：

SGLang, vLLM, または TokenSpeed。
FP8 量子化: 配布された FP8 量子化済み重みは細粒度量子化（ブロックサイズ 128）を使用しており、オリジナルモデルとほぼ同等のパフォーマンスを実現しています。

サンプリングパラメータ

思考モード: temperature=1.0, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=0.0, repetition_penalty=1.0
Instruct モード: temperature=0.7, top_p=0.80, top_k=20, min_p=0.0, presence_penalty=1.5, repetition_penalty=1.0

長文コンテキストの扱い

100万トークンまでコンテキストを拡張するには、config.json の rope_parameters を変更し、rope_type: "yarn" に設定し、factor を 4.0 に設定してください。チームは、静的 YaRN が短いテキストでのパフォーマンスに影響を与える可能性があると警告しており、通常のアプリケーションの長さに応じて factor を調整することを推奨しています。

コミュニティの洞察と観察

Hacker News からのコミュニティフィードバックは、いくつかの実用的なデプロイ経験を示しています：

ハードウェアパフォーマンス: RTX 3090 や M5 Max MacBooks など、さまざまなハードウェアでの成功したデプロイが報告されています。あるユーザーは、RTX 5090 で ninfer エンジンを使用したところ、約 138 トークン/秒の速度を達成したと述べています。
推論挙動: 一部のユーザーは、xhigh 推論モードが「過剰な思考」や「分岐したコード」を引き起こすことがあると観察しており、シンプルなタスクには medium や low の努力レベルがより適している可能性があると指摘しています。
MoE との比較: 一部の開発者は、M1 Max などの低スペックハードウェアでの効率性を考慮し、Mixture-of-Experts（MoE）モデル（例：35B A3B）を好む傾向があると述べており、27B デンスモデルがメモリを多く消費する可能性があると指摘しています。
実世界での有用性: 複数のユーザーが、このモデルが「実際には Opus 4.5/4.6 のように感じられる」と報告しており、特に複雑なコーディングタスクや SVG 生成において顕著です。

"画像と、私が作りたいものの広範な概要を渡したところ、最初から最後まで一貫して全体を構築してくれました。" — @swalsh