Der Cache, den wir wieder ausgebaut haben
Der Cache funktionierte genau wie entworfen. Ähnliche Fragen kamen sofort zurück, die Kosten fielen um rund zwanzig Prozent, und die Entwurfsprüfung, die ihn entfernte, dauerte fünfzehn Minuten — nachdem jemand fragte, was eine schnelle Antwort eigentlich verrät.
Was er leistete und was er verriet
Die Plattform bedient mehrere Unternehmen aus einem Deployment. Vor dem Generierungsschritt saß ein semantischer Cache: War eine eingehende Frage nah genug an einer bereits beantworteten, kam die gespeicherte Antwort ohne Modellaufruf zurück. Die Kosten fielen um rund ein Fünftel, die mittlere Latenz verbesserte sich deutlich.
Das Problem ist nicht, dass Antworten eine Grenze überschritten hätten. Taten sie nicht; der Cache war mandantenbezogen geschlüsselt. Das Problem ist die Zeit. Eine Frage, die in achtzig Millisekunden statt zwei Sekunden beantwortet wird, sagt dem Fragenden, dass diese Frage kürzlich gestellt wurde — und auf einer Plattform, auf der zwei Mandanten konkurrieren, ist das eine Information über einen Wettbewerber.
Warum das leicht zu übersehen war
Jede Prüfung, die wir gemacht hatten, fragte, ob Daten zwischen Mandanten wandern können. Die Antwort war zu Recht nein, und dort hörten wir auf. Der Kanal ist nicht der Inhalt der Antwort, sondern der Umstand, dass sie schnell eintrifft — und den bildet kein Datenflussdiagramm ab.
Das ist die allgemeine Gestalt der Lektion. Isolationsprüfungen sehen auf das Zurückgegebene, und eine geteilte Ressource kann über Dauer, Erfolg oder Kosten offenlegen — nichts davon steht in der Nutzlast.
Die Forschung, die es benannt hat
Song und Kollegen veröffentlichten in jenem September eine Arbeit zu Timing-Seitenkanälen in Systemen, die große Sprachmodelle ausliefern, und untersuchen, wie geteilte Infrastruktur wie Caching es einem Nutzer erlauben kann, allein aus der Antwortzeit auf die Anfragen eines anderen zu schließen.
Wir hatten unseren Cache zum Zeitpunkt der Lektüre bereits entfernt, aufgrund einer unangenehmen Frage in einer Prüfung. Die Arbeit lieferte das Vokabular und die Gewissheit, dass es sich um eine bekannte Klasse handelt und nicht um eine Eigenart unseres Entwurfs — was verändert hat, wie wir es Kunden heute beschreiben.
| Cache-Reichweite | Was wir betreiben |
|---|---|
| Mandantenübergreifend, semantisch | Nie. Genau dieser Fall wurde entfernt |
| Je Mandant, semantisch | Ja, für Mandanten mit hohem Volumen |
| Je Mandant, exakte Wiederholungen | Ja, überall |
| Embeddings unserer eigenen Dokumente | Ja. Keine Nutzereingabe beteiligt |
Was wir behalten haben
Den größten Teil der Ersparnis, wie sich zeigte. Caching innerhalb eines Mandanten ist unbedenklich, denn wer die Zeit beobachten kann, ist ohnehin zum Inhalt berechtigt — und bei den größeren Mandanten liegt die Trefferquote im eigenen Verkehr nicht weit unter der geteilten.
Wir cachen außerdem beherzt dort, wo gar keine Nutzereingabe beteiligt ist: Embeddings unseres eigenen Bestands, Reranker-Ausgaben für feste Passagenpaare und Vorlagenfragmente. Dieser Teil der Rechnung brauchte nie einen geteilten Cache — und dort steckt ein überraschender Anteil der Kosten.
Der Kanal, der bleibt
Caching je Mandant leckt weiterhin innerhalb eines Mandanten. Ein Nutzer kann erfahren, dass ein Kollege kürzlich Ähnliches gefragt hat, und in einer Organisation, in der Personal- oder Rechtsabteilung denselben Assistenten nutzen, ist das nicht nichts.
Wir behandeln das über Reichweite statt über Verzicht: Assistenten für sensible Funktionen laufen mit eigenem Cache und eigenem Index. Das ist mehr Infrastruktur und die einzige Antwort, die wir gefunden haben, die nicht darauf beruht, dass niemand auf die Idee kommt zu messen.
Was wir heute in Entwurfsprüfungen fragen
Drei Fragen zu jeder geteilten Ressource. Kann ein Mandant beobachten, dass ein anderer sie genutzt hat? Kann er beobachten, wie viel? Kann er beobachten, wann? Lautet eine Antwort ja, wird die Ressource partitioniert — oder sie führt keine aus Nutzern abgeleiteten Daten.
Das ist bewusst gröber als ein Bedrohungsmodell, und grob hat bei uns besser funktioniert. Es fängt Caches, mandantenübergreifende Ratenbegrenzungen, Kosten-Dashboards mit falscher Aggregationsebene und Fehlermeldungen, die nicht gefunden von nicht erlaubt unterscheiden.
Was der Ausbau gekostet hat
Rund sechs Prozent auf der Monatsrechnung, nachdem wir das Caching je Mandant neu gebaut hatten — gegenüber den zwanzig Prozent, die der geteilte Cache gespart hatte. Die mittlere Latenz stieg für die kleinsten Mandanten, die am wenigsten von einem Cache des eigenen Verkehrs haben und am meisten von dem der anderen hatten.
Wir haben diesen Kunden den Grund genannt, was ein besseres Gespräch war, als es klingt. Ein Anbieter, der erklärt, das System sei etwas langsamer, weil es sie nicht länger gegenüber ihren Wettbewerbern offenlegt, hat keine schwierige Botschaft zu überbringen.
Was wir nicht behaupten
Wir behaupten nicht, geteilte Caches seien immer falsch. In einem Einzelmandanten-Deployment oder wo alle Nutzer in einer Organisation ohne innere Grenzen sitzen, stellt sich die Sorge nicht, und die Ersparnis ist real.
Wir behaupten auch nicht, jeden Zeitkanal gefunden zu haben. Wir haben einen gefunden, weil jemand in einer Prüfung eine gute Frage stellte — und die ehrliche Position ist, dass diese Klasse jedes Mal leicht zurückkehrt, wenn eine neue geteilte Komponente nach einer offensichtlichen Optimierung aussieht.
