Skip to main content
Votre machine Strix Halo exécute déjà le modèle. Le défi consiste à y accéder depuis votre ordinateur portable, votre éditeur ou votre agent de programmation sans ouvrir de ports entrants. En lançant le connecteur Tokios à côté du moteur d’exécution, vous obtenez un point de terminaison authentifié à l’adresse https://api.tokios.com capable de traiter les requêtes au format OpenAI et Anthropic. Ainsi, Claude Code, opencode ou tout autre client compatible OpenAI peuvent communiquer avec la machine sans avoir à modifier les règles du pare-feu.

​
Une fois le point de terminaison opérationnel

Les utilisateurs de Framework Desktop, de mini-PC et d’autres appareils AMD Ryzen AI Max+ 395 (« Strix Halo ») choisissent la configuration à 128 Go de mémoire unifiée pour exécuter des modèles locaux volumineux. Sur cette puce, la communauté constate que l’utilisation de llama.cpp avec le moteur Vulkan s’avère plus fiable que l’usage de ROCm/HIP. Une fois le modèle répondant sur localhost, la plupart des utilisateurs souhaitent ensuite le relier à un agent de programmation tel que opencode, Claude Code ou un outil similaire. Cela implique plusieurs étapes :
  • Un point de terminaison compatible OpenAI accessible depuis d’autres appareils. Par défaut, le moteur d’exécution s’attache à l’adresse 127.0.0.1 sur la machine Strix Halo. Pour y accéder depuis un ordinateur portable ou un agent de programmation distant, il faut lier l’adresse à 0.0.0.0, ouvrir un port ou établir un tunnel, chacune de ces méthodes nécessitant une configuration spécifique et ne proposant aucune authentification par client.
  • La structure de l’API. Claude Code utilise le format de messages d’Anthropic ; en revanche, llama.cpp, Ollama et LM Studio utilisent le format de complétion de chat d’OpenAI. Pour les relier, il faut généralement concevoir et maintenir un petit proxy.
  • Un emplacement stable pour orienter les outils. Il ne devrait pas être nécessaire de reconfigurer chaque client lorsque l’on bascule entre llama.cpp, Ollama ou LM Studio sur la même machine, ou lorsque l’on change de modèle.
Tokios constitue la couche de connecteur s’interfaçant avec le moteur d’exécution déjà en place ; il ne remplace en aucun cas llama.cpp, Ollama, LM Studio ou vLLM.
2 boîtiers Strix Halo peuvent disposer de suffisamment de mémoire agrégée pour les poids GGUF de DeepSeek-V4-Flash-0731, mais le chemin RPC llama.cpp requis est fragile, non sécurisé et relève de la preuve de concept. Ne le considérez pas comme un déploiement de production. Consultez Matériel local DeepSeek V4 Flash pour connaître les limites expérimentales.

​
Configurez-le sur votre boîtier Strix Halo.

1

Lancez le moteur d’exécution sur ce boîtier.

Exécutez votre serveur de modèles comme d’habitude, par exemple avec llama.cpp sur le moteur Vulkan :
ou bien via le serveur local de LM Studio, ou encore Ollama :
Vérifiez d’abord que le serveur répond via son propre API compatible OpenAI /v1 avant d’ajouter le connecteur.
2

Obtenez un code d’autorisation puis associez le connecteur.

Dans le tableau de bord dashboard, ouvrez l’onglet Setup et sélectionnez Start pairing afin de recevoir un code d’autorisation unique au format TKS-XXXX-XXXX (valable environ 15 minutes).Sur Linux :
Sur Windows (PowerShell) :
De retour dans le tableau de bord, validez l’appareil dans l’onglet Setup ou Connectors. Le jeton du connecteur est transmis via le tunnel — il n’est jamais nécessaire de le copier dans un fichier.
3

Indiquez au connecteur l’adresse de l’endpoint /v1 de votre moteur d’exécution.

