Qu’est-ce que ddalcu/mlx-serve ?

Un serveur d'inférence natif en Zig qui charge des modèles MLX et GGUF sur Mac Apple Silicon et expose les API OpenAI, Anthropic et Ollama sur le port 11234. Le projet vise les utilisateurs qui veulent éviter Python et Electron, mais la licence réelle reste à vérifier.

Puis-je utiliser ddalcu/mlx-serve à des fins commerciales ?

À vérifier. La licence de ce dépôt n’entre pas dans les catégories que nous classons automatiquement : lisez son fichier LICENSE avant tout usage commercial.

ddalcu/mlx-serve est-il encore maintenu ?

Oui. Les derniers commits datent d’il y a 1 jour.

En quel langage de programmation ddalcu/mlx-serve est-il écrit ?

Principalement Zig, d’après les statistiques de langage de GitHub.

mlx-serve : serveur d'inférence LLM natif Apple Silicon en Zig

En bref

De quoi s’agit-il ?: Un serveur d'inférence natif en Zig qui charge des modèles MLX et GGUF sur Mac Apple Silicon et expose les API OpenAI, Anthropic et Ollama sur le port 11234. Le projet vise les utilisateurs qui veulent éviter Python et Electron, mais la licence réelle reste à vérifier.
À qui s’adresse-t-il ?: mlx-serve convient aux développeurs sur Mac Apple Silicon qui veulent un point d'entrée local unique pour Claude Code, le SDK OpenAI ou des clients Ollama, sans Python ni Electron, et qui acceptent de vérifier eux-mêmes la licence réelle du dépôt avant tout usage en entreprise. Il ne convient pas à ceux qui ont besoin d'un serveur Linux, d'un déploiement multi-nœuds ou d'une compatibilité API garantie sur toute la surface OpenAI.
Puis-je l’utiliser commercialement ?: À vérifier. La licence de ce dépôt n’entre pas dans les catégories que nous classons automatiquement : lisez son fichier LICENSE avant tout usage commercial.
Est-il encore maintenu ?: Oui. Les derniers commits datent d’il y a 1 jour.
En quel langage est-il écrit ?: Principalement Zig, d’après les statistiques de langage de GitHub.

Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.

ANALYSE OPEN SOURCE APPROFONDIE

Rédaction Hysen Labs · 10 septembre 2026 · ddalcu/mlx-serve

Le problème : faire tourner un LLM local sur Mac sans empiler les couches

Sur Apple Silicon, faire tourner un modèle en local implique souvent de choisir entre plusieurs mondes : MLX pour les poids natifs Apple, llama.cpp pour les fichiers GGUF, et un serveur qui expose une API compatible avec les clients existants. Chaque outil a son propre format, son propre port, ses propres variables d'environnement. mlx-serve part du constat inverse : un seul binaire, un seul port, une seule API pour les deux formats de poids. Le README annonce que le même http://localhost:11234 fonctionne avec Claude Code, le SDK OpenAI, Continue, Cursor et Open WebUI. C'est le problème visé : éviter de maintenir trois configurations pour un seul Mac. Le public visé est clair : développeurs sur Mac Apple Silicon qui veulent un serveur local sans Python à l'exécution, sans Electron, et qui utilisent déjà des outils qui parlent le protocole OpenAI ou Anthropic. Le README précise aussi que le projet s'adresse à ceux qui veulent générer images, vidéo, musique, parole et modèles 3D depuis le même serveur, ce qui élargit la cible au-delà du seul texte.

Architecture : un binaire Zig, deux moteurs d'inférence, trois surfaces d'API

