2026年6月10日

モデルに適応するAIサービングプラットフォーム

すべてのAIモデル（クラシックなML、ディープラーニング、エージェント）に対応する1つのプラットフォーム：300K+ QPS、10ms未満、調整不要

概要：1つのCPUコアで動作する2 MBのscikit-learn分類器から、8つのGPUで動作する微調整済みの70B LLMまで、あらゆるモデルを本番環境で調整なしで実行できるフルマネージドプラットフォーム。
解決する課題：カスタムモデルはリソースプロファイルやトラフィックパターンが大きく異なるため、単一の静的な構成ではすべてに対応できません。代わりにこのプラットフォームが自動的に適応し、各ノードの効率性を維持しながら、低レイテンシを実現します。
導入効果：自社運用スタックから移行したお客様において、<10msのp99レイテンシオーバーヘッドで300K+ QPSを達成し、インフラストラクチャコストを最大90%削減しました。

カスタムモデル推論の実行における課題

機械学習モデルを本番環境にデプロイすることは、一種の契約を結ぶようなものです。つまり、トラフィックの急増に関わらずすべてのリクエストが数ミリ秒以内に完了し、トラフィックが少ないときはコストを低く抑えるという契約です。モデルサービングは、その契約を維持するためのインフラストラクチャですが、業界の歴史の大半において、この契約を守ることはモデル自体を構築することと同じくらい困難でした。

カスタムモデルは、基盤モデルとは根本的に異なります。基盤モデル（Llama、Mistral、CLIPのバリアントなど）をホストするプラットフォームは、実行しているもの（アーキテクチャ、メモリフットプリント、推論特性など）を正確に把握しているため、その1つのモデルに対して高度な最適化を行うことができます。カスタムモデルのプラットフォームはその逆です。同じプラットフォームで、単一の CPU コア上の2 MBの scikit-learn 分類器と、8台の GPU 上のファインチューニングされた70Bの LLM の両方を提供しなければなりません。また、キューイングを許容できない低レイテンシのランカーと、積極的なバッチ処理で真価を発揮する埋め込みモデルの両方を処理する必要があります。つまり、あらゆる種類のモデルに対応し、リソースプロファイル、トラフィックパターン、レイテンシ予算が同じものは2つと存在しないプラットフォームが必要になります。

従来のプラットフォームは、レプリカ数、レプリカごとの同時実行数、オートスケーリングのしきい値といった複雑な設定を顧客に押し付けています。これは、抽象度が上がっただけで、依然としてDIYのようなものです。しかも、それは終わりがありません。新しいモデルが登場したりトラフィックが変動したりするたびに、プロファイリングとチューニングをやり直す必要があります。そのため、優秀なエンジニアがデプロイの前後で本番環境のトラブル対応に追われ、サービングがすべてのリリースの足を引っ張る要因になってしまいます。その結果、最も重要なコストが発生します。開発環境で実証されたモデルが、本番環境にデプロイされるまでに何週間も放置されることになるのです。

私たちの使命：MLスタック税の排除

サービングインフラを手動で再チューニングすることは、組織が実行するすべてのモデルに対する「税金」のようなものです。規模が大きくなると、本番環境でモデルを稼働させ、パフォーマンスを維持することだけを任務とする専用のサービンググループを立ち上げるなど、構造的な問題になります。私たちはこれをMLスタック税と呼んでいます。

Databricks Custom Model Servingは、MLflowでパッケージ化されたあらゆるモデルに対応する、フルマネージドのリアルタイム推論プラットフォームです。私たちの使命は、この税金を排除し、モデルのライフサイクルの3つの段階において、お客様のサービングチームがより高度な価値創造に集中できるようにすることです：

プレプロダクションをシンプルにする。Databricksでトレーニングされたモデルは、ワンクリックでデプロイできます。環境を正確に一致させるため、実行時の予期せぬトラブルはなく、デプロイ時間を最適化して迅速なイテレーションとロールバックを維持します。
本番環境の信頼性、スケーラビリティ、コスト効率を高める。インフラストラクチャは実行時に各モデルとそのトラフィックに適応し、複雑な設定なしで低レイテンシと低コストを維持します。（この記事の主なテーマです。）
ポストプロダクションをシンプルにする。すべてのエンドポイントは、設定なしでテレメトリをUnity Catalogに出力します（メトリクス、OTelネイティブのログとトレース、DeltaおよびMLflow Tracingへのすべてのリクエストをキャプチャする即時推論テーブル）。その上にGenie Codeが位置し、これまでにないエージェント型運用オブザーバビリティを提供します。AIのオブザーバビリティはコンテキストの問題であり、そのすべてのコンテキストが1つのプラットフォームに存在します。

