Comment deployer un LLM open source sur un serveur local d'entreprise en 7 etapes

Deployer un LLM open source sur un serveur local d'entreprise n'est plus reserve aux geants de la tech. En 2026, des modeles comme Llama 4, Mistral Medium 3.5, Qwen 3 et DeepSeek V4 offrent des performances qui rivalisent avec GPT-4o et Claude — sans envoyer la moindre donnee a un tiers. Pour les entreprises francaises, c'est un levier strategique : maitriser ses donnees, reduire les couts recurrents d'API, et se conformer au RGPD sans compromettre la qualite des reponses.

Pourtant, le passage du prototype a la production reste un obstacle pour de nombreuses equipes. Entre le dimensionnement GPU, le choix du framework d'inference, la configuration reseau et l'optimisation des performances, les pieges sont nombreux. Ce guide vous accompagne a travers 7 etapes concretes pour deployer un LLM open source en local, du choix du modele jusqu'au monitoring en production. Chaque etape est illustree par du code fonctionnel et des configurations testees sur des infrastructures francaises.

Etape 1 — Evaluer les besoins et choisir le modele

Le choix du modele determine tout le reste : dimensionnement serveur, performances attendues, et cout d'infrastructure. Ne partez jamais du modele le plus gros « parce qu'il est meilleur » — partez de votre cas d'usage. Un modele 7B bien optimise surpasse souvent un 70B mal configure pour une tache specifique.

Les quatre familles de modeles open source qui dominent en 2026 :

Llama 4 (Meta) : La reference pour le raisonnement general. Llama 4 Scout (17B actifs, architecture MoE) offre un excellent rapport taille-performance. Llama 4 Maverick (400B) est reserve aux infrastructures multi-GPU. Licence permissive (Llama Community License), compatible avec un usage commercial sans restriction de taille d'audience.

Mistral Medium 3.5 : Developpe par l'equipe francaise Mistral AI, ce modele excelle en francais et en raisonnement structure. Sa taille compacte (environ 40B parametres) le rend deployable sur un seul serveur avec 2 GPU. Ideal pour les entreprises francaises qui veulent un modele natif en francais avec un support europeen.

Qwen 3 (Alibaba) : Particulierement performant en generation de code et en raisonnement mathematique. Les versions 7B, 14B et 32B couvrent tous les budgets GPU. Licence Apache 2.0, la plus permissive du lot. Le mode « thinking » integre (similaire a o1) est un atout unique pour les taches complexes.

DeepSeek V4 : Architecture MoE avec des performances de pointe sur les benchmarks. Excellent pour le code et le raisonnement long. Necessite plus de VRAM que les alternatives a performance egale en raison de son architecture, mais offre un debit eleve grace au routage dynamique des experts.

Pour vous aider dans le choix, voici un arbre de decision visuel :

Etape 2 — Dimensionner le serveur (GPU, RAM, stockage)

Le dimensionnement du serveur est l'etape ou les erreurs coutent le plus cher. Sous-dimensionner signifie des temps de reponse inacceptables ; surdimensionner gaspille du budget. La regle fondamentale : la VRAM GPU est le facteur limitant, pas la RAM systeme ni le CPU.

Pour calculer la VRAM necessaire, utilisez cette formule simplifiee : VRAM (Go) = Nombre de parametres (milliards) x Bits de quantification / 8 + 2 Go (overhead). Par exemple, un modele 32B en quantification Q4 (4 bits) necessite : 32 x 4 / 8 + 2 = 18 Go de VRAM. Ajoutez 20 a 30 % pour le KV cache si vous prevoyez des contextes longs ou du batching.

Voici les configurations recommandees selon le profil d'utilisation :

Equipe de developpement (2-10 personnes) : un serveur tour avec 1 GPU NVIDIA RTX 4090 (24 Go VRAM), 64 Go de RAM DDR5, un SSD NVMe 2 To, et un processeur AMD EPYC ou Intel Xeon recents. Budget : environ 5 000 a 8 000 euros. Permet de faire tourner Llama 4 Scout, Qwen 3 32B quantifie, ou Mistral 7B en pleine precision.

Departement ou business unit (10-50 personnes) : un serveur rack avec 2 GPU NVIDIA A100 80 Go (ou L40S 48 Go), 256 Go de RAM ECC, un RAID SSD NVMe 4 To, alimentation redondante. Budget : 25 000 a 45 000 euros. Permet de deployer Mistral Medium 3.5, DeepSeek V4, ou Llama 4 Maverick en quantification.

