Planeie implementações de agentes do Copilot Studio para limites de débito e taxa

Os agentes do Copilot Studio aptos para produção precisam de mais do que o licenciamento e o planeamento do volume total de mensagens. Também precisam de planeamento da capacidade de processamento. O planeamento de throughput abrange a rapidez com que o tráfego chega, que plataforma serve as chamadas da solução e quais os limites que se aplicam em toda a solução.

Este artigo ajuda arquitetos de soluções, criadores e administradores do Power Platform a preparar implementações de grande volume do Copilot Studio para tráfego de produção, testes de aceitação do utilizador (UAT), testes de carga, cenários business-to-customer (B2C) e cargas de trabalho autónomas.

A provisão de tarifas é separada da provisão de licenças

O planeamento da Production Copilot Studio tem dois processos de trabalho relacionados, mas separados:

  • Disponibilização de licenças abrange os direitos de utilização e o consumo comercial, como licenças, créditos, capacidade pré-paga, pacotes de mensagens e faturação consoante a utilização.
  • A provisão de tarifas cobre a rapidez com que o tráfego pode ser processado antes de se aplicarem controlos de limitação ou proteção de serviço.

Note

Microsoft utiliza o termo quotas para limites de taxa Copilot Studio. No vocabulário mais amplo da indústria, esta atividade de planeamento é frequentemente chamada de provisão de tarifas. Revise os limites publicados, estime as taxas de pico de pedido e planeie antes da chegada do tráfego de produção.

O pagamento conforme a utilização pode aumentar os limites disponíveis face a configurações de menor capacidade, mas a taxa de transferência não é infinita. Verifique os limites atuais do Copilot Studio, as alocações de pedidos do Power Platform, os limites do Power Automate, os limites de proteção do serviço Dataverse, as regras de limitação dos conectores e os limites das APIs a jusante.

O que acontece quando ocorre a limitação?

A limitação é um comportamento de proteção de serviço. Protege os serviços partilhados contra padrões de tráfego que excedam os limites publicados, controlos de rajadas ou capacidade de serviço. O sintoma exato depende do serviço que está sujeito a limitação.

Quando se atinge um limite, a consequência é mais do que uma questão de planeamento. Os pedidos podem ser limitados, atrasados, bloqueados ou rejeitados. Em conversas dirigidas ao utilizador, este comportamento pode manifestar-se como uma interrupção temporária do serviço. Por exemplo, o utilizador pode não conseguir enviar a mensagem seguinte, receber uma mensagem de indisponibilidade do agente ou de limite de utilização, ou deparar-se com a falha de uma etapa porque um fluxo, conector, chamada do Dataverse, serviço de IA ou API a jusante atingiu o respetivo limite.

Aprenda sobre sintomas e mensagens de erro específicos de Copilot Studio em Resolver erros de limite de utilização em agentes.

Como são medidos os limites de taxa

Os limites de tarifa medem quanto tráfego um serviço pode aceitar durante uma janela de tempo específica. Pense nestas janelas de forma detalhada: por minuto, por cinco minutos, por 10 minutos, por hora, por dia, por semana e por mês. O volume mensal ou semanal ajuda a estimar a procura total, mas janelas mais curtas são importantes para a provisão de tarifas, pois a limitação muitas vezes resulta de tráfego concentrado.

Por exemplo, uma empresa B2C pode receber a maior parte do tráfego do seu agente durante uma única hora de campanha focada. A sua média semanal pode parecer baixa, mas essa única hora pode ainda assim criar pressão suficiente para causar limitação ou interrupções no serviço. Um design que parece seguro a nível semanal ou mensal pode ainda exceder os limites durante um pico de uma hora.

Compreender o âmbito dos limites

Os limites não se aplicam apenas ao nível individual do agente. Dependendo do serviço, podem aplicar-se ao nível do ambiente, ao nível da ferramenta, ao nível da API, ao nível do conector, ao nível do canal ou ao nível do serviço a jusante.

Por exemplo, os limites de mensagens para agente do Copilot Studio são definidos pelo âmbito do ambiente Dataverse. Ao estimar o tráfego, inclua todas as fontes que enviam mensagens aos agentes nesse ambiente, incluindo canais voltados para o utilizador, integrações, cargas de trabalho autónomas e skills do Azure Bot Service. Verifique os valores atuais e o alcance em quotas e limites do Copilot Studio.

Decida se a provisão de tarifas se aplica ao seu agente

