Du choix du nœud à la première tâche

Déployez votre première tâche MLX ou CI sur un Mac cloud

Ce guide s’adresse aux développeurs et équipes d’ingénierie qui souhaitent louer un VMMini M4. Vous vérifierez votre charge de travail, comparerez les quatre nœuds disponibles, créerez votre commande, vous connecterez, puis lancerez un service d’inférence MLX ou un self-hosted runner.

VMMini M4 est un nœud physique dédié équipé d’un Mac Mini M4, de 16GB de RAM et d’un SSD de 256GB, et non une machine virtuelle. Les nœuds fonctionnent 365 jours par an ; les performances réseau, la disponibilité et les informations de livraison sont celles affichées en temps réel dans la console.

1configuration fixe
4nœuds disponibles
2parcours pour la première tâche
Feuille de déploiement VMMini M4
Disponible au catalogue
Processeur
M4
Mémoire
16GB
Disque système
256GB SSD
Nœuds
Singapour, Tokyo, Séoul et Hong Kong
Sorties de tâche
MLXContrôle de santé réussi
CIrunner prêt à recevoir des tâches
Préparer le démarrage

Clarifiez les sept éléments avant de créer la commande

Le nœud, la durée et le stockage déterminent directement votre mode d’utilisation après livraison. Préparez une courte fiche de tâche pour éviter de découvrir après connexion que le dépôt est trop éloigné, que le disque est insuffisant ou que l’équipe ne dispose pas de clé publique utilisable.

01

Définir l’objectif

Précisez si la première tâche concerne l’inférence MLX, le déploiement IA sur Mac, une compilation iOS/macOS ou l’automatisation à distance. Notez la durée, le mode de concurrence et les livrables finaux.

02

Indiquer la localisation de l’équipe

Listez les régions où se trouvent les principaux opérateurs. En cas de collaboration, ne tenez pas compte uniquement de l’administrateur : considérez aussi les personnes qui consulteront les journaux et récupéreront les livrables.

03

Confirmer l’emplacement des sources de code

Notez le réseau où se trouvent le dépôt, les fichiers de modèles, le cache des dépendances et le stockage des artefacts. Le point d’entrée des données influence souvent davantage le choix du nœud que la localisation de l’équipe.

04

Choisir la durée de location

Une validation courte peut se faire à la journée, un sprint continu à la semaine, et une compilation ou un service stable au mois ou au trimestre. La durée doit couvrir le déploiement, la validation et l’export des données.

05

Estimer la capacité de stockage

Additionnez les poids des modèles, le cache des dépendances, les répertoires de compilation, les artefacts archivés et les journaux. N’estimez pas le disque système à partir de la seule taille du dépôt.

06

Préparer la clé publique SSH

Utilisez une clé distincte pour cette tâche et vérifiez que la clé privée est conservée par des personnes autorisées. Envoyez la clé publique uniquement ; ne transmettez jamais la clé privée par e-mail ou ticket.

07

Confirmer l’adresse e-mail de réception

Utilisez une adresse professionnelle capable de recevoir durablement les notifications de commande et de service, et assurez-vous que le responsable de la livraison peut y accéder. Mettez à jour le contact interne avant le transfert de la tâche.

Étape 1 · Choisir un nœud

Choisissez selon le parcours des données, pas selon le nom de la ville

VMMini M4 est actuellement disponible à Singapour, au Japon (Tokyo), en Corée du Sud (Séoul) et à Hong Kong. Les quatre options du catalogue peuvent être commandées ; la disponibilité réelle est celle affichée en temps réel dans la console.

SG Disponible

Singapour

Convient aux tâches dont la source de code, l’équipe ou les utilisateurs du service se trouvent en Asie du Sud-Est. Avant de récupérer de grands modèles ou dépendances depuis une autre région, testez le parcours de téléchargement réel plutôt que de vous limiter au ping.

À vérifier en priorité
Connectivité vers l’Asie du Sud-Est
Idéal pour tester
Téléchargement de modèles, accès API et envoi d’artefacts
JP Disponible

Japon (Tokyo)

