メインコンテンツへスキップ
ローカルモデルは、重み、KV キャッシュ、およびいくつかの動作オーバーヘッドを保持するために十分なメモリを必要とします。VRAM に完全に収まらない場合、オフロードは GPU で高速に実行する部分と CPU で低速に実行する部分を決定します。このページでは容量計算の理論とオフロードの仕組みを説明します。GPU やモデルサイズ別の既成の VRAM 表については、GPU モデル適合ガイドを参照してください。このページではそれらの表を繰り返しません。

​
容量計算の式

モデルの重みは、精度によってパラメータあたりのバイト数が固定されます。 GGUF Q4_K_M は混合精度であり、K-quants が異なるテンソルに異なるビット幅を割り当てるため、パラメータあたり約 0.5–0.56 バイトに平均化され、一律の 0.5 ではありません。これらの名称の読み方については、量子化を参照してください。 パラメータ数にパラメータあたりのバイト数を掛けて生重みのサイズを求め、次に modest なコンテキスト長における KV キャッシュ、活性化値、フレームワークのオーバーヘッドに対して約 20% を加算します。
Hugging Face は 15B+ モデルでこのパターンを直接測定しており、約 29 GB で bf16、~15 GB で 8-bit、~9.5 GB で 4-bit でした。詳細は、Hugging Face の LLM 最適化ガイドを参照してください。より長いコンテキストは、この 1.2× ベースラインの上にさらに KV キャッシュを追加します。なぜそのようなスケーリングになるかは、KV キャッシュとコンテキストを参照してください。
この式は重みサイズの計画推定値であり、厳密な真値ではありません。実際の値は、実行する正確な量子化における実際の GGUF ファイルサイズに、ターゲットのコンテキスト長に対する KV キャッシュを加えたものです。計算例とインタラクティブな推定ツールについては、GPU モデル適合ガイドを参照してください。

​
実際にメモリを争う要素

三つの要素が同じ VRAM（または統一メモリ）プールを共有します。
  • モデルの重み — モデルの読み込み時に固定され、プロンプトの長さには影響されません。
  • KV キャッシュ — コンテキスト長とバッチサイズに応じて増加します。詳細は KV キャッシュとコンテキストを参照してください。
  • 活性化値とフレームワークのオーバーヘッド — 各フォワードパス中に必要な小さな作業メモリであり、上記の式における 1.2× 係数が概ねこれを説明しています。
重みが最も大きく予測可能なコストです。KV キャッシュはコンテキストが成長するまで目に見えないため、驚かされやすい部分です。

​
オフロード：モデルが完全に収まらない場合

モデルの重みが GPU の VRAM に完全に収まらない場合、llama.cpp などのバックエンドは、完全に失敗するのではなく、モデルを GPU と CPU で分割して実行できます。これは --n-gpu-layers（短縮形 -ngl）フラグで制御されます。このフラグは、モデルのレイヤーのうち何層を GPU に読み込むかを設定し、残りはシステム RAM に保持します。
  • 完全オフロード（すべてのレイヤーをカバーするのに十分な -ngl を設定）：モデル全体が GPU で実行され、GPU のフル速度で動作します。
  • 部分的なオフロード：一部のレイヤーが GPU で実行され、残りはシステム RAM を使用して CPU で実行されます。これにより、VRAM より大きなモデルを実際に読み込んで実行できますが、コストがかかります。
  • オフロードなし（-ngl 0）：モデル全体が CPU のみで実行されます。
部分的なオフロードのコストは速度であり、正しさではありません。出力はどちらの場合も同じです。CPU 側のレイヤーとシステム RAM は、GPU VRAM よりもはるかに低いメモリ帯域幅を持ちます。推論の仕組みで回想すると、デコードはメモリ帯域幅に制限されます。生成されるすべてのトークンは関連するレイヤーを読み取る必要があるため、より低速なメモリにあるレイヤーは、各ステップでボトルネックになります。GPU から外すレイヤーが増えるほど、生成は遅くなります。モデルが RAM からディスクに溢れると、劇的に遅くなることがあります。
モデルが RAM に留まるのではなくディスク（スワップ）に溢れる場合、深刻な速度低下を伴います。ディスクの帯域幅は RAM よりも桁違いに低速であり、VRAM と比較すればさらに低速です。ディスクへの溢れは、実行し続けるものではなく、より小さなモデルを選択するか、より積極的な量子化を行うべきサインとして扱ってください。
バックエンド固有の正確なフラグ名と動作は、llama.cpp リポジトリで確認してください。他のバックエンド（LM Studio、Ollama）も、内部で llama.cpp を使用していることが多く、独自の設定を通じて同じアイデアを提供しています。

​
統一メモリが状況をどう変えるか

システムで統一メモリ（Apple Silicon および AMD の Strix Halo プラットフォーム）を搭載した場合、CPU と GPU が個別の小さな VRAM を持つ GPU とは異なり、単一のメモリプールを共有します。これにより、オフロードの計算が変化します。
  • 容量：統一メモリシステムは、固定された VRAM を持つディスクリート GPU よりもはるかに大きなモデルを読み込むことができます。「VRAM」プールは、グラフィックス使用に割り当てられた部分まで、マシンの合計 RAM と同じ大きさになるためです。
  • 帯域幅：同じプールは、ディスクリート GPU 上の専用 GDDR メモリよりも低い帯域幅で動作します。統一メモリに完全に収まるモデルでも、同じモデルがディスクリート GPU の VRAM に完全に収まる場合よりも、デコード速度が遅くなります。デコード速度は容量だけでなく帯域幅に追従するためです。
実際には、統一メモリは「そもそも収まるか」から「収まった後、どれくらいの速度で実行されるか」へとトレードオフをシフトさせます。これはオフロードを強いる容量の問題を解決しますが、その見返りに GDDR クラスの帯域幅を提供するわけではありません。特定の統一メモリシステムがディスクリート GPU とどのように比較されるかは、GPU モデル適合ガイドを参照してください。

​
さらに詳しく

推論の仕組み

なぜデコードがそもそもメモリ帯域幅に制限されるのか。

KV キャッシュとコンテキスト

モデルだけでなく、会話に応じて増加するメモリ使用量の部分。

量子化

パラメータあたりのバイト数を縮小し、容量計算の式で最も大きな入力を変更する。

GPU モデル適合ガイド

VRAM 表、インタラクティブな推定ツール、および一般的なハードウェアに収まるもの。

​
収まり、実行された後

容量計算とオフロードにより、モデルは完全に GPU で実行するか、CPU と分割するかを問わず、ハードウェア上で実行されます。localhost でリクエストに応答し始めたら、次のステップは他の場所からアクセスすることです。

安定したエンドポイントを提供する

Tokios はモデルを選択、ホスト、ファインチューニングしません。ローカルで実行されると、Tokios はそれをどこからでも呼び出せる安定した認証済みエンドポイントに変換します。