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? Die API-Anbieter haben die Frage bereits öffentlich beantwortet — Cache-Reads zum Zehntel des Input-Preises, Cache-Writes mit Aufschlag, das Ganze per Dekret in der Rate-Card, die wir im Cache-Read-Preiskrieg verfolgt haben. 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 das zu „12–14 Prozentpunkte bei jeder getesteten Last“; die exakten Lücken der Tabelle sind 11,7–13,6 — eine Rundung, die wir selbst an Tabelle 3 des Papiers nachgeprüft haben². Die Richtung kippt nie, und die Lücke weitet sich mit zunehmender Last. Parallel dazu liest die GPU-Auslastung 97–99 % über alle vier Lasten, und die Leistungsaufnahme folgt der Last — die Kiste ist bei jeder Stellung tatsächlich beschäftigt, weshalb der Widerspruch ein Messproblem und kein Idle-Kapazitätsartefakt ist².

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 ein Token-Meter Retrieval- und Agenten-Tenants falsch bepreist

Der Mechanismus ist derselbe, an den unser Agent-Fleet-Ökonomie-Stück auf der Anbieterseite immer wieder stieß: Cache-lastige Tenants verbrauchen GPU-Sekunden — ihr KV liegt resident im HBM, belegt paged Blocks und hält Speicher als Geisel für die nächste Runde —, verursachen aber fast keine frischen Token. Ein Token-Meter bepreist Durchsatz; die knappe Ressource in einem geteilten Prefix-Caching-Server ist Residenz. Das sind verschiedene Güter, und jedes Token-Meter bepreist das Gut, das der Cache-lastige Tenant am meisten verbraucht, systematisch zu niedrig.

Rechnen wir die Einheiten durch. Eine pausierte Agenten-Session mit 32.768 residenten KV-Tokens auf exakt dieser Konfiguration:

# H100-Lauf aus arXiv:2609.24991 Sec. 9: 57 KB KV/Token, 995.296-Token-Pool, 80 GiB HBM
# illustrativer On-Demand-H100-Stundenpreis: $2.50, im ganzen Guide konstant gehalten
GiB   = 1024**2               # in KB
kv_per_tok_kb = 57            # papiergemessen, Qwen2.5-7B bf16
hbm_gib       = 80
hourly        = 2.50
 
paused_tokens = 32_768        # residenter KV einer pausierten Agenten-Session
held_gib = paused_tokens * kv_per_tok_kb / GiB
residency_per_hour = hourly * held_gib / hbm_gib
print(round(held_gib, 2))              # 1.78
print(round(residency_per_hour, 4))     # 0.0557
print(round(paused_tokens / 995_296, 3))          # 0.033

Eine einzige pausierte Session hält 1,78 GiB — rund 3,3 % des gesamten Pools —, und ihr anteiliger GPU-Preis beträgt etwa \$0,06 pro Stunde, die sie dort liegt³. Nun die Messfrage als Monat:

month_hours = 24 * 30
held_gib = 32_768 * 57 / (1024**2)
resid_month = 2.50 * held_gib / 80 * month_hours   # eine pausierte Session, einen Monat gehalten
 
# dieselbe Session sendet ihren Kontext 24x/Tag erneut: alles Cache-Reads
read_tokens_month = 32_768 * 24 * 30
cache_read_bill   = read_tokens_month / 1e6 * 2 * 0.1   # 0,1x eines $2/1M-Input-Preises
print(round(resid_month, 2))     # 40.08
print(round(cache_read_bill, 2)) # 4.72
print(round(resid_month / cache_read_bill, 1))  # 8.5

Einen Monat resident gehalten, kostet die Session anteilig rund \$40 GPU-Zeit. Die Token-artige Rechnung für ihre 23,6 Mio. Cache-Read-Tokens — zum aggressiven 0,1x-Read-Rabatt, den Anbieter gern bewerben — liegt unter \\$5: eine Verpreiszierung von Residenz als Token um den Faktor 8,5. Diese Lücke ist gemessene Struktur, kein modellierter Pessimismus: Der Begleittext des Autors meldet für den Simulator des Papiers bei 3 Req/s eine gesamte Cache-Hit-Rate von 75 %, mit dem Agents-Tenant bei 92,6 % Prompt-Token-Hits und Search bei 33,7 %⁴. (Diese Simulator-Tenant-Zahlen stammen aus der synthetischen Fallstudie, nicht aus dem H100-Lauf — die Kennzeichnung zählt, und wir behalten sie bei.)

Die 11,7–13,6 Punkte des Papiers sind also kein Rauschen; sie sind der messbare Preis dafür, Bandbreiten-Sekunden als Token zu behandeln. Die Arithmetik oben ist dieselbe Physik und erklärt, warum die Richtung der Lücke nicht kippen kann: Das Token-Meter stellt dem Retrieval-Tenant Prompt-Bytes in Rechnung, die er überwiegend aus dem Cache neu liest, während das Zeit-Meter ihm Wanduhrzeit in Rechnung stellt, deren Batches er mit allen teilt.

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². Das Token-Meter und das Zeit-Meter klammern die Wahrheit für einen geteilten Server ein, und die Empfehlung des Papiers ist die richtige: Die Messregel explizit festlegen, die Anteile veröffentlichen und aufhören, so zu tun, als reiche die Autorität der Gesamtsumme des Hauptbuchs bis zu ihrer Aufteilung. 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 handelt sich um Sonden eines konstruierten Multi-Pod-Szenarios: ein Monat synthetischer OpenCost-Allokationen, keine beobachteten Abrechnungsdaten¹:

• 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².

Wir kennzeichnen alle vier Seam-Befunde als Synthetik-Allokations-Szenario, papierverifiziert — reale Fehlermodi, demonstriert an konstruierten Daten, mit Rohausgaben im Repo⁶. Der Befund zur Kommunikation verallgemeinert dieselbe Vorsicht: GPU-Zeit in NCCL-Collectives summiert sich auf \$12.059 des synthetischen Monats, und ein Token-proportionales Showback davon verschiebt \\$3.737 vom Tensor-Parallel-Tenant auf den Pipeline-Parallel-Tenant².

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 beiden ist der Preis dafür, das Modell warm und bereit zu halten; das eigene Beispiel des CNCF-Posts ist nutzungsbasiert \$1,00/M gegen allokationsbasiert \\$4,00/M — ein Auslastungsverhältnis von 25 %⁷. Diese Lücke ist dieselbe Größe, die die Meter des Papiers Tenant für Tenant einklammern, und die KV-Cache-Hit-Gutschrift ist genau dort, wo die Messentscheidung steckt: Sie ist eine Preisrichtlinie — jemand hat entschieden, dass Cache-residente Reads günstiger sind —, exakt die Entscheidung, die arXiv:2609.24991 explizit und nicht als Erbschaft eines Metriknamens getroffen sehen will. Workload- und Team-Zuschreibung bleiben auf der OpenCost-Seite offen⁷⁹, also wird die offene Frage — welcher Meter speist diese Zeilen — pro Betreiber entschieden, meist zufällig. 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, muss wissen, dass man Cache-residente Agenten-Tenants ungefähr um die Residenz-Arithmetik oben subventioniert — und entscheiden, ob diese Subvention das Produkt ist.

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 Fehlermodi sind real; die Zahlen sind Demonstrationen. In diesem Genre ist das keine Schwäche — es ist die einzige ehrliche Art zu publizieren.