Qwen3.8-27Bとは？Apache 2.0で商用可のローカルLLM｜必要VRAM・ベンチマーク・使い方を整理

Qwen3.8-27B は、Alibaba Cloud の Qwen（通義）チームが2026年8月14日（日本時間15日）に Apache 2.0 ライセンスで公開した、270億パラメータのマルチモーダル・オープンウェイトLLMです。 画像と動画も入力でき、ネイティブで262,144トークンの文脈を扱い、量子化すればGPU 1枚のPCでもローカル実行できます。

ただし注意点が2つあります。同じ「Qwen3.8」を名乗るモデルでも Apache 2.0 なのは 27B だけで、上位の Qwen3.8-2.4T-A95B は別ライセンスです。また公開されているベンチマークはすべて Qwen 自身の発表値で、独立した第三者による再現検証は本稿執筆時点で確認できていません。

想定読者は、社内データを外に出さずにLLMを動かしたい企業の技術担当者、自前GPUでコーディングエージェントを回したい開発者、ローカルLLM用のマシン購入を検討している個人です。必要VRAM、ライセンス、ベンチマークの読み方、Ollama・vLLM での動かし方、API利用とのコスト比較まで、公式モデルカードとベンダー公式ドキュメントで確認できた範囲で整理します。

Qwen3.8-27Bの位置づけ：押さえておく3点

1. 「27Bクラスで現状最強クラス」だが「フロンティア置き換え」ではない。 公式発表値では Terminal-Bench 2.1 で 73.0、OSWorld-Verified で 84.3 と、前世代 Qwen3.6-27B を大きく上回ります。ただし同じ Terminal-Bench で Claude Opus 4.8 は 78.9、DeepSWE 1.1 では GPT-5.6 が 72.7（Qwen3.8-27B は 42.2）とされ、難度の高いエージェント系タスクでは差が残ります。
2. Apache 2.0 で商用利用できるのは「27B」。 同時期に公開された Qwen3.8-2.4T-A95B は独自ライセンスで条件が異なります。ここを混同すると法務判断を誤ります。
3. 「動く」と「実用になる」は別。 4bit量子化なら重み17〜19GB程度ですが、実際にはKVキャッシュがこの上に乗ります。長い文脈を使うほどメモリは膨らみ、公称サイズどおりのVRAMでは足りません。

迷ったときの判断は単純です。機密データを外に出せない／トークン課金の上限なしに回したいならローカル実行の価値が大きく、単にコストを下げたいだけならAPI経由のほうが安く済むケースが大半です。

Qwen3.8-27Bの基本スペック

出典：Hugging Face「Qwen」公式Organizationページ（https://huggingface.co/Qwen）

Qwen3.8-27B は、テキストに加えて画像・動画を理解できる Dense（非MoE）モデルです。Hugging Face と ModelScope からウェイトをダウンロードして自己ホストできます。

なぜ27Bで長文が現実的に回るのか

日本語の解説記事ではあまり触れられていませんが、Qwen3.8-27B の長文処理はアーキテクチャ側の工夫に支えられています。公式モデルカードによれば、レイヤ構成は次のようなハイブリッド型です。

16 × ( 3 × (Gated DeltaNet → FFN) → 1 × (Gated Attention → FFN) )

• Gated DeltaNet（線形アテンション）を3層に対して、フルアテンション（Gated Attention）を1層という比率で混成
• 隠れ層次元 5,120／64レイヤ／FFN中間次元 17,408
• 学習には Multi-Token Prediction（MTP）を使用

線形アテンション主体にすることで、文脈長に比例して膨らむKVキャッシュを抑えるのが狙いです。262Kという長さを27Bクラスで実用域に持ち込めている理由がここにあります。裏を返すと、推論エンジン側がこのハイブリッド構成に対応していないと正しく動きません。 vLLM や SGLang にバージョン要件があるのはこのためです。

【重要】「Qwen3.8＝Apache 2.0」は誤り。3モデルの違い

