{"id":2198,"date":"2026-04-07T12:13:07","date_gmt":"2026-04-07T10:13:07","guid":{"rendered":"https:\/\/askem.eu\/?p=2198"},"modified":"2026-04-07T12:13:30","modified_gmt":"2026-04-07T10:13:30","slug":"vllm-servir-des-llm-a-haute-performance-en-production","status":"publish","type":"post","link":"https:\/\/askem.eu\/en\/2026\/04\/07\/vllm-servir-des-llm-a-haute-performance-en-production\/","title":{"rendered":"vLLM : servir des LLM \u00e0 haute performance en production"},"content":{"rendered":"

vLLM : servir des LLM \u00e0 haute performance en production avec l’open source<\/h2>\n\n\n\n

Ollama simplifie l’ex\u00e9cution locale de mod\u00e8les de langage, mais quand il s’agit de servir des dizaines d’utilisateurs en parall\u00e8le avec des contraintes de latence et de d\u00e9bit, il faut passer \u00e0 l’\u00e9chelon sup\u00e9rieur. vLLM<\/strong> est un moteur d’inf\u00e9rence open source con\u00e7u sp\u00e9cifiquement pour le serving haute performance de LLM en production, avec un throughput jusqu’\u00e0 24\u00d7 sup\u00e9rieur \u00e0 une inf\u00e9rence na\u00efve gr\u00e2ce \u00e0 son algorithme PagedAttention.<\/p>\n\n\n\n

Pourquoi vLLM plut\u00f4t qu’Ollama en production<\/h3>\n\n\n\n

Ollama excelle pour le prototypage et l’usage individuel. Mais d\u00e8s que l’on doit g\u00e9rer du batching continu<\/strong> (traiter plusieurs requ\u00eates simultan\u00e9ment), optimiser l’utilisation m\u00e9moire GPU, ou garantir des temps de r\u00e9ponse stables sous charge, vLLM apporte des m\u00e9canismes que les solutions simples ne proposent pas. Son architecture repose sur PagedAttention<\/strong>, un algorithme qui g\u00e8re la m\u00e9moire du cache KV comme un syst\u00e8me de m\u00e9moire virtuelle pagin\u00e9e, \u00e9liminant le gaspillage m\u00e9moire et permettant de servir bien plus de requ\u00eates concurrentes sur le m\u00eame GPU.<\/p>\n\n\n\n

D\u00e9ployer vLLM sur Docker<\/h3>\n\n\n\n

Le d\u00e9ploiement se fait via une image Docker officielle. Un docker-compose.yml<\/code> minimal suffit pour exposer un serveur compatible OpenAI API :<\/p>\n\n\n\n

services:\n  vllm:\n    image: vllm\/vllm-openai:latest\n    runtime: nvidia\n    ports:\n      - \"8000:8000\"\n    volumes:\n      - .\/models:\/root\/.cache\/huggingface\n    command: >\n      --model mistralai\/Mistral-7B-Instruct-v0.3\n      --max-model-len 8192\n      --gpu-memory-utilization 0.90\n    deploy:\n      resources:\n        reservations:\n          devices:\n            - driver: nvidia\n              count: 1\n              capabilities: [gpu]<\/code><\/pre>\n\n\n\n
Le serveur expose alors les endpoints \/v1\/chat\/completions<\/code> et \/v1\/completions<\/code>, directement compatibles avec tout client OpenAI, y compris Open WebUI, n8n, ou Langfuse.<\/p>\n\n\n\n
Les m\u00e9canismes cl\u00e9s de performance<\/h3>\n\n\n\n
PagedAttention<\/strong> d\u00e9coupe le cache KV (key-value) en blocs de taille fixe stock\u00e9s de mani\u00e8re non contigu\u00eb en m\u00e9moire GPU. Contrairement aux approches classiques qui pr\u00e9-allouent de la m\u00e9moire contigu\u00eb pour la longueur maximale de s\u00e9quence, PagedAttention n’alloue que ce qui est r\u00e9ellement n\u00e9cessaire, r\u00e9duisant le gaspillage m\u00e9moire de 60 \u00e0 80 %.<\/p>\n\n\n\n
Continuous batching<\/strong> permet d’ins\u00e9rer de nouvelles requ\u00eates dans un batch en cours de traitement, sans attendre que toutes les requ\u00eates du batch pr\u00e9c\u00e9dent soient termin\u00e9es. Le GPU reste ainsi occup\u00e9 en permanence, maximisant le throughput.<\/p>\n\n\n\n
Tensor parallelism<\/strong> distribue un mod\u00e8le trop large pour un seul GPU sur plusieurs cartes, avec un argument aussi simple que --tensor-parallel-size 2<\/code>.<\/p>\n\n\n\n
Quantization et mod\u00e8les support\u00e9s<\/h3>\n\n\n\n
vLLM supporte nativement les formats de quantization les plus courants : GPTQ<\/strong>, AWQ<\/strong>, GGUF<\/strong> (via conversion), et FP8<\/strong>. Cela permet de servir des mod\u00e8les 70B sur un GPU 24 Go en AWQ 4-bit, l\u00e0 o\u00f9 le mod\u00e8le complet n\u00e9cessiterait 140 Go de VRAM. La biblioth\u00e8que de mod\u00e8les support\u00e9s couvre Llama 3, Mistral, Mixtral, Qwen 2.5, Phi-3, Gemma 2, DeepSeek-V2 et la plupart des architectures transformer courantes sur Hugging Face.<\/p>\n\n\n\n
Int\u00e9gration dans une stack auto-h\u00e9berg\u00e9e<\/h3>\n\n\n\n
Dans une architecture type askem.eu, vLLM s’ins\u00e8re naturellement :<\/p>\n\n\n\n