Convient aux tâches de compilation dont les dépendances et les collaborateurs principaux se trouvent au Japon ou en Asie de l’Est. Si le pipeline télécharge souvent des dépendances, mesurez à la fois la latence du premier paquet et le débit soutenu.

À vérifier en priorité
Sources de code et registres d’artefacts d’Asie de l’Est
Idéal pour tester
Clonage du dépôt, restauration du cache et consultation des journaux
KR Disponible

Corée du Sud (Séoul)

Convient aux tâches dont l’équipe ou la chaîne de livraison se trouve en Corée du Sud et en Asie du Nord-Est. Si les artefacts de compilation sont envoyés en continu, ajoutez un test de transfert de fichiers réel.

À vérifier en priorité
Accès de l’équipe en Asie du Nord-Est
Idéal pour tester
Opérations à distance, envoi d’artefacts et vérification du service
HK Disponible

Hong Kong

Convient aux tâches dont les opérateurs principaux, la source de code ou le parcours métier se trouvent dans le sud de la Chine ou en Asie du Sud-Est. Les accès interrégionaux restent soumis aux variations des opérateurs et du routage locaux.

À vérifier en priorité
Parcours vers le sud de la Chine et l’Asie du Sud-Est
Idéal pour tester
Allers-retours SSH, synchronisation du code et téléchargement d’artefacts
A

Tâches interactivesObservez en priorité la réactivité des entrées SSH, l’actualisation des journaux et le transfert de petits fichiers.

B

Tâches de compilationObservez en priorité le clonage du dépôt, le téléchargement des dépendances, la restauration du cache et l’envoi des artefacts.

C

Service d’inférenceObservez en priorité la préparation du modèle, le parcours réel des requêtes du client au serveur et la stabilité dans la durée.

Référence de latence des nœuds

Utilisez la médiane pour un premier tri, puis retestez avec votre propre réseau

Le tableau indique les temps aller-retour ICMP entre plusieurs villes de test et les quatre nœuds disponibles. Il aide à écarter les parcours manifestement inadaptés, mais ne remplace pas les tests réels du dépôt, de la source des modèles, du registre d’artefacts et du parcours utilisateur final.

Période de testJours ouvrés, 10:00–12:00 (UTC+8)
Fournisseur réseauConnexion haut débit professionnelle locale standard
Nombre d’échantillons30 par parcours
Méthode statistiqueMédiane des échantillons valides
Médiane du ping entre les villes de test principales et les nœuds de Singapour, Tokyo, Séoul et Hong Kong
Ville du point de test Nœud de Singapour Nœud de Tokyo Nœud de Séoul Nœud de Hong Kong
Point de test de Shanghai 79 ms 48 ms 52 ms 36 ms
Point de test de Shenzhen 47 ms 66 ms 61 ms 24 ms
Point de test de Taipei 58 ms 39 ms 45 ms 31 ms
Point de test de Bangkok 33 ms 92 ms 99 ms 56 ms
Comment retester

Depuis les réseaux habituellement utilisés par l’équipe, exécutez plusieurs séries de ping et répétez-les pendant les heures prévues. Clonez ensuite un dépôt de taille comparable, téléchargez des dépendances ou un modèle, puis envoyez un artefact représentatif.

Comment interpréter les résultats

Une faible médiane ne garantit pas une stabilité durable. Observez également les pertes de paquets, les variations, le débit de téléchargement et les changements aux heures de pointe. Ces résultats servent uniquement au premier choix du nœud et ne constituent pas une garantie de performances continues.

Étape 2 · Créer une commande

Configuration fixe : choisissez d’abord le nœud et la durée, puis les options

Une seule configuration VMMini M4 est actuellement proposée. La commande doit préciser le nœud physique, la durée de location et les options ; n’attendez pas la soumission pour estimer le stockage ou le nombre d’appareils interconnectés.

Configuration disponible

VMMini M4

Mac Mini M4 · 16GB RAM · 256GB SSD

Créer une commande VMMini M4
Par jour $20.5 Pour les validations courtes et les tâches ponctuelles
Par semaine $55.4 Pour les sprints de publication et les compilations intensives
Par mois $102.6 Pour les pipelines stables et les expérimentations continues
Par trimestre $279.1 Pour les projets continus et les environnements d’exécution fixes
01
Choisir le nœud

