Skip to main content
1 つのモデルをサービングするには、プロファイルと組み合わせて ModelDeployment で直接デプロイします。バンドルは作成されません。 複数のモデルを 1 つの単位としてサービングする場合、投機的デコーディングを設定する場合、または名前付きの構成を検証して共有する場合は、代わりにバンドルを作成します。カスタムバンドルの作成 をご覧ください。

前提条件

デプロイの前に、お使いの環境に応じたクイックスタートを完了してください。

クイックスタート - ホステッド

ホステッド版 SambaStack のシステムセットアップ

クイックスタート - オンプレミス

オンプレミス版 SambaStack のシステムセットアップ
あわせて、以下を確認してください。

モデルのデプロイ

1

YAML ファイルの作成

spec.models の下にモデルとプロファイルをインラインで宣言する YAML ファイルを作成します。
チェックポイントのパスは不要です。チェックポイントは、参照した Model から解決されます。startupTimeout の単位は秒です。ここでの 7200 は、起動プローブが失敗するまでにエンジンがモデルをダウンロードしてロードするための時間として 2 時間を与えるもので、デフォルトの 45 分を大きく上回ります。起動タイムアウト をご覧ください。
2

ModelDeployment の適用

3

デプロイ状態の監視

すべてのサービング Pod が ready ステータスを報告すれば、デプロイは完了です。

デプロイの確認

Pod が ready を報告するのはサービングコンテナが起動したことを意味するだけで、モデルがリクエストに応答することの確認にはなりません。サービング名を確認したうえで、推論リクエストを 1 件送信してください。

サービング名の解決

API に送信する名前は、Kubernetes のリソース名ではありません。関係する名前は 3 つあります。 デプロイした Model からサービング名を読み取ります。
次に、ゲートウェイがそのモデルをサービングしていることを確認します。レスポンス内の各 id が、サービング可能な名前です。
投機的デコーディングのドラフトモデルなど、modelSettings.routable: false が設定されたモデルは、意図的にこの一覧から除外されており、直接アクセスすることはできません。

リクエストの送信

model フィールドにサービング名を使用します。
成功した場合のレスポンスは、model にサービング名を、choices[0].message に生成内容を返します。
usage オブジェクトには、スループットとレイテンシに関する追加のフィールドが含まれます。レスポンスボディの全体像と、各環境で使用する API ドメインについては、クイックスタート - ホステッド または クイックスタート - オンプレミス をご覧ください。
Pod が稼働しているのに model not found エラーが発生する場合、通常はリクエストで spec.name ではなく metadata.name を使用したことが原因です。ロードされて一覧にも表示されるモデルで推論エラーが発生する場合、通常はチェックポイントとプロファイルの model_arch が一致していないことが原因です。デプロイの失敗 をご覧ください。

デプロイメントの更新・削除

デプロイメントの構成を変更するには、その YAML ファイルを編集して再適用します。Legalizer が自動的に変更を再検証します。
デプロイメントを削除するには、次を実行します。

トラブルシューティング

インラインの spec.models 仕様から作成されたデプロイメントは、その場で Legalizer による検証を受けるため、2 種類の失敗の両方が発生し得ます。Legalizer の検証失敗 と デプロイの失敗 については、デプロイメントのトラブルシューティング をご覧ください。

関連ドキュメント

ModelDeployment

デプロイメントリソースの全フィールドのリファレンス

バンドルのデプロイ

複数のモデルを 1 つの単位としてまとめてサービング