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

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に対して実際にメモリへ載るのは約57GiBであることも実測で確認できました。これはメモリ容量が厳しい環境にとってかなり重要な性質です。

Qwen3.8-Flash-Nextとは

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

アーキテクチャ面では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も併記します。

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

量子化版のサイズ

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

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

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

検証環境

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

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 10674, commit 866322481)
built with MSVC 19.51.36252.0 for Windows AMD64

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

モデルのダウンロード

Hugging Faceの unsloth/Qwen3.8-Flash-Next-GGUF から、UD-Q2KXLの分割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、topp=0.95、topk=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回試行の平均です。

マージ前のPRブランチ(250b61446)でビルドしたバイナリと、マージ後のmaster(866322481)を連続して測り比べましたが、性能差はありませんでした。

なおこの数値は、OSのページキャッシュの状態によって1割程度上下します。ダウンロード直後の最初の計測では3.09 t/sが出ましたが、他の大きなモデルを動かしてキャッシュが入れ替わったあとは2.9 t/s前後に落ち着きました。以降の数値はすべて後者の状態で揃えています。

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

生成速度で約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-Q2KXLの73.45GiBのうち、26.82GiB、実に37%がこのテーブル1つで占められています。

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

テンソル名まで見ると、Unsloth Dynamicの配分が明確に出ています。エキスパート層のうち ffn<em>gate</em>exps と ffn<em>up</em>exps はIQ2XS(2bit級)まで落とす一方、ffn</em>down<em>exps はIQ4NL(4bit)、共有エキスパートとattention周りはQ5K/Q6Kで残しています。そして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-cliで128トークン生成させ、プロセスのワーキングセット最大値とOSの空き物理メモリ最小値を0.7秒間隔でサンプリングしています。

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

なお auto と off の差はこのPCではほとんど出ませんでした(生成速度の0.2 t/s差は各1回の計測なので誤差の範囲です)。llama.cppはmmapでモデルを開くため、off を指定してもOSのデマンドページングが働き、結局は触ったページしか物理メモリに載らないためです。差が出るのは、モデルが物理メモリに明らかに収まらず、スワップやページアウトが発生する環境だと考えられます。

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

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

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

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

実測結果です。

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

結果を見ると、UD-Q3KXLは中途半端な位置にあります。UD-IQ4XSの方がファイルは3.4GiB大きいのに、生成速度は速く(2.37対2.28)、精度指標も上(91.1%対90.4%)です。Q3K_XLは空き物理メモリが10GiB台まで下がるため、ページの奪い合いで試行ごとのばらつき(±0.27)が大きくなったのが効いています。

一方でプロンプト処理はUD-IQ4XSが明確に遅くなります(7.45対9.08)。IQ系の量子化はデコードのコストが高く、512トークンをまとめて処理するpp512でその差が出ます。長いプロンプトを頻繁に投げるならQ2KXL、生成品質を取るならIQ4XSという選び方になります。

96GBというメモリ容量に対しては、UD-IQ4XSが上限に近い実用的な選択肢です。次の段のUD-Q4K_XL(111.3GB = 103.7GiB)は、n-gramテーブルを引いても常駐分が77GiB前後になる計算なので、KVキャッシュを含めるとかなり厳しくなります。

Qwen3.8-27Bとの比較

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

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

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

所要時間は1問ごとにllama-cliを起動した実測値で、モデルのロード時間を含みます。Flash-Next側は毎回73GiBを開き直すため、ページキャッシュが冷えている1問目ほど不利になります(詳細は後述)。

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

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)