Comment utiliser les LLMs locaux comme APIs ?

Votre ordinateur portable peut exposer un modèle de 70 milliards de paramètres derrière un point de terminaison compatible OpenAI, identique à celui utilisé en production. En pratique, vous changez une seule valeur (base_url) et votre code continue de fonctionner. Ce guide montre comment choisir un runtime local, exposer l’API, connecter vos clients OpenAI existants, puis valider le flux avec Apidog avant de basculer vers un modèle hébergé.

Essayez Apidog aujourd’hui

En bref

Vous pouvez exécuter une API LLM locale avec Ollama, vLLM ou llama.cpp. Ces runtimes exposent des endpoints REST compatibles OpenAI, par exemple :

http://localhost:11434/v1

Dans un client OpenAI existant, il suffit de remplacer :

base_url="https://api.openai.com/v1"

par :

base_url="http://localhost:11434/v1"

Le même code peut alors appeler Llama 3.3, DeepSeek V4 ou Qwen 3.6 en local, sans réécriture majeure. Avec Apidog, vous pouvez garder les mêmes scénarios de test entre local, staging et production.

Introduction

La pile d’API LLM locales est passée du prototype de recherche à un environnement de développement quotidien. Le changement clé : les runtimes majeurs parlent désormais le format OpenAI /v1/chat/completions.

Conséquence directe : vous n’avez plus besoin de maintenir deux clients.

• En local : http://localhost:11434/v1
• En production : https://api.openai.com/v1
• Même SDK
• Même schéma JSON
• Même logique de test

Pour les développeurs d’API, c’est important. Vos modèles de requêtes dans Apidog peuvent pointer vers https://api.openai.com/v1/chat/completions, puis basculer vers localhost via une variable d’environnement. Si vous suivez déjà les dépenses d’API par fonctionnalité, vous pouvez comparer un modèle local et un modèle hébergé avec les mêmes scénarios.

Ce guide couvre :

• le choix du runtime ;
• la configuration du serveur local ;
• le câblage client en Python et JavaScript ;
• les tests de scénario dans Apidog ;
• les compromis de quantification ;
• le calcul coût/latence entre local et hébergé.

Pour un aperçu plus large des modèles, consultez Meilleurs LLM locaux 2026.

Pourquoi les LLM locaux sont utiles pour les développeurs d’API

Une API LLM locale vous donne un environnement de développement qui ressemble à la production, mais sans dépendance réseau.

Cas typiques :

• vous travaillez hors ligne ;
• le réseau client bloque *.openai.com ;
• vous devez tester des prompts contenant des données sensibles ;
• vous voulez réduire le coût des boucles de développement ;
• vous avez besoin d’un modèle stable pour les tests de régression.

Confidentialité

HIPAA, GDPR et l’EU AI Act considèrent les prompts comme des données utilisateur dès qu’ils contiennent des notes médicales, contrats, identifiants ou données biométriques.

Un modèle local évite d’envoyer ces données vers un endpoint hébergé. Pour les charges réglementées, c’est souvent plus simple à auditer : les données restent sur la machine ou dans le réseau privé.

Coût

Une équipe qui envoie 50 millions de tokens d’entrée par jour vers un modèle hébergé paie un coût récurrent. En local, le coût marginal par token tombe à zéro une fois le matériel payé.

Vous pouvez appliquer le même raisonnement à votre propre volume à partir d’une ventilation comme Comment utiliser GPT-5.5 Instant.

Stabilité

Un modèle local est un fichier sur disque. Il ne change pas tant que vous ne le remplacez pas.

C’est utile si :

• vos tests dépendent de réponses LLM ;
• vous voulez comparer deux versions de modèle ;
• vous devez reproduire un bug plusieurs mois plus tard.

Trois runtimes pour exposer une API compatible OpenAI

Choisissez le runtime selon votre charge de travail, pas seulement selon sa popularité.

Ollama

Ollama est le chemin le plus simple pour démarrer.

Il fournit :

• un binaire ;
• une CLI ;
• un serveur HTTP local ;
• des modèles téléchargeables avec ollama pull ;
• un endpoint compatible OpenAI sur http://localhost:11434/v1.

Installation sur macOS :

brew install ollama
ollama serve &
ollama pull llama3.3:70b-instruct-q4_K_M
ollama run llama3.3:70b-instruct-q4_K_M

Endpoint OpenAI-compatible :

http://localhost:11434/v1

Ollama convient bien pour :

• le développement mono-utilisateur ;
• les démos ;
• les tests locaux ;
• les runners CI simples ;
• les machines Apple Silicon.

vLLM

vLLM est plus adapté aux environnements partagés ou proches de la production.