出典：GitHub「QwenLM/Qwen3」公式リポジトリ（https://github.com/QwenLM/Qwen3）

ここは事実誤認が広がっている部分です。2026年8月に「Qwen3.8」の名前で複数のモデルが登場しましたが、ライセンスもモダリティも別物です。

つまり、Apache 2.0 で自由に商用利用・再配布・派生モデル配布ができるのは 27B のみです。2.4T-A95B は「オープンウェイト」ではあってもライセンス条文が別で、事業規模によって追加要件が発生するとされています（条文の具体的制限については、利用前に必ず原文を確認してください）。

多くの記事が「Qwen3.8がApache 2.0で公開」とまとめていますが、法務レビューに通すのであればモデル名単位で確認する必要があります。上位モデル側の詳細は Qwen3.8-Maxの解説記事 で扱っています。Qwenシリーズの系譜としては、Qwen 3.7 Max や Qwen3.6-Plus も参考になります。

Qwen3.8-27Bでできること

1. 画像・動画の理解

STEM分野の図表、スキャンした文書、長尺動画の内容理解に対応します。文書解析系の OmniDocBench 1.5 では 91.1（公式発表値）と、OCR・レイアウト解析用途にも耐える水準が示されています。

一方で音声の入出力には対応していません。音声込みで扱いたい場合は Qwen 3.5-Omni のようなOmni系モデルが別途必要です。

2. Thinking（熟考）モードの3段階制御

既定でThinkingがONになっており、<think>...</think> ブロックを生成しながら推論します。特徴はリクエスト単位でOFFにでき、深さも3段階から選べることです。

API では reasoning_effort パラメータ、Ollama では /set parameter nothink などで制御します。また Preserved Thinking（過去メッセージのthinkingブロックを保持して一貫性を上げる機能）が備わっており、preserve_thinking: false で無効化できます。

実務上ここは重要で、既定の xhigh のままだと「今日は何日？」レベルの質問にも推論トークンを大量消費します。ローカルでは体感速度の低下、API経由では課金額に直結するため、タスクに応じた設定変更を前提に組んでください。

3. エージェントとしての実行能力

Qwen3.8-27B の売りは、テキスト生成よりむしろエージェント方向です。公式発表値では PC操作の OSWorld-Verified が 84.3、モバイル操作の AndroidWorld が 81.9、ブラウザ操作の WebArena-Verified が 64.8 とされています。

• 自律的な計画立案と、環境フィードバックを受けた再計画
• マルチモーダルなツール呼び出し（画面を見ながらの操作）
• 構造化出力（JSON等）への対応
• 長時間タスクの完遂

ツール連携の標準規格については MCP（Model Context Protocol）の解説 も合わせて確認すると、実装イメージが掴みやすくなります。

4. ファインチューニングと派生モデルの配布

Apache 2.0 のため、LoRA等でファインチューニングした派生モデルを商用配布することも可能です（帰属表示とライセンス条文の同梱が必要）。Unsloth Desktop が Thinkingトグル付きの実行とLoRAファインチューニングに対応しています。

5. 推奨サンプリングパラメータ（公式）

公式モデルカードはモードごとに異なる設定を推奨しています。ここを既定値のまま使うと性能を出し切れません。

ベンチマークスコア（すべてQwen公式発表値）

まず前提を明示します。以下のスコアはすべてQwenが自社で公表した数値であり、本記事執筆時点（2026年8月17日）で独立した第三者による再現検証は確認できていません。 QwenSWEBench のような自社ベンチも含まれます。参考値として読んでください。

テキスト・コーディング系

マルチモーダル・エージェント系

フロンティアモデルとの距離

数字を正しく読むために、上位モデルとの差も並べておきます。

難度の高い自律コーディングでは、依然として明確な差があります。 「27Bというサイズで、無料で、手元のGPUで動く」ことの価値が大きいのであって、クラウドのフロンティアモデルをそのまま置き換えられるという話ではありません。なお学習コーパス・学習トークン数・知識カットオフはいずれも非公開です。