これが機能するのは、Custom Model ServingがDatabricksにネイティブに組み込まれているためです。データ、特徴量、トレーニング、MLflowパッケージング、サービング、エージェントが、バラバラのシステムを繋ぎ合わせたものではなく、1つのガバナンスが効いたスタックとして統合されています。

この記事では、第2の段階である、複雑な設定なし（no knob）のアプローチで、多種多様なモデルにわたり低レイテンシで300K以上のQPSを達成する方法について説明します。これこそが、税金を消し去る仕組みです。

アーキテクチャ

アーキテクチャにおけるすべての決定は、低レイテンシ、大規模スケール、コスト効率という3つの制約によって形作られています。これらは互いに相反する関係にあります（レイテンシを下げる簡単な方法は過剰プロビジョニングであり、コストを下げる簡単な方法は過少プロビジョニングです）。あらゆる種類のモデルに対して、リソースを無駄にすることなくこれら3つすべてを同時に満たすことこそが、真のエンジニアリング課題です。

これを実現するために、3つの要素が機能しています。

各ホップでのレイテンシオーバーヘッドを最小限に抑える、短く隔離されたリクエストパス。
自動ランタイム選択：各モデルは、それに最も適した推論エンジンでサービングされます。
プラットフォームの心臓部：モデルとトラフィックの両方にリアルタイムで適応するオートスケーラー。レイテンシを低く抑え、スケールアップしながら、コストを削減します。

最初の2つは単一のリクエストを高速に保ち、3つ目はモデルやトラフィックが変化してもシステム全体を高速かつコスト効率よく保ちます。このセクションの大部分は、3つ目の要素についてです。

短く隔離されたリクエストパス

すべてのサービングエンドポイントは、独自のPodとモデルバージョンに固有のコンテナイメージを持つ、完全に隔離されたKubernetesデプロイメントです。この隔離は意図的なものです。あるエンドポイントのトラフィック、障害、またはリソースの逼迫が別のエンドポイントに影響を与えることはなく、カスタムワークロードのセキュリティが維持されます。

レイテンシはすべてのレイヤーにおいて最優先の制約事項であるため、パス自体は可能な限り短く保たれています。リクエストはPoPプロキシ経由で到達し、認証されると、接続管理用の共有ロードバランサーを通過して、それを処理するPodに即座に到達します。各Podは、プラットフォームの監視と顧客向けダッシュボードの両方のために、メトリクス、ログ、ペイロードログ、トレースをエクスポートするオブザーバビリティサイドカーも実行しています。

効率的なモデルランタイムの選択

各Podの内部では、モデルはそのタイプに最も適した推論エンジンで実行されます。従来のMLモデル用の非同期Gunicorn MLflowサーバーから、vLLM、Triton、または顧客独自のランタイムをサポートする大型モデル用のGPU最適化エンジンまで、すべてが1つの統一されたサービングインターフェースの背後で動作します。

オートスケーラー：モデルとトラフィックへの適応

私たちが構築したカスタムKubernetesコントローラーであるAutoPilot Pod Autoscaler（APA）が、プラットフォームの中心に位置しています。ロードバランサーからのシグナル（アクティブな同時実行数、キューの深さ）と、Pod自体からのシグナル（CPU使用率、GPU使用率、GPUメモリなど多数）を継続的に収集し、それらをスケーリングの決定に変換します。

オートスケーラーは、2つの予測不可能性を同時に吸収するために存在します：

