Oltrepassamento dei costi di Claude da 1,8 milioni di dollari in Amazon: come prevenire una spesa AI fuori controllo

Introduzione

Secondo quanto riportato, un progetto interno di Amazon che utilizzava Anthropic Claude Sonnet ha accumulato una fattura di 1,8 milioni di dollari, superando il budget pianificato del 860%, rimanendo non rilevato per cinque mesi e non riuscendo infine a entrare in produzione.

Il compito in sé suona piuttosto ordinario: abbinare le informazioni sugli autori con le schede prodotto sulla piattaforma di e-commerce di Amazon.

La vicenda è stata riportata dal Financial Times dopo che un ingegnere senior di Amazon ha discusso di molteplici casi di superamento dei costi legati all'AI durante una riunione interna dei dipendenti. Essa rappresenta un utile monito per qualsiasi organizzazione che passa dall'uso occasionale di chatbot a flussi di lavoro automatizzati, poiché questi possono generare migliaia o milioni di chiamate a modelli a pagamento ogni giorno.

I difetti del software tradizionale tendono a sprecare tempo di ingegneria o a produrre output errati. I difetti nei flussi di lavoro AI basati sulla misurazione possono causare entrambe le cose, continuando a generare costi per token, strumenti, storage e calcolo per ogni minuto in cui rimangono attivi.

La lezione non è che le aziende dovrebbero smettere di usare l'AI, ma che i processi AI autonomi o ad alto volume richiedono controlli finanziari altrettanto chiari quanto i loro controlli di sicurezza e qualità.

Cosa è successo internamente in Amazon

Secondo fonti informate, Amazon ha utilizzato Claude Sonnet in un progetto volto ad abbinare le informazioni sugli autori con le schede prodotto sulla sua piattaforma di vendita al dettaglio.

Secondo quanto riportato, la distribuzione:

• È costata 1,8 milioni di dollari
• Ha superato il budget assegnato dell'860%
• Ha impiegato cinque mesi per essere rilevata
• Non è riuscita a entrare in produzione

Gli ingegneri senior hanno definito alcuni errori di codifica legati all'AI come "catastroficamente costosi".

Amazon ha risposto affermando che sta sperimentando, imparando e migliorando il proprio utilizzo di questa tecnologia, inclusa la gestione dell'efficienza dei costi. L'azienda ha inoltre dichiarato che presentare alcuni casi isolati come pratica comune non riflette accuratamente l'uso dell'AI nell'organizzazione più ampia di Amazon.

Entrambe le affermazioni potrebbero essere vere.

Questi eventi potrebbero aver coinvolto solo una piccola parte dei team di Amazon, ma rivelano anche un problema di controllo che altre organizzazioni dovrebbero prendere seriamente.

Il difetto di codifica specifico non è ancora stato divulgato

La segnalazione iniziale in cinese attribuiva il superamento dei costi a un programma senza limiti di frequenza delle chiamate che continuava a inviare richieste in ciclo continuo.

Questa spiegazione è plausibile, ma non è ancora confermata dagli attuali resoconti pubblici.

Il Financial Times ha descritto errori di codifica, controlli di spesa deboli e ritardi nel rilevamento. Non ha pubblicato un'analisi post-mortem tecnica che mostri:

• Il codice sorgente
• Il difetto preciso
• Se il processo fosse un ciclo infinito
• Il numero di chiamate al modello
• Il numero di token di input o output
• Se il modello fosse stato accessibile direttamente o tramite Amazon Bedrock
• La versione del modello
• La configurazione dell'uso degli strumenti
• I componenti infrastrutturali che hanno generato i costi

La conclusione più sicura è più cauta: una distribuzione fallita di Claude Sonnet ha prodotto una fattura enorme e i sistemi di controllo di Amazon non sono riusciti a rilevare il problema per cinque mesi.

