Planlæg Copilot Studio agentinstallationer for gennemløbs- og hastighedsgrænser

Produktionsklare Copilot Studio agenter har brug for mere end licenser og samlet planlægning af meddelelsesvolumen. De har også brug for planlægning af dataoverførselshastighed. Planlægning af dataoverførselshastighed dækker, hvor hurtigt der modtages trafik, hvilken platform der servicer løsningens kald, og hvilke grænser der gælder på tværs af hele løsningen.

Denne artikel hjælper løsningsarkitekter, udviklere og Power Platform-administratorer med at forberede store Copilot Studio udrulninger til produktionstrafik, test af brugeraccept (UAT), belastningstest, B2C-scenarier (business-to-customer) og autonome arbejdsbelastninger.

Klargøring af takster er adskilt fra klargøring af licenser

Produktions- Copilot Studio planlægning har to relaterede, men separate arbejdsstrøm:

  • Klargøring af licenser dækker kommercielle rettigheder og forbrug, f.eks. licenser, kreditter, forudbetalt kapacitet, meddelelsespakker og fakturering, der betales efter forbrug.
  • Klargøring af hastighed dækker, hvor hurtigt trafik kan behandles, før der gælder begrænsnings- eller tjenestebeskyttelseskontroller.

Bemærkning

Microsoft bruger udtrykket quotas for Copilot Studio satsgrænser. I bredere brancheordforråd kaldes denne planlægningsaktivitet ofte satsklargøring. Gennemse de publicerede grænser, anslå spidsbelastningsanmodninger og planlæg, før produktionstrafik ankommer.

Pay-as-you-go kan øge de tilgængelige grænser sammenlignet med konfigurationer med lavere kapacitet, men dataoverførselshastigheden er ikke uendelig. Kontrollér de aktuelle Copilot Studio grænser, allokeringer af Power Platform-anmodninger, Power Automate grænser, beskyttelsesgrænser for Dataverse-tjenesten, regler for begrænsning af connectorer og api-grænser for downstream.

Hvad sker der, når der sker neddrosling?

Throttling er en tjenestebeskyttelsesmekanisme. Den beskytter delte tjenester mod trafikmønstre, der overskrider publicerede grænser, burst-kontrolelementer eller tjenestekapacitet. Det nøjagtige symptom afhænger af, hvilken tjeneste der er begrænset.

Når en grænse nås, er konsekvensen mere end et planlægningsproblem. Anmodninger kan begrænses, forsinkes, blokeres eller afvises. I chats, der vender mod brugeren, kan denne funktionsmåde blive vist som en midlertidig tjenesteafbrydelse. Brugeren kan f.eks. ikke sende den næste meddelelse, modtage en agent-utilgængelig eller forbrugsgrænsemeddelelse eller opleve et mislykket trin, fordi et flow, en connector, et Dataverse-kald, en AI-tjeneste eller en downstream-API har nået grænsen.

Få mere at vide om Copilot Studio-specifikke symptomer og fejlmeddelelser i Løs fejl ved forbrugsgrænser i agenter.

Sådan måles hastighedsgrænser

Hastighedsgrænser måler, hvor meget trafik en tjeneste kan acceptere i løbet af et bestemt tidsvindue. Tænk på disse vinduer detaljeret: pr. minut, pr. fem minutter, pr. 10 minutter, pr. time, pr. dag, pr. uge og pr. måned. Månedlig eller ugentlig volumen hjælper med at estimere den samlede efterspørgsel, men kortere tidsvinduer er vigtige for kapacitetsplanlægning, fordi hastighedsbegrænsning ofte skyldes koncentreret trafik.

En B2C-virksomhed kan f.eks. modtage det meste af sin agenttrafik i løbet af én fokuseret kampagnetime. Det ugentlige gennemsnit kan se lavt ud, men den enkelte time kan stadig skabe tilstrækkeligt gennemløbstryk til at forårsage begrænsning eller tjenesteafbrydelser. Et design, der ser sikkert ud på ugentligt eller månedligt niveau, kan stadig overskride grænserne i løbet af en times spidsbelastning.

