Mac dédié · Guide pratique

De la première connexion SSH
à la mise en ligne d’un endpoint d’inférence

Connectez-vous à la machine, migrez vos projets et modèles, puis faites tourner votre service sur le nœud. Les commandes de ce guide s’adressent aux Mac mini déjà livrés ; utilisez l’adresse publique, le nom d’utilisateur et les identifiants indiqués dans la console pour votre instance.

Louer un Mac cloud Ouvrir la console

Vous avez déjà commandé ? Vérifiez d’abord dans la console que votre instance est livrée, puis suivez les étapes ci-dessous.

Connexion sécuriséeSSH → MLX

XCODEOPS / GUIDE D’EXPLOITATION

Établissez d’abord une connexion fiable,
puis ouvrez l’accès au service.

01Récupérer les identifiantsVérifiez le nœud et l’adresse publique dans la console
02Créer un tunnelSSH pour le terminal et le bureau à distance
03Lancer l’endpointMLX écoute par défaut sur l’interface locale
Accès planifiéNœud physique · Usage exclusif

Accéder par tâche

Pour une première utilisation, lisez dans l’ordre les sections Connexion, Migration et MLX. Si votre environnement est déjà opérationnel, passez directement au choix de région et au dépannage.

01 / ACCÈS

Connectez-vous d’abord au serveur dédié en SSH

Récupérez les informations de connexion uniquement dans les détails de l’instance, dans la console. Ne stockez pas les identifiants initiaux dans un dépôt, des journaux CI ou des messages d’équipe. Vérifiez d’abord la connexion par clé, puis renforcez la sécurité de l’accès.

01

Vérifier l’instance

Connectez-vous à la console, ouvrez l’instance livrée et notez le nœud, l’adresse IP publique, le port SSH et le nom d’utilisateur. Vérifiez l’état de l’instance avant de vous connecter ; sa disponibilité réelle est celle indiquée dans la console.

02

Ajouter la clé publique

Générez une clé dédiée sur votre ordinateur, puis ajoutez la clé publique dans l’espace prévu à cet effet dans la console ou dans le fichier authorized_keys du compte de l’instance. Ne téléversez que la clé publique ; gardez toujours la clé privée sur votre appareil.

03

Tester, puis renforcer la sécurité

Vérifiez dans un deuxième terminal que la connexion par clé fonctionne, puis désactivez l’authentification SSH par mot de passe selon la politique de votre équipe. Avant toute modification, gardez la session actuelle ouverte et vérifiez la syntaxe de la configuration pour éviter de perdre l’accès à l’instance.

Préparer la connexion locale

Après avoir généré une clé, téléversez le contenu du fichier .pub . Les adresses d’exemple de la configuration ci-dessous sont réservées à la documentation. Avant utilisation, remplacez-les par l’adresse IP, le port et le nom d’utilisateur indiqués dans la console.

ssh-keygen -t ed25519 -f ~/.ssh/xops_node

cat ~/.ssh/xops_node.pub

~/.ssh/config

Host xops-node
  HostName 192.0.2.10
  User mac-user
  Port 22
  IdentityFile ~/.ssh/xops_node
  IdentitiesOnly yes

Enregistrez le fichier, puis exécutez chmod 600 ~/.ssh/config, puis lancez ssh xops-node. Lors de la première connexion, vérifiez l’empreinte de l’hôte. En cas de problème, vérifiez l’adresse IP, le port, les permissions de la clé et l’état de l’instance.

02 / BUREAU À DISTANCE

Accédez au bureau à distance par un tunnel SSH, sans exposer VNC

Pour utiliser l’interface graphique de Xcode ou vérifier les artefacts de build, assurez-vous d’abord que le partage d’écran est activé sur l’instance, puis transférez le port distant 5900 vers votre machine. Le tunnel se ferme à la fin de la session SSH.

Exécutez cette commande dans le terminal local 
ssh -N -L 5901:127.0.0.1:5900 xops-node

Laissez ce terminal ouvert. Dans l’app Partage d’écran de votre Mac ou un client compatible VNC, connectez-vous à vnc://127.0.0.1:5901. Vérifiez séparément les autorisations de connexion à l’interface graphique et celles de SSH ; ne partez pas du principe que les deux utilisent les mêmes identifiants.

