Prestaties en wachttijd

Artikel
11/23/2024

In dit artikel vindt u achtergrondinformatie over hoe latentie en doorvoer met Azure OpenAI werken en hoe u uw omgeving kunt optimaliseren om de prestaties te verbeteren.

Inzicht in doorvoer versus latentie

Er zijn twee belangrijke concepten die u moet bedenken bij het aanpassen van de grootte van een toepassing: (1) Doorvoer op systeemniveau gemeten in tokens per minuut (TPM) en (2) Reactietijden per aanroep (ook wel latentie genoemd).

Doorvoer op systeemniveau

Dit bekijkt de totale capaciteit van uw implementatie: hoeveel aanvragen per minuut en het totale aantal tokens dat kan worden verwerkt.

Voor een standaardimplementatie bepaalt het quotum dat aan uw implementatie is toegewezen, gedeeltelijk de hoeveelheid doorvoer die u kunt bereiken. Quota bepaalt echter alleen de toegangslogica voor aanroepen naar de implementatie en dwingt de doorvoer niet rechtstreeks af. Vanwege latentievariaties per aanroep kunt u mogelijk niet zo hoog als uw quotum bereiken. Meer informatie over het beheren van quota.

In een ingerichte implementatie wordt een vaste hoeveelheid modelverwerkingscapaciteit toegewezen aan uw eindpunt. De hoeveelheid doorvoer die u op het eindpunt kunt bereiken, is een factor van de workloadshape, waaronder de hoeveelheid invoertoken, de uitvoerhoeveelheid, de aanroepsnelheid en de cacheovereenkomst. Het aantal gelijktijdige aanroepen en het totale aantal verwerkte tokens kan variëren op basis van deze waarden.

Voor alle implementatietypen is het begrijpen van doorvoer op systeemniveau een belangrijk onderdeel van het optimaliseren van de prestaties. Het is belangrijk om rekening te houden met de doorvoer op systeemniveau voor een bepaald model, een bepaalde versie en een bepaalde workload, omdat de doorvoer afhankelijk is van deze factoren.

Doorvoer op systeemniveau schatten

TPM schatten met metrische gegevens van Azure Monitor

Een benadering voor het schatten van de doorvoer op systeemniveau voor een bepaalde workload is het gebruik van historische tokengebruiksgegevens. Voor Azure OpenAI-workloads kunnen alle historische gebruiksgegevens worden geopend en gevisualiseerd met de systeemeigen bewakingsmogelijkheden die worden aangeboden in Azure OpenAI. Er zijn twee metrische gegevens nodig om de doorvoer op systeemniveau voor Azure OpenAI-workloads te schatten: (1) Verwerkte prompttokens en (2) Gegenereerde voltooiingstokens.

In combinatie bieden de metrische gegevens verwerkte prompttokens (invoer-TPM) en gegenereerde voltooiingstokens (uitvoer-TPM) een geschatte weergave van doorvoer op systeemniveau op basis van daadwerkelijk workloadverkeer. Deze benadering houdt geen rekening met voordelen van promptcaching, dus dit is een conservatieve schatting van de systeemdoorvoer. Deze metrische gegevens kunnen worden geanalyseerd met behulp van minimale, gemiddelde en maximale aggregatie van meer dan 1 minuut gedurende een tijdshorizon van meerdere weken. Het is raadzaam om deze gegevens te analyseren gedurende een periode van meerdere weken om ervoor te zorgen dat er voldoende gegevenspunten zijn om te beoordelen. In de volgende schermopname ziet u een voorbeeld van de metrische gegevens Verwerkte prompttokens die zijn gevisualiseerd in Azure Monitor, die rechtstreeks beschikbaar is via Azure Portal.

Schermopname van Azure Monitor-grafiek waarin de metrische gegevens verwerkte prompttokens worden gesplitst op model en versie.

TPM schatten op aanvraaggegevens

Een tweede benadering van de geschatte doorvoer op systeemniveau omvat het verzamelen van gegevens over tokengebruik uit API-aanvraaggegevens. Deze methode biedt een gedetailleerdere benadering voor het begrijpen van de workloadshape per aanvraag. Het combineren van gebruiksgegevens per aanvraagtoken met aanvraagvolume, gemeten in aanvragen per minuut (RPM), biedt een schatting voor de doorvoer op systeemniveau. Het is belangrijk te weten dat veronderstellingen voor consistentie van gebruiksgegevens voor tokens in aanvragen en aanvraagvolume van invloed zijn op de schatting van de systeemdoorvoer. De uitvoergegevens voor tokengebruik vindt u in de API-antwoorddetails voor een bepaalde aanvraag voor voltooiing van de Azure OpenAI-service-chat.

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

