Planera driftsättning av Copilot Studio-agenter för genomströmning och hastighetsbegränsningar

Produktionsklara Copilot Studio-agenter behöver mer än licenser och planering av den totala meddelandevolymen. De behöver också planering av genomströmning. Dataflödesplaneringen beskriver hur snabbt trafiken kommer fram, vilka plattformstjänster lösningen anropar och vilka gränser som gäller för hela lösningen.

Den här artikeln hjälper lösningsarkitekter, tillverkare och Power Platform-administratörer att förbereda distributioner med stora volymer Copilot Studio för produktionstrafik, användargodkännandetestning (UAT), belastningstestning, B2C-scenarier (business-to-customer) och autonoma arbetsbelastningar.

Taxeprovisionering är separat från licensprovisionering

Produktionsplaneringen Copilot Studio har två relaterade men separata arbetsströmmar:

• Licenstilldelning omfattar kommersiella rättigheter och användning, till exempel licenser, krediter, förbetald kapacitet, meddelandepaket och fakturering enligt användning.
• Rate provisioning omfattar hur snabbt trafik kan bearbetas innan begränsningar eller tjänstskyddskontroller tillämpas.

Betala per användning kan öka tillgängliga gränser jämfört med konfigurationer med lägre kapacitet, men dataflödet är inte oändligt. Kontrollera de aktuella Copilot Studio gränserna, Power Platform-begärandeallokeringar, Power Automate gränser, begränsningar för Dataverse-tjänstens skydd, regler för anslutningsbegränsning och underordnade API-gränser.

Vad händer när strypning inträffar?

Strypning är ett beteende för att skydda tjänsten. Den skyddar delade tjänster från trafikmönster som överskrider publicerade gränser, burst-kontroller eller tjänstkapacitet. Det exakta symptomet beror på vilken tjänst som begränsas.

När en gräns nås är konsekvensen mer än ett planeringsproblem. Begäranden kan begränsas, fördröjas, blockeras eller avvisas. I användarriktade chattar kan det här beteendet visas som ett tillfälligt avbrott i tjänsten. Användaren kanske till exempel inte kan skicka nästa meddelande, ta emot ett meddelande om agentens otillgängliga eller användningsgräns eller uppleva ett misslyckat steg eftersom ett flöde, anslutningsprogram, Dataverse-anrop, AI-tjänst eller underordnade API har nått sin gräns.

Lär dig mer om Copilot Studio-specifika symtom och felmeddelanden i Upplös användningsgränsfel i agenter.

Hur hastighetsgränser mäts

Hastighetsbegränsningar mäter hur mycket trafik en tjänst kan acceptera under en viss tidsperiod. Tänk på dessa fönster detaljerat: per minut, per fem minuter, per 10 minuter, per timme, per dag, per vecka och per månad. Månads- eller veckovolymer hjälper till att uppskatta den totala efterfrågan, men kortare tidsfönster är viktiga för kapacitetsplanering eftersom strypning ofta orsakas av koncentrerad trafik.

Ett B2C-företag kan till exempel få merparten av sin agenttrafik under en enda fokuserad kampanjtimme. Veckogenomsnittet kan se lågt ut, men den enda timmen kan fortfarande skapa tillräckligt med dataflödestryck för att orsaka begränsningar eller avbrott i tjänsten. En utformning som verkar säker på vecko- eller månadsnivå kan ändå överskrida gränserna under en enskild topptimme.

Förstå gränsernas omfattning

Gränser gäller inte bara på den enskilda agentnivån. Beroende på tjänsten kan de tillämpas på miljönivå, verktygsnivå, API-nivå, anslutningsnivå, kanalnivå eller underordnad tjänstnivå.

Till exempel gäller gränserna för meddelanden till agent i Copilot Studio per Dataverse-miljö. När du uppskattar trafik, inkludera alla källor som skickar meddelanden till agenter i den miljön, inklusive användarorienterade kanaler, integrationer, autonoma arbetsbelastningar och Azure Bot Service-färdigheter. Kontrollera aktuella värden och omfång i Copilot Studio kvoter och gränser.

Bestäm om rate provisioning gäller för din agent

Alla agenter behöver inte detaljerat arbete med taxeprovisionering. En enkel intern FAQ-agent med en liten målgrupp, förutsägbar användning och få eller inga underordnade anrop kommer sannolikt inte att nå hastighetsgränserna. Kapacitetsplanering är viktigt när en agent kan överskrida gränserna för antal begäranden per minut eller timme, även om den månatliga volymen verkar blygsam.

Tänk på förväntad trafik tidigt i projektet, tillsammans med lösningsdesign. Innan användargodkännandetestning (UAT) och belastningstestning börjar bör teamet vara säkra på att agentdesignen, miljön, anslutna tjänster och underordnade system kan stödja den förväntade dataflödesprofilen.