Alternative cloud (location mensuelle) : Pour les entreprises qui preferent l'OPEX au CAPEX, OVH propose des instances GPU a partir de 300 euros par mois (T4), et Scaleway des GPU H100 a environ 2 500 euros par mois. L'avantage est l'elasticite ; l'inconvenient, le cout cumulatif sur 2-3 ans qui depasse largement l'achat.

# Verifier la VRAM disponible sur le serveur
nvidia-smi --query-gpu=name,memory.total,memory.free,driver_version \
  --format=csv,noheader

# Resultat attendu (exemple avec 2x A100) :
# NVIDIA A100-SXM4-80GB, 81920 MiB, 81520 MiB, 555.42.06
# NVIDIA A100-SXM4-80GB, 81920 MiB, 81520 MiB, 555.42.06

# Estimer la VRAM necessaire pour un modele
python3 -c "
params_b = 32  # milliards de parametres
quant_bits = 4  # quantification Q4
overhead_go = 2  # overhead runtime
vram_go = (params_b * quant_bits / 8) + overhead_go
print(f'VRAM estimee: {vram_go:.1f} Go')
print(f'Avec KV cache (ctx 8k): {vram_go * 1.3:.1f} Go')
"

Etape 3 — Installer l'environnement (CUDA, Docker, nvidia-container-toolkit)

L'installation de l'environnement est l'etape la plus technique. L'ordre d'installation est critique : les drivers NVIDIA d'abord, puis CUDA, puis Docker, puis le nvidia-container-toolkit. Une inversion provoque des erreurs difficiles a diagnostiquer.

#!/bin/bash
# install-llm-stack.sh — Ubuntu 22.04 / 24.04 LTS

set -euo pipefail

echo "=== 1. Mise a jour systeme ==="
sudo apt update && sudo apt upgrade -y
sudo apt install -y build-essential curl wget git

echo "=== 2. Drivers NVIDIA ==="
# Installer le driver recommande automatiquement
sudo apt install -y nvidia-driver-555
sudo reboot  # Necessaire apres l'installation du driver

echo "=== 3. CUDA Toolkit 12.x ==="
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-6

# Ajouter CUDA au PATH
echo 'export PATH=/usr/local/cuda/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc
source ~/.bashrc

echo "=== 4. Docker Engine ==="
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER
sudo systemctl enable docker

echo "=== 5. NVIDIA Container Toolkit ==="
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \
  | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \
  | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \
  | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt update
sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

echo "=== 6. Verification ==="
nvidia-smi
docker run --rm --gpus all nvidia/cuda:12.6.0-base-ubuntu24.04 nvidia-smi
echo "Installation terminee avec succes."

Apres l'execution de ce script, la commande docker run --rm --gpus all nvidia/cuda:12.6.0-base-ubuntu24.04 nvidia-smi doit afficher vos GPU avec la version CUDA. Si ce n'est pas le cas, verifiez que le nvidia-container-toolkit est bien configure avec nvidia-ctk runtime configure --runtime=docker et que Docker a ete redemarre.

Pour les deploiements sur des serveurs d'entreprise avec des contraintes de securite strictes (pas d'acces Internet direct), telechargez les paquets .deb sur une machine connectee et transferez-les via scp ou une cle USB. Les images Docker et les poids des modeles peuvent egalement etre precharges et importes avec docker load. Pour un guide detaille sur le deploiement d'Ollama avec Docker dans un contexte securise, consultez notre article sur le deploiement Ollama en production securisee avec Docker.

Etape 4 — Deployer avec vLLM ou Ollama

Deux frameworks dominent le deploiement de LLM en local : vLLM pour la production haute performance et Ollama pour la simplicite. Voici les configurations Docker pour chacun.

Option A : Deploiement avec vLLM (recommande pour la production)

