皆さんお待ちかね！？ Qwen3.8-27Bの実力を見てみる。

アリババの超巨大モデル「Qwen3.8-2.4T-A95B」が世界を騒がせてから、ローカルLLM界隈で待望されていたのが、手元のGPUでも動かせる小型版の登場でした。そこに応える形で公開されたのが、今回取り上げる「Qwen3.8-27B」です。

Qwen3.8-27Bのアーキテクチャは、前世代のQwen3.5・3.6からほぼ据え置きです。それなのに、実際に動かしてみると受け答えの質が明らかに変わっている。特に顕著だったのが、Qwenシリーズでおなじみだった「グダグダと自問自答するThinking区間」の様子です。同じ構造のはずなのに、なぜこんなに「考え方」まで変わったのか。

今回は、アーキテクチャ解析と実機検証(通常モード・Vision・Thinking区間の中身)を通じて、その理由を探ってみました。前回検証したMuse Glimmer 30Bとの比較も交えながら見ていきます。

Qwen3.8の登場

Qwen3.8-2.4T-A95Bが与えた強烈なインパクト

Moonshot-AIが提供するKimi-K3が世界中を驚かせてからおよそ1か月弱となる2026年8月12日、中国アリババグループからQwen3.8-2.4T-A95BがHugging Face上に公開されました。2.4Tパラメータという非常に巨大なモデルであり、多くの人が手元で動かすには困難なモデルであるにもかかわらず、ローカルLLMに取り組む人々を多く賑わせました。

推論能力はKimi K3に迫る成績が記録されており、アメリカの主要なフロンティアモデルに迫る能力を突きつけました。

一部のユーザは自前の設備を用いて1bitあるいは2bit量子化モデルを実行し、それがハッタリでも何でもない、本当の実力であることを確認^[1]しており、その声は世界を席巻しました。

Qwen3.8-27Bの実力やいかに？

それから3日後の2026年8月15日 日本時間の午前0時、小規模モデルとしてリリースされたのがQwen3-27Bです。

ここで重要なのはライセンス形態の違いです。巨大モデルであるQwen3.8-2.4T-A95Bは独自ライセンスとしてQwen3.8-Maxライセンスが適用されており、商用利用の場合一定の条件があります。これだけのモデルをサービスとして公開しうるような企業ですと、おそらく商用利用のためのライセンス契約を締結する必要があります。

しかし、このモデルは純粋なApache-2.0ライセンスが適用されており、商用利用するにも無償利用することが可能となっています。また、Qwen3.8-27Bはそのモデル名を見てわかるようにDenseモデルとなっており、知識を余すことなく使うことが出来る高性能型モデルとなっています。

Qwen3.8-2.4T-A95Bは非常に高い性能を世に知らしめましたが、では、その小型版ともいえるこのモデルはどの程度の実力を秘めているのでしょうか？

実際に検証なども行いつつ、このモデルについて深堀してみました。

Qwen3.8-27Bのアーキテクチャ

Qwen3.8のアーキテクチャですが、基本的にQwen3.5及びQwen3.6～アーキテクチャそれ自体は「全く」変わっておりません。構造図を以下に示します。

図1 Qwen3.8-27Bのアーキテクチャ構造

Hugging Face上に公開されている構成ファイルconfig.jsonを参照してみると、踏襲していることがよりはっきりとわかる記述がありました。

