デプロイ#

デプロイの概要#

Backend.AI では、デプロイ（Deployments） 機能を通じて AI モデルを推論サービスとしてデプロイできます。デプロイは、モバイルアプリやウェブサービスのバックエンド、社内ツールなどのエンドユーザーアプリケーションが推論を実行するために呼び出せる、安定したエンドポイント URL の背後にモデルを公開します。

デプロイは通常のコンピュートセッションを拡張し、自動メンテナンス、レプリカのスケーリング、そしてレプリカの増減に左右されない永続的なエンドポイントアドレスを提供します。必要なスケーリングパラメータを指定するだけで、Backend.AI が内部の推論セッションを自動的に作成・監視・終了するため、セッションを手動で管理する必要はありません。

デプロイページ#

デプロイページには、現在のプロジェクト内のすべてのデプロイの一覧が表示されます。サイドバーメニューの デプロイ をクリックしてアクセスできます。

ページ上部で、ライフサイクルステージ別にデプロイをフィルタリングできます：

• アクティブ: 現在実行中または作成中のデプロイを表示します。これがデフォルトビューです。
• 破壊された: 終了したデプロイを表示します。

また、プロパティフィルターバーを使用して、デプロイ名、サービスエンドポイントURL、または オーナー（管理者およびスーパー管理者に提供）でデプロイを検索できます。

デプロイを作成 ボタンをクリックしてデプロイ作成モーダルを開きます。

デプロイの作成#

デプロイを作成するフローは次の 2 ステップに分かれています。

1. デプロイメントの作成 — デプロイメントのアイデンティティ情報（名前、公開範囲、デプロイメントメタデータ、リソースグループ）のみを定義する軽量なコンテナを作成します。
2. Revision の追加 — 実際に実行される構成（起動コマンド、環境変数、ランタイムバリアント、イメージ、リソース、モデルストレージ）を含む設定スナップショットを追加します。

1 つのデプロイメントは複数の Revision を保持できます。任意の時点で 現在 の Revision（トラフィックを処理する Revision）は 1 つだけであり、デプロイ詳細ページの Revisions タブから他の Revision に切り替えることができます。

デプロイメント作成モーダル#

デプロイページで デプロイを作成 ボタンをクリックすると、デプロイメント作成 モーダルが開きます。このモーダルではデプロイメント単位のメタデータのみを入力し、この段階で Revision は作成されません。

モーダルには次のフィールドが含まれます。

• デプロイ名: ダッシュボード、API、エンドポイント URL でデプロイメントを識別するための一意の名前です。
• リソースグループ: デプロイメントが実行されるリソースグループです。プロジェクトで利用可能なリソースグループが 1 つしかない場合は自動的に選択され、手動で選択しなくても先に進めます。
• 希望レプリカ数: このデプロイメントで実行し続けるレプリカ数です。システムはアクティブプールをこの目標に向けてスケーリングします。
• タグ: デプロイメントを整理・フィルタリングするための任意のラベルです。Enter またはカンマで追加します。
• 公開: 有効にすると、アクセストークンなしでエンドポイントにアクセスできます。無効にすると、すべてのリクエストにトークンが必要です。詳細は トークンの生成 を参照してください。

デプロイを作成 をクリックするとデプロイメントが作成され、デプロイ詳細ページに移動します。最初の Revision を追加するまで、デプロイされたリビジョンがありません 警告が表示されます。作成後にデプロイレベルの設定（名前、公開設定、希望レプリカ数、タグ）を更新するには、サービス情報カードの 編集 ボタンをクリックします。

Revision の追加#

Revision には、推論サーバを実行するために必要なすべての設定（イメージ、起動コマンド、リソース、モデルマウント、環境変数）が含まれます。デプロイ詳細ページで Revision を追加 ボタンをクリックしてモーダルを開きます。

モーダルのタイトル部にある プリセットモード / 高度な設定モード の切り替えスイッチで、Revision の構成方法を選択します。

デプロイに現在の Revision がある場合、両方のモードの上部に 現在の Revision を読み込む バナーが表示されます。現在の Revision を読み込む をクリックすると、現在適用中の Revision の設定を開始点としてフォームに事前入力します（必要に応じて自動的に高度な設定モードに切り替わります）。現在の Revision がまだないデプロイではバナーは表示されず、設定を一度読み込むとバナーは消えます。

プリセットモード#

あらかじめ定義されたデプロイメントプリセットを使用して、Revision をすばやく追加します。

• プリセット: デプロイメントのリソースグループと互換性のあるデプロイメントプリセットです。セレクタ横の ⓘ ボタンをクリックすると、プリセットの詳細構成を確認できます。
• モデルフォルダー: 各レプリカにマウントされるストレージフォルダーです。

デプロイメントのリソースグループに対応するプリセットがない場合は、案内メッセージが表示されます。その場合は高度な設定モードに切り替えて手動で構成してください。

高度な設定モード#

すべての設定を直接構成します。

フォームは以下のセクションで構成されています。

• モデルとランタイム: モデルフォルダーとランタイムバリアントを選択します。vLLM / SGLang バリアントではランタイムパラメータパネルが、Custom バリアントではモデル定義モードコントロールが表示されます。ランタイム固有のフィールドの詳細については、以下のセクションを参照してください。
• 環境: コンテナイメージ（実行環境 / バージョン）を選択し、環境変数を追加します。
• クラスターとリソース: CPU、メモリ、アクセラレータのリソースを割り当てます。
• 詳細設定 （折りたたみ可能）: モデルフォルダーに加えて、追加でマウントするストレージフォルダーを設定します。

