Mandantenfähiger LLM-Betrieb

Szenario

Ein Großkunde meldet seit zwei Wochen schlechte Antworten. Eure aggregierten Qualitäts-Proxymetriken sind unauffällig. Der Dienst hat rund 40.000 Mandanten; ein Vorschlag ist, alle Qualitätsmetriken künftig mit der Mandantenkennung als Metrik-Dimension zu erfassen.

Anforderungen

• Wie machst du Mandantenprobleme sichtbar, ohne das Metrik-System zu sprengen?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Aggregierte Metriken behalten, die Mandantenkennung als Attribut an Traces und Logs führen und nur für eine begrenzte, gepflegte Menge großer oder auffälliger Mandanten eigene Zeitreihen erzeugen. Richtig. Hohe Kardinalität gehört zu Traces und Logs, nicht in Metrik-Dimensionen. Eine kleine, bewusst gepflegte Ausnahmeliste deckt genau die Fälle ab, in denen ein einzelner Mandant geschäftlich zählt.
2. Plausibler Fehlweg: Alle Metriken nach Mandant aufschlüsseln, Speicher ist billiger als ein unentdeckter Kundenverlust. 40.000 Dimensionswerte multiplizieren jede Metrik und treffen ein Zeitreihen-System an seiner strukturellen Schwäche — typischerweise werden dann alle Metriken langsam oder unzuverlässig, auch die, die vorher funktionierten.
3. Plausibler Fehlweg: Auf Mandantenmetriken verzichten und stattdessen Meldungen aus dem Support als Signal nehmen. Genau dieser Pfad hat zwei Wochen gekostet. Support-Meldungen sind ein Spätindikator mit hoher Dunkelziffer — die meisten unzufriedenen Nutzer melden sich nicht.
4. Plausibler Fehlweg: Die aggregierten Metriken feiner takten, damit kleine Ausschläge sichtbar werden. Höhere Zeitauflösung hilft bei kurzen Ereignissen, nicht bei einem Anteilsproblem: Ein Mandant mit einem Bruchteil des Gesamtverkehrs bleibt im Aggregat unsichtbar, egal wie fein die Zeitachse ist.

Szenario

Ein Plattformteam braucht globale Betriebsmetriken; Mandantenadministratoren dürfen ausschließlich ihre eigenen Diagnosedaten sehen. Inhalte können vertrauliche Nutzdaten enthalten.

Anforderungen

• Ordne jedes Artefakt der engsten angemessenen Sichtbarkeitszone zu.
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Latenzverteilung des einzelnen Mandanten. Zuordnung zur Zone tenant.
2. Tragfähiger Ansatz: Aggregierte Queue-Sättigung des gesamten Dienstes. Zuordnung zur Zone platform.
3. Tragfähiger Ansatz: Vollständiger Prompt mit möglichem Kundengeheimnis. Zuordnung zur Zone restricted.
4. Tragfähiger Ansatz: Fehlertrace mit serverseitig bestimmter Mandantenkennung. Zuordnung zur Zone tenant.
5. Tragfähiger Ansatz: Anteil nicht bereiter Inferenzinstanzen ohne Mandantendimension. Zuordnung zur Zone platform.
6. Tragfähiger Ansatz: Unredigierte Modellausgabe eines konkreten Nutzers. Zuordnung zur Zone restricted.

Szenario

Ein Mandant startet einen Massenimport und schickt Anfragen mit sehr langem Kontext. Die Anfragerate bleibt unter dem geltenden Limit von 100 Anfragen pro Minute pro Mandant, trotzdem steigt für alle anderen Mandanten die Latenz um ein Vielfaches. Die Beschleuniger-Kapazität ist erschöpft.

Anforderungen

• Wie ziehst du das Kontingent neu?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Das Kontingent auf die knappe Ressource beziehen — verarbeitete Ein- und Ausgabemenge beziehungsweise gleichzeitig belegte Arbeit je Mandant — statt auf die Anzahl der Anfragen. Richtig. Ein Limit schützt nur, wenn es die Größe begrenzt, die tatsächlich knapp ist. Bei stark variablem Aufwand pro Anfrage ist die Anfragezahl kein Maß für Verbrauch.
2. Plausibler Fehlweg: Das Anfragelimit von 100 auf 20 pro Minute senken. Das bestraft alle Mandanten mit vielen kleinen Anfragen und lässt den eigentlichen Verursacher — wenige, sehr teure Anfragen — weiterhin durch. Die Bezugsgröße bleibt falsch.
3. Plausibler Fehlweg: Die maximale Kontextlänge global begrenzen. Eine plausible Schutzmaßnahme, aber sie deckelt nur eine Dimension: Der Mandant könnte weiterhin sehr viele mittellange Anfragen mit hohem Gesamtverbrauch schicken. Als Ergänzung sinnvoll, als Kontingent nicht ausreichend.
4. Plausibler Fehlweg: Kapazität hinzufügen, damit die Spitze verkraftbar wird. Ohne wirksames Kontingent verschiebt zusätzliche Kapazität nur die Grenze: Der nächste Massenimport füllt auch sie und trifft alle anderen erneut.

