Ein Cache-Hit gilt in den meisten LLM-Stacks als Beleg dafür, dass Rechenarbeit gespart wurde. Ein synthetischer Kontrolltest, über den dieser Text berichtet, widerspricht dieser Annahme: Ein Treffer ist zunächst nur die Aussage eines einzelnen Bausteins im System, und sie kann falsch sein, ohne dass ein Evaluator anschlägt. Das klingt nach Wortklauberei, ist aber der Kern jeder LLM Cache Verifikation. Ein Laufzeit-System kann acht gecachte Tokens melden, während der Prompt-Pfad genau diese acht Tokens erneut durchrechnet.
Ein solches System kann Zustand wiederverwenden und trotzdem eine andere Antwort zurückgeben. Es kann einen isolierten Namespace als Miss ausweisen, ohne zu sagen, ob Isolation, Eviction oder ein kalter Cache dafür verantwortlich war. Die Engine Attestation ist eine Aussage. Ob sie stimmt, ist eine zweite, unabhängige Frage. Der Prüfaufwand liegt genau dazwischen.
Als Bild taugt ein Lieferschein im Lager. Er dokumentiert, welche Ware das Lager verlassen hat, und im Alltag funktioniert das gut. Nur belegt er nicht, dass die Ware tatsächlich vom Regal kam und nicht doch neu kommissioniert werden musste. Diese Lücke zwischen Dokument und tatsächlicher Bewegung ist der Gegenstand des Tests. Der Entwickler von LLMTraceFX beschreibt ihn als deterministische, synthetische Kontrolle auf Token-Ebene, veröffentlicht im zusammengeführten Pull Request #74 zum Commit 1a1c195526c42ad0b06648e4840ca19b57767f5a.
Der Aufbau ist schlicht. Ein fester Anfrageablauf läuft durch einen Token-Level Cache. Ein unabhängiges Orakel berechnet aus exakter Token-Identität und festgeschriebener Cache-Policy, welches Präfix sicher wiederverwendbar ist. Die Engine meldet ihre Wiederverwendung, der Prompt-Pfad protokolliert die tatsächlich verarbeitete Arbeit, und eine Kontrolle ohne Cache liefert die Prüfung von Ausgabe-Identität und Aufgabenkorrektheit. Zehn Fälle genügen, um zu zeigen, wie weit diese vier Aussagen auseinanderliegen können.
Zehn Fälle auf neun Tokens: drei verschiedene Wahrheiten
Die Referenzfolge umfasst zehn Fälle, und fast alle drehen sich um dieselben neun Tokens. Der exakte Doppellauf ist der saubere Positivfall: Das Orakel erwartet acht wiederverwendbare Tokens, die Engine attestiert acht, und der Prompt-Pfad verarbeitet ein einziges. Das Urteil lautet verified_hit, also ein verifizierter Treffer mit 8/9 wiederverwendeten und 1/9 verbleibenden Prompt-Tokens. Damit ist ein verified hit partial reuse verdict sauber abgegrenzt, bevor die schwierigen Fälle beginnen.
Dieselben neun Tokens ergeben in einem anderen Fall ein anderes Bild. Eine Mutation im Inneren der Sequenz stoppt die Wiederverwendung bereits bei Token drei: drei von neun wiederverwendet, sechs von neun als Prompt-Arbeit. Das Urteil heißt partial_reuse. Eine Mutation an der Grenze lässt vier sichere Tokens übrig, eine Änderung am Ende sogar acht, wobei das geänderte Schluss-Token neu berechnet wird — wieder partial_reuse, kein voller Treffer.
Ein Fall sieht harmlos aus und ist es nicht. same-length-different-ids enthält ebenfalls neun Tokens, aber ihre IDs unterscheiden sich. Das Orakel erwartet null Wiederverwendung, die Engine attestiert null, und der Prompt-Pfad verarbeitet alle neun Tokens. Gleiche Länge erzeugt keine Identität. Ein Werkzeug, das nur Länge und Trefferquote protokolliert, hätte diesen Fall als Treffer verbucht.
In allen zehn Fällen konstant bleibt: Ausgabe-Identität und Evaluator bestehen durchgehend, die Wiederverwendung hat die Antwort also nicht verändert und die Aufgabe blieb korrekt gelöst. Beide Prüfungen sagen aber nichts über den Cache-Befund aus. Sie beantworten andere Fragen: ob Reuse die Ausgabe verändert hat und ob das Ergebnis korrekt geblieben ist. Ein bestandener Evaluator ist kein Freibrief für eine falsche Attestation.
Fünf unabhängige Prüfungen statt einer Selbstauskunft
Ein System kann sich nicht selbst bescheinigen, dass sein Cache-Bericht stimmt. Deshalb prüft die Cache Hit Verifikation in diesem Aufbau gegen fünf unabhängige Instanzen. Das Token-Orakel leitet aus exakter Anfrage, Cache-Zustand, Namespace und Policy das erwartbare Präfix ab. Die beobachtete Prompt-Arbeit zählt die Tokens, die der Prompt-Pfad wirklich verarbeitet hat. Beide Werte müssen zur Engine Attestation passen, sonst fällt die Behauptung durch.
Hinzu kommen zwei weitere Ebenen. Die Ausgabe-Identität vergleicht die Token-Arrays mit und ohne Cache, und der Evaluator prüft, ob das deterministische Aufgabenergebnis korrekt bleibt. Ein korrekter Reuse-Zähler beweist noch nicht, dass die Antwort gleich geblieben ist. Eine token-identische Ausgabe beweist noch nicht, dass die Aufgabe bestanden wurde. Zum Schluss bindet ein hashgebundener Verifier Schemas, Artefakte, Quellcode-Digest, Allowlist, Verdict-Prädikate und Prüfsummen aneinander.
Die Kette ist fail-closed gebaut. Wenn ein einzelner Wert sich bewegt, ohne dass die anderen mitziehen, hält die Behauptung nicht. Timing und Laufzeit-Speicher stehen in diesem Kontrolltest auf null, und das ist ausdrücklich nicht null Sekunden oder null Byte. Kein Token-Zähler wird in gesparte Millisekunden umgerechnet, keine geschätzte vermiedene Arbeit wird als beobachtete Rechenleistung ausgegeben.
Gleiche Token-Anzahl ist nicht gleiche Token-Identität
Drei Fälle enthalten neun Eingabe-Tokens und verarbeiten neun Tokens: cold, same-length-different-ids und namespace-isolation. Die Gründe dafür sind grundverschieden. Der kalte Fall hat keinen Kandidaten, beim namensgleichen Fall stimmen die Token-IDs nicht, und der isolierte Fall sieht einen Kandidaten aus einem fremden Namespace schlicht nicht. Eine Kennzahl, die nur Anfragelänge und Trefferquote speichert, wirft diese drei Zustände in einen Topf.
Für die Verifikation ist das ein Problem. Länge kann eine Anfrage beschreiben, aber keine wiederverwendbare Zustandsbasis belegen. Der Auditor führt deshalb exakte Token-Identität und Namespace im Claim-Pfad mit. Wer einen Token-Level Cache bewertet, sollte sich dieselbe Frage stellen: Misst die Metrik Identität, oder misst sie nur Ähnlichkeit? Davon hängt ab, ob ein Bericht belastbar ist oder nur plausibel klingt.
Mutation, Isolation, Eviction: drei Ursachen für null Wiederverwendung
Bei der Wiederverwendung zählt nicht Ähnlichkeit, sondern Präfix-Identität. Eine Mutation nach Token drei lässt drei Tokens übrig, eine Mutation an der Grenze vier, ein geändertes Suffix acht. Für einen Menschen mögen die Anfragen fast gleich aussehen. Für das Orakel legt das erste abweichende Token die sichere Reuse-Grenze fest. Deshalb vergleicht der Test erwartete Reuse, attestierte Reuse und Prompt-Arbeit in derselben Zeile. Wandert ein Wert ohne die anderen, schlägt die Prüfung fehl.
Null Wiederverwendung beschreibt zudem eine Menge, nicht eine Ursache. Namespace-Isolation heißt: Ein ansonsten passender Kandidat lag außerhalb des Namensraums der Anfrage. Eviction heißt: Ein zuvor residenter, kompatibler Kandidat wurde unter kontrolliertem Kapazitätsdruck entfernt. Ein kalter Miss heißt: Es gab überhaupt keinen wiederverwendbaren Vorgänger. Alle drei erscheinen als null Prozent Reuse und sehen in einer Dashboard-Kachel identisch aus.
Der Unterschied wird erst über Typen und Belege sichtbar. capacity-seed, cold, capacity-pressure und namespace-isolation tragen das Urteil verified_miss; ihre Fallkonfiguration und Evidenzfelder halten die unterschiedlichen Ursachen fest. Der Fall capacity-revisit endet dagegen mit dem eigenen Urteil evicted, gestützt auf ein aufbewahrtes Vorgänger-Beweismittel und kontrollierte Residenz-Beobachtungen. Die reine Verdict-Enum allein unterscheidet einen kalten Zustand nicht von einer Namespace-Isolation.
Was der Nachweis nicht belegt
Die Grenze ist im Demo benannt, und sie ist groß. Der Test validiert Auditor, Orakel, Attestation-Pfad, Evaluator, Schemas, Datenschutzregeln, Hashes und den eigenständigen Verifier. Er belegt keine MLX- oder vLLM-Beschleunigung, keine Produktionskorrektheit von Caches, keine Anbieter- oder Hardware-Identität, keine GPU-Leistung, keine Latenzeinsparung und keine Laufzeit-Speichereinsparung. Auch blockweises Cache-Verhalten ist nicht Gegenstand dieses Token-Level-Tests.
Das ist Absicht, kein Mangel. Ein synthetic cache control test auf Token-Ebene ist ein Prüfstand für die Beweiskette, nicht für die Silizium-Performance. Wer aus einem einzelnen verified_hit auf einen schnelleren Inference-Stack schließt, überzieht die Datenlage. Was der Test zeigt, ist die Grenze: Ein Cache-Hit reicht als Beweis nicht aus. Er wird erst durch Orakel, Arbeit, Ausgabeidentität, Evaluator und Hash-Bindung zur cache prefix reuse attestation.
Reproduktion, Prüfsummen und die Lücke zwischen Prüfen und Benutzen
Der Nachweis ist reproduzierbar. Aus dem zusammengeführten LLMTraceFX-Repository erzeugt ein Make-Ziel das verifizierte Bundle, der öffentliche Snapshot liegt unter examples/cache-audit/kv-truth-demo. Nach dem Lauf dokumentiert das README einen gesperrten Offline-Befehl, der das erzeugte Bundle prüft, ohne dem installierten Einstiegspunkt vertrauen zu müssen. Die Integrität hängt an festgeschriebenen SHA-256-Werten für Prüfsummendateien, Bundle, report.html, evidence_bundle.py, truth-table.json sowie Demo- und Historical-Snapshot. Ohne diese Bindung wäre die schönste Tabelle wertlos.
Die Prüfung vor dem Merge war aufwendig. Die vollständige lokale Suite lief mit 4.749 bestandenen und 3 übersprungenen Tests, die fokussierte Evidence-Catalog-Suite mit 91 bestandenen Tests. Der exakt freigegebene Head durchlief eine Sechs-Job-Matrix, Build- und Wheel-Prüfungen, beide sauberen Bootstrap-Pfade, Qualitätsprüfungen sowie CodeQL-Workflow und -Analyse. Reviews aus Code, Security, Operations-UX und Methodik fielen sauber aus.
Eine Review fand dabei ein Time-of-Check-to-Time-of-Use-Risiko bei der Ausführung des eigenständigen Verifiers. Die zusammengeführte Änderung behebt es, indem sie vor der Ausführung ein privates, verifiziertes Skript mit exklusiver O_EXCL-Semantik anlegt. Abschließende Review und Checks decken genau diesen Fix ab. Das zeigt, wie eng Verifikation hier gefasst ist, und wie viel Arbeit zwischen einem plausiblen Bericht und einem belastbaren Nachweis liegt.
Für die Praxis stellt sich also eine andere Frage: Kann für einen einzelnen Treffer gezeigt werden, welches Präfix identisch war, wie viel Prompt-Arbeit übrig blieb und ob die Ausgabe gleich und korrekt geblieben ist? Wer Prompt Caching betreibt und die Trefferquote als Beweis für gesparte Arbeit behandelt, verlässt sich auf einen Lieferschein ohne Regalprüfung. Der Kontrolltest mit neun Tokens liefert dafür kein fertiges Produkt, aber ein brauchbares Prüfraster: drei Wiederverwendungsgrade, vier Urteilstypen und eine Kette, die hält, wenn alle fünf Prüfungen übereinstimmen.
Quelle: siddhantkhare.com
