Ottimizzare i costi per i carichi di lavoro di intelligenza artificiale in Azure

Questo articolo mostra ai team di startup nelle fasi iniziali come identificare e ridurre i costi dei carichi di lavoro IA su Microsoft Azure. È pensato per il fondatore, il CTO o il primo ingegnere assunto che si occupa allo stesso tempo della fattura del cloud e del set di valutazione (eval). Tratta l’uso dei tag e l’igiene del budget, le quattro leve del percorso delle richieste (cache, elaborazione in batch, routing e selezione del modello), il dimensionamento ottimale delle GPU per l’inferenza ospitata in proprio, gli schemi di recupero multi-tenant e un ciclo di modifiche sicure che puoi eseguire senza un team di piattaforma dedicato. Ogni sezione è contrassegnata con la fase della guida all'architettura Azure per le startup in cui si applica (Esplora, Espandi o Estrai), in modo da evitare di ottimizzare i problemi non ancora presenti.

Questo articolo descrive come:

• Identificare i principali driver di costo in un carico di lavoro di intelligenza artificiale in Azure.
• Associare le leve di ottimizzazione dei costi alla fase di avvio.
• Applicare la cache dei prompt, la cache semantica, l'elaborazione in batch, l'instradamento del modello e il corretto dimensionamento.
• Progettare schemi di recupero e database multi-tenant che scalano linearmente con i ricavi, non con l’uso.
• Inserite le variazioni dei costi in una fase di valutazione, con avvisi di budget e limiti di richieste per tenant.
• Riconosci i primi segnali che un approccio fai-da-te alla gestione dei costi non è più sufficiente.

Prerequisiti

• Una sottoscrizione Azure con almeno un carico di lavoro di intelligenza artificiale in esecuzione in produzione, staging o prototipo funzionante.
• Autorizzazioni di Proprietario o di Collaboratore sulle risorse che si desidera misurare.
• Apertura facilitata del portale di Azure. Non è necessaria alcuna esperienza precedente con Gestione costi o Monitoraggio di Azure. Questo articolo indica le pagine pertinenti.
• Piccolo set di valutazione per la funzionalità di intelligenza artificiale, con 10-50 richieste rappresentative e comportamenti previsti. Se non ne hai ancora uno, consulta la sezione Articoli correlati. È possibile compilare la prima versione in un pomeriggio.

Perché questo aspetto è importante per le startup

Per un'avvio in fase iniziale, il costo dell'IA è un rischio operativo. Un’inferenza meno costosa libera ore di lavoro del team di ingegneria per l’esperimento successivo, e un costo per utente attivo stabile ti consente di pianificare oltre la prossima tappa di finanziamento invece che alla fattura successiva. I modelli in questo articolo sono deliberatamente piccoli. Ognuno di essi è raggiungibile da un ingegnere fondatore durante un fine settimana, senza la piattaforma o il team FinOps richiesto.

Importante

Non è necessario un team FinOps dedicato per iniziare. L’80% iniziale dei risparmi sui costi deriva dall’etichettare tutto fin dal primo giorno, dall’assegnare a una persona la responsabilità di una revisione settimanale della gestione dei costi e dall’applicare le leve descritte in questo articolo nell’ordine delle fasi. Inserire strumenti e processi FinOps formali solo dopo che la spesa supera circa $ 50.000 al mese o copre più di cinque carichi di lavoro distinti.

Perché i costi di intelligenza artificiale vengono visualizzati in modo diverso rispetto ai costi cloud tradizionali

In un'app web tradizionale, la maggior parte della spesa mensile è dovuta a VM, database e traffico in uscita. In genere è possibile prevederlo con un margine del 10% conoscendo il numero di utenti serviti. I carichi di lavoro di intelligenza artificiale interrompono questa intuizione. Lo stesso utente può costare $ 0,001 un minuto e $ 0,40 il successivo, a seconda della lunghezza del contesto, della profondità di recupero e del modello a cui è stata indirizzata la richiesta.

Quattro modelli di costo ricorrono nella maggior parte dei prodotti di IA in Azure:

• La spesa del token viene ridimensionata con la lunghezza del contesto, non il numero di utenti. Un prompt di retrieval-augmented generation (RAG) ingenuo può espandersi da 800 a 12.000 token in seguito a una modifica del prodotto.
• L'inattività della GPU è il maggiore costo nascosto nell'inferenza autogestita. Un A100 lasciato in esecuzione tutta la notte costa più di un mese di un piccolo database Postgres.
• La diramazione del recupero dai database di ricerca e vettoriali si amplifica. Ogni turno di chat potrebbe generare tre-otto query nascoste che non vengono mai visualizzate nei log.
• L'uscita e l'archiviazione passano lentamente attraverso artefatti del modello, incorporamenti, log di controllo e indici per tenant.

Ogni determinante di costo ha un insieme noto di leve. Le restanti sezioni li descrivono in ordine di priorità, contrassegnati con la fase della startup in cui ciascuna leva è applicabile, così che i team non progettino soluzioni eccessivamente complesse per problemi che non hanno ancora.

Tip

Usare le linee guida per l'ottimizzazione dei costi di Azure Well-Architected Framework nell'architettura per sostenere e migliorare il ritorno sugli investimenti (ROI).

Mappa delle fasi: dove collocare le leve

La guida all'architettura Azure per le startup descrive tre fasi dello sviluppo del prodotto: Esplora, Espandi ed Estrai. Le leve di ottimizzazione dei costi in questo articolo sono allineate a tali fasi. Usa la tabella seguente per stabilire quali sezioni si applicano oggi al tuo team e quali rimandare.

Fase	Numero dipendenti	Obiettivo di costo principale	Leve che danno risultati
Esplora	1-10 ingegneri	Facoltatività e velocità	Assegnazione di tag, memorizzazione nella cache dei prompt, modello predefinito economico
Espandere	10-50 ingegneri	Fermare la crescita lineare dei costi rispetto ai ricavi	Cache semantica, scalabilità a zero, routing, API Batch
Extract	Oltre 50 ingegneri	Margine, prevedibilità, FinOps	Prenotazioni, indici dedicati, quantizzazione, prezzi per tenant

Identificare i principali driver di costo

Prima di ottimizzare qualsiasi cosa, ottenere una vista piatta di dove i soldi stanno effettivamente andando. In Azure il percorso più veloce è Gestione costi, raggruppato per servizio e tag, per gli ultimi 30 giorni.

Contrassegna tutto dal primo giorno

L'applicazione dei tag è la pratica più efficace per la visibilità dei costi. Senza tag coerenti, non è possibile attribuire la spesa a un tenant, a una funzionalità o a un ambiente. Il modello di riferimento Startup Scale Landing Zone (SSLZ) impone l'assegnazione di tag a livello di criteri della landing zone. Usare lo stesso approccio per le risorse di intelligenza artificiale.

costCenter = product | platform | research
tenant     = <customer-id> | shared
workload   = inference | embedding | training | eval
env        = prod | staging | dev
team       = <owning-team>

Dove guardare per primo

Driver di costo	Dove trovarla	Condivisione tipica della fattura
Token (LLM API)	Azure metriche OpenAI > token di richiesta/completamento elaborati	30-60%
GPUs	Ore dei nodi VM/AKS per SKU (famiglie ND, NC e NV)	20-50%
Ricerca vettoriale	Unità di query di ricerca di intelligenza artificiale, UR/sec di Cosmos DB	5-20%
Storage	gestione rete virtuale di Azure, File di Azure e Registro Azure Container per gli artefatti del modello	3-10%
Egress	Larghezza di banda fuori area, in particolare chiamate tra cloud	2-15%

Esporta Cost Management in un account di archiviazione ogni giorno e collegalo al tuo stack di analisi esistente. Un grafico settimanale dei costi per utente attivo è un segnale affidabile che un'ottimizzazione ha avuto l'effetto previsto.

Leva 1: Memorizzazione nella cache, invio in batch, routing e selezione del modello

