𝕂onekoJe viens de lancer une analyse d’un projet perso avec Claude Code en utilisant un modèle auto-hébergé (llama3.2).
Ça fait plus de 10 minutes que mon PC turbine.
15 minutes pour ça :
❯ Analyse le code.
â—Ź I'll start by analyzing the provided code snippet.
# This is a JSON object, but I don't see any clear indication of what it represents.
Could you please provide more context or information about this JSON object? What kind of data does it contain?
Also, I notice that there are some system reminders and local command caveats at the top. These seem to be related to the environment or tool being used, but they don't appear to be
relevant to the task at hand.
Let's focus on analyzing the code snippet itself. It appears to be a JSON object with several properties, including allowed_domains, blocked_domains, and a query property. However, without
more context, it's difficult for me to determine the purpose or meaning of this data.
If you could provide more information about what this code represents or how it should be used, I'd be happy to try and assist further.
Status: Incomplete
Action Required: Provide more context or information about the JSON object.
âś» Cooked for 15m 7s
Je retente avec le modèle qwen3.5.
J’ai lancé la commande
Ça fait déjà plus de 6 minutes que ça tourne à fond.
J’ai lancé la commande
/init.Ça fait déjà plus de 6 minutes que ça tourne à fond.
Je pense que je vais m’arrêter là .
La conclusion, c’est que c’est inimaginable d’utiliser l’IA sans utiliser la puissance de calcule démesurée des datacentres.
Faite-le test :
ollama launch claude --model qwen3.5Je lui ai demandé de me générer un firmware en Rust pour clavier mécanique.
Je suis volontairement resté très vague.
Quel microcontrôleur ? Split ou non ? Combien de touches ? Aucune question ne me sera posée. Un·e vraie développeuse n’aurait pas commencé sans un minimum de spec.
Un modèle m’a pondu un bout de code ridicule, utilisant une crate qui n’existe pas, et qui «gère», en gros, les touches fléchées.
Un autre modèle me propose d’utiliser la crate qmk-rs (inexistante) pour utiliser le firmware QMK (zéro ligne de Rust). Il communique avec le firmware avec la crate libusb (pareil, projet full C, et côté hôte par dessus le marché).
Inexploitable
🪨@koneko Plusieurs observations de ton thread, venant de mon "expérience" avec ollama :
- llama3.2 a un an, c'est une éternité en termes de modèles. C'est aussi des petits modèles que j'ai jamais trouvé très bons perso.
- Quel GPU est-ce que tu utilises ? As-tu vérifié que ça tourne bien sur ton GPU et pas sur ton CPU ? 15 minutes à tourner pour un petit modèle, ça semble beaucoup... Perso j'ai une AMD RX 6700XT, elle n'est officiellement pas supportée pour faire tourner Rocm donc je dois rajouter une variable d'environnement pour l'utiliser avec ollama
- La taille du modèle et du contexte comptent beaucoup avec les modèles locaux. En gros tu veux le modèle le plus récent possible (gemma4 vient de sortir, pas encore testé, qwen3.5 est récent aussi mais ses données s'arrêtent en 2024 donc il faut l'utiliser avec des "outils"), le plus gros possible pour ta carte graphique, tout en gardant assez de place pour le contexte. Il y a des calculateurs genre apxml.com/tools/vram-calculator pour voir si le modèle rentre et combien de tokens tu peux utiliser pour le contexte, en général je pars sur 2/3 de ma VRAM pour le modèle, si je veux une tâche qui demande un gros contexte (genre analyser une codebase complète) il faudra un plus petit modèle.
- Si tu mets en mode code et que tu donnes un prompt très vague, le modèle va juste pondre un truc vague. Je trouve perso que les modèles locaux sont mauvais pour commencer un projet parce qu'ils n'ont pas assez de données sur les libs existantes, donc ça pond juste un truc qui l'arrange, et pour utiliser les outils de recherche internet il faut passer par des services de recherche pour LLM qui ont leurs propres tokens (yay capitalisme). Si tu définis les dépendances toi-même (ou en utilisant un modèle "connecté" juste pour cette partie, mais du coup ça tue un peu le concept de tout faire en local), que tu rajoutes ces dépendances et ensuite ajoute au contexte les dépendances locales, tu vas avoir des meilleurs résultats.
- Si tu veux un truc un minimum complexe, toujours commencer en mode "plan", et quand tu as tout défini, continuer en mode "build". Une bonne idée aussi c'est de mettre le résultat du plan dans un .MD et laisser un autre contexte utiliser ça, pour éviter des potentielles contaminations du contexte du genre "ok, je vais utiliser la crate qmk-rs. Non ducon elle n'existe pas !! Ok je vais implémenter ça moi-même" et vu que ça mentionne qmk-rs ça va chercher à l'utiliser.
- Les "outils", c'est nécessaire avec les derniers modèles, mais chaque outil prend du contexte, donc évalue ce qui est nécessaire et utilise juste ça. J'ai pas encore assez testé les outils pour avoir une opinion, mais une chose qui est essentielle c'est rajouter les fichiers que tu veux au contexte, et laisser le modèle lire les fichiers liés pour mieux analyser les dépendances.
- llama3.2 a un an, c'est une éternité en termes de modèles. C'est aussi des petits modèles que j'ai jamais trouvé très bons perso.
- Quel GPU est-ce que tu utilises ? As-tu vérifié que ça tourne bien sur ton GPU et pas sur ton CPU ? 15 minutes à tourner pour un petit modèle, ça semble beaucoup... Perso j'ai une AMD RX 6700XT, elle n'est officiellement pas supportée pour faire tourner Rocm donc je dois rajouter une variable d'environnement pour l'utiliser avec ollama
- La taille du modèle et du contexte comptent beaucoup avec les modèles locaux. En gros tu veux le modèle le plus récent possible (gemma4 vient de sortir, pas encore testé, qwen3.5 est récent aussi mais ses données s'arrêtent en 2024 donc il faut l'utiliser avec des "outils"), le plus gros possible pour ta carte graphique, tout en gardant assez de place pour le contexte. Il y a des calculateurs genre apxml.com/tools/vram-calculator pour voir si le modèle rentre et combien de tokens tu peux utiliser pour le contexte, en général je pars sur 2/3 de ma VRAM pour le modèle, si je veux une tâche qui demande un gros contexte (genre analyser une codebase complète) il faudra un plus petit modèle.
- Si tu mets en mode code et que tu donnes un prompt très vague, le modèle va juste pondre un truc vague. Je trouve perso que les modèles locaux sont mauvais pour commencer un projet parce qu'ils n'ont pas assez de données sur les libs existantes, donc ça pond juste un truc qui l'arrange, et pour utiliser les outils de recherche internet il faut passer par des services de recherche pour LLM qui ont leurs propres tokens (yay capitalisme). Si tu définis les dépendances toi-même (ou en utilisant un modèle "connecté" juste pour cette partie, mais du coup ça tue un peu le concept de tout faire en local), que tu rajoutes ces dépendances et ensuite ajoute au contexte les dépendances locales, tu vas avoir des meilleurs résultats.
- Si tu veux un truc un minimum complexe, toujours commencer en mode "plan", et quand tu as tout défini, continuer en mode "build". Une bonne idée aussi c'est de mettre le résultat du plan dans un .MD et laisser un autre contexte utiliser ça, pour éviter des potentielles contaminations du contexte du genre "ok, je vais utiliser la crate qmk-rs. Non ducon elle n'existe pas !! Ok je vais implémenter ça moi-même" et vu que ça mentionne qmk-rs ça va chercher à l'utiliser.
- Les "outils", c'est nécessaire avec les derniers modèles, mais chaque outil prend du contexte, donc évalue ce qui est nécessaire et utilise juste ça. J'ai pas encore assez testé les outils pour avoir une opinion, mais une chose qui est essentielle c'est rajouter les fichiers que tu veux au contexte, et laisser le modèle lire les fichiers liés pour mieux analyser les dépendances.