{
  "architectures": [
    "Qwen3_5ForConditionalGeneration"
  ],
  "image_token_id": 248056,
  "language_model_only": false,
  "model_type": "qwen3_5",
  "text_config": {

その他、基本的なスペックとしては以下の通りとなります。

• 最大コンテキストサイズ: 256k Tokens(検証環境では64kに制限しています)
• 全体で64ブロック構成 (GDN 3 : GA 1, 4 layers x 16 groups)
• HiddenSize: 5,120
• FFN方式: Dense
  • Activate関数: SiLU
  • Activation次元数: 17,408

アテンション構造は意外とマイノリティなハイブリッド

Qwen3.8のアテンション構造は「Gated Delta Network」と「Gated Attention(実質GQA)」の2種類を使ったハイブリッド構造で、昨今流行りとなっている「局所＋全体統括」の構造とはかなり異なったものになっています。

「Gated Delta Network」は状態更新・情報の圧縮という2つの役割を保持し、これがアテンション層全体に対して75%構成されています。残る25%は「Gated Attention」層と呼ばれ、内部構造はGroup Query Attentionとなっており、こちらは全体統括と精密検索という2つの役割を持っています。

この構成はQwen3-Next-80Bモデルから採用されて、その後Qwen3.5～3.6でも採用されています。

「局所＋全体統括」構造とは大きく異なり、**「圧縮＋統括」**と言えばよいのかなという構造になっており、こうした方式を採用しているのは今のところ主要モデルではQwenぐらいじゃないのかなと思います。

Vision Encoderも従来と同様のSigLIP2ベース

Qwen3.8のVision Encoderは従来同様にSigLIP2ベースのアーキテクチャ(SigLIP2-SO-400M)を踏襲しています。追加学習はもちろん行われていると予想されますが、仕組み上の大きな変更は発生していません。

先に紹介したMuse Glimmerとはこの点について取り組み方が大きく異なります。

検証して動かしてみよう！

今回、GPUSOROBAN「高速コンピューティング」のNVIDIA RTX A4000が搭載されたインスタンスを用いて検証しました。

全体構成

構成としては以下の通りになります。アクセスサーバとSSHトンネルを張り、そこを通りながら接続先インスタンスへアクセスします。^[2] llama.cppのサービスポートは、互いの8001番ポートを介してローカルホストと中継することにします。

図2 接続構成の概要

使用するインスタンス

今回、使用するのはこちらのNVIDIA RTX A4000というGPUです。インスタンスのスペック含めて以下の通り示します。

項目	スペック情報
使用インスタンス種別	s16-1-a-standard-ubs24-v
GPU	NVIDIA RTX A4000
GPUメモリ	GDDR6 16GiB
GPUメモリ帯域幅	448.0 GB/s
演算性能FP32	19.17 TFLOPS
演算性能BF16	38.34 TFLOPS
演算性能INT8	153.4 TOPS
演算性能INT4	306.7 TOPS
vCPU	11 Core
システムメモリ	50 GiB
ストレージ	Persistent 100 GiB
CUDAバージョン	13.2
NVIDIA Driver Ver.	580
OS	Ubuntu 24.04 Server

表1 使用するインスタンスのスペック情報

使用するモデルファイル

Qwen3.8-27Bは4bit量子化を施したモデルでも16GiBを超えてしまいます。KVキャッシュの使用量等も考慮し、今回はUnsloth Dynamic 2.0で最適化されているモデルの2bit量子化モデルを採用しています。

UnslothからリリースされているQwen3.8-27B-GGUFのリポジトリサイトから、以下のファイル名のファイルをダウンロードしました。

ファイル名	容量	ファイル概要
Qwen3.8-27B-UD-Q2_K_XL.gguf	12 GB	UD2.0/2bit量子化モデル
mmproj-bf16.gguf	889 MB	量子化されたVisionエンコーダ

表2 llama.cppに適用するファイル一覧

llama.cppについては、「version: 0.1.0-dev (build 10450, commit ece963f41)」を使用しています。

Qwen3.5からアーキテクチャ更新は行われていないため、既存ビルド版のllama.cppでも気軽に動かせるのは一種のアドバンテージがあるともいえるかもしれません。

動作検証：通常モード

ではまず、モデル本体のみを使ってテキスト推論を実行させてみます。

llama.cppによる起動コマンド

以下のコマンドにてWebフロントエンドを呼び出し、検証を行っています。

今回、KVキャッシュは8bit化せずにFP16モードで実行させていますが、メモリ容量制約のために、最大コンテキストサイズを65,536に下げています。また、メモリ使用状況をチェックするため、logレベルをデフォルトの3から4に引き上げています。

build/bin/llama-server --model ./models/Qwen3.8-27B-UD-Q2_K_XL.gguf -t 12 -np 1 --prio 2 --temp 0.6 --top-p 0.95 --top-k 20 --port 8001 --host 0.0.0.0 --fit off --no-warmup --no-cache-prompt -fa on --cache-ram 0 -c 65536 --reasoning on --reasoning-effort xhigh --log-verbosity 4

reasoningのレベル設定が可能に

ここ最近、llama.cppのパワーアップポイントなのかなとも感じたところが、「reasoning_effort」というパラメータを設定できるようになったことです。

--reasoning-effort LEVEL   reasoning effort level given to the chat template:
                           'default' to keep the template default, or a level
                           such as 'minimal', 'low', 'medium', 'high', 'xhigh'
                           or 'max' (default: default)
                           (env: LLAMA_ARG_REASONING_EFFORT)

表3 reasoning_effort設定オプションに関する記述(llama-serverオプション設定から引用)

実際にどのレベルが使えるかはQwen3.8-27B自体が持つchat_template.jinjaに左右されるため、これを確認したところ、以下のレベルが使用可能なようです。

• xhigh(デフォルト設定)
• medium
• low

これらを設定することで、システムプロンプトに以下の文章が注入されるようです。

レベル	注入文
xhigh	Reasoning effort is set to xhigh. Please think carefully through the task, validate key assumptions, consider plausible alternatives, and prioritize correctness, consistency, and clarity in the final answer.（日本語訳：推論の難易度は「高」に設定されています。この課題について慎重に考察し、重要な前提条件を検証し、現実的な代替案を検討した上で、最終的な回答においては正確性・一貫性・明瞭性を最優先に考慮してください。）
medium	＜システムプロンプト注入なし＞
low	Reasoning effort is set to low. Keep your thinking brief and focused, moving directly to the conclusion without unnecessary elaboration.（日本語訳：推論の労力レベルは「低」に設定されています。思考は簡潔かつ焦点を絞り、不必要な詳細説明を避け、直接的に結論へと導いてください。）

表4 reasoning_effortレベルと注入されるプロンプト文

つまりは、明確なTokens budgetは指定されないながらも、システムプロンプトへの文の追加をすることにより、その推論レベルのコントロールを行っているようです。

メモリ消費量：KVキャッシュ容量の大きさが課題

メモリ消費量は以下の通りとなりました。Qwenシリーズ全般に言えることなのですが、KVキャッシュ容量がやっぱり大きいです。当初131,072を最大コンテキスト数として設定しようとしたのですが、それだとOOMエラーが出たためにこれを半減させて起動させています。すると65,536を上限に設定した状態でKVキャッシュ容量は4,096 MiBとなりました。

表5 通常モード（メインモデルのみ）におけるメモリ消費量

つまり、f16モードで131,072トークンを最大に設定した場合、その要求メモリ量は8,192 MiBということになります。さらに、モデルとしての最大コンテキストサイズ262,144に設定した場合の要求メモリ量は16,384 MBとなります。

この原因は他モデルと比較してもGlobal層(GQA)が多く、それぞれのHead数・次元数も多めに構成されていることにあります。

モデル	Muse Glimmer 30B	Gemma-4-31B	Qwen3.8-27B
層構造	SWA+Global(3:1)	SWA+Global(5:1)	GDN+Global(3:1)
全体レイヤー数	52	60	64
統括層の数	13	10	16
統括層のKV設計	2 heads x 128 dim	4 heads x 512 dim	4 heads x 256 dim
KVキャッシュ容量(128k, f16)	1,742.00 MiB	5,920.00 MiB	8,192.00 MiB
設計のポイント	軽量な推論能力を狙い、極限までメモリ削減を狙った構成	高度な推論とメモリ削減の両方をとった構成	高度な推論に狙いを定めた構成

表6 ハイブリッドモデルの各統括層の構成・KV設計

Gated Delta Networkは「局所・全体統括」方式と比べると非常に効率的なアーキテクチャで、情報圧縮を担うGated Delta Networkには消費されるKV容量がゼロで済むという特性があります。実際、全く同一条件でニューラルネットワークを構成した場合、その要求キャッシュ容量は必ず「局所・全体統括」方式のほうが上回ってきます。

しかし、Global層の登場頻度が非常に高い上、他のモデルと比べてもレイヤー数が多く、統括層のKV設計がかなりリッチな構成になっているため、結果的にQwen3.8-27BのKVキャッシュサイズが大きくなってしまっていることが分かりました。

これは、Qwen3.8-27Bが軽量推論を行うことを目指したのではなく、あくまで深い推論能力をもって確実な回答を出力することを念頭に置いて設計していることを如実に表しているといえるでしょう。

出力された内容

以下の質問を投げてみて、その応答内容を吟味してみます。

最近熊本地震が発生したこともあり、気になってこういう質問をいろんなモデルにして回ったりしています。

九州の地盤に関してその特徴を述べてください。

応答内容は以下の通りとなりました。ぱっと見の印象は「お、詳しいかも？」でした。

九州の地盤は、地質・地形・水文が複雑で、場所によって地盤の強さや性質が
大きく変わる点が最大の特徴です。建設地盤としての特徴をまとめると、次の
ようになります。

1. 地質・地盤の多様性
九州は火山島弧上に位置し、火山地盤、堆積地盤、花崗岩地盤、風化土、河川
堆積物などが短距離で混在します。
- 北九州（福岡・佐賀・長崎など）：堆積盆地、花崗岩、一部では蛇紋岩類な
  どの基盤岩が見られる。
- 中部（熊本など）：阿蘇カルデラ、火山灰・軽石・溶岩、河川堆積物など
  が発達。
- 南九州（大分・宮崎・鹿児島など）：火山地盤、花崗岩、堆積平野が混在。
このため、同じ九州内でも地盤条件が大きく異なります。

2. 平野部は軟弱な最近堆積物が多い
福岡、佐賀、長崎、熊本、大分、宮崎、鹿児島などの平野や河川氾濫平野で
は、最近堆積物、すなわち砂、シルト、粘土などが厚く堆積している場所が
多くあります。主な特徴は次のとおりです：含水比が高い／せん断強度が低
い／圧縮性・沈下しやすさがある／地震時に液状化しやすい／不同沈下や地
盤沈下が生じやすい。特に河川沿いや沿岸平野では、軟弱地盤への対応が必
要です。

3. 火山地盤が広く分布する
九州は火山が多数あり、軽石、火山灰、溶岩、火成岩などが地盤を形成して
います。軽石・火山灰は強度が低い場合が多く、透水が高く、圧縮性が高
く、湿潤・飽和状態では液状化しうるほか、沈下や土圧変動が生じやすい特
徴があります。阿蘇、桜島、霧島、九重、雲仙、指宿などでは、こうした火
山由来の地盤が重要になります。一方、溶岩・火成岩は強度が高く基礎の支
持層として良好な場合がありますが、風化、割れ、空洞、侵食による不均一
性があり、表層は軟弱で深部が強い場合があります。火山地盤は「強い岩
盤」と「軟弱な火山堆積物」が近接しているため、地盤調査が特に重要です。

4. 山地・斜面では地すべり・崩壊リスクが高い
九州は山地が急峻で、風化岩、残土、火山土、河川堆積物が斜面を構成して
います。斜面の傾斜が急で、降雨・台風・地震で地すべりや崩壊が発生しや
すく、風化度によって地盤強度が大きく変わります。特に豪雨や地震時に
は、地すべりや土砂災害のリスクが高まります。

5. 活断層・地震による地盤への影響が大きい
九州はプレート境界付近や活断層帯に位置する地域があり、地震動が比較的
大きい可能性があります。地震時には液状化、地すべり、斜面崩壊、地盤の
沈下・不同沈下、構造物の基礎への影響が考えられます。したがって、耐震
設計だけでなく、地盤の地震応答まで考慮する必要があります。

6. 地下水や水理条件も複雑
九州の地盤は、平野部では浅い地下水、火山岩や花崗岩では裂隙水、沿海部
では塩水混入などが考えられます。建設時には、湧水／地下水位の上昇／軟
弱地盤の強度低下／地盤改良時の排水・止水などを考慮する必要があります。

7. 建設上の注意点
九州の地盤では、場所により地盤条件が大きく異なるため、一般的な地盤評
価に頼らず、敷地ごとの地盤調査が不可欠です。軟弱地盤では杭基礎や地盤
改良、溶岩・岩盤では支持層の確認、火山地盤では液状化・沈下対策、斜面
では地すべり防止・アンカリング、地震・豪雨を想定した地盤評価、地すべ
り・液状化・不同沈下の総合的な検討が必要です。

まとめ
九州の地盤は、軟弱な最近堆積物、火山由来の低強度土、強い溶岩・岩盤、
活断層・地震・地すべりなどが複合している点が特徴です。したがって、九
州では「地盤が強い／弱い」を一概に判断できず、敷地の地質、地形、水
文、地震・降雨リスクを個別に確認することが重要です。

GPT-5.6-Lunaを使ったDeepSearchエージェント(Powered by Dify)で評価をさせた結果は以下の通りとなりました。（内容から、あまりに長文の箇所は削除しています）

今回、Muse Glimmer 30Bでも同様の質問・評価を行っていますが、指摘内容のレベルがちょっと上に上がっていました。つまり、Muse Glimmer 30Bのそれとはどうやら次元が違うようです。

全体の妥当性は問題ないとGPT-5.6-Lunaは判断しており、その上で説明資料として修正すべきところ、読みやすさの向上を図るための指摘など、「内容そのものの妥当性よりも、そのうえでさらに完成度を上げるための指摘」に踏み込んでおり、確実に「一段階上のレベルで文章を読んでいる」ことが分かりました。

このケースにおいてははっきりと「Muse Glimmerを凌駕している」と言えるでしょう。

総合評価
この文章は、九州の地盤が地域によって大きく異なることを説明する一般向
けの概説としては、全体の方向性が妥当です。火山地盤、平野部の沖積層、
山地斜面、地震、地下水を一通り扱っており、構成も追いやすくなっていま
す。一方で、建設実務や専門教育に使うには、いくつかの用語と断定表現を
修正する必要があります。

目安として評価すると、正確性：6.5点／10点、読みやすさ：8点／10点、建
設実務向けの適合性：6点／10点です。表面的に大きく誤っているというよ
り、条件によって変わる性質を一律に述べていることと、地質材料、地盤特
性、災害リスクを同じ分類に並べていることが主な問題です。

修正が必要な点として、「最大の特徴」は断定が強い、平野部の性質を一律
に述べている、地震の説明は地盤特性と災害ハザードを分ける、地下水の説
明は補足が必要、「地盤が強い、弱い」を分解する、地盤材料と災害を分け
る、重複を減らす、といった点が挙げられます。

最終評価として、この文章は九州の地盤を初めて説明する一般向け資料とし
ては使いやすい構成です。ただし「最近堆積物」「残土」「南九州に大分を
含める地域区分」「火山灰は透水性が高い」「湿潤なら液状化しうる」と
いった部分は、修正または条件付けが必要です。修正後は、一般向け解説と
して十分利用できます。建設計画や基礎形式の選定に使う場合は、この文章
を判断根拠にせず、地質図、土地条件図、液状化ハザードマップ、活断層情
報、ボーリング調査、標準貫入試験、地下水位調査などを組み合わせる必要
があります。

パフォーマンス

これもMuse Glimmer 30Bと比較をしてみました。速度に関してはほぼ変化がないことがはっきりと出ましたが、それ以上に「結果を出すためのトークン使用量が3倍近く多い」ということ、そのために3倍近い時間を要しているということがはっきりと出ました。

【Qwen3.8-27Bの場合】
prompt eval time = 303.63 ms / 64 tokens ( 4.74 ms per token, 210.78 tokens per second)
       eval time = 248375.97 ms / 5771 tokens (43.05 ms per token, 23.23 tokens per second)
      total time = 248679.60 ms / 5835 tokens

【Muse Glimmerの場合】
prompt eval time = 262.18 ms / 68 tokens ( 3.86 ms per token, 259.37 tokens per second)
       eval time = 82874.28 ms / 1866 tokens (44.41 ms per token, 22.52 tokens per second)
      total time = 83136.46 ms / 1934 tokens

今回どちらもReasoning EffortはHighに設定して検証していますが、Qwenシリーズ全般に言える傾向「回答を出すまでにすごく時間がかかる」というのは全く変わってないようにも見えました。

動作検証：Visionを使用する場合

Qwen3.8は元々前のバージョンからマルチモーダルモデルとしてリリースされてきた過去があり、このモデルも当然の如くVisionエンコーダーを有しています。以下のようにllama.cppの場合はVision Encoderモデルを適用することにより画像を読み込ませることが可能になります。

ちょうどこの辺りでぎりぎり動作・・という感じになりそうです。コンテキスト長を稼ぎたい場合はKVキャッシュを量子化する必要が出てきます。

コマンドライン

build/bin/llama-server --model ./models/Qwen3.8-27B-UD-Q2_K_XL.gguf -t 12 -np 1 --prio 2 --temp 0.6 --top-p 0.95 --top-k 20 --port 8001 --host 0.0.0.0 --fit off --no-warmup --no-cache-prompt -fa on --cache-ram 0 -c 65535 --reasoning on --reasoning_effort xhigh --log-verbosity 4 --mmproj models/mmproj-BF16.gguf

メモリ消費量

メモリ消費量は以下の通りで、およそ1,336 MiB程度のメモリ上昇を確認しました。

表7 Visionエンコーダ有効化時のメモリ消費量

質問と出力の内容

通常モードの推論とは異なり、画像を添付してそれに対する質問をすることで分析能力を測ってみることにしました。

そこで、以下の画面を分析させました。前回調査対象にしたMuse Glimmerのモデル構造図を今回もそのまま添付^[3]し、「詳細分析し、何が書かれているかについてその詳細を述べよ」としています。

図4 Vision Encoderに読み込ませた画像

結果は以下の通りとなりました。赤文字箇所は解釈を誤っている箇所です。

MUSE GLIMMER 30B 構造スライド 詳細分析

1. 画像の全体構成
スライドは「参考:MUSE GLIMMER 30Bの構造」というタイトル（濃紺背景
バー）の下、3層からなる。上部テキスト（左＝モデル基本仕様、右＝アテ
ンション機構(SA/FA)の定義）、中央吹き出し（ブロック構成の補足説明）、
下部フロー図（入力→埋め込み→Transformerブロック群→出力）で構成され
ている。目的は、29.6B規模のDense型マルチモーダルLLMのアーキテクチャ
と、その中核であるSA/FAハイブリッドアテンションの設計思想を視覚化す
ること。

2〜5. パラメータ・アテンション機構・フロー図・吹き出しの解析
（Dense 29.6B、Hidden Size 6,656、SwiGLU、RoPE θ=50,000でFAには不適
用、Max Context 128k、DFlashベースのDrafter、SA/FAそれぞれの役割分担
などを、図の記載どおりに詳細に整理）

6. 整合性・注意点（分析上の指摘）
ブロック数の不一致：図ラベルは「52ブロック構成」、吹き出しは「50ブ
ロック」。52=4×13はgroupsとしての整合、50=12×4+2はテキスト側の整合。
この2はGlimmer Visionの2層分を別カウントしている可能性が高く、図(52)
＝Vision含む実体層数、吹き出し(50)＝テキスト側ブロック数のみ、と解釈
するのが自然。スライド内での定義の統一が望ましい点。誤植の可能性：FA
の説明「位置のな情報」は「位置の情報」の誤記と推定。

7. まとめ
本スライドは、MUSE GLIMMER 30Bが Dense 29.6B / 128kコンテキストを前
提に、SA(局所・低コスト)とFA(全体・高品質)を3:1で繰り返し配置し、位
置エンコーディングはSAに集中させFAからは除去する、計算効率と推論性能
を両立させたハイブリッドアテンション設計であることを説明している。加
えてVision入力の融合、GQA+Sigmoid Gate、DFlash/MTPによる推論対応が主
要な設計要素であり、図とテキストのブロック数(50/52)の定義差が唯一の
整合性上の注意点である。

なんと、前回同じタスクを投げたMuse Glimmer 30Bより倍の量のレポートが返ってきました。そのうえ、まとめの内容もほぼ完璧ですし、あまつさえ私の図の書き込み内容に対するツッコミまで最後についてきました（苦笑）。

Vision EncoderはSigLIP2を踏襲していますが、追加学習の結果が何かしら反映された可能性はありますし、その情報を得たうえでの解の導き方が非常にうまくなった印象を受けました。

Thinking区間の文章を覗き見てみる

Qwenと言えば、何故かThink区間で「ものすごいネガティブ人格」が形成されており、いざリリースするときになって「さあだそう！・・いや、待ってくれ、もうちょっと確認したい、一からやり直したい」と言い出して冗長に思考する癖があまりにも有名です。今回もそうなっているのでしょうか？試しに確認してみました。

実際に出力されているThink区間の内容(九州の地盤についての質問に対するもの)は本記事末尾の付録に要約を掲載しますが、ここでは出力させた結果をGoogle Gemini 3.7 Flashに評価させた要点を先に紹介します。

Geminiの分析によれば、Qwen3.8-27Bの思考パターンは大きく5つの特徴を持っていました。まず「思考言語(英語)と出力言語(日本語)の分離」で、内部推論は英語、最終出力は日本語という多言語処理特有の挙動が見られます。次に「多角的な文脈の想定と意図の補完」として、質問の裏にある用途（建設実務なのか試験対策なのか等）を先回りして検討する様子が確認できました。3点目は「知識の網羅的ブレインストーミングと分類化」で、関連キーワードを網羅的に洗い出したうえで地域別・地質別に体系化していきます。4点目が「リアルタイムの自己修正とファクトチェック」で、「宮城」と書きかけて即座に「宮崎」に訂正したり、蛇紋岩の分布範囲について過度な一般化を避けたりと、細かい事実確認を執拗に繰り返します。最後に「出力構成・フォーマットの反復シミュレーション」として、表形式か箇条書きか、見出しの順序をどうするかまで、何度も構成案を試作していました。

ここで重要なのは、Qwen3.5までは多かった「明らかにネガティブな感情の露呈」が起きておらず、評価結果も「きわめて論理的に」進めていると記述されている点です。アーキテクチャに対する変更は一切発生してないため、今回のレベルアップはどうやら学習法にあるようです。

このモデルにはどのような手が加えられたのでしょうか。糸口は以下のサイトにありそうです。

Qwen3.8-Max: A New Bar for Coding and Cowork
(https://qwen.ai/blog?id=qwen3.8)

この記事は最上位モデルであるQwen3.8-2.4T-A95Bモデルに関する記述ではありますが、それを小型化したモデルであることを考えると、同様の学習処理を受けているものと考えられます。Workの項では、実世界RLシステムの大規模化(タスク・作業スペース・ツールチェーンを独立した軸で継続的にスケールアップ)、多様な検証を内部化できる汎用報酬システム、オンラインデータバランサーの3つを組み合わせることで、複数の主要ツールチェーンにわたる業務遂行能力を均一に向上させたと説明されています。

元々、Qwen3より適用されている独特のネガティブ人格のようなものは、Qwen発祥ではなく、DeepSeek-AIが生み出した**「Long CoT Cold Start」**^[4]という学習法によるもので、これは非常に多くのターンを繰り返すケースにおける推論能力を引き上げるためにDeepSeek-R1に適用された学習法です。Cold Startというキーワードは、途中立ち止まって一から考え直す特性に基づいているといわれています。

この中で、それまで用いられていたQAのようなデータセットばかりではなく、Redditに代表されるプログラミング掲示板などに含まれるデータを適用することで、試行錯誤をする過程を学習させているのですが、この中のデータには多くの「人間の感情表現が含まれて」おり、それがネガティブ人格につながっているといわれています。この特性はQwenのみならず、元祖であるDeepSeekやその他中国系のLLMに対して多く見られます。

Qwen3.8では、各種学習工程の見直しをどうやら行っているようで、それに関連する論文として、「Unified Data Selection for LLM Reasoning」^[5]という論文が見つかりましたので、この内容を確認してみました。

すると、この論文では、**High-Entropy Sum(HES)**と呼ばれる学習不要かつ極めて軽量な新しいデータ評価指標を提案しており、SFT(教師あり学習)・RFT(棄却サンプリング微調整)・RL(強化学習)の各工程に適用し、その効果を測定したようであることがわかりました。

通常の学習法(平均エントロピーの利用)では重要な思考の分岐点が、大量の低エントロピートークン(定型的な文章・単純計算ロジック)で薄められてしまい、解法の良しあしを区別できないまま学習していくのに対して、HESを用いることにより、最適化したモデルは良質な解法を非常に高効率で学習でき、その高い学習効果が確認できたとのことです。

元々Qwen3.8-Max規模のモデルを相手にした学習には、相当に推論ステップを含む大量の回答データが与えられているはずで、そこにこのHESの概念を適用したことで、より効果的な解法、その傾向からより論理的な道筋が採択されやすくなり、感情ノイズを抑制した結果、より高度な推論能力が身についたのではないかと私は推察しています。

また、ほかにも**「Revisiting Overthinking in Long Chain-of-Thought from the Perspective of Self-Doubt」**^[6]という論文でも挙げられるようにLong CoT方式での学習に課題があることは既に指摘されており、こうしたところへの対策も何かしら施されたのではないかと考えられます。

「中国モデルはフロンティアモデルから能力をかすめ取っただけだ！」という人も未だいるかもしれませんが、少なくともこうしたところはQwen3.8-27Bにおいては少し内容が違うのかなと感じており、少なくとも蒸留だけが能力を引き上げる理由にはなってないように見受けられます。少なくともQwenチームは様々な技術に貪欲で、目を光らせ積極的に取り込みを続けてるように見えます。そのハングリー精神がこのモデルを成立させているのではないでしょうか。

また、この学習法の転換により解の求め方として、そのプロセスのたどり方が従来と比較してかなり変化がおきたのではないかとも考えられ、特にハーネスエンジニアリングを行っている場合において、従来の指揮の仕方ではうまくいかない個所などが出てくる可能性は考えられます。従来方式でうまくいかなかった場合に、そうした部分への見直しが今後もしかしたら発生するのかもしれません。

このように、AIモデルがアップデートされていくにつれて、その処理形態・処理方式が変わっていくことに対して、我々もアップデートを求められているのかもしれません。

調査：世間が見る性能値として

アリババQwenチームが公開しているベンチマーク比較内容について、以下の通り転記しました。なんと、Anthropic Claude Opus 4.6のMax Reasoningモードに勝るとも劣らぬ成績をとっています。ただ、これまでの検証内容を拝見する限りでは、その内容は決して嘘ではないのだろうと思われます。

分野	ベンチマーク	Qwen3.8-27B	Qwen3.6-27B	Qwen3.7-Plus	Muse Glimmer-30B	Opus4.6 Max
Coding	Agentic terminal coding (Terminal Bench 2.1)	73	63.4	64	51.7	78.2
Coding	Agentic coding (SWE-bench Pro)	61.7	53.5	57.6	51.2	53.4
Coding	Repo-level code generation (NL2Repo-Bench)	42.3	36.2	41.1	--	47.6
Coding	Agentic coding (DeepSWE 1.1)	42.2	13.3	14.2	--	--
Coding	Software engineering (QwenSWEBench)	79	49.3	59.2	--	63.8
Agent	Long-horizon office work (CoWorkBench)	70.7	61	65.1	--	68.2
Agent	Professional job tasks (JobBench)	33.4	21.8	27.6	--	--
Agent	Frontier agentic tasks Pass@1 (Agents' Last Exam)	20.4	10.6	13.2	--	--
Agent	Frontier agentic tasks Score (Agents' Last Exam)	42.9	27.3	33.6	--	--
General	Instruction following (IFBench)	79.5	69.1	79.1	77	62.5
General	Scientific reasoning (GPQA Diamond)	89.2	87.8	90.3	83.5	91.3
General	Multidisciplinary reasoning (HLE)	30.8	24	34.7	22	40
General	Competitive coding (LiveCodeBench v6)	90.3	83.9	89.6	--	88.8

では、第三者評価の場合においてはどうでしょうか。こちらはArtificial AnalysisのIntelligence Indexのグラフです。


図5 Artificial AnalysisにおけるIntelligenceグラフ

Thinking On状態で衝撃のスコア52を記録し、なんとClaude Opus 4.6のスコアを上回るどころかOpenAIでおそらく現在最も利用者が多いであろうGPT-5.6 Lunaに肩を並べました。ここまでスコアを上昇させてきたというのは私にとっても予想外でした。

ただし、その動きはDeepResearchには非常に有効ですが、雑談などが混じっているような汎用性という意味では、出力に時間がかかりそうなモデルともいえますし、いろいろ新たな試みを投入したことで、様々なミドルウェアやInstructionの再調整などが発生するのは明らかです。

そういう意味では、先に紹介しておりますMetaのMuse Glimmer 30Bやもっと以前から登場しているGoogle DeepMindのGemma-4-31B-itも決して意味がないとは言えません。回答を得るまでに必要な時間はThinking区間がQwen3.8と比べると圧倒的に短く、その分回答が速く出せるようになります。

特にMuse Glimmer 30BやGemma-4ではSliding Windowによるメモリ節約効果が非常に高く、比較的容易にコンテキスト長を拡張しやすいモデルともいえます。Muse Glimmer 30BのVision Encoderもその分解性能の高さは魅力的であるといえ、そうした観点から長所をどこに我々は使っていくかというところで、1つのモデルを盲目的に使うのではなく、その使い分け技術、適用技術が求められていくのではないかなと感じました。

まとめ

今回は、ローカルLLM界隈で待望されていたQwen3.8のコンパクトモデル「Qwen3.8-27B」を紹介しました。その実力は決して伊達ではなく、こちらの想像を上回るパフォーマンスを見せてくれています。特に、Artificial Analysisで公開されたそのベンチマーク結果は、多くの人に相当の衝撃をもたらしたのではないでしょうか。^[7]

最適な用途として真っ先に思いつくのは「Deep Research」です。検索エンジンと連携することで深い内容まで難なく探索でき、無駄な推論ループにも陥りにくい強靭さは、検索拡張として活用する上で非常に心強い武器となります。

アーキテクチャ面では、Qwen3.5の「Gated Delta Network」を核としたハイブリッド構成を踏襲しており、推論エンジンをアップデートすることなくそのまま動かせる点が大きな魅力となっています。

しかし、性能面に大きく舵を切った路線であることから、そのKVキャッシュ容量が大きくなりがちな点は一種の弱点とも言えるでしょう。最大コンテキスト長を非常に長く保つには、それなりのGPUが必要になってきます。そのメモリハンドリングはローカルLLMの人たちにとっては悩みの種になってくると思われます。

一方、学習面では従来のLong CoT Cold Startから手法が転換されたことで、一部のユーザーに戸惑いが生じているのも事実です。この仕様変更にどう適応し、どのような指示（プロンプト）の改修が必要になるかを見極めることが今後の鍵になるでしょう。

こうした新しいアプローチは、arXiv等で知見が共有されるにつれ、他のモデルにも徐々に浸透していくと考えられます。こうした取り組みは商用フロンティアモデル・オープンウェイトモデル共々その性能を大きく引き上げるトリガーとして作用するかもしれません。

新技術の進化は、アーキテクチャやトークナイザーの仕様だけでなく、普段は隠蔽されがちな「Thinking区間（思考プロセス）」の中にも現れます。ぜひ普段はあまり目を向けない領域にも注目し、モデルの挙動の変化を観察してみてはいかがでしょうか。

参考文献

Qwen/Qwen3.8-27B -- Hugging Face
https://huggingface.co/Qwen/Qwen3.8-27B

unsloth/Qwen3.8-27B-GGUF - Hugging Face
https://huggingface.co/unsloth/Qwen3.8-27B-GGUF

OpenLM-AI Qwen3.8
https://openlm.ai/qwen3.8/

Qwen3.8-Max: A New Bar for Coding and Cowork
https://qwen.ai/blog?id=qwen3.8

DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning
https://arxiv.org/pdf/2501.12948

Unified Data Selection for LLM Reasoning
https://arxiv.org/pdf/2605.22389

Revisiting Overthinking in Long Chain-of-Thought from the Perspective of Self-Doubt
https://arxiv.org/pdf/2505.23480

付録

想定されるKVキャッシュ容量

Qwen3.8-27Bは、KVキャッシュ容量が以下のように要求されます。長文コンテキストをサポートするには、VRAM上に以下の容量をウェイトデータやVideo Encoderデータ以外に要求されますので注意してください。

Max Context Size	K:f16, V:f16	K:q8_0, V:q8_0	K:q8_0, V:turbo3[8]
65,536	4,096 MB	2,048 MB	1,488 MB
131,072	8,192 MB	4,096 MB	2,976 MB
262,144	16,384 MB	8,192 MB	5,952 MB

表8 想定されるKVキャッシュ容量一覧

九州の地盤について説明したときのThinking内容（抜粋）

本文で紹介した質問「九州の地盤に関してその特徴を述べてください」に対する、実際のThinking区間の内容(英語で出力されたものを日本語訳したもの)から、口調がわかる箇所をいくつか抜粋します。全文は非常に長大なため割愛しますが、実際の言い回しを見た方がその落ち着きぶりが伝わると思います。

地名を書きかけて、その場で静かに訂正する場面:

福岡・佐賀・長崎平野は最近の堆積物、熊本・大分・宮城？ただし宮城は九州地域に含まれません。宮崎は堆積物と火山岩質地盤が分布。

事実関係をその都度確認する場面:

「蛇紋岩」は九州西部に存在するのでしょうか？海洋性地殻の一部である蛇紋岩化岩は存在します。沿岸部の一部地域では「蛇紋岩類」を基盤岩として記載することも可能です。

表現が強すぎないか自分で戒める場面:

過剰な表現にならないよう注意が必要です。「軽石は液状化する可能性がある」という記述は適切です。「火山灰は透水性が高い」という点については、一般的には正しいものの、その程度にはばらつきがあります。

回答のボリュームそのものを気にする場面:

ただし、情報量が多すぎる可能性もあります。箇条書き形式で簡潔にまとめるのも一案です。最終的な回答は長すぎないようにしましょう。

草案を何度も作り直しながらも、最後まで「いや、待ってくれ、一からやり直したい」といった取り乱した表現は一度も出てきませんでした。淡々と自問自答と事実確認を積み重ねながら、着実に完成度を上げていく、というのが実際の中身です。

ただし、この試行錯誤自体の「量」は決して少なくありません。地名や地質用語の確認、表現のトーン調整、構成案の試作を何度も繰り返しており、そこにかかっている時間・トークン量は相応に大きいというのが実態です。「取り乱していない」ことと「思考が短い」ことは別の話で、Qwenシリーズが指摘され続けている「考えすぎ(overthinking)」自体は、このモデルでも変わらず残っていると見るべきでしょう。

脚注

1. 中には、単純にハードウェアに載らない前提でメモリ削減の仕組みを実装し、独自で推論エンジンを構築して動作検証をなさったとんでもない方もいらっしゃいました。2bit量子化モードでは、想像を絶する好成績を記録したようです。

2. こちらの詳細については、拙著「GPUSOROBANを使う(https://www.bluecore.net/archives/242)」を参照してください。

3. この画像は、先のページで表示させていたモデル図より前の版を使用しました。

4. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning(https://arxiv.org/pdf/2501.12948)

5. https://arxiv.org/pdf/2605.22389

6. https://arxiv.org/pdf/2505.23480

7. おそらく、ベンチマークを担当された方々も、その結果に一度目をこすって「もしかしたら何か間違えたかな？」と再検証を実施したのではないでしょうか（そのぐらい今回Qwen3.8-27Bの結果が出るまで思った以上に時間がかかってました）

8. TurboQuant技術に対応したllama.cppフォークを使用して計測。turbo3はTurboQuant 3bit量子化がなされていることを示す。2GPU構成で検証したため、オーバーヘッドが存在していることに注意。