Pezzo: Prompt-Verwaltung und LLM-Tracing als selbst gehosteter Stack

Welche Lücke Pezzo im Entwicklungsalltag schließt

Prompts landen in vielen Projekten dort, wo sie am schnellsten zu ändern sind: als Zeichenkette im Anwendungscode. Sobald mehrere Personen an einem Produkt arbeiten, entsteht daraus ein Problem. Wer den Wortlaut geändert hat, wann die Änderung in Produktion ging und welche Antworten vorher und nachher ausgeliefert wurden, lässt sich nur noch über die Versionshistorie des Repositories rekonstruieren. Pezzo setzt genau an dieser Stelle an. Die Plattform verwaltet Prompts mit Versionen, liefert sie zur Laufzeit an die Anwendung aus und zeichnet die Aufrufe auf.

Die Zielgruppe ist im README nicht als Rollenbeschreibung formuliert, ergibt sich aber aus den Bausteinen. Angesprochen sind Teams, die Anwendungen mit Sprachmodellen betreiben und dabei zwei Dinge getrennt halten wollen: den Prompt als eigenständiges Artefakt und die Anwendung, die ihn verwendet. Für Einzelpersonen mit einem einzigen Prompt ist der Aufwand, vier Infrastrukturdienste zu betreiben, schwer zu rechtfertigen.

Vier Infrastrukturdienste und ihre Aufgaben im Datenfluss

Pezzo bezeichnet sich im README als vollständig cloud-native und stützt sich nach eigener Angabe ausschließlich auf PostgreSQL, ClickHouse, Redis und Supertokens. Diese Aufteilung ist der eigentliche Architekturkern. PostgreSQL trägt über Prisma das Schema der Anwendung, also die verwalteten Prompts und ihre Versionen. ClickHouse ist eine spaltenorientierte Datenbank und wird für die Auswertung der aufgezeichneten Aufrufe eingesetzt, wo große Mengen an Ereignissen anfallen. Redis dient als Zwischenspeicher, was zur beworbenen Caching-Funktion passt. Supertokens übernimmt Authentifizierung und Sitzungsverwaltung.

Für den Datenfluss ergibt sich daraus eine zweigeteilte Struktur. Der verwaltende Teil läuft über die Anwendung und PostgreSQL, der beobachtende Teil über ClickHouse. Die Schnittstelle nach außen ist GraphQL. Darauf deutet die Empfehlung im README hin, die GraphQL Language Feature Support Erweiterung für VSCode zu installieren, sowie der Codegen-Schritt, der Typen aus dem Schema erzeugt. Wer den Stack betreiben will, muss also nicht nur eine Anwendung, sondern auch eine Analytikdatenbank mit ihren eigenen Betriebsregeln mitziehen. Das ist der Preis für die Trennung von Verwaltungs- und Auswertungsdaten.

Clients: Node.js und Python, LangChain über ein Issue verlinkt

Die Client-Tabelle im README nennt drei Spalten: Node.js, Python und LangChain. Für Node.js und Python sind jeweils Prompt Management, Observability und Caching als unterstützt markiert. Bei LangChain verweist die Spaltenüberschrift nicht auf eine Dokumentationsseite, sondern auf die Issue-Nummer 180 im Projekt. Das ist ein aufschlussreicher Unterschied. Für die beiden Sprach-Clients existieren veröffentlichte Pakete, das Node-Paket ist als @pezzo/client auf npm geführt. Die LangChain-Anbindung ist dagegen über einen Arbeitsthread verlinkt, was auf einen Integrationsstand hindeutet, der nicht dieselbe Reife wie die eigenen Clients hat.

Für die Auswahl bedeutet das: Wer eine Anwendung in TypeScript oder Python schreibt, findet direkte Anbindung. Wer stark auf LangChain aufbaut, sollte den verlinkten Thread lesen, bevor er Pezzo als festen Bestandteil einplant. Das README bietet außerdem an, ein Issue zu eröffnen, wenn ein benötigter Client fehlt. Eine Zusage, dass dieser Client dann entsteht, ist damit nicht verbunden.

Vom Repository zum laufenden Stack

