Qwen3.8-Flash-Nextをllama.cppで動かす ― unknown model architecture ‘qwen4exp’ の解決方法

公開日：2026/08/27

2026年8月26日に公開されたQwen3.8-Flash-Nextを早速ローカルで動かしてみました。

GGUFをダウンロードして最新版のllama.cppから起動しようとしたところ、最初に遭遇したのが次のエラーです。

unknown model architecture: 'qwen4exp'

llama.cppを最新版へ更新しても解消しなかったため調べたところ、Qwen3.8-Flash-Nextは従来のQwen3.8とは異なる新しいアーキテクチャを採用しており、対応途中のllama.cppを使用する必要がありました。

この記事では、Apple Silicon MacでQwen3.8-Flash-NextのGGUFをllama.cppから起動するところまでをまとめます。

Qwen3.8-Flash-Nextは従来のQwen3.8とは別物

名前だけを見るとQwen3.8シリーズの高速版のように見えますが、Qwen3.8-Flash-Nextはアーキテクチャ的にはかなり新しいモデルです。

Qwen公式では、Qwen3.8-Flash-Nextを将来のQwen4で採用されるアーキテクチャのearly previewと位置付けています。

主な特徴として、

Gated DeltaNet（GDN）+ Qwen Sparse Attention（QSA）
Gated Residual
N-gram Embedding
125Bパラメータのメインモデル
追加の51B N-gram Embedding
1 tokenあたり6BパラメータをactivateするMoE構成
ネイティブ262K context

といった新しい仕組みが採用されています。

つまり、従来のQwen3.8モデルをそのまま高速化したモデルというより、Qwen4へ向けた新アーキテクチャの実験的・先行的なモデルと考えた方が分かりやすいです。

GGUFではqwen4expとして認識される

Qwen3.8-Flash-NextのGGUFを通常のllama.cppで読み込もうとすると、

unknown model architecture: 'qwen4exp'

というエラーが発生する場合があります。

ここで重要なのがqwen4expという名前です。

Qwen3.8-Flash-Nextの新アーキテクチャは、GGUF / llama.cpp側ではqwen4expというarchitectureとして扱われています。

そのため、使用しているllama.cppがqwen4expを認識できなければ、モデルのロード段階で停止します。

qwen4exp対応版llama.cppを用意する

今回は通常使用しているllama.cppを壊さないよう、別ディレクトリへcloneしました。

cd ~/src

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

cd llama.cpp-qwen4exp

続いて、qwen4exp / Qwen3.8-Flash-Next対応のPull Requestを取得します。

git fetch origin pull/27742/head:qwen4exp

git checkout qwen4exp

これでqwen4exp対応コードへ切り替わります。

なお、この番号や対応状況は記事公開後に変わる可能性があります。将来的に対応コードがllama.cpp本体へmergeされた場合、この手順は不要になります。

Apple Silicon向けにビルドする

Apple Silicon Macなので、Metalを有効にしてビルドします。

cmake -B build \
  -DGGML_METAL=ON \
  -DCMAKE_BUILD_TYPE=Release

cmake --build build -j --target llama-server llama-cli

正常に完了すれば、

build/bin/llama-server
build/bin/llama-cli

が生成されます。

通常版のllama.cppとはディレクトリを分けているため、従来モデルについては今までのllama.cpp、Qwen3.8-Flash-Nextについてはllama.cpp-qwen4expを使う、といった運用もできます。

Qwen3.8-Flash-Next GGUFをダウンロードする

今回はUnslothが公開しているGGUFを使用しました。

M5 Max / 128GB環境で試すため、まずUD-IQ1_Sをダウンロードしています。

uvx hf download unsloth/Qwen3.8-Flash-Next-GGUF \
  "*-UD-IQ1_S-*" "*tokenizer*" "*chat_template*" \
  --local-dir ~/models/qwen3.8-flash-next-unsloth

UD-IQ1_Sでも全体で約72.5GBあります。

ダウンロードすると、GGUFが次のように複数ファイルへ分割されています。

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

分割GGUFは結合しなくてよい

最初は3ファイルを結合する必要があるのかと思いましたが、llama.cppはsplit GGUFをそのまま扱えます。

3ファイルを同じディレクトリへ置いた状態で、最初の00001-of-00003だけを指定します。

--model ~/models/qwen3.8-flash-next-unsloth/UD-IQ1_S/Qwen3.8-Flash-Next-UD-IQ1_S-00001-of-00003.gguf

残りの、

00002-of-00003
00003-of-00003

はllama.cppが自動的に読み込みます。

推論するだけであれば、事前に1ファイルへ結合する必要はありません。

まずllama-cliでモデル単体を確認する

いきなりClaude CodeなどのAgentへ接続するより、まずモデル単体が正常にロードできることを確認した方がトラブルを切り分けやすくなります。

~/src/llama.cpp-qwen4exp/build/bin/llama-cli \
  -m ~/models/qwen3.8-flash-next-unsloth/UD-IQ1_S/Qwen3.8-Flash-Next-UD-IQ1_S-00001-of-00003.gguf \
  -ngl 999 \
  -p "Write a short hello world program in Python."

通常版llama.cppでは、

unknown model architecture: 'qwen4exp'

で停止していましたが、qwen4exp対応版ではモデルをロードして推論を開始できました。

llama-serverとして起動する

モデル単体で動くことを確認したら、llama-serverとして起動します。

まずは動作確認を優先して、contextやbatchをやや控えめにしています。

