StudioForge 2.0: Konten, scopingfähige API-Schlüssel sowie ein sicherer Upgrade-Prozess

StudioForge ist der GPU-exklusive Modellserver, den ich entwickelt habe, um LM Studio auf meinem System zu ersetzen (die vollständige Geschichte finden Sie in dem ursprünglichen Beitrag). In Version 2.0 wurde festgelegt, wer mit dem Server kommunizieren darf. In Version 0.2.0 reagierte der Server auf Anfragen über alle Netzwerkschnittstellen – er vertraute dabei jedem, der ihn erreichen konnte; lediglich für die Agenten-Tools gab es optional einen PIN-Code. Ab Version 2.0 hört der Server nur noch auf Anfragen von dem Rechner, auf dem er läuft – es sei denn, man konfiguriert etwas anderes. Sobald der Server freigeschaltet ist, benötigt jeder Anrufer einen Schlüssel.

Quellcode auf GitHub

Am 19.10.2026 habe ich mein eigenes System aktualisiert. Alle Programme, die den Server ohne Schlüssel anriefen, erhielten innerhalb weniger Minuten den Fehlercode 401: mein Mail-Tool, meine Chat-App, die Speichersuche des Agenten-Gateways sowie einige Skripte. Keines dieser Programme war defekt – sie hatten lediglich noch keinen Schlüssel. Diese Seite wünschte ich mir zuvor gelesen zu haben.

Was ändert sich für Sie?

In einfachen Worten: Drei Dinge.

• Standardmäßig ist alles privat. Der Gateway-Port (1234), das Kontrollpanel (8080) sowie der Recovery-Watchdog (1235) binden an 127.0.0.1. Andere Geräte können sie überhaupt nicht erreichen.
• Zum Öffnen ist ein Login erforderlich. Falls einer der drei Dienste auf einer Netzwerkadresse lauscht und es weder ein Besitzerkonto noch einen Admin-Key gibt, beendet studioforge serve den Betrieb mit dem Exit-Code 4 und weist Sie darauf hin, wie Sie das Problem beheben können. Sie können nun nicht mehr versehentlich einen öffentlich zugänglichen Server starten.
• Jedes Programm erhält seinen eigenen Schlüssel. Ein Schlüssel ist ein String wie sf-i-…, den ein Programm als Authorization: Bearer <key> sendet. Jeder Schlüssel besitzt einen Namen, einen Gültigkeitsbereich, optional ein Ablaufdatum sowie eine begrenzte Anzahl erlaubter Anfragen pro Minute. Sie können einen Schlüssel widerrufen, ohne die anderen zu beeinflussen.

Hier sehen Sie das Ergebnis meines Tests: Alle drei Hosts waren auf 0.0.0.0 eingestellt und es gab kein Konto:

error: Refusing to start: the gateway, the control panel, the watchdog would listen on a
non-loopback address (0.0.0.0, 0.0.0.0, 0.0.0.0) but no owner account or admin API key exists,
so anyone on the network could drive this server. Fix: run `studioforge setup` (creates the
owner account) or `studioforge keys create --name admin --scope admin`, then start again.

Ein Detail hat mich überrascht: Das Erstellen des ersten Schlüssels aktiviert die Authentifizierung für alle – einschließlich Programme auf demselben Rechner. Auf einem Testserver, der nur über Loopback erreichbar war, erstellte ich einen Schlüssel; anschließend führte ein einfacher curl-Aufruf zu /v1/models vom selben Rechner aus dazu, dass der Statuscode von 200 auf 401 wechselte. Die StudioForge-CLI, das Systemmenü sowie das Kontrollpanel funktionieren weiterhin, da sie jeweils ihren eigenen lokalen Admin-Key (local-cli) erzeugen – dieser ist ausschließlich für den Besitzer im Datenverzeichnis gespeichert. Ab diesem Zeitpunkt benötigt alles andere einen Schlüssel.

Das zehnminütige, sichere Upgrade

Dies ist die Reihenfolge, die zu einer kurzen Ausfallzeit führt. Sie folgt den Migrationsschritten aus dem CHANGELOG – mit zwei Korrekturen, die ich bei meinem eigenen Test vorgenommen habe.

