Je choisirais Qwen3.6 35B si je veux le meilleur équilibre local. Mais selon votre Mac mini, le bon choix change vite entre code, raisonnement, multimodal et mémoire disponible. Le vrai sujet, c’est d’éviter le modèle trop lourd qui tourne mal.
Quel modèle choisir selon votre Mac mini ?
Le bon modèle local, sur un Mac mini Apple Silicon, se choisit d’abord avec la mémoire unifiée. Pas avec le nom le plus sexy du moment. Ollama et LM Studio ont rendu les LLM locaux vraiment utilisables, même assez simples à lancer, mais la limite reste très concrète : taille du modèle, fenêtre de contexte, usage, et RAM disponible.
La fenêtre de contexte, c’est la quantité de texte que le modèle peut garder en tête d’un coup. 256K, c’est énorme, et c’est très pratique pour lire un gros dépôt de code ou un long document. Mais si le modèle ne tient pas correctement en mémoire, ça ne sert pas à grand-chose. J’ai souvent vu des équipes choisir trop gros, se battre avec des lenteurs ou des plantages, puis revenir à un modèle un peu plus petit mais stable. Et au quotidien, c’est souvent ce choix-là qui gagne.
| Modèle | Taille Ollama ou mémoire indiquée | Contexte | Usage principal | Mac mini recommandé |
| Qwen3.6 35B | Environ 23GB | 256K | Texte et images, codage agentique et raisonnement | 32GB+ |
| Qwen3.6 27B | Environ 18GB | 24GB+ | ||
| Gemma 4 26B | A4B | 256K | Image et texte | 24GB+ |
| gpt-oss-20b | Environ 14GB | 128K | Raisonnement et agents | 16GB+ |
| Qwen3-Coder 30B | Environ 19GB | 256K | Code | 24GB+ |
| Llama 3.3 70B | Environ 43GB | 128K | 48GB ou 64GB |
Avec 16GB, je viserais plutôt gpt-oss-20b. C’est déjà sérieux pour du raisonnement et des agents locaux. Avec 24GB, on commence à être plus à l’aise : Qwen3.6 27B, Gemma 4 26B, ou Qwen3-Coder 30B deviennent des options réalistes. Avec 32GB, Qwen3.6 35B devient beaucoup plus confortable. Et pour Llama 3.3 70B, je ne tournerais pas autour du sujet : il faut viser 48GB ou 64GB.
Mon conseil simple : choisissez le plus gros modèle qui reste fluide, pas le plus gros modèle qui démarre une fois sur deux.
Quel est le meilleur LLM local généraliste ?
Qwen3.6 35B est le meilleur choix global local dans cette sélection. Si je devais installer un seul LLM généraliste sur un Mac mini Apple Silicon en 2026, c’est celui que je regarderais en premier.
Son intérêt, c’est l’équilibre. Il reste lourd, oui, mais pas délirant pour une machine locale sérieuse. Via Ollama, on parle d’environ 23GB à télécharger ou à stocker selon la version disponible. Sa fenêtre de contexte de 256K change aussi pas mal de choses. Le contexte, c’est la quantité de texte que le modèle peut garder “en tête” pendant une conversation. Avec 256K, on peut lui donner de gros documents, plusieurs fichiers, voire une bonne partie d’un dépôt de code sans découper dans tous les sens.
Il est aussi intéressant parce qu’il ne se limite pas au texte. Le support texte et images le rend plus polyvalent pour analyser une capture, un schéma, une interface ou un document visuel. Ce n’est pas juste un chatbot local pour répondre à trois questions. On commence à être sur un assistant généraliste solide.
Pour le codage agentique, il est bien placé aussi. Par codage agentique, j’entends un modèle qui ne fait pas seulement “écrire une fonction”, mais qui peut raisonner sur plusieurs fichiers, comprendre une intention, proposer un plan, modifier du code, relire ses erreurs. J’ai vu chez des clients que la vraie limite des petits modèles, ce n’est pas toujours la syntaxe. C’est la compréhension globale du projet. Là, Qwen3.6 35B marque des points.
Pour le lancer avec Ollama, je ferais simple : # lancer Qwen3.6 35B puis ollama run qwen3.6:35b.
Maintenant, il faut rester concret. La variante Qwen3.6 27B est plus légère, autour de 18GB, et elle peut être beaucoup plus réaliste sur un Mac mini avec 24GB de mémoire unifiée. Le 35B est plus ambitieux. Le 27B est plus facile à faire tourner. C’est vraiment le compromis à garder en tête.
| Configuration ou besoin | Choix conseillé |
| Mac mini avec 24GB de mémoire | Regarder plutôt Qwen3.6 27B, plus léger et plus confortable |
| Mac mini avec 32GB ou plus | Qwen3.6 35B devient le choix logique |
| Besoin principal en code pur | Attendre Qwen3-Coder, que je traite plus loin |
Quel LLM local choisir pour le multimodal ?
Si je devais choisir un modèle local pour faire du multimodal sur un Mac mini Apple Silicon, je regarderais d’abord Gemma 4 26B A4B. C’est le modèle le plus intéressant de cette sélection quand on veut manipuler du texte et des images sans partir directement sur des modèles énormes, souvent plus compliqués à faire tourner proprement en local.
Son intérêt est assez simple. Gemma 4 26B A4B sait traiter du texte et des images, et il propose une fenêtre de contexte de 256K. La fenêtre de contexte, c’est la quantité d’informations que le modèle peut garder en tête pendant une requête. Plus elle est large, plus on peut lui donner de documents, de captures, de descriptions ou d’historique sans tout découper à la main.
Le point vraiment important, surtout sur Mac mini, c’est son architecture Mixture-of-Experts. En clair, le modèle contient plusieurs “experts”, mais il n’active pas tout à chaque requête. Gemma 4 26B A4B annonce environ 25,2B paramètres au total, pour environ 3,8B paramètres actifs. Ça ne veut pas dire que ça devient magique ou léger comme un petit modèle, mais ça change la lecture. On a un modèle assez gros sur le papier, avec une exécution qui n’utilise qu’une partie des paramètres à un instant donné.
C’est exactement le genre de compromis que je trouve intéressant sur Mac mini. On reste prudent, bien sûr. Je ne promets pas des performances que je n’ai pas sous les yeux, et selon la quantification, la RAM, la pression mémoire et votre usage, le ressenti peut changer. Mais si votre sujet, c’est “je veux analyser des images et discuter avec le modèle localement”, Gemma 4 26B A4B est celui à regarder en priorité.
Ollama propose plusieurs variantes autour de Gemma 4, dont 26B, 31B dense et edge. Ma recommandation reste Gemma 4 26B A4B ici, parce que c’est celui décrit comme le meilleur multimodal pour sa taille. Je viserais 24GB de mémoire ou plus.
# lancer Gemma 4 26B A4B ollama run gemma4:26b
| Modèle | Multimodal | Taille | Mémoire recommandée |
| Gemma 4 26B A4B | Oui, image et texte | Environ 25,2B paramètres totaux, environ 3,8B actifs | 24GB+ |
| Qwen3.6 35B | Non, plutôt orienté texte dans cette comparaison | 35B | 24GB+ selon quantification |
Quel LLM local prendre pour raisonner et coder ?
Je ne choisirais pas un seul modèle pour “raisonner et coder”, parce que ça mélange deux usages proches, mais pas identiques. Dans la vraie vie, je préfère séparer les rôles : gpt-oss-20b pour raisonner, planifier, créer des agents, et Qwen3-Coder 30B quand il faut vraiment travailler sur du logiciel.
Pour le raisonnement général, gpt-oss-20b est pour moi le meilleur modèle open-source de raisonnement dans cette sélection. Sa taille Ollama tourne autour de 14GB, avec une fenêtre de contexte de 128K. La fenêtre de contexte, c’est la quantité de texte que le modèle peut garder en tête d’un coup. 128K, c’est confortable pour analyser des specs, des documents, des logs, ou piloter un agent qui doit enchaîner plusieurs actions.
Il est orienté raisonnement et agents. Un agent, ici, c’est un LLM qui ne se contente pas de répondre, mais qui peut planifier, appeler des outils, lire des fichiers, décider quoi faire ensuite. Sa licence est Apache 2.0, ce qui est très permissif, mais attention quand même : il reste soumis à la politique d’usage gpt-oss. Sur un Mac mini Apple Silicon avec 16GB de RAM ou plus, il est viable.
# lancer gpt-oss-20b pour raisonnement et agents
ollama run gpt-oss:20b
Pour le code pur, je partirais plutôt sur Qwen3-Coder 30B. C’est le meilleur modèle local pour le codage dans cette sélection. Il a 30B paramètres totaux, mais seulement environ 3,3B activés à chaque génération. C’est une architecture plus efficace, pensée pour ne pas tout mobiliser en permanence.
Sa fenêtre de contexte monte à 256K, ce qui change vraiment la donne sur de gros dépôts. Quand un client me demande d’analyser une vieille base Node ou Python avec des dossiers partout, ce genre de contexte évite de découper le problème en miettes. Il est optimisé pour l’ingénierie logicielle agentique, donc pour lire, modifier, comprendre et naviguer dans du code avec une logique d’agent. Sa taille Ollama tourne autour de 19GB, et je recommande plutôt 24GB de mémoire ou plus.
# lancer Qwen3-Coder 30B pour le code
ollama run qwen3-coder:30b
| Besoin | Modèle à prendre |
| Mac mini 16GB et raisonnement agents | gpt-oss-20b |
| Code, refactoring, grands dépôts | Qwen3-Coder 30B |
| Usage plus généraliste | Qwen3.6 35B |
Quand faut-il viser un très gros LLM local ?
Je vise un très gros LLM local uniquement quand la machine suit vraiment. Llama 3.3 70B est un bon exemple. Sur le papier, c’est séduisant. En pratique, la version quantifiée via Ollama fait environ 43GB, avec une fenêtre de contexte de 128K tokens, donc on n’est plus dans le petit modèle qu’on lance tranquillement sur n’importe quel Mac mini.
Pour moi, Llama 3.3 70B devient intéressant sur un Mac mini avec 48GB ou 64GB de mémoire unifiée. Là, ça commence à avoir du sens, surtout sur des variantes hautes type M5 Pro, où la mémoire et la bande passante permettent de travailler sans transformer chaque réponse en attente interminable.
Sur 16GB ou 24GB, je ne le choisirais pas. Oui, on peut parfois forcer les choses, quantifier plus fort, fermer toutes les apps, prier un peu. Mais si le Mac commence à swapper, c’est-à-dire à utiliser le disque comme mémoire parce que la RAM est pleine, l’expérience devient vite mauvaise. Le modèle est gros, mais il répond lentement. Et franchement, je préfère un modèle légèrement plus petit qui répond vite plutôt qu’un 70B lancé pour la beauté du benchmark. Je l’ai vu chez des clients, le “plus gros modèle possible” finit souvent abandonné au bout de deux jours.
Avec Ollama, le lancement reste très simple. C’est son intérêt ici : on lance un modèle local avec une commande claire, sans passer sa journée à configurer l’environnement.
# lancer Llama 3.3 70B sur un Mac mini avec forte mémoire
ollama run llama3.3:70b
LM Studio reste aussi une option populaire pour faire tourner des LLM localement, surtout si vous préférez une interface graphique plutôt que des commandes. Je le vois souvent utilisé pour tester vite plusieurs modèles et comparer les réponses sans trop se prendre la tête.
Mon choix global reste assez simple. Qwen3.6 35B pour l’équilibre général. Gemma 4 26B si vous voulez gérer image et texte. Gpt-oss-20b pour du raisonnement sur 16GB et plus. Qwen3-Coder si votre priorité, c’est le code. Et Llama 3.3 70B seulement pour les grosses configurations, là où la mémoire permet vraiment de l’exploiter.
Alors, quel LLM local mérite vraiment votre Mac mini ?
Si je devais trancher vite, je partirais sur Qwen3.6 35B pour un usage local solide et polyvalent, avec la variante 27B si la mémoire est plus serrée. Gemma 4 26B A4B est le choix malin pour le multimodal. gpt-oss-20b reste très intéressant sur Mac mini 16GB+ pour le raisonnement et les agents. Qwen3-Coder 30B est plus logique pour le développement, surtout avec de grands dépôts. Llama 3.3 70B, lui, demande une vraie grosse configuration. Le bénéfice pour vous est simple : choisir un modèle adapté à votre machine, pas juste le plus impressionnant sur le papier.
FAQ
- Quel est le meilleur LLM local pour Mac mini en 2026 ?
Dans cette sélection, je placerais Qwen3.6 35B en premier pour un usage global. Il pèse environ 23GB via Ollama, propose une fenêtre de contexte 256K, gère texte et images, et vise le codage agentique comme le raisonnement sur de gros dépôts. - Peut-on faire tourner un LLM local sur un Mac mini 16GB ?
Oui, le modèle le plus réaliste ici est gpt-oss-20b. Sa taille Ollama est d’environ 14GB, sa fenêtre de contexte est de 128K, et il est présenté comme viable sur Mac mini 16GB+ pour le raisonnement et les agents. - Quel modèle choisir pour coder localement sur Mac mini ?
Je choisirais Qwen3-Coder 30B pour le code. Il est optimisé pour l’ingénierie logicielle agentique et la compréhension de grands dépôts, avec une fenêtre 256K, environ 19GB via Ollama, et une recommandation mémoire de 24GB+. - Quel LLM local utiliser pour analyser texte et images ?
Gemma 4 26B A4B est le meilleur choix multimodal pour sa taille dans cette liste. Il combine image et texte, une fenêtre 256K, et une architecture Mixture-of-Experts avec environ 25,2B paramètres totaux pour environ 3,8B actifs. - Llama 3.3 70B est-il adapté à tous les Mac mini ?
Non. La version quantifiée via Ollama fait environ 43GB et vise plutôt des Mac mini avec 48GB ou 64GB de mémoire. Sur 16GB ou 24GB, ce n’est pas le choix pratique. Il vaut mieux prendre un modèle plus léger et stable.
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. J’accompagne des équipes qui veulent utiliser l’IA concrètement, sans empiler des outils inutiles. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez cadrer vos usages IA, vos agents ou vos automatisations, 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.





