【RTX 3090 爆速LLMシリーズ Vol.1】Qwen3.6-35B-A3B を 100〜140 t/s で動かす完全ガイド｜AMD AI MAX+ 395 ハイブリッド構成

はじめに：このシリーズについて

ローカルでLLMを動かすとき、「24GB VRAM」のRTX 3090は2026年現在でも最強コスパクラスのままです。RTX 4090 や 5090 と比べても、MoE（Mixture of Experts）モデルでは事実上ほぼ同等の速度が出ます。

※RTX 3090 24GBなら15-20万ぐらいで中古で手に入れることができるため。
コマンドが通る通らないなどあるため全部実機でテストしています。

このシリーズでは、私の手元PC（AMD Ryzen AI MAX+ 395 + RTX 3090 24GB）で実測しながら、ローカルLLM爆速化のレシピをVol.1〜Vol.3で公開していきます。

「RTX 3090 持ってるけど活かしきれてない」「AMD AI MAX+ 395 を買ったけどNVIDIA併用の最適解が分からない」という方に向けて、コピペで動く設定 + 実測値を中心に書きます。

検証環境

ハードウェア構成は次の通り。

ポイントは「RTX 3090 単独でも MoE 35B クラスまでは余裕」「AMD iGPU は Vol.3 でハイブリッド推論用に温存」という分業設計にしていることです。今回（Vol.1）は RTX 3090 シングル GPU に焦点を絞ります。

なぜ Qwen3.6-35B-A3B なのか

Qwen3.6-35B-A3B は 総パラメータ 35B / アクティブ 3B（A3B） の MoE モデル。

• 総パラメータ 35B だが、推論時にアクティブになるのは 3B 相当

• そのため VRAM 24GB に Q5_K_M でフィットしつつ、3B 推論レベルの速度 が出る

• 35B クラスの知識量・コーディング能力をそのまま享受できる

「24GB に乗る最高品質」と「3B 級の速さ」を両取りできる、RTX 3090 にとって理想のモデル構成です。

セットアップ手順

1. llama.cpp を最新版でビルド

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

# CUDA + Flash Attention 有効でビルド
cmake -B build -DGGML_CUDA=ON -DGGML_CUDA_FA_ALL_QUANTS=ON
cmake --build build --config Release -j$(nproc)

2. Qwen3.6-35B-A3B GGUF をダウンロード

Unsloth 版がメンテナンスされていて品質も安定しているのでおすすめ。

# Q5_K_M 推奨（品質と速度のバランスがベスト）
hf download \
  unsloth/Qwen3.6-35B-A3B-GGUF \
  Qwen3.6-35B-A3B-UD-Q5_K_M.gguf \
  --local-dir ~/models/

VRAM が厳しいときは Q4_K_M か IQ4_NL を選択。

3. RTX 3090 専用おすすめ起動コマンド

⚠️ Q5_K_M は 24GB VRAM に物理的に収まりません

ここは私自身が痛い目を見て初めて気づいたポイントです。Unsloth UD版 Qwen3.6-35B-A3B のサイズ感は次の通り：

Unsloth UD GGUF 版の実ファイルサイズ（2026年5月時点）と、24GB VRAM へのフィット可否は次の通り。

実際にQ5_K_Mで起動を試みると、こんなOOMで落ちます：

ggml_backend_cuda_buffer_type_alloc_buffer: allocating 24704.80 MiB on device 0:
  cudaMalloc failed: out of memory

24,704 MiB（重みだけ） > 24,576 MiB（RTX 3090 物理VRAM）なので、コンテキストサイズを 0 にしても物理的に入りません。フルGPUで載せたいなら Q4_K_M 一択です。

おすすめパターンA：Q4_K_M フルGPU（推奨・本命）

131k context まで余裕で確保できる、24GB VRAM の正解構成。

# モデルダウンロード（未取得なら）
hf download \
  unsloth/Qwen3.6-35B-A3B-GGUF \
  Qwen3.6-35B-A3B-UD-Q4_K_M.gguf \
  --local-dir ~/llm/models/gguf/Qwen3.6-35B-A3B/