Den här vägledningen är viktigast för större, mer intensiva agenter i företagsklass där trafik kan komma in i toppar, många användare eller händelser kan anropa agenten samtidigt, eller så är varje interaktion beroende av flera plattformstjänster. Det kan också gälla för mindre agenter med koncentrerade användningsmönster, till exempel ett kort startfönster, en avdelningsomfattande händelse, en schemalagd process eller ett arbetsflöde som skapar många begäranden på några minuter.

B2C och autonoma agenter kräver tidigt tillhandahållande av priser

Kundinriktade B2C-agenter kan ta emot trafik från kampanjer, offentliga webbplatser, kundportaler, incidentkommunikation, produktlanseringar eller säsongsbaserad efterfrågan. Autonoma agenter kan generera trafik med hög frekvens från scheman, händelser, bakgrundsprocesser eller när de anropar flera verktyg och arbetsflöden.

Använd toppfönster, inte bara månatliga summor

Fråga om agenten kan skapa koncentrerade begäranden på en minut eller timme. Ett mindre scenario kan fortfarande behöva frekvensetablering om ett belastningstest, en kampanj, ett avbrottssvar eller en automatiserad utlösare skickar för många meddelanden, generativa AI-anrop, arbetsflödesåtgärder, anslutningsanrop eller Dataversum-begäranden via miljön i ett kort fönster.

Månadsvolym är användbar för att uppskatta den totala efterfrågan, men det räcker inte för kapacitetsplanering. Konvertera förväntad användning till mindre tidsfönster så att du kan jämföra designen med aktuella begäranden per minut (RPM), begäranden per timme (RPH), burst och dagliga gränser från de länkade sidorna.

Skapa både en genomsnittlig trafikprofil och en trafikprofil med hög belastning. Om den mesta trafiken till exempel sker varje dag mellan 17.00 och 18.00 bör timtopparna återspegla den koncentrationen. Den dagliga uppskattningen behöver inte vara 24 gånger maxtimmen om trafiken är koncentrerad till ett enda tidsfönster.

Använd dessa uppskattningar för att dimensionera och validera designen. Uppskattningar är inte tillräcklig motivering för en begäran om ökad genomströmning. Förfrågningar granskas mot observerad trafik från en pilotfas, som beskrivs i Kör en pilotfas innan en ökad genomströmning begärs.

När annars kan strypning inträffa?

Strypning kan också inträffa när:

• En stor personalpopulation använder agenten under ett förutsägbart toppfönster, till exempel en avdelningsomfattande händelse eller utbildning.
• En marknadsföringskampanj, ett avbrott, en lansering eller en planerad affärshändelse leder till en kort trafikspik.
• Power Automate-flöden inkluderar loopar, återförsök, sidindelning eller underflöden som ökar volymen av begäranden.
• Rapportering, revision, telemetriexport eller insamling av transkript körs synkront i flödet för användarens tur.
• Flera agenter eller arbetsbelastningar delar samma miljö, identitet, anslutningsprogram eller kapacitet hos bakomliggande API:er.
• Belastningstesterna ökade snabbare än produktionsarkitekturen eller supportprocessen var förberedda på att hantera.

Var du kan söka efter relevanta hastighetsgränser

Copilot Studio har sina egna begränsningar, och agentens körningsväg kan omfatta andra tjänster med egna begränsningar. Granska alla relevanta gränser för de tjänster som agenten använder.

Begränsningar i Copilot Studio

Andra plattformsgränser att tänka på

Den lägsta begränsningen i körvägen avgör användarupplevelsen. En agent i Copilot Studio kan hålla sig inom sina egna gränser samtidigt som ett flöde, ett anslutningsprogram, ett Dataverse-anrop, en språktjänst eller ett externt API stryps.

Utformning för att minska belastningen på genomströmningen

Låt inte frekvensökningar vara din första designlösning. Granska först agentdesignen och optimera effektiviteten. Om agenten behöver leta upp något kan du hålla externa anrop avsiktliga, optimera API-anrop och undvika onödiga begärandevolymer i Copilot Studio, Power Automate, Dataverse, anslutningsappar och underordnade system.

När designen är effektiv kontrollerar du dataflödet så att trafiken når plattformen på ett förutsägbart sätt:

• För gränser på miljönivå bör du överväga att dela upp agenter i flera miljöer om den metoden matchar din driftsdesign. Den här metoden kan hjälpa till att hindra högvolymagenter, affärsenheter, regioner eller autonoma arbetsbelastningar från att konkurrera med orelaterade arbetsbelastningar för samma miljöomfångsgränser.
• För autonoma agenter använder du köer, batchbearbetning, utlösarfilter, schemalagd bearbetning, återförsökskontroller och övervakning så att bakgrundsarbete inte tas emot som en okontrollerad burst.
• Flytta schemalagt arbete, rapporteringsarbete, export av granskningsdata och telemetriarbete utanför den interaktiva chattvägen när det är möjligt.
• Granska belastningstestresultat och produktionstelemetri för att identifiera var begäranden koncentreras, justera sedan agenten, flöden, anslutningsappar och underordnade API:er innan du begär högre gränser.

Autonoma agenter har särskilt goda förutsättningar att maximera användningen av sin tilldelade kapacitet med god förutsägbarhet och god observerbarhet genom att köa förfrågningar och styra hur ofta de utlöses.

Kör en pilotfas innan du begär en ökning av genomströmningen

Standardgränser tillgodoser de flesta produktionsagenter, inklusive agenter som betjänar tusentals aktiva användare varje månad. Innan du planerar för en genomströmningsökning, kontrollera att agenten faktiskt behöver en.

Att gå direkt till en lansering i full skala är inte ett stött utrullningsmönster. Släpp agenten till en delmängd av den avsedda målgruppen först, observera verklig användning och använd dessa mått för att planera hela utrullningen. En pilotfas minskar både uppskjutningsrisken och ger de bevis som en begäran om ökad genomströmning kräver.

Den verkliga användningen skiljer sig rutinmässigt från uppskattningar före lansering. Sessionslängd, meddelanden per session, hur ofta användare når generativa svar eller åtgärder, återförsöksbeteende och antalet flödes-, connector-, Dataverse- och externa API-anrop per tur är alla svåra att förutsäga innan agenten är i händerna på riktiga användare. En pilot lyfter fram de gränser som är viktiga och de trafikmönster som är svåra att uppskatta i förväg.

Utforma ett effektivt pilotprojekt

Mät under pilotfasen

Fånga de värden som direkt motsvarar de publicerade hastighetsgränserna:

• Meddelanden per minut och per timme, i genomsnitt och vid topp.
• Sessioner, samtidiga sessioner, sessionslängd och meddelanden per session.
• Generativa AI-anrop per omgång och per session, inklusive generativa svar, agentåtgärder och verktyg.
• Power Automate-åtgärder, anslutningsanrop och Dataverse-förfrågningar som genereras vid varje agentomgång.
• Strypningshändelser, fel på grund av användningsgränser, omförsök och latens under pilotens perioder med högst belastning.
• Pilotpublikens storlek, uttryckt som en andel av hela den avsedda publiken.

Extrapolera till full kapacitet

Skala de observerade toppmätningarna till hela publiken och dokumentera metoden du använde. Basera skalningen på topptrafiken under pilotfasen, inte på dagliga eller veckovisa genomsnitt, eftersom strypning beror på koncentrerad trafik. Räkna med allt som piloten inte inkluderade, såsom extra regioner, kanaler, autonoma arbetsbelastningar eller en lanseringskampanj som koncentrerar trafiken mer än pilotperioden gjorde.

Resultatet är en evidensbaserad förfrågan: uppmätt pilottrafik, pilotens andel av användarbasen, extrapolationsmetoden och det resulterande toppbehovet vid full skala.

Vad du ska göra om standardfrekvensgränserna inte räcker

Om observerad pilottrafik visar att agenten eller någon ansluten tjänst överskrider nuvarande publicerade gränser i full skala, starta supportprocessen för hastighetsprovisionering innan du expanderar utrullningen. Vänta inte på det första produktionsfelet.

Öppna en supportförfrågan

Administratörer kan begära support från administrationscentret för Power Platform.

Öppna biljetten efter pilotfasen och inkludera de uppmätta resultaten tillsammans med extrapoleringen till full kapacitet. Förfrågningar som endast innehåller designtidsuppskattningar eller små UAT-resultat kan inte granskas och fördröjer ökningen. Ju mer noggrant detaljerad information du ger, desto snabbare blir granskningen. Uppdatera förfrågan när utrullningen utökas och ytterligare telemetri blir tillgänglig.

Grundläggande information som ska inkluderas

Mer information som kan hjälpa

Relaterad information

• Copilot Studio-kvoter och gränser
• Metodtips för att förbättra konversationsagentens prestanda
• Lösa användningsgränsfel i agenter
• Begäranden, gränser och allokeringar
• Förstå plattformsgränser och undvika strypning
• Gränser för automatiserade, schemalagda och omedelbara flöden
• API-gränser för tjänstskydd
• Översikt över Dataverse API-begränsningar
• Begränsningar för förståelse av konversationsspråk
• Få support i administrationscentret för Power Platform