A meno che Amazon non pubblichi un rapporto tecnico sull'incidente, qualsiasi spiegazione più dettagliata dovrebbe essere etichettata come deduzione.

Non è l'unico problema di costi

Superamento dei costi

Secondo quanto riferito, lo stesso rapporto interno ha discusso di almeno altri due casi.

Progetto	Costi non previsti segnalati
Strumento di audit finanziario	Circa 541.000 dollari
Progetto logistico volto ad accelerare i tempi di consegna	Circa 134.000 dollari

Secondo quanto riportato, il superamento dei costi logistici è stato rilevato solo dopo più di due settimane.

Questi casi sono di dimensioni inferiori rispetto al progetto di abbinamento autori da 1,8 milioni di dollari, ma indicano lo stesso schema: quando nessun guasto tecnico costringe il processo a fermarsi, i sistemi AI basati sull'utilizzo possono continuare ad accumulare costi.

I processi batch tradizionali possono bloccarsi, esaurire la memoria o non superare i test.

I processi AI, invece, possono rimanere tecnicamente sani ma economicamente collassati.

Anche se un progetto non produce più risultati utili, può continuare a ricevere risposte API di successo, scrivere log, chiamare strumenti, ritentare attività o elaborare record a basso valore.

Perché i guasti ai costi dell'AI si comportano in modo diverso

I costi delle applicazioni tradizionali sono generalmente legati a unità relativamente familiari:

• Tempo server
• Capacità del database
• Storage
• Trasferimento di rete
• Ore di lavoro umano

I flussi di lavoro AI possono invece incrementare simultaneamente più livelli tariffari basati sul consumo:

• Token di input
• Token di output
• Contesto cache e non cache
• Token di ragionamento
• Chiamate a strumenti
• Ricerche web
• Sessioni di esecuzione del codice
• Ricerca vettoriale
• Ritentativi degli agenti
• Processi di lavoro paralleli
• Cronologie di conversazione lunghe
• Risorse di calcolo cloud
• Log e output di storage

Ciò produce un effetto moltiplicatore.

Supponiamo che un'attività invii un prompt molto lungo, generi una risposta corposa, chiami due strumenti, ritenti dopo un errore e passi la cronologia completa al passaggio successivo. Se l'applicazione elabora milioni di record, un piccolo errore di progettazione può diventare estremamente costoso.

Da un punto di vista operativo, l'applicazione può apparire normale. Le richieste restituiscono ancora 200 OK. I processi di lavoro rimangono attivi. Le code continuano a ridursi. La fattura è spesso il primo posto in cui il problema emerge.

Un modello di costo semplice per i flussi di lavoro AI

Prima di avviare un processo AI automatizzato, stima il costo per ogni attività aziendale completata.

Un modello semplificato è il seguente:

Componente di costo	Calcolo
Costo di input	Numero di token di input × prezzo di input del modello
Costo di output	Numero di token di output × prezzo di output del modello
Costo degli strumenti	Numero di chiamate a strumenti × prezzo dello strumento
Costo dei ritentativi	Numero di tentativi falliti o ripetuti × costo medio per tentativo
Costo dell'infrastruttura	Calcolo, storage, database, rete e log
Costo della revisione umana	Tempo di revisione × tariffa completa inclusa manodopera

L'indicatore chiave non è semplicemente il costo per token.

È:

Costo totale per risultato aziendale completato con successo

Una richiesta più economica, se ha un tasso di fallimento più alto, richiede chiamate ripetute o genera più revisione umana, può comunque produrre un flusso di lavoro più costoso.

Allo stesso modo, un modello più potente che completa l'attività in meno passaggi può in definitiva costare meno.

Primo controllo: designare un responsabile finanziario per ogni attività AI

Ogni flusso di lavoro AI in produzione dovrebbe avere un responsabile nominato, competente sia per il comportamento tecnico che per la spesa.

Il responsabile dovrebbe conoscere:

• Il volume di attività previsto
• Il modello utilizzato
• Il costo previsto per ciascuna voce
• Il budget giornaliero e mensile
• Il costo massimo per singola esecuzione
• Le condizioni per l'arresto

Il flusso di lavoro

• Le persone da avvisare
• Il processo per approvare limiti superiori

Quando un singolo operatore può emettere richieste in continuazione, un budget vago a livello di progetto non è sufficiente.

I budget dovrebbero esistere su più livelli:

Livello	Esempio
Organizzazione	Massimale mensile della spesa AI
Team	Quota mensile di una business unit
Applicazione	Budget di un prodotto o flusso di lavoro
Ambiente	Limiti separati per sviluppo, pre-produzione e produzione
Job	Costo massimo di un batch
Utente o tenant	Quota di utilizzo per cliente
Sessione agente	Numero massimo di token, passaggi, strumenti e durata

I livelli inferiori forniscono il meccanismo di arresto più rapido ed efficace.

Impostare limiti rigidi all'interno dell'applicazione

Gli avvisi di fatturazione cloud sono importanti, ma non sostituiscono i controlli a livello applicativo.

L'applicazione dovrebbe fermarsi o richiedere un'approvazione quando raggiunge un confine prestabilito.

I limiti utili includono:

• Numero massimo di richieste per attività
• Numero massimo di passaggi dell'agente
• Numero massimo di ritentativi
• Numero massimo di token di input
• Numero massimo di token di output
• Lunghezza massima del contesto
• Numero massimo di chiamate a strumenti
• Numero massimo di thread paralleli
• Durata massima
• Costo massimo in dollari per job
• Numero massimo di record da elaborare prima della revisione

Questi controlli dovrebbero essere disattivati per impostazione predefinita.

Se il servizio di tracciamento dei costi non è disponibile, o se l'applicazione non riesce a determinare il budget rimanente, il comportamento più sicuro è solitamente quello di mettere in pausa piuttosto che continuare all'infinito.

Utilizzare un interruttore di emergenza indipendente dall'agente

Gli agenti autonomi non dovrebbero controllare la propria autorità di spesa finale.

Un servizio indipendente dovrebbe essere in grado di:

• Disabilitare le chiavi API
• Rifiutare le chiamate al modello
• Mettere in pausa le code
• Ridurre i thread di lavoro a zero
• Bloccare gli strumenti esterni
• Revocare i ruoli
• Interrompere le attività pianificate
• Richiedere l'approvazione umana prima della ripresa

Anche se l'agente rimane intrappolato in un ciclo di ritentativi o produce messaggi di stato fuorvianti, l'interruttore di emergenza dovrebbe rimanere operativo.

Testarlo prima della messa in produzione.

Un controllo mai utilizzato è solo teoria.

Monitorare ogni chiamata al modello

Le organizzazioni che utilizzano Amazon Bedrock possono abilitare la registrazione delle chiamate al modello per le chiamate bedrock-runtime supportate.

AWS afferma che questi log possono includere dati di richiesta e risposta, metadati, identificatori del modello, identificatori della richiesta, informazioni sull'identità e utilizzo dei token. Le destinazioni dei log possono includere Amazon CloudWatch Logs e Amazon S3.

La registrazione delle chiamate è disattivata per impostazione predefinita.

Il team dovrebbe abilitare solo i dati necessari per l'osservabilità e applicare controlli adeguati di privacy, sicurezza, conservazione e mascheramento. Prompt e output possono contenere informazioni sensibili dell'azienda o dei clienti.

Come minimo, i registri di monitoraggio dei costi dovrebbero includere:

• Timestamp
• Applicazione
• Ambiente
• Team o centro di costo
• Modello
• Utente o tenant
• Numero di token in input
• Numero di token in output
• Utilizzo della cache
• Chiamate agli strumenti
• Numero di tentativi
• Identificatore del job
• Costo stimato della richiesta
• Risultato aziendale
• Errori o motivi di escalation