同じくオープンライセンスの中国系モデルとしては GLM-5.1 や Kimi K2.6 が競合にあたります。

必要スペック：量子化別の必要VRAMと現実的な構成

ローカル実行を検討している方にとって、ここが最大の関心事だと思います。

量子化別の目安

ウェイトサイズ＝必要メモリ、ではない

多くの解説記事が量子化ファイルのサイズだけを載せて終わっていますが、実際に必要なのは次の合計です。

必要VRAM ＝ ウェイト ＋ KVキャッシュ ＋ アクティベーション等のオーバーヘッド

KVキャッシュはコンテキスト長と同時実行数にほぼ比例して増えます。4bit量子化で重みが18GBでも、100Kトークンのコードベースを丸ごと読ませれば、そこに数GB〜十数GBが上乗せされます。262Kをフルに使う想定なら、公称ウェイトサイズの何倍もの余裕が必要です。

節約手段としては、KVキャッシュ自体の量子化（llama.cpp系で q8_0 を指定すると既定のf16に対して概ね半分）と、Flash Attention の有効化が定番です。

環境別の判断ライン

Mac については、LM Studio と Unsloth の GGUF を組み合わせて16GBクラスから動作したという報告があります。統合メモリはOS・他アプリと共有するため、実際にはさらに余裕を見てください。

日本語での実測レポートから読み取れること

RTX 5070 Ti（VRAM 16GB）＋ Ryzen 7 5800X3D ＋ WSL2（メモリ48GB割当）という構成での検証レポートが日本語で公開されています。要点は次のとおりです。

• Q4_K_M（約19GB）は16GB VRAMに載り切らず、CPUオフロード必須（GPU約70%／CPU約30%配分）。応答に体感できる遅延が出る
• KVキャッシュを q8_0 にすることでメモリを圧縮、Flash Attention も有効化
• 既定の xhigh Thinking は単純な質問でも文脈を浪費するため、タスクに応じて low またはOFFが推奨
• 数学・化学の推論は良好だが、ニッチな事実知識（日本のローカルな話題など）ではハルシネーションや欠落が発生
• 専門ツール向けの厳密なフォーマット生成（計算化学ソフトの入力ファイルなど）では、キーワード混同や座標の不整合が起きた

この報告から読み取るべき実務的な結論は、「16GBでも一応動くが、常用したいなら24GB以上」「日本語のローカル知識には期待しすぎない」の2点です。日本語特有の知識が重要な用途では、国産LLMの比較 や LLM-jp-4 のような国内モデルとの併用も検討する価値があります。

使い方：4つの実行ルート

出典：GitHub「vllm-project/vllm」公式リポジトリ（https://github.com/vllm-project/vllm）

用途と手持ちの環境によって、選ぶべきルートが変わります。

1. Ollama / LM Studio でまず試す

もっとも手軽なルートです。Unsloth が公開日当日に Dynamic V3.0（preview）の GGUF を公開しており、llama.cpp / LM Studio / Ollama / Jan から直接ロードできます。

# 量子化版を指定してロードする例
ollama run hf.co/unsloth/Qwen3.8-27B-GGUF:UD-Q2_K_XL

VRAMに応じて UD-Q4_K_XL（約17〜19GB）、UD-Q2_K_XL（約11〜13GB）などタグを変えます。まず動かして体感速度を測り、そのうえで量子化レベルを上げ下げするのが確実です。

2. vLLM で社内APIとして立てる

vLLM は 0.17.0 以降でハイブリッドアテンション用のカーネルと公式レシピを同梱しています。OpenAI互換の /v1 エンドポイントが立つため、既存のクライアントコードをほぼそのまま使えます。

vllm serve "Qwen/Qwen3.8-27B"

262Kを超える長文（YaRNによる拡張）を使う場合は、config.json にYaRN設定を指定します。