モーダル下部の 追加後に自動的にアクティブにする チェックボックスをオンにすると、Revision の作成直後に有効化されます。オフの場合は非アクティブ状態で保存され、後から Revisions タブで適用できます。

Revision 構成: フィールドリファレンス#

以下のサブセクションでは、Revision レベルのフィールドについて詳しく説明します。これらは 高度な設定モード で手動で Revision を追加する場合と、各フィールドの動作を理解したい場合の両方に適用されます。

モデル定義モード（Custom ランタイムのみ）#

Custom ランタイムバリアントを選択すると、フォームの上部に モデル定義モード セグメントコントロールが表示されます。推論サーバの起動方法を次の 2 つの中から選択できます。

コマンド入力モード#

コマンドを入力 を選択すると、CLI コマンドとして推論サーバの起動を直接定義できます。使用できるフィールドは次のとおりです。

• 起動コマンド: 推論サーバを起動するコマンドです（例: python -m http.server 8000）。

chmod +x /setup.sh; vllm serve /models

/bin/bash -c "chmod +x /setup.sh; vllm serve /models"

• モデルマウント先: コンテナ内でモデルストレージフォルダーがマウントされるパスです（デフォルト: /models）。
• ポート (Port): 推論サーバがリッスンするコンテナポートです（デフォルト: 8000）。
• ヘルスチェックを有効にする: 有効にすると、システムは推論サーバへ定期的に HTTP リクエストを送信し、正しく応答しているか確認します。無効（新規 Revision のデフォルト）の場合、ヘルスチェックは設定されず、異常なレプリカは自動的に検出されません。本番デプロイでは有効にすることを推奨します。ヘルスチェックを有効にする をオンにすると、以下のフィールドが追加で表示されます。
  • パス: HTTP エンドポイントパス
  • 間隔: ヘルスチェック間隔（秒）
  • 最大リトライ数: 最大連続失敗回数
  • 最大待機時間: タイムアウト（秒）
  • 予想ステータスコード: 正常を示すHTTPステータスコード
  • 初期ヘルスチェック猶予時間: コンテナ起動後の猶予時間（秒）

設定ファイル使用モード#

設定ファイルを使用 を選択すると、モデルストレージフォルダーに保存された model-definition.yaml ファイルから推論サーバの設定を読み込みます。使用できるフィールドは次のとおりです。

• マウント先: コンテナ内でモデルストレージフォルダーがマウントされるパスです（デフォルト: /models）。
• モデル定義ファイルパス: モデルストレージフォルダー内のモデル定義ファイルへのパスです（デフォルト: model-definition.yaml）。

モデル定義ファイルの作成手順については、モデル定義ファイルの作成 セクションを参照してください。

ランタイムパラメータ（vLLM / SGLang）#

vLLM または SGLang ランタイムバリアントを選択すると、モデル定義モードセレクタの代わりに ランタイムパラメータ セクションが表示されます。このセクションでは、設定ファイルを手動で編集することなくサービングフレームワークを構成できます。

パラメータはタブで区切られたカテゴリ別に構成されています。使用可能なタブの一覧はランタイムバリアントによって異なります。

ヘルスチェックを有効にする

高度な設定モードでは、vLLM や SGLang を含むすべてのランタイムバリアントのランタイムパラメータエリア下部に ヘルスチェックを有効にする セクションがあります。新規 Revision ではデフォルトで無効です。ヘルスチェックを有効にする をオンにすると、以下のフィールドが表示され、すべて必須となります。

• パス: HTTP エンドポイントパス
• 間隔: ヘルスチェック間隔（秒）
• 最大リトライ数: 最大連続失敗回数
• 最大待機時間: タイムアウト（秒）
• 予想ステータスコード: 正常を示すHTTPステータスコード
• 初期ヘルスチェック猶予時間: コンテナ起動後の猶予時間（秒）

vLLM ランタイムパラメータ

vLLM は次のパラメータタブを提供します: Model Loading、Resource Memory、Serving Performance、Multimodal、Tool Reasoning など。

Model Loading タブの主要フィールド:

• Model: 使用するモデルの名前またはパスです。
• DType: モデルの重みと計算のデータ型です（例: Auto、float16、bfloat16）。
• Quantization: モデルの量子化方式です（例: awq、gptq、fp8）。
• Max Model Length: モデルが処理できる最大コンテキスト長（トークン数）です。
• Served Model Name: API エンドポイントで公開するモデル名です。
• Trust Remote Code: モデルリポジトリのカスタムモデルコードの実行を許可します。

SGLang ランタイムパラメータ

SGLang は次のパラメータタブを提供します: Model Loading、Resource Memory、Serving Performance、Tool Reasoning など。

Model Loading タブの主要フィールド:

• Model: 使用するモデルの名前またはパスです。
• DType: モデルの重みと計算のデータ型です（例: Auto、float16、bfloat16）。
• Quantization: モデルの量子化方式です（例: awq、gptq、fp8）。
• Context Length: モデルが処理できる最大コンテキスト長です。
• Served Model Name: API エンドポイントで公開するモデル名です。
• Trust Remote Code: モデルリポジトリのカスタムモデルコードの実行を許可します。