1. Listen Sie alle Clients auf. Jede Chat-App, jeder Agent, jedes Skript sowie alle anderen Systeme, die den Server aufrufen. Falls Sie unsicher sind, suchen Sie in deren Konfigurationen nach der Server-Adresse. Diese Liste ist im Grunde die gesamte Aufgabe.
2. Erstellen Sie ein Backup und führen Sie einen Testlauf durch. Kopieren Sie das Datenverzeichnis, aktualisieren Sie den Code (git pull) und installieren Sie ihn anschließend in Ihrem venv gemäß den Angaben in der README für Ihre Plattform. Führen Sie danach studioforge migrate --dry-run aus. Version 2.0.1 migriert die Datenbank auf Schema 10; studioforge migrate erstellt vor der Anwendung ein Backup.
3. Erstellen Sie die notwendigen Zugangsdaten, damit der Server starten kann. Entweder verwenden Sie studioforge setup (der interaktive Ersteinrichtungsprozess; er erstellt das Administratorkonto sowie, falls Sie „mein lokales Netzwerk“ wählen, aktiviert HTTPS und generiert einen Admin-Key) oder geben Sie einfach studioforge keys create --name admin --scope admin ein.
4. Erstellen Sie für jeden Client einen Schlüssel – alle auf einmal, bevor Sie den neuen Server starten:

   studioforge keys create --name chat-app  --scope inference --rate-limit-rpm 120
   studioforge keys create --name dashboard --scope read
   studioforge keys create --name laptop    --scope admin --expires-in-days 30

   Jeder Schlüssel wird nur einmal ausgegeben und anschließend nicht gespeichert; kopieren Sie ihn daher umgehend in die Konfiguration des jeweiligen Clients.
5. Starten Sie den Server und testen Sie jeden Client mit einer echten Anfrage. Ein 401 invalid_api_key bedeutet, dass der Client noch keinen Schlüssel hat; ein 403 permission_denied zeigt an, dass der Berechtigungsumfang des Schlüssels für die gewünschte Aktion zu gering ist.
6. Deaktivieren Sie erst anschließend die alten Zugangsdaten. Sobald jeder Client mit seinem eigenen Schlüssel funktioniert: Geben Sie studioforge keys revoke legacy ein, löschen Sie server.api_key und deaktivieren Sie den MCP-PIN. Lesen Sie dazu unten unter „Der PIN-Fehler“; allein das Löschen des PINs reicht nicht aus.
7. Führen Sie studioforge doctor aus und lesen Sie die verbleibenden Hinweise.

Falls Sie bereits server.api_key verwendet haben, führt das Upgrade an sich zu keinen Problemen: Der alte Schlüssel wird als Admin-Schlüssel mit dem Namen legacy in die Schlüsseltabelle übernommen und funktioniert weiterhin. Auf meinem System gab es keinen gemeinsamen Schlüssel – nur den PIN –, weshalb alle Clients gleichzeitig ausfielen. Hätte ich Schritt 4 vor Schritt 5 ausgeführt, wäre mir das meiste davon erspart geblieben.

Das Panel: Anmelden, Einrichten, Schlüssel erstellen

Diese Screenshots stammen von einer temporären 2.0.1-Instanz, die ich in Podman auf einem Rechner ohne NVIDIA-GPU ausgeführt habe (weitere Infos dazu unten). Die beiden Grafikkarten sind simuliert; die Schlüssel sind daher wertlos.

Das Panel verfügt nun über eine Anmeldeseite. Verwenden Sie den Benutzernamen und das Passwort des Inhabers – oder lassen Sie den Benutzernamen leer und fügen Sie einen Admin-Schlüssel ein. Ein read- oder inference-Schlüssel reicht jedoch nicht aus, um sich anzumelden.

Die Einrichtungsanleitung unter /setup führt durch acht Schritte: Inhaberkonto, Hardware, Engine, Modellbibliotheken, ein Startmodell, ein Test-Chat, Client-Beispiele sowie die Festlegung, wer auf den Server zugreifen darf. Jeder Schritt kann übersprungen werden. Im letzten Schritt wählen Sie zwischen „Nur dieser Computer“ und „Mein lokales Netzwerk über HTTPS“.

Schlüssel werden unter Benutzer & Schlüssel verwaltet. Geben Sie einen Namen an, der beschreibt, welches Programm den Schlüssel nutzt; wählen Sie außerdem einen Gültigkeitsbereich sowie optional ein Ablaufdatum und eine Anfragerate.

