インストール後の確認

サービスヘルス、モデル接続性、推論リクエスト、ルーティング動作、エラー処理を検証することで、インストール後にモデル推論ゲートウェイが正しく動作していることを確認します。

モデル推論ゲートウェイをインストールして設定した後、デプロイメントが正しく機能していることを確認します。以下の検証タスクを順番に完了してください。次に進む前に各ステップが成功することを確認してください。

ゲートウェイのヘルス確認

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 を返し、上流エラーをログに記録
不正なモデル IDmodel を存在しない 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 authorityCA 証明書が ca_cert_pem に欠落または誤っている
environment variable not foundenv.* で参照されたシークレットがマウントされたシークレットにない

イベントレベルのエラー (コンテナの起動を防ぐシークレットマウント失敗など) の場合:

oc describe pod -n <bob-namespace> -l app=inference-service

コア推論モデルの切り替え

インストール後にサポートされているコア推論モデルを別のものに切り替えるには:

新しいモデルがデプロイされていることを確認

新しいモデルがデプロイされてサービングされていることを確認します。モデルサービングインフラを参照してください。

モデルゲートウェイ設定ファイルを更新

model-gateway.yaml を更新して新しいモデルを参照します。モデルゲートウェイの設定を参照してください。

変更を適用

bobctl update-model-config を使用して更新された設定を適用します。

bobctl update-model-config --model-config ./my-model-config.yaml --update-secrets

フラグのリファレンスについては設定のデプロイを参照してください。

このトピックはいかがですか?