Vous utilisez des LLM open source et des assistants de code en local ? Partagez votre environnement

• Un fil Ask HN qui demande aux utilisateurs de Hacker News comment ils utilisent des LLM open source et des assistants de code en local, et sur quel matériel portable
• Quels modèles ils utilisent (par ex. Ollama, LM Studio, etc.), et quels assistants de code open source / solutions d’intégration (par ex. des plugins VS Code)
• Quel matériel portable ils utilisent (CPU, GPU/NPU, mémoire, GPU dédié ou intégré, OS), et quelles performances ils obtiennent dans leur workflow
• Pour quelles tâches ils les utilisent (complétion de code, refactorisation, débogage, revue de code) ? Et quel niveau de fiabilité ils observent (ce qui fonctionne bien et ce qui manque encore)

---

• 1) MacBook Pro / Mac Studio (M2~M4 Max, 64~128GB) + LM Studio/Ollama + VS Code Continue

  • Avantages
    • Grâce à la mémoire unifiée des Mac, des modèles comme Qwen3-Coder-30B-A3B, gpt-oss-20b et même Gemma 27B tournent simplement en local, ce qui permet un workflow du type « lire le code → résumer → faire de petites modifications »
    • Il suffit de lancer LM Studio API ou Ollama serve pour que Continue.dev dans VS Code, Zed ou JetBrains s’y connecte directement, avec au final une UX proche de Claude Code
    • Grâce à la faible latence typique des Mac, autour de 50 à 80 tok/s, la complétion de code et la génération de commentaires restent assez fluides
    • Le fait que cela fonctionne aussi dans l’avion, le train ou hors ligne est un gros avantage, particulièrement pour garder le code de l’entreprise sans sortie vers l’extérieur
  • Inconvénients
    • À partir de modèles de plus de 20B, il y a des problèmes de chaleur et de bruit de ventilateur, et même avec un M4 Max 128GB, le 120B devient lent ou atteint ses limites
    • Les scénarios d’agent capables de « pousser jusqu’au bout comme Claude 4.5 Sonnet avec une boucle bash » restent encore insuffisants
    • Sur les MacBook avec 24GB ou 32GB, l’allocation VRAM est limitée, donc il faut souvent redescendre vers du 7B~12B, et dès qu’on augmente fortement le contexte, les performances chutent rapidement

• 2) Structure avec desktop/workstation équipé d’une RTX 3090·4090·Pro 6000, et portable utilisé comme client léger

  • Avantages
    • Cela permet d’essayer llama.cpp / vLLM / Ollama dans tous les cas de figure, et même de faire tourner gpt-oss-120B, « lentement mais réellement »
    • En lançant Continue ou llama-vscode dans VS Code sur le portable, tandis que l’inférence tourne sur une machine à la maison, on évite presque totalement la charge batterie et thermique sur le laptop
    • Avec une RTX 3090 24GB, des modèles comme gpt-oss-20B et Qwen2.5/3 Coder 14~30B offrent une vitesse de génération exploitable en pratique, suffisante pour l’autocomplétion et de petites refactorisations
    • Beaucoup utilisent un schéma avec Open WebUI + Ollama hébergé à domicile, accessible via VPN/Tailscale, ce qui permet de garder un environnement privé même à distance
  • Inconvénients
    • Si la VRAM du GPU est de 24GB ou moins, il faut quantifier fortement le 120B, et la qualité s’en ressent visiblement
    • vLLM est performant, mais son installation et son build sont pénibles, au point qu’on en arrive à recommander de « réessayer avec un runner mis à jour », ce qui implique un vrai coût de maintenance
    • Il n’y a pratiquement aucune portabilité, donc si l’objectif est de « tout faire vraiment sur un seul laptop », cette architecture n’est pas adaptée

• 3) Configuration centrée sur gpt-oss-120B (Aider, Codex, agents locaux)

  • Avantages
    • Plusieurs personnes disent que, parmi ce qu’elles ont testé en local, c’est ce qui se rapproche le plus de GPT-5, avec une précision élevée sur les tâches de codage
    • Des expériences réelles fonctionnent en l’attachant à des assistants de code open source comme Aider, Codex ou roocode, pour enchaîner revue → modification → tests → commit
    • Des astuces circulent pour le faire tourner de force même avec 8GB de VRAM grâce au chargement mixte CPU+GPU dans llama.cpp, ce qui rend les exigences matérielles plus flexibles qu’on pourrait le croire
  • Inconvénients
    • Le principal problème, c’est la vitesse. Là où ChatGPT termine 50 questions en 6 minutes, un 120B peut y passer plus d’une heure, donc c’est une option pour ceux qui acceptent d’attendre
    • Avec des outils comme Codex, il faut hardcoder les paramètres d’inférence pour éviter qu’il ne s’arrête, et écrire un AGENTS.md assez lourd pour obtenir un comportement proche d’un humain
    • Sur un laptop seul, la chaleur, la consommation et la mémoire rendent son usage prolongé difficile ; en pratique, il faut plutôt voir cela comme un portable relié à un GPU distant

