Prestazioni e latenza

Questo articolo fornisce informazioni generali sul funzionamento della latenza e della velocità effettiva con Azure OpenAI e su come ottimizzare l'ambiente per migliorare le prestazioni.

Informazioni sulla velocità effettiva e la latenza

Esistono due concetti chiave da considerare quando si ridimensiona un'applicazione: (1) Velocità effettiva a livello di sistema misurata in token al minuto (TPM) e (2) tempi di risposta per chiamata (nota anche come latenza).

Velocità effettiva a livello di sistema

Questa metrica mostra la capacità complessiva della distribuzione, ovvero il numero di richieste al minuto e i token totali che può elaborare.

Per una distribuzione standard, la quota assegnata alla distribuzione determina parzialmente la quantità di throughput che puoi ottenere. Tuttavia, la quota determina solo la logica di ammissione delle chiamate alla distribuzione e non impone direttamente la larghezza di banda. A causa delle variazioni di latenza per chiamata, potrebbe non essere possibile ottenere una velocità effettiva pari a quella della quota.

In una distribuzione con provisioning si alloca una quantità impostata di capacità di elaborazione del modello all'endpoint. La quantità di velocità effettiva che è possibile ottenere dall'endpoint dipende dalla forma del carico di lavoro, tra cui la quantità di token di input, la quantità di output, la frequenza delle chiamate e la frequenza di corrispondenza della cache. Il numero di chiamate simultanee e i token totali elaborati possono variare in base a questi valori.

Per tutti i tipi di distribuzione, comprendere la velocità effettiva a livello di sistema è un componente chiave dell'ottimizzazione delle prestazioni. Prendere in considerazione la velocità effettiva a livello di sistema per una determinata combinazione di modello, versione e carico di lavoro, in quanto la velocità effettiva varia in questi fattori.

Stima della velocità effettiva a livello di sistema

Stima del TPM con metriche di Monitoraggio di Azure

Un approccio alla stima della velocità effettiva a livello di sistema per un determinato carico di lavoro consiste nell'usare i dati cronologici di utilizzo dei token. Per Azure carichi di lavoro OpenAI, è possibile accedere a tutti i dati di utilizzo cronologici e visualizzarli con le funzionalità di monitoraggio native offerte all'interno di Azure OpenAI. Sono necessarie due metriche per stimare il throughput a livello di sistema per i carichi di lavoro di Azure OpenAI: (1) Token di prompt elaborati e (2) Token di completamento generati.

In combinazione, le metriche Processed Prompt Tokens (input TPM) e Generated Completion Tokens (output TPM) forniscono una visualizzazione stimata della velocità effettiva a livello di sistema in base al traffico effettivo del carico di lavoro. Questo approccio non tiene conto dei vantaggi derivanti dalla memorizzazione nella cache dei prompt, quindi sarà una stima conservativa della velocità effettiva del sistema. Queste metriche possono essere analizzate usando l'aggregazione minima, media e massima in finestre di 1 minuto in un orizzonte temporale di più settimane. È consigliabile analizzare questi dati in un orizzonte temporale di più settimane per assicurarsi che ci siano sufficienti punti dati da valutare. Lo screenshot seguente mostra un esempio della metrica Processed Prompt Token visualizzata in Monitoraggio di Azure, disponibile direttamente tramite il portale di Azure.

Stima del TPM dai dati delle richieste

Un secondo approccio alla velocità effettiva stimata a livello di sistema prevede la raccolta di informazioni sull'utilizzo dei token dai dati delle richieste API. Questo metodo offre un approccio più granulare per comprendere la forma del carico di lavoro per ogni richiesta. La combinazione delle informazioni sull'utilizzo dei token per richiesta con il volume di richieste, misurate nelle richieste al minuto (RPM), fornisce una stima per la velocità effettiva a livello di sistema. È importante notare che qualsiasi ipotesi effettuata per coerenza delle informazioni sull'utilizzo dei token tra le richieste e il volume delle richieste influirà sulla stima della velocità effettiva del sistema. I dati di output dell'utilizzo dei token si possono trovare nei dettagli della risposta dell'API per una determinata richiesta di completamento chat di modelli Azure OpenAI in Microsoft Foundry.

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

