Taux d’acceptation MTP : le seuil de 50 % détermine le bénéfice du décodage spéculatif
Un utilisateur de Reddit a testé la MTP (prédiction multi-tokens) avec mlx-vlm sur Gemma-4 (26B, 4 bits) et a constaté que les performances dépendent entièrement du taux d'acceptation des tokens candidats. Les mesures sur un M4 Max Studio montrent des seuils concrets.
Résultats des charges de travail
- Génération de code : 75 tok/s → 114,8 tok/s (1,53× plus rapide) — taux d'acceptation : 66 % des slots
- Prose longue : 75 tok/s → 71,1 tok/s (0,95×, quasiment inchangé) — taux d'acceptation : 31 % des slots
- Sortie JSON : 51,3 tok/s → 25,6 tok/s (0,50× plus lent) — taux d'acceptation : 8 % des slots
Le seuil semble être d'environ 50 % d'acceptation. En dessous, la surcharge du décodage spéculatif l'emporte sur les gains.
Détails du test : le code était « écrire quelques fonctions Python pour faire X » ; la prose longue était « rédiger un essai de 800 mots sur la monnaie papier sous la dynastie Tang » ; la sortie JSON impliquait un regroupement d'éléments par similarité en une sortie structurée.
Astuce bonus : l'utilisateur note que le respect des instructions de structure JSON de Gemma est correct, mais l'activation de la sortie structurée (json_schema) ajoute environ 20 % de surcharge. Il recommande d'accepter un JSON légèrement approximatif et de le corriger à l'exécution. mlx-vlm ne supporte d'ailleurs pas json_schema pour le décodage spéculatif.
En résumé : La MTP est excellente pour le codage local mais peut dégrader les performances pour les tâches structurées ou de prose avec de faibles taux d'acceptation.
📖 Lire la source complète : r/LocalLLaMA
👀 See Also
Correction du délai d'attente OpenClaw LLM pour le chargement de modèle à froid
Un utilisateur de Reddit a identifié et corrigé un problème de délai d'attente spécifique dans OpenClaw où les LLM locaux chargés à froid échouaient au bout d'environ 60 secondes, même avec des délais d'attente généraux plus élevés définis. La solution implique d'ajuster la configuration du délai d'attente d'inactivité du LLM de l'embedded-runner.
Correction du Gaspillage de Jetons Claude Code : Désactiver l'En-tête d'Attribution pour de Meilleurs Résultats de Cache
Définir CLAUDE_CODE_ATTRIBUTION_HEADER=false dans votre configuration shell peut améliorer le taux de succès du cache d'invites entre sessions de Claude Code de 48% à 99,98%, réduisant les coûts de traitement des invites système par 7x par session.
Les utilisateurs de Claude rapportent des sessions plus rapides en demandant des documents en markdown plutôt qu'en format Word.
Un utilisateur de Claude a découvert que demander du markdown au lieu de documents Word réduit considérablement le temps de réponse et l'utilisation de tokens. L'IA produit nativement du markdown, tandis que générer des fichiers .docx nécessite de lancer un environnement Python et d'exécuter des scripts de conversion.
Quatre fichiers locaux pour maintenir le contexte de Claude dans les projets longs
Un utilisateur de Reddit recommande de maintenir quatre fichiers Markdown—claude.md, memory.md, restart.md et backlog.md—comme mémoire externe pour Claude afin de contrer la compression de la fenêtre de contexte dans les conversations prolongées.