Der Schlüssel wird nur einmal angezeigt. In diesem Screenshot habe ich ihn verdeckt – auf einem echten Server sehen Sie ihn jedoch genau in diesem Dialogfenster.

In der Tabelle sind für jeden Schlüssel der Gültigkeitsbereich, die ersten Zeichen des Schlüssels, das letzte Nutzungsdatum, das Ablaufdatum, die Anfragerate sowie der Status aufgeführt. Darunter befindet sich das Audit-Log: alle erstellten bzw. widerrufenen Schlüssel, jede Anmeldung sowie jede Änderung durch Administratoren – inklusive des ausführenden Benutzers und dessen Herkunftsort. Geheime Daten gelangen niemals in dieses Log.

Berechtigungen: read, inference, admin

Berechtigung	Kann	Für wen
read	Einsicht in Statusinformationen, Modelllisten, /metrics sowie lese-only MCP-Tools. Es ist nicht möglich, etwas per POST zu senden.	Dashboards, Monitoring-Tools
inference	Einsicht sowie Nutzung der Chat-Funktionen (/v1/chat/completions, /v1/messages, /v1/responses). Außerdem: Modelle laden, entladen und testen sowie den eigenen GPU-Zugriff verwalten.	Chat-Apps, Agenten, Skripte sowie andere Programme, die GPU-Ressourcen nutzen
admin	Einstellungen ändern, System neu starten, Engine installieren/aktualisieren, Dateien herunterladen/löschen, Schlüssel verwalten, Konten steuern sowie den Audit-Log einsehen. Enthält auch „destruktive“ MCP-Tools.	Nur Sie selbst

Entscheidend ist der Code – nicht irgendwelche Konventionen (api/auth.py:required_scope). Die Berechtigungen werden anhand des Pfadpräfixes bestimmt; alle Routen, die Zustandsänderungen bewirken und bisher nicht klassifiziert wurden, erfordern zwingend admin. Somit sind neue Routen standardmäßig abgedeckt. Eine Berechtigung wird immer überprüft – selbst auf Servern, bei denen eigentlich keine nötig wäre: Ein Schlüssel mit read-Berechtigung darf beispielsweise nichts per POST senden. Auf einer Testinstanz habe ich dies überprüft: Ein Schlüssel mit inference-Rechten lieferte 200 bei /v1/models und 403 bei /api/keys.

Auch Agenten erhalten einen Schlüssel – niemals jedoch das eigentliche Passwort. Auf der Seite „Integrationen“ im Panel finden Sie vorformatierte Beispiele für OpenClaw, die Python SDKs von OpenAI und Anthropic, DisPatch, curl sowie Claudes --mcp-config-Datei. Zuerst wählen Sie in dem Dropdown-Menü einen Schlüssel aus: Wenn der Platzhalter ausgewählt ist, enthält das curl-Beispiel keinen Authorization-Header – bei direktem Einfügen erhalten Sie somit einen Fehlercode 401.

Das Besitzerkonto, der alte gemeinsame Schlüssel und der PIN

In Version 2.0 gibt es drei Arten von Anmeldeinformationen – zwei davon werden jedoch in Kürze nicht mehr verwendet.

• Das Besitzerkonto: Damit kann man sich im Panel anmelden. Das Passwort muss mindestens 10 Zeichen lang sein und wird mit Argon2id gehasht. Das Hash wird – falls das optionale keyring-Extra installiert ist – in den OS-Schlüsselspeicher geschrieben; andernfalls in eine Datei, die nur für den Besitzer zugänglich ist. Es befindet sich nicht in der Datenbank – daher enthält eine kopierte Datenbank keine Anmeldeinformationen.
• server.api_key (veraltet): Funktioniert weiterhin überall als Administrator-Anmeldeinformation. Er erscheint unter dem Namen legacy; das Kommando keys revoke legacy deaktiviert ihn tatsächlich.
• mcp.pin (veraltet): Es handelt sich dabei um eine achtstellige Administrator-Anmeldeinformation, die nur für die MCP-Endpunkte gilt. Auf einem Server ohne andere Schlüssel ermöglicht er weiterhin den Zugriff auf bestimmte HTTP-Routen – dadurch funktionieren alte Verbindungen weiterhin. Sobald jedoch ein anderer Schlüssel vorhanden ist, hört das auf zu funktionieren.

