リソースグループ

リソースグループは同じワークスペース内のサブスクリプションアカウントと API チャネルを選択します。メンバーごとに必要なリソースやモデルが異なる場合はグループを分けます。別のワークスペースのリソースは関連付けられません。

リソースの種類とルーティング

リソース グループは、個人ゲートウェイ キー、メンバー許可、およびモデル ポリシーをバインドします。編集者はサブスクリプション アカウントと API チャネルを個別に選択します。各リソースの種類には、ワークスペースの分離を維持しながら独自の管理ページがあります。

新しい UI グループは、API フォールバックがオフのサブスクリプションを優先します。混合グループは、フォールバックが明示的に有効であり、利用可能な対象となるサブスクリプションがない場合にのみ、新しいリクエストに API チャネルを使用します。 API のみのグループは、選択したチャネルを直接使用します。管理者は API チャネルを優先することも、クライアント プロトコルの優先順位を保持することもできます。 API コールはアップストリーム残高を消費する可能性があります。 SubLane はそのバランスを問いません。

アップグレードでは、既存のグループのプロトコル設定とキー バインドが保持されます。ルーティングの変更後、既存の会話が別のリソースに移動することはありません。フォールバックを無効にしたり、バインドされたリソースを削除/無効にすると、その ID が変更されるのではなく、既存の会話が失敗する可能性があります。

管理者 API は /api/groups そして互換性のある account_ids ペイロード。新しい UI が送信するのは、 resources (kind: "subscription" または "channel" とリソース id） そして routing (preference, allow_api_fallback）。混合メンバーシップ表現、重複 ID、および間違ったリソースの種類は拒否されます。

管理者のワークフロー

1. 選択したワークスペースで、開きます リソースグループ そして名前付きグループを作成します。サブスクリプション アカウントと API チャネルを個別に選択します。新しいリソースは、グループに選択されるまで割り当てられないままになります。
2. 開ける メンバー 各メンバーに、使用できるグループへのアクセスを許可します。助成金はそのメンバーに直接適用されます。人事チームはありません。新しいメンバーと新しいグループは、自動的には付与されません。
3. メンバーは、アクセスできる有効なグループの個人キーを作成します。各キーはそのワークスペースとグループに永続的にバインドされます。キーを取り消して再作成し、バインドを変更します。

管理対象外のグループは同じアップストリーム アカウントを共有できます 1 つのワークスペース内で。あ 利用枠 排他的なグループが必要です。最初にそのリソースを他のグループから削除してください。グループに割り当てが設定されると、一時停止した場合でも、割り当てが存在する間はそのリソース メンバーシップは固定されたままになります。グループを無効にするか、メンバーの許可を取り消すと、今後のリクエストがブロックされ、WebSocket は既存の会話を別のリソースに移動せずに回転します。

ワークスペースは、最大 32 のグループと、グループあたり 100 のリソースの関連付けをサポートします。グループの名前を変更したり、無効にしたりできます。現在のインターフェイスではグループは削除されません。メンバーのリクエスト制限とリソースの許容量は個別に設定されます。

次のスクリーンショットは、account-pool ラベルが付いている以前のバージョンのものです。現在のリソース グループ エディタには、API チャネルとルーティング設定もリストされます。

リクエストと会話の動作

• キーの作成では、キーの挿入と同じトランザクションで現在のメンバーとグループのアクセスがチェックされます。
• 各リクエストと WebSocket ターンでは、ワークスペースのステータス、メンバーシップ、キーのステータス、グループ アクセス、およびモデル ポリシーが再チェックされます。
• 検出と推論では、バインドされたグループ内の適格なアカウントのみが使用されます。リクエストでは、保存されたカタログがリクエストされたモデルをサポートしている場合にのみアカウントを使用できます。
• 会話のアフィニティは、メンバー、グループ、セッションに限定されます。バインドされたアカウントが使用できなくなったり、グループから脱退したりすると、サイレントにアカウントを切り替えるのではなく、会話は失敗します。
• すでに許可されたリクエストは、許可が変更された後に終了する場合があります。次のリクエストまたはターンでは新しいポリシーが表示されます。

HTTP エンドポイント

管理エンドポイントには、選択したワークスペースの管理者ロールが必要です。ブラウザーのリクエストにはワークスペースの選択が含まれており、突然変異に対する同一生成元の保護が必要です。

ゲートウェイは、ブラウザー選択ヘッダーではなく、認証されたキーからワークスペースを識別します。見る ワークスペース そして API キー.

モデルアクセス

管理者が有効にできるのは、 許可されるモデルを制限する グループエディターで。によって返された ID を使用して、最大 100 個の正確な ID を 1 行に 1 つずつ入力します。 /v1/models。ネイティブ ID により、グループ内のサポートするプロバイダー全体でその正確なモデルが可能になります。既存のプロバイダー限定ルールは、元のプロバイダーのスコープを保持します。 SubLane を更新しても、それらは書き換えられたり拡張されたりしません。従来の修飾ルールは引き続き明示的に送信できます。ワイルドカードはサポートされていないため、モデル バリアントを明示的にリストする必要があります。

グループは、新しく検出されたモデルも含め、デフォルトでは制限されません。エントリを指定せずにホワイトリストを有効にすると、すべてのモデルが拒否されます。 API はオプションで model_policy: {"restricted": true, "models": ["synthetic-model"]} 作成/更新時。省略すると、既存のポリシーが保持されます。アクセスはリセットされません。グループの回答には次のものが含まれます。 restricted_models;詳細な応答には以下も含まれます allowed_models.

モデル検出は、ホワイトリスト外のモデルをフィルターで除外し、ポリシーによって完全に除外されたプロバイダーには接続しません。 Responses、Chat Completions、圧縮、および WebSocket ターンごと (ローカルのプリウォームを含む) は、アカウントの選択またはアップストリームの作業の前に現在のポリシーをチェックします。拒否されたモデルが返される 403 model_not_allowed;メンバー レートや同時実行の許容量を消費せず、アフィニティも作成しません。すでに承認されているリクエストは終了する場合があります。

自動的に検出されたモデル

開ける モデル グループ上で、対象となるアカウントの保存されたモデル カタログの結合を検査します。リストはアカウント メンバーシップに従い、既存の許可リストを適用します。これは、そのポリシーの 2 番目の編集可能なコピーではありません。新しい上流モデルは、制限のないグループにのみ自動的に表示されます。有効になっている空のすべて拒否リストを含む明示的な制限は、同期によって変更されません。

推論では、通常のロード/クールダウン ルールを適用する前に、アカウント固有のカタログ サポートを使用します。異なるサブスクリプション機能を持つアカウントはグループを共有できます。リクエストは、そのモデルを報告したアカウントにのみ適格です。見る モデルカタログ 新鮮さ、失敗、そして会話の親和性のために。