Grupos de recursos
Configura grupos de recursos y concede acceso directo a sus miembros.
Un grupo de recursos selecciona cuentas de suscripción y canales API de un mismo espacio de trabajo. Crea grupos separados cuando los miembros necesiten recursos o modelos distintos. Los recursos y grupos no pueden asociarse entre espacios.
Tipos de recursos y enrutamiento
Los grupos de recursos vinculan claves de puerta de enlace personales, subvenciones para miembros y políticas modelo. El editor selecciona cuentas de suscripción y API canales por separado; Cada tipo de recurso tiene su propia página de administración manteniendo el aislamiento del espacio de trabajo.
Los nuevos grupos de UI prefieren suscripciones con API reserva. Un grupo mixto utiliza canales API para nuevas solicitudes solo cuando el respaldo está explícitamente habilitado y no hay ninguna suscripción elegible disponible. Un grupo exclusivo de API usa sus canales seleccionados directamente. Los administradores pueden preferir API canales o conservar la preferencia del protocolo del cliente. API las llamadas pueden consumir saldo ascendente; SubLane no consulta ese saldo.
Las actualizaciones preservan las preferencias de protocolo y las combinaciones de claves de los grupos existentes. Las conversaciones existentes nunca pasan a otro recurso después de cambios de ruta. Deshabilitar el respaldo o eliminar/deshabilitar un recurso vinculado puede hacer fallar su conversación existente en lugar de cambiar su identidad.
La gestión API mantiene /api/groups y compatibles account_ids cargas útiles. La nueva interfaz de usuario envía resources (kind: "subscription" o "channel" y recurso id) y routing (preference, allow_api_fallback). Se rechazan las representaciones de membresía mixta, las identificaciones duplicadas y los tipos de recursos incorrectos.
Flujo de trabajo del administrador
- En el espacio de trabajo seleccionado, abra Grupos de recursos y crear un grupo con nombre. Seleccione cuentas de suscripción y API canales por separado. Los nuevos recursos permanecen sin asignar hasta que se seleccionen para un grupo.
- Abierto Miembros y otorgar a cada miembro acceso a los grupos que pueda utilizar. Una subvención se aplica directamente a ese miembro; no hay equipos de personal. Los nuevos miembros y nuevos grupos no reciben subvenciones automáticas.
- Los miembros crean una clave personal para un grupo habilitado al que pueden acceder. Cada clave está permanentemente vinculada a ese espacio de trabajo y grupo. Revocar y volver a crear una clave para cambiar su vinculación.
Los grupos no administrados pueden compartir la misma cuenta ascendente dentro de un espacio de trabajo. A asignación de recursos requiere un grupo exclusivo: elimine primero sus recursos de otros grupos. Una vez que un grupo tiene una asignación, su membresía de recursos permanece fija mientras exista la asignación, incluso si está en pausa. Deshabilitar un grupo o revocar la concesión de un miembro bloquea solicitudes futuras y WebSocket se activa sin mover una conversación existente a otro recurso.
Un espacio de trabajo admite hasta 32 grupos y 100 asociaciones de recursos por grupo. Los grupos se pueden cambiar de nombre y desactivar. La interfaz actual no elimina grupos. Los límites de solicitudes de miembros y las asignaciones de recursos se configuran por separado.
La siguiente captura de pantalla es de una versión anterior con las etiquetas del grupo de recursos; el editor de grupos de recursos actual también enumera API canales y preferencias de enrutamiento:
Comportamiento de solicitud y conversación
- La creación de claves verifica el acceso de los miembros y grupos actuales en la misma transacción que la inserción de la clave.
- Cada solicitud y WebSocket turno vuelve a verificar el estado del espacio de trabajo, la membresía, el estado de las claves, el acceso al grupo y la política del modelo.
- El descubrimiento y la inferencia utilizan únicamente cuentas elegibles en el grupo vinculado. Una solicitud puede utilizar una cuenta solo si su catálogo guardado admite el modelo solicitado.
- La afinidad de la conversación tiene como ámbito el miembro, el grupo y la sesión. Si su cuenta vinculada deja de estar disponible o abandona el grupo, la conversación falla en lugar de cambiar de cuenta silenciosamente.
- Una solicitud ya admitida puede finalizar después de que cambie una concesión; la siguiente solicitud o turno ve la nueva política.
HTTP puntos finales
Los puntos finales de administración requieren una función de administrador en el espacio de trabajo seleccionado. Las solicitudes del navegador llevan la selección del espacio de trabajo y requieren protección del mismo origen para mutaciones.
| Ruta | Objetivo |
|---|---|
GET /api/groups / POST /api/groups | Listar o crear grupos en el espacio de trabajo seleccionado |
GET /api/groups/{id} / PATCH /api/groups/{id} | Leer o actualizar un grupo de propiedad |
GET /api/groups/{id}/members | Lista de miembros habilitados y concedidos directamente |
GET /api/groups/members/{userId} | Enumere las subvenciones grupales de un miembro en este espacio de trabajo |
PUT /api/groups/members/{userId} | Reemplazar atómicamente las subvenciones de ese miembro en este espacio de trabajo |
GET /api/keys/groups | Listar los grupos actualmente disponibles para el miembro que ha iniciado sesión |
La puerta de enlace identifica el espacio de trabajo a partir de la clave autenticada, no del encabezado de selección del navegador. Ver espacios de trabajo y Claves API.
Acceso al modelo
Un administrador puede habilitar Límite de modelos permitidos en el editor de grupo. Ingrese hasta 100 ID exactas, una por línea, utilizando las ID devueltas por /v1/models. Las identificaciones nativas permiten ese modelo exacto entre los proveedores de soporte del grupo. Las reglas existentes calificadas por proveedores conservan su alcance de proveedor original; actualizar SubLane no los reescribe ni los amplía. Las reglas calificadas heredadas aún se pueden enviar explícitamente. No se admiten comodines y las variantes del modelo deben enumerarse explícitamente.
Los grupos no tienen restricciones de forma predeterminada, incluidos los modelos recién descubiertos. Al habilitar la lista de permitidos sin entradas se rechazan todos los modelos. El API acepta un opcional model_policy: {"restricted": true, "models": ["synthetic-model"]} al crear/actualizar. La omisión preserva una política existente; no restablece el acceso. Las respuestas del grupo incluyen restricted_models; Las respuestas detalladas también incluyen allowed_models.
El descubrimiento de modelos filtra los modelos fuera de la lista de permitidos y no contacta a los proveedores excluidos por completo por la política. Responses, Chat Completions, compactación y cada WebSocket turno (incluido el precalentamiento local) verifican la política actual antes de la selección de cuentas o el trabajo ascendente. Vuelve un modelo negado 403 model_not_allowed; no consume ninguna tarifa de miembro/asignación de simultaneidad y no crea afinidad. Las solicitudes ya admitidas podrán finalizar.
Modelos descubiertos automáticamente
Abierto Modelos en un grupo para inspeccionar la unión de los catálogos de modelos guardados de sus cuentas elegibles. La lista sigue la membresía de la cuenta y aplica la lista de permitidos existente; no es una segunda copia editable de esa política. Los nuevos modelos ascendentes aparecen automáticamente solo en grupos sin restricciones. Las restricciones explícitas, incluida una lista de denegación total vacía habilitada, permanecen sin cambios durante la sincronización.
Inference utiliza soporte de catálogo específico de cuenta antes de aplicar reglas normales de carga/cooldown. Cuentas con diferentes capacidades de suscripción pueden compartir un grupo: una solicitud es elegible sólo para las cuentas que reportaron su modelo. catálogos de modelos para la frescura, fracasos y afinidad de conversación.