L’upstream du connecteur est l’API compatible OpenAI propre au moteur d’exécution sur le boîtier, et non un port que vous exposez à l’extérieur. Ports par défaut : llama.cpp 8080, LM Studio 1234, Ollama 11434 (tous avec /v1 ajouté ; pour Ollama, utilisez son API compatible OpenAI /v1, et non l’/api native). Aucune règle de pare-feu entrante n’est nécessaire — le connecteur n’établit que des connexions sortantes.
4

Effectuez un déploiement

Dans l’onglet Models, associez votre ID de modèle amont à un nom de déploiement public tel que strix-coder. Les clients transmettent ce nom de déploiement dans le champ model, et non l’ID amont.
5

Créez une clé API

Dans l’onglet Keys, générez une clé. Il s’agit de jetons sk-tok-… de type Bearer, affichés une seule fois, et pouvant être limités à certains modèles de noms de déploiement.

​
Utilisez-la depuis votre agent de codage

Une fois le connecteur associé et le déploiement enregistré, indiquez à votre agent de codage d’utiliser Tokios plutôt que l’adresse locale de la machine.
Le sélecteur de modèles de Claude Code ne liste que les IDs claude* ; par conséquent, votre déploiement Tokios n’apparaîtra pas dans la liste — il faut donc spécifier --model strix-coder manuellement.
Si vous exécutez plusieurs moteurs sur la même machine — par exemple llama.cpp pour un modèle et Ollama pour un autre — utilisez le fichier de configuration du connecteur afin de définir plusieurs routes et modèles amont, plutôt que de suivre le processus d’association à un seul modèle. Consultez Le routage des modèles pour savoir comment enregistrer et basculer entre plusieurs déploiements derrière un même point d’accès.

​
Pourquoi un seul point d’accès ?

  • Permet de changer de moteur sans modifier la configuration de l’agent. Vous pouvez passer de llama.cpp à LM Studio ou Ollama sur la même machine, et tous les agents ciblant déjà strix-coder continueront de fonctionner — il suffit de modifier le modèle amont dans le connecteur, sans toucher aux paramètres clients.
  • Des clés limitées à des modèles spécifiques plutôt qu’une adresse commune. Vous pouvez attribuer à un collègue une clé ne fonctionnant que pour certains noms de déploiement, sans avoir à ouvrir le port du moteur sur votre réseau.
  • Aucun port entrant requis sur la machine. Le connecteur ne crée que des connexions sortantes, donc il n’est pas nécessaire de lier le moteur à l’adresse 0.0.0.0 ni de mettre en place un tunnel pour y accéder depuis un ordinateur portable ou un agent de codage.

​
Le connecteur Strix Halo peut-il exécuter Kimi K3 ?

Non. Le pool de mémoire unifiée de 128 Go de Strix Halo (~90–110 Go disponibles après déduction des frais du système d’exploitation) est bien en deçà de ce que Kimi K3 requiert. K3 compte 2.8 billions de paramètres au total et nécessite environ 1.4 To à sa précision MXFP4 native (4 bits par paramètre) — avant les échelles de blocs, les tampons d’exécution, les activations et le cache KV. Même si vous pouviez utiliser chaque octet du pool de 128 Go pour les poids, il vous manquerait encore environ 1.27 To. Moonshot recommande de déployer K3 sur un supernode doté de 64 accélérateurs ou plus. Pour le calcul complet de la mémoire requise et la dimensionnement du cluster, consultez le guide détaillé sur le matériel pour Kimi K3.
Vous cherchez un modèle compatible avec Strix Halo ? Consultez la liste des modèles adaptés à la place de Kimi K3 — le meilleur modèle polyvalent et dédié au codage pour un pool de mémoire unifiée de 128 Go.

​
Prochaines étapes

Guide de démarrage rapide

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

Installation du connecteur

Référence complète pour l’installation et le couplage du connecteur sur toutes les plateformes.

Utilisation de Claude Code

Configuration détaillée de ANTHROPIC_BASE_URL et ANTHROPIC_API_KEY.

Référence de configuration du connecteur

Servez plusieurs modèles depuis un seul appareil grâce à tokios-connector.json.