1. Pain split : le décodage domine les sorties longues
(1) Optimisation du mauvais segment : les équipes évaluent le TTFT mais expédient des charges de travail dominées par le décodage long (suite du code, rapports). Le décodage spéculatif ébauche les jetons avec un petit modèle et les vérifie en parallèle avec la cible ; si le décodage est court, les frais généraux fixes engloutissent la victoire. (2) Inadéquation du brouillon : lorsque le brouillon et la cible divergent, les rejets augmentent et vous pouvez être plus lent qu'un décodage naïf alors que les GPU semblent occupés. (3) Dérive de la configuration : mlx-lm et la pile MLX ont évolué rapidement en 2026 – sans versions gelées + traces P95, vous ne pouvez pas expliquer « rapide la semaine dernière, lent aujourd'hui ».
2. Matrice : quel signal répond à quelle question ?
| Métrique | Question | Pratique 2026 |
|---|---|---|
| Taux d'acceptation | Le projet et l'objectif sont-ils alignés ? | Contextes de bucket court/moyen/long ; exécutez 200 étapes chacune ; si l'acceptation reste <0,45, arrêtez d'abord d'élargir les brouillons |
| Tok/s stables (décodage) | La spéculation bat-elle l'autorégression ? | Lâchez les premiers 64 jetons d'échauffement ; mesurer la pente sur 512 à 2 048 jetons ; comparez P50/P95 et spéculatif |
| Mémoire unifiée maximale | Risque d'échange final ? | Surveiller la pression de la mémoire et échanger des fichiers ; si le swap reste >1,5 Go, réduisez la simultanéité avant de poursuivre des spéculations plus larges |
| vs llama.cpp Metal | Écosystème vs pile Apple native | Même quant + plafond de contexte ; voir sur site la Matrice MetalRT / MLX / lama.cpp |
3. Runbook en cinq étapes
- Freeze triple : versions mlx-lm + mlx, empreinte digitale du poids cible, lignage préliminaire (même petit quant de la famille).
- Charges scriptées : continuation du code (forte ramification), mémo technique (moyen), finition de la traduction (faible), chacun avec un plafond de jetons fixe.
- Référence d'abord : spéculatif désactivé ; capturer le pré-remplissage/décodage, tok/s ; conserver les noms de fichiers journaux bruts.
- Grille à variable unique : largeur de tirage, température, top-k – un bouton à la fois pour que l'attribution reste honnête.
- Note de régression : publier le plancher d'acceptation, le plancher de tok/s, le plafond d'échange sur le wiki ; les données datant de plus de deux semaines sont obsolètes.
4. Numéros de planification citables
Numéros de support que vous devez re-mesurer sur votre matériel :
- Lorsque le décodage occupe >65 % du temps GPU et que l'acceptation se situe entre 0,55 et 0,72, les chemins spéculatifs affichent plus souvent des tok/s nets positifs.
- Si la largeur de lot supplémentaire augmente la mémoire maximale de >12 % et que les échanges sont ≥3 fois par semaine, réduisez la simultanéité ou l'essai sur un Mac distant de classe 128 Go.
- Envoyez au moins trois numéros au service d'approvisionnement : acceptation P50, décodage P95, échange de pointe ; le fait d'en manquer un met fin à l'histoire. Voir l'acceptation Ollama+MLX et l'API locale + lancé.
5. Matrice de déchargement Mac à distance
La spéculation n'est pas un moyen de contourner la physique de la mémoire unifiée ; il est groupé sur le chemin de décodage. Utilisez ce tableau signal → action dans les revues hebdomadaires.
| Signal | Action |
|---|---|
| Acceptation <0,42après réglage | Revenir à l'autorégression ou modifier la famille de brouillon ; n'élargissez pas aveuglément les fenêtres de devinettes |
| IDE + navigateur + média simultanés, latence de queue pointue | Déplacer le lot à contexte long vers un nœud Apple Silicon distant dédié ; lire le Guide Mac à distance SSH/VNC |
| Passerelle de production, pas un essai solo | Traitez le service compatible mlx-lm OpenAI comme entrée principale ; spéculatif en tant que indicateur de fonctionnalité avec quotas et métriques |
| Reproductibilité inter-équipes | Exécution nocturne sur un Mac distant image épinglée/préfixe de brassage ; éviter les débats incomparables sur « mon ordinateur portable semble plus rapide » |
6. FAQ
Le décodage spéculatif modifie-t-il la sémantique ? Les implémentations correctes ne devraient pas le faire ; si l'échantillonnage diverge énormément, vérifiez d'abord les versions de température/top-p et du noyau par rapport à la ligne de base. Les brouillons doivent-ils être de la même série ? La même famille de tokenizer est la valeur pragmatique par défaut ; les projets inter-familles nécessitent un travail d’alignement et davantage d’échantillons de régression. Mode batterie ? Branchez toujours et désactivez la faible consommation pour les tests d'acceptation.
Conflit avec le chemin Ollama 0.19 MLX ? Pas en soi, mais évitez les combats à deux voies sur les caches et les ports : une passerelle unique pour la production, un deuxième chemin pour l'A/B contrôlé uniquement.
7. Analyse : la télémétrie d'acceptation est l'atout rare
Les publications de référence sont abondantes en 2026 ; le harnais scripté + graphiques P95 + preuves d'échange sont rares. Le décodage spéculatif ajoute une machine à états brouillon → vérification → restauration : vous devez tracer l'acceptation au fil du temps, sinon le réglage ressemble à de la superstition.
Les équipes créatives partagent une mémoire unifiée avec les outils d'évaluation et NLE ; échanger des queues fait plus mal que la moyenne des tok/s. Un Mac distant dédié achète l'isolation : machine interactive pour la révision, distante pour le décodage long. Si vous exécutez déjà un service selon API locale + launchd, traitez la spéculation comme un indicateur de fonctionnalité convivial pour la restauration, et non comme une valeur par défaut silencieuse.
Le taux de désabonnement des fournisseurs sur les piles mlx-* signifie que les mises à niveau peuvent briser les hypothèses. Stockez les empreintes digitales de poids, les versions mlx-lm, la largeur de dépouille et les seuils d'acceptation dans le même enregistrement de modification pour minimiser les différences lorsque les régressions surviennent – moins cher que l'achat de matériel d'urgence sans données.
8. Fermer : Mac est idéal pour expérimenter ; la production a encore besoin d'un budget mémoire
(1) Limites : la spéculation ajoute du travail de vérification et des conflits de bande passante ; une faible acceptation ajoute à la complexité ; les ordinateurs portables effectuent plusieurs tâches en échange de queues.
(2) Pourquoi le Mac distant est utile : cohérence du chemin Apple Silicon + Metal ; Épinglage et isolation plus faciles pour le décodage par lots.
(3) Ajustement MACGPU : si vous souhaitez un essai à faible engagement sur une mémoire unifiée élevée avant les investissements, MACGPU loue des nœuds Mac distants avec des plans/aide publics – CTA ci-dessous (pas de connexion).