Configuration d'un serveur d'inférence : vLLM, llama.cpp, SGLang

Le matériel arrive, le pilote fonctionne, nvidia-smi L'article présente toutes les cartes. Reste à savoir quelle plateforme distribue les tokens. Il existe quatre ou cinq solutions ouvertes, et un mauvais choix peut entraîner une réduction de débit de 2x, une latence de 3x, ou trois jours de débogage. Cet article examine objectivement ces solutions et décrit la configuration de celle que la plupart des clients Kentino devraient privilégier : vLLM dans Docker, avec l'image validée par NGC, sur un point de terminaison compatible avec OpenAI.

Public cible : quelqu'un qui a lu L02, peut courir docker run --gpus all nvidia-smiet nécessite maintenant la couche suivante.

La matrice de décision

Cinq piles technologiques à considérer en mai 2026. Tout le reste n'est qu'une surcouche de l'une d'entre elles ou un projet de recherche.

En résumé : en cas de doute, exécutez vLLM dans le conteneur NGC. Si votre charge de travail nécessite beaucoup de sortie structurée ou d'invites système partagées, utilisez SGLang. Si vous utilisez un Jetson ou un poste de développement équipé d'un seul processeur 4090, exécutez llama.cpp. Tout autre cas est particulier.

vLLM est la valeur par défaut — et la raison

vLLM (version 0.20+ depuis mai 2026) est la pile logicielle open source la plus déployée pour les LLM et VLM de transformateurs. Trois éléments lui confèrent ce succès :

1. Dosage continu — Les requêtes entrantes sont intégrées à un lot en cours lors du prochain passage. L'utilisation du GPU sur un point de terminaison à trafic mixte passe de 40 % à plus de 85 % par rapport à une inférence Hugging Face par lots classique.
2. Mise en cache du préfixe PagedAttention plus Le cache KV est géré par blocs de taille fixe, à l'instar des pages de mémoire virtuelle du système d'exploitation. Deux requêtes partageant une même invite système se partagent les blocs KV associés à ce préfixe. Pour les flux de travail d'agents avec des invites système partagées de 2 Ko, le taux d'accès au cache de préfixes atteint 80 à 95 %.
3. Blackwell-premiers grains — FlashAttention 3, attention FP8, quantification de poids uniquement MXFP4 et la cible de chemin matmul basée sur CUTLASS sm_120 (5090, RTX Pro 6000 Blackwell) et sm_100 (B200) nativement.

CUDA 13 est la version par défaut pour les roues PyPI v0.20+ et vllm/vllm-openai:latest image. Les roues CUDA 12.8 sont toujours livrées pour le repli sm_120.

Installation de vLLM : pip ou Docker ?

Deux options d'installation s'offrent à vous. Choisissez Docker, sauf raison particulière de faire autrement.

Chemin A — pip dans un environnement virtuel (développement uniquement)

python3.12 -m venv ~/venvs/vllm && source ~/venvs/vllm/bin/activate
pip install --upgrade pip && pip install vllm   # CUDA 13.0 wheels by default

vllm serve meta-llama/Llama-3.3-70B-Instruct-FP8 --tensor-parallel-size 4 --port 8000

Pip fonctionne et est plus rapide pour l'itération sur les options du moteur. Il fixe également la compatibilité entre l'interpréteur Python, l'environnement d'exécution CUDA et le pilote sur une seule configuration hôte. À utiliser en développement, pas en production.

Chemin B — Docker avec l'image en amont (paramètre par défaut de production)

docker run --gpus all --runtime nvidia \
  --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HUGGING_FACE_HUB_TOKEN=$HF_TOKEN \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-3.3-70B-Instruct-FP8 \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.92 \
  --max-model-len 8192 \
  --enable-prefix-caching

Remarques qui pénalisent ceux qui les ignorent :

• --ipc=host Nécessite une configuration multi-GPU. Les nœuds vLLM communiquent via une mémoire partagée ; l’espace de noms IPC Docker par défaut est de 64 Mo et ne peut pas contenir les tampons NCCL.
• Montez le cache HuggingFace. Sinon, chaque docker run retélécharge 75 Go de poids.
• Ajouter une étiquette pour la production : vllm/vllm-openai:v0.20.2 pas :latest.