Supponendo che tutte le richieste per un determinato carico di lavoro siano uniformi, moltiplicare i token di richiesta e i token di completamento dai dati di risposta api in base al valore RPM stimato per identificare il TPM di input e output per il carico di lavoro specificato.

Come usare le stime della velocità effettiva a livello di sistema

Dopo aver stimato il throughput a livello di sistema per un determinato carico di lavoro, usa queste stime per dimensionare le distribuzioni Standard e Provisioned. Per le distribuzioni Standard, combinare i valori TPM di input e output per stimare il TPM totale da assegnare a una determinata distribuzione. Per le distribuzioni Provisioned, utilizzare i dati relativi all'utilizzo del token di richiesta oppure i valori TPM di input e output per stimare il numero di PTU necessarie a supportare un determinato carico di lavoro tramite lo strumento di calcolo della capacità di distribuzione.

Ecco alcuni esempi per il modello mini GPT-4o:

Dimensioni prompt (token)	Numero di token generati	Richieste al minuto	Input TPM	Output TPM	TPM totale	PTU obbligatori
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

Il numero di PTU viene ridimensionato approssimativamente linearmente con la frequenza di chiamata quando la distribuzione del carico di lavoro rimane costante.

Latenza: tempi di risposta per chiamata

La definizione elevata della latenza in questo contesto è il tempo necessario per ottenere una risposta dal modello. Per le richieste di completamento e completamento della chat, la latenza dipende in gran parte dal tipo di modello, dal numero di token nella richiesta e dal numero di token generati. In generale, ogni token di prompt aggiunge poco tempo rispetto a ogni token incrementale generato.

La relazione TTLT = TTFT + (TBT × Tokens Generated) consente di separare la latenza prevista basata su token dalle regressioni reali. Per informazioni dettagliate, vedere Informazioni sulla latenza di Azure OpenAI.

La stima della latenza prevista per chiamata può risultare complessa con questi modelli. La latenza di una richiesta di completamento può variare in base a quattro fattori principali: (1) il modello, (2) il numero di token nel prompt, (3) il numero di token generati e (4) il carico complessivo nella distribuzione e nel sistema. I fattori uno e tre spesso contribuiscono maggiormente al tempo totale. La sezione successiva illustra in modo più dettagliato l'anatomia di una chiamata di inferenza del modello linguistico di grandi dimensioni.

Comprendere la latenza di Azure OpenAI

La latenza delle richieste di Azure OpenAI segue una formula prevedibile. Conoscere questa formula consente di indicare i tempi di risposta previsti basati su token dalle regressioni delle prestazioni reali.

Formula di latenza

Il tempo totale per generare una risposta è:

TTLT = TTFT + (TBT × Token generati)

Dove:

• TTFT (Time to First Token) è il tempo trascorso dall'invio della richiesta fino a quando il primo token non viene restituito, in millisecondi.
• TBT (tempo tra token) è il tempo medio tra i token generati consecutivi, in millisecondi.
• Token generati è il numero totale di token di output per la risposta.
• TTLT (Time to Last Token) è il tempo totale di risposta end-to-end.

Poiché il valore TTLT viene ridimensionato con il numero di token generati, un aumento del valore TTLT è spesso spiegato completamente da un aumento dei token di output, non da un problema di prestazioni del sistema. Controllare sempre i conteggi dei token prima di concludere che sia presente una regressione della latenza.

Metriche di latenza chiave

Usare queste metriche di Monitoraggio di Azure per analizzare la latenza, indipendentemente se si esegue lo streaming delle risposte.