Il utilise PagedAttention et le batching continu pour augmenter le débit sur GPU. Il expose une API compatible OpenAI sur /v1.

Exemple :

pip install vllm

vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --port 8000 \
  --gpu-memory-utilization 0.9 \
  --max-model-len 8192

Endpoint :

http://localhost:8000/v1

vLLM convient bien pour :

• les GPU NVIDIA CUDA ;
• les cartes AMD ROCm récentes ;
• les clusters internes ;
• les équipes qui envoient plusieurs requêtes concurrentes ;
• les benchmarks de débit.

Il n’est pas le meilleur choix pour un ordinateur portable Apple Silicon.

llama.cpp

llama.cpp est le runtime C++ qui a popularisé l’écosystème GGUF. Il fonctionne sur beaucoup de matériels, du Raspberry Pi aux configurations multi-GPU.

Son binaire llama-server expose /v1/chat/completions.

Exemple avec Metal sur macOS :

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp && make -j LLAMA_METAL=1

./llama-server -m models/llama-3.3-70b-q4_k_m.gguf \
  --port 8080 \
  --host 0.0.0.0 \
  -c 8192 \
  -ngl 99

Endpoint :

http://localhost:8080/v1

Le drapeau -ngl 99 décharge autant de couches que possible sur le GPU.

llama.cpp convient bien si vous devez :

• contrôler finement la quantification ;
• faire rentrer un modèle dans peu de VRAM ;
• tester du matériel atypique ;
• exécuter un modèle GGUF sans couche logicielle lourde.

LM Studio et Jan enveloppent llama.cpp dans une interface graphique et exposent aussi un endpoint OpenAI local. Ils sont pratiques pour les équipes non techniques qui veulent tester des prompts sans terminal.

Vérifier que l’endpoint local fonctionne

Avant d’intégrer le runtime à votre application, testez le contrat OpenAI avec un petit script.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama",
)

resp = client.chat.completions.create(
    model="llama3.3:70b-instruct-q4_K_M",
    messages=[
        {
            "role": "user",
            "content": "Reply with the word OK only."
        }
    ],
)

print(resp.choices[0].message.content)

Résultat attendu :

OK

Si vous obtenez cette réponse, trois choses sont validées :

• le runtime est lancé ;
• le port est correct ;
• le SDK OpenAI comprend la réponse.

Tester votre LLM local avec Apidog

Une API LLM locale n’est utile que si vos tests peuvent l’appeler comme ils appellent la production. Apidog permet de gérer cela avec des variables d’environnement.

Étape 1 : créer un environnement Local

Dans Apidog, créez un environnement appelé Local.

Ajoutez :

BASE_URL=http://localhost:11434/v1
API_KEY=ollama

Étape 2 : créer un environnement Production

Clonez votre environnement OpenAI existant, puis configurez :

BASE_URL=https://api.openai.com/v1
API_KEY=<votre_clé_openai>

Étape 3 : variabiliser la requête

Remplacez les valeurs codées en dur par les variables Apidog.

URL :

{{BASE_URL}}/chat/completions

Header :

Authorization: Bearer {{API_KEY}}
Content-Type: application/json

Body :

{
  "model": "llama3.3:70b-instruct-q4_K_M",
  "messages": [
    {
      "role": "user",
      "content": "Réponds uniquement avec OK."
    }
  ]
}

Étape 4 : ajouter des assertions

Créez un scénario de test avec ces assertions :

choices[0].message.role == "assistant"
choices[0].message.content != ""
usage.total_tokens > 0

Étape 5 : exécuter contre local et production

Lancez le scénario contre Local.

Puis changez l’environnement vers Production et relancez.

Le même scénario doit passer sur les deux cibles.

Ce flux sert aussi de test de fumée après une mise à jour de modèle. Après un ollama pull, relancez le scénario local. Si la forme de réponse dérive, vous le détectez avant que l’application ne l’utilise.

Le même principe s’étend aux tests d’agents IA qui appellent des API multi-étapes.

Basculer entre local et production en Python

Voici une structure minimale avec le SDK OpenAI :

import os
from openai import OpenAI

def get_client():
    if os.getenv("ENV") == "local":
        return OpenAI(
            base_url="http://localhost:11434/v1",
            api_key="ollama",
        )

    return OpenAI(
        api_key=os.environ["OPENAI_API_KEY"]
    )

client = get_client()

response = client.chat.completions.create(
    model=os.getenv("MODEL", "llama3.3:70b-instruct-q4_K_M"),
    messages=[
        {
            "role": "system",
            "content": "You are a JSON-only assistant."
        },
        {
            "role": "user",
            "content": "Return {\"status\": \"ok\"}."
        },
    ],
    response_format={"type": "json_object"},
)

