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

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

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

In una distribuzione fornita, all'endpoint viene allocata una quantità definita 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 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 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 Processed Prompt Token visualizzata in Monitoraggio di Azure, disponibile direttamente tramite il portale di Azure.

Screenshot di Monitoraggio di Azure che mostra il grafico della 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 un determinato Azure OpenAI nella richiesta di completamento di chat dei modelli 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, 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 determinare la dimensione delle distribuzioni Standard e Provisioned. 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:

Dimensione del prompt (token)	Dimensione della generazione (numero di 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 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 richiesta aggiunge poco al tempo di elaborazione 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 nel prompt, (3) il numero di token generati e (4) il carico complessivo nel sistema di distribuzione e . Uno e tre sono spesso i principali collaboratori 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 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 al Azure endpoint 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 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:

Impostare il max_tokens parametro in ogni chiamata il più piccolo possibile.
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 la risposta più veloce, non impostare n (o impostarlo su 1).

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

Nota

max_tokens 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 con chiamate di grandi dimensioni che richiedono molto tempo per l'elaborazione. Molti clienti e livelli intermedi hanno timeout nelle chiamate individuali. Le chiamate di generazione prolungata 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. Con lo streaming abilitato 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 riceveranno token finché il modello non ha terminato l'intera risposta.

Filtro del contenuto

Azure OpenAI include un sistema di filtro content che funziona insieme ai modelli principali. 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 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 accesso alla cache poiché entrambi competono per lo stesso spazio. Quando possibile, è consigliabile avere distribuzioni separate per ogni carico di lavoro.

Dimensioni prompt

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 aumentano di grandi dimensioni.

Raggruppamento

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 una distribuzione tramite due modalità:

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 la suddivisione in base a ModelDeploymentName.
Totale token al minuto: il numero totale di token elaborati al minuto dalla tua distribuzione. Sono inclusi i prompt e i token generati. Questa operazione viene spesso ulteriormente suddivisa nel misurare entrambi gli aspetti per una comprensione più approfondita delle prestazioni della distribuzione. Questa misura può essere misurata in Azure-Monitor usando la metrica dei token di inferenza elaborati.

Per altre informazioni, vedere Monitoring Azure OpenAI.

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 di contenuto. Il modo in cui si misura il tempo varia se si usa o meno lo streaming. È consigliabile adottare un set diverso di misure per ogni caso.