アンスケールのフィールドCTO、クリスチャン・スタノ氏 – インタビュー・シリーズ

クリスチャン・スタノ氏は、アンスケールのフィールドCTOであり、大規模AIインフラストラクチャ、機械学習プラットフォーム、分散コンピューティングの交差点でキャリアを築いてきました。アンスケールに入社する前、アテンティブではAI/MLプラットフォーム組織を率いて、5億人以上のユーザーに対するパーソナライゼーションをサポートするインフラストラクチャを拡大し、開発速度を向上させつつ運用コストを削減するRayベースの統一コンピュートシステムの採用を推進しました。彼のキャリアは、AIプラットフォームエンジニアリング、MLOps、クラウドネイティブインフラストラクチャ、開発者エンゲージメント、組織スケーリングにわたっており、企業がAIを本格的に導入する際に深い経験を積んでいます。

アンスケールは、Rayの背後にある企業であり、Rayは、CPUとGPUのクラスタを横断してAIおよびPythonワークロードをスケーリングするために広く使用されているオープンソースの分散コンピュートフレームワークです。UCバークレーのRISELabからRayのオリジナルクリエイターによって設立されたアンスケールは、大規模AIインフラストラクチャの展開、オーケストレーション、管理を簡素化することに重点を置いています。トレーニング、推論、データ処理、エージェントAIワークロードのための分散AIシステムをクラウドとオンプレミス環境で実行できるようにするプラットフォームを提供し、モダンAIアプリケーション向けに設計された観測可能性、ガバナンス、パフォーマンス最適化を提供します。Rayは、開発者がPythonコードを変更せずにワークロードを単一マシンから数千ノードにスケールできるようにすることで、エマージングAIインフラストラクチャスタックの重要なレイヤーとなっています。

サイバーセキュリティ、パブリックセクタのMLプラットフォーム、ハイパースケールパーソナライゼーションシステムなど、さまざまな分野でご経験があります。組織がAIのパイロットプロジェクトから本格的な導入に移行する際に、どのようなパターンが一貫して見られる傾向にありますか。

業界を問わず、3つのパターンが繰り返し現れます。第一に、開発から本格的な導入までの信頼できるプロセスが存在しません。ノートブックでモデルを構築できますが、それを本格的に稼働させるための標準化された方法がありません。毎回の展開が一意であり、毎回の失敗が予期せぬものとなります。第二に、インフラストラクチャが必要なスケールに応じられません。パイロットプロジェクトで機能したシステムが、実際のデータ量やトラフィックに耐えられないことがあります。第三に、チームは状況を把握できません。システムの実際のパフォーマンス、どこで問題が発生するか、いつ介入すべきかを知ることができません。

これらの問題の根底にあるのは、スケールアップに対する健全なメンタルモデルが存在しないことです。チームはすべてを一度に解決しようとするのではなく、優先順位をつけて段階的に進めるべきです。私はこれを3つのフェーズに分けます：動くようにする、正しくする、速くする。これらのフェーズは、一度のマイルストーンではなく、繰り返し行われるプロセスです。チームは、どのフェーズにいるかを理解し、基盤が固まらない内に先に進もうとしないよう、自制する必要があります。

アンスケールでは、さまざまな段階でチームが訪れます。いくつかのチームはまだ「動くようにする」段階にあり、開発から本格的な導入までの信頼できるプロセスが必要です。他のチームはそのプロセスを持っていますが、運用の複雑さに溺れており、「正しくする」段階にあります。さらに多くのチームは、機能するシステムを構築しましたが、ビジネスが要求するスケールに到達できないために、アンスケールに来ます。統一されたコンピュートレイヤーは各段階で役立ちますが、エントリーポイントは、痛みが最も激しい場所によって決まります。

アテンティブでは、数百万人のユーザーをサポートするAIシステムのスケールアップを担当しました。どのようなアーキテクチャ上または組織上のボトルネックに直面し、どのようにしてそれを克服しましたか。

最も大きなボトルネックは、インフラストラクチャの複雑さのSカーブでした。モデルにさらに多くのデータを組み込んで、より多くの顧客にサービスを提供するにつれて、コンピュートのインフレクションポイントに達し、垂直にスケールアップしたノードでさえもメモリ不足エラーが発生し、ナイーブな水平スケーリングでは対処できませんでした。コンピュートがデータのスケールに追いつかなくなりました。