NGC nvcr.io/nvidia/vllm:25.09-py3 Cette image inclut CUDA 13.0, une version vLLM testée, NCCL et le label QA de NVIDIA. Plus volumineuse (environ 12 Go), elle a un ou deux mois de retard sur les versions officielles. Utilisez-la si vous exécutez également TensorRT-LLM ou Triton sur le même hôte et souhaitez une seule pile CUDA/NCCL pour l'ensemble de ces applications. Sinon, l'image Docker Hub est plus petite, plus récente et équivalente.

Les drapeaux qui comptent vraiment

vLLM expose environ deux cents options de ligne de commande. La plupart sont situationnelles. Voici celles que vous utiliserez systématiquement :

--gpu-memory-utilization Il s'agit du paramètre le plus sensible. vLLM l'utilise pour déterminer la quantité de VRAM à pré-allouer après le chargement des poids ; la VRAM restante constitue le pool de cache KV. Une valeur trop basse entraîne une préemption KV prématurée en cas de charge. Une valeur trop élevée provoque une erreur de mémoire insuffisante (OOM) lors de la première requête de contexte long. 0.92 est un point de départ raisonnable pour un serveur d'inférence dédié. Réduisez cette valeur à 0.85 si vous partagez le GPU.

Trois ordres de lancement concrets

Voici les configurations réellement utilisées par les clients de Kentino. Toutes supposent l'utilisation de CUDA 13.0, du pilote 570+, de l'image Docker, et --ipc=host.

Qwen 2.5 72B Instruction INT4 (AWQ) sur 4× RTX Pro 6000 Blackwell

docker run --gpus all --runtime nvidia --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HUGGING_FACE_HUB_TOKEN=$HF_TOKEN \
  vllm/vllm-openai:v0.20.2 \
  --model Qwen/Qwen2.5-72B-Instruct-AWQ \
  --quantization awq \
  --tensor-parallel-size 4 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.92 \
  --enable-prefix-caching \
  --max-num-seqs 64 \
  --port 8000

Environ 36 Go de poids à INT4, répartis sur 4 cartes de 96 Go. À TP=4, chaque carte traite 1/4 du contexte KV par requête ; ainsi, un contexte de 32 Ko pour 64 utilisateurs simultanés reste largement dans les limites du budget. On peut s'attendre à 40–60 tok/s par requête en faible concurrence, et à un débit agrégé d'environ 600–900 tok/s pour 32 utilisateurs simultanés.

Llama 3.3 70B Instruction FP8 sur 8× RTX 5090

docker run --gpus all --runtime nvidia --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HUGGING_FACE_HUB_TOKEN=$HF_TOKEN \
  vllm/vllm-openai:v0.20.2 \
  --model meta-llama/Llama-3.3-70B-Instruct-FP8 \
  --quantization fp8 \
  --tensor-parallel-size 4 \
  --pipeline-parallel-size 2 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --max-num-seqs 64 \
  --swap-space 4 \
  --port 8000

Notez que TP=4 × PP=2, et non TP=8. Les 5090 disposent de 32 Go chacune ; le poids FP8 pour 70 octets est d'environ 75 Go, largement inférieur à 128 Go sur quatre cartes. La répartition du pipeline évite l'explosion des performances qu'entraînerait un TP=8 sur PCIe (voir K03, N03). TP=8 sur les échelles PCIe est pire que TP=4 × PP=2 avec un traitement par lots continu à une concurrence supérieure à 8.

Qwen 2.5 VL 32B sur double 5090

docker run --gpus all --runtime nvidia --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:v0.20.2 \
  --model Qwen/Qwen2.5-VL-32B-Instruct-AWQ \
  --quantization awq \
  --tensor-parallel-size 2 \
  --max-model-len 16384 \
  --limit-mm-per-prompt '{"image": 4, "video": 0}' \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --port 8000

Deux 5090, environ 20 Go de poids INT4, espace pour un encodeur de vision + KV. La variante 72B VL le fait pas Compatible avec deux 5090 même à INT4 ; utilisez 4× 5090 ou une seule Pro 6000 pour cela. --limit-mm-per-prompt limite le nombre d'images par requête — une seule requête avec 20 images peut saturer la mémoire de l'encodeur de vision sur un 5090. Le point de terminaison est compatible avec OpenAI (POST /v1/chat/completions au image_url parties).

SGLang — quand son routeur surpasse vLLM

