Qwen3.5-397B IQ4_NL実測：28回のランで平均22.5tok/s、ハイブリッドオフロード構成と400B級MoEの常用可能性

Qwen3.5-397B-A17B（397B総パラメータ/17B活性MoE）をIQ4_NL量子化でEPYC 9175F + GPU環境にハイブリッドデプロイ。28回の連続推論で平均TG 22.5tok/s、最大PP 372tok/s。WordPress的Django CMS基盤の長文脈コード生成評価を含む。

技術メモとして残していた ObsidianノートにAIの要約を利用しています。

背景

Qwen3.5-397Bは総パラメータ397B、活性17BのMoEモデル。通常はH100複数枚が必要なクラスだが、IQ4_NL量子化 + cpu-moe + テンソルオフロードの組み合わせで、EPYC + コンシューマGPU環境でも動く。

問題は「動くだけ」なのか「常用できる速度」なのか。28回の連続推論で定量評価した。加えて、長文脈でのコード生成能力を確認するため、WordPressライクなDjango CMS基盤の仕様を入力してプロジェクト骨格の生成を試した。

目的

IQ4_NL量子化での定常TG/PP速度を28回のランから統計的に把握
ハイブリッドオフロード（cpu-moe / マルチGPUテンソルオフロード）の実行構成を記録
コンテキスト長依存性と安定性を評価
400B級MoEの日常運用可能性を判定
長文脈コード生成タスク（Django CMS基盤）での品質評価

実験環境

項目	仕様
CPU	AMD EPYC 9175F（Zen 5, 16C, L3 512MB）
メモリ	DDR5-6400 768GB（12ch）
GPU	NVIDIA RTX PRO 6000（96GB VRAM）
OS	Ubuntu 24.04 LTS
Runtime	ik_llama.cpp（cpu-moe有効）
量子化	IQ4_NL
コンテキスト	最大262,144

結果

スループット統計（28回のラン）

指標	Prefill (PP)	Generation (TG)
最大値	372.24 tok/s	24.04 tok/s
最小値	101.49 tok/s	19.13 tok/s
平均（定常時）	約160 tok/s	約22.5 tok/s

代表的なラン

#	PP(tok)	TG(tok)	PP速度(tok/s)	TG速度(tok/s)	合計(s)
1	4,699	13	314.22	21.95	15.5
3	1,125	2,048	161.67	20.81	105.4
8	1,124	2,048	154.76	23.82	93.3
14	15,866	2,048	372.24	22.98	131.7
16	550	520	117.78	22.91	27.4

Run #14: 15,866トークンの大規模入力を42.6秒で処理し、22.98 tok/sで生成開始。1.5万トークンのソースコード群を40秒強で読み込める。

コンテキスト依存性

PP速度: 短いプロンプト（<1k）では100 tok/s台。長くなるほど並列効率が上がり300 tok/s超に加速
TG速度: コンテキスト長によらず21-24 tok/sの範囲で極めて安定

ハイブリッドオフロード構成

単一GPU + cpu-moe構成

  IMG=compute.home.arpa/ik_llama-cuda
MODEL=/models/.../IQ4_KSS/Qwen3.5-397B-A17B-IQ4_KSS-00001-of-00006.gguf

podman run --rm -it --device nvidia.com/gpu=all \
  -p 8001:8080 --shm-size 16g --cap-add=SYS_NICE \
  -v "$MO":/models:ro,Z "$IMG" \
  --host 0.0.0.0 --port 8080 -m "$MODEL" \
  -c 262144 --threads 13 --threads-batch 24 \
  --jinja -b 2048 -ub 2048 -ngl 99 \
  -fa on --no-mmap --cpu-moe

--cpu-moe: GPUに収まらないエキスパート計算をCPU側で処理。EPYC 9175Fの12ch DDR5帯域がアクティブなエキスパートを供給し、GPU側でAttention演算を加速するハイブリッド設計。

