Trouvez vos réponses avant de commander

Chaque location comprend un Mac mini physique attribué à un seul locataire, et non une machine virtuelle découpée sur un hôte partagé. Le CPU, le GPU et la mémoire unifiée de la machine sont à la disposition de vos tâches. Cette configuration convient aux services MLX qui ont besoin d’une mémoire unifiée disponible de façon stable, ainsi qu’aux pipelines CI qui ne doivent pas entrer en concurrence avec d’autres locataires pour les ressources.

Les performances ne seront pas les mêmes pour toutes les tâches : la taille du modèle, la quantification, le cache de build et la connexion réseau influent sur les résultats. Pour choisir, commencez par estimer les besoins en mémoire selon les poids du modèle et son pic d’utilisation, puis consultez les caractéristiques réelles des trois configurations.

Non. Une fois le Mac mini livré, son CPU, son GPU, sa mémoire unifiée et son stockage sont réservés au locataire en cours. Le réseau du centre de données fait partie de l’infrastructure ; cela ne signifie pas que les ressources de calcul de la machine sont partagées. Si vous exécutez à la fois des builds et un endpoint d’inférence permanent, prévoyez assez de mémoire pour les deux processus au lieu d’allouer tout le budget de mémoire unifiée aux poids du modèle.

Vous pouvez installer dans l’environnement macOS livré des outils de développement, des gestionnaires de paquets et des dépendances d’exécution conformes à leurs licences, notamment les outils de ligne de commande Xcode, Homebrew, Python et les logiciels liés à MLX. Avant de modifier l’accès à distance, le proxy réseau ou le démarrage des services, notez les paramètres actuels afin de pouvoir revenir en arrière. En particulier, ne désactivez pas le mode de connexion actuel avant d’avoir vérifié que l’authentification par clé fonctionne.

Choisissez d’abord une configuration, puis une période prépayée. Chaque période a son propre tarif catalogue : le prix à la semaine ou au mois ne se calcule pas en multipliant le tarif journalier. Par exemple, le XOps 16 coûte $19.4/jour, $52.3/semaine, $96.8/mois et $263.3/trimestre. Le stockage supplémentaire ou la mise en parallèle Thunderbolt 5 sont facturés séparément selon la période choisie. Vérifiez le détail complet avant de passer commande.

Pour tester un modèle sur une courte période, consultez le tarif journalier. Pour maintenir un endpoint d’inférence en ligne, comparez directement les tarifs à la semaine, au mois et au trimestre.Les tarifs complets et les optionsprésentent les prix des trois configurations pour les quatre périodes.

Seuls USDT-TRC20 et les cartes Visa / Mastercard / Amex traitées par Stripe sont acceptés. Tous les prix catalogue et montants à régler sont en dollars américains (USD). Les moyens de paiement réellement disponibles au moment du règlement sont ceux indiqués en temps réel par la console. Avant de payer, vérifiez le réseau sélectionné, le montant et les informations de la commande.

Consultez la date d’expiration de la commande dans la console et renouvelez avant cette échéance. Ne partez pas du principe que la période sera prolongée automatiquement parce qu’une tâche est toujours en cours. À l’échéance, toute machine non renouvelée est libérée conformément aux règles de la commande. Les fichiers locaux, poids de modèles et caches de build présents sur une machine libérée ne restent pas accessibles en ligne. Exportez les données à conserver avant l’échéance et vérifiez les copies. Pour toute question sur le statut de la commande, vous pouvezvous connecter à la console et ouvrir un ticket.

Avant de commander, vérifiez les options, la période et le montant total en dollars dans le récapitulatif de configuration. Après la commande, consultez les détails de celle-ci et les factures dans la console. Avant de modifier ou de résilier une option, vérifiez les actions autorisées pour la commande en cours ; supprimer des fichiers sur le disque ne revient pas à résilier une option. Pour toute demande concernant un paiement, indiquez le numéro de commande et la référence de la transaction. N’envoyez jamais vos coordonnées complètes de carte ni votre clé privée.

Vous pouvez choisir entre Singapour, Tokyo, Séoul et Hong Kong. Les trois configurations — XOps 16, XOps 24 et XOps Pro 64 — sont proposées dans ces quatre nœuds. La disponibilité au moment de la commande est celle indiquée en temps réel par la console. Pour choisir un nœud, tenez compte non seulement de l’emplacement de votre équipe, mais aussi de la connexion utilisée pour envoyer les poids des modèles, synchroniser le dépôt de code et accéder au bureau à distance.

Faites des tests depuis le lieu principal où vous appelez l’API d’inférence ou utilisez le bureau à distance, plutôt que de vous fier uniquement à la distance sur une carte. Mesurez la latence aller-retour vers chaque nœud candidat, puis testez l’envoi d’un fichier de taille identique. Si votre activité principale est la compilation CI, comparez aussi les connexions utilisées pour récupérer le code et ses dépendances. Consultez d’abordle tableau de latence des nœuds dans le guide de connexion, puis refaites les mesures depuis votre propre réseau.

Le tableau du guide donne la moyenne de 100 tests ICMP consécutifs, réalisés avec une connexion Internet résidentielle en soirée, un jour ouvré. Il sert uniquement à comparer les nœuds dans un premier temps. Ce n’est pas une garantie concernant le temps de réponse en SSH, la fluidité du bureau VNC ou la vitesse de transfert de gros fichiers. Le routage de l’opérateur, les pertes de paquets, la taille des fichiers et la configuration du client influent sur l’expérience. Si vous prévoyez d’utiliser régulièrement le bureau à distance, testez depuis votre propre réseau.

