StudioForge 2.0 : Comptes, clés API limitées à un périmètre spécifique et procédure de mise à niveau sécurisée

StudioForge est le serveur de modèles dédié aux GPU que j’ai développé pour remplacer LM Studio sur ma machine (toute l’histoire se trouve dans l’article original). La version 2.0 modifie les règles d’accès au serveur. Dans la version 0.2.0, StudioForge écoutait sur toutes les interfaces réseau et faisait confiance à tout ce qui pouvait y accéder, avec un code PIN optionnel pour les outils d’agent. En version 2.0, il n’écoute que sur la machine sur laquelle il s’exécute, sauf si vous en décidez autrement ; une fois l’accès autorisé, chaque appelant doit disposer d’une clé.

Code source sur GitHub

J’ai mis à jour ma propre machine le 19 octobre 2026. Tous les programmes qui s’adressaient à StudioForge sans clé ont commencé à recevoir des erreurs 401 en quelques minutes : mon outil de messagerie, mon application de chat, le moteur de recherche mémoire du gateway d’agents, ainsi que plusieurs scripts. Aucun de ces programmes n’était défectueux ; ils ne disposaient simplement pas encore de clé. Cette page représente ce que j’aurais aimé lire en premier.

Quels changements pour vous ?

Trois points, expliqués simplement.

• Par défaut, tout est privé. Le passerelle (port 1234), le panneau de contrôle (8080) et le mécanisme de surveillance de récupération (1235) sont liés à 127.0.0.1. Aucun autre ordinateur ne peut y accéder.
• Pour les rendre accessibles, il faut se connecter. Si l’un de ces trois services écoute sur une adresse réseau, mais qu’il n’existe ni compte propriétaire ni clé d’administration, studioforge serve s’arrête avec le code de sortie 4 et indique comment corriger la situation. Il est désormais impossible de lancer par erreur un serveur ouvert.
• Chaque programme dispose de sa propre clé. Une clé est une chaîne de caractères du type sf-i-… que le programme envoie sous la forme Authorization: Bearer <key>. Chaque clé possède un nom, un périmètre d’autorisation, une date d’expiration optionnelle ainsi qu’une limite de requêtes par minute optionnelle ; vous pouvez en révoquer une sans affecter les autres.

Voici le refus obtenu lors de mon test, avec les trois hôtes configurés sur 0.0.0.0 et aucun compte créé :

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.

Un détail m’a surpris : la création de la première clé active l’authentification pour tout le monde, y compris les programmes exécutés sur la même machine. J’ai créé une clé sur un serveur de test limité au loopback ; aussitôt, une requête curl vers /v1/models en provenance de la même machine est passée du code 200 au code 401. La CLI, le tray et le panneau StudioForge continuent de fonctionner car ils génèrent leur propre clé d’administration locale (local-cli, stockée uniquement pour le propriétaire dans le répertoire de données). Tous les autres programmes auront désormais besoin d’une clé pour fonctionner.

La mise à jour sécurisée en dix minutes

C’est l’ordre qui permet de limiter la durée de la panne. Il suit les étapes de migration indiquées dans le CHANGELOG, avec deux corrections issues de mon propre déploiement.

1. Listez vos clients. Toute application de chat, tout agent, tout script et toute autre machine qui appelle le serveur. Si vous n’en êtes pas sûr, recherchez dans leurs configurations l’adresse du serveur à l’aide de grep. Cette liste représente toute la tâche.
2. Faites une sauvegarde et une prévisualisation. Copiez le répertoire de données, mettez à jour le code (git pull, puis réinstallez-le dans votre venv selon les instructions du README pour votre plateforme), et exécutez studioforge migrate --dry-run. La version 2.0.1 passe la base de données au schéma 10, et studioforge migrate en fait d’abord une sauvegarde avant d’appliquer les modifications.
3. Créez les identifiants nécessaires pour démarrer. Soit en utilisant studioforge setup (l’assistant de première utilisation ; il crée le compte propriétaire et, si vous choisissez « mon réseau local », active le HTTPS et génère une clé d’administration), soit simplement en exécutant studioforge keys create --name admin --scope admin.
4. Créez une clé par client, toutes en même temps, avant de lancer le nouveau serveur :

   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

   Chaque jeton est affiché une seule fois et jamais stocké ; collez-le donc immédiatement dans la configuration de ce client.