À vérifier avant de commencer

  • Privilégiez l’app Partage d’écran intégrée au système. Tout autre client doit prendre en charge le mode de connexion et d’authentification choisi.
  • Si l’affichage est saccadé, réduisez d’abord la résolution et la profondeur de couleur à distance, puis vérifiez la connexion réseau avec le nœud. N’exposez pas le port VNC sur Internet pour gagner en vitesse.
  • La synchronisation du presse-papiers dépend du client et de la session distante. Pour transférer des poids de modèles, des certificats ou des projets volumineux, utilisez plutôt rsync ou un autre outil de synchronisation de fichiers.
  • Sur un ordinateur partagé, fermez le bureau à distance et le tunnel SSH en fin de session, puis supprimez les fichiers sensibles laissés sur la machine locale.
03 / MIGRATION DE L’ENVIRONNEMENT

Migrez votre Mac local vers le cloud en trois étapes

Synchronisez d’abord les fichiers de projet que vous pouvez recréer, restaurez ensuite la chaîne d’outils et configurez enfin la CI. Les poids de modèles, les éléments de signature et le cache de build ne se traitent pas de la même manière. Ne copiez pas sans tri tout le dossier utilisateur de votre Mac local.

01 / DONNÉES

Données et modèles

Utilisez rsync pour synchroniser progressivement vos projets et les poids des modèles. Faites d’abord un essai, puis vérifiez le répertoire cible, les permissions des fichiers et l’espace disponible. Une image de disque externe ne convient qu’à une migration hors ligne, après vérification du format et de la capacité.

rsync -avh --progress ./project/ \
  xops-node:~/work/project/

Transférez les fichiers de poids volumineux en plusieurs fois, puis comparez leur taille et leur somme de contrôle. Ne placez pas de clés privées ni de jetons temporaires dans le répertoire du projet.

Durée estiméeÀ partir de 15 à 60 minutesSelon le volume de données et le débit montant
02 / CHAÎNE D’OUTILS

Outils et signature

Sur votre Mac local, exportez un Brewfileavec Homebrew Bundle, puis importez-le sur le nœud. Vérifiez ensuite la version de Xcode, les outils en ligne de commande et les fichiers de verrouillage des dépendances. Transférez les certificats de signature séparément et limitez l’accès au trousseau après leur importation.

brew bundle dump --file=./Brewfile
rsync -av ./Brewfile xops-node:~/work/
ssh xops-node 'brew bundle --file=~/work/Brewfile'

Ne copiez pas directement votre environnement virtuel Python local : réinstallez les dépendances sur la machine cible.

Durée estiméeÀ partir de 20 à 45 minutesSelon les paquets et la vitesse de téléchargement
03 / CI

Intégration à la pipeline

Enregistrez un runner auto-hébergé dans votre projet CI existant et associez-le au dépôt ou à l’équipe concernée. Placez le cache de build dans un répertoire séparé et réglez le parallélisme en fonction de la mémoire disponible et de la charge de build habituelle.

  • Lancez d’abord un build de test sans clé de publication.
  • Notez le chemin du cache, l’espace disque utilisé et la stratégie de nettoyage.
  • Vérifiez que le runner s’exécute avec un compte dédié.
Durée estiméeÀ partir de 15 à 30 minutesHors premier build complet

Ces durées sont des estimations pour les opérations de migration, pas des délais de livraison de l’instance. Avant la première synchronisation, vérifiez l’espace disque disponible. Pour augmenter la capacité, consultez les configurations proposées dansModèles et options.

04 / INFÉRENCE MLX

Faites d’abord tourner l’endpoint en local, puis partagez-le avec l’équipe

La mémoire unifiée des puces Apple Silicon est partagée entre le CPU et le GPU. La capacité à charger un modèle dépend aussi du format de quantification, de la longueur du contexte et de la mémoire utilisée par les autres processus. Lors du choix de la machine, prévoyez une marge pour le système et les services ; ne considérez pas toute la mémoire annoncée comme disponible pour les poids du modèle.

Installer, démarrer, vérifier

Créez un environnement Python dédié au service sur l’instance. Le chemin du modèle ci-dessous doit pointer vers un répertoire local déjà synchronisé sur cette instance. Après le démarrage, vérifiez d’abord l’API compatible avec OpenAI depuis l’instance.

python3 -m venv ~/mlx-service/.venv
~/mlx-service/.venv/bin/python -m pip install mlx-lm

