Un modèle 72B sur MacBook M2 Pro : 1 à 2 tokens par seconde et un ordinateur portable en surchauffe

Une histoire classique : on lit deux articles, on tape ollama pull dans le terminal, et voilà « son propre agent IA qui connaît tout le code ». L'ingénieur QA Egor Laptev, de SENSE, a testé ce scénario sur un MacBook Pro M2 Pro avec 32 Go de mémoire et en a tiré une leçon que les tutoriels ne racontent pas.

Ce qui a mal tourné

Il a pris Qwen Coder 72B et l'a compressé en Q2_K, soit environ 26 Go. Sur le papier, le modèle tient dans 32 Go. En pratique, Ollama a avalé presque toute la mémoire, macOS est parti en swap intensif, le SSD s'est mis à ronronner, et le processeur comme le GPU tournaient à 100 %. La mémoire d'Apple Silicon étant unifiée, la charge pèse sur l'ensemble du système. Le navigateur rame, l'IDE se fige, et au bout de quelques minutes le thermal throttling s'enclenche.

Limiter la mémoire n'a rien réglé. Les conseils habituels autour de 4 Go ne fonctionnent pas : 26 Go n'y rentrent pas, et Ollama renvoie simplement une erreur. Il a fallu relever la limite à 28 Go. Le modèle a démarré, mais à 1–2 tokens par seconde. Une requête simple comme « écris un parseur JSON » demande une à deux minutes d'attente. La température est passée de plus de 95 °C à 85–90 °C : le portable redevient utilisable, mais pas confortable.

Il y a aussi un coût caché. Le swap permanent use le SSD, il vaut donc mieux ne pas mener ce genre d'expérience pendant des heures. L'auteur indique toutefois que son ordinateur est intact : le throttling était une réaction de protection, pas une panne.

Le PC de bureau aide, mais pas gratuitement

Sur un PC avec une RTX 4070 Ti Super (16 Go de VRAM), 32 Go de DDR5 et un i5-13600KF, le même modèle atteignait 5–8 tokens par seconde. La réponse à une requête simple prenait 10 à 20 secondes. Une partie des poids restait en RAM, et cela se sentait. Le principal défaut : pendant que l'agent travaille, la carte graphique est occupée à 80–90 %. Impossible de jouer ou de monter une vidéo avant d'avoir arrêté l'agent.

RAG : là où la facture grimpe

Un modèle sans contexte n'est pas encore un agent. Pour qu'il connaisse le code, la documentation et les tickets, il faut du RAG : base vectorielle, embeddings, recherche. L'auteur a estimé les volumes. Un projet personnel de 14 000 chunks occupe environ 200 Mo. Une documentation interne de 1,4 million de chunks représente environ 20 Go. Un domaine complet de 14 millions de chunks atteint 200 Go. L'index HNSW ajoute 30 à 50 % de surcoût. Et si l'on veut en plus affiner le modèle, les états de l'optimiseur multiplient la mémoire nécessaire par environ 3 à 4.

Bilan matériel : une station de travail avec RTX 4090 ou A5000, 64 Go de RAM et 4 To de SSD coûte environ 6 500 $. L'électricité ajoute 100 à 180 $ par an. Le plus coûteux reste de transformer un appareil personnel en serveur.

Que faire alors ?

La conclusion de l'auteur est plutôt sobre. En local, mieux vaut garder des modèles 7B–14B en Q4_K_M ou Q8 : selon lui, cela représente environ 90 % de la qualité pour un tiers des ressources. Ils conviennent aux tâches rapides et au code privé. Le raisonnement lourd, le RAG sur des centaines de gigaoctets et le fine-tuning sont à confier au cloud ou à un cluster GPU.

Il faut aussi nommer les limites. Il s'agit d'une expérience isolée sur un matériel précis, pas d'un benchmark. Q2_K a été choisi délibérément comme test de résistance, et l'auteur reconnaît lui-même que la qualité d'un tel modèle est faible. Les chiffres de stockage et de coût sont indicatifs.

La leçon pratique est simple : avant de charger un 72B sur un portable, calculez la mémoire nécessaire pour les poids, le contexte et l'index. Si un seul de ces postes manque, prenez un modèle plus petit ou le cloud. Et ne croyez pas les tutoriels qui promettent que « tout est simple ».