Skip to main content
SambaStack は、一連の Kubernetes カスタムリソースを通じてモデルサービングを管理します。本ページでは、これらのリソースの相互関係、クラスターに既に存在するリソースの確認方法、目的のデプロイに応じてどのワークフローに従えばよいかを解説します。このセクションの各ページでは、それぞれのワークフローを順を追って説明します。個々のリソースのフィールドリファレンスは、カスタムリソース配下の専用ページにあります。 SambaStack のデプロイメントは、1 つのノード上で 1 つ以上のモデルを、バッチサイズやシーケンス長を含む構成と共にサービングします。このアプローチでは、SambaNova の Reconfigurable Dataflow Unit (RDU) を利用して、1 つのデプロイメントで複数のモデルと構成をサポートします。デプロイメント内のすべてのモデルはすでにメモリに常駐しているため、モデル間の切り替えに重みの再ロードは不要であり、単一の静的なモデルをロードするデプロイメントと比較してスループットが向上します。 例えば、1 つのバンドルで Llama-3.3-70B-Instruct と Llama-3.1-8B-Instruct の両方をサービングすることで、両者をほぼ瞬時に切り替えられます。各構成はノード上の容量を消費するため、バンドルごとに含まれる構成のセットは異なります。バッチサイズ 4、シーケンス長 16k の Llama-3.3-70B-Instruct は 1 つの構成に相当します。SambaNova が提供するバンドルについては、対応モデルとバンドル をご覧ください。
SambaStack v2.0.2 では、バンドルのデプロイ方法を管理する新しい Kubernetes カスタムリソース (CR) 群が導入されました。旧バージョンの SambaStack の CR は非推奨となりましたが、2026 年 9 月 30 日までは引き続き機能します。非推奨の CR で構築したモデルバンドルは、新しいリソースモデルへの移行が必要になります。
バンドルは必須ではありません。単一のモデルをサービングする場合は、モデルプロファイルと組み合わせて直接デプロイします。複数のモデルを 1 つの単位としてサービングする場合、投機的デコーディングを設定する場合、または名前付きの構成を検証して共有する場合に、バンドルを作成します。

​
用語

​
リソースアーキテクチャ

このセクションでは、カスタムのデプロイメントを作成する際に使用するリソース構造を説明します。これらのリソースはすべて apiVersion: sambanova.ai/v1alpha1 を使用します。 各ノードには役割を示すタグが付いています。provided とタグ付けされたノードは破線の枠線で示され、SambaStack のインストールと共に提供されるため、名前で参照します。you author とタグ付けされたノードは実線の枠線で示され、ユーザーが作成するリソースです。not a CR とタグ付けされた角丸のノードはカスタムリソースではなく、Model と ModelProfile の 1 つのペアリングを表しており、spec.modelConfigs の 1 エントリに対応します。 各リソースは、次のように責務を分担します。
  1. Pef - コンパイル済み実行ファイルと、そのモデルアーキテクチャ、バッチサイズ、最大シーケンス長を含む、サポート内容を記述するメタデータを登録します。
  2. ModelProfile - モデルアーキテクチャを「どのように」実行できるかを定義します。使用する PEF、サポートする機能、各シーケンス長ティアで利用可能なバッチサイズを含みます。
  3. Model - 各アーキテクチャに対して「どのチェックポイント」が利用可能かを、使用するトークナイザーとあわせて定義します。
  4. ModelBundle - 1 つ以上のモデルとプロファイルのペアを、名前付きの単一のデプロイ可能な単位にまとめます。任意です。
  5. ModelDeployment - バンドル、またはインラインのモデルとプロファイルのペアから、クラスター上に 1 つ以上のレプリカをインスタンス化します。
この分離により、次のことが可能になります。
  • バンドルを作成せずに、モデルをプロファイルと組み合わせて単一モデルをデプロイする
  • ファインチューニングしたモデルのカスタムチェックポイントを含め、同じアーキテクチャを共有するすべてのモデルとチェックポイントで 1 つのプロファイルを再利用する
  • プロファイルには手を加えず、Model リソースを追加するだけでカスタムチェックポイントをサービングする
  • 複数のモデルをまとめてサービングする必要がある場合に、検証済みで共有可能な 1 つの単位にグループ化する
  • プロファイルやデプロイメント構成を変更せずにチェックポイントを更新する
  • 同じ構成を異なるレプリカ数でデプロイする
チェックポイントのパスをバンドルやデプロイメントで宣言することはありません。オペレーターは、参照した Model からパスを解決します。解決には、<model-name>[:<arch>][:<version>] 形式の参照、または modelSettings.checkpointOverrides が使用されます。チェックポイントとプロファイルの互換性は model_arch によって定義されますが、オペレーターはこれを検証しません。参照するプロファイルと互換性のあるアーキテクチャを持つチェックポイントを選択してください。

​
利用可能なモデルとプロファイルの特定

デプロイメントを作成する前に、クラスターで利用可能なモデルとプロファイルを特定し、どの組み合わせが可能かを確認します。
1

利用可能なモデルの一覧表示

モデルを一覧表示し、各モデルの spec.checkpoints 配下のアーキテクチャキーを確認します。
例:
これらのコマンドが一覧表示するのは Kubernetes のリソース名 (metadata.name) であり、推論 API に送信する名前ではありません。リクエストには spec.name のサービング名を使用してください。対応モデルとバンドル をご覧ください。
2

利用可能なプロファイルの一覧表示

プロファイルを一覧表示し、それぞれの model_arch の値を確認します。
出力:
3

プロファイルとモデルのマッチング

プロファイルの内容を表示して、そのアーキテクチャ、機能、バッチングサポートを確認します。
プロファイルの model_arch の値が、モデルの spec.checkpoints 配下のアーキテクチャキーのいずれかと一致する場合、そのプロファイルをモデルと組み合わせて使用できます。オペレーターはこのペアリングを検証しないため、デプロイ前にご自身で確認してください。プロファイルでは、以下を確認します。
  • model_arch - プロファイルが対象とするアーキテクチャ
  • features - プロファイルの PEF がサポートするオプション機能
  • batchingConfigs - 名前付きのバッチング設定。それぞれがシーケンス長ティアをそのバッチサイズにマッピングします
  • pefs - プロファイルが参照する PEF のバージョン
features リストに speculative_decoding を含むプロファイルには、ドラフトモデルが必要です。バンドルの spec.specDecodingPairs を使用してペアリングしてください。

​
ワークフローの選択

単一モデルのデプロイ

バンドルを使わずに、モデルをプロファイルと組み合わせて直接デプロイ

バンドルのデプロイ

SambaNova が提供するバンドル、または自作したバンドルのサービング

カスタムバンドルの作成

複数のモデルとプロファイルを、名前付きの検証済みの 1 つの単位に統合

カスタムチェックポイントのデプロイ

独自のカスタムチェックポイントやファインチューニング済みチェックポイントの変換・アップロード・サービング

高スループット vs. 高インタラクティビティ

2 種類の専用デプロイ構成の使い分け

バンドル設定の移行

非推奨のカスタムリソースで構築したバンドルの移行