In questo modo è possibile associare la fatturazione a attività specifiche, invece di scoprire un importo complessivo enorme solo durante la revisione finanziaria mensile.

Utilizzare AWS Budgets per monitorare i costi di Claude su Bedrock

AWS Budgets consente di monitorare costi o utilizzo rispetto a soglie definite e inviare notifiche. Le azioni di budget possono inoltre applicare misure di controllo quando le soglie vengono superate, come policy IAM o service control policy. A seconda della configurazione, le azioni possono essere eseguite automaticamente o attendere l'approvazione manuale.

Un dettaglio AWS importante e facilmente trascurato.

La documentazione di AWS Cost Anomaly Detection indica che il servizio non monitora i prodotti di terze parti venduti tramite AWS Marketplace, inclusi i modelli linguistici di terze parti offerti tramite Amazon Bedrock, come Anthropic Claude.

Questi costi compaiono comunque in Cost Explorer e nella fatturazione, ma AWS consiglia di utilizzare AWS Budgets per ricevere avvisi su tali spese.

I budget possono utilizzare filtri per entità di fatturazione per tracciare in modo più preciso le spese del Marketplace.

Questo è esattamente il tipo di dettaglio di configurazione che può creare un falso senso di sicurezza. Un'azienda potrebbe abilitare il rilevamento delle anomalie credendo che tutti i costi dei modelli siano coperti, mentre una specifica categoria di fatturazione non viene inclusa.

Non trattare AWS Budgets come un interruttore in tempo reale

La documentazione AWS indica che lo stato dei budget viene aggiornato più volte al giorno.

La documentazione avverte inoltre che i costi possono continuare ad aumentare prima o dopo la consegna della notifica.

Ciò significa che AWS Budgets è utile per la governance finanziaria, ma da solo potrebbe non essere abbastanza rapido per bloccare agenti ad alta produttività.

Lo stack di controllo dovrebbe includere:

1. Contatori a livello di richiesta nell'applicazione
2. Metriche di utilizzo quasi in tempo reale
3. Limiti massimi rigidi per job e per sessione
4. Avvisi di budget sul cloud
5. Azioni di budget automatizzate quando opportuno
6. Revisioni finanziarie giornaliere per i rilasci ad alto rischio

Più velocemente un flusso di lavoro consuma denaro, più vicino al punto di chiamata devono trovarsi i controlli.

Utilizzare il rilevamento delle anomalie per i costi coperti dal servizio

AWS Cost Anomaly Detection utilizza modelli di machine learning per identificare modelli di spesa anomali e aiutare a individuare le possibili cause principali.

AWS dichiara che il servizio valuta i dati di fatturazione elaborati circa tre volte al giorno.

Può rilevare efficacemente crescite inattese nei servizi AWS, account, regioni, tipi di utilizzo e tag di allocazione dei costi.

Per i sistemi di intelligenza artificiale, può identificare anomalie nei costi di supporto relativi a calcolo, archiviazione, database o rete.

Tuttavia, il team dovrebbe ricordare la limitazione del Marketplace sopra menzionata e creare separatamente AWS Budgets per i costi dei modelli di terze parti quando necessario.

Trattare Service Quotas come confine di sicurezza, non come budget

Amazon Bedrock applica quote di servizio per l'inferenza dei modelli, inclusi limiti basati su token per i modelli e gli endpoint supportati.

Le quote possono prevenire una produttività illimitata, ma non sono progettate per essere budget finanziari precisi.

Le quote possono comunque consentire una spesa ben oltre i limiti previsti del progetto. Al contrario, aumentare le quote per risolvere problemi di capacità produttiva può rimuovere involontariamente un utile confine di sicurezza.

Pertanto, le modifiche alle quote dovrebbero richiedere:

• Una giustificazione aziendale
• Una previsione dei costi aggiornata
• Un'approvazione nominativa
• Soglie di avviso aggiornate
• Un piano di rollback
• Una revisione dopo l'aumento del traffico

