TrueFoundry：2023年 年末レビュー

2023年も終盤を迎え、今こそ TrueFoundryの 過去1年間の道のりを振り返る時です。この振り返りは、私たちの達成を祝うだけでなく、乗り越えてきた課題、与えられた機会への感謝、そして得られた学びを認めるものでもあります。運用上の詳細に焦点を当てるのではなく、MLOpsに関する私たちの見解と、それが現実でどのように展開されたかという観点から、学びと気づきの時系列的な道のりをご案内します。 

私は個人的に宇宙愛好家なので、スタートアップをロケット船に例える伝統的な比喩は適切だと感じています。もし私たちがロケット船を建造していると想像して、そのタイムラインを説明するとすれば、 2022年はエンジンを組み立て、試運転を行った年でした一方、2023年は星々への航路を定め、宇宙の壮大な旅のための推進器を確保した年です！2023年の私たちの道のりをご案内できることを大変嬉しく思いますが、まずはTrueFoundryと2023年の初めについて、少し背景を説明させてください。 

TrueFoundryと2022年

TrueFoundryは、Kubernetes上にクラウドに依存しないPaaSを構築しており、本番環境に対応した開発者フレンドリーなAPIを使用して、機械学習モデルのトレーニングとデプロイを標準化するものです。 

2022年、私たちはチームの構築、異なるクラウドプロバイダー間でのプラットフォームの基盤レイヤーの開発に時間を費やし、最初の数社のデザインパートナーと密接に協力しました。コアサービスデプロイメントレイヤーを開発し、UI、CLI、Python-SDKによるエクスペリエンスを構築し、初めての顧客からの収益という喜びを経験しました！私たちは、MLOps分野での販売が難しいことに気づきました。なぜなら、ほとんどの企業が「機能するもの」を構築しており、変化への抵抗が非常に高かったからです。 

その一方で、私たちが解決しようとしていた問題は、確かに検証されていました。 

• 機械学習モデルが本番環境に移行していなかった
• モデルの引き渡しが原因でMLデプロイが遅延していた 
• データサイエンティストは主要なインフラ管理の問題に直面していた
• ML分野でのK8sの採用は最小限だった
• 機械学習モデルがフルスタックソフトウェアとは異なるデプロイメントパイプラインに従うことは、非常に問題があった 
• 企業は機械学習の運用において、本来必要とされるコストの2〜10倍もの費用をかけていました

この頃には、私たちは経済的に大きな影響を与える主要な問題を解決していることを認識していましたが、課題は、それが顧客にとって緊急の問題ではなかったことでした。この経験から得た教訓は次のとおりです。 

主要な課題を解決することは持続可能性にとって極めて重要ですが、緊急性を捏造することはできません。それは顧客と市場が決めることです。ビジネスの世界における物理法則のようなものだと考えましょう。それに逆らわず、探し続けましょう！ 

2023年の始動

そうして、私たちは2023年をスタートさせました。デザインパートナーとの協業で得た学びに基づき、複数のGTM（Go-to-Market）実験を行うことになっていました。実施した実験の中から具体的な例をいくつか挙げます。 

1. クロスクラウド仮説: 企業の84%がクロスクラウドを利用しており、複数のクラウドベンダー間でワークロードを実行することは非常に困難です。これは組織的に時間とコストの大きな浪費でしたが、この問題を最優先事項として抱えている担当者を繰り返し見つけることはできませんでした。
2. K8s駆動のMLワークロード: フルスタックソフトウェアの世界では、K8sとそのエコシステムの規模の恩恵をすでに享受し始めており、機械学習においても、これらの恩恵がさらに顕著になることは明らかでした。K8sへの移行を優先事項としているチームもいくつか見つけましたが、顧客にとってのユーザー向け作業と比較すると、常に後回しにされていました。 
3. コスト最適化: 当社のプラットフォームを利用しているデザインパートナーのほとんどが、クラウドインフラコストを40〜50%削減していることに気づき、年間目標としてコスト削減を掲げている組織をターゲットにしました。もちろん、これは共感を呼びましたが、コスト削減を担当するチームは主にDevOpsであり、彼らの任務は一度限りのコスト削減であり、開発者のワークフローに対してほとんど、あるいは全く制御権を持っておらず、それが再び問題を引き起こすことに気づきました。 

なるほど、いくつかの部分的に成功した、あるいは失敗した実験を通じて、私たちが解決しようとしていた問題がいかに広範に存在するかをさらに認識しましたが、緊急性があり、外部から繰り返し特定できる、まさにその問題を抱える狭い顧客ペルソナを特定する道筋をまだ見つけることができませんでした。 

これは、世界中の誰もがLLM（大規模言語モデル）を使いたがるようになり、私たちが絶好の機会に恵まれるまで続きました。 

LLMは私たちにとっての需要を集約してくれました。誰もがLLMを使いたがり、そして誰もが、私たちが解決しようとしていたのと同じ問題に「緊急に」直面するようになりました。  