{
  "rope_type": "yarn",
  "rope_theta": 10000000,
  "factor": 4.0,
  "original_max_position_embeddings": 262144
}

vLLM から指定する場合は、VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 を付けたうえで --max-model-len と --hf-overrides を併用します。

注意点として、100万トークンはネイティブ性能ではありません。 YaRN による外挿であり、精度と速度のトレードオフを伴います。「1Mコンテキスト対応」という表現だけを見て設計しないでください。

3. SGLang で高スループットを狙う

SGLang にも公式クックブックがあります。ハイブリッドGDN系モデルでは --mamba-full-memory-ratio（既定0.9）がスループットに効くとされており、ここのチューニングが実効性能を左右します。

4. 公式が保証する範囲を把握しておく

Qwen が公式に提供・保証しているのは BF16 と FP8（ブロックサイズ128の細粒度量子化、「元モデルとほぼ同等」と記載）のみです。GGUF・AWQ・NVFP4 などは第三者による変換であり、品質は自己責任になります。

Hugging Face 上には429件もの量子化版が存在しますが、業務利用では出所を絞ってください。 公式リポジトリ（Qwen/Qwen3.8-27B、Qwen/Qwen3.8-27B-FP8）か、Unsloth のように実績のあるアップローダに限定するのが無難です。

料金：ローカル実行とAPI、どちらが安いのか

モデル本体は無料

Apache 2.0 のオープンウェイトなので、モデル自体のライセンス費用はゼロです。かかるのはGPU・電力・運用工数だけです。

API経由で使う場合

OpenRouter の価格は情報源によって $0.40/$3.00 と $0.45/$3.20 で割れており、ルーティング先プロバイダによる変動と考えられます。幅で見ておくのが安全です。

Qwen Cloud でのホスト版（1Mコンテキストを既定とし、公式ビルトインツールを付ける構成）は提供が予告されていますが、時期・価格ともに現時点では未確認です。また Alibaba Cloud Model Studio（百煉）は国際リージョンと中国本土リージョンで価格が異なるという指摘があり、契約前に一次情報での確認が必要です。

損益分岐点をざっくり試算する

「GPUを買うべきか、APIで済ませるか」は次のように考えられます。以下は概算であり、為替1ドル＝150円、コーディング用途で入力：出力＝5：1という前提を置いた目安です。

• API側：入力100万＋出力20万トークンで、およそ $1.0（約150円）
• ローカル側：24〜32GB級GPU搭載機を仮に40万円として3年償却＝月約11,000円、電気代を月2,000〜4,000円と見て、月13,000〜15,000円程度

この月額をAPIに置き換えると、おおむね月間1億トークン規模を消費してようやく釣り合う計算になります。個人利用や小規模チームでは、コストだけを理由にローカルGPUを買う合理性は薄いというのが率直な結論です。

ローカル実行の価値は金額ではありません。

• 社外にデータを一切出せない（医療・金融・法務・自治体など）
• レート制限や従量課金を気にせず、エージェントを長時間回したい
• オフライン環境・閉域網で動かす必要がある
• モデルを固定してバージョン変動の影響を受けたくない
• ファインチューニングして自社仕様の派生モデルを持ちたい

これらが当てはまるなら、コスト比較の結果に関わらずローカル実行を選ぶ理由があります。

弱み・制約：導入前に把握すべき7点

1. 音声の入出力に非対応。 テキスト・画像・動画のみです。
2. 1Mコンテキストはネイティブではない。 ネイティブは262,144トークンで、100万トークンはYaRNによる外挿です。長さに応じて精度が落ちます。
3. Thinking既定ONによるトークン浪費。 簡単な質問でも推論トークンを大量消費します。設定変更を前提に運用設計してください。
4. 動画のフレームサンプリング既定値が保守的。 時間スケールの長い動画は手動でのパラメータ調整が必要です。
5. ニッチな事実知識に弱い。 特に日本語ローカルな話題でハルシネーションの報告があります。RAG等で外部知識を補うのが前提です。
6. 専門ドメインの厳密なフォーマット生成が苦手な場面がある。 検証レポートでは、専門ソフトの入力ファイル生成でキーワード混同や不整合が発生しています。
7. ベンチマークは自己申告で、独立再現が確認できていない。 学習データ・学習トークン数・知識カットオフも非公開です。

