Iniziare con le distribuzioni configurate in Microsoft Foundry

La guida seguente illustra i passaggi principali per la creazione di una distribuzione con provisioning con la risorsa Microsoft Foundry. Per altri dettagli sui concetti illustrati qui, vedere:

Prerequisiti

Verificare la disponibilità della quota PTU

Le distribuzioni di throughput con provisioning vengono ridimensionate in unità denominate Unità di Velocità Effettiva con Provisioning (PTU). La quota PTU per ogni tipo di distribuzione provvista viene concessa a una sottoscrizione a livello regionale e limita il numero totale di PTU che possono essere distribuite in tale regione per tutti i modelli e versioni.

La creazione di una nuova distribuzione richiede una quota disponibile (inutilizzata) per coprire le dimensioni desiderate della distribuzione. Ad esempio: se una sottoscrizione include quanto segue negli Stati Uniti centro-meridionali:

  • Quota PTU totale = 500 PTU
  • Distribuzioni:
    • 100 PTU: GPT-4o, 2024-05-13
    • 100 PTU: DeepSeek-R1, 1

Vengono quindi considerate utilizzate 200 PTU di quota e sono disponibili 300 PTU per effettuare nuovi deployment.

Una quantità predefinita di quota globale, zona dati e con provisioning a livello di area viene assegnata alle sottoscrizioni idonee in diverse aree.

È possibile visualizzare la quota disponibile in un'area visitando il riquadro Quota nel riquadro Microsoft FoundryOperate e selezionando la sottoscrizione e l'area desiderati.

È possibile richiedere una quota aggiuntiva selezionando il pulsante Richiedi quota .

Creare una risorsa Foundry

Le distribuzioni configurate vengono create tramite oggetti di risorsa di Foundry all'interno di Azure. È necessario disporre di una risorsa Foundry in ogni area in cui si intende creare una distribuzione.

Nota

Le risorse di Foundry possono supportare contemporaneamente più tipi di distribuzioni di Foundry. Non è necessario assegnare ulteriori risorse per le distribuzioni assegnate.

Scoprire i modelli con l'opzione di distribuzione provisionata

Dopo aver verificato la quota, è possibile creare una distribuzione. Accedi al catalogo dei modelli Foundry per individuare i modelli con opzioni di distribuzione previste/provisionate.

  1. Accedere a Microsoft Foundry. Assicurarsi che l'interruttore New Foundry sia attivato. Questi passaggi fanno riferimento a Foundry (nuovo).These steps refer to Foundry (new).
  2. Nella home page del portale Foundry, scegliere la sottoscrizione abilitata per le distribuzioni configurate e selezionare la risorsa desiderata nella regione dove si dispone di una quota.
  3. Selezionare Esplora nella barra di navigazione in alto a destra, quindi Modelli nel riquadro sinistro.
  4. Selezionare il filtro Collections e filtrare in base Direct da Azure per visualizzare i modelli mantenuti e serviti direttamente da Azure. Una selezione di questi modelli supporta l'opzione di distribuzione del throughput fornito.
  5. Selezionare il modello da distribuire per aprire la scheda del modello.
  6. Selezionare Distribuisci>impostazioni personalizzate per personalizzare la distribuzione.
  7. Selezionare il menu a discesa Tipo di distribuzione per verificare se la distribuzione con provisioning è disponibile per il modello.

Creare una distribuzione provvista: la capacità è disponibile

È possibile creare la distribuzione a livello di codice usando il comando interfaccia della riga di comando di Azure seguente. Per specificare il tipo di distribuzione, modificare il sku-name in GlobalProvisionedManaged, DataZoneProvisionedManaged o ProvisionedManaged in base al tipo di distribuzione previsto. Aggiornare sku-capacity con il numero desiderato di unità di throughput provisionate.

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

È anche possibile usare REST, modello di Resource Manager, Bicep e Terraform per creare distribuzioni. Vedere la sezione relativa all'automazione delle distribuzioni nella guida alle procedure per la gestione delle quote e sostituire sku.name con GlobalProvisionedManaged, DataZoneProvisionedManagedo ProvisionedManaged anziché .Standard

Facoltativamente, acquistare una prenotazione

Dopo la creazione della distribuzione, è possibile acquistare uno sconto per il periodo tramite una prenotazione con Azure. Una prenotazione Azure può offrire uno sconto sostanziale sulla tariffa oraria per gli utenti che intendono usare la distribuzione oltre alcuni giorni.

