Je choisirais le LLM local selon votre mémoire unifiée, pas selon le modèle le plus connu. Sur Mac mini, Ollama et LM Studio rendent ça simple, mais 16, 24, 32 ou 64 Go ne racontent pas la même histoire. Je vous montre quoi lancer, pour quel usage.
Pourquoi le Mac mini tient la route ?
Le Mac mini tient la route pour faire tourner un LLM local, un grand modèle de langage installé sur votre machine, parce que les puces Apple Silicon utilisent une mémoire unifiée rapide. Cette mémoire est partagée entre le CPU, le GPU et le Neural Engine. Ce n’est pas une station IA magique, soyons clairs, mais c’est une machine compacte, silencieuse, stable, et très correcte pour tester, automatiser, coder et garder ses données en local.
Le vrai sujet, ce n’est pas seulement la puce. C’est surtout la quantité de mémoire unifiée. Un Mac mini 16 Go peut déjà faire tourner des modèles quantifiés, donc compressés pour consommer moins de mémoire, mais il faut garder de la place pour le système, le navigateur, l’IDE, n8n, Docker parfois, et vos outils de dev. Si vous remplissez tout avec le modèle, l’expérience devient lente et pénible.
| Mémoire Mac mini | Type de modèle réaliste | Usage recommandé | Limite à prévoir |
| 16 Go | Modèle gpt-oss-20b et petits modèles quantifiés | Tests simples, prompts courts, assistants légers, scripts locaux | Peu de marge si le navigateur, l’IDE et plusieurs outils tournent déjà |
| 24 Go | Qwen3.6 27B, Gemma 4 26B A4B, Qwen3-Coder 30B | Développement, automatisations, assistant interne raisonnable | Les gros contextes et les réponses longues peuvent ralentir |
| 32 Go | Qwen3.6 35B | Usage sérieux en local, code, analyse de documents, workflows dev | Il faut encore surveiller la mémoire disponible |
| 48/64 Go | Llama 3.3 70B | Tests avancés, meilleure qualité de réponse, gros assistants locaux | Le modèle reste lourd, le temps de réponse peut compter |
Ollama est très pratique si vous aimez lancer vos modèles en ligne de commande. Je l’utilise surtout pour des scripts, des automatisations, des workflows développeur, ou pour brancher un modèle local derrière une API simple. LM Studio est plus confortable si vous voulez tester vite, comparer plusieurs modèles, ajuster des prompts et éviter de mettre les mains dans le terminal.
J’ai souvent vu des équipes acheter trop gros côté modèle et pas assez réfléchir à l’usage réel. Pour un assistant interne, un modèle plus petit bien prompté bat souvent un très gros modèle lancé trop lentement. La bonne question, c’est rarement “quel est le plus gros modèle possible ?”. C’est plutôt “quel modèle répond assez bien, assez vite, avec assez de marge pour bosser normalement ?”.
Quel modèle choisir au quotidien ?
Pour mon usage quotidien, je partirais sur Qwen3.6 35B si le Mac mini a au moins 32 Go de mémoire unifiée. C’est le modèle le plus équilibré du lot, surtout si vous faites un peu de tout : rédaction, raisonnement, lecture de documents, analyse d’images, scripts, SQL, Python, automatisation. Bref, le modèle qu’on lance sans trop se poser de questions.
Sous Ollama, il faut compter environ 23 Go pour Qwen3.6 35B. Sa grosse force, c’est sa fenêtre de contexte de 256K. Le contexte, c’est la quantité de texte que le modèle peut garder “sous les yeux” pendant une demande. En pratique, ça change pas mal de choses : vous pouvez lui donner de longues specs, un gros document, des bouts de dépôt Git, des consignes détaillées ou un historique de conversation sans taper trop vite dans la limite.
Le support texte + image est aussi utile. Je m’en sers pour analyser des captures d’écran, des schémas simples, des interfaces ou des bouts de dashboard. Ça ne remplace pas un humain, et ça peut se tromper, mais pour dégrossir vite un sujet visuel, c’est confortable. Et comme le modèle est orienté codage agentique, c’est-à-dire capable de raisonner sur plusieurs fichiers ou étapes, il colle bien aux profils dev, data et automation. Sur des workflows Make, n8n, Python ou API, c’est typiquement le genre de modèle qui aide vraiment.
Si votre Mac mini est plus limité, je regarderais plutôt Qwen3.6 27B. Il pèse environ 18 Go et vise plutôt les machines avec 24 Go de mémoire unifiée ou plus. Sur 24 Go, ça passe, mais il faut rester raisonnable. Si vous avez Chrome avec 40 onglets, Docker, VS Code, Slack et Figma ouverts, vous allez le sentir.
Installer Ollama si ce n’est pas déjà fait.
brew install ollama
Lancer Qwen3.6 35B.
ollama run qwen3.6:35b
Lancer la variante plus légère si disponible dans votre registre Ollama.
ollama run qwen3.6:27b
Petite remarque honnête : la disponibilité exacte des variantes dépend du catalogue Ollama au moment où vous testez. Je vérifierais d’abord les modèles déjà présents en local.
ollama list
Pour chercher les modèles disponibles, le plus simple reste de consulter le catalogue Ollama ou l’interface que vous utilisez autour d’Ollama.
| Modèle | Mémoire recommandée | Taille approx. | Contexte | Usage | Compromis |
| Qwen3.6 35B | 32 Go et plus | 23 Go | 256K | Usage général, code, data, documents longs, images | Plus lourd, demande une machine confortable |
| Qwen3.6 27B | 24 Go et plus | 18 Go | 256K | Usage quotidien plus prudent, rédaction, code, analyse simple | Moins puissant, attention aux apps lourdes en parallèle |
Quel LLM pour voir et raisonner ?
Pour un usage multimodal compact, je prendrais Gemma 4 26B A4B. C’est le genre de modèle que je trouve intéressant sur Mac mini parce qu’il sait traiter du texte et des images, sans demander le même niveau de calcul qu’un gros modèle dense classique.
Son point fort, c’est son architecture MoE, pour Mixture of Experts. Dit simplement, le modèle contient plusieurs “experts” internes, mais ils ne travaillent pas tous à chaque réponse. Sur Gemma 4 26B A4B, on parle d’environ 25,2 milliards de paramètres au total, mais seulement autour de 3,8 milliards sont activés à chaque inférence. Ça veut dire quoi en pratique ? Que le coût de calcul par token reste plus raisonnable qu’un modèle dense équivalent. Par contre, la mémoire reste un vrai sujet, parce que les paramètres existent quand même.
Gemma 4 26B A4B supporte texte + image et une fenêtre de contexte de 256K. La fenêtre de contexte, c’est la quantité d’information que le modèle peut garder sous les yeux pendant une demande. Là, c’est confortable pour lire de longs documents, analyser des captures d’écran, comprendre une maquette produit, qualifier des contenus visuels, ou aider dans des workflows d’automatisation. J’ai déjà vu ce type d’usage chez un client qui devait trier des demandes support avec pièces jointes. Le gain ne venait pas juste de “voir” l’image, mais de la relier au texte du ticket.
Je viserais 24 Go de mémoire minimum. C’est un bon candidat pour un Mac mini 24 Go ou plus, mais je testerais toujours selon la quantification choisie et les apps ouvertes à côté. Safari, Docker, un IDE, Slack… Ça mange vite.
ollama run gemma4:26b
Petite note pratique : Ollama peut proposer plusieurs variants. Je commencerais par le variant recommandé ou quantifié pour votre machine, puis je mesurerais la latence réelle sur vos prompts. Pas sur un benchmark abstrait.
| Je le choisis si | Vous avez besoin d’image + texte, vous voulez un modèle efficace pour sa taille, et votre Mac mini a 24 Go ou plus. |
| Je l’évite si | Votre priorité absolue est le codage agentique profond, ou si vous êtes limité à 16 Go de mémoire. |
Quel modèle pour coder en local ?
Pour coder en local sur Mac mini, je choisirais Qwen3-Coder 30B. C’est le choix le plus logique si votre objectif, c’est de bosser sérieusement sur du code : comprendre un dépôt, générer des fonctions, aider sur un refactor, diagnostiquer un bug, ou raisonner sur une base de code sans tout envoyer dans le cloud.
Le modèle annonce 30B paramètres au total, avec environ 3,3B paramètres activés à chaque inférence. Chez Ollama, il est listé autour de 19 Go. Sa fenêtre de contexte monte à 256K tokens, avec une mémoire recommandée de 24 Go ou plus. Sur un Mac mini bien configuré, ça commence à devenir vraiment intéressant.
La fenêtre de contexte change beaucoup de choses en développement. Un assistant qui ne voit que trois fichiers est vite aveugle. Avec une grande fenêtre, je peux lui donner un README, une spec, plusieurs fichiers source, des logs d’erreur, des tests unitaires, et lui demander une réponse cohérente. C’est souvent là que les petits modèles décrochent.
Lancer Qwen3-Coder 30B
ollama run qwen3-coder:30b
Exemple de prompt à donner au modèle
Tu es mon assistant de code. Analyse ces fichiers, identifie le bug probable, propose une correction minimale, puis écris les tests associés. Ne réécris pas tout le projet.
Mon workflow reste simple. J’ouvre le projet, je copie les fichiers pertinents, je demande un diagnostic, puis je fais valider les changements par les tests. Je garde toujours la main sur les commits. Je ne laisse jamais un agent modifier un dépôt critique sans revue humaine, surtout chez un client. C’est tentant, mais c’est comme donner les clés de prod à un stagiaire très rapide.
On peut aussi appeler Ollama depuis un script local, ce qui devient pratique pour brancher le modèle à un outil interne, un script maison, n8n, ou une chaîne d’automatisation.
#!/bin/bash
# Exemple simple pour envoyer une question de code à Ollama en local
# Prérequis : Ollama lancé sur la machine et modèle qwen3-coder:30b disponible
curl http://localhost:11434/api/generate \
-d '{"model":"qwen3-coder:30b","prompt":"Explique ce que fait cette fonction et propose une version plus lisible.","stream":false}'
| Critère | Qwen3-Coder 30B | Qwen3.6 35B |
| Meilleur pour coder | Oui, clairement | Bon, mais moins spécialisé |
| Meilleur généraliste | Correct | Oui |
| Mémoire conseillée | 24 Go ou plus | Plutôt 32 Go ou plus |
| Contexte | 256K | Très large aussi selon version |
| Usage conseillé | Code, refactor, debug, tests | Rédaction, analyse, assistant polyvalent |
Quel choix avec peu ou beaucoup de mémoire ?
Avec la mémoire unifiée des Mac mini, je raisonne toujours comme ça : est-ce que je veux un modèle confortable au quotidien, ou est-ce que je veux pousser la machine pour voir jusqu’où elle tient ? Ce n’est pas le même choix.
Avec 16 Go, je partirais sur gpt-oss-20b. C’est un modèle open-weight d’OpenAI, donc les poids sont disponibles, et il est conçu pour tourner sur votre propre infrastructure. Dans Ollama, sa taille approximative est listée autour de 14 Go. Il propose une fenêtre de contexte de 128K, une recommandation mémoire de 16 Go, et une licence Apache 2.0, avec la politique d’usage gpt-oss.
Je le trouve intéressant si vous voulez tester du raisonnement local sans acheter tout de suite une machine très chargée en mémoire. Par contre, sur 16 Go, il faut rester raisonnable. Je fermerais les grosses apps, le navigateur avec 40 onglets, Docker si vous ne l’utilisez pas, et je n’attendrais pas le confort d’un gros serveur GPU. Ça marche, mais ce n’est pas magique.
ollama run gpt-oss:20b
Avec 48 ou 64 Go, je regarderais plutôt Llama 3.3 70B. En version quantifiée via Ollama, il pèse environ 43 Go, avec une fenêtre de contexte de 128K. Là, on parle clairement d’un modèle pour Mac mini haute mémoire. Je ne le recommanderais pas sur 16 ou 24 Go, sauf pour faire un test un peu masochiste.
ollama run llama3.3:70b
Le compromis est simple. Llama 3.3 70B peut être pertinent si vous voulez un modèle plus massif pour des tâches exigeantes, mais il faut tester la latence, la mémoire restante, et le confort réel. Sur un poste de travail, la meilleure réponse n’est pas toujours le plus gros modèle. C’est souvent celui qui répond assez bien, assez vite, et qui rentre proprement dans votre workflow.
| Modèle | Meilleur usage | Taille approximative | Contexte | Mémoire conseillée | Commande Ollama |
| Qwen3.6 35B | Usage général solide, analyse, rédaction, tâches mixtes | Environ 22 à 24 Go quantifié | 128K | 32 Go minimum, 48 Go confortable | ollama run qwen3.6:35b |
| Gemma 4 26B A4B | Bon compromis vitesse, qualité, usage quotidien | Environ 16 à 18 Go quantifié | 128K | 24 à 32 Go | ollama run gemma4:26b |
| gpt-oss-20b | Raisonnement local sur Mac modeste | Environ 14 Go | 128K | 16 Go | ollama run gpt-oss:20b |
| Qwen3-Coder 30B | Code, refactorisation, génération technique | Environ 18 à 20 Go quantifié | 128K | 32 Go confortable | ollama run qwen3-coder:30b |
| Llama 3.3 70B | Tâches exigeantes, modèle massif, meilleure profondeur | Environ 43 Go quantifié | 128K | 48 à 64 Go | ollama run llama3.3:70b |
Alors lequel je lancerais en premier ?
Je ne choisirais pas un LLM local sur Mac mini au prestige du nom. Je partirais de votre mémoire, de votre usage et de votre tolérance à la lenteur. Pour un bon équilibre, Qwen3.6 35B est solide si vous avez 32 Go. Pour le multimodal, Gemma 4 26B A4B est très intéressant. Pour coder, Qwen3-Coder 30B est le plus naturel. Avec 16 Go, gpt-oss-20b reste le choix raisonnable. Avec 48 ou 64 Go, Llama 3.3 70B devient jouable. Le bénéfice pour vous est simple : tester l’IA en local sans envoyer vos données partout, avec un modèle vraiment adapté à votre machine.
FAQ
- Quel est le meilleur LLM local pour un Mac mini en 2026 ?
Je choisirais Qwen3.6 35B comme meilleur choix général si votre Mac mini a au moins 32 Go de mémoire unifiée. Il combine une grande fenêtre de contexte, des usages texte et image, et de bonnes capacités en raisonnement et codage. - Peut-on faire tourner un LLM local avec 16 Go de mémoire ?
Oui, mais il faut viser un modèle raisonnable. gpt-oss-20b est le candidat le plus adapté dans cette sélection, avec environ 14 Go listés par Ollama et une recommandation à partir de 16 Go. Il faut quand même garder une machine propre et éviter les apps lourdes en parallèle. - Ollama ou LM Studio pour lancer un LLM sur Mac mini ?
J’utiliserais Ollama pour les commandes, les scripts, les automatisations et les intégrations via API locale. Je prendrais LM Studio pour tester plus confortablement des modèles avec une interface graphique. Les deux approches sont complémentaires. - Quel modèle local choisir pour coder ?
Qwen3-Coder 30B est le choix le plus logique pour le codage local. Il est conçu pour l’ingénierie logicielle agentique, avec une fenêtre de contexte 256K et une taille approximative de 19 Go chez Ollama. Je le viserais sur un Mac mini avec 24 Go ou plus. - Est-ce que Llama 3.3 70B vaut le coup sur Mac mini ?
Il vaut le coup seulement sur une configuration haute mémoire, typiquement 48 Go ou 64 Go. Sa version quantifiée pèse environ 43 Go via Ollama. Sur 16 ou 24 Go, je ne le recommanderais pas, l’expérience risque d’être trop contrainte.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Avec mon agence webAnalyste et l’organisme Formations Analytics, j’accompagne des équipes qui veulent rendre leurs données, leurs outils IA et leurs automatisations vraiment exploitables. 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 cadrer vos usages IA locaux, automatiser vos workflows ou former vos équipes, contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
- Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
- Data Analyst & Analytics engineering : tracking avancé (GTM server, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
- Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.