L'atout majeur de SGLang réside dans RadixAttention : la réutilisation du cache de préfixes, implémentée sous forme d'arbre radix entre les requêtes, et non pas une simple correspondance par blocs. Pour les charges de travail où la plupart des requêtes partagent de longs messages système, son taux de réussite surpasse celui du cache de préfixes de vLLM. Les benchmarks publics montrent que SGLang atteint environ 16 000 requêtes par seconde (tok/s) contre environ 12 000 requêtes par seconde (tok/s) pour vLLM sur H100 pour les charges de travail à préfixes partagés, avec des écarts bien plus importants pour le trafic à sortie structurée.

Points forts de SGLang :

• JSON structuré via xGrammar. Plus rapide et plus conforme que le décodage contraint de vLLM. Pour une API JSON-out traitant des millions de requêtes, c'est un avantage considérable.
• DeepSeek-V3 et autres grands MoE. La désagrégation étendue des fonctions parallèles d'experts et de préremplissage/décodage a été déployée plus tôt ; elle reste en tête à l'échelle multi-nœuds.
• Flux de travail des agents avec invites système partagées. Points de terminaison RAG, copilotes, invites système de 2 à 4 Ko partagées entre la plupart des requêtes.

Les points forts de vLLM : traitement par lots avec des invites uniques (les limites de RadixAttention s’effondrent), étendue du modèle (plus d’architectures prêtes à l’emploi) et délai d’exécution du premier point de terminaison.

docker run --gpus all --runtime nvidia --ipc=host \
  -p 30000:30000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  lmsysorg/sglang:latest \
  python3 -m sglang.launch_server \
    --model-path Qwen/Qwen2.5-72B-Instruct-AWQ \
    --quantization awq \
    --tp 4 \
    --port 30000 \
    --host 0.0.0.0

SGLang propose un point d'accès compatible OpenAI sur son propre port (30000 par défaut). Utilisez-le pour le même code client, ainsi que les points d'accès de génération structurée natifs de SGLang. Notre recommandation : commencez par vLLM. Si votre taux de réussite avec les préfixes partagés dépasse 60 % et que la latence de queue est importante pour vous, effectuez un nouveau test avec SGLang et choisissez la solution la plus performante.

llama.cpp — quand les petites victoires singulières

llama.cpp est un module d'inférence en C++ sans environnement d'exécution Python ni dépendance à CUDA, utilisant un format de poids GGUF qui intègre les métadonnées de quantification dans le fichier. Il fonctionne sur CPU, GPU unique, Mac série M, Jetson, ou partiellement sur chacun de ces systèmes. Contrairement à vLLM, il n'utilise pas le parallélisme tensoriel. Un modèle, une boucle d'inférence : rapide.

Quand llama.cpp est la bonne réponse :

• Jetson Orin. vLLM n'est pas optimisé pour Jetson ; llama.cpp l'est. Pour un modèle embarqué sur un Unitree G1, c'est la solution standard.
• Boîtier de développement unique 5090 / 4090. Un seul développeur par itération, aucune concurrence, chemin d'installation le plus rapide.
• Répartition mixte CPU+GPU. Une carte 70B ne rentre pas sur une 5090 (32 Go). -ngl 4040 des 80 couches sont traitées par le GPU, le reste s'exécute sur le CPU à une vitesse acceptable pour un utilisateur unique.
• Appareil intégré. Pas de Docker, pas de problèmes de compatibilité de pilotes, pas de Python.

Choix de quantification GGUF, par ordre de taille vs qualité :

Q4_K_M est le bon choix par défaut. Q5_K_M si vous avez suffisamment de marge. Q8_0 sert uniquement à vérifier l'absence de perte de données. Les i-quants (IQ4_XS et autres) constituent une évolution de 2025/2026 intéressante à tester pour installer 70 octets sur une seule carte de 32 Go.

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON && cmake --build build --config Release -j

./build/bin/llama-server \
  --model models/qwen2.5-72b-instruct-q4_k_m.gguf \
  --n-gpu-layers 99 --ctx-size 32768 \
  --host 0.0.0.0 --port 8080 --api-key sk-localdev

-ngl 99 Décharge autant de couches que nécessaire. Le point de terminaison est compatible avec OpenAI à l'adresse suivante : :8080/v1/chat/completionsPour une utilisation multi-utilisateurs, cet outil n'est pas adapté ; utilisez plutôt vLLM. En revanche, pour un seul utilisateur sur un système 5090 ou Jetson, il convient parfaitement.

TensorRT-LLM et Triton — l'option lourde

