Exécuter des modèles locaux, c’est désormais vraiment bien

 (vickiboykis.com)
4 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Même sur un Mac M2 de 2022, les LLM locaux sont désormais assez performants pour être utilisés de façon pratique pour des questions de développement, des tâches de code et la vérification de documentation
  • Les premiers modèles locaux étaient lents, difficiles à utiliser et peu précis pour les tâches de programmation, mais depuis GPT-OSS, il est devenu moins fréquent de devoir revérifier avec des modèles API
  • Avec les dernières versions de la famille Gemma 4, les boucles de codage agentique en local fonctionnent à environ 75 % de la précision et de la vitesse des modèles de pointe
  • La combinaison de Pi et LM Studio permet d’exécuter des workflows agentiques via un endpoint d’inférence local, des artefacts de modèle et une configuration d’isolation Docker
  • Les modèles locaux gardent des limites en latence d’inférence, taille de fenêtre de contexte et contraintes matérielles, mais on peut observer et modifier directement le traitement des tokens, les prompts système, la quantification et le harness

Où en sont les modèles locaux aujourd’hui

  • Les premiers modèles locaux étaient lents, difficiles à utiliser et peu précis pour la plupart des tâches de programmation
  • L’idée que les modèles locaux étaient nettement en retard était globalement juste, du point de vue d’un usage individuel, jusqu’à la sortie de GPT-OSS
  • Le critère personnel d’un « modèle suffisamment bon » était de savoir s’il fallait revérifier avec un modèle API, et GPT-OSS a été le premier modèle à fortement réduire cette fréquence
  • Jusqu’à récemment, les modèles locaux servaient surtout de Google rapide et personnalisé pour des questions de développement ne nécessitant pas les toutes dernières informations
  • Depuis les dernières versions de la famille Gemma 4, les boucles de codage agentique en local atteignent environ 75 % de la précision et de la vitesse des modèles de pointe {p:75}

Modèles utilisés et environnement d’exécution

Exemples concrets de travail agentique en local

  • Un script Python qui était auparavant dans un notebook a été refactorisé en un dépôt composé de 5 à 6 modules
  • Ces modules ont été lintés pour utiliser des annotations de type génériques conformes à PEP 585
  • La configuration locale a aussi servi à relire des billets de blog, écrire des tests unitaires et initialiser un dépôt pour un modèle two-tower de recommandation
  • Le dépôt de modèle two-tower généré par l’agent à partir de zéro restait basique, mais dépassait ce qui semblait possible l’an dernier
  • Tous les workflows agentiques ont été exécutés dans des conteneurs Docker dont les permissions d’exécution étaient limitées

Utilisation des ressources et derniers petits modèles

  • Les tâches réalisées relevaient moins de travaux révolutionnaires que d’un Google personnalisé ou d’une consultation de documentation
  • Pendant ces tâches, l’utilisation du GPU et de la RAM augmentait fortement, et le cache K-V montait jusqu’à 64 Go de RAM
  • Même pour des tâches simples, ce type de travail local avec des modèles était encore impossible il y a 6 mois
  • Gemma-4-12b-qat a impressionné par son rapport taille/performance dès sa sortie
  • L’architecture du modèle pousse à se demander quels compromis architecturaux sont nécessaires quand il existe des contraintes de performance et de coût

Configuration d’exécution d’un modèle agentique local

  • Pour exécuter un flux agentique local, il faut un moteur d’inférence de modèle local, un harness agentique et des artefacts de modèle locaux
  • Le harness doit être configuré pour pointer vers un endpoint d’inférence local, et les artefacts de modèle téléchargés doivent être servis via le moteur d’inférence
  • La configuration locale actuelle utilise Pi comme harness agentique et LM Studio comme serveur d’inférence
  • Elle suit l’article sur la configuration du codage agentique Gemma 4 avec Pi et LM Studio, avec quelques modifications
    • Le modèle utilisé n’était pas le Gemma 26B A4B de l’article, mais le gemma-4-12b-qat, plus récent, plus petit et plus rapide, avec une perte de précision limitée
    • Pour des raisons de sécurité, toutes les sessions Pi étaient exécutées dans des conteneurs Docker et n’avaient que des permissions bash, sans exécution de code Python ni navigation web
    • Sur une image séparée dédiée aux tâches de recherche, l’autorisation de curl est envisagée
    • Comme l’exécution se fait dans Docker, le models.json de Pi a été modifié pour permettre à Pi de communiquer avec le modèle

