Avancer par tâche

Préparer, connecter, exécuter, puis diagnostiquer

Il ne s’agit pas d’une liste de commandes isolées. Vérifiez d’abord la commande et le nœud dans la console, établissez ensuite la connexion et reproduisez la chaîne d’outils, puis validez la tâche avec des journaux conservables. Convient au NowMini M4 avec 16GB de RAM et 256GB SSD, sur un nœud physique dédié.

Louer un Mac dans le cloud Voir les étapes de connexion

4 types de tâches: Préparer, connecter, exécuter, diagnostiquer
4 nœuds: Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong
1 configuration: Nœud physique dédié NowMini M4

Parcours vérifiables

Une fiche d’exécution facile à transmettre

Chaque étape conserve les entrées, les actions et les résultats de validation. En cas d’anomalie, inutile de repartir de zéro.

01
Préparer l’environnement Commande, région, identifiants, origine de l’accès
02
Connecter le nœud SSH, session graphique, empreinte de l’hôte
03
Exécuter les tâches Xcode, runner, MLX, archivage des artefacts
04
Diagnostiquer les problèmes Chronologie, étapes de reproduction, journaux expurgés

Trouver rapidement

Commencez par décrire la tâche en cours

Saisissez des termes comme « Xcode », « SSH », « runner » ou « disque » : la page conservera les étapes pertinentes. Vous pouvez aussi choisir directement un point d’entrée ci-dessous.

Première activation

Effectuez six vérifications avant la connexion

Ne mélangez pas confirmation de commande, autorisation réseau et initialisation du système lors d’une même connexion. Notez les résultats dans l’ordre pour localiser rapidement la cause d’un échec d’authentification.

Liste de vérification de l’activation

De la console à la première session

Fiez-vous aux informations de commande et de nœud renvoyées en temps réel par la console. Ne copiez pas l’adresse de l’hôte depuis un ancien ticket ou une conversation d’équipe.

Confirmer l’identifiant de commande

Notez l’identifiant de commande, la durée de location et la configuration NowMini M4 afin de vérifier que vous travaillez sur la bonne commande.

Vérifier la région du nœud

Confirmez Singapour, Japon (Tokyo), Corée du Sud (Séoul) ou Hong Kong, et utilisez le même nom de région dans toute l’équipe.

Lire les identifiants système

Vérifiez le nom d’utilisateur, l’adresse de l’hôte et les exigences relatives aux clés. Stockez les identifiants uniquement dans un coffre-fort contrôlé, jamais dans un dépôt de code.

Confirmer l’origine de l’accès

Notez le réseau professionnel, la sortie fixe ou l’adresse d’origine du runner. Évitez la première initialisation depuis un réseau public inconnu.

Établir la première connexion

Vérifiez d’abord l’accessibilité réseau, puis l’empreinte de l’hôte et les autorisations de la clé. Ne modifiez pas plusieurs variables à la fois avant de réessayer.

Initialiser le compte

Créez un environnement doté des autorisations minimales nécessaires, définissez les répertoires de travail et de journaux, puis conservez une trace de validation exempte de secrets.

Validation du matériel

Vérifiez le M4, les 16GB de RAM et le SSD de base de 256GB. Si la commande inclut une extension de stockage, contrôlez séparément l’espace disponible et le point de montage.

Validation de la session

Notez séparément si les sessions SSH et graphiques s’établissent, le temps de la première connexion, ainsi que le fonctionnement du clavier et du presse-papiers.

Ouvrir les instructions de connexion

Environnement de développement

Reproduisez la chaîne d’outils en respectant les dépendances

Commencez par figer les versions des outils, puis ajoutez les identifiants, le cache et les éléments de signature. Inverser cet ordre fait souvent passer un problème de version pour un problème d’autorisation.

Étape 1

Figer la chaîne d’outils Xcode

Vérifiez d’abord le répertoire développeur sélectionné, puis notez les versions de Xcode et du SDK. La chaîne CI doit traiter la version comme une entrée de build, et non dépendre d’un choix interactif.

Vérifier le chemin des outils en ligne de commande
Noter les versions du compilateur et du SDK
Effectuer un build de référence avec un projet minimal

Étape 2

Configurer les identifiants Git