LLMOPs、MLOPs、DevOpsの統一性

ここで、LLMの文脈におけるそれらの問題のいくつかを説明します。 

• デモから本番環境へ: 文字通り、誰もがいくつかのプロンプトを書き、豪華なGPT-4ベースのデモを作成できました。Langchainを使って迅速なRAGを構築するのは数時間の作業であると、すべてのデータサイエンティストが同意するでしょう。課題は、これらのデモを本番環境に対応させることであり、それには多くの要素を信頼性の高い方法で組み合わせる必要があります。 データサイエンティストが最初からこれらのアプリケーションを本番環境での設定で考えやすくするようなワークフローを構築する必要があります. 
• A100sはどこに？：LLMをインフラで扱った開発者で、GPU、特にA100の入手困難さに不満を漏らさなかった者は一人もいません。彼らがこれらのGPUを入手できる可能性をどうすれば高められるでしょうか？複数のクラウドやデータセンターにアクセスできるようにする、しかし 適切なツールがなければ、マルチクラウドアーキテクチャを扱うのは非常に厄介です。 
• オープンソースモデルのホスティング：これらの大規模言語モデルをホスティングするには、インフラの綿密なサポートが必要であり、これによりデータサイエンスチームのインフラチームへの依存度が高まります。もし、適切なプラットフォームを構築できれば、 DSチームが合理的に「インフラから独立」できるようなものであれば、既製のモデルホスティングのような比較的シンプルなユースケースでは、この問題は軽減されるでしょう。
• 長時間実行されるファインチューニングジョブ- 多くのお客様がLLMのファインチューニングを行っており、一部は事前学習も行っています。これらは長時間実行される高価なジョブであり、人為的なミスによるGPUサイクルを多く無駄にするわけにはいきません。 ロギング、モニタリング、実験追跡のベストプラクティスがここでは極めて重要です。例えば、デフォルトでモデルのチェックポイントを保存しない場合、実行開始から2日後にトレーニングジョブが停止してしまったら、それは時間とリソースの莫大な無駄になります。 
• コスト監視- LLMは学習も実行も安価ではありません。多くの企業は、いつかコストが下がると仮定してLLMを使ってユーザーにサービスを提供しているため、現在、ユニットエコノミクスがマイナスになっています。EC2インスタンスにプレミアム料金を課し、スポットインスタンスをほとんど活用しないSagemakerのようなクラウドプラットフォームへの依存が、この問題をさらに悪化させています。さらに、サービスのオーナーである開発者には、インフラコストの可視性がほとんどありません。 この問題はLLMの場合に顕著に見えますが、上記で述べたロジックはすべて、あらゆるソフトウェアにとって基本的なものです。 
• ベクトルDBとシークレット管理：LLMベースのアプリケーションを構築するために、開発者は、様々なベクトルDB、Label Studio、多様なAPIサービスといった複数のアプリケーションと格闘することになりました。それぞれがセットアップに時間を要し、適切なレベルの監視を行いながら組織全体でAPIキーを共有するためのインフラが必要です。 データサイエンティストは、これに対処するための適切なツールを備えているとは感じておらず、唯一の解決策は「安全なソリューションが実装されるまで、ペースを落とす」ことです。 

これらは一例に過ぎませんが、非同期推論のセットアップ、GPU対応ノートブック、ノートブック間での共有ストレージドライブ、大規模Dockerコンテナのコールドスタート時間など、企業が解決に苦慮していた同様のユースケースは他にも多数存在します。 

LLMのために当社を利用するすべてのお客様が、データサイエンティストのインフラへの依存度軽減、コスト削減、クラウドプロバイダー間でのアプリケーションのスケーリングによるロックイン回避といったメリットを経験していることが判明しました。そして、これらのメリットがLLM以外の他の機械学習モデルにも適用可能であり、現実的にはソフトウェアスタックの残りの部分にも適用できることを認識しています。ソフトウェアや従来のMLモデルのデプロイで当社を利用し始めたお客様が、LLMでも同様のメリットを享受しているという、ユースケースの相互作用が見られます。 

結論

MLはソフトウェアであり同様にデプロイされるべきであるという明確な見解、K8sが長期的には優位に立つこと、そして企業がクラウドであれ他のソフトウェアベンダーであれベンダーロックインを避けたいと考えるだろうという信念を持って、当社がコアインフラの構築に費やした時間が、私たちとお客様にとって実を結んでいることを、このことは確信させてくれます。 

それでは、ロケット船のたとえを使って締めくくります。 

2023年が領域を開拓し、スラスターの準備を整えた年だとすれば、2024年はブースターに点火し、このロケット船を推進させる年となることを楽しみにしています！

皆様にとって素晴らしい 新年となりますよう、TrueFoundryチーム一同を代表して心よりお祈り申し上げます！ようこそ2024年。