Le serveur est écrit en Zig et embarqué dans l'application MLX Core. Le README indique que mlx-serve charge les modèles MLX natifs et les fichiers GGUF via llama.cpp embarqué. Deux moteurs d'inférence dans un seul processus, donc. Le serveur expose trois surfaces HTTP : OpenAI-compatible, Anthropic Messages API, et Ollama API (/api/chat, /api/generate, /api/tags, /api/embed, /api/pull). Le README mentionne aussi l'OpenAI Responses API avec transport WebSocket et l'endpoint /v1/responses/compact. Le chargement des modèles se fait à la demande par nom quand on lance mlx-serve serve : les modèles ne sont pas tous résidents en mémoire, ils sont chargés quand une requête les nomme. Le README cite la quantification du KV-cache en 4 ou 8 bits, le continuous batching, et le décodage spéculatif (PLD, drafter, MTP natif). Ces mécanismes sont annoncés comme présents, pas documentés en détail dans le README. L'application MLX Core ajoute une couche menu-bar avec chat, mode agent, client MCP et dix outils intégrés, ainsi qu'un shell d'agent sandboxé dans une VM Linux isolée. Le serveur sous-jacent reste le même binaire que celui de la CLI.

Installation : Homebrew, CLI ou compilation depuis les sources

Le README donne trois chemins. Par Homebrew : brew tap ddalcu/mlx-serve https://github.com/ddalcu/mlx-serve, puis brew install --cask mlx-core pour l'application, ou brew install mlx-serve pour la CLI et le serveur seuls. En terminal, la CLI reprend les commandes d'Ollama : mlx-serve run gemma4 télécharge Gemma 4 E4B en 4 bits, le sert et ouvre un chat dans le terminal ; mlx-serve pull qwen3.6:27b télécharge seulement, avec reprise, depuis Hugging Face ; mlx-serve list affiche ce qui est sur disque ; mlx-serve serve sert tout ce qui a été téléchargé, avec chargement à la demande par nom. Les identifiants courts, les formes org/repo de Hugging Face et les formes name:tag sont acceptés. Pour compiler depuis les sources, il faut Xcode 26.2 ou plus récent avec le composant Metal Toolchain. Le README précise la commande de secours si xcrun -sdk macosx metal --version échoue : xcodebuild -downloadComponent MetalToolchain. Ensuite : git clone --recurse-submodules, brew bundle install --file=Brewfile (cmake et webp), puis ./app/build.sh. Le README affirme que Zig, mlx et llama.cpp sont épinglés et récupérés ou compilés par le script, et qu'il n'y a pas de Python dans la chaîne de build. Le prérequis système annoncé est macOS 26.2 ou plus récent sur Apple Silicon.

Ce que le README ne dit pas : licence, versioning et surface API réelle

Le README affiche un badge License: MIT et un lien vers le fichier LICENSE. L'API GitHub du dépôt renvoie pourtant NOASSERTION comme identifiant de licence, ce qui signifie que le fichier n'a pas été reconnu automatiquement comme une licence standard, ou qu'il contient des clauses qui sortent du texte MIT. Le README mentionne aussi une ligne de tableau où la licence du projet est indiquée comme MIT, en comparaison avec LM Studio (propriétaire), Ollama (MIT) et mlx-lm (MIT). Il y a donc une contradiction apparente entre deux sources du même dépôt. Pour un usage commercial ou une redistribution, c'est le premier point à vérifier : ouvrir le fichier LICENSE et lire le texte, pas le badge. Autre zone floue : le versioning. Les releases récentes s'appellent v26.9.2, v26.9.1, v26.8.11, ce qui ressemble à un schéma année.mois.patch, mais le README ne documente pas la politique de compatibilité entre versions. La surface API annoncée est large (OpenAI, Anthropic, Ollama, Responses, WebSocket), et le README reconnaît lui-même que LM Studio ne couvre que partiellement Anthropic et Responses. Rien n'indique dans le matériel fourni quelles parties de la spécification OpenAI sont effectivement implémentées, ni comment les erreurs sont renvoyées. C'est une lacune documentaire, pas nécessairement un défaut du code.

Limites et cas où mlx-serve n'est pas le bon outil