Ein kleiner „Trick“ beim PIN-Handling: Im CHANGELOG wird empfohlen, server.api_key sowie mcp.pin zu löschen. Wenn man jedoch nur mcp.pin: null setzt, generiert das System beim nächsten Start automatisch einen neuen zufälligen PIN und speichert ihn – schließlich ist mcp.pin_required weiterhin auf true gesetzt. Um den PIN wirklich außer Betrieb zu nehmen, muss man beide Werte setzen.

mcp:
  pin: null
  pin_required: false

Gleiche Logik gilt auch für eine frisch installierte Version 2.0.1: Beim ersten Start wird ein neuer PIN generiert; anschließend meldet studioforge doctor, dass dieser veraltet ist. Das ist harmlos – man sollte sich aber nicht darüber wundern.

Bindung, HTTPS und Browser

• Bindungsregel. server.host, gui.host sowie watchdog.host haben standardmäßig den Wert 127.0.0.1. In Konfigurationen, die von älteren Versionen erstellt wurden, wird explizit 0.0.0.0 angegeben; daher ändert der neue Standardwert diese Einstellung nicht. Solche Konfigurationen verweigern weiterhin Anfragen, bis eine gültige Anmeldeinformation eingegeben wird.
• HTTPS. server.tls.mode ist ein einziger Schalter für alle drei Listener: off, self_signed (es wird ein Zertifikat im Datenverzeichnis erstellt; dessen SHA-256-Fingerabdruck wird im Panel angezeigt, damit Clients ihn als „Pin“ nutzen können) oder cert (Ihre eigenen Zertifikatsdateien). Bei aktivierter Netzwerkbindung und deaktiviertem TLS warnt doctor davor, dass Schlüssel unverschlüsselt über das Netzwerk übertragen werden. Auch ein Reverse-Proxy oder tailscale serve vorneweg funktioniert in diesem Fall.
• Browser. server.cors_origins hat nun standardmäßig keinen Wert (zuvor war es ["*"]). Nicht-browserbasierte Clients beachten das nicht. Die MCP-Endpunkte führen zusätzlich eine eigene Überprüfung des „Origin“-Werts durch: Eine Anfrage, die einen Origin-Header enthält, muss von einer lokalen Seite oder einem in der Liste aufgeführten Ursprung stammen; ein gespeicherter Wert * zählt dabei nicht. Dadurch wird verhindert, dass eine beliebige Webseite über Ihren Browser die Verwaltungstools Ihres Systems steuern kann.
• Brute-Force-Angriffe. Bei falschen Anmeldeinformationen erhält jede Client-Adresse drei freie Versuche; danach verlängert sich die Wartezeit jeweils um das Doppelte – bis zu maximal fünf Minuten. Dies gilt getrennt für die API, das Panel sowie den Watchdog.

Die gemeinsame Nutzung der Grafikkarten: Leasing und Nutzer

Falls andere Programme auf dem System die GPUs nutzen (z. B. ein Bildgenerator, ein Sprachserver oder ein Benchmark-Programm), können sie zuerst ein Leasing für eine Grafikkarte beantragen. StudioForge lädt in diesem Fall kein Modell auf diese Karte, bis das Leasing beendet wird oder die Karte nach Ablauf der Zeit nicht mehr genutzt wird. Version 2.0 führt außerdem ein Tenant-Register ein – dadurch können diese Programme sich selbst melden und auf der „Placement“-Seite mit aktuellem Status angezeigt werden. Zudem gibt es die Einstellung devices: "auto", wodurch ein Tenant nach einer beliebigen Karte mit ausreichend freiem Speicherplatz fragen kann, anstatt eine bestimmte Karte auszuwählen. StudioForge zeigt alle Tenants an und kann sie dazu auffordern, eine Karte „vorzuwärmen“ oder freizugeben – doch es startet bzw. stoppt sie niemals selbst.

Der Fix in Version 2.0.1 ist wichtig, falls Sie eines der folgenden nutzen: In Version 2.0.0 benötigten die Tenant-Routen einen admin-Schlüssel; daher erhielt ein Sprach- oder Bildserver, der einen gültigen inference-Schlüssel verwendete, den Statuscode 403, als er versuchte, ein Lease zu erhalten. In Version 2.0.1 handelt es sich dabei um inference-Routen – jedes Lease ist dabei an den Schlüssel gebunden, der es erstellt hat: Ein weiterer inference-Schlüssel kann es nicht freigeben (ich habe es ausprobiert; es kam die Fehlermeldung 403 permission_denied mit dem Hinweis „Lease … wurde nicht von diesem API-Schlüssel erstellt“). Ein admin-Schlüssel kann dies jedoch immer noch.

