Prestazioni e latenza

Articolo
11/23/2024

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.

Comprendere la velocità effettiva rispetto alla 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

In questo modo viene esaminata la capacità complessiva della distribuzione, il numero di richieste al minuto e i token totali che possono essere elaborati.

Per una distribuzione standard, la quota assegnata alla distribuzione determina parzialmente la quantità di velocità effettiva che è possibile ottenere. Tuttavia, la quota determina solo la logica di ammissione per le chiamate alla distribuzione e non applica direttamente la velocità effettiva. A causa delle variazioni di latenza per chiamata, potrebbe non essere possibile ottenere una velocità effettiva pari a quella della quota. Altre informazioni sulla gestione delle quote.

In una distribuzione con provisioning, all'endpoint viene allocata una quantità impostata di capacità di elaborazione del modello. La quantità di velocità effettiva che è possibile ottenere nell'endpoint è un fattore della 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. È importante considerare 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 le 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 i carichi di lavoro OpenAI di Azure, è possibile accedere a tutti i dati cronologici di utilizzo e visualizzarli con le funzionalità di monitoraggio native offerte all'interno di Azure OpenAI. Sono necessarie due metriche per stimare la velocità effettiva a livello di sistema per i carichi di lavoro OpenAI di Azure: (1) token di richiesta 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 Token di richiesta elaborati visualizzata in Monitoraggio di Azure, disponibile direttamente tramite il portale di Azure.

Screenshot del grafico di Monitoraggio di Azure che mostra la metrica Token di richiesta elaborati divisa per modello e versione.

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 sono disponibili nei dettagli della risposta dell'API per una determinata richiesta di completamento della chat del servizio OpenAI di Azure.

{
  "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, i token di richiesta e i token di completamento dei dati di risposta API possono essere moltiplicati per il 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

Una volta stimata la velocità effettiva a livello di sistema per un determinato carico di lavoro, queste stime possono essere usate per ridimensionare le distribuzioni Standard e Provisioning. Per le distribuzioni Standard, i valori TPM di input e output possono essere combinati per stimare il TPM totale da assegnare a una determinata distribuzione. Per le distribuzioni con provisioning, è possibile usare i dati di utilizzo del token di richiesta o i valori TPM di input e output per stimare il numero di PTU necessari per supportare un determinato carico di lavoro con l'esperienza di calcolo della capacità di distribuzione.

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

Dimensioni richiesta (token)	Dimensioni della generazione (token)	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 a grandi linee 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 richiesta aggiunge poco tempo rispetto a ogni token incrementale generato.

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 nella richiesta, (3) il numero di token generati e (4) il carico complessivo nel sistema e nella distribuzione. Uno e tre sono spesso i principali elementi che contribuiscono al tempo totale. La sezione successiva illustra in dettaglio l’anatomia di una chiamata di inferenza del modello linguistico di grandi dimensioni.

Migliorare le prestazioni

Esistono diversi fattori che è possibile controllare per 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 completamenti della chat. Se il caso d'uso richiede i modelli con la latenza più bassa e i tempi di risposta più rapidi, è consigliabile usare l'ultimo modello GPT-4o mini.

Dimensioni della generazione e token Max

Quando si invia una richiesta di completamento all’endpoint di Azure OpenAI, il testo di input viene convertito in token che vengono quindi inviati 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 per considerare il processo è 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, le dimensioni di generazione richieste, parametro max_tokens, vengono usate 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:

Impostare il parametro max_tokens per ogni chiamata il più piccolo possibile.
Includere sequenze di arresto per impedire la generazione di contenuto aggiuntivo.
Generare meno risposte: i parametri best_of e n possono aumentare notevolmente la latenza perché generano più output. Per ottenere la risposta più veloce, non specificare questi valori o impostarli su 1.

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

Streaming

L’impostazione di stream: true in una richiesta fa in modo che il servizio restituisca i token non appena sono disponibili, anziché 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 mentre viene generata.

Lo streaming è utile anche con chiamate di grandi dimensioni che richiedono molto tempo per l’elaborazione. Molti client e livelli intermedi hanno timeout su singole chiamate. Le chiamate di generazione prolungata potrebbero essere annullate a causa di timeout a 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. Con lo streaming abilitato si ricevono i token in blocchi non appena sono disponibili. Gli utenti finali percepiscono spesso questo approccio come se il modello rispondesse 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 riceveranno token finché il modello non ha terminato l’intera risposta.

Filtri dei contenuti

Azure OpenAI include un sistema di filtro dei contenuti che funziona insieme ai modelli di base. Questo sistema funziona eseguendo 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 dei contenuti comporta un aumento della sicurezza ma anche latenza. Ci sono molte applicazioni in cui questo compromesso nelle prestazioni è necessario, tuttavia potrebbe valere la pena esplorare la disabilitazione dei filtri di contenuti per migliorare le prestazioni in alcuni casi d’uso a basso rischio.

Altre informazioni sulla richiesta di modifiche ai criteri di filtro dei contenuti 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 insieme durante l’inferenza e le chiamate brevi possono attendere completamenti più lunghi e (2) combinare le chiamate può ridurre la frequenza di riscontri nella cache in quanto sono entrambi in competizione per lo stesso spazio. Quando possibile, è consigliabile separare le distribuzioni per ogni carico di lavoro.

Dimensioni delle richieste

Anche se le dimensioni delle richieste hanno un impatto minore sulla latenza rispetto alle dimensioni di generazione, influiscono sul tempo complessivo, soprattutto quando le dimensioni assumono grandi dimensioni.

Batch

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

È consigliabile misurare la velocità effettiva complessiva in una distribuzione con due misure:

Chiamate al minuto: il numero di chiamate all’inferenza API effettuate al minuto. Questo valore può essere misurato in Monitoraggio di Azure usando la metrica Richieste di Azure OpenAI ed eseguendo una separazione con ModelDeploymentName
Token totali al minuto: numero totale di token elaborati al minuto dalla distribuzione. Sono inclusi richieste e token generati. Questa operazione viene spesso suddivisa ulteriormente secondo una misurazione per una comprensione più approfondita delle prestazioni della distribuzione. Questa misurazione può essere calcolata in Monitoraggio di Azure usando la metrica Token di inferenza elaborati.

Seguire il collegamento per altre informazioni sul Monitoraggio del Servizio OpenAI di Azure.

Come misurare la latenza per chiamata

Il tempo necessario per ogni chiamata dipende dal tempo necessario per leggere il modello, generare l’output e applicare filtri dei contenuti. Il modo in cui si misura il tempo varia se si usa o meno lo streaming. È consigliabile adottare un insieme diverso di misure per ogni caso.