vllm-metal : vLLM tient la charge sur un Mac

Ce qui se passe

Servir un modèle en local sur un Mac ne pose aucun problème tant qu'une requête arrive à la fois. Dès que plusieurs agents ou sessions interrogent le même serveur, le temps avant le premier token (TTFT), la croissance de la mémoire et l'admission des requêtes deviennent des problèmes d'ordonnancement.

vllm-metal apporte à Apple Silicon ce que vLLM fait sur GPU : l'ordonnanceur V1, le cache KV paginé, le prefill découpé et le serveur compatible OpenAI, avec streaming et analyse des appels d'outils. Les modèles viennent de mlx_lm, et MLX les exécute. La première version officielle, v0.28.0, aligne sa numérotation sur vLLM ; la v0.29.0 est la version actuelle.

Installer et lancer

Sur macOS 15 ou plus récent :

brew tap vllm-project/vllm-metal https://github.com/vllm-project/vllm-metal
brew install vllm-project/vllm-metal/vllm-metal

vllm serve Qwen/Qwen3.5-0.8B --gpu-memory-utilization 0.5

Sur un Mac de 64 Go, le projet suggère mlx-community/Qwen3.8-27B-4bit avec --gpu-memory-utilization 0.7. L'API répond sur http://localhost:8000/v1 : tout outil qui accepte une URL compatible OpenAI peut s'y brancher, agents de code compris.

--gpu-memory-utilization fixe le budget. Au démarrage, un passage de préchauffage mesure poids, activations et tampons, puis le reste du budget devient un cache KV de taille fixe. Une requête qui n'y tient pas attend qu'une page se libère, au lieu de faire gonfler la mémoire.

Pourquoi il tient mieux la charge

mlx_lm aligne toutes les requêtes d'un lot sur la plus longue et complète les autres par du vide. vllm-metal les met bout à bout dans un seul passage du modèle, des repères marquant où chacune commence, et range le cache KV en pages de taille fixe. Les couches qui traitent chaque token isolément sont reprises telles quelles de mlx_lm ; seule l'attention est remplacée par un noyau Metal, porté du noyau Triton de vLLM.

L'effet se voit sur des lots inégaux. Qwen3.6-35B-A3B en 4 bits, huit requêtes, environ 6 000 tokens de prompt au total (secondes par lot) :

Sous une charge d'agents

Banc SiliconBench, profil « agent » : 100 prompts multi-tours d'environ 4 600 tokens, sur un M5 Pro de 64 Go, poids en 4 bits.

• Qwen3.8-27B : vllm-metal a le TTFT et la latence de bout en bout les plus bas à 2 et 4 requêtes simultanées ; à une seule, oMLX avec son cache sur SSD passe devant.
• Gemma 4 E4B : TTFT bas jusqu'à 16 requêtes simultanées.
• Prédiction multi-token (Gemma 4, un token proposé par étape) : à une requête, −15 % de durée et +20 % de débit ; à 16, −8 % de durée mais +20 % de TTFT. Réservée à Gemma 4, avec temperature=0 et --no-async-scheduling.

Les autres ajouts

• Sur M5, un noyau d'attention exploitant le matériel tensoriel accélère automatiquement le prefill.
• Réutilisation du préfixe de conversation sur les modèles hybrides de type Qwen3.5, encore expérimentale et incompatible avec le décodage spéculatif.
• Adaptateurs LoRA, sorties structurées, trois méthodes de décodage spéculatif, fichiers GGUF.
• Parallélisme de pipeline sur plusieurs Mac.
• En expérimental : modèles vision-langage, embeddings, reranking, transcription.

Les réserves

Ces mesures sont celles de l'équipe, chaque moteur utilisant sa propre conversion 4 bits, et llama.cpp ses quatre emplacements par défaut. Les scripts sont publiés dans le dépôt SiliconBench, ce qui permet de les rejouer ; l'article qui l'accompagne est une prépublication, pas un résultat relu.

Source : Announcing vllm-metal: Concurrent Serving on Apple Silicon, blog vLLM, 22 septembre 2026.