Per altre informazioni sul modello di acquisto e sulle prenotazioni, vedere:

Importante

La disponibilità della capacità per le distribuzioni di modelli è dinamica e cambia frequentemente tra aree e modelli. Per evitare di acquistare una prenotazione per più PTU di quanti ne puoi usare, crea prima le distribuzioni e quindi acquista la Prenotazione di Azure per coprire i PTU che hai distribuito. Questa procedura consigliata garantisce che sia possibile sfruttare appieno lo sconto sulla prenotazione e impedire l'acquisto di un impegno a termine che non è possibile utilizzare.

Effettuare le prime chiamate di inferenza

Il codice di inferenza per le distribuzioni con provisioning è identico a quello di un tipo di distribuzione standard. Il frammento di codice seguente mostra una chiamata di completamento della chat a un modello GPT-4. Per la prima volta che si usano questi modelli a livello di codice, è consigliabile iniziare con la guida introduttiva. È consigliabile usare la libreria OpenAI con la versione 1.0 o successiva perché include la logica di ripetizione dei tentativi all'interno della libreria.

    import os
    from openai import AzureOpenAI

    client = AzureOpenAI(
        azure_endpoint = os.getenv("AZURE_OPENAI_ENDPOINT"), 
        api_key=os.getenv("AZURE_OPENAI_API_KEY"),  
        api_version="2024-10-21"
    )

    response = client.chat.completions.create(
        model="gpt-4", # model = "deployment_name".
        messages=[
            {"role": "system", "content": "You are a helpful assistant."},
            {"role": "user", "content": "Does Azure OpenAI support customer managed keys?"},
            {"role": "assistant", "content": "Yes, customer managed keys are supported by Azure OpenAI."},
            {"role": "user", "content": "Do other Azure services support this too?"}
        ]
    )

    print(response.choices[0].message.content)

Importante

Per l'ambiente di produzione, usare un modo sicuro per archiviare e accedere alle credenziali, ad esempio Azure Key Vault. Per altre informazioni sulla sicurezza delle credenziali, vedere questo articolo sulla sicurezza .

Comprendere la velocità effettiva prevista

La quantità di velocità effettiva che è possibile ottenere nell'endpoint è un fattore del numero di PTU distribuiti, dimensioni di input, dimensioni di output e frequenza delle chiamate. Il numero di chiamate simultanee e i token totali elaborati possono variare in base a questi valori.

Misurare l'utilizzo della distribuzione

Quando si distribuisce un numero specificato di unità di throughput provisionate, una quantità impostata di throughput di inferenza è resa disponibile per tale endpoint. L'utilizzo di questa velocità effettiva è una formula complessa basata sul modello, sulla frequenza delle chiamate della versione del modello, sulle dimensioni della richiesta, sulle dimensioni della generazione. Per semplificare questo calcolo, è possibile fornire una metrica di utilizzo in Monitoraggio di Azure. La tua distribuzione restituisce un errore 429 per qualsiasi nuova chiamata quando l'utilizzo supera il 100%. L'utilizzo con provisioning è definito come segue:

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

È possibile trovare la misura di utilizzo nella sezione Azure-Monitor per la risorsa. Per accedere ai dashboard di monitoraggio, effettuare l'accesso a https://portal.azure.com, andare alla risorsa Azure OpenAI e selezionare la pagina Metriche dalla barra di navigazione a sinistra. Nella pagina delle metriche selezionare la metrica "Provisioned-managed utilization V2". Se nella risorsa sono presenti più distribuzioni, è necessario dividere anche i valori per ogni distribuzione selezionando il pulsante "Applica suddivisione".

Screenshot dell'utilizzo gestito fornito nel pannello delle metriche della risorsa nell'Azure portal.

Gestire l'alta utilizzazione

Le distribuzioni con risorse preassegnate forniscono una quantità allocata di capacità di calcolo per eseguire un determinato modello. La metrica denominata 'Provisioned-Managed Utilization V2' in Monitoraggio di Azure misura l'utilizzo del deployment in incrementi di un minuto. Le distribuzioni gestite-fornite sono ottimizzate anche in modo che le chiamate accettate vengano elaborate con una latenza massima coerente per ogni chiamata. Quando il carico di lavoro supera la capacità allocata, il servizio restituisce un codice di stato HTTP 429 fino a quando l'utilizzo non scende al di sotto di 100%. Il tempo prima della ripetizione dei tentativi viene fornito nelle intestazioni di risposta retry-after e retry-after-ms, che forniscono rispettivamente il tempo in secondi e millisecondi. Questo approccio mantiene gli obiettivi di latenza per chiamata offrendo allo sviluppatore il controllo su come gestire le situazioni di carico elevato, ad esempio ritentare o deviare ad un'altra esperienza/endpoint.

