Che cos'è la velocità effettiva con provisioning?

La funzionalità di velocità effettiva con provisioning consente di specificare la quantità di velocità effettiva necessaria in una distribuzione. Il servizio alloca quindi la capacità di elaborazione del modello necessaria e garantisce che sia pronta per l'utente. La velocità effettiva è definita in termini di unità elaborate con provisioning (PTU), ovvero un modo normalizzato per rappresentare la velocità effettiva per la distribuzione. Ogni coppia versione-modello richiede quantità diverse di PTU per distribuire e fornire quantità diverse di velocità effettiva per PTU.

Cosa forniscono i tipi di distribuzione con provisioning e provisioning globale?

• Prestazioni prevedibili: latenza massima stabile e velocità effettiva per carichi di lavoro uniformi.
• Capacità di elaborazione riservata: una distribuzione configura la quantità di velocità effettiva. Una volta distribuita, la velocità effettiva è disponibile indipendentemente dal fatto che venga usata o meno.
• Risparmio sui costi: i carichi di lavoro con velocità effettiva elevata possono offrire risparmi sui costi rispetto al consumo basato su token.

Una distribuzione Azure OpenAI è un'unità di gestione per un modello OpenAI specifico. Una distribuzione fornisce ai clienti l'accesso a un modello per l'inferenza e integra altre funzionalità, ad esempio Moderazione contenuto (vedere la documentazione sulla moderazione del contenuto). Le distribuzioni globali sono disponibili nelle stesse risorse OpenAI di Azure dei tipi di distribuzione non globali, ma consentono di sfruttare l'infrastruttura globale di Azure per instradare dinamicamente il traffico al data center con la migliore disponibilità per ogni richiesta.

Che cosa si ottiene?

Quantità di velocità effettiva per PTU che si ottiene per ogni modello

La quantità di velocità effettiva (token al minuto o TPM) che una distribuzione ottiene per PTU è una funzione dei token di input e output nel minuto. La generazione di token di output richiede un'elaborazione maggiore rispetto ai token di input e quindi più token di output hanno generato il TPM complessivo inferiore. Il servizio bilancia dinamicamente i costi di input e output, quindi gli utenti non devono impostare limiti di input e output specifici. Questo approccio indica che la distribuzione è resiliente alle fluttuazioni della forma del carico di lavoro.

