Una H100 su p5.4xlarge costa 5.022$ al mese: servono ~7.300 token/s per pareggiare Bedrock

Per eseguire gpt-oss-120b su una singola H100 in EC2 p5.4xlarge servono 5.022 dollari al mese. Per pagare quanto Amazon Bedrock con lo stesso modello, il nodo deve macinare circa 7.300 token al secondo, sempre, giorno e notte. Lo ha calcolato Evgeny Anikiev usando i listini ufficiali AWS e un setup replicabile su Kubernetes con EKS¹.

L’analisi mette a confronto un prezzo per token, quello di Bedrock, con un prezzo per ora, quello dell’istanza GPU. Il break-even nasce da lì: quanta produzione continua serve per far valere l’investimento in GPU dedicate con pesi open-weight identici a quelli offerti da Bedrock. Se il traffico non raggiunge e non regge quel livello, Bedrock costa meno. L’autogestione torna invece utile quando serve un modello che Bedrock non ha¹.

I numeri arrivano dall’AWS Price List API al 23 ottobre 2026, regione US East N. Virginia, e coprono tre famiglie: gpt-oss-120b, gpt-oss-20b e Llama 3.3 70B. Per ciascuna, Anikiev abbina la capacità GPU necessaria e deriva il volume di pareggio in token al mese e in token al secondo. Il dato più netto è quello su gpt-oss-120b con una H100: 5.022 dollari al mese di costo stimato e soglia a ~7.300 token/s per stare al passo con Bedrock¹.

Il post chiarisce anche cosa nascondono le due metriche di prezzo. Il costo per token sintetizza risorse, gestione e margine in un numero unico. Il costo orario della GPU espone invece tutta la capacità acquistata, usata o meno. È qui che il pareggio si gioca: una scheda poco sfruttata pesa sul conto più di quanto appaia guardando solo il costo per token. Viceversa, un throughput alto e stabile diluisce i costi fissi¹.

Per togliere teoria e mettere numeri, Anikiev fornisce configurazioni concrete. Una NodePool di Karpenter per scalare il cluster EKS con istanze capaci di ospitare il modello. Un Deployment vLLM per misurare throughput reale con i pesi open-weight scelti. Con questi manifest è possibile replicare i test, osservare i token al secondo ottenuti e confrontarli con la soglia di pareggio calcolata¹.

Il profilo dell’autore spiega l’attenzione ai dettagli operativi. Anikiev è un DevOps engineer certificato AWS, con oltre dieci anni su automazione build, CI/CD e Kubernetes in produzione. L’approccio resta pratico: partire dai listini, scegliere la regione, fissare un modello, poi confrontare il flusso di token effettivo con il costo mensile della GPU. La nota di cautela è implicita nei calcoli: la soglia è calcolata su carico continuo, non su picchi brevi¹.

Per team che valutano il self-host, il messaggio è netto: prima di allocare GPU, serve una misura affidabile del throughput e della stabilità del traffico, idealmente con i manifest vLLM e Karpenter proposti, nella regione prevista e con gli stessi pesi. Chi invece usa già Bedrock può leggere i numeri come un tetto di efficienza: se non si raggiunge quel ritmo, non c’è risparmio da inseguire su EKS con lo stesso modello¹.

Poiché i calcoli si basano sui listini del 23 ottobre 2026 e su una regione specifica, ogni variazione di prezzi o area geografica richiede di rifare i conti con lo stesso metodo esposto da Anikiev¹.