Guide d’utilisation du Mac dans le cloud

Résolvez vos problèmes d’utilisation par tâche, des champs de commande aux journaux de build

Vous n’avez pas besoin de lire tout le guide avant de commencer. Accédez à la section correspondant à votre tâche et vérifiez successivement la durée, le nœud, les informations de connexion, l’environnement de développement et les journaux. Si le problème persiste, transmettez le contexte complet dans un ticket depuis la console.

Louer un Mac dans le cloud Consulter le guide de démarrage rapide

5 types de tâches 2 offres disponibles 5 nœuds disponibles

RUN SHEET

Ordre des vérifications initiales

Prêt à démarrer

Vérifier la commande Modèle, durée, nœud et stockage supplémentaire

ORDER

Confirmer la connexion Adresse, compte, réseau local et identifiants

ACCESS

Préparer la chaîne d’outils Xcode, outils en ligne de commande, dépendances et cache

BUILD

Conserver les éléments de diagnostic Heure, message d’erreur complet et journaux anonymisés

TRACE

Nœud physique Apple Silicon dédié 365 DAYS

Commencer selon votre tâche

Dites-nous à quelle étape vous êtes bloqué

Saisissez une tâche, un champ d’état ou un symptôme d’erreur : les résultats vous orienteront directement vers la checklist correspondante. Vous pouvez aussi commencer par l’une des cinq catégories, sans suivre l’ordre des chapitres.

Champs de commande et d’instance

Vérifiez d’abord ce que définit la commande, puis déterminez si l’instance présente un problème

La commande définit la puce, la mémoire, le stockage, le nœud et la durée de location. Les champs d’état de la console décrivent la phase actuelle de livraison ou d’exécution : ne les confondez pas. La disponibilité réelle des combinaisons affichées dans le catalogue dépend des informations en temps réel de la console.

Vérification de la commande

Cinq groupes de champs à vérifier un par un

ORDER PROFILE

Durée de location: Facturation à la journée, à la semaine, au mois ou au trimestre. Vérifiez la période actuelle et la durée du projet ; ne mélangez pas les montants de périodes différentes dans un même budget.
Nœud physique: 5 nœuds : Singapour, Japon (Tokyo), Corée du Sud (Séoul), Hong Kong et est des États-Unis. Tenez compte en priorité du chemin d’accès de l’équipe, de l’emplacement du code source et du flux de données.
Configuration de base: ArmVMS M4 : M4, 16 Go de RAM, SSD de 256 Go ; ArmVMS Pro (M4 Pro) : M4 Pro, 64 Go de RAM, SSD de 2 To.
Options supplémentaires: Vérifiez séparément le SSD de +1 To, le SSD de +2 To ou la connexion Thunderbolt 5 en parallèle, et confirmez que les options figurent dans la même période de commande que la configuration de base.
Mode de règlement: USDT-TRC20 et Visa / Mastercard / Amex (via Stripe) uniquement ; règlement intégral en dollars américains (USD). Les passerelles effectivement disponibles sont indiquées par le backend.

États courants

En traitement et prêt à se connecter

« En traitement » signifie généralement que les informations de la commande suivent encore le processus de livraison ; « Prêt à se connecter » indique que les informations de connexion ont été générées. Après un changement d’état, actualisez les détails de la commande avant d’utiliser les champs de connexion les plus récents.

Principe de diagnostic

Une commande correcte ne signifie pas que l’environnement est prêt

Même si la configuration et le nœud sont corrects, vérifiez le compte système, l’espace disque disponible, la version de Xcode et les dépendances du projet. Ne recréez pas une commande pour résoudre un problème d’environnement.

Vérifier la configuration et le prix