5. Démarrez le serveur et testez chaque client avec une requête réelle. Un 401 invalid_api_key signifie que le client n’a toujours pas de clé ; un 403 permission_denied indique que la portée de sa clé est insuffisante pour ce qu’il a tenté d’effectuer.
6. Retirez en dernier les anciennes identifiants. Une fois que tous les clients fonctionnent avec leur propre clé : studioforge keys revoke legacy, supprimez la valeur de server.api_key et désactivez le PIN MCP. Consultez ci-dessous le piège lié au PIN ; il ne suffit pas de simplement effacer le PIN.
7. Exécutez studioforge doctor et lisez le résultat.

Si vous avez déjà utilisé server.api_key, la mise à niveau ne pose aucun problème : la clé ancienne est simplement copiée dans le tableau des clés en tant que clé d’administrateur nommée legacy, et continue de fonctionner. Sur mon système, il n’y avait pas de clé partagée, seulement un code PIN ; par conséquent, tous les clients ont cessé de fonctionner en même temps. Si j’avais effectué l’étape 4 avant l’étape 5, j’aurais évité la plupart de ces problèmes.

Le panneau de contrôle : connexion, configuration, création de clés

Ces captures d’écran proviennent d’une instance 2.0.1 temporaire que j’ai exécutée dans Podman sur une machine dépourvue de GPU NVIDIA (plus de détails ci-dessous) ; les deux cartes graphiques sont donc simulées et les clés générées ne servent à rien.

Le panneau de contrôle dispose désormais d’une page de connexion. Utilisez le nom d’utilisateur et le mot de passe du propriétaire, ou laissez le nom d’utilisateur vide et collez une clé d’administrateur. Une clé read ou inference ne permet pas de s’y connecter.

Le guide de configuration situé à l’adresse /setup décrit huit étapes : création du compte propriétaire, configuration matérielle, moteur de traitement, bibliothèques de modèles, modèle de départ, test de chat, extraits de code client, ainsi que les utilisateurs autorisés à accéder au serveur. Chaque étape peut être ignorée. La dernière étape permet de choisir entre « uniquement cet ordinateur » et « mon réseau local, via HTTPS ».

Les clés se trouvent dans la section Utilisateurs & Clés. Donnez-leur un nom indiquant quel programme les utilisera, choisissez leur portée, et définissez éventuellement une date d’expiration ainsi qu’une limite de requêtes.

Le token est affiché une seule fois. Je l’ai masqué sur cette capture d’écran, mais sur un vrai serveur, cette fenêtre est la seule occasion de le voir.

Le tableau indique la portée de chaque clé, les premiers caractères du token, la dernière utilisation, la date d’expiration, la limite de requêtes et son état actuel. En dessous se trouve le journal d’audit : toute création ou révocation de clé, toute tentative de connexion et tout changement effectué par un administrateur y sont consignés, avec l’identité de l’utilisateur et sa provenance. Les secrets ne figurent jamais dans ce journal.

Scopes : read, inference, admin

Scope	Autorisations	À qui l’attribuer ?
read	Consultation : statut, listes de modèles, /metrics, outils MCP en lecture seule. Il est impossible d’effectuer des requêtes POST.	Tableaux de bord, outils de surveillance
inference	Lecture, ainsi que possibilité de discuter via les endpoints (/v1/chat/completions, /v1/messages, /v1/responses), charger, décharger et tester des modèles, ainsi que d’acquérir ou de libérer un accès à la GPU.	Applications de chat, agents, scripts, autres programmes utilisant la GPU
admin	Modification de la configuration : paramètres, redémarrages, installation et mise à jour des moteurs, téléchargements, suppressions, gestion des clés, comptes, journal d’audit, bundles de support, outils MCP destructifs.	Vous