~/mlx-service/.venv/bin/python -m mlx_lm.server \
  --model ~/models/quantized-model \
  --host 127.0.0.1 --port 8080
curl http://127.0.0.1:8080/v1/models

Vérifiez que les fichiers du modèle sont complets, que l’environnement Python fonctionne et qu’aucun autre processus n’utilise le port. Les options de mlx-lm peuvent varier selon les versions. Avant le déploiement, référez-vous à l’aide de la commande correspondant à la version installée sur l’instance.

ACCÈS / 01

Donner accès à l’équipe

Par défaut, le service écoute uniquement sur 127.0.0.1. Pour quelques appels internes, chaque membre peut créer son propre tunnel SSH. Pour centraliser l’accès, utilisez un proxy inverse avec authentification, contrôle d’accès et TLS. N’exposez jamais directement sur Internet un endpoint d’inférence non protégé.

ssh -N -L 8080:127.0.0.1:8080 xops-node
DÉMARRAGE / 02

Relancer le service après un redémarrage

Une fois la commande exécutée au premier plan validée, créez une configuration launchd au niveau utilisateur pour le service. Indiquez le chemin Python de l’environnement virtuel, le chemin du modèle, le répertoire de travail et les fichiers journaux. Vérifiez la configuration avant de la charger dans la session utilisateur active ; après le redémarrage de l’instance, contrôlez à nouveau le processus et l’endpoint.

plutil -lint ~/Library/LaunchAgents/com.xcodeops.mlx.plist
launchctl bootstrap gui/$(id -u) \
  ~/Library/LaunchAgents/com.xcodeops.mlx.plist

Repères mémoire : 16GB conviennent aux essais avec de petits modèles quantifiés ; 24GB permettent de valider un service unique avec les modèles quantifiés courants de 7B à 8B ; 64GB offrent plus de marge pour les modèles volumineux ou plusieurs tâches. Le débit réel dépend du modèle, du contexte et de la charge : mesurez-le avec vos propres requêtes.

05 / DÉVELOPPEMENT ET LIVRAISON

Gardez les builds Xcode sur le nœud et les tests sur appareils réels dans un processus maîtrisé

Un Mac physique dédié convient aux compilations Xcode, aux tests sur simulateur et aux runners auto-hébergés : sur cette machine, le CPU, le GPU et la mémoire unifiée ne sont pas partagés avec les tâches d’autres clients. Mais la réussite d’un test sur simulateur ne garantit pas celle des essais de caméra, de Bluetooth ou de performances sur un appareil réel.

Matrice de simulateurs

Fixez les versions de Xcode et des runtimes de simulateur, puis établissez une matrice de test couvrant les tailles d’écran et les versions du système importantes. Commencez par exécuter xcrun simctl list devices available pour vérifier les appareils réellement disponibles et éviter qu’une pipeline ne fasse référence à un runtime non installé.

À vérifier : version / appareil / rapport de test

Archivage et distribution

Commencez par faire exécuter au runner les tests déterministes et l’archivage, puis téléversez le build TestFlight en suivant le processus de signature déjà utilisé par votre équipe. Stockez les certificats, profils de provisioning et identifiants de téléversement dans un espace contrôlé ; ne les ajoutez ni au dépôt ni aux journaux de build conservés.

À vérifier : signature / archivage / résultat du téléversement

Limites des tests sur appareil réel

Les scénarios impliquant des capteurs, le changement de réseau réel, la consommation d’énergie ou des accessoires doivent toujours être vérifiés sur des appareils réels contrôlés par l’équipe. Le nœud cloud peut gérer les builds et leur distribution ; les appareils locaux servent ensuite aux tests de régression finaux et à la reproduction des problèmes.

À vérifier : journaux de l’appareil / étapes de reproduction
06 / NŒUDS ET RÉSEAU

Mesurez la connexion aux quatre nœuds avant de choisir où exécuter vos tâches

Singapour, Tokyo, Séoul et Hong Kong sont disponibles. L’emplacement des membres de l’équipe, le routage des opérateurs et la congestion aux heures de pointe influent sur l’expérience réelle. Pour une API d’inférence, mesurez aussi le temps aller-retour des requêtes et le temps de génération du modèle ; le ping seul ne suffit pas.

Mesures indicatives des connexions en Asie-Pacifique

Le tableau ci-dessous présente des mesures de référence en millisecondes, obtenues selon le protocole indiqué. Elles ne garantissent pas la latence en temps réel de votre connexion. Répétez les mesures sur votre propre réseau avant de choisir un nœud.

