Centre d’aide GPUMini

Identifiez d’abord le problème, puis vérifiez chaque élément à partir des preuves

Pour les problèmes de connexion, de build, de réseau, de stockage et de facturation sur des nœuds physiques dédiés Mac dans le cloud. Saisissez un message d’erreur, un outil ou un élément de facturation pour trouver la procédure la plus pertinente.

6 catégoriesAccès aux questions fréquentes
5 étapesOrdre de diagnostic standard
2 optionsCanaux de contact humain
Se connecter au portail et envoyer un ticket Voir les conditions de contact
Fiche de diagnostic SUPPORT / 01
A

Objet à confirmerNœud, compte, commande ou tâche de build

B

Conserver les preuvesHeure, commandes, lignes d’erreur et logs anonymisés

C

Réduire le périmètreRéseau, identifiants, disque ou chaîne d’outils

Disponible pour SG · JP · KR · HK Nœuds physiques dédiés
Choisir selon la tâche

Six catégories, chacune avec son premier point de contrôle

Un échec de connexion ne vient pas forcément du réseau, et un échec de build pas forcément de Xcode. Choisissez d’abord une catégorie, puis vérifiez les éléments les plus discriminants.

Connexion

Connexion à distance

Vérifiez l’adresse du nœud, le port, le réseau client, la vérification de l’hôte et les paramètres du bureau Mac distant. Idéal pour les délais d’attente, écran noir, presse-papiers non synchronisé et latence de saisie.

Voir le parcours de diagnostic de connexion
Compte

Compte et autorisations

Vérifiez l’adresse e-mail de connexion, l’instance associée, la mise à jour des identifiants temporaires et les autorisations locales requises par la commande ou le répertoire. Ne transmettez jamais votre mot de passe dans une demande d’assistance.

Voir les vérifications des autorisations
Build

Build Xcode

Vérifiez le chemin Xcode, le SDK, le Scheme, l’espace de travail, le cache des dépendances et l’espace disque. Conservez le code de sortie complet de xcodebuild et l’emplacement de la première erreur.

Voir la méthode de diagnostic du build
Automatisation

Fastlane

Distinguez les problèmes liés à Ruby, Bundler, aux paramètres du lane, aux variables d’environnement et aux éléments de signature. Notez en priorité le nom de l’étape en échec, pas uniquement la dernière ligne.

Voir les points clés des logs d’automatisation
Réseau

Diagnostic réseau

Mesurez séparément la latence, la gigue, la perte de paquets et l’accessibilité du port cible. Ne jugez pas la liaison sur un seul ping ; comparez aussi le réseau local à un autre réseau d’accès.

Voir l’ordre des mesures réseau
Facturation

Stockage et facturation

Distinguez l’offre de base, la durée de location, le nœud, l’extension de stockage et l’agrégation Thunderbolt 5, puis vérifiez chaque montant sur la confirmation de commande et la facture.

Voir comment vérifier une facture
Parcours de connaissances

Partez des symptômes, pas des suppositions

Les six parcours restent affichés sur cette page. Les boutons de catégorie servent uniquement à localiser et mettre en évidence le contenu, sans masquer les autres informations, afin de faciliter les comparaisons.

Connexion à distance Vérification estimée : 5 min

Délai SSH dépassé ou session de bureau Mac distant impossible à établir

Vérifiez d’abord dans le portail que l’instance est accessible, puis contrôlez exactement l’adresse et le port du nœud. Testez ensuite l’accessibilité du port depuis votre réseau local ; s’il est inaccessible, changez une fois de réseau pour distinguer un problème du nœud d’un problème de liaison. Lors de la première connexion SSH, vérifiez l’empreinte de l’hôte. En cas d’échec des identifiants, contrôlez le nom d’utilisateur, le chemin de la clé et les autorisations du fichier. Si une session graphique établie affiche un écran noir, réduisez d’abord la résolution et les effets dynamiques, puis déconnectez l’ancienne session et reconnectez-vous.

  • Indiquez le système client, le nom et la version de l’outil de connexion.
  • Conservez la ligne complète de l’erreur de délai d’attente, de refus de connexion ou d’authentification.
  • En cas de latence élevée, indiquez simultanément la médiane du ping, la gigue et la perte de paquets, et non un seul résultat.