• 4) Portables à très grande RAM comme AMD Strix Halo / Ryzen AI / Framework 128GB + llama.cpp/Continue.dev

  • Avantages
    • Avec 128GB de RAM, Qwen3 Coder 30B devient utilisable en conditions réelles, avec un fonctionnement hybride où certaines couches tournent sur GPU/NPU et le reste en RAM
    • D’après les retours, c’est un choix réaliste dans des situations comme « le code ne doit pas sortir de l’entreprise » ou « sur AMD, les drivers cloud ne sont pas encore terribles »
    • Une architecture où un serveur llama.cpp simple comme lemonade-server se lance automatiquement au démarrage et où l’éditeur s’y connecte via le réseau semble bien fonctionner
  • Inconvénients
    • Sous Linux, il y a encore des retours sur des problèmes de mise en veille / caméra / drivers, avec parfois la nécessité d’attendre le noyau 6.18
    • Les performances NPU ne sont pas au niveau de NVIDIA, donc impossible de viser des « agents de niveau frontier » ; on reste plutôt sur un rôle d’assistant en 20~30B
    • La documentation et les retours côté AMD doivent souvent être cherchés dans des dépôts GitHub ou des forums, avec une densité d’information plus faible que pour Mac ou NVIDIA

• 5) Configuration sur portable standard 16~32GB (MacBook Air, M2/M3 Pro avec peu de RAM) + modèles 7B~12B pour autocomplétion FIM uniquement

  • Avantages
    • Même avec qwen2.5-coder:7b, mistral 7b instruct ou gemma3:12b, on obtient immédiatement des réponses utiles pour « continue cette ligne », « c’était quoi déjà cette syntaxe SQL », etc.
    • Avec le plugin llama-vscode ou Continue.dev, l’autocomplétion continue de fonctionner même sans Internet, ce qui évite de casser le rythme de travail
    • La contrainte matérielle est faible, donc il y a peu de chauffe, peu de bruit de ventilation et la batterie se vide moins vite
  • Inconvénients
    • Dès que le contexte s’allonge un peu, le taux d’hallucinations augmente nettement, et les tâches comme la refactorisation ou la génération de tests, qui exigent de comprendre plusieurs fichiers à la fois, deviennent presque impossibles
    • Beaucoup insistent sur le fait que ce n’est pas un remplacement des modèles cloud, mais uniquement une solution d’autocomplétion
    • Comme il faut souvent réduire fortement les modèles en 4 bits, le choix de modèles reste limité

• 6) Configuration totalement hors ligne / priorité à la confidentialité (Ollama + Open WebUI + VPN)

  • Avantages
    • En laissant tourner chez soi un Mac Studio M4 Max 128GB ou un desktop avec simplement Ollama + Open WebUI, on peut ensuite s’y connecter de l’extérieur depuis un portable ou un téléphone via VPN tout en gardant un traitement entièrement local
    • Ceux qui utilisent cette architecture mettent en avant des points comme « je n’utilise presque plus ChatGPT » ou « comme la version ne change pas, mes prompts ajustés ne se cassent pas »
    • C’est aussi l’architecture la plus facile à expliquer quand l’entreprise exige qu’aucun code ne puisse être utilisé pour l’entraînement
  • Inconvénients
    • Il faut gérer soi-même les mises à jour et remplacements de modèles, donc contrairement au cloud, rien ne « devient plus intelligent tout seul »
    • Si le GPU est faible, les modèles au-delà de 20B deviennent immédiatement lents, ce qui pousse à faire évoluer le matériel — et à se demander pourquoi ne pas être resté sur le cloud

• 7) Ce qui ressort au final comme constat commun

  • Avec un laptop seul, il reste difficile de remplacer Claude Code / GPT-5 + agent ; en local, les modèles sont surtout bons pour la génération courte de code, l’aide, les résumés et l’autocomplétion
  • Les configurations qui reviennent le plus souvent sont donc soit « laptop ↔ grosse machine à la maison », soit « Mac 128GB pour faire tourner rapidement du 20~30B »
  • Malgré tout, tout le monde dit à peu près la même chose : si l’on a besoin de confidentialité garantie + quasi-absence de latence + versions stables, alors le local reste aujourd’hui la bonne réponse

