Contexte technique
Le chiffre de 115 tok/s a retenu mon attention, non pas pour une belle capture d'écran, mais parce qu'il représente une vitesse de travail viable pour l'AI automation sur Mac, et non une simple curiosité de laboratoire. Il s'agit du modèle gemma-4-26B-A4B-it-mlx-lm-4bit, un modèle MoE (Mixture-of-Experts) de 26B où environ 4B de paramètres sont actifs par token.
C'est un détail crucial. Sur le papier, le modèle est grand, mais en pratique, la charge d'inférence est nettement plus légère que celle d'un modèle dense de 26B ou 30B. C'est pourquoi la combinaison Gemma 4 + MLX sur Apple Silicon apparaît maintenant moins comme un compromis que comme une intégration IA pratique pour les scénarios locaux.
Je n'ai pas vu de benchmark officiel de Google pour cette configuration spécifique. La source ici est essentiellement la communauté : MLX-LM, une version 4 bits pour Apple, des optimisations comme TurboQuant, et des mesures de personnes qui l'utilisent en direct sur les puces de la série M. Un aspect clé de la nouvelle est que 115 tok/s est nettement supérieur à ce que beaucoup voyaient auparavant avec des pipelines mal conçus ou des modes de repli.
Et sur ce point, je ne mettrais pas tout dans le même panier. Ollama, llama.cpp, MLX-LM brut, la longueur du contexte, le prefill et le decode donnent des chiffres très différents. Si quelqu'un a vu 2 tok/s sur un MoE de 26B et a conclu que le modèle n'était « pas viable localement », ce benchmark prouve le contraire : le problème venait souvent de la stack, pas du modèle.
Autre point pratique : la variante MLX 4 bits nécessite environ 14 Go, mais il faut tout de même une marge de mémoire unifiée pour une expérience fluide. Avec 24 Go, on peut déjà l'utiliser sans problème, et sur les puces M haut de gamme, cela devient une inférence locale vraiment confortable, sans cloud, avec un bon contexte et sans attente interminable pour une réponse.
Qu'est-ce que cela change pour les entreprises et l'automatisation ?
Pour moi, la conclusion est simple : les agents locaux sur Mac ne sont plus un gadget. Si un modèle peut réellement maintenir cette vitesse de décodage, je peux commencer à construire des pipelines privés pour les documents, le support, la recherche interne et l'analyse sans avoir à envoyer systématiquement les données à l'extérieur.
Les gagnants sont les équipes qui privilégient la vitesse, la confidentialité et des coûts prévisibles. Les perdants sont principalement les scénarios basés sur le cloud où de petites requêtes transitent par une API externe coûteuse par pure inertie.
Mais il y a un piège que je vois régulièrement dans les projets clients : un benchmark rapide ne garantit pas à lui seul un bon système. Il faut une architecture IA appropriée, un routage des tâches, une gestion du contexte, une mise en cache et une compréhension des points forts d'un modèle local par rapport à l'utilisation d'un service externe. Chez Nahornyi AI Lab, nous construisons ce genre de systèmes pour des processus réels, pas seulement pour des démos impressionnantes.
Si vous envisagez une AI implementation sans dépendance au cloud, je vous suggère d'examiner sobrement votre stack : que peut-on exécuter localement, où peut-on réduire la latence et comment assembler le tout en un système d'automatisation fonctionnel ? Chez Nahornyi AI Lab, c'est généralement par là que je commence, car Vadym Nahornyi n'aime pas vendre de la magie quand une entreprise a simplement besoin d'un résultat fiable.