vLLM および SGLang ランタイムバリアントは、環境 セクションに次の環境変数を事前入力します。

• vLLM: BACKEND_MODEL_NAME、VLLM_QUANTIZATION、VLLM_TP_SIZE（テンソル並列化）、VLLM_PP_SIZE（パイプライン並列化）、VLLM_EXTRA_ARGS（追加 CLI 引数）
• SGLang: BACKEND_MODEL_NAME、SGLANG_QUANTIZATION、SGLANG_TP_SIZE（テンソル並列化）、SGLANG_PP_SIZE（パイプライン並列化）、SGLANG_EXTRA_ARGS（追加 CLI 引数）

環境#

環境 セクションはすべてのランタイムバリアントで利用できます。

• 実行環境 / バージョン: 推論サーバに使用するコンテナイメージです。ランタイムバリアントを選択すると、そのランタイムと互換性のあるイメージにリストが絞り込まれます。
• 環境変数: 推論サーバコンテナに渡されるキー/値のペアです。vLLM および SGLang の場合は、上記に示したランタイム専用の変数が事前入力されています。エントリは自由に追加、編集、削除できます。

クラスターとリソース#

クラスターとリソース セクションでは、各レプリカに割り当てるコンピュートリソースを指定します。

• リソースプリセット: CPU、メモリ、アクセラレータの割り当てがあらかじめ設定されたバンドルです。利用可能なプリセットはデプロイメントのリソースグループに応じてフィルタリングされます。プリセットを選択せずに手動でリソース（CPU、メモリ、GPU）を設定することもできます。

詳細設定#

詳細設定 折りたたみパネルを展開すると、モデルストレージフォルダーに加えて追加のストレージフォルダーをマウントできます。

• 追加マウント: 推論サーバコンテナにマウントするストレージフォルダーの一覧です。準備完了（ready）状態の汎用（非モデル）フォルダーのみ選択できます。名前が . で始まる隠しフォルダーおよびモデルストレージフォルダー自体は除外されます。

Custom ランタイム構成ファイル#

モデル定義ファイルの作成#

モデル定義ファイルには、推論セッションを自動的に開始、初期化、およびスケーリングするためにBackend.AIシステムで必要な構成情報が含まれています。これは推論サービスエンジンを含むコンテナイメージとは独立して、モデルタイプフォルダーに保存されます。これにより、特定の要件に基づいて異なるモデルをエンジンが提供できるようになり、モデルが変更されるたびに新しいコンテナイメージを構築してデプロイする必要がなくなります。ネットワークストレージからモデル定義とモデルデータをロードすることで、自動スケーリング中にデプロイメントプロセスを簡素化し、最適化できます。

モデル定義ファイルは次の形式に従います：

models:
  - name: "simple-http-server"
    model_path: "/models"
    service:
      start_command:
        - python
        - -m
        - http.server
        - --directory
        - /home/work
        - "8000"
      port: 8000
      health_check:
        path: /
        interval: 10.0
        max_retries: 10
        max_wait_time: 15.0
        expected_status_code: 200
        initial_delay: 60.0

モデル定義ファイルのキーと値の説明

• name (必須): モデルの名前を定義します。

• model_path (必須): モデルが定義されているパスを指定します。

• service: サービスされるファイルに関する情報を整理する項目です （コマンドスクリプトおよびコードを含む）。

  • pre_start_actions: start_commandの前に実行されるアクションです。これらのアクションは、 設定ファイルの作成、ディレクトリのセットアップ、初期化スクリプトの実行などによって環境を準備します。 アクションは定義された順序で順次実行されます。

    • action: 実行するアクションのタイプ。利用可能なアクションタイプとそのパラメータについては 事前開始アクションを参照してください。
    • args: アクション固有のパラメータ。各アクションタイプには異なる必須引数があります。

  • start_command (必須): モデルサービングで実行されるコマンドを指定します。 文字列または文字列のリストで指定できます。

  • port (必須): モデルサービス用のコンテナポートです（例：8000、8080）。

  • health_check: モデルサービスの定期的なヘルスモニタリングの設定です。 設定すると、システムはサービスが正しく応答しているか自動的に確認し、 異常なインスタンスをトラフィックルーティングから除外します。

    • path (必須): ヘルスチェックリクエスト用のHTTPエンドポイントパスです（例：/health、/v1/health）。
    • interval (デフォルト: 10.0): 連続するヘルスチェック間の秒数です。
    • max_retries (デフォルト: 10): サービスをUNHEALTHYとしてマークする前に 許容される連続失敗回数です。このしきい値を超えるまでサービスはトラフィックを受け続けます。
    • max_wait_time (デフォルト: 15.0): 各ヘルスチェックHTTPリクエストのタイムアウト秒数です。 この時間内に応答がない場合、チェックは失敗とみなされます。
    • expected_status_code (デフォルト: 200): 正常な応答を示すHTTPステータスコードです。 一般的な値：200（OK）、204（No Content）。
    • initial_delay (デフォルト: 60.0): コンテナ作成後にヘルスチェックを開始するまでの 待機時間（秒）です。モデルのロード、GPUの初期化、サービスのウォームアップに時間を確保します。 大規模モデルの場合はより高い値を設定してください（例：70B+のLLMの場合300.0）。

ヘルスチェック動作の理解