[kaydash]

Plutôt que d’utiliser un VPN, il me semble préférable de configurer un bearer token et d’utiliser un tunnel SSH.

[savvykang]

Je pense que, pour le self-hosting de LLM, la mise de départ restera trop élevée au cours des 5 prochaines années pour que l’équation économique soit viable. Je compte reconsidérer la question dans 3 à 5 ans, lorsqu’un matériel suffisamment rapide pour la seule autocomplétion de code sera disponible et offrira un vrai avantage en termes de prix.

Configurations examinées

1. Configuration tout-en-un : impossible de faire tourner un LLM sur la machine de travail. La RAM manque déjà rien que pour faire tourner les outils de développement et les applications basées sur le navigateur.
2. Machine dédiée au LLM : impossible à faire tourner au bureau faute de carte graphique. Même pour un PC personnel, il n’est pas facile d’anticiper un tel investissement matériel.

[GN⁺]

Avis Hacker News

• J’ai voulu mettre directement les mains dans l’IA, donc j’ai acheté d’occasion un Dell Precision 3620 Tower i7-7700
  J’ai augmenté la RAM et remplacé l’alimentation pour y installer un GPU RTX 3060
  J’y ai installé Ubuntu Server, l’ai configuré comme nœud du cluster k3s de la maison, et j’y fais tourner Ollama et OpenWebUI
  Je m’en sers surtout pour le tagging IA et les résumés de Karakeep, mais aussi pour analyser la caméra de l’allée afin de détecter les véhicules de livraison avec du code Python

• J’exécute Ollama en mode CPU sur un Dell Precision T710 (Xeon E6320, 120GB RAM, RAID5 SSD 240TB), sans GPU
  Je travaille sur un projet qui indexe les lois électorales des 50 États avec du RAG afin de visualiser les incohérences terminologiques et les problèmes d’hallucination
  L’objectif est d’identifier les écarts d’intégrité dans les procédures électorales
  Le mindmap associé est visible ici : Election Frauds v1.4 Mindmap PDF

  • C’est vraiment admirable de mettre ses compétences au service de ce type de projet sociétal

• Je code avec des LLM en local, mais pas question de faire ça sur un portable
  J’utilise un serveur GPU avec llama.cpp + llama-swap pour changer de modèle selon les besoins
  La configuration qui me satisfait le plus est le combo Aider + gpt-oss-120b
  Ce serait sans doute faisable avec un Ryzen AI Max+ et 128GB de RAM, mais le matériel non NVIDIA est très lent
  On peut aussi passer par OpenRouter en ne choisissant que des fournisseurs sans conservation des données
  Mais GPT5 ou Claude sont bien plus rapides et moins chers qu’un setup local

  • J’ai créé un agent RAG avec gpt-oss-120b pour ingérer la documentation GCP
    ChatGPT a fait 46/50 en 6 minutes, gpt-oss-120b 47/50 en 1 heure
    Le tout tournait sur une machine i7 + 64GB de RAM + GPU 8GB de VRAM
  • Lien GitHub de llama-swap

• Si vous voulez faire tourner un agent de code local sur Mac, voici comment procéder

  1. npm install -g @openai/codex
  2. brew install ollama; ollama serve
  3. ollama pull gpt-oss:20b
  4. codex --oss -m gpt-oss:20b
     Ça fonctionne sans Internet, et il faut un Mac M1 ou plus récent + 24GB de mémoire GPU
     Le modèle 120b offre 1,5x les performances du 20b, mais demande 5x plus de ressources
  • LM Studio est plus simple, et s’intègre aussi avec JetBrains IDE ou Zed
  • Je me demande si le modèle 20b permet réellement de produire du code utile

• Je fais tourner Qwen3-Coder-30B-A3B Q4 quant avec llama.cpp sur un MacBook Pro 64GB
  Dans VSCode, j’utilise continue.dev avec un prompt système très court
  J’obtiens 50 tokens par seconde en génération et 550 tokens en traitement
  Sur des tâches courtes et bien définies, la qualité est proche de celle des modèles frontier
  C’est rapide et stable même hors ligne, donc j’en suis très satisfait
  Pour les tâches plus complexes, j’utilise les API Claude ou Deepseek

  • Quelqu’un a demandé si le modèle Instinct de continue.dev avait été testé, et comment il se compare à Qwen : Instinct
  • Il y avait aussi une demande de recommandation sur un meilleur quant pour une machine 128GB, avec partage d’un lien de téléchargement Hugging Face
  • Un autre commentaire demandait comment faire tourner Qwen3 dans llama-vscode (lien vers l’issue)

