Large Language Models (LLMs) haben sich zu zustandsbehafteten Systemen entwickelt, die den gesamten Gesprächsverlauf im Speicher behalten, um Antworten deutlich schneller und mit geringerem Rechenaufwand liefern zu können. Ermöglicht wird dies durch Prompt-Caching – ein Mechanismus, der den internen Zustand des LLMs im Arbeitsspeicher des Servers behält und so die erneute Berechnung bei jeder Anfrage vermeidet. Privatemode ist der erste KI-Inference-Service, der Prompt-Caching mit nachweisbarer Sicherheit kombiniert – dank Confidential Computing und offenem Quellcode. In diesem Beitrag erklären wir, wie wir das erreichen.
Hintergrund: Was sind KV‑Cache und Prompt Caching?
Der Key‑Value‑Cache (KV‑Cache) ist eine Datenstruktur, mit der beim Generieren einer Antwort die Attention‑Daten eines LLM zwischengespeichert werden. Die Inferenz‑Engine hält einen Cache der Attention‑Key- und Value-Vektoren des zuvor verarbeiteten Kontext, sodass diese nicht bei jedem generierten Token erneut berechnet werden müssen. Beim Erzeugen eines neuen Tokens wird das Attention‑Ergebnis mithilfe der gecachten Keys und Values berechnet. Anschließend werden die Keys und Values des aktuellen Tokens dem Cache hinzugefügt. Das spart Zeit und Rechenleistung, sorgt für eine hohe Generationsgeschwindigkeit und ist inzwischen Stand der Technik.
Prompt Caching, auch Context Caching genannt, führt dieses Prinzip weiter, indem der KV‑Cache einer ganzen Unterhaltung über mehrere Anfragen hinweg erhalten bleibt. So können mehrstufige Dialoge oder agentenbasierte Workflows nahtlos fortgesetzt werden, ohne jedes mal bei Null anzufangen.
Für LLM‑Inference bedeutet dies, dass der KV‑Cache für längere Zeit auf dem Server verbleibt – entweder im unverschlüsselten RAM oder sogar auf Festplatten. Das gilt für die meisten Inference‑Anbieter, doch Details zur konkreten Umsetzung sind selten öffentlich.
»Aber es ist doch gar nicht der Prompt selbst, sondern nur eine interne Repräsentation – ein Haufen Zahlen. Warum sollte mich das kümmern?«
Tatsächlich wird nicht der reine Text gespeichert, aber der KV‑Cache ist lediglich eine andere, erweiterte Repräsentation derselben Daten. Es ist das, was das LLM von einem Prompt sieht und denkt – und ein Modell könnte dir allein basierend auf dem KV‑Cache sagen, was im Prompt stand. Aus Sicherheitssicht ist das Auslesen des KV‑Caches also nicht weniger problematisch als das Auslesen des Prompts, selbst bei sehr langen Prompts.
Wie lässt sich der Cache also absichern? Du hast es erraten – durch Confidential Computing.
So bleiben Prompts sicher
Mit Confidential Computing werden Daten nicht nur während der Übertragung oder im Ruhezustand verschlüsselt, sondern auch im Arbeitsspeicher und sind vor externem Zugriff geschützt – einschließlich des Host‑Betriebssystems, der restlichen Infrastruktur und sogar des Cloud‑Providers. Seit NVIDIAs H100 lässt sich Confidential Computing nun auch auf GPUs ausweiten. Indem wir LLMs in solchen vertraulichen Umgebungen betreiben, können wir Prompts sicher cachen, ohne das Risiko, sie preiszugeben. Deine Prompts bleiben dank der Garantien von Confidential Computing und der Transparenz von offenem Quellcode nachweislich sicher, selbst vor Cloud‑Provider oder Sysadmins geschützt.
Side-Channel Leaks
Confidential Computing schützt Daten auch während der Inferenz, schließt jedoch nicht alle Risiken aus. Eine zentrale Herausforderung in sicheren Systemen sind Side‑Channel‑Angriffe – hier insbesondere zeitbasierte Angriffe, die verraten könnten, ob ein Prompt gecacht wurde, und Angreifern so Rückschlüsse darauf erlauben, welche Prompts aktuell im System liegen.
Privatemode nutzt vLLM, eine High‑Speed‑Inferenz‑Engine für LLMs. Um Prompt Caching sicher einsetzen zu können, mussten wir vLLMs' Prefix Cache – seine Implementierung eines Prompt‑Caches – gegen solche Side‑Channel‑Leaks schützen. Wir haben festgestellt, dass der Cache messbare Unterschiede in den Antwortzeiten zwischen Cache‑Hits und Cache‑Misses verursacht. Diese Timing‑Lücke wird zur Angriffsfläche: Ein Angreifer, der dasselbe Backend nutzt, kann Eingaben generieren und die Antwortzeiten messen, um herauszufinden, ob ein bestimmtes Prompt bereits gesehen wurde. So kann er Prompts Stück für Stück rekonstruieren.
So läuft ein Angriff ab
Schauen wir uns ein konkretes Szenario an, bei dem ein Angreifer Zugriff auf dasselbe Inferenz‑System hat wie du. Das könnte der Service‑Provider, der Admin eines selbst gehosteten Systems oder auch ein anderer regulärer Nutzer sein. Nutzt ihr Confidential Computing, kann er den Speicher nicht direkt auslesen, womit viele Bedrohungen bereits abgedeckt sind. Durch Prompt Caching kann er jedoch mit dem Dienst interagieren und über Antwortzeiten Prompts eines anderen Nutzers extrahieren.
So geht er vor: Der Angreifer bestimmt zunächst die Länge des System‑Prompts, etwa indem er den Token‑Verbrauch analysiert oder Antwortzeiten bei eigenen Anfragen mit wachsender Länge misst. Ist die Länge des System-Prompts bekannt, kann er dazu übergehen, Blöcke des Prompts zu rekonstruieren. Angenommen, der Cache arbeitet in Blöcken zu 16 Token, so muss der Angreifer diese 16 Token (~10 Wörter) erraten – Block für Block.
Bei jeder Anfrage beobachtet er die Antwortzeit des Systems:
- Cache-Miss: Die Antwort dauert spürbar länger, weil das Ergebnis von Grund berechnet werden muss
- Cache-Hit: Die ANtwort ist schneller, da der Cache wiederwerwendet wird.
Diese Zeitdifferenz – etwa 15 ms auf einer NVIDIA H100 mit Llama‑3.3‑Setup – genügt, damit der Angreifer weiß, ob seine Eingabe mit einem gecachten Token‑Block übereinstimmt. Mit diesem Feedback kann er den gesamten Prompt Block für Block extrahieren. Die Zahl möglicher Eingaben je Block ist zwar hoch, lässt sich aber auf sinnvolle Optionen reduzieren, z. B. mit Wörterbüchern oder sogar LLMs, um gültigen Text zu generieren. Der erste Block ist leichter zu erraten, weil das System‑Prompt enthalten ist und vermutlich nicht auf einer 16‑Token‑Grenze endet. Hat der Angreifer den ersten Block gefunden, setzt er den Angriff mit dem nächsten Block fort und nutzt dabei den bereits bestimmten Kontext.
Das ist kein rein theoretisches Risiko. Forschungsarbeiten haben gezeigt, dass solche Angriffe praktisch funktionieren und sensible medizinische Daten preisgeben können. Angreifer benötigen keine privilegierten Rechte: Sie könnten externe Nutzer sein, die eine öffentliche API angreifen, oder Insider in einer Organisation, die etwa Patientenakten, Rechtsdokumente oder andere vertrauliche Informationen extrahieren, die kürzlich vom System verarbeitet wurden.
So verhindern wir Side‑Channel‑Angriffe
Um das Problem zu lösen, haben wir Cache‑Salting in vLLM entwickelt, das die Prompt‑Caches verschiedener Nutzer voneinander trennt. Wenn Prompts im Cache gespeichert oder gesucht werden, wird ein geheimer, vom Nutzer bereitgestellter „Salt“ hinzugefügt[1]. So erscheinen ansonsten identische Eingaben für den Cache einzigartig, und können nur von Nutzern mit entsprechender Berechtigung verwendet werden. Es ist vergleichbar mit dem Einfügen zufälliger Wörter zu Beginn eines Prompts, sodass es praktisch unmöglich wird, ihn zu erraten – nur dass wir jeden Block absichern und so den gesamten Prompt schützen.
Wie in der Abbildung oben zu sehen, übergibt der Nutzer zusammen mit dem Prompt einen Cache‑Salt. Aus Effizienzgründen organisiert vLLM den Prompt‑Cache in Token‑Blöcken (in diesem Beispiel zwei Token; üblicherweise länger). Wenn der Cache‑Lookup‑Key per Hashing der Input‑Token berechnet wird, wird der Salt dem ersten Token‑Block hinzugefügt. Um Kollisionen zu vermeiden, haben wir zudem Unterstützung für das Hashen von Token mittels SHA‑256 umgesetzt. Der Hash eines Blocks fließt in den Hash des nächsten Blocks ein und erzeugt so eine eindeutige Sequenz von Cache‑Lookup‑Keys. Dies ist notwendig, da Attention‑Werte Informationen über vorherige Token enthalten und Blöcke nicht isoliert wiederverwendet werden können. Unvollständige Blöcke werden nicht gecacht, d. h. Attention‑Keys und ‑Values werden für diese Token neu berechnet.
Mit diesem Mechanismus kann ein Nutzer nur dann auf den Cache zugreifen, wenn er in folgenden Anfragen denselben Cache‑Salt mitliefert. Ein Angreifer, der das geheime Salt nicht kennt, erhält keine Cache‑Hits und kann daher keine Zeitdifferenzen messen. Damit konnten wir Prompt Caching sicher aktivieren.
Geschwindigkeitsvorteile
Mit aktiviertem Prompt Caching können wir die KI‑Inference für agentische Workloads stark beschleunigen und die User Experience deutlich verbessern. Wir haben den Einfluss des Prompt Cachings auf die End‑to‑End‑Antwortzeiten gemessen. Unser System bestand aus vLLM mit Cache Salting, einer NVIDIA H100 GPU mit Confidential Computing, und einem quantisierten Llama 3.3‑70B unter Verwendung von Anfragen unterschiedlicher Länge (1 000 Token und 10 000 Token). Zuerst schickten wir eine Initialanfrage mit einem Dokument im Kontext und anschließend eine Folgeanfrage mit demselben Dokument – einmal ohne Caching (without caching)) und einmal mit aktiviertem Caching (with caching).
Das Ergebniss ist eindrucksvoll: Prompt Caching minimiert die Antwortlatenz, insbesondere bei großem Kontext. Das Verarbeiten eines Dokuments mit 10 000 Token (etwa 6 000 Wörter bzw. 12 Seiten Text) dauert ohne Prompt Caching etwa 9 Sekunden. Jede weiter Anfrage mit dem Dokument an das Modell würde ebenfalls 9 Sekunden oder länger dauern. Mit aktiviertem Prompt Caching entfällt diese Verzögerung – dank der gecachten Attention‑Eingaben antwortet das Modell bereits nach etwa einer Sekunde.
Flexibles und kollaboratives Prompt Caching mit Privatemode AI
Unsere Implementierung des Prompt Cachings in Privatemode sorgt nicht nur für die Vertraulichkeit der Interaktionen einzelner Nutzer mit dem LLM, sondern ermöglicht auch eine granulare Konfiguration eines Caches, der von vertrauenswürdigen Nutzergruppen gemeinsam verwendet werden kann. So können unsere Kunden agentische Workloads und andere Use‑Cases über mehrere Nutzer hinweg effizient skalieren.
Zum Beispiel arbeiten Coding‑Agents mit großen Codebasen, sodass die Nutzung innerhalb eines Teams von der Wiederverwending des selben gemeinsamen Kontext profitiert. Durch Nutzung eines gemeinsamen Caches für Team‑Mitglieder entfällt die häufige Neuberechnung geteilten Code‑Kontexts, wodurch die Antwortzeiten sinken. Ebenso profitieren Teams, die mit großen, sensiblen Dokumenten arbeiten, von schnellen Antworten dank des gemeinsam gecachten Dokumentkontexts, während gleichzeitig Angriffe anderer Nutzer verhindert werden.
In unserer API ist Prompt Caching opt‑in und konfigurierbar. Du kannst entscheiden, ob Prompts nur für einen einzelnen Nutzer oder in einem Team‑, Projekt‑ oder sogar in einem organisationsweiten Cache gespeichert werden sollen. Wenn du mehr Kontrolle brauchst, kannst du den geteilten Cache für sensiblere Queries je Anfrage deaktivieren. Der Cache‑Salt wird client‑seitig erzeugt und muss sicher bleiben. Privatemode kann das auf dem Client-System übernehmen – es verwendet sichere, zufällige Salts – oder du verwaltest die Salts selbst, zum Beispiel um einen Cache mit ausgewählten Nutzern zu teilen.
In der Privatemode‑App ist Prompt Caching standardmäßig aktiviert – aber ohne Cache Sharing. Das heißt, lange Unterhaltungen oder hochgeladene Dokumente des Nutzers werden schnell verarbeitet. Es wird jedoch kein Cache zwischen Nutzern geteilt, solange dies nicht explizit konfiguriert ist.
Dieses flexible Setup bringt dir alle Geschwindigkeits‑ und Effizienzvorteile des Cachings, während deine Prompts stets vertraulich und unter deiner Kontrolle bleiben.
Fazit
Mit Confidential Computing und offenem Quellcode ist Sicherheit nachweisbar und für jeden überprüfbar. Prompt Caching liefert schnelle Antworten für wiederholten Kontext, doch der Cache muss geschützt werden. Wir haben Cache‑Salting in vLLM eingeführt – eine offene, sichere und flexible Methode, deine gecachten Prompts auch in Multi‑User‑ und Team‑Setups vor Side-Channel Angriffen zu schützen. Kombiniert mit Confidential Computing erhältst du schnelle und sichere KI‑Inference.
Wenn du vLLM in einer Multi‑Tenant‑Umgebung betreibst, empfehlen wir dir, kollisionsfreies SHA‑256‑Hashing für den Prompt‑Cache zu aktivieren und Cache‑Salting einzusetzen, um Side‑Channel‑Angriffe zu verhindern. Wir raten, Cache‑Salting in jedem Multi‑Tenant‑Setup einzusetzen, unabhängig von Confidential Computing, um das Risiko eines Prompt‑Leaks zu minimieren.
Und wenn du einen sofort einsatzbereiten Service suchst, der Confidential Computing und Prompt Caching zuverlässig vereint, wirf einen Blick auf Privatemode.
- Der Cache‑Salt ist hier nicht nur ein typischer kryptografischer Salt; er schützt zusätzlich den Inhalt des Prompts. Daher muss er geheim bleiben, im Gegensatz zu herkömmlichen Salts, die nicht vertraulich sein müssen.