マルチGPUテンソルオフロード構成

2GPU環境では-otで正規表現ベースのレイヤー分散が可能:

  ./build/bin/llama-server \
  --model "$model" \
  -fa on --ctx-size 135168 \
  -ctk q8_0 -ctv q8_0 \
  -ub 2048 -b 2048 -ngl 999 \
  -ot "blk\.(0|1|2|...|12)\.ffn_(gate|up|down)_exps.*=CUDA0,\
       blk\.(47|48|...|60)\.ffn_(gate|up|down)_exps.*=CUDA1" \
  --cpu-moe --threads 24 --no-mmap --jinja

初期レイヤー（0-12）をCUDA0、終盤レイヤー（47-60）をCUDA1に割り当て。中間レイヤーはcpu-moeが処理。VRAM消費を平滑化しつつ135kコンテキストを確保。

長文脈コード生成評価：WordPressライクDjango CMS

評価内容

Qwen3.5-397B-A17Bに長い設計文書を渡し、WordPressの概念モデルをDjangoに落としたCMS基盤のプロジェクト骨格を生成させた。仕様はPosts/Pages、Categories/Tags、Comments、Media Library、Menus/Navigation、Drafts/scheduled publishing、Revision historyまで含む。

推論設定

  IMG=compute.home.arpa/ik_llama-cuda
MO=/mnt/data/hf/hub/models--ubergarm--Qwen3.5-397B-A17B-GGUF
MODEL=/models/snapshots/.../IQ4_KSS/Qwen3.5-397B-A17B-IQ4_KSS-00001-of-00006.gguf

podman run --rm -it --device nvidia.com/gpu=all \
  -p 8001:8080 --shm-size 16g --cap-add=SYS_NICE \
  -v "$MO":/models:ro,Z "$IMG" \
  --host 0.0.0.0 --port 8080 -m "$MODEL" \
  -c 262144 --threads 13 --threads-batch 26 \
  --jinja --temp 0.7 --repeat-penalty 1.2 \
  --min-p 0.01 --top-p 0.95 --seed 317 --top-k 40 \
  -b 2048 -ub 2048 -ngl 99 \
  -fa on --no-mmap -ger

262kコンテキスト設定により、長い仕様書を入力してから実装コードを出力するまでを1セッションで実行。

仕様設計のポイント

仕様のなかで効果的だったのは、WordPress概念とDjangoモデルの対応表を先に置いたことだった。Post/Page -> content.Post/content.Page、Category/Tag -> taxonomy.Term、Post Meta -> content.PostMeta、Revision -> content.Revisionという対応表があることで、後半のフィールド設計が崩れにくくなった。

非目標（Out of Scope）を明示したことも重要で、WordPress完全互換、Gutenberg再現、multisite UI parity、完全WYSIWYGを外したことで、モデルが無駄に複雑な構造に寄りにくくなった。

生成結果

ログ上では以下のファイル群が生成された:

apps/core/models.py / models_site.py / models_setting.py
apps/content/models.py / models_page.py / models_extra.py
apps/taxonomy/models.py
apps/media/models.py
apps/comments/models.py
apps/navigation/models.py
apps/seo/models.py
config/settings/base.py / dev.py / prod.py
config/urls.py / asgi.py / wsgi.py
manage.py / requirements.txt

仕様書を読ませた結果として、Djangoプロジェクトの骨格と主要appのモデル定義までかなりまとめて出力できている。

生成品質の強み

仕様追従: Post、Term、Revision、SEOEntryのような大枠はかなりそのまま使えた
概念マッピング: WordPress的な操作感を残しつつ、Djangoのモデル設計として整合している
抽象モデル: TimeStampedModel、SoftDeleteModel、PublishableModel、SluggedModelの共通基盤が自然に出力された
SEO制約: SEOEntryにpostまたはpageのいずれかに結び付くCheckConstraintまで生成していた

生成品質の弱み

