Reprise du message précédent :
D.ieu veut pas nous faire un agent IA qui peut répondre, connait l'art du redface, et sait poster du code, tout en utilisant correctement le BB code, idéalement en memant avec les réfs historiques d'HFR ?

openclaw c'est pas du code

Personne a parlé d'OpenClaw
 
Et si on l'utilisait, tu peux appeler une IA dans une autre IA au pire, le(s) modèle(s) que tu veux pour générer du code

Yes le topic sur le slang HFR va servir

mais la différence bon sang, j'ai utilisé Gemini CLI pour avancer ,c'est tellement mieux que antigravity (à part que dans antigravity on a accès aux modèles claudes), mais les versions de gemini dans CLI sont beaucoup moins nerf
ça change tout !

"moins nerf"? ce veut dire quoi?

Ils rendent les modèles moins performants (moins intelligents)
Comme si je prends du sirop et je le dilue plus que de raison avec de l'eau
Ben le goût c'est pas le même à la sortie

Spécifique à Antigravity ou ça a été constaté sur d'autres IDE ?

Les autres je sais pas
C'est mon ressenti en tout cas sur antigravity versus Gemini CLI

Opencode + llama.cpp et Qwen3-Coder-Next-GGUF:UD-IQ3_S ça marche pas mal!
 
Il arrive bien a progresser sur la reimplementation du MCP debug pour fs-uae.
 
Le code C++ est assez propre avec les même travers que d'habitude, genre parser JSON maison et des classes de 1k lignes sans split dans des fichiers.
 
Le problème par contre c'est que malgré des prompts agents et simili Ralph, il s'arrête au bout d'une heure, souvent sur une erreur de parsing or de tool. J'ai l'impression qu'il ne récupère pas le taux d'utilisation de contexte et fini par le remplir. C'est étrange car j'ai l'impression qu'il compacte quand même, je vois pas comment il pourrait ternir avec 64K de contexte pendant plus de 30 minutes.
 
Sinon ça bouge bien coté TurboQuants sur llama.cpp:
https://github.com/ggml-org/llama.cpp/discussions/20969
 
TLDR; en tq3 on a 900MB pour 64k de contexte. Il y a plein d'impl différentes en cours, certains rapportent même des gains en vitesse (+15%), d'autres des pertes, ou encore des perplexités plus élevées. Mais ya un gros potentiel, sur certains modèles comme les Qwens c'est x5 sans pertes. D'autres modèles ayant moins de layers, comme GPT, ont des gains beaucoup plus faibles.

Y a ça d'intéressant pour ton cas de figure https://github.com/itigges22/ATLAS

 
Il doit utiliser une vieille version de llama, ça fait un moment que le Speculative decoding est cassé sur Qwen 3.5:
https://github.com/ggml-org/llama.cpp/issues/20039
https://github.com/ggml-org/llama.cpp/pull/19493
 
Mais je sais pas si son approche est viable, il fait 3 tentatives de processing de prompt puis répare jusqu'à avoir le bon résultat. Mes prompts actuels prennent entre 20 et 60 minutes, mais son postula c'est que ça serait plus rapide en faisant 3x plus de prompts avec un plus petit modèle et plus rapide. Je pense pas que ça soit applicable a ce que je fais.
 
Ce qu'il résous c'est ce genre de trucs:
https://huggingface.co/datasets/liv [...] ation_lite

depuis la dernière mise à jour de google antigravity, j'ai cette erreur: error executing cascade step: CORTEX_STEP_TYPE_RUN_COMMAND: failed to set up sandbox: sandboxing is not supported on Windows

et vous ?

J'ai eu ça aussi mais ça bloquait pas le reste

oue ca bloque quand il veut faire certaines commandes sensible, ca veut créer une sandbox.

Et il arrive pas à finir ? Tu peux pas lui dire de faire autrement ?

j'ai un vieux site en ansi iso-8859-1, le llm marche bien qu'avec utf-8, sinon il faut qu'il fasse des commande en sandbox, mais c'est là que ça bug.

ca marchait bien avant, ça a dérapé avec la dernière mise à jour.

là j'utilise gemini 3 flash, les autres j'ai atteind la limite, peut être qu'ils sont moins con et arrivent à passer outre comme avant ?!
je dois attend le 2 avril

3 flash oublie, il est con  ce modèle

Vous avez des workflows ou des astuces pour travailler en local avec des tous petits modèles (qui tourne sur 32GB RAM + 10GB VRAM) ?

Prend un model qui appelle Claude
 
Avec cette quantité de VRAM, le model ne pourra pas faire au delà de l'auto complétion je dirais. et ça dépend aussi de l'IDE que tu utilises pour de l'auto complétion, pour un cli avec cette quantité de VRAM ça va être compliqué)

Tu peux diminuer la largeur d'adressage (8b, 4b) pour gérer des modèles plus gros. Si tu es sur Nvidia, CUDA est nativement géré sinon AMD, go HIP SDK pour ROCm
 
Je teste gpt-oss-20b, gemma3-12/27b, et qq autres petits modèles. Sans bon GPU ça marchera, mais avec le couple CPU/RAM plutôt que GPU/VRAM, auquel cas, tu seras à quelques tokens / secondes plutôt que quelques dizaines de tokens/minute
 
