TabbyAPI face à Ollama et llama.cpp : 262K de contexte et trois agents sans OOM

Le résultat d'abord

Un Qwen 3.8 27B chargé avec 262 000 tokens de contexte, sans offload vers la mémoire système, sans mémoire unifiée, à 25-60 tokens par seconde — avec des pics relevés à 80. Deux puis trois agents lancés en parallèle sur la même carte, le contexte maintenu en mémoire vidéo, aucun Out Of Memory. C'est ce que nous avons obtenu avec Patrice Ferlet en passant d'Ollama puis llama.cpp à TabbyAPI.

Après deux ans et demi à chercher de l'optimisation en IA locale, c'est le saut le plus net que nous ayons mesuré sans changer de matériel.

Le parcours : Ollama, puis llama.cpp, puis TabbyAPI

Ollama reste le meilleur point de départ : une commande, un modèle, une API compatible OpenAI. C'est ce qui l'a imposé comme standard de fait, et ce que nous recommandons encore à quiconque démarre.

llama.cpp vient ensuite, quand on veut reprendre la main : quantifications fines, gestion de la mémoire unifiée, réglages serveur. Patrice Ferlet le pratique depuis des années et son constat est honnête : ça répond très bien, mais chaque session garde son propre contexte en mémoire. Avec deux sessions actives, on sature vite, et il faut penser à activer la purge des sessions côté serveur. La RAM, elle, reste plus lente que la VRAM. Le compromis retenu était de redescendre le contexte à 128K.

TabbyAPI — à ne pas confondre avec TabbyML, qui n'a rien à voir — change la donne sur ce point précis. Attention d'ailleurs : des sites se réclamant du projet circulent, la seule source légitime est le dépôt GitHub officiel.

Pourquoi c'est plus rapide : ExLlama et la quantification EXL3

TabbyAPI est un serveur d'API bâti sur ExLlama. Il n'utilise pas les fichiers GGUF du monde llama.cpp mais un format de quantification distinct, EXL3, et il est optimisé pour CUDA — donc pour les cartes NVIDIA, exclusivement.

Cette spécialisation est toute la différence. Là où llama.cpp doit rester portable (CPU, Apple Silicon, AMD, Vulkan), TabbyAPI peut exploiter les dernières techniques d'optimisation propres au matériel NVIDIA et à l'inférence pure. Résultat : une empreinte mémoire nettement plus faible à contexte égal, ce qui libère la place nécessaire pour un contexte long et plusieurs sessions simultanées.

Les modèles testés : Qwen3.8-27B en EXL3 (environ 11,5 Go de poids) et Qwen3-coder-30B-A3B. Les deux tiennent confortablement sur une carte de 24 Go — typiquement une RTX 3090, et plus largement toutes les séries x090.

Comparatif des trois moteurs

Aucun des trois n'est « meilleur » dans l'absolu : ils ne visent pas le même usage. Voici comment nous les départageons après tests.

Les limites, honnêtement

TabbyAPI impose CUDA. Pas de Mac, pas d'AMD, pas de repli CPU : si votre parc n'est pas NVIDIA, la question ne se pose même pas. La bibliothèque de modèles en EXL3 est également plus réduite que l'immense catalogue GGUF, et les nouveautés y arrivent avec un léger décalage.

llama.cpp reste donc parfaitement pertinent, et Ollama garde tout son sens pour démarrer ou pour un poste unique. Le bon réflexe n'est pas de migrer par principe : c'est de passer à TabbyAPI quand on bute précisément sur le contexte long ou sur le multi-agents, avec du matériel NVIDIA en face.

• Restez sur Ollama si vous débutez ou si un seul utilisateur travaille sur la machine
• Restez sur llama.cpp si votre matériel n'est pas NVIDIA, ou si vous dépendez de modèles disponibles uniquement en GGUF
• Passez à TabbyAPI si vous avez une carte 24 Go et besoin de contextes de 200K+ ou de plusieurs agents simultanés

Mise en place

Le déploiement se fait en conteneur — Docker ou Podman — ce qui isole proprement les dépendances CUDA. La configuration est courte : le modèle EXL3, la taille de contexte, le cache, et le serveur expose une API compatible OpenAI sur laquelle se branchent vos interfaces et vos outils de code habituels.

Patrice Ferlet prépare la publication de sa configuration, notamment les variantes pour OpenCode. Son retour détaillé est à lire sur LinkedIn ; c'est de ses tests que viennent les chiffres cités ici.

Ce que ça change sur une station IA Local

Ces niveaux d'optimisation sont précisément ce que nous configurons sur nos stations avant livraison. Le matériel seul ne suffit pas : entre une installation par défaut et une chaîne d'inférence réglée pour le contexte long et le multi-agents, l'écart se compte en facteur, pas en pourcentage.

Concrètement, sur une station équipée d'une carte 24 Go, cela signifie faire tourner un assistant conversationnel, un agent de code et un agent d'analyse documentaire en même temps, sur des dossiers complets, sans jamais toucher au cloud.