# docker-compose.vllm.yml
services:
  vllm:
    image: vllm/vllm-openai:v0.8.3
    container_name: vllm-server
    restart: unless-stopped
    ports:
      - "127.0.0.1:8000:8000"  # Localhost uniquement
    volumes:
      - ./models:/root/.cache/huggingface:rw
    environment:
      - HUGGING_FACE_HUB_TOKEN=${HF_TOKEN}
    command: >
      --model meta-llama/Llama-4-Scout-17B-16E-Instruct
      --tensor-parallel-size 1
      --max-model-len 16384
      --gpu-memory-utilization 0.90
      --enable-prefix-caching
      --max-num-batched-tokens 32768
      --max-num-seqs 64
      --served-model-name llama-4-scout
      --api-key ${VLLM_API_KEY}
      --host 0.0.0.0
      --port 8000
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
        limits:
          memory: 32G
    networks:
      - llm-internal

  # Pour deployer Mistral en parallele sur un 2e GPU :
  vllm-mistral:
    image: vllm/vllm-openai:v0.8.3
    container_name: vllm-mistral
    restart: unless-stopped
    ports:
      - "127.0.0.1:8001:8000"
    volumes:
      - ./models:/root/.cache/huggingface:rw
    environment:
      - HUGGING_FACE_HUB_TOKEN=${HF_TOKEN}
      - CUDA_VISIBLE_DEVICES=1
    command: >
      --model mistralai/Mistral-Medium-3.5
      --tensor-parallel-size 1
      --max-model-len 32768
      --gpu-memory-utilization 0.90
      --quantization awq
      --served-model-name mistral-medium
      --api-key ${VLLM_API_KEY}
      --host 0.0.0.0
      --port 8000
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              device_ids: ['1']
              capabilities: [gpu]
    networks:
      - llm-internal

networks:
  llm-internal:
    internal: true

Option B : Deploiement avec Ollama (plus simple, ideal pour les petites equipes)

# docker-compose.ollama.yml
services:
  ollama:
    image: ollama/ollama:0.18
    container_name: ollama-server
    restart: unless-stopped
    ports:
      - "127.0.0.1:11434:11434"
    volumes:
      - ollama-data:/root/.ollama
    environment:
      - OLLAMA_HOST=0.0.0.0:11434
      - OLLAMA_NUM_PARALLEL=8
      - OLLAMA_MAX_LOADED_MODELS=3
      - OLLAMA_KEEP_ALIVE=10m
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    networks:
      - llm-internal

networks:
  llm-internal:
    internal: true

volumes:
  ollama-data:

# Apres le lancement, telecharger les modeles :
# docker exec ollama-server ollama pull llama4-scout
# docker exec ollama-server ollama pull qwen3:32b
# docker exec ollama-server ollama pull mistral:medium

La difference cle entre les deux : vLLM utilise PagedAttention et le continuous batching, ce qui lui permet de traiter 3 a 5 fois plus de requetes simultanees qu'Ollama avec la meme quantite de VRAM. En revanche, Ollama est operationnel en 5 minutes avec une simple commande ollama pull, sans gerer les tokens Hugging Face ni les formats de modeles. Pour une analyse detaillee de la configuration Mistral avec vLLM, consultez notre guide sur Mistral Medium 3.5 en local avec vLLM.

Etape 5 — Configurer l'API et le reverse proxy

Un LLM en local sans reverse proxy est un LLM expose. Nginx gere l'authentification, le chiffrement TLS, le rate limiting et le load balancing entre plusieurs instances. Voici la configuration complete :

# nginx/nginx.conf — Reverse proxy pour LLM local
worker_processes auto;
error_log /var/log/nginx/error.log warn;

events {
    worker_connections 1024;
}

http {
    # Rate limiting par IP
    limit_req_zone $binary_remote_addr zone=llm_api:10m rate=30r/s;

    # Timeouts adaptes a l'inference LLM (reponses longues)
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
    proxy_connect_timeout 10s;

    # Upstream : basculer entre vLLM et Ollama selon votre choix
    upstream llm_backend {
        # Option vLLM :
        server vllm-server:8000;
        # Option Ollama :
        # server ollama-server:11434;
    }

    server {
        listen 443 ssl http2;
        server_name llm.votre-entreprise.fr;

        # TLS
        ssl_certificate /etc/ssl/certs/llm-cert.pem;
        ssl_certificate_key /etc/ssl/private/llm-key.pem;
        ssl_protocols TLSv1.3;

        # Headers securite
        add_header X-Frame-Options DENY always;
        add_header X-Content-Type-Options nosniff always;
        add_header Strict-Transport-Security "max-age=63072000" always;

        # Authentification Bearer
        location /v1/ {
            limit_req zone=llm_api burst=50 nodelay;

            # Verifier le token
            if ($http_authorization != "Bearer VOTRE_API_KEY_INTERNE") {
                return 401 '{"error":"non autorise"}';
            }

            proxy_pass http://llm_backend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

            # Support du streaming SSE
            proxy_buffering off;
            proxy_cache off;
            chunked_transfer_encoding on;
        }

        # Health check (sans auth, pour le monitoring)
        location /health {
            proxy_pass http://llm_backend/health;
            access_log off;
        }
    }
}