# 起動
~/llm/apps/llama.cpp/build/bin/llama-server \
  --model ~/llm/models/gguf/Qwen3.6-35B-A3B/Qwen3.6-35B-A3B-UD-Q4_K_M.gguf \
  --port 8001 \
  --alias qwen3.6-35b-a3b \
  -c 131072 \
  -n 32768 \
  --no-context-shift \
  --temp 0.6 --top-p 0.95 --top-k 20 \
  --repeat-penalty 1.00 \
  -ngl 999 \
  -fa on \
  -ctk q8_0 -ctv q8_0 \
  -np 1 \
  --batch-size 2048 \
  --ubatch-size 1024 \
  --chat-template-kwargs '{"preserve_thinking": true}'

MoE モデルでは Q5 と Q4 の品質差は実用上ほぼ感じません。131k context が確保できるメリットの方が圧倒的に大きいです。

おすすめパターンB：Q5_K_M + Expert Offload（品質最優先）

「どうしてもQ5の品質を取りたい」人向け。--n-cpu-moe で一部 Expert を CPU に逃がします。

~/llm/apps/llama.cpp/build/bin/llama-server \
  --model ~/llm/models/gguf/Qwen3.6-35B-A3B/Qwen3.6-35B-A3B-UD-Q5_K_M.gguf \
  --port 8001 \
  --alias qwen3.6-35b-a3b \
  -c 65536 \
  -n 16384 \
  --no-context-shift \
  --temp 0.6 --top-p 0.95 --top-k 20 \
  -fa on \
  -ctk q8_0 -ctv q8_0 \
  --n-cpu-moe 4 \
  -np 1 \
  --batch-size 2048 \
  --ubatch-size 1024

ポイント：

• -ngl 999 は付けない（付けると再びOOM）

• --n-cpu-moe 4 で Expert 4層をCPUへ。VRAMが約1〜2GB浮く

• 数値は nvidia-smi でVRAM空きを見ながら 4 → 8 → 16 と調整

• 速度はパターンAより15〜25%程度落ちるが、Q5の品質を維持

RTX 3090 で効くポイント

• -ngl 999：全レイヤーをGPUに完全オフロード。24GB に余裕で載るので CPU Expert offload（-ncmoe）は 不要

• -fa on：Flash Attention 有効化。Ampere（sm_86）は完全対応なので必ずON

• -ctk q8_0 -ctv q8_0：KVキャッシュ量子化を Q8_0 で確保。長文 262k まで使う場合は q4_0 まで落としても品質劣化はわずか

• Speculative Decoding（--spec-type 系）はオフ推奨：3090 では逆効果になる報告が多い（Vol.2 の DFlash で扱う方式は別物）

コミュニティ実測値（参考値）

Reddit r/LocalLLaMA、X、HF Discussion での 2026年5月時点の報告を整理した参考値です。

参考までに RTX 4090 は同条件で 130〜170 t/s 前後との報告。3090 は約 80〜85% の速度を半額以下で出している計算で、コスパは依然として圧倒的です。

自分の実測値

実際にRTX 3090（VRAM 24,126 MiB / Driver 595.58.03 / CUDA 13.2 / llama.cpp build 9008）で計測した数値です。

llama-bench 結果一覧（量子化 × コンテキスト長）

~/llm/apps/llama.cpp/build/bin/llama-bench を -ngl 999 -fa 1 -ctk q8_0 -ctv q8_0 共通設定で実行。

Q4_K_M（標準推奨構成）

IQ4_NL（新発見・実質最強構成）

262k context まで設定可能で、ファイルサイズはQ4_K_Mの18GB / 22.1GB と小さいのに速度はQ4_K_Mを超える。

Q5_K_M + --n-cpu-moe 10（Expert Offload）