Forstå omfanget af grænser

Grænser gælder ikke kun på individuelt agentniveau. Afhængigt af tjenesten kan de anvendes på miljøniveau, værktøjsniveau, API-niveau, connectorniveau, kanalniveau eller downstreamtjenesteniveau.

Copilot Studio grænser for meddelelser til agent er f.eks. begrænset pr. dataversemiljø. Når du estimerer trafik, skal du inkludere alle kilder, der sender meddelelser til agenter i det pågældende miljø, herunder brugervendte kanaler, integrationer, autonome arbejdsbelastninger og Azure Bot Framework-færdigheder. Kontrollér de aktuelle værdier og området i Copilot Studio kvoter og grænser.

Beslut, om satsklargøring gælder for din agent

Ikke alle agenter har behov for detaljeret arbejde med opsætning af satser. Det er usandsynligt, at en simpel intern FAQ-agent med en lille målgruppe, forudsigelig brug og få eller ingen downstreamopkald vil overskride grænser for hyppigheden. Klargøring af rater bliver vigtig, når en agent kan overskride grænserne for anmodninger pr. minut eller pr. time, selv om det månedlige volumen ser beskedent ud.

Tænk på forventet trafik tidligt i projektet sammen med løsningsdesign. Før test af brugeraccept (UAT) og belastningstest begynder, bør teamet være sikker på, at agentdesign, miljø, forbundne tjenester og downstream-systemer kan understøtte den forventede gennemløbsprofil.

Denne vejledning er vigtigst for større, mere intensive agenter i virksomhedsklassen, hvor trafik kan ankomme i bursts, mange brugere eller hændelser kan aktivere agenten på samme tid, eller hver interaktion afhænger af flere platformtjenester. Den kan også gælde for mindre agenter med koncentreret brugsmønstre, f.eks. et kort startvindue, en hændelse for hele afdelingen, en planlagt proces eller en arbejdsproces, der opretter mange anmodninger på få minutter.

B2C og autonome agenter kræver tidlig klargøring af takster

B2C-agenter, der vender mod kunden, kan modtage trafik fra kampagner, offentlige websteder, kundeportaler, hændelseskommunikation, produktlanceringer eller sæsonbestemt efterspørgsel. Autonome agenter kan generere trafik med høj hyppighed fra tidsplaner, hændelser, baggrundsprocesser, eller når de kalder flere værktøjer og arbejdsprocesser.

Tip

Behandl B2C- og autonome anvendelsesscenarier som primære scenarier for klargøring af hastighed. De kan generere bursttrafik, flere samtidige anmodninger og højfrekvens baggrundsaktivitet hurtigere end mange chatoplevelser, der vender mod medarbejderne.

Brug spidsbelastningsvinduer, ikke kun månedlige totaler

Spørg, om agenten kan oprette koncentrerede anmodninger på et minut eller en time. Et mindre scenarie kan stadig have brug for satsklargøring, hvis en belastningstest, en kampagne, et afbrydelsessvar eller en automatiseret udløser sender for mange meddelelser, generative AI-kald, arbejdsproceshandlinger, connectorkald eller Dataverse-anmodninger via miljøet i et kort vindue.

Månedligt volumen er nyttigt til vurdering af den samlede efterspørgsel, men det er ikke nok til klargøring af rate. Konvertér det forventede forbrug til mindre tidsvinduer, så du kan sammenligne designet med aktuelle anmodninger pr. minut (RPM), anmodninger pr. time (RPH), burst og daglige grænser fra de sammenkædede sider.

Opret både en gennemsnitlig trafikprofil og en profil for spidsbelastningstrafik. Hvis der f.eks. sker mest trafik hver dag mellem kl. 17 og 18,00, skal timetoppet afspejle denne koncentration. Det daglige estimat behøver ikke at være 24 gange myldretiden, hvis trafikken er koncentreret i ét vindue.

Brug disse estimater til at dimensionere og validere designet. Estimater er ikke tilstrækkelig begrundelse for en anmodning om øget gennemstrømning. Anmodninger gennemgås mod observeret trafik fra en pilotfase, som beskrevet i Kør en pilotfase, før der anmodes om en stigning i gennemstrømningen.

