Drew Pletcher, Principal Network Architect, Voltage Park

インフラストラクチャと製品チームのブリッジング：GenAIプラットフォームの構築から得られた教訓

疑う余地はない：ジェネレーティブAI、またはGenAIは、現在のトピックであり、過去2年間そうであった。目標はプロセスを自動化すること、ニュープロダクトデザインを生成すること、コンテンツを作成すること、またはドメイン全体の他の機能であるが、組織は今最も重要な作業を開始し、GenAI戦略を実行する時期である。GenAIの成功、研究からトレーニング、そして最終的に推論までのワークロードは、デプロイ、観察可能性、コスト管理、テレメトリ、基礎となるインフラストラクチャとサービスの待機時間ターゲットの周りの密接な調整に依存する。これらは、AIワークロードの達成可能な効率性を促進し、計算と通信のバランスを保ち、GPUが必要なデータを常に持っていることを保証する。課題は、構造的なギャップがあることである。インフラストラクチャエンジニアリングは、コンピュートとデプロイスタックに焦点を当てているが、ソフトウェアと製品チームは、GenAIを現実世界に導入するユーザー向けアプリケーションを構築することに集中している。両者のグループが完全に一致していない場合、納期の遅れ、パフォーマンスの問題、使いやすさの問題が生じることが多い。したがって、このギャップは現実世界ではどのように見え、組織はGenAIの成功のためにインフラストラクチャと製品チームを一致させるためにどのような戦略を使用できるか。不一致の問題インフラストラクチャと製品チームが不一致している場合、症状はしばしば明らかであるが、必ずしも十分に早く対処されるわけではない。非同期のチームの特徴的なものは、待機時間の期待またはモデル機能についての不一致した仮定である。たとえば、インフラストラクチャエンジニアリングチームは、実際のインフラストラクチャ設計が一致しないパフォーマンスレベルを仮定する機能またはデプロイを計画することがある。これにより、遅い段階での再作業、スコープの変更、納期の遅れが生じる。不一致は、非最適化されたインフラストラクチャにデプロイすることによっても生じることがあり、待機時間の変動とスケーラビリティの問題が生じ、トレーニングまたは大規模な分散型推論ジョブのパフォーマンスに影響を及ぼす。ダウンストリームのセキュリティとコンプライアンスのリスクも、チームの不一致の特徴的なものである。2つのチームの間での早期のコラボレーションの欠如により、データプライバシーとコンプライアンスの要件が見落とされる可能性があるためである。そして、チームの不一致は、ユーザーエクスペリエンスが悪化する原因となり、インフラストラクチャエンジニアリングチームは、制約が不明確な場合、ワークアラウンドに頼るようになり、イテレーションサイクルが遅くなり、テクニカルデットが増加する。もちろん、製品とインフラストラクチャチームの間の不一致は、どのソフトウェアプロジェクトでもコストのかかるものであるが、GenAIの場合、運用の非効率性の増加、競争上の優位性の低下、セキュリティリスクなど、賭けははるかに高い。成功へのブリッジGenAIの成功は、堅固なインフラストラクチャを持つことに加えて、インフラストラクチャと製品プロセスを結びつける戦術的なフレームワークを作成することに依存する。たとえば、GPUプロビジョニングの内部セルフサービスAPIのアイデアを考えてみよう。インフラストラクチャチームにとって、これらのAPIはアクセスを標準化し、チケットのオーバーヘッドを削減し、コンプライアンスを保証する。製品チームにとって、これらは、キューに待たずにコンピュートに迅速かつ予測可能にアクセスできることを提供する。結果として、両方のグループは同じAPI「契約」から作業し、ボトルネックを除去し、期待を明確にする。リアルタイムの使用状況ダッシュボードは、同様の役割を果たす。インフラストラクチャエンジニアには、システムの負荷と効率性の可視性を提供し、同時に製品チームには、ワークロードが実際の消費にどのように翻訳されるかを示す。両側が同じデータを参照しているため、パフォーマンスまたはボトルネックについての議論は、よりコラボレーション的で、より対立的ではなくなり、単一の真実の源となる。オートスケーリングは、もう1つの統一メカニズムである。インフラストラクチャエンジニアから常時の消防活動を解放し、製品開発者がワークロードのスパイク中にパフォーマンスの天井に当たらないことを保証する。もしそれがそうでない場合、安定性とアジリティの間の引張り合いとなるが、共同戦略となる。スケールは自動的に管理され、運用の回復力と製品のパフォーマンス目標の両方と一致する。最後に、コストの洞察は、共有されたビューに財務の次元を追加する。インフラストラクチャチームは割り当てを最適化し、容量プランニングを正当化することができ、製品チームは、アーキテクチャまたはモデル選択が費用にどのように影響するかを理解することができる。この透明性は、効率性を集団的な責任ではなく、個々の懸念としてではなく、共同の責任として促進する。しかし、調整には、共有ツールよりも共有ビジョンが必要である。ここで、共同のロードマップが重要になる。各チームは、上位の目標を理解するだけでなく、それを達成するために必要なステップを理解する必要がある。インフラストラクチャの場合、それはハードウェアとソフトウェアの深い技術的根底に焦点を当てるのではなく、開発者とエンドユーザーが実際にシステムをどのように体験するかとの関わりを持つことを意味する。製品チームの場合、それは待機時間、コスト、モデル効率などの制約に対する尊重を必要とする。イノベーションを持続可能にするための運用上の現実を評価する。最後に、どのようなパートナーシップでも、セキュリティとコンプライアンスへの相互のコミットメントがなければ継続できない。SOC2、HIPAA、ISOなどの特定の要件は、顧客ベースと業界の垂直方向によって異なるが、責任は共有される。インフラストラクチャと製品の両方のチームは、これらの義務を内面化し、コンプライアンスがチェックボックスの演習ではなく、ユーザーとの信頼の基盤であることを認識する必要がある。まとめると、これらの実践とマインドセットは、インフラストラクチャと製品を、共有された言語、共有された可視性、進歩、回復力、信頼性のための共有された責任性を持つ一貫したユニットに結び付ける。知識豊かなチーム正しいシステムを持つことと同じくらい、正しい人を持つことも重要である。理想的には、チームにはすでにGenAIを知っているメンバー、またはハイパフォーマンスコンピューティングとハイパースケールデータセンターのバックグラウンドを持つメンバーが含まれているべきである。本当に重要なのは、実践的な経験と、GPU-as-a-Serviceプラットフォームを構築してサポートすることから得られる教訓である。つまり、GPUがどのように互いに話しかけるか、どのように密接に結合されたトレーニングランが動作するか、待機時間、同期、データの配信に対してどのように敏感であるかを理解することである。モデルが成長し、デプロイが拡大するにつれて、チームは、顧客の全体的な旅について考える必要がある。初期の研究と実験から始まり、大規模なトレーニング、ファインチューニング、最終的に推論に移る。各段階は少し異なり、ニーズは途中で変化する。モデル開発の反復的な性質は、GenAIデータセンターを目的のために適切な状態に保つために必要なインフラストラクチャ、ワークフロー、機能について教えてくれる。インフラストラクチャと製品チームは、しばしば独自のバブルで動作する。GenAIを本格的に生産に導入しようとするどの会社にとっても、それが変わる必要がある。成功は、シロを打ち破り、プラットフォームの共有所有権を作成することに依存する。正しい人、明確なビジョン、実用的フレームワークがあれば、両側は同じプレイブックに一致することができ、それは彼らがより迅速に動き、責任を負い、最終的に成功したGenAIデプロイを提供するのを助ける。