LLM ゲートウェイ（推論ゲートウェイ）クイズ

このクイズでは、提案する設計の保証事項と制限事項を確認します。対象は、予約、キャッシュの意味、認可、ストリーミング、PII、ガードレール、コンテキストを考慮したルーティングです。ここで名前を挙げるすべてのゲートウェイが、この設計を実装していると主張するものではありません。

選択問題

1. ゲートウェイがディスパッチ前にリソースを予約し、その後に精算するのはなぜですか。

• A. SSE には2回の認証が必要だから
• B. 受付時点では最終的な使用量が分からないため、同時リクエストに対してクォータと金額を原子的に予約する必要があるから
• C. すべての HTTP エラーは無料だから
• D. 入力トークン数の推定値で、厳密な金額上限が保証されるから

答えを表示

答え: B. 受付時点では最終的な使用量が分からないため、同時リクエストに対してクォータと金額を原子的に予約する必要がある

解説: ディスパッチ前に、各呼び出しの検査済み入力と保守的なコスト上限に基づいて予約します。課金対象となるルーター、フィルター、ガードレール、再試行の呼び出しも含めます。メイン処理が拒否されても、すでに発生した補助的な課金は取り消されません。TPM の引き落としだけでは金額を予約したことになりません。予約は実際の課金に冪等に置き換えます。ストリームが中断すると最終使用量を取得できない場合があるため、コストがゼロだと仮定せず、照合が済むまで適切な予約を保持してください。

2. プロンプトキャッシュの保持に関する正しい説明はどれですか。

• A. すべてのプロバイダーで、生の HTTP JSON の各バイトが必ずキャッシュキーに含まれる。
• B. プロバイダー固有のプロンプト／トークンのプレフィックスと、サポート対象のキャッシュ制御を保持する。JSON エンベロープの形式だけでは再利用が無効にならないことがある。
• C. コーディングエージェントのキャッシュヒット率は常に90%を超える。
• D. プロトコル間の変換によって、変換先のキャッシュが温まることはない。

答えを表示

答え: B. プロバイダー固有のプロンプト／トークンのプレフィックスと、サポート対象のキャッシュ制御を保持する。JSON エンベロープの形式だけでは再利用が無効にならないことがある

解説: Anthropic はキャッシュブレークポイントによる同一プロンプトセグメントを説明しています。vLLM はトークンブロックと追加コンテキストをハッシュします。一貫した変換によって、変換先で再利用できるプレフィックスを作れる場合があります。必須のポリシー変換は生データの転送より優先されます。また、キャッシュによるコスト削減は、選択したモデル、TTL、ワークロードで測定してください。

3. フォールバックまたは予算別ティアへの切り替え後に再認可するのはなぜですか。

• A. すべてのフォールバックは自動的に低コストだから
• B. 新しいモデル／プロバイダー／リージョンが、元の認可やプライバシー確認を通過しているとは限らないから
• C. サーキットブレーカーが一時的な権限を付与するから
• D. モデル名が似ていれば、機能も同等だと証明されるから

答えを表示

答え: B. 新しいモデル／プロバイダー／リージョンが、元の認可やプライバシー確認を通過しているとは限らない

解説: 実際の送信先に対して、モデル、リージョン、プライバシー、必須機能、予算を再確認します。元のモデルがすべてのチェックに引き続き合格する場合に限って、そのモデルを使います。それ以外の場合は拒否します。エイリアスの解決や文字列上のバージョン順序は、認可の根拠になりません。

4. ストリーミング応答で透過的なフェイルオーバーを停止する必要があるのはいつですか。

• A. 最初の表示可能なテキストトークンが出力された後だけ
• B. テキストトークンより前であっても、下流のヘッダーや状態を伴うツールイベントによって応答が確定した時点
• C. 最終的な使用量イベントの後だけ
• D. 2つのプロバイダーで1つの応答を安全に共有できるため、停止する必要はない

答えを表示

答え: B. テキストトークンより前であっても、下流のヘッダーや状態を伴うツールイベントによって応答が確定した時点

解説: 応答の確定後に透過的な再試行をすると、内容やツール操作が重複し、追加料金が発生する可能性があります。クライアントプロトコルのエラー処理に従って終了し、未完了の使用量を記録してください。確定前であっても、再試行には試行回数／期限の上限が必要であり、プロバイダーに発生する可能性のある課金を考慮します。出力はユーザーに渡す前に検査する必要があります。バッファリングによってユーザーから見た TTFT が増加することがあります。

