Reprise du message précédent :
Je test un nouveau workflow ici :
J'écris mon cahier des charges un peu brut à Claude pour qu'il me le rephrase au propre puis je corrige une dernière fois pour que ce soit comme je le souhaite
J'enregistre tout ce qui est token et infos sensibles dans un secret-tool (ça évite les 15 allers retours inutiles sur le fait qu'il ne sait pas où stocker le bordel proprement et qu'un fichier pourrait fonctionner mais oups le chmod 600 encore et encore )
je lance sur pi dev  
 
j'attends    
 
Sinon j'aime bien pi dev. Clairement brut de décoffrage mais comme il me recopie tout ce qu'ils se passe derrière je comprend là où le modèle perd du temps pour corriger et ça fait un vrai potentiel gain pour la communauté (moins de plugins qui existent qu'avec les autres harness mais qui pourraient être utiles à moi et la communauté si j'arrive à sortir des trucs propres)

 
je sais pas  j'ai pas testé.  J'ai testé 48mo avec les 2x8go a 2900 (donc en dual) , j'ai pas vraiment vu de différence.
 
Il voir avec les adaptateurs Sodimm.
 
Mon cpu est un Ryzen 7 5700G .  

 
Si ça peut servir de réflexion à d'autres :  
 
/!\ Alerte IA /!\
 
 
Serveur IA local pour agents (2 utilisateurs) : Mac Studio M5 Max / M5 Ultra vs box GB10 (DGX Spark)
 
Prix constatés le 02/09/2026, TTC, config 128 Go ou 96 Go / 1 To.
 

 
Ordre de grandeur : un tour d'agent, 27B dense Q4, 60K tokens de prefill + 800 tokens générés, 1 seul flux
 

 
Source : la ligne GB10 est mesurée (Qwen3.8-27B, llama.cpp ~838 t/s prefill, ~11,5 t/s décodage ; vLLM NVFP4 fait mieux en batch). M5 Max = extrapolation depuis des benchs M5 Max MacBook Pro. M5 Ultra = pure extrapolation (2x M5 Max), personne n'a encore la machine. M3 Ultra = benchs communautaires llama.cpp.
 
Points clés pour un usage agentique
 
1. Deux métriques, pas une. Le prefill (ingestion du contexte) dépend du calcul GPU ; le décodage dépend de la bande passante mémoire. Les agents sont très lourds en prefill : à chaque étape ils réingèrent la sortie des outils, les fichiers, l'historique. La bande passante seule ne suffit pas.
 
2. Le M3 Ultra reconditionné est un piège pour ce cas. Ses 819 Go/s ne gagnent que ~7 s en décodage mais l'absence de Neural Accelerators lui fait perdre 50+ s en prefill par rapport au M5 Max. Excellent pour du chat, mauvais pour des agents.
 
3. Multi-agents = problème de débit agrégé, pas de latence. Sur GB10, vLLM NVFP4 monte à ~84 t/s agrégés à 10 requêtes simultanées contre ~12 t/s en flux unique : la concurrence est quasi gratuite. Sur Mac, le batching MLX est moins mature et chaque agent supplémentaire ampute visiblement les autres.
 
4. La mémoire fixe le plafond de modèle. La classe qui compte en 2026 pour les agents, c'est les MoE 100-125B (gpt-oss-120b ~60 Go, Qwen3.8 Flash-Next ~107 Go en Q4). Avec 96 Go, Flash-Next en Q4 ne rentre pas. Avec 128 Go, ça passe, mais 2 sessions longues sur Flash-Next restent tendues ; gpt-oss-120b est confortable. Passer le M5 Ultra à 256 Go coûte +4 000 $.
 
5. Dense vs MoE sur GB10. Le 273 Go/s fait mal sur un modèle dense (27B à 12 t/s, on le sent). Sur MoE 3-6B actifs (Qwen3-Coder-30B-A3B, Qwen3.x-35B-A3B, gpt-oss-120b) le Spark tourne à 45-90 t/s. Pour des agents, on tourne en MoE de toute façon.
 
6. Écart intelligence 27B dense vs MoE 125B (chiffres Qwen, non répliqués) : quasi nul en tâche isolée (SWE-bench Pro 62,5 vs 61,7), large sur les tâches longues et agentiques (DeepSWE 58,7 vs 42,2, JobBench 55,7 vs 33,4). Le 27B boucle ou perd le fil à l'étape 14 ; le 125B finit la tâche.
 
