Ollama (Plateforme d'exécution locale de modèles)

1. Vue d'ensemble du concept et problème systémique

Avant l'arrivée d'Ollama, le déploiement local d'un modèle de langage ouvert constituait un véritable défi d'ingénierie : les développeurs devaient cloner manuellement le dépôt llama.cpp, configurer les flags de compilation en fonction de l'architecture de leur GPU (CUDA, Metal ou ROCm), rechercher des fichiers de quantification éparpillés sur Hugging Face, convertir les poids, calculer la mémoire nécessaire pour chaque couche et ajuster manuellement les balises de contrôle des templates de chat (<|im_start|>, [INST]). Une simple erreur dans un caractère spécial transformait la génération en une suite de mots incohérente.

Ollama a radicalement changé cette dynamique en devenant le « Docker de l'intelligence artificielle ». La plateforme a encapsulé les poids, les paramètres de quantification, les instructions système et les templates de dialogue dans un artefact standardisé unique — le Modelfile. Les ingénieurs peuvent désormais gérer leurs modèles locaux via une interface CLI concise (run, pull, list, rm) et les connecter instantanément à n'importe quelle application externe.

2. Taxonomie architecturale et modèle mental

L'ossature architecturale d'Ollama repose sur un démon Go léger couplé à un noyau C++ haute performance :

┌─────────────────────────────────────────────────────────────┐
│                     OLLAMA SYSTEM ARCHITECTURE              │
├─────────────────────────────────────────────────────────────┤
│ 1. Host Daemon & API Server (Written in Go):                │
│    • Local REST API (localhost:11434)                       │
│    • OpenAI Compatibility Layer (/v1/chat/completions)      │
│    • Dynamic Model Swapping Controller (Keep-Alive Manager) │
├─────────────────────────────────────────────────────────────┤
│ 2. Unified Artifact Layer (Modelfile & OCI Registry):       │
│    FROM base_model ➔ PARAMETER temperature ➔ SYSTEM prompt  │
├─────────────────────────────────────────────────────────────┤
│ 3. Core Compute Engine (llama.cpp Under the Hood):          │
│    • Hardware Dispatcher: Apple Metal / NVIDIA CUDA / ROCm  │
│    • Automatic Layer Splitter: VRAM vs System RAM           │
├─────────────────────────────────────────────────────────────┤
│ 4. Storage Subsystem (~/.ollama/models/blobs)               │
└─────────────────────────────────────────────────────────────┘

1. Démon serveur (Go Daemon Layer) :
   • Processus en arrière-plan qui gère la file d'attente des requêtes et contrôle le chargement et le déchargement des modèles en mémoire (paramètre keep_alive, par défaut 5 minutes d'inactivité).
2. Templateur Modelfile :
   • Fichier de configuration déclaratif analogue au Dockerfile. Il permet de figer le modèle de base, de modifier les paramètres d'échantillonnage (temperature, top_p, num_ctx) et de définir des règles immuables de comportement agentique.
3. Backend de calcul (llama.cpp) :
   • Exploite les accélérateurs matériels spécifiques à la machine. Il détecte automatiquement la quantité de VRAM disponible et décharge les couches vers le GPU avec une efficacité maximale.
4. Stockage de contenu (Blobs Storage) :
   • Conserve les couches des modèles dans le répertoire ~/.ollama/models. Les couches communes entre différentes versions de modèles sont dédupliquées, économisant ainsi l'espace disque.

3. Pipeline technique et mécanique interne

Le cycle de vie de l'exécution d'une commande dans l'environnement Ollama se déroule comme suit :

1. Requête de lancement du modèle : L'ingénieur exécute : ollama run deepseek-r1:14b.
2. Récupération du manifeste et des poids : Si le modèle est absent localement, le client contacte le registre registry.ollama.ai, télécharge parallèlement les couches GGUF quantifiées et vérifie leurs sommes de contrôle.
3. Introspection matérielle et allocation mémoire : Le backend scanne le système :
   • Lit la quantité de VRAM disponible sur le GPU.
   • Calcule la taille du modèle en tenant compte de la fenêtre de contexte allouée (par exemple, num_ctx: 32768).
   • Répartit les calculs entre le GPU et le CPU sans intervention manuelle de l'utilisateur.
4. Initialisation de session et ouverture des sockets : Le modèle s'initialise en mémoire. Une session TUI interactive s'ouvre dans la console, tandis que le port en arrière-plan 11434 commence à accepter les requêtes HTTP.
5. Génération streaming et traitement des outils : À la réception d'un prompt, Ollama transmet les tokens à llama.cpp, supportant aussi bien le streaming texte simple que l'appel structuré d'outils (Tool Calling) au format JSON.

4. Scénarios d'ingénierie pratiques en production

01. Déploiement d'un copilote privé pour VS Code / Cline

L'ingénieur configure son environnement pour travailler sur un projet confidentiel :

• Commande dans le terminal : ollama run qwen2.5-coder:32b.
• Dans le plugin Cline, on spécifie le fournisseur « OpenAI Compatible », l'URL http://localhost:11434/v1 et le nom du modèle qwen2.5-coder:32b.
• Le développeur obtient un environnement agentique complet avec édition autonome du code, fonctionnant à 100 % hors ligne.

02. Création d'un Modelfile personnalisé pour l'entreprise

Création d'un modèle spécialisé respectant les règles strictes de l'équipe :

• L'ingénieur rédige le fichier Modelfile :

  FROM llama3.3:70b
  PARAMETER temperature 0.2
  PARAMETER num_ctx 32768
  SYSTEM """Ти старший системний архітектор. Пиши код виключно мовою Go. Використовуй тільки стандартну бібліотеку та Uber Zap логер. Будь-які коментарі пиши українською мовою."""
  

• Exécute la commande ollama create senior-go -f ./Modelfile.
• Obtient un nouveau modèle personnalisé senior-go, prêt à être utilisé par toute l'équipe.

03. Automatisation de la validation des prompts dans un CI/CD local

L'ingénieur teste la robustesse de l'extraction JSON depuis du texte non structuré :

• Dans le script de test, on appelle l'endpoint http://localhost:11434/api/generate avec le flag format: "json".
• La suite de tests s'exécute localement en quelques secondes, sans coût lié aux tokens cloud.

5. Pièges courants, erreurs typiques et sécurité

• Limitation de la fenêtre de contexte par défaut : Par défaut, de nombreux modèles Ollama utilisent une petite fenêtre de contexte (2048 tokens) pour économiser la mémoire. Pour travailler sur de gros volumes de code, il est impératif d'augmenter ce paramètre via le Modelfile ou l'API (num_ctx: 16384 ou 32768).
• Danger d'exposer le port 0.0.0.0 sans authentification : Par défaut, Ollama écoute sur 127.0.0.1. Si le développeur change la variable pour OLLAMA_HOST=0.0.0.0 afin d'accéder depuis un autre PC, le serveur local devient accessible à tout le réseau local sans aucun mot de passe.
• File d'attente séquentielle des requêtes (Concurrency Throttling) : Si plusieurs développeurs interrogent simultanément le même serveur Ollama, les requêtes seront traitées séquentiellement, sauf si le paramètre OLLAMA_NUM_PARALLEL est explicitement augmenté.
• Accumulation de gigaoctets de vieux modèles sur le disque : Chaque modèle 70B quantifié en 4 bits occupe environ 40 Go de SSD. Le téléchargement d'une dizaine de modèles différents épuise rapidement l'espace disque du laptop. Lancez régulièrement ollama rm.