SuperhumanとDatabricksが共同で構築した200K QPS推論プラットフォーム

アナリティクスパートナーからリアルタイム推論パートナーへ

Superhumanは、Superhuman、Coda、Superhuman Mail、Superhuman Goを含む生産性プラットフォームであり、数十の言語で4,000万人以上の日次ユーザーにサービスを提供しています。SuperhumanのAIコミュニケーションアシスタンスは、人々が書くすべての場所で、正確さ、明瞭さ、トーン、スタイルのためのリアルタイムの提案を提供します。

DatabricksとSuperhumanは長年のパートナーです。Superhumanチームは、これまで分析の基盤としてDatabricks Data Intelligence Platformを使用してきました。しかし、分析は全体像の半分にすぎませんでした。

Superhumanのリアルタイム提案の多くは、大規模で提供される高度なカスタムAIモデルによって支えられています。Superhumanは、このモデルを毎秒200,000以上のクエリのピークトラフィックで実行しており、エンドツーエンドのレイテンシはP99で1秒未満、厳格な4 9の信頼性保証を備えています。Superhumanは、Databricksのモデル提供を活用して大規模言語モデルの提供スタックを最新化しました。これには、共同の製品およびエンジニアリング作業に基づいた新しい種類のパートナーシップが必要でした。

Superhumanはどのように提供スタックを最新化しましたか

この移行の前は、SuperhumanはvLLM上に構築されたDIY提供スタックと、トレーニングおよびモデル管理用の内部ツールを運用していました。内部MLインフラストラクチャチームがこのスタックを維持していましたが、これは大規模をサポートしていましたが、大規模言語モデルを提供する際にはいくつかのペインポイントが累積していました。

カスタム大規模言語モデルは、200K以上のQPSピークで、リクエストごとに約50の入力トークンと50の出力トークンで、文法エラー訂正を大量に処理します。これは、L40S-gpusベースのスタックが提供できるものの限界を押し上げていました。モデルの新しいイテレーションごとに、オンボーディングのために数か月の手動パフォーマンスチューニングが必要でした。一方、運用上の負担は増大しており、容量計画、パフォーマンスチューニング、自動スケーリングは、モデルの品質と製品イノベーションに集中する必要がある少数精鋭チームの時間を消費していました。

Superhumanは、提供スタックのパフォーマンスとレイテンシSLAにコミットし、それらを満たすために必要なエンジニアリングに共同投資するプラットフォームパートナーを必要としていました。両チームは、サブセカンドのp99レイテンシとSuperhumanの内部評価ハーネスでの品質低下ゼロという、リアルタイムレイテンシSLOを事前に定義しました。

プラットフォームインフラストラクチャでのリアルタイムSLAの達成

単一のポッドでレイテンシターゲットを達成することは、必要ですが十分ではありません。200K以上のQPSを確実に提供するには、負荷を分散し、動的にスケーリングし、スパイクを吸収できるインフラストラクチャが必要です。これを正しく行うには、両チーム間の緊密な協力が必要でした。

負荷分散の最適化：2つの選択肢の選択

Superhumanの文法訂正エンドポイントトラフィックは、特定の期間に急速なランプアップを伴う強い日次パターンを示し、多くの場合200k QPSを超えます。デフォルトのKubernetesラウンドロビンの負荷分散は低QPSでは十分ですが、テストによると、このパフォーマンスは高QPSでは低下し、不均一なリクエスト分布がホットスポットを作成してテールレイテンシを急増させることが明らかになりました。

アプローチの核心は、エンドポイント検出サービス（EDS）です。これは、Kubernetes APIを継続的に監視して、サービスとエンドポイントスライスの変更を検出する軽量なコントロールプレーンです。EDSは、2つの選択肢の選択 (引用) に基づいたカスタム負荷分散アルゴリズムを駆動します。各リクエストについて、2つの候補ポッドがサンプリングされ、アクティブなリクエストが少ない方にトラフィックがルーティングされ、高QPSでラウンドロビンが作成するホットスポットを防ぎます（ブログを参照）。

プラットフォームのコスト効率を変動トラフィックパターンに合わせて維持するために、システムは顧客の需要に応じて動的に自動スケーリングします。自動スケーラーは、ポッド全体で平均化されたrequest_concurrencyを追跡し、レプリカあたりの最大持続可能なRPSのベンチマークから導出されたポッドごとの同時実行ターゲットを使用します。スケーリング戦略は意図的に非対称です。スケールアップは積極的で応答性が高く、スケールダウンは保守的であり、レイテンシスパイクを引き起こすフラッピングを防ぎます。SuperhumanとDatabricks間の共同シャドウテストを通じて、自動スケーラーのパラメータ調整、特にいつ積極的にスケールするか、いつ安定を維持するか、スケールダウンでどれだけ保守的になるかについて、エッジケースを特定し、問題を修正しました。

