Un Mac mini M4 loué (Singapour, Tokyo, Séoul, Hong Kong, US Ouest) exploite la mémoire unifiée pour l’IA si vous calibrez pile, micro-lots et timeouts de file avec le plan de contrôle réel. Nous comparons PyTorch MPS et MLX en batch, les pics sur 16 Go / 24 Go, puis une matrice paramétrée runbook. Capacité : Accueil, Tarifs, Aide.
Choisir l’offre de calcul sur un M4 loué
Priorisez le débit utile et les pics (chargement modèle, compilation Metal, premier jet) plutôt que l’étiquette du framework. CPU, GPU et NPU partagent une DRAM unique : pas de VRAM discrète pour absorber un mauvais B.
M4 16 Go : working set stable (poids, séquence max, activations à B, marge OS, cache, agent) plusieurs Go sous le plafond. M4 24 Go : sessions parallèles, B plus large, contextes longs ou second modèle chaud. Même logique « pool unique » que Blender batch & mémoire unifiée.
Gros artefacts : alignez région et téléchargements sur matrice datasets / poids LLM pour ne pas être RTT-limité avant le premier batch.
MPS vs MLX : cas d’usage et choix de pile
PyTorch MPS : modèles torch, opérateurs tiers, portage CUDA → inférence ; runtime plus lourd, écosystème et debug familiers.
MLX : graphes Apple-first, boucle légère sur mlx, batch régulier si l’export est maîtrisé et les formes dynamiques rares.
Toujours un plan de session (charger une fois, drainer la file). Cohabitation LLM HTTP + scoring : OpenClaw + Ollama batch (loopback, moins d’exposition).
Comparatif rapide
| Dimension | PyTorch MPS | MLX |
|---|---|---|
| Adéquation équipe | Ingénieurs torch, écosystème étendu | Équipes Apple Silicon d’abord, export MLX maîtrisé |
| Boucle batch | Patterns DataLoader, nombreux exemples | Contrôle Python léger autour de MLX |
| Empreinte opérationnelle | RSS plus élevé ; garde-fous pour paralléliser | Souvent plus frugal ; discipline mémoire explicite |
Taille de micro-lot, sessions concurrentes et pics de mémoire unifiée
Un seul pool : B, séquence, caches KV, tampons CPU et sessions parallèles (états framework dupliqués) additionnent les pics.
Protocole : warm-up, montée de B jusqu’à pression ou falaise de pas ; journaliser RSS et p95. 16 Go : une session dominante + superviseur léger. 24 Go : deux sessions si plafonds prouvés.
Parallélisez via la file et des plafonds, pas par sur-sessions GPU aveugles — sinon gigue perçue comme timeouts aléatoires.
Timeouts de file, relances et échelle de dégradation
Deux timeouts : attente en file vs calcul par batch — ne pas les fusionner.
Dégradation : réduire B, contexte, modèle plus petit, résultat partiel + jeton. Échecs → dead-letter ; voir DLQ, backoff, webhooks.
HTTP : deadlines client = plafond serveur + RTT. SSH intercontinental : gigue ; préférer un agent local qui consomme la file sur le Mac.
Nœuds régionaux et latence du plan de contrôle
Le calcul on-chip est comparable pour un même SKU ; les écarts JP / KR / HK / SG / US Ouest viennent du staging des poids et des allers-retours données. Colocalisez nœud et stockage dominant pendant la fenêtre batch.
Latence & TCO : journée vs mois si warm-up long. RTT : surtout tuning interactif ; nuit : débit entrant et marge disque APFS.
Matrice de décision paramétrée
Recopiez ce tableau dans votre runbook interne et remplacez les symboles par des chiffres issus de vos benchmarks. Gardez les unités explicites (secondes, jetons, lignes).
| Levier scénario | Symbole | M4 16 Go — point de départ | M4 24 Go — point de départ | Note de politique |
|---|---|---|---|---|
| Micro-lot max (lignes / images) | B | Fixer B pour résident ≤ ~11–12 Go après marge OS | Fixer B pour résident ≤ ~18–20 Go avant sessions parallèles | N’élargir B qu’après mesure en régime établi post warm-up |
| Sessions GPU concurrentes | S | S = 1 dominante (+ superviseur minimal optionnel) | S = 1–2 si plafond indépendant par session | Préférer la profondeur de file au fan-out aveugle |
| Timeout d’attente en file | Wq | 30–120 s (interactif) ; 5–15 min (nuit) | Même ordre ; adapter au budget de relances | Wq court si replanification multi-nœuds |
| Timeout de calcul par batch | Wc | 2× p95 du pas + marge compilation modèle | Identique ; marge supplémentaire si B large | Toujours dissocier Wq et Wc |
| Relances max avant DLQ | R | R = 3 avec backoff exponentiel et jitter | R = 3–5 si uploads WAN instables | Plafonner les tentatives ; jamais de boucle infinie |
| Choix de pile | F | F = MPS si chemin torch ; sinon MLX si export OK | Identique ; 24 Go permet un B ou S un peu plus large | Documenter F par version d’artefact modèle |
Traitez les symboles comme des paramètres vivants : relancez la montée en charge lors d’une montée de version torch, d’un changement de distribution des séquences ou d’un changement de région.
Liens internes et sitemap (pour éditeurs)
Navigation par scénario (données, TCO, files, RAM unifiée), pas seulement par framework.
Publication. Cartes index : frontend/fr/blog/assets/data/blog.json. Crawlers : URL + lastmod dans frontend/fr/blog/sitemap.xml (référencé par frontend/sitemap.xml). hreflang : version EN homologue.
FAQ
Puis-je mixer MLX et PyTorch sur un même Mac ? Oui, mais traitez-les comme des sessions distinctes avec budgets mémoire distincts. N’attendez pas une partition type VRAM discrète.
MPS couvre-t-il toutes les opérations torch de mon entraînement ? Pas toujours ; construisez un chemin inférence seul et validez sur les versions exactes de macOS et torch de l’image louée.
Premier signe d’une mauvaise région ? Des heures perdues à transférer des artefacts avant que l’utilisation GPU ne monte — corrigez le staging avant d’optimiser B.
Synthèse
MPS pour torch existant ; MLX pour exports Apple-first et batch serré. Les deux : mémoire unifiée et timeouts explicites. La matrice fige un contrat ops ; TCO / région et téléchargements évitent les goulots transfrontaliers.
Pour louer de la puissance et laisser tourner l’inférence hors laptop : Tarifs, Achat (M4 16/24 Go selon B, S, timeouts), puis une semaine de mesure avant engagement mensuel.