Nem todos os agentes precisam de trabalho detalhado de provisionamento de tarifas. Um simples agente interno de FAQ com uma audiência pequena, utilização previsível e poucas ou nenhumas chamadas a jusante dificilmente atingirá os limites de taxa. A provisão de tarifas torna-se importante quando um agente pode exceder os limites de pedidos por minuto ou de pedidos por hora, mesmo que o seu volume mensal pareça modesto.

Pense no tráfego esperado no início do projeto, juntamente com o design da solução. Antes de começarem os testes de aceitação do utilizador (UAT) e os testes de carga, a equipa deve estar confiante de que o design do agente, o ambiente, os serviços conectados e os sistemas a jusante conseguem suportar o perfil de throughput esperado.

Esta orientação é especialmente importante para agentes empresariais maiores e mais intensivos, onde o tráfego pode chegar em rajadas, muitos utilizadores ou eventos podem invocar o agente ao mesmo tempo, ou cada interação depende de múltiplos serviços de plataforma. Também pode aplicar-se a agentes mais pequenos com padrões de utilização concentrados, como uma janela de lançamento curta, um evento a nível de departamento, um processo agendado ou um fluxo de trabalho que gera muitos pedidos em poucos minutos.

Os agentes B2C e autónomos exigem a configuração antecipada das tarifas

Os agentes B2C voltados para o cliente podem receber interações provenientes de campanhas, sites públicos, portais de clientes, comunicações de incidentes, lançamentos de produtos ou procura sazonal. Agentes autónomos podem gerar tráfego de alta frequência a partir de agendamentos, eventos, processos em segundo plano ou quando apelam a múltiplas ferramentas e fluxos de trabalho.

Tip

Considere os casos de uso B2C e os casos de uso autónomos como cenários principais de provisionamento de tarifas. Podem gerar tráfego em rajadas, múltiplos pedidos simultâneos e atividade em segundo plano de alta frequência mais rapidamente do que muitas experiências de chat direcionadas para colaboradores.

Utilize janelas de pico, não só totais mensais

Pergunte se o agente consegue criar pedidos concentrados num minuto ou numa hora. Um cenário mais pequeno pode ainda precisar de provisionamento de capacidade se um teste de carga, uma campanha, uma resposta a indisponibilidades ou um acionador automático fizer passar demasiadas mensagens, chamadas de IA generativa, ações de fluxo de trabalho, chamadas de conector ou pedidos ao Dataverse no ambiente num curto espaço de tempo.

O volume mensal é útil para estimar a procura total, mas não é suficiente para a provisão de tarifas. Converta a utilização prevista em janelas de tempo mais pequenas, para que possa comparar a conceção com os pedidos atuais por minuto (RPM), os pedidos por hora (RPH), os picos e os limites diários indicados nas páginas associadas.

Constrói tanto um perfil de tráfego médio como um perfil de tráfego de pico. Por exemplo, se a maior parte do trânsito acontecer todos os dias entre as 17h e as 18h, o pico horário deve refletir essa concentração. A estimativa diária não precisa de ser 24 vezes a hora de pico se o trânsito estiver concentrado numa única janela.

Use estas estimativas para dimensionar e validar o desenho. As estimativas não são justificação suficiente para um pedido de aumento de rendimento. Os pedidos são analisados com base no tráfego observado durante uma fase piloto, conforme descrito em Executar uma fase piloto antes de solicitar um aumento de throughput.

Quando mais pode acontecer o throttling?

A limitação também pode acontecer quando:

  • Uma grande população de funcionários utiliza o agente durante uma janela de pico previsível, como um evento ou formação a nível de departamento.
  • Uma campanha de marketing, interrupção, lançamento ou evento empresarial agendado cria um pico curto de tráfego.
  • Os fluxos do Power Automate incluem ciclos de repetição, novas tentativas, paginação ou fluxos subordinados que aumentam o volume de pedidos.
  • A criação de relatórios, a auditoria, a exportação de telemetria ou a captura de transcrição são executadas de forma síncrona no fluxo de interação do utilizador.
  • Múltiplos agentes ou cargas de trabalho partilham o mesmo ambiente, identidade, conector ou capacidade de API a jusante.
  • Os testes de carga aumentam mais rapidamente do que a arquitetura de produção ou o processo de suporte estavam preparados para suportar.

Onde consultar os limites de taxa relevantes

O Copilot Studio tem os seus próprios limites, e o percurso de execução do agente pode incluir outros serviços com os seus próprios limites. Revise todos os limites relevantes para os serviços que o seu agente utiliza.

Limites do Copilot Studio

