V100クラスタでMoE推論50tok/s台、RTX 5090で27Bが最適解、Opusに迫る27Bの実測
目次
この記事はAIによって編集・作成されています。
V100クラスタでMoE実用域到達、RTX 5090の27B最適解、Opusに迫るコード品質
旧世代V100 SXMクラスタ（12x32GB）でMoEモデルの128B級が50tok/s台を実測。vLLM非対応のVoltaでもllama.cpp経由なら実用的な速度圏に入る。一方最新のRTX 5090環境では35B Q8のRAMロード遅延が問題となり、27B Q4/NVFP4の方が「賢く」感じられるという逆転評価が寄せられた。Qwen3.6 27BはOpus級と同等のHTML5ゲーム生成品質を記録し、64K以内のコンテキストで最大知能を発揮、128K超えるとIQ低下する実測も報告された。ローカルLLMのハードウェア選定とモデルサイズ選択が、数値だけでなく本質的な品質で論じられている。
🗣️ Reddit話題: V100 SXM 12枚構成でMoE推論を実用速度に引き上げる
Update on 12x32gb sxm v100 cluster / local AI for legal drafting | Reddit コミュニティ
話題の背景と経緯
ローカルLLMの実装では、vLLMが主力推論フレームワークとして広く採用されてきた。しかしThreadripper Pro搭載の12x V100-SXM2（各32GB）環境で、MoE GGUFモデルをvLLMで実行した結果、VoltaアーキテクチャではMoE GGUFに対応していないためvLLMが使えないという問題が表面化した。この制約により、llama.cppへ移行せざるを得なかった経緯が報告されている。vLLMのGGUF対応状況はハードウェアアーキテクチャに依存しており、Volta以降のアーキテクチャでもMoE GGUFサポートに差があることが実測で明らかになった。
この報告の背景には、Legal Drafting（法律文書起草）という実際の業務負荷がある。128Bパラメータ級のDenseモデルを12枚のV100で動かそうとした結果、27-32Bで20-28 tok/s、128Bで9 tok/sという速度になり「実用的ではない」判定が下された。MoEモデルに転じた結果、Gemma-4-26B-A4Bで約113 tok/s、Qwen3.5-122B-A10Bで約50 tok/sを達成。122B/10BのMoEが4カードで50tok/sに達し、前回のvLLM環境でのDenseモデルより高速となった。これは旧世代GPUでも、モデル選択を間違えなければMoE推論が実用範囲に入ることを示す実測データである。
コミュニティで何が議論されているか
議論の中心は「なぜvLLMが使えなくなったのか」「MoEの速度特性はどこにあるのか」の2点に集約される。あるユーザーはVoltaアーキテクチャのvLLM実装ではMoE GGUFのカーネルが未実装だと説明し、Hopper以降（H100など）なら対応可能だが、Voltaには対応がないためllama.cppしかない、と説明している。この報告はvLLMのアーキテクチャ依存性を明らかにする。
MoEモデルの速度特性については、アクティブパラメータが小さい点が恩恵になるとの見方もある。122B総パラメータ・10BアクティブのQwen3.5-122B-A10Bが4カードで50tok/sを発揮するのは、総パラメータ数が大きくなってもアクティブ部が小さいため、VRAM消費と計算量がDense同等にならないためだと解釈できる。一方、Denseモデルの低速化については「VRAMの大半をKVキャッシュが占有し、計算バースト率が低い」との分析があり、MoEが相対的に高速に見える理由も説明されている。
懐疑的な声もある。12枚のV100-SXM2はNVLinkがボード内のみ有効化でボード間ではPCIe経由になるため、スケーラビリティに制約がある。あるユーザーは「NVLinkフル接続なら結果が全然違うはずだ」と報告し、この構成の実用的価値に疑問を呈している。また、113tok/sはGemma-4-26B-A4Bという比較的小規模なMoEでの数値であり、122B-A10Bの50tok/sは実用上十分か議論の余地があると報告されている。
技術的な核心
この報告の技術的意義は3点に集約される。第一に、vLLMのMoE GGUF対応がアーキテクチャ依存であることの確認。Volta（V100）には対応がなく、llama.cpp経由が唯一の手段となる。第二に、MoEモデルのアクティブパラメータ数が小さいために、総パラメータ数が大きくても推論速度がDense同等以上になるという「MoEの速度メリット」が旧世代GPUでも確認された。第三に、128B級モデルを50tok/sで動かせる環境は、法律文書起草のような長時間のコンテキストが必要なタスクで、llama.cpp経由でも実用域に入る。
量子化設定の選択も重要。Q8 GGUF / Q4 KV cache / flash-attn有効の組み合わせが推奨されている。Q4 KV cacheによりVRAM消費を抑制しつつ、Q8のモデルパラメータで精度を維持するこの設定が、50tok/s圏の条件として報告されている。
実際に使える・試せる情報
V100 SXM環境でMoEモデルを試す場合の具体設定は以下の通り。
推奨モデル: Gemma-4-26B-A4B（113 tok/s / 4 card）、Qwen3.6-35B-A3B（82 tok/s / 4 card）、Qwen3.5-122B-A10B（50 tok/s / 4 card）。全てQ8 GGUF形式。
量子化設定: Q8 GGUF（モデル）、Q4 KV cache（KVキャッシュ）、flash-attn有効。この組み合わせで速度と精度のバランスが確認されている。
カード構成: 1ボード4カード構成で動作確認済み。NVLinkはボード内のみ有効。ボード間の通信はPCIe経由になるため、スケーラビリティに注意。
旧世代V100環境でMoEを試す場合、vLLMではなくllama.cpp経由、Q8 GGUF/Q4 KV cacheの組み合わせ、4カード構成で始めて実用速度圏に入る。128B級MoEの50tok/sは実用上許容範囲だが、より高速を望むなら小規模MoE（26B-A4B級）を検討すべき。
🗣️ Reddit話題: RTX 5090 576GBの壁、27Bが35Bを凌ぐ理由
Looking for Suggestions — Single 5090 & 64gb DDR5 | Reddit コミュニティ
話題の背景と経緯
RTX 5090は576GBのVRAMを備え、かつてないローカルLLM環境として話題となった。64GB DDR5システムメモリとの組み合わせで、どのようなモデルサイズが最適かという問いがコミュニティで投げかけられた。特にエージェント型コーディング用途での比較が焦点となり、27B（Q4/NVFP4）と35B（Q8）のどちらが実用的かという議論が展開されている。
この議論の背景には、モデルサイズと量子化の組み合わせによる実際の速度・品質のトレードオフがある。VRAMに収まるサイズでも、量子化の粗さ（Q8など）で遅延が発生する。逆にVRAM内に収まるQ4やNVFP4の方が、RAMに落ちるQ8より高速になる可能性がある。576GBという大容量VRAMがある環境でも、モデル選択には注意が必要だという実測知見が得られた。
コミュニティで何が議論されているか
圧倒的なコンセンサスは「27BモデルをVRAMに完全に収める構成が最適」である。あるユーザーは「35B Q8はシステムメモリ（RAM）にロードすると遅延が発生し、応答速度が低下する。27B Q4/NVFP4の方が、35B Q8よりも「賢く」感じられ、ツール呼び出しの失敗が少ない」と実測で報告している。
この「27Bの方が賢く感じる」という報告は直感に反する。35Bの方がパラメータ数が多く、理論的には表現能力が高い。しかしRAMロードによる遅延が、エージェント作業でのツール呼び出し失敗に直接影響する。VRAM完結の27B Q4/NVFP4は、RAMの読み込み遅延を回避でき、応答速度と安定性の両方で実際の性能向上につながる。
64GB DDR5の活用方法については「主モデルのオフロードには使わない」という強い意見がある。代わりに「巨大なコンテキストウィンドウ、RAG、ベクターDB、キャッシュ、並列エージェントのサポート用」という位置付けが推奨されている。これはVRAM完結モデルを基本とし、RAMを補助的なリソースとして活用する設計思想である。
推奨設定としては、vLLMでのMTP/DFLASH活用、llama.cppではQ5 quantizationが推奨されている。特に単一GPU構成ではVRAM完結が最重要との結論は、576GBの大容量VRAMがあっても「モデル全体をVRAMに載せる」ことが最優先事項であることを示している。
技術的な核心
この議論の核心は「VRAM完結 vs RAMロードの遅延差」にある。VRAM内にモデル全体が収まるQ4/NVFP4構成は、GPUメモリ内でのみ完結するため、RAMとの間でデータを移動するオーバーヘッドがゼロになる。一方、35B Q8はVRAMに収まらないため、システムRAMに一部がスワップされる。このRAMスワップが応答速度の低下、特にエージェント作業でのツール呼び出しの失敗率増加につながる。
「27Bが35Bより賢く感じる」という評価は、ベンチマークスコアとは異なる「実際の知能」の指標である。エージェント作業では、ツール呼び出しの成功率と応答速度が、全体の作業効率に直結する。パラメータ数の多さがベンチマークスコアでは有利でも、RAMスワップによる遅延が実用上の知能を低下させる。この「実際の知能」と「理論知能」の分離が、5090環境でのモデル選択の鍵になる。
実際に使える・試せる情報
RTX 5090 + 64GB DDR5環境での具体的なモデル推奨は以下の通り。
推奨モデル: Qwen3.6 27B Q4_K_S / NVFP4（VRAM完結）、Llama 27B系（VRAM完結）。Q8量子化はVRAMオーバーのため非推奨。
非推奨: Qwen3.6 35B Q8（RAMロードによる遅延）。35BはVRAM内に収まらないため、64GB DDR5へのスワップが発生し、エージェント作業での応答速度低下とツール呼び出し失敗の原因になる。
64GB DDR5の適切な活用: 主モデルのオフロードには使用せず、巨大コンテキストウィンドウ、RAG、ベクターDB、キャッシュ、並列エージェントのサポート用に使用する。
量子化推奨: llama.cppではQ5 quantizationが推奨。vLLMではMTP/DFLASHを有効化。
576GB VRAMの環境でも「VRAM完結」が唯一の基準。35B Q8をVRAM完結で動かす量子化（Q4など）があれば別だが、通常は27B Q4/NVFP4が最適解。
🗣️ Reddit話題: Qwen3.6 27BがOpus級コード生成を実現する実測
Okay 27B made me a believer | Reddit コミュニティ
話題の背景と経緯
Qwen3.6 27Bのコード生成能力を実際のプロジェクトで評価した結果、Opus級の大規模モデルに匹敵する一貫性のある品質が記録された。単一ショットのプロンプトでHTML5ゲームコンソール向けの「Breakout」ゲームを生成し、コントロール・グラフィック・サウンド・コンソールAPI連携がすべて正常動作する完成度の高いコードを出力した。LLM特有の安っぽさがなく、「思考が込められた」ような品質だと報告されている。カスタマイズ用1回のフォローアップと1つの修正で完了した。
この報告の背景には、Qwen3.6 27BがOpus級モデルと同等以上のコード品質を発揮するという、従来の27Bクラスの評価を覆す知見がある。ローカルLLMの主流化という文脈で、27Bモデルが「十分すぎる」品質を持つことが実測で示された。
コミュニティで何が議論されているか
コンテキスト長と知能発揮の関係が注目されている。64K以内のコンテキストで知能が最大に発揮され、128Kを超えるとIQが低下するという実測報告がある。これはモデルのコンテキスト長自体が128K以上あるにもかかわらず、実際には64K以内で最適パフォーマンスを発揮することを意味する。
長期エージェント作業については「要約・再読み込みによる情報保持が鍵」との分析がある。コンテキストが長くなると品質が低下するため、要約で情報を圧縮しながら状態を維持するアプローチが必要だと報告されている。64K以内の知能最大状態を維持できるかどうかは、長期作業の成否を分ける条件になる。
「単一ショットでプレイ可能な完成度高いコード」という報告は、LLMのコード生成能力の評価基準を押し上げる。多くのLLMコード生成は「骨組みは書けるが実装に穴がある」という水準だったが、Qwen3.6 27Bは単一ショットで実際に動作可能なゲームを生成し、フォローアップと1つの修正で完了するという品質を示した。
技術的な核心
64K以内の最適コンテキストと128K超でのIQ低下という現象は、モデルのAttention機構の特性、あるいは訓練データのコンテキスト長分布に起因する可能性が高い。64K以内ではAttentionの分散が最適化され、128Kを超えると分散が粗くなるため、情報保持力が低下する可能性がある。この現象はQwen3.6 27B固有のものかもしれないが、他のモデルでも同様の傾向が見られる可能性がある。
Opus級と同等品質のコード生成は、27Bというモデルサイズでも訓練の品質・データの質が性能を大きく左右することを示している。パラメータ数だけでは測れない「実際のコード品質」の指標として、単一ショットでの実用コード生成が有効な評価手法であることが確認された。
実際に使える・試せる情報
Qwen3.6 27Bの実際のコード品質評価と活用方法の具体情報は以下の通り。
コンテキスト長推奨: 64K以内。この範囲で知能が最大に発揮される。128Kを超えるとIQが低下するため、長期作業では要約・再読み込みによる情報保持が必須。
コード生成品質: 単一ショットで実際に動作可能なHTML5ゲーム生成が可能。コントロール・グラフィック・サウンド・コンソールAPI連携のすべてが正常動作。Follow-up 1回 + 修正1回で完了。
長期エージェント作業: 64K以内の知能最大状態を維持するため、定期的に要約して情報を圧縮・再読み込みするパイプラインが必要。128Kコンテキストは使わない、または要約で64K以下に圧縮する。
64K以内のコンテキストでOpus級のコード品質を発揮する27Bモデルは、ローカルLLMの実用的な主流として十分に機能する。128K以上のコンテキストが必要な場合は、要約パイプラインを組んで64K以下に圧縮する必要がある。
まとめ
ローカルLLMのハードウェア選定とモデルサイズ選択は、VRAM容量だけでなく「VRAM完結 vs RAMスワップ」の境界線で決まる。V100クラスタでもMoE選択で50tok/s圏、5090でも27B Q4/NVFP4が35B Q8を凌ぐ。64K以内のコンテキストでOpus級のコード品質を発揮する27Bモデルは、ローカルLLMの実用ラインを明確にした。
576GB VRAMの5090環境でも35B Q8は非推奨。27B Q4/NVFP4のVRAM完結が唯一の正解。64GB DDR5はRAG・キャッシュ用に回すが、主モデルには使わない。コンテキスト64K以内が最適で、128K超は要約圧縮必須。この判断材料は、次のモデルサイズ選定で直接活用できる。
SwitchBot公式ページ
クーポン「AF-4903」で5％引き（アフィリエイトクーポンになりますのでご協力お願いします）
割引の詳しい仕組みに関してはこちらのページを参照ください。