イメージアクセラレーションによるコンテナ起動の最適化

Superhumanのエンドポイントトラフィックがオフピークからピークに急増すると、自動スケーラーは多数のポッドを追加する必要があります。各ポッドがコンテナイメージをプルして起動するのに数分かかると、ランプ中にユーザーはレイテンシスパイクを経験します。ポッドの起動時間を短縮することは、スケールアップを高速化し、トラフィックの急増中のレイテンシをスムーズにすることに直接つながります。

Databricksのモデル提供チームは、サーバーレスコンピューティング用に構築されたイメージアクセラレーション（ブログ）を採用して、コールドスタートを回避しました。このアプローチは、Superhumanのために提供された比較的小さなモデルによく適合しました。

コンテナイメージを構築する際に、標準のgzipベースのイメージ形式を、遅延読み込みに適したブロックデバイスベースの形式に変換する追加ステップを追加します。これにより、コンテナイメージは本番環境で4MBセクターのシーク可能なブロックデバイスとして表現できます。

コンテナイメージをプルする際、カスタマイズされたコンテナランタイムは、コンテナのルートディレクトリ（ディレクトリ構造、ファイル名、権限を含む）をセットアップするために必要なメタデータのみを取得し、それに応じて仮想ブロックデバイスを作成します。次に、アプリケーションがすぐに実行を開始できるように、仮想ブロックデバイスをコンテナにマウントします。

アプリケーションがファイルを初めて読み取る際に、仮想ブロックデバイスに対するI/O要求は、イメージフェッチャープロセスへのコールバックを発行します。このプロセスは、リモートコンテナレジストリから実際のブロックコンテンツを取得します。取得されたブロックコンテンツはローカルにもキャッシュされ、コンテナレジストリへの繰り返しのネットワークラウンドトリップを防ぎ、将来の読み取りに対する変動するネットワークレイテンシの影響を軽減します。

この遅延読み込みコンテナファイルシステムにより、アプリケーションの起動前にコンテナイメージ全体をダウンロードする必要がなくなり、コンテナ起動までの時間を数分からわずか数秒に短縮できます。

ランタイムの最適化：ポッドあたりのスループットが60％向上

プラットフォームレイヤーがフリートレベルのスケーリングを処理するようになったため、次の問題は、各ポッドがサポートできるQPSとコストでした。

このセクションでは、ポッドあたりのスループットをH100 GPUで750 QPSから1,200 QPSに60％向上させた最適化について説明します。これらは、品質低下をゼロに保ちながら達成されました。

FP8量子化

FP8量子化は、ポッドあたりのQPSを最大30％増加させ、単一の最大のパフォーマンス向上でした。

SuperhumanのMLチームは、vLLMのオンライン量子化ライブラリを使用してチェックポイントをFP8に事前量子化し、Databricksが提供用にロードした圧縮テンソル形式のチェックポイントを生成しました。最終構成では、アテンション射影（Q、K、V、および出力）とMLP射影はすべてFP8パスで実行され、KVキャッシュ量子化は無効のままにされました。これは、重み量子化がパフォーマンス向上の源であり、KVキャッシュ量子化はそれ自体で品質のトレードオフを導入し、このワークロードでは追求する価値がなかったためです。

最終構成を決定する前に、両チームは量子化するレイヤーについて検討しました。MLP射影は最初から量子化されており、アテンションレイヤーを量子化するかどうかが未解決の問題でした。Databricksのモデル提供は、最初からハイブリッド精度推論をサポートするように提供エンジンを設計していたため、いずれかのレイヤーグループが量子化で品質に敏感すぎることが判明した場合でも、全体的な提供アーキテクチャを変更せずに高精度で維持できました。両チームが影響を直接測定できるように、アテンション量子化をオン/オフできるフラグをリリースしました。実験はクリーンに完了し、Q/K/Vおよび出力射影を量子化しても、Superhumanの評価で測定可能な品質低下は見られませんでした。

