Quel LLM local choisir sur Mac mini sans le cloud en 2026 ?

Je choisirais selon la mémoire du Mac mini, pas selon le modèle le plus à la mode. Qwen, Gemma, gpt-oss, Qwen-Coder ou Llama n’ont pas le même rôle. Le bon choix, c’est celui qui tourne vraiment chez vous.

Quelle mémoire faut-il prévoir ?

La mémoire unifiée du Mac mini est le vrai critère de choix pour un LLM local, avant même le nombre de paramètres. Sur Apple Silicon, le CPU et le GPU piochent dans la même mémoire. Donc un modèle quantifié qui prend 14 Go, 19 Go ou 43 Go ne laisse pas la même marge à macOS, à votre navigateur, à votre IDE, à Docker, à vos fichiers ouverts, et au contexte de la conversation.

J’ai déjà vu des setups où le modèle démarre, oui. Techniquement ça tourne. Mais dès qu’on ouvre VS Code, Chrome avec 20 onglets et deux PDF lourds, ça devient pénible. Le Mac swappe, les réponses ralentissent, et on finit par fermer des apps pour parler à son LLM. Pour moi, ce n’est pas un vrai setup de travail.

Les seuils utiles sont assez simples à retenir :

• 16 Go C’est le minimum pour GPT-OSS-20B, en restant raisonnable sur les apps ouvertes.
• 24 Go ou plus C’est le bon point de départ pour Gemma 4 26B A4B, Qwen3.6 27B et Qwen3-Coder 30B.
• 32 Go ou plus C’est plus propre pour Qwen3.6 35B, surtout si vous codez ou analysez des fichiers longs.
• 48 à 64 Go C’est ce que je viserais pour Llama 3.3 70B quantifié, sinon on est vite dans le compromis permanent.

La fenêtre de contexte compte aussi. 128K ou 256K, ça veut dire que le modèle peut garder beaucoup de texte en mémoire. C’est pratique pour relire un projet, analyser plusieurs documents, ou suivre une longue conversation. Mais ce contexte consomme de la mémoire en pratique. Les tailles Ollama sont de bons repères, pas une garantie absolue de confort.

Modèle	Taille Ollama indiquée	Contexte	Mémoire Mac mini conseillée	Usage principal
GPT-OSS-20B	Environ 14 Go	128K	16 Go minimum	Assistant général, synthèse, rédaction
Qwen3.6 27B	Environ 19 Go	256K	24 Go ou plus	Raisonnement, analyse, usage polyvalent
Qwen3.6 35B	Environ 22 Go	256K	32 Go ou plus	Raisonnement plus solide, documents longs
Gemma 4 26B A4B	Environ 14 à 16 Go	128K	24 Go ou plus	Usage quotidien rapide et équilibré
Qwen3-Coder 30B	Environ 19 Go	256K	24 Go ou plus	Code, refactorisation, lecture de projet
Llama 3.3 70B	Environ 43 Go	128K	48 à 64 Go	Qualité haute, tâches complexes, production sérieuse

Quel modèle généraliste installer ?

Pour un usage généraliste solide sur Mac mini, je mettrais Qwen3.6 35B en premier choix si la machine a assez de mémoire, et gpt-oss-20b si je veux un modèle plus léger. C’est le genre de choix que je fais quand je veux un assistant local qui tienne la route, sans cloud, sans dépendre d’une API externe.

Qwen3.6 35B est, pour moi, le meilleur choix global. Il tourne autour de 23 Go via Ollama, avec une fenêtre de contexte de 256K, donc une grosse capacité à garder beaucoup de texte en mémoire pendant une discussion. La fenêtre de contexte, c’est simplement la quantité d’informations que le modèle peut “voir” en même temps. Il gère aussi le texte plus image, ce qui le rend plus polyvalent.

Je le vois très bien pour du raisonnement, des agents locaux, de l’analyse de dossiers, de la synthèse documentaire, et de l’assistance au codage. Sur des projets clients, c’est souvent là que les gros modèles font la différence. Pas sur une question simple, mais quand on leur donne beaucoup de contexte, plusieurs fichiers, des règles métier un peu tordues.