L'avantage de cette configuration : vos applications internes interrogent le LLM local via une API compatible OpenAI. Il suffit de changer le base_url dans vos clients OpenAI existants pour pointer vers https://llm.votre-entreprise.fr/v1. Aucune modification de code n'est necessaire dans vos applications.

# Tester l'API depuis un poste client
curl -X POST https://llm.votre-entreprise.fr/v1/chat/completions \
  -H "Authorization: Bearer VOTRE_API_KEY_INTERNE" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-4-scout",
    "messages": [
      {"role": "system", "content": "Tu es un assistant IA interne."},
      {"role": "user", "content": "Resume ce document en 3 points."}
    ],
    "temperature": 0.7,
    "max_tokens": 1024,
    "stream": true
  }'

# Utilisation en Python (compatible openai SDK)
# from openai import OpenAI
# client = OpenAI(
#     base_url="https://llm.votre-entreprise.fr/v1",
#     api_key="VOTRE_API_KEY_INTERNE"
# )
# response = client.chat.completions.create(
#     model="llama-4-scout",
#     messages=[{"role": "user", "content": "Bonjour"}]
# )

Etape 6 — Optimiser les performances (quantification, batching, KV cache)

Un modele deploye brut ne donne jamais ses meilleures performances. Trois leviers d'optimisation sont essentiels : la quantification, le batching, et la gestion du KV cache.

Quantification : reduire la precision numerique des poids du modele (de 16 bits a 4 ou 8 bits) diminue la VRAM necessaire et accelere l'inference avec une perte de qualite minime. Les formats recommandes en 2026 :

• AWQ (Activation-aware Weight Quantization) : le meilleur rapport qualite-compression pour vLLM. Perte negligeable jusqu'a Q4.
• GPTQ : alternative mature, bien supportee par tous les frameworks. Legerement inferieur a AWQ en qualite a compression egale.
• GGUF (llama.cpp) : format natif d'Ollama. Simple a utiliser avec des modeles pre-quantifies disponibles sur Hugging Face.

# Deployer un modele AWQ quantifie avec vLLM
# Ajouter --quantization awq au lancement
docker compose exec vllm python -m vllm.entrypoints.openai.api_server \
  --model TheBloke/Qwen3-32B-AWQ \
  --quantization awq \
  --max-model-len 16384 \
  --gpu-memory-utilization 0.92

# Avec Ollama, la quantification est automatique :
# ollama pull qwen3:32b-q4_K_M
# Le suffixe q4_K_M indique la methode de quantification

# Benchmark rapide des performances
# Installer llm-benchmark :
pip install llm-benchmark

llm-benchmark --endpoint https://llm.votre-entreprise.fr/v1 \
  --api-key VOTRE_API_KEY \
  --model llama-4-scout \
  --concurrent-users 10 \
  --num-prompts 100 \
  --max-tokens 256

Continuous batching : plutot que de traiter les requetes une par une, vLLM regroupe automatiquement les requetes en cours dans un seul batch GPU. C'est ce qui explique la difference de debit entre vLLM et une inference naive. Le parametre --max-num-seqs controle le nombre maximum de sequences traitees simultanement — augmentez-le si vous avez de la VRAM disponible.

KV cache et prefix caching : le KV cache stocke les calculs d'attention pour eviter de les recalculer a chaque token. Le --enable-prefix-caching de vLLM va plus loin en reutilisant les calculs entre requetes qui partagent le meme prefixe (par exemple, le meme prompt systeme). Cela accelere considerablement les cas d'usage RAG ou le prompt systeme est identique pour toutes les requetes. Consultez egalement notre guide complet sur le deploiement de modeles IA open source pour les PME qui couvre d'autres strategies d'optimisation.

Etape 7 — Monitoring, maintenance et mise a jour

