Il primo bivio di una soluzione AI su Azure non è quale prompt scrivere, ma quale modello mettere sotto — e in parecchi casi se serva davvero un modello generativo. Microsoft Foundry espone un catalogo di oltre 10.000 modelli, con circa cinquanta nuovi ingressi al mese, e accanto a essi i Foundry Tools, cioè i servizi specializzati che risolvono compiti chiusi senza generazione. Muoversi fra queste due famiglie con criterio è la competenza che il dominio “Plan and manage” misura in modo più diretto.

Ragionamento o velocità: la forcella principale

Foundry separa nettamente i modelli di ragionamento da quelli veloci. GPT-5 è un modello di ragionamento: eccelle in logica multi-passo, pianificazione, generazione e revisione di codice, tool calling agentico e sintesi di ricerca; in cambio ha latenza più alta, perché consuma token di ragionamento prima di iniziare a rispondere. GPT-4.1 non è un modello di ragionamento ed è ottimizzato per chat in tempo reale, risposte brevi e volumi elevati: bassa latenza, throughput alto e, nella variante long-context, input fino a un milione di token. GPT-5 accetta 272K token in input e ne genera fino a 128K, per 400K complessivi.

La leva che sposta l’ago è il livello di ragionamento, esposto in quattro gradini: minimal, low, medium (default) e high. Salendo crescono profondità, latenza e costo; scendendo migliorano throughput e time-to-first-token. Il dettaglio che l’esame ama: con reasoning_effort su minimal le chiamate parallele ai tool non sono supportate, quindi un agente che invoca più strumenti nello stesso turno richiede almeno low. Lo stesso schema vale per le varianti mini e nano.

completion = client.chat.completions.create(
    model="gpt-5",                 # è il nome del deployment, non del modello
    messages=[{"role": "user", "content": "Analizza il contratto e isola le clausole a rischio"}],
    reasoning_effort="medium",     # minimal | low | medium | high
)

Se il criterio cambia da richiesta a richiesta si può delegare la scelta: il model router valuta il prompt, assegna un punteggio ai candidati e instrada verso il modello più adatto, con un risparmio dichiarato fino al 60% sull’inferenza a qualità comparabile. Prima della produzione va comunque confrontato con una baseline su qualità, costo stimato e latenza.

Il catalogo si divide in due categorie con conseguenze contrattuali, non solo tecniche. I Foundry Models venduti da Azure sono ospitati e venduti da Microsoft, con supporto Microsoft, SLA enterprise e fatturazione tramite i meter di Azure. I modelli da partner e community richiedono invece una sottoscrizione via Azure Marketplace e sono supportati dal provider: se l’identità che esegue il deployment non ha i permessi di Marketplace sulla sottoscrizione, il rilascio fallisce subito.

Gli small language model della famiglia Phi-4, incluse le varianti mini-instruct, mini-reasoning, reasoning e multimodal-instruct, sono la risposta giusta quando il compito è stretto e i vincoli sono costo e latenza; un modello piccolo con un buon retrieval batte quasi sempre un modello grande con un prompt povero. Per i compiti visivi esistono i modelli vision-enabled, che accettano immagini nella Chat Completion API tenendo conto che le immagini consumano token, e modelli generativi di immagini come MAI-Image per creazione ed editing image-to-image. Gli embedding sono una categoria a sé, valutata con metriche proprie.

Il catalogo si filtra per Collections, Region, Deployment options, Deployment SKU, Lifecycle, Industry, Supported features e Inference tasks; la model card riporta Quick facts, Details, Deployments, Benchmarks e License, e il leaderboard confronta qualità, sicurezza, costo e throughput. Errore tipico: fermarsi al benchmark pubblico, che serve a restringere la rosa e non a decidere.

Quando il compito non chiede un modello generativo

Sotto lo stesso resource provider dei modelli vivono i Foundry Tools: Azure Language in Foundry Tools, Azure Speech in Foundry Tools, Azure Vision in Foundry Tools e Content Understanding. Il criterio di scelta è netto. Se l’output ha uno schema stabile e verificabile — riconoscere entità e PII, classificare, tradurre, trascrivere, fare OCR, estrarre campi da un documento — il servizio specializzato è più economico, più prevedibile e più facile da testare di un LLM istruito a produrre lo stesso risultato. Se invece il testo è aperto, la sintesi va costruita e il ragionamento attraversa contesti eterogenei, serve il modello generativo. Attenzione a un vincolo architetturale concreto: alcune capacità restano solo a livello di risorsa Foundry e non sono esposte a livello di progetto, come l’API di Translator.

Dal compito al servizio Foundry

L’obiettivo d’esame chiede di mappare cinque tipi di carico sui servizi giusti. Per i compiti generativi si parte da un deployment di modello sul progetto Foundry. Per il grounding la scelta dipende da dove sta il dato: una knowledge base di Foundry IQ per contenuto aziendale curato e sensibile ai permessi, un indice Azure AI Search quando servono controllo su chunking e filtri, i tool di web grounding quando la risposta dipende da informazione pubblica aggiornata. Per la vector search la contrapposizione è fra un indice vettoriale gestito da voi e il vector store del tool file search, comodo ma con meno leve. Per i flussi agentici c’è Foundry Agent Service, con prompt agent e hosted agent, oppure la Responses API per un agente effimero definito nel codice dell’applicazione. Per il multimodale, Content Understanding estrae caratteristiche strutturate da documenti, immagini e video, mentre i modelli multimodali servono al ragionamento aperto sull’evidenza visiva.

Da ricordare per l’esame

  • Modello di ragionamento contro modello veloce: GPT-5 per pianificazione, codice e tool calling complesso; GPT-4.1 per chat in tempo reale, risposte brevi e alto throughput.
  • Con reasoning_effort su minimal le chiamate parallele ai tool non funzionano: per un agente multi-tool servono almeno low.
  • Venduti da Azure significa supporto Microsoft, SLA e fatturazione a meter Azure; partner e community significa sottoscrizione Azure Marketplace e supporto del provider.
  • Un compito con output a schema stabile va a un Foundry Tool, non a un LLM: costa meno, è deterministico ed è verificabile.
  • Il leaderboard restringe la rosa, non decide: la scelta finale si valida sul proprio dataset.