La règle est basée sur le code, non sur des conventions (api/auth.py:required_scope). Elle fonctionne selon le préfixe du chemin d’accès ; toute requête modifiant l’état du système et non classée dans un scope spécifique nécessite obligatoirement le scope admin. Ainsi, les nouvelles routes sont automatiquement couvertes. Un scope est systématiquement vérifié dès qu’une clé est transmise, même sur un serveur ne nécessitant aucun contrôle de permissions : une clé read ne peut donc pas effectuer de requêtes POST sur un serveur destiné uniquement à l’usage local. J’ai testé les limites sur une instance d’essai : une clé inference renvoie le code 200 pour /v1/models, mais le code 403 pour /api/keys.

Les agents reçoivent également une clé, jamais le mot de passe administrateur. La page « Intégrations » du panneau d’administration affiche des blocs prêts à être copiés pour OpenClaw, les SDK Python d’OpenAI et d’Anthropic, DisPatch, curl ainsi que le fichier --mcp-config de Claude. Il faut d’abord sélectionner une clé dans le menu déroulant : si aucune n’est choisie, le bloc curl omet l’en-tête Authorization, ce qui entraîne un code 401 lors de son utilisation.

Le compte propriétaire, l’ancienne clé partagée et le PIN

La version 2.0 dispose de trois types de identifiants d’authentification ; deux d’entre eux sont en voie de suppression.

• Le compte propriétaire sert à se connecter au panneau d’administration. Le mot de passe doit comporter au moins 10 caractères et est haché avec argon2id. Le hash est stocké dans le porte-clés du système d’exploitation si l’extra keyring est installé ; sinon, il est enregistré dans un fichier accessible uniquement au propriétaire. Ce mot de passe n’est pas présent dans la base de données, donc une copie de la base ne permet pas de se connecter.
• server.api_key (déprécié) fonctionne toujours partout en tant qu’identifiant d’administrateur ; il apparaît sous le nom legacy. L’action keys revoke legacy le désactive effectivement.
• mcp.pin (déprécié) est un identifiant d’administrateur composé de huit chiffres, utilisable uniquement pour les endpoints MCP. Sur un serveur ne disposant d’aucune autre clé, il permet toujours l’accès aux routes HTTP permettant de modifier les paramètres ; ainsi, les anciennes configurations continuent de fonctionner. Dès qu’une clé à portée définie est créée, ce mécanisme cesse de fonctionner.

Le piège lié au PIN. Le CHANGELOG indique de “supprimer server.api_key et mcp.pin”. Si vous définissez simplement mcp.pin: null sans autre modification, un nouveau PIN aléatoire sera généré au prochain démarrage et enregistré, car mcp.pin_required reste à la valeur true. J’ai moi-même observé ce phénomène. Pour le désactiver définitivement, il faut définir les deux paramètres suivants :

mcp:
  pin: null
  pin_required: false

De la même manière, une installation neuve de la version 2.0.1 génère automatiquement un PIN au premier démarrage ; par la suite, studioforge doctor le signale comme étant déprécié. Ce comportement est inoffensif, mais ne soyez pas surpris s’il se produit.

Liaison réseau, HTTPS et navigateurs

