GPUとCPUを分業させるローカルLLM構成の計画と、現実の試行錯誤

結論

Blackwell 96GB と EPYC 9175F の 12ch メモリ帯域を持つワークステーションで、GPU と CPU を分業させるローカル LLM 構成を計画した。

計画: CPU 側を Dagster パイプラインで冪等・非同期処理に使い、パラメータの大きい MoE モデルで品質の高い成果物を目指す。GPU 側をユーザーの対話窓口として、少し低めのパラメータで fine-tuning した専門性の高いモデルを置き、毎日の Dagster asset から LoRA で品質を上げていく。

現実: ik_llama.cpp を使って GPU に少し重みを載せて、メモリ帯域を食い合わないようにモデルの組み合わせを日々試行錯誤しているところだ。計画の Dagster + LoRA パイプラインはまだ動いていない。

計画: CPU/GPU 分業アーキテクチャ

CPU レーン — Dagster 冪等パイプライン

CPU 側の 12ch メモリ帯域を活かし、パラメータの大きい MoE モデル（100B〜400B 級）を非同期で回す。

• Dagster でパイプラインを冪等に構成する。asset ベースでジョブを管理し、失敗しても再実行で同じ結果が得られる
• 用途はリポジトリ全体の解析、ドキュメント生成、テストコード生成、大規模リファクタリングの思考など、時間をかけて品質を出す仕事
• 即応性は求めない。Fire & Forget で投げて、結果を待つ

MoE モデルは GPU 1 枚では active parameter が少なくても total parameter が大きいため VRAM に載りきらないことが多い。12ch の CPU メモリ帯域なら、非同期レーンとして十分実用的な速度が出る。

GPU レーン — 対話窓口 + 日次 LoRA 更新

GPU 側はユーザーの対話窓口として使う。

• パラメータ 30B 前後の、応答性の高いモデルを置く
• fine-tuning で専門性を上げる。自分のコードベース、設計パターン、使う言語に特化させる
• 毎日の Dagster asset から LoRA アダプタを生成し、ベースモデルに日次で適用する。CPU 側の重い処理結果が、GPU 側の対話品質に反映される循環

この循環が計画の核心だ。CPU 側で時間をかけて得た知見を、GPU 側の対話モデルに LoRA として還元する。ユーザーから見れば「使うほど賢くなるローカル LLM」になる。

計画時のパイプライン図

  CPU (EPYC 12ch):
  Dagster Pipeline → MoE 100B-400B (ik_llama.cpp / vLLM)
    → asset: コード解析結果、テスト生成、リファクタ提案
    → asset: LoRA 学習データ
    → 日次 LoRA アダプタ生成

GPU (Blackwell 96GB):
  対話サーバー → Dense 30B 級 (vLLM) + LoRA アダプタ
    → Zed MCP / Aider / CLI
    → 即時レスポンス
    → 日次で LoRA 更新（CPU 側の asset から）
  

現実: ik_llama.cpp でのモデル組み合わせ試行

計画の Dagster + LoRA パイプラインはまだ構築できていない。現状は ik_llama.cpp を使って GPU に少し重みを載せ（部分オフロード）、CPU と GPU でメモリ帯域を食い合わないモデルの組み合わせを探っている段階だ。

試行の焦点

• GPU に載せる重みの量を調整して、対話の応答性と CPU 側の帯域確保のバランスを取る
• 同時に複数モデルを立てるとき、メモリ帯域の競合で両方遅くなるパターンを避ける
• 量子化の選択（GGUF IQ, NVFP4, FP8）がモデルごとに品質と速度にどう影響するかを実測する

ツール構成（現状）

vLLM は計画にはあるが、現状は ik_llama.cpp の部分オフロードのほうが柔軟に組み合わせを試せるため、こちらを主力にしている。

モデル試行履歴

2026 年 1 月〜3 月にかけて試したモデルの時系列記録。cold storage のアーカイブから取得。

2026年1月

2026年2月

2026年3月

傾向

3 ヶ月の試行を振り返ると、いくつかの傾向が見える。

• 1月: 基本的なモデル選定。Dense コーディングモデル（IQuest-Coder 40B）と MoE（Scout, Maverick）の比較、NVFP4 量子化の品質検証が中心
• 2月前半: GLM, Kimi, DeepSeek など中国系モデルの評価が増える。Flash 系の軽量モデルも試行
• 2月後半: Qwen3.5 世代の MoE（397B, 122B, 35B）が中心に。量子化手法ごとの比較（同一モデルの GGUF/NVFP4/FP8 を複数試す）が増える
• 3月: 日本語特化モデル（Nemotron-Nano-9B-v2-Japanese）と埋め込みモデル（Perplexity）の検証に移行

全体を通して、同一モデルの異なる量子化を複数ダウンロードしているケースが多い。これは ik_llama.cpp での部分オフロード時に、量子化レベルが GPU/CPU 分業の効率に直結するためだ。

今後

計画の Dagster パイプライン + 日次 LoRA 更新はまだ実装していない。現状の試行錯誤から得られた知見をもとに、次のステップとして進めたい。

• ik_llama.cpp の部分オフロードで安定したモデル組み合わせを確定させる
• Dagster で冪等パイプラインを構築し、CPU レーンを非同期処理専用にする
• GPU レーンのベースモデルに対して、Dagster asset からの日次 LoRA 適用を開始する
• ctree + pathfinder の MCP ツールを Dagster asset の入力として組み込む