Copilot Studio-Agent-Bereitstellungen für Durchsatz- und Ratenbegrenzungen planen

Produktionsbereite Copilot Studio-Agenten benötigen mehr als nur die Lizenzierung und die Planung des gesamten Nachrichtenvolumens. Sie benötigen auch die Durchsatzplanung. Die Durchsatzplanung deckt ab, wie schnell Datenverkehr eingeht, welche Plattformdienste die Lösung aufruft und welche Grenzwerte für die gesamte Lösung gelten.

Dieser Artikel hilft Lösungsarchitekten, Erstellenden und Power Platform-Admins bei der Vorbereitung von Copilot Studio-Bereitstellungen für Produktionsdatenverkehr, Benutzerakzeptanztests (UAT), Auslastungstests, Business-to-Customer(B2C)-Szenarien und autonome Workloads.

Die Tarifbereitstellung ist von der Lizenzbereitstellung getrennt.

Die Planung für die Copilot-Studio-Produktion umfasst zwei zusammenhängende, aber separate Arbeitsstränge:

  • Die Lizenzbereitstellung umfasst kommerzielle Nutzungsrechte und Verbrauch, z. B. Lizenzen, Guthaben, Prepaid-Kapazität, Nachrichtenpakete und nutzungsbasierte Abrechnung.
  • Die Bereitstellung der Verarbeitungsrate bezieht sich darauf, wie schnell Datenverkehr verarbeitet werden kann, bevor Drosselungs- oder Dienstschutzmechanismen greifen.

Note

Microsoft verwendet den Begriff quotas für Copilot Studio Ratengrenzwerte. In einem breiteren Branchenvokabular wird diese Planungsaktivität häufig als Rate-Bereitstellung bezeichnet. Überprüfen Sie die veröffentlichten Grenzwerte, schätzen Sie spitzen Anforderungsraten und planen Sie, bevor der Produktionsverkehr eintrifft.

Pay-as-you-go kann die verfügbaren Grenzwerte im Vergleich zu Konfigurationen mit niedrigerer Kapazität erhöhen, der Durchsatz ist jedoch nicht unendlich. Überprüfen Sie die aktuellen Copilot Studio Grenzwerte, Power Platform-Anforderungszuweisungen, Power Automate Grenzwerte, Grenzwerte für den Dataverse-Dienstschutz, Connectoreinschränkungsregeln und downstream-API-Grenzwerte.

Was passiert, wenn gedrosselt wird?

Die Drosselung ist ein Dienstschutzverhalten. Es schützt gemeinsam genutzte Dienste vor Verkehrsmustern, die veröffentlichte Grenzwerte, Burstkontrollen oder die Kapazität des Dienstes überschreiten. Das genaue Symptom hängt davon ab, welcher Dienst gedrosselt wird.

Wenn eine Grenze erreicht wird, ist die Folge mehr als ein Planungsproblem. Anfragen können gedrosselt, verzögert, blockiert oder abgelehnt werden. In benutzerorientierten Chats kann dieses Verhalten als vorübergehende Dienstunterbrechung angezeigt werden. Beispielsweise kann der Benutzer die nächste Nachricht möglicherweise nicht senden, eine agent-nicht verfügbare oder nutzungslimit-Nachricht empfangen oder einen fehlgeschlagenen Schritt erleben, da ein Fluss, Connector, Dataverse-Aufruf, AI-Dienst oder downstream-API seinen Grenzwert erreicht hat.

Erfahren Sie mehr über Copilot Studio-spezifische Symptome und Fehlermeldungen unter Beheben von Fehlern aufgrund von Nutzungsbeschränkungen bei Agents.

Messung der Geschwindigkeitsgrenzwerte

Ratenbegrenzungen messen, wie viel Datenverkehr ein Dienst innerhalb eines bestimmten Zeitfensters akzeptieren kann. Überlegen Sie sich diese Fenster präzise: pro Minute, pro fünf Minuten, pro 10 Minuten, pro Stunde, pro Tag, pro Woche und pro Monat. Das monatliche oder wöchentliche Volumen hilft dabei, die Gesamtnachfrage abzuschätzen, aber für die Bereitstellung der Rate sind kürzere Zeitfenster wichtig, weil Drosselung häufig durch gebündelten Datenverkehr verursacht wird.

