IA
04 May 2026

Assistant IA en local : pourquoi le plus gros modèle est souvent la mauvaise réponse

Plutôt que de laisser un 32B monopoliser la mémoire pour répondre à des questions triviales, un routing local (un petit modèle toujours chargé qui classifie et répond, des spécialistes chargés à la demande) multiplie par quatre le débit sur un Mac Studio, avec deux angles morts à connaître avant de répliquer le pattern.

Assistant IA en local : pourquoi le plus gros modèle est souvent la mauvaise réponse

Summary

Assistant IA en local : pourquoi le plus gros modèle est souvent la mauvaise réponse

Le réflexe du plus gros modèle

Pour faire tourner un assistant IA en local, le réflexe est de charger le plus gros modèle qui rentre dans la machine. Cela peut être la mauvaise réponse, voyons ensemble pourquoi.

Sur Apple Silicon, mémoire unifiée oblige, un 32B Q4 occupe 22 Go en permanence. La RAM disponible fond, le modèle rampe à une douzaine de tokens par seconde, et l'utilisateur regarde son texte arriver mot après mot. Le tout pour répondre à « quelle est la capitale de la France ».

Demander à un 32B la capitale de la France, c'est mobiliser un architecte senior pour étiqueter des cartons. Le talent est réel, l'allocation est absurde.

Le model routing local, testé chez NDA

Une autre approche existe, et nous l'avons testée chez NDA : le model routing local.

Le principe tient en deux idées. Un petit modèle (7B) reste chargé en permanence et joue deux rôles : classifier la requête entrante (code, raisonnement, général) et répondre lui-même aux requêtes générales. Les spécialistes (un modèle dédié au code, un 32B pour le raisonnement) ne se chargent qu'à la demande. Ollama gère l'éviction. Le tout tient dans un script Python d'environ 200 lignes : la table de routing est de la donnée, l'intelligence est dans le classifieur.

Astuce apprise sur le terrain : annoncer le cold start à l'utilisateur, pas tenter de le supprimer. Un délai annoncé est tolérable, un blanc silencieux fait fermer l'onglet.

Les résultats sur Mac Studio M4

Résultats sur Mac Studio M4 64 Go : 40 à 50 tokens par seconde sur la majorité des requêtes (contre une douzaine quand le 32B est seul aux commandes), mémoire qui respire enfin pour Xcode et le navigateur, et le gros modèle qui mérite sa place quand il est sollicité.

Deux angles morts avant de répliquer le pattern

Le multi-turn est un piège. Chaque changement de modèle re-prefill tout l'historique (le KV cache n'est pas portable d'un modèle à l'autre). Sur conversation longue, le pattern peut se retourner contre vous.

Le backend MLX, natif Apple, gomme une partie de l'urgence : 15 à 30 % de throughput en plus que llama.cpp, 10 % de mémoire en moins.

Verdict : un point de départ, pas un point d'arrivée

Le pattern est solide pour un assistant local mono-utilisateur. Il reste un point de départ, pas un point d'arrivée, dès qu'on bascule en produit ou en multi-tenant.

Et nous n'avons même pas parlé des architectures Mixture of Experts (Mixtral et consorts), qui résolvent le même problème nativement et qui rendent peut-être ce pattern obsolète.

Chez NDA, nous accompagnons les équipes sur les architectures LLM. Si ces questions résonnent avec votre contexte, n'hésitez pas à nous contacter.