1. Découpage : le contrat d’exécution avant le benchmark
(1) Moteur vs packaging : une même GGUF n’a pas la même courbe mémoire sous llama.cpp et MLX. Les piles type MetalRT visent Metal direct ; MLX côté Python expose d’autres leviers.(2) Pic tok/s seul : prefill et decode ne sont pas comparables ; la contention de verrous détruit les chiffres multi-utilisateurs.(3) Mémoire unifiée : sous swap, changer de topologie avant d’agrandir le modèle.
2. Trois runtimes
| Runtime | Lecture 2026 | Public / coût |
|---|---|---|
| Classe MetalRT | Metal direct sur Apple Silicon, decode et multimodalité | Pour chasseurs de decode ; chaîne d’outils jeune, versions figées |
| MLX | Aligné sur la mémoire unifiée, service dans le même dépôt Python/Swift | Plus exigeant qu’une UI one-click |
| llama.cpp | Écosystème GGUF large, nombreux exemples CLI/serveur | Très pratique sur Mac ; défauts jamais universels |
2b. Préremplissage et décodage séparés
Prefill écrit le KV, decode produit les tokens. Un « decode tok/s » sans longueur de contexte ni politique de batch est trompeur pour le RAG long.
| Phase | Métrique prioritaire | Erreur fréquente |
|---|---|---|
| Prefill / TTFT | Délai du premier token, explosion au-delà de 8K tokens | Ne mesurer que des prompts courts |
| Decode | tok/s stable, ralentissement avec la longueur | Batch trop grand → thrashing |
| Charge mixte | Pression mémoire, swap, IDE saccadé | Bench « propre » sans apps réelles |
3. Cinq étapes reproductibles
- Figeler la charge : chat, RAG, batch nuit – objectifs distincts, endpoints distincts.
- Verrouiller modèle et quantification : une GGUF/MLX de référence, puis comparer les moteurs.
- Mesure unifiée : même prompt, contexte, batch ; journaliser TTFT, decode, dérive longue session ; noter puce et version du moteur.
- Réglage par paliers : threads & ctx/batch, puis KV & parallélisme, puis changement de modèle.
- Une semaine mixte : IDE, navigateur, export ouverts ; si la mémoire rouge revient aux heures créatives, déporter la charge.
4. Chiffres de planification (non constructeur)
Pour dossiers internes :
- Au moins 8Go réservés à l’OS et aux apps résidentes avant poids et KV.
- IDE lourd + long contexte + timeline : 1–2 flux d’inférence.
- >20h/semaine à pleine charge sur portable mobile : nœud distant souvent meilleur TCO.
5. Matrice Mac distant
| Signal | Conseil |
|---|---|
| Endpoint OpenAI-compatible partagé avec audit | Quota sur nœud distant ; portable pour essais légers |
| Pression mémoire casse le montage / IDE | Déplacer l’inférence ou réduire contexte/quantification |
| Tests A/B longs sans salir la machine principale | Mac distant image fixe comme bac à sable |
| Service 24/7 | Topologie fixe + supervision sur Mac distant |
6. FAQ
Coexistence ? Oui, mais ports et bindings documentés ; doubles téléchargements saturant le SSD.Chiffres communautaires ? Rejouer avec prompt figé.Arrêt ? Trois blocages créatifs par semaine → déplacer la charge.
7. Analyse
Le sujet n’est pas le tokenizer mais le contrat d’inférence reproductible : mêmes versions, ports, auth entre dev/staging/démo. Voir aussi API MLX compatibles OpenAI.
8. Synthèse : limites du multi-moteur local et MACGPU
(1) Limites : poids, ports et dépendances se multiplient ; la mémoire unifiée se remplit de caches dupliqués ; veille et mises à jour cassent le 24/7 portable.
(2) Intérêt du distant : image reproductible pour l’inférence, portable en client léger ; charge thermique et monitoring plus simples sur un nœud Mac créatif/industriel.
(3) MACGPU : pour un endpoint compatible OpenAI prévisible et des quotas d’équipe, la location horaire d’Apple Silicon distance souvent les cycles d’upgrade locaux. Daemons MLX/llama.cpp et jobs longs sur le nœud ; CTA vers tarifs publics sans login.