【GPU不要】Qwen3.8-Flash-NextをDDR4メモリだけで動かす

2026.08.29

2026年8月26日、AlibabaのQwenチームが「Qwen3.8-Flash-Next」のオープンウェイトを公開しました。次期Qwen4ファミリーで使われる新アーキテクチャの先行公開版という位置づけで、総パラメータ125B(アクティブ6B)に加えて、51Bという巨大なn-gram埋め込み層を持つのが最大の特徴です。

前回、DeepSeek V4 FlashをRyzen 5 3600とDDR4-2400メモリ96GBという構成で動かしましたが、今回は同じPCでQwen3.8-Flash-Nextを動かします。結論から言うと、動きます。しかもDeepSeek V4 Flashより速いです。

そして検証の過程で、このモデルのn-gram埋め込み層がllama.cpp側で「ディスクに置いたまま必要な行だけ読む」扱いになっており、ファイルサイズ73.45GiBに対して実際にメモリへ載るのは約58GiBであることも実測で確認できました。これはメモリ容量が厳しい環境にとってかなり重要な性質です。

Qwen3.8-Flash-Nextとは

Qwen4アーキテクチャのプレビューとして公開された、マルチモーダル対応のMoE(Mixture of Experts)モデルです。

項目内容
総パラメータ数125B(+ n-gram埋め込み51B、MTP 4B)
アクティブパラメータ数6B
レイヤ数48
隠れ層次元2560
エキスパート数512(1トークンあたりrouted 10 + shared 1を使用)
コンテキスト長262,144トークン(YaRNで最大100万)
入力モダリティテキスト・画像・動画
ライセンスqwen-community-1.0
公開日2026年8月26日

アーキテクチャ面では4つの変更が入っています。

  • GDN + QSAハイブリッドアテンション: 線形アテンションのGated DeltaNetと、疎アテンションのQwen Sparse Attention(QSA)を組み合わせた構成です。レイヤ構成は「3層のGated DeltaNet + 1層のQSA」を12回繰り返す形になっています。QSAはトークン単位ではなくマイクロブロック単位で選択するのが特徴です。
  • Gated Residual: 残差ストリームを4本に広げ、ゲートで動的に制御します。
  • N-gram Embedding: 直前の数トークン(bigram/trigram)をハッシュして巨大なテーブルを引くことで、計算量をほとんど増やさずにパラメータ数を稼ぐ仕組みです。ここが51B分を占めます。
  • Muon/AdamWの使い分け: 重みの種類ごとに最適化手法を変える学習レシピです。

このn-gram埋め込みが本記事の主役です。MoEのエキスパート層と違って、n-gram埋め込みは「テーブルから該当行を引くだけ」の処理なので、GPUメモリどころかRAMにすら常駐させる必要がありません。Qwenチーム自身が「メモリ制約のあるアクセラレータ向けに効率よくパラメータをスケールさせる手法」と説明しているとおりの設計です。

ベンチマーク

Qwen公式が公開しているスコアです。参考として前回動かしたDeepSeek-V4-Flash-0731と、比較対象のQwen3.8-27Bも併記します。

ベンチマークQwen3.8-Flash-NextQwen3.8-27BQwen3.7-PlusDeepSeek-V4-FlashClaude-Opus-4.6
総パラメータ125B27B397B284B--
アクティブ6B27B17B13B--
DeepSWE 1.158.742.216.554.4--
SWE-bench Pro62.561.755.856.053.4
CoWorkBench73.970.765.145.168.2
JobBench55.733.427.641.336.6
IFBench81.379.579.179.262.5
GPQA Diamond91.789.290.390.891.3
LiveCodeBench v691.990.389.690.688.8

アクティブパラメータ6BでSWE-bench Proが62.5というのは、かなり高い数字です。エージェント系(CoWorkBench、JobBench)での伸びが特に大きく、Qwen3.7-Plusの約9分の1の学習コストでこれを達成したとされています。

量子化版のサイズ

Unslothが公開しているGGUFの一覧です。右列はUnslothが公表している精度指標(Top-1% Accuracy)で、数値が高いほど元モデルに近い挙動をします。

