ローカルLLMを遅くしないための量子化・KV cache・実行系

最初に分けるべき三つの重さ

「7BならMacで動く」という言い方は、半分だけ正しい。重みが載るか、会話が長くなっても載るか、欲しい待ち時間で返るかは別の問いである。重みは主にモデルのパラメータ数と精度で決まり、会話中の作業領域はKV cacheで増え、待ち時間はプロンプトの読み込みと一語ずつの生成で性質が違う。この三つを一つの「必要メモリ」に潰すと、量子化して起動したのに長い資料で落ちる、GPU使用率は高いのに最初の応答が遅い、といった現象を説明できなくなる。

1. 1モデル重み
2. 2起動時に常駐
3. 3量子化で主に縮小

1. 1入力トークン
2. 2KV cache
3. 3会話・同時利用で増加

1. 1prefill
2. 2最初の一語
3. 3decode
4. 4一語ずつの待ち時間

重みは各層の行列であり、FP16なら概算で「パラメータ数×2 bytes」が下限の目安になる。実際にはテンソルの配置、実行用バッファ、OSやランタイムの領域が加わる。4 bit量子化は単純に四分の一になる魔法ではない。ブロックごとのscaleやzero pointなどのメタデータ、量子化しないテンソル、アクティベーションが残るからである。それでも、帯域幅が律速になりやすい生成では、読む重みを小さくして速度と搭載可能性を改善できる。

量子化は「精度を何bitにするか」より「どこで誤差を払うか」

量子化は連続値の重みを限られた表現へ写す。代表的な手順は、重みの小さなグループごとにscaleを求め、整数値とscaleで近似することだ。外れ値を同じscaleに押し込めば他の値の刻みが粗くなり、グループを小さくすればメタデータが増える。ゆえにQ4というラベルだけで品質を比較してはいけない。方式、グループサイズ、キャリブレーション、対象モデル、評価タスクがセットで必要になる。

まずは同じプロンプト、同じ温度、同じ最大出力でFP16相当と候補量子化を比較する。確認するのは「文章が自然か」では足りない。数値抽出、JSONの妥当性、短いコードのテスト、固有名詞を含む要約のように、自分が失敗を許せない作業を20件ほど固定する。速度は一回だけ測らず、cold startを除いた複数回の中央値を取る。モデル名とコミット、量子化ファイルのハッシュ、コンテキスト長、入出力トークン数を記録しなければ、翌週の比較は再現しない。

KV cacheは会話履歴そのものではなく、再計算を避ける表

Transformerは各トークンで過去トークンへ注意を向ける。各層のKeyとValueを保存しておけば、次のトークンで過去全体を再計算しなくてよい。この保存表がKV cacheである。概算では層数、KV head数、head dimension、トークン数、要素bytesに比例する。モデルの重みを4 bitにしても、KV cacheがFP16/BF16なら、長文・多数セッションではこちらが先に効く。

長いコンテキストを指定すると、空きメモリがその長さ分だけ必要になるとは限らないが、最悪ケースを許容する実装では予約が大きくなる。RAGで常に巨大な資料を丸ごと入れる設計は、品質以前に同時実行数を押し下げる。検索で候補を絞り、引用単位で入力し、必要なら会話を要約して状態を圧縮する。これは節約ではなく、根拠を追いやすくする設計でもある。

vLLMの PagedAttention 解説はKV cacheを固定連続領域で扱わず、論理ブロックを物理ブロックへ割り当てる考え方を説明する。ページングの利点は、長さの異なる要求で生じる空き領域を減らし、共有できるprefixを扱いやすくする点にある。ただしGPUサービング向けの最適化であり、単独のMac上の軽い対話へそのまま持ち込む判断ではない。

MLX、llama.cpp、vLLMは同じ仕事を競っているわけではない

Apple Siliconを主戦場にするなら、MLXはunified memoryとMetalを扱える配列基盤で、Pythonから研究・変換・軽い推論を試しやすい。MLX LMなどの周辺実装を使う場合も、モデル形式、利用条件、量子化形式は個別に確認する。MLXそのものはモデル配布許諾を与えない。

llama.cppはGGUFを中心にCPU、Metal、CUDAなど幅広い環境で動かしやすい推論実装である。端末で一つのモデルを試す、ローカルHTTP serverを立てる、配布物を小さく保つといった用途に向く。速さはバックエンド、スレッド、GPU offload、バッチ、プロンプト長で大きく変わる。READMEの機能一覧は確認できるが、任意のモデルの品質・ライセンスを保証する資料ではない。

vLLMは多数リクエストをGPUでさばくサーバー設計に強い。continuous batching、KV cache管理、OpenAI互換サーバーなどが選定理由になる。一人のデスクトップ利用で「最速」を約束する製品名ではない。CUDA対応GPU、ドライバ、モデルアーキテクチャ、運用監視まで含むため、学習用の最初の一台はllama.cppかMLXで失敗面積を小さくし、複数利用者や負荷試験が必要になった時点でvLLMを評価する順が安全である。

1. 1個人の試行
2. 2MLX または llama.cpp
3. 3入出力と品質を固定評価

1. 1複数要求・GPU運用
2. 2vLLM
3. 3同時数・p95待ち時間・KV使用量を観測

1. 1品質低下
2. 2量子化方式を一段戻す
3. 3同じ評価セットで再測定

手を動かす最小実験

1. 使うモデルの公式配布ページで、重みのライセンスと許可される用途を読む。OSSランタイムのライセンスと混同しない。
2. まず20個の短い入出力例をjsonlで固定する。各行に期待する検査を付ける。例えばJSON parse、正規表現、単体テスト、人手採点である。
3. 同じモデルの二つの量子化を、同一のseed・温度・出力上限・コンテキスト長で走らせる。起動、prefill、decodeを別の列で記録する。
4. 4,000、16,000、32,000 token相当の入力で、実際のメモリと失敗を観察する。入力を水増しして作った結論は、実文書で再確認する。
5. 結果表に「この条件では採用」「これ以上の会話では未検証」と書く。単一のtokens/sを普遍値として掲げない。

失敗の多くはモデルの弱さではなく、測定対象の曖昧さから始まる。速い短文チャットと、長い契約書を根拠付きで読む仕事は同じベンチマークでは選べない。重み、KV cache、入出力の三つを別々に見れば、次に増やすべきRAM、VRAM、検索、あるいは評価データが判別できる。

2026年9月の runtime check：release は測定面を変え得る

llama.cpp の release stream には2026年9月の build と platform asset が見える。これは現在の保守シグナルであり、あなたの機械の throughput 主張ではない。runtime を更新したら同じ prompt corpus を再実行し、正確な tag/commit、backend、context length、quantization、warm-up 条件、prefill 時間、decode tokens/sec、peak memory、失敗を記録する。Apple Silicon 最適化の断片性に関する LocalLLaMA 議論はコミュニティ体験であり、報告数値で選ばず自分の stack を測る動機にする。

2026-09-13公開のllama.cpp b10935 releaseは、benchmark でなく日付付き runtime artifact である。ローカル測定を繰り返す時は正確な tag を使い、一般的な releases index を9月 release と呼ばない。