インストール後の確認
サービスヘルス、モデル接続性、推論リクエスト、ルーティング動作、エラー処理を検証することで、インストール後にモデル推論ゲートウェイが正しく動作していることを確認します。
モデル推論ゲートウェイをインストールして設定した後、デプロイメントが正しく機能していることを確認します。以下の検証タスクを順番に完了してください。次に進む前に各ステップが成功することを確認してください。
ゲートウェイのヘルス確認
Inference Service Pod が実行中で、すべてのコンテナが Ready であることを確認します。
oc get pods -n <bob-namespace> -l app=bob-inferenceゲートウェイ初期化の起動ログを確認します。起動成功時には設定済みの各モデルが登録されるログが出力されます。クレデンシャルまたは設定の解析エラーはここに表示されます。
oc logs -n <bob-namespace> deploy/bob-inference --since=5mクラスター内からゲートウェイの /v1/models エンドポイントが応答していることを確認します — これがゲートウェイが起動して設定を読み込んでいる最も明確なシグナルです。
oc exec -n <bob-namespace> deploy/bob-gateway -- \
curl -sk https://bob-inference.<bob-namespace>.svc.cluster.local:7330/v1/model/info | jq .モデル接続性の検証
期待される各 model_name の /v1/models レスポンスを確認します。接続に失敗したモデル (不正な URL、認証エラー、TLS 障害) はリストに表示されないか、エラーステータスで表示されます。
model_info で exposed: true に設定されたモデルのみがパブリックの /v1/models リストに表示されます。exposed: false のモデル (例: ガードレールモデル) は表示されませんが、内部的には到達可能である必要があります。リストへの非表示は接続障害とは限りません。
モデル推論のテスト
コアモデルとガードレールモデルの両方について、クラスター内から Inference Service に直接最小限のテスト補完リクエストを送信します。
oc exec -n <bob-namespace> deploy/bob-gateway -- \
curl -sk https://bob-inference.<bob-namespace>.svc.cluster.local:7330/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "<model_name>",
"messages": [{"role": "user", "content": "Say hello."}],
"max_tokens": 10
}' | jq .成功レスポンスには message.content フィールドを持つ choices 配列が含まれます。
一般的なエラー:
| HTTP ステータス | 原因 |
|---|---|
401 Unauthorized | クレデンシャルが無効または権限が不足 |
404 Not Found | 指定されたモデル ID がプロバイダーに存在しない |
502 Bad Gateway | 上流のモデルエンドポイントに到達できない |
ガードレールモデルは到達可能でリクエストを処理できる必要があります。ガードレールモデルが利用できない場合、IBM Bob はすべての推論リクエストを拒否します。インストールが完了したと見なす前に、ガードレールの検証が成功することを確認してください。
モデルルーティングの検証
レスポンスの model フィールドがリクエストされた model_name と一致することを確認して、プライマリモデルが正しくルーティングされることを確認します。
モデルエントリに fallbacks が設定されている場合は、プライマリモデルの base_url を一時的に到達不可能なホストに向けてゲートウェイがリスト内の次のモデルにフォールバックすることを確認してフォールバックパスを検証します。テスト後に正しい base_url を復元してください。
exposed: false のモデルについては、パブリックモデルリストに表示されなくても内部ルーティングが正しく解決されることを確認します。
エラー処理の検証
ゲートウェイが障害を適切に処理することを確認するために、以下の意図的なネガティブテストを実行します。
| テスト | トリガー方法 | 期待される動作 |
|---|---|---|
| 無効な API キー | シークレットに誤ったキー値を一時的に設定 | ゲートウェイが 401 を返し、クラッシュしない |
| 到達不可能なエンドポイント | base_url を無効なホストに設定 | ゲートウェイが 502 または 503 を返し、上流エラーをログに記録 |
| 不正なモデル ID | model を存在しない ID に設定 | プロバイダーが 404 を返し、エラーが呼び出し元に表示される |
| シークレット環境変数の欠落 | bob.modelGateway.secrets からキーを削除 | リクエスト時に欠落した変数を参照するログエラーで失敗 |
| 期限切れの TLS 証明書 | ca_cert_pem として期限切れの証明書を提供 | リクエスト時に TLS ハンドシェイク失敗がログに記録 |
ログの収集とトラブルシューティング
テストリクエスト中にライブログをストリームして、リアルタイムでゲートウェイのルーティング決定を観察します。
oc logs -n <bob-namespace> deploy/bob-inference -fサポートへの共有用にフルログダンプを収集します。
oc logs -n <bob-namespace> deploy/bob-inference --since=1h > bob-inference.log主要なログパターン:
| ログパターン | 意味 |
|---|---|
| Model registered successfully | ゲートウェイがエラーなしでモデルエントリを読み込みました |
connection refused / no route to host | モデルエンドポイントへの接続障害 |
上流からの 401 / 403 | クレデンシャルが誤っているか、必要な権限がない |
certificate signed by unknown authority | CA 証明書が ca_cert_pem に欠落または誤っている |
environment variable not found | env.* で参照されたシークレットがマウントされたシークレットにない |
イベントレベルのエラー (コンテナの起動を防ぐシークレットマウント失敗など) の場合:
oc describe pod -n <bob-namespace> -l app=inference-serviceコア推論モデルの切り替え
インストール後にサポートされているコア推論モデルを別のものに切り替えるには:
新しいモデルがデプロイされていることを確認
新しいモデルがデプロイされてサービングされていることを確認します。モデルサービングインフラを参照してください。
モデルゲートウェイ設定ファイルを更新
model-gateway.yaml を更新して新しいモデルを参照します。モデルゲートウェイの設定を参照してください。