• Règle de liaison. server.host, gui.host et watchdog.host prennent par défaut la valeur 127.0.0.1. Une configuration créée par une version antérieure spécifie explicitement 0.0.0.0 ; le nouveau réglage par défaut ne modifie donc pas cette valeur. Dans ce cas, l’accès est refusé jusqu’à ce que vous fournissiez des identifiants valides.
• HTTPS. server.tls.mode sert de paramètre unique pour les trois écouteurs : off, self_signed (un certificat est généré dans le répertoire de données ; sa empreinte SHA-256 est affichée afin que les clients puissent la vérifier) ou cert (vos propres fichiers). Lorsqu’une liaison réseau est activée et que le TLS est désactivé, doctor avertit que les clés circulent en clair sur le réseau. Un proxy inverse ou tailscale serve placé en amont fonctionnent également.
• Navigateurs. server.cors_origins est désormais vide par défaut (auparavant, il valait ["*"]). Les clients non-navigateurs ne sont pas concernés. Les points de terminaison MCP effectuent en plus leur propre vérification d’origine : toute requête portant un en-tête Origin doit provenir d’une page locale ou d’une origine autorisée ; la valeur * ne compte pas comme origine valide. Cela empêche toute page web aléatoire de piloter les outils de gestion via votre navigateur.
• Tentatives de force brute. Trois tentatives gratuites sont autorisées par adresse client en cas d’identifiants incorrects ; ensuite, le délai d’attente est doublé jusqu’à cinq minutes. Ces règles s’appliquent séparément à l’API, au panneau d’administration et au watchdog.

Partage des cartes GPU : baux et locataires

Si un autre programme sur la machine utilise les GPU (un générateur d’images, un serveur de reconnaissance vocale, un outil de benchmark), il peut d’abord obtenir un bail sur une carte. StudioForge ne chargera alors aucun modèle sur cette carte tant que le bail n’est pas libéré ou qu’il reste inactif au-delà du délai imparti. La version 2.0 introduit en outre un registre de locataires, permettant à ces programmes de s’enregistrer et d’apparaître avec leur état de santé en temps réel sur la page de placement ; elle propose également devices: "auto", ce qui permet à un locataire de demander n’importe quelle carte disposant de suffisamment de mémoire libre, sans avoir à en nommer une précisément. StudioForge affiche les locataires et peut leur demander de précharger un modèle ou de libérer une carte, mais ne démarre ni n’arrête jamais ces programmes.

Le correctif de la version 2.0.1 est important si vous utilisez l’un de ces programmes : dans la version 2.0.0, les routes destinées aux locataires nécessitaient une clé admin ; par conséquent, un serveur de reconnaissance vocale ou de génération d’images disposant d’une clé inference recevait un code 403 lorsqu’il tentait d’obtenir un bail. Dans la version 2.0.1, il s’agit désormais de routes inference, et chaque bail est lié à la clé qui l’a demandé : une autre clé inference ne peut pas le libérer (j’ai essayé, et j’ai obtenu 403 permission_denied avec le message « lease … was not created by this API key ») ; en revanche, une clé admin le peut toujours.

Une chose importante à savoir lors de l’enregistrement d’un locataire : les baux sont associés aux locataires en fonction de la famille, c’est-à-dire du nom du titulaire jusqu’au premier -. Un locataire enregistré sous le nom speech-demo ne voyait pas son propre bail speech-demo (la famille du bail étant speech) ; en revanche, s’il était enregistré sous le nom speech, il le voyait. Il convient donc d’utiliser un nom de locataire sans tiret. Le protocole lui-même est décrit dans le fichier docs/TENANTS.md du dépôt.

sfctl 2.0.1, la commande à distance

sfctl est un petit client permettant de piloter un serveur StudioForge depuis une autre machine, ainsi que le pont MCP pour les agents. Il nécessite désormais une clé d’accès. Ce programme n’est pas disponible sur PyPI (l’instruction uv tool install studioforge-companion indiquée dans son README échoue), donc il faut l’installer en clonant le dépôt :

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

Le fichier de configuration se trouve à l’emplacement ~/.config/studioforge/companion.toml ; il est réservé uniquement au propriétaire, car il contient la clé d’accès. Il est également possible d’utiliser la variable d’environnement SF_API_KEY. Si le gateway ne se trouve pas sur le port 1234, il faut ajouter l’option --watchdog-url, car l’adresse du watchdog est déduite de celle du gateway. Voici un exemple d’utilisation depuis mon instance de test, avec une clé de type inference :

$ 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

(J’ai supprimé les colonnes Util et Temp ainsi que le tableau des serveurs pour gagner de la place.)

Doctor et le paquet de support

