Wer bezahlt den KV-Cache? Messregeln sind getarnte Preisentscheidungen

Jede FinOps-Konversation über selbst gehostete Inferenz kollidiert irgendwann mit einer Frage, die die Public Clouds mit einer Preisliste beantworten und die privaten mit einem Streit: Wenn vier Tenants sich eine GPU und einen KV-Cache teilen, wer zahlt? Einige API-Anbieter veröffentlichen Preise für Cache-Reads und Cache-Writes; diese Preislisten machen ihre Zuteilungsregel sichtbar, wie im Vergleich der Cache-Read-Preise besprochen. Auf einem Kubernetes-Cluster mit eigenem vLLM liefert niemand eine Messrichtlinie. Man wählt eine, und die Wahl verpreist stillschweigend jeden Tenant.

Genau darum geht es in arXiv:2609.24991, „Who Pays for the KV Cache? Attributing Shared AI Inference Spend Across Kubernetes and LLM Provider Bills“ von Timothy Urista (eingereicht am 21. September 2026)¹. Das Papier hat zwei Hälften, die üblicherweise getrennt bleiben: ein Tool, unalloc, das OpenCost-, LiteLLM-, OpenAI- und Anthropic-Kostendaten zu einem dezimalgenauen Hauptbuch verbindet und den Anteil des Spendings ohne Eigentümer ausweist; und eine Messung auf einer H100 mit vLLM, wie sehr allein die Messregel — nicht die Workload, nicht die Hardware, nur der Abrechnungsschlüssel — Geld zwischen Tenants verschiebt. Wir haben beide Hälften an den Primärquellen verifiziert; dieser Guide zerlegt die zweite, weil sie verallgemeinert. Wer agentische Workloads mit starker Prefix-Wiederverwendung betreibt, für den geht es um die eigene Rechnung.

Die Schlagzeile, verifiziert

Auf einem DigitalOcean-H100-80GB-Droplet (ein 29-minütiger Lauf für rund $2,15, vollständig im Repo dokumentiert) diente vLLM 0.29.0 mit Qwen2.5-7B-Instruct in bf16, 8.192-Token-Kontext und Prefix-Caching; vLLM dimensionierte den KV-Pool auf 995.296 Tokens². Vier Tenants teilen sich den Pod. Über konfigurierte Lasten von 2 bis 16 Requests pro Sekunde — 3,7 bis 26,9 abgeschlossene Requests pro Sekunde, denn die konfigurierte Rate zählt nur Session-Initial-Ankünfte — widersprechen sich die beiden Meter bei jeder Last²:

Das Abstract rundet auf „12–14 Prozentpunkte bei jeder getesteten Last“. Aus den angezeigten, gerundeten Anteilen in Tabelle 3 ergeben sich 11,7, 11,9, 12,5 und 13,6 Punkte; der Paper-Text nennt als Obergrenze 13,7 Punkte auf Basis der zugrunde liegenden Werte. Die Tabelle zeigt nicht genug Dezimalstellen, um die letzte ungerundete Differenz nachzurechnen². In diesen vier Läufen ist die Richtung gleich, und die Differenz des jeweiligen Gesamtlaufs steigt mit der konfigurierten Last. Pro Last gab es nur einen zweiminütigen Lauf; die Zehn-Sekunden-Fenster beschreiben die Variation innerhalb davon, aber keine Unsicherheit zwischen unabhängigen Läufen. nvidia-smi meldet 97–99 % GPU-Auslastung, während sich der Durchsatz ungefähr versiebenfacht: Diese Kennzahl beweist weder Sättigung noch eine faire Kostenzuordnung².

Ebenfalls verifiziert und der Klarheit halber: Alle 6.241 Requests wurden fehlerfrei abgeschlossen, und das Modell speichert nach eigener Rechnung des Papiers etwa 57 KB KV pro Token².

Warum die Meter in diesem Lauf auseinandergehen

Im synthetischen Traffic des Papers haben Search-Requests lange Prompts (600–1.400 Token) und kurze Antworten (16–64 Token), während Agents mehrstufige Prompts senden und längere Antworten erzeugen². Ein roher Tokenzähler zählt Prompt-Token auch bei einem wiederverwendeten Cache-Prefix; ein gleicher Zeitanteilszähler teilt jedes 50-ms-Fenster unter den gerade laufenden Requests auf. Im gemessenen H100-Lauf entfallen unter dem Tokenzähler 16,5–18,9 % der umverteilten Rechnung auf Search, unter dem Zeitanteil 4,7–5,3 %. Das sind verschiedene Zuteilungsregeln, kein Beleg, dass eine davon der wirtschaftlich richtige Preis ist. Ihre Reihenfolge ist eine Beobachtung für diese Workload und kann sich mit Tenant-Mix, Cache-Hit-Raten, Ausgabelängen und Batching ändern².

