Creare la risorsa Azure OpenAI

Il primo passo è provisionare una risorsa Azure OpenAI all’interno di Azure AI Foundry (o via portale/CLI). È una risorsa di tipo Cognitive Services con kind: OpenAI, associata a una region e a un pricing tier (S0). La scelta della region non è cosmetica: la disponibilità dei modelli e delle modalità di deployment varia per area geografica, e la quota viene assegnata per region. Per la governance è buona pratica disabilitare l’accesso via API key e forzare l’autenticazione con Microsoft Entra ID (managed identity + RBAC, ruolo Cognitive Services OpenAI User), abbinando private endpoint e disattivazione dell’accesso pubblico quando i requisiti di rete lo richiedono.

Creazione rapida via CLI:

az cognitiveservices account create \
  --name myaoai --resource-group rg-ai \
  --kind OpenAI --sku S0 --location swedencentral

Deployment dei modelli

Una risorsa non “contiene” modelli: bisogna creare un model deployment, cioè un nome logico (deployment name) che mappa un modello base + una model version. È il deployment name — non il nome del modello — che si passa nelle chiamate.

Le famiglie principali da conoscere:

  • GPT-4o / GPT-4.1: modelli multimodali (testo + immagini) per chat, reasoning generico, function calling e structured outputs.
  • o-series (o3, o4-mini): modelli di reasoning per compiti a più passaggi, matematica, coding complesso; costano di più e hanno latenza maggiore.
  • Embedding (text-embedding-3-large/small): generano vettori per RAG, ricerca semantica e clustering.
  • DALL-E / GPT-image: generazione di immagini.

Ogni deployment ha una deployment type che determina lo SLA di dati e la posizione di elaborazione: Global Standard (throughput più alto, elaborazione in qualsiasi datacenter), DataZone e Regional Standard (dati elaborati nella region scelta, utile per residenza dati).

Scaling: Standard (TPM) vs Provisioned Throughput (PTU)

Qui si gioca la scelta architetturale d’esame.

  • Standard (pay-as-you-go): paghi a consumo per token. La capacità è governata dalla quota TPM (Tokens Per Minute) assegnata al deployment, da cui deriva anche un limite RPM. È elastico e ideale per traffico variabile, imprevedibile o sporadico (dev/test, POC, picchi rari). Rischio: sotto carico intenso puoi ricevere 429 (throttling); si mitiga distribuendo la quota o usando retry con backoff.

  • Provisioned Throughput Units (PTU): riservi capacità dedicata acquistando unità. Ottieni throughput garantito e latenza prevedibile, indipendente dal “rumore” degli altri tenant. Conviene per carichi elevati e costanti in produzione. Si acquista tipicamente come reservation mensile/annuale (Provisioned Managed) per contenere il costo, altrimenti il prezzo orario è alto. Non conviene per traffico basso o intermittente, dove pagheresti capacità inutilizzata.

Un pattern comune è ibrido: PTU per il carico di base garantito + un deployment Standard come spillover per gestire i picchi.

Versioning e retirement dei modelli

Ogni modello ha versioni datate. Puoi impostare l’auto-update to default perché il deployment segua la versione di default, oppure pinnare una versione specifica per stabilità. Microsoft comunica date di retirement: dopo il ritiro le chiamate a quella versione falliscono, quindi vanno pianificate le migrazioni. Per l’esame: conoscere questi controlli è parte della gestione del ciclo di vita.

Chiamare i modelli: REST e SDK

L’endpoint REST segue lo schema:

POST {endpoint}/openai/deployments/{deployment-name}/chat/completions?api-version=2024-10-21
  • REST: header api-key oppure Authorization: Bearer <token Entra>; body con messages, temperature, max_tokens.
  • SDK (openai Python/.NET, o Azure AI Inference): si configura azure_endpoint, api_version e le credenziali (DefaultAzureCredential con Entra ID è l’approccio consigliato). Nel client il parametro model corrisponde al deployment name.

Trappole tipiche d’esame

  • Scenario: traffico produttivo alto e costante con requisito di latenza stabile → risposta giusta: Provisioned Throughput (PTU), non Standard.
  • Scenario: workload sporadico / POC che riceve errori 429 solo occasionalmente → Standard con quota TPM e retry con backoff; le PTU sarebbero uno spreco.
  • Scenario: “il modello è disponibile ma la chiamata dà quota insufficiente in un’altra region” → ricorda che la quota TPM è per region e per modello, non globale: va richiesta/spostata nella region del deployment.
  • Scenario: serve residenza dei dati nella region → scegli il deployment type Regional/DataZone, non Global Standard.
  • Scenario: il codice chiama gpt-4o ma riceve 404 → nelle richieste si usa il deployment name, non il nome del modello base.