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?

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

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 a livello di area, che definisce il numero massimo di unità elaborate con provisioning 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. Se si espande l'elemento quota nel riquadro Quota di Studio verranno visualizzate 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 aggiuntiva, i clienti possono richiederla tramite il collegamento Richiedi quota a destra degli elementi 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 riceverà 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à. Ciò può limitare la possibilità per alcuni clienti di creare una distribuzione del modello, della versione o del numero di unità elaborate con provisioning desiderate in un'area selezionata, anche se la quota è disponibile in tale area. In generale:

• La quota imposta un limite per il numero massimo di unità elaborate con provisioning che possono essere distribuite in una sottoscrizione e in un'area e non costituisce una garanzia in merito alla 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 aiutare gli utenti a trovare la capacità necessaria per le distribuzioni, i clienti useranno una nuova esperienza di API e Studio per fornire informazioni in tempo reale.

In Azure OpenAI Studio, l'esperienza di distribuzione identificherà quando un'area non dispone della capacità per supportare il modello, la versione e il numero di unità elaborate con provisioning desiderate e indicherà all'utente di selezionare un'area alternativa quando necessario.

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 consente inoltre di identificare a livello di codice la distribuzione di dimensioni massime di un modello specificato che è possibile creare in ogni area in base alla disponibilità di entrambe le quote della sottoscrizione e della 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
• 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. Ciò significa anche 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 dimensioni molto elevate possono riscontrare una velocità effettiva inferiore per unità elaborata con provisioning rispetto a una distribuzione meno estesa con le stesse dimensioni medie dei token di prompt 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.

Quando viene superata la capacità nelle distribuzioni gestite con provisioning e gestite con provisioning globale, l'API restituirà immediatamente un errore di stato HTTP 429. In questo modo l'utente può 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 sfruttare una strategia di ripetizione dei tentativi per gestire una determinata richiesta. Il servizio continuerà a restituire il codice di stato HTTP 429 fino a quando l'utilizzo non 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. Se il parametro max_tokens 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 continuerà 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.

Passaggi successivi

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