Qwen 3.5 sur MacBook Pro : huit serveurs locaux comparés pour le travail en équipe

Faire tourner de gros modèles en local sur Mac n'est plus depuis longtemps un jouet pour passionnés, mais le cas de Qwen 3.5 35B montre qu'il y a loin entre « ça démarre » et « ça convient pour une API d'équipe ». L'auteur a pris un MacBook Pro M2 Max avec 64 Go de mémoire et a évalué non pas le modèle lui-même, mais l'infrastructure qui l'entoure : quel serveur MLX tient une charge de travail réelle, n'affiche pas de beaux chiffres dans ses logs et ne s'effondre pas dès que deux utilisateurs arrivent en même temps.

Pour le test, un banc d'essai en Python a été construit et huit serveurs locaux y ont été soumis, tous présentés comme un moyen rapide de monter une API au-dessus de modèles MLX sous macOS.

Le test ne reposait pas sur une seule question commode. Il a utilisé un ensemble de huit prompts de types et de longueurs variés, dont des tâches de niveau AIME et des entrées longues allant jusqu'à 52 mille tokens. Chaque scénario a été exécuté cinq fois pour lisser les pics aléatoires et obtenir une image plus honnête de la latence, de la vitesse de génération et du comportement global sous charge. L'accent a été mis non pas sur la vitesse de pointe en laboratoire, mais sur le comportement dans un régime proche de l'usage réel : avec réponse en streaming, couche réseau et conditions de mesure reproductibles.

Avec un seul utilisateur, il n'y a presque pas eu de suspense : les trois premiers ont obtenu des résultats proches et, sur de courtes sessions, l'écart entre eux paraît plus cosmétique que réel. C'est précisément pourquoi les promesses marketing des README induisent si facilement en erreur. À ne regarder qu'une requête isolée, on a l'impression que presque n'importe quel serveur MLX actuel suffit pour un usage quotidien. Mais cette conclusion s'effondre dès que le modèle local passe d'outil personnel à service d'équipe, où les requêtes commencent à se chevaucher dans le temps.

L'étape la plus parlante du test était la charge parallèle de deux requêtes. C'est là que l'écart réel entre les solutions est apparu. Quatre frameworks sur six finissaient en file d'attente et traitaient les requêtes presque séquentiellement, alors qu'ils avaient l'apparence du multithread. Un autre serveur ne conservait le parallélisme que sur le papier et tombait à un coefficient de 0,85x : la deuxième requête gênait plus qu'elle n'aidait à exploiter le matériel. Un seul participant a affiché une véritable accélération de 2,17x, ce qui ressemble enfin à un comportement acceptable pour une API locale d'équipe, où il ne s'agit pas seulement de répondre vite à un utilisateur, mais de tenir plusieurs appels sans chute spectaculaire.

En chemin, des problèmes plus importants que les chiffres secs d'un tableau ont surgi. À un endroit, l'auteur est tombé sur un attention quadratique qui, en 2026, peut encore dégrader fortement le comportement sur les contextes longs. Ailleurs, sur des 14 000 tokens/sec fantômes, dus non pas à une optimisation magique mais à une seule ligne du parseur SSE qui faussait la mesure.

L'auteur mentionne aussi un processus zombie qui laissait environ 20 Go de RAM occupés, un risque que les README préfèrent taire. Pour qui prévoit une production locale, ce ne sont pas des broutilles : ces bugs nuisent à la prévisibilité du service, à la supervision et au coût de maintenance plus qu'un écart de quelques pour cent en vitesse brute.

La valeur pratique de ce travail tient à ce qu'il déplace l'attention des belles promesses vers les scénarios d'usage. Si un développeur seul a besoin du modèle pour des requêtes ponctuelles, il peut regarder la simplicité de mise en route et la vitesse de base. Mais s'il s'agit d'une API d'équipe, avec parallélisme, contextes longs et besoin de récupérer vite après une panne, choisir un serveur d'après son README devient risqué.

Ce benchmark rappelle une chose simple : la pile locale pour Qwen 3.5 doit être évaluée comme une infrastructure, pas comme une démo. Sinon, on peut se retrouver avec un système qui paraît « rapide » dans les tests isolés et qui, en usage réel, transforme un MacBook puissant en une coûteuse file d'attente de requêtes.