Un MLOps engineer sceglie il modello generativo come sceglierebbe una macchina virtuale: partendo dal profilo del carico. Quale modello per quale compito e come si garantisce capacità a un traffico che non può aspettare sono la stessa domanda posta due volte, sulla qualità della risposta e sulla sua disponibilità. In Microsoft Foundry entrambe le risposte finiscono in un artefatto versionato, perché modello, versione, tipo di deployment e capacità sono proprietà di una risorsa Azure.

Scegliere il modello per il caso d’uso

Il punto di partenza sono le model leaderboard del catalogo Foundry, che confrontano i modelli su quattro assi: qualità (un quality index, media di accuratezze su dataset pubblici di ragionamento, conoscenza, matematica e codice), sicurezza (attack success rate su HarmBench, dove più basso è meglio), prestazioni (latenza media e percentili, tempo al primo token, token generati al secondo) e costo. Ci sono anche leaderboard per scenario e per gli embedding.

La documentazione avverte: i dataset pubblici si saturano nel tempo e le prestazioni sono misurate con carichi sintetici a rapporto input/output fisso su una sola regione. Sono un filtro, non il traguardo.

La distinzione operativa più importante è fra modelli di ragionamento e modelli veloci. Un modello di ragionamento spende token prima di rispondere, e la latenza segue la relazione TTLT = TTFT + (TBT × Tokens Generated): più token genera, più tempo passa. La guida al prompt engineering di Foundry aggiunge che le sue tecniche non sono raccomandate per i modelli di ragionamento: un prompt tarato su una famiglia non si trasferisce sull’altra. Per un endpoint interattivo si va verso modelli piccoli, max_tokens basso e streaming; per un’analisi asincrona il ragionamento si paga volentieri. Anche il costo va proiettato sul traffico storico e non sul listino: token di ragionamento, input in cache e output strutturato possono spostare l’economia unitaria di un fattore due o più. Infine si verificano regione, SKU e quota, e che il candidato possa girare accanto al modello attuale, per il rollback.

Il tipo di deployment fa parte della scelta

Per i modelli serviti come Serverless API, Foundry offre tre categorie — standard a consumo, provisioned a capacità riservata, batch asincrono — su tre luoghi di elaborazione: globale, data zone (Stati Uniti, Unione Europea, Asia Pacifico) e regione singola. Da qui gli SKU GlobalStandard, GlobalProvisionedManaged, GlobalBatch, DataZoneStandard, DataZoneProvisionedManaged, DataZoneBatch, Standard, ProvisionedManaged e DeveloperTier, quest’ultimo solo per valutare modelli fine-tuned, senza SLA e con vita fissa di 24 ore. Il managed compute non usa questi tipi.

La raccomandazione è partire da Global Standard e spostarsi solo con un motivo: residenza del dato, throughput riservato, lotti asincroni. Il criterio è il profilo di traffico: variabile e a picchi si serve con i tipi standard, alto e costante giustifica il provisioned. Lo SKU ammesso si impone con Azure Policy sul campo sku.name.

Dimensionare e riservare il throughput

Una provisioned throughput unit misura capacità di elaborazione riservata: Foundry la trattiene per il deployment, che sia in uso o no. Le PTU sono indipendenti dal modello, ma la quota è per sottoscrizione, regione e tipo di deployment, con Global, Data Zone e Regional in pool separati. Il throughput che una PTU produce dipende invece dal modello, e ogni modello ha un minimo sotto il quale il deployment non si crea.

La trappola d’esame è la differenza fra quota e capacità. La quota è un limite di policy e non costa nulla; la capacità è la disponibilità reale in regione al momento del deploy. Avere quota non garantisce capacità: se la regione non ne ha, la creazione fallisce. E ridurre o cancellare un deployment la restituisce al pool senza garanzia di riaverla.

Il dimensionamento parte da tre grandezze: forma della richiesta (richieste al minuto, token medi di input e output), rapporto fra token di output e di input, tasso di cache. I token serviti dalla cache non consumano capacità PTU, quindi tenere la parte statica del prompt all’inizio abbassa le PTU necessarie. Le grandezze si ricavano dallo storico — le metriche ProcessedPromptTokens e GeneratedTokens in Azure Monitor, o il blocco usage delle risposte — e diventano TPM normalizzati da dividere per l’input TPM per PTU del modello.

Restano due leve. Lo spillover instrada su un deployment standard della stessa risorsa Foundry le richieste che il provisioned rifiuta con 429, globalmente o per singola richiesta con l’header x-ms-spillover-deployment. La fatturazione è oraria per PTU, o scontata con una Azure Reservation per tipo di deployment: sconto sul contatore, non prenotazione di capacità, quindi prima il deployment e poi l’acquisto.

Dichiarare tutto come codice

Il deployment del modello è una sottorisorsa Microsoft.CognitiveServices/accounts/deployments: si dichiara in Bicep o via Azure CLI, con modello, versione, SKU e capacità come parametri per ambiente. I valori ammessi li elenca az cognitiveservices account list-models.

      - uses: azure/login@v2          # OpenID Connect, senza client secret
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      - run: |
          az cognitiveservices account deployment create \
            -n $ACCOUNT -g $RG --deployment-name chat-prod \
            --model-name $MODEL --model-version $VERSION --model-format OpenAI \
            --sku-name GlobalProvisionedManaged --sku-capacity $PTU

Il login federato è quello raccomandato, non il service principal con client secret. Così il passaggio da standard a provisioned è una pull request leggibile.

Da ricordare per l esame

  • Le leaderboard misurano qualità, sicurezza, prestazioni e costo su dataset pubblici: restringono la rosa, ma la scelta si valida sui propri dati.
  • Global Standard è il punto di partenza raccomandato; Data Zone o regione singola per la residenza del dato, provisioned per il throughput riservato, batch per i lotti.
  • Le PTU sono indipendenti dal modello, ma la quota è per sottoscrizione, regione e tipo di deployment: Global, Data Zone e Regional sono pool distinti.
  • Quota non significa capacità: con quota disponibile ma capacità esaurita in regione il deployment fallisce, e quella rilasciata non è garantita al ritorno.
  • I token in cache non consumano PTU; lo spillover devia su un deployment standard le richieste che ricevono 429; la Azure Reservation sconta senza prenotare capacità.