Un LLM en production sans monitoring est une bombe a retardement. Les metriques specifiques a l'inference LLM sont differentes de celles d'un serveur web classique. Voici les indicateurs critiques a surveiller et la configuration Prometheus pour les collecter.

# docker-compose.monitoring.yml
services:
  prometheus:
    image: prom/prometheus:v2.54.0
    container_name: llm-prometheus
    volumes:
      - ./monitoring/prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prometheus-data:/prometheus
    ports:
      - "127.0.0.1:9090:9090"
    networks:
      - llm-internal

  grafana:
    image: grafana/grafana:11.2.0
    container_name: llm-grafana
    volumes:
      - grafana-data:/var/lib/grafana
      - ./monitoring/dashboards:/etc/grafana/provisioning/dashboards:ro
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_PASSWORD}
    networks:
      - llm-internal

  nvidia-exporter:
    image: utkuozdemir/nvidia_gpu_exporter:1.3.0
    container_name: nvidia-exporter
    devices:
      - /dev/nvidiactl
      - /dev/nvidia0
    volumes:
      - /usr/bin/nvidia-smi:/usr/bin/nvidia-smi:ro
      - /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1:/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1:ro
    ports:
      - "127.0.0.1:9835:9835"
    networks:
      - llm-internal

volumes:
  prometheus-data:
  grafana-data:

# --- monitoring/prometheus.yml ---
# global:
#   scrape_interval: 15s
#
# scrape_configs:
#   - job_name: 'vllm'
#     static_configs:
#       - targets: ['vllm-server:8000']
#     metrics_path: /metrics
#
#   - job_name: 'nvidia-gpu'
#     static_configs:
#       - targets: ['nvidia-exporter:9835']
#
#   - job_name: 'nginx'
#     static_configs:
#       - targets: ['nginx:8080']

Les metriques essentielles a surveiller :

• Tokens par seconde (tokens/s) : le KPI principal. Un Llama 4 Scout sur RTX 4090 doit generer 40 a 80 tokens/s. En dessous de 20, l'experience utilisateur se degrade.
• TTFT (Time To First Token) : le temps entre la requete et le premier token genere. Critique pour les applications interactives. Cible : sous 500 ms.
• Utilisation VRAM : doit rester sous 95 %. Au-dela, les erreurs OOM (Out Of Memory) commencent a apparaitre et le serveur crashe.
• Temperature GPU : les GPU d'inference tournent en charge constante. Au-dessus de 85 degres Celsius, le GPU throttle et les performances chutent. Verifiez la ventilation du serveur.
• Queue depth (profondeur de file d'attente) : le nombre de requetes en attente. Si elle augmente continuellement, c'est le signe que le serveur est sous-dimensionne pour la charge.

Pour la maintenance et les mises a jour, etablissez une routine mensuelle : verifiez les nouvelles versions des modeles (les releases sont frequentes), testez-les sur un environnement de staging avant de les deployer en production, et gardez un journal des versions deployees. La strategie de mise a jour recommandee est le blue-green deployment : lancez la nouvelle version sur un second conteneur, validez les performances, puis basculez le traffic.

#!/bin/bash
# update-model.sh — Mise a jour blue-green d'un modele

NEW_MODEL="meta-llama/Llama-4-Scout-17B-16E-Instruct"
NEW_TAG="v2"

echo "=== 1. Telecharger le nouveau modele ==="
docker compose exec vllm huggingface-cli download $NEW_MODEL

echo "=== 2. Lancer l'instance de staging ==="
docker compose -f docker-compose.staging.yml up -d

echo "=== 3. Tester les performances ==="
llm-benchmark --endpoint http://localhost:8002/v1 \
  --model llama-4-scout \
  --concurrent-users 5 \
  --num-prompts 50

echo "=== 4. Si OK, basculer le traffic ==="
# Modifier l'upstream nginx pour pointer vers la nouvelle instance
# Puis arreter l'ancienne :
# docker compose stop vllm
# docker compose -f docker-compose.staging.yml stop

echo "Mise a jour terminee. Verifier les metriques Grafana."

Pour les equipes qui envisagent de migrer leurs outils de developpement IA existants vers des alternatives open source, notre article sur la migration de GitHub Copilot vers des alternatives open source detaille le processus etape par etape, y compris l'integration avec un serveur LLM local comme celui decrit dans ce guide.

FAQ