Choisissez uniquement Singapour, Tokyo, Séoul ou Hong Kong et notez la justification de votre choix.

02
Choisir la durée

Créez la commande à la journée, à la semaine, au mois ou au trimestre ; la durée doit inclure le déploiement et l’export des données.

03
Choisir les options

Vérifiez les quantités selon les besoins en modèles, cache, artefacts et appareils interconnectés.

Les options suivent la même durée que la commande

L’extension de stockage et l’interconnexion Thunderbolt 5 ne font pas partie de la configuration de base. Ajoutez-les uniquement si la tâche le nécessite et intégrez leur prix à la durée correspondante dans votre budget.

+1TB SSDExtension de stockage
Jour
$2.4
Semaine
$6.4
Mois
$11.8
Trimestre
$32.1
+2TB SSDExtension de stockage
Jour
$4.8
Semaine
$12.8
Mois
$23.6
Trimestre
$64.2
Interconnexion Thunderbolt 5Par appareil
Jour
$1.3
Semaine
$3.4
Mois
$6.3
Trimestre
$17.1
Étape 3 · Régler la commande

Vérifiez le total en USD et les deux modes de paiement

Les prix et le règlement sont indiqués en USD. Avant de payer, vérifiez la durée de base, le nœud, l’extension SSD et le nombre d’interconnexions Thunderbolt 5, puis assurez-vous que le total correspond à votre fiche de tâche.

USDT-TRC20

Effectuez le transfert selon les informations de la commande et vérifiez le réseau, le montant et le statut de la commande.

Visa / Mastercard / Amex

Le paiement par carte est traité par Stripe ; la passerelle réellement disponible est celle affichée dans la console.

Étape 4 · Première connexion

Vérifiez d’abord les informations de livraison, puis installez la chaîne d’outils

La première connexion ne sert pas à lancer immédiatement une tâche, mais à établir une base fiable. Vérifiez d’abord l’empreinte de l’hôte, les informations système, le disque, l’heure, le réseau et les autorisations du compte avant de modifier l’environnement.

  1. 01

    Vérifier l’empreinte de l’hôte

    Comparez caractère par caractère l’empreinte affichée à la connexion avec le relevé de livraison. En cas de divergence, interrompez la connexion et ouvrez un ticket depuis la console.

  2. 02

    Utiliser SSH ou VNC

    Privilégiez SSH pour les tâches en ligne de commande ; utilisez VNC pour observer l’interface graphique macOS. N’ouvrez que les accès indispensables à la tâche.

  3. 03

    Vérifier le système et le disque

    Notez la version de macOS, l’architecture du noyau, la capacité du disque système et l’espace disponible afin d’établir une base pour le dépannage.

  4. 04

    Vérifier l’heure et le réseau

    Vérifiez le fuseau horaire, l’heure système, le DNS, l’accès aux dépendances externes et la connectivité avec la source de code afin d’éviter les problèmes de certificats ou d’horodatage des compilations.

  5. 05

    Vérifier les autorisations du compte

    Vérifiez que le compte actuel ne possède que les autorisations nécessaires à la tâche et séparez les identifiants du projet des identifiants de connexion des personnes.

Checklist de première connexion READ ONLY FIRST
sw_vers
uname -m
df -h /
date
scutil --get TimeZone
networkQuality
whoami
id
Architecture attendue arm64 Méthode de conservation Enregistrer une sortie désensibilisée
Étape 5 · Exécuter la charge de travail

Commencez par une petite tâche vérifiable

Ne lancez pas l’intégralité du processus de production lors de la première exécution. Validez d’abord l’environnement, les journaux, le code de sortie et le chemin des artefacts avec une requête utilisant un petit modèle ou une seule compilation, puis élargissez progressivement la tâche.

Parcours A

Contrôle de santé du service d’inférence MLX

Vérifiez d’abord l’environnement Python et le répertoire du modèle, puis faites écouter le service uniquement sur l’adresse locale. Après validation du contrôle de santé, ouvrez les ports nécessaires selon les appelants réels et la stratégie d’accès.