Nome visualizzato	Nome API REST	Cosa misura	Quando usare
Tempo per l'ultimo byte	AzureOpenAITTLTInMS	Tempo totale dall'invio del prompt all'ultimo token, misurato dal gateway API. Mappata a TTLT.	Richieste non in streaming, o ogni volta che è necessario un tempo di risposta complessivo.
Tempo per la risposta	AzureOpenAITimeToResponse	Tempo dalla presentazione del prompt al primo segmento di risposta. Mappata a TTFT.	Richieste di streaming o in qualsiasi momento è necessaria la velocità di risposta del primo token.
Tempo tra i token	AzureOpenAINormalizedTBTInMS	Millisecondi medi tra i token generati consecutivi. Mappata a TBT. A volte chiamato frequenza media di generazione dei token.	Richieste di streaming o per diagnosticare la velocità effettiva di generazione.
Tempo normalizzato al primo byte	AzureOpenAINormalizedTTFTInMS	Latenza di primo byte divisa per numero di token di richiesta.	Confronto dell'efficienza del primo token tra dimensioni di richiesta diverse. Non usare questa metrica per la diagnosi di latenza assoluta.
Gettoni di completamento generati	GeneratedTokens	Numero di token di output per richiesta.	Associare sempre una metrica di latenza: i token di output sono il driver primario di TTLT.
Token di prompt elaborati	ProcessedPromptTokens	Numero di token di input per richiesta.	Le richieste più grandi aumentano il tempo di elaborazione TTFT e il tempo di elaborazione complessivo.

Nota

La formula di latenza usa TTFT, ma Monitoraggio di Azure offre due metriche correlate a TTFT. Per diagnosticare la latenza assoluta che i clienti riscontrano, usare Time to Response (AzureOpenAITimeToResponse). Usare Normalized Time to First Byte (AzureOpenAINormalizedTTFTInMS) solo quando è necessario confrontare l'efficienza del primo token tra richieste di dimensioni diverse.

Abbina sempre una metrica di latenza a una metrica di conteggio dei token. Un TTLT di 5 secondi che genera 2.000 token è molto diverso da un TTLT di 5 secondi che genera 50 token. La latenza senza contesto del token non è praticabile.

Per il catalogo completo delle metriche, incluse le dimensioni e le indicazioni sulle aggregazioni, consultare il riferimento ai dati di monitoraggio di Azure OpenAI.

Valutare la latenza in 10 minuti

Usare il percorso che corrisponde al carico di lavoro per valutare se la latenza di distribuzione si comporta come previsto. Entrambi i percorsi usano le metriche di latenza chiave di Monitoraggio di Azure dalla tabella Key latency metrics.

Carichi di lavoro non in streaming

1. Nel portale di Azure aprire la risorsa Azure OpenAI e quindi selezionare Monitoraggio>Metrics.

2. Aggiungere Time to Last Byte (AzureOpenAITTLTInMS) e dividere per ModelDeploymentName per isolare il comportamento per distribuzione.

3. Aggiungere un secondo grafico per i token di completamento generati (GeneratedTokens) nello stesso intervallo di tempo.

4. Confrontare i due grafici:

   • Se il protocollo TTLT e i token generati aumentano insieme, la modifica della latenza viene spiegata dal volume del token. Questo comportamento previsto non è una regressione.
   • Se il TTLT aumenta senza un aumento del conteggio dei token, verifica un'eventuale saturazione della capacità. Nelle distribuzioni gestite da PTU, consultare il grafico Utilizzo gestito con provisioning V2 (AzureOpenAIProvisionedManagedUtilizationV2). Nelle implementazioni con pagamento a consumo, controllare Azure OpenAI Requests (AzureOpenAIRequests) per verificare la limitazione 429 e il volume delle richieste simultanee.

Carichi di lavoro di streaming

1. Nel portale di Azure aprire la risorsa Azure OpenAI e quindi selezionare Monitoraggio>Metrics.

2. Aggiungere Time to Response (AzureOpenAITimeToResponse) e dividere per ModelDeploymentName la latenza del primo token.

3. Aggiungi tempo tra token (AzureOpenAINormalizedTBTInMS) per la velocità effettiva di generazione per token.

