Ollama et vLLM : servir un modèle

Pourquoi héberger un modèle soi-même ?

Appeler un modèle chez un fournisseur cloud est simple : une clé, une requête, une facture au token. Héberger un modèle ouvert (dont les poids sont téléchargeables) sur sa propre machine répond à d’autres besoins :

• confidentialité : les données ne quittent pas votre infrastructure ;
• maîtrise des coûts : un coût de machine prévisible plutôt qu’un coût proportionnel à l’usage ;
• indépendance : pas de changement de version imposé, fonctionnement hors ligne possible.

Les contreparties sont réelles : il faut une machine adaptée (souvent un GPU), installer, superviser, mettre à jour et sécuriser. Les modèles ouverts que l’on peut faire tourner sur une seule carte sont aussi, en général, moins performants que les plus grands modèles commerciaux sur les tâches difficiles. D’où l’architecture « local d’abord, cloud en secours » vue plus loin.

Ollama : démarrer en trois commandes

Ollama est un outil open source qui télécharge, gère et sert des modèles. Sous Linux, l’installation officielle se fait par un script, puis :

ollama serve &                 # démarre le serveur (souvent lancé comme service)
ollama pull qwen2.5:0.5b       # télécharge un petit modèle
ollama run qwen2.5:0.5b "Explique une boucle for en une phrase."
ollama list                    # modèles téléchargés
ollama ps                      # modèles chargés en mémoire, sur GPU ou CPU

Les modèles sont désignés par un nom et une étiquette (qwen2.5:0.5b) qui précise la taille et parfois la quantification. Sans GPU, Ollama fonctionne sur CPU, plus lentement : c’est suffisant pour apprendre avec un petit modèle.

L’API HTTP d’Ollama

Le serveur écoute par défaut sur 127.0.0.1:11434. Votre application l’interroge en HTTP :

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model": "qwen2.5:0.5b",
  "prompt": "Donne un synonyme de rapide.",
  "stream": false
}'

La réponse JSON contient le texte (response), un indicateur done et des mesures : prompt_eval_count et eval_count (tokens lus et générés), eval_duration et total_duration (en nanosecondes). D’autres routes existent : /api/chat pour une conversation, /api/tags pour la liste des modèles, /api/embed pour les embeddings.

Ollama expose aussi une API compatible OpenAI sous /v1 (par exemple /v1/chat/completions) : une bibliothèque cliente prévue pour OpenAI fonctionne en changeant l’URL de base.

vLLM : servir à grande échelle

vLLM est un moteur d’inférence open source conçu pour le débit sur GPU. Il regroupe dynamiquement les requêtes en cours (continuous batching) et gère la mémoire du cache d’attention par pages (PagedAttention), ce qui lui permet de servir efficacement de nombreuses requêtes simultanées.

vllm serve Qwen/Qwen2.5-7B-Instruct --max-model-len 8192 --api-key "$VLLM_API_KEY"
curl -s http://127.0.0.1:8000/v1/models -H "Authorization: Bearer $VLLM_API_KEY"

vLLM charge les modèles au format Hugging Face (désignés par organisation/modèle) et sert par défaut sur le port 8000 une API compatible OpenAI. Une image Docker officielle (vllm/vllm-openai) facilite le déploiement.

Lequel choisir ?

Critère	Ollama	vLLM
Mise en route	très simple	plus technique
Matériel	CPU ou GPU	GPU principalement
Format des modèles	GGUF (quantifiés)	Hugging Face, quantifications AWQ, GPTQ…
Point fort	prototypage, petits volumes	nombreuses requêtes simultanées

Comme les deux parlent le même dialecte OpenAI, on peut commencer avec Ollama et passer à vLLM quand la charge l’exige, sans réécrire l’application : seuls l’URL et les noms de modèles changent. Mesurez votre propre charge avant de décider : aucun chiffre générique ne remplace un test sur votre matériel.

À retenir

• Héberger soi-même apporte confidentialité et maîtrise, au prix de l’exploitation.
• Ollama : pull, run, list, ps, API sur le port 11434.
• vLLM : orienté débit sur GPU, API compatible OpenAI sur le port 8000.
• L’API compatible OpenAI permet de changer de serveur sans réécrire l’application.