ヘルスチェックシステムは、個々のモデルサービスコンテナを監視し、ヘルスステータスに基づいてトラフィックルーティングを自動的に管理します。

① AppProxy: トラフィックルーティング制御

② Manager: ヘルス状態管理と eviction

UNHEALTHYまでの時間:

• 初期起動時: initial_delay + interval × (max_retries + 1)

  デフォルト値の例: 60 + 10 × 11 = 170秒（約3分）

• 運用中（正常状態後）: interval × (max_retries + 1)

  デフォルト値の例: 10 × 11 = 110秒（約2分）

Backend.AIモデルサービングでサポートされているサービスアクションの説明

• write_file: 指定されたファイル名でファイルを作成し、内容を追加するアクションです。 デフォルトのアクセス権限は 644 です。

  • arg/filename: ファイル名を指定
  • body: ファイルに追加する内容を指定
  • mode: ファイルのアクセス権限を指定
  • append: ファイルへの内容の上書きまたは追加を True または False で設定

• write_tempfile: 一時ファイル名（.py）でファイルを作成し、内容を追加するアクションです。 モードの値が指定されていない場合、デフォルトのアクセス権限は 644 です。

  • body: ファイルに追加する内容を指定
  • mode: ファイルのアクセス権限を指定

• run_command: コマンドを実行した結果が、エラーも含めて以下の形式で返されます （out: コマンド実行の出力、err: コマンド実行中にエラーが発生した場合のエラーメッセージ）

  • args/command: 実行するコマンドを配列として指定（例：python3 -m http.server 8080 コマンドは ["python3", "-m", "http.server", "8080"] になります）

• mkdir: 入力パスによってディレクトリを作成するアクションです

  • args/path: ディレクトリを作成するパスを指定

• log: 入力メッセージによってログを出力するアクションです

  • args/message: ログに表示するメッセージを指定
  • debug: デバッグモードの場合は True、それ以外は False に設定

モデル定義ファイルをモデルタイプフォルダーにアップロード#

モデル定義ファイル（model-definition.yml）をモデルタイプフォルダーにアップロードするには、 バーチャルフォルダーを作成する必要があります。バーチャルフォルダーを作成する際は、 デフォルトの general タイプではなく model タイプを選択してください。 フォルダーの作成方法については、データページのストレージフォルダーの作成セクションを参照してください。

フォルダーを作成した後、データページの「MODELS」タブを選択し、 最近作成したモデルタイプフォルダーアイコンをクリックしてフォルダーエクスプローラーを開き、 モデル定義ファイルをアップロードします。 フォルダーエクスプローラーの使用方法については、フォルダーの探索セクションを参照してください。

デプロイメントの事前設定 (deployment-config.yaml)#

モデルフォルダーに deployment-config.yaml ファイルを配置することで、そのモデルからデプロイメントを作成する際に使用されるリソース、環境、およびランタイム設定を事前に設定できます。ファイルが存在する場合、その値は デフォルト として使用されます。デプロイメント時に設定したもの（リビジョン追加フォームまたは API リクエスト）は、これらの値をオーバーライドします。

deployment-config.yaml は オプション であり、デプロイメントに必須ではありません。ファイルの有無にかかわらず、モデルをデプロイできます。不足しているまたは不正な形式のファイルは単にスキップされます。オプションの model-definition.yaml（モデルと推論サーバーを説明）と共に、管理者がモデルと共に適切なデフォルト値を配布できます。

値は 3 段階のオーバーライド階層 を通じて解決され、最も低い優先度から最も高い優先度の順です。

1. ルートレベルのデフォルト — すべてのランタイムバリアントに適用されます。
2. ランタイムバリアントセクション（例: vllm、sglang、tgi）— そのバリアントのみの個別フィールドをオーバーライドします。
3. デプロイメント時の入力（リビジョン追加フォーム / API リクエスト）— すべてをオーバーライドします。

environment:
  image: "example.com/model-server:latest"
  architecture: "x86_64"

resource_slots:
  cpu: 4
  mem: "16gb"
  "cuda.shares": "0.5"

environ:
  MODEL_NAME: "example-model-name"

resource_opts:
  shmem: "8g"

vllm:
  environment:
    image: "vllm-optimized:0.4.0"
  resource_slots:
    cpu: 8
    "cuda.device": 2

フィールドリファレンス

• environment: 推論サービス用のコンテナーイメージとアーキテクチャーです。
  • image: コンテナーイメージの完全なパスです（例: example.com/model-server:latest）。
  • architecture: イメージの CPU アーキテクチャーです（例: x86_64、aarch64）。
• resource_slots: 各レプリカに割り当てられるコンピュートリソースです。
  • cpu: CPU コア数です（例: 4、8）。
  • mem: 単位サフィックス付きのメモリー量です（例: "16gb"）。
  • "cuda.shares" / "cuda.device": 分数または整数の GPU 割り当てです。ドットを含むキーはクォートしてください。
• environ: 推論サービスコンテナーに渡される環境変数です。ルート値とバリアント値はマージされます。
• resource_opts: shmem（共有メモリーサイズ）などの追加リソースオプションです。

クイックデプロイ#

プリセットベースのクイックデプロイを使用すると、別途の設定ファイルなしでデプロイを作成できます。次の 2 つの入口からクイックデプロイを開始できます。