Go Artificial Analysis pour les benchs sur les modèles (cloud ou locaux) qui conviendront à ton usage (IAG, RAG, agentique, etc.)
 
LM Studio est mieux qu'Ollama (MCP géré nativement, quantification, inférence, etc. réglables à la main) mais je fais aucune confiance au soft en termes de confidentialité et sécu des données pro. Mieux vaut mieux pisser du code en Python faire sa propre boîte quitte à vibe coder plus que de raison

Anthropic a sorti quels modèles non-cloud?

Aucun
Il dit de prendre un modèle qui appelle Claude pour contourner son soucis de quantité de mémoire

Qwen 3.5  devrait pouvoir tourner sans trop de soucis ( A toi d'essayer lequel : 27b ou 35bA3) ... (Avec lmstudio +Opencode pluggé dessus ça marche bien)

 
Je teste un peu zed
 
L’autocomplétion, c'est le pire en fait. C'est beaucoup trop long. Ou alors faudrait que j'essaie vraiment des mini modèles
En mode agent, c'est lent, mais ça avance    
 

 
Merci, je vais regarder tout ça
 

 
Ouais, jusque là, Qwen 3.5, c'est le seul que j'ai réussi à faire tourner à peu près (ollama + zed)

J'ai tester plein de modèle (plus récemment) tenant dans 24 Go et même des un peu plus grand et franchement au delà de l'auto complétion et éventuellement répondre a des questions, ça ira pas plus loin de ce que j'ai vu.
 
Après c'est toujours pareil ça doit dépendre de ton besoin, mais pour moi c'est pas encore assez puissant pour du code local. Si tu prend un model 100+ peut être que ça doit commencer a être pas mal, mais la rapidité va être catastrophique.
 
J'ai tester dernièrement opcode avec Glm 4.7-flash ce que propose Ollama avec opencode en recommande, je lui pose un question simple et il se met a me modifier le code de partout ... donc bon ^^

Peut être https://huggingface.co/Qwen/Qwen2.5 [...] truct-GGUF ?

De mon coté je suis assez content du combo Qwen-coder-next, llama et Opencode, merci pour la suggestion Tronklou!
 
J'ai installé Ultraworks: https://github.com/code-yeongyu/oh-my-openagent et il bosse depuis ce matin 8h sans arrêt! Mais en fait il fait pas grand-chose, il a juste changé 20 lignes de code .
Quand je vois le prompt c'est beaucoup trop:
https://github.com/code-yeongyu/oh- [...] default.ts
 
14Kb \o/ il bouffe tout le contexte juste pour prendre le prompt en compte... faut que je trouve un truc plus léger

En semi-pro (apprentissage + développement de compétences + poste de travail local IA), j'ai regardé pour une RTX 5000 48 Go (déjà omis la RTX 6000 96 Go ), elle reste encore sacrément chère    
 
Quelqu'un a un site qui trace l'évolution des prix (horaires, journaliers, mensuels) pour des pods/workers cloud dédiés à l'IA ( volume de VRAM et de TFLOPS IA -donc FP4 ou FP8- mais pas nécessairement sur GPU dédié ) ??
J'aimerais sortir de l'environnement API/cloud assez vite sans être tributaire de ladite tour pour computer à minima. Fait un tour d'horizon rapido, pas trouvé mon bonheur, c'est beaucoup de benchmarks de modèles  
 
L'idée serait de pouvoir connecter des workers agentiques, scalables, dont le prix a un certain agnosticisme (pas total mais dans une certaine mesure), sur des produits sur mesure déployés par des clients, et (surtout), de fonctionner en avance de phase sur la facturation si les coûts d'hébergement/IA explosent

C'est ce que j'ai utilisé en 32B mais au delà de l'auto complétion c'est pas efficace.

 
Faudrait tenter Qwen 3.5 27B UD-IQ3_XXS avec de offload CPU, il est très lent mais marche pas mal.

C'est facile de plug lmstudio à open code?

Le problème est pas le offload c'est le modèle.
 
Le model 32B est meilleur mais j'étais en IQ4 full VRAM mais c'est quand même trop limité.

 
Non, je pensais pareil avec Qwen 3.5 en 35B A3B, mais en fait non. Comme le 32B ce sont des modèles MoE, dans le cas du 35B il n'a que 3B d'actif. Dans mes tests le 27B était bien meilleur que le 35B, mais beaucoup plus lent, dans les 10/15 tg/s la ou 35B montait facilement a 50 tg/s.
 

J'ai remplacé Ultrawork par sa version slim:
https://github.com/alvinunreal/oh-my-opencode-slim
 
On va voir ce que ça donne, ça à l'air beaucoup plus rapide.

 
Oui il y a un connecteur natif (lmstudio est dans la liste des providers)

 
Tip top
 
J'ai commandé pas mal de trucs pour tester... des trucs, je ferais un retex ici

 
Cool, j'aime les tests de trucs

Encore une fois le problème n'est pas la rapidité mais la qualité des réponses.