La variante Qwen3.6 27B est souvent plus réaliste. Elle tourne autour de 18 Go via Ollama, et je la recommanderais plutôt si votre Mac mini n’a pas une marge énorme. En pratique, je viserais 24 Go de mémoire ou plus pour le 27B, et 32 Go ou plus pour le 35B. Si le modèle idéal fait swapper la machine, il n’est pas idéal. Le swap, c’est quand macOS utilise le disque comme mémoire, et là les performances peuvent vite devenir pénibles.

Commande Qwen3.6 35B ollama run qwen3.6:35b

Commande Qwen3.6 27B ollama run qwen3.6:27b

gpt-oss-20b est l’autre choix très intéressant. C’est un modèle open-weight d’OpenAI pensé pour fonctionner localement, listé autour de 14 Go par Ollama, avec environ 16 Go de mémoire recommandée et un contexte 128K. Il est sous licence Apache 2.0, avec des conditions d’usage associées à gpt-oss, sans que vous ayez besoin de devenir juriste pour commencer à l’utiliser correctement.

Je le positionne pour du raisonnement, du codage, des outils et des agents quand je veux rester dans une enveloppe plus accessible. Moins lourd, plus simple à faire tourner, souvent plus confortable sur une machine moyenne.

Commande gpt-oss-20b ollama run gpt-oss:20b

Modèle	Confort	Puissance	Mémoire	Meilleur cas d’usage
Qwen3.6 35B	Très bon si 32 Go ou plus	Très élevée	Environ 23 Go	Agents locaux, gros contexte, analyse, code
Qwen3.6 27B	Bon dès 24 Go ou plus	Élevée	Environ 18 Go	Usage généraliste sérieux sans trop pousser la machine
gpt-oss-20b	Très accessible	Solide	Environ 14 Go	Raisonnement, codage, outils, agents légers

Quel modèle choisir pour l’image ?

Pour les tâches texte plus image sur Mac mini, je choisirais Gemma 4 26B A4B dans cette sélection. C’est le choix le plus logique si vous voulez un assistant local capable de lire du texte, mais aussi de comprendre une image, une capture d’écran, un schéma ou une maquette.

Gemma 4 26B A4B est un modèle multimodal de Google. Multimodal, ça veut juste dire qu’il peut travailler avec plusieurs types d’entrées, ici du texte et de l’image. Il est aussi construit en Mixture-of-Experts, souvent abrégé MoE. L’idée est simple : le modèle contient environ 25,2 milliards de paramètres au total, mais seulement autour de 3,8 milliards sont actifs à l’inférence, donc quand il génère une réponse. Tous les paramètres ne bossent pas à chaque jeton. La charge effective est donc plus basse qu’un modèle dense équivalent, où tout le réseau est sollicité tout le temps.

Concrètement, c’est intéressant sur Mac mini parce qu’on cherche toujours le bon équilibre entre qualité, mémoire et réactivité. Gemma 4 26B A4B coche pas mal de cases sans partir dans un modèle énorme impossible à utiliser confortablement en local.

• Texte et image : Vous pouvez lui donner une capture d’écran à résumer, un schéma à expliquer, une maquette à commenter ou une image à partir de laquelle rédiger une réponse.
• Fenêtre de contexte 256K : Il peut garder beaucoup d’informations en mémoire dans une même conversation. C’est utile pour analyser un gros document avec des visuels ou garder le fil d’un projet.
• Raisonnement et code : Il peut aider à comprendre une interface, proposer une correction, expliquer une logique technique ou générer du code à partir d’un besoin visible dans une capture.
• Assistant local : Les données restent sur la machine. Pour certains clients, rien que ça change tout, surtout quand il y a des captures internes ou des documents pas encore publics.