• モデルストアで事前構成されたモデルカードを閲覧し、デプロイ ボタンをクリックすると、プリセットベースですぐにデプロイできます。
• データページの モデル タブでモデルフォルダーの サービスとしてデプロイ ボタンをクリックすると、プリセットで新規デプロイメント作成 モーダルが開きます。プリセットとリソースグループを選択すると、別途の設定なしですぐにデプロイされます。

モデルデプロイの全体的な流れについては、モデルストア セクションを参照してください。

デプロイ詳細ページ#

デプロイ一覧でデプロイ名をクリックすると、デプロイメントの詳細情報を表示できます。

デプロイメントアラート#

デプロイ詳細ページでは、デプロイメントの現在の状態に応じて、ページ上部にコンテキスト対応のアラートバナーが表示されます。

• デプロイの準備が完了しました: デプロイメントのステータスが HEALTHY の場合に表示されます。ページを離れずにモデルをテストできるよう、LLM チャットテストインターフェースへのショートカットとして チャットでテスト ボタンが含まれます。

• 非公開デプロイメントです。エンドポイントの使用にはアクセストークンが必要です。: アプリを外部公開 が無効な場合に表示されます。トークンの発行やコピーができるよう、アクセストークンを管理 へのショートカットが含まれます。詳細は トークンの生成 を参照してください。

• デプロイされたリビジョンがありません。リビジョンを追加してこのサービスを有効化してください。: デプロイメントに現在の Revision が存在しない場合に表示されます。Revision を追加 をクリックして最初の Revision を作成し、サービスを有効化します。

• サービスを準備しています: デプロイメントが作成中、またはステータスが遷移中の場合に表示されます。サービスがまだリクエストを処理する準備ができていないことを示します。

• このモデルサービスは別のプロジェクトに属しています: デプロイが現在選択されているプロジェクトとは異なるプロジェクトに属している場合に表示されます。このアラートが表示されている間は Edit ボタンが無効になります。アラート内の プロジェクトを切り替える ボタンをクリックして正しいプロジェクトに切り替えてください。

基本情報#

基本情報 カードにはデプロイメントのメタデータが表示されます。

• ライフサイクル: デプロイメントのステータスタグです。ステータスタグの横に スケジュール履歴 リンクボタンが表示され、クリックするとこのデプロイメントのスケジューリングイベント履歴をモーダルで確認できます。
• デプロイ名とステータス
• デプロイIDとセッションオーナー
• 公開範囲: 公開 / 非公開 タグとして表示されます。公開 はアクセストークンなしでエンドポイントにアクセスできることを意味し、非公開 は呼び出し元が有効なアクセストークンを送信する必要があることを意味します。
• レプリカ数
• サービスエンドポイント: デプロイメントにアクセスするための URL です。LLM デプロイメントの場合、チャットでテスト ボタンが利用可能です。
• リソースグループ: デプロイメントが実行されるリソースグループです。リソースグループは Revision 単位ではなく、デプロイメントのメタデータの一部として（デプロイメント作成時に一度だけ設定）管理されます。
• リソース: 割り当てられた CPU、メモリ、アクセラレータ、および 共有メモリ (SHM) です。共有メモリの値は現在の Revision を基準に表示され、推論サーバが利用できる /dev/shm のサイズを表します。マルチ GPU やマルチプロセス推論のワークロードで重要です。
• モデルストレージ: マウントされたモデルストレージフォルダーとマウント先です。
• 追加マウント: マウントされた追加のストレージフォルダーです。
• 環境変数: コードブロックとして表示されます。
• イメージ: サービスに使用されるコンテナイメージです。

その他メニュー（編集と削除）#

サービス情報カードのヘッダーには、編集 ボタンに加えて その他 メニューが表示されます。その他メニューには現在 デプロイを削除 アクションが含まれます。

Revisions タブ#

デプロイ詳細ページの Revisions カードには、現在の Revision、Revision 履歴、監査ログ の 3 つのタブがあります。カード上部の Revision を追加 ボタンはすべてのタブから使用でき、Revision 追加モーダルを開きます（Revision の追加 を参照）。

現在の Revision タブ#

現在の Revision タブは、現在アクティブでトラフィックを処理している Revision の完全な設定を表示します。

次のフィールドが表示されます。

• Revision 番号: 自動割り当てされた連番です（例: #3）。
• Revision ID: この Revision の UUID です。
• 作成日時
• リソース割り当て: 各レプリカのリソース割り当て（CPU、メモリ、アクセラレータ）です。
• モデルフォルダー: 各レプリカにマウントされたモデルフォルダーで、リンクと モデルフォルダーのマウント先 とともに表示されます。
• モデル定義ファイルパス: モデルフォルダー内のモデル定義ファイルのパスです。
• 追加マウント: 各レプリカにマウントされた追加のストレージフォルダーです。
• ランタイム: サービングランタイムです（例: vLLM、SGLang、Custom）。
• ランタイムパラメータ: この Revision に設定されたランタイムバリアントのプリセットパラメータ値です（例: DType: float32、Quantization: awq）。プリセットパラメータ値が設定されている vLLM または SGLang の Revision にのみ表示されます。Custom ランタイムまたはプリセット値のない Revision の場合はダッシュが表示されます。
• ランタイム設定: vLLM または SGLang ランタイムで追加設定が存在する場合に JSON 形式で表示されます。
• イメージ: レプリカの実行に使用されるコンテナイメージです。
• クラスターモード: 各レプリカのコンピューティングセッションのクラスタリングレイアウト（モード / サイズ）です。
• 環境変数: コンテナに注入されるキーと値のペアで、シェルスクリプトブロックとして表示されます。

