Module 10 — Limites de l'exécution locale
Neuf modules pour bâtir un assistant local fonctionnel. Il serait malhonnête d'arrêter le cours ici. Ce module dresse la liste, sans complaisance, des limites intrinsèques du déploiement local avec Ollama, et propose la carte des arbitrages qui permet de décider en connaissance de cause quand rester en local, quand passer à un serveur dédié, quand mordre sur du cloud.
La qualité, comparée aux grands modèles en API
C'est la limite qui compte le plus, et c'est aussi celle sur laquelle règne le plus grand brouillard commercial. Un llama3.1:8b-instruct-q4_K_M n'est pas de la même catégorie qu'un GPT-4o ou un Claude 3.7 Sonnet. Sur des tâches simples de reformulation, de résumé, de classification ou d'extraction structurée, la différence est faible et souvent invisible pour l'utilisateur final. Sur des tâches longues à raisonnement en plusieurs étapes — décomposer une question juridique complexe, arbitrer entre deux jurisprudences concurrentes, rédiger une conclusion en tenant compte de dix éléments simultanés — l'écart devient franchement visible.
Ce n'est pas une fatalité définitive : la frontière recule chaque trimestre, et les modèles ouverts autour de 30B (Qwen 2.5, Mixtral) rivalisent aujourd'hui avec les modèles cloud d'il y a dix-huit mois. Mais pour un cabinet qui déploie aujourd'hui, la lucidité est de séparer les usages : le local convient à ce qui est répétitif, structuré et sans enjeu de subtilité juridique fine ; le reste peut rester manuel, ou, si le cadre légal le permet, être ponctuellement délégué à un modèle cloud sous contrat encadré.
La concurrence de plusieurs utilisateurs
Ollama traite les requêtes en parallèle (paramètre OLLAMA_NUM_PARALLEL, défaut 4), mais chaque requête concurrente consomme sa part de mémoire et de puissance. Sur le serveur commun du cabinet (RTX 4060 8 Go, llama3.1:8b), une requête isolée sort à 65 jetons/seconde ; à quatre requêtes simultanées, chacune reçoit environ 20 jetons/seconde. Au-delà, la file d'attente s'allonge et la latence perçue explose. Autrement dit : Ollama n'est pas conçu pour servir cent utilisateurs simultanés — c'est un serveur d'inférence pour équipe, pas pour service public.
Le seuil au-delà duquel il faut passer à un serveur dédié (vLLM, text-generation-inference, TGI) se situe grossièrement à 20 utilisateurs actifs simultanés ou 100 requêtes par minute soutenues. Ces moteurs implémentent des optimisations dont Ollama ne dispose pas (batchage continu, paged attention) qui multiplient par cinq à dix le débit sur le même matériel. Le prix : ils demandent une configuration, une supervision et un déploiement bien plus lourds qu'un binaire d'Ollama.
Le contexte long, un plafond réel
Les grands modèles d'API annoncent aujourd'hui des fenêtres de 128 K à 1 M de jetons. Sur Ollama, monter num_ctx à 128 K est théoriquement possible mais rarement praticable : la mémoire nécessaire au cache d'attention grossit linéairement, et le temps de traitement de la consigne (prompt eval) devient rédhibitoire au-delà de 32 K sur du matériel bureautique. En pratique, un déploiement local s'organise autour de 4 K à 16 K de contexte, et compte sur la récupération de documents du module 9 pour ne présenter au modèle que ce qui compte à chaque requête, plutôt que d'essayer d'y faire entrer tout un dossier.
Les mises à jour, à ne pas oublier
Un modèle téléchargé aujourd'hui reste identique demain. C'est un avantage — reproductibilité totale, pas de dérive silencieuse — mais aussi une charge : les progrès de l'écosystème passent par une mise à jour délibérée. Nous imposons au cabinet une revue trimestrielle : ollama pull des nouvelles étiquettes intéressantes, rejeu du banc d'essai de vingt questions, comparaison honnête. Si le nouveau modèle est meilleur, on l'adopte ; sinon, on retire le fichier téléchargé pour libérer l'espace disque. La mise à jour du service Ollama lui-même suit un rythme similaire — les versions récentes améliorent souvent le débit et la compatibilité matérielle sans changer l'API.
La sécurité du poste
Un serveur qui tourne 24 heures sur 24 sur le réseau interne, écoute un port HTTP et charge des poids venant de la bibliothèque publique, est une surface d'attaque nouvelle pour le cabinet. Trois vecteurs à considérer sérieusement. L'accès non authentifié au port 11434 — traité au module 8 par le proxy inverse. Le téléchargement de modèles depuis la bibliothèque publique — se contenter des modèles connus (Llama, Mistral, Qwen, Gemma) et des variantes officielles ; méfiance envers les modèles téléchargés depuis des sources tierces, qui pourraient contenir des poids empoisonnés destinés à révéler certains secrets sur des consignes précises. Les mises à jour du service — appliquer les correctifs sécurité rapidement, comme pour n'importe quel autre logiciel serveur.
La carte des arbitrages
Une décision d'architecture, résumée en cinq critères. Local avec Ollama est le bon choix quand la confidentialité est non négociable, l'usage reste interne, la charge est inférieure à 20 utilisateurs simultanés, la qualité requise est celle d'un 8B à 30B, et le contexte tient dans 16 K jetons.
Un serveur dédié (vLLM, TGI) devient utile quand la charge dépasse ce seuil ou qu'il faut servir des équipes multiples à latence prévisible. Une API cloud (OpenAI, Anthropic, Mistral) devient nécessaire quand la qualité requise dépasse ce qu'un modèle ouvert propose à date — typiquement pour les tâches de raisonnement long non structuré. Rien n'oblige à choisir un seul de ces trois modes : le cabinet a construit une architecture hybride où le local traite 90 % des requêtes (résumé, classification, RAG interne) et où un modèle cloud n'est appelé que pour les 10 % restants, avec journal explicite et effacement des logs côté fournisseur activé quand disponible.
Le local est confortable, mais il n'est pas gratuit : matériel, électricité, maintenance, banc d'essai trimestriel, courbe d'apprentissage des collaborateurs. Sur un usage occasionnel — dix requêtes par semaine — une API cloud avec contrat de traitement des données à jour coûte souvent moins cher et pose moins de problèmes qu'un serveur local qui prend la poussière. La bonne question n'est pas « local ou cloud », c'est « quel est le mode le plus honnête pour ce cas précis ? ».
En résumé
- Sur les tâches longues à raisonnement fin, un modèle local reste en deçà des grands modèles cloud ; la frontière recule, mais l'arbitrage se fait aujourd'hui, pas en projection.
- Ollama sature au-delà d'environ 20 utilisateurs simultanés ; passer à vLLM/TGI pour un service à plus grande échelle.
- Le contexte long reste pratiquement plafonné autour de 16 K jetons ; la récupération de documents (module 9) est le meilleur substitut à une fenêtre géante.
- Sécurité : proxy inverse authentifié, modèles depuis sources connues, mise à jour trimestrielle du service et des étiquettes — l'exécution locale est une infrastructure à administrer, pas seulement un binaire à lancer.
Module suivant : le récapitulatif du cours et l'examen final de 40 questions.