Arize Phoenix im Test: LLM-Tracing und Evals auf eigener Infrastruktur

Arize Phoenix ist ein Open-Source-Server, der aufzeichnet, was eine LLM-Anwendung getan hat — jeden Prompt, jeden Retrieval-Schritt, jeden Tool-Aufruf und jedes Token — und das dann bewertet. Er startet mit einem Befehl auf dem Laptop oder landet im eigenen Kubernetes-Cluster, und die Lizenz stellt auf nichts einen Zähler. Die Position dieses Tests ist ungeschminkt: Phoenix ist der kürzeste Weg, Trace-Daten im eigenen Netz zu behalten, und was man dafür zahlt, ist der Job, einen Observability-Stack selbst zu betreiben.

Er sitzt zwischen Anwendung und Dashboard und konkurriert mit Langfuse, Braintrust und LangSmith um diese Stelle, und mit dem AX-Cloud von Arize für Teams, die lieber eine Rechnung schicken als eine Datenbank betreiben. Er ersetzt meist etwas Schlimmeres: einen Haufen Log-Dumps, ein Dashboard, das niemand öffnet, und eine Tabelle mit Evaluationsergebnissen.

Was es ist

Phoenix ist eine containerisierte Anwendung aus drei Teilen — Oberfläche, Trace-Collector und SQL-Backend — von Arize unter der Elastic License 2.0 veröffentlicht. Das Python-Paket ist arize-phoenix, stand Anfang Oktober 2026 in Version 20.19.0 und verlangt Python 3.11 oder neuer; das Repository hat knapp über 11.700 Sterne. Alles steckt in der freien Version: Tracing, Annotation, Datasets, Experimente, eine Prompt-IDE und LLM-as-a-Judge-Evaluation.

• Lizenz: Elastic License 2.0 (ELv2), frei zur Selbsthostung ohne Nutzungslimits und ohne Feature-Gates
• Aufnahme: OTLP mit den OpenInference-Konventionen plus Auto-Instrumentierungspakete für Provider und Frameworks
• Speicherung: standardmäßig SQLite, für Produktion PostgreSQL ab Version 14, beide hinter demselben SQL-Schema
• Deployment: Terminal, Docker, Kubernetes, Helm, CloudFormation und One-Click-Vorlagen für Railway, Render, Cloud Run und Azure
• Umfang: Traces und Sessions, Annotationen, Datasets, Experimente, Prompt-Versionierung, Code-Scorer und LLM-as-a-Judge
• Mandantenmodell: eine Instanz ist ein Mandant, mit OAuth2, LDAP, lokalen Konten und rollenbasierter Zugriffskontrolle im selben Build
• Cloud-Pendant: Arize AX, wo Support, Verfügbarkeitszusage und Multi-Tenancy liegen

Für ein Team, dessen Kunde oder Aufsicht Trace-Daten nicht aus dem Land lassen darf, ist diese Liste für sich die Shortlist. Für alle anderen ist es ein Tausch: das ganze Produkt kostet nichts, und die Aufgaben, die sonst ein Anbieter erledigt — Retention, Backups, Upgrades und die Antwort darauf, wer angerufen wird, wenn der Collector ausfällt — gehen auf das eigene Konto.

So funktioniert es

Der instrumentierte Prozess schreibt Spans an einen OpenTelemetry-Exporter, Phoenix nimmt sie über OTLP auf Port 6006 entgegen, legt sie in SQL ab und gruppiert sie zu Projekten, Sessions und Traces. Jeder Span trägt OpenInference-Attribute für Tokens, Kosten, Modell, Retrieval-Payloads und Tool-Argumente — deshalb kann ein Scorer später den Lauf lesen und nicht nur dessen Endstring.

Danach läuft die Schleife, die Arize veröffentlicht: beobachten, annotieren, Hypothese aufstellen, experimentieren, messen. Aus einem Produktions-Trace wird eine Datasets-Zeile, ein Kandidaten-Prompt läuft als Experiment gegen dieses Datasets, und Scorer — eingebaute, codebasierte oder judge-basierte — hängen Bewertungen an die Datensätze, die die Oberfläche ohnehin zeigt. Die Dokumentation beschreibt außerdem PXI, eine Agenten-Oberfläche zur Untersuchung von Problemen und zum Ausführen von Experimenten über erfasste Traces, sowie den agentengestützten Befehl px setup, der auf einen echten Trace wartet, bevor er Erfolg meldet.