Hvornår kan der ellers ske begrænsning?

Begrænsning kan der også ske når:

  • En stor medarbejderpopulation bruger agenten i et forudsigeligt vindue med spidsbelastninger, f.eks. en afdelingsbegivenhed eller uddannelse.
  • En marketingkampagne, afbrydelse, lancering eller planlagt forretningshændelse skaber en kort trafikspids.
  • Power Automate-flows omfatter løkker, genforsøg, paginering eller underflows, der øger anmodningsmængden.
  • Rapportering, overvågning, telemetrieksport eller registrering af transskription kører synkront i brugerens tursti.
  • Flere agenter eller arbejdsbelastninger deler den samme miljø-, identitets-, connector- eller downstream-API-kapacitet.
  • Belastningstestrampen er hurtigere end produktionsarkitekturen eller supportprocessen blev forberedt til at håndtere.

Hvor kan du søge efter relevante satsgrænser?

Copilot Studio har sine egne grænser, og agentens kørselssti kan omfatte andre tjenester med deres egne grænser. Gennemse alle relevante grænser for de tjenester, som din agent bruger.

Copilot Studio grænser

Område til klargøring af satser Hvad skal man slå op Hvor skal de aktuelle værdier kontrolleres? Sådan bruger du den
Meddelelser til en agent Nuværende RPM- og RPH-grænser og omfang for beskeder sendt til agenten. Copilot Studio-kvoter og -begrænsninger Sammenlign forventede meddelelser pr. minut og pr. time for destinationsmiljøet Dataverse.
Generativ AI-meddelelser Aktuel grænse for generativ orkestrering, agenthandlinger, AI-værktøjer, handlinger i agentarbejdsprocesser og generative svar. Generative AI-meddelelser til en agent Model ai-tunge og autonome scenarier i forhold til de aktuelle publicerede grænser.
Autonome udløsernoder Aktuelle grænser, der gælder, når en autonom agent udløses af hændelser, tidsplaner eller baggrundsprocesser. Copilot Studio-kvoter og -begrænsninger Modelhændelsesdrevne og planlagte arbejdsbelastninger adskilt fra interaktiv chattrafik.
Copilot Studio grænser for abonnementsanmodninger Aktuelle power platform-anmodningsgrænser, der gælder for Copilot Studio brug. Copilot Studio abonnementsgrænser Brug disse værdier sammen med planlægning af hastighedsgrænser for flow, dataverse og forbundne tjenester.

Andre platformgrænser, der skal overvejes

Den laveste grænse i kørselsstien bestemmer brugeroplevelsen. En Copilot Studio agent kan være inden for sine egne grænser, mens et flow, en connector, et Dataverse-kald, en sprogtjeneste eller en ekstern API er begrænset.

Bemærkning

Andre platformgrænser kan påvirke din agent, hvis den bruger andre komponenter i agentanmodningsstien. Tag også højde for disse grænser, herunder Power Platform, Power Automate, Dataverse, connectors, sprogtjenester og downstream-systemer.