モデルは予測不可能です。カスタムモデルのリソースプロファイルを事前に知ることはできません。CPU負荷の高いxgboostモデルは1コアあたり1リクエストしか処理できないかもしれませんが、エージェントは1コアあたり数百のリクエストを実行でき、ファインチューニングされた13BのLLMは複数のリクエストをまとめてバッチ処理することでメリットを得られます。APAは実行時に各モデルの限界を学習し、各レプリカが受け入れるべきリクエスト数を調整します。これが、モデルを認識する垂直スケーリング（model-aware vertical scaling）です。
トラフィックは予測不可能です。警告なしに急増、バースト、またはゼロに低下します。不正検知エンドポイントは、セールの開始時に数秒で10倍に跳ね上がることがあります。また、特定の地域向けのユースケースでは、1時間だけ激しく稼働し、夜間はアイドル状態になることもあります。APAは需要がシフトした瞬間に反応します。これが、リクエストベースの水平スケーリング（request-based horizontal scaling）です。

これが、オートスケーラーがシステムの心臓部である理由です。プラットフォーム上のすべてのモデルに対して、レイテンシ、スケール、コストという3つの制約すべてを同時に満たす唯一のコンポーネントだからです。

弾力性の2つの軸

従来のオートスケーラーは、リクエストベースまたはリソースベースのいずれかのオートスケーリングを行いますが、それぞれに弱点があります。リクエストベースのスケーリングは素早く反応しますが、非効率的です。各レプリカの負荷状況に関わらずすべてのリクエストを同一に扱うため、過剰プロビジョニングが発生するか、レプリカ数が激しく変動（スラッシング）することになります。リソースベースのスケーリング（CPU、GPU使用率）は効率的ですが、遅延が発生します。使用率メトリクスはトラフィックの後を追うため、オートスケーラーが起動する頃には、すでにp99への悪影響が発生してしまっています。

水平スケーリングはリクエストに反応します。エンドポイントごとのアクティブな同時実行リクエスト数を監視し、需要がシフトした瞬間にレプリカを追加または削除します。計算式はKubernetes Horizontal Pod Autoscalerに準拠しています。

モデルを考慮した垂直スケーリングは、モデルの特性に応じて動作します。定期的に、オートスケーラーは一連のメトリクスを確認して、単一のレプリカが実際に処理できる負荷を特定し、それに応じて上記の数式の target_concurrency を調整します。これは、ハードウェアのタイプを変更する従来の垂直スケーリングとは根本的に異なります。ここではハードウェアは同じままで、変更されるのは各ポッドが受け入れる同時実行リクエスト数であり、その上で実行されているモデルのリソースプロファイルに合わせて調整されます。

依存するメトリクスには以下が含まれますが、これらに限定されません。

ハードウェアメトリクス — CPUおよびGPUの使用率、メモリ使用率、I/Oウェイト
現在のレイテンシとキューの深さのプロファイル
GPU固有のメトリクス — メモリ帯域幅、FP16/BF16 FLOPS使用率

セーフガード。ノードあたりの同時実行数の変更はデリケートであり、変動が大きかったり頻繁に発生したりすると、システムのパフォーマンスが低下する可能性があります。ポッドのメトリクスは、一時的なトラフィックの変化や、モデルによってリクエストあたりのコストが大きく異なる場合に変動することがあります。私たちは、このようなメトリクスのノイズに対するセーフガードを設けています。一時的なCPUスパイクによって同時実行制限がすぐに縮小され、その数秒後に再び拡張されるようなことは避けるべきです。このために、3つのステップを実行します：

同時実行数は、メトリクスが安定したしきい値を超えた場合にのみ調整され、しきい値はメトリクスごとに微調整されます。
意思決定サイクルあたりの同時実行数の最大変化量を制限します
ワークロードに対して常に最小/最大同時実行制限を適用します
同時実行数の変更は、水平スケーリングと比較して低い頻度（30秒ごと）で行われます。これは、HPAのような現在のトラフィックではなく、過去のメトリクスに依存するため、重要なポイントでもあります。

2つの軸は結合されています：垂直スケーリングの同時実行出力は、target_concurrencyの分母を通じて水平スケーリングの計算に反映されます。水平スケーリングは、トラフィックが変化した瞬間に可用性と低レイテンシを確保します。モデルを考慮した垂直スケーリングは、各ノードが効率的に使用されるようにし、モデルの挙動の変化に合わせて同時実行数を適切にサイジングします。これらが組み合わさることで、「高速だが無駄が多い」か「効率的だが遅い」かという誤った二者択一を回避できます。

