オンプレLLM／技術記録
前回（実録④）は、中古GPU4枚の機体にVulkanバックエンドで Qwen3-Coder-30B-A3B を載せた話でした。今回はその次です。RTX 3060 12GBが一枚しかない機体で、総パラメータ177Bのモデルを動かします。4bit量子化しても104GB。VRAMには100分の1も入りません。
それでも成立するのは、対象が MoE（Mixture of Experts） だからです。そしてMoE時代のモデル選定は、従来とは見るべき指標が変わります。
GGUFメタデータから構造を確認する
選定の最初にやったのは、配布物のヘッダを読むことでした。llama-cli の print_info が返した値です。
- n_layer = 48
- n_expert = 512
- n_expert_used = 10
- params = 176.94 B
各層に512人の専門家がいて、1トークンあたり10人だけがルーティングされる。これが「総177B／アクティブ3B」の実体です。
ここから2つの帰結が出ます。必要な容量は総パラメータで決まり、生成速度はアクティブパラメータで決まる。両者は独立です。したがって設計は素直に決まります——容量（104GB）は安価なDDR4で賄い、計算が重く容量の小さい共通部（アテンション・埋め込み）だけをVRAMに置く。
結果、実際にVRAMを使ったのは 6.7GB でした。12GBのうち半分以上が余っています。「VRAMが足りないからGPUを買う」という判断が、この構造では成立しないということです。
量子化の選定：128GBという制約が上限を決める
採用したのは unsloth の Dynamic量子化 UD-Q4_K_XL（103.7GiB）。同じリポジトリの他の量子化とサイズを比べると、選択肢は自動的に絞られました。
- UD-Q2_K_XL：73.5GiB（載るが精度を捨てすぎ）
- UD-Q4_K_XL：103.7GiB ← 採用
- UD-Q5_K_XL：147.4GiB（載らない）
- UD-Q6_K_XL：157.5GiB（載らない）
- Q8_0：175.3GiB（載らない）
KVキャッシュとOSの余白を差し引くと、128GBで4bitが上限。ここが「メモリをいくら積むか」の逆算根拠になりました。
ハードウェア側：帯域が天井を決める
機体はThreadripper 1950X（16C/32T）、4ch DDR4-2400の8枚挿しで128GB。理論帯域は 76.8GB/s です。
この世代は1チャネルに2枚挿すとメモリクロックを落とさないと安定しないことが知られており、8枚構成では2133まで落ちる例が珍しくありません。生成速度に直結するため、増設後に dmidecode で実効クロックを確認しました。実測2400 MT/s、8枚とも定格維持。ここが落ちていたら、増設した意味の1割前後を失うところでした。
対抗馬を同じ機体で実測する
候補はもう一つありました。DeepSeek-V4-Flash です。総パラメータは284Bとこちらが大きく、賢さでは有利に見えます。ただ、選定基準は「総量」ではありません。config.json からアクティブ側を計算しました。
(6+1)専門家 × 3行列 × 4096 × 2048 × 43層 ≒ 7.6B——Qwen側の約2.5倍です。
実測にあたっては、DeepSeek側に有利な条件を与えました。128GBに収めるには2bitまで落とす必要がありますが、ビット数が少ないほど1トークンあたりに読むバイト数が減り、速度では得をするからです。
- Qwen3.8-Flash-Next 177B（Q4／103.7GiB）：生成 16.7 tok/s ／ プロンプト処理 131 tok/s
- DeepSeek-V4-Flash 284B（Q2／90.2GiB）：生成 11.0 tok/s ／ プロンプト処理 64 tok/s
2bitという下駄を履かせてなお、生成で1.5倍、プロンプト処理で2倍の差がつきました。アクティブ2.5倍の重さが、量子化の利得を上回った形です。加えてDeepSeekは2bitまで潰す必要があり、精度でも不利になります。
なお DeepSeek-V4-Pro（Q4で791GiB）やV3.2（380GiB）は、この機体では起動すらしません。128GBという制約下では、そもそもFlash系しか土俵に上がれませんでした。
選定基準は、この一行に集約できる
生成速度 ≒ メモリ帯域 ÷（アクティブパラメータ × 量子化後のバイト数／パラメータ）——総パラメータは「載るかどうか」だけを決め、速度には現れません。
賢さのベンチマークだけを見ていたら、別の選択をしていたはずです。手元のハードで動かす前提なら、公開されている config.json から先に割り算をしておく——それが今回の選定でいちばん効きました。
次回は構築編。--n-cpu-moe という比較的新しいオプションと、実測でしか見えなかった3つの罠を書きます。
当社は、お手元の遊休ハードウェアを活用した「社内専用AI基盤」の構築を支援しています。
既存機材の適性診断は無料。買う前に、config.json とメモリ帯域から「動かせるモデルと速度」を計算してお示しします。
お問い合わせフォーム（「社内AI基盤 相談希望」とお書き添えください）／ info@flagship-ai.jp
シリーズ「レガシー to AI 実録」
- 総集編：1台のPCで22システム・24.6万行 ― AI開発3.5ヶ月の実測記録
- 実録①：20年もののJavaを、約1週間でフル刷新
- 実録②：既存コード0行変更で、基幹系に新しい入口を作る
- 実録③：1ヶ月級の構成検討を、プロトタイプ2日＋実測で
- 実録⑤：VRAM 12GBで177Bを動かす、MoE時代のモデル選定
- 実録⑤：VRAM 12GBで177Bを動かす、MoE時代のモデル選定（本記事）
- 実録⑥：同じ機体で速度が3倍、--n-cpu-moe と3つの罠
- 実録⑦：ベンチ16.7・実運用6.6 ― 帯域律速の現実
※本記事の数値は2026年9月時点、Threadripper 1950X / DDR4-2400 4ch 128GB / RTX 3060 12GB / llama.cpp CUDAビルドでの自社実測です。構成により結果は異なります。