Méthode d’isolation basée sur Docker

  • Dans la configuration Pi, baseUrl était défini sur http://host.docker.internal:1234/v1 et l’API sur openai-completions
  • La configuration Docker Compose monte models.json, le répertoire de travail, la configuration Pi et le répertoire de session dans le conteneur
  • Le script de lancement relie le répertoire de travail courant à l’espace de travail du conteneur et peut ajouter, si nécessaire, un fichier Compose de sandbox plus sécurisé
  • Pi s’exécute dans le dépôt en cours de travail et, comme il lance Docker, il ne peut pas supprimer directement des fichiers ou répertoires du disque physique
  • La configuration personnalisée du modèle en json peut être injectée dans le conteneur, ce qui a assez bien fonctionné dans un environnement expérimental

Limites restantes

  • Les modèles locaux peuvent encore être lents à l’inférence, leur fenêtre de contexte reste petite, et le contexte utilisable dépend du matériel disponible
  • L’écosystème est devenu bien plus simple grâce à des outils comme LM Studio et le bouton Use This Model de Hugging Face
  • Les premières versions rencontrent des problèmes de mauvaise correspondance de templates de prompt, mais ce genre de problème est généralement corrigé très rapidement
  • Il reste difficile d’affirmer avec certitude que tout cela est prêt à être utilisé directement pour du développement logiciel en production

