- 「Qwen3.8-4B」はQwen公式の配布物ではなく、Qwen3.5-4Bを土台にした第三者の蒸留モデルである。配布元自身がベースと教師を明記している。
- 同じ機材で並べて測ると、生成速度もプロンプト処理も必要VRAMもベースとほぼ同じだった。名前の世代が上がっても、1トークンを吐くコストは今回の条件では変わらなかった。1問あたりの所要時間が変わるのは、次に挙げる生成量の差のほうである。
- 実測ではっきり差が出たのは、短い問いに答えるまでに使う思考トークンの量。蒸留版は中央値で約10分の1から30分の1のトークンで答えの行に到達した。長い推論を要する課題で同じ差が出るかは測っていない。
「Qwen3.8-4B」という名前が指しているもの
「Qwen3.8-4B」という名前で配布されているモデルの土台は、Qwen3.5-4Bである。そこにQwen3.8の出力を蒸留したもので、Qwen公式が出した3.8世代の4Bではない。配布しているのもQwenではない第三者で、位置づけとしては第三者配布のモデルになる。では土台をそのまま使う場合と何が違うのか。同条件で並べて測ると、生成速度も必要VRAMもほとんど変わらず、差がついたのは1点、短い問いに答えるまでに費やす思考トークンの量だった。
2026年8月22日時点で、Hugging FaceのQwen公式アカウントに置かれているQwen3.8系のリポジトリは Qwen3.8-27B、Qwen3.8-27B-FP8、Qwen3.8-2.4T-A95B、Qwen3.8-2.4T-A95B-FP8 の4つで、4Bサイズは含まれていない。これは公式アカウントで確認した範囲の話であり、他の配布経路や今後の追加公開を否定するものではない。公式の3.8世代のうち、個人の1枚ざしで扱う候補になるのは27Bのほうになる(Qwen3.8-27BをVRAM 16GBで実測)。
今回測ったのは empero-ai/Qwen3.8-4B-Distill とそのGGUF版である。配布元の説明では、Qwen/Qwen3.5-4B のアーキテクチャに Qwen3.8 2.4T A95B を蒸留した全パラメータの蒸留モデルで、約45,000件の教師トレースによる教師ありファインチューニングだとされている。ベースが何で、教師が何かはモデルカードに書かれており、素性が伏せられているわけではない。紛らわしいのは名前の付け方であって、配布元の説明そのものは一貫している。
測定環境と、測っていないもの
比較は次の環境で行った。ベース側と蒸留版を、同じビルド・同じ設定で交互に回している。使ったファイルは、蒸留版が empero-ai/Qwen3.8-4B-Distill-GGUF、ベース側が unsloth/Qwen3.5-4B-GGUF である。Qwen公式はQwen3.5-4BのGGUFを配布していないため、ベース側は第三者が変換したファイルにあたる。2つは変換系統が別なので、バイト単位の値はその前提で読む。
- GPU: RTX 5080 16GB (画面出力あり) / RTX 5060 Ti 16GB (OCuLink接続・画面出力なし)
- 推論エンジン: llama.cpp b10356 CUDA (Windows 11)
- 速度計測: llama-bench の pp512・tg128 を各3回、その平均
- サーバ計測: 同ビルドの llama-server、文脈16,384、temperature 0.6・top_p 0.95・top_k 20 (配布元の推奨値)
- 量子化: Q4_K_M と Q8_0 の2種類 (ベース側は Qwen3.5-4B-Q4_K_M.gguf と Qwen3.5-4B-Q8_0.gguf。同じリポジトリに置かれている UD- 付きのファイルではない)
蒸留版のGGUFリポジトリには BF16 / Q4_K_M / Q5_K_M / Q6_K / Q8_0 の5種類が置かれており、配布元はQ4_K_Mを推奨としている。今回はその推奨と、量子化による目減りを減らした側の代表としてQ8_0を選んだ。BF16と中間の量子化は測っていない。量子化を下げてVRAMに収める話そのものは量子化で27B級LLMはVRAM 16GBに載るかで扱っている。
測っていない次元も先に挙げておく。今回の課題は短答のみで、長文の読解・要約、コーディング、日本語での応答品質は評価していない。蒸留版のGGUFに入っているマルチトークン予測層を投機的デコードに使う構成での速度も、BF16での挙動も対象外である。今回は投機的デコードの指定をしておらず、配布元のGGUFカードにも有効化の手順は載っていない。生成された答えの正しさそのものも採点していないため、この記事はどちらのモデルが賢いかを判定するものではない。
本記事の実測値は2026年8月22日時点・当該構成での測定に基づく。
メタデータ上のアーキテクチャは配布元の説明どおりQwen3.5系だった
llama-server を詳細ログ付きで起動すると、GGUFに書き込まれたメタデータがそのまま表示される。Q8_0のファイルで両者を並べたのが次の表である。ここで見えるのは配布元が書き込んだ申告値で、重みを照合したものではない。一致を確かめられるのはアーキテクチャと層の構成までで、重みについては全パラメータを更新したと配布元は説明している。
| 項目 | Qwen3.8-4B (第三者蒸留) | Qwen3.5-4B (ベース) |
|---|---|---|
| アーキテクチャ表示 | qwen35 | qwen35 |
| モデル名表示 | Qwen3.8 4B | Qwen3.5-4B |
| ブロック数 | 33 | 32 |
| トランスフォーマ層数 | 32 | 32 |
| パラメータ数表示 (ファイル内の全テンソル) | 4.33B | 4.21B |
| GGUF内のマルチトークン予測層 | 1層 (今回の設定では読み飛ばされる) | このファイルには含まれていない |
| 文脈長 | 262,144 | 262,144 |
| Q8_0ファイルのサイズ | 4.611 GB | 4.482 GB |
アーキテクチャ識別子はどちらも qwen35 で、名前として表示される文字列だけが「Qwen3.8 4B」になっている。ファイルサイズは配布元表記の10進GBで、以降の表に出てくるMiB表記(2進)とは別の単位である。
ブロック数が33と32で1つ食い違うが、トランスフォーマ層数はどちらも32で一致している。多い1ブロックはマルチトークン予測用である。llama.cpp は投機的デコードが既定で無効で、この起動ではMTP用のテンソルはGPUに載っていない(後述のとおり起動ログの重みバッファがベース側と一致する)。使うには起動時に投機的デコードの種類を明示して指定する必要があり、今回はそれをしていない。つまりファイル上は存在するが、今回の実行経路では推論に関与しない。ただしブロック数が33と32に分かれること自体は、モデルの属性差ではない。公式のQwen3.5-4Bはconfig.jsonでマルチトークン予測層を1層と定義していて、配布されている重みにも該当するテンソルが入っている。今回用意した2つのGGUFは変換した側が異なり、ベース側のファイルには当該テンソルが入っていない。33対32はその差であって、モデルの設計上の差ではない。なぜ入らなかったのかまでは追っていない。パラメータ数表示の4.33Bと4.21Bの差もこの1ブロック分で、実行時にGPUへ載る量は、あとで見るとおりQ8_0では一致する(Q4_K_Mは混合量子化のため、変換した側の違いが残る)。マルチトークン予測そのものが速度にどう効くかは別の話題になる(MTP（マルチトークン予測）でローカルLLMは本当に速くなるか)。
ベースのQwen3.5-4Bは32層で、Gated DeltaNetを3層はさんで1層のGated Attentionを置くハイブリッド構成を採り、native 262,144トークンの文脈長を持つ。公式のモデルカードでは画像・動画の入力に対応するモデルとして記載されており、今回測ったGGUFはそのテキスト側だけを変換したファイルにあたる。表のパラメータ数もテキスト側だけの値になる。同じQwen3.5系でも規模が上がるとメモリ要求は跳ね上がり、手元で動かせる範囲から外れていく(巨大オープンモデルは手元で動くのか比較)。既定では思考モードで動作する。蒸留版も同じ土台を使っているため同様に思考モードで動き、実測でも両方が思考トークンを出している。あとで見るのは思考の有無ではなく、どこで思考を切り上げるかの長さの差である。
1秒あたりの生成速度はベースと変わらない
まず llama-bench による生成速度(tg128)である。文脈長ゼロからの生成で、長い文脈を抱えた状態の速度ではない。RTX 5080は画面出力に使っているカードで、常時1.7GB程度を他プロセスが保持している。
| モデル | 量子化 | RTX 5080 | RTX 5060 Ti |
|---|---|---|---|
| Qwen3.8-4B (第三者蒸留) | Q4_K_M | 191.9 tok/s | 114.0 tok/s |
| Qwen3.5-4B (ベース) | Q4_K_M | 187.0 tok/s | 112.6 tok/s |
| Qwen3.8-4B (第三者蒸留) | Q8_0 | 137.8 tok/s | 79.1 tok/s |
| Qwen3.5-4B (ベース) | Q8_0 | 137.5 tok/s | 79.0 tok/s |
Q8_0では両者の値がほぼ重なり、Q4_K_Mでは蒸留版がわずかに上に出た。3回平均どうしの比較で、この幅を実力差として扱う根拠はない。同じアーキテクチャで同じパラメータ規模なら、1トークンあたりに読む重みの量も変わらないため、この結果は素直な形といえる。
プロンプト処理(pp512)も同様である。512トークンのプロンプトを一括処理したときの速度で、実運用のプロンプト長・並列数を変えると値は動く。この処理が体感の待ち時間のどこに乗るかはTTFTとは何を測っているのかで分解している。
| モデル | 量子化 | RTX 5080 | RTX 5060 Ti |
|---|---|---|---|
| Qwen3.8-4B (第三者蒸留) | Q4_K_M | 8,996 tok/s | 4,733 tok/s |
| Qwen3.5-4B (ベース) | Q4_K_M | 9,057 tok/s | 4,761 tok/s |
| Qwen3.8-4B (第三者蒸留) | Q8_0 | 9,449 tok/s | 4,989 tok/s |
| Qwen3.5-4B (ベース) | Q8_0 | 9,576 tok/s | 4,982 tok/s |
サーバで回したときの速度と消費電力
ベンチ専用の測り方だけでなく、llama-server に開放型のプロンプトを投げたときの値も取った。プロンプト3本(いずれも生成上限1,024トークンに達した)の中央値である。速度はサーバが返す timings の値で、壁時計ではない。GPU全体の使用量は nvidia-smi の値で、他プロセスの分を含む(RTX 5080は画面出力で常時1.7GB程度)。モデル単体の増分ではない。
| GPU | モデル | 量子化 | 生成速度(中央値) | 消費電力(中央値) | GPU全体の使用量(ピーク) |
|---|---|---|---|---|---|
| RTX 5080 | Qwen3.8-4B (第三者蒸留) | Q4_K_M | 168.9 tok/s | 231W | 5,816MiB |
| RTX 5080 | Qwen3.5-4B (ベース) | Q4_K_M | 174.2 tok/s | 242W | 5,484MiB |
| RTX 5080 | Qwen3.8-4B (第三者蒸留) | Q8_0 | 130.0 tok/s | 223W | 7,607MiB |
| RTX 5080 | Qwen3.5-4B (ベース) | Q8_0 | 130.2 tok/s | 227W | 7,138MiB |
| RTX 5060 Ti | Qwen3.8-4B (第三者蒸留) | Q4_K_M | 108.8 tok/s | 148W | 3,510MiB |
| RTX 5060 Ti | Qwen3.5-4B (ベース) | Q4_K_M | 107.6 tok/s | 150W | 3,540MiB |
| RTX 5060 Ti | Qwen3.8-4B (第三者蒸留) | Q8_0 | 76.8 tok/s | 129W | 5,200MiB |
| RTX 5060 Ti | Qwen3.5-4B (ベース) | Q8_0 | 76.7 tok/s | 129W | 5,200MiB |
ここでも1秒あたりの生成量と消費電力は、モデルの違いよりGPUと量子化の違いで決まっている。電力あたりの生成量という見方はローカルLLMの電力あたり生成速度を実測で別途扱っている。GPU全体の使用量はRTX 5080で蒸留版のほうが多く出ているが、これは他プロセスを含んだ値である。画面出力に使っていないRTX 5060 Tiでは3,510MiBと3,540MiB、Q8_0では両者5,200MiBで、次節の起動ログの内訳と同じ向きになる。トークンを1つ吐くコストは、今回の条件では名前が3.8になっても土台と変わらない。
必要VRAMもほぼ同じで、ファイルの128MB差はGPUに載らない
次は起動ログが表示した確保量の内訳である。RTX 5080で文脈16,384を張ったときの値で、RTX 5060 Ti でも同じ内訳だった。表の値は起動ログが表示したGPU側バッファの確保量で、配布ファイルのサイズ(10進GB)とは単位も集計対象も違う。起動ログにはCPU側のマップについての行も出るが、GPU側の値との合計を配布ファイルのサイズと突き合わせられる形にはなっていない。ここは引き算する数字ではない。計算バッファはGPU側の値で、CPU側にも別途26.02MiBが確保される。
| モデル | 量子化 | GPU上の重み | KVキャッシュ | 線形アテンション状態 | 計算バッファ | 合計 |
|---|---|---|---|---|---|---|
| Qwen3.8-4B (第三者蒸留) | Q4_K_M | 2,573MiB | 512MiB | 201MiB | 80MiB | 3,366MiB |
| Qwen3.5-4B (ベース) | Q4_K_M | 2,604MiB | 512MiB | 201MiB | 80MiB | 3,397MiB |
| Qwen3.8-4B (第三者蒸留) | Q8_0 | 4,264MiB | 512MiB | 201MiB | 80MiB | 5,057MiB |
| Qwen3.5-4B (ベース) | Q8_0 | 4,264MiB | 512MiB | 201MiB | 80MiB | 5,057MiB |
Q8_0ではGPU上の重みが4,264MiBで一致し、合計も同じ値になった。ファイルサイズでは蒸留版のほうが128MB程度大きいのに、GPUに載る量は同じという結果である。Q8_0でこの一致が出るのは、前節のマルチトークン予測層が読み飛ばされるためで、今回のように投機的デコードを使わない生成では、多い1ブロックはディスク容量とダウンロード時間だけを使い、VRAMには効いてこない。一方Q4_K_Mでは、逆にベース側が2,604MiBとわずかに大きい。蒸留版のほうが小さいこの向きは、読み飛ばされる1ブロックでは説明がつかない。Q4_K_Mはテンソルごとに割り当てを変える混合量子化で、変換した側が違えばQ8_0のような一致は前提にできない、という程度に留めておく。いずれにせよ合計は3,366MiBと3,397MiBで、16GBのカードに対する余裕の見積もりが変わる差ではない。16GBという枠にどの規模まで収まるかの全体像はVRAM 16GBで動かすローカルLLM完全ガイドにまとめてある。
この内訳は文脈16,384での値である。配布元のGGUFカードは、長い文脈ではKVキャッシュが支配的なコストになると案内している。今回の範囲ではKVキャッシュ512MiBは重み側より小さく、支配的にはなっていない。文脈を伸ばしたときにどこで逆転するかは、モデルのKV構造次第で大きく変わる(2.6BのローカルLLMで128Kの文脈は張れるか)。
差が出たのは同じ問題に使う思考トークンの量
ここまでの結果だけなら、蒸留版を選ぶ理由も避ける理由も特にない。違いが出たのは、同じ短答課題を解かせたときの挙動である。各GPU・各量子化の組み合わせについて、短答3問を各3回、つまりモデルごとに9試行ずつ回した。生成上限は4,096トークン。ここでいう思考トークン数は、思考の開始と終了を示すタグで挟まれた区間に生成されたトークン数で、「答えを返した」はそのタグの後の最終応答が上限内に出たことを指す。
| GPU | モデル | 量子化 | 4,096トークン以内に答えを返した回数 | 思考トークン数の中央値 | 思考トークン数の範囲 | 1問あたりの生成時間の中央値 |
|---|---|---|---|---|---|---|
| RTX 5080 | Qwen3.8-4B (第三者蒸留) | Q4_K_M | 9/9回 | 233 | 62〜522 | 1.4秒 |
| RTX 5080 | Qwen3.5-4B (ベース) | Q4_K_M | 7/9回 | 2,456 | 406〜4,096(上限で打ち切り2件) | 14.4秒 |
| RTX 5080 | Qwen3.8-4B (第三者蒸留) | Q8_0 | 9/9回 | 84 | 67〜153 | 0.7秒 |
| RTX 5080 | Qwen3.5-4B (ベース) | Q8_0 | 7/9回 | 2,532 | 408〜4,096(上限で打ち切り2件) | 19.7秒 |
| RTX 5060 Ti | Qwen3.8-4B (第三者蒸留) | Q4_K_M | 9/9回 | 287 | 151〜744 | 2.7秒 |
| RTX 5060 Ti | Qwen3.5-4B (ベース) | Q4_K_M | 5/9回 | 3,427 | 419〜4,096(上限で打ち切り4件) | 32.3秒 |
| RTX 5060 Ti | Qwen3.8-4B (第三者蒸留) | Q8_0 | 9/9回 | 125 | 83〜1,213 | 1.7秒 |
| RTX 5060 Ti | Qwen3.5-4B (ベース) | Q8_0 | 6/9回 | 2,801 | 1,418〜4,096(上限で打ち切り3件) | 36.8秒 |
「4,096トークン以内に答えを返した回数」は、上限内に答えの行まで到達した回数であって、正答率ではない。到達しなかった回はいずれも誤答ではなく、上限に達して打ち切られたものである。また、ベース側は上限4,096で打ち切られた回が各条件で2〜4件ある。打ち切りは9回のうち4回以下なので、表に出した中央値そのものは打ち切られていない回で決まっている。一方、範囲の上端や平均を見るときは上限の影響を受ける。問題数も試行数も少なく、他の課題種別では別の結果になりうる。
思考トークン数の中央値は、どの組み合わせでもベース側が四桁、蒸留版が二桁から三桁に収まっている。同じ問題文・同じサンプリング設定を、同じアーキテクチャ・同じビルドで走らせている。しかも同じ向きの差はQ8_0でも出ていて、そちらはGPUに載る重みの量まで4,264MiBで一致している。量子化の作り方の違いで説明できる幅ではない。もっとも有力なのは学習後の重みの違い、つまり「どこで考えるのをやめるか」の癖である。ただし2つのGGUFは変換系統が違うため、ファイルに埋め込まれたチャットテンプレートのような、モデル本体以外の差までは切り分けていない。蒸留版も思考トークン自体は出しており、思考モードを切っているわけではない。ベース側は短い問いに対しても思考を続け、いくつかの回では上限まで走り切って答えの行に到達しなかった。
体感に直結するのは1問あたりの生成時間である。RTX 5080のQ8_0では0.7秒と19.7秒、RTX 5060 TiのQ8_0では1.7秒と36.8秒と、同じ問題に対する所要時間が大きく開いた。前節までのとおり1秒あたりの生成速度は同等なので、この差は速さではなく生成量の差から来ている。トークン単価が同じまま、使うトークンの本数が減った形である。
なお、上限4,096トークンという設定自体が結果に効いている。上限をもっと大きく取ればベース側が答えの行まで到達する回数は増える可能性があるが、その場合の1問あたりの待ち時間はここに出ている値より長くなる。上限を変えた条件は測っていない。
配布元が自分で出しているスコアは何を言っているか
配布元のモデルカードには、ベースと同設定の lm-evaluation-harness による CoT プロトコルで測ったという自己申告のスコアが載っている。それによると、MMLU(CoT・57科目)は0.354から0.553へ上がる一方、GSM8K(CoT)は0.850から0.785へ下がっている。ただしMMLUの側は採点系統が2つ併記されていて、この0.354と0.553は答えを緩く抽出する側(flexible-extract)の値である。厳密に書式まで一致を求める側では0.071から0.233への変化で、どちらのモデルも絶対値は大きく下がる。
この2つは方向が逆で、この評価条件では知識問題の側が上がり、多段の算術推論の側が下がった、という結果になっている。MMLU側の上昇は、知識そのものが増えたためとは限らない。生成予算が決まっている採点では、長い思考のまま答えの行に届かなかった回もそのまま不正解として数えられるためで、今回の実測でもベース側は上限で複数回打ち切られている。もっとも同じ表のGSM8Kではベース側が上に出ており、打ち切りだけで両方の向きを説明できるわけではない。プロトコルの詳細も採点の実装も配布元の説明に依存しており、独立に確かめてはいない。
今回の観測との関係も、断定できるところまでは詰められていない。短答で早く答えに到達するようになったことと、長い連鎖を要するGSM8Kのスコアが下がったことが、「考える長さが短くなった」という同じ変化の表と裏である可能性はある。ただしこの測定で取ったのは到達までのトークン量と時間、配布元の数字は正誤で、そもそも別の軸を測っている。別々の物差しの結果が並んでいる、というところまでが確かめられた範囲だ。
どちらを選ぶか
必要VRAMや1トークンあたりの処理性能で選ぶ理由は、ほぼない。違うのは1回答に使う生成量のほうで、そこは同じ機材で10倍から28倍開いている。
短い問いを数多く投げる用途、たとえば分類・抽出・短い応答の量産のように1回あたりの往復を短く保ちたい使い方では、1問あたりの所要時間という今回測った軸に限れば蒸留版が有利に出る。同じ機材で1問あたりの生成時間が約10倍から28倍変わるため、同じ時間に処理できる件数も変わってくる。ただし分類や抽出は出力の正しさが価値を決める用途なので、置き換えの前に自分のデータで正答を確かめる。ベース側で同じことをするなら、思考モードの扱いや生成上限の設計を自分で詰める必要がある。
逆に、長い推論を必要とする課題では、思考が短くなること自体が不利に働きうる。配布元のGSM8Kのスコアが下がっている点はその方向を示唆するが、自己申告値であり、長考が要る課題はここでは扱っていない。
コーディング、日本語での応答、長文の読解や要約、多段の自動実行についても同様で、測っていない以上どちらが向くとは言えない。「3.8世代の性能が4Bで手に入る」という読み方を、この記事の測定は支えていない。速度もVRAMも実測でサイズ相応のままで、品質側の材料は配布元の自己申告スコアだけ、しかも上下の両方向を含む。
使う前に確認しておくこと
最後に、手を出す前に把握しておく点を挙げる。
- 第三者による配布である。 Qwen公式のリポジトリではなく、公式サポートの対象でもない。不具合が出たときの問い合わせ先も、更新が続くかどうかも配布元次第になる。
- 配布元のライセンス表示はApache-2.0。 蒸留モデルとGGUF版のいずれも、2026年8月22日時点のモデルカードではApache-2.0と表示されている。これはベースのQwen3.5-4Bから継いだものとして配布元が付けた表示で、教師にあたるQwen3.8-2.4T-A95Bの側はApache-2.0ではなく qwen3.8-max ライセンスである。表示は将来変更されうるうえ、商用で詰める場合は上流側の条項も見ておく。
- llama.cppのビルドを選ぶ。 Qwen3.5系はハイブリッド構成のため、読み込みにはQwen3.5 / Gated DeltaNetに対応した新しめのllama.cppビルドが必要だと配布元が注意書きしている。今回の実測はb10356で行い、読み込めた。古いビルドのまま試して読み込めない場合は、まずここを疑うことになる。
- 名前が実体を表していない。 ファイル名にもメタデータにも「Qwen3.8 4B」と入るため、表示名だけを見ると公式の3.8世代を手に入れたつもりになりやすい。実際には公式サポートも今後の更新の保証もなく、手元にQwen3.5-4Bがあるなら同じ土台のモデルをもう1本抱えることになる。ローカルの一覧でも「Qwen3.8 4B」と並ぶため、後から設定や測定結果をベース側と取り違えやすい。見分けるには表示名ではなく、リポジトリの所有者がQwen公式かどうか、モデルカードのベース表記、起動ログのアーキテクチャ識別子(ここでは qwen35)を見ればよい。配布元自身はベースと教師を明記しているので、確認先は最初から示されている。
この記事で確認できたのは、同一機材・短答課題という限られた範囲での挙動である。
