Gestire le distribuzioni configurate in ambiente di produzione

Visualizzazione attualmente:Nuova versione - Passare alla versione per il portale di Foundry classico

Questo articolo illustra le attività complete necessarie per la gestione delle distribuzioni con throughput garantito in ambiente di produzione: gestione delle quote delle unità di throughput garantito (PTU), creazione di distribuzioni, acquisto di Azure Reservations, esecuzione di chiamate di inferenza, benchmarking, monitoraggio dell'utilizzo, gestione dei picchi di carico, scalabilità e liberazione delle risorse.

Questo articolo presuppone la conoscenza dei concetti illustrati in Che cos'è il throughput provisionato? e dei dettagli relativi alla fatturazione descritti in Fatturazione PTU e gestione dei costi.

Prerequisiti

  • Una sottoscrizione di Azure con un metodo di pagamento valido. Se non hai una sottoscrizione Azure, crea un account Azure a pagamento per iniziare.
  • Ruolo "Azure Contributor" o "Cognitive Services Contributor" sull'abbonamento o sul gruppo di risorse in cui si intende creare la distribuzione.
  • Un progetto Microsoft Foundry nella regione in cui si ha una quota PTU. Un progetto Foundry è gestito all'interno di una risorsa Foundry.

Stima dei requisiti PTU

Prima di creare una distribuzione con provisioning, è necessario stimare il numero di PTU necessarie per il proprio carico di lavoro. Per le formule di stima, un esempio lavorato e una procedura dettagliata del calcolatore della capacità, vedere Determinare il ridimensionamento PTU per un carico di lavoro.

Controllare e richiedere la quota PTU

La quota PTU viene concessa per sottoscrizione, per area e limita i PTU totali che è possibile distribuire in tale area in tutti i modelli. Per informazioni dettagliate sulla correlazione tra quota e capacità, vedere Quota PTU e capacità.

Per controllare l'utilizzo corrente o richiedere una quota aggiuntiva:

  1. Accedere a Gestisci>Quota>Unità di throughput assegnata nel portale Foundry.
  2. Selezionare la sottoscrizione e l'area desiderate per visualizzare l'utilizzo corrente.
  3. Per richiedere più quota, selezionare Richiedi quota e completare il modulo.

Tip

È anche possibile seguire questo collegamento diretto al modulo di richiesta di quota.

Creare una distribuzione preconfigurata

Per creare una distribuzione preconfigurata, consultare Guida rapida: Crea una distribuzione con larghezza di banda predefinita.

La quota PTU viene ripartita tra tutte le distribuzioni configurate dello stesso tipo all'interno di una regione. Se dopo la distribuzione iniziale è disponibile una quota rimanente, è possibile usarla per distribuire altri modelli supportati senza richiedere una quota maggiore. Controlla l'utilizzo della quota nella pagina Quota in Operazioni nel portale Foundry.

È possibile gestire la quota richiedendo una quota aggiuntiva o eliminando le distribuzioni esistenti per liberare PTU per le nuove distribuzioni.

Ridimensionare la distribuzione

È possibile aumentare o ridurre il numero di PTU di una distribuzione di cui è stato eseguito il provisioning in qualsiasi momento tramite il portale Foundry o l'interfaccia della riga di comando di Azure (interfaccia della riga di comando di Azure). Per informazioni sui limiti di capacità relativi allo scale-up, sui tempi di adeguamento della fatturazione e sull'impatto sulle prenotazioni esistenti, consultare Distribuzioni con provisioning scalabile.

Acquistare una prenotazione

Una volta che la tua distribuzione con provisioning sarà attiva, valuta la possibilità di acquistare una prenotazione Azure per ottenere una tariffa scontata sulla fatturazione delle PTU. Una prenotazione offre uno sconto significativo sulla fatturazione oraria per le distribuzioni che si prevede di eseguire per più di qualche giorno.

Seguire questo ordine di operazioni per evitare di acquistare una prenotazione per la capacità che non esiste o non corrisponde ai PTU distribuiti:

  1. Usare Foundry per distribuire il modello in un'area con quota disponibile. Questo passaggio conferma che la capacità è disponibile.
  2. Dopo la distribuzione, annota i dettagli della distribuzione: tipo di distribuzione (Global Provisioned, Data Zone Provisioned o Regional Provisioned), area geografica (per le distribuzioni Data Zone e Regional) e sottoscrizione.
  3. Acquistare una nuova prenotazione che corrisponda a tali dettagli o verificare che una prenotazione esistente copra già la distribuzione. Per le distribuzioni globali, l'area di prenotazione non deve corrispondere all'area di distribuzione perché una singola prenotazione globale può coprire le distribuzioni PTU globali in più aree.