モデル定義ファイルにモデルが定義されている場合、以下のフィールドも表示されます。

• モデル名、モデルパス、開始コマンド、ポート、シェル、事前起動アクション、ヘルスチェック URL、起動猶予期間、最大再試行回数、インターバル (s)、最大待機時間 (s)、想定ステータスコード

デプロイ進行中の状態

別の Revision がデプロイ中の間、現在の Revision タブには "Revision N をデプロイしています。" というアラートが表示されます。アラートの Revision を表示 ボタンをクリックすると、デプロイ中の Revision の詳細ドロワーが開きます。タブはデプロイが完了するまで5秒ごとに自動更新されます。

空の状態

まだ Revision がデプロイされていない場合、タブには "デプロイされたリビジョンがありません。リビジョンを追加してこのサービスを有効化してください。" と表示されます。

Revision 履歴タブ#

Revision 履歴 タブは、デプロイメントに追加されたすべての Revision を新しい順に表示します。

テーブルには次のカラムが含まれます。

• Revision (ID): Revision 番号とその UUID です。Revision 番号は増加する整数で、数値が小さいほど古い Revision です。Revision 番号をクリックすると Revision 詳細ドロワーが開きます。
• 作成日時
• ランタイム: この Revision で使用されるサービングランタイムです（例: vLLM、SGLang、Custom）。
• クラスターモード: 「モード / サイズ」形式のクラスタリングレイアウトです。カラムヘッダーをホバーすると説明が表示されます。

デフォルトでは非表示ですが、カラム設定から有効にできるカラム：

• モデルバージョン、イメージ、モデルフォルダー

Revision のデプロイとその他の操作

各行には デプロイ ボタンとその他メニューがあります。

• デプロイ: クリックすると確認ダイアログが開きます。確認後、選択した Revision が現在の Revision となり、デプロイメントは新しい設定でトラフィックの処理を開始します。以前の Revision は履歴に保持されます。

• この Revision を基に Revision を作成: その他メニューから選択できます。該当する Revision の設定が事前入力された状態で Revision 追加モーダルが開き、すばやく修正・再デプロイできます。

• 緑色の 現在 タグは、現在アクティブな Revision を示します。

• 黄色の デプロイ中 タグ（ローディングスピナー付き）は、デプロイ中の Revision を示します。

• デプロイ ボタンは、現在アクティブな Revision およびデプロイ中の Revision に対して無効化されます。

行の Revision 番号をクリックすると、その Revision の完全な設定を示す詳細ドロワーが開きます。ドロワーにも デプロイ ボタンと この Revision を基に Revision を作成 ボタンがあり、現在アクティブな Revision およびデプロイ中の Revision では デプロイ ボタンが無効化されます。

監査ログタブ#

監査ログ タブは、このデプロイメントに対して行われたすべての操作の時系列記録を表示します。誰がいつデプロイメントを変更したかを追跡するために使用します。

レプリカ#

レプリカタブには、デプロイメントを構成するルーティングノードが表示されます。タブ上部の 実行中 / 終了 ラジオコントロールで項目をフィルタリングします。これは以前の列挙型ステータスフィルタを置き換えるものです。

• 実行中: 現在プロビジョニング中、実行中、またはアクティブなレプリカを表示します。
• 終了: ライフサイクルが終了したレプリカを表示します。

各レプリカ行には、互いに独立した 3 つのステータスフィールドが表示されます。これらは異なる軸を表すため、組み合わせて読む必要があります。たとえば、レプリカのライフサイクルが実行中でも、ヘルスステータスはまだ未確認の場合があります。

• ライフサイクルステータス: レプリカがライフサイクルのどの段階にあるかを示します（例: プロビジョニング中、ウォームアップ中、実行中、終了中、終了）。ウォームアップ中の間、レプリカは起動猶予期間内にあります。つまり起動中で、最初のヘルスチェック成功を待機しています。この期間中はヘルスチェックの失敗が許容され、最初に成功すると実行中に移行し、期間が終わるまで一度も成功しなかった場合は終了します。列見出しにはライフサイクルと表示されます。
• ヘルスステータス: レプリカプロセスの現在の健全性です（正常、異常、低下、未確認）。
  • 未確認は、最初のヘルスチェックがまだ完了していないことを意味します。レプリカは通常、ウォームアップ中の猶予期間内にあります。それ自体はエラーではありません。レプリカの現在の段階はライフサイクルステータスで確認します。
• トラフィックステータス: レプリカが現在リクエストを処理しているかどうかです。レプリカは健全性とは無関係にトラフィックから除外されることがある（例: 手動で無効化した場合）ため、トラフィックはヘルスステータスにまとめずに独立したステータスとして表示されます。

セッション 列のセッション名をクリックするとセッション詳細ドロワーが開き、リビジョン(ID) 列のリビジョン番号をクリックするとリビジョン詳細ドロワーが開きます。

ライフサイクル 列のステータスタグの横には履歴アイコンボタンがあります。クリックすると該当レプリカの レプリカのスケジュール履歴 モーダルが開き、レプリカのスケジューリングイベント履歴を日付範囲やステータスなどで絞り込んで確認できます。