Eine wichtige Information bei der Benennung eines Tenants: Die Leases werden den Tenants anhand der Familie zugeordnet – also dem Namen, der vor dem ersten - steht. Ein Tenant, der als speech-demo registriert wurde, erhielt kein Lease mit dem Namen speech-demo (die „Familie“ des Leases lautet speech); als speech registriert, erhielt er es doch. Verwenden Sie daher einen Tenant-Namen ohne Bindestriche. Das Protokoll selbst ist in der Datei docs/TENANTS.md im Repository dokumentiert.

sfctl 2.0.1 – die Fernsteuerung

sfctl ist ein kleiner Client, mit dem man einen StudioForge-Server von einem anderen Rechner aus steuern kann; außerdem dient er als MCP-Brücke für Agenten. Mittlerweile wird ein Schlüssel benötigt. Das Programm ist nicht auf PyPI verfügbar (der Befehl uv tool install studioforge-companion aus der README-Datei schlägt fehl); daher muss man es über ein Clone-Repository installieren:

git clone https://github.com/LaserLloyd/StudioForge.git
uv tool install ./StudioForge/packages/studioforge-companion
sfctl servers add rig http://192.0.2.10:1234 --api-key sf-i-your-key --use
sfctl status

Die Konfigurationsdatei wird unter ~/.config/studioforge/companion.toml abgelegt; sie ist nur für den Besitzer lesbar, da sie den Schlüssel enthält. Alternativ kann man auch die Umgebungsvariable SF_API_KEY verwenden. Falls der Gateway nicht auf Port 1234 läuft, muss man --watchdog-url angeben – schließlich wird die Adresse des Watchdog-Dienstes aus der Gateway-Adresse abgeleitet. An meinem Testsystem mit einem inference-Schlüssel sieht das so aus:

$ sfctl status
┏━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━┳━━━━━━━━━━┓
┃ GPU ┃ Name                           ┃ Total    ┃ Used ┃ Free     ┃
┡━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━╇━━━━━━━━━━┩
│ 0   │ Demo GPU 0 (simulated) (sm_86) │ 24.0 GiB │ 0 B  │ 24.0 GiB │
│ 1   │ Demo GPU 1 (simulated) (sm_86) │ 24.0 GiB │ 0 B  │ 24.0 GiB │
└─────┴────────────────────────────────┴──────────┴──────┴──────────┘
no models loaded

$ sfctl leases add --devices 1 --holder image-render --reason "a render job outside StudioForge"
lease 933d9554c0c6 holds GPU 1 for image-render
release it with: sfctl leases release 933d9554c0c6

(Ich habe die Spalten „Util“ und „Temp“ sowie die Server-Tabelle gekürzt, um sie in den Rahmen zu bekommen.)

Doctor und das Support-Bundle

studioforge doctor überprüft Ports, GPUs, die Engine, die Festplatte, Dateiberechtigungen, das Zertifikat, Migrationen sowie den Authentifizierungsstatus und gibt für jedes Problem eine Lösung aus. Mit dem Parameter --strict beendet sich das Programm auch bei Warnungen mit einem Fehlercode – was für Monitoring-Zwecke geeignet ist. Dies ist der Demo-Container, der im Netzwerk auf Anfragen wartet; dabei wird ein Eigentümerkonto verwendet und TLS ist deaktiviert:

[ok  ] GPU: 2 GPU(s) via fake: Demo GPU 0 (simulated) (24 GiB), Demo GPU 1 (simulated) (24 GiB).
[WARN] Engine: No llama.cpp engine is installed.
        fix: Run `studioforge setup` or `studioforge engine --update` to install and smoke-test one.
[ok  ] Permissions: The data directory is writable and credential files are owner-only.
[ok  ] Migrations: The database is at schema 10 (current).
[info] Authentication: The server listens on the network and requires an API key or an account.
[WARN] Authentication: The network listeners use plain HTTP, so keys and passwords cross the network in the clear.
        fix: Set server.tls.mode to self_signed (or cert), or front the server with a TLS reverse proxy / `tailscale serve`.
