Leistung und Latenz

In diesem Artikel erfahren Sie, wie Latenz und Durchsatz mit Azure OpenAI funktionieren und wie Sie Ihre Umgebung optimieren, um die Leistung zu verbessern.

Grundlegendes zum Durchsatz im Vergleich zur Latenz

Bei der Größenanpassung einer Anwendung müssen zwei schlüsselbezogene Konzepte behandelt werden: (1) Systemebenendurchsatz, gemessen in Token pro Minute (TPM) und (2) Antwortzeiten pro Anruf (auch als Latenz bezeichnet).

Durchsatz auf Systemebene

Diese Metrik zeigt die Gesamtkapazität Ihrer Bereitstellung an – wie viele Anforderungen pro Minute und Gesamttoken, die verarbeitet werden können.

Bei einer Standardbereitstellung bestimmt das Ihrer Bereitstellung zugewiesene Kontingent teilweise den Durchsatz, den Sie erreichen können. Die Vorgabe bestimmt jedoch nur die Annahmelogik für Aufrufe an die Bereitstellung und erzwingt den Durchsatz nicht direkt. Aufgrund von Latenzvariationen pro Anruf können Sie möglicherweise nicht den Durchsatz so hoch wie Ihr Kontingent erreichen.

In einer bereitgestellten Bereitstellung weisen Sie Ihrem Endpunkt eine festgelegte Menge an Modellverarbeitungskapazität zu. Der Durchsatz, den Sie für den Endpunkt erzielen können, hängt vom Workload-Shape ab, einschließlich Eingabetokenbetrag, Ausgabebetrag, Anrufrate und Cache-Übereinstimmungsrate. Die Anzahl gleichzeitiger Aufrufe und verarbeiteter Gesamttoken kann je nach diesen Werten variieren.

Für alle Bereitstellungstypen ist das Verständnis des Systemebenendurchsatzes eine wichtige Komponente für die Leistungsoptimierung. Berücksichtigen Sie den Durchsatz auf Systemebene für ein bestimmtes Modell, eine Version und eine Workload-Kombination, da der Durchsatz je nach diesen Faktoren variiert.

Schätzen des Durchsatzes auf Systemebene

Schätzen von TPM mit Azure Monitor Metriken

Ein Ansatz zum Schätzen des Durchsatzes auf Systemebene für eine bestimmte Workload ist die Verwendung von historischen Tokennutzungsdaten. Für Azure OpenAI-Workloads können auf alle historischen Nutzungsdaten zugegriffen und mit den systemeigenen Überwachungsfunktionen in Azure OpenAI visualisiert werden. Es sind zwei Metriken erforderlich, um den Durchsatz auf Systemebene für Azure OpenAI-Workloads zu schätzen: (1) Processed Prompt Tokens und (2) Generated Completion Tokens.

In Kombination bieten die Metriken "Verarbeitete Eingabeaufforderungstoken " (Eingabe-TPM) und "Generierte Vervollständigungstoken " (Output TPM) eine geschätzte Ansicht des Durchsatzes auf Systemebene basierend auf dem tatsächlichen Workloaddatenverkehr. Da dieser Ansatz berücksichtigt nicht die Vorteile der Zwischenspeicherung von Prompts, ist die Schätzung des Systemdurchsatzes eher konservativ. Diese Metriken können mithilfe von Minimal-, Mittelwert- und maximaler Aggregation über 1-Minuten-Fenster über einen mehrwöchigen Zeithorizont analysiert werden. Es wird empfohlen, diese Daten über einen mehrwöchigen Zeithorizont zu analysieren, um sicherzustellen, dass genügend Datenpunkte zu bewerten sind. Der folgende Screenshot zeigt ein Beispiel für die Processed Prompt Tokens Metrik, die in Azure Monitor visualisiert wird, die direkt über das Azure Portal verfügbar ist.

Screenshot eines Azure Monitor Diagramms, das die Metrik "Verarbeitete Aufforderungstoken" nach Modell und Version darstellt.

Schätzen von TPM aus Anforderungsdaten

