Grupos de recursos
Configure grupos de recursos e conceda acesso direto aos membros.
Um grupo de recursos seleciona contas de assinatura e canais API do mesmo espaço de trabalho. Crie grupos separados quando os membros precisarem de recursos ou modelos diferentes. Não é possível associar recursos entre espaços.
Tipos de recursos e encaminhamento
Os grupos de recursos vinculam as chaves de gateway pessoais, as subvenções de membros e as políticas de modelos. O editor seleciona as contas de assinatura e API canais separadamente; cada tipo de recurso tem sua própria página de gerenciamento enquanto mantém o isolamento do espaço de trabalho.
Novos grupos de UI preferem assinaturas com API voltar atrás. Um grupo misto usa API canais para novos pedidos apenas quando o recurso estiver explicitamente habilitado e não estiver disponível nenhuma assinatura elegível. API- somente o grupo usa seus canais selecionados diretamente. Os administradores podem preferir API canais ou manter a preferência cliente-protocolo. API as chamadas podem consumir saldo a montante; SubLane não questione esse equilíbrio.
As atualizações preservam a preferência de protocolo e as combinações de chaves dos grupos existentes. As conversas existentes nunca se movem para outro recurso após as alterações de roteamento. Desativar o backback ou remover/desativar um recurso ligado pode falhar na sua conversação existente em vez de alterar a sua identidade.
A gestão API mantem /api/groups e compatível account_ids cargas. O novo UI envia resources (kind: "subscription" ou "channel" e recurso id) e routing (preference, allow_api_fallback). Representações mistas de membros, identidades duplicadas e tipos de recursos incorretos são rejeitados.
Fluxo de trabalho do administrador
- Na área de trabalho seleccionada, abrir Grupos de recursos e criar um grupo com nome. Selecione as contas de subscrição e API canais separadamente. Novos recursos permanecem sem atribuição até serem selecionados para um grupo.
- Abrir Membros e conceder a cada membro o acesso aos grupos que possam utilizar. Uma subvenção aplica-se directamente a esse membro; não existem equipas de pessoal. Novos membros e novos grupos não recebem subvenções automáticas.
- Os membros criam uma chave pessoal para um grupo habilitado que eles podem acessar. Cada chave está permanentemente ligada a essa área de trabalho e grupo. Revogue e recrie uma chave para alterar sua vinculação.
Grupos não gerenciados podem compartilhar a mesma conta a montante dentro de um espaço de trabalhoA Subsídio de recursos requer um grupo exclusivo: remover os seus recursos de outros grupos primeiro. Uma vez que um grupo tenha uma licença, a sua subscrição de recursos permanece fixa enquanto a licença existe, mesmo que seja pausada. Desactivar um grupo ou revogar uma subvenção de um membro bloqueia futuras solicitações e WebSocket gira sem mover uma conversa existente para outro recurso.
Uma área de trabalho suporta até 32 grupos e 100 associações de recursos por grupo. Os grupos podem ser renomeados e desabilitados. A interface atual não remove grupos. Os limites de solicitação de membros e as alocações de uso são configurados separadamente.
A imagem a seguir é de uma versão anterior com os rótulos do grupo de contas; o editor do grupo de recursos atual também lista API canais e preferências de encaminhamento:
Pedido e comportamento de conversação
- A criação de chaves verifica o acesso atual dos membros e grupos na mesma transação que a inserção da chave.
- Cada pedido e WebSocket Turn verifica novamente o status da área de trabalho, a associação, o status chave, o acesso ao grupo e a política de modelos.
- A descoberta e a inferência usam apenas contas elegíveis no grupo vinculado. Uma solicitação só pode usar uma conta se seu catálogo salvo suportar o modelo solicitado.
- A afinidade de conversação é explorada para o membro, grupo e sessão. Se sua conta vinculada ficar indisponível ou deixar o grupo, a conversa falha ao invés de mudar silenciosamente de contas.
- Um pedido já admitido pode terminar após uma alteração de subvenção; o próximo pedido ou turno vê a nova política.
HTTP endpoints
Os endpoints de gerenciamento requerem um papel de administrador na área de trabalho selecionada. As solicitações de navegadores carregam a seleção de espaço de trabalho e requerem proteção de mesma origem para mutações.
| Rota | Objecto |
|---|---|
GET /api/groups / POST /api/groups | Listar ou criar grupos na área de trabalho selecionada |
GET /api/groups/{id} / PATCH /api/groups/{id} | Ler ou atualizar um grupo próprio |
GET /api/groups/{id}/members | Lista diretamente concedida, membros habilitados |
GET /api/groups/members/{userId} | Listar as subvenções de grupo de um membro neste espaço de trabalho |
PUT /api/groups/members/{userId} | Substituir atómicamente as subvenções desse membro neste espaço de trabalho |
GET /api/keys/groups | Listar grupos atualmente disponíveis para o membro assinado |
O gateway identifica a área de trabalho a partir da chave autenticada, não o cabeçalho de seleção do navegador. Veja espaços de trabalho e Chaves de API.
Modelo de acesso
Um administrador pode activar Limitar os modelos permitidos no editor do grupo. Digite até 100 IDs exatos, um por linha, usando os IDs retornados por /v1/models. IDs nativos permitem que o modelo exato entre os provedores de suporte no grupo. Regras existentes qualificadas para provedor manter seu escopo de provedor original; atualização SubLane não as reescreve ou alarga. As regras qualificadas do Legacy podem ainda ser enviadas explicitamente. Os Wildcards não são suportados e as variantes do modelo devem ser listadas explicitamente.
Os grupos permanecem irrestritos por padrão, incluindo modelos recém- descobertos. Habilitar a lista de permissões sem entradas nega todos os modelos. API aceita um opcional model_policy: {"restricted": true, "models": ["synthetic-model"]} na criação/atualização. A omissão preserva uma política existente; ela não repõe o acesso. As respostas do grupo incluem restricted_models; respostas detalhadas também incluem allowed_models.
O modelo de descoberta filtra modelos fora da lista de allowlist e não contacta os fornecedores excluídos inteiramente pela política. Responses, Chat Completions, compactação, e cada WebSocket turn (incluindo pré- aquecimento local) verifica a política actual antes da selecção da conta ou do trabalho a montante. Um modelo negado retorna 403 model_not_allowed; não consome taxa de membro / subsídio de concorrência e não cria nenhuma afinidade. Pedidos já admitidos podem terminar.
Modelos descobertos automaticamente
Abrir Modelos em um grupo para inspecionar a união dos catálogos de modelos salvos de suas contas elegíveis. A lista segue a assinatura da conta e aplica a lista de allowlist existente; não é uma segunda cópia editável dessa política. Novos modelos upstream aparecem automaticamente apenas em grupos irrestritos. Restrições explícitas, incluindo uma lista vazia de negação ativa, permanecem inalteradas pela sincronização.
A inferência usa o suporte a catálogos específicos da conta antes de aplicar as regras normais de carga/refrigeração. Contas com diferentes capacidades de assinatura podem compartilhar um grupo: uma solicitação é elegível apenas para contas que reportaram seu modelo. catálogos de modelos para frescura, falhas e afinidade de conversa.