I limiti di velocità e token dovrebbero essere considerati parte della progettazione del rischio di sistema, non solo ostacoli allo scaling.

Monitorare direttamente utilizzo e costi di Anthropic quando appropriato

Per le applicazioni che chiamano direttamente Anthropic, la console Anthropic offre report su costi e utilizzo.

I limiti API di Anthropic possono includere richieste al minuto, token di input al minuto, token di output al minuto e limiti di spesa legati al livello di utilizzo.

Questi limiti possono ridurre una produttività incontrollata, ma dovrebbero comunque essere integrati da controlli a livello applicativo.

Le organizzazioni con più team possono inoltre implementare un gateway LLM tra le applicazioni e il provider di modelli. Un gateway può centralizzare autenticazione, monitoraggio dell'utilizzo, budget, limiti di velocità, routing dei modelli e log di audit.

Il gateway diventa un componente critico per la sicurezza e pertanto deve essere gestito e revisionato con la stessa attenzione di qualsiasi altro livello di accesso alla produzione.

Iniziare con un piccolo campione rappresentativo

Secondo quanto riportato, un progetto Amazon avrebbe tentato di eseguire un'attività di corrispondenza dati su larga scala.

Una modalità di distribuzione più sicura è:

1. Eseguire 100 record rappresentativi.
2. Misurare accuratezza e costi.
3. Eseguire 1.000 record.
4. Controllare errori e distribuzione dei token.
5. Testare gli input peggiori.
6. Verificare i controlli di arresto.
7. Stimare la spesa per l'elaborazione completa.
8. Richiedere un'approvazione prima di elaborare l'intero set di dati.

Non fare inferenze basandosi solo sul record medio.

I documenti più lunghi, i record con mancata corrispondenza, i casi ambigui, i tentativi e i cicli degli agenti tendono a dominare il costo totale.

Utilizzare stime basate su percentili, ad esempio costi P50, P95 e P99 per attività.

Stabilire un tetto massimo di costo per ogni risultato utile

Il flusso di lavoro dovrebbe fermarsi quando chiamate aggiuntive al modello non sono più economicamente ragionevoli.

Per un sistema di corrispondenza autori, metriche utili potrebbero includere:

• Costo per autore associato con successo
• Costo per record revisionato manualmente
• Percentuale di record risolti automaticamente
• Tasso di corrispondenze errate
• Costo delle corrispondenze errate
• Risparmio rispetto all'elaborazione manuale
• Numero di chiamate al modello per risultato accettato

Un processo che costa $0,02 per richiesta può sembrare economico.

Se richiede 50 chiamate, metà dei record fallisce e il resto passa alla revisione manuale, l'economia reale può essere pessima.

Instradare i compiti semplici verso metodi più economici

Non ogni record richiede un modello all'avanguardia.

Una pipeline attenta ai costi può utilizzare:

1. Corrispondenza esatta
2. Join su database
3. Regole
4. Similarità tramite embedding
5. Modelli più piccoli
6. Modelli più forti solo nei casi ambigui
7. Revisione umana per decisioni ad alto rischio

Per i progetti di corrispondenza dati, il software tradizionale può risolvere la maggior parte dei casi a costi inferiori e in modo più deterministico.

L'LLM dovrebbe essere utilizzato solo quando l'ambiguità linguistica lo richiede realmente, non applicato automaticamente a ogni riga.

La stessa guida ai prezzi di Anthropic consiglia di scegliere il modello appropriato, utilizzare il caching dei prompt per contesti ripetuti, impiegare l'elaborazione batch per lavori non urgenti e monitorare i modelli di utilizzo.

Prevenire tentativi illimitati

I tentativi sono una fonte comune di spese implicite.

Una richiesta fallita può essere ritentata dall'applicazione, dal sistema di code, dall'SDK, dal gateway, dal gestore dei worker, dall'agente o dall'orchestratore del flusso di lavoro.