レプリカでエラーが発生した場合、行のエラーインジケータをクリックすると JSON ビューアーモーダルが開き、生のエラーデータが表示されます。個別のレプリカの問題を診断する際に役立ちます。

自動スケーリングルール#

自動スケーリングルール（Auto Scaling Rules）は、ライブメトリックに基づいてモデルサービスのレプリカ数を自動的に増減します。これにより、使用率が低いときはリソースを節約し、使用率が高いときはリクエストの遅延や失敗を防ぎます。

ルール一覧には以下が含まれます：

• 作成された時間（Created At）および最後にトリガーされました（Last Triggered）の日時範囲でルールをフィルタリングできるプロパティフィルターバー。
• サーバーサイドのページネーション。
• メトリックソース（Metric Source）、コンディション（Condition）、クールダウン秒（Cooldown Sec.）、ステップサイズ（Step Size）、min / max レプリカ（Min / Max Replicas）、作成された時間（Created At）、最後にトリガーされました（Last Triggered）の列。ステップサイズ列は、設定されたしきい値から導出される方向に基づいて +、−、± を自動的に表示するため、Scale Out または Scale In を明示的に選択する必要はなくなりました。
• 各行のコンディションサマリーの横に表示される行ごとの編集および削除アイコン。

ルールを追加します ボタンをクリックすると、自動スケーリングルールを追加します エディターが開きます。既存のルールを変更するには、その行の編集アイコンをクリックします。ルールの値が事前に入力された状態で 自動スケーリングルールを編集します エディターが開きます。エディターには次のフィールドが順番に含まれます：

• メトリックソース（Metric Source）: Kernel または Prometheus を選択します。

• メトリック名（Metric Name）: Kernel の場合、メトリック名を入力します。cpu_util、mem、net_rx、net_tx などの一般的なメトリックがオートコンプリートの候補として提案され、カスタム名を自由に入力することもできます。

• メトリック名プリセット（Metric Name (Prometheus Preset)）: メトリックソースが Prometheus の場合のみ表示されます。ドロップダウンからプリセットを選択すると、プリセットのメトリック名、クエリテンプレート、および（定義されている場合）クールダウン秒（Cooldown Sec.）が自動的に入力されます。

• コンディション（Condition）: スケーリング方向を選択するセグメントコントロールです。3 つのオプションがあります。

  • スケールイン: メトリックがしきい値を下回るとレプリカを減らします。Metric < [しきい値] の条件を設定します。
  • スケールアウト: メトリックがしきい値を上回るとレプリカを増やします。Metric > [しきい値] の条件を設定します。
  • スケールイン＆アウト: メトリックが設定した範囲のどちら側を超えたかに応じて、自動的に縮小または拡張します。Metric < Min Threshold または Metric > Max Threshold の条件を設定します。

• ステップサイズ（Step Size）: スケーリングイベントごとに追加または削除するレプリカ数を指定する正の整数です。選択したコンディション（スケールイン / スケールアウト / スケールイン＆アウト）に応じて -、+、± の符号が自動的に表示されます。

  • 最小しきい値のみ設定: [metric] < [minThreshold] 条件になるとスケールイン（Scale In）されます（メトリックがしきい値を下回るとレプリカが減少します）。
  • 最大しきい値のみ設定: [metric] > [maxThreshold] 条件になるとスケールアウト（Scale Out）されます（メトリックがしきい値を上回るとレプリカが増加します）。
  • 両方設定: [metric] < [minThreshold] の場合はスケール イン、[metric] > [maxThreshold] の場合はスケール アウト されます。

• クールダウン秒（Cooldown Sec.）: スケーリングイベント後、次の評価まで待機する時間（秒単位）です。

• 最小レプリカ（Min Replicas）および最大レプリカ（Max Replicas）: 自動スケーリングがレプリカ数に対して強制する下限と上限です。自動スケーリングは、レプリカ数を最小レプリカより下げたり、最大レプリカより上げたりすることはありません。

トークンの生成#

デプロイのステータスが HEALTHY になったら、デプロイ一覧で対応するデプロイ名をクリックしてデプロイ詳細ページを開きます。サービス情報カードで サービスエンドポイント URL を確認できます。Open To Public が有効の場合、エンドユーザーはトークンなしでデプロイにアクセスできます。無効の場合は、以下の説明に従ってトークンを発行してください。

生成されたトークン一覧の右側にあるトークン生成ボタンを クリックします。表示されるモーダルで有効期限を入力します。

発行されたトークンは生成されたトークン一覧に追加されます。各トークンにはステータス（有効または期限切れ）、有効期限、作成日が表示されます。トークン 項目のcopyボタンをクリックしてトークンをコピーし、以下のキーの値として追加します。

デプロイの終了#

デプロイが不要になった場合は、終了することを推奨します。デプロイを終了するには、サービス情報カードの その他 メニューを開き、デプロイを削除 を選択します。入力確認モーダルが表示されるため、デプロイ名を入力すると 完全に削除 ボタンが有効になります。終了したデプロイは 破壊された フィルタービューに表示されます。

デプロイへのアクセス#

デプロイへのアクセスを可能にするため、デプロイ URL をエンドユーザーと共有します。Open To Public が有効の場合、デプロイ詳細ページの サービスエンドポイント URL をそのまま共有できます。非公開デプロイの場合は、URL とアクセストークンを併せて共有します。

APIリクエストの送信#

以下は、デプロイへのリクエスト送信が正しく機能しているかどうかを確認する curl コマンドの簡単な例です：

