LLM locaux sur Mac Studio : pour une personne seule ou une petite équipe, mieux vaut un travailleur lent mais puissant qu'un chat rapide

Introduction#

Quand on parle de faire tourner un LLM en local, on commence généralement par l'installation. On explique quel runtime utiliser, quel modèle télécharger et quel port ouvrir.

Mais après quelque temps d'usage, une autre question, plus importante, apparaît. Il ne s'agit plus seulement de savoir comment utiliser utilement un grand LLM en local, mais de comprendre comment en faire un outil vraiment productif. Car le faire démarrer et continuer à s'en servir sont deux problèmes entièrement différents.

Au début, j'ai moi aussi démarré avec Ubuntu + vLLM + deux 3090 Ti. Aujourd'hui, j'ai migré vers Mac Studio M3 Ultra(512GB) avec LM Studio, et j'exécute en local de grands modèles des familles deepseek, qwen et glm.

Cet article n'est pas un guide d'installation. Je veux plutôt résumer simplement pourquoi j'ai atteint les limites de deux 3090, pourquoi je suis passé au Mac Studio, et comment j'utilise concrètement un LLM local lent dans des tâches réelles.

Au départ, j'ai commencé avec deux 3090 Ti#

La configuration initiale était assez simple. J'ai trouvé deux GPU 3090 Ti d'occasion pour environ 2,2 millions de wons, je les ai montés sur Ubuntu, et j'ai utilisé vLLM comme runtime.

À l'époque, gemma 3 faisait partie des modèles les plus convaincants en local. Pour traiter des consignes très simples, servir d'assistant ou monter de petits workflows, il était déjà impressionnant. Les performances multilingues n'étaient pas mauvaises, et la vitesse de génération de tokens était, pour l'époque, tout à fait satisfaisante.

J'ai effectivement construit et testé plusieurs assistants dans cet environnement.

• un agent conversationnel
• un lecteur de tarot
• un assistant orienté traduction
• un petit outil d'exécution de workflow

À ce stade, la conclusion était claire. Les LLM locaux n'étaient déjà plus de simples jouets. Mais il leur manquait encore beaucoup pour conclure qu'ils permettaient d'emblée de construire un agent réellement utile.

Le vrai problème n'était pas le logiciel, mais la réalité du matériel#

Au départ, si j'avais choisi vLLM, la raison était simple. La mise en place restait relativement simple, et vLLM était bien plus connu que sglang.

Mais avec le temps, j'ai compris autre chose : quand on fait tourner un multi-GPU de 3090 à la maison, le véritable goulot d'étranglement est bien plus concret que le choix du runtime.

• La facture d'électricité devenait lourde.
• La chaleur était excessive.
• Il était difficile de les faire tourner en continu à la maison.
• Surtout, les grands modèles que je voulais réellement exécuter restaient hors de portée.

À l'époque, ce que je voulais, c'était manipuler en local un modèle du niveau de deepseek v3, avec un contexte réellement confortable. Or, avec deux 3090, la limite était nette. Bien faire tourner de petits modèles, et faire d'un grand modèle un véritable outil de travail au quotidien, ce n'est pas du tout la même chose.

J'ai donc fini par revendre les GPU et acheter un Mac Studio M3 Ultra(512GB). Ce changement n'a pas été un simple remplacement de machine : il a modifié ma manière même d'envisager les LLM locaux.

Ce qui est devenu possible après le passage au Mac Studio#

Après le passage à macOS + LM Studio, le changement le plus marquant a été le suivant : des modèles qu'il était auparavant presque impossible d'envisager sont devenus des options réalistes.

Quand j'ai pu charger moi-même de grands modèles comme deepseek, glm ou Qwen3-235B-A22B et vérifier leurs résultats, j'ai été assez surpris par leurs performances. La qualité d'inférence était meilleure que prévu. Dès qu'on leur donne des consignes un peu complexes, ils produisent souvent des résultats bien plus précis et stables qu'avant.

