Ollama, llama.cpp ou vLLM : choisir un serveur LLM local

Pour un développeur seul sur un portable, lancez Ollama : l'installation prend quelques minutes, les modèles se téléchargent par leur nom et se chargent à la demande. Pour une petite équipe, un Mac, un serveur sans GPU ou une carte graphique grand public, prenez llama-server de llama.cpp, qui sert des modèles GGUF avec un contrôle explicite des slots parallèles, des clés d'API et des métriques Prometheus. Pour du trafic de production sur des GPU de data center, lancez vLLM, dont le continuous batching et PagedAttention maintiennent un débit élevé quand la concurrence augmente. Les trois exposent une API compatible OpenAI, ce qui permet de commencer avec l'un et de passer à un autre en changeant une base URL et un nom de modèle.

Ce que chaque serveur optimise

Ollama optimise le temps jusqu'à la première réponse. Il tourne comme application de bureau ou service d'arrière-plan, télécharge les modèles par leur nom, charge un modèle à la première requête et le décharge après une période d'inactivité, cinq minutes par défaut selon la FAQ d'Ollama. Quelques variables d'environnement OLLAMA_* remplacent un réglage fin de l'ordonnanceur, et cette simplicité est tout l'intérêt.

llama.cpp optimise la portabilité. C'est un moteur d'inférence en C/C++ construit sur la bibliothèque ggml, avec des backends Metal pour Apple Silicon, CUDA, HIP pour AMD, Vulkan, SYCL et des chemins CPU optimisés pour AVX, AVX2, AVX-512, AMX et ARM NEON. Quand un modèle ne tient pas en VRAM, il peut garder une partie des couches sur le GPU et le reste en mémoire système. Son serveur HTTP, llama-server, se résume à un binaire, un fichier GGUF et des options. Le README du projet montre désormais une commande unifiée llama serve dans son démarrage rapide, tandis que la documentation de llama-server et les images Docker livrent toujours l'exécutable llama-server utilisé dans cet article.

vLLM optimise le débit sur accélérateurs. Son README cite PagedAttention pour la gestion du cache KV, le continuous batching, le chunked prefill, le prefix caching, le service de plusieurs LoRA, le parallélisme tensoriel et pipeline, ainsi qu'une longue liste de formats de quantification. Il prend en charge les GPU NVIDIA, AMD et Intel ainsi que les CPU x86, ARM et PowerPC, et d'autres accélérateurs via des plugins matériels.

En résumé, Ollama et llama.cpp conviennent à du matériel modeste et à quelques utilisateurs simultanés, alors que vLLM justifie sa mise en place plus lourde dès que de nombreuses requêtes arrivent en même temps. Le versant matériel de la décision, notamment la mémoire nécessaire aux poids et au cache KV, est traité dans le guide du matériel pour LLM locaux.

Un client OpenAI, trois base URL

Les trois serveurs implémentent /v1/chat/completions, /v1/completions, /v1/embeddings, /v1/models et /v1/responses. La page de compatibilité OpenAI d'Ollama précise que son support de Responses est sans état. llama-server propose en plus un /v1/messages compatible Anthropic, et vLLM liste Anthropic Messages, la transcription audio et des API de pooling à côté des routes OpenAI.

Gardez le choix du serveur dans la configuration pour que le code client ne change jamais :

import os
from openai import OpenAI

# Ollama:       http://127.0.0.1:11434/v1
# llama-server: http://127.0.0.1:8080/v1
# vLLM:         http://127.0.0.1:8000/v1
client = OpenAI(
    base_url=os.environ["LLM_BASE_URL"],
    api_key=os.environ.get("LLM_API_KEY", "not-used"),
)

reply = client.chat.completions.create(
    model=os.environ["LLM_MODEL"],
    messages=[{"role": "user", "content": "Explain HTTP 429 in two sentences."}],
    temperature=0.2,
)
print(reply.choices[0].message.content)

Le SDK OpenAI exige une chaîne de clé, donc passez une valeur factice quand le serveur n'en a pas. Ollama ignore la clé en local, tandis que llama-server et vLLM ne la vérifient que s'ils ont été démarrés avec une clé.