Szenario

Ein neuer Großkunde verlangt vertraglich zugesicherten Durchsatz zu jeder Tageszeit, Datenverarbeitung ausschließlich in einer bestimmten Region und einen Nachweis, dass seine Inhalte nie mit denen anderer Kunden in denselben Speicherstrukturen liegen. Euer Dienst läuft heute als geteilte Bereitstellung in zwei Regionen mit Kontingenten je Mandant.

Anforderungen

• Wie erfüllst du die Anforderungen?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Für diesen Kunden eine eigene Bereitstellung in der geforderten Region betreiben und die Mehrkosten in den Vertrag einpreisen. Richtig. Zugesicherter Durchsatz unabhängig von Nachbarn, regionale Bindung und getrennte Speicherstrukturen sind zusammen nicht mehr durch Kontingente in einer geteilten Bereitstellung darstellbar — die Anforderung bestimmt hier die Isolationsstufe.
2. Plausibler Fehlweg: Dem Kunden ein großzügigeres Kontingent geben und Kapazität aufstocken — als identische Grenze für alle Mandanten, Datenräume und Serviceklassen umgesetzt. Ein Kontingent begrenzt nach oben, es sichert nichts nach unten zu: Bei gleichzeitiger Spitzenlast anderer Mandanten ist der zugesagte Durchsatz nicht garantiert. Region und Speichertrennung bleiben ebenfalls offen.
3. Plausibler Fehlweg: Die Anforderungen ablehnen, weil geteilte Infrastruktur der Kern eures Betriebsmodells ist. Eine legitime Geschäftsentscheidung, aber keine technische Bewertung — die Frage war, wie die Anforderungen erfüllbar sind, und erfüllbar sind sie mit einer eigenen Bereitstellung.
4. Plausibler Fehlweg: Die Mandantenkennung in alle Cache-Schlüssel und Indexfilter aufnehmen; damit sind die Daten getrennt. Das erfüllt die logische Trennung, aber weder den zugesicherten Durchsatz noch die regionale Bindung — und „nie in denselben Speicherstrukturen“ verlangt mehr als einen Filter im gemeinsamen Index.

Szenario

Euer geteilter LLM-Dienst bedient mehrere Kundenmandanten. Im Architektur-Review geht es um die Frage, an welchen Stellen die Mandantenkennung Teil der Struktur sein muss — also Schlüssel, Filter am Ort der Auswahl oder getrennter Speicher — und wo eine nachgelagerte Maßnahme ausreicht, weil dort keine mandantenfremden Inhalte entstehen können.

Anforderungen

• Ordne jede Stelle danach ein, ob sie die Mandantenkennung strukturell braucht oder ob eine nachgelagerte Maßnahme genügt.
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Antwort-Cache, der Ergebnisse über Mandanten hinweg wiederverwendet. Zuordnung zur Zone structural.
2. Tragfähiger Ansatz: Gemeinsamer Vektorindex, aus dem Kontextpassagen abgerufen werden. Zuordnung zur Zone structural.
3. Tragfähiger Ansatz: Trace-Speicher, der vollständige Prompt- und Antwortinhalte enthält. Zuordnung zur Zone structural.
4. Tragfähiger Ansatz: Aus Produktionsverkehr aufgebautes Regressions-Testset. Zuordnung zur Zone structural.
5. Tragfähiger Ansatz: Latenz-Histogramm des Dienstes ohne Inhaltsbezug. Zuordnung zur Zone downstream.
6. Tragfähiger Ansatz: Öffentliche Statusseite mit Verfügbarkeitsangaben des Gesamtdienstes. Zuordnung zur Zone downstream.

Szenario

Ein regulierter Mandant fordert nach einem Audit nachweisbar eigene Schlüssel, getrennte Netzwerkgrenzen und keine gemeinsame Beschleunigerbelegung. Der bisherige Dienst trennt logisch über IDs, RBAC und Quoten.