Ervan uitgaande dat alle aanvragen voor een bepaalde workload uniform zijn, kunnen de prompttokens en voltooiingstokens van de API-antwoordgegevens worden vermenigvuldigd met de geschatte RPM om de invoer- en uitvoer-TPM voor de opgegeven workload te identificeren.

Schattingen van doorvoer op systeemniveau gebruiken

Zodra de doorvoer op systeemniveau is geschat voor een bepaalde workload, kunnen deze schattingen worden gebruikt om de grootte van Standard- en ingerichte implementaties te wijzigen. Voor standaardimplementaties kunnen de TPM-waarden voor invoer en uitvoer worden gecombineerd om een schatting te maken van het totale aantal TPM dat moet worden toegewezen aan een bepaalde implementatie. Voor ingerichte implementaties kunnen de gebruiksgegevens van het aanvraagtoken of de TPM-waarden voor invoer en uitvoer worden gebruikt om het aantal PTU's te schatten dat nodig is om een bepaalde workload te ondersteunen met de ervaring van de rekenmachine voor implementatiecapaciteit.

Hier volgen enkele voorbeelden voor het GPT-4o minimodel:

Promptgrootte (tokens)	Generatiegrootte (tokens)	Aanvragen per minuut	TPM-invoer	TPM-uitvoer	Totaal aantal TPM's	VEREISTE PTU's
800	150	30	24,000	4.500	28,500	15
5.000	50	1.000	5,000,000	50,000	5,050,000	140
1.000	300	500	500,000	150.000	650,000	30

Het aantal PTU's wordt ongeveer lineair geschaald met de aanroepsnelheid wanneer de workloaddistributie constant blijft.

Latentie: de reactietijden per oproep

De hoge definitie van latentie in deze context is de hoeveelheid tijd die nodig is om een antwoord terug te krijgen van het model. Voor voltooiings- en chat-voltooiingsaanvragen is latentie grotendeels afhankelijk van het modeltype, het aantal tokens in de prompt en het aantal gegenereerde tokens. Over het algemeen voegt elk prompttoken weinig tijd toe in vergelijking met elk incrementeel token dat wordt gegenereerd.

Het schatten van de verwachte latentie per oproep kan lastig zijn met deze modellen. Latentie van een voltooiingsaanvraag kan variëren op basis van vier primaire factoren: (1) het model, (2) het aantal tokens in de prompt, (3) het aantal gegenereerde tokens en (4) de totale belasting van het implementatie- en systeem. Een en drie zijn vaak de belangrijkste inzenders voor de totale tijd. In de volgende sectie vindt u meer informatie over de anatomie van een grote taalmodeldeductieaanroep.

De prestaties verbeteren

Er zijn verschillende factoren die u kunt beheren om de latentie per aanroep van uw toepassing te verbeteren.

Modelselectie

Latentie varieert op basis van het model dat u gebruikt. Voor een identieke aanvraag verwacht u dat verschillende modellen verschillende latenties hebben voor de oproep voor het voltooien van de chat. Als voor uw use-case de laagste latentiemodellen met de snelste reactietijden zijn vereist, raden we het nieuwste GPT-4o minimodel aan.

Generatiegrootte en Max-tokens

Wanneer u een voltooiingsaanvraag naar het Azure OpenAI-eindpunt verzendt, wordt uw invoertekst geconverteerd naar tokens die vervolgens naar uw geïmplementeerde model worden verzonden. Het model ontvangt de invoertokens en begint vervolgens met het genereren van een antwoord. Het is een iteratief sequentiële proces, één token tegelijk. Een andere manier om het te bedenken is als een for-lus met n tokens = n iterations. Voor de meeste modellen is het genereren van het antwoord de traagste stap in het proces.

Op het moment van de aanvraag wordt de aangevraagde generatiegrootte (max_tokens parameter) gebruikt als een eerste schatting van de generatiegrootte. De rekentijd voor het genereren van de volledige grootte wordt door het model gereserveerd wanneer de aanvraag wordt verwerkt. Zodra het genereren is voltooid, wordt het resterende quotum vrijgegeven. Manieren om het aantal tokens te verminderen:

Stel de max_tokens parameter voor elke aanroep zo klein mogelijk in.
Stopreeksen opnemen om te voorkomen dat er extra inhoud wordt gegenereerd.
Minder antwoorden genereren: de parameters best_of & n kunnen de latentie aanzienlijk verhogen omdat ze meerdere uitvoer genereren. Geef voor het snelste antwoord deze waarden niet op of stel ze in op 1.

Kortom, het verminderen van het aantal tokens dat per aanvraag wordt gegenereerd, vermindert de latentie van elke aanvraag.

Streaming

