AIアプリケーション向けホスティング：CPU、GPU、ストレージの容量設定

まずAIワークロードを絞り込む

ハードウェアの選定は、特定のGPUから始めるのではなく、課題から始めるものです。 推論 既存のモデルが入力を処理し、例えば回答を生成します。ファインチューニングは、事前学習済みのモデルを追加のデータやタスクに合わせて調整するものであり、一方、完全な学習は、独自の学習プロセスを通じてモデルの重みを構築するものです。

これらの目標により、負荷プロファイルはそれぞれ異なります。チャットサービスはリクエストに応答する必要がありますが、トレーニングジョブは長時間にわたってデータを処理し、中間結果を保存します。 AIホスティング そのため、応答時間、処理されたリクエスト数、トレーニング時間、あるいは特定のタスクにかかるコストなど、どの要素を重視するかを明確にしておくべきです。

モデルバージョンや実行時間、パラメータ数、アーキテクチャ、精度、および計画されている量子化について記録してください。 さらに、予想される入力および出力の長さ、同時リクエスト数またはバッチサイズ、ならびにピーク負荷についても記録してください。これにより、単なるハードウェアの仕様値を比較するだけでなく、同じ前提条件に基づいて見積もりやその後のテストを比較することが可能になります。

内部チャットアシスタントの場合、単一の短いリクエストなら問題なく処理できますが、複数の長い会話があるとメモリが不足してしまいます。KVキャッシュはテキスト生成時に追加の状態を保持しており、その必要量はモデルや処理内容などによって異なります。 したがって、平均的な対話だけでなく、長いコンテキストや並行利用も想定して計画を立てる必要があります。

また、どのデータが処理されるか、その保存場所、必要な可用性および復旧時間についても明確にしておく必要があります。これらの運用目標は、単一のサーバーを採用するか、より複雑なアーキテクチャを採用するかという選択に影響を与えます。これらの仮定はあくまで出発点に過ぎず、それが妥当かどうかは、代表的な負荷をかけた検証を行って初めて判明します。

開発中のCPUとRAM

モデルがGPU上で実行されている場合でも、CPUはデータパスに沿って連携して動作します。CPUはリクエストを受け付け、テキストをトークン化し、ファイルを読み込み、モデル処理のための入力を準備することができます。この準備作業が遅すぎると、GPUは処理を待たされることになり、より高性能なアクセラレータを導入しても、必ずしもそのボトルネックが解消されるとは限りません。

仝 ワーキングメモリ 用途に応じて、モデルコンポーネント、前処理済みのデータ、ファイルキャッシュを格納します。さらに、トレーニングデータを読み込んで変換するプロセス用のメモリも必要です。したがって、モデル自体だけでなく、データセットから完成したバッチに至るまでのプロセスも計画し、処理のピーク時に備えて十分な余裕を確保してください。

PyTorchのDataLoaderは、複数のワーカーを利用してデータを並列処理することができます。ただし、ワーカーが増えるとメモリ使用量も増加し、共有メモリ領域が不足する可能性もあります。そのため、一律の推奨値を採用するのではなく、ワーカーの数を段階的に増やしながら、データの待ち時間やメモリ使用量を注意深く監視するようにしてください。

CPUコア数が増えることは、特に処理対象のタスクを並列実行できる場合に効果を発揮します。一方、ストレージへのアクセス、単一の処理ステップ、あるいはGPU自体がスループットを制限している場合、コア数を増やしてもほとんど効果はありません。また、クロックの挙動も短いクエリにおいては重要になる場合があります。この点に関する詳細は、以下の記事で解説されています。 ホスティングサーバーにおけるCPUガバナー.

小規模なモデルや稀なリクエストの場合、常時稼働のGPUシステムに代わる選択肢として、CPU推論を検討する価値があります。同じモデル、適切な精度、および予想される負荷プロファイルを用いて、両方の方式を比較してください。 重要なのは、ピーク時であってもCPUが要求される応答時間を達成できるかどうか、そして実際にどの程度のコストが発生するかという点です。

GPUとVRAMを正しく理解する

完全にGPU上で実行される推論の場合、モデルの重みは利用可能なGPUメモリ内に収まる必要があります。その VRAMの必要量 しかし、それだけではありません。実行時には、中間結果や一時的なバッファ用にさらに領域が必要となります。したがって、計算上ちょうど重みが収まるマップであっても、本番運用における確実な基盤とはなり得ません。

自己回帰型テキスト生成では、KVキャッシュが追加されます。これは、すでに計算済みのキーと値の状態を保存し、その後の生成ステップで再利用できるようにするものです。長いコンテキストや同時に処理されるクエリにより、この追加のメモリ要件が増加する可能性があります。その増加幅は、モデルや処理方法によって異なります。