~/src/llama.cpp-qwen4exp/build/bin/llama-server \
  --model ~/models/qwen3.8-flash-next-unsloth/UD-IQ1_S/Qwen3.8-Flash-Next-UD-IQ1_S-00001-of-00003.gguf \
  --host 0.0.0.0 \
  --port 8080 \
  \
  --ctx-size 65536 \
  --n-predict 8192 \
  --parallel 1 \
  \
  --flash-attn on \
  -ngl 999 \
  \
  --batch-size 2048 \
  --ubatch-size 1024 \
  \
  --cache-type-k q8_0 \
  --cache-type-v q8_0

これでOpenAI互換APIを持つllama-serverとして利用できます。

なぜ最初は64K contextにしているのか

Qwen3.8-Flash-Next自体は262,144 tokenのネイティブcontextをサポートしています。

しかし、今回使用しているUD-IQ1_Sだけでも約72.5GBあります。

M5 Max 128GBであればロード可能なサイズですが、

約72.5GBのモデル
+
KV Cache
+
Metalのcompute buffer
+
macOS
+
IDE
+
Claude Codeなどのアプリケーション

がすべて128GBのユニファイドメモリを共有します。

そのため、最初から262K contextや複数parallel slotを確保するのではなく、まず、

ctx-size 65536
parallel 1
batch-size 2048
ubatch-size 1024

程度で正常動作を確認してから増やしていく方が安全です。

Qwen3.8-Flash-Nextはなぜこんなに巨大なのか

「6B activeのMoEなのに、なぜIQ1量子化でも70GB以上あるのか」と疑問に思うかもしれません。

Qwen3.8-Flash-Nextは、125Bパラメータのメインモデルに加えて、51B規模のN-gram Embeddingを持っています。

MoEの「6B active」という数字は、1 tokenの計算時にすべての125Bパラメータを使うわけではない、という意味です。

一方でモデルをロードするには、非activeなexpertを含むweightやN-gram Embedding自体を保持する必要があります。

そのため、計算量は比較的小さいが、モデルを保持するためのメモリ容量は非常に大きいという少し特殊なモデルになっています。

この性質が、128GB以上のユニファイドメモリを持つApple Siliconとどう噛み合うのかは興味深いところです。

現時点では開発途中の対応であることに注意

Qwen3.8-Flash-Nextは公開されたばかりで、llama.cpp側の対応も進行中です。

実際、qwen4expに関してはGPU offload時の問題などもすでに報告されています。

そのため、

動作していたcommitで突然動かなくなる
backendによって挙動が異なる
Metal / CUDA / Vulkanで性能や安定性が異なる
chat templateやTool Calling周辺が変更される

といった可能性があります。

特に記事執筆時点ではPull Request上のコードを使用しているため、通常の安定版llama.cppと同じ感覚で運用するのは避けた方がよいでしょう。

将来的には通常のllama.cppで動くはず

今回必要だった、

git fetch origin pull/27742/head:qwen4exp
git checkout qwen4exp

という手順は、あくまでQwen3.8-Flash-Next公開直後の暫定的なものです。

qwen4exp対応がllama.cpp本体へmergeされれば、通常の最新版llama.cppから、

llama-server \
  --model Qwen3.8-Flash-Next-UD-IQ1_S-00001-of-00003.gguf \
  ...

と起動できるようになるはずです。

もしこの記事を後から読んでいる場合は、まず最新のllama.cppで起動してみてください。

それでも、

unknown model architecture: 'qwen4exp'

が出る場合に、この記事のqwen4exp対応ブランチを試すのがよいでしょう。

Claude Codeのローカルバックエンドとして使えるか

今回このモデルを試している主な目的は、Claude CodeなどのCoding AgentのローカルLLMバックエンドとして利用することです。

以前Qwen3.8-27Bでは、

reasoningの分離
Tool Calling
Chat Template
長いcontext
Auto Compact

などを調整することで、llama.cppをClaude Codeのバックエンドとして動かすことができました。

Qwen3.8-Flash-Nextでも同様の構成を試す予定ですが、新しいqwen4expアーキテクチャであることに加えてllama.cpp側の対応も始まったばかりなので、Tool Callingや長時間のAgent Loopがどの程度安定するかは別途検証が必要です。

特にCoding Agentでは、単にモデルが文章を生成できるだけでは不十分です。

Claude Code
    ↓
LLMへ推論要求
    ↓
Qwen3.8-Flash-Next
    ↓
Tool Call
    ↓
Claude CodeがRead / Edit / Bash等を実行
    ↓
Tool Resultをモデルへ返す
    ↓
次のTool Call

というAgent Loopを何十ターンも安定して回せる必要があります。

このあたりは今後実際のコーディング作業で検証していきます。

まとめ

Qwen3.8-Flash-NextのGGUFを最新版のllama.cppで起動しようとして、

unknown model architecture: 'qwen4exp'

が出る場合、GGUFファイルが壊れているわけでも、起動オプションが間違っているわけでもありません。

Qwen3.8-Flash-NextがQwen4へ向けた新しいアーキテクチャを採用しており、GGUFではqwen4expとして扱われていることが原因です。

記事執筆時点では、

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

git fetch origin pull/27742/head:qwen4exp
git checkout qwen4exp

cmake -B build \
  -DGGML_METAL=ON \
  -DCMAKE_BUILD_TYPE=Release

cmake --build build -j --target llama-server llama-cli

としてqwen4exp対応版をビルドすることで、Apple Silicon Mac上でもモデルをロードして推論できました。

公開直後のモデル・アーキテクチャなので今後かなり速いペースで状況が変わると思いますが、Qwen4の先行プレビューをローカル環境で試せるという意味でも、Qwen3.8-Flash-Nextはかなり面白いモデルです。