Fase: Esplora fino a Estrazione. Inizia con il caching in Explore, aggiungi il routing e l'elaborazione in batch in Expand e aggiungi la selezione granulare del modello per tenant in Extract.

Tip

Memorizza nella cache gli embedding indicizzati in base all'hash del contenuto di origine e usa un modello più piccolo ed economico, come GPT-4o mini o un modello a pesi aperti da 7B a 13B, per la classificazione o l'estrazione in una prima fase. Inoltra a un modello più avanzato solo le richieste per cui il modello piccolo è incerto. Questo modello da solo spesso riduce i costi di inferenza del 60 all'80% senza perdita di qualità misurabile nelle query di routine.

Caching

• Prompt caching: Azure OpenAI applica automaticamente sconti ai prefissi ripetuti per prompt di almeno 1.024 token, funzionalità supportata da GPT-4o e dai modelli più recenti. I primi 1.024 token devono essere identici a raggiungere la cache, quindi mantenere stabili le definizioni degli strumenti e le richieste di sistema.
• Semantic cache: Archiviare coppie di incorporamento e risposta in cache di Azure per Redis o Cosmos DB. Restituisce la risposta memorizzata nella cache quando una nuova query presenta una somiglianza coseno superiore a circa 0,95.
• Cache di output: Per gli endpoint non personalizzati, ad esempio domande frequenti e strumenti deterministici, una cache TTL (Time-to-Live) semplice riduce il traffico del 30 all'80%.

Elaborazione a lotti

Le attività di embedding e classificazione sono i candidati più ovvi. L'API Batch di Azure OpenAI offre uno sconto del 50% rispetto all'elaborazione in tempo reale per i processi che possono attendere fino a 24 ore, ad esempio gli aggiornamenti notturni dell'indice, le esecuzioni del valutatore e la generazione asincrona di riepiloghi.

Routing

La maggior parte dei prodotti non richiede il modello più costoso per ogni chiamata. Un router, basato su regole o appreso, può inviare il 60 all'80% del traffico a un modello più economico senza cali di qualità misurabili.

Modello	Percorso a basso costo	Percorso costoso
Classificazione delle finalità	GPT-4o mini o Phi-4	GPT-4o per richieste ambigue
Uso dello strumento o chiamata di funzioni	Modello di livello intermedio	Modello di livello superiore al tentativo
Riepilogo con contesto lungo	Finestra scorrevole con modello di livello intermedio	Modello di livello superiore del contesto completo
Generazione di codice	Modello di livello intermedio per boilerplate	Modello di livello superiore per i refactoring

Selezione del modello

Rivalutare la scelta del modello ogni trimestre. I prezzi e la qualità si spostano rapidamente. Un modello che era l'unica opzione sei mesi fa potrebbe ora essere cinque volte più costoso di uno SKU più recente che assegna punteggi entro uno a due punti sulle valse.

Leva 2: infrastruttura di dimensioni corrette con scalabilità automatica

Fase: Espansione ed estrazione. In Esplora, usa serverless o piattaforma come servizio (PaaS), ad esempio App Service, Container Apps Consumption o Servizio Azure OpenAI, e salta questa leva.

Se esegui l'inferenza in modalità self-hosted con vLLM, Triton o Text Generation Inference (TGI) su Servizio Azure Kubernetes (AKS) o Container Apps, il secondo fattore più importante è assicurarsi che le GPU non restino inattive.

Scalare a zero per i carichi di lavoro inattivi

Imposta minReplicas: 0 in Container Apps con un profilo di carico di lavoro con GPU oppure usa Horizontal Pod Autoscaling (HPA) o KEDA in AKS per ridimensionare i pool di nodi a zero quando non sono presenti richieste in corso. Gli avvii a freddo richiedono in genere decine di secondi. Esegui il benchmark sul tuo modello e mantieni una replica calda durante l'orario lavorativo se è importante contenere la latenza percepita dagli utenti.

Dimensionare correttamente la SKU GPU in base alle dimensioni del modello