Per indicazioni sul dimensionamento, sui prezzi e sulla gestione delle prenotazioni, vedere Fatturazione pTU e gestione dei costi.

Effettuare chiamate di inferenza

Per esempi di codice di inferenza che utilizzano la distribuzione configurata, consultare la guida introduttiva. Il codice per l'inferenza per le distribuzioni con provisioning è lo stesso di quello per qualsiasi altro tipo di distribuzione. Usare il nome della distribuzione (non il nome del modello) come valore del model parametro.

Eseguire un benchmark

Le performance effettive e la capacità di throughput della tua implementazione dipendono dal numero di PTU implementate, dal tipo di richieste che effettui e dal profilo del carico di lavoro (tra cui la dimensione del prompt, la lunghezza della generazione, la frequenza delle richieste e fattori simili). Il modo migliore per determinare la velocità effettiva per il carico di lavoro consiste nell'eseguire un benchmark sui propri dati.

Lo strumento di benchmarking fornisce forme del carico di lavoro preconfigurate e restituisce le metriche delle prestazioni chiave. Usare questo strumento per eseguire benchmark nella distribuzione. Per informazioni dettagliate e impostazioni di configurazione, vedere il repository azure-openai-benchmark su GitHub.

Flusso di lavoro di benchmarking consigliato:

  1. Stimare i requisiti della PTU usando il calcolatore della capacità.
  2. Esegui un test di benchmark con questo profilo di traffico per almeno 10 minuti per ottenere risultati in condizioni di regime.
  3. Osservare l'utilizzo, i token elaborati e la frequenza delle chiamate dallo strumento di benchmark e Monitoraggio di Azure.
  4. Esegui un benchmark con il tuo profilo di traffico e carico di lavoro utilizzando la tua implementazione client. Implementare la logica di ripetizione dei tentativi usando la libreria client OpenAI o la logica di ripetizione dei tentativi personalizzata.

Misurare l'utilizzo della distribuzione

Quando si crea una distribuzione con provisioning, il servizio assegna una quantità fissa di throughput di inferenza. Per monitorare la quantità di capacità utilizzata dal tuo carico di lavoro, utilizza la metrica Utilizzo gestito assegnato V2 in Monitoraggio di Azure.

L'utilizzo di PTU è definito come:

Utilizzo della distribuzione PTU = (PTU utilizzate nel periodo di tempo) / (PTU distribuite nel periodo di tempo)

Per visualizzare la metrica:

  1. Accedi al portale di Azure.
  2. Passa alla risorsa Foundry e seleziona Metriche nella barra di navigazione a sinistra.
  3. Selezionare la metrica Utilizzo gestito e provisionato V2.
  4. Se nella risorsa sono presenti più distribuzioni, selezionare Applica suddivisione per visualizzare i valori suddivisi per distribuzione.

Schermata della metrica Provisioned-managed utilization V2 visualizzata nel pannello delle metriche della risorsa nel portale di Azure.

Come funziona l'utilizzo

Ogni cliente dispone di una determinata quantità di capacità che può utilizzare in un'implementazione con provisioning. Per mantenere l'utilizzo al di sotto del 100% pur consentendo una certa variabilità nel traffico, il servizio utilizza una variante dell'algoritmo "leaky bucket" come segue:

  1. Limitazione a 100%: quando viene effettuata una richiesta, se l'utilizzo corrente è pari a 100%, il servizio restituisce immediatamente HTTP 429, con retry-after-ms e retry-after intestazioni di risposta che indicano il tempo di attesa.
  2. Stima delle richieste: per ogni richiesta in ingresso, il servizio stima il costo di calcolo combinando il numero di token di richiesta (meno token memorizzati nella cache) e l'oggetto specificato max_tokens nella chiamata. I token memorizzati nella cache ricevono uno sconto di 100% e non contribuiscono all'utilizzo. Se max_tokens non viene specificato, il servizio stima un valore. Ciò può comportare una concorrenza inferiore al previsto quando i token generati effettivi sono inferiori a quelli stimati. Per ottenere la massima concorrenza, imposta max_tokens il più vicino possibile alla dimensione di generazione reale.
  3. Correzione post-richiesta: al termine di una richiesta, il servizio corregge la stima dell'utilizzo usando il numero effettivo di token. Se il costo di calcolo effettivo supera la stima, la differenza viene aggiunta all'utilizzo; se è minore, la differenza viene sottratta.
  4. Svuotamento continuo: l'utilizzo si svuota continuamente a una velocità proporzionale ai PTU distribuiti. Una distribuzione con più PTU si esaurisce più rapidamente.

Le richieste accettate vengono sempre completate con una latenza prevedibile, perché le risposte con codice 429 vengono restituite immediatamente invece di mettere il traffico in coda.