TensorRT-LLM est le compilateur d'optimisation de NVIDIA pour l'inférence LLM. Il intègre un modèle dans un moteur TensorRT en amont, fusionne les noyaux et sélectionne la meilleure configuration pour chaque GPU. On observe généralement une amélioration du débit de 10 à 25 % et de la latence de 15 à 30 % par rapport à vLLM sur le même matériel, et davantage sur les H100/B200. Le coût réside dans une étape de compilation (de quelques minutes à plusieurs heures par modèle, plus la configuration du GPU), des moteurs non portables entre les générations CUDA/pilotes/GPU, et une complexité opérationnelle accrue. docker run.

Triton Inference Server est la couche de service multi-modèles qui héberge les moteurs TensorRT-LLM (ainsi que PyTorch, ONNX, TensorFlow, Python et vLLM en tant que backend) sur un seul serveur. Le modèle de dépôt permet de charger LLM A, LLM B, un modèle de vision, un modèle de reconnaissance automatique de la parole (ASR) et un pipeline Python via une seule URL, avec gestion des versions, routage A/B et graphes d'ensemble.

L'investissement est justifié lorsque : plusieurs modèles hétérogènes sont servis sur un seul serveur ; des mois de production en régime permanent avec un choix de modèle stable ; l'optimisation de la latence p99 sur les GPU des centres de données Hopper/Blackwell.

Cela n'en vaut pas la peine si : vous êtes encore en train de choisir votre modèle (chaque changement nécessite une nouvelle version du moteur) ; vous utilisez des GPU grand public/de station de travail (le gain de vitesse du TRT-LLM diminue par rapport au H100, et le modèle vLLM sera disponible la semaine suivante six semaines avant le TRT-LLM) ; vous êtes une petite équipe avec peu de ressources opérationnelles.

NVIDIA NIM — le chemin préconfiguré

NIM (NVIDIA Inference Microservices) regroupe « Triton + TensorRT-LLM + une configuration optimale pour ce modèle spécifique + une licence d'entreprise » dans un seul conteneur. docker pull nvcr.io/nim/meta/llama-3.3-70b-instruct:latestDéfinissez une clé NGC, exécutez, et vous obtenez un point de terminaison compatible OpenAI testé sans avoir à choisir de paramètres quantitatifs ou de réglage.

