Se si è documentato sull'attribuzione dei costi AI o sugli strumenti di cloud observability, si sarà quasi certamente imbattuto nel termine eBPF. Compare nelle piattaforme di sicurezza, negli strumenti di networking, nei sistemi di performance monitoring e, sempre più spesso, nell'attribuzione dei costi AI. Ma cosa significa davvero e perché è rilevante per misurare la spesa in AI?
eBPF: una definizione
eBPF è l'acronimo di extended Berkeley Packet Filter. Il nome è un retaggio delle origini (nasce come sistema per filtrare i pacchetti di rete), ma la tecnologia si è evoluta in qualcosa di ben più ampio: un modo per eseguire piccoli programmi in sandbox direttamente all'interno del kernel Linux, senza modificarne il codice sorgente né installare moduli aggiuntivi.
In pratica, eBPF consente al software di osservare ciò che accade su una macchina al livello più basso: ogni chiamata di sistema, ogni pacchetto di rete, ogni processo, ogni interazione con la GPU, nel momento in cui avviene. E lo fa in modo sicuro. I programmi eBPF vengono eseguiti in un ambiente verificato e isolato, quindi non possono mandare in crash il kernel né aprire falle di sicurezza. Per un approfondimento tecnico sull'architettura di caricamento e verifica, l'introduzione su eBPF.io è il riferimento pubblico più completo disponibile.
Un sensore eBPF è il componente software che sfrutta questa capacità. È un programma leggero che si aggancia agli eventi del kernel e trasmette dati su ciò che osserva, in genere verso un collector o un livello di analisi in esecuzione altrove. Si può immaginare come un sensore integrato nel sistema operativo stesso, che monitora attività invisibili a qualsiasi strumento a livello applicativo.
Sensori eBPF, moduli del kernel e agenti a confronto
Prima di eBPF, ottenere questo tipo di visibilità significava di norma una delle due cose: scrivere un modulo del kernel personalizzato oppure eseguire un agente pesante agganciato al livello applicativo.
I moduli del kernel possono vedere tutto ciò che vede un sensore eBPF, ma comportano rischi concreti. Un bug in un modulo del kernel può mandare in crash l'intera macchina, perché il modulo gira con accesso completo e non controllato alla memoria del kernel. In più, i moduli vanno ricompilati e testati per ogni versione del kernel, con un onere di manutenzione continuo che pochi team hanno voglia di assumersi.
Gli agenti a livello applicativo evitano questo rischio, ma lo pagano con dei punti ciechi. Un agente installato all'interno di un'applicazione vede solo ciò che quella applicazione decide di esporre. Non riesce a vedere il traffico che passa attraverso un driver GPU condiviso, un socket di rete del kernel o un processo di cui non è mai stato informato.
Un sensore eBPF si colloca a metà strada, con i pregi di entrambi. Gira all'interno del kernel, quindi vede tutto ciò che vedrebbe un modulo del kernel, ma ogni programma eBPF passa attraverso il verifier del kernel prima dell'esecuzione, e quindi non può mandare in crash il sistema né leggere aree di memoria non autorizzate. Questa combinazione, visibilità completa con rischio contenuto, è il motivo per cui eBPF è diventato la scelta di riferimento per l'observability moderna, la sicurezza e, oggi, per gli strumenti di attribuzione dei costi.
Perché l'osservazione a livello di kernel è importante
La maggior parte degli strumenti di monitoraggio e attribuzione lavora a livello applicativo. Presuppone che qualcosa sia stato strumentato: un tag su una risorsa, un SDK che avvolge una chiamata API, una riga di log che un engineer si è ricordato di aggiungere. Funziona bene quando ciò che si misura è statico e ben definito.
L'infrastruttura AI non è né statica né ben definita. È proprio qui che le pratiche FinOps tradizionali iniziano a scricchiolare; per approfondire, si veda come il FinOps si adatta (e non si adatta) ai workloads AI. Un cluster GPU condiviso serve più prodotti contemporaneamente. Un account API di un modello gestito riceve richieste da decine di team. Un gateway LLM aggrega il traffico di agenti, pipeline e utenti umani in un unico flusso in uscita, spesso rimuovendo lungo il percorso l'identità del chiamante. Nessuna di queste attività porta con sé un tag. Nessuna passa attraverso un SDK che Lei può controllare.
Un sensore eBPF non ha bisogno di nulla di tutto questo. Operando all'interno del sistema operativo, vede direttamente il consumo effettivo: il processo, il container, il pod, il ciclo GPU, il token. Non chiede all'applicazione di riportare nulla. Osserva il sistema stesso.
Si consideri uno scenario tipico: un team di engineering instrada tutto il traffico dei modelli attraverso un unico gateway LLM per gestire rate limit e failover tra i provider. Dal punto di vista del gateway, ogni richiesta appare identica: una API key, un flusso in uscita. Anche l'estratto di fatturazione del provider del modello riflette lo stesso appiattimento. Dalla sola fattura è impossibile capire se un determinato dollaro provenga da una funzionalità rivolta ai clienti, da un'automazione interna o da uno script di test fuori controllo. Un sensore eBPF risolve il problema osservando il traffico nel punto esatto in cui lascia la macchina, prima che il gateway lo aggreghi, e ricollegando ogni richiesta al processo che l'ha generata.
Come funziona un sensore eBPF, passo dopo passo
- Attach. Il sensore si aggancia a specifici eventi del kernel, come chiamate di sistema, attività di rete o scheduling della GPU, in base a ciò che è progettato per osservare.
- Cattura. Al verificarsi di questi eventi, il sensore raccoglie i dati rilevanti: ID di processo, utilizzo delle risorse, timing e così via.
- Verifica. Prima ancora che tutto ciò accada, il verifier eBPF del kernel Linux controlla il programma per confermare che sia sicuro da eseguire. È questo che rende eBPF diverso da un modulo del kernel tradizionale, che comporta rischi ben maggiori.
- Streaming. Il sensore trasmette ciò che osserva a un livello di raccolta esterno al kernel, dove i dati possono essere combinati con altre informazioni, come i record di fatturazione dei provider.
- Mapping. I dati aggregati vengono poi ricondotti al workload responsabile: quale agente, quale feature, quale cliente.
L'intero processo si svolge in modo continuo e in tempo reale, senza richiedere modifiche al codice, interventi sui manifest o strumentazione di alcun tipo.
Sensori eBPF e attribuzione dei costi AI
È qui che eBPF diventa direttamente rilevante per la Tokenomics, la disciplina che studia quanto costa ciascun token e quanto vale. I workloads AI si muovono troppo in fretta e in modo troppo imprevedibile perché un'attribuzione basata sulla strumentazione riesca a stare al passo. Un agente può generare un migliaio di sotto-agenti nel giro di una notte. Nel tempo che serve a un team di engineering per avvolgere un nuovo pattern di chiamata in un SDK, la fattura è già arrivata.
Un sensore eBPF aggira completamente il problema. Misurando dall'interno del sistema operativo, prima di qualunque proxy, di qualunque astrazione, di qualunque confine di ownership, cattura ogni token, ogni richiesta al modello e ogni ciclo GPU nel momento in cui avviene. Questi dati possono poi essere combinati con la fatturazione di provider come Anthropic, OpenAI, Google Gemini e AWS Bedrock, scomponendo automaticamente cached token, reasoning token, input token e output token.
Il risultato è un'attribuzione che non dipende da tag, SDK o modifiche al codice, e che si distribuisce in pochi minuti anziché in mesi. Questo livello di granularità è anche la base per misurare l'AI ROI in modo accurato. Senza sapere quanto costa realmente una funzionalità, qualsiasi calcolo del ROI si regge su un'ipotesi.
Domande frequenti
È sicuro eseguire un sensore eBPF in produzione? Sì. Ogni programma eBPF passa attraverso il verifier integrato del kernel prima di essere caricato. Il verifier controlla che il programma termini sempre, non legga memoria fuori dai limiti consentiti e non possa mandare in crash o destabilizzare il kernel. Si tratta di un profilo di rischio radicalmente diverso da quello di un modulo del kernel tradizionale, che ha accesso illimitato e nessun controllo di sicurezza integrato.
Un sensore eBPF richiede modifiche al codice o strumentazione? No. È proprio questo il vantaggio principale. Un sensore eBPF osserva l'attività a livello di kernel, quindi non ha bisogno di un tag, di un SDK o di una modifica al codice per vedere ciò che accade. Funziona allo stesso modo indipendentemente da come è stata scritta un'applicazione o dal linguaggio in cui è realizzata.
Quanto tempo richiede il deployment di un sensore eBPF? In genere si misura in minuti, non in settimane. Non essendoci alcun passaggio di strumentazione, nessuna modifica ai manifest e nessuna necessità di intervenire sul codice applicativo, un sensore può essere installato e iniziare a osservare il traffico quasi immediatamente. Con Attribute™ by DoiT, la maggior parte dei clienti vede i dati attribuiti nello stesso giorno.
Un sensore eBPF può vedere all'interno di una GPU condivisa o di un gateway LLM? Sì, ed è proprio questo che lo distingue dagli approcci basati su tagging o SDK. Poiché il sensore osserva il traffico a livello di sistema operativo, prima che attraversi qualsiasi gateway, proxy o risorsa condivisa, riesce a ricondurre l'attività al processo di origine anche quando viene aggregata o resa anonima più a valle.
eBPF serve solo per casi d'uso di networking e sicurezza? No. eBPF nasce come tecnologia di networking (l'acronimo sta per extended Berkeley Packet Filter), ma da allora si è esteso all'observability, alla sicurezza e ora all'attribuzione dei costi. Qualsiasi caso d'uso che tragga vantaggio dall'osservazione diretta dell'attività di sistema, senza doversi affidare all'auto-reporting dell'applicazione, è un buon candidato per un approccio basato su eBPF.
Qual è la differenza tra un sensore eBPF e un programma eBPF? Un programma eBPF è l'unità di codice di base che viene eseguita all'interno del kernel: un piccolo frammento di logica verificato e agganciato a uno specifico hook point. Un sensore eBPF è il sistema più ampio costruito al di sopra, che comprende la logica di raccolta e mapping in grado di trasformare le osservazioni grezze del kernel in dati utilizzabili.
È questa la base su cui poggia Attribute™ by DoiT. Scopra come si presenta l'attribuzione dei costi AI a livello di kernel nel Suo ambiente.