Área de aprovisionamento de tarifas O que procurar Onde verificar os valores atuais Como utilizá-lo
Mensagens para um agente Limites atuais de RPM e RPH e âmbito das mensagens enviadas ao agente. Copilot Studio quotas e limites Compare as mensagens esperadas por minuto e por hora para o ambiente Dataverse alvo.
Mensagens de IA generativa Limite atual para orquestração generativa, ações de agentes, ferramentas de IA, ações de workflow de agentes e respostas generativas. Mensagens de IA generativas para um agente Modelar cenários com forte IA e autónomos de acordo com os limites publicados atualmente.
Nodos de acionamento autónomos Limites atuais que se aplicam quando um agente autónomo é acionado por eventos, agendas ou processos em segundo plano. Copilot Studio quotas e limites Modele cargas de trabalho orientadas por eventos e agendadas separadamente do tráfego de chat interativo.
Limites de pedidos de subscrição do Copilot Studio Limites atuais de pedidos da Power Platform que se aplicam à utilização do Copilot Studio. Copilot Studio limites de subscrição Utilize estes valores em conjunto com o planeamento dos limites de taxa para fluxos, Dataverse e serviços conectados.

Outros limites de plataforma a considerar

O limite mais baixo no percurso de execução determina a experiência do utilizador. Um agente do Copilot Studio pode estar dentro dos seus próprios limites enquanto um fluxo, conector, chamada Dataverse, serviço de linguagem ou API externa é limitado.

Note

Outros limites da plataforma podem afetar o seu agente se este utilizar outros componentes na cadeia de pedido do agente. Considere também estes limites, incluindo o Power Platform, o Power Automate, o Dataverse, conectores, serviços linguísticos e sistemas a jusante.

Área de execução O que observar Questões sobre o fornecimento de tarifas Onde verificar os limites de corrente
Plano de pedidos do Power Platform Solicitações no Power Automate, chamadas de fluxos de trabalho no Copilot Studio, utilização do Dataverse, Power Apps e Dynamics 365. Qual utilizador, ligação, utilizador da aplicação ou principal do serviço gera os pedidos? As alocações de pedidos são suficientes para a carga diária e máxima de trabalho esperada? Limites de solicitações e alocações
Fluxos do Power Automate Acionadores, ações, ciclos, fluxos subordinados, ações HTTP, ações de conector, novas tentativas, paginação e concorrência. Quantas ações são criadas por turno de agente? Os limites de pico, concorrência, disparador e conector estão incluídos? Compreenda os limites da plataforma e evite a contenção
Limites dos fluxos automatizados, programados e instantâneos
Dataverse Operações CRUD, suplementos, fluxos de trabalho, operações de atribuição e partilha, chamadas ao conector e operações de sistema necessárias para concluir transações. Que utilizadores, utilizadores de aplicações ou principais de serviço geram chamadas Dataverse? É provável que sejam aplicáveis limites de proteção do serviço ou comportamento de repetição? Limites da API de proteção do serviço
Descrição geral dos limites da API do Dataverse
Connectors Conectores padrão, conectores premium, conectores personalizados, throttling específico para conectores e APIs downstream. Qual conector é o gargalo? O serviço a jusante impõe o seu próprio limite de taxa? Limites de taxa de transferência da API nos conectores
Referência do conector do Power Automate
Compreensão conversacional de linguagem (CLU) e serviços de IA Chamadas CLU, pedidos à IA, operações de pesquisa e sumarização, ferramentas suportadas por modelos, tamanho da carga útil e limites específicos do serviço. Cada interação do utilizador invoca um serviço de linguagem ou de IA? Essas chamadas são repetidas durante novas tentativas ou a orquestração? Limites da compreensão da linguagem conversacional
Copilot Studio quotas e limites
APIs externas e sistemas de linha de negócio APIs de fornecedores, APIs internas, bases de dados, middleware, gateways e serviços personalizados. Que limite é que o proprietário a jusante impõe? Existe um contrato de retentativa, fila ou estratégia de contrapressão? Utilize os limites atuais, o acordo de nível de serviço (SLA) e o processo de suporte do responsável pelo serviço a jusante.

Projeto para reduzir a pressão de rendimento

Não faça dos aumentos de taxa a sua primeira resposta de design. Primeiro, reveja a conceção do agente e otimize a eficiência. Se o agente precisar de procurar algo, mantenha as chamadas externas deliberadas, otimize as chamadas às APIs e evite um volume desnecessário de pedidos no Copilot Studio, no Power Automate, no Dataverse, nos conectores e nos sistemas a jusante.

