Je choisirais le LLM local selon votre RAM, pas selon le buzz. Sur Mac mini, Qwen3.6, Gemma 4, gpt-oss, Qwen3-Coder et Llama 3.3 ne jouent pas le même rôle. Le bon choix dépend surtout du codage, du raisonnement, de l’image et de la mémoire disponible.
Quel LLM local prendre en priorité ?
Qwen3.6 35B est le meilleur choix global si votre Mac mini a assez de mémoire. C’est celui que je prendrais en priorité, parce qu’il combine bien le raisonnement, le codage agentique, l’analyse de dépôts de code et le support texte plus image.
Qwen3.6 est aussi intéressant sur Apple Silicon parce qu’il existe en version MLX. MLX, c’est le framework optimisé par Apple pour faire tourner des modèles IA sur ses puces M1, M2, M3, M4 et suivantes. Dans la vraie vie, ça compte, parce qu’un bon modèle mal optimisé devient vite pénible à utiliser.
Il peut aussi se lancer via Ollama, ce qui reste la voie la plus simple pour tester un LLM local sans bricoler pendant deux heures. La version Qwen3.6 35B pèse environ 23GB via Ollama, avec une fenêtre de contexte de 256K. Le contexte, c’est la quantité de texte que le modèle peut garder en tête dans une conversation ou une analyse. Pour lire un gros dépôt, plusieurs fichiers ou une longue documentation, c’est un vrai avantage.
Il existe aussi une version 27B plus compacte, autour de 18GB. Elle est moins ambitieuse, mais souvent plus confortable sur une machine qui n’a pas énormément de marge mémoire.
Mon avis terrain est assez simple. Quand je teste des modèles locaux avec des équipes data ou dev, le piège c’est souvent de choisir le plus gros modèle disponible sans regarder la RAM. Sur le papier, ça fait sérieux. Au quotidien, ça rame, ça swap, ça coupe les workflows. Un modèle un peu plus petit mais stable rend souvent beaucoup plus service.
Je viserais 24GB+ de mémoire pour Qwen3.6 27B, et 32GB+ pour Qwen3.6 35B. Sur un Mac mini en 16GB, ce n’est pas le modèle que je choisirais en premier. Je partirais plutôt sur un modèle plus léger, quitte à perdre un peu en raisonnement.
Commande Ollama : ollama run qwen3.6:35b
| Usage | Mémoire conseillée | Contexte | Point fort |
|
Qwen3.6 35B pour dev, data, analyse de dépôt et assistant agentique |
32GB+ |
256K |
Meilleur équilibre global |
|
Qwen3.6 27B pour usage quotidien plus stable |
24GB+ |
256K |
Plus compact, plus confortable |
|
Mac mini 16GB |
16GB |
Variable selon modèle |
Je choisirais plus léger |
Quel modèle choisir pour l’image ?
Gemma 4 26B A4B est mon meilleur choix multimodal pour sa taille, surtout si votre objectif est de travailler avec du texte et des images sans exploser la consommation mémoire. Si Qwen3.6 reste mon choix généraliste sur Mac mini, Gemma 4 devient plus logique dès que l’image est au centre de l’usage.
Ce qui change tout ici, c’est son approche Mixture-of-Experts, souvent abrégée MoE. En simple, le modèle ne mobilise pas tout son cerveau à chaque mot généré. Gemma 4 26B A4B fait environ 25.2B paramètres au total, mais seulement environ 3.8B paramètres sont activés à l’inférence. L’inférence, c’est le moment où le modèle répond à votre prompt. Résultat, on garde une bonne capacité globale, mais avec moins de calcul effectif par token. Et sur un Mac mini, ce genre de détail compte beaucoup.
| Capacité | Image + texte |
| Contexte | 256K tokens |
| Mémoire conseillée | 24GB+ |
| Variantes Ollama | 26B, edge, 31B dense |
Dans la pratique, je le vois bien sur les usages où on doit faire lire une capture d’écran, comprendre une interface, résumer un visuel, ou croiser une image avec des consignes textuelles. Ce n’est pas juste “un modèle qui voit des images”. C’est surtout un modèle qui arrive à raisonner avec le texte autour de l’image, et c’est là que ça devient utile.
Commande Ollama
ollama run gemma4:26b
Les usages où je le trouve vraiment pertinent sont assez directs :
- Analyse de captures d’écran, par exemple pour comprendre une erreur, une interface ou un tableau de bord.
- Extraction d’informations visuelles depuis une image avec un prompt précis.
- Assistance multimodale quand vous mélangez texte, image et contexte métier.
- Préparation de contenu avec contexte image, comme transformer une capture en explication claire.
Mon avis simple : si vous faites surtout du texte, restez sur Qwen3.6. Si vos workflows commencent souvent par une image, Gemma 4 26B A4B est plus cohérent.
Quel LLM local pour raisonner ?
Pour du raisonnement local sur Mac mini, mon choix le plus logique, c’est gpt-oss-20b. Je le mets surtout dans la short list dès qu’on a une machine à partir de 16GB de mémoire, parce qu’on reste dans une contrainte réaliste, sans partir sur un modèle énorme qui va étouffer la machine.
Ce modèle est un LLM open-source d’OpenAI pensé pour le raisonnement, l’utilisation d’outils et les agents. Un agent, ici, c’est un modèle qui ne se contente pas de répondre, mais qui peut décider quoi faire, appeler un outil, lire un résultat, corriger son plan, puis continuer. C’est exactement le genre d’usage où un modèle local devient intéressant, surtout si vous voulez garder vos données sur votre machine.
| Modèle | gpt-oss-20b |
| Mémoire recommandée | Environ 16GB |
| Mémoire indiquée par Ollama | Environ 14GB |
| Fenêtre de contexte | 128K |
| Licence | Apache 2.0, sous politique gpt-oss |
La fenêtre de contexte de 128K, c’est la quantité de texte que le modèle peut garder en tête pendant une session. En pratique, ça aide pour analyser de longs documents, garder un historique de travail, ou manipuler plusieurs fichiers dans une logique d’agent.
Je ne le présenterais pas comme le plus gros modèle, ni comme le meilleur choix multimodal. Si votre sujet principal c’est l’image, il y a mieux. Mais pour de la logique, de la décision, du code, des workflows avec outils, ou des tâches où le modèle doit réfléchir avant d’agir, gpt-oss-20b devient franchement intéressant. J’ai vu ce genre de compromis mieux tenir dans la durée chez des clients que des modèles plus impressionnants sur le papier, mais trop lourds au quotidien.
Commande Ollama
ollama run gpt-oss:20b
Si je résume simplement, je prendrais Qwen3.6 pour le meilleur équilibre global, Gemma 4 pour l’image, et gpt-oss-20b pour raisonner localement avec moins de RAM.
Quel modèle local pour coder ?
Qwen3-Coder 30B est, pour moi, le meilleur choix local pour coder sur un Mac mini en 2026. Surtout si vous travaillez sur de vrais dépôts, avec plusieurs dossiers, des dépendances, des conventions internes, et pas juste trois fonctions à générer dans un fichier isolé.
Le point important, c’est le chiffre 30B. Le modèle fait bien 30 milliards de paramètres au total, mais il n’en active qu’environ 3.3B à chaque génération. C’est une architecture dite “Mixture of Experts”, ou mélange d’experts. En clair, le modèle a plusieurs blocs spécialisés, mais il n’utilise qu’une partie pertinente à chaque réponse. Sur Mac mini, ça change beaucoup la perception du modèle. On a une capacité assez large, sans avoir le comportement lourd d’un vrai dense 30B classique.
| Modèle | Qwen3-Coder 30B |
| Paramètres activés | Environ 3.3B |
| Contexte | 256K tokens |
| Taille Ollama | Autour de 19GB |
| Mémoire recommandée | 24GB+ |
| Usage principal | Codage agentique, analyse de grands dépôts, refactors |
La fenêtre de contexte de 256K est un vrai sujet ici. Un token, pour simplifier, c’est un morceau de texte que le modèle lit. Avec 256K, vous pouvez lui donner beaucoup plus qu’un extrait de code. Vous pouvez lui faire lire une architecture, plusieurs fichiers, des logs, des tests, une convention de nommage. C’est exactement là que les modèles spécialisés codage deviennent intéressants.
Pour du code, je préfère souvent un modèle spécialisé qui comprend les dépôts et les enchaînements de fichiers plutôt qu’un gros généraliste qui répond bien à tout mais manque de précision sur les refactors. J’ai vu ça chez un client récemment. Le modèle généraliste expliquait très bien le code, mais dès qu’il fallait déplacer une responsabilité entre deux modules, il ratait les effets de bord. Sur ce type de tâche, Qwen3-Coder est plus rassurant.
Commande Ollama à lancer :
ollama run qwen3-coder:30b
Les cas d’usage où je le trouve le plus pertinent sont assez concrets :
- Audit d’un dépôt existant pour repérer les zones fragiles.
- Génération de tests à partir du comportement réel du code.
- Explication d’un module complexe avec ses dépendances.
- Aide à la refonte d’une partie du projet sans perdre le contexte.
- Préparation d’un agent de développement local qui lit, propose, modifie et vérifie.
Avec un Mac mini équipé de 24GB de mémoire ou plus, c’est clairement le modèle local que je testerais en premier pour du développement sérieux.
Quand choisir Llama 3.3 70B ?
Llama 3.3 70B, je le choisis uniquement si le Mac mini a beaucoup de mémoire. Typiquement 48GB, 64GB, ou une configuration équivalente haute mémoire. Sur 16GB ou 24GB, ce n’est pas le bon réflexe. Ça peut tourner dans certains cas très optimisés, oui, mais ce n’est pas agréable au quotidien.
Dans cette sélection, je le vois comme le meilleur choix généraliste haute capacité. Il est solide sur l’écriture, l’analyse, le raisonnement, la reformulation, la synthèse, les tâches un peu longues. La version quantifiée fournie par Ollama tourne autour de 43GB, avec une fenêtre de contexte de 128K. Le contexte, c’est la quantité de texte que le modèle peut garder en mémoire pendant une conversation. 128K, c’est confortable pour charger de gros documents, des spécifications, des transcriptions ou plusieurs fichiers à la fois.
Le compromis est simple. Vous gagnez en capacité, mais vous mettez plus de pression sur la mémoire. Et sur Mac, la mémoire unifiée sert à tout. Le système, les apps ouvertes, le navigateur avec 38 onglets, Docker si vous l’utilisez, et le modèle local. J’ai déjà vu des setups très puissants devenir pénibles juste parce que la machine était utilisée comme un poste de travail complet en même temps.
Si votre objectif, c’est de lancer vite un LLM local tous les jours, poser des questions, résumer deux pages, coder un petit script, un modèle plus petit sera souvent plus confortable. Si votre objectif, c’est de maximiser la qualité générale sur une machine bien équipée, là Llama 3.3 70B devient cohérent.
Commande Ollama
ollama run llama3.3:70b
| Modèle | Meilleur usage | Mémoire conseillée | Contexte | Commande Ollama |
| Qwen3.6 35B |
Bon équilibre généraliste, analyse, rédaction, raisonnement. |
32GB à 48GB |
128K |
ollama run qwen3.6:35b |
| Gemma 4 26B A4B |
Usage quotidien fluide, assistant local rapide, bonne qualité sans trop charger la machine. |
24GB à 32GB |
128K |
ollama run gemma4:26b |
| gpt-oss-20b |
Modèle léger, pratique pour démarrer vite sur Mac mini avec moins de mémoire. |
16GB à 24GB |
128K |
ollama run gpt-oss:20b |
| Qwen3-Coder 30B |
Code, refactorisation, génération de scripts, aide développeur locale. |
32GB à 48GB |
256K |
ollama run qwen3-coder:30b |
| Llama 3.3 70B |
Meilleur choix généraliste haute capacité sur Mac mini bien équipé. |
48GB à 64GB |
128K |
ollama run llama3.3:70b |
Alors, lequel je lancerais sur mon Mac mini ?
Si je devais choisir vite, je partirais sur Qwen3.6 35B avec 32GB ou plus, ou sa version 27B si je veux rester plus confortable. Pour l’image, Gemma 4 26B A4B est le choix malin. Pour raisonner localement avec moins de RAM, gpt-oss-20b tient bien sa place. Pour coder, Qwen3-Coder 30B est le plus ciblé. Llama 3.3 70B, lui, mérite surtout un Mac mini très bien doté. Le vrai bénéfice pour vous, c’est d’éviter les mauvais tests et de choisir directement un LLM local adapté à votre machine.
FAQ
- Quel est le meilleur LLM local pour un Mac mini en 2026 ?
Pour un usage global, je choisirais Qwen3.6 35B si le Mac mini a au moins 32GB de mémoire. Il couvre bien le raisonnement, le codage agentique, le texte, l’image et l’analyse de dépôts. Avec moins de mémoire, la version 27B devient plus réaliste. - Est-ce qu’un Mac mini 16GB suffit pour lancer un LLM local ?
Oui, mais il faut viser un modèle adapté. Dans cette sélection, gpt-oss-20b est le plus cohérent à partir de 16GB, avec environ 14GB indiqués par Ollama et une recommandation autour de 16GB. - Quel LLM local choisir pour coder sur Mac mini ?
Je prendrais Qwen3-Coder 30B. Il est pensé pour l’ingénierie logicielle agentique, l’analyse de grands dépôts et les tâches de codage. Il demande plutôt 24GB ou plus, avec une taille listée autour de 19GB sur Ollama. - Quel modèle local utiliser pour du texte et de l’image ?
Gemma 4 26B A4B est le meilleur choix multimodal pour sa taille. Il supporte image plus texte, propose une fenêtre de contexte 256K et son architecture Mixture-of-Experts réduit les besoins effectifs de calcul par token. - Quand est-ce que Llama 3.3 70B devient intéressant ?
Llama 3.3 70B devient intéressant sur un Mac mini avec beaucoup de mémoire, typiquement 48GB ou 64GB. Sa version quantifiée autour de 43GB via Ollama le rend peu adapté aux machines 16GB ou 24GB.
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, IA appliquée en entreprise et SEO/GEO. J’accompagne des équipes qui veulent rendre leurs données, leurs outils et leurs workflows vraiment exploitables, pas juste plus à la mode. Avec webAnalyste et Formations Analytics, j’ai travaillé pour des acteurs comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez intégrer l’IA ou automatiser vos process sans partir dans tous les sens, 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.