Beispielsweise kann ein B2C-Unternehmen während einer fokussierten Kampagnenstunde den größten Teil des Agent-Datenverkehrs erhalten. Der wöchentliche Durchschnitt könnte niedrig aussehen, aber diese einzelne Stunde kann dennoch genügend Durchsatzdruck erzeugen, um Drosselungen oder Dienstunterbrechungen zu verursachen. Ein Design, das auf der wöchentlichen oder monatlichen Ebene sicher aussieht, kann während eines einstündigen Höchstwerts weiterhin Grenzwerte überschreiten.

Verstehen des Umfangs von Grenzwerten

Grenzwerte gelten nicht nur auf der Ebene einzelner Agenten. Je nach Dienst können sie auf Umgebungs-, Tool-, API-, Connector-, Kanalebene oder auf der Ebene des nachgelagerten Dienstes angewendet werden.

Beispielsweise gelten die Grenzwerte für Nachrichten an Agents in Copilot Studio pro Dataverse-Umgebung. Wenn Sie den Datenverkehr schätzen, schließen Sie alle Quellen ein, die Nachrichten an Agents in dieser Umgebung senden, einschließlich benutzerorientierter Kanäle, Integrationen, autonomer Workloads und Azure Bot Framework-Fähigkeiten. Überprüfen Sie die aktuellen Werte und den Bereich in Copilot Studio Kontingenten und Grenzwerten.

Entscheiden Sie, ob die Provisionierungstarife für Ihren Agenten gelten.

Nicht jeder Agent benötigt großen Aufwand für die Ratenbereitstellung. Ein einfacher interner FAQ-Agent mit kleinem Nutzerkreis, vorhersehbarer Nutzung und wenigen oder keinen nachgelagerten Aufrufen wird die Ratenbegrenzung voraussichtlich nicht erreichen. Die Ratenbereitstellung gewinnt an Bedeutung, wenn ein Agent die Grenzwerte für Anfragen pro Minute oder pro Stunde überschreiten könnte, selbst wenn sein monatliches Volumen gering erscheint.

Denken Sie früh im Projekt über den erwarteten Datenverkehr nach, neben dem Lösungsdesign. Bevor Benutzerakzeptanztests (UAT) und Lasttests beginnen, sollte das Team sicher sein, dass das Agent-Design, die Umgebung, verbundene Dienste und downstream-Systeme das erwartete Durchsatzprofil unterstützen können.

Diese Hinweise sind besonders wichtig für größere, leistungsintensivere Agenten auf Enterprise-Niveau, bei denen der Datenverkehr stoßweise auftreten kann, viele Benutzer oder Ereignisse den Agenten gleichzeitig auslösen können oder jede Interaktion von mehreren Plattformdiensten abhängt. Sie kann auch auf kleinere Agents mit konzentrierten Verwendungsmustern angewendet werden, z. B. ein kurzes Startfenster, ein abteilungsweites Ereignis, einen geplanten Prozess oder einen Workflow, der viele Anforderungen in wenigen Minuten erstellt.

B2C und autonome Agenten erfordern eine frühe Tarifbereitstellung

Kundenorientierte B2C-Agents können Anfragen aus Kampagnen, öffentlichen Websites, Kundenportalen, der Kommunikation zu Vorfällen, Produkteinführungen oder aufgrund saisonaler Nachfrage erhalten. Autonome Agents können hochfrequenten Datenverkehr anhand von Zeitplänen, Ereignissen oder Hintergrundprozessen erzeugen oder wenn sie mehrere Tools und Workflows aufrufen.

Tip

Behandeln Sie B2C- und autonome Anwendungsfälle als erstklassige Szenarien für die Tarifbereitstellung. Sie können sprunghaften Datenverkehr, mehrere gleichzeitige Anfragen und hochfrequente Hintergrundaktivitäten schneller erzeugen als viele Chat-Erlebnisse für Mitarbeitende.

Verwenden Sie Spitzenzeitfenster, nicht nur Monatssummen

Fragen Sie, ob der Agent konzentrierte Anforderungen in einer Minute oder Stunde erstellen kann. Ein kleineres Szenario kann weiterhin eine Ratebereitstellung benötigen, wenn ein Auslastungstest, eine Kampagne, eine Ausfallantwort oder ein automatisierter Trigger zu viele Nachrichten, generative KI-Aufrufe, Workflowaktionen, Connectoranrufe oder Dataverse-Anforderungen über die Umgebung in einem kurzen Fenster überträgt.

