TrueFoundryで150万人にモデルを提供する2人チーム

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
ここ数ヶ月、私たちは少数精鋭のチームと協力する機会がありました。彼らは最先端の深層学習モデルを開発し、1000万人以上のユーザーに提供するためのパートナーシップを構築しました。
彼らの成功事例における最後の課題は、これを実現するためのエンジニアリングでした。モデルは計算負荷が高く、最終ユーザーにモデルを提供したい規模では、彼ら2人(DevOpsエンジニア1名とMLエンジニア1名)で管理できる、信頼性が高く高性能なインフラスタックが必要でした。
非同期デプロイの必要性
このモデルは、様々なサイズの音声入力を処理するために構築されました。モデルの処理時間が長かったため(平均約5秒)、各リクエストを処理し応答するために非同期推論が必要でした。
チームはAWS Sagemaker上にスタックを開発していました。
チームはSagemaker上にモデル提供のための初期スタックを構築しました。しかし、この設計で最初のパイロット運用を行った際、このスタックでは望ましい規模でモデルを安定して提供することが難しいと認識しました。
ユーザーは8~10分の遅延に直面しました。
非同期設定を使用した後でも、インスタンスのスケーリングに時間がかかったため(1台あたり8~10分)、ユーザーはこの遅延に耐えなければならず、エンドユーザーエクスペリエンスが損なわれました。

しかし、PoC中に、彼らは応答時間に大きな遅延に直面しました。Sagemaker関連の多くの制御に不慣れだったため、遅延の原因究明に貴重な時間を費やしました。彼らが直面した課題の一部は以下の通りです。
- 学習が困難: DS/MLEとして、Sagemakerを使用するために必要な新しい概念を理解することが困難だと感じました。
- 可視性の制限: 直感的でないダッシュボードやインターフェースのため、特に本番環境での問題の根本原因分析は困難でした。
- スケーリングが困難: Sagemakerのスケーリングは遅く、ユーザー応答の遅延と顧客体験の低下を引き起こしました。
- 個別のクォータ: AWSは、Sagemaker予約済みGPUインスタンスの容量を得るために個別の申請を要求します。チームはこのプロセスが遅く、制限が多いと感じました。
- 高価: SagemakerでGPUを使用することは、SagemakerがEKSの生インスタンスよりも25〜40%高くマークアップするため、チームにとって費用がかかりました。
PoC後、チームはSagemakerへの信頼を失い、2人(MLエンジニア1名とDevOpsエンジニア1名)で1,000万人以上のターゲットユーザーにサービスを提供できるソリューションが必要だと判断しました。
TrueFoundryでのシステムデプロイ(2日未満)
チームとの連携を開始した際、彼らのパイロット版リリースまで約7日でした。私たちは、TrueFoundryのモジュールを使用してスタック全体を2日未満で移行し再構築することで、パイロット版が本番稼働する前に十分なテスト時間を確保できるよう支援できることをチームに保証しました。

はるかに高速なスケーリング
チームは、Sagemakerとのパフォーマンスを比較するため、モデルに88件のリクエストをバースト送信してベンチマークを実施しました。TrueFoundryは スケールアップしました 78%高速に Sagemakerよりも高速にスケールアップし、ユーザーにより高速な応答を提供しました。その クエリへの応答にかかるエンドツーエンドの時間は、TrueFoundryでは40%高速でした。
150以上のノードへの信頼性の高いスケーリング
チームは、次の理由により、アプリケーションを150以上のGPUノードに簡単にスケールできました。
- 設定が簡単: UI上で引数を変更するだけで、受信リクエストのバックログに基づいてオートスケーリングルールを簡単に設定できました。そうでなければ、エンジニアリングチームとの何度もやり取りが必要だったでしょう。

- GPUクォータの増加: TrueFoundryを使えば、SpotとRaw ECSの両方を利用できました。クラウドプロバイダーにおけるGPU不足のため、TrueFoundryは異なるGPUプロバイダーやリージョン間でスケールする選択肢もチームに提供しました。

- スポット利用とオートスケーリング: チームは、サービスにスポットインスタンスを使用するための設定に、追加の労力を費やす必要がありませんでした。トラフィックが少ないときには、インスタンスもスケールダウンされました。TrueFoundryのスポット利用とオートスケーリング設定のための信頼性メカニズムを使用することで、チームはパイロット期間中に10万ドル以上を節約しました。
- 開発・デモ環境: チームはモデルの開発・デモサービスもデプロイし、使用していないときはマシンをスケールダウンしながらフィードバックを収集しています。
既に150万人のユーザーにサービスを提供し、日々増加中!
をUsing TrueFoundry利用して、2人チームで全体のワークロードを管理できます。これはしばしば150以上のGPUノードにまでスケールしますが、彼ら自身で管理できます。私たちと協力する中で、チームが最も注目したのは、当社のカスタマーサポートと迅速な対応時間でした。TrueFoundryはクライアントの成功に投資しており、すべてのクライアントがこのプロジェクトと同様の規模でスケールし、影響を生み出すことを願っています!
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.


















.webp)
.webp)


.png)

.png)