もう1つの考慮事項は、量子化の粒度でした。市販のカーネルは、テンソルごとのスケーリング（重みテンソル全体に単一のFP8スケール係数）を使用していました。Databricksのカーネルはチャネルごとのスケーリングを使用し、各線形レイヤーの出力チャネルごとに個別のスケール係数を計算します。これにより、重要な部分のダイナミックレンジが維持され、MLPレイヤーの量子化エラーは、評価に現れるしきい値を十分に下回ります。カーネルレベルの改善と組み合わせることで、チャネルごとの量子化は、同じスループットで他のオープンソースベースラインと同等またはそれを超えるパフォーマンスを発揮しました。

CPU側のボトルネックの排除

小さくて高速なモデルの場合、パフォーマンスはGPUではなくCPUによってボトルネックになることがよくあります。Databricksチームは、高速PEFT提供での作業でCPUボトルネックの排除をすでに調査しており、ここで同様のCPU最適化をSuperhumanのワークロードに直接適用しました。

具体的には、チームはマルチプロセッシングランタイムサーバーを導入しました。ほとんどのモデル提供ワークロードでは、GPUがボトルネックでありCPUではないため、単一のプロセスでGPUを飽和状態に保つのに十分な速度が得られます。しかし、小さくて高速なモデルでは、GPUは、単一のプロセスが次のバッチを準備するよりも速くフォワードパスを完了し、ボトルネックがCPUに切り替わります。

チームは、複数のRPCサーバープロセスを実行することでこれに対処しました。複数のCPUプロセスが並列でGPUに作業を準備およびディスパッチできるようにすることで、単一プロセスのシリアライゼーションボトルネックを解消しました。これにより、さらに20%のスループットが向上しました。

その他のCPU側の最適化により、パフォーマンスが数パーセント向上しました。

1. Pythonオーバーヘッドの削減。各CUDAグラフデコードステップの開始時に行っていたPythonレベルのテンソルスライシング、コピー、およびフィルを、単一のC++呼び出しに置き換えました。並列戦略（ThreadPool、OpenMP）も検討しましたが、CUDA同期オーバーヘッドのため、シングルスレッドC++が最適でした。これにより、フォワードパスごとのGPUアイドル時間がわずかに短縮されました。
2. CPUとGPUのワークオーバーラップを改善するための非同期スケジューリング。CPU側の後処理をクリティカルパスから外し、次のGPUフォワードパスと並行して実行されるようにしました。バッチNのすべての後処理を完了してからバッチN+1を起動するのではなく、スケジューラはN+1をすぐにディスパッチし、Nの後処理を並列で処理します。後処理では、フルバッチではなく、関連するリクエストのサブセットのみを反復処理します。これにより、次のフォワードパスがより早く開始されるようになりました。

今後の展開

この作業は、より広範なパートナーシップの基盤となります。Superhumanは現在、さまざまなモデルサイズ、タスクタイプ、レイテンシー要件にまたがる追加モデルをDatabricksに移行しており、トレーニングワークフロー、実験追跡、評価（従来のML、ディープラーニング、生成AI/エージェント）、モデルおよび（LLM）ジャッジレジストリ、および大規模なエージェントトレースの取り込みのために、AIプラットフォームをより広範に採用しています。

この大規模プラットフォームの構築は、双方にとって会社全体の取り組みであり、並外れた学習体験でした。SuperhumanのMLおよびインフラストラクチャチームの皆様には、深い協力、困難なトレードオフに対するオープンなイテレーションへの意欲、そしてすべての品質基準と負荷テストにもたらされた厳密さに、心より感謝申し上げます。私たちが共に構築したエンジニアリングプレイブックは、彼らのものでもあり、私たちのものです。今後、あらゆるワークロードに同じレベルのパートナーシップをもたらすことを楽しみにしています。

主なポイント

マネージド推論サービスを使用しても、制御を失う必要はありません。Superhumanはモデルトレーニング、量子化、品質基準の完全な所有権を維持しますが、Databricksはランタイムパフォーマンスとプラットフォームの信頼性を維持します。この責任分担は、共有SLO、共同品質検証、およびDatabricksプラットフォームへのオンボーディング時の段階的な負荷テストとうまく機能します。

カスタムモデルを大規模に提供する準備はできましたか？Databricks Foundation Model APIが最も要求の厳しい推論SLAをどのように満たすことができるか、そしてチームに単なるマネージドサービスではなく、真のエンジニアリングパートナーを提供する方法をご覧ください。高QPSモデルサービングユースケースのオンボーディングについては、https://www.databricks.com/company/contactまでお問い合わせください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事