Databricks Certified Generative AI Engineer Associate 教科書
第4章 アプリケーションの組み立てとデプロイ(Assembling and Deploying Applications, 22%)
🎯 この節の学習目標
LLMアプリの推論コストは、大づかみには「単価 × トークン量 × 呼び出し回数」と「確保しているコンピュート(待機時間を含む)」で決まります。最適化の打ち手も、この構造に対応して整理できます。
まず効くのがモデルサイズの適正化です(1-2の復習)。要件を満たす最小のモデルを選ぶのが原則で、分類や抽出のような定型タスクに最大級のモデルを使うのは典型的な無駄です。小さいモデルは単価が安いだけでなくレイテンシも短いため、品質要件を満たす限り「小さいほど良い」が基本線です。
Foundation Model API(4-2)には2つの課金モデルがあります。試験でも使い分けがよく問われます。
| 方式 | 課金 | 向いている状況 |
|---|---|---|
| pay-per-token | 処理したトークン量に応じた従量課金。使わなければゼロ | 低頻度・変動が大きいワークロード。PoC・開発・社内ツールなど |
| Provisioned Throughput | 確保したスループット(処理能力)に応じた課金。性能が保証される | 高頻度・安定した高負荷の本番ワークロード。SLAやレイテンシ保証が必要な場合 |
考え方は携帯電話の「従量プランと定額プラン」と同じです。利用量が少ないうちはpay-per-tokenが安く、利用量が増えて安定すると、ある損益分岐点からProvisioned Throughputの方が単位あたりコストで有利になり、かつスループットとレイテンシが安定します。
💼 例:フェーズによる切り替え
開発・PoCフェーズでは呼び出しが散発的なのでpay-per-tokenで始めます。本番リリース後、毎日安定して大量のリクエストが来るようになり、ピーク時のレイテンシ保証も必要になった時点でProvisioned Throughputへ切り替える——これが典型的なライフサイクルです。逆に、月に数回しか動かないバッチ用途を定額で確保し続けるのは無駄の典型です。
カスタムモデルエンドポイント(4-2)では、scale-to-zeroを有効にするとアイドル時にコンピュートがゼロまで縮退し、リクエストがない間の課金を抑えられます。ただしゼロ状態から最初のリクエストを受けると、コンテナ起動・モデルロードのためのコールドスタート遅延が発生します。
| 設定 | コスト | レイテンシ | 向く用途 |
|---|---|---|---|
| scale-to-zero有効 | アイドル時ゼロで安い | 初回リクエストにコールドスタート遅延 | 開発・検証環境、利用が散発的な社内ツール |
| scale-to-zero無効 | 待機分も課金される | 常に安定 | 応答速度が重要な本番の顧客向けアプリ |
📝 試験のポイント
「開発環境のエンドポイントのコストを削減したい」→ scale-to-zeroを有効化。「本番で初回応答が遅いという苦情」→ scale-to-zeroが原因のコールドスタートを疑う。この双方向の出題に対応できるようにしましょう。
従量課金では、入力・出力トークンがそのままコストです。品質を保ちながらトークンを削る主な手段は次の通りです。
💡 例:チャンク数削減+max_tokens制御
# 多めに取得 → リランキングで上位3件だけをLLMへ
retriever = index.as_retriever(search_kwargs={"k": 20})
top_chunks = rerank(query, retriever.invoke(query))[:3]
# 出力上限を要件(短い要約)に合わせる
llm = ChatDatabricks(
endpoint="databricks-llm-endpoint",
max_tokens=256,
)
「渡すチャンクを20個から3個へ」「出力上限を256トークンへ」とするだけで、1リクエストあたりのトークン量は大きく減ります。品質への影響は評価(第5章)で確認しながら詰めます。
キャッシング:FAQボットのように同じ質問が繰り返されるアプリでは、同一(または意味的に同等の)クエリに対する応答をキャッシュして返せば、LLM呼び出し自体を回避できます。最も高価な処理を「実行しない」ことによる削減です。
バッチ推論:リアルタイム応答が不要な大量処理(数万件のレビュー分析など)は、1件ずつオンラインエンドポイントに投げるのではなく、ai_query()による一括実行(4-2)でまとめて処理します。ジョブとしてスケジュール実行すれば、常時稼働のエンドポイントを維持する必要もありません。
ガバナンスによる統制(4-4の復習):個々の最適化と並行して、Unity AI Gatewayで組織としてのコスト統制をかけます。
試験では「状況+コスト削減したい」という形で問われます。状況ごとの第一の打ち手を整理します。
| 状況(問題文のシグナル) | 第一の打ち手 |
|---|---|
| 簡単な定型タスクに大型モデルを使っている | 要件を満たすより小さいモデルへ変更(1-2) |
| 利用が低頻度・散発的なのに定額で確保している | pay-per-tokenへ切り替え |
| 高頻度・安定高負荷で従量課金が高額化 | Provisioned Throughputを検討 |
| 開発環境のエンドポイントがアイドル時間も課金されている | scale-to-zeroを有効化 |
| RAGのプロンプトが長大(チャンクを大量に渡している) | チャンク数削減・リランキングでコンテキストを圧縮 |
| 応答が不必要に長い | max_tokensを制御 |
| 同じ質問への回答を毎回生成している | キャッシング |
| 大量データへの非リアルタイム処理を1件ずつ呼んでいる | バッチ推論(ai_query一括実行) |
| 特定チーム/ユーザーの利用暴走が怖い・実態が見えない | Unity AI Gatewayのレート制限+使用状況トラッキング(4-4) |
📝 試験のポイント
コスト問題では「品質要件を犠牲にしない範囲で」という条件が付くのが通例です。「モデルを最小にする」「チャンクを渡さない」のような極端な選択肢は、品質要件に反するため誤答になります。要件を満たしつつ無駄だけを削る選択肢を選んでください。
✅ この節のまとめ
問1. 社内向けPoCとして構築したLLMアプリは、利用が1日数回程度と散発的である。推論コストを最小化する課金・構成の選択として最も適切なものはどれか。
正解:B
低頻度・変動の大きいワークロードには、使った分だけ課金されるpay-per-tokenと、アイドル時にゼロへ縮退するscale-to-zeroの組み合わせが最適です。AのProvisioned Throughputは安定高負荷向けで、散発利用では待機分が無駄になります。C・Dは待機コストを最大化する構成で正反対です。
問2. 本番のRAGボットで、検索でヒットした20個のチャンクをすべてプロンプトに含めており、トークンコストが高騰している。回答品質をできるだけ保ちながらコストを下げる最も適切な方法はどれか。
正解:B
リランキングで上位の少数チャンクだけを渡せば、プロンプト長(=入力トークン)を大幅に削減しながら関連性の高い文脈は維持できます。AはRAGの根拠付けを放棄して品質要件に反し、Cはコストをさらに倍増させ、Dの質問文はコンテキストに比べ僅少で効果がほぼありません。
問3. 毎晩、数十万件の商品レビューに感情分析を実行する必要がある。リアルタイム性は不要である。コスト効率の良い実行方法として最も適切なものはどれか。
正解:B
リアルタイム性が不要な大量処理は、ai_query()による一括バッチ推論をジョブでスケジュールするのが定石です。Aはオンライン呼び出しのオーバーヘッドが件数分積み上がり非効率、Cはエンドポイント作成の起動コストが支配的になる非現実的な構成、Dはコンテキスト長の上限を超え、結果の対応付けもできません。
問4. 経営層から「全社のLLM利用コストが見えない。まず部門別の利用実態を把握し、暴走的な利用を防止せよ」と指示された。最も適切な打ち手はどれか。
正解:B
「利用実態の把握」→使用状況トラッキング(システムテーブルへの利用記録)、「暴走防止」→レート制限と、要求がそのままUnity AI Gatewayの機能に対応します(4-4)。Aは正確性と強制力がなく、Cは業務を止める過剰反応、Dは可視化にも暴走防止にもならず、品質要件を損なう恐れもあります。