Das monatliche Volumen ist nützlich, um die Gesamtnachfrage zu schätzen, aber es reicht nicht für die Bereitstellung von Tarifen aus. Konvertieren Sie die erwartete Nutzung in kleinere Zeitfenster, damit Sie das Design mit aktuellen Anforderungen pro Minute (RPM), Anforderungen pro Stunde (RPH), Burst und täglichen Grenzwerten von den verknüpften Seiten vergleichen können.

Erstellen Sie sowohl ein durchschnittliches Datenverkehrsprofil als auch ein Spitzendatenverkehrsprofil. Wenn beispielsweise der größte Datenverkehr jeden Tag zwischen 17 und 18 Uhr stattfindet, sollte der stündliche Spitzenwert diese Konzentration widerspiegeln. Die Tagesschätzung muss nicht dem 24-Fachen der Spitzenstunde entsprechen, wenn sich das Verkehrsaufkommen in einem einzigen Zeitfenster konzentriert.

Nutzen Sie diese Schätzungen, um das Design zu bewerten und zu validieren. Schätzungen sind keine ausreichende Begründung für eine Erhöhung des Durchsatzes. Anfragen werden anhand des während einer Pilotphase beobachteten Datenverkehrs geprüft, wie in Vor dem Beantragen einer Erhöhung des Durchsatzes eine Pilotphase durchführen beschrieben.

Wann kann sonst eine Drosselung stattfinden?

Drosselung kann auch auftreten, wenn:

  • Eine große Mitarbeiterpopulation verwendet den Agent während eines vorhersagbaren Spitzenfensters, z. B. einer abteilungsweiten Veranstaltung oder Schulung.
  • Eine Marketingkampagne, ein Ausfall, eine Produkteinführung oder ein geplantes geschäftliches Ereignis verursacht einen kurzen Anstieg des Datenverkehrs.
  • Power Automate-Flows umfassen Schleifen, Wiederholungen, Paginierung oder untergeordnete Flows, die das Anforderungsvolumen erhöhen.
  • Berichterstellung, Überwachung, Telemetrieexport oder Transkripterfassung werden synchron im Pfad der Benutzerinteraktion ausgeführt.
  • Mehrere Agents oder Workloads nutzen dieselbe Umgebung, Identität, Connector oder downstream-API-Kapazität.
  • Lasttests steigen schneller an, als die Produktionsarchitektur oder der Supportprozess darauf vorbereitet sind.

Wo relevante Zinsgrenzwerte nachschlagen

Copilot Studio hat eigene Grenzwerte, und der Laufzeitpfad des Agents kann andere Dienste mit ihren eigenen Grenzwerten enthalten. Überprüfen Sie alle relevanten Grenzwerte für die Dienste, die Ihr Agent verwendet.

Copilot Studio Grenzwerte

Tarifbereitstellungsbereich Wonach gesucht werden soll Wo die aktuellen Werte überprüft werden sollen So verwenden Sie es
Nachrichten an einen Agent Aktuelle RPM- und RPH-Grenzen sowie Umfang der an den Agenten gesendeten Nachrichten. Copilot Studio-Kontingente und -Grenzwerte Vergleichen Sie die erwarteten Nachrichten pro Minute und Stunde für die Dataverse-Zielumgebung.
KI-generierte Nachrichten Aktueller Grenzwert für generative Orchestrierung, Agentaktionen, KI-Tools, Agent-Workflowaktionen und generative Antworten. Generative KI-Nachrichten an einen Agent Modellieren Sie KI-schwere und autonome Szenarien mit den aktuellen veröffentlichten Grenzwerten.
Autonome Triggerknoten Aktuelle Grenzwerte, die gelten, wenn ein autonomer Agent durch Ereignisse, Zeitpläne oder Hintergrundprozesse ausgelöst wird. Copilot Studio-Kontingente und -Grenzwerte Modelliere ereignisgesteuerte und geplante Workloads getrennt vom interaktiven Chatdatenverkehr.
Copilot Studio Grenzwerte für Abonnementanfragen Aktuelle Power Platform-Anforderungsbeschränkungen, die für Copilot Studio Nutzung gelten. Copilot Studio-Abonnementbeschränkungen Verwenden Sie diese Werte neben der Zinslimitplanung für Flüsse, Dataverse und verbundene Dienste.

