Consultez d’abord :
la réponse s’y trouve probablement

Le Shell M4 est équipé d’une puce M4, de 16 Go de mémoire et d’un SSD de 256 Go. Il convient pour tester la compilation d’un projet, créer des paquets en ligne de commande ou exécuter une CI peu parallèle. La mémoire nécessaire dépend du nombre de projets ouverts et de simulateurs lancés simultanément, ainsi que de l’utilisation éventuelle de conteneurs ou d’autres services.

Lancez une compilation complète avec votre dépôt pour vérifier la pression mémoire, l’espace d’échange et l’espace disque disponible. Si la pression mémoire reste élevée, réduisez d’abord le niveau de concurrence. Si cela ne suffit pas, envisagez la configuration M4 / 24 Go / 512 Go du Shell M4 Plus. Ne vous fiez pas uniquement à la durée d’une compilation incrémentielle pour évaluer l’ensemble de la configuration.

Le Shell M4 Pro est équipé d’une puce M4 Pro, de 64 Go de mémoire unifiée et d’un SSD de 2 To. Cette configuration est à privilégier pour évaluer l’exécution simultanée de plusieurs compilations, les grands volumes de dépendances et d’artefacts, ou les expérimentations MLX et llama.cpp qui nécessitent davantage de mémoire unifiée.

La capacité à charger un modèle dépend aussi de la quantification, de la longueur du contexte, du cache d’exécution et de la mémoire utilisée par les autres processus. La taille du fichier modèle ne suffit donc pas pour déterminer s’il tiendra dans 64 Go. Mesurez la mémoire maximale et le débit réel avant de vous engager sur une longue durée. Nous ne garantissons ni une taille de modèle donnée ni un facteur d’accélération fixe.

Évaluez séparément les besoins de calcul et de capacité. Si la puce et la mémoire actuelles suffisent, mais que plusieurs versions de Xcode, les caches de compilation ou les artefacts saturent le disque, envisagez un SSD de +1 To ou de +2 To. L’ajout de stockage n’augmente pas la mémoire unifiée et ne transforme pas un M4 en M4 Pro.

Si votre charge de travail nécessite un M4 Pro et 64 Go de mémoire unifiée, choisissez le Shell M4 Pro avec son SSD de 2 To. Avant de commander, vérifiez la capacité ajoutée, la période de facturation et les modalités de montage. Faites une sauvegarde indépendante avant de transférer vos fichiers : l’ajout de capacité n’inclut ni migration automatique ni service de sauvegarde.

Les quatre durées ont chacune leur propre tarif catalogue : le tarif trimestriel ne correspond pas à une simple addition des tarifs journaliers. Voici les tarifs journaliers et trimestriels des trois configurations, pour comparer les essais ponctuels et les usages prolongés. Retrouvez les tarifs hebdomadaires, mensuels et des options sur la page des offres.

Une location longue durée réduit le coût par période, mais vous engage pour une durée d’achat plus longue. Pour une publication ponctuelle, un test d’environnement ou un archivage unique, évaluez d’abord la location à la journée. Pour un runner permanent, comparez la durée prévue et le coût des options.

Ouvrez la commande concernée dans la console pour voir les options de renouvellement, de modification de configuration et d’ajout disponibles. La confirmation de commande indique si le changement prend effet immédiatement, nécessite une migration, modifie la période déjà payée et entraîne un montant supplémentaire. Ne calculez pas vous-même un ajustement à partir du tarif journalier.

Si l’option voulue n’apparaît pas, connectez-vous à la console et ouvrez un ticket en précisant le numéro de commande, la durée souhaitée et la configuration à modifier. En cas de changement de modèle ou de disque, sauvegardez vos données avant de confirmer les modalités d’intervention. L’envoi d’une demande ne signifie pas que la modification a été effectuée.

Ne partez pas du principe qu’un paiement réussi active automatiquement le renouvellement. Vérifiez dans la console les paramètres de renouvellement, l’état de la facture et la date d’échéance ; fiez-vous aux autorisations et confirmations effectives. Pour les pipelines qui doivent fonctionner sans interruption, vérifiez la situation avant l’échéance plutôt que d’attendre la coupure de la connexion.

La facturation dépend de la période achetée, pas de l’utilisation du CPU. Fermer une session SSH, arrêter un runner ou une compilation, ou laisser la machine inactive n’annule pas la commande et ne change pas sa date d’échéance. Pour modifier la durée suivante, utilisez les options de commande disponibles dans la console.

Les tarifs catalogue des configurations, des durées et des options sont tous indiqués en dollars américains (USD), ce qui facilite la comparaison d’une même configuration entre les différents emplacements. Le symbole $ sur le site désigne le dollar américain. Avant de commander, vérifiez le prix de base, les options et le montant total à payer.

Si la devise de facturation de votre carte est différente, la conversion et les éventuels frais sont pris en charge par l’émetteur de la carte et ne font pas partie des tarifs catalogue ArmShell. Pour payer en USDT-TRC20, suivez le réseau, le montant et les coordonnées de paiement affichés sur la page de paiement ; ne les remplacez pas par ceux d’un autre réseau.

Les emplacements disponibles sont Singapour, le Japon (Tokyo), la Corée du Sud (Séoul), Hong Kong et l’est des États-Unis. Les trois configurations sont proposées dans ces cinq emplacements. La disponibilité effective au moment de la commande est indiquée en temps réel par la console.

Si vous utilisez souvent le bureau graphique, testez la réactivité depuis votre réseau professionnel principal. Pour la CI, tenez aussi compte des itinéraires vers le dépôt de code, les sources des dépendances et le serveur qui reçoit les artefacts. Les équipes distribuées doivent se baser sur le lieu principal d’exécution des tâches, et non uniquement sur celui d’un membre de l’équipe.