[info] Authentication: mcp.pin is set. It is deprecated and grants admin on the MCP endpoints.

9 ok, 3 info, 2 warnings, 0 failures.

Auf dem Loopback-Testserver, auf dem noch server.api_key gesetzt war, gab derselbe Befehl folgende Warnung aus: „server.api_key ist gesetzt. Er funktioniert zwar weiterhin (als Admin-Schlüssel ‚legacy‘), ist aber veraltet.“ Die empfohlene Lösung: Scoped-Keys erstellen, Clients umziehen sowie legacy widerrufen.

studioforge support-bundle erstellt ein kleines ZIP-Archiv für Fehlerberichte: eine anonymisierte Konfiguration, die Ausgabe von „doctor“, Versionsinformationen, die Liste der GPUs sowie die letzten Log-Einträge. Bei mir war das Archiv 6 KiB groß; dabei wurde der PIN-Code als [REDACTED] angezeigt. Ebenfalls anonymisiert wurde engine.pinned_tag, also die Build-Nummer von llama.cpp – diese ist für Fehlerberichte nützlich und eigentlich kein Geheimnis; daher sollte man sie manuell hinzufügen. Der Befehl selbst warnt: „Schauen Sie genau hin, bevor Sie teilen“ – und das zu Recht.

Ausführen in einem Container

Version 2.0 enthält ein Dockerfile mit Varianten für CUDA, ROCm und Vulkan, einen Benutzer ohne Root-Rechte, ein read-only-Root-Dateisystem sowie ein benanntes Volume. Zudem gibt es Compose-Dateien für Docker und Podman. Beim ersten Start auf einem neuen Volume erstellt der Container das Owner-Konto – basierend auf dem Wert von SF_OWNER_PASSWORD oder einem automatisch generierten Passwort, das im Volume gespeichert wird. Ein veröffentlichter Port gilt innerhalb des Containers als „außerhalb des Loopbacks“; daher werden die Ports standardmäßig an 127.0.0.1 weitergeleitet – es sei denn, Sie setzen SF_BIND.

Die Images befinden sich noch nicht in einem Registry; der Abruf über ghcr.io/laserlloyd/studioforge wird derzeit abgelehnt. Daher müssen Sie das Image zunächst selbst erstellen; in der README finden Sie die genauen Befehle für jede Plattform. Für diese Screenshots habe ich das Vulkan-Image mit Podman erstellt – es ist 568 MB groß und läuft im read-only-Modus, wobei alle Funktionen deaktiviert sind. Nur das NVIDIA-Image hat bisher ein echtes Modell erfolgreich verarbeitet; die AMD- sowie Vulkan-Images starten zwar und reagieren auf /health, wurden jedoch noch nicht auf AMD- oder Intel-Hardware getestet. Informationen zu Image-Größen, GPU-Flags, Tests zur Kompatibilität nach Updates sowie Backups für das gesamte System finden Sie unter Jedes Modul in Docker; daher werde ich sie hier nicht erneut aufzählen.

Weitere Neuerungen in Version 2.0

• Mehr Clients funktionieren weiterhin ohne Änderungen: LM Studio’s native REST-API unter /api/v1, ein mit Anthropic kompatibler Endpunkt /v1/messages (x-api-key sowie Bearer-Token funktionieren beide), sowie ein stateless OpenAI-Endpunkt /v1/responses.
• Fehlermeldungen, die angeben, wie man sie beheben kann: 76 Fehlercodes – jeder mit den Feldern fix und docs in der Fehlermeldung. Der Fehlercode 401, den ein Client ohne API-Schlüssel erhält, nennt außerdem den Befehl, mit dem man einen Schlüssel erstellen kann.
• Mehr Unterstützung als nur für NVIDIA: Erkennung von ROCm-, Vulkan- sowie Metal-GPUs; außerdem ein Installationsprogramm, das die Prüfsummen der Archive überprüft. Getestet wurde anhand von vorher aufgezeichneten Testergebnissen – nicht auf echter AMD- oder Apple-Hardware. Software-basierte Vulkan-Implementierungen wie llvmpipe werden abgelehnt, da StudioForge gerade verhindern soll, dass Modelle auf der CPU ausgeführt werden.
• Ein größeres Bedienpanel: 11 Abschnitte (Übersicht, Modelle, Bereitstellung, Engines, Integrationen, Benutzer & Schlüssel, Updates, Protokolle & Metriken, Diagnose, Erweitertes) sowie drei neue Design-Themes.
• Semantisches Versionsmanagement: Die Version 2.0.0 entspricht der bisherigen Kalenderversion 1.26-09-23; der Updater sortiert beide Versionsschema korrekt.