自然な対応は、限界を回避するためにさらに多くのツールを追加することでした。これは、私の前の経験から導かれた内部的なプレイブックでした。各ツールは狭い問題を解決しましたが、運用の複雑さを追加しました。MLパイプラインは、パッチワークの統合になりかねない状況にあり、各新しいユースケースはさらに多くの接続、失敗モード、コスト、プラットフォームチームの負担をもたらしました。

最終的に私たちをスケールアップさせたのは、Rayとアンスケール上でデータ処理、トレーニング、推論、サービスを統一することでした。影響は即時でした：インフラストラクチャコストが大幅に低減され、トレーニングサイクルが短縮され、データ量が増えてもモデルを顧客数のオーダーにスケールアップできるようになりました。

アンスケールに入社する際の動機と、Field CTOとしての役割についてお話しください。また、アンスケールのプラットフォームを通じてRayの採用が進む中で、統一されたアプローチを採用する組織と、断片的なツールを組み合わせる組織の違いについてはどう見ていますか。

アテンティブでアンスケールを導入した経験は、私のMLプラットフォーム構築のプレイブックを根本的に変えました。以前は、断片的なシステムを組み合わせるためのプラットフォームエンジニアリングが大部分を占めていました。アンスケールでは、そのようなオーバーヘッドを排除し、代わりに開発者エクスペリエンス、信頼性、パフォーマンスに焦点を当てることができました。その変化は、チームの生産性とシステムの成果に大きな影響を与えました。アンスケールに入社することは、その問題にフルタイムで取り組み、他の組織が同様の移行を乗り越えるのを支援する機会でした。Field CTOとしての私の役割は、現場でのレッスンを繰り返し適用可能なパターンに変えることです。

企業がAIのパイロットプロジェクトから本格的な導入に移行する際に、どのような点が具体的に壊れやすい傾向にありますか。

企業がAIの実験から本格的な導入に移行する際に、壊れるのはモデルだけではありません。周囲のシステムや運用も壊れやすいです。場合によっては、チームはインフラストラクチャの限界に早期に遭遇し、必要なスケールでトレーニングやサービスを提供できないことがあります。モデルが対応できる顧客数やユースケースを制限する必要があることがあります。より多くの場合、運用での予期せぬエッジケースやデータの変化によって問題が発生します。最も一般的な障害点の1つはメモリです。データのサイズ、分布、またはモダリティが変化すると、ジョブがメモリ不足となり、失敗します。これらの問題は予測が難しく、自動回復も困難です。実際には、運用での失敗は避けられません。目標はそれを完全に避けることではなく、迅速に検知し、理解し、自己回復システムを構築してビジネスに影響を与える前に解決することです。

アンスケールの背後にある分散コンピューティングフレームワークであるRayが、AIワークロードの基盤として注目されている理由についてお話しください。

分散実行とワークロード管理は、AIパイプラインのためのテーブルステークスとなりました。モダンAIワークロードは、基本的に並列でリソースを大量に消費します。トレーニング、推論、データ処理はすべて、CPUとGPUの大量のタスクを動的に調整する必要があります。今日のコンピューティングランドスケープでは、これらのワークロードを管理する複雑さは、運用上の大きな負担となります。従来のシステムはこのレベルの複雑さやスケールに設計されていません。Rayのようなフレームワークは、チームが単一マシンから数千ノードにワークロードをスケールアップできるようにすることで、基盤となる調整を自動化することができるため、重要です。この変化は、AI専用のコンピューティングへの移行を反映しており、インフラストラクチャはAIワークロードのパターンに特化して設計されるのではなく、古いパラダイムから適応されるのではなく、AIワークロードのパターンに特化して設計されるようになっています。

アンスケールのプラットフォームを通じてRayの採用が進む中で、統一されたアプローチを採用する組織と、断片的なツールを組み合わせる組織の違いについてはどう見ていますか。

