Una soluzione AI su Azure non ha mai una sola voce di costo: il consumo a token dei modelli, l’ora di calcolo di un deployment dedicato, la telemetria in Application Insights, l’indice di ricerca acceso comunque. La parte che riguarda chi sviluppa è che quasi tutte le leve si tirano prima del portale: quale tipo di deployment scegliere, quanto contesto mandare a ogni richiesta e, soprattutto, cosa fa il codice quando il servizio risponde 429.

La quota è un budget di velocità, non di spesa

In Microsoft Foundry la quota si assegna per sottoscrizione, per regione e per modello, e l’unità di misura sono i token al minuto (TPM). Non è un tetto di fatturazione: è un tetto di portata. Quando crei un deployment gli ritagli una fetta della quota disponibile per quel modello in quella regione, e la somma delle fette non può superare la quota della sottoscrizione. Da qui un fraintendimento ricorrente: un modello che il portale non lascia distribuire spesso non è indisponibile, semplicemente non ha più quota residua perché un vecchio deployment di prova se l’è presa.

Il pannello della quota ha due schede, una per i TPM dei deployment standard e una per le PTU dei provisioned. Per vedere le allocazioni serve il ruolo Cognitive Services Usages Reader sulla sottoscrizione; per chiedere un aumento servono Owner o Contributor. Dopo una modifica bisogna dare tempo alla propagazione — la documentazione parla di attendere fino a quindici minuti — quindi un test lanciato subito dopo può raccontare una bugia. Foundry mette poi a disposizione un pool di quota condivisa per provare i modelli del catalogo: va bene per endpoint di test temporanei, non per la produzione, dove si chiede quota dedicata. I modelli in instant access (preview) attingono invece a una quota globale per modello, separata da quella regionale dei deployment.

Il 429 non è un guasto, è il contratto

Superare il rate limit produce una risposta HTTP 429. Su un deployment provisioned succede lo stesso quando la capacità è satura: la metrica ProvisionedUtilization vale PTU consumate diviso PTU distribuite, e quando raggiunge il cento per cento le chiamate vengono limitate. Un client scritto bene non tratta quel codice come un errore applicativo ma come contropressione: ritenta con backoff esponenziale e un po’ di jitter, rispetta l’indicazione di attesa fornita dal servizio e non peggiora le cose ritentando subito e in parallelo.

import random
import time

def chiama_con_backoff(operazione, tentativi=5):
    for i in range(tentativi):
        try:
            return operazione()
        except RateLimitError:          # HTTP 429
            time.sleep(min(2 ** i, 30) + random.random())
    raise RuntimeError("rate limit persistente: rivedere quota o instradamento")

Sopra il codice ci sono le leve architetturali, ed è quello che l’esame chiede di saper scegliere. Lo spillover instrada automaticamente il traffico in eccesso da un deployment provisioned a uno standard durante i picchi, invece di restituire errori. Il global batch accetta molte richieste in un file, le mette in coda con una quota di enqueued token separata, dichiara un obiettivo di completamento entro 24 ore e costa il 50 per cento in meno rispetto a Global Standard: è la scelta giusta quando il lavoro è asincrono e nessuno sta aspettando. Il priority processing va nella direzione opposta, per carichi pay-as-you-go sensibili alla latenza. Infine, quando i consumatori sono più d’uno, il Foundry Control Plane con AI Gateway permette di imporre limiti di token per singolo consumatore, così che un client disattento non prosciughi il deployment condiviso.

Che forma dare alla capacità

Le domande da farsi sono tre: il traffico è prevedibile, la latenza è critica, il modello è mio o del catalogo. Un deployment standard pay-as-you-go non costa nulla quando nessuno lo interroga: paghi i token che passano. Un deployment provisioned riserva capacità in PTU e dà latenza prevedibile, ma la capacità si paga — a ore o tramite Azure Reservations — che qualcuno la usi o no. Il managed compute ospita modelli open-source su GPU dedicate, con fatturazione oraria per SKU e una quota separata da quella delle VM di Azure; supporta auto-scaling e scale-to-zero, e senza scale-to-zero paga anche di notte. Un modello fine-tuned ha tre componenti di costo: training, inferenza a token e hosting orario del deployment personalizzato, che matura anche se nessuno chiama il modello. È qui che arriva la sorpresa in fattura: i deployment personalizzati inutilizzati vanno cancellati, non lasciati distribuiti.

Leggere il consumo e chiudere il cerchio sul costo

Azure Monitor raccoglie le metriche dei deployment automaticamente, senza configurazione. Per il consumo contano InputTokens, OutputTokens e TotalTokens, con TokensCacheMatchRate e ProvisionedUtilization sui provisioned; per lo stato di salute ModelRequests e ModelAvailabilityRate. Nel metrics explorer conviene usare la categoria Models, che copre tutti i modelli della risorsa e non solo quelli Azure OpenAI, e fare splitting sulle dimensioni ModelDeploymentName e ModelName: è così che si scopre quale deployment sta bruciando i token.

Il costo vero si legge però in Microsoft Cost Management. Raggruppa per Meter per capire quale servizio genera la spesa e per Resource per attribuirla: i modelli venduti da Azure appaiono come meter sotto la risorsa Foundry, quelli da partner sono fatturati tramite Azure Marketplace e compaiono a livello di resource group. Ogni progetto Foundry è taggato automaticamente con un tag project, che abilita il chargeback senza tag manuali. Le stime del portale servono al monitoraggio quasi in tempo reale; la riconciliazione finanziaria si fa sui meter fatturati. Sopra a tutto vanno messi budget con soglie di avviso, perché non esiste un limite rigido che blocchi la spesa.

Da ricordare per l’esame

  • La quota è per sottoscrizione, per regione e per modello, in TPM: vederla richiede Cognitive Services Usages Reader, aumentarla Owner o Contributor, e le modifiche impiegano tempo a propagarsi.
  • 429 significa rate limit: si gestisce lato client con retry e backoff esponenziale, lato architettura con spillover, batch o più quota.
  • Provisioned, managed compute e deployment fine-tuned costano anche a traffico zero; standard pay-as-you-go no.
  • Global batch costa il 50 per cento in meno di Global Standard, con obiettivo a 24 ore e quota di enqueued token separata: è per il lavoro asincrono.
  • Le metriche di token stanno in Azure Monitor (categoria Models), il costo effettivo in Cost Management raggruppato per Meter, e il tag project abilita il chargeback per progetto.