Andere Zu berücksichtigende Plattformbeschränkungen

Der niedrigste Grenzwert im Laufzeitpfad bestimmt die Benutzererfahrung. Ein Copilot Studio-Agent kann innerhalb seiner eigenen Grenzwerte liegen, während ein Flow, Connector, Dataverse-Aufruf, Sprachdienst oder eine externe API gedrosselt wird.

Note

Andere Plattformgrenzwerte wirken sich möglicherweise auf Ihren Agent aus, wenn er andere Komponenten im Agent-Anforderungspfad verwendet. Berücksichtigen Sie diese Grenzwerte auch, einschließlich Power Platform, Power Automate, Dataverse, Connectors, Sprachdienste und downstream-Systeme.

Laufzeitbereich Was sie sich ansehen sollten Fragen zur Ratenbereitstellung Wo die aktuellen Grenzwerte überprüft werden sollen
Power Platform-Anforderungsebene Anforderungen in Power Automate, Copilot Studio-Workflowaufrufen, bei der Dataverse-Nutzung, Power Apps und Dynamics 365. Welcher Benutzer, Verbindung, Anwendungsbenutzer oder Dienstprinzipal generiert die Anforderungen? Reichen Anforderungszuweisungen für die erwartete Tages- und Höchstlast aus? Anforderungslimits und -zuteilungen
Power Automate-Flows Trigger, Aktionen, Schleifen, untergeordnete Flows, HTTP-Aktionen, Konnektoraktionen, Wiederholungen, Paginierung und Parallelität. Wie viele Aktionen werden pro Zug eines Agenten erstellt? Sind Burst-, Parallelitäts-, Trigger- und Connector-Grenzwerte im Geltungsbereich enthalten? Plattformgrenzen verstehen und Drosselung vermeiden
Grenzwerte für automatisierte, geplante und sofortige Abläufe
Dataverse CRUD-Vorgänge, Plug-Ins, Workflows, Zuordnungs-/Freigabevorgänge, Connectoraufrufe und Systemvorgänge, die zum Abschließen von Transaktionen erforderlich sind. Welche Benutzer, Anwendungsbenutzer oder Dienstprinzipale generieren Dataverse-Aufrufe? Ist es wahrscheinlich, dass Dienstschutzlimits oder Wiederholversuche zur Anwendung kommen? API-Grenzwerte für den Serviceschutz
Dataverse API-Grenzwerte – Übersicht
Connectors Standardkonnektoren, Premiumkonnektoren, benutzerdefinierte Konnektoren, konnektorspezifische Drosselung und nachgelagerte APIs. Welcher Verbinder ist der Engpass? Erzwingt der nachgeschaltete Dienst seine eigene Rategrenze? API-Durchsatzgrenzwerte für Connectors
Power Automate-Connector-Referenz
Konversations-Sprachverständnis (CLU) und KI-Dienste CLU-Aufrufe, KI-Eingabeaufforderungen, Such- und Zusammenfassungsvorgänge, modellgestützte Tools, Nutzlastgröße und dienstspezifische Grenzwerte. Wird bei jeder Benutzereingabe ein Sprach- oder KI-Dienst aufgerufen? Werden diese Aufrufe bei Wiederholungsversuchen oder während der Orchestrierung wiederholt? Grenzen des konversationellen Sprachverstehens
Copilot Studio-Kontingente und -Grenzwerte
Externe APIs und Branchensysteme Anbieter-APIs, interne APIs, Datenbanken, Middleware, Gateways und benutzerdefinierte Dienste. Welche Beschränkung setzt der nachgelagerte Eigentümer durch? Gibt es eine Strategie für Wiederholungsmechanismen, Warteschlangen oder Gegendruck? Verwenden Sie die aktuellen Beschränkungen, die Service-Level-Vereinbarung (SLA) und den Supportprozess des Eigentümers des nachgelagerten Dienstes.

Entwurf zur Reduzierung des Durchsatzdrucks

Machen Sie Ratenerhöhungen nicht zu Ihrer ersten Designreaktion. Überprüfen Sie zunächst das Agent-Design und optimieren Sie die Effizienz. Wenn der Agent etwas nachschlagen muss, halten Sie externe Aufrufe absichtlich, optimieren Sie API-Aufrufe, und vermeiden Sie unnötiges Anforderungsvolumen über Copilot Studio, Power Automate, Dataverse, Connectors und downstream-Systeme.