export MODEL_PATH="/srv/models/current"
export SERVICE_PORT="8080"

python -m mlx_lm.server \
  --model "$MODEL_PATH" \
  --host 127.0.0.1 \
  --port "$SERVICE_PORT"

curl --fail \
  "http://127.0.0.1:${SERVICE_PORT}/v1/models"
  • Consignez la version du modèle, le fichier de verrouillage des dépendances et les paramètres de démarrage.
  • Vérifiez que le contrôle de santé renvoie un état de réussite et l’identifiant de modèle attendu.
  • Placez le jeton d’accès dans une variable d’environnement ou un stockage de clés contrôlé.
  • Conservez les journaux de démarrage, les erreurs et les observations des pics de ressources.
Parcours B

Enregistrer un self-hosted runner

Créez un runner restreint pour un seul projet et configurez-le avec un jeton d’enregistrement à durée limitée. Exécutez d’abord une compilation minimale sans signature ni publication, puis intégrez le pipeline officiel.

export REPOSITORY_URL="$CI_REPOSITORY_URL"
export RUNNER_TOKEN="$CI_RUNNER_TOKEN"

./config.sh \
  --url "$REPOSITORY_URL" \
  --token "$RUNNER_TOKEN" \
  --name "vmmini-m4-runner"

./run.sh
  • Utilisez des répertoires de travail et des périmètres d’identifiants distincts pour chaque projet.
  • Affichez les versions des outils avant la compilation, sans jamais afficher de jeton.
  • Isolez le cache par clé de projet et vérifiez toute contamination après un échec.
  • À la fin de la tâche, révoquez le runner et supprimez les identifiants restants.
0erreur inexpliquée

La première tâche doit fournir un code de sortie clair et des journaux permettant d’identifier la cause.

1enregistrement reproductible

Conservez les versions des dépendances, les commandes, la configuration et les chemins des artefacts.

2types d’identifiants isolés

Gérez séparément les accès des personnes et les identifiants d’automatisation du projet.

Vérifications après livraison

Une tâche réussie ne signifie pas que le déploiement est terminé

Après ces six vérifications, l’équipe dispose d’un environnement récupérable, dépannable et proprement clôturable. Pour chacune, notez un responsable, le résultat de la validation et la condition de la prochaine vérification.

Valider la reprise après redémarrage

Vérifiez que le service, le runner ou le script d’orchestration redémarre comme prévu et notez les étapes nécessitant une intervention manuelle.

Organiser les journaux de tâche

Séparez les journaux d’exécution, les journaux d’erreur et les enregistrements d’audit, désensibilisez-les et définissez une stratégie de capacité et de conservation.

Tester l’export des artefacts

Téléchargez ou envoyez réellement un artefact représentatif, puis vérifiez sa somme de contrôle, ses autorisations, sa destination et la durée du transfert.

Mettre en place la supervision et les alertes

Couvrez au minimum la disponibilité du service, les échecs de tâche, l’espace disque restant et l’état des processus clés, puis vérifiez que les notifications parviennent au responsable.

Documenter le plan de nettoyage des données

Listez le code, les modèles, le cache, les journaux, les copies d’artefacts et les identifiants temporaires à supprimer à la fin de la tâche.

Conserver l’identifiant de commande

Conservez l’identifiant de commande, le nœud, l’heure du problème, les étapes de reproduction et les journaux désensibilisés comme informations minimales pour toute demande d’assistance.

Critère de transfert Un autre ingénieur doit pouvoir, à partir des seuls enregistrements d’exécution, se connecter, reproduire, exporter et terminer la tâche en toute sécurité.
Consulter la documentation d’assistance
Prêt à créer votre première commande

Apportez votre fiche de tâche dans la console et choisissez le nœud selon le parcours réel

Choisissez VMMini M4, un nœud à Singapour, Tokyo, Séoul ou Hong Kong, ainsi qu’une durée à la journée, à la semaine, au mois ou au trimestre. Toutes les commandes sont réglées en USD ; après livraison, établissez d’abord la base de connexion, puis lancez votre première charge de travail.