テストプロンプト処理 (PP)生成速度 (TG)Q4_K_M 比pp512 / tg256598.13 ± 5.21 t/s105.05 ± 3.49 t/sTG -29% / PP -83%

VRAM内訳（メモリブレークダウン）：

CUDA0 (RTX 3090): 24,126 = 2,991 free + (20,813 used:
                  19,084 model + 742 context + 986 compute) + 320 unaccounted
Host:             6,781 = 6,509 model + 0 + 272

→ MoE Expert 約 6.5 GB が CPU に退避。動作はするが、PP 速度の大幅低下が致命的。

重要な発見：量子化選択の優先順位

このシリーズで最も価値ある知見の1つ。24GB VRAM環境では「IQ4_NL > Q4_K_M >> Q5_K_M + offload」。

IQ4_NLが「容量小・速度同等以上・最大contextも2倍」。コミュニティでは「IQ系は遅い」と言われがちですが、最新 llama.cpp + RTX 3090 + 595系ドライバ + CUDA 13.2の組み合わせでは逆転しています。Q5_K_M を Expert Offload で頑張るより、IQ4_NL に切り替えた方が圧倒的に幸せ。

読み解き（共通）

• TG が 16k context でもほぼ無減速（148.64 → 147.52）。Flash Attention + KV q8_0 が理想動作している証拠

• PP速度は 3,500 → 3,150 で長コンテキストでも 90% 以上維持

• 標準偏差が ±0.10〜0.33 と小さく、測定の再現性が極めて高い

• コミュニティ実測値 120〜140 t/s を恒常的に超過

実 API 呼び出しでの計測（curl + llama-server）

curl -s http://127.0.0.1:8001/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.6-35b-a3b",
    "messages": [
      {"role": "user", "content": "Pythonでフィボナッチ数列の100番目を求める関数を書いて"}
    ],
    "max_tokens": 512
  }' | jq '.usage, .timings'

結果（27 tok prompt, 512 tok output）：

llama-bench の純粋な数値より若干低いのは、HTTP/JSONオーバーヘッド + チャットテンプレート整形分。実用ユースケースでも 145 t/s 出ている事実が重要。

電力リミット 320W テスト結果

320W で速度低下はわずか 2% 程度。これは重要な発見です。

電力モニタリング（nvidia-smi dmon -s pu 60秒間）

推論中ピーク：        318-319 W （320W リミットに張り付き = 制限が完璧に効いてる）
GPU 使用率：          99-100%
温度：                65-68°C （350W時より明確に低い）
GPU メモリ転送率：    57-59%
アイドル時：          78-150 W

結論：320W は "Sweet Spot"

• わずか 2% の速度低下で 9% の電力削減

• 温度 65-68°C は非常に余裕（350W なら 70-75°C）

• 発熱・騒音・PSU 余裕が大きく改善

• 24時間運用やサーバー化なら 320W 常用が正解

• ベンチや短時間バーストなら 350W で OK

Persistence Mode は必須

sudo nvidia-smi -pl 320 だけだと、Persistence Mode が無効な環境では即座に 350W に戻ってしまいます。先に sudo nvidia-smi -pm 1 で Persistence Mode を有効化してから設定するのが正解。

sudo nvidia-smi -pm 1   # 永続化を有効に（先に必須）
sudo nvidia-smi -pl 320 # 電力リミット設定
nvidia-smi --query-gpu=persistence_mode,power.limit --format=csv  # 確認

systemd で起動時に自動設定したい場合：

sudo tee /etc/systemd/system/nvidia-power-limit.service > /dev/null <<'EOF'
[Unit]
Description=NVIDIA GPU Power Limit
After=nvidia-persistenced.service

[Service]
Type=oneshot
ExecStartPre=/usr/bin/nvidia-smi -pm 1
ExecStart=/usr/bin/nvidia-smi -pl 320
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl enable --now nvidia-power-limit.service

Speculative Decoding 実測：受理率95%でも -30% という衝撃

draft モデル Qwen3.5-0.8B（vocab 248320 で Qwen3.6 と互換）を組み合わせて4種類のタスクで計測：