Ouvrir le guide de connexion Mac à distance
Compte et autorisations Vérification estimée : 4 min

Connexion au nœud réussie, mais commande, répertoire ou projet refusé

Déterminez d’abord si l’échec concerne la connexion au portail, la connexion locale ou la vérification des autorisations d’une commande. Le portail sert à consulter les commandes, instances, factures et tickets ; les autorisations locales du nœud dépendent de l’utilisateur courant, du propriétaire du répertoire et des exigences de la commande. Si vous voyez Permission denied, indiquez le chemin cible, la commande exécutée et l’utilisateur courant. Ne modifiez pas de façon répétée les autorisations de tout le répertoire du projet. Mettez à jour les identifiants temporaires après la première connexion et évitez d’enregistrer les informations de connexion sur un appareil public.

  • Vérifiez que l’instance et l’adresse e-mail de connexion correspondent bien à l’opération.
  • Utilisez whoami,pwd et les informations d’autorisation du répertoire pour confirmer le contexte d’exécution.
  • Ne joignez jamais de mot de passe, clé privée ou jeton d’accès non anonymisé à une demande d’assistance.
Ouvrir le portail pour vérifier l’instance
Build Xcode Vérification estimée : 8 min

xcodebuild ne trouve pas le Scheme, le SDK ou l’appareil cible

Vérifiez d’abord que la commande est exécutée à la racine du projet et distinguez .xcodeproj de .xcworkspace. Affichez ensuite le chemin Xcode sélectionné et les SDK disponibles, puis vérifiez que le Scheme est partagé et que la casse de son nom est identique. Si le problème apparaît après une mise à jour des dépendances, ne supprimez pas immédiatement tous les caches : conservez le premier log d’échec, localisez la première erreur explicite, puis décidez s’il faut nettoyer DerivedData ou résoudre à nouveau les dépendances.

  • Conservez la commande complète, le répertoire de travail, la version de Xcode et le code de sortie.
  • Utilisez les commandes de liste pour confirmer l’espace de travail, le Scheme et les destinations disponibles.
  • En cas d’interruption soudaine du build, vérifiez l’espace disque restant, le répertoire temporaire et la taille du cache des dépendances.
Voir l’ordre de vérification initiale de l’environnement
Fastlane Vérification estimée : 7 min

Fastlane s’arrête lors du chargement des dépendances, de l’exécution du lane ou de l’exportation

Vérifiez d’abord si le projet utilise la commande système ou bundle exec fastlane, puis assurez-vous que Ruby, Bundler et Gemfile.lock correspondent. La dernière ligne du log indique souvent seulement l’arrêt du processus ; la cause réelle apparaît généralement plus haut. Conservez le contexte précédant le premier bloc d’erreur et indiquez le lane, l’action et la source des paramètres en échec. Ne transmettez que le nom des variables d’environnement et leur présence, jamais leur valeur réelle.

  • En cas d’échec lors des dépendances, indiquez les versions de Ruby, Bundler et Fastlane.
  • En cas d’échec d’une action de build, conservez aussi le code de sortie xcodebuild sous-jacent.
  • Pour une tâche répétée, indiquez si elle s’arrête toujours à la même étape et si le résultat change après le nettoyage du cache.
Préparer le problème selon la liste d’assistance
Diagnostic réseau Vérification estimée : 6 min

Connexion ralentie, affichage saccadé ou transfert de fichiers instable

L’expérience à distance dépend à la fois de la latence, de la gigue, de la perte de paquets et de la bande passante disponible. Testez séparément, depuis votre lieu d’utilisation habituel, les nœuds de Singapour, Tokyo, Séoul et Hong Kong ; choisissez le trajet offrant la meilleure latence médiane et la plus faible gigue. Gardez le réseau local, la plage horaire et le nombre d’échantillons constants. Si le Wi-Fi fluctue nettement, refaites le test en filaire ou via un autre réseau. Pour les sessions graphiques, réduisez la résolution, la qualité des couleurs et les effets dynamiques ; pour les commandes et tâches longues, privilégiez SSH.

  • Conservez au moins une série d’échantillons consécutifs, et non la latence minimale d’un seul test.
  • Précisez quel élément est anormal : navigation web, SSH, session de bureau ou transfert de fichiers.
  • Indiquez votre zone d’accès locale, le type de réseau, le nœud cible et la période d’apparition du problème.
