Quando la tua bolletta Amazon Bedrock sale e nessuno riesce a dire quale feature ne è la causa, non hai un problema di prezzo. Hai un problema di osservabilità. La fattura ti dice che l'account ha speso di più in token. Non ti dice quale agente, quale tenant, o quale percorso di codice ha speso, e senza quell'attribuzione ogni conversazione sui costi è una supposizione. Non puoi ottimizzare ciò che non puoi misurare, e la maggior parte dei team misura il totale e nient'altro sotto di esso.

La spesa in token ha una proprietà che rende tutto questo peggiore del normale costo cloud: è generata da un sistema non deterministico. Una modifica al prompt, un ciclo di retry, un agente chiacchierone, o un utente che ha trovato un modo per far pensare di più al modello possono tutti spostare la bolletta, e nessuno di questi appare come una nuova risorsa in fattura. La spesa si nasconde dentro un'unica voce di riga Bedrock. Il compito è scomporre quella voce prima che ti sorprenda, non dopo.

L'attribuzione è tutto il gioco

La domanda che conta non è mai "quanto abbiamo speso su Bedrock". È "quanto ha speso questo, e ne vale la pena". Rispondere richiede una dimensione su ogni unità di spesa in token. Come minimo, tagga ogni chiamata con:

  • Feature o area di prodotto, così puoi chiederti se il riassuntore o l'assistente di chat è il motore del costo.
  • Tenant o cliente, così puoi vedere se un account è sovvenzionato dal resto e se il tuo pricing copre il tuo costo di servizio.
  • Agente o workflow, così il costo di una pipeline multi-step è visibile per singolo passo anziché come un unico totale opaco.
  • Modello, così puoi capire quando il traffico costoso va verso un modello frontier che uno più economico avrebbe gestito lo stesso.

Senza queste dimensioni, l'ottimizzazione dei costi degrada in misure generiche: limita tutti, oppure spegni delle feature e guarda quale lamentela arriva. Con esse, puoi puntare al percorso esatto che è cresciuto e decidere se quella crescita se l'è guadagnata.

Due livelli di strumentazione

Cost allocation tag per la fattura

I cost allocation tag di AWS sono il livello grossolano. Tagga le risorse e le richieste che guidano l'uso di Bedrock così che i dati di fatturazione stessi portino le tue dimensioni, e i report sui costi possano raggruppare per feature o ambiente invece di mostrare un'unica cifra Bedrock indifferenziata. Questa è la vista in cui vivono la finanza e i responsabili di piattaforma. È a grana mensile e buona per la conversazione "dove vanno i soldi", non per intercettare un picco sul momento.

Metriche CloudWatch per il quadro in tempo reale

La fattura è un indicatore ritardato. L'indicatore anticipato è il throughput dei token, e quello appartiene a CloudWatch. Bedrock emette metriche di utilizzo, e puoi pubblicare le tue metriche personalizzate dimensionate per agente, per tenant, o per feature direttamente dall'applicazione:

# emit token counts as custom metrics, dimensioned
put_metric_data(
  namespace = "LLM/Usage",
  metric    = "InputTokens",
  value     = usage.input_tokens,
  dimensions = { "Feature": "summarizer", "Tenant": tenant_id }
)
# same for output_tokens, and cache read/write counts

Ora la spesa è un grafico su cui puoi impostare allarmi. Una metrica di token per agente che triplica nel giro di una notte fa scattare un avviso il martedì, invece di una domanda finanziaria a fine mese. Leggi input e output separatamente, perché l'output è prezzato più alto e una generazione fuori controllo si manifesta lì per prima.

Cosa ti permette di fare la visibilità

Una volta che ogni token è attribuito, le ottimizzazioni smettono di essere generiche. Puoi instradare le chiamate economiche e meccaniche che una metrica per agente rivela verso un modello più piccolo, e riservare il modello frontier al ragionamento che se lo merita. Puoi trovare il tenant il cui costo di servizio supera il piano che ha sottoscritto e correggere il pricing o l'utilizzo. Puoi intercettare il ciclo di retry introdotto da una modifica al prompt, perché il suo conteggio di token è aumentato mentre il conteggio delle richieste no. Ognuna di queste mosse richiede di sapere quale fetta della bolletta tagliare, ed è esattamente ciò che ti dà la strumentazione e che la fattura grezza non ti darà mai.

Il punto chiave

Una bolletta Bedrock che non puoi scomporre è una bolletta che non puoi gestire. Tratta la spesa in token come telemetria, non solo come una voce di fattura: taggala con i cost allocation tag per la vista di fatturazione, emetti metriche di token per agente e per tenant verso CloudWatch per la vista in tempo reale, e imposta allarmi sull'indicatore anticipato così che un picco sia un avviso, non un post-mortem. I team i cui costi LLM restano sotto controllo non sono quelli con i prezzi migliori. Sono quelli che possono vedere, in qualsiasi momento, esattamente quale feature, tenant e agente sta spendendo i soldi.

Da leggere ora

Per il playbook di FinOps e visibilità dei costi cloud oltre agli LLM, le note di campo sul cloud sono su ercan.cloud, e l'hub è su ercanermis.com.