スケールアップとスケールダウンのしきい値

生のHPA数式だけでは不十分です。突発的なトラフィックに対して回復力がありません。一時的な10倍のスパイクが発生すると10倍のレプリカ増加が計算され、一時的な95%の減少が発生すると95%の減少が計算されます。どちらも、コスト、またはレイテンシと可用性の観点から危険です。

水平スケールアップは積極的です。 本番環境では、高レイテンシはビジネスに極めて深刻な悪影響を及ぼす可能性があります。多くのユースケースでは、本質的に非常に突発的なトラフィックパターンが発生するため、これをサポートすることが極めて重要です。スパイクに対応するため、私たちは1秒ごとに着信リクエストをスクレイピングし、APAは過去20秒間のトラフィックに基づいて5秒ごとにアップスケーリングの決定を行います。これにより、スパイク時のキューイングと429エラーが大幅に減少します。多くのお客様が最大5倍の差を実感しています。また、現在の負荷に対して1サイクルでスケールアップできる量も制限しています。全体として、60秒未満で10から10K qpsに移行できます（モデルのロード時間によって異なります）

スケールダウンは保守的です。スパイクは多くの場合、さらなるトラフィックの到来を予告します。スケールダウンの場合、APAは引き続き5秒ごとに決定を行いますが、レプリカを削除する前に過去約5分間のトラフィックを考慮します。

この非対称性は意図的なものです。スパイクは突然発生しますが、減少は一時的であることが多いためです。時期尚早なスケールダウンのコスト（最悪のタイミングでのコールドスタート）は、一時的にいくつかのアイドルレプリカを維持するコストを上回ります。

垂直同時実行数のスケールアップとスケールダウン。同じ非対称の哲学が垂直スケーリングにも適用されます。ポッドに負荷がかかっている場合は、同時実行数を迅速に削減し（すでに負荷がかかっているレプリカへのルーティングリクエストを減らすことでレイテンシを保護します）、ただし最小値を下回ることはありません。これらの決定は30秒間隔で実行され、5秒の水平ループよりも遅くなります。これは意図的なものです。垂直スケーリングは、スパイクへのリアルタイムの反応ではなく、時間をかけてモデルのリソースプロファイルに適応する定常状態の最適化であるためです。

コールドスタート時間の最小化

コールドスタートは、サービングシステムにおける最悪 of レイテンシイベントです。一度発生してしまうと、最適化によって回避することはできません。私たちはこれに対して2つのアプローチで取り組んでいます。可能な限りウォーム状態に保つことと、避けられない部分を可能な限り高速化することです。

ウォームノードプール。予測アルゴリズムにより、Databricksクラスターごとに事前プロビジョニングされたノードのプールが維持され、ベースランタイムイメージが事前にロードされます。オートスケーラーがレプリカを追加するときは、このプールから選択します。ノードはすでに起動しており、ベースイメージはすでにプルされているため、残りの作業はモデルのダウンロードだけです。ウォームプールの容量に対してお客様に課金することはありません。これは、お客様がDatabricksから直接得られる価値です。

高速なモデルダウンロード。モデルコンテナイメージはクラウドストレージのホットキャッシュレイヤーに保存され、ポッドの起動時に並列チャンクでプルされるため、大規模なモデルコンテナのイメージプル時間が大幅に短縮されます。モデルやその依存関係に影響を与えない設定変更（エンドポイントのメタデータ更新、ルーティングルールの変更など）は、ポッドを再起動することなく適用されます。再起動を回避することこそが、最も迅速な起動方法だからです。

プロビジョニングされた同時実行数。コールドスタートを一切許容できないレイテンシ重視のエンドポイントの場合、ユーザーは最小同時実行数の下限を設定します。これにより、モデルがロードされ、すぐにサービングできる状態のポッドのベースラインが完全に維持され、最初のリクエストでキューイングが発生することはありません。

ゼロダウンタイムのアップデートとメンテナンス。アップデートとメンテナンスは完全にゼロダウンタイムで行われます。トラフィックが古いポッドから移行する前に、新しいモデルバージョンのすべてのポッドが起動し、準備が整います。