export API_TOKEN="<token>"
export MODEL_SERVICE_ENDPOINT="<model-service-endpoint>"
curl -H "Content-Type: application/json" -X GET    -H "Authorization: BackendAI $API_TOKEN"    "$MODEL_SERVICE_ENDPOINT"

LLMチャットテスト#

大規模言語モデル（LLM）サービスを作成した場合、リアルタイムでLLMをテストできます。 デプロイの準備が完了すると、デプロイ詳細ページ上部の デプロイの準備が完了しました バナーに チャットでテスト ボタンが表示されます。このボタンをクリックしてテストを開始します。

作成したモデルが自動的に選択されたChatページにリダイレクトされます。 Chatページで提供されるチャットインターフェースを使用して、LLMモデルをテストできます。 チャット機能の詳細については、Chatページを参照してください。

API接続に問題が発生した場合、Chatページにモデル設定を手動で構成できるオプションが表示されます。 モデルを使用するには、以下の情報が必要です：

• ベースパス（オプション）: モデルが配置されているサーバーのベースURLです。 バージョン情報を含めてください。 例えば、OpenAI APIを使用する場合は、https://api.openai.com/v1 を入力してください。
• トークン（オプション）: モデルサービスにアクセスするための認証キーです。トークンは Backend.AIだけでなく、さまざまなサービスから生成できます。形式と生成プロセスは サービスによって異なる場合があります。詳細については、常に特定のサービスのガイドを参照してください。 例えば、Backend.AIで生成されたサービスを使用する場合は、 トークンの生成方法についてはトークンの生成セクションを参照してください。

モデルストア#

モデルストア（Model Store）は、事前構成されたモデルを閲覧、検索、デプロイできるカードベースのギャラリーを提供します。サイドバーメニューからモデルストアにアクセスできます。

モデルの閲覧と検索#

ページ上部には検索と並べ替えのレイアウトが使用されています：

• モデルの検索（Search Models）: 名前でフィルタリング（Filter By Name）プロパティフィルターを使用して、モデルカードを名前で検索します。
• 並べ替え（Sort）: 結果の並び順を選択します。使用可能なオプションは、名前 (A→Z)、名前 (Z→A)、古い順、新しい順 です。
• 更新（Refresh）: 更新ボタンをクリックしてカード一覧を再読み込みします。

各カードには、モデルブランドのアイコン、タイトル（タイトルが設定されていない場合は名前）、タスクタグ、相対作成時刻、およびアイコン付きの著者（Author）が表示されます。現在のプロジェクトに互換性のあるプリセットがないカードは不透明度 50 % で表示されます。そのようなカードを開いて詳細を表示することは可能ですが、デプロイ（Deploy） ボタンは無効化され、ドロワーに 互換性のあるプリセットがありません。このモデルはデプロイできません。 というエラーアラートが表示されます。

サーバーで MODEL_STORE プロジェクトが設定されていない場合、ページには管理者に問い合わせるようにとの案内とともに モデルストアプロジェクトが見つかりません というメッセージが表示されます。フィルターに一致するモデルカードがない場合は モデルが見つかりません と表示されます。

一覧はページ下部でページネーションされます。ページサイズは 10、20、50 件の中から変更できます。

モデルカードの詳細#

カードをクリックすると、ページの右側にモデルカードのドロワーが開きます。ドロワーの上部にはモデルのタイトルと説明が表示され、次にタスク、カテゴリ、ラベル、ライセンスのタグが続き、その後に次の項目を含む詳細一覧が表示されます：

• 著者（Author）
• アーキテクチャ（Architecture）
• フレームワーク（Framework）（各フレームワークはアイコン付きで表示）
• バージョン（Version）
• 作成日時（Created） および 最終更新日時（Last Modified） のタイムスタンプ
• モデルフォルダ（Model Folder）: モデルストレージフォルダのフォルダエクスプローラを開くクリック可能なリンク
• 最小リソース（Min Resource）: 最小リソース要件（CPU、メモリ、GPU）

モデルカードに README が含まれている場合は、ドロワーの下部に README.md カードとしてレンダリングされます。

モデルのデプロイ#

ドロワーヘッダーの デプロイ（Deploy） ボタンをクリックすると、モデルがサービスとしてデプロイされます。デプロイフローは次の 2 通りのいずれかで動作します：

• 自動デプロイ: モデルに使用可能なプリセットがちょうど 1 つあり、現在のプロジェクトにアクセス可能なリソースグループがちょうど 1 つある場合、モーダルを表示せずにデプロイが静かに作成されます。エンドポイントがクエリ可能になった後、そのデプロイ詳細ページに遷移します。

• モデルのデプロイモーダル（Deploy Model）: それ以外の場合、モデルのデプロイモーダルが次の必須フィールドとともに開きます。

  • プリセット（Preset）: 使用可能なリソースプリセットのグループ化されたドロップダウンです。プリセットが複数のランタイムバリアントにまたがる場合、オプションはランタイムバリアント名ごとにグループ化されます。それ以外の場合は、フラットなリストとして表示されます。
  • リソースグループ（Resource Group）: サービスが実行されるリソースグループです。

  モーダルの デプロイ（Deploy） ボタンをクリックしてデプロイを開始します。モデルがデプロイされたことを確認する成功トーストが表示され、デプロイ詳細ページに遷移します。