Le projet cible macOS 26.2 ou plus récent sur Apple Silicon. Pas de Linux, pas de Windows, pas d'Intel. Si votre production tourne sur des serveurs Linux ou dans des conteneurs, mlx-serve ne s'applique pas. Le README présente la compilation depuis les sources comme dépendante de Xcode 26.2 et du composant Metal Toolchain, ce qui suppose une version récente de macOS et un environnement Apple à jour. Un Mac plus ancien, ou une version de macOS antérieure, ne pourra pas compiler le projet. Autre limite : la promesse de vitesse. Le README annonce +26 % en décodage (moyenne géométrique) face à LM Studio sur des poids MLX identiques, avec les réglages par défaut. Ce chiffre vient du projet lui-même, pas d'un test indépendant, et le README renvoie à une section Performances non incluse dans le matériel fourni. Il faut le traiter comme une revendication de l'auteur, pas comme une mesure vérifiée. Le projet intègre aussi un shell d'agent sandboxé dans une VM Linux isolée : c'est une fonctionnalité qui exécute du code, donc une surface de risque à évaluer séparément. Enfin, la largeur fonctionnelle (texte, image, vidéo, musique, parole, 3D) signifie que la maintenance couvre plusieurs domaines à la fois. Un projet qui fait tout est plus difficile à auditer qu'un projet qui fait une chose.

Alternatives : Ollama et mlx-lm, avec des différences de fond

Ollama est l'alternative la plus directe pour un serveur local. Il tourne sur macOS, Linux et Windows, expose l'API Ollama native, et mlx-serve implémente cette même API pour que les clients Ollama fonctionnent sans modification. La différence : Ollama ne charge pas les modèles MLX, sauf quelques conversions NVFP4 selon le README, donc la comparaison de vitesse se fait GGUF contre GGUF. mlx-serve charge les deux formats et revendique un avantage sur les poids MLX. Ollama ne fournit pas d'API Anthropic Messages, pas de génération d'images ou de vidéo, pas de client MCP intégré. En échange, Ollama est portable et son écosystème de clients est plus large. mlx-lm est l'autre point de comparaison : c'est l'outil Python de référence pour MLX. Il exige Python à l'exécution, ce que mlx-serve évite explicitement. Le README indique que mlx-lm ne supporte que le drafter pour le décodage spéculatif, alors que mlx-serve annonce PLD, drafter et MTP natif. mlx-lm n'expose pas d'API OpenAI-compatible selon le tableau du README. Le choix se résume donc à : portabilité et écosystème (Ollama), intégration Python et simplicité MLX (mlx-lm), ou serveur natif multi-format avec API multiples sur Mac uniquement (mlx-serve).

Maintenance, mises à jour et implications de licence

Le rythme de publication est soutenu : v26.9.2 le 9 septembre 2026, v26.9.1 le 3 septembre, v26.8.11 le 29 août. Les notes de version mentionnent des changements fonctionnels (réglages par modèle, fournisseurs de chat, terminaux dans la barre latérale, contexte 1M) et des mises à jour de dépendances (MLX 0.32.2). Ce rythme implique une vérification régulière des notes de version avant mise à jour, surtout si vous dépendez d'un comportement précis de l'API. Le projet dépend de Zig, mlx et llama.cpp, épinglés par le script de build selon le README : une mise à jour de mlx-serve peut donc entraîner une recompilation complète de ces dépendances. Sur le plan de la licence, le README affiche MIT mais l'API GitHub renvoie NOASSERTION. Le MIT autorise l'usage commercial, la modification et la redistribution avec conservation du copyright et de la notice. Si le fichier LICENSE réel contient des clauses supplémentaires, ces droits peuvent être restreints. Ce n'est pas un avis juridique : lisez le fichier LICENSE du dépôt et, en cas d'usage en entreprise, faites-le valider par votre service juridique. Le README mentionne aussi que l'application MLX Core est signée et notarized, ce qui est un point distinct de la licence du code source.

Conclusion éditoriale

mlx-serve convient aux développeurs sur Mac Apple Silicon qui veulent un point d'entrée local unique pour Claude Code, le SDK OpenAI ou des clients Ollama, sans Python ni Electron, et qui acceptent de vérifier eux-mêmes la licence réelle du dépôt avant tout usage en entreprise. Il ne convient pas à ceux qui ont besoin d'un serveur Linux, d'un déploiement multi-nœuds ou d'une compatibilité API garantie sur toute la surface OpenAI. Avant d'adopter, clonez le dépôt et lisez le fichier LICENSE et le champ license du manifeste : le README affiche un badge MIT, mais l'API GitHub renvoie NOASSERTION.

Sources officielles

Notes de la communauté