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

疑う余地はない：ジェネレーティブAI、またはGenAIは、現在のトピックであり、過去2年間でそうであった。目標はプロセスを自動化すること、ใหมの製品デザインを生成すること、コンテンツを作成すること、または他のドメインでの機能など、組織は最も重要な作業を始め、GenAI戦略を動かすべき時である。

GenAIの成功は、研究からトレーニングまで、そして最終的に推論まで、デプロイ、観測可能性、コスト管理、テレメトリ、レイテンシーターゲットの下にあるインフラストラクチャとサービスの密接な調整に依存する。これらは、AIワークロードの実現可能な効率性を推進するのに役立つ。計算と通信のバランスを保ち、GPUが必要なデータを常に持つことを保証する。

課題は、構造的なギャップがあることである：インフラストラクチャエンジニアリングはコンピュートとデプロイスタックに焦点を当てているが、ソフトウェアと製品チームは、GenAIを現実世界に持ち込むユーザー向けアプリケーションを構築することに集中している。これらのグループが完全に整列していない場合、遅延、パフォーマンスの問題、ユーザビリティの問題が頻繁に発生する。

では、このギャップは現実世界ではどのように見え、組織はGenAIの成功のためにインフラストラクチャと製品チームを整列させるためにどのような戦略を使用できるか。

整列していないことの問題

インフラストラクチャと製品チームが整列していない場合、症状は明らかであるが、必ずしも迅速に解決されるわけではない。整列していないチームの特徴的な特徴は、レイテンシ予想またはモデル能力についての誤った仮定の不一致である。たとえば、インフラストラクチャエンジニアリングチームは、実際のインフラストラクチャ設計が一致しないパフォーマンスレベルを仮定して、機能またはデプロイを計画する可能性がある。これにより、後期の再作業、スコープの変更、納期の遅れが発生する。

整列していないことは、非最適化されたインフラストラクチャにデプロイすることにより、パフォーマンスの低下、レイテンシの変動、スケーラビリティの問題が発生する可能性がある。ダウンストリームのセキュリティとコンプライアンスのリスクも、チームの整列していないことの特徴である。両方のチーム間の初期のコラボレーションの欠如により、データプライバシーとコンプライアンスの要件が見落とされる可能性がある。

最後に、チームの整列していないことにより、ユーザーエクスペリエンスが低下し、インフラストラクチャエンジニアリングチームは、制約が不明確な場合、ワークアラウンドに頼るようになり、イテレーションサイクルが遅くなる。もちろん、製品とインフラストラクチャのチームの整列していないことによるコストは、どのソフトウェアプロジェクトでも高くなるが、GenAIの場合、運用の非効率性、競争上の優位性の低下、セキュリティリスクなど、より高い賭けがかかっている。

成功へのブリッジ

GenAIの成功は、堅固なインフラストラクチャを持つことだけでなく、インフラストラクチャと製品プロセスをリンクする戦術的フレームワークを作成することにも依存する。たとえば、GPUプロビジョニングの内部セルフサービスAPIのアイデアを考えてみよう。インフラストラクチャチームの場合、これらのAPIはアクセスを標準化し、チケットのオーバーヘッドを削減し、コンプライアンスを保証する。製品チームの場合、これらのAPIは、キューに待たずに、計算リソースへの迅速で予測可能なアクセスを提供する。結果として、両方のグループは同じAPI「契約」から作業し、ボトルネックを除去し、期待を明確にする。

リアルタイムの使用状況ダッシュボードも同様の役割を果たす。これらは、インフラストラクチャエンジニアにシステムの負荷と効率性の可視性を提供し、同時に製品チームに、ワークロードが実際の消費にどのように翻訳されるかを示す。両方の側面が同じデータを表示しているため、パフォーマンスまたはボトルネックに関する議論は、より協力的なものとなり、対立的なものではなくなり、単一の真実の源となる。

自動スケーリングは、もう1つの統一メカニズムである。インフラストラクチャエンジニアから常時の消防活動を解放し、製品開発者がワークロードのスパイク中にパフォーマンスの天井に当たらないようにする。安定性とアジリティの間のトレードオフは、共同戦略となる。スケールは自動的に管理され、運用の回復力と製品のパフォーマンス目標の両方と一致する。

最後に、コストの洞察は、共有ビューに財務的側面を追加する。インフラストラクチャチームは割り当てを最適化し、容量計画を正当化することができ、製品チームは、設計またはモデル選択が費用にどのように影響するかを理解することができる。この透明性は、効率性を集団的な責任として、隠れた懸念ではなく、共同の責任として促進する。

しかし、整列には共有ツールだけでなく、共有ビジョンも必要である。これは、共同ロードマップが必要な場所である。各チームは、上位レベルの目標を理解するだけでなく、それを達成するために必要なステップも理解する必要がある。インフラストラクチャの場合、これはハードウェアとソフトウェアの深い技術的ルーツを超えて、開発者とエンドユーザーがシステムを実際にどのように体験するかを関与することを意味する。製品チームの場合、これは、レイテンシ、コスト、モデル効率などの制約を尊重することを意味する。運用的現実を理解することで、イノベーションを持続可能にする。

最後に、どのようなパートナーシップも、セキュリティとコンプライアンスに対する相互のコミットメントなしには持続できない。SOC2、HIPAA、ISO、またはその他のフレームワークが適用されるかどうかは、顧客ベースと業界の垂直性によって異なるが、責任は共有される。インフラストラクチャと製品の両方のチームは、これらの義務を内部化し、コンプライアンスはチェックボックスの演習ではなく、ユーザーとの信頼の基盤であることを認識する必要がある。

これらの実践とマインドセットをまとめると、インフラストラクチャと製品は、共有言語、共有の可視性、進歩、回復力、信頼性のための共有の説明責任を持つ統一されたユニットになる。

知識豊かなチーム

正しいシステムを持つことと同じくらい、正しい人を持つことも重要である。理想的には、チームにはすでにGenAIを知っているメンバー、または高性能コンピューティングとハイパースケールデータセンターのバックグラウンドを持つメンバーが含まれている必要がある。本当に重要なのは、実践的な経験と、GPU-as-a-Serviceプラットフォームを構築してサポートすることから得られる教訓である。つまり、GPUがどのように互いに通信するか、タイトに結合されたトレーニングランがどのように動作するか、そしてどのようにレイテンシ、同期、データの配信に敏感であるかを理解することである。

モデルが成長し、デプロイがスケールアップするにつれて、チームは顧客の全体的なジャーニーについて考える必要がある。早期の研究と実験から始まり、大規模なトレーニング、次にファインチューニング、最終的に推論に至る。各段階は少し異なり、ニーズは途中で変化する。モデル開発の反復的な性質は、GenAIデータセンターを目的のために適合させるために必要なインフラストラクチャ、ワークフロー、機能について教えてくれる。

インフラストラクチャと製品チームは、しばしば独自のバブルの中で動作する。GenAIを本格的に生産に移すことを真剣に考えている企業の場合、これは変化しなければならない。成功は、シロを打ち破り、プラットフォームの共有所有権を作成することによって依存する。正しい人、明確なビジョン、実用的なフレームワークを持つと、両側は同じプレイブックに整列することができる。そうすることで、より迅速に進み、説明責任を持ち、最終的に成功したGenAIのデプロイを提供することができる。