C'est le champ model qui distingue les serveurs. Ollama attend un tag de sa bibliothèque, par exemple qwen3:8b. vLLM attend le nom du dépôt Hugging Face ou la valeur de --served-model-name. Un llama-server à modèle unique sert ce qu'il a chargé, --alias définit le nom renvoyé par /v1/models, et en mode router le nom sélectionne le modèle.

La compatibilité s'arrête aux limites de la spécification OpenAI. vLLM accepte des paramètres supplémentaires comme top_k via extra_body et applique par défaut le generation_config.json du modèle, ce qui peut modifier les valeurs d'échantillonnage par défaut si vous ne passez pas --generation-config vllm. Les templates de chat et les tokenizers peuvent aussi différer entre une conversion GGUF et le checkpoint d'origine : avant de changer de serveur, exécutez le même jeu d'évaluation sur les deux, comme le décrit le guide d'évaluation des agents IA.

Formats de modèles et provenance des poids

Les trois serveurs ne lisent pas les mêmes fichiers, et cela tranche souvent la question avant les performances.

Ollama télécharge les modèles de sa bibliothèque par leur nom, exécute des dépôts GGUF de Hugging Face avec ollama run hf.co/{user}/{repo}:{quant} et importe des fichiers GGUF locaux ou des répertoires Safetensors via un Modelfile dont la ligne FROM pointe vers les poids. Il ne quantifie pas les fichiers GGUF à l'import : quantifiez-les d'abord avec les outils de llama.cpp.

llama.cpp lit le GGUF. On convertit un checkpoint Hugging Face avec convert_hf_to_gguf.py puis on le quantifie, ou on télécharge un GGUF prêt à l'emploi avec -hf user/repo:quant. Le README mentionne une quantification entière de 1,5 à 8 bits. Les modèles de vision ont aussi besoin d'un fichier de projecteur, que -hf récupère automatiquement.

vLLM lit les dépôts de modèles Hugging Face avec des poids Safetensors, ainsi que des checkpoints quantifiés GPTQ, AWQ, FP8, INT8, INT4 et compressed-tensors. Sa documentation qualifie le support GGUF de très expérimental, et ce support a migré vers un plugin externe, vllm-gguf-plugin.

# Ollama: a library model, or a GGUF repository on Hugging Face
ollama pull qwen3:8b
ollama run hf.co/bartowski/Llama-3.2-3B-Instruct-GGUF:Q8_0

# llama.cpp: download a GGUF and serve it
llama-server -hf ggml-org/Qwen3.5-0.8B-GGUF --port 8080

# vLLM: serve a Hugging Face repository
vllm serve Qwen/Qwen3-0.6B --host 127.0.0.1 --port 8000

Concurrence, batching et mémoire du cache KV

La concurrence coûte de la mémoire. Chaque séquence active conserve les clés et valeurs d'attention de chaque token de son contexte, donc la mémoire croît avec le nombre de séquences simultanées multiplié par leur longueur, en plus des poids. Pour un transformer standard, cette estimation est utile :

KV bytes per token = 2 × layers × kv_heads × head_dim × bytes_per_value
Qwen3-8B, 16-bit cache: 2 × 36 × 8 × 128 × 2 = 147,456 bytes = 144 KiB
One 32,768-token sequence: 144 KiB × 32,768 = 4.5 GiB

Le nombre de couches, le nombre de têtes KV et la dimension de tête viennent du config.json du modèle. Quatre séquences de ce type demandent 18 GiB de cache avant même de compter les poids. Les modèles à attention en fenêtre glissante ou hybride en demandent moins, la formule donne alors une borne supérieure.

Ollama

OLLAMA_NUM_PARALLEL fixe le nombre de requêtes que chaque modèle chargé traite en même temps, et la FAQ indique une valeur par défaut de 1. OLLAMA_MAX_LOADED_MODELS vaut par défaut trois fois le nombre de GPU, ou trois en inférence CPU. OLLAMA_MAX_QUEUE accepte par défaut 512 requêtes en file, après quoi le serveur répond par une erreur 503. La FAQ avertit aussi que la mémoire requise croît avec OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH. La longueur de contexte par défaut est décrite différemment selon les pages et dépend de la VRAM disponible : fixez-la explicitement et vérifiez-la dans la colonne CONTEXT de ollama ps.