Je recommande quand même 24 Go de mémoire ou plus sur Mac mini. En dessous, ça peut vite devenir pénible selon la quantification, la taille du contexte et les autres apps ouvertes.

Ollama propose plusieurs variantes de Gemma 4, dont le 26B, des versions plus petites et une version dense 31B. Si votre objectif est le multimodal équilibré, je commencerais par le 26B.

Commande Gemma 4 26B A4B

ollama run gemma4:26b

Le multimodal local est très pratique pour garder les données chez vous, mais je testerais toujours les sorties. Surtout sur des documents sensibles, ambigus ou avec des détails visuels importants. Ça aide beaucoup, oui. Ça ne remplace pas un outil métier de vision spécialisé.

Quel modèle prendre pour coder ?

Pour coder localement sur un Mac mini en 2026, je prendrais Qwen3-Coder 30B en priorité. C’est le choix le plus logique si votre sujet principal, c’est le développement logiciel, pas juste discuter avec un modèle généraliste.

Qwen3-Coder 30B est spécialisé pour le code et l’ingénierie logicielle. Il a 30 milliards de paramètres au total, mais environ 3,3 milliards seulement sont activés à chaque génération. C’est ce qu’on appelle un modèle MoE, pour Mixture of Experts, en gros le modèle choisit une partie de ses “experts” selon la tâche. Ça aide à garder de bonnes capacités sans exploser complètement les ressources. Il a aussi une fenêtre de contexte de 256K, donc il peut avaler beaucoup de fichiers, de logs, de documentation ou de code avant de répondre. Dans Ollama, il est indiqué autour de 19 Go, ce qui reste costaud, mais beaucoup plus réaliste qu’un gros 70B.

Concrètement, je l’utiliserais pour ces cas développeur :

• Lire un répertoire et comprendre l’architecture d’un projet.
• Faire de la refactorisation sans casser l’intention métier.
• Expliquer un bug à partir de plusieurs fichiers.
• Générer des tests unitaires ou d’intégration.
• Analyser une base de code sur une longue portée, surtout quand le projet est proprement structuré.
• Servir d’agent de codage local, avec un outil qui lui donne accès aux fichiers.

Chez un client, j’ai vu un truc assez net. Le gain n’était pas juste “le modèle génère du code”. Le vrai gain, c’était de passer moins de temps à lui réexpliquer le contexte. Quand le contexte est long et que le repo est bien rangé, ça change vraiment la qualité des réponses.

Commande Qwen3-Coder 30B

ollama run qwen3-coder:30b

Llama 3.3 70B, je le vois autrement. C’est un modèle généraliste haute-capacité, pas un choix léger. Une version quantifiée via Ollama tourne autour de 43 Go, avec un contexte 128K. Je le réserverais plutôt à un Mac mini avec 48 ou 64 Go de mémoire. Sur 16 ou 24 Go, ce n’est pas adapté si vous voulez travailler confortablement.

Commande Llama 3.3 70B

ollama run llama3.3:70b

Qwen3-Coder 30B	Développement logiciel et agents de code.
Llama 3.3 70B	Modèle généraliste haute-capacité sur grosse mémoire.

Comment les lancer en local ?

Le plus simple, franchement, c’est d’utiliser Ollama si vous êtes à l’aise avec le terminal, et LM Studio si vous préférez une interface graphique. J’utilise souvent les deux chez des clients, parce que ça évite de perdre du temps. Ollama est parfait pour automatiser. LM Studio est plus confortable pour tester vite.

Ollama sert à télécharger, lancer et gérer des modèles locaux sur macOS. Vous l’installez depuis la source officielle, vous ouvrez le terminal, puis vous lancez le modèle choisi. Si tout répond vite, parfait. Si le Mac mini commence à souffler, que les réponses sont lentes ou que la mémoire sature, je change de modèle. C’est aussi simple que ça.

Lister les modèles ollama list

Télécharger sans lancer ollama pull nom-du-modele

Lancer un modèle ollama run nom-du-modele

Supprimer un modèle ollama rm nom-du-modele