Champs courants de la console et contrôles à effectuer
Champ	Signification	À vérifier	À noter en cas d’écart
ORDER ID	Identifiant unique associé à la commande	Le ticket, la facture et l’instance utilisent-ils le même numéro ?	Numéro complet de la commande
REGION	Région du nœud physique	Correspond-elle au nœud choisi lors de la commande ?	Code du nœud et nom affiché
TERM	Période de location actuelle	Jour, semaine, mois ou trimestre, avec les informations de début et de fin	Nom de la période et capture de la commande
ACCESS	Les informations de connexion ont-elles été générées ?	Adresse, compte et mode de connexion sont-ils complets ?	Nom des champs manquants
STATE	Phase actuelle d’exécution de l’instance	L’état change-t-il après actualisation ? La connexion est-elle rétablie ?	Texte exact de l’état et heure d’apparition

Documentation de l’environnement de développement

Rendez le build reproductible avant de chercher à l’accélérer

Lors de la migration vers un Mac dans le cloud, commencez par rétablir la cohérence de la chaîne d’outils, des dépendances et des chemins du projet. Ne copiez pas tout l’ancien environnement d’emblée : reconstruisez-le à partir d’une checklist pour réduire les incompatibilités d’architecture, les anciens chemins résiduels et la contamination du cache.

Préparer le projet Xcode

Notez la version majeure de Xcode requise, le projet ou l’espace de travail, le Scheme de build, la plateforme cible et la version minimale du système. Lors de la première ouverture, résolvez d’abord les dépendances, puis lancez un build complet.

Vérifiez que les fichiers du projet et les sous-modules sont complets
Vérifiez que le Scheme peut être utilisé pour un build en ligne de commande
Vérifiez séparément la configuration de signature et la version du code

Outils en ligne de commande

Confirmez d’abord le répertoire développeur sélectionné, puis vérifiez le compilateur, les outils de contrôle de version et l’interpréteur de scripts. Les tâches automatisées doivent afficher les chemins et versions réellement utilisés afin d’éviter que les sessions interactives et les exécuteurs n’utilisent des environnements différents.

Notez le résultat de la sélection Xcode actuelle
Vérifiez que les fichiers d’initialisation du shell ne bloquent pas l’exécution interactive
Utilisez des chemins explicites ou des variables d’environnement contrôlées dans les scripts

Gestion des dépendances

Restaurez en priorité les dépendances à partir des fichiers de verrouillage et de l’inventaire logiciel. Après l’installation, vérifiez l’architecture Apple Silicon, la source des binaires et le chemin de résolution des commandes ; ne supposez pas que les fichiers précompilés de l’ancien environnement restent compatibles.

Conservez les fichiers de verrouillage des dépendances et les journaux d’installation
Vérifiez que les scripts ne contiennent pas en dur les anciens répertoires de la machine
Placez les identifiants des dépendances privées dans des variables contrôlées

Cache de build

Le cache ne doit conserver que des données reconstructibles. Validez d’abord la base avec un build sans cache, puis restaurez progressivement le cache des dépendances et les données dérivées. En cas d’écart de compilation inexpliqué, nettoyez en priorité le cache de la tâche actuelle plutôt que toutes les données du projet.

Distinguez le cache des dépendances, le cache de compilation et les artefacts finaux
Incluez les versions de la chaîne d’outils et des dépendances dans la clé de cache
Vérifiez régulièrement la taille du cache et l’espace disque disponible

Intégration CI/CD

Utilisez l’exécuteur comme un nœud physique auditable

Une tâche automatisée doit indiquer qui l’a déclenchée, quelle version du code elle utilise, quels identifiants elle lit, quels artefacts elle produit et ce qu’elle nettoie à la fin. Les ressources dédiées réduisent la concurrence, mais ne remplacent pas le contrôle des permissions du pipeline.

01

Injecter le minimum d’identifiants

Séparez les identifiants par dépôt, source de dépendances et cible de distribution, en accordant uniquement les permissions nécessaires à la tâche. Transmettez-les via des variables contrôlées, sans les écrire dans le dépôt, les scripts de build ou les journaux.

CREDENTIALS
02