Cette solution est idéale si : vous avez acheté NVIDIA AI Enterprise (ou si un client l'exige) ; vous souhaitez un accès ultra-rapide à un point de terminaison fonctionnel (quelques heures, pas des jours) ; le modèle souhaité figure au catalogue (Llama, Mistral, Mixtral, Gemma, Nemotron et une gamme de partenaires en constante expansion). Après la GTC 2026, une offre gratuite permet d'utiliser jusqu'à 16 GPU pour les membres du programme développeur, ce qui est suffisant pour effectuer des tests sur la plupart des installations Kentino mono-serveur. Veuillez vérifier les conditions de licence en vigueur avant de vous engager.

Ne convient pas lorsque : le modèle n'est pas au catalogue (les poids ouverts arrivent avec des semaines de délai) ; vous souhaitez effectuer un réglage (NIM cache la plupart des boutons de conception).

Proxy inverse, authentification, limitation de débit

N'exposez pas vLLM directement sur Internet. Utilisez nginx (ou Caddy, ou Traefik) comme pare-feu. Voici une configuration nginx minimale :

upstream vllm_backend {
    server 127.0.0.1:8000;
    keepalive 32;
}

limit_req_zone $binary_remote_addr zone=vllm:10m rate=20r/s;

server {
    listen 443 ssl http2;
    server_name infer.example.com;

    ssl_certificate     /etc/letsencrypt/live/infer.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/infer.example.com/privkey.pem;

    location /v1/ {
        if ($http_authorization != "Bearer sk-yourlongrandomtoken") {
            return 401;
        }
        limit_req zone=vllm burst=40 nodelay;

        proxy_pass http://vllm_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;             # streaming SSE
        proxy_read_timeout 600s;
        chunked_transfer_encoding on;
    }
}

Trois points sur lesquels les gens se trompent souvent :

• proxy_buffering off est nécessaire pour les réponses en continu. Sinon, les jetons s'accumulent dans le proxy et le client ne reçoit qu'une seule réponse.
• proxy_read_timeout Par défaut, la durée est de 60 secondes. Les préremplissages multimodaux longs à 4 tok/s dépassent largement cette durée. Réglez-la sur 5 à 10 minutes.
• Le if Le bloc correspond exactement. Pour une authentification réelle, utilisez Lua, oauth2-proxy ou une passerelle comme Kong.

Le Monitoring

Deux sources de données, deux cibles de collecte.

• vLLM /metrics point final. Compatible avec Prometheus, même port que l'API OpenAI (:8000/metrics). Publie vllm:num_requests_running, vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, vllm:time_to_first_token_seconds, vllm:time_per_output_token_seconds. L'utilisation du cache KV est ce qui permet de détecter les préemptions avant qu'elles n'entraînent une latence excessive.
• Exportateur DCGM (nvcr.io/nvidia/k8s/dcgm-exporter, port 9400). Exporte l'utilisation du GPU SM, l'utilisation de la mémoire, la puissance, la température, la bande passante PCIe et les compteurs ECC.

Les deux dans Prometheus, les deux dans Grafana. Premier tableau de bord : requêtes en cours, utilisation du cache KV, utilisation du GPU, température du GPU, TTFT P95, TPOT P95. Si l’utilisation du cache KV atteint un seuil maximal tandis que le nombre de requêtes en attente augmente, vous êtes en train de préempter ; abandonnez. --max-num-seqs, Augmenter --gpu-memory-utilization, ou ajoutez une réplique.

Le mannequin s'est fait avoir lors de l'échauffement.

La première requête adressée à un vLLM nouvellement démarré est 5 à 30 fois plus lente qu'en régime permanent. Des graphiques CUDA sont capturés pour chaque forme de lot, le cache de préfixes est vide et le planificateur est en cours d'étalonnage. Lancez une petite requête. /v1/chat/completions Il est nécessaire d'effectuer une requête au démarrage avant de rejoindre l'équilibreur de charge ; sans cela, le premier utilisateur réel obtient une réponse de 15 secondes sur un modèle qui répond normalement en 1 seconde. Pour les déploiements bleu/vert, il est recommandé de préchauffer la nouvelle réplique avant de vider l'ancienne. Omettre cette phase de préchauffage est la cause la plus fréquente du problème suivant : « Le déploiement semblait correct, mais les utilisateurs se sont plaints pendant dix minutes. »

Multi-modèle sur un seul serveur

vLLM est fondamentalement un serveur à modèle unique. Trois options s'offrent à vous si vous avez besoin de plusieurs serveurs :

1. Un conteneur par modèle, ports différents. Chacune possède sa propre mémoire vidéo. Une carte 70B et une carte 7B partagent un boîtier à 4 GPU via CUDA_VISIBLE_DEVICES découpe et appariement --gpu-memory-utilizationC'est à vous de planifier votre budget mémoire.
2. Chargement à la demande. L'interface charge et décharge les données à la réception des requêtes. Le chargement prend entre 30 et 120 secondes pour un fichier de 70 octets ; la latence de la première requête est inacceptable pour une utilisation interactive. Elle convient pour le traitement par lots.
3. Le référentiel de modèles de Triton. Triton gère le cycle de vie de N modèles sur un seul serveur et effectue le routage par nom de modèle. C'est la solution à laquelle vous migrez lorsque l'option 1 atteint ses limites.

Pour la plupart des installations Kentino, l'option 1 convient jusqu'à ce que vous ayez quatre modèles ou plus, moment auquel la taxe opérationnelle de Triton vaut la peine d'être payée.

Le point de vue honnête

95 % des clients de Kentino devraient commencer par vllm/vllm-openai Dans un conteneur Docker, derrière nginx, sur un seul modèle, avec Prometheus et l'exportateur DCGM pour le scraping, et sans autre considération pendant les trois premiers mois. SGLang s'avère indispensable pour la génération de sorties structurées ou le trafic d'agents à préfixe partagé à grande échelle. llama.cpp trouve sa place sur un Jetson, un Mac ou un poste de développement monoposte. Triton et TensorRT-LLM s'imposent après plusieurs mois de production stable avec plusieurs modèles. NIM trouve sa place lorsque le modèle est référencé et que la licence est acquise.

Le coût d'une configuration trop complexe dès le départ est bien réel. Nous avons vu des installations en laboratoire passer trois semaines à configurer Triton + TensorRT-LLM pour gérer un seul serveur Llama 70B, alors que vLLM aurait pu le faire en vingt minutes. Commencez par une solution simple. N'ajoutez de la complexité que lorsque vous avez la certitude que c'est nécessaire.

---

Ceci fait partie du Kentino Wiki, une série de référence sur l'intelligence artificielle, la robotique et les systèmes qui les connectent. Commentaires et corrections bienvenus. info@kentino.com.