5. プライバシー要件とキャッシュコストは、どのように両立させますか。

• A. プレフィックスキャッシュがミスしたら、マスキングを無効にする。
• B. 必須のプライバシー制御を適用し、安全な範囲でスコープを限定した安定的な変換を使い、キャッシュとレイテンシへの影響を測定する。
• C. ツール引数に PII は含まれないため、ユーザーテキストだけを検査する。
• D. 呼び出し元が指定したプレースホルダーは、どれでも元の値に戻す。

答えを表示

答え: B. 必須のプライバシー制御を適用し、安全な範囲でスコープを限定した安定的な変換を使い、キャッシュとレイテンシへの影響を測定する

解説: 機密データはテキストだけでなく、ツール、結果、添付ファイルにも含まれる可能性があります。検査がサポートされていない場合はブロックするか、承認済みの送信先を使ってください。対応表を認証済みのテナント／プリンシパル／セッションに結び付け、復元を認可します。対応表が失われると正確性に影響することがあります。検出には偽陰性があるため、ゲートウェイも分類器も、情報漏えいが皆無であることを証明できません。

6. Bedrock Guardrails はどのように統合するのが適切ですか。

• A. ガードレールを作成すれば、すべての呼び出しに自動で適用される。
• B. 選択した API のガードレール用フィールドを使い、スコープを検証し、サポートされる場合は承認済み ID／バージョンを強制する。
• C. 非同期モードを使えば、機密情報のマスキングが保証される。
• D. すべての Bedrock API で同じトップレベルの JSON フィールドを使う。

答えを表示

答え: B. 選択した API のガードレール用フィールドを使い、スコープを検証し、サポートされる場合は承認済み ID／バージョンを強制する

解説: Converse は guardrailConfig を使います。InvokeModel は guardrailIdentifier／guardrailVersion を操作パラメーター（HTTP ヘッダー）として使います。guardContent で評価範囲を指定でき、ApplyGuardrail はモデルを呼び出さずにコンテンツを評価します。適切な IAM 条件とバイパス防止によって、ゲートウェイのポリシーを補強できます。非同期ストリーミングでは検査前にコンテンツが配信される可能性があり、機密情報のマスキングもサポートされません。ログやトレースも保護する必要があります。

7. キャッシュブレークポイントの近くにゲートウェイポリシーのプロンプトを挿入するとき、何に注意しますか。

• A. それ以降のリクエストでは、必ずキャッシュヒットする。
• B. 意図したキャッシュ境界内でポリシー内容を安定させ、認証済みのゲートウェイメタデータだけを重複排除する。
• C. キャッシュマーカーの後ろにあるブロックは、必ず前のセグメントを無効にする。
• D. 呼び出し元が指定した一致するハッシュが、ポリシーの適用を証明する。

答えを表示

答え: B. 意図したキャッシュ境界内でポリシー内容を安定させ、認証済みのゲートウェイメタデータだけを重複排除する

解説: キャッシュの再利用は、サポートされる同一セグメント、モデル要件、最小長、スコープ、TTL に左右されます。後続のブロックは、それ以前のキャッシュ済みセグメントを必ず無効にするのではなく、その外側に置かれます。コピーされたポリシーマーカーによって、必須の挿入やスキャンを省略してはいけません。プロンプトは指針であり、実行可能な認可ではありません。

8. ツールの認可は、最終的にどこで強制する必要がありますか。

• A. システムプロンプトだけ
• B. 危険なシェル文字列の正規表現照合だけ
• C. ツール実行側で行い、ゲートウェイの出力チェックを追加の層として使う
• D. プロバイダーから最終使用量が返された後だけ

答えを表示

答え: C. ツール実行側で行い、ゲートウェイの出力チェックを追加の層として使う

解説: ゲートウェイはツール呼び出しの引数全体をバッファリングして検証するべきですが、バイパスや、すでに実行されたプロバイダー側ツールまで制御できるわけではありません。実行側には、認証済み ID、リソース／引数の認可、スキーマ検証、最小権限、サンドボックス化、機密操作の承認が必要です。モデルのロールラベルやツール名だけでは、信頼性を証明できません。

