【要約】コンシューマー機2台をRPCでつないで96GB相当のVRAMを作り、6つのオープンLLMを実測してみた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
個人開発者や小規模チームが、大規模なLLMを動かすためのVRAM確保において、コストと性能のジレンマに直面している。プロ向けGPUは極めて高価であり、手が出しにくいのが現状である。具体的には以下の課題が挙げられる。
- ・高価なプロ向けGPU（VRAM 96GB等）の導入コスト。
- ・複数マシン構成におけるネットワーク通信帯域の不足。
- ・--tensor-split設定ミスによる、意図しないGPUへの負荷集中。
- ・プロセス終了後に残留するVRAMによる、リソース不足の発生。
// Approach
筆者は、安価なコンシューマー向けGPUを複数台組み合わせ、RPC経由でVRAMを統合する構成を採用した。ネットワークの帯域制限を前提とした、現実的な回避策を模索している。具体的な手法は以下の通りである。
- ・2台のマシンをCAT6Aケーブルで直結し、5Gbpsの帯域を確保。
- ・llama.cppのRPCサービスを利用し、モデルを層単位で分割ロード。
- ・速度、翻訳精度、コード理解、ハルシネーション、校正の5項目で評価。
- ・Opus 4.8を用いたLLM-as-judgeによる自動採点と人手による確認。
// Result
検証の結果、モデルのアーキテクチャがRPC環境の性能を決定づけることが判明した。通信帯域がボトルネックとなるため、モデルの特性が顕著に影響する。主な成果は以下の通りである。
- ・Qwen3.6-35B-A3B（MoE）は、高速かつ高精度で最もバランスが良い。
- ・Llama-3.3-70B（Dense）は、通信負荷により極端に低速化する。
- ・MoEモデルの活用が、低帯域な分散環境における現実的な解となる。
- ・VRAMの残留管理など、運用上の細かな注意が必要であることが判明した。
Senior Engineer Insight
> 本構成は、限られた予算で大規模モデルを動かすための極めて現実的な解だ。しかし、通信帯域が致命的なボトルネックとなる。特にDenseモデルでは、層ごとの通信が性能を著しく損なう。実運用では、MoEモデルの選択が不可欠だ。また、VRAMの残留管理など、運用上の細かな注意も必要となる。スケーラビリティの観点では、Thunderbolt 5等の高速接続への移行が鍵となるだろう。