Comment utiliser les LLMs locaux comme APIs ?

Votre ordinateur portable peut faire tourner un modèle de 70 milliards de paramètres derrière le même point de terminaison de type OpenAI que celui que vous utilisez en production. Changez une seule URL de base et votre code continue de fonctionner. Ce seul changement débloque le développement hors ligne, un coût par jeton nul, et un chemin privé pour les données réglementées, ce qui explique pourquoi Hacker News a fait passer « L'IA locale doit être la norme » de 633 à 1 760 points en une journée. L'article ci-dessous vous montre comment choisir un environnement d'exécution, exposer le point de terminaison, y connecter votre client, et tester l'ensemble du flux avec Apidog avant de promouvoir tout changement vers un modèle hébergé.

En bref

Vous pouvez exécuter une API LLM locale sur votre ordinateur portable avec Ollama, vLLM ou llama.cpp, et chacun d'eux expose un point de terminaison REST compatible OpenAI. Changez `base_url` en `http://localhost:11434/v1` dans votre client OpenAI existant et le même code s'exécutera contre Llama 3.3, DeepSeek V4 ou Qwen 3.6 sans réécriture. Pilotez l'ensemble du flux depuis Apidog afin que vos tests de scénario restent identiques entre les environnements locaux et hébergés.

Introduction

La pile d'API LLM locales est passée du jouet de recherche au pilote quotidien en dix-huit mois. Apple a livré 128 Go de mémoire unifiée sur le M3 Max. Ollama a atteint un million de téléchargements hebdomadaires. vLLM a dépassé la barre des 30 000 étoiles sur GitHub. Le plus grand changement, cependant, a été social. Chaque environnement d'exécution majeur parle maintenant le format OpenAI `/v1/chat/completions`. Vous n'avez plus à maintenir deux chemins clients. Le même appel SDK frappe localhost ou `api.openai.com` en fonction d'une variable d'environnement.

C'est important pour les développeurs d'API car vos outils existants continuent de fonctionner. Vos modèles de requête dans Apidog pointent vers `https://api.openai.com/v1/chat/completions`. Changez la variable d'URL de base, appuyez sur Envoyer, et vous obtenez le même JSON en retour d'un modèle exécuté sur votre propre GPU. Pas de nouveau schéma. Pas de nouveau flux d'authentification. Si vous suivez déjà les dépenses d'API par fonctionnalité, vous pouvez faire un test A/B entre un modèle local et un modèle hébergé et regarder la ligne de coût baisser tandis que la latence augmente.

Ce guide aborde le choix de l'environnement d'exécution, la configuration du serveur, le câblage du client, les tests de scénario, les compromis de quantification et un tableau coût-vs-latence pour quatre modèles actuels. Les exemples de code sont testés avec Ollama 0.6 et vLLM 0.7 sur macOS 15.4 et Ubuntu 24.04. Pour un aperçu plus large des options, consultez Meilleurs LLM locaux 2026. Les références externes pour chaque affirmation se trouvent en bas.

button

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

Vous livrez du code qui appelle un LLM. Vous déboguez également ce code en avion, lors de conférences avec un mauvais Wi-Fi, et au sein de réseaux clients qui bloquent l'accès à `*.openai.com`. Une API LLM locale vous offre un environnement de développement qui reflète la production sans la dépendance réseau.

L'aspect confidentialité est le plus retentissant. HIPAA, GDPR et l'EU AI Act considèrent tous les invites comme des données utilisateur dès qu'elles incluent des notes de patient, des contrats ou des identifiants biométriques. L'envoi de cette charge utile à un point de terminaison hébergé crée une relation de processeur de données que vous devez documenter, auditer et renouveler. Un modèle qui ne quitte jamais votre matériel évite entièrement cette paperasserie. Les lignes directrices de 2024 de l'European Data Protection Board sur le traitement de l'IA notent que l'inférence sur l'appareil supprime la plupart des obligations de transfert transfrontalier en vertu de l'article 44.

Le coût évolue dans l'autre sens. Une équipe qui exécute 50 millions de jetons d'invite par jour via GPT-5.5 Instant paie environ 250 $ par jour à 5 $ par million de jetons. Le même volume sur un studio M3 Max à 4 500 $ s'amortit à zéro après dix-huit jours d'utilisation complète, sans compter l'électricité. Vous pouvez lire une ventilation de ces chiffres dans Comment utiliser GPT-5.5 Instant et appliquer la même arithmétique à votre propre charge de travail.