Depois de a conceção ser eficiente, controle o fluxo para que o tráfego chegue à plataforma de modo previsível:

  • Para limites ao nível do ambiente, considere dividir agentes em múltiplos ambientes se essa abordagem corresponder ao seu design operacional. Esta abordagem pode ajudar a evitar que agentes de alto volume, unidades de negócio, regiões ou cargas de trabalho autónomas concorram com cargas de trabalho não relacionadas pelos mesmos limites definidos pelo ambiente.
  • Para agentes autónomos, utilize filas, processamento em lotes, filtros de acionamento, processamento programado, controlos de repetição e monitorização, para que o trabalho em segundo plano não surja de forma descontrolada.
  • Deslocar o trabalho agendado, a elaboração de relatórios, a exportação de auditoria e a telemetria para fora do fluxo da conversa interativa, sempre que possível.
  • Revise os resultados dos testes de carga e a telemetria de produção para identificar onde os pedidos se concentram, depois ajuste o agente, os fluxos, os conectores e as APIs a jusante antes de solicitar limites mais elevados.

Os agentes autónomos estão numa posição única para maximizar a utilização da sua capacidade atribuída, com previsibilidade e observabilidade robustas, pondo os pedidos em fila de espera e controlando as respetivas taxas de acionamento.

Realize uma fase piloto antes de solicitar um aumento de rendimento

Os limites padrão acomodam a maioria dos agentes de produção, incluindo agentes que servem milhares de utilizadores ativos mensais. Antes de planear um aumento de rendimento, confirme que o agente realmente precisa de um.

Ir diretamente para um lançamento em grande escala não é um padrão de implementação suportado. Liberte primeiro o agente para um subconjunto do público-alvo, observe o uso real e use essas medições para planear o lançamento completo. Uma fase piloto reduz o risco de lançamento e produz a evidência que um pedido de aumento de rendimento exige.

Important

Os pedidos de aumento de rendimento são analisados com base no uso observado. Volumes projetados, estimativas produzidas durante o projeto, pequenas execuções de testes de aceitação por utilizadores (UAT) e testes de carga sintética não são aceites como justificação por si só. Faz uma fase piloto e submete os resultados medidos.

O uso real difere rotineiramente das estimativas pré-lançamento. A duração da sessão, as mensagens por sessão, a frequência com que os utilizadores obtêm respostas ou ações generadas, o comportamento de nova tentativa e o número de chamadas a fluxos, conectores, Dataverse e APIs externas por turno são difíceis de prever antes de o agente estar nas mãos de utilizadores reais. Um projeto piloto revela os limites que importam e os padrões de tráfego que são difíceis de estimar antecipadamente.

Projetar um piloto eficaz

Atributo piloto Guidance
Público Disponibilize a uma secção alargada e representativa do público-alvo, em vez de a uma equipa de projeto ou de teste. O grupo piloto deve incluir os papéis, regiões e casos de uso esperados em escala completa.
Duração Execute-o durante pelo menos uma semana, para que o piloto abranja um ciclo de negócio completo, incluindo períodos de pico conhecidos, como mudanças de turno, processamento de fim de mês, horários de campanha ou execuções autónomas agendadas.
Configuration Mantenha o percurso de execução em produção: os mesmos canais, tópicos, configuração de IA generativa, fontes de conhecimento, ações, fluxos, conectores e sistemas a jusante que a implementação total utiliza. O tráfego medido em relação a uma conceção reduzida não permite extrapolações fiáveis.
Telemetry Ative a análise, o Application Insights e os relatórios do centro de administração de que necessita antes do início do piloto, para que as sessões, as mensagens, as chamadas de IA generativa e os erros sejam capturados ao longo de todo o período.

Medição durante o piloto

Capture os valores que correspondem diretamente aos limites de taxa publicados:

  • Mensagens por minuto e por hora, em média e no pico.
  • Sessões, sessões simultâneas, duração da sessão e mensagens por sessão.
  • Chamadas de IA generativa por turno e por sessão, incluindo respostas geradas, ações de agentes e ferramentas.
  • Ações do Power Automate, chamadas de conectores e solicitações do Dataverse geradas por cada turno do agente.
  • Ocorrências de limitação, erros de limite de utilização, novas tentativas e latência durante os períodos de pico do projeto-piloto.
  • A dimensão do público piloto, expressa em percentagem do público-alvo total.

Extrapolar até à capacidade total

Escale as medições de pico observadas para o público completo e documente o método que utilizou. Baseie o escalonamento no tráfego de pico durante o piloto, e não nas médias diárias ou semanais, porque a limitação resulta da concentração de tráfego. Tenha em conta tudo aquilo que o piloto não incluiu, como regiões adicionais, canais, cargas de trabalho autónomas ou uma campanha de lançamento que concentre mais tráfego do que durante o período-piloto.

