概要
この記事は、NVIDIA RTX 4000 SFF Ada Generation 20 GB——外部電源コネクタ不要の 70 W カードで ZimaCube に収まる——が、コンテナ化 llama.cpp サーバーを通じて ZimaOS 1.7.1 上でローカル LLM 推論を実行する実測ベンチマークを記録したものです。20 GB の VRAM が 16 GB の RTX PRO 2000との重要な違いです：モデル本来の 256K コンテキストウィンドウが使えるようになります。
5 ステップのデプロイ手順は ローカル LLM 推論をご覧ください。
TL;DR
| 結論 | 結果 |
|---|---|
| デプロイ | コンテナ化——ghcr.io/ggml-org/llama.cpp:server-cuda、ローカルコンパイル不要 |
| 最適なモデル | Qwen3.6-35B-A3B、unsloth UD-IQ3_XXS（13.21 GB） |
| デコード速度 | 74.5 t/s（Q3_K_S は 83.3 t/s だが 2.3 GB 余計にかかる） |
| コンテキスト | 256K のネイティブコンテキストを達成、KV q4 量子化と併用 |
| MTP 投機的デコード | テストのうえ却下——受け入れ率 62〜72% だがデコードの利得は小さく不安定 |
| 電力 | 70 W の壁で 69.8 W、フル負荷で 83 °C |
一言で言えば：20 GB の VRAM を備えた RTX 4000 SFF Ada は、16 GB ティアと同じ 35B MoE モデルをフルの 256K コンテキストウィンドウで動かします——推奨構成は 14.5 GB に収まり、十分な余裕があります。
テスト環境
| コンポーネント | 仕様 |
|---|---|
| GPU | NVIDIA RTX 4000 SFF Ada Generation、Compute Capability 8.9、20475 MiB |
| デバイス | ZimaCube（互換 PCIe スロット、70 W で外部電源不要） |
| OS | ZimaOS 1.7.1——カード挿入時にドライバー 580.105.08 が自動で有効化 |
| ランタイム | Docker + nvidia-container-toolkit、--gpus all を検証済み |
| エンジン | ghcr.io/ggml-org/llama.cpp:server-cuda（4.3 GB イメージ、sm_80〜120 CUDA カーネル同梱、ローカルビルド不要） |
| モデル形式 | GGUF |
特に断りのない限り、ベンチマークは llama-bench を -p 512 -n 256 -r 3（プロンプト 512 トークン、生成 256 トークン、3 回の平均）で使用します。
ベンチマーク結果
量子化比較（llama-bench、512/256）
量子化の出所がモデルの MTP（次トークン予測）層の有無を決めます：prithivMLmods/...-MTP-GGUF の量子化は MTP を保持し、unsloth/...-GGUF の UD 量子化はそれを除去します（ロード時に model doesn't contain MTP layers と報告されます）。
| 量子化 | サイズ | MTP | デコード t/s | プリフィル t/s | メモ |
|---|---|---|---|---|---|
| Q3_K_S（標準 K-quant） | 15.55 GB | あり | 83.3 | 1692.6 | CUDA カーネルへの適合が最良 |
| IQ3_XXS（unsloth UD） | 13.21 GB | なし | 74.5 | 1771.2 | デコードが 10.6% 遅く、2.3 GB 節約 |
20 GB カードは IQ3_XXS を選ぶべきです：KV q4 で 256K コンテキストのための余地が残ります。Q3_K_S の 15.55 GB は 16 GB カードではロードすらできません。
モデルの選択自体は 16 GB ティアと同じです：Qwen3.6-35B-A3B はこのクラスのカードに収まる最強のモデルで、ハイブリッド MoE アーキテクチャはエージェントとコーディングのシナリオ向けに作られています——帯域幅の完全な分析は RTX PRO 2000のページにあります。本格的なコーディングやナレッジベースのワークロードには、122B / Flash ティアが次のステップで、より大きなカードが必要です。
最適化スイッチ A/B（llama-bench、512/256、3 回の平均）
| 構成 | プリフィル | デコード |
|---|---|---|
| ベースライン（最適化なし） | 1713.3 | 83.7 |
| + flash-attn | 1295.6（−24%） | 84.2 |
| + KV q8 | 1692.6 | 83.3 |
| + ubatch 2048 | 2312.9（+36%） | — |
Flash Attention と長コンテキスト
| プロンプト | プリフィル（fa=on） |
|---|---|
| 4096 | 1691.7 |
| 8192 | 1635.1 |
| 16384 | 1580.8 |
fa=off では 4096 トークンでも failed to create context で失敗します。このモデルでは flash attention が長コンテキストの必須条件です。
256K コンテキストのメモリ計算
| 構成 | 結果 | VRAM |
|---|---|---|
| KV f16 + 256K | メモリ不足 | >20 GB |
| KV q8 + 256K（MTP なし） | 動作 | ~18.35 GB（Q3_K_S）/ 16186 MiB（IQ3_XXS） |
| KV q4 + 256K（MTP なし） | 動作 | 14906 MiB（IQ3_XXS） |
| KV q4 + 256K + MTP | 動作（Q3_K_S） | 18894 MiB |
MTP 投機的デコード
| 測定項目 | 結果 |
|---|---|
| 実際の受け入れ率（サーバーログ） | 62〜72% |
| デコード利得、自然な短い返信 | +3.9% |
| デコード利得、固定 256 トークン、temp=0.8 | +26.1% |
| デコード利得、貪欲 temp=0 | −10.1% |
MTP は 20 GB ティアでは却下です：受け入れ率は高いものの、デコードは帯域幅でロックされており——MoE モデルはトークンごとに約 3B のアクティブエキスパートを読まざるを得ません。利得は小さく不安定なので、MTP はスキップが推奨です。
エージェントワークロード：長コンテキストでの DeepSeek Harness
実際の DeepSeek Harness エージェントセッションをワークロードとして測定：
| 総コンテキスト | デコード t/s |
|---|---|
| 76K | 39.2 |
| 101K | 33.0 |
コンテキストが大きくなるとデコードは遅くなります（KV の読み取りが増え、アテンションも増えるため）。これは長コンテキストの固有コストであり、欠陥ではありません——オーバーフローもトランケーションもありません。約 100K のコンテキストでも、約 33 t/s はストリーミングエージェントにとって依然として流暢です。DeepSeek Harness や Codex スタイルのコーディングエージェントにとって、この 256K ウィンドウこそが 16 GB ティアではなくこのカードを選ぶ理由です。
消費電力と温度（フル負荷）
| 項目 | 値 |
|---|---|
| 消費電力 | 69.8 W（70 W 制限いっぱい） |
| 温度 | 83 °C（正常。スロットリング閾値は約 90 °C+） |
| 使用率 | 96〜100% |
| 電力制限の調整可否 | 調整不可（-pl は拒否され exit 4） |
なぜここでは MTP が効かないのか
16 GB の RTX PRO 2000では、デコードはメモリ帯域幅で約 65〜70 t/s に制限されます。4000 SFF Ada は帯域幅が大きく（320 GB/s）、デコードは 74〜83 t/s に上がります——しかし同じ MoE の帯域幅ロジックは依然として成立します：トークンごとに約 3B のアクティブエキスパートを読む必要があります。MTP はその上にドラフトモデルを追加し、62〜72% の受け入れ率では、自然なテキストでの実利得は数パーセントで、貪欲サンプリングではマイナスです。メモリは KV q4 と 256K ウィンドウに使う方が価値があります。
推奨構成（20 GB ティア）
| 項目 | 値 |
|---|---|
| 量子化 | Qwen3.6-35B-A3B UD-IQ3_XXS（13.21 GB） |
| Flash attention | オン |
| KV キャッシュ | q4_0 |
| コンテキスト | 256K |
| ubatch | 2048 |
| MTP | スキップ |
| VRAM | 14906 MiB（14.56 GB、約 5.5 GB の余裕） |
1 コマンドでサーバーを起動します：
docker run -d --name llm-server --gpus all -p 8080:8080 \ |
サービスは http://<host-ip>:8080/v1 で OpenAI 互換エンドポイントを公開します（API key はプレースホルダーで、サーバーは認証しません）。OpenAI 形式のクライアントやエージェントならどれでも直接接続できます。
ティア比較
| ティア | 組み合わせ | VRAM |
|---|---|---|
| 20 GB | IQ3_XXS + 256K + KV q4 | 14.5 GB |
| 20 GB | Q3_K_S + 256K + KV q4 + MTP | 18.45 GB（タイト） |
| 16 GB | IQ3_XXS + 128K + KV q4 | 約 14 GB（Q3_K_S はロード時に OOM） |
制限事項
- MTP のデータポイントと長コンテキストの減衰は単一サンプルです。分散は厳密には評価していません。最適化マトリクス（A/B 表）は 3 回の平均です。
- ハードウェアで検証したのは 20 GB 単一カードティアのみです。16/24/32 GB ティアは理論上の互換マトリクスに従い、本測定の対象外です。
- NVFP4（Blackwell のみ）、EAGLE、電力制限の調整はこのカードでは利用できず、テストに含めていません。