En cas de doute, testez l’ensemble du processus sur une courte période : clonage du dépôt, restauration des dépendances, compilation et transfert des artefacts. Un seul test ping ne permet pas d’évaluer ces quatre étapes.

Après activation, récupérez l’adresse de connexion, le port et les identifiants dans la console. « Machine physique dédiée » décrit l’attribution des ressources de calcul ; cela ne signifie pas automatiquement qu’une adresse IP publique est fixe, que la sortie réseau est exclusive ou que l’adresse restera inchangée.

Si votre dépôt, votre pare-feu ou vos procédures de conformité exigent une adresse dédiée, une liste d’autorisations en sortie ou une adresse fixe, contactez le support avant de commander. Précisez si vous avez besoin d’une adresse de connexion entrante ou d’une adresse de sortie, et vérifiez que l’emplacement choisi répond à ce besoin. N’autorisez pas une adresse à l’avance sur la base du nom d’hôte d’un exemple de commande.

La latence varie selon l’opérateur, le routage, l’heure et le réseau local. Une valeur de référence en millisecondes ne garantit pas votre résultat. Le temps aller-retour ICMP, la réactivité des commandes SSH et la fluidité du bureau distant sont également des indicateurs différents.

Vérifiez d’abord l’adresse et le port de connexion indiqués dans la console, puis contrôlez votre réseau local et votre pare-feu. Comparez les résultats à différents moments sur un même réseau et notez si le délai se produit à l’établissement de la connexion, au téléchargement des dépendances ou au transfert des fichiers. Joindre ces résultats à un ticket facilite le diagnostic, bien davantage qu’un simple « c’est lent ». Les nœuds fonctionnent normalement toute l’année, 365 jours par an, mais la connexion de bout en bout dépend aussi du réseau côté utilisateur.

Ne considérez pas la durée de conservation après échéance comme une garantie de sauvegarde. Exportez vos données avant la fin de la commande et consultez dans la console les informations relatives à leur traitement. Pour connaître les modalités de conservation et l’avancement de l’effacement, contactez le support en précisant l’état de la commande. Aucune durée de récupération uniforme n’est garantie.

Après la remise en service du nœud, les données de l’utilisateur précédent sont traitées conformément à la procédure prévue. Les données effacées ne peuvent pas être récupérées en renouvelant la location. Avant de cesser d’utiliser la machine, synchronisez vos fichiers, vérifiez que les sauvegardes sont lisibles et révoquez les identifiants de dépôt, les inscriptions de runner et les autres jetons d’accès dont vous n’avez plus besoin.

Pendant la location, vous utilisez un nœud physique dédié dont le CPU, le GPU et la mémoire unifiée ne sont pas partagés avec d’autres clients. Sans autorisation, ArmShell n’accède pas aux fichiers utilisateur ni aux charges de travail présentes sur le nœud. Pour obtenir de l’aide au diagnostic, décrivez le problème dans un ticket et fournissez uniquement les journaux nécessaires ou l’accès strictement requis.

Le caractère dédié de la machine ne remplace pas la gestion de vos comptes et des autorisations. Attribuez à chaque membre de l’équipe un compte système et une clé SSH distincts plutôt que de partager un mot de passe à long terme. Limitez les accès aux répertoires et dépôts nécessaires. Ne divulguez jamais de clé privée, de mot de passe de signature ou de jeton valide dans un ticket, une capture d’écran ou un journal de compilation.

Organisez vos sauvegardes en trois catégories : placez le code dans votre dépôt ; documentez les scripts de compilation, les versions des outils et la configuration de l’environnement pour pouvoir le reconstruire ; transférez les artefacts et les fichiers de travail à conserver hors du nœud avec rsync ou un autre moyen de transfert contrôlé. Stockez les identifiants sensibles dans le système sécurisé approuvé par votre équipe.

Copier des fichiers dans un autre répertoire du même nœud ne constitue pas une sauvegarde indépendante. Après la première sauvegarde, vérifiez quelques fichiers et leurs sommes de contrôle, puis tentez de reconstruire l’environnement de travail à partir de la copie. À l’approche de l’échéance, effectuez une nouvelle synchronisation incrémentielle et vérifiez que la copie locale contient les résultats de la dernière compilation.

Seuls les paiements en USDT-TRC20 et par carte Visa / Mastercard / Amex (via Stripe) sont acceptés. Tous les paiements sont en dollars américains (USD). Les moyens effectivement disponibles sont ceux indiqués par l’interface de paiement au moment de la commande.

Pour payer par carte, suivez les étapes de vérification sur la page de paiement. Pour un paiement en USDT-TRC20, vérifiez le réseau, le montant et les coordonnées du destinataire. Ne renvoyez pas de paiement à l’adresse d’une ancienne commande et ne considérez pas une capture d’écran comme la confirmation de l’activation d’une nouvelle commande : vérifiez ensuite son état dans la console.

Consultez d’abord l’état de la facture et de la commande dans la console pour éviter un double paiement causé par un simple retard d’affichage. Si le statut reste incertain, ouvrez un ticket depuis la console ou écrivez à support@armshell.com en indiquant le numéro de commande, le moyen de paiement, le montant payé et, selon le cas, la référence de facturation de la carte ou le hachage de la transaction USDT-TRC20.

N’envoyez ni numéro complet de carte, ni cryptogramme, ni mot de passe système, ni clé privée. Le support vérifiera les informations à partir de la commande et des données de paiement. La réception du paiement, sa vérification et l’activation du nœud sont des étapes distinctes : la validation de l’une ne remplace pas celle des autres.