Configurez une clé dédiée pour le nœud ou le compte d’automatisation, avec uniquement les droits requis sur le dépôt. Après le premier clonage, notez l’adresse distante, la branche et le commit de référence.

Vérifier les permissions du fichier de clé
Vérifier les limites de lecture et d’écriture du dépôt
Éviter d’exposer des secrets dans les paramètres des scripts

Étape 3

Séparer les dépendances et le cache

Séparez les dépendances reconstructibles, le cache de compilation et les artefacts finaux. La clé du cache doit au minimum inclure la version des outils, le résumé du fichier de verrouillage et la plateforme cible.

Figer le résultat de la résolution des dépendances
Limiter la croissance du répertoire de cache
Conserver une méthode de build de référence après vidage du cache

Étape 4

Importer les éléments de signature en dernier

Importez les certificats, profils de provisionnement et informations de déverrouillage après validation de la chaîne d’outils. Utilisez un répertoire contrôlé et supprimez les copies temporaires à la fin de la tâche.

Noter la portée de validité des certificats
Limiter les entités autorisées à accéder au trousseau
Vérifier la chaîne de signature avec une tâche d’archivage

Critères de validation

Un même commit doit pouvoir résoudre les dépendances, compiler, tester et archiver dans un répertoire de travail propre. En cas d’échec, les journaux doivent indiquer l’étape précise, et non seulement « échec du build ».

Intégration CI/CD

Intégrez le nœud physique à votre file existante

Le runner est un point d’exécution : il ne doit pas servir simultanément de coffre-fort à secrets, de dépôt d’artefacts à long terme et de répertoire partagé. Définissez d’abord les répertoires et les droits avant d’augmenter la concurrence.

Chaîne d’exécution

Cinq étapes, une chronologie auditable

Chaque tâche doit au minimum consigner le commit, le runner, l’heure de début, l’état final et l’emplacement des artefacts. Le nœud fonctionne normalement 365 jours par an.

Enregistrer le runner

Utilisez un compte d’automatisation dédié pour enregistrer l’exécuteur. Les étiquettes doivent décrire le système et les capacités de la tâche, sans inclure de secrets ni de noms personnels.

Isoler le répertoire de travail

Utilisez un chemin de travail distinct pour chaque pipeline. Supprimez les fichiers temporaires à la fin de la tâche afin d’éviter qu’un build en contamine un autre.

Définir la stratégie de cache

Nommez le cache selon le fichier de verrouillage et la version des outils, fixez une limite de capacité et conservez le parcours d’exécution complet en cas de cache manquant.

Renvoyer les artefacts de build

Renvoyez les archives, fichiers de symboles et rapports de test vers le stockage existant de l’équipe. Le répertoire de travail du nœud ne doit pas être l’unique copie.

Conserver les journaux d’échec

Conservez l’étape en échec, le code de sortie et le contexte clé. Avant de contacter l’assistance, retirez les jetons, clés et éléments de signature.

Contrôle de la concurrence

Établissez d’abord une référence avec une seule tâche, puis augmentez progressivement la concurrence de la file. Avec 16GB de RAM, séparez les tests, l’archivage et l’inférence selon les pics réels des tâches.

Limites des nouvelles tentatives

Ne relancez que les étapes récupérables, comme une brève coupure réseau. Conservez le résultat original en cas d’échec de compilation, de test ou de signature afin de ne pas écraser la première erreur.

Vérification des artefacts

Après le retour, vérifiez la taille, le résumé et l’identifiant de tâche des fichiers. L’équipe doit pouvoir relier chaque artefact au commit et à l’environnement de build correspondants.

Expérimentation MLX

Validez d’abord l’environnement, puis augmentez les tâches d’inférence

NowMini M4 convient aux petites expériences MLX reproductibles. Séparez les fichiers de modèle, les paramètres d’exécution et les résultats pour faciliter le nettoyage et la relance.

MLX CHECKPOINTS NOWMINI M4

Validation de l’environnement

Notez les versions de Python, MLX et des dépendances clés, puis vérifiez l’exécution avec de petites opérations sur des tenseurs.

Emplacement des modèles

Placez les fichiers de modèle dans un répertoire de données dédié et vérifiez leur résumé. Ne les mélangez ni au dépôt source ni au cache temporaire.

Exécution de la tâche

