VMKeep fournit des machines physiques Apple Silicon dédiées, conçues pour fonctionner en continu, et non des machines virtuelles. Les équipes peuvent standardiser la puce, la mémoire et la chaîne d’outils pour transformer l’inférence MLX, les builds mobiles et la collaboration à distance en workflows reproductibles.
Les tâches adaptées à un Mac dans le cloud présentent généralement trois caractéristiques : elles dépendent de macOS ou d’Apple Silicon, s’exécutent au-delà des horaires de travail locaux et nécessitent un environnement fixe pour reproduire les résultats. Pour une simple validation locale de courte durée, votre équipement actuel peut suffire.
Utilisez SSH pour le développement en ligne de commande et l’automatisation, et VNC pour l’interface graphique macOS. Le code, les dépendances et les services locaux restent disponibles sans devoir recréer l’environnement chaque jour.
Placez le runner, Xcode, CocoaPods, Node.js et le cache des dépendances sur le même nœud physique afin que chaque build s’exécute avec les mêmes répertoires, versions et limites de permissions.
Exécutez MLX sur une configuration définie de puce et de mémoire, puis mesurez la version quantifiée du modèle, la mémoire maximale, la latence du premier token et le débit soutenu afin d’éviter les écarts liés aux machines de chaque membre.
Pour un premier déploiement, inutile de commencer par une orchestration complexe. Vérifiez d’abord sur le nœud que le modèle se charge, que les requêtes aboutissent et que la mémoire reste stable, puis ouvrez l’accès aux appelants contrôlés. Vous pourrez ainsi distinguer les problèmes de compatibilité du modèle des problèmes réseau.
Notez la source, la version, la méthode de quantification, la longueur de contexte et la somme de contrôle du fichier. Séparez le répertoire du modèle du code du service pour remplacer facilement la version quantifiée sans modifier la logique de démarrage.
Figez les versions de Python et des dépendances liées à MLX, puis inscrivez la liste d’installation dans le dépôt. Exécutez d’abord une inférence unique en ligne de commande pour vérifier le tokenizer, le format des poids et les besoins mémoire.
Faites d’abord écouter le service sur l’adresse locale et ajoutez un contrôle d’état, des délais d’expiration et des journaux structurés. Utilisez un prompt fixe pour vérifier la structure de la réponse, puis observez la latence du premier token et la mémoire maximale.
Après avoir confirmé la stabilité des requêtes locales, ouvrez l’accès selon la politique réseau de l’équipe. Le client conserve le délai d’expiration, les nouvelles tentatives et l’identifiant de requête ; le serveur consigne la version du modèle et les paramètres d’inférence.
curl -X POST http://127.0.0.1:8080/infer \
-H "Content-Type: application/json" \
-d '{
"prompt": "Summarize build log",
"max_tokens": 128
}'Ne consignez pas uniquement un chiffre de débit. La version du modèle, la quantification, la longueur de contexte, le nombre de requêtes simultanées et les cycles de préchauffage modifient tous les résultats. Figez d’abord les conditions de test avant de changer de modèle ou de configuration.
| Élément consigné | Condition fixe | Utilité |
|---|---|---|
| Version quantifiée | Même modèle et même longueur de contexte | Comparer les compromis entre précision, mémoire et vitesse |
| Mémoire maximale | Mêmes entrées et même nombre de requêtes simultanées | Vérifier que la configuration conserve une marge suffisante pour fonctionner de manière stable |
| Latence du premier token | Même état de préchauffage | Évaluer le temps d’attente des requêtes interactives |
| Débit soutenu | Même longueur de sortie | Évaluer les performances des longues sorties et des tâches par lots |
| Enregistrement des échecs | Conserver l’identifiant de requête et les journaux | Distinguer les problèmes liés au modèle, à la mémoire, au service et aux appels |
L’intérêt d’un nœud physique fixe ne se limite pas à pouvoir exécuter Xcode : il délimite clairement le code source, les dépendances, les tests, la signature et l’emplacement des archives. En cas d’échec, vous pouvez suivre l’ordre d’exécution au lieu de rechercher à nouveau les différences d’environnement.
Utilisez des identifiants à privilèges limités pour lire le dépôt indiqué, puis figez la branche, le commit et l’état des sous-modules.
Installez les dépendances depuis les fichiers de verrouillage. Isolez les répertoires de cache par projet et par version pour éviter la contamination par un ancien cache.
Définissez workspace, scheme, configuration et destination, puis conservez la commande complète.
Consignez séparément les tests unitaires, les tests d’interface et les cas en échec, en conservant des rapports lisibles par machine.
Limitez l’accès aux éléments de signature nécessaires et n’écrivez ni le contenu des certificats ni les identifiants sensibles dans les journaux de build.
Conservez les archives, journaux et rapports de tests par commit et numéro de tâche, avec une stratégie de nettoyage définie.
Identifiez d’abord l’étape en échec, puis choisissez de relancer les tests, de reconstruire les dépendances ou de recréer l’archive. Appliquez des stratégies différentes aux caches invalides, aux échecs réseau et aux erreurs de code.
Un build React Native couvre Node.js, le gestionnaire de paquets, CocoaPods et Xcode. Verrouiller uniquement les versions des paquets JavaScript ne suffit pas : Ruby, Pods, les réglages du projet Xcode et la commande de build doivent aussi figurer dans une liste reproductible.
Figez les versions du runtime et du gestionnaire de paquets, et distinguez les caches selon l’empreinte du fichier de verrouillage.
Consignez l’état des Pods, le scheme, la configuration de build et l’appareil cible.
Associez le numéro de commit, la tâche de build et le répertoire des artefacts.
Gérez séparément le cache des paquets JavaScript, celui de Pods et les données dérivées de Xcode. Un cache valide peut accélérer le processus, mais ne doit pas masquer une incohérence de versions.
À consigner : résumé des fichiers de verrouillage, état des Pods, version de XcodeLes scripts automatisés ne lisent que les identifiants nécessaires à l’exécution. Masquez les informations sensibles dans les journaux et supprimez les fichiers temporaires à la fin du build selon la politique de l’équipe.
À conserver : numéro de commit, numéro de tâche, somme de contrôle de l’artefactLes deux modes de connexion peuvent servir la même machine physique dédiée, mais leurs usages diffèrent. Après la première connexion, mettez à jour le mot de passe, configurez les clés SSH et limitez la diffusion des identifiants. Les informations de connexion et l’état réellement disponible sont ceux renvoyés en temps réel par la console.
Les équipes peuvent affecter différents runners, expériences de modèles ou files de build à des nœuds physiques distincts. Chaque nœud consigne séparément le périmètre des tâches, les versions d’environnement et le répertoire des artefacts, ce qui simplifie le diagnostic et la planification de capacité par rapport à un environnement partagé et mélangé.
La restauration des dépendances, les tests et l’archivage s’exécutent dans un répertoire de build fixe.
Isolez les caches JavaScript, Pods et données dérivées de Xcode.
Figez la puce, la mémoire, la version du modèle et les conditions d’entrée.
Les trois offres sont des machines physiques Apple Silicon dédiées, et non des machines virtuelles. Pour une validation légère, maîtrisez les coûts ; pour un pipeline continu, privilégiez le cache et la concurrence ; pour l’inférence avec forte consommation mémoire, vérifiez d’abord l’utilisation maximale après chargement du modèle.
M4 · 16GB · 256GB
Convient au développement sur un projet, aux builds iOS légers, à la validation d’un environnement MLX et aux tests de compatibilité de petits modèles. Si le stockage est limité, prévoyez à l’avance la gestion du cache et le nettoyage des artefacts.
M4 · 24GB · 512GB
Convient aux runners permanents, au cache des dépendances de projets intermédiaires, aux builds React Native continus et aux expériences d’inférence MLX nécessitant davantage de mémoire disponible.
M4 Pro · 64GB · 2TB
Convient à l’inférence MLX exigeante en mémoire, à la comparaison de quantifications de modèles volumineux, aux expériences parallèles et aux files de build à forte charge. Validez d’abord avec le modèle réel et les paramètres de concurrence.
Les trois configurations sont disponibles à la commande dans ces cinq emplacements. La disponibilité réelle est celle renvoyée en temps réel par la console.
Choisissez d’abord la configuration, puis le nœud à Singapour, au Japon (Tokyo), en Corée du Sud (Séoul), à Hong Kong ou dans l’est des États-Unis, et définissez une durée de location à la journée, à la semaine, au mois ou au trimestre. La commande et la gestion de la machine s’effectuent dans la console.