Quando più livelli ritentano in modo indipendente, un singolo compito logico può generare più richieste a pagamento.

Definire una strategia di retry unificata con:

• Un numero massimo ridotto di tentativi
• Backoff esponenziale
• Jitter
• Gestione esplicita degli errori non ritentabili
• Idempotenza
• Code di lettera morta
• Avvisi per fallimenti ripetuti
• Un budget per attività che includa tutti i costi correlati, inclusi i tentativi

Gli errori non dovrebbero creare cicli economici infiniti.

Separare le credenziali di sviluppo da quelle di produzione

Gli script di test non dovrebbero ereditare i limiti di produzione.

Utilizzare account o spazi di lavoro separati, chiavi API, ruoli IAM, budget, quote, log, fonti dati e permessi di rete.

Gli ambienti di sviluppo dovrebbero avere deliberatamente limiti di spesa bassi.

Un prototipo che entra accidentalmente in un ciclo dovrebbe fallire con una fattura minima, non ricevere quote di produzione di livello aziendale.

Revisionare il codice generato dall'AI come si revisiona un'infrastruttura finanziaria in produzione

L'incidente ha coinvolto un progetto scritto con l'ausilio dell'IA, ma il problema chiave non era se il codice fosse stato generato da un modello.

La questione importante è se il codice possa spendere denaro.

Qualsiasi componente in grado di avviare richieste a pagamento al modello dovrebbe essere sottoposto a revisione per:

• Terminazione dei cicli
• Comportamento dei tentativi
• Concorrenza
• Espansione delle code
• Contesto massimo
• Limiti delle chiamate agli strumenti
• Gestione dei timeout
• Meccanismi di annullamento
• Attribuzione dei costi
• Percorsi di errore
• Registrazione log
• Esecuzione dei budget
• Comportamento di arresto di emergenza

I test unitari dovrebbero includere scenari di fallimento economico.

Esempi: il modello non restituisce mai una risposta valida, consegna ripetuta di attività, crash del worker dopo una chiamata a pagamento, errori di limitazione ricorrenti, crescita del contesto a ogni turno a causa dell'output degli strumenti, e indisponibilità del servizio di stima dei costi.

Il percorso normale funzionante non è sufficiente.

Checklist per il controllo dei costi dell'IA a livello di produzione

Proprietà e pianificazione

• Un responsabile tecnico designato è responsabile della spesa.

• Sono documentati consumo e costo previsti per ogni risultato utile.