O resultado é um pedido baseado em evidências: o tráfego do piloto medido, a quota do piloto na audiência, o método de extrapolação e o requisito de pico resultante em escala total.

O que fazer se os limites de taxa de incumprimento não forem suficientes

Se o tráfego piloto observado mostrar que o agente ou qualquer serviço ligado ultrapassa os limites publicados atuais em escala total, inicie o processo de suporte ao provisionamento de taxas antes de expandir o lançamento. Não esperes pela primeira falha de produção.

Note

O Copilot Studio é um serviço SaaS com limites de tarifa para proteger o serviço de todos os clientes. Com justificação adequada, a engenharia pode permitir limites personalizados para cenários aprovados. Justificação adequada significa uso medido a partir de uma fase piloto, não de uma projeção.

Abrir um pedido de suporte

Os administradores podem solicitar apoio ao centro de administração da Power Platform.

Abra o bilhete após a fase piloto e inclua os resultados medidos juntamente com a extrapolação até à capacidade total. Pedidos que contenham apenas estimativas de tempo de projeto ou pequenos resultados de UAT não podem ser revistos e atrasam o aumento. Quanto mais detalhe medido fornecer, mais rápida será a avaliação. Atualize o pedido à medida que o lançamento se expande e mais telemetria fica disponível.

Informação central a incluir

Informação Description
ID do Ambiente O ambiente Dataverse onde o agente corre.
Nome ou identificador do agente O agente afetado pelo pedido.
Impacto comercial Impacto crítico se os limites padrão não forem suficientes.
Informação conhecida O que se sabe sobre o cenário, canal, contexto de lançamento, criticidade do negócio e se é B2C, autónomo, voltado para o colaborador ou apenas interno.
Instantâneo do agente Um snapshot ou exportação que ajuda os revisores a compreender a configuração do agente, o design, os serviços ligados e as definições relevantes.
Design do agente Descrição de alto nível de tópicos, uso de IA generativa, fontes de conhecimento, ações, fluxos, conectores, chamadas Dataverse e APIs externas usadas pelo agente.
Resumo do piloto Datas e duração do piloto, a dimensão do público-piloto e esse público enquanto percentagem do público-alvo total.
Tráfego médio observado Mediu o tráfego médio do piloto por minuto, hora e dia.
Tráfego de pico observado Foram medidos o pico de mensagens, as sessões, as chamadas de IA generativa, as ações de fluxo, as chamadas de conectores, os pedidos ao Dataverse e as chamadas de API externas durante as janelas de pico do piloto.
Requisito de pico extrapolado O requisito de pico no tamanho total da audiência, com o método de extrapolação e quaisquer suposições que tenha aplicado.

Mais detalhes que podem ajudar

Informação Description
Intervalo de datas Data de início e fim do aumento solicitado. Forneça intervalos de datas separados para testes de carga, teste de aceitação do utilizador e produção, caso diferem.
Padrão de pico Janelas de pico, fusos horários, condutores esperados e se o tráfego está concentrado numa janela diária curta.
Perfil da sessão Sessões simultâneas, duração média e pico das sessões, mensagens por sessão e perguntas por sessão.
Exemplos típicos de sessões Caminhos representativos dos utilizadores, passos típicos realizados, ferramentas usadas e IDs de sessão de exemplo quando disponíveis.
Caminho de execução Fluxos, ações, prompts de IA, consultas de conhecimento, pedidos do Dataverse, conectores e APIs por interação.
Picos ao nível das funcionalidades Volume máximo por agente, funcionalidade, utilizador, ambiente, conector, minuto, hora e dia, onde conhecido.
Produtos a necessitar de análise Quer o pedido diga respeito ao Copilot Studio, a alocações de pedidos no Power Platform, ao Power Automate, a conectores, ao Dataverse, a serviços CLU/de IA ou a APIs externas.
Evidence Telemetria do piloto, IDs de sessões de exemplo, erros, IDs de correlação, logs, eventos de limitação e observações de produção. Os resultados dos testes de carga podem complementar a telemetria do piloto, mas não a substituam.
Medidas de mitigação Resume o que já tentou para reduzir a pressão de rendimento. Consulte as orientações sobre Conceção para reduzir a pressão sobre o débito, incluindo revisão da conceção, otimização das chamadas externas, segmentação de ambientes, processamento em lote, colocação em fila, filtragem de acionadores, agendamento, distribuição da carga de trabalho e outras otimizações já implementadas.

Important

Um aumento de rendimento não é garantido. O Suporte da Microsoft analisa pedidos com base no cenário, ambiente, intervalo de datas solicitado, tráfego piloto observado, elegibilidade, limites atuais e capacidade de serviço.

  • Última atualização a