Figez le modèle, les entrées, les paramètres d’échantillonnage et la graine aléatoire. Commencez par un petit lot, puis surveillez la mémoire et la stabilité des sorties.

Surveillance des ressources

Consignez le pic de mémoire, la croissance du disque, la durée d’exécution et l’état de sortie afin d’éviter que les journaux ou résultats intermédiaires ne saturent l’espace.

Que conserver au minimum pour une expérience

Entrées: Identifiant du modèle, résumé du fichier, invite ou version du jeu de données
Environnement: Système, Python, MLX et versions des dépendances
Paramètres: Taille du lot, longueur générée, paramètres d’échantillonnage
Résultats: Durée d’exécution, pic de ressources, résumé de sortie, état de sortie

Limites de stockage

La configuration de base inclut un SSD de 256GB. Vérifiez l’espace disponible avant de télécharger un modèle. Les grands modèles, résultats intermédiaires et poids multiples doivent être inclus dans le plan de nettoyage ou dans une extension de stockage choisie lors de la commande.

Voir la configuration et le stockage

Arbre de diagnostic

Commencez par les conditions aux limites, sans modifier les paramètres au hasard

Déterminez d’abord si le problème concerne le réseau local, le contrôle d’accès, l’authentification, la chaîne d’outils ou les ressources. Ne changez qu’une variable à la fois et notez le résultat.

Impossible de se connecter au nœud : quelle couche vérifier en premier ?

Vérifiez que le réseau local peut accéder aux services externes, puis retestez après avoir désactivé tout proxy temporaire modifiant le routage.
Vérifiez à nouveau l’adresse de l’hôte et la région du nœud depuis la console. N’utilisez pas une adresse provenant d’une ancienne capture d’écran.
Confirmez que l’origine actuelle de l’accès respecte les restrictions et vérifiez que le pare-feu local ne bloque pas le port cible.
Consignez séparément les résultats de la résolution DNS, de l’accessibilité réseau et de la négociation du protocole, plutôt que de conclure simplement « impossible de se connecter ».

Échec d’authentification : distinguer le problème d’utilisateur de celui de la clé

Vérifiez que le nom d’utilisateur correspond au nœud actuel. Ne réutilisez pas celui d’un autre serveur.
Vérifiez les permissions et le format du fichier de clé privée, ainsi que le chemin de clé effectivement chargé par le client.
Vérifiez que l’empreinte de l’hôte correspond au premier relevé. En cas de changement, interrompez la connexion et ouvrez un ticket pour vérification.
Activez les journaux détaillés du client, conservez la négociation des méthodes d’authentification et l’étape de refus par le serveur, puis retirez les données sensibles avant l’envoi.

Anomalie de build : commencer par les versions, les dépendances ou la signature ?

Vérifiez d’abord que Xcode, le SDK et le chemin des outils en ligne de commande correspondent à la référence.
Dans un répertoire propre, résolvez à nouveau les dépendances verrouillées afin de déterminer si le cache est en cause.
Séparez les problèmes de compilation et de signature : terminez d’abord un build ne nécessitant pas de signature de distribution, puis validez l’archivage.
Conservez la première erreur et son contexte, sans extraire uniquement le résumé situé en fin de journal.

Espace disque insuffisant : quels répertoires vérifier en priorité ?

Notez la capacité totale, l’espace utilisé et l’évolution entre le début et la fin de la tâche. Ne supprimez pas immédiatement tous les fichiers.
Vérifiez successivement les caches de build, archives, résultats de test, modèles téléchargés et répertoires de journaux à croissance continue.
Après confirmation du retour des artefacts, nettoyez les copies présentes sur le nœud afin de ne pas supprimer l’unique fichier récupérable.
Définissez des limites de capacité pour le cache et les journaux, et intégrez le nettoyage au processus de fin de tâche.

Dépassement de délai : distinguer un traitement lent d’un blocage

À partir de la dernière ligne de journal valide, déterminez si la tâche calcule encore, attend le réseau ou attend un sous-processus.
Vérifiez si d’autres tâches sur le même nœud utilisent la mémoire, le disque ou le verrou du répertoire de travail.
Définissez des délais distincts pour le téléchargement, le build, les tests et l’envoi. N’utilisez pas un délai global pour toutes les étapes.
Avant une nouvelle tentative, sauvegardez l’état du processus et les journaux d’échec. Si le problème est reproductible, joignez la tâche minimale au ticket.