La troisième raison est le déterminisme. Les modèles hébergés modifient les poids à votre insu. La page de dépréciation des modèles d'OpenAI liste onze retraits de clichés au cours des douze derniers mois. Un modèle local est un fichier sur disque. Il produit les mêmes logits aujourd'hui et dans trois ans. Cette stabilité est importante lorsque votre suite de régression dépend de la sortie du LLM. Le point de terminaison compatible OpenAI a changé la donne car vous ne payez plus de taxe d'intégration pour cette stabilité. Le SDK que vous utilisez déjà fonctionne.

Trois environnements d'exécution qui livrent des points de terminaison compatibles OpenAI

Quatre environnements d'exécution dominent l'espace des API LLM locales en 2026. Trois livrent un serveur REST compatible OpenAI dès le départ. Le quatrième, llama.cpp, en livre un dans le cadre de son binaire `llama-server`. Choisissez en fonction de la charge de travail, et non de la popularité.

Ollama

Ollama est le moyen le plus simple de démarrer. Un binaire, une CLI, un serveur HTTP sur le port 11434. Il cible les développeurs exécutant un seul modèle sur une seule machine et gère pour vous les téléchargements de modèles, la quantification GGUF et la templétisation des invites.

## installer 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

Une fois que `ollama serve` est lancé, le point de terminaison compatible OpenAI se trouve à `http://localhost:11434/v1`. Il prend en charge le chat, les embeddings et le streaming. Le plafond de débit sur un M3 Max avec un modèle 70B Q4_K_M se situe autour de 12 jetons par seconde. Les modèles plus petits atteignent 80 à 120 jetons par seconde. Ollama est le bon choix pour le développement mono-utilisateur, les démos et les runners CI.

vLLM

vLLM est l'option de qualité production. Il utilise PagedAttention et le traitement par lots continu (continuous batching) pour augmenter le débit de deux à quatre fois par rapport aux runners naïfs. Il sert sur le port 8000 par défaut et expose une API compatible OpenAI à `/v1`. Vous pouvez lire les détails de l'architecture dans le document vLLM à la référence Kwon et al. SOSP 2023 ci-dessous.

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

Sur un seul H100, vLLM sert Llama 3.3 70B à environ 2 400 jetons par seconde sur des requêtes concurrentes. Il nécessite un GPU CUDA ou une carte AMD ROCm récente et ne fonctionne pas sur Apple Silicon, ce qui en fait le mauvais choix pour les ordinateurs portables et le bon choix pour les clusters de développement partagés.

llama.cpp

llama.cpp est l'environnement d'exécution C++ qui a lancé l'écosystème GGUF. Il fonctionne partout, du Raspberry Pi 5 aux configurations à deux RTX-5090. Son binaire `llama-server` utilise le format OpenAI sur `/v1/chat/completions`.

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

Le drapeau `-ngl 99` décharge toutes les couches sur le GPU. llama.cpp vous donne le plus de contrôle sur la quantification, le traitement par lots et le mappage de la mémoire. C'est le bon choix lorsque vous devez faire rentrer un modèle dans 16 Go de VRAM ou tester du matériel exotique.

LM Studio et Jan enveloppent llama.cpp dans une interface graphique et exposent également un point de terminaison OpenAI sur un port configurable. Ils sont utiles pour les utilisateurs non techniques de votre équipe qui ont besoin de tester des invites sans toucher un terminal.

Une simple vérification Python que le point de terminaison fonctionne :

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)

Si vous voyez `OK`, l'environnement d'exécution, le port et le contrat du SDK correspondent tous. Vous êtes prêt à câbler le point de terminaison à vos outils.

Testez votre LLM local avec Apidog

Une API LLM locale n'est utile que si votre suite de tests peut y accéder de la même manière qu'elle accède à la production. Apidog gère cela avec des variables d'environnement sur le modèle de requête, ce qui signifie qu'un seul projet couvre les deux cibles.

Le processus comporte cinq étapes.