Kørselsområde Hvad skal man se på? Spørgsmål om klargøring af hastighed Her kan du kontrollere de aktuelle grænser
Power Platform-anmodningsniveau Anmodninger på tværs af Power Automate, Copilot Studio arbejdsproceskald, dataverseforbrug, Power Apps og Dynamics 365. Hvilken bruger, forbindelse, programbruger eller tjenesteprincipal genererer anmodningerne? Er anmodningstildelinger tilstrækkelige til den forventede daglige arbejdsbelastning og spidsbelastning? Grænser for anmodninger og fordelinger
Power Automate-flow Udløsere, handlinger, løkker, underordnede flow, HTTP-handlinger, connectorhandlinger, forsøg, sideinddeling og samtidighed. Hvor mange handlinger oprettes pr. agent-tur? Er grænser for burst, samtidighed, udløser og connector omfattet? Forstå platformgrænser, og undgå kapacitetsbegrænsning
Grænser for automatiserede, planlagte og øjeblikkelige flow
Dataverse CRUD-handlinger, plug-ins, arbejdsprocesser, handlinger til tildeling/deling, connectorkald og systemhandlinger, der kræves for at fuldføre transaktioner. Hvilke brugere, programbrugere eller tjenesteprincipaler genererer Dataverse-kald? Er det sandsynligt, at grænser for servicebeskyttelse eller genforsøgsadfærd vil gælde? API'er for tjenestebeskyttelsesgrænser
Oversigt over Dataverse-API-grænser
Forbindelser Standard-connectors, Premium-connectors, brugerdefinerede connectors, connector-specifik drosling og downstream-API'er. Hvilken connector er flaskehalsen? Gennemtvinger downstream-tjenesten sin egen satsgrænse? Grænser for API-gennemløb for connectors
Power Automate-connectorreference
Forståelse af samtalesprog (CLU) og AI-tjenester CLU-kald, AI-prompts, søge- og opsummeringshandlinger, modelbaserede værktøjer, nyttedatastørrelse og tjenestespecifikke grænser. Kalder hver bruger et sprog eller en AI-tjeneste? Gentages disse kald under forsøg eller orkestrering? Grænser for forståelse af samtalesprog
Copilot Studio-kvoter og -begrænsninger
Eksterne API'er og line of business-systemer Leverandør-API'er, interne API'er, databaser, middleware, gateways og brugerdefinerede tjenester. Hvilken grænse gennemtvinger downstream-ejeren? Er der en strategikontrakt for genforsøg, kø eller backpressure? Brug downstream-tjenesteejerens aktuelle grænser, serviceniveauaftale (SLA) og supportproces.

Design til at reducere gennemløbstrykket

Lad ikke prisstigninger være din første designmæssige reaktion. Først skal du gennemse agentdesignet og optimere effektiviteten. Hvis agenten skal slå noget op, skal du holde eksterne opkald bevidst, optimere API-kald og undgå unødvendig anmodningsmængde på tværs af Copilot Studio, Power Automate, Dataverse, connectors og downstream-systemer.

Når designet er effektivt, kan du styre dataoverførselshastigheden, så trafikken når platformen på en forudsigelig måde:

  • I forbindelse med grænser på miljøniveau kan du overveje at opdele agenter på tværs af flere miljøer, hvis denne fremgangsmåde stemmer overens med dit driftsmæssige design. Denne fremgangsmåde kan hjælpe med at forhindre, at agenter, forretningsenheder, områder eller autonome arbejdsbelastninger konkurrerer med ikke-relaterede arbejdsbelastninger for de samme miljøomfangede grænser.
  • Til autonome agenter skal du bruge køer, batchbehandling, udløserfiltre, planlagt kørsel, styring af genforsøg og overvågning, så baggrundsarbejde ikke kommer i ukontrollerede bølger.
  • Flyt planlagt, rapportering, overvågningseksport og telemetri uden for den interaktive chatsti, når det er muligt.
  • Gennemse belastningstestresultater og produktionstelemetri for at identificere, hvor anmodninger koncentreres, og juster derefter agenten, flowene, connectorerne og downstream-API'erne, før du anmoder om højere grænser.

Autonome agenter er unikt placeret til at maksimere brugen af deres tildelte kapacitet med robust forudsigelighed og observabilitet ved at sætte anmodninger i kø og styre deres udløserhastigheder.

Kør en pilotfase, før du anmoder om en gennemstrømningsforøgelse

Standardgrænser dækker de fleste produktionsagenter, inklusive agenter, der betjener tusindvis af månedlige aktive brugere. Før du planlægger en stigning i gennemstrømningen, skal du bekræfte, at agenten faktisk har brug for en.

At gå direkte til en fuldskala lancering er ikke et understøttet udrulningsmønster. Frigiv agenten til en delmængde af den tiltænkte målgruppe først, observer det reelle forbrug, og brug disse målinger til at planlægge den fulde udrulning. En pilotfase reducerer både opsendelsesrisikoen og producerer de beviser, som en anmodning om øget gennemstrømning kræver.

Vigtigt!