Nachdem das Design effizient ist, steuern Sie den Durchsatz, damit der Datenverkehr die Plattform auf vorhersehbare Weise erreicht:

  • Erwägen Sie bei Grenzwerten auf Umgebungsebene die Aufteilung von Agents auf mehrere Umgebungen, wenn dieser Ansatz Ihrem betriebstechnischen Entwurf entspricht. Dieser Ansatz kann dazu beitragen, zu verhindern, dass Agenten mit hohem Volumen, Geschäftseinheiten, Regionen oder autonome Workloads mit nicht zusammenhängenden Workloads um dieselben umgebungsspezifischen Grenzwerte konkurrieren.
  • Verwenden Sie für autonome Agents Warteschlangen, Stapelverarbeitung, Triggerfilter, geplante Verarbeitung, Steuerung von Wiederholversuchen und Überwachung, damit Hintergrundarbeit nicht als unkontrollierte Lastspitze anfällt.
  • Verschieben Sie geplante Aufgaben, Berichtserstellung, Audit-Exporte und Telemetriearbeiten nach Möglichkeit außerhalb des Pfads des interaktiven Chats.
  • Überprüfen Sie die Ergebnisse von Lasttests und die Produktionstelemetrie, um zu ermitteln, wo sich Anfragen konzentrieren, und optimieren Sie dann den Agenten, Flows, Konnektoren und nachgelagerte APIs, bevor Sie höhere Limits anfordern.

Autonome Agenten sind besonders gut geeignet, die Nutzung ihrer zugewiesenen Kapazität mit hoher Vorhersagbarkeit und Beobachtbarkeit zu maximieren, indem sie Anfragen in Warteschlangen einreihen und die Rate ihrer Auslösung steuern.

Führen Sie eine Pilotphase durch, bevor Sie eine Durchsatzerhöhung anfordern

Die Standardlimits reichen für die meisten Produktionsagenten aus, einschließlich Agenten, die Tausende monatlich aktiver Nutzer bedienen. Bevor Sie eine Erhöhung des Durchsatzes planen, stellen Sie sicher, dass der Agent tatsächlich eine benötigt.

Der direkte Start in vollem Maßstab ist kein unterstütztes Rollout-Muster. Geben Sie den Agent zunächst an eine Teilmenge der Zielgruppe frei, beobachten Sie die tatsächliche Nutzung und nutzen Sie diese Messungen, um den vollständigen Rollout zu planen. Eine Pilotphase reduziert sowohl das Startrisiko als auch liefert die Beweise, die eine Durchsatzerhöhungsanforderung erfordert.

Important

Anfragen zur Erhöhung des Durchsatzes werden auf Grundlage der beobachteten Nutzung geprüft. Prognostizierte Volumen, während der Konstruktion erstellte Schätzungen, Small User Acceptance Testing (UAT)-Läufe und synthetische Lasttests werden für sich genommen nicht als Rechtfertigung akzeptiert. Führen Sie eine Pilotphase durch und reichen Sie die gemessenen Ergebnisse ein.

Die tatsächliche Nutzung unterscheidet sich routinemäßig von den Vorstartschätzungen. Sitzungslänge, Nachrichten pro Sitzung, wie oft Nutzer generative Antworten oder Aktionen erreichen, das Wiederholungsverhalten sowie die Anzahl der Flow-, Connector-, Dataverse- und externen API-Aufrufe pro Runde sind alle schwer vorherzusagen, bevor der Agent in den Händen echter Nutzer ist. Ein Pilot zeigt die wichtigen Grenzen und die Verkehrsmuster, die schwer im Voraus abzuschätzen sind, auf.

Entwerfen Sie einen effektiven Piloten