KV-Belegung ist eine weitere Ressource und ermöglicht einen weiteren Meter. Das Paper nennt etwa 57 kB KV pro Token und einen Pool für 995.296 Token. Nur als Größenordnung angenommen, eine Session hält tatsächlich 32.768 KV-Token:

# Hypothetisch gehaltener Kontext mit gerundeten 57 kB/Token des Papers.
held_tokens = 32_768
pool_tokens = 995_296
kv_bytes_per_token = 57_000  # dezimale kB; ungefährer Paper-Wert
print(round(held_tokens / pool_tokens * 100, 2))       # 3,29 % des Token-Pools
print(round(held_tokens * kv_bytes_per_token / 1024**3, 2))  # rund 1,74 GiB

Das ist ein Kapazitätsbeispiel, keine beobachtete pausierte Session und keine Monatsrechnung. Für eine Abrechnung der KV-Residenz bräuchte man Blockeigentum und Haltezeit, Cache-Eviction-Verhalten, einen Preis für reservierte Kapazität und eine Regel für ungenutzte Blöcke. Weder rohe Token noch gleicher Zeitanteil messen KV-Byte-Sekunden. In der H100-Validierung waren nur 0,7–8,1 % des KV-Pools belegt; dieser Lauf zeigt also keine Kapazitätsgrenze des KV-Caches².

Kein Meter ist Ground Truth — und das Papier sagt es selbst

Der respektabelste Satz des Papiers ist, dass kein Meter ein Ground Truth ist, mit einer Positionierung gegen exakte Shapley-basierte Energiezuschreibung¹³. Gleicher Zeitanteil ist selbst eine Heuristik — er berechnet einem Request, der auf Prefill wartet, dasselbe wie einem decodierenden. Listenpreis-Gewichtung (Cache-Input zu 0,1x, Output zu 4x) ist kaum besser: Im Simulator entfernt sie den Agents-Tenant zwölf Punkte vom gemessenen Step-Zeit-Anteil². Keiner der beiden Meter begrenzt einen eindeutig richtigen Tenant-Anteil. Das Paper empfiehlt, den gewählten Meter zu veröffentlichen und ungenutzte GPUs, leere KV-Pools sowie Kommunikation zunächst als eigenen Overhead auszuweisen, bevor man sie per Richtlinie umverteilt². Das ist das On-Prem-Spiegelbild des Read-Preis-Kampfs auf Anbieterseite: Jemand zahlt für Cache-Residenz; die einzige Frage auf dem eigenen Cluster ist, ob man selbst wählt — oder der Join-Key.

Die Kubernetes-Seams: exzellente Befunde in synthetischer Verkleidung

Die andere Hälfte des Papiers — wo Zuschreibung zwischen Kubernetes-Allokationen, Gateway-Logs und Anbieterrechnungen bricht — ist seriöses Failure-Mode-Engineering, und das Papier ist mit seinem Geltungsbereich sorgsamer als die Zweitberichte. Es sind konstruierte Fälle: ein Monat synthetischer OpenCost-Allokationen für ein Multi-Pod-Deployment sowie synthetische Gateway-/Anbieterrechnungen über Mock-APIs. Beobachtete Produktionsrechnungen sind das nicht²:

• Labels nur auf LeaderWorkerSet-Leader-Pods lassen 66 % der GPU-Rechnung jenes Deployments herrenlos (65,9 % im Detaillauf)².
• Der naheliegende Fallback-Key senkt den Schlagzeilenwert des Unallocated-Anteils auf 4 % (4,4 %) — indem er $23.597, also 61 % der Rechnung, in einen Bucket namens vllm lenkt, dem app.kubernetes.io/name des Helm-Charts, das auf dem kanonischen Schlüssel name mit dem LeaderWorkerSet kollidiert².
• Das Aktivieren aller Quellen zählt das gesamte Gateway-Spending doppelt¹.
• Das Lesen einer einzigen Seite einer Billing-API meldet ein Viertel des Spendings¹.

Man lese den zweiten Punkt zweimal, denn er ist der eigentliche Beitrag: Der Fallback repariert die Zuschreibung nicht, er verwandelt herrenloses Spending in falsch zugeordnetes Spending, während die Schlagzeilenkennzahl besser aussieht. Ein Tool, das nur einen Unallocated-Prozentsatz meldet, kann dieses Szenario nicht von einem korrekten unterscheiden; die Lösung des Papiers ist, den Fallback-zugeordneten Betrag separat auszuweisen und die Kollisionsauflösung reihenfolgenunabhängig zu machen².

