Portare un modello fondazionale in produzione somiglia solo in apparenza al deploy di un modello addestrato in casa. Non decidi tu i pesi, non decidi tu il ciclo di vita, e la data di ritiro te la comunica il fornitore. Quello che decidi è dove il modello viene eseguito, come lo paghi, quale versione serve il traffico e come lo sostituisci senza che chi lo consuma se ne accorga. Sono quattro decisioni distinte, e l’esame le tratta come tali.

Serverless API contro managed compute: chi paga che cosa

Microsoft Foundry offre due opzioni di deployment. La Serverless API è l’opzione preferita e più completa: copre tutti i Foundry Models, sia quelli venduti da Azure sia una selezione di modelli di partner e community, e include i tipi di deployment standard, provisioned, batch e developer. Il managed compute, attualmente in preview pubblica e quindi senza SLA e non raccomandato per i carichi di produzione, ospita modelli open source, di partner e custom su GPU dedicate gestite da Foundry.

La differenza che decide la scelta è la fatturazione. Serverless API si paga a token di input e output, oppure a capacità riservata con le provisioned throughput unit. Il managed compute si paga a ora per SKU di acceleratore, secondo una formula che è acceleratori per istanza, moltiplicati per numero di istanze, per ore di esecuzione, per tariffa oraria. Ne discende il criterio: un carico discontinuo o a basso volume paga meno a token, perché quando non arriva traffico non paghi nulla; un carico continuo e saturo può convenire su GPU orarie. Il managed compute mitiga il rischio con l’auto-scale e lo scale-to-zero, che azzera la fatturazione appena le istanze scendono, ma resta una scelta da giustificare.

Altre asimmetrie da conoscere. La risorsa di deployment è la risorsa Foundry per il serverless e il progetto Foundry per il managed compute. Il filtro contenuti integrato e personalizzabile c’è sul serverless, mentre non fa parte del percorso dati del managed compute in preview: se serve, va chiamata l’API di content safety dall’applicazione. Il serverless offre elaborazione regionale, data zone o globale; il managed compute è globale. Infine la quota: quella del managed compute è concessa per famiglia di acceleratori e per regione attraverso il processo di quota di Foundry ed è separata dalla quota delle macchine virtuali di Azure, che non è riutilizzabile. Entrambe le opzioni condividono lo stesso endpoint di progetto, la stessa autenticazione e gli stessi SDK; il managed compute è raggiungibile sulla rotta <endpoint>/managed-deployments/<deployment-name>/ e, se il runtime è compatibile, anche sulla rotta /openai/v1/.

Il deployment del modello come codice

Un deployment fatto a mano nel portale non è riproducibile fra ambienti. Il flusso automatizzabile parte dalla scoperta dei modelli disponibili, che restituisce esattamente i quattro attributi che servono per crearlo: nome, formato (cioè il provider), versione e SKU.

az cognitiveservices account list-models -n $accountName -g $resourceGroupName

az cognitiveservices account deployment create \
  --deployment-name Phi-4-mini-instruct \
  --model-name Phi-4-mini-instruct \
  --model-version 1 \
  --model-format Microsoft \
  --sku-name GlobalStandard \
  --sku-capacity 1 \
  -n $accountName -g $resourceGroupName

In Bicep lo stesso oggetto è Microsoft.CognitiveServices/accounts/deployments, dove lo sku.name è il codice del tipo di deployment e le proprietà descrivono il modello e la policy di filtro contenuti.

resource modelDeployment 'Microsoft.CognitiveServices/accounts/deployments@2024-04-01-preview' = {
  name: '${accountName}/${modelName}'
  sku: {
    name: 'GlobalStandard'
    capacity: capacity
  }
  properties: {
    model: {
      format: modelPublisherFormat
      name: modelName
      version: modelVersion
    }
    versionUpgradeOption: 'OnceCurrentVersionExpired'
    raiPolicyName: contentFilterPolicyName
  }
}

I codici SKU corrispondono ai tipi di deployment: GlobalStandard, DataZoneStandard, Standard per il pagamento a token; GlobalProvisionedManaged, DataZoneProvisionedManaged, ProvisionedManaged per la capacità riservata; GlobalBatch e DataZoneBatch per l’asincrono; DeveloperTier per la sola valutazione di modelli fine-tuned. La raccomandazione ufficiale è di partire da Global Standard e spostarsi solo per un motivo preciso — residenza del dato, throughput riservato o elaborazione batch.

