複数のローカルモデルが1つのアクセラレーターを共有できるようにするコンポーネントとは？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

What Components Enable Multiple Local Models to Share One Accelerator?

複数のローカルモデルは、サービング層がワークロード間で重みの常駐、動的メモリ、実行時間、リクエスト分離を調整すれば、1つのアクセラレーターを共有できます。

家庭用GPUは、チャットモデル、埋め込みモデル、ビジョンエンコーダー、音声認識を切り替えて実行できます。すべての重みセットを常駐させるとVRAMの容量を超える可能性がある一方、リクエストごとにアンロードすると、最初のトークンまでのレイテンシーが不安定になります。マルチモデルコントローラーには、個別のプロセスを競わせるだけではなく、常駐ポリシー、モデル間のメモリ計上、スケジューリング、キャッシュ分離、プリエンプション、公平性が必要です。

常駐ポリシーが、どの重みをウォーム状態に保つかを決める

コントローラーは、モデルサイズ、到着レート、ロード時間、レイテンシー目標、直近の利用状況を追跡します。利用頻度の高いモデルは常駐させ、利用頻度の低いモデルはCPUまたはストレージ上に置き、予測した需要に基づいて、次のリクエストがアクセラレーターに到達する前にプリウォームを開始できます。

マルチモデルのプリウォームは、複数のモデル向けに汎用GPUワーカーを準備し、エビクションを考慮した配置とプリウォームを調整します。その結果は、予測可能な需要のもとでコールドロードを避けることが、最初のトークンまでの時間を大幅に改善できる理由を示しています。この違いは、後の家庭環境でのテストでも確認できます。

常駐の判断には、量子化やアダプターのバリエーションも含めるべきです。見かけ上は似た2つのエンドポイントでも、異なるベース重みを保持している可能性があるためです。厳格なメモリ予算を設けることで、プロアクティブなロードによってアクティブなリクエストのKVキャッシュが追い出されるのを防ぎます。自動化を進める前に、中間結果を検証可能な状態に保つ必要があります。

モデル間のメモリ調整が断片化した容量を防ぐ

重みはおおむね安定していますが、アクティベーションとKVキャッシュはバッチサイズやシーケンス長に応じて増加します。共有アロケーターは必要に応じてメモリページを割り当て、アイドル状態の領域を回収し、予約領域を公開できます。これにより、あるモデルが別のモデルに約束された容量を消費するのを防げます。

モデル間のメモリ調整では、動的な仮想・物理ページマッピングと、実行時の共有ポリシーによるモデル間のメモリ調整を導入しています。この設計は、通常のプロセスレベルのGPU共有では、急速に変化するモデル需要にうまく対応できない理由を説明しています。この境界は、現実的な運用条件のもとで個別に測定すべきです。

メモリ共有はデータ共有ではありません。KVキャッシュブロック、プレフィックスキャッシュ、一時バッファー、アダプター状態にはテナント識別子とモデル識別子が必要です。そうでなければ、再利用されたページやキャッシュキーによって、エンドポイント間でコンテキストが漏洩したり、結果が破損したりする可能性があります。

スケジューリングとアダプター多重化が実行時間を制御する

スケジューラーは、モデルを同時にメモリへ配置する空間共有と、カーネルを交互に実行する時間共有のどちらを採用するかを選択します。継続的バッチ処理はスループットを向上させ、プリエンプションと重み付きキューは、長時間のバックグラウンドジョブから対話型リクエストを保護します。

アダプターの多重化は、アダプターの重みをページングし、異種バッチを調整することで、共有ベースモデル上で数千の低ランクアダプターに対応します。これは、完全に分離したモデルレプリカよりも多くの状態を共有しながら、特化処理を実現できることを示しています。複数のソースが限られたコンテキストを奪い合うとき、その実際の効果が現れます。

問題が発生する境界は、カーネルとメモリの干渉です。同時に収まる2つのモデルでも、計算資源、帯域幅、コピーエンジンを奪い合うと、レイテンシー目標を達成できない場合があります。共有が有用なのは、全体の利用率が高く見えるときではなく、モデルごとのp95レイテンシーと公平性がポリシーの範囲内に収まる場合だけです。

Featured

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

ZimaCube2

モデル共有の干渉マトリクスを作成する

各モデルを単独で測定した後、重要なすべての組み合わせと、想定される4モデル構成について、短いリクエスト、長いリクエスト、バースト性のあるリクエスト、バックグラウンドリクエストを実行します。コールドロード時間、常駐メモリ、KVの増加量、カーネル利用率、スループット、p50およびp95レイテンシー、エビクションを記録します。

ルーティングされたモデル常駐に示されるルーティングスタックの原則を使い、各エンドポイントに優先度と常駐クラスを割り当てます。アダプター、量子化バリエーション、継続的バッチ処理、プリエンプションを用いて再度テストし、キャッシュとリクエストIDが分離されたままであることを確認します。

重要な対話型モデルが、想定される最悪の組み合わせでもレイテンシー目標を満たす場合にのみ、共有ポリシーを維持します。ある組み合わせでスラッシングが繰り返し発生するなら、利用率グラフを改善するために同時実行数を増やすのではなく、その組み合わせを直列化するか、時間枠を予約してください。