このセクションでは、SambaStack 管理者がユーザー権限の管理、管理者アクセスの設定、サービスティアおよび QoS (Quality of Service: サービス品質) レベルの設定を行う方法を説明します。
管理者は、どのユーザーがどのモデルへアクセスできるか、どの程度利用できるか、またそのリクエストにどの優先度を割り当てるかを制御できます。
管理者の追加
ユーザーに管理者権限を付与するには、SambaStack の設定ファイルにそのユーザーのメールアドレスを追加します。
sambastack.yaml ファイルの db-admin セクションにメールアドレスを追加します。
例:
data:
sambastack.yaml: |
db-admin:
admins:
- abc@example.com
セキュリティを維持するため、認可された管理者のみを追加してください。
-
.yaml ファイルを更新後、以下のコマンドで構成を反映します。
kubectl apply -f sambastack.yaml
管理者アクセスの確認
設定が正しく機能していることを確認するには、まず SambaStack 管理者 UI へのアクセスを確認します。
-
インストーラーログを確認して UI ドメインを特定します。
kubectl -n sambastack-installer logs -l sambanova.ai/app=sambastack-installer -f
-
ブラウザ (Chromeを推奨) で以下にアクセスします。
管理者としてログインすると、Admin ページが表示されます。
サービスティアの構成
サービスティア (service tier; UI 上では「Usage Plan」と表示) は、ユーザーがアクセスできるモデル、使用制限、権限を定義します。
サービスティア構成のサンプル
sambastack.yaml の data セクション内に、適切なインデントでサービスティアを追加します。詳細はこちらの例を参照してください。
data:
sambastack.yaml: |
serviceTiers:
example:
- models:
- Llama-4-Maverick-17B-128E-Instruct
queueDepth: 25
qos: "free"
rates:
- allowedRequests: 100
periodSeconds: 30
kubectl apply -f sambastack.yaml
example というティアは Admin ページ上で Usage Plan として表示され、ユーザーに割り当てることができます。
サービスティアの主要フィールド
以下の表は、サービスティアを定義する際に使用される主要フィールドとその説明・値の例を示しています。
| フィールド | 説明 | 値の例 |
|---|
qos | このティアのリクエストに割り当てられる QoS (サービス品質) レベル。通常はティア名と一致。 | enterprise-group-1, customer-demo |
models | ティア内のユーザーがアクセス可能なモデルのリスト。少なくとも 1 つのティアに含まれていないとモデルにアクセスできません。 | [Llama-3.3-Swallow-70B-Instruct-v0.4] |
queueDepth | ビジー応答を返す前にキューできる最大クエリ数。 | 100 |
rates | ユーザーごとのレート制限（許可リクエスト数と秒単位の期間）を定義。 | { allowedRequests: 10, periodSeconds: 60 } |
inherits | ティアが既存のティア設定を継承し、一部のフィールドを上書き可能。 | inherits: previously defined tier name, overrides: mentions which properties to override |
サービスティアの機能
サービスティアを利用すると、ユーザーアクセス、利用制限、権限を柔軟かつ安全に制御できます。
- アクセス制御: ユーザーやグループごとに利用可能なモデルを指定
- 利用制限: 一定期間内に許可されるリクエスト数やトークン数を制限
サービスティアの仕組み
サービスティアは、アクセス制御と運用制限を定義するモデルグループのリストとして構成されます。
各モデルグループでは、キュー深度やレート制限を指定してリソース利用を制御します。
inherits 属性を使用すると、既存ティアの構成を継承して再利用でき、overrides セクションで特定項目のみを上書きできます。
サービスティアの管理
サービスティアの作成・編集
ベースティアを定義し、継承を用いて派生ティアを作成することで、一貫性と再利用性を確保できます。
例 - ベースティア
serviceTiers:
free:
- models:
- Llama-3.1-Swallow-8B-Instruct-v0.3
- Meta-Llama-3.1-8B-Instruct
queueDepth: 25
qos: "free"
rates:
- allowedRequests: 20
periodSeconds: 60
premium:
inherits: free
overrides:
- models:
- Meta-Llama-3.1-70B-Instruct
batchSize: 2
queueDepth: 50
qos: "premium"
rates:
- allowedRequests: 100
periodSeconds: 60
kubectl apply -f sambastack.yaml
サービスティア設計の推奨事項
安定性・安全性・柔軟性を確保するため、以下のベストプラクティスを推奨します。
-
デフォルトティアを維持する - 初期構成のfreeおよびwebティアは可能な限り変更しないでください。これらはユーザーの基本アクセスを保証します。削除または無効化すると、重要なアクセス経路が遮断される恐れがあります。
-
変更は慎重に行う - デフォルトティアのレート制限やモデルリストを調整する際は、ユーザー要件と整合するよう注意してください。ティアを上書きすると既存構成全体が置き換わります。ティアを
sambastack.yaml から削除すると、SambaNovaの既定値に戻ります。
-
カスタムティア (custom tier) で柔軟性を確保 - free や web などのベースティアを継承してカスタムティアを作成すると、構造を維持しつつ柔軟に調整できます。
-
システム管理ティア (system-managed tier) を理解する - モデルのライフサイクル管理やアクセス制御のため、以下のティアはシステムによって予約されています。
deprecated: 廃止済みモデル用 (HTTP 410)。対象モデルへのリクエストを拒否。maintenance: 一時的に利用不可のモデル用 (HTTP 503)。restricted: アクセス制限付きモデル用 (HTTP 403)。
これらは自動管理されるため、サービスティア設計時に考慮してください。
sambastack.yaml におけるシステム管理 (system-managed) / 必須 (required) / カスタム (custom) ティアの例
text
apiVersion: v1
kind: ConfigMap
metadata:
name: sambastack
labels:
sambastack-installer: "true"
data:
sambastack.yaml: |
version: 0.3.297
serviceTiers:
###################################
# SYSTEM-MANAGED TIERS #
###################################
deprecated:
- models:
- Old-Model-v1
queueDepth: 0
rates:
- allowedRequests: 0
periodSeconds: 3600
restricted:
- models:
- Restricted-Model
queueDepth: 1
rates:
- allowedRequests: 0
periodSeconds: 60
###################################
# REQUIRED TIERS #
###################################
free:
- models:
- Meta-Llama-3.1-8B-Instruct
queueDepth: 100
qos: "free"
rates:
- allowedRequests: 20
periodSeconds: 60
web:
- models:
- Meta-Llama-3.1-8B-Instruct
queueDepth: 100
qos: "web"
rates:
- allowedRequests: 20
periodSeconds: 60
###################################
# CUSTOM TIERS #
###################################
developer:
inherits: free
overrides:
- models:
- Meta-Llama-3.1-8B-Instruct
queueDepth: 100
qos: "developer"
rates:
- allowedRequests: 60
periodSeconds: 60
enterprise:
inherits: developer
overrides:
- models:
- Meta-Llama-3.3-70B-Instruct
queueDepth: 100
qos: "enterprise"
rates:
- allowedRequests: 200
periodSeconds: 60
サービス品質 (QoS)
サービス品質 (quality of service; QoS) は、複数のデプロイ間でリソースを競合する際にリクエスト処理の優先順位を決定する仕組みです。高優先度のトラフィックが優先的に処理されることで、リソース利用を最適化します。
QoS の構成
- QoS レベルはサービスティアの構成内で、それぞれのティアに対して
qos ラベルとして定義します。
- デプロイメントでは、対応する QoS レベルの優先順位を
qosList で指定します。
例: sambastack.yaml におけるQoS構成例の抜粋
serviceTiers:
- name: Standard
qos: "free"
bundleDeploymentSpecs:
- name: <Model Name>
groups:
- name: <Group Name>
minReplicas: <number>
qosList:
- "web"
- "free"
web ティアのリクエストが優先的に処理され、待機中のリクエストがない場合に free ティアが処理されます。
QoSの目的
QoS は高優先度のトラフィックを先に処理することで、公平かつ予測可能なリソース共有を実現します。
- 例:
qosList: ["free", "web"] の場合、free ティアのリクエストが優先的に処理され、空きがあるときのみ web ティアを処理します。
注意事項
- Free ティアはすべての新規ユーザーに自動的に割り当てられるデフォルトティアです。
- デプロイメントは複数の QoS レベルをサポートし、異なるトラフィック種別を同時処理可能です。
QoS とサービスティアの違い
| コンセプト | 制御内容 | 定義される場所 |
|---|
| サービスティア | ユーザーごとのモデル、レート制限、キュー深度、QoS ラベルを定義し、アクセス制御を設定。 | sambastack.yaml の serviceTiers セクション、または Admin UI (Usage Plans) |
| QoS | 各ティアからのトラフィックをデプロイメント側で優先順位に基づきディスパッチ。 | Deployment specifications (bundleDeploymentSpecs 内の qosList) |
- サービスティアは「誰が・何を・どのくらい使えるか」を定義します。
- QoS は「いつ処理されるか」 (優先度) を決定します。
ユーザーリクエスト処理のワークフロー
以下では、ユーザーからのリクエストがどのような手順で処理されるかをステップごとに示します。
また、サービスティアと QoSの優先順位がどのように連携し、システム全体のトラフィックを効率的に管理・ルーティングしているかを説明します。
- ユーザーが自身の認証情報を使用して API リクエストを送信します。
- SambaStack がそのユーザーに割り当てられたサービスティア (Usage Plan) を特定します。
- リクエストが、そのティアで許可されたモデル、バッチサイズ、レート制限、関連するQoS設定に適合しているかを確認します。
- デプロイメントは、
qosList に定義された優先順位に基づいて処理すべきリクエストを選択します。
- リクエストがユーザーのレート制限を超過している場合、HTTP 429 “Too Many Requests” の応答を返して拒否します。
- 指定された優先度の QoS キューが満杯の場合、システムは「ビジー」応答を返します。
- それ以外の場合、リクエストは QoS キューに登録され、順次処理が行われます。
管理者は Admin UI からサービスティアやクォータ (使用枠) を調整できます。
ティア設定、レート制限、QoS設定などの変更はクラスタ全体に適用されます。
これらの変更は、 sambastack.yaml ファイルを編集・デプロイすることで反映され、構成の整合性を保つため、可能な限りバージョン管理下で行うことを推奨します。 