Pilotenattribut Leitlinien
Publikum Veröffentlichen Sie es an einen großen, repräsentativen Teil der Zielgruppe und nicht an ein Projekt oder Testteam. Die Pilotgruppe sollte die Rollen, Regionen und Anwendungsfälle umfassen, die im vollen Maßstab erwartet werden.
Dauer Lassen Sie den Pilotbetrieb mindestens eine Woche lang laufen, damit der Pilot einen vollständigen Geschäftszyklus abdeckt, einschließlich bekannter Spitzenzeiten wie Schichtwechsel, Monatsendverarbeitung, Kampagnenzeiten oder geplanter autonomer Läufe.
Konfiguration Behalte den Produktionslaufzeitpfad: dieselben Kanäle, Themen, generative KI-Konfiguration, Wissensquellen, Aktionen, Flows, Connectors und Downstream-Systeme, die der vollständige Rollout verwendet. Datenverkehr, der anhand eines reduzierten Designs gemessen wird, lässt sich nicht zuverlässig extrapolieren.
Telemetry Aktivieren Sie vor Beginn des Pilotprojekts die benötigten Analysen, Anwendungseinblicke und Admin-Center-Berichte, damit Sitzungen, Nachrichten, generative KI-Anrufe und Fehler während des gesamten Zeitraums erfasst werden.

Messung während des Pilotprojekts

Erfassen Sie die Werte, die direkt den veröffentlichten Ratenbegrenzungen entsprechen:

  • Nachrichten pro Minute und pro Stunde, im Durchschnitt und in der Spitzenzeit.
  • Sitzungen, gleichzeitige Sitzungen, Sitzungslänge und Nachrichten pro Sitzung.
  • Generative KI-Aufrufe pro Runde und pro Sitzung, einschließlich generativer Antworten, Agentenaktionen und Werkzeuge.
  • Power Automate-Aktionen, Connector-Anrufe und Dataverse-Anfragen, die pro Agenten-Runde generiert werden.
  • Drosselungsereignisse, Fehler aufgrund von Nutzungslimits, Wiederholungsversuche und Latenz während der Spitzenzeiten des Pilotprojekts.
  • Die Größe des Pilotpublikums, ausgedrückt als Anteil an der gesamten Zielgruppe.

Extrapolieren Sie auf volle Kapazität

Skalieren Sie die beobachteten Peak-Messungen auf das gesamte Publikum und dokumentieren Sie die verwendete Methode. Richten Sie die Skalierung nach der Spitzenlast während der Pilotphase aus, nicht nach Tages- oder Wochendurchschnitten, da die Drosselung durch konzentriertes Verkehrsaufkommen verursacht wird. Berücksichtigen Sie alles, was der Pilot nicht beinhaltete, wie zusätzliche Regionen, Kanäle, autonome Arbeitslasten oder eine Startkampagne, die den Verkehr stärker konzentriert als die Pilotphase.

Das Ergebnis ist eine evidenzbasierte Anfrage: gemessener Pilotverkehr, der Anteil des Piloten an der Zielgruppe, die Extrapolationsmethode und die daraus resultierende Spitzenanforderung im vollen Maßstab.

Was ist zu tun, wenn die Standardratenbeschränkungen nicht ausreichen?

Wenn beobachteter Pilotverkehr zeigt, dass der Agent oder ein verbundener Dienst die aktuellen veröffentlichten Grenzen im vollen Maßstab überschreitet, starten Sie den Unterstützungsprozess zur Tarifbereitstellung, bevor Sie den Rollout erweitern. Warten Sie nicht auf den ersten Produktionsfehler.

Note

Copilot Studio ist ein SaaS-Dienst mit Tarifbegrenzungen, um den Service für alle Kunden zu schützen. Mit der richtigen Begründung kann das Engineering benutzerdefinierte Grenzwerte für genehmigte Szenarien aktivieren. Eine angemessene Begründung bedeutet gemessene Nutzung aus einer Pilotphase, nicht eine Prognose.

Supportanfrage öffnen

Administratoren können Support über das Power Platform Admin Center anfordern.

Öffnen Sie das Ticket nach der Pilotphase und fügen Sie die gemessenen Ergebnisse zusammen mit der Extrapolation auf die volle Kapazität ein. Anfragen, die nur Designzeit-Schätzungen oder kleine UAT-Ergebnisse enthalten, können nicht überprüft werden und verzögern die Erhöhung. Je mehr Detailgenauigkeiten Sie liefern, desto schneller ist die Prüfung. Aktualisieren Sie die Anfrage, sobald der Rollout erweitert wird und weitere Telemetrie verfügbar wird.

Kerninformationen, die einbezogen werden sollen

