Un modello nel catalogo non serve a niente finché non esiste un deployment che lo espone e un’applicazione autorizzata a chiamarlo. Questa unità copre esattamente quel tratto di strada: che cosa decidi quando distribuisci un modello in Microsoft Foundry, come si collega un’applicazione Python a un progetto Foundry, e che cosa cambia in pratica fra consumare un LLM, un modello piccolo, uno di codice e uno multimodale. Gli errori commessi qui — endpoint sbagliato, chiave al posto dell’identità, tipo di deployment che non regge il carico — tornano a galla più tardi travestiti da problemi di qualità.

Dal catalogo al deployment: che cosa decidi davvero

Il catalogo dei Foundry Models contiene due categorie con implicazioni molto diverse. I modelli venduti da Azure (Azure OpenAI, Codex, Grok, DeepSeek, Llama, Mistral, Sora) si fatturano sui meter Azure e si distribuiscono direttamente. I modelli da partner e community richiedono in più una sottoscrizione tramite Azure Marketplace: se in uno scenario compare un modello Anthropic o la famiglia Phi-4 e «il deployment fallisce», la sottoscrizione mancante è la prima ipotesi.

La seconda decisione è dove gira il modello. L’opzione preferita è la Serverless API, che comprende le varianti standard, provisioned, batch e developer; il managed compute ospita modelli open source su GPU dedicate, con auto-scaling e scale-to-zero, e ha una quota separata da quella delle VM Azure. Dentro la famiglia serverless i tipi di deployment combinano due assi: la residenza dei dati (GlobalStandard, DataZoneStandard, Standard su regione singola) e la modalità di consumo (Standard a token, ProvisionedManaged a PTU per latenza prevedibile, GlobalBatch per l’elaborazione asincrona, DeveloperTier per la sperimentazione). Il vincolo di conformità sceglie il prefisso, la forma del carico sceglie il suffisso.

Esiste anche l’instant access (preview): chiami un modello per nome senza creare un deployment. Va bene per un prototipo, ma non accetta modelli fine-tuned né guardrail personalizzati e attinge a una quota globale separata. In produzione si passa da un deployment esplicito, dove decidi anche la policy di versione — aggiornamento automatico, aggiornamento alla scadenza o versione fissa — sapendo che i modelli hanno un ciclo di vita con deprecation e retirement annunciati.

Collegare l’applicazione al progetto Foundry

Il progetto è l’unità a cui si aggancia l’applicazione, e ha un endpoint di questa forma: https://<resource-name>.services.ai.azure.com/api/projects/<project-name>. Con Python si installa azure-ai-projects e si costruisce un AIProjectClient autenticato con DefaultAzureCredential, cioè senza chiavi in configurazione.

from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential

project = AIProjectClient(
    endpoint="https://<resource-name>.services.ai.azure.com/api/projects/<project-name>",
    credential=DefaultAzureCredential(),
)

openai = project.get_openai_client()
risposta = openai.responses.create(
    model="gpt-5-mini",
    input="Riassumi in tre righe la politica di reso.",
)
print(risposta.output_text)

Da un solo endpoint ottieni due client, e conviene sapere quando usare quale. Il client di progetto serve alle operazioni native di Foundry: elencare le connessioni, leggere le proprietà del progetto, abilitare il tracing. Il client OpenAI-compatibile serve a tutto ciò che è costruito su concetti OpenAI: Responses API, agenti, valutazioni, fine-tuning. Quasi tutte le applicazioni usano entrambi.

Due eccezioni da ricordare. Gli embedding non passano dall’endpoint di progetto: si generano sulla rotta https://<resource-name>.openai.azure.com/openai/v1/, che è anche quella da preferire quando servono la massima compatibilità OpenAI o la latenza più bassa. Le chiavi API funzionano su quella rotta, ma l’autenticazione consigliata resta Microsoft Entra ID, con managed identity in produzione.

Sui permessi, il ruolo minimo per lo sviluppo quotidiano è Foundry User sul progetto; Foundry Project Manager serve a gestire progetto e connessioni, Foundry Account Owner a creare progetti. Quando l’app fallisce la tabella mentale è breve: 401 è token scaduto o chiave sbagliata, 404 quasi sempre nome di risorsa, progetto o deployment errato, 429 quota o rate limit da gestire con backoff esponenziale.

LLM generalisti e modelli di ragionamento

Con un LLM classico governi la generazione con i parametri di campionamento. Con un modello di ragionamento no: quella famiglia non supporta temperature, top_p, presence_penalty, frequency_penalty, logprobs, top_logprobs, logit_bias e max_tokens. Al loro posto c’è reasoning_effort, con valori che variano per modello fra none, minimal, low, medium, high, xhigh e max. Il modello genera reasoning token che non compaiono nel testo ma occupano il context window e si pagano come token di output, quindi il tetto si imposta con max_output_tokens sulla Responses API o max_completion_tokens su Chat Completions. Controlla sempre status: se la generazione esaurisce lo spazio la risposta torna incomplete e hai pagato input e ragionamento senza ricevere un testo.

Modelli piccoli, di codice e multimodali

Un modello piccolo non è un modello scadente: su classificazione, estrazione di campi, instradamento e riscritture brevi regge il confronto a una frazione di latenza e costo, e va scelto con una valutazione sul tuo compito, non per reputazione. I modelli di codice come Codex coprono generazione e revisione; se il codice prodotto finisce in esecuzione, accoppiali all’evaluator Code Vulnerability. I modelli multimodali accettano immagini nella chiamata di chat: le immagini consumano token, quindi il livello di dettaglio è una decisione di costo oltre che di qualità. Per generare o modificare immagini esistono modelli dedicati come MAI-Image.

Quando non vuoi scegliere a ogni richiesta c’è il model router: un unico deployment che instrada in tempo reale verso il modello più adatto, con routing mode Balanced (default), Cost o Quality e la possibilità di restringere il model subset. Il dettaglio che ricorre nelle domande: la finestra di contesto effettiva è quella del modello sottostante più piccolo, il router accetta immagini ma decide sul solo testo, e non processa audio.

Da ricordare per l’esame

  • L’endpoint di progetto è https://<resource-name>.services.ai.azure.com/api/projects/<project-name>; in Python si usa con AIProjectClient e DefaultAzureCredential, e da lì si ottiene il client OpenAI-compatibile.
  • Gli embedding non passano dall’endpoint di progetto: vanno sulla rotta openai.azure.com/openai/v1.
  • I modelli da partner richiedono una sottoscrizione via Azure Marketplace, quelli venduti da Azure no.
  • I modelli di ragionamento ignorano temperature e affini: si governano con reasoning_effort e con il limite di token di output, e possono tornare incomplete.
  • Con il model router la finestra di contesto utile è quella del modello sottostante più piccolo.