4. Aggiungere token prompt elaborati (ProcessedPromptTokens). Le richieste più grandi aumentano TTFT.

5. Confrontare i grafici:

   • Se il tempo di risposta aumenta mentre la dimensione del prompt rimane costante, verificare il livello di utilizzo della distribuzione e il volume delle richieste simultanee.
   • Se il tempo tra i token aumenta, è probabile che l'implementazione sia sotto carico.

Se i valori osservati sembrano imprevisti, ricollegarli alla formula di latenza per verificare la integrità prima di aprire un caso di supporto.

Migliorare le prestazioni

Diversi fattori possono migliorare la latenza per chiamata dell'applicazione.

Selezione del modello

La latenza varia in base al modello in uso. Per una richiesta identica, si prevede che diversi modelli abbiano latenze diverse per la chiamata di completamento della chat. Se il caso d'uso richiede i modelli di latenza più bassi con i tempi di risposta più rapidi, è consigliabile usare il mini modello GPT-4o più recente.

Dimensione della generazione e token massimi

Quando si invia una richiesta di completamento all'endpoint OpenAI Azure, il servizio converte il testo di input in token e li invia al modello distribuito. Il modello riceve i token di input e inizia a generare una risposta. Si tratta di un processo sequenziale iterativo, un token alla volta. Un altro modo di pensarlo è come un ciclo for con n tokens = n iterations. Per la maggior parte dei modelli, la generazione della risposta è il passaggio più lento del processo.

Al momento della richiesta, la dimensione della generazione richiesta (max_tokens parametro ) viene usata come stima iniziale delle dimensioni della generazione. Il tempo di calcolo per la generazione delle dimensioni complete viene riservato dal modello durante l'elaborazione della richiesta. Una volta completata la generazione, viene rilasciata la quota rimanente. Modi per ridurre il numero di token:

• Imposta il parametro max_tokens al valore più basso possibile per ogni chiamata.
• Includere sequenze di arresto per impedire la generazione di contenuto aggiuntivo.
• Generare un minor numero di risposte: l'uso del parametro può aumentare la n latenza perché produce più output per richiesta. Per ottenere la risposta più veloce, non impostarlo su n (o impostalo su 1).

In sintesi, la riduzione del numero di token generati per richiesta riduce la latenza di ogni richiesta.

Nota

Il max_tokens parametro modifica solo la lunghezza di una risposta e in alcuni casi potrebbe troncarla. Il parametro non modifica la qualità della risposta.

Streaming

L'impostazione stream: true in una richiesta rende i token restituiti dal servizio non appena sono disponibili, invece di attendere la generazione della sequenza completa di token. Non cambia il tempo per ottenere tutti i token, ma riduce il tempo per la prima risposta. Questo approccio offre un'esperienza utente migliore perché gli utenti finali possono leggere la risposta durante la generazione.

Lo streaming è utile anche per le chiamate di grandi dimensioni che richiedono molto tempo per l'elaborazione. Molti client e livelli intermedi hanno timeout nelle chiamate individuali. Le chiamate di generazione lunga potrebbero essere annullate a causa di timeout sul lato client. Tramite lo streaming dei dati, è possibile assicurarsi che i dati incrementali vengano ricevuti.

Esempi di quando usare lo streaming:

Bot di chat e interfacce conversazionali.

Lo streaming influisce sulla latenza percepita. Abilitando lo streaming, si ricevono i token in blocchi non appena sono disponibili. Per gli utenti finali, questo approccio spesso sembra che il modello risponda più velocemente anche se il tempo complessivo per completare la richiesta rimane invariato.

Esempi di quando lo streaming è meno importante:

Analisi del sentiment, traduzione della lingua, generazione di contenuti.

Esistono molti casi d'uso in cui si esegue un'attività in blocco in cui si è interessati solo al risultato finito, non alla risposta in tempo reale. Se lo streaming è disabilitato, non si ricevono token finché il modello non termina l'intera risposta.