Avantages des modèles locaux et possibilités d’expérimentation

  • Avec les modèles locaux, on peut quasiment tout inspecter, y compris le processus d’inférence des tokens en temps réel
  • Il est possible de vérifier directement le flux des tokens en entrée et en sortie
  • On peut modifier la fenêtre de contexte locale et observer comment les performances s’améliorent ou se dégradent
  • On peut analyser la manière dont les tokens sont traités sur le GPU, et aussi modifier les prompts système et les réglages de quantification
  • Il est possible de faire s’affronter les modèles entre eux ou de modifier la configuration côté harness et d’en observer les effets, ce qui élargit encore les possibilités d’expérimentation

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Avis Hacker News

  • Je ne sais pas si c’est vraiment mieux. J’utilise beaucoup les modèles locaux, mais l’exécution locale reste assez pénible
    Les modèles denses comme Qwen 27B et Gemma 31B sont plutôt intelligents mais lents, et les modèles MoE (mixture d’experts) comme Gemma 26B, Qwen 35B et North Mini Code 30B sont rapides mais font beaucoup d’erreurs
    Pour les faire tourner correctement, il faut beaucoup de mémoire, et la quantification affaiblit l’appel d’outils. La plupart les font tourner en quantification 4 bits puis se demandent pourquoi ce n’est pas terrible, alors qu’en pratique c’est comme faire une lobotomie au modèle. Je recommande la quantification Unsloth, et pour les MoE je conseille 6 bits, contre 5 bits pour les modèles denses
    Pour accélérer le prefill, il faut de la puissance de calcul ; pour accélérer le décodage, il faut de la bande passante ; et pour tout faire tenir, il faut aussi beaucoup de mémoire. En plus, les laptops deviennent des machines chaudes et bruyantes, peu agréables pour travailler
    Alors, est-ce que c’est bien ? Pas vraiment. Mais ça fonctionne
    J’ajoute que je pense que les modèles ouverts sont l’avenir, et je continue à contribuer à l’écosystème. Ce serait bien que les gens manipulent ce type de modèles et utilisent pi pour apprendre comment ils fonctionnent, mais il ne faut pas s’attendre à ce que ce soit immédiatement satisfaisant juste après téléchargement. Pour remplacer le « agent de code » que la plupart des gens veulent, il faut encore beaucoup de tuning et de configuration

    • Mon expérience est presque exactement la même. Il y a un ou deux mois, j’ai testé avec ollama les modèles recommandés sur un desktop relativement récent et haut de gamme (Radeon 6900 XT 16GB VRAM, Ryzen 9 7900X 12 cœurs, 64GB de RAM système)
      Les modèles non spécialisés code se retrouvaient souvent bloqués à dire « voici l’action que je vais faire » sans réellement appeler d’outil, et même en demandant quoi configurer pour changer ce comportement, ça n’aidait pas. Qwen refusait de croire qu’il tournait dans ollama et insistait sur le fait qu’il fonctionnait dans le cloud Alibaba sans accès au système local
      Même les modèles pour le code réfléchissaient à peine plus vite que ma vitesse de frappe, et la possibilité d’afficher leur raisonnement restait limitée
      Jusqu’ici, la meilleure expérience « gratuite » que j’ai trouvée, c’est OpenCode + Big Pickle. Ce n’est pas extrêmement intelligent et le premier résultat est souvent faux, mais le palier gratuit est généreux : même en l’utilisant souvent pendant plusieurs heures sur environ un mois, je n’ai touché la limite que deux fois. Si l’objectif est une vraie exécution locale, ce n’est pas adapté, mais si le but est « la meilleure expérience possible sans abonnement ni coût au token », c’est jusqu’ici l’option la moins mauvaise
    • À mon avis, pour bien faire tourner des modèles locaux, il faut encore un investissement matériel coûteux. Pour faire tourner ce genre de modèles avec un cache KV correct, on finit par vouloir environ 96GB de VRAM sur une architecture Blackwell récente
      Essayer de faire ça sur un Mac à mémoire unifiée, un processeur AMD AI Max ou un appareil proche du DGX Spark revient presque à se compliquer la vie. Le prefill plombe les performances
      Avec le bon GPU, c’est nettement mieux, mais ça reste encore en dessous du niveau de Sonnet ou de DeepSeek 4 Flash, et encore plus loin de Opus / DeepSeek Pro ou Mythos/Fable/GPT-5.5
      Si on a le budget, la puissance électrique et le refroidissement, on peut faire tourner des pipelines de données tout à fait corrects, mais pour le code, il reste le plus souvent plus raisonnable de payer un fournisseur d’API
    • Il ne faut peut-être pas faire tourner ces modèles sur des laptops aux fortes contraintes thermiques, ni s’attendre à une qualité proche de l’état de l’art avec une inférence aussi rapide que sur les grandes plateformes cloud
      Cela dit, ça vaut quand même la peine d’essayer pour moins dépendre des services centralisés
    • Gemma 4 est particulièrement bon pour les pipelines et l’automatisation
      D’après mon expérience, il surpasse les modèles Qwen, même les 100B+, sur le respect des règles ou les tâches de type automatisation. Il est aussi très bon en interprétation d’images, et sur les benchmarks il ressort au-dessus d’Opus
      Qwen a tendance à ignorer les instructions et, si l’on ne contraint pas explicitement le format de génération des tokens, à produire de façon répétée un mauvais format
      En revanche, sur DGX Spark, Gemma 31B Q4 + MTP tourne à environ 20 tokens/s, et Gemma 26B A4B à environ 60 tokens/s, donc cela reste assez lent. Sur des cartes Nvidia haut de gamme, ce sera bien plus rapide et ça tiendra aussi en mémoire
      À ceux qui débutent avec les modèles locaux, je recommande de se concentrer sur la bande passante mémoire plutôt que sur la RAM. Désormais, des modèles de moins de 100B suffisent déjà pour l’automatisation et sont très utiles
      Je suis d’accord pour dire qu’il n’y a pas encore de raison forte d’utiliser des modèles locaux pour le code ou la création. En revanche, pour parcourir des listes d’actions, faire un filtrage passe-haut de l’actualité, interpréter des logs ou analyser des captures d’écran, les modèles locaux sont déjà suffisants
    • Je me demande s’il ne vaudrait pas mieux avoir quelque part une machine qui fait tourner les modèles, partagée entre plusieurs personnes
      On pourrait peut-être justifier un Mac Studio M6 avec 256GB de RAM si plusieurs personnes se mettent d’accord pour accéder à un même modèle. Les laptops me semblent trop chauds et trop lents pour cet usage

  • Après avoir utilisé Qwen3.6-27B avec satisfaction pendant quelques semaines, je suis actuellement éloigné de mon matériel et obligé d’utiliser Claude Sonnet 4.6, et ça me donne l’impression d’une énorme régression
    Je ne comprends pas comment c’est possible. Il a beaucoup trop d’opinions tranchées non sollicitées, il parle beaucoup trop, et dans l’ensemble il me paraît plus bête
    Bien sûr, c’est un modèle bien plus gros, donc il doit encoder davantage de connaissances, mais si discuter avec lui est pénible, ça n’aide pas. En plus, discuter avec lui coûte réellement de l’argent
    Je me demande pourquoi ça me déplaît autant. C’est peut-être parce qu’il se voit presque comme un égal plutôt que comme un outil. Il se comporte comme si son opinion avait du poids
    Qwen aussi peut agir comme un stagiaire trop zélé, mais si on lui dit qu’il dit des bêtises, il ravale sa fierté. Claude, d’après mon expérience, ne le faisait pas
    Au final, je suis entièrement d’accord avec le titre

    • Je n’ai jamais dépensé un centime pour de l’inférence cloud, donc je ne peux pas comparer directement, mais je peux dire avec certitude que Qwen3.6-27B est un modèle local très compétent pour les tâches de code
      Je l’utilise presque tous les jours depuis un mois et demi sur une machine M2 Ultra ou RTX 5090. Je m’en sers pour de petites tâches ordinaires chez ggml-org [0], rien de spectaculaire, mais c’est clairement un outil utile pour un mainteneur
      Je l’utiliserais bien davantage si je ne passais pas autant de temps à relire des PR. En ce moment, j’utilise un harnais très léger : simplement l’agent pi dépouillé de tout (pi -nc --offline) et un court prompt système [1] pour l’adapter à mon style
      La vitesse de génération est d’environ 100 à 150 tokens/s sur RTX 5090, et d’environ 40 tokens/s sur Mac. Je préfère nettement le faire tourner sur la machine RTX parce que c’est beaucoup plus rapide, mais je le lance aussi souvent sur Mac pour tester les configurations locales et élargir mon expérience
      [0] - https://github.com/search?q=%22Assisted-by%22+user%3Aggml-or...
      [1] - https://github.com/ggml-org/llama.cpp/blob/master/.pi/gg/SYS...
    • J’utilise Qwen3.6-27B tous les jours, y compris comme outil principal au travail, et presque sans interruption depuis sa sortie. À mes yeux, c’est le seul petit modèle local vraiment valable, à condition de pouvoir le faire tourner
      Il est peut-être moins bon qu’Opus pour des demandes du genre « ajoute la grosse fonctionnalité X », mais ce n’est pas ce que j’attends d’un modèle. Je veux penser moi-même, et que le modèle tape pour moi. Qwen 3.6 27B est largement suffisant pour ça. D’après mon expérience, 35A3B ou la famille Gemma représentaient une nette régression
      En plus, il n’y a pas à se soucier des limites de débit, des quotas ou des files d’attente aux heures de pointe. On peut toujours voir tout le raisonnement, on n’a pas à se demander où partent les données, et il n’y a pas de baisse de qualité discrète
      Je le fais tourner sur 2×3090 avec llama.cpp en configuration Q6_K_XL + MTP, avec un préremplissage à 500–1000 tokens/s, une sortie à 60 tokens/s et une fenêtre de contexte de 220 000 tokens. Au-delà de 160 000 tokens, il commence à devenir un peu plus bête, et je n’utilise pas de quantification KV
    • Le fait qu’il « parle trop » est vraiment agaçant. Franchement, j’aimerais qu’il se taise et réponde de façon concise
      C’est peut-être un effet secondaire de la capacité de raisonnement, mais j’aimerais vraiment qu’il résume son raisonnement de manière bien plus brève. Même dans des situations où une réponse en une phrase suffit, les modèles de pointe écrivent au minimum cinq paragraphes et essaient de proposer 3 à 5 nouvelles directions
      Même quand on demande une seule étape à la fois, une seule option à la fois, et de ne pas suggérer activement la suite, c’est vraiment difficile à contrôler correctement par prompt
      Cela dit, je viens moi-même de faire exactement ce dont je me plaignais
    • Je ne généraliserais pas à partir de mon expérience avec Sonnet seulement. Les modèles flagship du côté de Claude, c’est-à-dire ceux qui correspondent à Opus, sont bien meilleurs
    • C’est amusant que les agents de code aient aussi une personnalité. Il y a même le caractère de « ce collègue » qu’on a envie d’éviter, même si on sait qu’il fait plutôt bien son travail

  • Les programmeurs ont l’habitude de ne pas payer leurs outils. Un ordinateur portable de base (SSD, multicœur, 16 Go de RAM) est déjà extrêmement puissant pour le développement en C/C++/Rust, et même en Python
    Et puis soudain, ça ne suffit plus, et on revient à une situation où l’on utilise l’ordinateur de quelqu’un d’autre et où l’on loue ses outils au quotidien. Pire encore, on se retrouve à utiliser un modèle différent chaque jour, et certains jours une sorte de mafia peut faire pression sur le fabricant et vous empêcher de louer le bon outil
    La plupart des autres métiers exigent un investissement conséquent dans les outils. Si l’on veut de bons outils, il faut environ 64 Go de mémoire GPU (par exemple 2×5090) et 96 Go de RAM. Si l’on paie 200 000 dollars un ingénieur spécialisé, dépenser 50 000 dollars en outils tous les deux ans paraît assez raisonnable

  • C’est une tendance dont des entreprises comme Anthropic devraient s’inquiéter. Plus l’exécution de modèles en local devient facile, plus le plafond de prix qu’elles pourront imposer va baisser.
    Il n’est pas dit que plus personne ne paiera $$$$$ par mois, mais beaucoup vont multiplier un abonnement mensuel par 12 ou 24 et se demander : « Est-ce que je peux monter un modèle local pour moins cher que ça et l’amortir en 1 à 2 ans ? »
    Si une part importante des clients choisit d’acheter plutôt que de louer, les entreprises fondées sur un modèle centré sur la location pourraient soudain se retrouver en manque de clients.

    • C’est exactement l’inverse qui s’est produit dans le cloud computing ces 20 dernières années. Et ce genre de bascule ne se produira pas pour les modèles d’IA.
      C’est presque gravé dans le modèle économique à l’américaine aujourd’hui : tout est externalisé. Personne ne veut gérer sa propre salle serveur, et beaucoup préfèrent payer 2 à 3 fois plus cher pour externaliser aussi les ennuis et la responsabilité.
      L’IA suivra la même logique. Que cette prime soit versée à Anthropic ou à AWS, c’est la même chose.
      Je travaille dans une entreprise plutôt petite, et nous avons récemment eu un incident lié à l’infrastructure locale. Alors même que notre temps d’arrêt cumulé en interne sur les 5 dernières années reste bien inférieur à une seule grosse panne récente d’AWS, le CEO met désormais la pression en disant que l’hébergement de notre propre infrastructure n’est pas fiable.
      Tout le monde veut se débarrasser du sale boulot et de la responsabilité.
    • Je me suis dit que ça ressemblait peut-être à la différence entre payer Netflix et télécharger via torrent pour faire tourner Plex.
      L’utilisateur grand public moyen semble plus susceptible de payer pour quelque chose de déjà configuré et immédiatement utilisable. Les gens plus techniques ou plus motivés le feront eux-mêmes, mais je me demande quelle sera la proportion entre les deux groupes.
    • Je me demande à quel moment les entreprises très orientées code commenceront à exploiter elles-mêmes des clusters d’IA on-premise.
      Je ne sais pas si quelqu’un a déjà proposé l’idée de vendre une machine 4 GPU que l’équipe d’ingénierie pourrait mettre dans un placard quelque part et utiliser avec les modèles de son choix.
      Ce ne sera pas attrayant pour tout le monde, mais avec les problèmes de confiance autour des hyperscalers qui aspirent les données des gens pour entraîner leurs modèles, certains accorderont sûrement de la valeur à une machine et à des modèles qu’ils peuvent contrôler de manière transparente, et dont ils peuvent aller débrancher la prise eux-mêmes si nécessaire.
    • Ces modèles locaux peuvent accomplir une partie de ce que font des modèles qui ne sont pas à la pointe absolue, mais pour moi la valeur reste limitée.
      Rien qu’avec Sonnet 4.6, on peut pratiquement travailler toute la journée avec un abonnement à 20 dollars par mois. Et Sonnet reste largement plus puissant que les modèles qu’on peut auto-héberger sur un Mac M2.
      Je changerai peut-être d’avis si tout le monde passe à la facturation à l’usage au token, mais sur une base d’abonnement, ça ne me semble pas tenir financièrement.
      C’est amusant. Mais ce n’est pas économiquement viable.
    • Ils font tout pour empêcher l’exécution de quoi que ce soit en local.
      OpenAI rachète toute la RAM disponible sur le marché spot, les prix de la RAM/VRAM montent par 6, et les GPU ainsi que les machines correctes deviennent inaccessibles pour la majorité.
      Une minorité aisée pourra acheter un Mac Studio 512GB ou une RTX Pro 6000 à 13 000 dollars et faire tourner un modèle local assez correct, mais la grande majorité devra passer par des API.
      À un moment, Nvidia pourrait aussi se dire : « On ne vend pas tant de 6000 que ça, on fait une marge 4 fois supérieure sur les GPU réservés aux datacenters, donc annulons ça. » À partir de là, ce sera introuvable, et il pourrait devenir impossible pour les particuliers de faire tourner en local des modèles corrects situés environ un an derrière l’état de l’art.

  • J’aimerais bien voir le code produit avec ça. J’ai envie d’utiliser des modèles locaux et j’ai le matériel pour, mais face à des remplaçants de modèles de pointe comme GPT 5.5 xhigh ou Opus, ils ne sont pas encore prêts.
    Entre la qualité et les points de friction, le flux de travail ralentit beaucoup trop, et il arrive même qu’ils cassent la syntaxe des appels d’outils.
    En revanche, pour des flux plus petits et bien définis, ou pour des modifications du type « change exactement cette partie comme ça », ça semble suffisant. J’attends qu’ils mûrissent assez pour remplacer l’état de l’art actuel, et je pense que c’est là que se fera le basculement.
    Puisqu’on parle de modèles locaux, il ne faut pas sous-estimer DiffusionGemma, ni les modèles de diffusion en général, pour un usage local. En général, le problème du local, c’est que les LLM exploitent mal le matériel à moins de regrouper les requêtes en batch pour en exécuter plusieurs en parallèle, ce qui suppose une approche totalement différente. Les modèles de diffusion, eux, sont bien plus rapides sur un prompt unique, et l’écart est loin d’être négligeable.
    Justement aujourd’hui, j’ai porté la prise en charge de diffusiongemma-26B-A4B-it de Transformers vers Candle, puis ajouté quelques optimisations, au point d’atteindre en inférence avec Candle environ 450 tokens/s (environ 19 itérations/s). Dans la bibliothèque HF Transformers, j’étais autour de 180 tokens/s (environ 11 itérations/s). Même en faisant tourner un LLM de taille comparable avec vLLM, je ne crois pas avoir dépassé 250 tokens/s sur un prompt unique, donc c’est intéressant pour un modèle local.

    • Les modèles de diffusion sont difficiles à entraîner correctement dès qu’on dépasse une petite à moyenne taille, et leur qualité est inférieure à celle des modèles classiques générant un token à la fois de même taille.

  • Pour 2 600 dollars, on peut acheter deux GPU AMD 9700 avec 32GB de RAM par carte et environ 285W de consommation. Le coût comme la consommation restent inférieurs à ceux d’une 5090.
    Avec un build de VLLM utilisant le patch AITER, on peut faire tourner Qwen3.6 27B FP8 à environ 45~50 TPS sur la fenêtre de contexte complète dans de vraies sessions de code avec Opencode ou PI.
    J’espère vraiment qu’on continuera à voir davantage de modèles denses autour de 30B, mais même avec Qwen3.6 seul, on peut déjà prendre en charge pas mal de tâches agentiques.
    En revanche, la stack ROCm ne convient pas à quelqu’un qui n’a pas envie de mettre les mains dedans et d’appliquer lui-même des patchs.

  • Je me demande pourquoi les critères d’un agent coding « bon » varient autant d’une personne à l’autre
    D’un côté, c’est vraiment impressionnant qu’on soit passé d’une intelligence du niveau de « lire “Set a Timer” sur Apple Music » à quelque chose qui pourrait presque réussir le test de Turing, mais d’un point de vue pratique, les petits modèles sont encore loin d’être « bons » pour autre chose qu’une démo technique
    Pour moi, un modèle 7B n’est qu’un écho flou de Wikipedia. Les modèles Gemma en 4 bits sont bien trop maladroits, ne serait-ce que pour générer de façon fiable du JSON d’appel d’outils ou copier une ligne de code afin d’appliquer un patch
    Qwen demande tellement d’instructions détaillées et d’attention pour éviter les boucles de perdition ou les pertes de contexte que, souvent, les consignes que je dois lui donner finissent par être plus longues que le code produit au final
    Est-ce qu’il existe un prompt magique que je ne connais pas ? Ou bien les autres sont-ils simplement beaucoup plus patients, ou ont-ils des attentes bien plus basses ?

    • Je me suis posé à peu près la même question. Je pense que si les attentes diffèrent, c’est parce que la charge de travail diffère aussi
      Sur de petits scripts, du glue code ou des changements CRUD simples, un petit modèle comme Qwen3.6-27B peut beaucoup mieux fonctionner que sur une base de code plus grosse et plus sale
    • Il y a certes un peu de standards trop bas, et ça s’accentue avec le temps, mais la configuration décrite me semble encore trop basse d’après mon expérience
      En faisant tourner des Qwen/Gemma de classe 27/35B en FP8, c’est meilleur que gemini-2.5 mais moins bon que gemini-3.1. DS4-flash FP8 peut tourner sur deux DGX Spark, et la situation continue de s’améliorer. DiffusionGemma a récemment affiché une vitesse de génération de tokens 4× plus élevée
      En résumé, les modèles essayés semblent soit trop petits, soit trop fortement quantifiés

  • J’aime faire tourner deux modèles en local. qwen3.6 27B 8 bits (dense) et qwen3.6 35B 4 bits (mixture of experts)
    Le 27B est plus intelligent et plus fiable, mais plus lent. Le 35B est plus rapide et reste très intelligent, mais il est en dessous du 27B et un peu moins stable. La raison, c’est son architecture mixture of experts (MoE), qui n’active qu’une partie des paramètres, ce qui le rend bien plus rapide
    Je fais tourner le 27B sur un MacBook Pro M5 Max + 40 cœurs GPU + 128 Go de RAM. Sur ce monstre, je peux charger le 27B et le 35B en mémoire en même temps tout en gardant de la marge pour d’autres tâches. Mais comme c’est un laptop, il est impossible de faire tourner un LLM local en permanence. Ça chauffe trop et ça devient trop bruyant
    Ce qui est plus intéressant, c’est de faire tourner le modèle 35B sur un MacMini M4 avec 64 Go de RAM. C’est rapide et ça abat beaucoup de boulot. Par exemple, il scanne, extrait et classe mes e-mails, puis continue à surveiller la boîte de réception et à travailler. Je l’utilise aussi comme assistant Hermes personnel pour lui demander des choses comme « Quand a lieu le prochain lancement de Starship ? », « Qui joue aujourd’hui à la Coupe du monde ? Donne-moi aussi quelques anecdotes »
    Mon prochain projet, c’est une workstation RTX Pro 6000 Blackwell dans le sous-sol. Je veux faire tourner Qwen très vite, avec plusieurs threads / prompts / agents en parallèle. Si le budget le permet, j’aimerais une config 2×RTX Pro 6000 pour faire tourner DeepSeek v4 flash et l’utiliser pour la recherche

    • Pour ce « Hermes », tu as pris quelque chose comme une clé API de recherche Brave ?
    • J’aimerais vraiment avoir une RTX 6000 Pro, mais comment justifier ça quand ça coûte le prix de 10 ans de Claude Max ?

  • Au quotidien, j’héberge Qwen3.6:27b, mais j’aimerais vraiment héberger deepseekv4 flash. C’est un modèle trop « bon » pour sa taille / vitesse / prix
    Je me demande à partir de quand les entreprises commenceront à héberger des modèles on-premises pour le travail quotidien, au lieu de payer un abonnement pour chaque développeur. C’est suffisamment bon et relativement abordable

  • On ne l’a pas demandé, mais aucun d’entre nous ne pense qu’il faille utiliser les tout derniers modèles de pointe pour écrire du code, ni d’ailleurs pour presque quoi que ce soit
    À la place, il faudrait développer des modèles open source pour des tâches spécifiques, et apprendre à coder, écrire et dessiner avec des doigts d’os et un cerveau de chair
    Les grandes entreprises et les centres de recherche peuvent peut-être s’en servir pour générer du code, des maths, etc., à condition d’avoir des experts pour vérifier que la sortie est correcte, mais même là, le rapport coût/valeur peut ne pas être intéressant. Par exemple, OpenAI a enregistré 36 milliards de dollars de perte nette l’an dernier, les modèles open source sont déjà assez proches, et tout le grand projet autour de l’IA est à court de crédulité à exploiter
    Il existe beaucoup de tâches qu’on peut déjà faire avec de très petits modèles, et beaucoup d’usages qui n’exigent ni une puissance de calcul délirante ni une quantité folle de mémoire, mais trop peu de gens travaillent sérieusement sur ce terrain-là