OLLAMA_HOST=127.0.0.1:11434 \
OLLAMA_NUM_PARALLEL=4 \
OLLAMA_CONTEXT_LENGTH=16384 \
OLLAMA_KEEP_ALIVE=30m \
ollama serve

llama-server

llama-server répartit le travail en slots. Chaque slot porte une conversation, -np fixe le nombre de slots, et la valeur par défaut -1 signifie automatique. Le continuous batching est activé par défaut, si bien que les nouvelles requêtes rejoignent le batch en cours entre deux étapes de décodage. Quand le nombre de slots est automatique, tous partagent un tampon KV unifié. Quand vous fixez -np vous-même, le tampon unifié est désactivé par défaut et -c est réparti entre les slots : -c 32768 -np 4 donne 8 192 tokens à chaque conversation. Vérifiez le résultat avec GET /slots, qui indique n_ctx pour chaque slot.

Le déchargement sur GPU se règle avec -ngl, qui accepte un nombre, auto (par défaut) ou all. Quand le modèle ne tient pas, les couches restées sur le CPU sont limitées par la bande passante de la mémoire système : un modèle partiellement déchargé fonctionne, mais génère en général ses tokens plus lentement.

llama-server -m /models/qwen3-8b-q4_k_m.gguf \
  --host 127.0.0.1 --port 8080 \
  -c 32768 -np 4 -ngl all \
  --api-key-file /etc/llama/api-keys.txt \
  --metrics

vLLM

Le continuous batching de vLLM admet de nouvelles séquences à chaque itération de décodage tant que des blocs de cache KV sont libres, et PagedAttention alloue ce cache en blocs de taille fixe au fil de la croissance des séquences au lieu de réserver la longueur maximale d'avance. Au démarrage, vLLM prend la fraction de mémoire GPU fixée par --gpu-memory-utilization et transforme ce qui reste après les poids et l'espace de travail des activations en blocs de cache KV. Quand les blocs manquent sous charge, il préempte certaines requêtes et les recalcule une fois la place libérée, ce qui apparaît dans la métrique vllm:num_preemptions et dans la latence de queue.

Les principaux leviers sont --max-model-len pour le contexte le plus long accepté, --max-num-seqs pour le nombre maximal de séquences par itération, --max-num-batched-tokens, --gpu-memory-utilization et --tensor-parallel-size pour répartir un modèle sur plusieurs GPU. Ramener --max-model-len à ce dont l'application a réellement besoin est en général le moyen le moins coûteux de loger davantage de requêtes simultanées.

export VLLM_API_KEY="$(openssl rand -hex 32)"
vllm serve Qwen/Qwen3-8B \
  --host 127.0.0.1 --port 8000 \
  --max-model-len 32768 \
  --max-num-seqs 64 \
  --gpu-memory-utilization 0.90

Sortie structurée et appels d'outils

Les trois serveurs savent contraindre la sortie à un schéma JSON via le champ OpenAI response_format, ce qui rend cette requête portable :

schema = {
    "type": "object",
    "properties": {
        "severity": {"type": "string", "enum": ["low", "medium", "high"]},
        "summary": {"type": "string"},
    },
    "required": ["severity", "summary"],
    "additionalProperties": False,
}

reply = client.chat.completions.create(
    model=os.environ["LLM_MODEL"],
    messages=[{"role": "user", "content": "Triage this log line: disk /var is 97% full"}],
    response_format={
        "type": "json_schema",
        "json_schema": {"name": "triage", "schema": schema},
    },
)

L'API native d'Ollama accepte aussi "json" ou un schéma dans son champ format, et sa documentation conseille de répéter le schéma dans le prompt. llama-server convertit les schémas JSON dans son format de grammaire GBNF et accepte aussi une grammaire brute pour d'autres formes de sortie. vLLM prend en charge response_format et un objet structured_outputs dans extra_body avec les clés json, regex, choice, grammar et structural_tag. Les anciens paramètres guided_* ont été supprimés dans la v0.12.0, comme le signale la page structured outputs de vLLM. Le décodage contraint garantit la syntaxe, pas la véracité, et une réponse coupée par max_tokens reste un JSON invalide : validez chaque résultat contre le schéma dans votre propre code.

Les appels d'outils fonctionnent sur les trois, avec une configuration différente :