Filtro del contenuto

Azure OpenAI include un sistema di filtro content che funziona insieme ai modelli principali. Questo sistema esegue sia la richiesta che il completamento tramite un insieme di modelli di classificazione volti a rilevare e impedire l'output di contenuto dannoso.

Il sistema di filtro del contenuto rileva e agisce su categorie specifiche di contenuto potenzialmente dannoso sia nelle richieste di input che nei completamenti di output.

L'aggiunta del filtro del contenuto comporta un aumento della sicurezza, ma anche la latenza. Ci sono molte applicazioni in cui questo compromesso nelle prestazioni è necessario, tuttavia esistono alcuni casi d'uso più bassi in cui la disabilitazione dei filtri di contenuto per migliorare le prestazioni potrebbe essere utile esplorare.

Altre informazioni sulla richiesta di modifiche ai criteri di filtro del contenuto predefiniti.

Separazione dei carichi di lavoro

La combinazione di carichi di lavoro diversi nello stesso endpoint può influire negativamente sulla latenza. Ciò è dovuto al fatto che (1) vengono raggruppati durante l'inferenza e le chiamate brevi possono attendere completamenti più lunghi e (2) combinando le chiamate si può ridurre il tasso di riscontro nella cache poiché entrambi competono per lo stesso spazio. Quando possibile, è consigliabile avere distribuzioni separate per ogni carico di lavoro.

Dimensione del prompt

Anche se le dimensioni delle richieste hanno meno influenza sulla latenza rispetto alle dimensioni della generazione, influisce sul tempo complessivo, soprattutto quando le dimensioni aumentano di grandi dimensioni.

Elaborazione a lotti

Se si inviano più richieste allo stesso endpoint, è possibile inviare in batch le richieste in una singola chiamata. In questo modo si riduce il numero di richieste che è necessario effettuare e, a seconda dello scenario, potrebbe migliorare il tempo di risposta complessivo. È consigliabile testare questo metodo per verificare se è utile.

Come misurare la velocità effettiva

Si consiglia di misurare il throughput complessivo in un'implementazione utilizzando due indicatori:

• Chiamate al minuto: il numero di chiamate all'inferenza API effettuate al minuto. Questo valore può essere misurato in Azure Monitor usando la metrica Azure OpenAI Requests e suddividendo per il nome del modello di distribuzione (ModelDeploymentName).
• Token totali al minuto: numero totale di token elaborati al minuto dalla distribuzione. Sono inclusi prompt e token generati. Questa operazione viene spesso suddivisa ulteriormente secondo una misurazione per una comprensione più approfondita delle prestazioni della distribuzione. Questa può essere misurata in Azure-Monitor usando la metrica dei token di inferenza elaborati.

Per l'elenco completo delle metriche di monitoraggio, delle dimensioni e dei log delle risorse, vedere Azure Informazioni di riferimento sui dati di monitoraggio OpenAI.

Riepilogo

• Latenza del modello: se la latenza del modello è importante, è consigliabile provare il modello mini GPT-4o.
• Token max inferiori: OpenAI ha rilevato che anche nei casi in cui il numero totale di token generati è simile alla richiesta con il valore più alto impostato per il parametro max token avrà una latenza maggiore.
• Ridurre il numero totale di token generati: meno token vengono generati, più rapida sarà la risposta complessiva. Tenere presente che si tratta di un ciclo for con n tokens = n iterations. Ridurre il numero di token generati e il tempo di risposta complessivo migliorerà di conseguenza.
• Streaming: l'abilitazione dello streaming può essere utile per gestire le aspettative degli utenti in determinate situazioni consentendo all'utente di visualizzare la risposta del modello durante la generazione anziché dover attendere fino a quando l'ultimo token non è pronto.
• Il filtro del contenuto migliora la sicurezza, ma influisce anche sulla latenza. Valutare se uno dei carichi di lavoro trarrà vantaggio dai criteri di filtro dei contenuti modificati.