衝撃の発見：受理率95.7%でも -30%遅い

A1 のフィボナッチ生成では 受理率 95.7% という驚異的な数値を達成。それでも TG は 104.85 t/s（baseline 149.81 から -30%）。

つまり原因は draft の精度不足ではなく、MoE構造そのもの。

理論との完全一致

これは thc1006 の先行ベンチ や llama.cpp Discussion #22473 でも報告されており、私の実測と完全に一致します。

結論：A3B MoE では Speculative Decoding を使うな

• 受理率 60〜96% と大きく変動しても、TG速度は約 100 t/s 台で頭打ち

• 高受理率でも MoE Expert ロードコストで30%遅くなる構造的問題

• 使わないのが正解（IQ4_NL を素のまま使うのが最速）

A3B MoE で speculative decoding 系を使うべきは DFlash のような MoE 専用に再設計された方式のみ（Vol.2 で詳述予定）。

全テスト完了サマリー

数値を取り次第、表を更新します。

再現したい方へ

# 標準ベンチ
~/llm/apps/llama.cpp/build/bin/llama-bench \
  -m ~/llm/models/gguf/Qwen3.6-35B-A3B/Qwen3.6-35B-A3B-UD-Q4_K_M.gguf \
  -ngl 999 -fa 1 -ctk q8_0 -ctv q8_0 \
  -p 512 -n 256

p を 4096 / 16384 に変えればコンテキスト別の数値が取れます。実測値を投稿したら X で #RTX3090爆速LLM ハッシュタグ付けて教えていただければ、記事の比較表に追記していきます。

計測コマンド（自分用メモ＋読者用）

# llama-bench で素の生成速度を測る
~/llama.cpp/build/bin/llama-bench \
  -m ~/models/Qwen3.6-35B-A3B-UD-Q5_K_M.gguf \
  -ngl 999 -fa 1 \
  -p 512 -n 256 \
  -ctk q8_0 -ctv q8_0

実測値を投稿したら X で #RTX3090爆速LLM ハッシュタグ付けて教えていただければ、記事の比較表に追記していきます。

ハマりどころ

1. KVキャッシュ量子化が効かない

-ctk -ctv オプションは llama.cpp ビルド時に -DGGML_CUDA_FA_ALL_QUANTS=ON が必要です。これを忘れると Q8_0 / Q4_0 KV が無効になり、速度がガクッと落ちます。

2. ドライバとCUDAのバージョン不一致

NVIDIAドライバ 555 系以降（理想は 595+ で CUDA 13 対応）が必須。古い 535 系のままだと llama.cpp 側が新しい CUDA ランタイムでビルドされている場合に：

ggml_cuda_init: failed to initialize CUDA: CUDA driver version is insufficient for CUDA runtime version
warning: no usable GPU found, --gpu-layers option will be ignored

というエラーで GPU が認識されません。

# 確認
nvidia-smi          # Driver 555+ / CUDA 12.5+ を確認（理想は595+ / CUDA 13）

# Ubuntu でアップグレード例
sudo apt update
sudo apt install nvidia-driver-595   # または最新版
sudo reboot

ドライバを上げたくない場合は、llama.cpp を現在のCUDAツールキットで再ビルドします：

cd ~/llm/apps/llama.cpp
rm -rf build
cmake -B build \
  -DGGML_CUDA=ON \
  -DCMAKE_CUDA_ARCHITECTURES=86 \
  -DGGML_CUDA_FA_ALL_QUANTS=ON
cmake --build build --config Release -j$(nproc)

-DCMAKE_CUDA_ARCHITECTURES=86 で RTX 3090（Ampere, sm_86）専用にするとビルドも速く、無駄なカーネルも消えます。

3. PCIe帯域がボトルネック

PCIe 3.0 x8 接続だと、長コンテキスト時のスループットが落ちる場合があります。BIOSで PCIe 4.0 x16 が有効になっているか確認しましょう。

