Passer au contenu principal
Votre boîtier domestique diffuse déjà les modèles sans problème sur le réseau local. Le défi réside en revanche à permettre à vos collègues — ou à une application extérieure — d’y accéder, surtout lorsque le CGNAT de votre fournisseur d’accès empêche toute redirection de port. En exécutant tokios-connector à côté de votre environnement de fonctionnement, vous obtenez un point d’accès authentifié sur https://api.tokios.com que quiconque recevra l’invitation pourra utiliser, sans ouverture de ports, sans modification de routeur et sans accès direct brut au boîtier.

Le problème de connectivité des serveurs domestiques

Un serveur GPU domestique est généralement dépourvu d’interface, installé dans un placard ou un rack, et exécute Ollama, vLLM ou llama.cpp pour les utilisateurs du réseau local. Le partage de ce serveur au-delà de ce cercle rencontre plusieurs obstacles majeurs :
  • Absence d’adresse IP publique pour la redirection. Si votre fournisseur d’accès utilise un CGNAT, il n’existe aucune adresse IP unique vers laquelle appliquer une règle de redirection de port — consultez Diffuser un LLM local derrière un CGNAT pour comprendre pourquoi il s’agit d’une configuration de routeur impossible à modifier soi-même.
  • On ne souhaite pas non plus le rendre accessible même si cela était possible. Lier l’environnement de fonctionnement à 0.0.0.0 et ouvrir un port transformerait votre boîtier GPU en service non authentifié sur Internet. Toute personne découvrant ce port pourrait alors lui envoyer des requêtes.
  • Partager l’accès revient à tout partager. Fournir à un collègue votre nœud Tailscale ou un port ouvert lui accorde exactement les mêmes droits que vous — il n’existe pas de clé API individuelle ni de moyen de restreindre un utilisateur sans affecter l’ensemble du groupe.
Tokios constitue la couche de connecteur s’interfaçant avec l’environnement de fonctionnement déjà en place ; il ne remplace en rien Ollama, vLLM ou llama.cpp.

Procédez à sa configuration sur votre serveur

1

Lancez vos environnements de fonctionnement sur le serveur

Lancez votre serveur de modèles comme d’habitude, par exemple :
ou
Laissez-le écouter sur son adresse de boucle locale par défaut. Vérifiez qu’il répond bien à votre propre API compatible OpenAI /v1 avant d’ajouter le connecteur.
2

Obtenez un code d’appairage et appairez le connecteur

Dans le tableau de bord dashboard, ouvrez l’onglet Setup puis sélectionnez Start pairing afin de recevoir un code d’appairage unique de forme TKS-XXXX-XXXX (valable environ 15 minutes). Sur le serveur, exécutez :
Linux
Avez-vous déjà installé tokios-connector ? Transmettez alors directement le code :
De retour dans le dashboard, cliquez sur approve pour l’appareil dans l’onglet Setup ou Connectors. Le jeton du connecteur (ct-tok-…) est transmis via le tunnel une fois l’appareil approuvé — vous ne le voyez jamais à l’écran et ne le collez dans aucun fichier.
3

Indiquez au connecteur les ID de modèle amont à utiliser

Les ID de modèle amont du connecteur correspondent à votre propre API compatible OpenAI sur le serveur, et non à un port exposé à l’extérieur. Les ports par défaut sont : Ollama 11434, llama.cpp 8080, vLLM 8000, LM Studio 1234 — tous suivis de /v1. Pour Ollama, indiquez son API compatible OpenAI /v1 et non son API native /api. Aucune règle de pare-feu entrante n’est requise, car le connecteur ne fait que des appels sortants.
4

Enregistrez un déploiement par modèle

Dans l’onglet Models, associez chaque ID de modèle amont (par exemple llama3.1) à un nom de déploiement public que votre équipe utilisera, tel que homelab-llama. Les clients transmettent ce nom de déploiement dans le champ model de chaque requête, jamais l’ID amont.
5

Créez des clés API spécifiques à chaque membre de l’équipe

Dans l’onglet Keys, cliquez sur Create key pour chaque collègue ou application. Définissez la portée de chaque clé API en fonction de motifs de noms de déploiement spécifiques (liste de motifs séparés par des virgules, * pour tout) afin qu’un collègue ne puisse accéder qu’aux modèles que vous avez désignés. Ces clés sont des jetons sk-tok-… de type Bearer, affichés une seule fois lors de leur création — copiez-les avant de quitter la page.

Héberger plusieurs modèles simultanément

Si votre machine exécute plusieurs modèles ou répartit le trafic entre Ollama, llama.cpp et vLLM, utilisez le fichier de configuration du connecteur plutôt que le processus de liaison à un seul ID de modèle amont. Dans tokios-connector.json, indiquez Routes et Upstreams dans la section Connector : il faut un Upstream par backend, chacun doté de son propre BaseUrl (y compris /v1). Transmettez ensuite ce fichier via --config. Consultez Le routage des modèles pour savoir comment enregistrer et basculer entre les différents déploiements derrière un même point d’accès.

Utilisation depuis n’importe où

Le champ model indique toujours le nom du déploiement enregistré, jamais l’ID de modèle amont. Consultez Utiliser Claude Code pour apprendre à interroger votre serveur domestique depuis claude --model homelab-llama.

Pourquoi un seul point d’accès pour toute l’équipe ?

  • Aucun port entrant n’est ouvert sur la machine, jamais. Le connecteur ne crée que des connexions sortantes, de sorte que vos collègues n’ont pas besoin de VPN, de tunnel SSH ni de port 0.0.0.0 configuré pour accéder au serveur — cela vaut que vous soyez ou non derrière un CGNAT.
  • Révoquer la clé d’un collègue sans impacter les autres. Puisque chaque personne dispose de sa propre clé sk-tok-…, la désactiver ou la supprimer dans l’onglet Keys bloque immédiatement cet utilisateur tout en laissant les autres clés pleinement opérationnelles.
  • Changer de modèle sans modifier la configuration cliente. En associant un nom de déploiement à un autre ID de modèle amont ou à un autre backend, tous les collègues et scripts ciblant déjà homelab-llama continuent de fonctionner sans modification.

Prochaines étapes

Démarrage rapide

Apprenez en quelques instants à mettre en place un connecteur, un déploiement et une clé API fonctionnels.

Le modèle LLM utilisé derrière les CGNAT

Pourquoi le transfert de ports échoue chez les fournisseurs d’accès résidentiels, et comment le connecteur contourne ce problème.

Référence de configuration du connecteur

Héberger plusieurs modèles depuis un seul serveur grâce à tokios-connector.json.

Routage des modèles

Enregistrer et basculer entre plusieurs déploiements derrière un même point d’accès.