Nota

Le chiamate vengono accettate fino a quando l'utilizzo raggiunge 100%. I picchi di poco più di 100% potrebbero essere consentiti per brevi periodi, ma nel tempo il traffico è limitato a 100% utilizzo.

Screenshot dell'algoritmo del

Gestire l'alta utilizzazione

Quando l'utilizzo raggiunge 100%, il servizio restituisce immediatamente HTTP 429 e include le retry-after intestazioni di risposta e retry-after-ms che indicano quanto tempo attendere prima che venga accettata la richiesta successiva. Questo approccio mantiene gli obiettivi di latenza per chiamata, dandoti il controllo su come gestire le situazioni di carico elevato.

Un codice 429 generato da un'implementazione con provisioning non è un errore di servizio, bensì un segnale di gestione del traffico.

Cosa fare quando si riceve una risposta 429

La risposta include le intestazioni retry-after-ms e retry-after, che indicano quanto tempo attendere prima che la richiesta successiva venga accettata. La modalità di gestione di 429 dipende dai requisiti dell'applicazione:

  • Reindirizzamento a un'altra distribuzione o modello: questa opzione produce la latenza aggiuntiva più bassa perché l'azione può essere eseguita non appena si riceve il segnale 429. La funzionalità di spillover automatizza il processo di reindirizzamento delle richieste dalla distribuzione configurata a una distribuzione standard.
  • Riprova utilizzando il tempo di attesa indicato nelle intestazioni della risposta: Se hai bisogno della distribuzione già pronta e puoi accettare una maggiore latenza, attendi il tempo indicato in retry-after-ms e riprova. Gli SDK OpenAI Azure implementano questo comportamento di ripetizione dei tentativi per impostazione predefinita. Potrebbe essere comunque necessaria un'ulteriore ottimizzazione in base ai casi d'uso.

Limiti delle chiamate simultanee

Il numero di chiamate simultanee che una distribuzione può sostenere dipende dalle caratteristiche di ciascuna chiamata, come la dimensione del prompt, il valore di max_tokens e fattori simili. Il servizio accetta chiamate finché l'utilizzo non raggiunge 100%. Per stimare il numero massimo di chiamate simultanee per una forma di chiamata specifica, usare il calcolatore della capacità nella pagina Quota del portale Foundry. Se il modello genera meno token rispetto al max_tokens valore, la distribuzione può accettare più richieste simultanee.

Modificare la logica di ripetizione dei tentativi nelle librerie client

Per impostazione predefinita, gli SDK di OpenAI effettuano un nuovo tentativo in caso di risposte 429, rispettando il tempo specificato nel tag retry-after. È possibile configurare o disabilitare il comportamento di ripetizione dei tentativi usando l'opzione max_retries :

import os
from openai import OpenAI

# Configure the default for all requests:
client = OpenAI(
    api_key=os.getenv("AZURE_OPENAI_API_KEY"),
    base_url="https://<myResourceName>.openai.azure.com/openai/v1/",
    max_retries=5, # default is 2
)

# Or, configure per-request:
client.with_options(max_retries=5).chat.completions.create(
    messages=[
        {
            "role": "user",
            "content": "When was Microsoft founded?",
        }
    ],
    model="gpt-5.1",
)

Riferimento: Azure Linguaggi di programmazione supportati da OpenAI

Pulire le risorse

La fatturazione oraria ha inizio nel momento in cui viene creata una distribuzione con provisioning e termina quando la distribuzione viene eliminata. Gli addebiti per le distribuzioni in una risorsa eliminata continuano fino a quando la risorsa non viene eliminata, quindi eliminare sempre tutte le distribuzioni prima di eliminare la risorsa stessa.

Eliminare completamente una distribuzione già configurata

Per eliminare completamente una distribuzione già configurata:

  1. Nel portale Foundry, andare alla risorsa ed eliminare la distribuzione.
  2. Se si rimuove anche la risorsa Azure, eliminare prima tutte le distribuzioni, quindi eliminare la risorsa.
  3. Se la risorsa è stata eliminata nel passaggio precedente, eliminarla per assicurarsi che la fatturazione venga arrestata. Per istruzioni, vedere Come recuperare o eliminare definitivamente le risorse Azure AI eliminate.
  4. Passare alla pagina Reservations nel portale di Azure per esaminare le prenotazioni esistenti. Se si elimina una distribuzione, nessuna prenotazione PTU viene annullata o modificata. È possibile annullare o scambiare una prenotazione nel portale di Azure, ma questa azione potrebbe comportare costi. Per altre informazioni, vedere Fatturazione pTU e gestione dei costi .

Contenuto correlato

  • Last updated on