Ein zweiter Ansatz für den geschätzten Durchsatz auf Systemebene umfasst das Sammeln von Tokenverwendungsinformationen aus API-Anforderungsdaten. Diese Methode bietet einen differenzierteren Ansatz zum Verständnis des Workload-Shapes pro Anforderung. Die Kombination von Informationen zur Tokenverwendung pro Anforderungstoken mit Anforderungsvolumen, gemessen in Anforderungen pro Minute (RPM), liefert eine Schätzung für den Durchsatz auf Systemebene. Es ist wichtig zu beachten, dass alle Annahmen, die zur Konsistenz von Tokennutzungsinformationen bei Anfragen und dem Anforderungsvolumen getroffen werden, Auswirkungen auf die Schätzung des Systemdurchsatzes haben. Die Ausgabedaten für die Tokenverwendung finden Sie in den API-Antwortdetails für eine bestimmte Azure OpenAI in Microsoft Foundry Models Chat-Abschlussanforderung.

{
  "body": {
    "id": "chatcmpl-7R1nGnsXO8n4oi9UPz2f3UHdgAYMn",
    "created": 1686676106,
    "choices": [],
    "usage": {
      "completion_tokens": 557,
      "prompt_tokens": 33,
      "total_tokens": 590
    }
  }
}

Wenn alle Anfragen für eine bestimmte Workload gleichartig sind, multiplizieren Sie die Prompt-Token und Completion-Token aus den API-Antwortdaten mit der geschätzten RPM, um die Eingabe- und Ausgabe-TPM für die betreffende Workload zu ermitteln.

Verwendung von Durchsatzschätzungen auf Systemebene

Nachdem Sie den Durchsatz auf Systemebene für eine bestimmte Workload geschätzt haben, verwenden Sie diese Schätzungen zur Dimensionierung von Standard- und provisionierten Bereitstellungen. Kombinieren Sie für Standardbereitstellungen die TPM-Werte für Eingabe und Ausgabe, um das gesamte TPM zu schätzen, das einer bestimmten Bereitstellung zugewiesen werden soll. Verwenden Sie für provisionierte Bereitstellungen die Anforderungstokennutzungsdaten oder Eingabe- und Ausgabe-TPM-Werte, um die Anzahl der PTUs zu schätzen, die erforderlich sind, um eine bestimmte Workload mithilfe der Bereitstellungskapazitätsrechnererfahrung zu unterstützen.

Hier sind einige Beispiele für das GPT-4o-Minimodell:

Die Anzahl der PTUs skaliert ungefähr linear mit der Anrufrate, wenn die Workloadverteilung konstant bleibt.

Latenz: Die Antwortzeiten pro Anruf

Die allgemeine Definition der Latenz in diesem Kontext ist die Zeit, die benötigt wird, um eine Antwort vom Modell zurückzugeben. Für Abschluss- und Chatabschlussanforderungen hängt die Latenz weitgehend vom Modelltyp, der Anzahl der Token in der Eingabeaufforderung und der Anzahl der generierten Token ab. Im Allgemeinen fügt jedes Prompt-Token im Vergleich zu jedem schrittweise generierten Token kaum Zeit hinzu.

Mit der Beziehung TTLT = TTFT + (TBT × Tokens Generated) können Sie die erwartete tokengesteuerte Latenz von realen Regressionen trennen. Die vollständige Aufschlüsselung finden Sie unter Understanding Azure OpenAI latency.

Die Schätzung der erwarteten Latenz pro Anruf kann mit diesen Modellen eine Herausforderung darstellen. Die Latenz einer Abschlussanforderung kann je nach vier primären Faktoren variieren: (1) das Modell, (2) die Anzahl der Token in der Eingabeaufforderung, (3) die Anzahl der generierten Token und (4) die Gesamtlast für die Bereitstellung und das System. Die Faktoren 1 und 3 machen häufig den größten Teil der gesamten Zeit aus. Der nächste Abschnitt geht näher auf den Aufbau eines Inferenzaufrufs für ein großes Sprachmodell ein.

Das Verständnis von Azure OpenAI-Latenz

Azure OpenAI-Anforderungslatenz folgt einer vorhersehbaren Formel. Wenn Sie diese Formel kennen, können Sie die erwarteten, tokengesteuerten Antwortzeiten aus echten Leistungsregressionen erkennen.

Die Latenzformel

Die Gesamtzeit zum Generieren einer Antwort lautet:

TTLT = TTFT + (TBT × Token generiert)

Wo:

• TTFT (Time to First Token) ist die Zeit vom Absenden der Eingabeaufforderung bis zur Rückgabe des ersten Tokens, gemessen in Millisekunden.
• TBT (Time Between Tokens) ist die durchschnittliche Zeit zwischen aufeinander folgenden generierten Token in Millisekunden.
• Generierte Token sind die Gesamtzahl der Ausgabetoken für die Antwort.
• TTLT (Time to Last Token) ist die End-to-End-Antwortzeitspanne.

Da TTLT mit der Anzahl der generierten Token skaliert wird, wird eine Erhöhung der TTLT häufig vollständig durch eine Erhöhung der Ausgabetoken erklärt – nicht durch ein Systemleistungsproblem. Überprüfen Sie immer die Tokenanzahl, bevor Sie schließen, dass eine Latenzregression vorhanden ist.

Wichtige Latenzmetriken

Verwenden Sie diese Azure Monitor Metriken, um die Latenz zu untersuchen, unabhängig davon, ob Sie Antworten streamen:

Kombinieren Sie immer eine Latenzmetrik mit einer Token-Zähl-Metrik. Eine 5-Sekunden-TTLT, die 2.000 Token generiert, unterscheidet sich sehr von einem 5-Sekunden-TTLT, der 50 Token generiert. Latenz ohne Tokenkontext ist nicht verwertbar.

Den vollständigen Metrikkatalog, einschließlich Dimensionen und Aggregationsanleitungen, finden Sie unter Azure OpenAI-Überwachungsdatenreferenz.

Bewerten Sie Ihre Latenz in 10 Minuten

Verwenden Sie den Pfad, der Ihrer Workload entspricht, um zu beurteilen, ob die Bereitstellungslatenz erwartungsgemäß funktioniert. Beide Pfade verwenden Azure Monitor Metriken aus der Tabelle Key-Latenz-Metriken.

Nicht-Streaming-Workloads

1. Öffnen Sie im Azure-Portal Ihre Azure OpenAI-Ressource, und wählen Sie dann Monitoring>Metrics aus.

2. Fügen Sie Time-to-Last-Byte (AzureOpenAITTLTInMS) hinzu und teilen Sie ModelDeploymentName auf, um das Verhalten pro Bereitstellung zu isolieren.

3. Fügen Sie ein zweites Diagramm für generierte Vervollständigungstoken (GeneratedTokens) im gleichen Zeitraum hinzu.

4. Vergleichen Sie die beiden Diagramme:

   • Wenn TTLT und generierte Token zusammen steigen, wird die Latenzänderung durch tokenvolume erklärt. Dieses Muster wird erwartet, kein Regressionsverhalten.
   • Wenn TTLT steigt, ohne dass die Tokenanzahl erhöht wurde, prüfen Sie auf Kapazitätsdruck. Bei PTU-verwalteten Bereitstellungen wird das Diagramm Bereitgestellte verwaltete Nutzung V2 (AzureOpenAIProvisionedManagedUtilizationV2) verwendet. Prüfen Sie bei Pay-As-You-Go-Bereitstellungen Azure OpenAI-Anforderungen (AzureOpenAIRequests) auf Fehler 429 bei Drosselung und parallelem Anforderungsvolumen.

Streamingworkloads

1. Öffnen Sie im Azure-Portal Ihre Azure OpenAI-Ressource, und wählen Sie dann Monitoring>Metrics aus.

2. Fügen Sie Time-to-Response (AzureOpenAITimeToResponse) hinzu und teilen Sie ModelDeploymentName für die Latenz des ersten Tokens auf.

3. Um den Durchsatz pro Token zu messen, fügen Sie Zeit zwischen Token (AzureOpenAINormalizedTBTInMS) hinzu.

4. Verarbeitete Eingabeaufforderungstoken hinzufügen (ProcessedPromptTokens). Größere Prompts erhöhen TTFT.

5. Vergleichen Sie die Diagramme:

   • Wenn die Antwortzeit steigt, während die Größe der Aufforderung flach bleibt, überprüfen Sie die Bereitstellungsauslastung und das gleichzeitige Anforderungsvolumen.
   • Wenn „Time-Between-Tokens“ steigt, steht die Bereitstellung wahrscheinlich unter Last.

Wenn beobachtete Werte unerwartet wirken, stecken Sie sie zurück in die Latenzformel, um eine Plausibilitätsprüfung durchzuführen, bevor Sie einen Supportfall öffnen.

Verbessern der Leistung

Mehrere Faktoren können die Latenz pro Anruf Ihrer Anwendung verbessern.

Modellauswahl