Anmodninger om øget gennemstrømning vurderes i forhold til observeret brug. Forventede mængder, estimater produceret under design, små brugeraccepttests (UAT) og syntetiske belastningstests accepteres ikke som begrundelse i sig selv. Kør en pilotfase og indsend de målte resultater.

Den reelle brug adskiller sig rutinemæssigt fra estimaterne før lanceringen. Sessionslængde, beskeder pr. session, hvor ofte brugere når generative svar eller handlinger, retry-adfærd og antallet af flow-, connector-, Dataverse- og eksterne API-kald pr. tur er alle svære at forudsige, før agenten er i hænderne på rigtige brugere. En pilot fremhæver de grænser, der betyder noget, og de trafikmønstre, der er svære at vurdere på forhånd.

Udform et effektivt pilotprojekt

Pilotattribut Vejledning
Publikum Frigiv til en stor, repræsentativ del af den tiltænkte målgruppe frem for et projekt eller testteam. Pilotgruppen bør inkludere de roller, regioner og anvendelsestilfælde, der forventes i fuld skala.
Duration Kør i mindst en uge, så piloten dækker en komplet forretningscyklus, inklusive kendte spidsbelastningsperioder som vagtskift, månedsbehandling, kampagnetimer eller planlagte autonome kørsler.
Konfiguration Behold produktionskørselsbanen: de samme kanaler, emner, generativ AI-konfiguration, videnskilder, handlinger, flows, connectors og downstream-systemer, som den fulde udrulning bruger. Trafik målt mod et reduceret design ekstrapolerer ikke pålideligt.
Telemetri Tænd for analyse, Application Insights og administrationscenterrapportering, som du har brug for, før piloten begynder, så sessioner, beskeder, generative AI-opkald og fejl registreres for hele perioden.

Mål under pilotfasen

Indfang de værdier, der direkte matcher de offentliggjorte hastighedsgrænser:

  • Beskeder per minut og i timen, i gennemsnit og på spidsbelastning.
  • Sessioner, samtidige sessioner, sessionernes længde og beskeder pr. session.
  • Generative AI-kald pr. tur og pr. session, inklusive generative svar, agenthandlinger og værktøjer.
  • Power Automate-handlinger, connector-opkald og Dataverse-anmodninger genereret pr. agent-tur.
  • Throttlinghændelser, fejl ved brugsgrænser, genforsøg og latenstid under pilotens spidsbelastningsperioder.
  • Pilotpublikummet, udtrykt som en andel af det fulde tiltænkte publikum.

Ekstrapoler til fuld kapacitet

Skalér de observerede topmålinger til hele publikum, og dokumenter den metode, du har brugt. Basér skaleringen på spidsbelastningen under piloten, ikke på daglige eller ugentlige gennemsnit, fordi begrænsning skyldes koncentreret trafik. Tag højde for alt, piloten ikke inkluderede, såsom ekstra regioner, kanaler, autonome arbejdsbelastninger eller en lanceringskampagne, der koncentrerer trafikken mere end pilotperioden gjorde.

Resultatet er en evidensbaseret anmodning: målt pilottrafik, pilotens andel af publikum, ekstrapolationsmetoden og det resulterende spidsbelastningsbehov i fuld skala.

Hvad skal du gøre, hvis standardsatsgrænserne ikke er nok

Hvis observeret pilottrafik viser, at agenten eller en tilsluttet tjeneste overstiger de nuværende offentliggjorte grænser i fuld skala, skal du starte processen med at støtte til rate provisioning, før du udvider udrulningen. Vent ikke på den første produktionsfejl.

Bemærkning

Copilot Studio er en SaaS-tjeneste med takstgrænser for at beskytte tjenesten for alle kunder. Med korrekt begrundelse kan tekniker aktivere brugerdefinerede grænser for godkendte scenarier. Korrekt begrundelse betyder målt brug fra en pilotfase, ikke en fremskrivning.

Åbn en supportanmodning

Administratorer kan anmode om support fra Power Platform Administration.