Ouvrez votre projet Apidog et créez un nouvel environnement appelé `Local`. Ajoutez une variable `BASE_URL` avec la valeur `http://localhost:11434/v1`. Ajoutez `API_KEY` avec la valeur `ollama`. Enregistrez.
Clonez votre environnement OpenAI existant, renommez-le en `Production`, conservez `BASE_URL` comme `https://api.openai.com/v1` et `API_KEY` comme votre clé hébergée.
Dans toute requête qui appelle un point de terminaison de chat, remplacez l'hôte codé en dur par `{{BASE_URL}}` et l'en-tête d'authentification par `Bearer {{API_KEY}}`. L'URL de la requête devient `{{BASE_URL}}/chat/completions`.
Créez un test de scénario qui déclenche la requête, affirme que `choices[0].message.role == "assistant"`, affirme que `choices[0].message.content` n'est pas vide, et affirme que `usage.total_tokens > 0`. Enregistrez le scénario.
Exécutez le scénario contre `Local`. Passez le menu déroulant d'environnement à `Production`. Exécutez à nouveau. Les assertions devraient passer pour les deux.

Le même scénario sert également de test de fumée pour les mises à niveau de l'environnement d'exécution. Après un `ollama pull` sur une nouvelle étiquette, réexécutez le scénario `Local`. Si la forme de la réponse dérive, vous le détectez avant que le code de l'application ne touche les nouveaux poids. Ce modèle s'étend aux tests d'agents IA qui appellent des API multi-étapes.

Pour une utilisation programmatique, le SDK Python d'OpenAI change de cible avec un seul argument mot-clé :

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)

La forme JavaScript reflète ceci :

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: process.env.ENV === "local"
    ? "http://localhost:11434/v1"
    : "https://api.openai.com/v1",
  apiKey: process.env.ENV === "local" ? "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);

Connectez l'exécuteur de scénarios d'Apidog à votre CI en exportant le projet en tant que collection `apidog-cli` et en appelant `apidog run` dans GitHub Actions. L'exécuteur renvoie une sortie non nulle en cas d'échec d'assertion, ce qui fait échouer la construction dès qu'un contrat local ou hébergé dérive. Les ingénieurs QA peuvent intégrer le même flux dans les pipelines de test d'API existants.

Techniques avancées et astuces de pro

La quantification est le levier qui détermine si un modèle de 70B tient sur votre ordinateur portable. Le format GGUF stocke les poids à 8, 6, 5, 4, 3 ou 2 bits par paramètre. Q4_K_M est le choix par défaut pour une raison. Il perd 0,6 point de pourcentage sur le benchmark MMLU par rapport au FP16 et réduit un modèle 70B de 140 Go à 40 Go. Q8 vous maintient à moins de 0,1 point du FP16 mais double l'empreinte disque et RAM. Q2_K économise de l'espace mais l'impact sur la perplexité est visible dans toute tâche avec un long contexte. Choisissez Q4_K_M pour le chat, Q8 pour la génération de code, et Q5_K_M si vous avez la RAM et souhaitez une marge de sécurité.

Le déchargement GPU via le drapeau `-ngl` dans llama.cpp ou l'option `num_gpu` dans Ollama contrôle le nombre de couches de transformateur qui résident sur le GPU. Réglez-le aussi haut que votre VRAM le permet. Chaque couche qui retombe sur le CPU réduit le débit d'environ 30 pour cent. Sur une carte de 24 Go, un modèle 70B Q4 peut contenir 40 des 80 couches. Sur 48 Go, vous pouvez contenir toute la pile.

Le mappage mémoire ( `mmap`) est activé par défaut dans llama.cpp et Ollama. Il permet au système d'exploitation de paginer les poids à la demande au lieu d'allouer l'intégralité du modèle au démarrage. Laissez-le activé sauf si vous exécutez dans un conteneur avec des limites de mémoire strictes. Avec `mmap` désactivé, la latence du premier jeton diminue d'environ 200 ms mais l'utilisation de la RAM double.

Le traitement par lots est le superpouvoir de vLLM. Envoyez 32 requêtes concurrentes et vLLM les regroupe en une seule passe GPU. Le débit évolue de manière quasi-linéaire jusqu'au plafond de calcul du GPU. Définissez `--max-num-seqs 64` pour les ordinateurs portables avec mémoire CPU partagée et `--max-num-seqs 256` pour le matériel de classe H100.

Les réponses en streaming réduisent de moitié la latence perçue. Définissez `stream=True` dans le SDK OpenAI et le serveur envoie les jetons au fur et à mesure de leur génération. Le premier octet arrive en 200 à 500 ms au lieu d'attendre la complétion complète. Chaque runtime de ce guide le prend en charge.

Le Modelfile d'Ollama vous permet d'intégrer une invite système, une température et des séquences d'arrêt dans un modèle nommé afin que votre code d'application reste propre. Exécutez `ollama create my-assistant -f Modelfile` une fois et votre client pointera vers `my-assistant` au lieu de répéter l'invite système à chaque requête.

