Costi AI e GPU Cloud 2026: FinOps che F…

Aggiornato: 23 giugno 2026

I costi di AI e GPU nel cloud nel 2026 si tagliano lavorando su tre leve: scegliere il giusto modello di consumo (on-demand, batch, provisioned throughput o spot), sfruttare il prompt caching e i batch endpoint per ridurre fino al 90% il costo per token, e fare rightsizing sulle famiglie GPU corrette (H100 per training pesante, L40S o L4 per inference, Inferentia2/Trainium2 per chi può ricompilare). In un anno tipico ho visto bollette di training scendere da 2,1 milioni di dollari a 640 mila semplicemente cambiando scheduler e mix di istanze, senza toccare il modello.

Le istanze GPU on-demand (p5.48xlarge, ND H100 v5, A3) costano tra 39 e 98 dollari l'ora: lo spot le porta a 12-40 dollari ma richiede checkpointing serio.
Prompt caching su Bedrock, Azure OpenAI e Vertex AI riduce il costo dei token cached fino al 90% e la latenza fino all'85% per prompt ripetitivi (RAG, agenti).
Le batch API di Bedrock, OpenAI e Vertex offrono uno sconto fisso del 50% sui token rispetto alle chiamate sincrone, con SLA di 24 ore.
Provisioned Throughput (PTU su Azure, PT su Bedrock) conviene oltre ~70.000 richieste al giorno con prompt costanti; sotto soglia perdi soldi.
Inferentia2 e Trainium2 su AWS, e le TPU v5e su GCP, abbattono il costo per milione di token del 40-70% rispetto a H100, se il modello è supportato.
Una FinOps pipeline matura per AI separa training (capex-like, sconto via Savings Plans o committed use) da inference (opex variabile, ottimizzazione per token).

Perché i costi AI nel cloud stanno esplodendo nel 2026

Nel 2026 le voci "GPU compute" e "model inference" sono diventate, in molte aziende che seguo, la seconda o addirittura la prima voce della bolletta cloud, sopra database e storage. Il motivo è strutturale: una H100 in p5.48xlarge costa circa 98 dollari l'ora on-demand, e un singolo job di fine-tuning su Llama 3.3 70B con 8 GPU per 36 ore vale ~28.000 dollari. Moltiplicato per cinque data scientist che fanno experiment tracking senza budget, sono 140.000 dollari al mese che spesso non finiscono in nessun cost center.

Sul lato inference il problema è opposto: tante chiamate piccole con prompt lunghi e ripetitivi. Un'app RAG con 50.000 utenti attivi mensili può facilmente generare 8 miliardi di token in input al mese su Claude o GPT-4o, con bollette tra 12.000 e 60.000 dollari a seconda del modello e di quanto il team usa caching e batching. Quasi sempre, all'audit, scopro che nessuno aveva attivato il prompt caching introdotto da Anthropic e poi ripreso da OpenAI e Google, e si stava pagando il prezzo pieno su ogni system prompt da 4.000 token ripetuto migliaia di volte al giorno. Onestamente, è il primo posto in cui guardo.

La buona notizia è che ogni hyperscaler ha messo a disposizione, negli ultimi 18 mesi, strumenti specifici per ridurre i costi AI: AWS ha lanciato Bedrock prompt caching e batch inference, Azure ha esteso le PTU (Provisioned Throughput Units) con sconti committed use, GCP ha introdotto context caching su Vertex AI per Gemini 2.0. Sapere quale strumento applicare a quale workload è la differenza tra una bolletta sostenibile e un blocco di budget a metà trimestre. Per chi parte da zero su questo tema, conviene anche rivedere le basi di tagging e cost allocation FinOps, perché senza tag non si fa nessun FinOps su AI.

Prezzi reali delle istanze GPU su AWS, Azure e GCP

Il primo passo per qualunque strategia FinOps su AI è conoscere il prezzo reale delle istanze GPU, non quello del listino di sei mesi fa. Ecco i numeri aggiornati al Q2 2026 per le famiglie più diffuse nelle region us-east-1, swedencentral e us-central1.

Istanza	GPU	Cloud	On-demand $/h	Spot $/h (medio)	3y RI/SP $/h
p5.48xlarge	8x H100 80GB	AWS	98.32	32-48	52.10
p5e.48xlarge	8x H200 141GB	AWS	112.40	40-58	61.80
g6e.48xlarge	8x L40S 48GB	AWS	30.18	9-14	16.40
inf2.48xlarge	12x Inferentia2	AWS	12.98	4.5-6	6.85
trn2.48xlarge	16x Trainium2	AWS	44.10	n/d	23.50
ND H100 v5 (8x)	8x H100 80GB	Azure	96.80	28-42	54.20
NC H100 v5 (1x)	1x H100 NVL	Azure	13.62	3.8-6.2	7.40
a3-highgpu-8g	8x H100 80GB	GCP	88.10	26-40	49.50
a3-ultragpu-8g	8x H200 141GB	GCP	104.60	32-48	57.80
ct5lp-hightpu-8t	TPU v5e (8 chip)	GCP	10.40	3.1-4.2	6.20