4. 電力制限：320W が Sweet Spot

RTX 3090 は TDP 350W ですが、実測で 320W リミットなら速度低下わずか 2%（後述「自分の実測値」参照）。発熱・騒音・PSU余裕が大幅改善されるので、常用は 320W、ベンチや短時間バーストは 350W の使い分けが正解。

ただし nvidia-smi -pl だけでは Persistence Mode が無効な環境で設定が即リセットされる罠があるので、先に Persistence Mode を有効化してください：

sudo nvidia-smi -pm 1    # ① Persistence Mode を有効化（先に必須）
sudo nvidia-smi -pl 320  # ② 320W にリミット
nvidia-smi --query-gpu=persistence_mode,power.limit --format=csv  # 確認

番外編：VRAM 12GB でも MoE なら諦めなくていい

「RTX 3090 持ってないから無理…」と思った方、実はQwen3.6-35B-A3B は VRAM 12GB クラスでも十分実用速度で動きます。MoE モデルの構造上の特性のおかげです。

なぜ MoE は低VRAMでも速いのか

Qwen3.6-35B-A3B は 総パラメータ 35B / アクティブ 3B（A3B） の MoE。前述の通り、1トークン推論ごとに使われるのは "アクティブな 3B 分のExpert" だけです。

つまり：

• アクティブな部分（Attention + 一部Expert）だけGPUに置く

• 残りの非アクティブ Expert は CPU/システムメモリに退避

• ルーターが「次はこのExpertを使う」と判断したときだけ、必要分をGPUに引き上げる

この戦略を Expert Offload（CPU MoE Offload）と呼びます。Dense モデル（Llama 3 70B など）では同じことをすると激遅になりますが、MoE では active 3B 部分の演算が GPU で高速に回るので、CPU側の通信オーバーヘッドが相対的に小さく済むわけです。

まとめと次回予告

RTX 3090 + Qwen3.6-35B-A3B の組み合わせは、**2026年5月時点で「24GB単体GPUで動く最強実用構成」**と言って差し支えないバランスです。

要点を8つに絞ると：

1. 24GB VRAM の事実上の最強構成は IQ4_NL（149.81 t/s + 262k context、Q4_K_M を全面で上回る）

2. Q4_K_M も互角で安定（148.64 t/s、131k context）。IQ4が苦手な環境ではこちら

3. Q5_K_M は重みだけで24GB超え、Expert Offload しても TG -29% / PP -83% で実用性が大きく落ちる

4. -ngl 999 + -fa on + -ctk/-ctv q8_0 の3点セットを忘れない

5. OOM 対策の優先順位：context↓ → KVキャッシュ量子化↓ → --n-cpu-moe 投入

6. 電力リミット 320W が Sweet Spot：速度 -2% で電力 -9%、発熱・騒音改善（常用おすすめ）

7. Speculative Decoding は使うな：受理率 95.7% でも -30%。MoE Expert ロードのオーバーヘッドが先読みの節約を上回る構造的問題

次回 Vol.2 では、同じRTX 3090で27Bモデルを 130 t/s 超え にする Luce DFlash の構築・ベンチ手順を扱います。スタンドアロン C++/CUDA 実装で llama.cpp とは別系統、Speculative Decoding をGGUF対応に移植したという面白い構成です。

Vol.3 では本命の AMD AI MAX+ 395 + RTX 3090 ハイブリッド推論。iGPU / NPU を遊ばせず、長文プロンプト処理で並列分担させる構成を検証します。

シリーズで追っていただけるとありがたいです。コメント・質問・「ウチの環境ではこうだった」報告も大歓迎。

参考資料

• Unsloth Qwen3.6-35B-A3B-GGUF（Hugging Face）

• llama.cpp 公式リポジトリ

• Reddit r/LocalLLaMA（コミュニティ実測値の主な情報源）

計測条件・パラメータの最適値は llama.cpp のバージョンで微妙に変動します。本記事は 2026年5月時点の情報です。