Due vincoli di permessi che si pagano in pipeline: per creare e gestire deployment serve il ruolo Cognitive Services Contributor o equivalente sulla risorsa, e i modelli di partner e community richiedono in più i permessi di Azure Marketplace (le azioni Microsoft.MarketplaceOrdering/... e Microsoft.SaaS/register/action), inclusi nei ruoli Owner e Contributor della sottoscrizione. Ultimo dettaglio prezioso: lo stesso modello può essere distribuito più volte con nomi di deployment diversi, ed è così che si tengono in piedi configurazioni a confronto, filtri contenuti diversi inclusi.

Versioni del modello e criterio di aggiornamento

Ogni deployment porta con sé una policy di aggiornamento della versione, configurabile alla creazione e modificabile dopo, che vale per i tipi di deployment standard. Le opzioni sono tre, e i loro nomi nel modello a oggetti sono NoAutoUpgrade, OnceNewDefaultVersionAvailable e OnceCurrentVersionExpired.

Con la rinuncia all’aggiornamento automatico il deployment resta sulla versione scelta e, alla data di ritiro, smette di accettare richieste e restituisce errori. Con l’aggiornamento alla nuova versione di default il passaggio avviene appena la nuova default esce. Con l’aggiornamento alla scadenza il deployment migra automaticamente quando la versione corrente viene ritirata. Azure notifica i clienti almeno due settimane prima che una nuova versione diventi quella di default e mantiene la versione maggiore precedente fino alla sua data di ritiro, così è possibile tornare indietro. Da sapere anche che l’aggiornamento avviene anche se la nuova versione non è ancora disponibile nella regione del deployment: viene distribuita per l’occasione.

I deployment provisioned, batch e fine-tuned non sono aggiornati automaticamente: si migrano a mano, in place oppure affiancando un nuovo deployment. E le date di ritiro non sono prorogabili: non esiste un processo di eccezione.

Sostituire un modello senza rompere chi lo consuma

Microsoft descrive la migrazione fra modelli in sei fasi — Discover, Assess, Adapt, Validate, Roll out, Retire — e il passo preparatorio più importante viene prima di tutte: congelare un dataset di test con input rappresentativi, ground truth e criteri di successo. Se il dataset cambia in corsa, i risultati del modello sorgente e di quello di destinazione non sono più confrontabili. La cattura dei dati di produzione va attivata in anticipo, perché non è retroattiva.

In fase di Adapt la regola è rieseguire il carico senza modifiche sul nuovo modello prima di toccare qualsiasi cosa, così si distingue ciò che ha cambiato il modello da ciò che hai cambiato tu. E la migrazione non è mai solo riscrittura di prompt: tocca i parametri, le definizioni dei tool, gli schemi di output e il codice chiamante. In Validate si esegue lo stesso set di valutatori su sorgente e destinazione, misurando qualità, latenza e costo per richiesta.

Il punto che sorprende chi viene da Azure Machine Learning riguarda il Roll out. Su un online endpoint di Azure Machine Learning il traffic split e il mirroring sono nativi; su un deployment di modello Foundry il routing pesato si implementa nel proprio gateway o nel livello applicativo. Dove non si può esporre traffico reale, l’equivalente è la modalità shadow: si eseguono gli input di produzione sul nuovo modello fuori linea e si confrontano gli output. In ogni caso si tiene un corridoio di rollback, cioè il vecchio deployment ancora raggiungibile. La migrazione, avverte la documentazione, è raramente binaria: spesso una parte del carico resta sul modello precedente per settimane. La fase Retire esiste proprio per evitare che quei deployment sopravvivano come detriti.

Da ricordare per l esame

  • Serverless API è l’opzione preferita e si paga a token o a PTU; managed compute è in preview, si paga a ora per SKU di acceleratore e ha quota separata da quella delle macchine virtuali di Azure.
  • Il filtro contenuti integrato non è disponibile sul managed compute in preview; il serverless lo ha, integrato e personalizzabile.
  • Il codice SKU nel comando o nel Bicep è il tipo di deployment: si parte da GlobalStandard e ci si sposta solo per residenza dei dati, throughput riservato o batch.
  • Le tre policy di versione sono NoAutoUpgrade (il deployment smette di funzionare al ritiro), OnceNewDefaultVersionAvailable e OnceCurrentVersionExpired; valgono per i deployment standard, mentre provisioned, batch e fine-tuned si migrano a mano.
  • Nella migrazione si congela il dataset di test prima di scegliere il modello, si rifà girare il carico senza modifiche e si tiene aperto il rollback: il routing pesato fra due deployment Foundry lo implementi tu, non è nativo come sugli online endpoint di Azure Machine Learning.