Anforderungen

• Welche Architekturentscheidung entspricht der neuen Grenze?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Den Mandanten in eine dedizierte Betriebszelle mit eigener Daten-, Schlüssel- und Compute-Grenze verschieben. Die geforderten physischen und administrativen Grenzen lassen sich nicht allein durch zusätzliche logische Filter im gemeinsamen Pfad belegen.
2. Plausibler Fehlweg: Im gemeinsamen Dienst lediglich das Requestlimit senken und die vorhandene Mandanten-ID länger machen. Weder ein niedrigeres Kontingent noch ein längerer Identifikator erzeugt getrennte Schlüssel, Netzwerke oder Compute-Ressourcen.
3. Plausibler Fehlweg: Nur ein eigenes Dashboard bereitstellen, während Cache, Schlüssel und Beschleuniger vollständig geteilt bleiben. Getrennte Sichtbarkeit ist keine getrennte Verarbeitung. Das Dashboard erfüllt die geforderten technischen Grenzen nicht.
4. Plausibler Fehlweg: Alle übrigen Mandanten ebenfalls in dieselbe neue Zelle verschieben und sie dort weiterhin gemeinsam betreiben. Damit bleibt die beanstandete gemeinsame Belegung bestehen und der Kostenpreis dedizierter Isolation wird trotzdem bezahlt.

Szenario

Ein gemeinsam genutzter Assistent liefert selten Dokumente des falschen Mandanten. Der Modellaufruf selbst ist korrekt isoliert; die Vermischung entsteht früher.

Anforderungen

• Welches Ereignis verletzt die Mandantengrenze?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Tragfähiger Ansatz: Den Cache-Key und jeden Cache-Eintrag an die serverseitig bestimmte Mandantenidentität und Datenversion binden. Der Cache wird Teil derselben Mandantengrenze wie Retrieval und Autorisierung. Eine fremde Passage kann dann nicht über einen identischen Fragetext wiederverwendet werden.
2. Plausibler Fehlweg: Die tenant_id aus einem zusätzlichen freien Promptfeld des Nutzers übernehmen und vor die Frage setzen — als identische Grenze für alle Mandanten, Datenräume und Serviceklassen umgesetzt. Nutzereingaben sind keine vertrauenswürdige Identitätsquelle. Damit könnte der Aufrufer die Grenze selbst wählen.
3. Plausibler Fehlweg: Nur den Modellanbieter pro Mandant wechseln und den gemeinsamen Retrieval-Cache unverändert weiterverwenden. Der Fehler liegt vor dem Modellaufruf. Ein anderer Anbieter isoliert keine bereits falsch zugeordnete Cache-Antwort.

Szenario

Zwei Mandanten senden jeweils 60 Requests pro Minute. Mandant A nutzt kurze Klassifikationen, Mandant B erzeugt lange Kontexte und Antworten. Trotz identischem Requestlimit verbraucht B fast die gesamte Inferenzzeit.

Anforderungen

• Wie wird die Fairnessgrenze belastbarer?
• Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt.

Schritte

1. Plausibler Fehlweg: Die Requestzahl pro Mandant beibehalten und lediglich für beide Mandanten denselben höheren Grenzwert setzen. Gleiche Requestzahlen bedeuten bei stark unterschiedlicher Arbeit keine gleiche Ressourcennutzung. Ein höheres Limit verstärkt die Sättigung.
2. Tragfähiger Ansatz: Kontingente auf gemessene Arbeitsmaße und Nebenläufigkeit beziehen sowie getrennte Queues fair bedienen. Token- oder Laufzeitbudgets bilden die knappe Arbeit besser ab. Getrennte Fairnessgrenzen verhindern, dass ein Mandant alle Ausführungsslots bindet.
3. Plausibler Fehlweg: Alle langen Requests ungeachtet von Mandant, Priorität und verfügbarem Budget pauschal ablehnen. Das schützt Kapazität, verwirft aber auch zulässige und finanzierte Arbeit. Die Policy sollte Verbrauch und Serviceklasse berücksichtigen.
4. Plausibler Fehlweg: Mandant B auf ein größeres Modell routen, damit dessen lange Requests automatisch weniger Kapazität benötigen. Ein größeres Modell benötigt typischerweise nicht automatisch weniger Serving-Ressourcen. Routing ersetzt keine gemessene Verbrauchsgrenze.