Das README beschreibt zwei Wege. Für den vollständigen lokalen Betrieb verweist es auf den Abschnitt Running With Docker Compose in der Dokumentation. Der Entwicklungsweg ist im Repository ausgeschrieben und setzt Node.js 18 oder neuer sowie Docker voraus. Zuerst werden die Abhängigkeiten installiert:

npm install

Danach sind die Umgebungsdateien anzulegen. Pezzo verwendet laut README eine .env-Datei, bei Docker-Betrieb zusätzlich eine .env.docker, mit .env.example als Vorlage. Erst dann starten die Infrastrukturdienste:

docker-compose -f docker-compose.infra.yaml up

Darauf folgen die Prisma-Migrationen, ausgeführt über dotenv-cli mit dem Schema unter apps/server/prisma/schema.prisma, und der Server selbst über npx nx serve server. Dass das Repository auf Nx aufgebaut ist, zeigt sich an den serve-Zielen für server und console. Die Gesundheitsprüfung läuft unter http://localhost:3000/api/healthz, die Konsole nach dem Start von npx nx serve console unter http://localhost:4200.

Ein Detail, das in der Anleitung leicht überlesen wird: Für die Schemaentwicklung ist in einem zweiten Terminal npm run graphql:codegen:watch zu starten. Ohne diesen Schritt bleiben die generierten Typen stehen, während sich das Schema ändert. Wer nur mit dem Server arbeitet und den Watcher weglässt, bekommt Abweichungen zwischen Schema und Typen, die sich erst später als Fehler zeigen.

Wo Pezzo die falsche Wahl ist

Der offensichtlichste Fall gegen Pezzo ist der Betriebsaufwand. Wer Prompts nur versionieren und ausliefern will, muss trotzdem PostgreSQL, ClickHouse, Redis und Supertokens bereitstellen. ClickHouse ist für Auswertungen über viele Ereignisse gebaut, nicht als leichte Beigabe. Ein Team, das keine Tracing-Daten auswertet, betreibt damit eine Datenbank ohne Verwendungszweck.

Ein zweiter Fall betrifft die Beobachtung selbst. Observability heißt hier, dass Aufrufe an die Plattform gemeldet werden. Das setzt voraus, dass die Anwendung den Pezzo-Client verwendet und die Aufrufe dorthin weiterleitet. Für bestehende Systeme, die bereits über ein anderes Tracing-System instrumentiert sind, entsteht dadurch eine zweite Erfassungsschicht mit eigenem Datenbestand. Wer ausschließlich OpenTelemetry-Spans an eine bestehende Sammelstelle senden will, wird Pezzo nicht als Ersatz verwenden, sondern als zusätzliche Komponente.

Drittens ist der Reifegrad an den Versionsnummern ablesbar. Die jüngste aufgeführte Veröffentlichung ist v0.9.2 vom 15. Mai 2024. Eine Null-Komma-Neun-Serie bedeutet üblicherweise, dass Schnittstellen noch wechseln können. Wer Pezzo in eine Produktionskette einbaut, sollte Änderungen an GraphQL-Schema und Client-Paketen einplanen.

Abgrenzung zu einem reinen Prompt-Speicher

Die nächstliegende Alternative ist kein anderes LLMOps-Produkt, sondern der Verzicht auf eine Plattform: Prompts als Dateien im Anwendungsrepository, versioniert mit Git, ausgeliefert beim Deployment. Diese Lösung hat einen Vorteil, der schwer zu schlagen ist. Sie benötigt keine zusätzliche Infrastruktur, und der Versionsverlauf ist derselbe wie der des Codes, der die Prompts verwendet.

Der Unterschied liegt im Zeitpunkt der Auslieferung. Bei Prompts im Repository ist eine Änderung am Prompt eine Änderung am Deployment. Pezzo trennt beides: Der Prompt wird in der Plattform geändert und die Anwendung holt die aktuelle Fassung zur Laufzeit ab. Das ist der Kern des Versprechens, Änderungen ohne neues Deployment auszuliefern. Der Preis dafür ist eine Laufzeitabhängigkeit. Fällt Pezzo aus oder ist das Netzwerk zwischen Anwendung und Plattform gestört, muss die Anwendung entscheiden, ob sie einen zwischengespeicherten Prompt verwendet oder fehlschlägt. Genau hier wird Redis im Stack relevant.