print(response.choices[0].message.content)

Exécution locale :

ENV=local MODEL=llama3.3:70b-instruct-q4_K_M python app.py

Exécution production :

ENV=production OPENAI_API_KEY=sk-... python app.py

Basculer entre local et production en JavaScript

Même logique avec le SDK JavaScript :

import OpenAI from "openai";

const isLocal = process.env.ENV === "local";

const client = new OpenAI({
  baseURL: isLocal
    ? "http://localhost:11434/v1"
    : "https://api.openai.com/v1",
  apiKey: isLocal
    ? "ollama"
    : process.env.OPENAI_API_KEY,
});

const resp = await client.chat.completions.create({
  model: process.env.MODEL || "llama3.3:70b-instruct-q4_K_M",
  messages: [
    {
      role: "user",
      content: "Say hi."
    }
  ],
});

console.log(resp.choices[0].message.content);

Exécution :

ENV=local node app.js

Intégrer les tests Apidog à la CI

Une fois les scénarios Apidog prêts, vous pouvez les exécuter dans la CI avec apidog-cli.

Exemple GitHub Actions :

name: API tests

on:
  pull_request:
  push:
    branches:
      - main

jobs:
  apidog-tests:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run local-compatible API scenarios
        run: apidog run

Si une assertion échoue, la commande renvoie un code non nul et le build échoue.

Les équipes QA peuvent intégrer ce modèle dans leurs pipelines de test d’API.

Techniques avancées et astuces de pro

Choisir la bonne quantification

La quantification détermine si un modèle tient dans votre mémoire.

Le format GGUF stocke les poids en 8, 6, 5, 4, 3 ou 2 bits par paramètre.

Règle pratique :

Quantification	Usage recommandé
Q8	génération de code, meilleure qualité, plus de RAM
Q5_K_M	bon compromis si vous avez assez de mémoire
Q4_K_M	choix par défaut pour le chat
Q2_K	faible mémoire, qualité plus dégradée

Q4_K_M est souvent le meilleur point de départ : il réduit fortement l’empreinte mémoire tout en conservant une qualité acceptable pour beaucoup de tâches de chat.

Ajuster le déchargement GPU

Avec llama.cpp :

-ngl 99

Avec Ollama, utilisez les options de modèle/runtime disponibles pour contrôler le nombre de couches sur GPU.

Plus vous déchargez de couches sur le GPU, plus le débit augmente. Si des couches retombent sur CPU, la génération ralentit fortement.

Garder mmap activé

mmap est activé par défaut dans llama.cpp et Ollama.

Il permet au système d’exploitation de charger les poids à la demande au lieu de tout allouer au démarrage.

Gardez-le activé sauf si vous exécutez le modèle dans un conteneur avec des limites mémoire strictes.

Utiliser le batching avec vLLM

Le batching est l’un des principaux avantages de vLLM.

Exemple :

vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --port 8000 \
  --max-num-seqs 64

Pour du matériel plus puissant, vous pouvez augmenter :

--max-num-seqs 256

Cela permet de traiter plus de requêtes concurrentes dans une même passe GPU.

Activer le streaming

Le streaming réduit la latence perçue.

Python :

stream = client.chat.completions.create(
    model="llama3.3:70b-instruct-q4_K_M",
    messages=[{"role": "user", "content": "Explique mmap en une phrase."}],
    stream=True,
)

for event in stream:
    delta = event.choices[0].delta.content
    if delta:
        print(delta, end="")

Au lieu d’attendre la réponse complète, votre application reçoit les tokens au fur et à mesure.

Utiliser un Modelfile Ollama

Un Modelfile permet d’intégrer une invite système, une température ou des séquences d’arrêt.

Exemple :

FROM llama3.3:70b-instruct-q4_K_M

SYSTEM """
Tu es un assistant API. Réponds de façon concise et technique.
"""

PARAMETER temperature 0.2
PARAMETER stop "<END>"

Créer le modèle :

ollama create my-assistant -f Modelfile

Puis appeler :

response = client.chat.completions.create(
    model="my-assistant",
    messages=[
        {"role": "user", "content": "Explique le code HTTP 429."}
    ],
)

Erreurs courantes

Évitez ces pièges :

• coder http://localhost:11434 en dur dans le code applicatif ;
• oublier de déplacer base_url dans une variable d’environnement ;
• utiliser un modèle local sans limite de génération ;
• supposer qu’Ollama et vLLM utilisent le même port ;
• oublier l’en-tête Authorization alors que vLLM est lancé avec --api-key ;
• attendre d’un modèle Q4 la même qualité qu’un modèle hébergé haut de gamme ;
• ne pas tester la forme JSON de la réponse avant intégration.