16 Go conviennent pour commencer avec de petits modèles quantifiés et des expérimentations individuelles. 24 Go permettent d’évaluer des services persistants utilisant la quantification 4 bits de modèles courants de 7B à 8B. 64 Go conviennent mieux aux modèles plus grands, à l’exécution parallèle de plusieurs modèles ou à la conservation simultanée de charges de build. Il s’agit de repères pour planifier, pas d’une garantie qu’un modèle d’une taille donnée tiendra en mémoire.

Pour estimer les besoins, tenez compte des poids du modèle, du cache KV, de la longueur du contexte, des requêtes simultanées et de la mémoire utilisée par macOS, puis prévoyez une marge. Le fait qu’un modèle se charge ne garantit pas le débit souhaité. Avant de choisir une configuration, testez-la de préférence avec des requêtes réelles.

Oui, vous pouvez les installer et les exécuter séparément, mais les poids des modèles, les caches et les requêtes simultanées des deux services utilisent les mêmes ressources. Mesurez d’abord le pic d’utilisation de chaque service séparément, puis testez-les ensemble. En cas de pression mémoire ou de hausse notable du temps de réponse, réduisez le nombre de requêtes simultanées, décalez les démarrages ou choisissez une configuration avec plus de mémoire : modifier uniquement le port d’écoute ne suffira pas.

Utilisez mlx_lm.server pour lancer un endpoint compatible avec l’API OpenAI. Configurez-le pour écouter uniquement sur l’adresse de bouclage locale, puis permettez aux clients autorisés de l’équipe de s’y connecter par tunnel SSH. Si vous passez par un proxy inverse, configurez séparément l’authentification, le chiffrement des communications et les restrictions d’accès. N’exposez jamais directement sur Internet un port d’inférence non protégé.

Le guide de déploiement rapide MLXprésente les étapes d’installation, de démarrage et de connexion. Avant la mise en production, vérifiez la mémoire et le débit avec les modèles et le volume de requêtes réels de votre équipe.

Oui, vous pouvez installer et conserver plusieurs versions selon les besoins de vos projets, sous réserve de l’espace disponible, de la compatibilité avec la version de macOS et des licences logicielles. Avant de lancer une tâche automatisée, sélectionnez explicitement la version requise et notez le chemin utilisé par les outils de ligne de commande. Ainsi, le runner ne réutilisera pas par erreur la chaîne d’outils de la tâche précédente pour compiler une autre branche. Pour transférer des éléments de signature, utilisez uniquement les procédures d’export et d’import autorisées par votre équipe.

Commencez par vérifier en SSH que le dépôt de code, Xcode et les dépendances de build sont accessibles, puis ajoutez la machine à votre équipe en suivant la procédure d’inscription de votre plateforme CI. Attribuez au runner un répertoire de travail dédié et les permissions minimales nécessaires. Définissez les règles de nettoyage du cache et le nombre maximal de tâches simultanées. Pour le premier pipeline, exécutez uniquement des vérifications d’environnement ; une fois la chaîne d’outils et la configuration de signature validées, ajoutez les tâches d’archivage de production.

Pour connaître l’ordre complet de migration de l’environnement et de connexion à la CI, consultez leguide de démarrage.

Un Mac cloud peut exécuter le simulateur Xcode, des builds et des tests automatisés, et préparer les artefacts nécessaires à la distribution. Il ne remplace pas un appareil iOS physique à votre disposition. Les tests faisant appel au matériel — caméra, Bluetooth, capteurs ou réseau cellulaire, par exemple — doivent toujours être réalisés par votre équipe sur des appareils physiques. Vous pouvez intégrer les tests de régression du simulateur à la CI et réserver les vérifications matérielles aux appareils locaux.

Après la libération de la machine, le disque entier est effacé avant sa préparation pour une nouvelle livraison. Ne conservez pas les poids de modèles, fichiers de projet, clés ou artefacts de build comme uniques copies sur une machine libérée. Avant la libération, exportez les données nécessaires vers un emplacement que vous gérez et vérifiez que les archives sont lisibles. Le lancement d’une synchronisation ne signifie pas que la sauvegarde est terminée.

Pendant la période de location, vous pouvez exporter les données que vous gérez par SSH, avec une méthode de transfert adaptée à la taille des fichiers. Pour les gros fichiers, vérifiez d’abord l’espace disponible et le chemin de destination, puis synchronisez par lots et vérifiez le résultat. Les caches de build pouvant généralement être régénérés, donnez la priorité aux fichiers de projet, configurations et poids de modèles impossibles à recréer. Pour connaître l’ordre précis de migration avec rsync consultez leguide de connexion et de migration.

Utilisez des identifiants uniques et robustes pour accéder à la console. Pour vous connecter à la machine, privilégiez les clés SSH et limitez l’emplacement où votre clé privée est stockée ainsi que les accès à celle-ci. Connectez-vous au bureau à distance VNC par un tunnel SSH ; n’exposez pas directement le port du service. Lorsqu’un membre quitte l’équipe, vérifiez sans attendre les autorisations existantes, les identifiants du runner et les clés de déploiement. En cas de signe d’accès inhabituel,connectez-vous à la console et ouvrez un ticket.