量子化サイズTop-1% Accuracy
UD-Q4_K_XL111.3GB93.5%
UD-IQ4_XS93.7GB91.1%
UD-Q3_K_XL90GB90.4%
UD-IQ3_XXS82GB87.6%
UD-Q2_K_XL78.9GB85.2%
UD-IQ1_M74.5GB82.4%
UD-IQ1_S72.5GB80.2%

今回はメインの検証にUD-Q2_K_XLを使いました。実測サイズは78,869,128,864バイト、つまり73.45GiBです(上表の「GB」は10進のGBなので、GiB換算では小さく見えます)。

前回のDeepSeek V4 Flashでは1.75bpwのIQ1_Mまで落とさないと96GBに収まりませんでしたが、今回はその1段〜2段上の量子化が使えています。

検証環境

前回のDeepSeek V4 Flash検証と全く同じPCです。

パーツ内容
CPUAMD Ryzen 5 3600(6コア12スレッド、2019年発売)
メモリDDR4-2400 96GB(16GB×2 + 32GB×2)
OSWindows 10 Pro 22H2(10.0.19045)
ストレージモデル配置先の空き容量400GB以上

llama.cppのビルド

Qwen3.8-Flash-Nextのアーキテクチャ(llama.cpp内部の名前は qwen4exp)は、モデル公開の翌日、2026年8月28日にllama.cpp本家のmasterへマージされました(コミット 6c84c7d5d、Unsloth のdanielhanchen氏によるPR #27742)。現在は最新版をcloneするだけで動きます。

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

対応が入ったのはごく最近なので、すでにllama.cppをcloneしてある場合は必ず git pull してください。マージ前のビルドでは qwen4exp が未知のアーキテクチャとして扱われ、モデルの読み込みに失敗します。

既存のllama.cppを別のブランチで使っている場合は、worktreeで並行させると安全です。

git fetch origin master
git worktree add --detach ../llama.cpp-master origin/master

Windowsでのビルドは、Visual Studio(C++ワークロード)を入れた上で開発者コマンドプロンプトから実行します。

cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release -DLLAMA_CURL=OFF
cmake --build build --target llama-cli llama-server llama-bench -j 8

今回ビルドできたバイナリは以下のとおりです。

version: 0.3.0-dev (build 10686, commit 3173a5647)
built with MSVC 19.51.36252.0 for Windows AMD64

CUDAもROCmも使わないので、CMakeのオプションはこれだけで十分です。GPUバックエンドを有効にしていないぶん、ビルドは数分で終わります。

モデルのダウンロード

Hugging Faceの unsloth/Qwen3.8-Flash-Next-GGUF から、UD-Q2_K_XLの分割GGUF3ファイルを取得します。

Qwen3.8-Flash-Next-UD-Q2_K_XL-00001-of-00003.gguf
Qwen3.8-Flash-Next-UD-Q2_K_XL-00002-of-00003.gguf
Qwen3.8-Flash-Next-UD-Q2_K_XL-00003-of-00003.gguf

同じフォルダに置けば、1番目を指定するだけで残りは自動的に読み込まれます。今回は約60MB/sで20分ほどでした。

実際に動かす

Qwen公式が推奨するサンプリングパラメータは、thinkingモードで temperature=1.0、top_p=0.95、top_k=20、min_p=0.0 です。

llama-cli.exe -m Qwen3.8-Flash-Next-UD-Q2_K_XL-00001-of-00003.gguf ^
  -c 16384 -t 6 ^
  --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0

このモデルはデフォルトで思考(thinking)します。思考の深さは reasoning_effort で xhigh(デフォルト)/medium/low の3段階から選べます。CPU推論では生成速度が3トークン/秒程度なので、xhighのままだと思考だけで10分以上かかることがあります。今回の検証はすべて medium で実施しました。

--chat-template-kwargs "{\"reasoning_effort\":\"medium\"}"

思考自体を切りたい場合は {"enable_thinking": false} を指定します。

最初の応答は次のようになりました。

> こんにちは。あなたは誰ですか。一文で答えてください。

[Start thinking]
We need to respond to user: ... Answer in one sentence. We are Qwen?
We can say something like ... Need ensure not mention version. Final concise.
[End thinking]

こんにちは、私はQwen（Tongyi Qianwen）というAIアシスタントです。

[ Prompt: 7.8 t/s | Generation: 3.0 t/s ]

ベンチマーク結果

llama-benchでプロンプト処理(pp512)と生成(tg128)を測定しました。スレッド6、3回試行の平均です。

modelsizeparamsbackendthreadstestt/s
qwen4exp A3B Q2_K - Medium73.44 GiB176.94 BCPU6pp5129.45 ± 0.03
qwen4exp A3B Q2_K - Medium73.44 GiB176.94 BCPU6tg1283.09 ± 0.03

マージ後、masterには model: qwen4exp: reduce number of graph splits(PR #27880)というqwen4exp専用の最適化が入りました。グラフの分割数を減らすもので、n-gram埋め込みの参照を入力埋め込みと同じ分割にまとめる変更です。効果を確認するため、この最適化が入る前のビルドと連続して測り比べました。

ビルドpp512tg128
master 3173a5647(#27880適用後)9.07 ± 0.113.02 ± 0.05
PRブランチ 250b61446(適用前)9.30 ± 0.033.04 ± 0.06

CPU単体では差が出ませんでした。グラフ分割のコストは複数バックエンド(CPUとGPUなど)をまたぐときに発生するもので、CPUだけで動かしている今回の構成では削減しても差が出ないためと考えられます。GPUを併用する環境では効果が出る可能性があります。

なおこれらの数値は、OSのページキャッシュの状態によって1割程度上下します。同じ設定・同じビルドでも、直前に別の大きいモデルを動かした直後は3.02 t/s、キャッシュが暖まった状態では3.09 t/sというように振れます。以降の数値はキャッシュが暖まった状態で揃えています。

前回のDeepSeek V4 Flash(同一PC)と並べると差は明確です。

モデル量子化サイズpp512tg128
Qwen3.8-Flash-NextUD-Q2_K_XL73.44 GiB9.45 t/s3.09 t/s
DeepSeek V4 FlashUD-IQ1_M80.93 GiB3.16 t/s1.58 t/s

生成速度で約2倍、プロンプト処理速度で約3倍です。しかも重み1個あたりの平均ビット数(bpw)を計算すると、DeepSeek側が約2.44bpwなのに対してこちらは約3.57bpw。量子化の粗さで有利になっているわけではなく、むしろ精度面で余裕がある条件でこの差がついています。

理由はアクティブパラメータ数の違いです。DeepSeek V4 Flashは1トークンあたり13B、Qwen3.8-Flash-Nextは6B。CPU推論の速度はメモリ帯域で決まり、メモリ帯域の消費量はアクティブパラメータ数にほぼ比例するので、2倍前後の差になります。

n-gram埋め込み層とメモリの話

ここからが今回の本題です。GGUFのテンソル構成を調べると、面白いことがわかります。

per_layer_token_embd.weight   IQ4_NL   shape=[160, 320001536]   26.82 GiB

これがn-gram埋め込みテーブルです。1行160次元、3億2000万行。UD-Q2_K_XLの73.45GiBのうち、26.82GiB、実に37%がこのテーブル1つで占められています。

量子化タイプ別の内訳は以下のとおりです。

量子化タイプテンソル数合計サイズ
IQ4_NL4947.92 GiB
IQ2_XS9421.23 GiB
Q5_K1891.81 GiB
Q8_02440.74 GiB
IQ3_XXS20.60 GiB
Q6_K640.49 GiB
Q4_K10.33 GiB
F325570.29 GiB
BF16240.04 GiB

テンソル名まで見ると、Unsloth Dynamicの配分が明確に出ています。エキスパート層のうち ffn_gate_exps と ffn_up_exps はIQ2_XS(2bit級)まで落とす一方、ffn_down_exps はIQ4_NL(4bit)、共有エキスパートとattention周りはQ5_K/Q6_Kで残しています。そしてn-gramテーブルもIQ4_NLを維持しています。Unslothの解説によれば、n-gram埋め込みはランダムアクセスされるため、あまり強く量子化すると品質が落ちるとのことです。

そしてこの巨大テーブル向けに、--tensor-read-lazy というオプションが同時に追加されています(qwen4exp対応と同じPR #27742で入り、現在はmasterに含まれます)。

--tensor-read-lazy MODE
  on-demand reading of certain tensors, for example per-layer embeddings (default: auto)
  - on:   read the rows of such tensors from disk on demand instead of keeping them resident
  - auto: on, but only for tensors larger than 4 GiB
  - off:  always keep them resident

デフォルトの auto では、4GiBを超えるマーク済みテンソル(まさにn-gramテーブル)について、テンソル全体をメモリに載せるのではなく、必要な行だけをディスクから読みます。

このオプションはllama-benchにも後から追加されました(PR #27881)。3つのモードすべてをllama-benchで測り、同時にプロセスのワーキングセット最大値とOSの空き物理メモリ最小値を0.8秒間隔でサンプリングしています。

モードpp512tg128ピークWorking Set
auto(デフォルト)9.45 ± 0.033.09 ± 0.0357.83 GiB
on9.47 ± 0.043.29 ± 0.0357.83 GiB
off9.42 ± 0.033.12 ± 0.0357.83 GiB

注目すべきは、73.45GiBのモデルに対してピークのメモリ使用量が約58GiBにとどまっている点です。26.82GiBのn-gramテーブルのうち、実際に触られたのは一部だけということになります。

そして3モードでピークのメモリ使用量が完全に一致しました。これはllama.cppがmmapでモデルを開いているためです。off を指定してテンソル全体をマップしても、OSのデマンドページングが働いて結局は触ったページしか物理メモリに載りません。差が出るのは、モデルが物理メモリに明らかに収まらず、ページアウトが発生する環境だと考えられます。

生成速度に0.2 t/sほどの差が見えますが、これは設定の効果ではありません。このモデルで遅延読み込みの対象としてマークされているテンソルはn-gramテーブル1つだけで、26.82GiBは auto のしきい値である4GiBを超えています。つまり auto と on は同じ動作になるはずです。それでも3.09と3.29に分かれたので、この程度の差はrunごとのばらつきと考えてください。

96GBならもう一段上の量子化が載る

ファイルサイズ73.45GiBに対して実メモリが約58GiBで済むということは、96GB環境ではもっと大きい量子化が選べるはずです。UD-Q3_K_XL(83.81GiB)とUD-IQ4_XS(87.25GiB)も落として確かめました。

テンソル構成を見ると、n-gramテーブルは3つとも全く同じIQ4_NLの26.82GiBでした。増えているのはMoEのエキスパート層(IQ2_XS → IQ3_XXS → IQ3_S)と、その他の層をQ8_0で持つ分です。

量子化ファイルサイズn-gramテーブルそれ以外(常駐分)
UD-Q2_K_XL73.45 GiB26.82 GiB46.63 GiB
UD-Q3_K_XL83.81 GiB26.82 GiB56.99 GiB
UD-IQ4_XS87.25 GiB26.82 GiB60.43 GiB

n-gramテーブルは常駐しないので、いちばん大きいUD-IQ4_XSでも実質的にメモリへ載るのは60.43GiB。96GBに対してはまだ余裕があります。

実測結果です。

量子化サイズ平均bpwTop-1% Accpp512tg128ピークWorking Set空き物理メモリ最小値
UD-Q2_K_XL73.44 GiB3.5785.2%9.45 ± 0.033.09 ± 0.0357.83 GiB20.12 GiB
UD-Q3_K_XL83.80 GiB4.0790.4%9.24 ± 0.172.61 ± 0.0160.59 GiB17.22 GiB
UD-IQ4_XS87.24 GiB4.2591.1%8.03 ± 0.052.53 ± 0.0462.49 GiB14.69 GiB

3つとも問題なく動作しました。品質もUD-Q3_K_XL・UD-IQ4_XSの両方で確認しており、コード生成の課題(compress_ranges)は9ケース全合格、算数の問題も正解です。

サイズが上がるほど生成もプロンプト処理も遅くなり、精度指標は上がるという、わかりやすいトレードオフになりました。生成速度はQ2_K_XLからIQ4_XSまでで18%落ちます。

ここで一点、測定にまつわる注意があります。この表を最初に取ったときはUD-Q3_K_XLが2.28 ± 0.27、UD-IQ4_XSが2.37 ± 0.03となり、「大きいIQ4_XSの方が速い」という逆転が出ていました。誤差が±0.27と異常に大きいことからわかるとおり、これはメモリ逼迫による揺らぎです。llama.cppを更新して測り直したところ2.61と2.53に落ち着き、順当な並びになりました。空きメモリが10GiB台まで落ちる条件では、3回試行の平均でも数値が信用できなくなるということです。誤差の大きさは必ず見てください。

96GBのメモリで使えるのは、UD-IQ4_XSまでです。次の段のUD-Q4_K_XL(111.3GB = 103.7GiB)は、n-gramテーブルを引いても常駐分が77GiB前後になる計算なので、KVキャッシュを含めるとかなり厳しくなります。

Qwen3.8-27Bとの比較

前回と同様にQwen3.8-27B(Q4_K_M)と比較します。まず速度を、同じllama-bench・同じスレッド数6で揃えて測りました。

モデルサイズparamspp512tg128
Qwen3.8-Flash-Next (UD-Q2_K_XL)73.44 GiB176.94 B9.45 t/s3.09 t/s
Qwen3.8-27B (Q4_K_M)15.65 GiB27.32 B6.44 t/s1.32 t/s

ファイルサイズが4.7倍大きいFlash-Nextの方が、生成で2.3倍、プロンプト処理で1.5倍速いという結果です。直感には反しますが、アクティブパラメータで考えれば当然で、Flash-Nextは6B、27Bは密モデルなので27B。1トークンあたりにメモリから読む量が4分の1以下なので、こうなります。CPU推論において「モデルファイルの大きさ」と「生成の速さ」は別物だという、わかりやすい例です。

応答品質の比較も、両モデルとも同じllama-cliで行いました。推論エンジンが違うと前提が揃わないので、比較はすべてllama.cppに統一しています。条件は temperature=1.0、top_p=0.95、top_k=20、min_p=0.0、コンテキスト16384、スレッド6、reasoning_effort は両者とも medium です(27Bのチャットテンプレートも xhigh/medium/low に対応しています)。

所要時間は1問ごとにllama-cliを起動した実測値で、モデルのロード時間を含みます。Flash-Next側は毎回73GiBを開き直すため、ページキャッシュが冷えている1問目ほど不利になります(詳細は後述)。なおこの応答テストは一つ前のmaster(866322481)で実施しています。前掲のとおりqwen4exp向け最適化の前後で性能差は測定できていないため、ベンチマークの数値と突き合わせて読んで問題ありません。

質問1: 算数の文章題

「1個120円のりんごと1個80円のみかんを合わせて10個買ったら、合計金額はちょうど1000円でした。りんごとみかんをそれぞれ何個買いましたか?」

モデル結果生成速度所要時間
Qwen3.8-Flash-Next (Q2_K_XL)正解(りんご5個・みかん5個)1.6 t/s437秒
Qwen3.8-27B (Q4_K_M)正解(りんご5個・みかん5個)1.3 t/s468秒

どちらも連立方程式を立てて正解しました。思考はどちらも英語で行い、回答は日本語です。回答の構成もよく似ていて、条件を表にまとめ、代入して解き、最後に検算を付けるという流れまで一致しました。この難易度では差がつきません。

Flash-Nextの回答から条件整理の部分です。

| 条件 | 式 |
|---|---|
| 個数が合わせて10個 | x ＋ y ＝ 10 …① |
| 合計金額が1000円 | 120x ＋ 80y ＝ 1000 …② |

質問2: ビジネス系の説明タスク

「日本の中小企業がローカルLLMを導入するメリットとデメリットを3つずつ挙げて、それぞれ1〜2文で簡潔に説明してください。」

モデル生成速度所要時間
Qwen3.8-Flash-Next (Q2_K_XL)2.5 t/s389秒
Qwen3.8-27B (Q4_K_M)1.3 t/s690秒

両者とも「3つずつ・1〜2文」という指示は守りました。内容の方向性もほぼ同じで、メリットは「データ保護」「コスト」「カスタマイズ性または可用性」、デメリットは「初期投資」「人材」「クラウド大手との性能差」という構成でした。

差が出たのは具体性です。Flash-Nextは思考の段階で日本の個人情報保護法や稟議書・見積書といった商慣習を明示的に洗い出しており、回答にもそれが反映されました。

3. 自社業務に特化した最適化ができる 稟議書・見積書・業界用語など、日本の商慣習に合うようファインチューニングを施せば、市販の汎用モデルより精度の高い社内AIを構築できる。他社と共有されない独自資産として競争力の源になる。

27B側は「顧客情報・設計図・財務データ」「金融・医療・製造など守秘義務が厳しい業界」と業種を挙げる方向で具体化しており、日本固有の商慣習には触れませんでした。どちらも問題のない回答ですが、「日本の中小企業」という条件に合わせた具体性はFlash-Nextの方が高いです。

一方で両モデルとも、デメリットの初期投資額を実態より重く見積もりました。Flash-Nextは「A100/RTX 4090級GPUや専用サーバーが必要で数百万円規模」、27Bは「A100・H100級を備えたサーバー一式で数百万〜数千万円」と書いています。この記事自体が示しているとおりGPUなしでも動く選択肢はあるので、この点は両者とも同じ弱点を持っています。

質問3: コード生成

「Pythonで、整数のリストを受け取り、連続する整数の範囲をまとめた文字列に変換する関数 compress_ranges を書いてください。例: [1,2,3,5,7,8,9] は '1-3,5,7-9' になります。」

生成されたコードは、そのままコピーしてテストコードで検証しました。基本例に加えて、空リスト・単一要素・未ソート入力・重複あり・負の数([-3,-2,-1,1,2] → '-3--1,1-2')・ゼロ・連続なしの計9ケースです。

モデルテスト結果生成速度所要時間
Qwen3.8-Flash-Next (Q2_K_XL)9/9 合格2.6 t/s508秒
Qwen3.8-27B (Q4_K_M)9/9 合格1.3 t/s1010秒

両者とも全ケース合格でした。しかもアルゴリズムはほぼ同一で、sorted(set(nums)) で重複除去とソートを同時に行い、start/end の2変数で走査する方式でした。前回のDeepSeek V4 Flashは重複除去をしておらず [5,5,6] が '5,5-6' になりましたが、Qwen系は両モデルともここを押さえています。

Flash-Nextが生成したコードです。

def compress_ranges(nums: list[int]) -> str:
    """
    整数のリストを受け取り、連続する範囲を 'start-end' 形式の
    文字列に圧縮する。

    例: [1, 2, 3, 5, 7, 8, 9] → '1-3,5,7-9'
    """
    if not nums:
        return ''

    # 重複除去 + 昇順ソート
    sorted_nums = sorted(set(nums))

    ranges: list[str] = []
    start = end = sorted_nums[0]

    for n in sorted_nums[1:]:
        if n == end + 1:
            # 連続 → 現在の範囲を延長
            end = n
        else:
            # 不連続 → 現在の範囲を確定し、新しい範囲を開始
            ranges.append(str(start) if start == end else f'{start}-{end}')
            start = end = n

    # ループ後の最後の範囲を忘れない
    ranges.append(str(start) if start == end else f'{start}-{end}')

    return ','.join(ranges)

27B側は範囲の整形を _format というヘルパー関数に切り出し、docstringにdoctest形式の例を2つ入れる書き方でした。設計としてはこちらの方が丁寧です。Flash-Nextは最後に計算量(O(n log n))と空間計算量を添えていました。どちらも実用上まったく問題ないレベルです。

比較のまとめ

  • 正答率は3問すべてで互角。この難易度では差がつかない
  • 生成速度はFlash-Next 3.09 t/s、27B 1.32 t/sでFlash-Nextが2.3倍速い(llama-bench)。実際の応答でも27Bは3問とも1.3 t/sで安定しており、ベンチの値と一致した
  • 所要時間は3問ともFlash-Nextが短い。特に長い回答になるコード生成では508秒対1010秒とほぼ半分
  • 日本語の具体性(商慣習への言及)はFlash-Nextがやや上、コードの構成の丁寧さは27Bがやや上
  • メモリ消費はFlash-Nextが約58GiB、27Bが約16GiB

Flash-Next側は1問ごとに73GiBを開き直すロード時間を含んでもなお速い、という結果です。常時起動のllama-serverで使えば、この差はさらに開きます。

ページキャッシュの状態で速度が変わる

Flash-Nextの応答テストでは、1問目の生成が1.6 t/s、2問目以降が2.5〜2.6 t/sと、同じ設定なのに差が出ました。llama-benchの3.09 t/sにも届いていません。

原因は --tensor-read-lazy の副作用です。n-gram埋め込みテーブルはメモリに常駐せずディスクから行を読むので、そのページがOSのページキャッシュに乗っているかどうかで速度が変わります。1問目は直前に別の大きいモデル(UD-Q3_K_XL)を動かしてキャッシュが入れ替わった直後だったため、最も不利な条件でした。

実用上のポイントは2つです。

  • モデルはSSDに置く。HDDだとこのランダムアクセスが致命的に遅くなります
  • llama-serverで常駐させ、同じプロセスを使い続ける。プロセスを立ち上げ直すたびにキャッシュが冷えるところからやり直しになります

高速化するには

現状3.1トークン/秒をどこまで伸ばせるかの目安です。

  • DDR5環境への更新: CPU推論の速度はメモリ帯域でほぼ決まります。DDR4-2400デュアルチャネルの理論帯域は約38GB/s、DDR5-5600なら約90GB/sなので、7トークン/秒前後が見込めます。
  • 24GB級GPUの追加: MoEモデルでは「attention層とKVキャッシュをGPUに載せ、エキスパート層はメインメモリに残す」構成(-ngl 99 --n-cpu-moe 99)が定番です。生成で2〜3倍、プロンプト処理で5〜10倍が期待できます。n-gram埋め込みテーブルはもともとGPUに載せる必要がないので、この構成との相性は良いはずです。
  • スレッド数: 今回は物理コア数の6で測定しました。Ryzen 5 3600ではSMTを使って12スレッドにしてもメモリ帯域が上限に達しているので、ほとんど改善しません。
  • SSDに置く: n-gram埋め込みテーブルはディスクからランダムアクセスされるので、モデルの配置先はSSD必須です。

なお量子化を上げると速度は落ちます(IQ4_XSで生成2.53 t/s、pp512 8.03 t/s)。速度優先ならUD-Q2_K_XL、生成品質を取るならUD-IQ4_XSを選んでください。

まとめ

  • Qwen3.8-Flash-Next(125B MoE + 51B n-gram埋め込み)は、UnslothのUD-Q2_K_XL(73.45GiB、平均3.57bpw)を使えばDDR4メモリ96GBのGPUなしPCで動く
  • 対応は2026年8月28日にllama.cpp本家masterへマージ済み(コミット 6c84c7d5d)。最新版をpullすればそのまま動く
  • その後masterに入ったqwen4exp向け最適化(PR #27880)は、CPU単体では効果が測定できなかった。GPU併用時には効果が出る可能性がある
  • 生成速度は3.09トークン/秒。同一条件で測ったDeepSeek V4 Flash(1.58 t/s)の2.0倍、Qwen3.8-27B(1.32 t/s)の2.3倍と、ファイルサイズが4.7倍大きいのに速い
  • 品質はQwen3.8-27B(Q4)と互角以上。コード生成は境界ケース込みで一発合格
  • n-gram埋め込みテーブルは --tensor-read-lazy により必要な行だけ読まれるため、73.45GiBのモデルでも実メモリ使用量は約58GiBにとどまる
  • その余裕を使ってUD-Q3_K_XL(83.81GiB)とUD-IQ4_XS(87.25GiB)も動作した。96GBならUD-IQ4_XSが実用上の上限で、生成2.53 t/s・精度指標91.1%とバランスが良い
  • 一方で、ページキャッシュが冷えていると生成が1.6 t/s程度まで落ちる。モデルはSSDに置き、llama-serverで常駐させるのが実用的

アクティブパラメータが6Bしかないため、ファイルは巨大なのに生成は速い、という珍しいモデルです。メモリさえ用意できれば、5年以上前のCPUでも実用的な速度が出ます。DDR4の96GBは中古なら比較的安く揃うので、大容量メモリのPCがあれば試す価値があります。

スポンサーリンク

コメント

タイトルとURLをコピーしました