概要
この記事は、ZimaCube Creator の公式 GPU オプションである NVIDIA RTX PRO 2000 Blackwell 16 GB が、ZimaOS 1.7.1 上でローカル LLM 推論を実行する実測ベンチマークを記録したものです。合成ベンチマーク、実会話の生成、長コンテキストの検証、消費電力をカバーし、最後に推奨モデルとデプロイ構成を示します。
5 ステップのデプロイ手順は ローカル LLM 推論をご覧ください。物理的な取り付けは GPU 拡張をご覧ください。
TL;DR
| 結論 | 結果 |
|---|---|
| ローカル LLM を動かせるか | はい——CUDA 13.0 / Compute Capability 12.0 を完全サポート |
| 最適なモデル | Qwen3.6-35B-A3B(IQ3_XXS 量子化) |
| デコード速度 | 約 65〜70 tokens/s |
| 長コンテキスト | 64K は安定、128K は実用可能 |
| 27B 密モデルとの比較 | わずか 18〜23 t/s——MoE モデルは約 3.5 倍高速 |
| 真のボトルネック | コンピュートでも電力でもなく、16 GB の VRAM |
一言で言えば:RTX PRO 2000 はローカルエージェント推論に最適な 16 GB カードの 1 つです——70 W、Blackwell アーキテクチャ、そして MoE モデルなら同フットプリントの密モデルより数倍速くデコードします。
テスト環境
ハードウェア
| コンポーネント | 仕様 |
|---|---|
| デバイス | ZimaCube NAS(第一世代エントリーモデル、ZimaOS 公式ハードウェア) |
| OS | ZimaOS 1.7.1 |
| CPU | Intel N100(4 コア、0.7〜3.4 GHz) |
| メモリ | 16 GB(約 15 GB 使用可能)+ 5.2 GB スワップ |
| GPU | NVIDIA RTX PRO 2000 Blackwell |
| VRAM | 16 GB GDDR7 |
| CUDA | 13.0、ドライバー 580.105.08——カード挿入時に ZimaOS 1.7.1 が自動で有効化 |
| Compute capability | 12.0(sm_120、Blackwell) |
| 電力制限 | 70 W |
これは GPU が強く CPU が弱いデバイスです。N100 は低電力の効率コアなので、すべてのモデルを VRAM に完全に収める必要があります。推論が CPU に溢れた瞬間、速度は崩壊します。
テストしたデバイスは第一世代のエントリー ZimaCube です。ZimaCube 2 では、より強力な CPU は結果を改善するだけです——カードが同一なので GPU 側の数値は変わりません。
ソフトウェア
| ソフトウェア | バージョン / メモ |
|---|---|
| 推論エンジン | llama.cpp(CUDA sm_120 バックエンドでソースからビルド。ビルドには CUDA 12.8 を使用——13.1 には既知の MMQ カーネル問題があります) |
| サーバー | llama-server(OpenAI 互換 API) |
| モデル形式 | GGUF(Unsloth Dynamic 量子化を含む) |
RTX PRO 2000 は Blackwell カード(sm_120)です。新しい CUDA ランタイムと推論バックエンドが必要で——古いビルド済み llama.cpp リリースはこのカードを認識しないことがあります。
テスト方法
- 合成ベンチマーク:
llama-benchでフル GPU オフロード(-ngl 99)、プロンプト処理(512/2048 tokens)とトークン生成(128/512 tokens)をテスト。 - 実生成:
llama-cli、--temp 0.7、単一ターンモード、固定乱数シード、実際の中国語の質問応答。 - マルチターンと長コンテキスト:OpenAI 互換の llama-server API を通じたマルチターン会話と干し草の山から針を探す検索。
- コンテキスト容量:モデルを 64K / 128K コンテキストでロードし、VRAM 使用量を測定。
テスト対象モデル
| モデル | アーキテクチャ | 総パラメータ | アクティブパラメータ | 量子化 | サイズ |
|---|---|---|---|---|---|
| Qwen3.8-27B | 密 | 27.3B | 27.3B(すべてアクティブ) | Q3_K_XL / Q2_K_XL / IQ2_XXS | 8.4〜12.5 GiB |
| Qwen3.6-35B-A3B | ハイブリッド MoE | 34.7B | 約 3B | IQ3_XXS / Q2_K_XL | 11.4〜12.3 GiB |
Qwen3.6-35B-A3B はハイブリッドアーキテクチャです:フルアテンション層 10 層と SSM(Mamba)+ MoE 層 30 層、256 のエキスパートのうちトークンごとに 8 個がアクティブになります。エージェントとコーディングのシナリオを狙ったモデルです。
ベンチマーク結果
合成ベンチマーク(llama-bench、フル GPU オフロード、tokens/s)
| モデル(量子化) | サイズ | プリフィル pp2048 | デコード tg512 |
|---|---|---|---|
| Qwen3.8-27B Q3_K_XL | 12.51 GiB | 670 | 17.9 |
| Qwen3.8-27B Q2_K_XL | 9.93 GiB | 670 | 20.7 |
| Qwen3.8-27B IQ2_XXS | 8.38 GiB | 570 | 23.1 |
| Qwen3.6-35B-A3B IQ3_XXS | 12.29 GiB | 1490 | 68.1 |
| Qwen3.6-35B-A3B Q2_K_XL | 11.44 GiB | 1564 | 74.4 |
実生成(llama-cli、–temp 0.7、中国語の質問応答)
| 量子化 | 生成速度 |
|---|---|
| IQ3_XXS | 64.7 t/s |
| Q2_K_XL | 70.3 t/s |
マルチターンと長コンテキストの検証
| テスト | 結果 |
|---|---|
| マルチターンのコンテキスト保持 | 合格——ターン 2 で以前の情報を正しく想起 |
| 干し草の山から針を探す検索 | 合格——以前の内容を検索できた |
| 繰り返し呼び出しの安定性 | 合格——約 63 t/s で安定 |
エージェントワークロードへの適合性
Qwen3.6-35B-A3B のハイブリッドアーキテクチャはエージェントとコーディングのシナリオを狙っており、測定結果もそれを裏付けています:マルチターンのコンテキスト保持と干し草の山から針を探す検索はどちらも合格し、繰り返し呼び出しは約 63 t/s で安定します。DeepSeek Harness や Codex スタイルのコーディングエージェントにとって、これは流暢なインタラクティブ速度であり、35B の総パラメータが小さな密モデルにはない推論力とコーディング能力をもたらします。
この 16 GB カードでの制約はコンテキストです。エージェントの会話は成長し、64K は快適でも 128K はタイトです。エージェントワークロードがモデル本来の 256K ウィンドウを必要とするなら、20 GB の RTX 4000 SFF Adaが KV q4 量子化でそれを実現します。
MoE モデルが密な 27B より 3.5 倍速い理由
これは今回のテストで最も価値のある発見です。
- 密モデルは生成するトークンごとに 27B の重みをすべて読み込むため、デコード速度はメモリ帯域幅で頭打ちになります。実測の有効デコード帯域幅は約 224 GiB/s で、27B モデルは 18〜23 t/s に留まります。
- MoE モデルはトークンごとに 256 のエキスパートのうち 8 個(約 3B パラメータ)しかアクティブにしないため、読む重みが 1 桁少なく、帯域幅のボトルネックを回避します。これが 65〜70 t/s に到達できる理由です。
VRAM が限られたデバイスでは、MoE がパラメータ容量とデコード速度を同時に得る最善の方法です。
VRAM が唯一のハードリミット
- 35B-A3B の IQ3_XXS 量子化はわずか 12.3 GiB で、16 GB に約 2.4 GB の余裕が残ります。
- より高い量子化(Q4 は約 19〜20 GB)やより大きなモデルは 16 GB を超えます。CPU オフロードが始まると、N100 が速度を使い物にならない水準まで引きずり下ろします。
- 「16 GB に収まる最強の MoE」がこのデバイスの性能上限です。
消費電力
フル生成負荷で実測したところ、カードは約 55〜70 W(70 W 制限内で上限に張り付き)、アイドル時は 6〜12 W です。24/7 稼働の NAS としては優れた効率です。
コンテキスト容量
| コンテキスト | VRAM 使用量 | 余裕 | 判定 |
|---|---|---|---|
| 64K | 13.5 GB | 2.4 GB | 快適、推奨 |
| 128K | 14.8 GB | 1.1 GB | 実用可能、タイト |
| ~150K | ~15.6 GB | ~0.3 GB | 理論上の限界 |
| 256K(モデル本来) | >16 GB | — | 収まらない |
コンテキストのオーバーヘッドはごく小さく(1K トークンあたり約 22 MiB)、KV キャッシュが必要なのは 10 のアテンション層だけです。SSM 層は一定の状態を保ちます。
結論と推奨
最適なモデル
推奨:Qwen3.6-35B-A3B(IQ3_XXS 量子化、3.06 bpw)
- 16 GB の VRAM に完全に収まる最大かつ最強のモデルです。
- 約 65 t/s のデコード——27B 密モデルの 3.5 倍——は流暢なエージェント体験に十分です。
- 35B の総パラメータは、同フットプリントのどの密モデルよりもはるかに多くの知識、推論力、コーディング能力をもたらします。
- IQ3_XXS は品質と速度のスイートスポットです。Q2_K_XL は約 8% 速いですが、2 ビットの品質低下はより目立ちます。
16 GB カードでは、これがこのティアの上限です。本格的なコーディングやナレッジベースのワークロードには、122B / Flash ティアが次のステップです——16 GB には収まらず、より大きなカードが必要です。
使用上の注意
- サンプリングは 0.6〜0.7 で、貪欲(temp=0)は決して使わない。 貪欲サンプリングではこの推論モデルが無限の繰り返しに退化します。
- これは推論モデルです。 回答の前に思考の連鎖を出力し、思考トークンは上限にカウントされます。
max_tokensは 2048 以上に保ってください。そうしないと思考の途中で回答が切れます。 - レスポンスフィールド。 最終回答は
content、推論のトレースはreasoning_content(DeepSeek と同じ拡張フィールド)に入ります。
ユースケース
- ローカルエージェント:コーディング、タスクオーケストレーション、ツール呼び出し
- NAS 上のプライベート AI アシスタントと RAG ナレッジベースの質問応答
- 低電力・常時稼働のローカル推論
- 不向き:128K を超えるコンテキスト、または高量子化の大型モデル
デプロイ(OpenAI 互換サーバー)
デプロイガイドと同じコンテナ化サーバーを使用します——コンパイル不要で、イメージには sm_120 までの CUDA カーネルが同梱されています:
docker run -d --name llm-server --gpus all -p 8080:8080 \ |
サーバーは OpenAI 互換 API を公開し、主要なエージェントフレームワーク(OpenAI SDK など)から直接呼び出せます:
from openai import OpenAI |
付録:検証済み GPU プロファイル
NVIDIA RTX PRO 2000 Blackwell |