Transformers 4.48.2のドキュメントでは、VRAMを節約する方法として、キャッシュの量子化やスワップアウトなどが説明されています。ただし、その効果は実装方法や負荷によって異なります。追加の処理やデータ転送により、速度が低下する可能性があります。 したがって、メモリの節約を自動的にパフォーマンスの向上とみなすのではなく、メモリ使用量と応答時間を併せて検証する必要があります。

トレーニングにおいては、推論計算だけでは到底不十分です。 重みに加えて、勾配、オプティマイザーの状態、保存された活性化値のためのメモリ要件が発生します。これらの割合がどの程度になるかは、オプティマイザー、精度、学習手法などによって異なりますが、特に長いシーケンスや大きなバッチは、活性化値のメモリ使用量を増加させる可能性があります。

完全にGPU上で実行するには、利用可能なVRAMが、必要な重みと実行時データを収容できる必要があります。 ハイブリッド手法では、処理の一部やモデルの重みをGPU外に保持することができますが、その適性やデータ転送のコストは実行時間に依存します。これは、Transformers 4.48.2で説明されているKVキャッシュのアウトオブメモリ処理とは区別する必要があります。

モデル、実行時間、および計画された並列処理を総合的に検討し、代表的な負荷条件下でのメモリ使用量のピーク値を確認してください。選択した実行方式に対して十分なメモリ容量を確保しているからといって、必ずしも望ましい応答時間や利用率が保証されるわけではありません。

モデルメモリの概算を算出する

最初のメモリ計算は、モデルパラメータの数と、その重みが実際に保存される形式から始まります。これにより、メモリ使用量の下限値は得られますが、GPUサーバーの完全な仕様決定には至りません。特に、実行時に具体的なリクエストがどれだけのメモリを必要とするかについては、この計算からは分かりません。

説明用の計算例であり、実際の測定結果ではありません： 70億個のパラメータに2バイトを掛けると、重みの合計は140億バイトになります。 これを1 GiBあたり1,073,741,824バイトで割ると、約13.0 GiBとなります。ただし、これは対象となるすべての重みが、実際にパラメータ1つあたり2バイトという統一された形式で存在することを前提としています。他の形式や追加の表現形式がある場合は、この計算結果が変わってきます。

以下は含まれていません： KVキャッシュ テキスト生成、一時バッファ、および実行時のオーバーヘッドのためです。特にコンテキストが長い場合、キャッシュは大幅に肥大化する可能性があります。また、同時に処理されるリクエストの数も、必要な予備容量に影響します。 また、Transformers 4.48.2のキャッシュに関するドキュメントには、メモリを節約できる手法も記載されていますが、手法によっては処理速度が低下する場合があります。

トレーニングに関しては、重みの計算量だけでは到底不十分です。『Transformers 4.35.0』のドキュメントによると、AdamW を使用した混合精度構成の例では、パラメータ1つあたり18バイトに加え、活性化関数の分も必要とされています。 これには、勾配やオプティマイザーの状態といったその他の要素も反映されています。活性化関数のサイズは、シーケンスの長さやバッチサイズなどによって異なります。

この18バイトは、あらゆるトレーニングに適用される一般的な乗数というわけではありません。オプティマイザー、精度、およびトレーニング手法によって、必要な容量は変化する可能性があります。したがって、この数値や13.0 GiBという数値から、特定のVRAM容量を推奨するものではありません。 選択にあたっては、具体的な実行時間と、代表的な負荷条件下での予想されるメモリ使用量のピーク値が決定的な要素となります。

ワークロードとボトルネックの比較

同じモデルの重みであっても、タスクによって非常に異なる要件が生じる場合があります。この表は、考えられる検証ポイントを示したものであり、優先順位を示すものでも、ボトルネックが確実に発生することを保証するものでもありません。実際にどのリソースがボトルネックとなるかは、モデル、データパイプライン、並列化、負荷などの要因によって異なります。

社内チャットアシスタントの場合、モデルと生成機能は計画の一部に過ぎません。 最大入力長、想定される出力長、および同時接続ユーザー数を設定します。その後、ピーク負荷時でも応答時間が許容範囲内であるか、また重み付け、キャッシュ、バッファが利用可能なメモリに同時に収まるかどうかを確認できます。

生成型応答を伴うドキュメント検索では、データ処理の経路が長くなります。ドキュメントをインポートして前処理を行い、埋め込みベクトルを生成し、インデックスを検索して、関連するコンテンツを言語モデルに渡すという一連の処理が行われます。 インポートと検索には、生成処理とは異なるCPU、RAM、ストレージの要件が求められる場合があります。そのため、これらのステップにかかる時間とメモリ要件を個別に把握しておくことが重要です。