セキュリティ：ローカルなら安全、ではない

ローカルLLMの解説記事の多くが「ローカルだからデータが外に出ず安全」で止まっていますが、実際にはそこで終わりません。メリットとリスクを分けて考える必要があります。

得られるもの：データの外部送信をなくせる

Apache 2.0 ＋ 自己ホストの組み合わせにより、機密データを外部APIに送らずに推論できます。医療・金融・法務など、オンプレミス要件がある領域との相性は良好です。

それでも残るリスク

1. 学習由来のバイアス
ホスト型の中国系アシスタントが、政治的に敏感な話題で回答を拒否・回避する傾向は複数報告されています。セルフホストすればサービス側の検閲レイヤは外せますが、学習段階で組み込まれたバイアスまでは除去できません。 世論分析・国際政治・歴史的経緯が絡む業務では、出力の偏りを前提にレビュー工程を置くべきです。

2. prefill攻撃への脆弱性
アシスタント応答の冒頭を強制的に注入してガードレールを回避する「prefill攻撃」について、オープンウェイトモデル全般に系統的な脆弱性があることが学術的に指摘されています（arXiv 2602.14689 ほか）。ウェイトを持てるということは、攻撃側も自由に試行できるということです。なお Qwen3.8-27B 単体の安全性スコア（CASI等）は現時点で確認できていません。

3. エージェント権限の設計
OSWorld 84.3／AndroidWorld 81.9 が示すのは、このモデルがPCやスマートフォンを実際に操作できるということです。ファイル書き込み・ネットワークアクセス・シェル実行の権限を無制限に与えれば、ローカルLLMであっても被害は発生します。サンドボックス化と最小権限の原則は必須です。この観点は AIエージェントのセキュリティ対策 で体系的に整理しています。

4. サプライチェーン
Hugging Face 上には第三者による量子化版が数百件アップロードされており、出所の確認が欠かせません。素性の不明なリポジトリからウェイトを引くのは、素性の不明なバイナリを実行するのと同じリスクを持ちます。

コード生成用途でのリスク全般は AIコーディングのセキュリティリスク も参考にしてください。日本企業での利用にあたっては、経産省・IPAのガイドラインおよび社内のAI利用規程との整合を各自で確認してください。

他のローカルLLMとの棲み分け

27Bクラスのオープンモデルには複数の選択肢があります。用途に応じた使い分けの目安を整理します。

Qwen3.8-27B を選ぶ決め手は3つです。「画像・動画を入力に使う」「エージェントとしてPC/ブラウザ操作をさせる」「Apache 2.0で派生モデルを商用配布したい」。このいずれも当てはまらないなら、他モデルのほうが素直な選択肢になることもあります。

クラウドAPIも含めた開発ツール全体の比較は AIコーディングツールおすすめ比較 で扱っています。

こんな人におすすめ

• 社外にデータを出せない企業の開発・情シス担当者：Apache 2.0＋自己ホストで、機密文書やコードを外部送信せずに処理できる
• 自前GPU（24GB以上）を持つ開発者：4bit量子化で常用可能。トークン課金を気にせずエージェントを回せる
• 画像・図表・スキャン文書を扱う業務：OmniDocBench 91.1（公式発表値）が示すとおり文書解析に強い
• PC操作の自動化を試したい人：OSWorldで84.3。オープンモデルとしてはトップクラスの操作能力
• モデルを自社仕様に育てたい企業：LoRAファインチューニング済みの派生モデルを商用配布できる
• モデルのバージョン固定が必要な業務：クラウド側の予告なきモデル更新の影響を受けない

おすすめしない人