Trova la corrispondenza della classe GPU al conteggio dei parametri. T4 o L4 è sufficiente per i modelli inferiori a circa 13B parametri. A100 o H100 convengono solo per modelli con oltre circa 34 miliardi di parametri o con un numero elevato e sostenuto di query al secondo (QPS). La GPU serverless di Container Apps supporta attualmente le GPU T4 e A100. L4 e H100 richiedono il servizio Azure Kubernetes.

Eseguire il training burst e i processi batch per individuare

Esegui valutazioni notturne, aggiornamenti degli embedding e sintesi offline su pool di nodi spot, che in genere sono dal 60 all'80% più economici rispetto a quelli on-demand. Mantenere l'inferenza di produzione sulla capacità dedicata. La tabella seguente riepiloga le strategie di scalabilità automatica e i relativi risparmi tipici.

Caution

La capacità spot può essere revocata con un preavviso di appena 30 secondi. Utilizzare istanze spot solo per carichi di lavoro che possono essere salvati tramite checkpoint o riavviati correttamente, ad esempio valutazioni batch, aggiornamenti degli embedding, generazione di riepiloghi offline e fine-tuning con checkpoint frequenti. Non inserire mai l'inferenza o i processi rivolti all'utente senza logica di riavvio in loco.

Strategy	Come	Risparmio tipico
Ridimensionamento a zero	minReplicas: 0 su Container Apps con profilo del carico di lavoro con GPU. Gli avvii a freddo richiedono in genere decine di secondi. Esegui un benchmark con il tuo modello.	Fino a 90%
KEDA in base alla profondità della coda	Ridimensionare i messaggi di bus di servizio o coda, non la CPU.	30-60%
SKU di dimensioni corrette	T4 o L4 per i modelli con meno di 13B parametri. A100 o H100 solo per i modelli con più di 34B parametri o QPS elevati. Container Apps serverless attualmente supporta solo le GPU T4 e A100. L4 e H100 richiedono il servizio Azure Kubernetes.	40-70%
Capacità Spot	Pool di nodi Spot per batch e valutazione. Capacità su richiesta per la produzione.	40-80%
Quantizzazione	Quantizzazione AWQ o GPTQ a 4 bit per adattarsi a modelli più grandi su GPU più piccole.	Adatta 30B su 16 GB

Note

Il ridimensionamento su zero in una superficie di chat aggiunge una latenza di avvio a freddo visibile. Un modello comune consiste nel mantenere una o due repliche attive durante l'orario lavorativo e ridurre a zero durante la notte.

Leva 3: modelli multi-tenant senza picchi nei costi di recupero

Fase: Espansione ed estrazione tardive. In Esplora si ha quasi sicuramente un tenant: se stessi. Ignorare questa sezione fino a quando non si hanno almeno tre clienti reali.

I prodotti di intelligenza artificiale multi-tenant hanno esito negativo su larga scala quando sono stati scelti modelli di recupero e database per il prototipo a tenant singolo. Tre schemi ricorrono.

Indice per tenant e indice condiviso con filtri

Un indice di ricerca IA dedicato a ciascun tenant garantisce un isolamento netto, ma comporta addebiti per ogni indice anche quando è inattivo. Un indice condiviso con un filtro tenant è molto più economico su scala ridotta e media. Passare a dedicato solo per il livello Enterprise o quando un tenant supera una soglia di dimensioni definita.

Scelta del database vettoriale

Scegli il database vettoriale in base all'infrastruttura esistente e alla scalabilità richiesta. La tabella seguente riepiloga quando ogni opzione si adatta.

Avvertimento

L'eliminazione di un indice vettoriale o del relativo archivio sottostante è irreversibile e la nuova generazione degli embedding per un corpus di grandi dimensioni può costare da centinaia a migliaia di dollari in chiamate al modello, oltre a ore di lavoro tecnico. Prima di qualsiasi modifica distruttiva in un archivio vettoriale, creare uno snapshot dei documenti di origine e verificare che la pipeline di reincorporare venga eseguita end-to-end in un piccolo subset.

