Ein privates Modell-Deployment entsteht meist mit mehr Sorgfalt als das, was es überwacht. Der Inferenz-Stack wird dimensioniert, gehärtet und netzwerkseitig isoliert, und dann bewertet jemand die Qualität, indem er ein paar Prompts ausprobiert und die Ausgabe für gut erklärt. Sechs Wochen später wird ein Prompt geändert, ein Retrieval-Index neu gebaut oder der Serving-Stack aktualisiert, und niemand kann sagen, ob das System besser oder schlechter geworden ist, weil es nie eine Messung zum Vergleich gab.
Auf privater Infrastruktur wiegt das schwerer als in einem Cloud-Deployment, aus einem leicht zu übersehenden Grund. Teams mit kommerzieller API erben die Regressionstests des Anbieters auf dem Modell selbst; das Modell verhält sich konsistent, weil jemand anderes es stabil hält. Teams, die Open-Weight-Modelle auf eigener Hardware betreiben, besitzen jede Variable: die Gewichte, die Quantisierung, die Serving-Engine, den Umgang mit dem Kontextfenster, die Retrieval-Schicht und die Prompts. Jede davon kann sich unter Ihnen verändern, und mehrere werden es tun.
Die Restriktion ist, dass die naheliegenden Werkzeuge für dieses Problem cloud-first sind. Die meisten Evaluations- und Tracing-Plattformen sind um ein SaaS-Backend gebaut, das Ihre Prompts, Completions und abgerufenen Kontexte empfängt, also genau die Daten, die das private Deployment motiviert haben. Das zu lösen ist zuerst ein Problem der Werkzeugauswahl und erst danach ein Engineering-Problem.
Was die Anforderung “private Infrastruktur” tatsächlich hinzufügt
Fünf Eigenschaften trennen Werkzeuge, die innerhalb eines kontrollierten Perimeters funktionieren, von solchen, die lediglich Enterprise-Reife behaupten.
- Vollständig lokale Ausführung. Evaluationen, Trace-Speicherung, Dashboards und Scoring laufen ohne Kontakt zu einem externen Backend. Das muss den Scoring-Pfad einschließen, denn ein Evaluations-Framework, das ein gehostetes Judge-Modell aufruft, exportiert genau die Inhalte, die Sie schützen wollten.
- Prompt-Regressionstests. Ein fester Testsatz, der bei jeder Änderung an Prompts, Retrieval-Indizes oder Modellversionen läuft und einen vergleichbaren Score liefert statt eines Eindrucks.
- Trace-Erfassung mit brauchbaren Payloads. Prompts, Completions, abgerufener Kontext, Tool-Aufrufe, Token-Zahlen, Latenzen und Kosten, je Anfrage. Die Span-Struktur allein reicht nicht; die Payload muss reich genug sein, um zu rekonstruieren, was passiert ist.
- Überwachung von Qualitätsdrift. Ausgabequalität über die Zeit verfolgt, über automatisierte Evaluationspipelines und menschliches Feedback, gebunden an definierte Rollback-Schwellen.
- Echte private Betriebsmodi. Private VPC, On-Premises oder Air-Gapped-Betrieb ohne Internetabhängigkeit, auch für Lizenzprüfungen und Telemetrie.
Der letzte Punkt erwischt viele. Eine Plattform, die auf Ihrer Hardware läuft, aber für die Lizenzvalidierung nach Hause telefoniert, erfüllt eine Air-Gap-Anforderung nicht, und sie scheitert daran meist im denkbar ungünstigsten Moment.
Die Werkzeuglandschaft 2026
Die Vergleiche aus 2026 ordnen das Feld nützlicher nach Betriebsmodell als nach Funktionsliste.
Open-Source-Kern mit belastbarem Self-Hosting: Langfuse, Arize Phoenix und Comet Opik tauchen durchgängig unter den selbst hostbaren Plattformen auf. Sie sind der Standardeinstieg, wenn Sie den Code im eigenen Perimeter wollen und keine Anbieterbeziehung im kritischen Pfad.
Kommerziell mit ausdrücklichem privaten Deployment: Braintrust wird als self-hosted und On-Premises-fähig beschrieben, einschließlich Private VPC und Air-Gapped-Nutzung, was es zur direkteren Antwort macht, wenn ausdrücklich eine unterstützte Air-Gapped-Evaluationsplattform gefragt ist. Orq.ai bietet Cloud, VPC und On-Premises über eine Produktlinie hinweg, was Organisationen entgegenkommt, die einen Anbieter über Umgebungen unterschiedlicher Sensibilität wollen.
Cloud-first mit begrenzten On-Premises-Optionen: LangSmith und Maxim werden in Vergleichen aus 2026 beide als cloud-first charakterisiert, mit eingeschränktem oder auf die Enterprise-Stufe begrenztem Self-Hosting. Es sind leistungsfähige Produkte, und sie haben für eine vollständig offline arbeitende Anforderung die falsche Form.
Die Auswahlregel ist kurz. Wenn Sie einen Open-Source-Kern wollen und ihn selbst betreiben können, beginnen Sie mit Langfuse, Phoenix oder Opik. Wenn Sie ein unterstütztes Produkt mit ausdrücklicher Air-Gap-Fähigkeit brauchen, sehen Sie sich Braintrust an. Wenn Sie einen Anbieter über Cloud, VPC und On-Premises hinweg brauchen, sehen Sie sich Orq.ai an. Bauen Sie eine vollständig offline arbeitende Anforderung nicht auf einer cloud-first Plattform auf in der Erwartung, sich später dorthin verhandeln zu können.
Die Architektur, die trägt
Vier Ebenen, und die Disziplin liegt in ihrer Verbindung statt in einer einzelnen davon.
Der Eval-Harness pflegt einen kuratierten Testsatz echter Fragen mit geprüften Antworten und läuft bei jeder Änderung an Prompts, Modellversionen oder Retrieval-Indizes. Das tragende Wort ist kuratiert. Ein Satz, der aus echten Nutzerfragen und echten Fehlern zusammengestellt wurde, ist ein Vielfaches eines von einem Modell erzeugten Satzes wert, denn generierte Fragen prüfen die Verteilung, die der Generator sich vorstellt, und nicht die, die Ihre Nutzer erzeugen.
Die Tracing-Schicht instrumentiert jede Span der Pipeline: die eingehende Anfrage, das Retrieval, den Modellaufruf und jeden Tool-Aufruf. Richten Sie sich auf OpenTelemetry-förmige Instrumentierung aus, denn die Observability-Werkzeuge von 2026 sind um Trace-Daten dieser Form gebaut, und das hält Sie zwischen Backends portabel. Die operative Anforderung geht allerdings über Standard-Spans hinaus. Die Payloads brauchen Prompts, Completions, Retrieval-Kontext, Token-Zahlen, Latenzen und Kosten, sonst haben Sie Zeitmessdaten für ein System, dessen Fehler fast nie mit Zeit zu tun haben.
Die Metrikebene verfolgt Latenz, Tokenverbrauch, Queue-Tiefe, Durchsatz und Kosten neben den Qualitätsmaßen. Auf privater Infrastruktur zahlt sich diese Ebene schnell aus, denn Queue-Tiefe und Durchsatz sind die Stellen, an denen sich Kapazitätsprobleme melden, bevor Nutzer sie bemerken.
Qualitätsgates und ein Model Registry. Verlangen Sie das Bestehen von Evaluationsschwellen, bevor eine Version freigegeben wird, und rollen Sie zurück, wenn die Qualität unter die Basis fällt. Versionieren Sie Modellartefakte mit ihren Metadaten: Hash der Trainingsdaten, wo einschlägig, Hyperparameter, Quantisierungseinstellungen und Evaluationsscores. Auf einem privaten Stack werden Sie irgendwann beantworten müssen, welches Artefakt genau eine bestimmte Ausgabe erzeugt hat, und ein Registry ist der Unterschied zwischen einer Antwort in fünf Minuten und einer forensischen Übung.
Die wichtigste Verbindung besteht zwischen Tracing-Schicht und Eval-Harness. Produktions-Traces und Offline-Evaluationen sollten dieselbe Telemetrieform teilen, damit sich ein Produktionsfehler direkt in den Regressionssatz heben lässt, ohne von Hand umgeschrieben zu werden. Teams, die das überspringen, enden mit zwei unverbundenen Sichten auf Qualität und verbringen ihre Zeit damit, sie abzugleichen.
Wie das in der Praxis läuft
Vor dem Rollout lassen Sie die Offline-Benchmark-Suite gegen einen festen Prompt-Satz laufen und vergleichen Kandidatenmodelle oder Prompt-Versionen auf identischen Eingaben. Das ist der einzige Vergleich, der etwas bedeutet, wenn Sie zwischen Open-Weight-Modellen wählen, denn veröffentlichte Benchmark-Werte sagen etwas über allgemeine Leistungsfähigkeit aus und nichts über Ihre Dokumente und Ihre Fragen.
Während des Rollouts leiten Sie einen kleinen Anteil des Verkehrs auf die neue Version und vergleichen Qualität, Latenz und Kosten. Auf privater Infrastruktur verhält sich die Kostendimension anders als bei einem API-Deployment: Eine Version, die mehr Token pro Anfrage verbraucht, verbraucht mehr einer festen Kapazität, weshalb Durchsatzregressionen als Kapazitätsprobleme auftreten und nicht als höhere Rechnung.
In der Produktion vergleichen Sie fortlaufend Live-Ausgabeverteilungen und Evaluator-Scores gegen die Basis. Drift auf einem selbst gehosteten Stack kommt selten vom Modell, das eingefroren ist, solange Sie es nicht ändern. Sie kommt daher, dass sich Eingaben und Retrieval-Korpus verschieben, und das ist ein langsamerer und weniger offensichtlicher Fehlermodus als ein Modell-Update; Teams, die nur auf Deployment-Ereignisse achten, übersehen ihn.
Für sensible Workloads halten Sie Prompts, Completions, Traces, Datensätze und Evaluationsergebnisse im selben Perimeter wie das Modell. Evaluationsdaten sind oft konzentrierter als Produktionsverkehr, denn ein Testsatz ist eine kuratierte Sammlung Ihrer schwierigsten und repräsentativsten Fälle. Er verdient dieselbe Behandlung wie die Quelldokumente.
Womit Sie anfangen
Bauen Sie den Regressionssatz, bevor Sie irgendetwas anderes bauen. Fünfzig echte Fragen mit geprüften Antworten, gesammelt bei den Menschen, die das System nutzen werden, sind eine Woche Arbeit, und sie machen jede spätere Entscheidung messbar. Ohne ihn werden Modellauswahl, Prompt-Änderungen und Retrieval-Tuning sämtlich nach Meinung entschieden.
Instrumentieren Sie dann ab dem ersten Tag des Pilotbetriebs auf vollständige Payload-Erfassung, nicht erst nach dem Launch. Traces, die Sie nicht gesammelt haben, lassen sich nicht wiederherstellen, und die Pilotphase ist die Zeit, in der die interessanten Fehler passieren und in der Sie noch die Aufmerksamkeit haben, sie anzusehen.
Wählen Sie die Plattform gegen Ihre härteste Betriebsrestriktion aus, nicht gegen Ihre typische. Wenn eine Umgebung im Geltungsbereich air-gapped ist, wählen Sie für diese Umgebung, denn zwei Evaluationsplattformen für zwei Umgebungen zu betreiben ist ein Aufwand, den Sie danach jede Woche zahlen.
Häufige Fragen
Dürfen wir eine Cloud-Eval-Plattform nutzen, wenn nur die Scores unser Netz verlassen und nicht die Prompts?
Manchmal, aber prüfen Sie, was das SDK tatsächlich überträgt, und nicht, was die Produktseite behauptet. Die meisten Tracing-Clients senden standardmäßig die vollständige Span-Payload einschließlich Prompt- und Completion-Text, und die Redaction-Hooks sind opt-in und mit einem neuen Instrumentierungsaufruf leicht zu umgehen. Wenn Ihre Anforderung lautet, dass kein Prompt-Inhalt den Perimeter verlässt, erzwingt ein selbst gehostetes Deployment das strukturell, während eine Cloud-Plattform mit aktivierter Redaction darauf baut, dass jede künftige Integration daran denkt, sie zu konfigurieren.
Wie groß muss der Regressionstestsatz sein?
Kleiner, als Teams erwarten, und kuratiert statt zufällig gezogen. Fünfzig bis zweihundert echte Fragen mit geprüften Referenzantworten, ausgewählt entlang der Fehlermodi, die Sie wirklich interessieren, fangen mehr Regressionen ab als tausend zufällig gezogene Anfragen. Ergänzen Sie einen Fall, sobald die Produktion eine falsche Antwort erzeugt; so werden Störungen zu dauerhafter Abdeckung. Der Satz hat nur Wert, wenn er bei jeder Änderung an Prompts, Modellversionen und Retrieval-Indizes läuft, halten Sie ihn also schnell genug, dass niemand versucht ist, ihn zu überspringen.
Was überwachen wir, sobald das System live ist?
Zwei Ebenen. Operative Metriken zuerst: Latenz, Tokenverbrauch, Queue-Tiefe, Durchsatz und Kosten pro Anfrage, denn die meisten für Nutzer sichtbaren Fehler sind operativ und nicht qualitativ. Danach Qualitätssignale: automatisierte Evaluator-Scores auf gesampeltem Produktionsverkehr im Vergleich zu Ihrer Basisverteilung, Trefferquoten im Retrieval, Verweigerungs- und Fallback-Raten sowie menschliches Feedback, wo Sie es erheben können. Koppeln Sie die Qualitätssignale mit einer vor dem Rollout vereinbarten Rollback-Schwelle, sonst wird über Drift diskutiert statt gehandelt.