7. Le choix logiciel compte autant que la puce. Sur Mac, les gains des Neural Accelerators passent par MLX ; llama.cpp/Ollama en capturent moins. Sur GB10, viser vLLM ou SGLang en NVFP4 (natif Blackwell, +46 % de débit batché vs FP8), prefix caching activé pour que les agents partageant un system prompt ne re-prefillent pas.
 
Verdict : pour plusieurs agents + 2 utilisateurs, la box GB10 à ~4 200 € l'emporte (128 Go, batching CUDA, second boîtier possible pour 256 Go, moins cher qu'un seul M5 Ultra). Le M5 Max 128 Go reste le bon choix si on veut une machine unique qui fait aussi du montage vidéo et qu'on refuse un Linux ARM headless. Le M5 Ultra 96 Go est le plus rapide en flux unique mais bridé par ses 96 Go pour ce cas d'usage.

dit donc j'espère que c'était généré localement sinon  

 
C'est du Fable 5.1    
 
Sur le fond tu penses toujours que le M5 Max 128Go est le meilleur parti ?

 
Je pense que la BP est tellement faible par rapport a de la VRAM que 40 GB/s ou 20GB/s avec une poignée de core (vs un GPU) change pas grand-chose.

D'experience plus c'est facile à utiliser mieux c'est utilisé : il m'a fallu 30 minutes pour démarrer mon premier qwen et jouer avec avec lm studio quand j'ai reçu mon M5 pro et le lendemain j'avais ma stack de dev connectée dessus (vs code dev container, avec cline). Mon strix halo ça fait 5 mois qu'il prenait la poussière en attendant que je finisse "encore un p'tit truc" et j'ai encore des emmerdes à la con genre : comment remettre en état si je casse trop de trucs ? alors qu'avec le Mac j'ai time machine c'est super facile et rapide de revenir à la minute que je préfère
 