• Ollama accepte tools sur /api/chat et sur /v1/chat/completions, y compris les appels parallèles, pour les modèles dont le template prend en charge les outils.
• llama-server prend en charge les outils de style OpenAI via les templates de chat Jinja, activés par défaut. Les notes de llama.cpp sur le function calling listent des gestionnaires natifs pour plusieurs familles de modèles et un mode générique de repli qui consomme plus de tokens. Les appels parallèles restent désactivés tant que la requête ne fixe pas "parallel_tool_calls": true.
• vLLM exige --enable-auto-tool-choice et un --tool-call-parser adapté à la famille du modèle, par exemple hermes pour Qwen2.5 ou llama3_json pour Llama 3.1 et 3.2. La page tool calling de vLLM explique que les fonctions nommées et tool_choice="required" s'appuient sur les structured outputs, alors que auto ne garantit pas que les arguments soient analysables.

vllm serve Qwen/Qwen2.5-7B-Instruct \
  --host 127.0.0.1 --port 8000 \
  --enable-auto-tool-choice --tool-call-parser hermes

Traitez les arguments d'outils comme des entrées non fiables. C'est le modèle qui les choisit, et un texte contenu dans un document récupéré peut orienter ce choix, comme l'explique le guide sur la prompt injection et la sécurité MCP.

Exécution dans Docker avec accès GPU

Sous Linux avec des GPU NVIDIA, installez d'abord le NVIDIA Container Toolkit pour que --gpus fonctionne. Les commandes ci-dessous reprennent l'image et les options documentées de chaque projet, avec un seul changement : chaque port n'est publié que sur 127.0.0.1. La documentation Docker sur la publication de ports indique qu'un port publié sans adresse d'hôte l'est sur toutes les adresses de l'hôte, et les notes de Docker sur le pare-feu ajoutent que le trafic des ports publiés est détourné avant que les règles ufw ne le voient.

# Ollama with NVIDIA GPUs
docker run -d --name ollama --gpus=all \
  -v ollama:/root/.ollama \
  -p 127.0.0.1:11434:11434 \
  ollama/ollama

# llama-server, CUDA build
docker run -d --name llama --gpus all \
  -v /srv/models:/models:ro \
  -p 127.0.0.1:8080:8080 \
  ghcr.io/ggml-org/llama.cpp:server-cuda \
  -m /models/qwen3-8b-q4_k_m.gguf --host 0.0.0.0 --port 8080 -ngl all

# vLLM with NVIDIA GPUs
docker run -d --name vllm --runtime nvidia --gpus all --ipc=host \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  --env "HF_TOKEN=$HF_TOKEN" \
  -p 127.0.0.1:8000:8000 \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen3-8B

Dans un conteneur, le serveur doit écouter sur 0.0.0.0, sinon le port publié ne peut pas l'atteindre. C'est le 127.0.0.1 côté hôte qui le garde privé. La commande documentée de vLLM ajoute --ipc=host parce que PyTorch échange des données entre processus via la mémoire partagée, en particulier pour l'inférence en parallélisme tensoriel. Pour les GPU AMD, utilisez ollama/ollama:rocm avec --device /dev/kfd --device /dev/dri, les images llama.cpp server-rocm ou server-vulkan, ou vllm/vllm-openai-rocm. En production, épinglez les tags ou les digests d'image au lieu de latest.

Sécurité : écoute locale, authentification au proxy

Traitez un port d'inférence comme un port de base de données. Quiconque l'atteint peut consommer votre temps GPU, lire tout ce que renvoie le modèle et, dans certaines configurations, appeler des routes d'administration.

Commencez par l'adresse d'écoute. Ollama écoute par défaut sur 127.0.0.1:11434 et llama-server sur 127.0.0.1:8080. vLLM fait exception : sans --host, son lanceur écoute sur toutes les interfaces, donc passez toujours --host 127.0.0.1 hors conteneur.

Vérifiez ensuite ce que protège réellement la clé de chaque serveur :

• L'API locale d'Ollama n'a aucun réglage de clé d'API. Tout ce qui atteint le port peut l'utiliser, donc ne la partagez qu'à travers un proxy qui authentifie.
• llama-server vérifie --api-key ou --api-key-file sur son API, tandis que /health reste public par conception. Son README signale que le CORS renvoie par défaut n'importe quel Origin et recommande --cors-origins sur un réseau local.
• La clé --api-key de vLLM ne couvre que quelques préfixes de chemin, dont /v1. Le guide de sécurité de vLLM liste des routes non protégées comme /invocations, qui atteint les mêmes fonctions d'inférence, ou /pause et /abort_requests, et recommande un reverse proxy qui n'autorise qu'une liste d'endpoints.