Comparer les quatre nœuds
Stockage et facturation Vérification estimée : 5 min

Vérifier l’offre de base, la durée de location et les options

Vérifiez la facture ligne par ligne à partir de la confirmation de commande : commencez par confirmer GPUMini M4 Core ou GPUMini M4 Plus, puis contrôlez la durée choisie — jour, semaine, mois ou trimestre —, le nœud cible et l’ajout éventuel d’une extension de stockage ou d’une agrégation Thunderbolt 5. Ne comparez pas uniquement le total : un même montant peut correspondre à des durées et options différentes. Tous les montants sont facturés en dollars américains. Les moyens de paiement disponibles sont USDT-TRC20, ou Visa, Mastercard et Amex traitées par Stripe ; la passerelle réellement disponible est indiquée lors du paiement.

  • Indiquez le numéro de commande, le nom des lignes de facture à vérifier et ne transmettez pas les informations de paiement complètes.
  • Un manque d’espace disque sur l’instance relève du fonctionnement ; indiquez aussi l’espace restant et l’occupation des principaux répertoires.
  • Si une ligne de facture ne correspond pas à vos attentes, joignez les informations textuelles de la confirmation de commande et de la ligne concernée.
Voir les définitions des offres et options
Preuves de commande

Conservez la première erreur, pas uniquement la dernière ligne

La fin des sorties SSH, xcodebuild et Fastlane peut simplement afficher « tâche échouée ». Les informations utiles au diagnostic se trouvent généralement à l’emplacement de la première erreur et dans les lignes qui l’entourent.

gpumini-diagnostics — zsh lecture seule 
$ ssh -v build@node.example
debug1: Connecting to node [port 22]
debug1: Server host key verified
Permission denied (publickey).
↑ Échec fréquent : nom d’utilisateur, chemin de clé ou autorisations de la clé

$ xcodebuild -workspace App.xcworkspace -scheme App build
Resolve Package Graph
xcodebuild: error: The workspace does not contain scheme "App".
↑ Échec fréquent : choix de l’espace de travail ou Scheme non partagé

$ bundle exec fastlane build
[build] Running gym
Exit status: 65
↑ Recherchez plus haut le premier bloc d’erreur xcodebuild
SSH

Échec de l’authentification

Indiquez le nom d’utilisateur, le nœud cible, le port, le résultat de la vérification de l’hôte et la ligne d’erreur complète. Le contenu de la clé privée ne doit jamais figurer dans les logs ou les tickets.

xcodebuild

Échec de configuration

Indiquez le répertoire de travail, le workspace ou project, le Scheme, la destination, la version de Xcode et le code de sortie.

Fastlane

Échec du processus

Indiquez le lane, l’action, les versions des dépendances et le premier bloc d’erreur. Indiquez seulement le nom des variables d’environnement et leur présence.

Procédure standard

Cinq étapes de diagnostic, sans modifier plusieurs variables à la fois

Passez à l’étape suivante uniquement après avoir noté le résultat de la précédente. Modifier plusieurs configurations simultanément peut masquer temporairement le problème sans en révéler la cause.

  1. 01

    Vérifier l’état du nœud

    Connectez-vous au portail pour vérifier l’instance, le code du nœud et son état actuel, et assurez-vous de consulter la bonne commande. Singapour, Tokyo, Séoul et Hong Kong sont des nœuds normalement disponibles à la commande ; leur disponibilité réelle est indiquée en temps réel dans le portail.

  2. 02

    Vérifier la connectivité réseau

    Contrôlez la résolution DNS, le port cible, la latence, la gigue et la perte de paquets, puis refaites le test via un autre réseau d’accès. Un port inaccessible et un échec d’authentification sont deux problèmes distincts qui nécessitent des traitements différents.

  3. 03

    Vérifier les identifiants de connexion

    Vérifiez exactement le nom d’utilisateur, le chemin de la clé, les autorisations du fichier et l’empreinte de l’hôte. Après plusieurs échecs, ne remplacez pas tous les identifiants au hasard et n’envoyez jamais votre mot de passe ou votre clé privée à l’équipe d’assistance.

  4. 04

    Vérifier l’espace disque

    Contrôlez la capacité restante du volume système, DerivedData, le cache des dépendances, les artefacts d’archive et les répertoires temporaires. La saturation du disque peut provoquer une interruption du build, un échec d’exportation ou l’arrêt anormal d’un outil.

  5. 05

    Lire les logs de build

    Étendez le contexte des logs autour de la première erreur explicite et notez la commande, le répertoire, la version de l’outil, le code de sortie et les étapes de reproduction. La dernière ligne seule ne suffit généralement pas au diagnostic.

