2x3090でCPUオフロードを使用したMiniMax M2.7 Q8_0 128Kの実行 – 実世界のベンチマークと設定

最近のr/LocalLLaMAの投稿で、あるユーザーがMiniMax M2.7モデル(Q8_0量子化)を2x3090構成、256GB DDR4、中古の10900X CPUで128Kコンテキストまで動作させた経験を共有しています。主な課題は、量子化されていないKVキャッシュを持つ大規模MoEモデルを、そのクラスとしては比較的低スペックなハードウェアで実行することでした。
パフォーマンス数値
ユーザーは次のように報告しています:
- プロンプト処理:毎秒約50トークン
- トークン生成:毎秒約10トークン
- 「非常に遅いが、コーディングエージェントのワークフローには使える」と説明
設定
彼らはik-llama-cuda(llama.cppのフォーク)を以下のフラグで使用しています(NixOS設定より):
${ik-llama-cuda}/bin/llama-server \
-m ${modelPath} \
--host 0.0.0.0 \
--port ${toString cfg.port} \
-c ${toString cfg.contextLength} \
-ngl 999 \
--cpu-moe \
-sm graph \
-fa on \
-t 16 \
-tb 16 \
-b 4096 \
-ub 4096 \
-np 1 \
-muge \
-ger \
--jinja \
--metrics \
--temp 1.0 \
--top-p 0.95 \
--top-k 40 \
--min-p 0.01注目すべきフラグ:
--cpu-moe– MoEエキスパート計算をCPUにオフロード-sm graph– グラフベースのスケジューリングを有効化-fa on– フラッシュアテンション-t 16/-tb 16– 計算とバッチそれぞれに16スレッド-b 4096/-ub 4096– バッチサイズとubatchサイズ-muge– メモリ使用量に基づくエキスパート読み込み(おそらく)-ger– GPUエキスパートルーティング
背景と動機
ユーザーは、低量子化で見られた「奇妙な動作」を軽減するためにQ8_0を選択したと報告しています。また、M2.7向けの投機的復号化用ドラフトモデルがリリースされておらず、これがあれば速度が向上したかもしれないと述べています。彼らは、生成に「文字通り一日中」かからない限り、速度よりも正確性を重視しています。
開発者への示唆
これは、マルチGPU構成でシステムRAMを活用して大規模MoEモデルを実行する人々にとって実用的なデータポイントです。--cpu-moeアプローチにより、VRAMの制限をはるかに超えてコンテキストを拡張できますが、速度は低下します。レイテンシがそれほど重要でないコーディングエージェントのワークフローでは、このトレードオフは許容できるかもしれません。
📖 原文を読む: r/LocalLLaMA
👀 See Also

クラウドユーザーが、直接的な技術的フィードバックのための「私の感情を管理しないで」プロンプトを共有
Claudeユーザーは、検証の前置きを減らしてより直接的な技術的フィードバックを得るために、ユーザー設定で特定のプロンプトを設定することを推奨しています。このプロンプトは、Claudeに外交的な言い回しを飛ばして、技術的・創造的な作業について率直な批評を提供するよう指示します。

OpenClawの3週間:トークンコスト、ループ、コンパクション — 現場からの教訓
Opusを使ったハートビートチェックやエージェントのループ対策、コンパクションによるコンテキスト損失を経て、Redditユーザーが苦労して得た解決策を共有:単純なタスクには安価なモデルを使い、アンチルールを記述し、決定ログを保存すること。

Claudeの/btwコマンドは、タスク実行中に並行してコミュニケーションを可能にします
Claude AIは現在、AIがタスクを積極的に処理している間にユーザーがAIと通信できる /btw コマンドをサポートしています。これにより、現在のワークフローを中断することなく、質問、追加の指示、または明確化を行うことができます。

劣化したClaudeのパフォーマンスを診断する:根本原因と修正方法
Claudeのコーディング結果が時間とともに劣化する理由と、コンテキスト管理やプロンプト衛生を含む実践的な修正方法を解説。