フィールド欠落: slug がPost生成途中で一度消え、後から差分で復元された
ファイル配置のぶれ: Pageを最初はmodels_page.pyに分け、その後models.pyに再統合する揺れが発生
フィールド不整合: Comment.save()がself.author_ipを参照しているのに、最初はauthor_ipフィールドが存在しなかった
ツール失敗: ctree_check、ctree_init、filesystem_create_directoryが複数回失敗し、write_fileにフォールバック

コード生成の知見

長い設計文書を渡しても、最終出力はきれいな一本道にはならない。ツール失敗、親ディレクトリ不足、モデル定義の欠落、フィールドの食い違いが繰り返し起きる。

それでも意味があるのは、モデルがゼロから骨格を作る速度が速いからだ。人間が見るべきところは、出力されたコードを信用することではなく、どの部分がそのまま使え、どの部分が必ずレビュー対象になるかを早く切り分けることにある。

考察

なぜ397Bが22 tok/sで動くか

397Bという巨大な器を持ちながら、推論時に動くのは17B。IQ4_NL量子化でメモリ帯域負荷を1/4以下に圧縮。12チャネルDDR5帯域がアクティブエキスパートを供給し、GPU側でAttention演算を加速する分業体制が「17B級の速度」を実現している。

IQ4_NL量子化の選択

397Bクラスでは量子化なしのデプロイは非現実的。IQ4_NLは品質の低下を最小限に抑えつつ、メモリフットプリントを大幅削減。28回のランで品質の明らかな劣化は観測されなかった。

ウォームアップの必要性

初回数回は挙動が揺らぐ。安定したTG速度に入るまで2-3回のダミーリクエストが有効。常駐運用前提ならウォームアップスクリプトを組み込む。

感想

「400B級は実験用」という認識は変わりつつある。22.5 tok/sは人間がリアルタイムで対話するには十分で、非同期バッチでは高い処理能力を意味する。

TG速度がコンテキスト長によらず21-24 tok/sで安定している点が特に重要。15kトークンのソースコードを投げても速度が落ちない。これは複雑なリポジトリ全体を食わせるユースケースで活きる。

Django CMS基盤の生成テストでは、400B級モデルの長文脈能力が実際のプロジェクト初期化に使えることを確認できた。仕様書の構造（概念マッピング表、非目標の明示、実装順序の指定）がそのまま生成品質に影響する点は、今後のプロンプト設計にも活きる。

マルチGPUテンソルオフロードは「GPU2枚あるなら使うべき」構成。cpu-moeだけでも動くが、-otでの明示的なレイヤー分散はスループットを向上させる。

補足ノウハウ

KVキャッシュ量子化

135k-262kの広大なコンテキストではKVキャッシュが大量のメモリを消費する。-ctk q8_0 -ctv q8_0でKVキャッシュを量子化し、メモリ圧迫を抑制。品質への影響は体感では小さい。

サンプリングパラメータ

安定したコード生成には--temp 0.7 --repeat-penalty 1.2 --min-p 0.01 --top-p 0.95 --top-k 40が有効。temp 1.0では創造的だが冗長になりやすい。

コード生成の仕様設計ガイドライン

次に同じことをやるなら、ソースを3つに分けるのが良い:

推論サーバー起動テンプレート
CMS仕様書（概念マッピング + 非目標 + 実装順序を含む）
生成ログとレビュー結果

概念辞書を先に置き、非目標を明示し、実装順序を指定することで、長い生成セッションでもモデルの出力が安定しやすくなる。

MiniMax-2.5 (229B MoE) Expert Offload 運用と Web 生成検証：IQ5_K から IQ3_S まで

229B級MoEモデル MiniMax-2.5 を EPYC …

Llama-4-Scout-17B-16E実測：CPU Q6_K 17tok/s vs GPU nvfp4 60tok/s、キャッシュ戦略と100kコンテキスト境界

Llama-4-Scout（17B活性/16エキスパート …