Un petit frontal Nginx répond aux deux besoins. Il termine TLS, vérifie un jeton bearer, ne transmet que /v1/ et renvoie 404 pour tout le reste.

map $http_authorization $llm_client {
    default "";
    "Bearer REPLACE_WITH_A_LONG_RANDOM_TOKEN" "team";
}

server {
    listen 443 ssl;
    server_name llm.example.internal;
    ssl_certificate     /etc/nginx/tls/llm.crt;
    ssl_certificate_key /etc/nginx/tls/llm.key;
    client_max_body_size 10m;

    location /v1/ {
        if ($llm_client = "") { return 401; }
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_read_timeout 600s;
    }

    location / {
        return 404;
    }
}

proxy_buffering off laisse les tokens en streaming parvenir au client au fur et à mesure de leur génération. Si le serveur amont a sa propre clé, donnez-lui le même jeton pour qu'une requête qui contourne le proxy échoue quand même. Pour Ollama, pointez proxy_pass vers le port 11434 et ajoutez proxy_set_header Host localhost:11434, comme dans l'exemple de la FAQ. Ajoutez limit_req quand plusieurs utilisateurs partagent un même GPU. Sur un portable de développement, gardez en tête que OLLAMA_ORIGINS=* permet à n'importe quelle page web visitée d'appeler le serveur local depuis votre navigateur.

Supervision et contrôles de santé

Commencez par la disponibilité. Le /health de llama-server renvoie 503 pendant le chargement du modèle et 200 une fois prêt, et vLLM expose aussi /health. Servez-vous-en pour les health checks de conteneurs et les sondes de load balancer, pas comme preuve que la qualité de génération est bonne.

vLLM expose des métriques Prometheus sur /metrics par défaut. La page des métriques de vLLM liste vllm:num_requests_running, vllm:num_requests_waiting, vllm:kv_cache_usage_perc, des histogrammes du temps jusqu'au premier token, de la latence inter-tokens et de la latence de bout en bout, ainsi qu'un compteur de préemptions. llama-server n'expose /metrics qu'avec --metrics, notamment llamacpp:requests_processing, llamacpp:requests_deferred, llamacpp:prompt_tokens_seconds et llamacpp:predicted_tokens_seconds, tandis que GET /slots montre l'état de chaque slot.

scrape_configs:
  - job_name: vllm
    static_configs:
      - targets: ["127.0.0.1:8000"]
  - job_name: llama-server
    static_configs:
      - targets: ["127.0.0.1:8080"]

L'API documentée d'Ollama n'a pas d'endpoint Prometheus. Utilisez GET /api/ps pour voir les modèles chargés, leur usage de VRAM, leur longueur de contexte et leur heure de déchargement, et lisez les champs de durée de chaque réponse. Les durées sont en nanosecondes, donc la vitesse de génération vaut eval_count / eval_duration × 10^9 tokens par seconde :

curl -s http://127.0.0.1:11434/api/generate \
  -d '{"model": "qwen3:8b", "prompt": "Say ready.", "stream": false}' |
  jq '{tokens: .eval_count, tokens_per_second: (.eval_count / .eval_duration * 1e9)}'

Alertez sur les signaux qui indiquent que des utilisateurs attendent : une file waiting ou deferred qui reste au-dessus de zéro, un usage du cache KV proche de 1, un compteur de préemptions en hausse et un temps jusqu'au premier token qui dérive au p95. Les métriques serveur décrivent la capacité. Elles ne disent pas quel prompt, quel appel d'outil ou quelle étape de recherche a ralenti une requête, donc reliez-les aux traces de requêtes comme le décrit le guide d'observabilité des agents IA.

Comparaison côte à côte

	Ollama	llama.cpp llama-server	vLLM
