Tracks
開発者向けアソシエイトAIエンジニア
26時間
Qwen3.8-Flash-Next のアーキテクチャ
メインの MoE は 125B パラメータですが、トークンあたりで実際にアクティブになるのは約 6B パラメータのみです。さらに n-gram 埋め込みとして 51B パラメータが追加されています。
このアーキテクチャには、Qwen が Qwen4 に向けて検討しているいくつかのアイデアが導入されています。
- Gated DeltaNet + Qwen Sparse Attention（QSA） による長文脈処理の高効率化
- Gated Residual 接続 による層間の情報フローの改善
- N-gram 埋め込み により、すべてのパラメータを都度計算せずにモデル容量を拡張
出典: Qwen
モデルのネイティブなコンテキストウィンドウは 262,144 トークンで、理論上は YaRN により 100 万トークンまで拡張可能です。
Qwen3.8-Flash-Next のコーディング性能は？
コーディングでも驚くほど強力です。以下は Qwen 自身の報告による、Qwen3.8-27B との比較結果の一部です。
|
ベンチマーク |
Qwen3.8-Flash-Next |
Qwen3.8-27B |
|
DeepSWE 1.1 |
58.7 |
42.2 |
|
SWE-bench Pro |
62.5 |
61.7 |
|
SWE-bench Multilingual |
81.0 |
73.8 |
|
Toolathlon Verified |
73.5 |
67.1 |
これらはQwen の社内評価であり、あくまでベンダー公表値として扱うべきですが、コーディング用途での体感とおおむね一致していました。
Qwen3.8-Flash-Next 用の GPU サーバー準備
私は VRAM 96GB の RTX PRO 6000 を使用しましたが、必ずしもここまでの VRAM は不要です。
実は、これが Qwen3.8-Flash-Next の興味深い点のひとつです。llama.cpp はモデルの一部をシステム RAM にオフロードできるため、十分な RAM があれば VRAM の少ない GPU でも利用可能です。
今回使用する Unsloth の UD-Q4_K_XL 量子化は約 111GB で、4 つの GGUF ファイルに分割されています。
私の構成では、RAM と VRAM を合わせて少なくとも 140GB の実効メモリを確保することを推奨します。モデル本体、コンテキスト、KV キャッシュ、ランタイムオーバーヘッドの領域を確保するためです。
H200 のような構成であれば、ほぼすべてを GPU 上に置けます。私は中庸のアプローチを取りました。
まずは GPU を確認します。
nvidia-smi
GPU、ドライバのバージョン、CUDA のバージョン、利用可能な VRAM が表示されます。
次に、必要なパッケージをインストールします。
sudo apt update
sudo apt install -y \
git \
cmake \
build-essential \
curl \
libcurl4-openssl-dev \
python3-pipQwen3.8-Flash-Next 対応で llama.cpp をビルドする
Qwen3.8-Flash-Next は新しい qwen4_exp アーキテクチャを使用しており、単に別の Qwen3.8 モデルを読み込むのとは大きく異なります。
サポートはまだ極めて新しいため、アーキテクチャを認識しない古い llama.cpp に頼るのではなく、Unsloth が保守する Qwen3.8-Flash-Next ブランチを使用しました。対応する llama.cpp の変更では、新しい qwen4exp アーキテクチャ、QSA、n-gram 埋め込み、その他モデル固有のコンポーネントが追加されています。
ワークスペースに移動します。
cd /workspaceUnsloth ブランチをクローンします。
git clone \
--branch qwen4exp/qwen3.8-flash-next \
https://github.com/unslothai/llama.cpp.gitディレクトリに入ります。
cd llama.cppCUDA 対応で llama.cpp をビルドします。
cmake -B build \
-DGGML_CUDA=ON \
-DCMAKE_BUILD_TYPE=Release
cmake --build build \
--config Release \
-j"$(nproc)"最後に、llama-server が正しくビルドされたか確認します。
./build/bin/llama-server --version私の環境では次のように表示されました。
version: 0.3.0-dev (build 10656, commit 035e22731)
built with GNU 13.3.0 for Linux x86_64Qwen3.8-Flash-Next の GGUF モデルをダウンロードする
このセットアップで最も厄介だったのは、実はモデルのダウンロードでした。
最初に ModelScope を試しましたが速度は今ひとつ。Hugging Face は当初はまずまずの速度でしたが、突然 KB/s レベルまで低下しました。
Hugging Face は現在、大容量モデルのダウンロードに Xet バックエンドを使用しており、通常は自動で適応的な並列化が有効になります。問題が出る場合に Xet を無効化するための HF_HUB_DISABLE_XET も提供されています。
私のケースでは、Xet を無効化し、4 つの GGUF シャードを並列ダウンロードするのが最も効果的でした。
Hugging Face CLI をインストールします。
pip install -U huggingface_hub今回のダウンロードでは Xet を無効化します。
export HF_HUB_DISABLE_XET=1
unset HF_XET_HIGH_PERFORMANCE
unset HF_XET_NUM_CONCURRENT_RANGE_GETS
unset HF_HUB_ENABLE_HF_TRANSFERHF_HUB_ENABLE_HF_TRANSFER は既に非推奨で、大容量転送は Xet に移行しています。
モデル用ディレクトリを作成します。
cd /workspace
mkdir -p Qwen3.8-Flash-Next-GGUF4 つのシャードを並列でダウンロードします。
for i in 1 2 3 4; do
shard=$(printf "%05d" "$i")
hf download unsloth/Qwen3.8-Flash-Next-GGUF \
"UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-${shard}-of-00004.gguf" \
--local-dir Qwen3.8-Flash-Next-GGUF &
done
wait
UD-Q4_K_XL の完全版はおよそ 111GB です。
llama.cpp で Qwen3.8-Flash-Next を実行する
llama.cpp のディレクトリに戻ります。
cd /workspace/llama.cppサーバーを起動します。
./build/bin/llama-server \
-m /workspace/Qwen3.8-Flash-Next-GGUF/UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-00001-of-00004.gguf \
--alias qwen3.8-flash-next \
--host 0.0.0.0 \
--port 8080 \
--ctx-size 131072 \
--parallel 1 \
--flash-attn on \
--fit on \
--fit-target 4096 \
--jinja \
--batch-size 1024 \
--ubatch-size 512 \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--min-p 0.0
あえてネイティブの 262K ではなく、131,072 トークンのコンテキストウィンドウを使用しました。
コーディングエージェント用途では 131K でも十分に大きく、ソースコード、ツール出力、ターミナルログ、長い対話などを OpenCode に入れる余裕がありつつ、実際には使わないかもしれない超長文脈にメモリを浪費せずに済みます。
ここで重要な設定は次のとおりです。
-
--fit onにより、llama.cpp がモデルのどの程度を GPU に載せるかを自動的に判断します。 -
--fit-target 4096は GPU メモリを約 4GB 空けておく 指示で、VRAM 上限ぎりぎりではなく、ランタイムに余裕を持たせます。llama.cpp は自動フィットと、メモリ余白の設定を公式にサポートしています。 -
サンプリング設定も意図的です。思考モードでは
temperature=1.0、top_p=0.95、top_k=20、min_p=0.0が Qwen の推奨です。
フルモデルを読み込んだ後でも、VRAM は約 13GB 余っており、コンテキストウィンドウや KV キャッシュ、他アプリケーションに十分な余裕がありました。
CURL で Qwen3.8-Flash-Next サーバーをテストする
llama-server は OpenAI 互換の API を公開します。
利用可能なモデルを確認します。
curl http://127.0.0.1:8080/v1/modelsqwen3.8-flash-next が表示されるはずです。
次に、回答生成をテストします。
curl http://127.0.0.1:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "qwen3.8-flash-next",
"messages": [
{
"role": "user",
"content": "Write a Python function that checks whether a number is prime."
}
]
}'有効なレスポンスが返れば、ローカルサーバーの準備は完了です。
私の環境では、当初は毎秒およそ 80 トークンと、モデルの一部がシステム RAM にあることを考えると意外な速さでした。
コンテキストが大きくなると、速度は毎秒 64 トークン程度に落ち着きました。
125B 級のモデルとしては十分実用的で、アーキテクチャ上の理由も納得できます。メインは 125B でも、トークンごとに実際に動くのは約 6B だからです。
llama.cpp の WebUI で Qwen3.8-Flash-Next をテストする
llama.cpp の良いところは、llama-server にシンプルな WebUI が付属している点です。
http://localhost:8080 を開きます。正しく稼働していれば、すでにモデルが利用可能になっているはずです。
最初の本格テストとして、政府の IT 部門向けウェブサイトをワンショットで作るよう依頼しました。
Create a modern, professional government IT department portfolio website in a single index.html file.
Use HTML, CSS, and JavaScript featuring a clean official design and responsive layout with smooth animations, interactive elements, and accessible government-style navigation.
It should display department overview, key services, digital transformation projects, achievements, technology initiatives, statistics, leadership/team section, latest updates, contact information, 
かなり大きな生成になりました。多くのトークンを使って思考した後、単一の HTML ファイルでサイト全体を生成。完了まで約 13 分かかり、コンテキストが増えるにつれて生成速度は徐々に低下しました。
しかし、結果は期待以上でした。
グラフ、アニメーション、タブ、複数セクション、レスポンシブなスタイル、JavaScript のインタラクションなどが含まれ、レイアウトの完成度も高いものでした。
興味深かったのは、これがほぼワンショット生成だった点です。細かな要素の多くは明示的に依頼していません。
この時点で、細部まで仕様を固めるよりも、ある程度の自由度を与えたコーディングタスクで特に強みを発揮するモデルだと感じました。
Qwen3.8-Flash-Next を OpenCode に接続する
チャットも良いのですが、今回は主にエージェント型のコーディングモデルとしてのテストが目的です。
そのために OpenCode を使用します。まずはインストールします。
curl -fsSL https://opencode.ai/install | bashターミナルを再起動し、インストールを確認します。
opencode --version私の環境ではバージョン 1.18.23 でした。
次に、OpenCode の設定を作成します。
mkdir -p ~/.config/opencode先ほどビルドしたローカルの llama.cpp プロバイダを追加します。
printf '%s\n' '{"$schema":"https://opencode.ai/config.json","model":"llama.cpp/qwen3.8-flash-next","provider":{"llama.cpp":{"npm":"@ai-sdk/openai-compatible","name":"Qwen3.8 Flash Next Local","options":{"baseURL":"http://127.0.0.1:8080/v1"},"models":{"qwen3.8-flash-next":{"name":"Qwen3.8 Flash Next","limit":{"context":65536,"output":32768}}}}}}' > ~/.config/opencode/opencode.json最重要なのは http://127.0.0.1:8080/v1 です。
OpenCode は @ai-sdk/openai-compatible によるカスタムの OpenAI 互換プロバイダをサポートしており、llama.cpp と非常に簡単に接続できます。
llama.cpp サーバー自体は 131K のコンテキストを持っていますが、OpenCode 側はワーキングコンテキストを 65K に設定しました。
これにより長文出力の余裕を十分に残しつつ、エージェントセッションがサーバーのコンテキスト全体を過度に消費しないようにしています。
ローカルのコーディングエージェントとして Qwen3.8-Flash-Next を使う
プロジェクトディレクトリへ移動し、OpenCode を起動します。
cd /workspace/my-project
opencode
あとは通常のエージェント型コーディングタスクを与えるだけです。例えば、Qwen にアナリティクスのダッシュボードを作るよう指示しました。
Build a modern system analytics and task-management dashboard.
It should monitor CPU, RAM, VRAM, GPU usage, temperatures, disk usage, running processes, and temporary files.
Users should be able to safely terminate tasks, free unused RAM/VRAM, clear caches, and clean temporary files from one interface.
モデルは、まず To-Do リストを作って計画を立ててから実装に取りかかりました。
数分で最初の動作版ダッシュボードができましたが、最初の UI は気に入りませんでした。間延びした印象で、使い勝手にもいくつか課題がありました。
そこで、気に入らない点を伝え、よりコンパクトなシステムコマンドセンター風に作り直すよう依頼しました。
2 回目のバージョンは大幅に改善されました。
最終的に、CPU、RAM、VRAM、GPU 使用率、ストレージ、ネットワーク、実行中プロセスをリアルタイムで監視できるコンパクトなダッシュボードになりました。キャッシュのクリア、一時ファイルの掃除、プロセス管理の操作も追加されています。
実装アプローチも興味深いものでした。2 つのアプリを試したところ、素の HTML、CSS、JavaScript を好む傾向があり、React や Node パッケージなど大型フレームワークの即時導入は避けることが多かったです。
私はこの挙動を好ましく感じました。フレームワークを指定しなければ、不要な依存を増やすのではなく、問題を解決する最もシンプルなアーキテクチャを選ぼうとします。
難点は、時間をかけることです。推論量も生成トークン数も多く、ときにデバッグもそれなりに発生します。問題を丁寧に考え抜いていることがトークン消費から伝わってきます。
それでも、最終成果物は多くの場合、これまで試した小型ローカルモデルよりも完成度が高いと感じました。
まとめ
Qwen3.8-Flash-Next をサイト生成やエージェント型コーディングで試した結果、Qwen3.8-27B から明確に一段上だと感じました。最大の違いはプロジェクトへの向き合い方です。単なるコード生成に留まらず、構造や細部、実装の実際面により目配りが利いています。ローカル実行に関心がある場合は、当社のモデルをローカルで動かす方法はQwen3.8-27B のチュートリアルをご覧ください。
また、不要なフレームワークや依存を増やすのではなく、HTML・CSS・JavaScript・Python といったシンプルな技術に依拠することが多い点も好印象でした。
主な難点はサイズです。UD-Q4_K_XL の GGUF は約 111GB に達し、特にデバッグ時は推論や出力トークンが多くなりがちです。
それ以外は、セットアップ自体は驚くほど素直でした。十分な RAM と VRAM があれば、Qwen3.8-Flash-Next は私がこれまで試した中でも屈指のローカル向けコーディングモデルです。