Figer le contexte d’exécution

Enregistrez le commit, la branche, le Scheme, la plateforme cible, la version de Xcode et le résumé des dépendances. Les tâches parallèles doivent utiliser des répertoires de travail distincts pour éviter l’écrasement mutuel des données dérivées.

CONTEXT
03

Exporter des artefacts traçables

Les archives, rapports de test, fichiers de symboles et journaux de build doivent porter l’identifiant de la tâche ; vérifiez leur intégrité avant l’export. Conservez suffisamment de journaux pour diagnostiquer les tâches échouées.

ARTIFACTS
04

Nettoyer l’environnement de la tâche

Supprimez les identifiants temporaires, fichiers montés, espaces de travail temporaires et artefacts intermédiaires inutiles. Placez les caches réutilisés à long terme dans le répertoire prévu, séparément du code source et des données sensibles.

CLEANUP

Guide des expérimentations d’IA

Planifiez d’abord le modèle, le stockage et la session avant de lancer une tâche longue

Pour les expérimentations d’IA, les principaux risques sont généralement la duplication des fichiers de modèle, l’augmentation du volume disque, l’interruption de session et l’absence d’export rapide des résultats. Définir les limites des données avant de commencer réduit les risques de manquer d’espace en cours d’exécution.

Planification de la capacité

Organisez les fichiers de modèle en trois niveaux de répertoires

SOURCE Modèle original

Conservez la source, la version, les informations de licence et le résumé de contrôle. Ne stockez qu’une copie du fichier original afin d’éviter les duplications entre répertoires d’expérimentation.

CACHE Cache reconstructible

Placez les caches de téléchargement, de conversion et les fragments temporaires dans un répertoire distinct ; en cas de manque d’espace, vous pourrez les supprimer et les régénérer.

OUTPUT Résultats de l’expérimentation

Archivez les checkpoints, métriques, journaux et fichiers exportés par numéro de tâche, puis transférez-les vers un emplacement de conservation à long terme une fois la tâche terminée.

Sessions des tâches longues

Les tâches d’entraînement, de conversion ou d’inférence par lots doivent s’exécuter indépendamment d’une session graphique temporaire. Après le démarrage, notez l’identifiant du processus, le répertoire de travail, le chemin des journaux et le mode de reprise, puis vérifiez que la tâche continue après une déconnexion.

Écrivez les journaux en continu dans un fichier
Utilisez un intervalle explicite pour les checkpoints
Réservez suffisamment d’espace pour la croissance du répertoire de sortie

Périmètre des sauvegardes

Le code, les informations de provenance des modèles, les checkpoints non reconstructibles et les résultats finaux doivent être sauvegardés séparément. Les caches de téléchargement, fragments temporaires et fichiers intermédiaires régénérables ne doivent pas consommer les mêmes ressources de sauvegarde.

Demander conseil pour choisir une charge de travail IA

Arbre de décision du dépannage

Vérifiez chaque couche sans modifier plusieurs variables à la fois

À chaque couche vérifiée, ne changez qu’une condition et notez le résultat. Le réseau, les identifiants, le système, le disque et les journaux de build doivent être examinés dans cet ordre ; sauter les vérifications préalables conduit facilement à confondre un problème de connexion avec un problème d’environnement de développement.

Le réseau local atteint-il l’adresse de connexion ?

Vérifiez que l’adresse est complète, que le réseau actuel n’impose pas de restriction aux connexions concernées et que le symptôme reste identique après changement de réseau. Notez le système client, le type de réseau et l’heure d’apparition de l’erreur.

Échec Conservez les champs d’adresse et le texte exact de l’erreur réseau

Les identifiants de connexion proviennent-ils des détails de la commande actuelle ?

Rouvrez les détails de la commande dans la console et vérifiez mot à mot le compte, l’adresse et le mode de saisie des identifiants. N’utilisez pas d’ancienne capture, l’historique du navigateur ou les informations d’une autre instance.