Åbn billetten efter pilotfasen og inkluder de målte resultater sammen med ekstrapolationen til fuld kapacitet. Anmodninger, der kun indeholder designtidsestimater eller små UAT-resultater, kan ikke gennemgås og forsinker stigningen. Jo mere målt detaljer du giver, desto hurtigere bliver gennemgangen. Opdater anmodningen, efterhånden som udrulningen udvides, og yderligere telemetri bliver tilgængelig.

Kerneoplysninger, der skal inkluderes

Oplysninger Beskrivelse
Miljø-id Det Dataverse-miljø, hvor agenten kører.
Agentnavn eller -id Den agent, der er berørt af anmodningen.
Forretningspåvirkning Kritisk indvirkning, hvis standardgrænserne ikke er nok.
Kendte oplysninger Hvad er kendt om scenariet, kanalen, startkonteksten, forretningskritiskhed, og om det er B2C, autonomt, medarbejderorienteret eller kun internt.
Øjebliksbillede af agent Et snapshot eller en eksport, der hjælper korrekturlæsere med at forstå agentkonfiguration, design, forbundne tjenester og relevante indstillinger.
Design af agent Beskrivelse af emner på højt niveau, generativ brug af kunstig intelligens, videnkilder, handlinger, flow, connectors, Dataverse-kald og eksterne API'er, der bruges af agenten.
Pilotoversigt Pilotdatoer og varighed, størrelsen af pilotpublikummet og dette publikum som andel af det fulde tiltænkte publikum.
Observeret gennemsnitlig trafik Målte gennemsnitlig trafik fra piloten pr. minut, time og dag.
Observeret spidstrafik Målte peak-beskeder, sessioner, generative AI-kald, flow-handlinger, connector-kald, Dataverse-anmodninger og eksterne API-kald under pilotens peak-vinduer.
Ekstrapoleret topkravet Peak-kravet ved fuld publikumsstørrelse, med ekstrapolationsmetoden og eventuelle antagelser, du har anvendt.

Flere oplysninger, der kan hjælpe

Oplysninger Beskrivelse
Datointerval Start- og slutdato for den ønskede forøgelse. Angiv separate datointervaller for belastningstest, brugeraccepttest og produktion, hvis de adskiller sig.
Spidsbelastningsmønster Spidsbelastningsperioder, tidszoner, forventede årsager til spidsbelastning og om trafikken er koncentreret i et kort dagligt tidsrum.
Sessionsprofil Samtidige sessioner, gennemsnitlig og spidsbelastningssessionslængde, meddelelser pr. session og spørgsmål pr. session.
Typiske sessionseksempler Repræsentative brugerstier, typiske trin, der udføres, anvendte værktøjer og eksempelsessions-id'er, hvor det er tilgængeligt.
Kørselssti Flow, handlinger, AI-prompts, videnskald, Dataverse-anmodninger, connectors og API'er pr. interaktion.
Spidsbelastninger på funktionsniveau Spidsbelastning pr. agent, funktion, bruger, miljø, connector, minut, time og dag, hvor det er kendt.
Produkter, der skal gennemses Uanset om anmodningen omfatter Copilot Studio, allokeringer af Power Platform-anmodninger, Power Automate, connectors, Dataverse, CLU/AI-tjenester eller eksterne API'er.
Beviser Pilottelemetri, prøvesession-ID'er, fejl, korrelations-ID'er, logfiler, throttling-hændelser og produktionsobservationer. Load test-resultater kan supplere pilottelemetri, men erstatte det ikke.
Afhjælpninger Opsummer det, du allerede har forsøgt at reducere gennemløbstrykket. Se Design for at reducere gennemløbsbelastningsvejledningen , herunder designgennemgang, optimerede eksterne kald, miljøsegmentering, batching, kø, udløserfiltrering, planlægning, arbejdsbelastningsdistribution og andre optimeringer, der allerede er på plads.

Vigtigt!

En forøgelse af gennemløb garanteres ikke. Microsoft Support gennemgår anmodninger baseret på scenarie, miljø, anmodede datointerval, observeret pilottrafik, berettigelse, aktuelle grænser og servicekapacitet.

  • Last updated on