Autoresearch pousse Qwen3.5-397B à 20,34 tok/s sur M5 Max via le streaming SSD

Configuration matérielle et du modèle
L'expérience a été menée sur un MacBook Pro M5 Max avec 128 Go de mémoire unifiée et un GPU à 40 cœurs. Le modèle utilisé était Qwen3.5-397B-A17B avec des experts Q3-GGUF (précision mixte Unsloth IQ3_XXS/IQ4_XS), une intégration Q8_0 et une tête de langage Q6_K. Le modèle occupe 209 Go sur le disque—4 fois plus que la RAM disponible—nécessitant que tout soit diffusé en continu depuis le SSD.
Résultats de performance
La vitesse de décodage a atteint 20,34 tok/s avec un pré-remplissage à 5,52 tok/s. Cela représente une amélioration de 2x par rapport au point de départ du M5 Max de 10,61 tok/s et une amélioration de 4,67x par rapport au point de référence original de Dan Woods de 4,36 tok/s sur le matériel M3 Max.
Méthodologie
Le chercheur a utilisé la méthodologie de boucle de recherche automatique du projet flash-moe de Dan Woods, en l'exécutant avec Claude Code (Anthropic) pour mener et évaluer systématiquement 36 expériences. Chaque expérience a été enregistrée avec les résultats avant de passer à la suivante, avec un contrôle qualité automatique via des seuils de perplexité pour détecter les régressions. La collaboration humain-IA impliquait que le chercheur dirigeait la recherche et prenait les décisions scientifiques tandis que Claude Code implémentait et évaluait sous direction.
Fondement technique
Ce travail s'appuie sur l'article original flash-moe de Dan Woods et la bifurcation d'Anemll, qui est un moteur d'inférence pur C/Metal pour exécuter Qwen3.5-397B via streaming SSD sur Apple Silicon. La bifurcation d'Anemll a ajouté la prise en charge des experts Q3-GGUF essentielle à ces résultats, le chercheur ayant ajouté des optimisations supplémentaires au niveau Metal.
Optimisations efficaces
- 16 threads d'E/S + cache-io-split=4 : Au lieu de lire chaque fichier de poids d'expert comme un seul bloc séquentiel, divisé en 4 lectures parallèles alignées sur les pages touchant simultanément différents canaux SSD. +1,5 tok/s
- Prédiction temporelle des experts : Découverte d'une corrélation de routage inter-token de 27 %, chevauchant les lectures SSD avec le calcul GPU. +4,3 tok/s
- Experts Q3-GGUF (Unsloth IQ3_XXS/IQ4_XS) : Charge utile plus petite avec Q3 comme point idéal. Meilleure perplexité que le 4 bits (5,58 vs 5,62) tout en étant 23 % plus petit. +2,3 tok/s
- Pré-encodage CMD2 : Élimine un écart de soumission de 30 μs par couche. +0,44 tok/s
- Noyau de projection Q/K/V fusionné : Lit le vecteur d'entrée une fois au lieu de trois fois (optimisation GPU Metal). +0,76 tok/s
- Pré-encodage CMD2 étendu à toutes les couches d'attention complète : +0,47 tok/s
Remarque : Les gains ne s'additionnent pas parfaitement car certaines optimisations interagissent entre elles.
Approches infructueuses
La recherche a eu un taux d'abandon de 78 %. Les approches infructueuses comprenaient : la quantification QJL 1 bit (perplexité 5647, catastrophique), le ternaire 2 bits avec 84 % de parcimonie des poids (effondrement du modèle), le routage d'experts K=3 (effondrement de la qualité), la prédiction inter-couches (taux de réussite de 0 %), le déchargement NAX (la surcharge de remplissage des tuiles a annulé les gains), et les experts MLX 2 bits (plus rapides isolément mais moins bonne perplexité et aucun avantage de vitesse une fois la prédiction temporelle appliquée à Q3).
Limitations et travaux futurs
La recherche est limitée à une seule plateforme matérielle, donc les résultats peuvent ne pas être généralisables. La quantification Q3 à cette échelle se dégrade sensiblement sur la génération de textes longs, produisant des artefacts sur les réponses plus longues malgré une qualité acceptable pour les tâches courtes. La qualité a été évaluée uniquement via la perplexité, et non via des benchmarks standardisés comme MMLU ou GPQA. Il s'agit d'un projet de recherche sur la vitesse, pas d'une affirmation de qualité de production.
Une découverte surprenante : le Neural Engine (ANE) d'Apple était complètement inactif pendant l'inférence, consommant 0 W malgré une offre de 38 TOPS de calcul. Le problème est que l'inférence MoE doit décider dynamiquement quels experts activer, tandis que l'ANE ne fonctionne qu'avec des graphes pré-compilés statiques. Il pourrait y avoir une opportunité pour le pré-remplissage par lots.
📖 Read the full source: r/LocalLLaMA
👀 See Also

RTX 5080 16 Go : Qwen3.6 35B MoE en contexte 128k — 56 tok/s, et pourquoi MTP n’aide pas
De nouveaux benchmarks montrent que Qwen3.6 35B MoE sur RTX 5080 16GB atteint 56 tok/s en génération avec un contexte de 128k. Le MTP (Multi-Token Prediction) le ralentit de 23% en raison de la pression VRAM qui pousse les couches expertes vers le CPU.

Porte d'Attention : Le Défi de l'Oubli Sélectif dans les Systèmes de Mémoire IA
Un développeur construisant un système de mémoire à cinq couches pour un bot OpenClaw identifie une limitation clé : les approches actuelles se concentrent sur le rappel mais manquent de mécanismes pour supprimer les informations non pertinentes pendant les tâches ciblées, similaire au filtrage attentionnel humain.

OpenClaw 2026.4.2 et 2026.3.31 interrompent les connexions aux LLM locaux.
Les versions 2026.4.2 et 2026.3.31 d'OpenClaw provoquent des délais d'attente de connexion aux instances Ollama hébergées localement. Le problème survient lors de la connexion à des machines Ubuntu exécutées localement, avec des journaux d'erreur indiquant des délais d'attente de requêtes LLM et des décisions de basculement.

Cowork peut utiliser une instance Chrome sur une autre machine sans que vous le sachiez
Un utilisateur de Reddit a découvert que Cowork peut exécuter des tâches de navigation en utilisant une instance Chrome sur une machine distante (Windows) jumelée via une extension, signalée comme isLocal: false — ce qui n'est pas documenté.