Échec Notez les champs manquants, sans transmettre les identifiants eux-mêmes

L’état de l’instance permet-il d’établir une session ?

Actualisez les détails de l’instance et vérifiez si le champ d’état change. Si l’état ne correspond pas au résultat réel de la connexion, notez le numéro de commande, le nœud, le texte exact de l’état et l’heure de première constatation.

Anomalie Envoyez les champs d’état et les étapes de reproduction

Le disque dispose-t-il de suffisamment d’espace de travail ?

Vérifiez le répertoire du projet, les données dérivées, le cache des dépendances, les fichiers de modèle et les artefacts temporaires. Une fois le manque d’espace confirmé, nettoyez en priorité les caches reconstructibles ; ne supprimez pas les résultats de build non encore exportés.

Insuffisant Notez l’espace total, disponible et les principaux répertoires

Les journaux de build permettent-ils d’identifier la première véritable erreur ?

Remontez depuis le code de sortie de la tâche jusqu’à la première erreur ; ne capturez pas uniquement la dernière ligne. Conservez la commande, la version de la chaîne d’outils, le commit et le contexte de l’erreur, en retirant les jetons, clés privées et autres informations sensibles.

Non résolu Anonymisez les journaux, puis envoyez un ticket

Contacter le support

Si vous ne pouvez pas résoudre le problème seul, fournissez un contexte directement exploitable pour le diagnostic

Pour les problèmes liés à une commande existante, associez en priorité la commande à un ticket depuis la console. Pour une demande de conseil avant commande ou si vous ne pouvez pas accéder à la console, envoyez un e-mail à support@armvms.com. Continuez dans la même conversation pour ajouter des éléments et évitez de créer plusieurs demandes pour un même problème.

À fournir obligatoirement

Informations sur la commande et le nœud

Fournissez le numéro complet de la commande, le nom du nœud, la configuration de base et les options supplémentaires. Si le problème concerne une instance précise, indiquez le champ d’état actuellement affiché dans la console.

Heure et reproduction

Décrivez l’action du premier échec

Indiquez l’heure, les étapes suivies, le résultat attendu et le résultat obtenu. Si vous avez effectué plusieurs essais, précisez les conditions modifiées et celles restées inchangées.

Pièces jointes de diagnostic

Joignez le texte exact de l’erreur et les journaux anonymisés

Copiez le message d’erreur complet et joignez les étapes de build ainsi que leur contexte. Les captures doivent afficher les noms des champs, mais masquer tous les identifiants sensibles et secrets du projet.

Comment ajouter de nouveaux journaux ou résultats de reproduction après l’envoi ?

Répondez dans le même ticket ou la même conversation e-mail en indiquant l’heure du nouveau test, la condition modifiée et le résultat. L’équipe pourra ainsi comparer les événements dans l’ordre chronologique sans recréer le contexte.

Quand faut-il privilégier un ticket depuis la console ?

Pour les problèmes liés à une commande existante — état, facturation, nœud, connexion à l’instance ou livraison — utilisez en priorité un ticket depuis la console. Il peut être associé au numéro de commande et réduit les demandes de confirmation.

Quelles informations préparer pour une demande de conseil avant commande ?

Indiquez le type de projet, le nombre de tâches simultanées, l’environnement Xcode requis, le stockage estimé, la durée de location et le nœud cible. Pour les grands projets ou l’inférence de grands modèles, précisez notamment la mémoire maximale et la taille des fichiers de modèle.

Préparez les éléments de diagnostic

Associez la commande au ticket pour placer directement le problème dans le bon contexte

Ajoutez le numéro de commande, le nœud, l’heure, les étapes de reproduction et les journaux anonymisés. Pour une demande avant commande, consultez aussi les deux configurations et indiquez la durée du projet ainsi que les ressources nécessaires.

Se connecter à la console et envoyer un ticket Contacter l’équipe de service