Se il traffico OpenAI della sua azienda passa da LiteLLM, Portkey, Kong AI Gateway o da un gateway interno, il suo modello di attribuzione dei costi è già compromesso.
Ogni chiamante upstream viene appiattito in un'unica identità di workload proprio nel punto in cui inizia la spesa. La fatturazione del provider, gli strumenti FinOps basati sui tag e le piattaforme di cloud cost non sono in grado di ripartire quel costo per servizio, team, funzionalità o cliente.
È il punto cieco degli LLM gateway. E sta rapidamente diventando un problema centrale per DevOps e per il FinOps for AI, dove la spesa a token e l'infrastruttura condivisa mandano in tilt i modelli tradizionali di attribuzione.
È la lacuna in più rapida crescita nell'attribuzione dei costi cloud e segue lo stesso schema che i team hanno già visto con Kafka, Snowflake e altri sistemi condivisi. La differenza è che oggi la spesa è a token, cresce in fretta ed è direttamente legata all'utilizzo del prodotto.
Perché la catena si spezza al gateway
Una chiamata mediata da un gateway prevede due hop:
upstream-svc ──► llm-gateway ──► api.openai.com
L'identità che conta si trova nel primo hop: servizio, tenant, funzionalità, cliente.
L'evento fatturabile avviene invece nel secondo hop: l'utilizzo dei token.
Le fatture del provider vedono solo l'identità del gateway. Una volta avvenuto questo appiattimento, i sistemi a valle non riescono più a ricostruire l'informazione.
Tutte le fonti di dati standard si collocano a valle di questo appiattimento:
- Gli export di fatturazione del provider mostrano il costo per chiave API o per progetto, non per servizio
- La fatturazione cloud ( CUR, GCP, Azure) non vede la spesa OpenAI oppure continua ad attribuirla al gateway
- Gli strumenti FinOps basati sui tag assegnano il costo alla risorsa che lo ha generato: llm-gateway
Il risultato è un unico calderone di costi di infrastruttura condivisa al posto di unit economics davvero utilizzabili.
Come si manifesta il problema nella pratica
| Vista | Default (appiattita) | Ciò che serve al business |
| Costo per workload | llm-gateway = $X | Ripartito sui servizi reali in base all'utilizzo dei token |
| Costo per cliente | Infrastruttura condivisa | Costo AI per singolo cliente |
| Costo per funzionalità | L'AI sembra gratuita | COGS AI reali per funzionalità |
| Segnale di pricing | % aggregata sul costo | Redditività a livello di cliente |
Non è solo un problema di visibilità. Ha un impatto diretto su:
- Analisi della redditività dei clienti
- Decisioni di pricing
- ROI delle funzionalità
- Ottimizzazione dei costi cloud
Perché tagging e log non sono sufficienti
La maggior parte dei team prova a risolvere il problema con la propagazione degli header e con i log. In staging funziona. In produzione no.
1. La propagazione perde colpi. Nuovi servizi, retry o percorsi alternativi generano attribuzioni mancanti. Con il tempo, una quota crescente della spesa finisce nella voce "sconosciuto".
2. I log non sono un sistema di cost accounting. Sampling, limiti di retention e bias di ingestion compromettono il dataset. Correlare log e fatturazione diventa una pipeline fragile.
3. Le chiamate condivise non si possono ripartire con i tag. Retry, batching, caching e workflow fan-out fanno sì che più chiamanti condividano la stessa richiesta verso il provider. I tag non permettono un'allocazione equa dei costi. Solo una contabilizzazione a livello di token può farlo.
4. I log non vedono lo spazio negativo. Chiamate fallite, retry e fallback generano comunque pressione sui costi infrastrutturali, ma non vengono intercettati in modo completo.
Ecco perché i team che cercano di allocare i costi cloud condivisi tra microservizi senza ricorrere al tagging finiscono per bloccarsi. Il tagging restringe il divario, ma non lo chiude.
Attribuzione a runtime: osservare la richiesta, non ricostruirla
L'unica soluzione affidabile è osservare il costo a runtime, invece di ricostruirlo a partire dai dati di fatturazione.
Attribute™ utilizza un sensore eBPF che gira a fianco del gateway e osserva entrambi i lati della richiesta:
- Primo hop: servizio upstream → gateway (identità intatta)
- Secondo hop: gateway → provider (utilizzo dei token e costo)
Correlando i due lati, riconduce il costo del provider al workload di origine sulla base del consumo effettivo di token.
In questo modo si ottengono:
- Visibilità dei costi Kubernetes per workload di origine
- Attribuzione dei costi AI a livello di cliente
- COGS AI a livello di funzionalità
- Segnali di costo in tempo reale
- Allocazione precisa dei costi cloud senza tagging
I dettagli implementativi che contano
- Sensore in sola lettura
- PII e segreti rimossi prima che qualunque dato lasci l'ambiente
- Eventi OpenTelemetry minimi su TLS con autenticazione JWT
- Compatibile con i collector OTel esistenti
- Nessun sidecar, nessuna modifica al codice, nessuna modifica alla configurazione del gateway
Il risultato: il calderone di costi llm-gateway sparisce. Ogni dollaro speso su OpenAI è ricondotto a un workload, a un team, a una funzionalità e a un cliente.
Checklist di valutazione
Se sta valutando strumenti FinOps per l'AI e per l'infrastruttura condivisa, si chieda:
- È in grado di ripartire il costo del gateway per workload di origine senza propagazione dei tag?
- Sa attribuire il costo dell'AI a clienti e funzionalità?
- Legge il traffico in tempo reale o gli export di fatturazione?
- Riesce a suddividere le chiamate condivise in modo proporzionale all'utilizzo dei token?
- La telemetria può restare all'interno del suo ambiente?
La maggior parte degli strumenti fallisce su più fronti perché entra in gioco dopo l'evento di fatturazione.
Gli LLM gateway spezzano l'attribuzione dei costi esattamente nel punto in cui la spesa ha inizio. Se il suo modello FinOps parte dai dati di fatturazione, il segnale più importante è già perso. L'unico modo per recuperarlo è osservare il sistema mentre è in esecuzione. È questa la differenza tra stimare un costo e comprenderlo davvero.