Wer sich mit AI-Kostenzuordnung oder Cloud-Observability-Tools beschäftigt, ist mit hoher Wahrscheinlichkeit schon über den Begriff eBPF gestolpert. Er taucht in Security-Plattformen, Networking-Tools, Performance-Monitoren und zunehmend auch bei der AI-Kostenzuordnung auf. Doch was steckt eigentlich dahinter, und warum ist er für die Messung von AI-Ausgaben relevant?
eBPF im Detail
eBPF steht für "extended Berkeley Packet Filter". Der Name ist ein Überbleibsel aus den Anfängen – die Technologie begann als Möglichkeit, Netzwerkpakete zu filtern –, doch inzwischen ist daraus etwas viel Umfassenderes geworden: eine Methode, um kleine, isolierte Programme direkt im Linux-Kernel auszuführen, ohne den Kernel-Quellcode zu verändern oder ein Kernel-Modul zu installieren.
Konkret ermöglicht eBPF Software, das Geschehen auf einer Maschine auf tiefster Ebene zu beobachten: jeden System Call, jedes Netzwerkpaket, jeden Prozess, jede GPU-Interaktion – in Echtzeit. Und das sicher. eBPF-Programme laufen in einer verifizierten Sandbox-Umgebung, sodass sie weder den Kernel zum Absturz bringen noch Sicherheitslücken öffnen können. Für eine tiefergehende technische Beschreibung des Loaders und der Verifizierungsarchitektur ist die eBPF.io-Einführung die gründlichste öffentlich verfügbare Referenz.
Ein eBPF-Sensor ist die Software, die diese Fähigkeit nutzt. Es handelt sich um ein schlankes Programm, das sich an Kernel-Events anhängt und Daten zu seinen Beobachtungen streamt – typischerweise an einen Collector oder eine Analyseschicht an anderer Stelle. Man kann sich das als einen im Betriebssystem selbst eingebetteten Sensor vorstellen, der Aktivitäten beobachtet, die kein Tool auf Anwendungsebene je zu Gesicht bekommt.
eBPF-Sensoren im Vergleich zu Kernel-Modulen und Agents
Vor eBPF gab es für diese Art von Einblick meist nur zwei Wege: ein eigenes Kernel-Modul entwickeln oder einen schwergewichtigen Agent betreiben, der sich in die Anwendungsschicht einklinkt.
Kernel-Module sehen alles, was auch ein eBPF-Sensor sieht – doch sie bringen ein reales Risiko mit. Ein Bug in einem Kernel-Modul kann die gesamte Maschine zum Absturz bringen, weil das Modul mit vollem, ungeprüftem Zugriff auf den Kernel-Speicher läuft. Zudem müssen Module für jede Kernel-Version neu gebaut und getestet werden – ein laufender Wartungsaufwand, den kaum ein Team gerne übernimmt.
Agents auf Anwendungsebene umgehen dieses Risiko, bezahlen dafür aber mit blinden Flecken. Ein in einer Anwendung installierter Agent sieht nur, was diese Anwendung preisgibt. Traffic durch einen gemeinsam genutzten GPU-Treiber, einen Kernel-Netzwerk-Socket oder einen Prozess, von dem er nichts weiß, bleibt für ihn unsichtbar.
Ein eBPF-Sensor liegt genau dazwischen und vereint das Beste aus beiden Welten. Er läuft im Kernel und sieht damit alles, was auch ein Kernel-Modul sehen würde – aber jedes eBPF-Programm durchläuft den Verifier des Kernels, bevor es ausgeführt werden darf. So kann es weder das System zum Absturz bringen noch Speicher lesen, auf den es keinen Zugriff haben sollte. Diese Kombination aus voller Sichtbarkeit bei begrenztem Risiko ist der Grund, warum eBPF zur Standardwahl für moderne Observability, Security und mittlerweile auch für Kostenzuordnungs-Tools geworden ist.
Warum Beobachtung auf Kernel-Ebene entscheidend ist
Die meisten Monitoring- und Zuordnungstools arbeiten auf der Anwendungsebene. Sie sind darauf angewiesen, dass etwas instrumentiert ist: ein Tag an einer Ressource, ein SDK um einen API-Aufruf, eine Logzeile, an die ein Engineer gedacht hat. Das funktioniert bestens, solange das Messobjekt statisch und klar definiert ist.
AI-Infrastruktur ist weder statisch noch klar definiert. Genau hier geraten klassische FinOps-Praktiken an ihre Grenzen; wie sich FinOps für AI-workloads anpasst (und wo nicht), erklärt dieser Beitrag im Detail. Ein gemeinsam genutzter GPU-Cluster bedient mehrere Produkte gleichzeitig. Ein Managed-Model-API-Account nimmt Anfragen von Dutzenden Teams entgegen. Ein LLM-Gateway bündelt Traffic von Agents, Pipelines und menschlichen Nutzern zu einem einzigen ausgehenden Stream – wobei die Identität des Aufrufers oft verloren geht. Nichts davon trägt ein Tag. Nichts davon läuft durch ein SDK, das Sie kontrollieren.
Ein eBPF-Sensor braucht nichts davon. Weil er innerhalb des Betriebssystems arbeitet, sieht er den tatsächlichen Verbrauch direkt: den Prozess, den Container, den Pod, den GPU-Zyklus, den Token. Er fragt die Anwendung nicht nach Reports. Er beobachtet das System selbst.
Ein typisches Szenario: Ein Engineering-Team leitet den gesamten Modell-Traffic über ein einziges LLM-Gateway, um Rate Limits und Failover zwischen Anbietern zu steuern. Aus Sicht des Gateways sieht jede Anfrage gleich aus: ein API-Key, ein ausgehender Stream. Die Abrechnung des Modellanbieters spiegelt genau diese Nivellierung wider. Aus der Rechnung allein lässt sich nicht ablesen, ob ein bestimmter Dollar aus einem kundenseitigen Feature, einer internen Automatisierung oder einem außer Kontrolle geratenen Test-Skript stammt. Ein eBPF-Sensor löst das, indem er den Traffic dort beobachtet, wo er die Maschine tatsächlich verlässt – bevor das Gateway ihn zusammenfasst – und jede Anfrage dem verursachenden Prozess zuordnet.
So funktioniert ein eBPF-Sensor Schritt für Schritt
- Anbindung. Der Sensor hängt sich an bestimmte Kernel-Events – etwa System Calls, Netzwerkaktivität oder GPU-Scheduling – je nachdem, was er beobachten soll.
- Erfassung. Sobald diese Events auftreten, erfasst der Sensor die relevanten Datenpunkte: Prozess-IDs, Ressourcennutzung, Timing und so weiter.
- Verifizierung. Bevor irgendetwas davon passiert, prüft der eBPF-Verifier des Linux-Kernels das Programm auf sichere Ausführung. Genau das unterscheidet eBPF von einem klassischen Kernel-Modul, das ein weitaus höheres Risiko birgt.
- Streaming. Der Sensor streamt seine Beobachtungen an eine Collection-Schicht außerhalb des Kernels, wo sie mit anderen Daten wie Abrechnungsdatensätzen der Anbieter zusammengeführt werden können.
- Zuordnung. Diese kombinierten Daten werden dem verantwortlichen workload zugeordnet: welcher Agent, welches Feature, welcher Kunde.
Der gesamte Prozess läuft kontinuierlich und in Echtzeit ab – ohne Codeänderungen, Manifest-Anpassungen oder Instrumentierung jeglicher Art.
eBPF-Sensoren und AI-Kostenzuordnung
Hier wird eBPF unmittelbar relevant für Tokenomics, also die Disziplin, den Preis und Wert jedes einzelnen Tokens zu verstehen. AI-workloads bewegen sich zu schnell und zu unvorhersehbar, als dass eine instrumentierungsbasierte Zuordnung mithalten könnte. Ein Agent kann über Nacht tausend Sub-Agents erzeugen. Bis ein Engineering-Team ein neues Aufrufmuster in ein SDK verpackt hat, ist die Rechnung längst da.
Ein eBPF-Sensor umgeht dieses Problem komplett. Weil er aus dem Betriebssystem heraus misst – vor jedem Proxy, vor jeder Abstraktion, vor jeder Ownership-Grenze – erfasst er jeden Token, jede Modellanfrage und jeden GPU-Zyklus in Echtzeit. Diese Daten lassen sich anschließend mit den Abrechnungen von Anbietern wie Anthropic, OpenAI, Google Gemini und AWS Bedrock zusammenführen, wobei Cached Tokens, Reasoning Tokens, Input Tokens und Output Tokens automatisch aufgeschlüsselt werden.
Das Ergebnis: eine Kostenzuordnung, die weder Tags noch SDKs noch Codeänderungen benötigt und in Minuten statt Monaten einsatzbereit ist. Diese Granularität ist zugleich die Grundlage, um AI-ROI präzise zu messen. Ohne zu wissen, was ein Feature tatsächlich kostet, beruht jede ROI-Rechnung auf einer Vermutung.
Häufig gestellte Fragen
Ist ein eBPF-Sensor sicher im Produktivbetrieb? Ja. Jedes eBPF-Programm durchläuft den in den Kernel integrierten Verifier, bevor es geladen werden darf. Der Verifier prüft, dass das Programm stets terminiert, keinen Speicher außerhalb seiner Grenzen liest und den Kernel weder zum Absturz noch aus dem Tritt bringen kann. Das Risikoprofil unterscheidet sich damit grundlegend von einem klassischen Kernel-Modul, das uneingeschränkten Zugriff und keine eingebaute Sicherheitsprüfung hat.
Erfordert ein eBPF-Sensor Codeänderungen oder Instrumentierung? Nein. Genau das ist der zentrale Vorteil. Ein eBPF-Sensor beobachtet Aktivität auf Kernel-Ebene und benötigt daher weder Tag noch SDK noch Codeänderung, um zu sehen, was passiert. Er funktioniert unabhängig davon, wie eine Anwendung geschrieben wurde oder in welcher Sprache sie vorliegt.
Wie lange dauert die Bereitstellung eines eBPF-Sensors? Die Bereitstellung erfolgt in der Regel in Minuten, nicht Wochen. Weil kein Instrumentierungsschritt, keine Manifest-Änderungen und keine Anpassungen am Anwendungscode nötig sind, lässt sich ein Sensor nahezu sofort installieren und beginnt umgehend mit der Beobachtung. Mit Attribute™ von DoiT sehen die meisten Kunden bereits am selben Tag zugeordnete Daten.
Kann ein eBPF-Sensor in eine gemeinsam genutzte GPU oder ein LLM-Gateway hineinsehen? Ja – und genau das unterscheidet ihn von Tagging- oder SDK-basierten Ansätzen. Weil der Sensor Traffic auf Betriebssystemebene beobachtet, bevor er ein Gateway, einen Proxy oder eine gemeinsam genutzte Ressource durchläuft, lässt sich die Aktivität selbst dann bis zum ursprünglichen Prozess zurückverfolgen, wenn sie weiter unten in der Kette aggregiert oder anonymisiert wird.
Funktioniert eBPF nur für Networking- und Security-Use-Cases? Nein. eBPF begann als Networking-Technologie (die Abkürzung steht für "extended Berkeley Packet Filter"), hat sich seither aber auf Observability, Security und nun auch Kostenzuordnung ausgeweitet. Jeder Anwendungsfall, der davon profitiert, Systemaktivität direkt zu sehen – ohne sich auf Selbstauskünfte der Anwendung zu verlassen –, ist ein Kandidat für einen eBPF-basierten Ansatz.
Was ist der Unterschied zwischen einem eBPF-Sensor und einem eBPF-Programm? Ein eBPF-Programm ist die zugrundeliegende Code-Einheit, die im Kernel läuft: ein kleines, verifiziertes Logikstück, das an einen bestimmten Hook-Punkt gebunden ist. Ein eBPF-Sensor ist das umfassendere System, das darauf aufbaut – einschließlich der Collection- und Mapping-Logik, die aus rohen Kernel-Beobachtungen nutzbare Daten macht.
Auf dieser Grundlage basiert Attribute™ von DoiT. Sehen Sie, wie AI-Kostenzuordnung auf Kernel-Ebene in Ihrer eigenen Umgebung aussieht.