Qwen 3.5 sur MacBook Pro : Comparaison de huit serveurs locaux pour le travail d'équipe

L'exécution locale de grands modèles sur Mac a cessé d'être un jouet pour les enthousiastes il y a longtemps, mais l'histoire avec Qwen 3.5 35B montre qu'il existe une grande distance entre « ça marche » et « ça fonctionne comme une API d'équipe. » L'auteur a pris un MacBook Pro M2 Max avec 64 GB de RAM et a testé non pas le modèle lui-même, mais l'infrastructure autour : quel serveur MLX peut gérer une charge de travail réelle, ne produit pas simplement de jolis chiffres dans les logs et ne s'effondre pas dès que deux utilisateurs arrivent simultanément.

Pour le test, ils ont construit un harnais Python séparé et exécuté huit serveurs locaux positionnés comme un moyen rapide de lancer une API sur des modèles MLX sur macOS. La validation ne s'est pas basée sur une seule question pratique, mais sur un ensemble de huit prompts de types et de longueurs différentes, incluant des tâches de niveau AIME et des entrées longues de jusqu'à 52 mille tokens. Chaque scénario a été exécuté cinq fois pour éliminer les pics aléatoires et obtenir un tableau plus honnête de la latence, de la vitesse de génération et du comportement général sous charge.

Un accent particulier a été mis sur l'évaluation non pas de la vitesse de pointe en laboratoire, mais du comportement du système dans des conditions proches du travail réel : avec des réponses en streaming, une surcharge réseau et des conditions de mesure répétables.

En mode single-user, il y avait peu de suspense : les trois premiers ont montré des résultats similaires, et sur les courtes sessions, la différence entre eux semblait plutôt cosmétique. C'est précisément pour cela que les promesses marketing dans les fichiers README trompent facilement. Si vous ne regardez qu'une seule requête, il semble que presque n'importe quel serveur MLX moderne soit déjà assez bon pour le travail quotidien. Mais cette conclusion s'effondre immédiatement dès que le modèle local se transforme d'un outil personnel en service pour une équipe, où les requêtes commencent à se chevaucher dans le temps.

L'étape la plus révélatrice du test—charge parallèle de deux requêtes. C'est là qu'un écart réel entre les solutions a émergé. Quatre frameworks sur six ont essentiellement basculé vers une mise en file d'attente et ont traité les requêtes presque séquentiellement, bien qu'ils semblent toujours multi-thread en surface.

Un autre serveur a maintenu le parallélisme uniquement formellement et a dégringolé à un coefficient de 0,85x, ce qui signifie que la deuxième requête entravait plutôt qu'aidait à utiliser le matériel. Un seul participant au test a montré une accélération honnête de 2,17x, ce qui ressemble déjà à un comportement adapté pour une API d'équipe locale, où il importe non seulement de répondre rapidement à un utilisateur, mais de gérer plusieurs requêtes sans dégradation drastique.

En cours de route, des problèmes ont émergé qui importent plus que les chiffres secs dans un tableau. À un endroit, l'auteur s'est heurté à une attention quadratique, qui en 2026 peut toujours dégrader considérablement le comportement sur les contextes longs. Dans un autre—phantom 14 000 tokens/sec qui est apparu non pas par optimisation magique, mais par une seule ligne dans un analyseur SSE qui a faussé la mesure. À part, il vaut la peine de mentionner un processus fantôme qui a laissé environ 20 GB de RAM occupée, bien que les READMEs préfèrent rester silencieux sur un tel risque.

Pour ceux qui planifient une production locale, ce ne sont pas des détails mineurs : de tels bugs impactent la prévisibilité du service, la surveillance et les coûts de support bien plus que des différences de quelques pourcentages en vitesse brute.

La valeur pratique de ce travail réside dans le déplacement de l'accent des belles promesses vers les cas d'utilisation réels. Si un modèle est nécessaire par un développeur pour des requêtes occasionnelles, vous pouvez regarder la simplicité du déploiement et la vitesse de base. Mais si nous parlons d'une API d'équipe avec parallélisme, contextes longs et nécessité de récupération rapide après défaillance, choisir un serveur basé sur README est déjà dangereux.

Ce benchmark montre une chose simple : la stack locale pour Qwen 3.5 doit être évaluée comme une infrastructure, pas comme une démo. Sinon, vous pouvez vous retrouver avec un système qui semble « rapide » sur des tests simples mais qui, en utilisation réelle, transforme un MacBook puissant en une file d'attente coûteuse de requêtes.