RAG 併用時は索引とチャットの RAM が衝突しやすいので、チャンク・埋め込み・ベクトルクォータの記事とセットで読むと安全です。ホームで概要を、購入ページで専用ノードを比較できます。
つまずきやすい点 1. ディスク上の GGUF サイズは実行時常駐と一致せず、KV と並行で膨らむ。2. バッチ拡大は膝を越えると圧縮やスパイクで逆効果。3. ビルド・テンプレ版がずれると再現性が崩れる。
ハードウェア境界
M4 クラスは ユニファイドメモリ で GPU／CPU／NE が同一プールを共有します。コンテキスト、KV、バッチは 一本の予算。重みと KV は毎ステップ流れるため、帯域と持続デコードがボトルネックになりやすく、ピーク TFLOPS だけでは読めません。圧力が上がるときは量子化一段下げ、num_ctx 短縮、並行削減の順が現実的です。
短いベンチより 数分〜十分のソーク でファン・温度・スワップを見る方が、長時間バッチ前提には信頼できます。
GGUF と量子化の選び方
GGUF は llama.cpp の交換形式で Ollama も利用します。実務では Q4_K_M／Q5_K_M が品質と容量の妥協点になりやすく、IQ 系はメモリ節約と評価セット必須のトレードです。MoE はルーティングでスパイクが出るため、版・量子化・テンプレを起動行に残します。
# 例（パスは環境に合わせる）
./llama-cli -m ./models/model.Q4_K_M.gguf -c 8192 -b 512 -ngl 99並行処理とバッチサイズ
llama.cpp： -c／-b（や -ub）、-ngl で明示。コンテキスト固定のままバッチを振り、許容 RSS 内の最大を残す。Ollama： Modelfile の num_ctx・num_batch、並行は OLLAMA_NUM_PARALLEL 等。スロットは KV 予算の乗算と見て、バーストはクライアントキューで吸収します。
ベースライン五手順
- コンテキストと並行の 上限をクライアントで固定。
- GGUF・量子化・テンプレ・版 をマニフェスト化。
- バッチスイープ で p95 プレフィル最良値を記録。
- ソーク でピーク RSS・スワップ・熱をログ化。
- 圧力継続時の フォールバック（短コンテキスト／低量子化）を決める。
| 観点 | llama.cpp | Ollama | M4 メモ |
|---|---|---|---|
| コンテキスト | -c／--ctx-size |
PARAMETER num_ctx |
KV は概ね線形増。ファイル容量だけ見ない |
| バッチ | -b／--batch-size |
num_batch |
膝まで上げ、超過はスパイク優勢 |
| GPU | -ngl で Metal 層 |
自動＋ num_gpu 等 |
部分オフロードでボトルネック移動。tok/s で見る |
| 並行 | 複数プロセスは常駐分離 | OLLAMA_NUM_PARALLEL＋キュー |
セッション≒KV 予算の乗算 |
| 帯域代理 | tok/s・メモリ圧・ビルド差 | 同左（リリース依存大） | 空きメモリがあるのに遅い→帯域／バッチ疑い |
本番前チェックリスト
- マニフェスト（量子化・ハッシュ・テンプレ・版）
- コールド→初回→並行ソークのメモリ曲線
- ステージ別
num_ctxとプロンプトキャップ - 採用
-b／num_batchと p95 のセット記録 - ログパスとローテーション共有
安定性に関する FAQ
途中で遅くなる？ 熱・圧縮・索引バックグラウンドが重なることが多い。並行と文脈を下げてソーク再現。
更新後だけ遅い？ ランタイムとモデルパスをピン留めし、必要ならミラー。
大バッチは最強？ いいえ。膝以降はメモリが勝つ。長プロンプトは分割・要約。
Metal オフ？ デバッグ以外非推奨。CPU 数値は容量見積に使わない。
共有運用？ 無秩序な積み上げよりキューか別ノード。
まとめ： 文脈・バッチ・量子化・並行は連動つまみ。定常計測と版固定で運用可能にし、索引とチャットは負荷を分離する。