微調整の際には、 勾配蓄積 同時に処理される個々のバッチは小さいものの、実質的なバッチサイズを大きくすることができます。パラメータが更新される前に、複数のステップの勾配が蓄積されます。これはメモリが限られている場合に役立つ可能性がありますが、スループットの向上が保証されるわけではありません。追加の処理ステップには時間がかかる場合があります。

データ供給についても、別途検討する必要があります。前処理や読み込みがモデル処理の速度に追いついていない場合、GPUの性能を向上させても必ずしも効果はありません。逆に、高速なデータパイプラインであっても、VRAMの容量不足を補うことはできません。したがって、代替案を比較する際は、同じ入力データと、明確な負荷プロファイルに基づいて行う必要があります。

ストレージとGPUの接続を計画する

ストレージの計画においては、データの種類とアクセス方法に応じて区分することが重要です。トレーニングデータセットは繰り返し読み込まれ、モデルの重みは使用前に読み込まれます。どちらも、ホストが変更された後も再提供できる信頼性の高いソースが必要です。容量だけでは不十分であり、読み込み時間やアクセスパターンも運用に影響を与えます。

高速な作業領域が必要な場合、一時的な作業データはローカルのNVMeに保存することができます。これらのデータが再起動やホストの変更を乗り切れるかどうか、プロバイダーに確認してください。 一方、チェックポイントやバックアップについては、綿密に計画された保存方法と検証済みの復元手順が必要です。ローカルのスクラッチディレクトリは、必ずしも独立したバックアップとは限りません。

共有ストレージやオブジェクトベースのストレージを利用することで、データセット、重み、チェックポイントの分散や保存が容易になります。 重要なのは、アプリケーションが選択したアクセス方式に対応しているかどうか、および所定の時間内にデータの読み込みと復元が可能かどうかです。追加のローカルワークスペースを設けることは有効ですが、恒久的な保存の代わりにはなりません。

GPUDirect Storage 適切なハードウェア、ソフトウェア、およびファイルシステムの環境下では、ストレージとGPUメモリ間のデータパスがより直接的になります。 これは、入出力がクリティカルパスに位置し、アプリケーションがサポートされているパスを利用している場合に特に有用です。CPUがまずデータをデコードしたり前処理したりする必要がある場合、その利点は限定的となる可能性があります。

複数のGPUを使用する場合、レプリケーションと分割を区別する必要があります。レプリケーションは、リクエストを分散させるためにモデルのコピーを用意するものであり、個別のVRAM領域を自動的に共有メモリにするものではありません。 vLLM 0.20.1のドキュメントでは、このようなデータ並列プロビジョニングについて説明されていますが、これは他の実行時バージョンについては何ら言及するものではありません。

一方、テンソル並列処理やパイプライン並列処理は、処理の一部を分散させるため、通信の必要性が生じます。そのため、GPU間の接続、および複数のサーバーを使用する場合はネットワークトポロジー、さらにモデルやランタイムによるサポート状況を確認してください。 vLLM 0.8.5のドキュメントでは、分散サービングに関するこれらの戦略について解説しています。具体的な注意事項はバージョンに依存します。

負荷時のボトルネックを特定する

有意義な比較は、記録されたデータから始まる 負荷プロファイル. モデルバージョン、精度、具体的なハードウェアの機種およびランタイムのバージョンを記録しておく。また、典型的なコンテキスト長と最大コンテキスト長、出力長、および同時リクエスト数も追加で記載する。これにより、将来インフラストラクチャを変更する際、同じ条件下での動作を確認できるようになる。

推論処理において、最初のトークンが生成されるまでの時間と生成速度を測定してください。また、通常の負荷時および予想されるピーク時のエラーや応答時間も記録してください。コンテキストが長かったり並列度が高かったりする場合、個々のリクエストの待ち時間が長すぎたり失敗したりするようでは、平均スループットが高いだけでは不十分です。

トレーニングや微調整を行う際は、時間単位あたりのステップ数や処理済みのサンプル数を出発点として設定するとよいでしょう。 併せて、データパイプラインが次のバッチをどのくらいの時間待機させるかを確認してください。PyTorchのDataLoaderは複数のワーカーを使用してデータを準備できますが、そのメモリ使用量や共有メモリへの負荷も評価の対象となります。

