Rapid-MLX : un serveur d'inférence LLM pour Apple Silicon conçu pour les agents de code

Dans le monde de l'inférence locale, Apple Silicon occupe depuis longtemps une position ambiguë. La mémoire unifiée permet à un simple Mac mini de contenir un modèle quantifié de plusieurs milliards de paramètres, mais la couche de service qui l'entoure reste loin de la maturité dont jouissent les utilisateurs de CUDA. Rapid-MLX vise précisément cette lacune. C'est un serveur d'inférence open source, sous licence Apache 2.0, construit sur le framework MLX d'Apple. Il expose à la fois des points d'accès de style OpenAI et de style Anthropic : /v1/chat/completions, /v1/responses et /v1/messages. L'objectif affiché est net : des appels d'outils fiables pour les agents de code. Ce choix est révélateur, car le projet ne fait pas de la vitesse brute son seul but. Il accorde le même poids à la capacité d'un agent d'appeler des outils sans que tout s'effondre. L'installation reste volontairement banale : le paquet est sur PyPI et dans Homebrew core, donc une commande, brew install rapid-mlx, suffit, et une application de bureau ainsi qu'un miroir de modèles sont proposés.

La vitesse est l'argument phare. Selon le projet, le décodage atteint jusqu'à quatre fois la vitesse du mlx-lm d'Apple, et environ 1,5 fois sur une tâche typique, avec le même modèle et les mêmes poids. Les chiffres proviennent de Qwen3.5-9B en 4 bits sur un Mac mini M4 Pro, en décodage glouton, les deux serveurs étant laissés à leur configuration par défaut. Deux réserves s'imposent. D'abord, l'écart entre « jusqu'à 4 fois » et « 1,5 fois en moyenne » montre que le gain dépend fortement de la forme de la charge : les scénarios qui touchent le cache ou servent plusieurs requêtes simultanées en profitent le plus. Ensuite, le test ne couvre qu'un modèle, une machine et un mode de décodage, et c'est le projet lui-même qui publie. Il faut donc lire ces chiffres comme un indice de direction et les rejouer sur ses propres modèles et tâches. À son crédit, le projet publie les résultats par tâche, la méthode et les données brutes, ce qui permet une vérification externe plutôt qu'un simple chiffre marketing.

Plusieurs mécanismes se combinent derrière ces résultats. Le premier est le batching continu, qui fait avancer de nombreuses requêtes dans une même boucle de décodage afin qu'une requête longue n'affame pas les autres. Le deuxième est le cache de préfixes. Rapid-MLX tient en mémoire un cache de préfixes en arbre radix, conserve des instantanés d'état pour les modèles d'architecture hybride, l'écrit sur disque à l'arrêt et le restaure au démarrage. C'est essentiel pour les agents de code : à chaque tour, un agent renvoie un long prompt système, les définitions d'outils et toute la conversation passée, et l'essentiel de ce préfixe est identique à celui du tour précédent. Réutiliser le cache permet d'éviter l'essentiel du préremplissage. Le troisième mécanisme est un cache KV quantifié, qui échange un peu de précision contre de la mémoire pour tenir des contextes plus longs ou davantage de sessions simultanées. L'ensemble cible le profil statistique du trafic d'agents, fait de longs préfixes, de nombreux tours et d'appels répétés, plutôt que le débit de crête d'une question isolée.

L'analyse des appels d'outils est le second fil conducteur, et c'est ce qui distingue ce projet de beaucoup de ses pairs. Les familles de modèles émettent leurs appels d'outils dans des formats textuels différents : balises de style XML, fragments JSON, ou appels mêlés au texte de raisonnement. Si le serveur les analyse mal, l'agent reçoit des arguments mal formés et s'arrête en cours de tâche. Rapid-MLX embarque 27 modules d'analyse, avec un repli par détection automatique, afin que l'utilisateur n'ait pas à adapter ses réglages à la main en changeant de modèle. Le tableau comparatif du projet indique que le serveur de mlx-lm ne gère les appels d'outils que pour les modèles dont le tokenizer déclare cette prise en charge, tandis qu'Ollama et LM Studio tiennent chacun leur propre documentation et implémentation. Une réserve toutefois : le nombre d'analyseurs n'est pas un gage de fiabilité. Le vrai test consiste à retrouver un appel valide dans une longue conversation, avec des arguments imbriqués ou un flux coupé en plein appel, et chacun devra le vérifier avec son propre framework d'agent.

Replacé dans le paysage général, Rapid-MLX ne manque pas de concurrents. oMLX repose aussi sur MLX et utilise un cache KV à deux niveaux, l'un chaud en mémoire, l'autre froid sur SSD. Ollama traite par défaut une seule requête en parallèle par modèle et a ajouté un moteur MLX pour les modèles safetensors. LM Studio fournit à la fois un moteur llama.cpp et un moteur MLX. Le serveur livré avec mlx-lm ne traite qu'une requête à la fois lorsqu'un cache KV quantifié est employé. Ce tableau, établi par le projet et daté du 26 septembre 2026, montre à lui seul que la catégorie converge vite vers un jeu de fonctions commun. La différence viendra des détails d'ingénierie et du comportement mesuré. Un lecteur dont la charge est un agent de code local sur Mac devrait comparer Rapid-MLX à son installation actuelle, avec le même modèle et la même tâche, en surveillant trois valeurs : le délai avant le premier jeton, le taux de succès du cache sur une longue session et le taux d'échec des appels d'outils. Ces trois mesures disent plus sur l'adéquation que n'importe quel multiple de vitesse.