Als stream: true u een aanvraag instelt, worden tokens voor de service geretourneerd zodra deze beschikbaar zijn, in plaats van te wachten tot de volledige reeks tokens wordt gegenereerd. Het verandert niet de tijd om alle tokens op te halen, maar vermindert de tijd voor het eerste antwoord. Deze benadering biedt een betere gebruikerservaring omdat eindgebruikers het antwoord kunnen lezen terwijl deze wordt gegenereerd.

Streaming is ook waardevol bij grote oproepen die lang duren voordat ze worden verwerkt. Veel clients en tussenliggende lagen hebben time-outs voor afzonderlijke aanroepen. Oproepen van lange generatie kunnen worden geannuleerd vanwege time-outs aan de clientzijde. Door de gegevens terug te streamen, kunt u ervoor zorgen dat incrementele gegevens worden ontvangen.

Voorbeelden van wanneer streaming moet worden gebruikt:

Chatbots en gespreksinterfaces.

Streaming heeft invloed op waargenomen latentie. Als streaming is ingeschakeld, ontvangt u tokens terug in segmenten zodra ze beschikbaar zijn. Voor eindgebruikers voelt deze aanpak vaak alsof het model sneller reageert, ook al blijft de totale tijd voor het voltooien van de aanvraag hetzelfde.

Voorbeelden van wanneer streaming minder belangrijk is:

Sentimentanalyse, taalomzetting, inhoudsgeneratie.

Er zijn veel gebruiksvoorbeelden waarbij u een bulktaak uitvoert waarbij u alleen om het voltooide resultaat geeft, niet het realtime antwoord. Als streaming is uitgeschakeld, ontvangt u geen tokens totdat het model het volledige antwoord heeft voltooid.

Inhoud filteren

Azure OpenAI bevat een systeem voor inhoudsfiltering dat naast de kernmodellen werkt. Dit systeem werkt door zowel de prompt als voltooiing uit te voeren via een ensemble van classificatiemodellen die zijn gericht op het detecteren en voorkomen van de uitvoer van schadelijke inhoud.

Het inhoudsfiltersysteem detecteert en onderneemt actie op specifieke categorieën van mogelijk schadelijke inhoud in zowel invoerprompts als uitvoervoltooiingen.

De toevoeging van inhoudsfilters wordt geleverd met een toename van de veiligheid, maar ook latentie. Er zijn veel toepassingen waarbij deze afweging in prestaties noodzakelijk is, maar er zijn bepaalde gebruiksscenario's met een lager risico waarbij het uitschakelen van de inhoudsfilters om de prestaties te verbeteren misschien de moeite waard is om te verkennen.

Meer informatie over het aanvragen van wijzigingen in het standaardbeleid voor inhoudsfilters.

Scheiding van workloads

Het combineren van verschillende workloads op hetzelfde eindpunt kan een negatieve invloed hebben op de latentie. Dit komt doordat (1) ze samen worden gebatcheerd tijdens deductie en korte aanroepen kunnen wachten op langere voltooiingen en (2) het combineren van de aanroepen uw cachetreffersnelheid kan verminderen omdat ze beide concurreren voor dezelfde ruimte. Indien mogelijk is het raadzaam om afzonderlijke implementaties te hebben voor elke workload.

Promptgrootte

Hoewel de promptgrootte een kleinere invloed heeft op de latentie dan de generatiegrootte, is dit van invloed op de totale tijd, met name wanneer de grootte groot wordt.

Batching

Als u meerdere aanvragen naar hetzelfde eindpunt verzendt, kunt u de aanvragen in één aanroep in een batch plaatsen. Dit vermindert het aantal aanvragen dat u moet indienen en afhankelijk van het scenario dat de totale reactietijd kan verbeteren. We raden u aan deze methode te testen om te zien of deze helpt.

Uw doorvoer meten

We raden u aan om de totale doorvoer voor een implementatie te meten met twee metingen:

Aanroepen per minuut: het aantal API-deductie-aanroepen dat u per minuut maakt. Dit kan worden gemeten in Azure Monitor met behulp van de metrische gegevens voor Azure OpenAI-aanvragen en splitsen door de ModelDeploymentName
Totaal aantal tokens per minuut: het totale aantal tokens dat per minuut wordt verwerkt door uw implementatie. Dit omvat prompt- en gegenereerde tokens. Dit is vaak verder onderverdeeld in het meten van beide voor een dieper inzicht in de implementatieprestaties. Dit kan worden gemeten in Azure Monitor met behulp van de metrische gegevens voor verwerkte deductietokens.

Meer informatie over het bewaken van de Azure OpenAI-service.

Latentie per aanroep meten

De tijd die nodig is voor elke aanroep, is afhankelijk van hoe lang het duurt om het model te lezen, de uitvoer te genereren en inhoudsfilters toe te passen. De manier waarop u de tijd meet, varieert als u streaming gebruikt of niet. We stellen voor elk geval een andere set met maatregelen voor.