Erreurs courantes

Coder en dur `http://localhost:11434` dans le code de production. Utilisez une variable d'environnement.
Oublier que les modèles locaux n'appliquent pas `max_tokens`. Ils généreront volontiers 4 096 jetons de trop. Définissez une séquence d'arrêt.
Exécuter Ollama et un autre runtime sur le même port. Les deux utilisent des ports propres par défaut, mais les ports personnalisés entrent en collision silencieusement.
Omettre l'en-tête `Authorization`. Ollama l'ignore, mais vLLM avec `--api-key` rejettera les requêtes non authentifiées avec un 401.
Charger un modèle Q4 et s'attendre à une qualité GPT-5.5 en mathématiques. La quantification érode le raisonnement le plus rapidement.

Local vs hébergé : calcul du coût et de la latence

Les chiffres ci-dessous supposent un M3 Max avec 128 Go de mémoire unifiée pour le local, et les prix publics actuels pour les points de terminaison hébergés. Le temps jusqu'au premier jeton (TTFT) est mesuré à froid, sans traitement par lots, sur une invite de 1 024 jetons.

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

La colonne hébergée gagne toujours en latence. La colonne locale gagne en coût dès que vous dépassez environ 10 millions de jetons par jour, et elle gagne en confidentialité dès la première requête. Pour le développement, vous voulez presque toujours le local. Pour la production orientée utilisateur, vous voulez presque toujours l'hébergé, à moins que votre classification des données ne l'interdise.

Un modèle pratique : exécutez localement pendant la boucle de développement interne, passez à l'hébergé en staging, maintenez les deux cibles au vert en CI. Les tests de scénario Apidog de la section ci-dessus prennent en charge ce modèle avec une seule bascule d'environnement. Pour des benchmarks plus approfondis sur des modèles individuels, consultez Comment exécuter DeepSeek V4 localement et le guide d'utilisation original de DeepSeek V4.

Cas d'utilisation réels

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 invites contiennent des numéros de compte et des schémas de transaction qui ne peuvent pas quitter le pays en vertu des règles MAS. Le point de terminaison hébergé qu'ils utilisent en production reçoit une version expurgée de la même invite. Les scénarios Apidog affirment que le rédacteur est exécuté sur chaque requête avant qu'elle ne quitte le localhost.

Un studio de jeux à Stockholm forme des stagiaires en conception à l'ingénierie d'invite avec une instance locale de Qwen 3.6. Gratuit, hors ligne et impossible de divulguer l'histoire du prochain jeu à un tiers. Le même projet est livré contre Gemini 3 Flash en production avec un seul changement de variable d'environnement. Ils réutilisent le guide de l'API Gemini 3 Flash pour le câblage de production.

Une startup de soins de santé exécute vLLM sur un A100 loué au sein du réseau hospitalier du client. Le point de terminaison ne voit jamais de DNS public. Leurs tests d'intégration sont exécutés depuis un agent Jenkins dans le même VLAN contre le même SDK OpenAI qu'ils utilisent localement. Même code, trois cibles de déploiement, une suite de scénarios.

Conclusion

La pile d'API LLM locales a mûri rapidement. Vous pouvez déplacer vos invites d'un point de terminaison hébergé sans réécrire votre client, vos tests ou votre CI. Les cinq étapes qui rendent cela réel :

Choisissez Ollama pour les ordinateurs portables, vLLM pour les clusters de développement partagés, llama.cpp pour les budgets mémoire serrés.
Exposez le point de terminaison compatible OpenAI et vérifiez-le avec une ligne de commande curl.
Déplacez `base_url` et `api_key` dans des variables d'environnement afin que le même code accède aux environnements local et hébergé.
Créez des tests de scénario dans Apidog qui s'exécutent de manière identique sur les deux environnements.
Consultez le tableau coût-vs-latence et choisissez la bonne cible par charge de travail.

Le signal de HN qui a propulsé « L'IA locale doit être la norme » au-delà de 1 700 points découle de cette maturité. Une fois que la surface de l'API s'est stabilisée, chaque outil de développement s'y est adapté. Téléchargez Apidog et pointez un environnement vers `http://localhost:11434/v1` pour voir à quelle vitesse la boucle se referme. Si vous n'avez pas encore choisi de modèle, commencez par Meilleurs LLM locaux 2026, et si vous souhaitez une plongée plus profonde dans le test des flux d'agents sur l'un de ces points de terminaison, lisez Comment tester l'API des agents IA.

button