Opzione	Migliore per	Struttura dei costi
Azure AI Search (vettoriale)	Ricerca ibrida e filtri	Per-replica, prevedibile
Cosmos DB (vettoriale)	I team che già usano Cosmos DB per i dati delle app	UR/s, scalabilità con QPS
pgvector in Postgres	Corpora di piccole o medie dimensioni, operazioni semplici	Per VM, molto conveniente
Database vettoriale dedicato	100M+ vettori, esigenze di richiamo elevate	Per nodo, costi elevati

Evitare i recupero N+1 nascosti

Ogni passaggio dell'agente che chiama search è una richiesta fatturabile. Registra il numero di chiamate di recupero dei log per ciascun turno utente e invia un avviso quando la mediana supera il budget previsto. Un buon obiettivo iniziale è di due recuperi o meno per turno. I re-ranker e i rewriter sono punti in cui è facile raddoppiare accidentalmente il traffico.

Governance: mantenere sicure le modifiche ai costi

Palco: Tutte le fasi. La versione leggera, che include un budget, un controllo di valutazione una riga prima della distribuzione e un singolo limite di frequenza, appartiene a Esplora dal primo giorno. La versione più complessa, con gate di valutazione che bloccano la CI e limiti di velocità per tenant in API Management, rientra in Expand e oltre.

Un'ottimizzazione che interrompe la qualità non è un'ottimizzazione. È un'interruzione. Gestisci ogni modifica dei costi entro tre paletti. Ogni guardrail può essere configurato in meno di un'ora da un singolo ingegnere.

1. Verifica di valutazione: Eseguite il set di valutazione prima di implementare qualsiasi modifica al prompt, al modello o al routing. Nella fase iniziale, questo controllo può essere uno script eseguito manualmente. Blocca la distribuzione o esegui il rollback se il punteggio scende oltre la soglia di tolleranza, ad esempio di un punto su una scala di 100 punti.
2. Avvisi di budget: Imposta budget di Gestione costi di Azure per ogni gruppo di risorse con avvisi al 50%, 80% e 100%. Inviali allo stesso canale Slack o Teams in cui ricevi le notifiche degli errori, così costi e incidenti confluiscono nello stesso posto.
3. Limite alla frequenza delle richieste: Anche un solo limite per IP o per chiave API in API Management, NGINX o nel tuo gateway impedisce a un client fuori controllo di esaurire il tuo credito residuo nel corso della notte. Aggiungi più avanti i limiti per singolo tenant, quando avrai clienti paganti.

Prestare attenzione al raggruppamento di diverse ottimizzazioni dei costi in una singola versione. Quando il set di modifiche viene integrato tutto insieme, stabilire la responsabilità diventa difficile e qualsiasi regressione è costosa da analizzare tramite bisezione.

L’esperimento a due leve: come confrontare prima e dopo

Quando si decide dove iniziare, scegliere due leve delle sezioni precedenti, spedirle dietro una bandiera di funzionalità e misurare da 7 a 14 giorni. Due leve sono sufficienti per rilevare un movimento significativo. Più di due rende l'attribuzione inaffidabile.

Prima coppia suggerita in base alla fase

Fase	Leva A	Leva B
Preavvio (<100 DAU)	Memorizzazione di prompt nella cache	Routing dei modelli con un modello predefinito a basso costo
Trazione precoce (100-10k DAU)	Cache semantica	Ridimensionamento a zero per l'inferenza
Scala (10k+ DAU)	API Batch per il lavoro asincrono	Strategia di indice per tenant
Livello Enterprise	Indici dedicati per gli account principali	Modelli quantizzati su L4 o H100

Baseline window:   2026-04-15 to 2026-04-28 (14 days)
Treatment window:  2026-05-01 to 2026-05-14 (14 days)
Levers shipped:    1) semantic cache on /chat
                   2) scale-to-zero on vLLM

Metrics:
  cost_per_active_user   (target: down 30%)
  p95_latency_ms         (guardrail: +<= 150 ms)
  eval_score_delta       (guardrail: >= -1.0)

Decision rule: Keep both if all guardrails hold. Otherwise, revert and ship one at a time.

Cosa descrive questo articolo e cosa non lo fa