Cosa devo fare quando ricevo una risposta 429?

Una risposta 429 indica che i PTU allocati vengono utilizzati completamente al momento della chiamata. La risposta include le intestazioni retry-after-ms e retry-after che indicano il tempo di attesa prima che venga accettata la chiamata successiva. La modalità di gestione di una risposta 429 dipende dai requisiti dell'applicazione. Ecco alcune considerazioni:

  • Se si è disposti ad accettare tempi di latenza per chiamata più lunghi, implementare un meccanismo di ritentativo sul lato client per attendere retry-after-ms e tentare di nuovo. Questo approccio consente di ottimizzare la velocità effettiva nella distribuzione. I client SDK forniti da Microsoft già lo gestiscono con impostazioni predefinite adeguate. Potrebbe essere comunque necessaria un'ulteriore ottimizzazione in base ai casi d'uso.
  • Valutare la possibilità di reindirizzare il traffico ad altri modelli, distribuzioni o esperienze. Questo approccio è la soluzione a latenza più bassa perché questa azione può essere eseguita non appena si riceve il segnale 429. Il segnale 429 non è una risposta di errore imprevista in caso di elevato sfruttamento delle risorse, ma fa parte della progettazione per gestire l'accodamento e l'elevato carico per le implementazioni preconfigurate.

Modifica della logica di ripetizione dei tentativi all'interno delle librerie client

Gli SDK OpenAI Azure riprovano a 429 risposte per impostazione predefinita e dietro le quinte nel client (fino al numero massimo di tentativi). Le librerie rispettano il retry-after tempo. È anche possibile modificare la modalità di ripetizione dei tentativi per adattarsi meglio alle tue esigenze. Ecco un esempio con la libreria Python.

È possibile usare l'opzione max_retries per configurare o disabilitare le impostazioni di ripetizione dei tentativi:

import os
from openai import AzureOpenAI

# Configure the default for all requests:
client = AzureOpenAI(
    azure_endpoint = os.getenv("AZURE_OPENAI_ENDPOINT"),
    api_key=os.getenv("AZURE_OPENAI_API_KEY"),
    api_version="2024-10-21",
    max_retries=5,# default is 2
)

# Or, configure per-request:
client.with_options(max_retries=5).chat.completions.create(
    model="gpt-4", # model = "deployment_name".
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Does Azure OpenAI support customer managed keys?"},
        {"role": "assistant", "content": "Yes, customer managed keys are supported by Azure OpenAI."},
        {"role": "user", "content": "Do other Azure services support this too?"}
    ]
)

Eseguire un benchmark

Le funzionalità esatte di prestazioni e velocità effettiva dell'istanza dipendono dal tipo di richieste eseguite e dal carico di lavoro esatto. Il modo migliore per determinare la velocità effettiva per il carico di lavoro consiste nell'eseguire un benchmark sui propri dati.

Per facilitare questo lavoro, lo strumento di benchmarking consente di eseguire facilmente benchmark nella distribuzione. Lo strumento include diverse forme di carico di lavoro preconfigurate e restituisce le metriche delle prestazioni chiave. Altre informazioni sullo strumento e sulle impostazioni di configurazione nel repository di GitHub: https://github.com/Azure/azure-openai-benchmark.

È consigliabile il flusso di lavoro seguente:

  1. Stima i PTU della capacità di elaborazione usando il calcolatore della capacità.
  2. Eseguire un benchmark con questo profilo di traffico per un periodo prolungato (oltre 10 minuti) per osservare i risultati in uno stato stabile.
  3. Osservare l'utilizzo, i token elaborati e i valori di frequenza delle chiamate dallo strumento di benchmark e Monitoraggio di Azure.
  4. Eseguire un test benchmark con le proprie forme di traffico e carichi di lavoro utilizzando la propria implementazione del client. Assicurarsi di implementare la logica di ripetizione dei tentativi usando una Azure libreria client OpenAI o una logica personalizzata.

Contenuto correlato

  • Last updated on