Die ersten beiden Befunde stammen aus dem synthetischen OpenCost-Monat, die letzten beiden aus Mock-Billing-APIs und synthetischen Kosten. Alle vier sind Demonstrationen mit Fixtures, Quellcode und protokollierten Ausgaben im Repository²⁴. Das Kommunikationsbeispiel nutzt PyTorch/Gloo-Zeitmessungen auf CPU über Loopback, um einen synthetischen Monat mit GPU-Allokationen zu dimensionieren; es ist keine Messung von NCCL-Verkehr auf GPUs. In diesem konstruierten Fall werden $12.059 kollektiver Kommunikation zugeschrieben und ein Token-proportionales Showback verschiebt $3.737 vom Tensor-Parallel-Tenant zum Pipeline-Parallel-Tenant. Bei der im Paper betrachteten GPU-näheren Sensitivitätsannahme von 10 % Kommunikation sind es $166².

Das Ökosystem bewegt sich in dieselbe Richtung

Das ist kein Einzelkämpfer-Problem. OpenCost 1.121.0 (Release vom 20. Juli 2026; am 5. August 2026 im CNCF-Blog angekündigt) lieferte „AI Inference Costs v1“ aus — erstmals verfügbare Kubernetes-Inferenz-Kostenerfassung auf Basis der vLLM-Metriken vllm:prompt_tokens_total und vllm:generation_tokens_total, validiert auf einem PoC-Cluster mit 109 GPUs und 30 Modellen, mit llm_total_hourly_cost und llm_cost_per_million_tokens über Prometheus und die REST-API⁵⁶. Die Design-Unterscheidung, die es trifft, ist genau die These des Papiers in Klempnerform: Allokationsbasierter Kosten pro Million Token ist die volle Hosting-Kosten — Gewichte, GPU und ein Anteil an Gateway und KV-Cache-Speicher —, während nutzungsbasierte Kosten nur die bei aktiver Inferenz verbrauchte Infrastruktur zählen, KV-Cache-Hit-Ersparnisse gutschreiben und die Kosten den tatsächlich verarbeiteten Tokens zuordnen⁵. Die Lücke zwischen diesen Kostenbasen auf Modellebene beschreibt im CNCF-Beispiel Hosting-Overhead; nutzungsbasiert $1,00/M gegen allokationsbasiert $4,00/M entspricht nach dessen Definition 25 % Auslastung⁵. Das hängt mit dem Thema zusammen, ist aber etwas anderes als der Vergleich von Tenant-Anteilen im Paper. OpenCost-PR #3845 listete Workload- und Team-Zuschreibung sowie detaillierte KV-Cache-Optimierungskosten bei der Aufnahme als künftige Arbeit; dieser Artikel prüft ihren Status in späteren Releases nicht⁷. unalloc selbst liegt auf PyPI bei 0.2.3 — der Release, auf den Archiv und Fixtures des Papiers gepinnt sind — und verbindet die vier großen Quellen, mit OpenCost-Allokationen als einer von mehreren Eingängen⁸¹.

Die praktische Checkliste für alle, die heute einen geteilten Inferenz-Server betreiben:

1. Die Messregel schriftlich festlegen — Token-Anteil, Zeit-Anteil oder ein Hybrid — und die Entscheidung ins Showback selbst schreiben, nicht ins Wiki.
2. Fallback-zugeordnetes Spending getrennt von Unallocated-Spending ausweisen. Ein Helm-Chart-Name darf nie eine Rechnung besitzen.
3. Beide Meter veröffentlichen, wenn Tenants streiten. Die 12-Punkte-Spanne ist die Größe des Streits, den man sonst führt.
4. Wer interne Tenants pro Token abrechnet, sollte separat festlegen, wie ungenutzte Kapazität, Cache-Residenz und gemeinsame Infrastruktur zugeteilt werden. Das H100-Experiment beziffert keine wahre Subvention eines Tenants.

Geltungsbereich, ein letztes Mal: Das 12–14-pp-Ergebnis stammt aus einem kontrollierten Multi-Tenant-vLLM-Lauf auf einer H100 mit vier synthetischen Tenants — sauber instrumentiert, reproduzierbar, aber keine Produktionsabrechnung. Die Seam-Prozentsätze sind per Konstruktion synthetische Allokationen. Die Beispiele zeigen plausible Fehlermodi; die Prozentsätze beschreiben diese konstruierten Szenarien.