GPUメモリおよびRAMの使用率のピーク値、ならびにストレージの使用率と待ち時間を計測します。既存のNVIDIAシステムでは、読み取りコマンドは次のように表示されます。 nvidia-smi デバイスやドライバによっては、GPUの状態やメモリ使用状況などが表示されます。本番環境の設定を変更することはありませんが、アプリケーションによる測定に代わるものではありません。

GPUの使用率が低いこと自体は、それだけではCPUやストレージの問題を意味するものではありません。 データ待ち時間、リクエストの推移、ストレージ使用状況と時間軸で比較し、比較ごとに可能な限り関連する要素を1つだけ変更するようにしてください。また、まれな負荷のピークや特に長い入力などがテストに含まれていない場合など、テストの限界についても記録してください。

AIインフラを安定して運用する

運用計画には、GPUのバリエーション、ドライバー、フレームワーク、およびモデルランタイムの、検証可能な組み合わせが含まれます。アップデートを行う前に、どのバージョンが互いにサポートされているか、また問題が発生した場合に以前の組み合わせに戻す方法を明確にしておきましょう。GPUDirect Storageのような特殊なデータパスでは、ハードウェア、ソフトウェア、ファイルシステムも、想定される用途に適している必要があります。

モデル、トレーニングデータ、ログ、管理インターフェースを誰が閲覧または変更できるかを明確に定めてください。また、機密性の高い入力データについては、保存場所、データ転送、保存期間をデータ保護要件と照らし合わせて確認する必要があります。これらの点は、モデルが実行されているサーバーだけでなく、関与するすべてのサービスについて確認してください。

A チェックポイント 後の再開に備えてトレーニングの状態を保存します。トレーニングソフトウェアがこれのためにどのような状態を必要とするか、どのくらいの頻度で保存されるか、そしてどのくらいの期間保持されるかを計画してください。デプロイ用のモデル重みと、再開用のチェックポイントはそれぞれ異なる目的を果たすため、それに応じて適切にラベル付けする必要があります。

ローカルの作業用ストレージは、必ずしも永続的なものではなく、独立したバックアップの代わりにはなりません。再起動時、ホストの交換時、または契約終了時にローカルデータがどうなるかについては、プロバイダーに確認してください。必要なデータは作業環境とは別に保管し、復旧が実際に可能かどうか、および再び利用可能になるまでの時間を含めて確認してください。

分散ジョブの場合、モニタリングの対象は個々のGPUだけでなく、ノード、ネットワーク接続、およびアプリケーション全体の進捗状況も含まれます。 障害発生後にジョブをどの保存時点から再開するか、またそのためにどのリソースが利用可能である必要があるかを計画してください。モデルの一部が複数のサーバーに分散している場合、それらの接続状況も動作に影響を与えます。vLLMドキュメント0.8.5に記載されている注意事項は、バージョンに依存するものです。

ホスティングモデルとGPUサーバーの選択

不定期の仕事の場合、一時的に配置される GPUサーバー 理にかなっている：常に容量を確保しておくのではなく、必要な提供内容に応じた具体的な契約条件に基づいて料金を支払うことになる。その際、開始時期、希望する時点での利用可能性、および保存データやデータ転送にかかる費用も比較検討しよう。

負荷が均一な場合、恒久的に予約されたインフラストラクチャを自前で運用することは有効です。これにより、実行時間やデータパスをより細かく制御できますが、更新、監視、復旧については独自の計画が必要となります。 マネージド推論サービスは、こうした運用の一部を代行してくれます。その一方で、そこで実際に利用可能なモデル、設定、データパスがどのようなものかを確認してください。

機械学習インフラストラクチャの選定にあたっては、以下の情報が必要です。 特定のGPUモデル VRAM容量、メモリ帯域幅、対応演算形式、およびフォームファクタ。製品ファミリーの最大値を、検証せずにすべてのバリエーションにそのまま適用してはならない。性能仕様については、理論上のピーク値だけで判断するのではなく、そのテスト条件および対象モデルと比較して評価すること。

スケーリング方式も提供内容に含まれます。レプリケートされたインスタンスはリクエストを分散できますが、モデルの分割には実行時間と接続トポロジによるサポートが必要です。 vLLMのドキュメントでは、バージョン0.20.1でデータ並列処理、バージョン0.8.5で分散サービングについて解説しています。これらの記述は、確認なしに他のバージョンに適用すべきではありません。

まずモデルと負荷プロファイルを定義し、次にストレージとデータパスを推定して、適切な見積もりを取り寄せます。その後、代表的なクエリやトレーニングデータを用いて、応答時間、エラー、リソース要件を確認します。分類に関するその他の点については、 Webアプリケーション向けGPUホスティング。このワークロード比較なしでは、普遍的に適用できるGPUの推奨事項を導き出すことはできません。