Die Latenz variiert je nach dem verwendeten Modell. Für eine identische Anforderung erwarten Sie, dass unterschiedliche Modelle unterschiedliche Latenzen für den Chatabschlussanruf aufweisen. Wenn Für Ihren Anwendungsfall die niedrigsten Latenzmodelle mit den schnellsten Reaktionszeiten erforderlich sind, empfehlen wir das neueste GPT-4o-Minimodell.

Generationsgrößen und maximale Tokenanzahl

Wenn Sie eine Abschlussanforderung an den Azure OpenAI-Endpunkt senden, wandelt der Dienst Ihren Eingabetext in Token um und sendet sie an Ihr bereitgestelltes Modell. Das Modell empfängt die Eingabetoken und beginnt dann mit dem Generieren einer Antwort. Es handelt sich um einen iterativen sequenziellen Prozess, jeweils ein Token. Man kann es sich auch wie eine Für-Schleife mit n tokens = n iterations vorstellen. Bei den meisten Modellen ist das Generieren der Antwort der langsamste Schritt im Prozess.

Zum Zeitpunkt der Anforderung wird die angeforderte Erzeugungsgröße (max_tokens Parameter) als erste Schätzung der Generierungsgröße verwendet. Die Berechnungszeit für die Generierung der vollständigen Größe wird durch das Modell reserviert, während die Anforderung verarbeitet wird. Nach Abschluss der Generierung wird das verbleibende Kontingent freigegeben. Möglichkeiten zum Verringern der Anzahl von Token:

• Legen Sie den max_tokens Parameter für jeden Aufruf so niedrig wie möglich fest.
• Schließen Sie Stoppsequenzen ein, um das Generieren zusätzlicher Inhalte zu verhindern.
• Generieren Sie weniger Antworten: Die Verwendung des Parameters kann die n Latenz erhöhen, da sie mehrere Ausgaben pro Anforderung erzeugt. Legen Sie für die schnellste Antwort nicht fest n (oder legen Sie sie auf 1fest).

Zusammenfassend verringert die Verringerung der Anzahl der pro Anforderung generierten Token die Latenz jeder Anforderung.

Streaming

Wenn Sie in einer Anforderung festlegen stream: true , werden die Dienstrückgabetoken zurückgegeben, sobald sie verfügbar sind, anstatt darauf zu warten, dass die vollständige Abfolge von Token generiert wird. Es ändert nicht die Zeit, um alle Token abzurufen, sondern reduziert die Zeit für die erste Antwort. Dieser Ansatz bietet eine bessere Benutzererfahrung, da Endbenutzer die Antwort lesen können, während sie generiert wird.

Streaming ist auch für große Anrufe nützlich, die eine lange Zeit in Anspruch nehmen. Viele Clients und Zwischenebenen verfügen über Timeouts für einzelne Anrufe. Lange Generierungsaufrufe können aufgrund von clientseitigen Zeitüberschreitungen abgebrochen werden. Durch das Zurückstreamen der Daten können Sie sicherstellen, dass inkrementelle Daten empfangen werden.

Beispiele für die Verwendung von Streaming:

Chat-Bots und Unterhaltungsschnittstellen.

Streaming wirkt sich auf die wahrgenommene Latenz aus. Durch aktivieren des Streamings erhalten Sie Token wieder in Blöcken, sobald sie verfügbar sind. Bei Endbenutzern fühlt sich dieser Ansatz oft so an, als würde das Modell schneller reagieren, obwohl die Gesamtzeit zum Abschließen der Anforderung unverändert bleibt.

Beispiele, wann Streaming weniger wichtig ist:

Stimmungsanalyse, Sprachübersetzung, Inhaltsgenerierung.

Es gibt viele Anwendungsfälle, in denen Sie eine Massenaufgabe ausführen, bei der Sie nur auf das fertige Ergebnis und nicht auf die Echtzeitantwort achten. Wenn Das Streaming deaktiviert ist, erhalten Sie keine Token, bis das Modell die gesamte Antwort abgeschlossen hat.

Inhaltsfilterung

Azure OpenAI umfasst ein Inhaltsfiltersystem das zusammen mit den Kernmodellen funktioniert. Dieses System führt sowohl die Eingabeaufforderung als auch den Abschluss durch ein Ensemble von Klassifizierungsmodellen aus, die darauf abzielen, die Ausgabe schädlicher Inhalte zu erkennen und zu verhindern.