En parallèle, leurs limites se sont révélées avec autant de netteté. Les performances en pp étaient plus lentes que je ne l'imaginais, et ce mode d'usage convenait clairement mal à tout ce qui demande des réponses immédiates, comme le chat en temps réel. J'avais déjà lu qu'il fallait s'attendre à cette lenteur, mais quand on l'utilise vraiment tous les jours, cette limite devient bien plus tangible.

À partir de là, j'ai changé de critère. Au lieu de me demander ce modèle est-il rapide ?, j'ai commencé par me demander où ce modèle doit-il être utilisé ?.

Les tâches lentes qui m'ont pourtant donné beaucoup de satisfaction#

Fait intéressant, dès que j'ai cessé de chercher une réponse en temps réel, les LLM locaux sont devenus bien plus utiles.

Les usages qui m'ont donné satisfaction se ressemblaient presque tous.

• les travaux qui demandent un résultat précis, comme l'analyse de données
• les travaux créatifs, comme l'écriture d'histoires de jeu, où le temps n'est pas critique
• les workflows d'analyse complexes, composés de nombreuses étapes
• les tâches de développement automatisé de type OpenHands, que l'on peut laisser tourner toute la nuit à la place d'une personne

Par exemple, produire une seule histoire peut prendre entre 40 et 60 minutes, voire davantage. Si l'on raisonne en termes de chat en temps réel, c'est une lenteur terrible. Mais si l'on change de méthode et qu'on met trois à cinq tâches dans la file avant d'aller dormir, puis qu'on récupère les résultats le matin, le tableau change complètement.

En échange de cette lenteur, les résultats sont bien plus riches et plus élaborés. La personne n'a pas à attendre toute la nuit : elle contrôle le résultat le lendemain, puis alimente la file suivante.

Il en allait de même pour les tâches OpenHands. Plutôt que de les utiliser comme un copilote réactif, il était beaucoup plus pertinent d'empiler les travaux dans une file et de les laisser s'exécuter automatiquement. Vue sous cet angle, un LLM local ressemble moins à un chatbot lent qu'à un travailleur silencieux qui tourne longtemps.

Même sans la vitesse du lièvre, on peut gagner comme la tortue#

En observant les LLM locaux, j'ai souvent repensé à la fable du lièvre et de la tortue.

Les LLM cloud ressemblent le plus souvent au lièvre. Ils sont rapides, répondent immédiatement et sont faciles à exploiter sur-le-champ. Les grands modèles locaux, eux, ressemblent davantage à la tortue. Ils sont lents, frustrants si on les juge à l'aune de l'immédiateté, et ils déçoivent vite dès qu'on les compare sans nuance.

Mais si l'on change le critère d'évaluation, le résultat change aussi.

Dans un duel de chat en temps réel, les LLM locaux perdent souvent. En revanche, si l'on organise le travail autour de la file, des tâches répétitives, de l'exécution par lots et du traitement nocturne, dans une structure où la constance l'emporte, l'histoire change. C'est dans ce cadre que j'ai obtenu le plus de satisfaction. En prime, la consommation électrique était bien plus stable que sur une configuration multi-GPU. Le fait de pouvoir faire tourner des modèles plus grands avec moins d'un septième de la consommation électrique de ma configuration GPU précédente a aussi beaucoup compté.

Au final, l'élément décisif n'était pas la vitesse du modèle, mais la manière dont je concevais le rythme de mon travail.

Mon code a lui aussi fini par basculer vers une logique de file#

Il ne s'agit pas seulement d'une impression : cela s'est reflété tel quel dans l'implémentation.

Si l'on regarde mon module ai-service, on voit assez clairement que j'y considère les LLM locaux moins comme un chat en temps réel que comme un worker en arrière-plan.

