要約

  • AWSは9月11日、HyperPod向けにモデルの重みとコンテナイメージのキャッシュを発表した。個別に有効化でき、文書上はいずれも初期設定で無効となる。
  • 重みはノードごとに保存される。準備済みノードへの配置は優先されるが必須ではなく、新規・交換ノードでは元の保存先からの取得が残る。

推論処理を増やすとき、買っているのは計算能力だけではない。追加したレプリカが要求に応答する前に、コンテナイメージとモデルの重みをそろえる時間も必要になる。Amazon SageMaker HyperPodの新機能は、すでに準備を済ませたノードで同じダウンロードを繰り返す負担を減らそうとするものだ。

9月11日の発表は二つの機能を分けている。重みキャッシュは、Amazon S3やAmazon FSxから繰り返し取得する代わりに、ファイルをノード内のNVMeへ保存する。イメージキャッシュは推論コンテナを先に取得し、その後の起動時に冷状態からダウンロードする工程を省く。推論オペレーターで片方だけ、または両方を有効にできるが、設定項目があるだけで有効になるわけではない。

AWSは57～145 GBのモデルを使ったベンチマークで、スケールアウトが約60%速くなったとする。別の指標として、イメージ取得にかかる時間を2分超、同工程の97%削減したという。測っている区間が異なるため、二つの比率は合算できない。利用者の要求全体の遅延や、顧客の請求額が同じ割合で減るとする結果でもなく、本稿が独自に再測定した値ではない。

重みキャッシュの前提は、指定した場所にローカルNVMeがあり、十分な空き容量を持つインスタンスであることだ。EBSのみのインスタンスはこの重みキャッシュに対応しない。条件が合わなければ、重みは引き続き遠隔の保存先から読み込まれうる。コンテナイメージだけが準備済みでも、重みの準備完了を示すことにはならない。

効果を分けるのが配置先だ。オペレーターはデプロイの配置条件を満たすノードを事前準備し、完了したノードへラベルを付ける。推論処理はそれらのノードを優先するが、別のノードにも配置できる。Kubernetesの説明でも、優先的なノードアフィニティは他の配置要件と組み合わせる選好であり、代替配置を全面的に禁じる条件ではない。これは一般的な意味の説明で、HyperPodのKubernetesバージョンを特定するものではない。

したがって、キャッシュを有効にした一つのデプロイでも、ローカルファイルを使う経路と、元の保存先から取得する経路が併存する。未準備ノードでは後者へ戻れるため、キャッシュの準備完了は必須条件ではなくなる。ただし、保存元への接続が不要になるわけではない。AWSの対処文書には、ダウンロード失敗やS3、FSxへの到達不能も挙げられている。

ノードを交換した場合も、新しいノードでは準備をやり直す。文書にある場面では、既存の準備済みノードは処理を継続する。しかし、ディスクに重みがあることは、GPUメモリへの読み込み完了や、次の需要急増に使える余剰能力を意味しない。キャッシュ完了ラベルの数だけでは、応答可能な処理能力は分からない。

保存先の分離にも限界がある。各デプロイは独立したキャッシュディレクトリを使う一方、同一ノードのNVMe容量をそれぞれ消費する。AWSは容量逼迫時に、インスタンスグループを分ける方法や、同時にキャッシュするデプロイを減らす方法を示す。これは文書上の運用条件で、実際の顧客障害を報告しているのではない。

AWSによれば、機能はHyperPodが提供される全リージョンで一般提供される。価値を左右するのは設定の有無より、条件に合う準備済みノードをどれだけ再利用できるかだ。

出典