Due osservazioni che faccio sempre quando porto questa tabella in un workshop. Primo: la differenza tra on-demand e spot su H100 è del 60-70%, ma la disponibilità spot a 8-GPU per più di 4 ore di fila è oggi limitata a poche AZ (us-east-1a/d, westus3, europe-west4). Secondo: g6e e NCadsH100 v5 sono spesso ignorate dai team data science che chiedono "una H100", ma per inference su modelli ≤30B parametri quantizzati a INT8 sono 3 volte più economiche con throughput comparabile.

Se il vostro mix è prevalentemente training, valutate istanze spot con checkpointing aggressivo e Karpenter o AKS spot node pools. Se è inference 24/7, partite da un baseline di Savings Plans a 1 anno sulle istanze più piccole e scalate l'extra su on-demand.

Come ridurre i costi di training di un modello AI

Il training è la voce più facile da ottimizzare perché è asincrona, tollerante alle interruzioni se fatta bene, e ha pattern di consumo prevedibili. La leva numero uno è lo spot. Su un cluster di fine-tuning con 4 nodi p5.48xlarge per 48 ore, passare da on-demand a spot porta il costo da ~18.900 a ~7.200 dollari, con una probabilità di interruzione realistica del 15-25% per job, gestibile con checkpoint ogni 500 step.

Un esempio concreto di configurazione SageMaker Training Jobs con managed spot:

import sagemaker
from sagemaker.pytorch import PyTorch

estimator = PyTorch(
    entry_point="train.py",
    role=role,
    instance_type="ml.p5.48xlarge",
    instance_count=4,
    framework_version="2.4.0",
    py_version="py311",
    use_spot_instances=True,        # abilita lo spot, sconto 60-70%
    max_run=72 * 3600,              # 72h hard limit
    max_wait=96 * 3600,             # max attesa capacita spot
    checkpoint_s3_uri="s3://finops-ml/ckpt/",
    checkpoint_local_path="/opt/ml/checkpoints",
    hyperparameters={
        "save_steps": 500,          # checkpoint frequenti
        "gradient_checkpointing": True,
        "bf16": True,
    },
)
estimator.fit({"train": "s3://finops-ml/data/"})

La seconda leva è il data parallelism efficiente: FSDP o DeepSpeed ZeRO-3 con activation checkpointing permettono di mettere modelli da 70B su 4 nodi invece di 8, dimezzando la spesa. Terza: usare gradient accumulation per ridurre i nodi a parità di effective batch size. Quarta: pre-trainare su TPU v5e o Trainium2 se il framework lo supporta, abbattendo il costo per FLOP del 40-60%.

Come ottimizzare i costi di inference e API LLM

Sul lato inference ci sono due modelli operativi: self-hosted (voi gestite le GPU con vLLM, TGI o TensorRT-LLM) o managed API (Bedrock, Azure OpenAI, Vertex AI). Per workload sotto i 5 miliardi di token al mese, le API managed sono quasi sempre più economiche perché eliminano il costo del 30-50% di idle capacity. Sopra quella soglia, self-hosted su L40S o Inferentia2 con vLLM batch dynamic vince con margini del 40-65%.

Le tre tecniche di ottimizzazione che applico sempre prima di scegliere la piattaforma:

Quantizzazione INT8 o INT4: AWQ o GPTQ su Llama 3.3 70B passano da 140 GB di VRAM a 35 GB, ovvero da p5 a g6e. Sconto ~65% sul costo orario.
Speculative decoding con un draft model piccolo (es. Llama 3.2 1B che propone token al 70B): throughput 2-3x a parità di hardware.
Dynamic batching con vLLM o TensorRT-LLM: a parità di GPU si passa da 80 a 600 token/s aggregati, riducendo le repliche necessarie.

Sulle API managed, oltre al prompt caching (vedi sezione dedicata), la differenza la fanno i model tier. Per la maggior parte dei task aziendali (classificazione, estrazione, summarization breve), Claude Haiku 4.5, GPT-4o mini o Gemini 2.0 Flash costano 12-20 volte meno del tier flagship con quality drop accettabile sotto i 90 percentili. Fate sempre un A/B test con LLM-as-a-judge prima di scalare il modello.

Prompt caching e batch API: la leva più sottovalutata