Rapport de diagnostic

Un diagnostic exploitable doit contenir cinq informations

Heure de l’incidentAvec le fuseau horaire
Région du nœudL’un des quatre nœuds disponibles à la vente
Étapes opératoiresReproductibles
Attendu et réelDécrire l’écart
Journaux expurgésConserver le contexte de l’erreur

Bonnes pratiques de sécurité

Intégrez les autorisations au cycle de vie des tâches

Les identifiants ne sont pas des fichiers configurés une fois pour toutes. Lorsque les personnes, le runner, l’origine réseau ou le projet changent, revérifiez les limites d’accès.

Faire tourner les identifiants

Effectuez immédiatement une rotation après un changement de membre, un doute sur une fuite de clé ou une modification du compte d’automatisation. Désactivez les anciens identifiants avant de valider les nouveaux afin d’éviter plusieurs accès inconnus simultanés.

Limiter les origines d’accès

Privilégiez une sortie fixe identifiable. Révoquez les accès temporaires à la fin de la tâche et consignez l’auteur, le motif et le résultat de la révocation.

Réduire les autorisations de l’automatisation

Le runner utilise un compte et une clé dédiés, avec accès uniquement au dépôt cible, au répertoire de travail et à l’emplacement des artefacts. Ne faites pas hériter les scripts de build des droits personnels permanents.

Nettoyer lors d’une migration ou d’un transfert

Renvoyez d’abord le code source, les modèles et les artefacts, puis supprimez les certificats temporaires, clés, caches et journaux contenant des champs sensibles. Le destinataire effectue une nouvelle validation à l’aide de la liste de contrôle.

Critères d’un transfert terminé

Le nouveau responsable peut se connecter avec ses propres autorisations, exécuter la tâche de référence et lire les journaux. Les identifiants de l’ancien responsable sont révoqués et aucun compte temporaire ni secret orphelin ne subsiste sur le nœud.

Assistance humaine

Présentez un problème sous forme de ticket immédiatement exploitable

Pour une commande existante, ouvrez en priorité un ticket depuis la console. Pour une demande avant-vente, l’évaluation d’un workflow à grande échelle ou un problème de connexion, vous pouvez envoyer un e-mail. Ce sont les deux seuls canaux de contact externes.

Champs du ticket

Préparez six éléments avant l’envoi

Plus les informations se rapprochent des conditions de reproduction, plus le diagnostic peut commencer directement, sans devoir reconfirmer les faits de base.

Identifiant de commande: Identifiant de la commande actuelle affiché dans la console
Région du nœud: Singapour, Japon (Tokyo), Corée du Sud (Séoul) ou Hong Kong
Heure de l’incident: Indiquer la date, l’heure et le fuseau horaire
Étapes de reproduction: Séquence d’actions entre l’état normal et l’apparition de l’erreur
Résultat réel: Texte de l’erreur, code de sortie ou comportement anormal
Journaux expurgés: Conserver le contexte et retirer mots de passe, clés et jetons

Ne transmettez aucun élément sensible

N’ajoutez pas de mots de passe, clés privées, informations de paiement complètes, éléments de signature ni jetons donnant directement accès à un dépôt de code dans vos tickets ou e-mails.

Problème concernant une commande existante

Connectez-vous à la console pour ouvrir un ticket et associer le problème à la commande et au nœud. Convient aux problèmes de connexion, de facturation, d’état du nœud et de tâches existantes.

Ouvrir un ticket depuis la console

Avant-vente et aide à la connexion

Envoyez un e-mail à support@nowmini.com en précisant le workflow, la région cible, la durée de location prévue et le problème reproductible. L’adresse e-mail peut s’afficher sur plusieurs lignes.

Envoyer un e-mail à support@nowmini.com

Étape suivante

Une fois la configuration définie, commencez immédiatement

Choisissez un nœud physique dédié NowMini M4 pour exécuter vos builds, automatisations et tâches MLX à Singapour, au Japon (Tokyo), en Corée du Sud (Séoul) ou à Hong Kong. La disponibilité réelle est indiquée en temps réel dans la console.

Louer NowMini M4 maintenant Contacter l’équipe