統一されたプラットフォームと断片的なツールの違いは、最終的にフォーカスと効率性に帰結します。チームが複数の切り離されたシステムに頼る場合、システムを接続する時間、不一致を管理する時間、異なる環境での障害に反応する時間を費やします。これは、運用上のオーバーヘッドを生み出し、実験を遅らせます。一方、統一されたアプローチでは、チームは単一のシステムを改善することに集中できます。これにより、信頼性、パフォーマンス、開発者エクスペリエンスが向上します。また、オンコールとデバッグプロセスも簡素化され、パターンは一貫性があり、理解しやすくなります。結果は、技術的な効率性のみではなく、組織的な明確性にもなります。

エンドツーエンドのMLプラットフォーム構築における経験から、開発者エクスペリエンス（DevEx）がAIの採用を加速する上でどれほど重要かについてお話しください。

開発者エクスペリエンスは、AIの採用を加速する上で最も高レバレッジの領域の1つです。プラットフォームチームが、標準化されたワークフロー、テンプレート、インフラストラクチャの摩擦の軽減に投資することで、システムを使用しやすくすると、組織内のすべてのエンジニアの生産性が増幅されます。これは、特にAIのように変化のペースが非常に速い分野で、チームが競争力を維持するために迅速に反復する必要があるため、特に重要です。開発者エクスペリエンスの改善は、実験の高速化、プロダクションへの迅速な移行、最終的にビジネスへの影響に直接つながります。AIコーディングツールは、これらの基本的な開発者エクスペリエンスを増幅します。多くの場合、これは組織全体の速度を上げる最もスケーラブルな方法です。

AIワークロードがスケールアップするにつれて、コスト効率が大きな懸念事項となります。企業がパフォーマンスを犠牲にすることなくインフラストラクチャコストを削減できる、最も見過ごされやすい方法についてお話しください。

AIワークロードがスケールアップするにつれて、コスト管理は重要性と複雑さの両方で増大します。最も見過ごされやすい課題の1つは、GPUベースのインフラストラクチャにおけるコストの急増です。大量のクラスタが数千のノードをスピンアップし、リソースが適切に管理またはシャットダウンされていない場合、コストは急速に蓄積します。これにより、AI固有のスプローが生じ、コンピュート使用量がチームの追跡や管理を上回ります。これに対処するには、ガバナンス、可視性、自動化の組み合わせが必要です。スケールアップすると、コスト効率は運用上の懸念のみならず、システム設計の基本的な部分となります。

フィーチャーストアからリアルタイム推論システムまで、幅広い分野でご経験があります。バッチとリアルタイムのAIワークロードのバランスはどのように進化しているかについてお話しください。

バッチとリアルタイムのAIワークロードのバランスは、基本的に変化しません。バッチ処理は通常、コスト効率が良く、運用も容易であるため、多くのユースケースに適しています。リアルタイムシステムは、遅延がユーザーエクスペリエンスやビジネス結果に直接影響する場合、チャットアプリケーションや不正検出などに不可欠です。両方のアプローチは共存し続けます。組織は、両方を効果的にサポートできるプラットフォームを構築することが重要です。決定は、コスト、遅延、信頼性のトレードオフに基づいて行われます。

今後2〜3年で、「成熟した」エンタープライズAIプラットフォームとはどのようなものになりそうですか。また、Rayやアンスケールのようなツールやプラットフォームは、その未来にどのように貢献するでしょうか。

次の数年で、「成熟した」エンタープライズAIプラットフォームは、いくつかの重要な特徴によって定義されます。データ処理からトレーニング、推論までの全AIライフサイクルをサポートする統一インフラストラクチャに依存し、断片的なツールのコレクションではありません。強力なDay 2運用を持ち、エージェントによる自動化された観測可能性、信頼性、迅速なデバッグ機能を備えています。コスト管理は予測可能で管理されており、組織が持続可能にスケールアップできるようにします。最も重要な点は、高い開発者速度を実現し、チームがアイデアから本格的な導入まで迅速に進めることができるようにすることです。Rayやアンスケールのようなプラットフォームは、このレベルのスケールと効率性を可能にするAIネイティブ基盤を提供することで、将来に重要な役割を果たします。

素晴らしいインタビュー、ありがとうございました。読者がさらに学びたい場合は、アンスケールを訪れてください。