CoreWeaveのAI専用インフラ課題

Corey SandersはPractical AIに出演し、CoreWeaveのAIインフラストラクチャアプローチについて、マイクロソフトで初期段階のAzure開発に携わった20年間の経歴に基づいて論じた。Sandersは中核的な問題をフレーミングした。AIアプリケーションの複雑性が増すにつれて、ウェブスケールアプリケーション用に設計された従来のクラウドコンピューティングはAIの独自の要求を効率的に対応することができない。彼はAI使用における2つの主要なストリームを特定した。トレーニング（OpenAI、Anthropic、Metaなどの組織によるモデルウェイトの作成）と推論（本番環境でこれらのモデルのデプロイと利用）である。トレーニングは非常に特定のインフラストラクチャを必要とする。大規模で高価なGPUデプロイメント、深く相互接続され協働するものを要求する。単一のGPUが障害を起こすか、ストレージを十分な速度でロードできない場合、トレーニング全体が遅延される——これは高価な結果である。なぜならトレーニング実行は高価なハードウェア全体で数十億の操作を伴うからである。従来のクラウドプラットフォームはこれを非効率的に処理する。需要急増時に反応的に計算をデプロイし、必要に応じてサーバーのラックを追加するために設計されていた。このアプローチはAIに対して機能しない。なぜなら、トレーニングクラスタは最初から事前デプロイされ、緊密に調整される必要があるからである。Sandersは、CoreWeaveがAIワークロードの従来クラウドにおける複数の非効率性ポイントを特定したと述べた。GPU障害、ストレージパフォーマンスボトルネック、ジョブオーケストレーション（どのジョブがどのインフラで実行されるかの決定）である。これらの問題の解決には、ハードウェアレベルの設計——GPUが物理的にどのようにレイアウトおよび相互接続されるか——とAIワークロード特性を理解するオーケストレーションソフトウェアの両方が必要である。CoreWeaveはこれに対応するために、可観測性とストレージを中心とした差別化されたサービスを構築している。Sandersの認識はマイクロソフトの最後の数年間に来た。彼はAIインフラストラクチャ最適化の議論に引き込まれていたが、公式には業界ソリューション（金融サービス、小売）に取り組んでいた。その経験——マイクロソフトがAIインフラストラクチャをどのようにデプロイしたか、そしてそれがどこで不足したかを目撃すること——は、AIインフラストラクチャが汎用クラウドの変種ではなく目的別プラットフォームを必要とするという彼の見方を結晶化させた。彼は回答の第2部を始めたが、Chrisが割り込むのを許した。その「ストーリーの後半」は推論とアプリケーションデプロイメントに対応する意図があり、トレーニング単独を超えたCoreWeaveのより広いエコシステムビジョンを示唆していた。

Sandersのフレーミングは、2000年代のクラウドコンピューティング変革と現在のAIインフラストラクチャの局面を直接的に並列化している。初期段階のAzureが従来のデータセンターに後付けするのではなくウェブスケールアプリケーション向けシステムを設計することで成功したのと同様に、CoreWeaveは特に大規模トレーニング実行において根本的に異なるハードウェアとオーケストレーション要件を持つAIワークロードという観察の周囲でポジショニングしている。重要な知見は、GPU障害、ストレージパフォーマンス、ジョブスケジューリングが全てトレーニング経済に異常な影響を与えることである。これは深く相互接続されたハードウェア全体で数十億の操作を実行する際の時間当たりの膨大なコストのためである。Sandersのマイクロソフトでの20年間は、この並列性を識別できる信用力を与えてくれる。彼はクラウド初期段階の移行を経験し、インフラストラクチャレベルの最適化（ハードウェア相互接続設計、可観測性、ストレージシステム）は機能追加ではなく基礎的なアーキテクチャ決定であることを認識している。これが彼が汎用クラウドからAIネイティブプラットフォームへ転向した理由を説明している——問題は段階的ではなく構造的に異なっているのである。「ストーリーの後半」（推論とアプリケーションデプロイメント）への言及は、CoreWeaveがトレーニングとデプロイメント両者を別個のベンダーの問題ではなく同じエコシステムの一部と見ています。

まだコメントがありません。最初のコメントを投稿しましょう！