Pour commencer, la connexion au modèle elle-même reste plus simple qu'on ne pourrait le croire. Dans RunnableAiModel, vllm et lm studio sont traités comme des fournisseurs compatibles OpenAI, et il suffit de remplacer le baseUrl. Autrement dit, du point de vue de l'application de plus haut niveau, tant que le backend local respecte la forme d'un endpoint compatible OpenAI, il se substitue assez naturellement.

Il existe aussi un exemple d'usage distinct pour LM Studio. LMStudioVisionClient est réellement implémenté pour connecter un modèle de vision via l'endpoint /v1 de LM Studio. En d'autres termes, j'ai ouvert la voie pour chaîner aussi de l'analyse d'images avec un VLM local.

Mais la partie la plus importante concerne le mode d'exécution.

AiAgentExecutor n'exécute pas immédiatement les workflows : il les enregistre dans une file sous forme de jobs DTE. LoopJobService et LoopWorkflowExecutor sont conçus pour traiter en arrière-plan des travaux longs exécutés de manière répétitive, avec aussi un flux de checkpoints et de reprise. WritingToolExecutor, le workflow multi-agent et la pipeline de génération marketing suivent eux aussi globalement une logique plus asynchrone qu'instantanée.

Ce n'est pas un hasard. Au lieu de forcer un modèle lent à entrer dans une interface temps réel, il est bien plus réaliste d'envoyer en file les tâches qui peuvent tolérer la lenteur.

En bref, voici la manière dont j'en suis venu à comprendre les LLM locaux.

• Ils conviennent mieux à une file de travail qu'à un simple moteur de réponse chat.
• Ils sont plus adaptés aux tâches où la difficulté et la précision comptent davantage que la vitesse.
• Ils se marient bien avec un schéma où l'on laisse tourner la nuit puis l'on révise le matin.
• Dès lors que l'API compatible OpenAI est respectée, les intégrer dans une architecture de service existante n'est pas particulièrement difficile.

Alors, à qui convient vraiment un LLM local ?#

Si vous avez lu jusqu'ici, vous vous posez probablement la même question : est-ce qu'un LLM local est réellement exploitable, et vaut-il vraiment l'investissement ?

Pour ma part, mon critère est assez clair.

Les LLM locaux conviennent bien aux personnes suivantes.

• celles pour qui le traitement par lots compte plus que le chat en temps réel
• celles qui veulent laisser tourner toute la nuit des tâches complexes de génération et d'analyse
• celles qui veulent exploiter durablement de grands modèles avec des coûts d'exploitation contenus
• celles qui peuvent repenser leur flux de travail autour d'une logique de file

À l'inverse, si l'expérience de conversation immédiate est votre priorité absolue, cela vous paraîtra sans doute frustrant au départ. Dans ce cas, choisir un LLM local repose facilement sur une attente mal placée.

Conclusion#

Faire tourner un grand LLM en local passe plus vite qu'on ne l'imagine de la réussite de l'installation à l'échec de l'usage. Le simple fait que le modèle démarre ne le rend pas immédiatement utile.

Je suis parti de deux 3090 Ti + Ubuntu + vLLM, et j'ai aujourd'hui migré vers Mac Studio M3 Ultra(512GB) avec LM Studio. Après ce parcours, ma conclusion est simple.

Vu du point de vue d'une personne seule ou d'une petite équipe, le LLM local brille bien davantage lorsqu'il devient un travailleur lent mais puissant qu'il ne le fait comme substitut d'un chat rapide.

Si vous avez déjà un Mac, et plus encore un équipement du niveau d'un Mac Studio, je vous recommande d'essayer cette manière d'exploiter un LLM local au moins une fois. Il n'est pas nécessaire de commencer par quelque chose de grandiose. Au lieu du chat en temps réel, choisissez simplement une tâche difficile à placer en file pour cette nuit.

Beaucoup plus de possibilités qu'on ne le pense commencent précisément à cet endroit.