studioforge doctor vérifie les ports, les GPU, le moteur, le disque, les permissions des fichiers, le certificat, les migrations ainsi que la configuration d’authentification, puis affiche une solution pour chaque problème détecté. --strict renvoie un code de sortie différent de zéro même en cas d’avertissements, ce qui est utile pour la surveillance. Voici le conteneur de démonstration, écoutant sur le réseau avec un compte propriétaire et sans TLS :

[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.

Sur le serveur de test en boucle locale où server.api_key était toujours défini, la même commande a affiché l’avertissement suivant : « server.api_key est défini. Il fonctionne encore (en tant que clé d’administration ‘legacy’) mais est obsolète » ; la solution proposée consiste à créer des clés à portée limitée, à déplacer les clients et à révoquer legacy.

studioforge support-bundle génère un petit fichier ZIP destiné aux rapports de bug : une configuration partiellement masquée, les résultats du diagnostic, les versions logicielles, la liste des GPU et les extraits des journaux. Le mien faisait 6 Ko, avec le PIN affiché comme [REDACTED]. Ce script masque également engine.pinned_tag, soit le numéro de version de la compilation de llama.cpp ; cette information est utile dans un rapport de bug et ne constitue pas un secret, il convient donc de la renseigner manuellement. La commande elle-même prévient : « regardez bien avant de partager », et c’est tout à fait juste.

Exécution dans un conteneur

La version 2.0 inclut un Dockerfile proposant des variantes avec CUDA, ROCm et Vulkan, un utilisateur non root, un système de fichiers racine en lecture seule ainsi qu’un volume nommé. Des fichiers compose pour Docker et Podman sont également fournis. Lors du premier démarrage sur un volume vierge, le conteneur crée le compte propriétaire à partir de SF_OWNER_PASSWORD ou d’un mot de passe généré et enregistré sur le volume ; en effet, la publication d’un port est considérée comme « en dehors du loopback » depuis l’intérieur du conteneur. Les ports sont publiés sur 127.0.0.1, sauf si vous définissez SF_BIND.

Les images ne se trouvent pas encore sur un registre (le téléchargement depuis ghcr.io/laserlloyd/studioforge est actuellement refusé), donc vous devez d’abord construire l’image vous-même ; le README indique les commandes exactes selon la plateforme. Pour ces captures d’écran, j’ai construit l’image Vulkan avec Podman : elle fait 568 Mo et fonctionne en mode lecture seule, toutes les capacités étant désactivées. Seule l’image NVIDIA a permis d’exécuter un modèle réel ; les images AMD et Vulkan démarrent correctement et répondent à /health, mais n’ont pas encore été testées sur du matériel AMD ou Intel. Les tailles des images, les paramètres liés aux GPU, les tests de mise à niveau ainsi que les procédures de sauvegarde pour l’ensemble de la pile se trouvent dans Chaque module dans Docker ; je ne les répéterai donc pas ici.

Nouveautés dans la version 2.0

• Plus de clients fonctionnent sans modification : l’API REST native de LM Studio sous /api/v1, une API compatible avec Anthropic à l’adresse /v1/messages (les méthodes x-api-key et bearer fonctionnent toutes deux), ainsi qu’une API OpenAI sans état à l’adresse /v1/responses.
• Messages d’erreur indiquant comment les corriger : 76 codes d’erreur, chacun accompagné des champs fix et docs dans le corps du message d’erreur. Le code 401 renvoyé à un client sans clé indique précisément la commande permettant de générer une clé.
• Plus de supports que NVIDIA, en théorie : détection des GPU ROCm, Vulkan et Metal, ainsi qu’un outil d’installation des moteurs capable de vérifier les sommes de contrôle des archives. Les tests ont été effectués à l’aide de sorties simulées, et non sur du matériel AMD ou Apple réel. Les dispositifs Vulkan logiciels tels que llvmpipe sont rejetés, car l’exécution d’un modèle sur le processeur est précisément ce que StudioForge vise à empêcher.
• Un panneau d’interface plus complet : 11 sections (Aperçu, Modèles, Mise en service, Moteurs, Configuration, Intégrations, Utilisateurs & Clés, Mises à jour, Journaux & Métriques, Diagnostics, Avancé) ainsi que trois nouveaux thèmes d’affichage.
• Versionnement sémantique : la version 2.0.0 succède à la précédente version calendaire 1.26-09-23 ; l’outil de mise à jour gère correctement les deux systèmes de numérotation.

Comment j’ai testé cela, et ce que je n’ai pas testé

L’ordinateur sur lequel j’écris ne dispose pas de GPU NVIDIA, donc je n’ai pas pu charger de modèle. StudioForge propose un backend GPU simulé pour son ensemble de tests (SF_GPU_PROBE=fake, avec une liste de cartes graphiques au format JSON dans SF_FAKE_GPUS) ; le panneau de contrôle, les clés, les comptes, les baux, les locataires, ainsi que les modules “doctor” et “support bundle” fonctionnent tous grâce à ce backend. Tout ce qui suit, où il est écrit “J’ai essayé” ou où des sorties sont affichées, a été exécuté sur la version 2.0.1 : une fois depuis une copie du dépôt dans un répertoire temporaire, et une autre fois dans un conteneur Podman ; dans les deux cas, sur des ports de boucle locale, en utilisant des fichiers de modèles de démonstration contenant des en-têtes mais pas de poids. Les tailles et quantifications des modèles affichées dans le panneau correspondent à de vraies valeurs d’en-tête ; en revanche, les modèles eux-mêmes ne sont pas réels.

Ce que je n’ai pas testé ici : le chargement ou le service d’un modèle, le TLS en mode self_signed, le tray Windows, ainsi qu’une mise à niveau “in-place” à partir d’un répertoire de données de la version 1.26 (l’article Docker traite d’une mise à niveau sur le même volume). La partie concernant la mise à niveau en haut de la page provient de ma propre machine, et non de l’instance temporaire utilisée pour les tests.

Points à améliorer

• Aucune version publiée pour l’instant. La version 2.0.1 se trouve sur la branche main, mais il n’y a ni tag, ni version publiée sur GitHub, ni paquet PyPI, ni image disponible. Le système de mise à jour automatique n’a donc rien à mettre à jour tant qu’aucune version ne sera publiée.
• Un avertissement trompeur. Sur un serveur en réseau disposant d’un compte administrateur mais sans server.api_key, la liste de vérification de configuration indique encore que le serveur est accessible « sans clé API : toute personne sur le LAN peut charger, décharger et supprimer des modèles ». Ce n’est pas le cas : la page Utilisateurs & Clés ainsi que les requêtes réelles montrent qu’une authentification est obligatoire. La liste de vérification ne prend en compte que l’ancienne clé partagée.
• Les documents diffèrent quant au moteur de conteneurs. Dans le README, la procédure Docker utilise l’image de 14 Go -cuda-devel et compile llama.cpp lors du premier démarrage ; en revanche, le guide sur les conteneurs précise que l’image allégée -cuda télécharge un moteur déjà compilé. Sans carte NVIDIA, je n’ai pas pu trancher ; suivez donc le README jusqu’à ce que les deux documents soient d’accord.
• Aucune autre personne ne l’a audité. Le modèle de sécurité est décrit dans le fichier docs/SECURITY.md du dépôt, y compris les menaces auxquelles il ne fait pas face (un administrateur sur la même machine, le protocole HTTP en clair sur un réseau non contrôlé par vous). Lisez-le avant de déployer StudioForge sur un réseau que vous partagez.

Obtenez-le

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

Ensuite, suivez les instructions du README pour votre plateforme. L’ancien fichier zip disponible sur l’article original correspond à la version 0.2.0 et ne contient rien de tout cela. Licence : MIT.

Voir aussi : StudioForge : un serveur LLM fonctionnant uniquement sur GPU (le planificateur, les mesures et les outils MCP), Chaque module dans Docker (la méthode de déploiement du stack entier via des conteneurs), ainsi que DisPatch (une application de chat qui s’y connecte à l’aide d’une clé).