Questo articolo ha un ambito volutamente limitato. Le sezioni seguenti elencano gli argomenti inclusi nell'ambito, gli argomenti che non rientrano nell'ambito e i segnali che indicano quando aggiungerli.

Nell'ambito

• Etichettatura, budget e pratiche di gestione dei costi adatti a qualsiasi startup.
• Le quattro leve del percorso della richiesta: cache, elaborazione in batch, routing e selezione del modello.
• Dimensionamento ottimale delle GPU e scaling a zero per l'inferenza ospitata in proprio.
• Schemi di recupero multi-tenant per prodotti con da tre a 100 tenant paganti.
• Un ciclo di governance delle modifiche sicure: controllo di valutazione, avvisi di budget e limiti di frequenza per tenant.

Fuori ambito

Argomento	Quando aggiungerlo
Prenotazioni e piani di risparmio per il calcolo di intelligenza artificiale	Il costo dell'inferenza rimane stabile per 90 giorni, di solito fino a metà del periodo di Expand.
Strumenti FinOps dedicati, ad esempio Apptio Cloudability, Vantage e strumenti simili	La spesa per il cloud supera circa $50.000 al mese oppure si opera su più cloud. La maggior parte delle startup in fase iniziale non ne ha bisogno.
Fatturazione personalizzata basata su token per cliente finale	Si vendono prezzi basati sull'utilizzo o un tenant supera il 25% della fattura.
Ottimizzazione dei costi di addestramento, ad esempio mediante la configurazione di DeepSpeed e FSDP	Addestri modelli internamente. I prodotti progettati con un approccio incentrato sull'inferenza non ne hanno bisogno.
Arbitraggio dei costi tra region o multi-cloud	Siete nella fase Extract con una sostenibilità economica in una singola regione già comprovata.

Quando questo approccio non è più sufficiente

Le procedure descritte in questo articolo sono progettate per i team di piccole dimensioni che eseguono il proprio cloud. A un certo punto, la tua azienda diventa troppo grande per loro. I segnali seguenti non sono errori. Sono una crescita. Se se ne applicano due o più, prevedi di introdurre strumenti dedicati o un responsabile della piattaforma part-time.

• La spesa mensile Azure supera circa $50.000 e l'IA è superiore al 30%.
• Più di 10 ingegneri possono rilasciare modifiche che incidono sui costi per il 5% o più.
• Almeno un cliente ha un utilizzo superiore a $ 10.000 al mese e paga una tariffa fissa.
• I tuoi investitori o partner finanziari hanno iniziato a chiedere una previsione dei costi mensili.
• Il prodotto è in esecuzione in più di una regione di Azure o cloud.

Fino ad allora, il processo snello descritto in questo articolo, che include tag, budget, un gate di valutazione e una revisione mensile, è lo strumento giusto. Resistere alla tentazione di adottare strumenti FinOps aziendali in anticipo. Aggiunge sovraccarico del processo prima di aggiungere valore.

Elenco di controllo di riferimento

Usare gli elementi seguenti come elenco di controllo per la revisione mensile. Ogni elemento è associato a una sezione di questo articolo.

• Tutte le risorse di intelligenza artificiale sono contrassegnate con costCenter, tenantworkload, e env.
• Esiste un dashboard di Gestione costi, è raggruppato per tag e viene esaminato ogni settimana.
• Le richieste di sistema sono sufficientemente stabili per i riscontri nella cache dei prompt.
• Il lavoro asincrono, ad esempio incorporamenti, valse e riepiloghi, viene eseguito nell'API Batch.
• Il router invia almeno il 60% del traffico a un modello più economico senza regressione di valutazione.
• I carichi di lavoro GPU si riducono fino a zero fuori dall'orario lavorativo oppure utilizzano istanze spot per i processi batch.
• La mediana del numero di recuperi per turno è pari o inferiore a due.
• La strategia multi-tenant viene selezionata esplicitamente: condivisa con filtro oppure dedicata.
• Sono applicati budget e limiti di frequenza per ogni tenant.
• Ogni richiesta, modello o modifica del routing esegue il gate eval prima dell'unione.