Wer also mehrmals täglich Prompts anpassen und die Wirkung beobachten will, gewinnt durch die Trennung. Wer Prompts selten ändert, tauscht einen einfachen, aber langsamen Prozess gegen einen komplexeren, aber schnelleren.

Lizenz, Wartung und der Blick auf den Zeitstempel

Der Quellcode steht unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, verlangt aber, dass Lizenzhinweise und Änderungshinweise erhalten bleiben und der Haftungsausschluss weitergegeben wird. Wer den Stack als gehosteten Dienst für Dritte anbietet, sollte die Namens- und Markenrechte gesondert prüfen. Das README selbst enthält dazu keine Angaben. Dieser Absatz ist eine Einordnung der Lizenzbedingungen, keine Rechtsberatung.

Für die Wartung ist der Zeitstempel der letzten Veröffentlichung die wichtigste Zahl. v0.9.2 datiert auf den 15. Mai 2024, die beiden vorherigen Versionen auf April und Mitte Mai 2024. Das sind drei Veröffentlichungen innerhalb weniger Wochen, gefolgt von einer Lücke. Wer heute einsteigt, übernimmt damit einen Stand, der nicht mehr im selben Tempo fortgeschrieben wurde. Das ist kein Ausschlusskriterium, aber ein Faktor bei der Frage, ob man auf Fehlerkorrekturen warten kann oder sie selbst beitragen muss. Das Repository nennt CONTRIBUTING.md und einen Discord-Kanal als Wege für Beiträge.

Ein Upgrade auf eine spätere Version ist mit Migrationsschritten verbunden. Die Prisma-Migrationen werden explizit über den Befehl mit dem Schema apps/server/prisma/schema.prisma eingespielt, ein Schemawechsel ist also ein bewusster Vorgang und kein Nebeneffekt des Neustarts.

Wer einsteigen sollte und was zuerst zu klären ist

Pezzo passt zu Teams, die eine eigene Instanz betreiben wollen und die vier genannten Dienste ohnehin oder bereitwillig betreiben. Es passt zu Anwendungen in Node.js oder Python, bei denen Prompts häufig geändert werden und die Wirkung dieser Änderungen nachvollziehbar bleiben soll. Es passt weniger zu Projekten mit einem einzigen stabilen Prompt, zu Umgebungen, in denen keine zusätzliche Datenbank zugelassen ist, und zu Teams, die bereits ein vollständiges Tracing über einen anderen Standard betreiben und keine zweite Erfassungsschicht wollen.

Vor dem ersten Deployment sind drei Dinge konkret zu prüfen. Erstens der Stand des verlinkten LangChain-Threads, falls die Anwendung darauf aufbaut. Zweitens der Inhalt von .env.example, weil daraus hervorgeht, welche Zugangsdaten und Endpunkte für die vier Dienste tatsächlich benötigt werden. Drittens das Verhalten der Anwendung, wenn die Plattform nicht erreichbar ist. Die Dokumentation beschreibt den Aufbau, aber die Entscheidung über einen zwischengespeicherten Prompt oder einen Fehler liegt beim aufrufenden Code. Diese Entscheidung sollte vor dem Produktivgang getroffen sein.

Redaktionelles Fazit

Wer Prompts versionieren, zur Laufzeit ausliefern und LLM-Aufrufe nachvollziehbar protokollieren will, ohne Daten an einen SaaS-Anbieter zu geben, findet in Pezzo einen selbst hostbaren Kandidaten mit klarer Infrastrukturabhängigkeit. Wer nur einen Prompt-Speicher braucht oder keine vier Dienste betreiben will, ist mit einer schlankeren Lösung besser bedient. Vor dem Einsatz ist zu prüfen, ob der Stand von v0.9.2 vom Mai 2024 zum eigenen Betriebsmodell passt und ob die eigene Umgebung die vier Infrastrukturdienste PostgreSQL, ClickHouse, Redis und Supertokens bereitstellen kann.

Offizielle Quellen

1. License: Apache-2.0
2. pezzolabs/pezzo on GitHub
3. Project website
4. README
5. Releases