• [

[ ] Gli ambienti di sviluppo, pre-produzione e produzione dispongono di budget indipendenti.

• L'elaborazione su larga scala richiede un'approvazione esplicita.

Controllo delle applicazioni

• Ogni attività ha un limite massimo di richieste, token, passaggi, tentativi e tempo di esecuzione.

• Ogni sessione agente ha un budget espresso in dollari statunitensi.

• I servizi non agente possono interrompere il flusso di lavoro.

• Le attività vengono messe in pausa quando il budget residuo non è leggibile.

• Il lavoro duplicato viene prevenuto tramite l'idempotenza.

Monitoraggio

• Ogni chiamata al modello è attribuita a team, progetto, utente e attività.

• Vengono registrati input, output, cache, strumenti e tentativi di utilizzo.

• Sono configurati avvisi sia per la velocità di spesa che per la spesa totale.

• Durante il lancio iniziale in produzione è abilitata una revisione giornaliera.

• I team sono a conoscenza delle voci di costo non coperte dal rilevamento delle anomalie.

Qualità ed economia

• I costi sono misurati in base a ogni risultato aziendale conseguito.

• Quando appropriato, vengono utilizzati codice convenzionale e modelli più piccoli.

• Sono stati testati i costi nello scenario peggiore e ai percentili elevati.

• Sono inclusi i costi di revisione umana.

• Il flusso di lavoro si interrompe quando chiamate aggiuntive non apportano più valore.

Governance

• Il codice generato dall'AI è sottoposto a revisione umana.

• Gli aumenti di budget e quote richiedono approvazione.

• L'interruttore di emergenza è stato testato.

• La risposta agli incidenti coinvolge stakeholder finanziari e tecnici.

• I team rivedono la spesa dopo ogni modifica significativa di modelli o prompt.

Insegnamenti dalla risposta di Amazon

Secondo quanto riportato, gli ingegneri di Amazon stanno costruendo salvaguardie automatizzate per i futuri progetti di IA.

Questa è la direzione giusta.

ma l'automazione deve esistere su più livelli.

Un sistema di controllo maturo dovrebbe combinare limiti massimi rigidi a livello di applicazione, limiti di modello e gateway, budget cloud, azioni automatizzate, log di utilizzo, dashboard finanziari, approvazioni umane e revisioni periodiche.

L'azienda ha inoltre rimosso in precedenza una classifica interna che incoraggiava i dipendenti a massimizzare l'uso del proprio strumento di sviluppo Kiro. Secondo il Financial Times, la classifica favoriva il fenomeno del "tokenmaxxing", in cui i dipendenti aumentavano il consumo di token per migliorare la propria posizione.

È un promemoria utile: gli incentivi possono indebolire il controllo dei costi.

Se i dipendenti vengono premiati per un maggiore utilizzo dell'IA anziché per la creazione di valore aziendale misurabile, l'utilizzo aumenterà anche se i risultati non migliorano.

Le organizzazioni dovrebbero premiare i problemi risolti, i miglioramenti di qualità, il tempo risparmiato, i ricavi generati, i rischi ridotti e la diminuzione del costo unitario per risultato.

Il numero di token è una metrica di input, non di produttività.

Domande frequenti

Amazon ha davvero speso 1,8 milioni di dollari su Claude Sonnet?

Il Financial Times ha riferito che un progetto interno di Amazon che utilizzava Claude Sonnet ha accumulato una fatturazione di 1,8 milioni di dollari. Il progetto, volto ad abbinare le informazioni sugli autori alle schede dei prodotti e-commerce, ha superato il budget dell'860% e non è mai stato lanciato.

Perché il superamento dei costi non è stato rilevato per cinque mesi?

Secondo quanto riportato pubblicamente, Amazon non disponeva di sufficienti controlli di spesa e un errore di codifica è stato uno dei fattori del problema. Amazon non ha pubblicato un'analisi post-mortem tecnica per identificare i difetti specifici o gli errori di monitoraggio.

Il problema è stato causato da cicli infiniti di IA?

Questa spiegazione è apparsa in alcune notizie secondarie, ma non è stata confermata dalle principali testate. Il numero esatto di richieste, la logica di retry, i volumi di token e i difetti del codice sorgente non sono ancora stati resi pubblici.

Amazon ha altri casi di superamento dei costi per l'IA?

Sì. Secondo quanto riportato, la stessa presentazione interna includeva costi imprevisti di circa 541.000 dollari per un progetto di audit finanziario e 134.000 dollari per un progetto logistico.

AWS Cost Anomaly Detection può monitorare i costi di Claude su Amazon Bedrock?

La documentazione AWS indica che Cost Anomaly Detection non monitora i prodotti di terze parti del Marketplace AWS, inclusi i modelli Anthropic Claude su Bedrock. AWS consiglia di utilizzare AWS Budgets per gestire questi costi e, se necessario, i filtri per entità di fatturazione.

AWS Budgets può fermare immediatamente la spesa AI fuori controllo?

Da solo, no. AWS dichiara che le informazioni sul budget vengono aggiornate più volte al giorno e che i costi possono continuare ad aumentare prima e dopo la finestra di notifica. Le applicazioni ad alto traffico richiedono limiti massimi rigidi a livello di richiesta e un interruttore di emergenza indipendente.

I limiti di frequenza equivalgono a limiti di spesa?

No. I limiti di frequenza controllano la produttività, mentre i budget controllano i costi accettabili. Un flusso di lavoro può operare entro i limiti di frequenza e comunque superare di gran lunga la spesa pianificata in settimane o mesi.

Qual è il controllo più importante per gli agenti IA?

Impostare un budget rigido per ogni sessione agente che includa richieste, token, strumenti, tentativi e tempo. Applicare tale budget all'esterno dell'agente e disporre di un metodo testato per interrompere immediatamente il flusso di lavoro.

Strumenti correlati

• AWS Budgets: consente di monitorare costi e utilizzo rispetto a soglie e attivare notifiche o azioni di budget configurate.
• AWS Cost Anomaly Detection: rileva modelli di spesa AWS anomali nelle categorie di fatturazione supportate.
• AWS Cost Explorer: aiuta i team ad analizzare costi e utilizzo storici tra servizi AWS e dimensioni di fatturazione.
• Registrazione chiamate dei modelli Amazon Bedrock: registra le chiamate ai modelli supportati e i relativi metadati in CloudWatch Logs o Amazon S3.
• Quote di servizio Amazon Bedrock: mostra i limiti di modelli ed endpoint che possono limitare la produttività di inferenza.
• Anthropic Console: fornisce chiavi API, report di utilizzo, report sui costi, workspace e controlli a livello di account per l'uso diretto dell'API Anthropic.

Link correlati

• Financial Times: il superamento dei costi AI di Amazon: il report principale sul progetto da 1,8 milioni di dollari e sui superamenti aggiuntivi dei costi interni.
• Documentazione AWS Budgets: guida ufficiale su come monitorare costi e utilizzo AWS in base al budget.
• AWS Budget Actions: descrive le azioni eseguite automaticamente o che richiedono approvazione umana al superamento delle soglie.
• Limiti di AWS Cost Anomaly Detection: documenta il monitoraggio delle anomalie e l'esclusione degli addebiti per i modelli di terze parti sul Marketplace.
• Registrazione delle chiamate Amazon Bedrock: spiega come registrare le chiamate ai modelli per il monitoraggio e il debug.
• Quote Amazon Bedrock: descrive le quote relative ai modelli e come queste influiscono sulla produttività.

com/bedrock/latest/userguide/model-invocation-logging.html): Guida ufficiale alla configurazione e al trattamento dei dati per la registrazione delle invocazioni di Bedrock.

