Servir un endpoint compatible OpenAI

Exécutez un moteur une fois et parlez-lui dans une fenêtre de chat : vous avez un jouet. Servez-le sur HTTP dans la forme que tout le monde parle déjà, et vous avez une infrastructure : éditeurs, interfaces, agents et vos propres scripts peuvent tous piloter le même modèle local. Cette page monte un endpoint local, puis couvre le streaming, les SDK, la sécurité et le maintien à chaud.

Pourquoi la forme OpenAI a gagné

Le format de requête chat-completions — un nom de modèle, une liste de messages {role, content}, quelques réglages — est devenu le standard de facto parce que chaque auteur d'outil a d'abord écrit un client pour lui. Quoi que vous pensiez de l'entreprise, la forme est neutre : ce n'est que du JSON sur POST. Conséquence pratique : tout serveur local qui l'imite est instantanément compatible avec un tas énorme de logiciels existants. Votre choix de moteur et votre choix de client deviennent des décisions indépendantes (voir moteurs).

llama-server en une minute

llama-server -m model.gguf -c 8192 --port 8080
# interface sur http://127.0.0.1:8080 — API sur /v1/chat/completions

Une requête annotée :

curl http://127.0.0.1:8080/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"model","messages":[{"role":"user","content":"Pourquoi tourner en local ? En une phrase."}],"temperature":0.7,"max_tokens":60}'

model — llama-server sert ce que vous avez lancé ; le champ est souvent ignoré, mais envoyez un nom sensé.
messages — toute la conversation, prompt système en premier ; serveur sans état, c'est vous qui gardez l'historique.
max_tokens — plafonne la réponse ; vous protège des générations folles.

La réponse (élaguée) porte la réponse plus la comptabilité de jetons dont vous aurez besoin pour du débogage gratuit :

{
  "choices": [
    { "message": { "role": "assistant", "content": "Pas de comptes, pas de limites de débit, et vos données ne quittent jamais la machine." } }
  ],
  "usage": { "prompt_tokens": 14, "completion_tokens": 15 }
}

usage est comment vous apprenez ce que vos prompts coûtent réellement en contexte — vérifiez-le avant d'incriminer un modèle d'« oublier » (voir jetons).

Streaming

Ajoutez "stream": true et le serveur bascule en server-sent events : des morceaux data: délimités par des sauts de ligne, chacun portant un petit delta, terminés par une sentinelle.

data: {"choices":[{"delta":{"content":"Pas "}}]}
data: {"choices":[{"delta":{"content":"de comptes"}}]}
data: [DONE]

Côté client : accumulez delta.content jusqu'à la ligne [DONE]. Le streaming n'accélère pas la génération — il rend l'attente tolérable, ce qui pour une UX de chat revient au même (voir vitesse).

Ollama : un service, deux APIs

L'API native d'Ollama est légèrement plus riche — options par requête et contrôle du cycle de vie des modèles :

curl http://127.0.0.1:11434/api/chat -d '{"model":"qwen3:8b","messages":[{"role":"user","content":"salut"}],"stream":false,"keep_alive":-1}'

Il sert aussi la route compatible OpenAI sur /v1/chat/completions, donc les clients façon OpenAI marchent contre Ollama sans modification. Utilisez l'API native pour keep_alive ou des options moteur par requête ; utilisez /v1 pour tout le reste.

vLLM pour les serveurs GPU

vllm serve Qwen/Qwen3-8B --max-model-len 16384 --port 8000

vLLM rapatrie les poids safetensors, charge une fois, et sert la même forme OpenAI avec du traitement par lots continu dessous — le bon outil dès que des utilisateurs simultanés apparaissent (voir concurrence). Il veut de la VRAM NVIDIA et un vrai GPU ; ne vous embêtez pas pour un bureau mono-utilisateur.

Pointez les SDK officiels vers localhost

Les bibliothèques OpenAI officielles ne sont que des clients HTTP ; changez l'URL de base et le champ clé d'API devient décoratif :

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:8080/v1", api_key="local")
r = client.chat.completions.create(
    model="qwen3-8b",
    messages=[{"role": "user", "content": "Pourquoi tourner en local ?"}],
)
print(r.choices[0].message.content)

import OpenAI from "openai";

const client = new OpenAI({ baseURL: "http://127.0.0.1:11434/v1", apiKey: "ollama" });
const r = await client.chat.completions.create({
  model: "qwen3:8b",
  messages: [{ role: "user", content: "Pourquoi tourner en local ?" }],
});

N'importe quelle chaîne marche pour la clé sauf si le serveur en a une de configurée. Cet échange d'URL de base est tout le truc derrière chaque outil « compatible modèles locaux ».

Ce que cela débloque

Éditeurs et interfaces de chat — voir interfaces et intégrations.
Vos propres applis : un modèle local derrière votre propre backend, zéro coût par jeton.
Pipelines scriptées avec schéma garanti — voir sortie structurée.
Boucles d'agents qui appellent des outils et itèrent — voir agents.
Le coin des jeux de ce forum : les agents échecs et janggi jouent en frappant un endpoint local de chat-completions exactement comme le curl ci-dessus.

Fermez la porte à clé

Un serveur de modèle est un LLM gratuit pour quiconque peut atteindre le port. Les défauts sont sûrs — llama-server et Ollama se lient à 127.0.0.1 — gardez-les ainsi sur les laptops. Pour exposer sur un LAN : définissez une clé d'API (--api-key sur llama-server et vLLM, et de l'auth dans toute interface devant), et préférez un reverse proxy pour TLS. Ne vous liez jamais à 0.0.0.0 sans authentification : n'importe qui sur le réseau peut brûler votre GPU, remplir votre contexte et sonder votre installation.

Gardez-le chaud

Le chargement à froid — les poids du disque vers la VRAM — coûte de quelques secondes à des dizaines de secondes de TTFT. llama-server et vLLM chargent au démarrage et restent résidents, donc seule la première requête paie. Ollama décharge après keep_alive (~5 minutes par défaut) : envoyez "keep_alive": -1 pour tenir le modèle indéfiniment, ou 0 pour libérer la VRAM immédiatement après une rafale. Si votre installation semble « lente au début, bien après », c'est un chargement à froid, pas un modèle lent — et en charge, une tempête de chargements est un vrai mode de défaillance (voir concurrence).

Voir aussi : concurrence · interfaces et intégrations · moteurs · sortie structurée