ModelWarden Schnellstart

Schritt 1

Die passende Version herunterladen

Für den aktuell veröffentlichten Supportpfad meldest du dich im Kundenportal an, öffnest Dashboard → Downloads und wählst den für dein Konto verfügbaren Linux-Build. Prüfe zuerst die Prozessorarchitektur:

uname -m
# x86_64  → Linux x86-64
# aarch64 → Linux ARM64

Öffne in Bash den Ordner mit dem heruntergeladenen Programm. Setze BINARY auf den tatsächlichen Dateinamen, zum Beispiel ./mw-proxy oder ./mw-proxy-arm64. Bei einem Archiv prüfst du dessen Prüfsumme vor dem Entpacken und wählst danach das entpackte Programm. Umbenennen ändert keine Prozessorarchitektur.

BINARY=./mw-proxy
sha256sum "$BINARY"

Bei abweichender Prüfsumme nicht fortfahren. Erst wenn sie mit Downloads übereinstimmt, machst du die Datei ausführbar und prüfst die Version:

chmod +x "$BINARY"
"$BINARY" --version

Schritt 2

Proxy nur lokal starten

Starte das heruntergeladene Programm im selben Bash-Terminal:

"$BINARY"

Beim ersten Start wird eine fehlende Standardkonfiguration angelegt und 127.0.0.1:3758 verwendet. Eine vorhandene Konfiguration wird samt Listener-Einstellungen wiederverwendet. Beachte die Adresse in der Startausgabe; starte keinen zweiten Proxy auf einem belegten Port.

Lass dieses Terminal weiterlaufen. Prüfe den Standard-Listener in einem zweiten Terminal:

curl --fail http://127.0.0.1:3758/health

"$BINARY" --init --config /absolute/path/config.json

Schritt 3

Dashboard-Zugang schützen und Lizenz aktivieren

Öffne das lokale Dashboard des Proxys unter http://127.0.0.1:3758/admin/. Lass es auf Loopback beschränkt. Dein Passwort für das Kundenportal ist nicht das lokale Dashboard-Passwort.

Dashboard-Passwort

Deine Browser-Anmeldung am lokalen Dashboard.

Proxy-Client-API-Schlüssel

Die Zugangsdaten deines Coding-Clients für Modellanfragen.

Admin-API-Token

Nur für privilegierte Automatisierung. Nie als Client-Schlüssel verwenden.

1. Bei einer neuen Einrichtung öffnest du Config → Credentials → Protect credentials. Setze ein Dashboard-Passwort, verwahre das einmal angezeigte Admin-Token sicher und melde dich erneut an. Verwende ein anderes Passwort als den Client-Schlüssel.
2. Öffne License und füge das vollständige Token aus Kunden-Dashboard → Lizenzen ein.
3. Lass den Heartbeat-Endpunkt leer, wenn das signierte Token bereits die vertrauenswürdige Portal-URL enthält. Andernfalls verwende https://modelwarden.ai/api/v1/license/heartbeat. Lass die Maschinen-ID bei der ersten Aktivierung leer.

Du kommst schon nicht mehr ins Dashboard? Rate nicht wiederholt Zugangsdaten. Stoppe den Proxy und folge Dashboard-Zugang wiederherstellen.

Schritt 4

Modell und Judge verbinden

Öffne Providers → Add Endpoint. Trage Endpunkt, Format, Zugangsdaten und Upstream-Modell deines Providers ein. Speichere den Eintrag und verwende beim Modell Assign, um die Client-Route my-model anzulegen.

• Der Routenschlüssel ist der Modellname, den dein Client an ModelWarden sendet.
• Das Upstream-Modell ist der Modellname, den ModelWarden an den Provider weitergibt.
• Beginne mit einem Provider. Mit Professional und Enterprise kannst du unter Routing berechtigte Provider-Reihenfolgen, Zeitpläne, Aliase und Failover einrichten.

Kontextbezogene Prüfung einrichten