• Report su costi e utilizzo di Anthropic: illustra i report su costi, utilizzo, token, modelli, spazi di lavoro e limiti di velocità nella console Anthropic.
• Limiti di velocità dell'API Anthropic: descrive i limiti relativi al numero di richieste, token di input, token di output e livelli di utilizzo.

Riepilogo

Secondo quanto riportato, un progetto Amazon interno che utilizzava Claude Sonnet ha speso 1,8 milioni di dollari, superando il budget dell'860%, rimanendo non rilevato per cinque mesi e non essendo mai stato messo in produzione. Altri progetti di intelligenza artificiale avrebbero generato spese impreviste per centinaia di migliaia di dollari.

I documenti pubblici non confermano che l'evento principale sia stato causato da un ciclo di richieste infinito. Ciò che i documenti confermano è il divario tra la velocità di spesa dei flussi di lavoro AI e la velocità con cui le organizzazioni rilevano i problemi.

Le aziende dovrebbero combinare il monitoraggio delle singole richieste, budget a livello di attività, limiti su token e strumenti, tentativi controllati, instradamento dei modelli, budget cloud, azioni automatizzate e interruttori di emergenza che gli agenti non possono bypassare.

**

La regola più sicura è semplice: nessun processo AI dovrebbe rimanere operativo per cinque mesi senza aver ripetutamente dimostrato di essere ancora utile, entro il budget e autorizzato a continuare.