本番環境で学んだこと

お客様はあらゆる側面でメリットを実感しています：

コスト：独自に構築したワークロードと比較して、90%以上のコスト削減を達成したお客様もいらっしゃいます。
レイテンシ：多くのお客様で、p99 & p50レイテンシが最大2倍改善されました。
スケール：お客様は、ほとんどメンテナンスを行うことなく、本番環境で100K+ QPSまでスケールアップしています。
本番環境で99.99%の可用性を維持しています。

2軸オートスケーリングは、モデルタイプを問わず汎用的に適用できます。水平＋垂直のアプローチが、CPU分類器からGPU LLMsにいたるまですべてに適用できるかどうかは確実ではありませんでした。しかし、実際に適用できました。水平軸はすべてのモデルに対して同じ方法でトラフィックを処理し、垂直軸は軽量モデルには高い同時実行数を、GPU負荷の高いモデルには低い同時実行数を設定します。同じコントローラー、同じロジックで、それぞれに適切な動作を実現します。

ほとんどのモデルは均質です。同時実行制限はトラフィックに伴って常に変動すると考えていましたが、実際には、同じ負荷の下でのモデルのリソースプロファイルはほとんど同様のままです。垂直軸はオンボーディング時にその価値を発揮し、その後は落ち着きます。

コールドスタートを完全に最適化してなくすことはできません。ウォームプール、並列イメージプル、デプロイの再利用によって、コールドスタートがほぼゼロになると期待していました。これらは非常に役立ちますが、物理的な限界があります。ポッドの起動にはモデルのサイズに比例した時間がかかり、大規模なGPUモデルでは数分かかります。その限界を超えた場合の唯一の解決策は、最小限の容量を完全に準備しておくことであり、これこそが最小プロビジョニング同時実行数が存在する理由です。

トラフィックは見た目以上に予測可能です。適切な最小値は静的なものではありません。B2Cアプリは夜間に静かになり、バッチパイプラインはスケジュールに従って実行されます。これらのパターンは学習可能であり、需要を追いかけるのではなく、需要に先んじて最小同時実行数を引き上げるためのトラフィック予測機能を構築しています。今後のアップデートにご期待ください。

結論

私たちは、終わりのない再チューニングや、それを必要とする専用のサービングチームといった、MLスタック税を取り除くことに着手しました。現在カスタムモデルサービングで実行されている多種多様なモデルに対して、2軸オートスケーラー、ウォームプール、ゼロダウンタイムデプロイがまさにそれを実現します。インフラがモデルに適応するのであり、その逆ではありません。モデルを用意し、同時実行範囲を設定すれば、あとはプラットフォームがすべて処理します。

しかし、モデルサービングはまだ解決された分野ではありません。より大規模なモデル、新しいハードウェア、エージェント型ワークロードにより、規模と複雑さは従来のサービングインフラが想定していたものを超え続けています。未解決の課題は山積みであり、私たちの志は高く掲げられています。コールドスタート時間の短縮、予測スケーリングのためのトラフィック予測、エンドポイントあたり1M+ QPSおよびクラスターあたり10M+ QPS、異種混在のGPUワークロードのよりスマートなビンパッキング、そしてp99を5ms未満に抑えることなどです。

そして、これはDatabricksだからこそ解決できる課題です。インフラをモデルに適応させるということは、モデルを理解することを意味します。つまり、モデルがどのようにトレーニングされたか、何に依存しているか、負荷がかかったときにどのように動作するかを把握することです。Databricksでは、これらすべてがガバナンスの効いた1つのプラットフォーム上に存在します。データと特徴量、トレーニング、MLflowによるパッケージング、サービング、エージェント、そしてそれらを監視するテレメトリです。スタンドアロンのサービングレイヤーに見えるのはコンテナだけですが、私たちはライフサイクル全体を捉えています。このコンテキストがあるからこそ、プラットフォームはすべてのモデルに合わせて自動調整を行うことができ、後付けのサービング製品ではMLスタック税を解消できない理由でもあるのです。

このようなインフラの課題に興味をお持ちでしたら、採用情報をぜひご覧ください。

今すぐ始める

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