ニュース
私たちの実験構成:低価格のRTX 3060で約83.6 GBのモデルをローカル実行
Qwen3.8-Flash-Next IQ3_S、RTX 3060 12 GB、わずか48 GBのシステムRAM。クラウドの推論はありません。手頃な価格の消費者向けハードウェアだけです。

これはすごい!
Qwen3.8-Flash-Next IQ3_S(約83.6 GB)を、システムRAMわずか48 GBの低価格RTX 3060 12 GBでローカル実行!
デコード最大68トークン/秒、プロンプト処理約916トークン/秒、30Kトークンのプロンプトをわずか34秒で処理。
エンジンはcoldnikoのStrata。クラウド推論なし。手頃な一般向けハードウェアだけです!
以下に、完全なベンチマーク、ハードウェア仕様、最適化、およびトレードオフを示します。
これらの結果の背後にあるハードウェア
データセンターGPUなし、高価なマルチGPUサーバーなし、大規模なRAM構成なし。
実験はすべて、ごく一般的なコンシューマー/ワークステーションPCで行いました。

CPU
- Intel Core Ultra 7 265 (Arrow Lake)
- 20コア/20スレッド
- 最大5.3GHz
- 30 MB L3キャッシュ
- AVX-VNNI/BF16サポート、AVX-512なし
マザーボード
- ASUS Pro Q870I-C
- Intel Q870チップセット、LGA1851
- Mini-ITXフォームファクター
メモリ
- 48 GB DDR5-5600 (2 × 24 GB Micron)
- 約46 GiB使用可能
GPU
- NVIDIA GeForce RTX 3060 12 GB
- GA106、計算能力8.6
- PCIe 4.0 ×16
- 電力制限を170 Wに設定
ストレージ
- Lexar NM1090 PRO 2 TB
- PCIe 5.0 ×4 NVMe
OS
- Ubuntu 24.04.5 LTS
- Linuxカーネル7.0.0-38
- NVIDIAドライバ615.71.10
ネットワーク
- Intel 1 GbE Ethernet
重要な詳細:モデルは、利用可能なVRAMとRAMを組み合わせたものよりもはるかに大きいです。
まさにそれがこの実験を面白いものにしています。
モデル、エンジン、メモリアーキテクチャ
モデル
Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S
GGUFシャード2個:
- 54.82 GB
- 28.80 GB
- 合計:83.62 GB(77.87 GiB)
追加コンポーネント
- パック済みの密な重み:約1.5 GiB
- MTP投機的デコード用のドラフター
- BF16ビジョンアダプタ:約866 MB
- CPUベースのビジョンエンコーダ(12スレッド)
推論エンジン
- Strata engine 0.1.52
- CUDA 13.0バックエンド
- CUDAアーキテクチャsm_86
実際のメモリ割り当て
- GPU VRAM:11.14 GiB使用済み
- システムRAMの常駐エキスパート:24 GiB
- NVMeからストリーミングされた残りのエキスパートデータ
- 通常の推論中にスワップアクティビティはありません
重要な構成設定
--expert-cache auto
--prefill 4096
--spec 4
--spec-min-p 0.5
--mtp mtp/rt
--max-context 32768
--kv int8
--kv-grow
--kv-resident 32768
--vision
--vram-reserve-mib 960
--pool-workers 12
--conversation-cache-mib 1536
--prompt-cache-tail
--prompt-cache-spread
--resident-experts
--resident-budget-gib 24
これは従来の「モデル全体をGPUメモリにロードする」設定ではありません。
Strataは、GPUメモリ、システムRAM、エキスパートキャッシュ、NVMeストレージを一緒に使用します。
重要な最適化は、GPUの生産性を維持しながら、高価なエキスパートの移転を最小限に抑えることです。
実際のベンチマーク結果
同じモデル、同じハードウェア、2つのルーティング構成。
モードA:高速、常駐優先のエキスパートルーティング(prior = 1.5)
| コンテキスト | プリフィル | コールドデコード | ウォームデコード |
|---|---|---|---|
| 1K | 285 tok/s | 42 tok/s | 61 tok/s |
| 4K | 804 tok/s | 50 tok/s | 65 tok/s |
| 8K | 819 tok/s | 61 tok/s | 68 tok/s |
| 16K | 916 tok/s | 60 tok/s | 68 tok/s |
| 30K | 890 tok/s | 58 tok/s | 61 tok/s |
最初のトークンまでのコールドタイム:
- 1K: 3.7 s
- 4K: 4.9 s
- 8K: 9.7 s
- 16K: 17.3 s
- 30K: 33.9 s
比較として、モードBでは常駐優先ルーティングを無効にしています(prior = 0):
| コンテキスト | プリフィル | コールドデコード | ウォームデコード |
|---|---|---|---|
| 1K | 282 tok/s | 24 tok/s | 27 tok/s |
| 4K | 781 tok/s | 29 tok/s | 26 tok/s |
| 8K | 789 tok/s | 30 tok/s | 32 tok/s |
| 16K | 889 tok/s | 30 tok/s | 29 tok/s |
| 30K | 878 tok/s | 26 tok/s | 27 tok/s |
500トークン生成の実行:
- 高速:62トークン/秒、合計7.1秒
- 正確:21トークン/秒、合計20.8秒
速度測定は、クライアント側のストリーミングタイミングと照合してクロスチェックされました。
主な観察事項:
キャッシュバイアスルーティングを無効にすると、デコード速度が約2〜2.4倍低下する可能性があります。
しかし、すべてのワークロードに対して積極的なルーティングを有効にしないことには重要な理由があります。詳細については、次のセクションを参照してください。
スピードとモデルの品質:隠されたトレードオフ
このバージョンのStrataエンジンでは、VRAMが13 GB以下のGPUは自動的に常駐優先ルーティングを使用します:
STRATA_ROUTE_PRIOR=1.5
これは、元のルーターが好むエキスパートを常に選択するのではなく、すでに高速メモリで利用可能なエキスパートを優先します。
そのメリットは劇的です。
- エキスパートキャッシュのヒット率:高速モードで97.2%
- バイアスなし:65.3%
- 比較されたワークロード中のストレージ読み取り:5.5 GiB対46 GiB
- デコード速度:約2倍速
ただし、これはタダで得られる最適化ではありません。
エキスパートの選択を変更すると、モデルの動作が変化し、元のモデルからの乖離が増え、長い推論やエージェントのワークフローに影響を与える可能性があります。
10のエージェントタスクに関する開発者の評価によると:
- ルーティングprior 1.5:4.5/10
- ルーティングprior 0:5.6/10
ベースライン結果自体は実行間で異なるため、これは方向性のある結果であり、決定的な品質測定ではありません。
私自身が行った6つの短いエージェントチェックは、両方のモードで合格しました。
ただし、別途行った一意性ストレス実行では繰り返しが発生しました:
- 高速モード:205行、96重複
- 精密モード:209行、79重複
結論は明快です:
- チャット、インタラクティブな使用、短いタスクのための高速ルーティング。
- より長く、品質に配慮したエージェントのワークフローのための元のルーティング。
そして、ベンチマークの速度だけをモデルの品質と混同してはいけません。
プロンプトキャッシュはすべてを変えます
最も印象的な結果の1つは、デコード速度ではありませんでした。同じプロンプトを使用して繰り返し要求した場合の応答時間でした。
完全にキャッシュされたプロンプトを使用する場合:
| コンテキスト | コールドTTFT | キャッシュされたTTFT |
|---|---|---|
| 1K | 3.7 s | 0.08 s |
| 4K | 4.9 s | 0.08 s |
| 8K | 9.7 s | 0.27 s |
| 16K | 17.3 s | 0.34 s |
| 30K | 33.9 s | 0.44 s |
これは、これらの実行で最初のトークンまでの時間を約45〜90倍短縮します。
プロンプトキャッシュは、同じ長いドキュメントを繰り返しクエリしたり、安定したコンテキストで会話を維持したりする場合に大きな違いをもたらします。
エンジンは、会話キャッシュ用にも構成されています。
- 1,536 MiBキャッシュ予算
- パーキングの最小トークン数:4,096
- 最小空きメモリしきい値:1,536 MiB
ただし注意点があります:これらの結果は、キャッシュを完全に再利用できる同一プロンプトの場合です。
新しい任意の30Kトークンのプロンプトが0.5秒で処理されるという意味ではありません。
しかし、インタラクティブなローカルAIにとって、ウォームキャッシュはゲームチェンジャーです。
SSDの謎:PCIe 5.0はボトルネックではありません
最初は、NVMeドライブが疑わしく遅いように見えました。PCIeリンク、ストレージトポロジ、および実際のI/O動作を調査しました。
ドライブ:Lexar NM1090 PRO 2 TB、PCIe 5.0 × 4。
確認済みのPCIe接続:
- 現在のリンク:32.0 GT/s× 4
- 最大リンク:32.0 GT/s× 4
- CPUルートポート:32.0 GT/s× 4
そのため、ドライブは完全なPCIe 5.0リンク速度で動作しています。
キャッシュを介さない直接読み取りベンチマーク:
- シングルストリーム、1〜4 MiBブロック:2.9〜3.4 GB/秒
- 4つの並列ストリーム:10.94 GB/秒
- 4ストリーム、64 KiBブロック:2.25 GB/秒
- 4ストリーム、4 KiBブロック:0.26 GB/秒(〜63K IOPS)
10.94 GB/秒のパラレル結果は特に重要です。これは、PCIe 4.0 × 4の実用的な帯域幅を超えています。
シングルストリームスループットがはるかに低いのはなぜですか?
PCIeの帯域幅はアプリケーションレベルのスループットと同じではないためです。
キューの深さ、I/Oサイズ、要求の並列処理、およびレイテンシはすべて重要です。
Strataのエキスパート読み込みパターンは、合成の最大スループットベンチマークよりも低並行性のケースにはるかに近いです。
観測されたエンジンストレージスループット:
- 高速ルーティング:~0.3 GB/秒
- 元のルーティング:~2.4 GB/秒
違いは、PCIeダウングレードではなく、フェッチする必要があるエキスパートの数にあります。
もう1つの有用な詳細:RTX 3060自体はPCIe 4.0デバイスです。アイドル中にGen1へのリンクがドロップするのを見ることは、通常の電源管理動作です。
PCIeの問題を診断する前に、測定しているデバイスを常に確認してください。
重要な教訓:48 GBのマシンで83.6 GBのモデルをLinuxにキャッシュさせないでください
最初の起動時に深刻な問題に遭遇しました。
最初の構成では、モデルファイルのバッファリングされた読み込みが可能になりました。
モデルは約83.6 GBですが、システムには48 GBの物理RAMしかありません。
そのワークロードの下で、Linuxは深刻なメモリ回収圧力に陥りました。マシンはSSH接続を含むほとんど応答しなくなり、強制的に再起動する必要がありました。
解決策は、ロード戦略を変更し、メモリセーフガードを導入することでした。
現在の設定:
- STRATA_UNBUFFERED_LOAD=1
- STRATA_RESIDENT_HEADROOM_GIB=10
- 常駐エキスパートの予算:24 GiB
- 起動前にメモリの可用性を確認しました
- 起動ポリシーで12 GiBの追加安全マージン
これらの変更後:
- 通常の推論中にスワップアクティビティはありません
- 観測時点のRAM使用量:約34.6 GiB
- 約12.7 GiBが利用可能
- 負荷下でも安定した生成
教訓:
物理メモリよりも大きいモデルを実行することは可能ですが、メモリアカウンティングは絶対に重要です。
ページキャッシュ圧力、ピン留めされたモデルデータ、常駐エキスパート、およびKVキャッシュを一緒に考慮する必要があります。
RAM構成がはるかに大きいマシンから最大性能フラグを盲目的にコピーしないでください。
消費電力、熱、および推論コスト
これはもう一つの楽しい驚きです。
測定されたコンポーネントパワー:
モデル読み込み済みのアイドル時:
- CPU: ~5.8 W
- GPU: 15–18 W
生成中:
- CPU: ~62.8 W
- GPU: 152–167 W
- 短いGPUピークは約174 W
コンセント側でのシステム全体の推定消費電力(電力計による実測ではありません):
- アイドル時:約54 W
- 生成時:約280 W
観測温度:
- 負荷時のGPU:62–68°C
- アイドル時のGPU:約40°C
- NVMe: 38–47°C
サーマルスロットリングは観察されませんでした。
想定電気料金が€0.25/kWhの場合:
- 24時間アイドル:約€0.32
- 30日間連続アイドル:約€9.72
- 1時間のアクティブな生成:約€0.07
これにより、自宅で機能的でプライバシーを保護するローカルAIエンドポイントを操作することが完全に現実的になります。
もちろん、これらは推定電力コストであり、総所有コストではありません。ハードウェアの減価償却費、冷却費、メンテナンス費は含まれていません。
RTX 3060構成が意味をなさなくなるところ
この構成は、短い対話型リクエストに最適ですが、制限があります。
最も重要なのは:
- 最大コンテキスト:32,768トークン
- 32K近いプロンプトでは生成に使える余地が足りない
- 実用的なベンチマーク上限は入力約30,165トークン
- 思考/推論は、生成された何百もの追加のトークンを消費する可能性があります
- 長時間のエージェントセッションはすぐに制約を受ける
比較のために、24 GBのGPUを搭載したより強力なローカルシステムで同じモデルを実行しました。
そのシステムで測定されたパフォーマンス:
- 4Kプロンプトプリフィル:1,339トークン/秒
- 4Kデコード:94トークン/秒
- 16Kプロンプトプリフィル:2,956トークン/秒
- 16Kデコード:125トークン/秒
- 最大コンテキスト:262,144トークン
- ワーカースレッド15本
同等のケースで、RTX 3060システムはプリフィルのスループットがはるかに低く、デコードのスループットは約半分で、利用できるコンテキストは8分の1です。
それでも、12 GBカードははるかに入手しやすく、驚くほど実用的です。
現在のアプローチ:
- 複雑で長時間動作するエージェントのためのより強力なハードウェア
- チャット、短いワークフロー、実験、バックアップ推論用の手頃な価格の12 GB GPU
重要なのは、安価なGPUがハイエンドマシンに取って代わるというふりをすることではありません。
重要なのは、ローカルAIがすでに安価なハードウェア上でどれだけ便利に実行できるかということです。
それでも最適化できる点は何ですか?
システムはすでに良好に動作していますが、さらに実験したい興味深い方向性がいくつかあります。
並行推論
--slots 2オプションにより、2つの同時会話で合計スループットが向上する可能性があります。
このワークロードでは合計スループットが推定+10–12%向上する可能性がありますが、検証が必要です。
これは、単一の会話が12%速くなることを意味するものではありません。
より大きなプレフィルバッチ
現在:--prefill 4096
候補:--prefill auto:16384
プリフィルのウィンドウを大きくすると長いプロンプトの処理が改善する可能性がありますが、使えるVRAMはすでに逼迫しています。
GPUの12 GiBの約11.14 GiBが占有されているため、メモリ動作を慎重に測定する必要があります。
より多くのシステムRAM
--ple-io ramを使うと、より多くのモデルデータをシステムメモリに載せ、ストレージからの読み取りを減らせる可能性があります。
開発者のドキュメンテーションには、次のことが示唆されています。
- プリフィル性能 +16–31%
- デコード性能 +3–11%
ただしこの構成には大幅に多くのRAMが必要で、測定したレイアウトでは約72 GiB以上になります。
現在の48 GB構成では実用的ではありません。
投機的デコード
MTP投機的デコードはすでに有効になっています。
観測された受理率:ドラフト50–60トークンのうち約33–41トークンが受理、つまり約65–70%。
より長いコンテキスト
現在の32Kという上限は運用上の設定による制限であり、モデル自体が32Kしかサポートしないことを示すものではありません。
これを増やすには、メモリ容量、KVキャッシュの動作、レイテンシ、および安定性を再確認する必要があります。
このワークロードでは、高価なエキスパートの読み取りを減らし、アクセスパターンを改善することは、ドライブの最大シーケンシャル帯域幅を増やすことよりも重要になる可能性があります。
いつもの通り、ハードウェアのマーケティング上の数字だけでなく、実際のワークロードでベンチマークしましょう。
まとめ
この実験では次のことを実証しています。
約83.6 GBの量子化MoEモデルは、次の構成でローカル実行できます:
- RTX 3060 12 GB
- 48 GB DDR5 RAM
- 一般向けIntel CPU
- PCIe 5.0 NVMe SSD
- Ubuntu + Strata
測定結果(最大値):
- 68トークン/秒のウォームデコード
- 916トークン/秒のプロンプト処理
- 30Kトークンのコールドプロンプトを約34秒で処理
- 完全にキャッシュされた30Kプロンプト:最初のトークンまで約0.44秒
- 通常の動作条件ではスワップなし
しかし、重要な注意事項があります。
- 設定上の最大コンテキストは32K
- 高速エキスパートルーティングがモデルの動作を変更
- 最高速度は必ずしも最高品質ではありません
- ストレージのパフォーマンスはアクセスパターンによって異なります
- メモリ管理には慎重なチューニングが必要です
- 長時間稼働するエージェントは、より強力なハードウェアの恩恵を受けます
私は特にローカルAIの実用的な経済学に興味があります。
€10,000のシステムでの最大ベンチマークだけでなく、一般向けマシンや約€1,000からの手頃な構成で実際に得られる有用な性能です。
プライバシー、独立性、管理された運用コスト、現実世界の有用性は、印象的なベンチマーク数値だけを追いかけるよりも重要です。
これはまだ進化している実験であり、測定、失敗、構成の変更、および改善を共有し続けます。
ローカルAIの未来は、すでに驚くほど手頃な価格になっています。
後日の追記
そういえば言い忘れていましたが、GPUは先週、ほんの数日前に公開されたNVIDIA Unlockで動作しています。
これで、ロック解除せずに同じベンチマークを実行するようAIエージェントに依頼しましたので、約15〜20分で結果を比較できます。
今日ではありませんが、数日中にこのGPUを$1,000未満のシステムに取り付けて、そこでの性能を確認します。