Local vs hébergé : coût et latence

Les chiffres ci-dessous supposent un M3 Max avec 128 Go de mémoire unifiée pour le local, et des prix publics pour les endpoints hébergés. Le temps jusqu’au premier token, ou TTFT, est mesuré à froid sur une invite de 1 024 tokens.

Model	Local TTFT	Local throughput	Hosted equivalent	Hosted price	Hosted TTFT
Llama 3.3 70B Q4_K_M	1.2 s	12 tok/s	GPT-5.5 Instant	$5 / $30 per 1M	200 ms
DeepSeek V4 67B Q4_K_M	1.4 s	10 tok/s	DeepSeek-Chat hosted	$0.55 / $2.20 per 1M	280 ms
Qwen 3.6 32B Q5_K_M	0.7 s	28 tok/s	Qwen-Max hosted	$1.60 / $6.40 per 1M	240 ms
Gemma 4 27B Q4_K_M	0.5 s	35 tok/s	Gemini 3 Flash	$0.35 / $1.05 per 1M	180 ms

Lecture pratique :

• l’hébergé gagne presque toujours en latence ;
• le local gagne en confidentialité dès la première requête ;
• le local devient intéressant en coût lorsque le volume quotidien augmente ;
• pour le développement, le local est souvent plus pratique ;
• pour la production utilisateur, l’hébergé reste souvent préférable sauf contrainte réglementaire.

Un modèle simple :

1. développez en local ;
2. testez en staging avec le modèle hébergé ;
3. gardez les deux environnements au vert dans la CI.

Pour approfondir certains modèles, consultez Comment exécuter DeepSeek V4 localement et le guide d’utilisation original de DeepSeek V4.

Cas d’utilisation réels

Conformité fintech

Une équipe de conformité fintech à Singapour utilise Ollama sur les ordinateurs portables des ingénieurs pour rédiger des rapports d’activités suspectes.

Les prompts contiennent des numéros de compte et des schémas de transaction qui ne peuvent pas quitter le pays selon les règles MAS.

Leur approche :

• exécution locale pour les données brutes ;
• endpoint hébergé uniquement avec une version expurgée ;
• scénarios Apidog pour vérifier que la rédaction est exécutée avant toute sortie de localhost.

Studio de jeux

Un studio de jeux à Stockholm forme ses designers à l’ingénierie de prompt avec une instance locale de Qwen 3.6.

Avantages :

• gratuit pendant la formation ;
• utilisable hors ligne ;
• aucun risque de fuite de scénario vers un tiers.

Le même projet est ensuite livré contre Gemini 3 Flash en production avec un changement de variable d’environnement. Ils réutilisent le guide de l’API Gemini 3 Flash pour le câblage de production.

Santé

Une startup de santé exécute vLLM sur un A100 loué dans le réseau hospitalier du client.

Le endpoint :

• n’a pas de DNS public ;
• reste dans le VLAN du client ;
• est testé depuis un agent Jenkins interne ;
• utilise le même SDK OpenAI que les environnements locaux.

Résultat : même code, trois cibles de déploiement, une suite de scénarios.

Checklist d’implémentation

Avant de pousser votre intégration LLM locale, vérifiez :

• [ ] le runtime est choisi : Ollama, vLLM ou llama.cpp ;
• [ ] l’endpoint /v1 répond ;
• [ ] le SDK OpenAI fonctionne contre localhost ;
• [ ] base_url est une variable d’environnement ;
• [ ] api_key est une variable d’environnement ;
• [ ] les requêtes Apidog utilisent {{BASE_URL}} ;
• [ ] les assertions valident la structure de réponse ;
• [ ] les scénarios passent en local ;
• [ ] les mêmes scénarios passent en production ;
• [ ] la CI échoue en cas de dérive du contrat.

Conclusion

Les API LLM locales sont maintenant assez mûres pour être intégrées dans une boucle de développement API sérieuse.

Les étapes essentielles :

1. Choisissez Ollama pour les ordinateurs portables, vLLM pour les environnements partagés, llama.cpp pour le contrôle bas niveau.
2. Exposez un endpoint compatible OpenAI.
3. Vérifiez-le avec le SDK OpenAI.
4. Déplacez base_url et api_key dans des variables d’environnement.
5. Créez des scénarios dans Apidog pour tester local et production avec le même contrat.
6. Utilisez le tableau coût/latence pour choisir la bonne cible selon la charge de travail.

Si vous n’avez pas encore choisi de modèle, commencez par Meilleurs LLM locaux 2026. Pour tester des flux d’agents plus complexes sur ces endpoints, lisez Comment tester l’API des agents IA.