• VRAM 16GB未満の環境しかない人：2〜3bit量子化でも快適とは言い難く、品質低下も避けられない。素直にAPIかクラウドサービスを使うべき
• コスト削減だけが目的の個人・小規模チーム：月間1億トークン規模を使わない限り、API経由のほうが安く収まる
• 最高難度のコーディングタスクを任せたい人：DeepSWE 1.1で42.2（GPT-5.6は72.7）。フロンティアモデルとの差は明確
• 音声入出力が必要な人：非対応。Omni系モデルを検討すること
• 日本語のローカル知識が精度上クリティカルな業務：ハルシネーション報告があり、RAGでの補強か国産LLMとの併用が必要
• 中国系モデルの利用が社内規程で制限されている組織：ウェイトを自社管理していても、規程上の判断は別問題
• サーバ運用の担当者を置けない組織：量子化選定・KVキャッシュ調整・エンジンのバージョン管理は継続的な工数がかかる

よくある質問

Q. Qwen3.8-27B を商用製品に組み込んで販売できますか。
A. Apache 2.0 のため、現時点の公式モデルカードに基づけば可能です。ただし帰属表示とライセンス条文の同梱が必要です。なお同名シリーズの Qwen3.8-2.4T-A95B は別ライセンスなので、組み込むモデル名を必ず特定してください。

Q. RTX 4090（24GB）で「快適に」動きますか。
A. 「4bit量子化で、中程度の文脈長（32K〜64K）なら常用の下限」というのが現実的な回答です。快適かどうかは同時実行数と文脈長次第で、262Kを使うなら24GBでは足りません。まずQ4系GGUFで自分のワークロードを流し、トークン生成速度と残メモリを実測してから判断してください。

Q. なぜ「262K」と「1M」の2つの数字が出てくるのですか。
A. 262,144トークンがネイティブの学習・設計上の上限で、100万トークンはYaRNという外挿手法を設定して拡張した場合の上限です。後者は精度・速度のトレードオフを伴うため、同列に扱えません。

Q. 公式のFP8版と、コミュニティのGGUF版はどちらを使うべきですか。
A. 48GB以上のVRAMがあり、品質を優先するなら公式FP8です。公式が「元モデルとほぼ同等」と記載しており、サポート範囲にも入ります。24GB以下の環境で動かすことが目的ならGGUF一択ですが、第三者変換である点は理解して使ってください。

Q. Thinkingは常にONにしておくべきですか。
A. 逆です。既定の xhigh は難問向けの設定で、日常的な質問に使うとトークンと時間を浪費します。分類・整形・短い応答では low かOFFにし、複雑な設計・デバッグのときだけ深くする運用が実務的です。

Q. 企業で導入する際、最初に確認すべきことは何ですか。
A. 順に3つです。①どのモデル名を使うのか（ライセンスがモデル単位で違うため）、②扱うデータの機密区分とオンプレ要件、③エージェント機能を使う場合の権限設計とサンドボックス。この3点を先に固めてからGPU選定に進むと、手戻りが起きにくくなります。

まとめ

Qwen3.8-27B は、「オープンウェイトのローカルLLMで、マルチモーダルとエージェント操作を実用域に乗せた」という点で節目になるモデルです。Apache 2.0 で商用利用でき、262Kのネイティブ文脈を持ち、量子化すればGPU 1枚で動きます。

一方で、公表ベンチマークは自己申告で独立検証がなく、難度の高いコーディングエージェント系ではフロンティアモデルとの差が残ります。「ウェイトサイズ＝必要VRAM」ではないという点、そして「ローカル＝安全」ではないという点も、導入前に押さえておくべきです。

判断の起点はシンプルです。データを外に出せない事情があるか、GPUに投資できるか。 この2つがYesなら、現時点で27Bクラスの有力な選択肢になります。Noであれば、Qwen3.8-Max のようなホスト型APIや、他のクラウドモデルから検討するほうが早く成果が出ます。