Il prompt caching è probabilmente la singola leva con il miglior ROI introdotta nel 2025-2026 dai provider di LLM, e il 70% dei team che incontro non l'ha ancora attivato. Funziona così: il provider salva il KV-cache del prefisso del prompt (system prompt, few-shot, documenti RAG statici) e nelle chiamate successive entro 5 minuti (o più, con cache extended) fattura quei token al 10% del prezzo normale.

Un caso reale, anonimizzato: un cliente con un agente customer-support su Claude Sonnet 4 inviava un system prompt da 6.200 token + 3 documenti RAG da 4.000 token ciascuno, totale ~18.200 token di prefisso costante. Su 280.000 chiamate al mese si parlava di 5,1 miliardi di token in input a 3$/M, ovvero 15.300$/mese solo di prefisso. Attivando il prompt caching sul system prompt e sui documenti RAG, il costo è sceso a circa 1.700$/mese (cache hit ratio del 92%), con latenza p50 ridotta da 1,8 a 0,4 secondi. Una mattina di lavoro, davvero.

Esempio di chiamata Bedrock Converse con cache point:

import boto3

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")

response = bedrock.converse(
    modelId="anthropic.claude-sonnet-4-20250514-v1:0",
    system=[
        {"text": LARGE_SYSTEM_PROMPT},        # 6k token, riusato
        {"cachePoint": {"type": "default"}},   # cache fino a qui
    ],
    messages=[
        {
            "role": "user",
            "content": [
                {"text": RAG_CONTEXT},          # 12k token RAG
                {"cachePoint": {"type": "default"}},
                {"text": user_question},        # variabile
            ],
        }
    ],
    inferenceConfig={"maxTokens": 1024, "temperature": 0.2},
)

La seconda leva, complementare, è la batch API. Bedrock Batch, OpenAI Batch e Vertex AI Batch Prediction offrono uno sconto fisso del 50% sui token rispetto all'API sincrona, in cambio di un SLA di completamento a 24 ore. Per tutti i workload non interattivi (generazione di descrizioni prodotto, embedding di archivi storici, classificazione di log, valutazione LLM-as-a-judge) il batch è obbligatorio. Su un cliente e-commerce abbiamo spostato 38 milioni di descrizioni prodotto da sincrono a batch, risparmiando 11.400 dollari al mese senza alcuna penalità di prodotto.

Bedrock vs Azure OpenAI vs Vertex AI: quale conviene

Domanda che ricevo ogni settimana. La risposta dipende dal modello che dovete servire e dal pattern di traffico. Ecco come la sintetizzo nei rapid assessment FinOps.

Dimensione	AWS Bedrock	Azure OpenAI	Vertex AI
Modelli flagship	Claude 4.x, Llama 3.3, Mistral Large 2	GPT-4.1, o4, GPT-4o	Gemini 2.0/2.5, Claude (in alcune region)
Pricing on-demand	Per token, listino pubblico, sconto cached 90%	Per token (Standard) o PTU (riservato)	Per token + context caching nativo
Provisioned throughput	PT a ore con commit 1m/6m	PTU con commit mensile o annuale	Provisioned throughput per Gemini, commit mensile
Batch (sconto)	Bedrock Batch -50%	Batch API -50%	Batch Prediction -50%
Sconti committed use	Savings Plans + Bedrock PT	EA + PTU yearly fino a -55%	CUD su PT, fino a -60%
Costo medio per 1M token (Claude/GPT classe)	3$ in / 15$ out (Sonnet 4)	2.50$ in / 10$ out (GPT-4o)	1.25$ in / 5$ out (Gemini 2.5 Pro)

La regola pratica: se il vostro stack è già su AWS e usate Claude come modello principale, Bedrock minimizza i costi di egress e il prompt caching è eccellente. Se siete su Microsoft 365 enterprise e avete già un Enterprise Agreement con Microsoft, Azure OpenAI con PTU annuali ottiene gli sconti più alti (>50%) ma vi vincola a un commit. Vertex AI vince sul rapporto qualità/prezzo puro su Gemini 2.5 Pro e ha il context caching più flessibile (fino a 24h di TTL nativi).

Per chi vuole confronti più strutturali sul lato infrastrutturale, vale la pena vedere anche la nostra guida agli sconti a impegno cloud: la logica PTU/PT è molto simile a quella delle Reserved Instances classiche.

Inferentia, Trainium e TPU: vale la pena migrare?

Custom silicon è il modo più aggressivo per abbattere il costo per token, ma porta un costo nascosto: porting, debugging e mancanza di feature parity con CUDA. La mia regola, dopo tre migrazioni andate male: migrate solo se siete sopra i 50 miliardi di token/mese di inference o avete un budget training annuale > 500.000$.

Numeri reali del Q2 2026:

Inferentia2: ~0,50$ per milione di token output su Llama 3.3 70B vs 3,2$ su H100 a parità di latenza p95. Supporto buono per modelli Llama, Mistral, Stable Diffusion via Optimum Neuron.
Trainium2: 30-40% più economico di H100 per FLOP, ma richiede Neuron SDK 2.20+ e debugging più complicato. Il sweet spot è il continued pretraining e fine-tuning di modelli supportati.
TPU v5e: il miglior costo/perf per inference Gemini e per training fino a 70B con JAX o PyTorch/XLA. Disponibilità ottima in europe-west4.
TPU v5p: training enterprise, prestazioni in classe H100 a costo inferiore del 25-35%, ma fuori dai grandi cloud lock-in è poco pratico.

Se vi interessa approfondire il tema del lock-in legato a custom silicon vs commodity GPU, la documentazione di riferimento è il AWS Neuron SDK per Inferentia/Trainium e Vertex AI pricing per le TPU.

Costruire una FinOps pipeline per carichi AI

L'errore più comune che vedo è applicare le pratiche FinOps classiche (tag, budget, alert) ai workload AI come fossero EC2. Non funziona, per due motivi: il costo principale è "per token" e non "per ora", e il consumo è guidato da decisioni di prodotto (lunghezza dei prompt, frequenza di refresh dei document store) che spesso nessuno traccia. Una pipeline FinOps per AI matura ha quattro componenti.

Token-level cost allocation. Ogni chiamata API deve essere arricchita con tag come team, feature, environment, model_tier. Su Bedrock si fa via inference profile + application inference profile, su Azure via API key per tenant, su Vertex via Cloud Logging custom labels. Senza questo, il chargeback è impossibile.
Unit economics dashboard. Non guardate solo $/mese: tracciate $/utente attivo, $/conversazione, $/documento processato. Una bolletta da +30% può essere positiva se il numero di utenti è raddoppiato, e negativa se gli utenti sono fermi ma i prompt sono cresciuti.
Anomaly detection sui token. Le anomalie sui costi AI hanno pattern diversi dagli EC2: spesso sono dovute a un bug che fa un loop infinito di chiamate, o un nuovo system prompt 4x più lungo. Strumenti come CloudWatch Anomaly Detection con metrica custom token_count o le pratiche descritte nella nostra guida al rilevamento anomalie costi cloud vanno adattati alle metriche per modello.
Model routing layer. Mettete un proxy (LiteLLM, Portkey, Bedrock Application Inference Profile) tra app e modelli e routate per intent: query semplici → Haiku/Mini, query complesse → Sonnet/GPT-4o, query agentiche → Opus/o4. Risparmi tipici 40-60% senza degrado UX percettibile.

Domande frequenti

Quanto costa addestrare un LLM da zero su AWS o GCP nel 2026?

Un modello da 7B parametri pre-trainato su ~1T token costa circa 180-250 mila dollari su un cluster di 16 H100 spot per ~28 giorni; un 70B sui 2-3,5 milioni di dollari. Per la maggior parte delle aziende fine-tunare un modello open weights è 50-100x più economico e raggiunge il 90% della qualità di un pretrain custom.

È sicuro usare istanze GPU spot per training di modelli grandi?

Sì, a patto di tre cose: checkpoint ogni 250-500 step su S3 o Cloud Storage, framework con resume nativo (HuggingFace Trainer, DeepSpeed, FSDP), e max_wait generoso per gestire l'attesa di capacità. Su training run di 24-72 ore vedo un completion rate del 92-96%.

Quando conviene Provisioned Throughput rispetto al pay-per-token?

La soglia di break-even per Bedrock PT o Azure PTU si trova intorno a 65-80 mila richieste al giorno con prompt costanti e traffico 24/7. Sotto quella soglia, il pay-per-token con prompt caching è quasi sempre più economico e flessibile. Sopra, il PT/PTU offre latenza prevedibile e sconti fino al 55% con commit annuale.

Come si fa cost allocation per chiamate LLM tra più team?

Tre approcci: (1) un'API key Bedrock/Azure/Vertex per team con tag a livello di account, (2) un proxy interno come LiteLLM o Portkey che logga costo e team per ogni call, (3) Application Inference Profile su Bedrock che permette il tagging nativo. Il proxy è la soluzione più portabile multi-cloud.

Il prompt caching funziona anche su Azure OpenAI e Vertex AI?

Sì. Azure OpenAI ha il prompt caching su GPT-4o e o-series dal 2025 (sconto 50% sui token cached, attivazione automatica oltre i 1024 token). Vertex AI ha il context caching esplicito su Gemini con TTL configurabile fino a 24 ore e sconto fino al 75% sui token in cache.