Öffne Judge → Provider chain, wähle ein für den Judge geeignetes Modell und klicke auf Add Provider. Free und Professional verwenden eigene Judge-Zugangsdaten. Enterprise Managed verwendet einen verwalteten Judge nur, wenn dein signierter Vertrag ihn enthält und er konfiguriert ist.

Kein Judge konfiguriert? Der aktuelle Quellcode fällt auf reine Heuristiken zurück, wenn kein Judge verfügbar ist. Eine funktionierende Modellroute belegt keine aktive kontextbezogene Prüfung. Judge-Aufrufe können Provider-Kosten verursachen.

Schritt 5

Client-Schlüssel erstellen und einen Client verbinden

Öffne nach der Trennung des Dashboard-Zugangs Config → Credentials → Generate new proxy key. Verwahre den angezeigten Schlüssel sicher und aktualisiere jeden Client, der einen älteren Schlüssel verwendet. Das Ergebnisfeld wird beim Verlassen geleert; über das authentifizierte Copy Config unter Providers oder Routing lässt sich der aktive Client-Schlüssel ebenfalls abrufen.

Verwende diesen Proxy-Schlüssel als MODELWARDEN_API_KEY, nie deinen Provider-Schlüssel oder das Admin-Token. Führe Folgendes im zweiten Bash-Terminal aus und starte den Client aus diesem Terminal.

Bash: Lies den Schlüssel ein, ohne ihn anzuzeigen. Füge ihn nicht in Befehlsverlauf, Logs oder Chats ein.

read -rsp 'ModelWarden-Client-Schlüssel: ' MODELWARDEN_API_KEY
export MODELWARDEN_API_KEY
printf '\n'

export ANTHROPIC_BASE_URL=http://127.0.0.1:3758
export ANTHROPIC_API_KEY="$MODELWARDEN_API_KEY"
claude --model my-model

Schritt 6

Jede Ebene prüfen, nicht nur den Prozess

curl --fail http://127.0.0.1:3758/health

curl --fail http://127.0.0.1:3758/v1/models

1. Prozess: /health antwortet erfolgreich.
2. Routenkatalog: /v1/models enthält deinen Routenschlüssel. Dieser Katalog-Endpunkt ist öffentlich und belegt nicht, dass der Client-Schlüssel stimmt.
3. Client-Anmeldung und Upstream: Sende mit dem vorgesehenen Client-Schlüssel über einen Fake-/Test- oder ausdrücklich freigegebenen Provider eine harmlose reine Textanfrage mit deaktivierten Tools. Ein echter Provider kann Kosten verursachen. Eine erfolgreiche Antwort belegt, dass der Schlüssel angenommen wurde und die Route ihren Upstream erreicht hat. Als negative Prüfung muss ein absichtlich ungültiger Platzhalter-Schlüssel mit 401 abgelehnt werden, ohne den Upstream zu erreichen; verwende dafür kein früheres echtes Geheimnis.
4. Schutzkonfiguration: Prüfe unter Config → Safety → General die Optionen Enabled, Audit only und Heuristics only. Normales Blockieren setzt aktivierten Schutz und ausgeschaltetes Audit only voraus; kontextbezogene Prüfung zusätzlich einen verfügbaren Judge und ausgeschaltetes Heuristics only. Prüfe On error: Standard ist allow, nicht Fail-closed.

Eine Textantwort ist kein Blockierungstest. Ohne Tool-Aufruf belegt eine normale Textanfrage keine Tool-Call-Durchsetzung und benötigt keinen Audit-Eintrag. Audit hängt außerdem von den Log-Einstellungen ab. In berechtigten Tarifen prüft Debug ein inertes Tool-Call-Beispiel ohne Ausführung; dabei kann der Judge aufgerufen werden, aber es entsteht kein Durchsetzungsereignis in Audit. Vollständige Schutzabnahme erfordert einen kontrollierten Tool-Call-Test mit passenden Client- und Audit-Nachweisen.

curl --fail http://127.0.0.1:3758/v1/chat/completions \
  -H "Authorization: Bearer $MODELWARDEN_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"model":"my-model","messages":[{"role":"user","content":"Antworte nur mit OK."}],"tools":[],"stream":false}'