Latence moyenne aller-retour ICMP indicative, en millisecondes, entre huit villes d’origine et les nœuds de Singapour, Tokyo, Séoul et Hong Kong
Ville d’origineSingapourTokyoSéoulHong Kong
Shanghai76 ms58 ms53 ms41 ms
Shenzhen62 ms72 ms65 ms29 ms
Taipei64 ms46 ms54 ms39 ms
Bangkok43 ms109 ms98 ms66 ms
Jakarta38 ms109 ms115 ms74 ms
Sydney101 ms132 ms146 ms141 ms
Osaka75 ms32 ms47 ms65 ms
Busan85 ms44 ms24 ms71 ms

Protocole : moyenne du temps aller-retour ICMP, 100 mesures consécutives par connexion, en soirée un jour ouvré, via une connexion Internet résidentielle. Ces résultats servent uniquement à présélectionner un nœud. Ils varient selon l’opérateur et le réseau et ne remplacent pas un test de l’instance réelle depuis votre lieu de travail.

01 / CHOIX DU NŒUD

Mesurez depuis le principal lieu d’utilisation de l’équipe

Commencez par envoyer des ping continus vers l’instance réelle, puis vérifiez les pertes de paquets et la gigue. Si votre équipe est répartie dans plusieurs régions, prenez comme référence principale les personnes qui utilisent le plus souvent le bureau à distance ou l’API d’inférence, plutôt que la ville géographiquement la plus proche.

02 / SYNCHRONISATION

Évitez les heures de pointe pour les gros fichiers

Les poids de modèles, les ressources multimédias et les caches de build se prêtent à une synchronisation incrémentielle. Planifiez les transferts volumineux en dehors des heures de pointe et reprenez-les en cas d’échec. Si VNC est saccadé, vérifiez aussi qu’une synchronisation en arrière-plan ne sature pas le débit montant.

03 / MISE À L’ÉCHELLE

Envisagez plusieurs machines selon la charge

Le couplage de plusieurs machines avec Thunderbolt 5 convient aux besoins réels de collaboration entre plusieurs machines, à condition que le workflow applicatif puisse en tirer parti. Il ne fusionne pas automatiquement la mémoire unifiée de plusieurs machines en un seul pool utilisable par un modèle. Vérifiez l’architecture logicielle avant de configurer cette solution.

07 / DÉPANNAGE ET ASSISTANCE

Fournissez les étapes pour reproduire le problème : c’est plus efficace que de dire simplement « impossible de se connecter »

Pour les problèmes liés à une instance ou à une commande, ouvrez un ticket depuis la console. Avant de l’envoyer, vérifiez votre réseau local, l’état de l’instance, le mode de connexion et l’heure d’apparition du problème. N’incluez jamais de clé privée, de jeton complet ni de données sensibles non masquées dans les captures d’écran ou les journaux.

Les quatre informations à fournir

  • 01Commande et nœudNuméro de commande, nœud associé à l’instance — Singapour, Tokyo, Séoul ou Hong Kong — et service concerné.
  • 02Action et erreurCommande exécutée, message d’erreur complet, étapes ayant mené au problème et capture d’écran expurgée si possible.
  • 03Date et périmètreHeure de la première occurrence, caractère continu ou intermittent du problème et éventuelles personnes de l’équipe concernées.
  • 04Vérifications effectuéesRésultats des vérifications de l’état de l’instance, des permissions de la clé, du port, du tunnel et du réseau local.

Que faire ensuite ?

Connectez-vous à la console et ouvrez un ticket depuis la commande ou l’instance concernée, en joignant les éléments de diagnostic. Pour une question sur le choix d’une configuration avant commande, écrivez à support@xcodeops.com. Pour un problème concernant une instance existante, privilégiez le ticket afin que l’équipe puisse le relier à la commande et au nœud.

Ouvrir un ticket dans la console Consulter la FAQ
PRÊT À DÉPLOYER

Choisissez un nœud et lancez votre première commande

Trois configurations de Mac mini physique dédié, facturées à la journée, à la semaine, au mois ou au trimestre. Choisissez d’abord un modèle, puis un nœud en fonction de vos mesures réseau. Une fois la machine livrée, suivez les étapes de connexion de ce guide.

Louer un Mac mini Comparer les modèles et les prix