Exécuter la même boucle de chat d’OpenAI localement avec Ollama
Exécuter localement la même boucle de chat d’OpenAI avec Ollama : diriger le SDK Python d’OpenAI vers localhost et conserver son code. Aucune clé API, pas de facturation de token, aucune donnée ne quitte le système.
Sources: Part 5 — Run the Same Loop on Ollama (no API key, OpenAI dialect)
Les conversations avec des fournisseurs hébergés coûtent de l’argent, et chaque requête est envoyée dans le data center d’un tiers. En exécutant un modèle ouvert sur votre propre machine avec Ollama, vous éliminez ces deux problèmes. Le meilleur aspect est que le code existant basé sur OpenAI continue de fonctionner, car seul l’adresse change.
Même dialecte, machine différente
Ollama est un serveur de modèles local. Après l’avoir installé, vous téléchargez un modèle une seule fois, et les poids sont téléchargés de la même manière qu’une image Docker. Le serveur écoute ensuite les requêtes HTTP sur localhost:11434. Ce qui rend cela pratique, c’est que Ollama imite délibérément l’API Chat Completions d’OpenAI : la même route /v1/chat/completions, la même liste de messages étiquetés par rôle, la même structure de réponse avec choices[0].message.content, ainsi que les mêmes compteurs d’utilisation.
Déplacer un cycle de chat d’OpenAI ne constitue donc pas une réécriture. C’est un changement d’adresse. Les avantages sont évidents : pas de clé API, pas de facturation par token et aucune donnée ne quitte la machine. En retour, on bénéficie de la vitesse du propre matériel ainsi que de la qualité d’un modèle ouvert plutôt que d’un modèle de pointe. Pour apprendre le fonctionnement des agents, où des centaines d’itérations sont normales, c’est une très bonne affaire.
Installation et une seule interaction
Téléchargez Ollama depuis ollama.com. Il s’installe en une seule étape et lance le serveur en arrière-plan. Ensuite, téléchargez un petit modèle : llama3.2, d’environ 2 GB, constitue un choix raisonnable par défaut. Rien de nouveau n’est nécessaire du côté Python, car le paquet standard openai pointe simplement vers une autre adresse :
from openai import OpenAI
# Part 2's SDK, different address
client = OpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama", # required, unused
)
resp = client.chat.completions.create(
model="llama3.2",
messages=[
{
"role": "system",
"content": "You are a concise "
"assistant.",
},
{
"role": "user",
"content": "Where are you running "
"right now?",
},
],
temperature=0,
)
print(resp.choices[0].message.content)
Deux paramètres méritent une attention particulière. En pointant base_url vers localhost, tout le trafic est redirigé hors d’OpenAI. La chaîne api_key="ollama" semble inutile, mais ce n’est pas le cas : le SDK refuse de créer un client sans clé, tandis qu’Ollama ignore tout ce que vous envoyez, donc n’importe quel texte non vide fera l’affaire. Enfin, model doit correspondre à un nom que vous avez déjà téléchargé. Il n’y a pas de niveau de tarification à choisir, seulement ce qui se trouve sur votre disque, ce que ollama list affichera.
La boucle d’histoire reste identique
Un bon test pour vérifier que le « dialecte » est le même consiste à voir si la fonction ask() précédente fonctionne avec Ollama sans aucune modification. C’est le cas. Seul le code utilisé pour créer le client diffère.
Une courte conversation le prouve, en commençant par un message système puis en s’élargissant progressivement :
msgs = [{
"role": "system",
"content": "You are a concise assistant.",
}]
def ask(text: str) -> str:
msgs.append(
{"role": "user", "content": text}
)
resp = client.chat.completions.create(
model="llama3.2",
messages=msgs, # full history
temperature=0,
)
reply = resp.choices[0].message.content
msgs.append({
"role": "assistant",
"content": reply,
})
return reply
print(ask("Define a context window."))
print(ask("Now for a five-year-old."))
print(ask("Which answer was shorter?"))
La troisième question illustre toujours le mécanisme d’historique, et tout ce qui a été appris avec la version hébergée reste valable. Le serveur ne se souvient de rien entre les appels. La liste croissante de msgs est la raison pour laquelle les réponses ultérieures prennent plus de temps. Vous n’êtes pas facturé ici, mais vous payez en secondes ; observer un modèle local ralentir à mesure que l’historique s’accumule fait ressentir le coût contextuel de manière concrète, ce que une facture ne pourrait jamais faire.
Fixez vos attentes en conséquence. Un modèle doté d’environ 3 milliards de paramètres est nettement moins performant que GPT-4o ou Claude. Il peut divaguer en dehors du prompt système ou faire des erreurs lors de comparaisons, comme déterminer quel des deux éléments est le plus court. Ce n’est pas une faille dans le mécanisme, mais bien ce que coûtent 3 milliards de paramètres ; voir cette différence de visu enseigne plus que de simplement lire des benchmarks.
Exécution de l’exemple
Trois commandes suffisent. La première installe le modèle, la deuxième installe les dépendances Python, et la troisième exécute le script :
# one-time: install from ollama.com, then
ollama pull llama3.2
pip install -r requirements.txt
python examples/part05_ollama.py
Avant toute autre chose, le script vérifie que le serveur Ollama répond sur localhost:11434. S’il ne répond pas, le script s’arrête en fournissant des instructions pour l’installation et le téléchargement. Il s’agit de l’équivalent local du mécanisme de détection rapide d’une clé API manquante. Ensuite, il exécute une conversation d’un seul tour ainsi que une conversation de trois tours, et enregistre l’utilisation des tokens, car Ollama indique cette utilisation dans les mêmes champs. Il n’y a ni clé ni coût associé. De plus, il est exclu des environnements CI pour une raison différente de celle des exemples hébergés : les machines CI ne lancent pas de serveur de modèle.
Lorsqu’un problème survient
- Une erreur « modèle non trouvé » signifie que cette étiquette spécifique n’a pas encore été téléchargée ; exécutez donc
ollama pull llama3.2. - Une erreur de connexion indique que le serveur n’est pas en cours d’exécution. Lancez-le avec
ollama serve, bien que les installations sur ordinateur le lancent automatiquement. - Une pause de plusieurs secondes avant le premier token lors de la première utilisation est due au chargement du modèle en mémoire. Rien ne s’est bloqué.
Pourquoi un endpoint local est avantageux
Les expériences avec les agents se répètent sans fin. Les pipelines de récupération sont reconstruits, les boucles de raisonnement effectuent plusieurs appels au modèle pour une seule question, et les workflows graphiques sont exécutés à nouveau après chaque petite modification de débogage. Payer par token pour chacune de ces exécutions entraîne des coûts importants, tandis qu’un endpoint local gratuit vous permet d’expérimenter sans surveiller un compteur. Comme Ollama utilise le dialecte d’OpenAI, n’importe quel exemple peut fonctionner de la même manière en changeant uniquement l’URL de base et le nom du modèle. Le résultat est un environnement de test avec un nombre illimité de tokens.
Le sujet suivant évident est le RAG. Un modèle ne peut pas connaître vos documents, donc la vraie question est de savoir quels tokens méritent une place dans la fenêtre de contexte.
Lectures complémentaires
- La boucle de chat sans état : Appeler l’API OpenAI manuellement en Python — Créez un chat à plusieurs échanges avec le SDK Python d’OpenAI en gérant vous-même l’historique des messages, et découvrez pourquoi cette même boucle constitue la base de la mémoire et des agents de LangChain.
- L’IA locale après Ollama : Choisir les environnements de exécution en 2026 — Pourquoi Ollama est un excellent point d’entrée mais un plan de contrôle peu fiable à long terme — et quels outils tels que llama.cpp, LM Studio, vLLM et autres conviennent à chaque étape.