Informationen Description
Umgebungs-ID Die Dataverse-Umgebung, in der der Agent ausgeführt wird.
Name oder Kennung des Agenten Der von der Anforderung betroffene Agent.
Geschäftliche Auswirkungen Kritische Auswirkungen, wenn die Standardgrenzwerte nicht ausreichen.
Bekannte Informationen Was ist über das Szenario, den Kanal, den Einführungskontext, die Geschäftskritikalität und darüber bekannt, ob es sich um B2C, autonom, mitarbeiterorientiert oder ausschließlich intern handelt.
Agent-Momentaufnahme Eine Momentaufnahme oder ein Export, die Prüfern hilft, die Agentkonfiguration, den Entwurf, die verbundenen Dienste und die relevanten Einstellungen zu verstehen.
Agentenentwurf Allgemeine Beschreibung von Themen, generative KI-Nutzung, Wissensquellen, Aktionen, Flüssen, Connectors, Dataverse-Aufrufen und externen APIs, die vom Agent verwendet werden.
Pilotzusammenfassung Pilotdaten und -dauer, die Größe des Pilotpublikums und dieses Publikum als Anteil an der gesamten beabsichtigten Zielgruppe.
Beobachteter Durchschnittsverkehr Der durchschnittliche Datenverkehr aus dem Pilotprojekt wurde pro Minute, Stunde und Tag gemessen.
Beobachteter Spitzenverkehr Gemessene Spitzenwerte bei Nachrichten, Sitzungen, Aufrufen generativer KI, Flow-Aktionen, Connector-Aufrufen, Dataverse-Anfragen und externen API-Aufrufen während der Spitzenzeiten des Pilotprojekts.
Extrapolierte Spitzenanforderung Die Spitzenanforderung bei voller Zielgruppe, mit der Extrapolationsmethode und allen Annahmen, die du angewandt hast.

Weitere Details, die Ihnen helfen können

Informationen Description
Datumsbereich Start- und Enddatum für die angeforderte Erhöhung. Geben Sie getrennte Datumsbereiche für Lasttest, Benutzerakzeptanztest und Produktion an, falls diese unterschiedlich sind.
Spitzenprofil Spitzenzeiten, Zeitzonen, erwartete Auslöser für Lastspitzen und ob sich der Datenverkehr auf ein kurzes tägliches Zeitfenster konzentriert.
Sitzungsprofil Gleichzeitige Sitzungen, durchschnittliche und Spitzensitzungslänge, Nachrichten pro Sitzung und Fragen pro Sitzung.
Typische Sitzungsbeispiele Repräsentative Benutzerpfade, typische Schritte, verwendete Tools und Beispielsitzungs-IDs, sofern verfügbar.
Laufzeitpfad Flüsse, Aktionen, KI-Prompts, Wissensabfragen, Dataverse-Anfragen, Konnektoren und APIs pro Interaktion.
Spitzen auf Merkmalsebene Spitzenvolumen pro Agent, Feature, Benutzer, Umgebung, Connector, Minute, Stunde und Tag, wo bekannt.
Produkte, die eine Überprüfung benötigen Ob die Anforderung Copilot Studio, Power Platform-Anforderungszuweisungen, Power Automate, Connectors, Dataverse, CLU/AI-Dienste oder externe APIs umfasst.
Evidence Pilot-Telemetrie, Sample-Session-IDs, Fehler, Korrelations-IDs, Logs, Drosselungsereignisse und Produktionsbeobachtungen. Lasttestergebnisse können die Pilot-Telemetrie ergänzen, aber nicht ersetzen.
Gegenmaßnahmen Fassen Sie zusammen, was Sie bereits unternommen haben, um den Druck auf den Durchsatz zu reduzieren. Verweisen Sie auf die Anleitung Entwurf zur Reduzierung des Durchsatzdrucks, einschließlich Designüberprüfung, optimierter externer Aufrufe, Umgebungssegmentierung, Batchverarbeitung, Warteschlangenverarbeitung, Triggerfilterung, Zeitplanung, Lastverteilung und anderer bereits implementierter Optimierungen.

Important

Eine Durchsatzerhöhung ist nicht garantiert. Microsoft-Support überprüft Anfragen basierend auf Szenario, Umgebung, beantragtem Datumsbereich, beobachtetem Pilotverkehr, Berechtigung, aktuellen Limits und Servicekapazität.

  • Zuletzt aktualisiert um