• Si vous achetez un Mac, je recommande au minimum un modèle Pro
  Le Air n’a pas de ventilateur, donc la gestion thermique est insuffisante, et je trouve le Studio meilleur que le Mac mini
  L’app TG Pro permet de régler les ventilateurs de façon plus agressive (environ 20 $)
  Je fais tourner le modèle GPT OSS 20B sur un MacBook Pro M4 Pro + 24GB de RAM, mais la fenêtre de contexte est petite
  Avec un modèle 128GB, on pourrait probablement coder hors ligne toute la journée

  • Le Mac mini a aussi un ventilateur, et le Studio n’est en fait qu’une version avec une puce plus puissante
  • Si vous achetez un Mac, la configuration idéale serait une puce Max ou Ultra + mémoire maximale
  • Le MacBook Pro 128GB a des performances de cache de contexte impressionnantes
  • La fenêtre de contexte par défaut est petite, mais sur gpt-oss-20b on peut l’étendre par 4
  • Certains ont aussi signalé que le traitement des longs prompts reste lent même sur M3/M4 + 128GB

• J’utilise un Apple M4 Max 128GB relié en USB-C à un GPD Win 4 (Ubuntu 24.04)
  Je combine Claude Code, RA.Aid et llama.cpp pour répartir le travail avec Agent Organizer
  Claude automatise de la conception d’architecture jusqu’à la revue de code

  • Quelqu’un a demandé quel rôle jouait le GPD Win 4, et si de petits modèles servaient à répartir la charge
  • Un autre commentaire demandait aussi le débit de tokens de chaque modèle
  • Il y avait également une question sur ce qu’est exactement l’Agent Organizer utilisé

• Si vous voulez voir des workstations LLM, je recommande la chaîne YouTube d’Alex Ziskind (@AZisk)
  Elle couvre différents tests de workstations pour LLM locaux
  Les présentations sont propres et les conseils pratiques

  • Il y a sans doute du sponsoring, mais le fait qu’il achète lui-même le matériel et assume le risque est impressionnant
  • Un autre commentaire le recommandait comme une chaîne « qui va droit au but, sans blabla inutile »

• Sur un MacBook Pro M4 Max 128GB, j’utilise surtout LMStudio et Ollama
  Les modèles sont qwen3-coder-30b A3B Instruct 8-bit MLX et gpt-oss-120b-MXFP4-Q8
  Il y a des limites pour la génération de gros volumes de code, mais c’est largement suffisant pour le résumé et la documentation de dépôts locaux
  La communauté autour de ces outils est aussi très active

  • r/LocalLLM
  • r/LocalLLaMA
  • Sur Mac, Coderunner (lien GitHub) permet d’exécuter en sandbox en toute sécurité le code généré par un LLM
  • En reliant l’API LM Studio et le CLI qwen, on peut recréer un environnement proche de Claude Code
    Pour générer des README, gemma3-27b-it-qat et gpt-oss-120b sont les modèles préférés

• Sur un MacBook Pro M1 Pro 32GB + Asahi Linux, je fais tourner Qwen3:32b en CLI
  Je m’en sers pour obtenir de l’aide sur l’assembleur ARMv8 et les sujets liés aux SoC
  La vitesse est largement suffisante, à peine plus lente que mon rythme de lecture
  J’ai entendu dire que Qwen3-coder est plus rapide, ce qui m’intéresse
  Je préfère un environnement entièrement local, sans cloud ni intégration d’agents
  Comme Ollama s’éloigne de son orientation hors ligne, je pense maintenant passer à llama.cpp
  Je me demande si je pourrai réutiliser directement mes modèles Ollama, vu le changement de format
  [Attention] Sous Linux, la consommation électrique est élevée, donc il faut absolument l’utiliser branché

  • Qwen3 Coder a une architecture MoE (3B actifs sur 30B), donc il est bien plus rapide
    Il est moins intelligent sur les tâches générales, mais beaucoup plus efficace pour le code

[chcv0313]

À force de lire, je me dis... qu’il y a finalement une demande pour DGX SPARK, non ? Au début, je pensais : ce truc a un rapport qualité-prix catastrophique, pourquoi l’acheter !, mais

[aer0700]

En raison de la politique de sécurité interne, nous n’utilisons absolument aucune API LLM externe, et nous utilisons à la place l’offre gpt oss fournie sur la base de vllm par le service interne de gestion du cloud.

[aer0700]

C’est un peu ambigu de parler de local, dans ce cas.