1. Découper la douleur : sans acceptation, ce n'est pas une optimisation
(1) Emprunter les gros titres : les posts citant ×1,6 en prefill ou ×2 en decode supposent quantification, longueur de contexte et batch 1 précis. Changez la famille de modèle ou montez au plafond prod et la courbe bouge aussitôt. (2) Mémoire unifiée finie : sous ~32 Go, l'IDE, le navigateur et l'assistant résident font apparaître tôt swap et compression ; dès que la pagination disque domine, le débit MLX s'effondre. (3) Doubles piles : Ollama pour le confort et mlx-lm derrière une passerelle OpenAI dupliquent caches, ports et jobs launchd, et le debug mange le gain.
Les chemins Metal et Neural Engine sur puces M récompensent une bande passante mémoire stable. Le prefill est plutôt compute-bound ; le decode devient bandwidth-bound plus vite que les feuilles de calcul ne le prédisent. Sans séparer les phases, on mal règle température, batching et concurrence. Prefill = temps jusqu'au premier token ; decode = pente après warm-up, pas un FPS unique.
On oublie souvent l'enveloppe thermique des laptops scellés. Un bench de quinze minutes sur secteur peut diverger de dizaines de pourcents des profils économie d'énergie. Documentez alimentation, courbe ventilateur et température ambiante comme les versions logicielles.
En 2026, documentez aussi le mode d'exposition de l'API : streaming activé ou non change la perception TTFT côté client et la pression file côté serveur. Les équipes confondent latence réseau et latence decode quand le proxy bufferise. Votre feuille d'acceptation doit dire explicitement si vous mesurez le premier byte HTTP ou le premier token applicatif.
2. Matrice métrique : ce que chaque mesure prouve
| Métrique | Question répondue | Pratique 2026 |
|---|---|---|
| TTFT / Prefill | Si le Neural Engine et la bande passante alimentent le premier token | Longueur de prompt et sampling figés ; 30 essais ; P50/P95 ; exclure le tout premier run à froid |
| Débit tok/s stable | Si les longues réponses restent rapides, pas seulement le burst initial | Forcer ≥512 tokens générés ; retirer les 64 premiers en warm-up ; mesurer la pente médiane |
| Pression mémoire | Si swap ou compression fausse la latence | Observer pression Moniteur d'activité et croissance du fichier swap ; swap soutenu >2 Go = signal rouge |
| Ollama vs service mlx-lm | Quelle surface pour bacs à sable perso vs API d'équipe | Multi-locataires et metering : passerelle mlx-lm ; itération GUI : Ollama |
3. Runbook en cinq étapes
- Geler les variables : build Ollama, fiches modèle, quantification, plafond de contexte, concurrence ; une dimension par expérience.
- Échelles de prompts : court (~256 tokens), moyen (~2k), proche prod ; éviter les seules répliques d'une ligne.
- Mesurer Prefill : TTFT via API streaming ; exclure le premier run post-téléchargement.
- Mesurer Decode : diviser tokens streamés par le temps mural ; sans compteur, fixer la longueur de sortie et déduire.
- Publier une note d'une page : Prefill P95, médiane decode, pic swap, CPU oisif ; marquer données périmées après 14 jours sans retest.
4. Seuils de planification citables
Chiffres pour slides de revue :
- Une session Ollama interactive plus IDE tient souvent ; un second démon toujours actif suppose en général ≥48 Go de marge mémoire unifiée sur laptops créatifs.
- Si l'inférence locale dépasse 30 h/semaine et que des pics swap surviennent plus de trois fois par semaine, un nœud distant dédié bat souvent des upgrades RAM incrémentaux.
- Un rapport d'acceptation exige trois nombres : Prefill P95, Decode P50, pic swap ; sans l'un des trois, les discussions achat et sécurité bloquent. Couplez avec l'analyse mémoire dans cette matrice mémoire Mac LLM.
5. Matrice d'offload Mac distant
Le distant n'est pas un pansement CPU : il isole la bande passante mémoire pour l'inférence pendant que le portable garde IDE, communications et outils créatifs. Servez-vous du tableau comme notes de réunion.
| Signal | Action |
|---|---|
| Besoin d'essais classe 70B sur machines 16–32 Go | Petits modèles en local pour le câblage ; gros checkpoints sur Apple Silicon distant 128 Go avant CAPEX |
| L'équipe exige un ingress OpenAI-compatible avec concurrence | Faire de mlx-lm ou de la passerelle la source de vérité ; garder Ollama en bac à sable perso |
| Le jitter suit le swap, pas le RTT | Réparer mémoire ou concurrence d'abord ; un hôte distant sous la même pression déplace seulement la douleur |
| Les previews Metal natives (couleur, ProRes) comptent | Préférer Apple Silicon distant aux îlots GPU Linux pour réduire les frictions de format ; voir le guide SSH vs VNC |
6. FAQ
Plus lent après mise à jour ? Première compilation de graphe, index Spotlight, I/O Time Machine ; laisser 10 minutes puis retester. Rosetta ? Rester arm64 de bout en bout pour des comparaisons valides. Rollback ? Archiver installateurs, manifestes modèle et variables OLLAMA_* ; épingler la semver plutôt que latest. Voisins bruyants ? Fermer les jobs collègues pendant l'acceptation ou isoler les locataires sur l'hôte distant. Mode batterie ? Brancher et désactiver l'économie d'énergie pour les sessions de bench.
7. Plongée : les droits d'acceptation sont l'actif 2026
La maturité MLX sur Apple Silicon est documentée, mais la qualité livrée dépend de scripts reproductibles, pas des tok/s de brochure. Ollama élargit l'accès MLX et amplifie les anecdotes. Sans P95 prefill et chronologies de swap, la finance et la sécurité n'approuvent pas le spend distant.
Les studios créatifs partagent la mémoire unifiée entre NLE, étalonnage et bacs LLM locaux. Les nœuds Apple Silicon distants achètent des distributions de latence prévisibles : interactif local, batch externe. Si vous avez suivi le guide launchd mlx-lm, cette matrice transforme les victoires perso en preuves d'organisation.
Les piles MLX changent encore de façon cassante ; co-versionnez modèles, formats de quantification et builds Ollama dans un journal unique pour minimiser les diffs au prochain release. Formalisez froid vs chaud : les chiffres marketing oublient souvent le premier run après changement de modèle, alors que les SLO prod le subissent. Indiquez si les caches de graphe persistent et comment ils sont invalidés.
Les clients de streaming masquent les compteurs de tokens ; imposez des journaux serveur ou un proxy qui s'aligne sur le temps mural. Sinon les incidents concluent à « un problème réseau » quand le goulet est decode. Pour les passerelles mlx-lm, des identifiants de requête et des champs de latence (file, prefill, decode) rendent les post-mortems actionnables.
La matrice ne cite RTT que lorsque le réseau domine vraiment : double encapsulation VPN, surcoût TLS, peering régional. Si les queues d'histogramme grossissent sans corrélation ping, le Mac distant n'est pas une intuition mais un test structurel : répéter les charges sur une configuration mémoire identique et comparer les courbes de swap. Offload ne devient topologie durable que si distant reste propre quand local swap.
Gouvernance : deux surfaces d'inférence impliquent deux chaînes de correctifs, deux surfaces CVE et deux modèles d'astreinte. La frontière Ollama contre mlx-lm est une question d'exploitation : une surface par environnement réduit la dérive. L'acceptation est le levier qui rend cela exécutable.
Le choix de quantification affecte asymétriquement prefill et decode : des quants agressifs peuvent accélérer le prefill pendant que le decode souffre d'une pression mémoire différente sur les activations intermédiaires. Documentez le manifeste (bits, groupement, jeu de calibration), pas seulement le nom de fichier. Sans alignement manifeste, marketing et engineering parlent de modèles « identiques » qui ne le sont pas.
Les échelles de prompts doivent inclure des schémas d'outils réalistes : de grandes listes de fonctions JSON déplacent la longueur de prompt et donc le TTFT plus qu'un simple paragraphe. Ajoutez une série « sans outils / avec outils moyens / tooling de prod » pour les équipes agents. Sinon vous sous-estimez le prefill réel des tickets.
La parallélisme est un multiplicateur caché du cache KV : deux sessions simultanées peuvent consommer plus de résident que la somme de deux runs isolés si le prefetching est agressif ou si des caches sont partagés. Mesurez 2–3 clients concurrents avec le même profil de prompt et notez s'il existe une file équitable. Sans cette série, l'achat de nœuds distants repose sur des hypothèses financières fausses.
Les sauvegardes Time Machine et l'indexation Spotlight faussent encore les benches : I/O disque et mémoire ressemblent à du throttling thermique. Réservez des créneaux d'acceptation avec jobs de backup suspendus et tâches de fond listées, comme pour interdire un gros npm install pendant la mesure.
Louez un Mac distant et rejouez la même échelle de benchmarks avant de basculer le routage. Sinon vous mélangez drift de release et drift topologique. Exigez mêmes build Ollama et mêmes manifestes modèle des deux côtés pour une comparaison nette.
8. Clôture : Ollama sur laptop est un début, pas toute la surface prod
(1) Limites : le swap allonge les queues ; les doubles piles ajoutent de la friction gouvernance ; grands contextes et multitâche déclenchent du throttling thermique. (2) Pourquoi Mac distant : Apple Silicon et mémoire unifiée alignent chaînes IA et média ; des nœuds dédiés retirent la contention batch des machines interactives. (3) MACGPU : louez des Mac distants très memoire pour valider les matrices avant d'acheter des stations ; le CTA ci-dessous pointe vers des offres publiques et de l'aide sans login.