Le test de base, c’est de lancer un modèle avec ollama run, puis de taper un prompt simple du genre “Résume ce texte en 5 points”. Ça permet de sentir tout de suite si le modèle est utilisable sur votre machine. Pas besoin de benchmark compliqué au début. Si ça rame déjà sur une question simple, ça ne tiendra pas dans un vrai workflow.

Ollama expose aussi une API locale, généralement sur localhost:11434. C’est très pratique pour brancher un script Python, un outil low code, un agent local, ou une automatisation maison sans envoyer vos données dans le cloud.

Voici un appel API local très simple avec curl : curl http://localhost:11434/api/generate -d {‘model’:’gpt-oss:20b’,’prompt’:’Résume ce texte en 5 points’,’stream’:false}. Selon votre shell, il faudra parfois ajuster les guillemets, surtout entre macOS, zsh et certains terminaux. Rien de grave, mais ça arrive.

LM Studio joue un autre rôle. Vous cherchez un modèle, vous le téléchargez, vous discutez avec lui dans une interface propre, puis vous pouvez activer un serveur local compatible avec beaucoup d’outils qui attendent une API de type OpenAI. Une API, ici, c’est juste une porte d’entrée standard pour qu’un logiciel parle au modèle.

Ma recommandation est simple. Ollama pour automatiser. LM Studio pour explorer. Les deux peuvent très bien cohabiter dans un workflow local sur Mac mini, sans cloud, sans abonnement obligatoire, et sans transformer chaque test en séance de bricolage.

Alors je prends lequel pour mon Mac mini ?

Je partirais d’abord de votre mémoire, puis de votre usage. Pour du raisonnement local léger, gpt-oss-20b est le plus accessible. Pour un assistant solide et polyvalent, Qwen3.6 27B ou 35B tient bien la route selon la machine. Pour l’image, Gemma 4 26B A4B est le choix naturel. Pour coder sérieusement, Qwen3-Coder 30B est le plus ciblé. Llama 3.3 70B, lui, demande une grosse configuration. Le bénéfice est simple : vous gardez vos données en local, vous testez vite, et vous choisissez un LLM qui travaille vraiment avec votre Mac mini.

FAQ

• Quel est le meilleur LLM local pour un Mac mini avec 16 Go ?
  Je viserais gpt-oss-20b en priorité. Il est listé autour de 14 Go via Ollama, avec environ 16 Go de mémoire recommandée. Il faudra quand même rester raisonnable sur les apps ouvertes et tester la fluidité réelle.
• Est-ce qu’un Mac mini 24 Go suffit pour faire tourner un bon LLM local ?
  Oui, c’est déjà une base correcte. Vous pouvez viser Qwen3.6 27B, Gemma 4 26B A4B ou Qwen3-Coder 30B selon l’usage. Pour Qwen3.6 35B, je préfère 32 Go ou plus pour garder du confort.
• Ollama ou LM Studio, lequel choisir ?
  J’utilise Ollama quand je veux automatiser, lancer des modèles en terminal ou brancher une API locale. LM Studio est plus confortable pour explorer, télécharger et tester des modèles avec une interface graphique.
• Quel LLM local choisir pour coder sur Mac mini ?
  Qwen3-Coder 30B est le choix le plus ciblé pour le développement. Il est pensé pour les tâches de code, les agents, l’analyse de répertoires et les longues bases de code, avec environ 19 Go indiqués via Ollama.
• Pourquoi faire tourner un LLM en local plutôt que dans le cloud ?
  Le gros intérêt, c’est de garder les données sur votre machine, de réduire la dépendance à une API externe et de tester librement. Ce n’est pas toujours plus puissant qu’un modèle cloud, mais c’est souvent plus contrôlable.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de Formations Analytics. J’accompagne des équipes sur le tracking server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA en entreprise et le SEO/GEO. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez mettre en place des LLM locaux, des agents IA ou des automatisations propres dans votre business, contactez-moi, je peux vous aider.