CPUオフロードによって、大規模なモデルをホームサーバー上で実行し続けられる仕組みとは?

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

CPUオフロードは、モデル全体をアクセラレーターのメモリに保持する代わりに、重いモデルの重みの一部をシステムRAMに保存することで、モデルを動作させ続けます。

ホームAIサーバーでは、これにより、1枚のGPUでは読み込めないモデルをローカルサービスとして利用できるようになります。トレードオフは明確です。VRAMの負荷は下がりますが、CPUメモリ、PCIeまたはインターコネクトの転送、場合によってはCPUでの実行が推論経路に加わります。オフロードはまず容量を確保するための手法であり、メモリ階層が十分に高速な場合に限って、パフォーマンス向上の手法にもなります。

高速なデバイスに必要な状態を保持できないと、サイズの大きいモデルは失敗する

ローカルモデルには、重みに加えて、KVキャッシュ、アクティベーション、一時バッファー、ランタイムの予約領域を保存するための容量が必要です。アクセラレーターに必要な常駐状態を保持できない場合、有効な推論が始まる前に読み込みが失敗することがあります。

Hugging Face Accelerateは、大規模モデルの推論を、利用可能なメモリ階層にモデルの重みを分散配置する問題として扱います。CPUオフロードでは、モデルの状態を保存する低速な階層としてシステムRAMを追加します。

アクセラレーターが物理的に増設されたわけではなく、同じ瞬間にVRAMへ常駐させる必要のあるモデル部分が減るため、モデルを実行できるようになります。

オフロードされた重みは、そのレイヤーが必要になるまでシステムRAMに保持される

ランタイムは、現在のレイヤーまたはレイヤー群がGPUでアクティブになっている間、選択したパラメータテンソルをCPU上に保持できます。実行が進むと、必要な重みがアクセラレーターへ転送され、古い重みはデバイスメモリへ戻されるか、そこから破棄されます。

DeepSpeed ZeRO-Inferenceは、モデルの重みをCPUまたはNVMeメモリに保持し、レイヤー単位でGPUへストリーミングできます。これによりアクセラレーターのピーク時の常駐量は減りますが、重みの転送が実行処理の一部になります。

レイヤーの配置を固定することもできます。一部のレイヤーをCPUに残してそこで実行し、他のレイヤーをGPUに配置する方法です。どちらの方式も、デバイスメモリへの負荷を、低速なメモリや転送経路と引き換えに軽減します。

PCIeまたは共有メモリの経路が、すべてのトークン処理の一部になる

順方向実行中に重みをPCIe経由で移動する必要がある場合、転送のレイテンシーと帯域幅が推論のクリティカルパスに直接入ります。モデル全体がVRAMに収まる場合、常駐する重みをデバイス帯域幅で再利用できます。一方、オフロードされたモデルでは、大きなテンソルを繰り返し取得することがあります。

PyTorchは、ホストメモリの固定化とCPUからGPUへの転送動作について説明しており、ホストとデバイス間のデータ移動がGPUの演算とは別のパフォーマンス領域であることを示しています。

そのため、CPUオフロードは、メモリ不足によるクラッシュを、動作するものの低速なモデルへ変えることができます。まず容量の問題は解決できますが、スループットは大幅に低下する可能性があります。

システムRAMを増やすと容量は拡張できるが、速度が保証されるわけではない

オフロードする部分に加えて、OS、ページキャッシュ、コンテナ、データベース、その他のホームサーバーサービスを保持するのに十分なRAMが必要です。モデルがスワップへ移行すると、低速な構成では実用性を失うことがあります。

Linuxは、メモリの回収とスワップをシステムメモリ階層の一部として説明しています。オフロードされたモデルは、同じRAMの予算を他のすべてのプロセスと共有します。

NAS、写真インデクサー、メディアデータベースも動作させるホームサーバーでは、モデルファイルだけを基準にRAM容量を決めるのではなく、十分な余裕を確保する必要があります。

量子化とオフロードは、適合性の問題における異なる部分を解決する

量子化は重みに使用するバイト数を減らすため、GPUとCPUの両方で必要な常駐容量を縮小し、転送量も削減できます。オフロードは、実行中にそのデータをどこに配置するかを変える手法です。

NVIDIA NeMoは、モデルのメモリ使用量を抑えるためのFP8、INT8、INT4量子化について説明しています。量子化したモデルはGPUに完全に収まり、オフロードを回避できる場合があります。一方、さらに大きなモデルでは両方の手法が必要になることもあります。

適切な手順は、まず許容できる精度とモデル品質を決め、その後に配置方法を選ぶことです。不必要に大きな表現をオフロードすると、帯域幅を無駄に消費する可能性があります。

ピークスループットよりも、モデルを動作させることを優先する場合にCPUオフロードを使う

最も適しているのは、VRAM容量を超えるものの、状態の一部をRAMに置いても許容できるレイテンシーで実行できる、たまに使うローカルモデルです。すべてのトークンが低速なリンクを繰り返し通過する必要がある対話型のマルチユーザーサービスでは、あまり適していません。

ZimaSpaceのAI NASのメモリとアクセラレーター容量に関するガイドは、計画を立てる際の基準となります。オフロードは、ホームサーバー全体のワークロードにおける容量確保のための代替策として扱うべきです。

VRAM使用量、RAM使用量、ホストとデバイス間の転送バイト数、初回トークンまでの時間、毎秒の出力トークン数、その他のセルフホストサービスへの影響を測定してください。技術的には読み込めても、スワップを発生させたりNASを停止させたりする構成は、実用的な選択とはいえません。

ZimaSpaceのモデルの常駐と解放に関する解説では、関連するトレードオフを扱っています。アクセラレーターのメモリを解放すると他の処理に使える容量は増えますが、次のリクエストで再び読み込みや転送が必要になり、待ち時間が発生する可能性があります。

よくある質問

CPUオフロードによって、RAMとVRAMは1つの高速なメモリプールとして統合されますか?

いいえ。ランタイムはモデルの状態を両方の階層に配置できますが、CPU RAMとGPU VRAMでは帯域幅とレイテンシーが異なります。両者の転送が推論の主なボトルネックになることがあります。

RAMを増設すると、オフロードされたモデルは高速になりますか?

現在のシステムでRAMが不足していたり、ページングが発生していたり、意図したオフロード状態をRAMに常駐させられなかったりする場合に限り、速くなる可能性があります。未使用のRAMが増えても、PCIe転送やCPU実行にかかるコストはなくなりません。

SSDオフロードはCPUオフロードと同じですか?

いいえ。ディスクオフロードは、RAMが不足した場合にさらに低速なストレージ階層を追加します。容量をさらに拡張できますが、モデルのページはストレージから通常はシステムメモリを経由して、アクセラレーターで実行されるまで移動する必要があります。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.