Optimisé pour	Installation rapide et gestion des modèles	Portabilité sur CPU, Apple Silicon et GPU grand public	Débit sur GPU de data center
Formats de modèles	Modèles de la bibliothèque, GGUF, import Safetensors	GGUF	Safetensors Hugging Face, GPTQ, AWQ, FP8 et d'autres ; GGUF expérimental
Adresse d'écoute par défaut	127.0.0.1:11434	127.0.0.1:8080	Toutes les interfaces, port 8000
Clé d'API intégrée	Aucune	--api-key, --api-key-file	--api-key ou VLLM_API_KEY, préfixes de chemin limités
Concurrence	OLLAMA_NUM_PARALLEL par modèle, 1 par défaut	Slots (-np) avec continuous batching	Continuous batching avec PagedAttention
Sortie structurée	format, response_format	response_format, schéma JSON, GBNF	response_format, structured_outputs
Appels d'outils	tools sur les routes natives et OpenAI	Templates Jinja, gestionnaires natifs ou génériques	--enable-auto-tool-choice avec un parser
Métriques	/api/ps et durées des réponses	/metrics avec --metrics, /slots	/metrics par défaut
Usage idéal	Un développeur, prototypes	Petites équipes, matériel modeste ou hétérogène	Nombreux utilisateurs simultanés, SLO de production

Arbre de décision pour le développement, l'équipe et la production

Parcourez ces questions dans l'ordre et arrêtez-vous à la première réponse nette.

1. Une seule personne explore-t-elle des modèles sur un portable ou une station de travail ? Utilisez Ollama. Passez à autre chose quand il vous faut des métriques, de l'authentification ou un contrôle par requête.
2. Travaillez-vous sur un Mac, un serveur sans GPU ou une carte grand public dont la VRAM contient à peine le modèle, voire pas du tout ? Utilisez llama-server. La quantification GGUF et le déchargement partiel lui permettent de tourner là où vLLM ne peut pas charger le modèle.
3. S'agit-il d'une petite équipe avec quelques utilisateurs simultanés sur une seule machine ? Utilisez llama-server avec -np réglé sur la concurrence de pointe, une clé d'API, --metrics et un proxy. Ollama convient aussi si tout le monde partage un ou deux modèles et que le proxy se charge de l'authentification.
4. Attendez-vous un trafic concurrent soutenu, des objectifs de latence, plusieurs GPU ou des formats de quantification GPU comme FP8 ou AWQ ? Utilisez vLLM, lié à localhost derrière une passerelle, avec des images épinglées et une collecte Prometheus dès le premier jour.

Beaucoup d'équipes finissent par en utiliser deux : Ollama ou llama-server sur les postes de développement, vLLM en staging et en production, et le même code client OpenAI partout. Cela ne fonctionne que si la suite d'évaluation tourne sur l'artefact de production, car une quantification GGUF et un checkpoint FP8 du même modèle se comportent en pratique comme des modèles différents. Le guide d'architecture d'un agent IA en production détaille la passerelle, les timeouts, les nouvelles tentatives et les solutions de repli à placer devant n'importe lequel de ces serveurs.

Checklist de déploiement

• Choisissez le serveur avec l'arbre de décision et consignez le fichier de modèle exact, la quantification et le template de chat que vous servirez.
• Calculez la mémoire du cache KV pour la concurrence de pointe et le contexte maximal, puis réglez OLLAMA_CONTEXT_LENGTH, -c et -np, ou --max-model-len et --max-num-seqs en conséquence.
• Écoutez sur 127.0.0.1, passez explicitement --host 127.0.0.1 à vLLM et publiez les ports Docker sous la forme 127.0.0.1:port:port.
• Placez TLS, l'authentification, une liste d'endpoints autorisés et la limitation de débit dans un reverse proxy. N'exposez jamais un port d'inférence sans authentification.
• Définissez une clé sur llama-server ou vLLM comme seconde couche, et gardez-la hors de l'historique du shell et des couches d'image.
• Collectez /metrics sur llama-server et vLLM, et interrogez /api/ps d'Ollama, via un réseau privé.
• Faites un test de charge avec vos propres prompts à la concurrence attendue, en relevant le temps jusqu'au premier token, les tokens par seconde, la longueur de file et la mémoire.
• Validez la sortie structurée contre son schéma dans le code et traitez les arguments d'outils comme des entrées non fiables.
• Épinglez les versions et les digests d'image, et relancez la suite d'évaluation à chaque changement de serveur, de fichier de modèle, de quantification ou d'image.