J’ai créé mon IA en local sur mon MAC (partie 2)

L’Odyssée technique : comment j’ai boosté mon IA locale de 25 à 127 tokens/seconde sur Mac (partie 2)

Note de l’auteur : Afin de rendre cet article technique accessible au plus grand nombre, j’ai intégré de nombreux encadrés de vulgarisation (les boîtes grises). Cela peut donner l’impression que l’article est très long, mais rassurez-vous : il se lit plus vite qu’il n’y paraît ! Ces explications sont là pour que personne ne soit laissé sur le bord de la route numérique.

IMPORTANT: Dans cet article, on parle d’un usage intensif de l’ia (analyse de code, gros volumes de données, requêtes fréquentes, etc.). pour de simples usages conversationnels ou des tâches légères, une infrastructure beaucoup plus modeste aurait largement suffi et une partie de la complexité décrite ici ne serait pas nécessaire.

Imaginez la scène : vous venez d’investir dans une machine de guerre, un Mac M3 Max (ok je sais ce n’est pas le plus récent), persuadé qu’il va pulvériser n’importe quelle tâche d’intelligence artificielle. Vous lancez votre première requête à votre IA locale, le cœur battant, et là… le curseur clignote. Une fois. Deux fois. Une réponse s’affiche, lettre par lettre, à la vitesse d’un modem 56k (oups, ça vous donne une idée de mon âge) en fin de vie. C’est le mur de la réalité que j’ai percuté en octobre 2025. Ce n’était pas un problème de matériel, mais une erreur d’architecture logicielle fondamentale.

Si vous avez lu la première partie de cette série sur la souveraineté numérique, vous savez pourquoi j’ai décidé de rapatrier mon intelligence artificielle à la maison. Aujourd’hui, nous soulevons le capot. Je vais vous expliquer comment je suis passé d’un système lent et instable sous Ollama à un outil de production fluide et efficace grâce à MLX, le framework méconnu d’Apple. Préparez-vous, nous allons parler technique, optimisation et choix déchirants, mais ne vous inquiétez pas, je vais tout décoder pour vous au fur et à mesure.

Dans cet article, le deuxième de notre trilogie, nous explorerons :

1. L’échec initial de ma stack technique « standard » et les leçons tirées.
2. Pourquoi la gestion de la mémoire unifiée est le nerf de la guerre.
3. La migration vers MLX qui a quintuplé la vitesse de génération.
4. Le choix stratégique du modèle Qwen 2.5 Coder 14B face aux géants.

Le mirage de la stack parfaite : quand la théorie s’effondre

En mars 2025, sur le papier, mon plan était impeccable. Pour MEMORA solutions, je voulais bâtir une infrastructure robuste. J’avais choisi des technologies éprouvées : Laravel 12 Octane pour le backend (ma zone de confort), React 19 pour l’interface, et surtout Ollama pour gérer l’inférence des modèles d’IA. Ollama était le standard de facto, l’outil que tout le monde recommandait pour sa simplicité.

Les premières semaines ont été un rêve, tant que je restais sur de petits modèles. Mais dès que j’ai voulu charger des modèles sérieux pour le codage, comme le Llama 3.1 70B, mon Mac s’est transformé en radiateur soufflant.

Le problème n’était pas seulement la lenteur. C’était l’instabilité. Mon IA locale, ANNY, dévorait les ressources avec un « workolisme » effrayant. Si je ne surveillais pas son appétit via mon moniteur d’activité, elle monopolisait le CPU et le GPU jusqu’à faire planter l’interface de macOS. J’avais une Ferrari, mais je roulais avec le frein à main serré.

Diagnostiquer l’invisible : création d’un moniteur sur mesure

Face à ces ralentissements inexpliqués, les outils standards de macOS ne suffisaient plus. J’avais besoin de voir exactement ce que mon IA consommait en temps réel, directement dans ma barre de menu, sans ouvrir des fenêtres complexes.

J’ai donc dû créer mon propre outil : un « moniteur d’activité » dédié à ANNY. Pour ce faire, j’ai utilisé Python avec la bibliothèque rumps (Ridiculously Uncomplicated macOS Python Statusbar apps), qui permet de créer très simplement des applications pour la barre de menu du Mac. Mais un simple script ne suffisait pas ; je voulais une vraie application Mac autonome.

C’est là que je me suis heurté à un mur technique : comment transformer mon script de surveillance en une vraie application .app installable ?

Voici comment j’ai résolu ce défi :

1. Le Script : J’ai codé la logique avec rumps pour l’interface et psutil pour lire les données du système (CPU, RAM).
2. L’Échec : Au début, le script fonctionnait mais affichait une icône générique « Python Launcher » dans le dock, ce qui n’est pas pro.
3. La Solution : J’ai utilisé py2app, un « bundler » (empaqueteur). Il a non seulement créé un exécutable natif, mais m’a permis de définir LSUIElement=True pour rendre l’app invisible dans le Dock (elle vit uniquement dans la barre de menu, discrète et efficace) et d’ajouter ma propre icône .icns.

Grâce à cet outil maison, j’ai pu identifier précisément quand et pourquoi ANNY saturait ma mémoire, me guidant vers la véritable solution : changer d’architecture.

Mise à jour : la troisième partie est disponible. Je raconte dans le virage MCP comment je suis passé au M4 Max 128 Go et comment j'ai bâti 8 serveurs MCP pour rendre mon IA locale vraiment utile.