Demystifying Batch Inference On Databricks | by AI on Databricks | May, 2025 | Mediumの翻訳です。
本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
著者: Ashwin Srikant (Senior Solutions Architect @ Databricks), Andrew Shieh (Software Engineer @ Databricks), Ankit Mathur (Staff Software Engineer @ Databricks)
イントロダクション
ビジネスにおける非構造化データから洞察を得ることはこれまでは、極端に手動で高価なものでした。しかし、基盤モデルは何ができるのかに関する期待値をクイックにリセットしました。これらのモデルは、納得できるコストでテキストに対するインテリジェントな分析を提供し、モデルが自動化されるという事実によって、企業は彼らの最大のデータセット(顧客のレビュー、ログ、書籍の全体)すらも分析できるようになりました。これはジェボンズのパラドックスの体現です。
バッチ vs. リアルタイム
技術的には、この種のワークロードのプラットフォームの構築はとても興味深いものです。バッチシステムとリアルタイムシステムにブレークダウンするベストな方法に関して、システムのコミュニティで数多くの長期にわたる議論が起きています。一般的には、バッチ処理はリアルタイム処理で使われるよりも効率的に行われると考えられています。バッチにおける違いや興味深いことは:
- 個々のリクエストのレイテンシーは重要ではありません - ジョブの全体のレイテンシーに注意すべきです。
- データの規模はとてつもないものであり、多くの場合リアルタイムよりもはるかに大きいものです - 数テラバイトのデータを格納することがあるテーブルが処理されます。
- 極端にバーストな需要があります - 推論処理は完全に並列化可能なので、短い時間で一度に処理を行うには、多くのコンピュートを持つことが望ましいです。
しかし、LLM推論においては、従来のバッチジョブと異なる対応が必要です: モデルは現状非常にキャパシティの制約のあるNVIDIA H100のようなベストなハードウェアでのみコスト効率よく動かすことができます - これらのプールの維持は非常に高価であり、このため、真の弾力性を提供することは困難です。
究極的には、これはうまく動作するリアルタイム製品やバッチ製品を実行する際には、使用率を最大化するためにコンピュートプールやサーバーであっても、それらを実行する際の大きなコスト効率性が存在することを意味します。これは、プロキシーのようなリアルタイムのプリミティブにおける非常に高スケールのサポートや、リアルタイムとバッチのリクエスト間の優先度付け、リソースが注意深く管理され、ジョブが適切にスケジュールされていることの保証のようないくつかの課題をもたらします。
簡単なことかもしれませんが、この問題をユーザーに引き渡すだけでこの問題を解決することができます。これまでは、Databricksにおけるバッチ推論の実行には、秒あたりのトークン数のためのキャパシティを保証するための専用エンドポイントをユーザーが作成できる、Databricksプロビジョン済みスループットのの活用が含まれていました。しかし、この世界においては、ユーザーはインフラストラクチャを管理し、これらの問題を解決しなくてはなりません。
最近では、DatabricksはAI関数によるサーバレスバッチ推論のサポートを発表しました - 手動でコンピュートキャパシティをプロビジョンすることなしに、すべてをDatabricks SQL内でバッチ推論を即座に実行する方法です。ユーザーが送信したらすぐにジョブがスタートするので、既存のETLとのシンプルなインテグレーションを可能にします。これは、ユーザーのワークフローを劇的にシンプルにし、インフラストラクチャ管理のオーバーヘッドを回避できますが、シェーリング、構成な共有、バックエンドのロードバランシングなど上でハイライトしたエンジニアリングの課題への対応を必要とします。
このブログ記事では、お客様がサーバレスバッチ推論ジョブを実行する際に、内部で起きているエンジニアリングを深掘りします。
サーバレスバッチ推論とは
Sparkクラスターのような事前にプロビジョンしたコンピュートを必要とする従来のバッチ推論とは異なり、サーバレスバッチ推論はワークロードの需要に基づいて動的にリソースを割り当てます。これによって、アイドル状態のコンピュートコストを排除し、効率性を最適化しつつも、ユーザーのワークフローをシンプルにします。
主要な特徴
- プロビジョンレス: 不必要なエンドポイントの事前プロビジョンとインフラ管理を回避します。
- 高いスループット: ジョブは高速なデータ処理を実現するために高スループットにスケールします。
- 即座の実行: 新規ジョブは割り当てられたコンピュートで即座に処理を開始します。
- ロードバランシング: 推論ジョブにおける効率性とコンピュートの公正な分配を保証します。
- 予測可能性: ジョブが概ね同じ時間で処理が完了するように、実行するたびに同じボリュームのコンピュートを取得します。
- コスト最適化: 推論ジョブで使われたコンピュートのみに支払い、アイドル状態のエンドポイントのコストを回避します。
- Databricks SQLネイティブ: Databricks SQLから離れることなしに、ジョブを定義、実行できます。
現時点では、サーバレスバッチ推論は3つのモデルで利用できます: LLama3.1–8B、LLama3.3–70B、LLama 4-Maverick、そしてGTE-Largeが利用でき、間も無く他のモデル(Claude 3.7 Sonnetなど)も利用できるようになります。
スケーリングの動作原理
サーバレスバッチ推論では、ワークロードをスケールさせるために数多くのテクニックを活用します。以下のステップに従います:
ジョブの送信: ユーザーは任意のDatabricks SQLインタフェースからバッチ推論ジョブを送信します。以下のみが必要であることに注意してください。
- プロンプト
- 選択したモデル
- 入力テーブルとカラム名
重要なことですが、ジョブを実行する前にはプロビジョン済みスループットのエンドポイントは作成されません。 以下のクエリーは、すべてのDatabricksワークスペースで利用できる(samplesカタログ配下の)データセットを用いた例です。
SELECT ai_query(
"databricks-meta-llama-3-3-70b-instruct",
"Extract data about which cookie store location this review is about and which cookies were tried: " || review,
responseFormat => 'STRUCT<cookie_review_extraction:STRUCT<city:STRING, cookies:ARRAY<STRING>>>'
)
FROM samples.bakehouse.media_customer_reviews;
リソース割り当て: バッチ推論のスケジューリングシステムは、新たなワークロードにバックエンドコンピュートノードのポーションを割り当て、すぐに処理が開始されるようにします。バックエンドはさらなるワークロードに対応するために全体的な需要に基づいて、コンピュートノードの数を独立してスケールさせます。
重要なことですが、リソースの割り当てとスケーリングは競合する優先度のバランスを取る必要があります:
- 予測可能性 & デッドラインの満足(指定されたジョブを明日も期待するのとおおよそ同じ時間で完了)
- 即座実行(すべてのジョブをスタート)
- 高スループットを維持(多くのコンピュートを用いた大規模ジョブを保証)
他の目的は置いておいて、1つの目的を達成することは簡単です。例えば、プールが大規模であったとしても、すべてのジョブで低く一貫性のあるスループットを提供することがあります。これは、予測可能な(悪い)体験につながります。同様に、すべてのジョブがすぐにスタートすることもありえます。あるいは、高スループットのみがゴールなのであれば、スケジューラーをシンプルに排除して、すべてのジョブに利用可能なすべてのリソースを使わせることもできます。最後になりますが、新たなジョブにおけるリソース枯渇が問題でないのであれば、シンプルなアルゴリズムでジョブに対するスループットを割り当てることができます。
タスク実行: Databricks SQLにおいては、Sparkドライバーはエンドポイントにバッチ推論のリクエストを送信する、それぞれのSparkエグゼキューターの同時実行性をスケールアップ、スケールダウンをて公的に行います。Sparkエグゼキューターはレート制限を受けたリクエストを再試行します。レート制限の比率が高い場合には、ドライバーは同時実行性を引き下げます。
スケーリング: バッチ推論のスケジューラーは、ワークロードに対する既存のコンピュートの割り当てで、ai_queryが飽和させることが可能かどうかに関して、ネットワークプロキシーからのシグナルを受信します。
- リクエストの多くがレート制限を受けるなど、既存の割り当てでワークロードが飽和する場合には、システムは多くの場合、ワークロードに対する乗数増加を許可するアルゴリズムを実行します。このアルゴリズムは、過度にセンシティブになることの回避、長期間のジョブをより高いスループットにプッシュするなどのいくつかの制約を考慮します。システムがバックエンドの合計コンピュートキャパシティに近づいた際には、すべての実行ジョブに割り当てられたコンピュートリソースを公平に減少させます。
- スケジューラは大規模なワークロードに対して、時間と共により多くのコンピュートを追加することで、スルーぷっっとが指数関数的に改善する傾向を持つように、製品の体験をクイックに改善するためにランプアップします。
安全な解体: バッチ推論が完了したら、ワークロードに割り当てられたコンピュートは自動でリリースされます。
バッチ推論 vs プロビジョン済みスループット vs Pay-Per-Token
現時点でDatabricksにおける推論ワークロードを支援している既存のプロビジョン済みスループットやPay-Per-Token(トークンあたりの課金)とバッチ推論をどのように比較したらいいのでしょうか？特筆すべきいくつかの違いがあり、以下でこれらのトレードオフを説明します。
サマリー: バッチ推論はすべてのオフライン推論タスクで最も適しています。 動的なオートスケーリングによって、バッチ推論はすべてのサイズとリクエスト形態のワークロードに対応できます。
| 機能 | バッチ推論 | プロビジョン済みスループット | Pay-Per-Token |
|---|---|---|---|
| スケーリング | ワークロードに応じて動的にオートスケール | ユーザーが定義したトークンのレンジに基づいてオートスケールするコンピュートを事前に割り当て | スケールしない静的なレート制限 |
| コスト構造 | 正確に使用したコンピュートの分だけ支払い | エンドポイントの起動時間に対する支払いであり、シャットダウンしない場合にはアイドルコストを引き起こす場合あり | 使用した入出力トークンに対する支払い |
| パフォーマンス | ワークロードに応じて弾力的にスケールする専用コンピュート | ユーザーが定義したレンジにおいてスケールするスループットを保証 | スループットは保証されない |
| ユースケースへの適合性 | オフラインで処理されるプロダクションワークロードに最適 | リアルタイムのプロダクションワークロードに最適 | 小規模なワークロード、実験、プロトタイプに最適 |
| ジョブ起動のレイテンシー | 即座のコンピュート配備によって定常的に低レイテンシー | 常時稼働のリソースによって定常的に低レイテンシー | 初期のレイテンシーが発生する場合あり |
| オペレーションの複雑性 | オートスケーリングを伴う完全マネージド | 規模を適切に設定するためのキャパシティ計画と監視が必要 | 完全マネージド |
他のプロバイダーとDatabricksバッチ推論の比較
Databricksのサーバレスバッチ推論は即座にワークロードをスタートするので、他のバッチ推論プロバイダーと比較して、より即時性が保証されたターンアラウンド時間を提供します:
- Amazon Bedrock: 通常バッチ推論ジョブは24時間以内に完了しますが、実際にはジョブのサイズやその他の要因によって時間は変動します。
- OpenAI Batch API: 24時間ウィンドウでリクエストを処理することを狙いとしています。
- Databricksバッチ推論: ワークロードは即座にスタートし、多くの場合数分以内に完了します。大規模なワークロードは処理に数時間を要する場合があります。 バッチ推論のワークロードは、DatabricksワークフローやDatabricksジョブの一部として、他の任意のワークロードように実行、スケジュールすることができます。
さらに、サーバレスバッチ推論はノートブックやSQLエディタを含む、すべてのDatabricksのSQLインタフェースと完全にインテグレーションされており、ユーザーは自身のクエリー環境から離れることなしに、バッチ推論ワークロードを実行することができます。これによって、ユーザーは以下に示すようにクエリープロファイルを通じて、バッチ推論ジョブがどれだけ進行しているのかに関してのリアルタイムでの統合された観測可能性を活用することができます:
これは、個々のエグゼキューターから報告されるメトリクスの集計によって可能となっており、ドライバーによってクエリープロファイルを通じてレポートされます。
まとめ
Databricksのサーバレスバッチ推論は、特定のワークロードに適したエンドポイントのコンピュートを特定しようとする複雑性を抽象化し、ユーザーインタフェースを直接Databricks SQLに連携させることで、大規模な生成AIワークロードをシンプルにします。これによって、開発者はバッチ推論やよりビジネス上重要な機能を含むエージェントのフロー、品質、評価メトリクスにフォーカスできるようになり、インフラストラクチャの管理をDatabricksに任せることができます。
すぐにDatabricksのバッチ推論を試したいのであれば、すべてのクラウドにおいてデフォルトで上述したモデルとAI_QUERYを利用することができます。フリートライアルはこちらから試せます！