État du service

Les nœuds fonctionnent toute l’année ; les incidents sont mis à jour selon leur impact

Les quatre nœuds GPUMini fonctionnent normalement 365 jours par an. En cas d’incident soudain, les informations d’état sont mises à jour selon le nœud concerné, l’heure de début, l’impact actuel, l’avancement du traitement et le résultat du rétablissement. Les problèmes propres au réseau, aux identifiants, au disque ou à la configuration d’un projet ne sont pas présentés à tort comme un incident global.

Lors de la consultation de l’état, vérifiez d’abord le code du nœud et l’état de l’instance, puis comparez la période observée. Si le problème persiste, ne signalez pas seulement « impossible de se connecter » : indiquez votre zone d’accès locale, le mode de connexion, l’erreur complète, l’heure de première apparition et celle de la dernière reproduction.

Ensemble minimal d’informations de diagnostic 6 éléments
Nœud
SG, JP, KR ou HK
Heure
Heure de l’événement avec fuseau horaire
Point d’accès
SSH, bureau distant ou tâche de build
Symptôme
Texte complet de l’erreur et code de sortie
Reproduction
Étapes minimales reproductibles
Logs
Supprimez les mots de passe, clés privées et jetons d’accès

Comment savoir si une intervention humaine est nécessaire :Si le même problème reste reproductible après les vérifications du nœud, du réseau, des identifiants, du disque et des logs, ou si une différence explicite apparaît entre la commande et la facture, envoyez un ticket. Pour une demande générale, vous pouvez également écrire à support@gpumini.com.

Contacter l’assistance humaine

Donnez à l’équipe d’assistance des informations immédiatement exploitables

Le nœud, l’heure, les étapes de reproduction et les logs anonymisés sont les quatre informations de base pour traiter un problème technique. Pour une question de facturation, ajoutez le numéro de commande et les lignes concernées.

Ticket depuis le portail

Pour les commandes, instances, factures et incidents persistants

Un ticket peut être associé aux commandes et instances de votre compte. Il convient aux problèmes techniques nécessitant de vérifier l’état d’un nœud, une ligne de facture ou un suivi continu.

  • Sélectionnez l’instance ou la commande concernée.
  • Indiquez le nœud et l’heure de l’événement avec son fuseau horaire.
  • Joignez les étapes de reproduction et les logs anonymisés.
Se connecter au portail et créer un ticket
E-mail d’assistance

Pour le choix d’une offre avant achat et les demandes générales

Avant d’envoyer votre e-mail, préparez la charge de travail, le nœud cible, la durée de location, le nombre de builds simultanés, ainsi que les besoins en mémoire et en stockage. Pour les problèmes techniques, n’ajoutez jamais de mot de passe ou de clé privée.

  • L’unique adresse e-mail publique est support@gpumini.com.
  • Indiquez dans l’objet le type de demande et le nœud cible.
  • Décrivez dans le message le résultat attendu et le symptôme observé.
Voir la liste complète des contacts
Préparer l’envoi du problème

Apportez les preuves avant de solliciter l’assistance

Pour un problème technique, préparez le nœud, l’heure, les étapes de reproduction et les logs anonymisés. Pour les commandes, instances et factures, privilégiez un ticket depuis le portail afin d’associer les éléments concernés.

Se connecter au portail et envoyer un ticket Contacter l’assistance GPUMini