Erste Schritte

Zwei Befehle. Der Server ist ein Python-Aufruf, uvx arize-phoenix serve, der auf http://localhost:6006 mit einem leeren Projekt antwortet. Auf der Client-Seite stehen arize-phoenix-otel und der OpenInference-Instrumentor für das SDK, das die Anwendung ohnehin benutzt:

# Terminal 1: uvx arize-phoenix serve  ->  UI auf http://localhost:6006
# pip install "arize-phoenix-otel>=0.16.0" openinference-instrumentation-openai
from phoenix.otel import register

register(
    project_name="support-agent",
    auto_instrument=True,
    endpoint="http://localhost:6006/v1/traces",
)

from openai import OpenAI

client = OpenAI()
reply = client.responses.create(
    model="gpt-5-mini",
    input="Summarise this ticket in one sentence.",
)
print(reply.output_text)

Zurück kommt ein Projekt mit echten Spans: Input, Output, Modell, Token-Zahlen, Latenz und die Verschachtelung der Tool-Aufrufe unter dem Agenten-Turn, der sie ausgelöst hat. Der register()-Aufruf liest PHOENIX_COLLECTOR_ENDPOINT, falls gesetzt, sodass derselbe Code Laptop, gemeinsame Staging-Server oder air-gapped Umgebung erreicht, ohne geändert zu werden.

Selbst hosten in der Praxis

Die Dokumentation verspricht eine air-gapped Installation: Die freie Version spricht nichts zu Arize, und Traces, Prompts und Datasets bleiben in der eigenen Infrastruktur. Der Aufwand dahinter ist ein Container und eine Datenbank, und das Arbeitsverzeichnis beziehungsweise PHOENIX_SQL_DATABASE_URL ist der einzige stateful Teil, der ein Backup-Schema verdient.

• Speicher: standardmäßig SQLite im Arbeitsverzeichnis; PHOENIX_SQL_DATABASE_URL schaltet auf PostgreSQL um, minimale unterstützte Version 14
• Images: arizephoenix/phoenix auf Docker Hub mit latest, gepinnter Version, nonroot und debug, dazu ein eigenes arizephoenix/phoenix-helm-Chart
• Authentifizierung: OAuth2, LDAP und lokale Konten, mit rollenbasierter Zugriffskontrolle und Retention-Regeln pro Projekt
• Skalierung: mehrere Instanzen hinter einem Load-Balancer auf einer Datenbank, oder eine Instanz pro Team mit eigener Datenbank
• Isolation: eine Schema-Einstellung teilt eine Datenbank zwischen Teams, ohne Zeilen zu teilen

Zwei Grenzen sollte man vor der ersten Produktionswoche kennen. Eine Instanz ist ein Mandant, Team-Isolation heißt also mehrere Deployments, und mandantenübergreifendes Gruppen-Modelling steht als Eintrag für 2026 im Issue-Tracker statt als ausgeliefertes Feature. SQLite ist außerdem die Entwicklungs-Datenbank: Die Architekturseite schickt Produktionsverkehr nach PostgreSQL, und damit landen Backups, Migrationen und Connection-Pooling in der eigenen Verantwortung.

Was es kostet

Phoenix selbst hat keinen Preis. Die Self-Hosting-Seite nennt keine Lizenzgebühren, keine Nutzungslimits und keine Feature-Gates, die Monatskosten sind also Maschine, Datenbank und wer sie betreibt. Die kommerzielle Fläche ist Arize AX, ein eigenes verwaltetes Produkt, dessen Gratisstufe zum Ausreichen reicht und dessen Pro-Stufe die erste echte Rechnung ist:

Beide ersten Tarife betreibt Arize, und die Preistabelle führt Self-Hosting nur bei AX Enterprise. Im Feld ist der freie Self-Hosted-Weg die Ausnahme: Langfuse deckt seine freie Cloud mit 50.000 Einheiten im Monat ab, Braintrust mit 1 GB und LangSmith mit 5.000 Traces, während ein unbegrenztes Phoenix eine Instanz kostet. Der Haken sitzt am anderen Ende — dedizierter Support und eine Verfügbarkeitszusage sind Enterprise-Zeilen, wer für 50 Dollar jemand anderen verantwortlich machen will, bekommt das dort nicht.

Wo es hakt

Phoenix verlangt, dass man sein eigener Observability-Anbieter wird, und das sieht man. Retention ist, was man konfiguriert, Aufnahmevolumen ist, was die Festplatte verkraftet, und nichts in der freien Version kommt mit Supportvertrag oder Verfügbarkeitszusage. Das SQL-Backend ist außerdem keine Analyse-Engine: Die Architekturseite schickt hochvolumige, sub-sekundige OLAP-Arbeit zu adb, der proprietären Datenbank von Arize, die es nur innerhalb von AX gibt. Dazu liefert das Projekt schnell, was für Features gut und für ein Upgrade-Fenster unbequem ist, und die gepflegten Hosting-Extras — verwaltete Agenten, Issue-Erkennung, Repository-Zugang — sind AX-Zeilen und keine von Phoenix.

Man wählt nach Einschränkungen, nicht nach Feature-Zahl. Wenn Datenresidenz die Bedingung sind, sind Phoenix oder selbst gehostetes Langfuse die Antwort, und Braintrust kommt erst nach einem Gespräch mit dem Vertrieb in Frage. Wenn die Rechnung wichtiger ist als die Datenebene, unterbietet Langfuse Core mit 29 Dollar AX Pro und bringt Prompt-Management mit. Wenn Evaluation in CI die eigentliche Aufgabe ist, sind eine Scorer-Bibliothek und eine fertige Eval-Aktion der kürzere Weg als das Zusammenbauen der Teile hier.

Sie dürfen die Software Dritten nicht als gehosteten oder verwalteten Dienst bereitstellen, wenn der Dienst den Nutzern Zugriff auf einen wesentlichen Teil der Funktionalität der Software bietet. — Elastic License 2.0, Einschränkungen

Fazit

Phoenix ist die richtige Standardwahl für ein Team, das Traces nicht exportieren darf und jemanden hat, der Postgres gern betreibt. Es ist die falsche Wahl für ein Team, das diese Woche eine Evaluations-Plattform ohne Infrastruktur-Gespräch will, denn Speicherung, Retention, Zugriffskontrolle und Upgrades sind echte Arbeit, auch wenn die Lizenz nichts kostet.

1. Wählen, wenn Trace-Daten im eigenen Netz bleiben müssen, auch in air-gapped Umgebungen: Die freie Version schickt nichts zu Arize.
2. Wählen, wenn das Kostenmodell wichtiger ist als die Feature-Liste: keine Span-Limits, kein Sitzplatzpreis, keine Aufnahmeabrechnung.
3. Wählen, wenn OpenTelemetry schon der Hausstandard ist, denn die Aufnahme ist OTLP und der Exporter lässt sich tauschen, ohne die Anwendung anzufassen.
4. Nicht wählen, wenn mandantenfähiges Hosting mit Verfügbarkeitszusage zum Einstiegspreis nötig ist: AX Pro ist nur gehostet, Verträge beginnen bei Enterprise.
5. Nicht wählen, wenn Evaluation in CI die Hauptaufgabe ist oder niemand im Team eine Datenbank besitzen will.

Quellen

1. Arize Phoenix: Open-Source-Observability und Evaluation
2. Phoenix-Dokumentation: Self-Hosting
3. Phoenix-Dokumentation: Lizenz unter der Elastic License 2.0
4. Phoenix-Dokumentation: Architektur, Speicherung und Skalierung
5. Phoenix-Dokumentation: Tracing einrichten
6. Phoenix-Dokumentation: OpenTelemetry-SDK einrichten
7. Arize-Preise: AX Free, AX Pro und AX Enterprise
8. Langfuse-Preise: Cloud-Tarife und abrechenbare Einheiten
9. LangChain-Preise: LangSmith-Tarife