9. 分散環境で保守的な金額ベースの予算を運用するための不変条件はどれですか。

• A. 各レプリカがチーム全体の上限額を個別に使える。
• B. 使用済み額と未処理の予約枠の合計を上限以内に保ち、予約と照合を永続化して冪等に行う。
• C. グラントの合計が、自動的に最悪時の超過額の上限になる。
• D. 期限切れグラントは、常にただちに再発行できる。

答えを表示

答え: B. 使用済み額と未処理の予約枠の合計を上限以内に保ち、予約と照合を永続化して冪等に行う

解説: 利用可能予算から差し引かれたグラントは、予約済みのキャパシティであり、超過利用枠ではありません。保守的なコスト上限、原子的なローカル受付、永続的な ID、照合を使います。期限切れになると新しい受付は停止しますが、未解決の処理や報告が残っている間は、安全に枠を再利用できません。計測対象となるヘルパー、メインモデル、出力チェックの呼び出しも、それぞれ予約を行って同じ予算を消費します。金額ベースのリースによって、レートカウンターまで自動的にグローバル化されるわけではありません。

10. インフラストラクチャのコンテキストをルーティングに反映する場合、どの点が重要ですか。

• A. 許可されたリージョンが遅ければ、より高速な任意のリージョンを使ってよい。
• B. ヘルス／負荷は、すでに認可された送信先の中から選ぶために使い、モデル／リージョン／プライバシーの許可範囲を広げない。
• C. ソースエンドポイントのリージョンを確認すれば、すべての処理がそのリージョン内だと証明できる。
• D. 分類器が失敗すると、予算ポリシーは無効になる。

答えを表示

答え: B. ヘルス／負荷は、すでに認可された送信先の中から選ぶために使い、モデル／リージョン／プライバシーの許可範囲を広げない

解説: ポリシーの境界内で、可用性やエンドポイントの判断にヘルスシグナルを利用します。Bedrock の推論プロファイルはソースリージョンの外にもルーティングする可能性があるため、すべての送信先を確認してください。最終的なコンテキストへの適合性を判断する際は、変換後の入力と、送信先モデルの出力／推論用の割り当て量の両方を含めます。必要なチェックをすべて通過する場合に限り、元のモデルにフォールバックできます。

11. ゲートウェイはトークン数のカウント用エンドポイントをどのように扱うべきですか。

• A. 認可されていないリクエストを含め、常に HTTP 200 を返す。
• B. 認証、認可、検証エラー、独立したレート制限を維持し、任意の近似値へのフォールバックはその旨を明示する。
• C. bytes/4 の推定値を、プロバイダーによる正確なカウントとして扱う。
• D. 推論ではないため、リクエストサイズや CPU の制限を無視する。

答えを表示

答え: B. 認証、認可、検証エラー、独立したレート制限を維持し、任意の近似値へのフォールバックはその旨を明示する

解説: カウント処理には、プロバイダー固有の検証エラーや独自の RPM 制限がある場合があります。これは推論の支出として差し引く処理ではありませんが、ゲートウェイ／プロバイダーのリソースは消費します。任意の近似値へのフォールバックによって、拒否を覆したり、出所を隠したり、コンテキストに正確に適合することを保証したりしてはいけません。製品固有の互換性シムを、汎用 API の要件とみなすこともできません。

12. メトリクスのラベルにユーザー ID／キー ID や生のプロンプトを含めない方がよいのはなぜですか。

• A. SSE を圧縮するため
• B. カーディナリティを抑え、ID／コンテンツの開示を減らすため。ただし、スクレイプアクセスも引き続き制限する必要がある。
• C. メトリクスにはチームラベルを含められないため
• D. 暗号化すればラベルに関するリスクがすべてなくなるため

答えを表示

答え: B. カーディナリティを抑え、ID／コンテンツの開示を減らすため。ただし、スクレイプアクセスも引き続き制限する必要がある

解説: 正規化されたモデル／プロバイダーや、適切な場合は設定済みのチーム名など、レビュー済みで種類数が制限されたラベルを使ってください。メトリクス／管理用エンドポイントを保護し、トレース属性やエラーにプロンプトを含めないようにします。セマンティック規約のバージョンを管理し、エクスポーターの命名も検証してください。カーディナリティが低くても、それだけで公開アクセスが許可されるわけではありません。