Wie ich das getestet habe – und was ich nicht getestet habe

Das System, auf dem ich schreibe, verfügt über keine NVIDIA-GPU; daher konnte ich kein Modell laden. StudioForge stellt für sein Testpaket ein simuliertes GPU-Backend bereit (SF_GPU_PROBE=fake sowie eine JSON-Liste von Grafikkarten in SF_FAKE_GPUS). Auf diesem simulierten Backend laufen sowohl das Panel als auch die Funktionen für Schlüssel, Konten, Lizenzen, Mandanten sowie die Support-Funktionen. Alles, was oben mit „Ich habe es ausprobiert“ gekennzeichnet ist oder Ausgaben zeigt, wurde unter Version 2.0.1 getestet: Einmal über eine Kopie des Repositories in einem temporären Verzeichnis, einmal im Podman-Container – beide Male über Loopback-Ports und mit Demo-Modelldateien, die Header enthalten, aber keine Gewichte. Die Modellgrößen sowie die Quantisierungswerte im Panel entsprechen tatsächlichen Werten; die Modelle selbst sind jedoch nicht echt.

Was ich hier nicht getestet habe: Das Laden bzw. Bereitstellen von Modellen, TLS im self_signed-Modus, die Windows-Tray-Funktion sowie ein In-Place-Upgrade aus einem Datenverzeichnis der Version 1.26 (das Docker-Tutorial behandelt ein solches Upgrade auf demselben Volume). Die Anleitung zum Upgrade oben stammt von meinem echten System – nicht von der temporären Testinstanz.

Unvollkommenheiten/Probleme

• Noch keine Veröffentlichung. Version 2.0.1 befindet sich auf dem main-Branch – ohne Tag, ohne GitHub-Release, ohne PyPI-Paket sowie ohne veröffentlichtes Image. Der Selbst-Updater hat bisher nichts zu aktualisieren.
• Irreführende Warnung. Auf einem Netzwerkserver, der zwar ein Administratorkonto besitzt, aber keinen server.api_key, gibt die Setup-Checkliste weiterhin an, dass der Server „ohne API-Schlüssel erreichbar ist: Jeder im LAN kann Modelle laden, entladen und löschen“. Das stimmt jedoch nicht – sowohl die Seite „Benutzer & Schlüssel“ als auch tatsächliche Anfragen zeigen, dass eine Anmeldung erforderlich ist. Die Checkliste berücksichtigt lediglich den alten, gemeinsam genutzten Schlüssel.
• Die Dokumentation widerspricht sich bezüglich des Container-Engines. Im README wird der 14 GB große -cuda-devel-Container verwendet; dabei wird llama.cpp beim ersten Start kompiliert. In der Container-Anleitung hingegen heißt es, dass der kleinere -cuda-Container ein bereits vorkompiliertes Engine-Image herunterlädt. Ohne NVIDIA-Grafikkarte konnte ich das nicht überprüfen – folgen Sie daher vorerst dem README, bis sich die Angaben decken.
• Bisher wurde es von niemandem geprüft. Das Sicherheitsmodell ist in der Datei docs/SECURITY.md dokumentiert; darin werden auch die Schwachstellen aufgeführt (z. B. ein Administrator auf demselben Rechner oder HTTP ohne Verschlüsselung in einem Netzwerk, das Sie nicht kontrollieren). Lesen Sie diese Datei, bevor Sie StudioForge in einem gemeinsam genutzten Netzwerk einsetzen.

Herunterladen

git clone https://github.com/LaserLloyd/StudioForge.git

Folgen Sie anschließend den Anweisungen in der README-Datei für Ihre Plattform. Das ältere ZIP-Archiv im ursprünglichen Artikel ist Version 0.2.0 und enthält nichts davon. Lizenz: MIT.

Verwandt: StudioForge: Ein GPU-exklusiver LLM-Server (der Planer, die Messungen sowie die MCP-Tools), Jedes Modul in Docker (der Container-Workflow für das gesamte System) sowie DisPatch (eine Chat-Anwendung, die per Schlüssel damit verbunden wird).