Per semplificare lo sforzo di dimensionamento, la tabella seguente descrive il TPM per PTU per i gpt-4o modelli e gpt-4o-mini che rappresentano il numero massimo di traffico è di input o output. La tabella mostra anche i valori di destinazione della latenza del contratto di servizio per modello. Per altre informazioni sul contratto di servizio per il servizio OpenAI di Azure, vedere la pagina [Contratti di servizio per i servizi online]. (https://www.microsoft.com/licensing/docs/view/Service-Level-Agreements-SLA-for-Online-Services?lang=1)

Per un elenco completo, vedere il calcolatore di AOAI Studio.

Concetti chiave

Tipi distribuzione

Quando si crea una distribuzione con provisioning in Azure OpenAI Studio, il tipo di distribuzione nella finestra di dialogo Crea distribuzione è Gestito con provisioning. Quando si crea una distribuzione gestita con provisioning globale in Azure OpenAI Studio, il tipo di distribuzione nella finestra di dialogo Crea distribuzione è Gestita con provisioning globale.

Quando si crea una distribuzione con provisioning in Azure OpenAI tramite l'interfaccia della riga di comando di Azure o l'API, è necessario impostare sku-name come ProvisionedManaged. Quando si crea una distribuzione con provisioning globale in Azure OpenAI tramite l'interfaccia della riga di comando di Azure o l’API, è necessario impostare sku-name come GlobalProvisionedManaged. sku-capacity specifica il numero di PTU assegnati alla distribuzione.

az cognitiveservices account deployment create \
--name <myResourceName> \
--resource-group  <myResourceGroupName> \
--deployment-name MyDeployment \
--model-name gpt-4 \
--model-version 0613  \
--model-format OpenAI \
--sku-capacity 100 \
--sku-name ProvisionedManaged 

Obiettivo di vendita

Unità elaborate con provisioning

Le unità elaborate con provisioning sono unità generiche di capacità di elaborazione del modello che è possibile usare per dimensionare le distribuzioni con provisioning per ottenere le unità elaborate necessarie per l'elaborazione dei prompt e generare completamenti. Le unità elaborate con provisioning vengono concesse a una sottoscrizione come quota. Ogni quota è specifica di un'area e definisce il numero massimo di PTU che possono essere assegnate alle distribuzioni in tale sottoscrizione e area.

Quota indipendente dal modello

A differenza della quota di token al minuto usata da altre offerte del servizio OpenAI di Azure, le unità elaborate con provisioning sono indipendenti dal modello. Queste unità possono essere usate per distribuire qualsiasi modello o versione supportata nell'area.

Per le distribuzioni con provisioning, la nuova quota viene visualizzata in Azure OpenAI Studio come elemento quota denominato Unite elaborate gestite con provisioning. Per le distribuzioni gestite con provisioning globale, la nuova quota viene visualizzata in Azure OpenAI Studio come elemento quota denominato Unità elaborate gestite con provisioning globale. Nel riquadro Quota di Studio espandere l'elemento quota mostra le distribuzioni che contribuiscono all'utilizzo di ogni quota.

Ottenere la quota di unità elaborate con provisioning

La quota di unità elaborate con provisioning è disponibile per impostazione predefinita in molte aree. Se è necessaria una quota maggiore, i clienti possono richiedere la quota tramite il collegamento Richiedi quota. Questo collegamento è disponibile a destra delle schede Quota unità elaborate gestite con provisioning o unità elaborate gestite con provisioning globale in Azure OpenAI Studio. Il modulo consente al cliente di richiedere un aumento della quota di unità elaborate specificata per una determinata area. Il cliente riceve un messaggio di posta elettronica all'indirizzo incluso dopo l'approvazione della richiesta, in genere entro due giorni lavorativi.

Valori minimi di unità elaborate con provisioning per modello

La distribuzione, gli incrementi e la capacità di elaborazione minimi associati a ogni unità variano in base al tipo di modello e alla versione.

Trasparenza della capacità

Il servizio OpenAI di Azure è un servizio molto ricercato in cui la domanda dei clienti potrebbe superare la capacità di GPU del servizio. Microsoft si impegna a fornire capacità per tutte le aree e i modelli che la richiedono, ma l'esaurimento della capacità in un'area è sempre una possibilità. Questo vincolo può limitare la capacità di alcuni clienti di creare una distribuzione del modello, della versione o del numero di PTU desiderati in un'area desiderata, anche se hanno una quota disponibile in tale area. In generale:

• La quota pone un limite al numero massimo di PTU che possono essere distribuiti in una sottoscrizione e in un'area e non garantisce la disponibilità della capacità.
• La capacità viene allocata in fase di distribuzione e viene mantenuta finché esiste la distribuzione. Se la capacità del servizio non è disponibile, la distribuzione avrà esito negativo
• I clienti usano informazioni in tempo reale sulla disponibilità della quota/capacità per scegliere un'area appropriata per lo scenario in uso con la capacità necessaria per il modello
• La riduzione delle prestazioni o l'eliminazione di una distribuzione rilascia la capacità corrispondente nell'area. Non è garantito che la capacità sia disponibile se le prestazioni della distribuzione vengono aumentate o la distribuzione viene ricreata in un secondo momento.

Indicazioni sulla capacità a livello di area

Per trovare la capacità necessaria per le distribuzioni, usare l'API di capacità o l'esperienza di distribuzione di Studio per fornire informazioni in tempo reale sulla disponibilità della capacità.

In Azure OpenAI Studio l'esperienza di distribuzione identifica quando un'area non dispone della capacità necessaria per distribuire il modello. Viene esaminato il modello, la versione e il numero di PTU desiderati. Se la capacità non è disponibile, l'esperienza indirizza gli utenti a un'area alternativa selezionata.

Per informazioni dettagliate sulla nuova esperienza di distribuzione, vedere la guida introduttiva sull'offerta Con provisioning del servizio OpenAI di Azure.

La nuova API delle capacità del modello può essere usata per identificare a livello di codice la distribuzione di dimensioni massime di un modello specificato. L'API considera sia la quota che la capacità del servizio nell'area.

Se un'area accettabile non è disponibile per supportare il modello desiderato, la versione e/o le unità elaborate con provisioning, i clienti possono anche provare le procedure seguenti:

• Tentare la distribuzione con un numero minore di unità elaborate con provisioning.
• Tentare la distribuzione in un altro momento. La disponibilità della capacità cambia in modo dinamico in base alla domanda dei clienti e una maggiore capacità potrebbe diventare disponibile in un secondo momento.
• Assicurarsi che la quota sia disponibile in tutte le aree accettabili. L'API delle capacità del modello e l'esperienza di Studio tengono conto della disponibilità delle quote nella restituzione di aree alternative per la creazione di una distribuzione.

Determinazione del numero di PTU necessari per un carico di lavoro

Le PTU rappresentano una quantità di capacità di elaborazione del modello. Analogamente al computer o ai database, carichi di lavoro o richieste diversi al modello utilizzeranno quantità diverse di capacità di elaborazione sottostante. La conversione da caratteristiche della forma di chiamata (dimensioni del prompt, dimensioni della generazione e frequenza di chiamata) a unità elaborate con provisioning è complessa e non lineare. Per semplificare questo processo, è possibile usare il calcolatore della capacità Azure OpenAI per ridimensionare forme di carico di lavoro specifiche.

Alcune considerazioni generali:

• Le generazioni richiedono una maggiore capacità rispetto alle richieste
• Per i modelli GPT-4o e versioni successive, il TPM per PTU viene impostato separatamente per i token di input e output. Per i modelli meno recenti, le chiamate più grandi sono progressivamente più costose da calcolare. Ad esempio, 100 chiamate con dimensioni del prompt di 1.000 token richiedono una capacità inferiore rispetto a una chiamata con 100.000 token nel prompt. Questa suddivisione in livelli significa che la distribuzione di queste forme di chiamata è importante nella velocità effettiva complessiva. I modelli di traffico con una distribuzione estesa che include alcune chiamate di grandi dimensioni potrebbero riscontrare una velocità effettiva inferiore per PTU rispetto a una distribuzione più stretta con le stesse dimensioni medie dei token di richiesta e completamento.

Funzionamento delle prestazioni di utilizzo

Le distribuzioni con provisioning e provisioning globale forniscono una quantità allocata di elaborazione di modelli per eseguire un determinato modello.

In Distribuzioni gestite con provisioning e gestite con provisioning globale, quando viene superata la capacità, l'API restituirà un errore di stato HTTP 429. Questa risposta rapida consente all'utente di prendere decisioni su come gestire il traffico. Gli utenti possono reindirizzare le richieste a una distribuzione separata, a un'istanza con pagamento in base al consumo standard o usare una strategia di ripetizione dei tentativi per gestire una determinata richiesta. Il servizio continua a restituire il codice di stato HTTP 429 fino a quando l'utilizzo scende al di sotto del 100%.

Come è possibile monitorare la capacità?

La metrica Utilizzo gestito con provisioning V2 in Monitoraggio di Azure misura un determinato utilizzo delle distribuzioni con incrementi di 1 minuto. Le distribuzioni gestite con provisioning e gestite con provisioning globale sono ottimizzate per garantire che le chiamate accettate vengano elaborate in un tempo di elaborazione coerente dei modelli (la latenza end-to-end effettiva dipende dalle caratteristiche di una chiamata).

Cosa bisogna fare quando si riceve una risposta 429?

La risposta 429 non è un errore, ma è invece parte della progettazione per indicare agli utenti che una determinata distribuzione viene usata completamente in un momento specifico. Fornendo una risposta di errore rapido, è possibile controllare come gestire queste situazioni in modo ottimale in base ai requisiti dell'applicazione.

Le intestazioni retry-after-ms e retry-after nella risposta indicano il tempo di attesa prima che venga accettata la chiamata successiva. La modalità di gestione di questa risposta dipende dai requisiti dell'applicazione. Ecco alcune considerazioni:

• Si può valutare la possibilità di reindirizzare il traffico verso altri modelli, distribuzioni o esperienze. Questa opzione è la soluzione a latenza più bassa perché questa azione può essere eseguita non appena si riceve il segnale 429. Per idee su come implementare efficacemente questo modello, vedere questo post della community.
• Se si ha familiarità con latenze per chiamata più lunghe, implementare la logica di ripetizione dei tentativi sul lato client. Questa opzione offre la quantità più elevata di velocità effettiva per PTU. Le librerie client Azure OpenAI includono funzionalità predefinite per la gestione dei tentativi.

In che modo il servizio decide quando inviare un messaggio 429?

Nelle offerte Gestita con provisioning e Gestita con provisioning globale ogni richiesta viene valutata singolarmente in base alle dimensioni del prompt, alle dimensioni previste della generazione e al modello per determinare l'utilizzo previsto. Ciò è in contrasto con le distribuzioni con pagamento in base al consumo che prevedono un comportamento di limitazione della frequenza personalizzato in base al carico stimato del traffico. Per le distribuzioni con pagamento in base al consumo, ciò può comportare la generazione di errori di tipo HTTP 429 prima del superamento dei valori di quota definiti se il traffico non viene distribuito in modo uniforme.

Per Gestita con provisioning e Gestita con provisioning globale viene usata una variante dell'algoritmo leaky bucket per mantenere l'utilizzo inferiore al 100%, consentendo al contempo un po' di burst nel traffico. La logica generale è la seguente:

1. Ogni cliente ha una quantità di capacità impostata che può usare in una distribuzione

2. Quando viene effettuata una richiesta:

   a. Quando l'utilizzo corrente è superiore al 100%, il servizio restituisce un codice 429 con l'intestazione retry-after-ms impostata sul tempo fino a quando l'utilizzo non è inferiore al 100%

   b. In caso contrario, il servizio stima la modifica incrementale all'utilizzo necessaria per gestire la richiesta combinando i token di richiesta e l'oggetto specificato max_tokens nella chiamata. Per le richieste che includono almeno 1024 token memorizzati nella cache, i token memorizzati nella cache vengono sottratti dal valore del token di richiesta. Un cliente può ricevere fino a uno sconto del 100% sui token di richiesta a seconda delle dimensioni dei token memorizzati nella cache. Se il max_tokens parametro non viene specificato, il servizio stima un valore. Questa stima può portare a una concorrenza inferiore del previsto quando il numero di token generati effettivi è ridotto. Per la concorrenza più elevata, assicurarsi che il valore max_tokens sia il più vicino possibile alla dimensione di generazione reale.

3. Al termine di una richiesta, si conosce ora il costo di calcolo effettivo per la chiamata. Per garantire una contabilità accurata, correggere l'utilizzo usando la logica seguente:

   a. Se l'effettivo > stimato, la differenza viene aggiunta all'utilizzo della distribuzione

   b. Se l'effettivo < stimato, la differenza viene sottratta.

4. L'utilizzo complessivo viene decrementato a una velocità continua in base al numero di PTU distribuiti.

Quante chiamate simultanee è possibile avere nella distribuzione?

Il numero di chiamate simultanee che è possibile ottenere dipende dalla forma di ogni chiamata (dimensione della richiesta, parametro max_token e così via). Il servizio continua ad accettare chiamate fino a raggiungere il 100%. Per determinare il numero approssimativo di chiamate simultanee, è possibile modellare le richieste massime al minuto per una determinata forma di chiamata nel calcolatore della capacità. Se il sistema genera meno del numero di token di campionamento come max_token, accetterà più richieste.

Quali modelli e aree sono disponibili per la velocità effettiva con provisioning?

Passaggi successivi

• Informazioni sui passaggi di onboarding per le distribuzioni di cui è stato effettuato il provisioning
• Guida introduttiva alle Unità elaborate con provisioning (PTU)