Das Inhaltsfiltersystem erkennt und führt Maßnahmen für bestimmte Kategorien potenziell schädlicher Inhalte sowohl in Eingabeaufforderungen als auch in Ausgabeabschlussen aus.

Das Hinzufügen der Inhaltsfilterung bietet eine Erhöhung der Sicherheit, aber auch Latenz. Es gibt viele Anwendungen, bei denen dieser Kompromiss bei der Leistung erforderlich ist, es gibt jedoch bestimmte Fälle mit geringerem Risiko, in denen das Deaktivieren der Inhaltsfilter zur Verbesserung der Leistung möglicherweise einen Wert darstellen kann.

Erfahren Sie mehr über das Anfordern von Änderungen an den Standardrichtlinien für die Inhaltsfilterung.

Trennung von Arbeitslasten

Das Mischen verschiedener Workloads auf demselben Endpunkt kann sich negativ auf die Latenz auswirken. Dies liegt daran, dass (1) sie während der Ableitung zusammengestapelt werden und kurze Anrufe auf längere Fertigstellungen warten können und (2) das Mischen der Aufrufe ihre Cachetrefferrate verringern kann, da beide für den gleichen Platz konkurrieren. Wenn möglich, empfiehlt es sich, separate Bereitstellungen für jede Workload einzurichten.

Prompt-Größe

Während die Promptgröße weniger Einfluss auf die Latenz hat als die Generationsgröße, wirkt sich dies auf die Gesamtzeit aus, insbesondere wenn die Größe groß wird.

Batching

Wenn Sie mehrere Anforderungen an denselben Endpunkt senden, können Sie die Anforderungen in einen einzelnen Anruf stapeln. Dadurch wird die Anzahl der Anforderungen reduziert, die Sie vornehmen müssen, und je nach Szenario kann die Gesamtantwortzeit verbessert werden. Wir empfehlen, diese Methode zu testen, um festzustellen, ob dies hilft.

So messen Sie Ihren Durchsatz

Es wird empfohlen, den Gesamtdurchsatz einer Implementierung mit zwei Messungen zu ermitteln:

• Aufrufe pro Minute: Die Anzahl der API-Ableitungsaufrufe, die Sie pro Minute tätigen. Dies kann in Azure-Monitor anhand der Metrik Azure OpenAI-Anforderungen und der Aufteilung nach dem ModelDeploymentName gemessen werden.
• Gesamtzahl der Token pro Minute: Die Gesamtanzahl der Token, die von Ihrer Implementierung pro Minute verarbeitet werden. Dazu gehören Prompt- und generierte Token. Dies wird oft weiter unterteilt, um beide Aspekte zu messen und ein tieferes Verständnis der Bereitstellungsleistung zu erlangen. Dies kann in Azure-Monitor mithilfe der Metrik "Verarbeitete Ableitungstoken" gemessen werden.

Eine vollständige Liste der Überwachungsmetriken, Dimensionen und Ressourcenprotokolle finden Sie unter Azure OpenAI-Überwachungsdatenreferenz.

Zusammenfassung

• Modelllatenz: Wenn die Modelllatenz für Sie wichtig ist, empfehlen wir, das GPT-4o-Minimodell auszuprobieren.
• Niedrigere max. Token: OpenAI hat festgestellt, dass auch in Fällen, in denen die Gesamtanzahl der generierten Token vergleichbar ist, die Anforderung mit dem höheren Wert, der für den parameter "max token" festgelegt ist, mehr Latenz hat.
• Niedrigere Gesamttoken generiert: Je weniger Token generiert wurden, desto schneller wird die Gesamtantwort ausgegeben. Denken Sie daran, dass dies wie eine for-Schleife mit n tokens = n iterations ist. Verringern Sie die Anzahl der generierten Token, und die Gesamtantwortzeit wird entsprechend verbessert.
• Streaming: Das Aktivieren von Streaming kann bei der Verwaltung der Benutzererwartungen in bestimmten Situationen nützlich sein, indem der Benutzer die Modellantwort sehen kann, da es generiert wird, anstatt warten zu müssen, bis das letzte Token bereit ist.
• Die Inhaltsfilterung verbessert die Sicherheit, wirkt sich aber auch auf die Latenz aus. Bewerten Sie, ob eine Ihrer Workloads von geänderten Inhaltsfilterrichtlinien profitieren würde.