Je dis pas que le mac est supérieur en tout (notamment le rapport qualité prix qui n'est pas la spécialité de nvidia mais qui est érigé en anti-pattern chez Apple ) mais de mon expérience perso si tu veux être productif faut soit du très facile pour tester / utiliser au quotidien soit du très très rapide qui justifie de perdre plusieurs jours/semaines avant de trouver une stack bien et tellement rapide que ça ne sert à rien de chercher une alternative.
 
Perso je ne regrette pas mon strix halo : tous les "encore un p'tit truc" tenait du rêve de gosse quand j'ai commencé à installer des appliance de sécurité sur une vieille becane pour protéger mon réseau. Mais si je voulais être productif ben je mettais 3k€ de plus sur mon macbook pro et j'avais le macbook pro max 128GO et c'était marre j'avais mes agents le lendemain pour bosser

jai absolument tout fermé, meme erreur. Apres j'ai redemarré. MacOS a peine lancé, avec rien de lancé, c'est presque 7Go de ram utilisés. ca ne passera jamais avec ca du coup, impossible d'avoir 20Go dispo !  
Tu fais comment toi ?

J'ai 48GO ...  
 
Mais normalement ça devrait swapper en nvme (pas terrible pour la mémoire flash mais bref pas le choix) tu maintiens bien le bouton option du clavier quand tu clic sur le bouton "load model" ?

Sur LM Studio ? je nai pas eu besoin, il se load bien, cest quand je poste un message qu'il m'affiche le message d'erreur.  
llama.cpp serait plus pratique a utiliser ? ca marche mieux ?

essaie de mettre un mini contexte (6k) et regarde ce que ça donne, copie colle les logs aussi (accessibles depuis l'icone developpeur en forme de prompt à gauche dans le menu principal)

Ca vaut pas une vue mer / montagne / paysage semi urbain mais c'est sympa quand même    
 

C'est magnifique
T'as tout ça avec l'API de llama.cpp ou tu choppes des trucs en plus?
 
Perso ça sera la map des layers en mémoire(s) que je voudrais. J'ai trouvé ça:
https://github.com/gpustack/gguf-parser-go
 
Mais Windows defender me dit qu'il y a un trojan dans les binaires alors j'ai pas insisté. Virustotal est presque green, donc je pense que c'est un faux positif, mais je testerais dans une semaine

 
+1
peut être que tu n'as pas le mmap activé?
 

 
L'avantage de llama.cpp c'est que tu auras directement la ligne d'erreur, en plus ya pas de UI qui bouffe de la RAM inutilement.

Contexte de 4K, logs vide  
[2026-09-02 02:00:49][INFO] Server stopped.
[2026-09-02 08:44:40][INFO] Server stopped.
[2026-09-02 09:05:58][INFO] Server stopped.
[2026-09-02 14:53:02][INFO] Server stopped.
[2026-09-02 15:15:38][INFO] Server stopped.

Toute la partie stat des tokens en effet Pour la partie hardware ça vient de rocm-smi il est capable de te former des outputs en json
 
Y'a de quoi faire niveau projets pour environnement de travail. J'aurais voulu les stats des tokens utilisables vs reasonning mais à priori il aurait fallu passer par un proxy pour les différencier. Je reste sur ça pour le moment

chope celui là (gguf)  

 
Si ça donne rien redémarre le mac, repasse lui la ligne de commande que je t'avais donné (elle est annulée après chaque reboot donc si maj ou autre ...) et relance le modèle

je teste avec llama.cpp la, justement le GGUF. DL en cours

Bonne idée après j'ai jamais eu de soucis avec lmstudio même en étant très limite sur la mémoire dispo

La chose qui me fait dire qu'Intel a peut-être quelque chose de performant en compute, c'est justement qu'ils foutent un paquet de ram. Au prix ou est la ram, ce serait débile de mettre autant de ram sur un truc de merde, non ?

Surtout qu'en compute, intel c'est pas les premiers venus qui découvrent

Pour ceux qui se posent la question de pi.dev / Hermes / Openclaw avec une ia locale en backend. Voici mon experience :
=> Openclaw : marche bien mais il est un peu chien fou (tu peux accéder à ce repo ? Ah bah oui, j'en ai lu le nom donc je me suis permis de développer un produit et de l'y commit sans rien demander de plus   ) et legerement fini à la pisse (llama qui passe son temps à passer les requetes en mode plain text parce que y'a des caractères interdits une requête sur deux, refus de passer la gateway de communication sur autre chose sur le modèle fourni au premier démarrage de l'app ...) en plus de bruler des tokens sans lendemain
=> Hermes : carré et bien bordé au niveau de l'app. Par contre un peu trop verbeux sur les canaux de communication (toutes les 5 minutes un nouveau message pour me dire qu'il bosse toujours  . à tendance à demander plein de trucs pour des raisons de sécurité mais sans attendre la réponse (c'est con je regarde pas chaque seconde ce qu'il fait et je sais pas si /approve est intéressant vu tout ce qu'il s'est passé depuis)
=> Pi.dev la plateforme des barbus   . Ca roule mais il a aucun moyen de tweaker ses paramètres automatiquement ou de te proposer des correctifs donc ça crash violent   sans prévenir mais heureusement c'est facile à troubleshooter parce qu'il a ecrit tout ce qu'il fait / pensé juste au dessus et la config de base est super minimaliste. C'est un peu rustique, comme une distrib d'il y a 20 ans, mais si tu es prêt à lui donner de l'attention il te le rendra  

dis ça à huawei et ses acelerateurs il y a un an

little coder que j'avais testé, il a pas aimé qwen 3.8 en xhigh, il coupait le raisonnement et produisait rien

 
On verra bien, mais ça serait pas la première fois qu'une boite sort un produit juste pour occuper le terrain
 
 

 
Pareil, il a pris sa retraite et claude a repris sa place. Le truc chiant c'est que Qwen quand on lui coupe son thinking ... ben il le reprend

 
Pour pi.dev, j'aime bien le fait qu'il soit en yolo par défaut. Après, je lui ait ajouté des plugins, et la ça devient un peu le bordel comme OpenClaw rapidement avec des trucs vibe-codés/vérolés . Ça aide pas non plus que je change de modèle tout les deux jours. Au final little-coder était ce a quoi je voulais arriver, mais il est trop interventionniste a mon gout.  

@neo world
ca marche avec llama.cpp, jai demandé a claude cli de faire des tests et des comparatifs. jai q3kxl, Q4KM et IQ4XS. ca me donne a peu pres du 5 token/s, petit contexte... le probleme nest pas la en fait. en fanlesse, le MBA chauffe tres vite et evidemment il throttle. donc si je veux faire de lia locale avec mon macbook, cest sur un pro ou rien (enfin jai limpression)
Merci pour le test cetait interessant

Tu as demandé à l’ia si tu pouvais avoir mieux avec un support ventilé ou les solutions avec du refroidissement actif (plaque watercoolee ou pelletier). Mais en effet même le 14 pouces throttle parce qu’il n’a qu’un seul ventilateur

J'avais jamais remarqué, peut être que c'est nouveau, mais on a des stats mémoire quand on quitte llama.cpp:
 

Interventionniste dans quel sens ? Ça posait quel genre de problème ?

Si tout va bien j’arrête plus le mien. Je vais juste lui ajouter un 27b débridé pour un agent Check code / sécurité

Ca ne m'interesse pas. je bouge trop pour me poser, je suis rarement sur un bureau fixe (et chez moi j'ai une 3090 qui arrive, ce sera plutot elle qui fera tourner un bon 3.8 en 27B).  
Le 14 pouces a 1 seul ventilateur en MX simple, en MX Pro / MX Max il en a deux.

Bon compromis. Tu as le mm studio link qui je crois est gratuit et te permettrait d’utiliser ta 3090 de n’importe où

J'ai aussi regardé pour un Pro mais c'est vite cher
Apple me reprend mon M3 Air 550 balles, ça vaut pas le coup.

D'où l'idée de le garder et de prendre un studio en plus (ou un GB10 en fonction des prix).

Ordre de grandeur en IA agentique :

DGX Spark:
8 requêtes simultanées (modèle 7B à quantification Q4), il maintient un débit global exceptionnel de ~620 jetons/s (soit environ 78 jetons/s par flux d'agent)

Mac Studio:
Bien que des frameworks tiers comme oMLX corrigent cela via du continuous batching et un cache KV hiérarchisé déchargé sur SSD, l'architecture matérielle d'Apple reste moins performante que CUDA pour le multi-utilisateur. Sur un test à 8 requêtes concurrentes (7B Q4), le Mac Studio M5 Max plafonne à ~340 jetons/s au global (~43 jetons/s par flux d'agent).

 
Déjà je coup de couper le thinking, ça pose plus de problème qu'autre chose je trouve. Qwen 3.8 se remet a résonner, et je trouve que sur 3.6 ça le faisait partir dans des trucs alacon.
J'ai vu aussi que little-coder coupait certains tools, en disait qu'il fallait pas faire comme ça. Si le modèle essayait d’éditer un fichier sans l'avoir lu avant, il l'envoyait bouler.
 
En plus je me prennait la tête a cause de la doc qui dit de changer:
~/.config/little-coder/models.json
 
Mais comme j'avais déjà testé pi.dev seul, il choppe sa config dans ~/.pi/    
 
Au final ya une tonne d'extensions, et c'est trop pour un truc léger:
https://github.com/itayinbarr/littl [...] extensions

pour les strix halo, y'a ça : https://github.com/julianmb/q38rocm
bon, je vois plein de trucs pour améliorer les vitesses, tant niveau quant que moteur.
intéressant

 
J'ai jamais reussi a avoir quoique ce soit d'utilisable avec leur quants

Les quants en rocmfpx ?
Avec le fork de llama.cpp ?

perso content du systeme atomic https://atomic.chat/blog/guides/how [...] xt-locally
 
Gros bordel à déployer (le llama qui venait avec lemonade le supporte pas. J'ai du passer par llama compilé exprès avec les bons flags et une integration comme custom cloud provider pour laisser lemonade router entre mes modèles) mais après ça semble rouler. J'attends de tester le soft avant de me prononcer totalement
 
edit : passage de la barre de 205k tokens de contexte. Compactage planifié à 240k tokens  

ça scan des failles wordpress mais ça ne dit pas non a une API de llm qui traine
 

 
 
#sortez couverts

GLM 5.3 flash tourne bien chez moi, je suis très content, d'autres utilisateurs moins. Je pense qu'ils promptent en français ou en allemand et se tapent des réponses en chinois. Moi je bosse en anglais et ça ne m'arrive pas.
Je trouve sa capacité de langage humain correcte, similaire à DS4 Flash. C'est un peu plus lent mais c'est plus précis sur les problèmes cachés dans du code complexe.