ホームAIサーバーはメモリ使用量に応じてモデルをどのように振り分けるのか？

ホームAIサーバーは、各リクエストを、利用可能なデバイスの余裕に完全なワーキングセットが収まるモデルに割り当てることで、メモリ使用量に応じてモデルを振り分けます。

ローカルルーターは、小型および大型の言語モデル、埋め込みモデル、ビジョンエンコーダー、音声システム、CPUまたはGPUの実行経路から選択できます。チェックポイントファイルのサイズは、あくまで出発点です。実際に実行を許可できるかどうかは、量子化メタデータ、ランタイムコンテキスト、KVキャッシュ、プロンプト長、同時実行数、ビジョントークン、一時ワークスペース、他のサービスがすでに確保しているメモリにも左右されます。優れたルーターは、実行前にこれらのコストをプロファイルし、リクエスト全体を通じて安定して動作できるモデル、精度、コンテキスト上限、ハードウェア経路を選択します。

チェックポイントのサイズはフットプリントの固定部分にすぎない

重みと量子化メタデータによって、予測可能な常駐メモリのベースラインが決まります。さらにランタイムが、ライブラリ、アロケータープール、実行グラフ、入力バッファー、アクティベーション、リクエスト状態を追加します。

ZimaSpaceのハードウェアガイドでは、AIに必要なメモリ全体を、モデルファイルのサイズ以上のものとして扱っています。

ファイルサイズだけを使うルーターでは、モデルの読み込みには成功しても、長いプリフィル、マルチモーダルリクエスト、同時チャットの処理中に失敗する可能性があります。

各モデルには実測に基づくメモリプロファイルが必要

すべてのモデルと量子化方式について、アイドル時の常駐メモリ、プリフィル時のピークメモリ、コンテキストトークンあたりのバイト数、KV精度、バッチ上限、ビジュアルトークンのコスト、ランタイムの予備領域を記録します。

2026年のマルチモデルスケジューリング研究では、単一の配置式がすべてのモデルに当てはまると仮定せず、アーキテクチャや異種ハードウェア全体にわたるモデルのメモリ挙動を分析しています。

コンパイルキャッシュやアロケーターのハイウォーターマークによって、以前のリクエスト後に利用可能なメモリが変化する可能性があるため、プロファイルにはコールド状態とウォーム状態の両方を含めるべきです。

ランタイム、ドライバー、コンテキスト設定、量子化方式、モデル形式を変更した場合は、プロファイルを再構築します。

ルーターは実行を許可する前に動的な余裕を確保する必要がある

リクエストからは、プロンプト長、予想出力長、画像の枚数と解像度、指定バッチ数、現在のユーザー同時実行数といった追加情報を取得できます。

Prismのグローバルメモリスケジューラーは、固定予約ではなく、ワークロードとキュー情報を使ってモデルのアクティベーションと排出を調整します。

ホームルーターでは、より単純な実行許可式を使用できます。デバイスの空きメモリから安全マージンを差し引いた値が、モデルのベースラインに推定リクエスト状態とワークスペースを加えた値を上回る必要があります。

推定値が収まらない場合、ルーターはコンテキストを短縮する、バッチ数を減らす、より小さなモデルを選ぶ、キャッシュ精度を下げる、リクエストをキューに入れる、別のデバイスへ振り分けるといった対応ができます。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

GPUに完全に収まる場合、部分オフロード、CPU実行は異なる経路

モデル全体がVRAMに収まる場合、通常はホストとデバイス間で重みを繰り返し転送する必要がありません。より大きなモデルは、CPUへの部分オフロードやユニファイドメモリによって実行できる場合がありますが、レイテンシーと帯域幅の制約は異なります。

ATSInferは、テンソルレベルの配置を使用して、コンシューマー向けCPUとGPUのメモリ間でストレージ、転送、計算を調整します。

ルーターは「実行できる」ことと「ワークフローの期限を満たせる」ことを区別すべきです。部分オフロードモデルは、一晩かけて行う分析には適していても、音声インタラクションには不適切な場合があります。

人気度と再読み込みコストが常駐モデルを左右する

頻繁にリクエストされるモデルはウォーム状態で保持し、使用頻度の低い大型モデルは、読み込みコストに見合うタスクが発生するまでストレージ上に置いておくことができます。

Weaverは、多数のエンドポイントにサービスを提供し、人気度に偏りがあるシステムにおけるホットモデルとコールドモデルを分析しています。

品質要件を満たし、長い排出と再読み込みのサイクルを避けられるなら、リクエストを少し小さなウォームモデルに振り分けることができます。一方、期待される品質向上が遅延を上回る場合は、難しいタスクのために大型モデルを読み込む価値があります。

タスク要件によってメモリだけに基づく判断を制約する必要がある

最もフットプリントが小さいモデルが、常に正しい経路とは限りません。コーディング、多言語テキスト、複雑な推論、OCR、ツールの計画には、小型モデルにない能力が必要になる場合があります。

MuxServeは、効率的なサービス提供がモデルの需要とリソースの挙動の両方に依存するため、配置とスケジューリングを組み合わせています。

まず必要な能力の最低基準を定義し、その後、ワークフローの品質、安全性、レイテンシー、形式のテストに合格するモデルの中から、最もフットプリントの小さいものを選びます。

決定論的な抽出タスクは常駐する小型モデルに振り分け、難しい計画リクエストは大型モデルに振り分けるか、空き容量が確保されるまで待機させることができます。

ルーティングはリアルタイムのメモリと直近の実行履歴に適応すべき

静的なプロファイルでは、アロケーターの予約、断片化した領域、競合するコンテナ、熱による速度低下のすべてを捉えることはできません。ルーターには、現在の空きメモリ、キューの深さ、常駐モデル、直近の失敗も必要です。

エージェント型CPU-GPUスケジューリングの研究では、異種AI処理を割り当てる際に、メモリフットプリント、コールドスタートコスト、実行履歴、ハードウェアに関する情報を組み合わせています。

選択した経路、予測メモリ、実際のピーク値、読み込み時間、初回トークンレイテンシー、出力速度、フォールバックの有無を記録します。予測誤差が定義したしきい値を超えた場合は、モデルプロファイルを更新します。

メモリを考慮したルーティングが成功している状態とは、リクエストを安定した容量内に収めながら、現在のタスクのサービス目標を達成できる最も高性能なモデルをサーバーが選択できることです。

FAQ

ルーターは簡易推定としてモデルファイルのサイズを使えますか？

有用なベースラインにはなりますが、リクエストを許可する前に、ランタイムのオーバーヘッド、KVキャッシュ、プロンプト、バッチ、安全マージンも考慮する必要があります。

VRAMがいっぱいになったら、モデルは常にCPUに振り分けるべきですか？

CPUまたはハイブリッド実行がタスクのレイテンシーとメモリ要件を満たす場合に限ります。キューに入れるか、より小さなモデルを選ぶ方がよい場合もあります。

メモリを考慮したルーティングには複数のGPUが必要ですか？

いいえ。1台のホームサーバー上で、1つのGPU、CPU実行、部分オフロード、異なる量子化方式、複数のモデルサイズから選択できます。