Reprise du message précédent :
C'est une tradition   ? Y'a un léger bug pour passer les tubes
 
Ici j'ai refait ma stack :
backend IA toujours sur Strix Halo (étonnant )  
VS Code Devcontainer (Docker Desktop sur Mac)
Cline en mode connexion compatible open AI (sinon cet idiot refuse de mettre une clé d'API )
Plan avec Minimax-m2.7 3qbits XXS
Code avec Qwen3 coder Next Q8
 
Je lui ait fait faire un flappy bee (qui a demandé quelques corrections que coder-next a géré seul)
https://crimson-ilene-59.tiiny.site/
 
enjoy  

Je fais toujours un flappy bird en mode one shot:

 
Ça me permet de voir si le modèle est bon ou pas. Un truc qui marche pas du premier coup c'est out.
Je peux valider le split mémoire et la charge, mais surtout le tg/s, je prends pas un modèle en dessous de 30 tg/s.
 
La je viens de lancer Mistral-Small-4-119B-2603-UD-IQ4_XS pour le fun, mais 5 tg/s c'est pas viable .
 
Le résultat est pas fameux:
https://goated-lint-j507.pagedrop.io
 
J'ai prévu de tester Nemotron et Qwen 122B avant de revenir a Qwen 3.6.

Je suis un peu plus exigeant
 

Nemotron super ne semble pas être un bon developpeur. Plutôt adapté à de l'orchestration

Comme dans la vraie vie : t'es nul en dev, va faire du pilotage de projet  

Rigole pas avec ces technologies on sera tous chef de projet / manager d’une équipe d’agents dans un futur pas si lointain

Ha mais c'est une certitude

Ou remplacé.

Je teste on verra bien
 

 
Pitié ça fait des années que je refuse ça...

Par un LLM ?  

 
En effet, 3 tg/s et code non fonctionnel. 120B de paramètre pour de l'orchestration c'est cher payé .

Ça fait cher de RAM , tu le fais tourner sur quoi ?

Ouais. Ou plutot l'idée que les LLM remplace les gens.
 
Les patrons ont viré massivement ces deux dernières années, sous prétexte d'optimisation via l'IA.

Le grand remplacement qu'on n'aura pas vu venir
 
Le RN s'attaquera à l'IA dans quelques années du coup

 
Ma config alacon: Ryzen 3600, 32GB RAM, 4060Ti 16GB + BC250.
 
Sinon Qwen 3.5 122B, 3tg/s nul
https://intuitive-aurora-g476.pagedrop.io

ah ouais l'offload vers le CPU fait mal ! Tu as testé des modèles en NFP4 ? C'est sensé faire des miracles avec les cartes nvidia

Non, j'ai un mix NV/AMD pour les CG.

attends tu fais du multinodes avec le BC250 ?    
 
moi je parlais de trouveru n modèle pépouse qui tient sur ta 4060 ti  

Ben oui, ça marche super bien, RPC powa
Ça me donne 30GB de VRAM.
 
La j'étais en train de tester des modèles de 50/60GB maintenant que j'ai libéré ma RAM.

je veux bien que tu nous dise comment tu as procédé (frameworks, config, partie réseau ...), les modèles qui le supportent le mieux etc. en mode tutoriel "j'ai trouvé une boite à chaussures dans mon grenier, une peau de banane et un raspberry pi nano. Je peux les assembler façon megazorde pour héberger mon modèle ?" Pour l'ajouter à la FP
 
Tu peux le faire rédiger pour une IA si elle est locale et si tu vérifie l'info

Faut donc devenir patron pour ne pas se faire grandremplacer  

c'est les suivants à se faire remplacer #Matrix

Merci à ceux qui m'ont répondu il y a déjà trois pages

Si je récapitule ce que j'ai testé sous Windows pour ma 9070XT où je voulais faire fonctionner Vulkan ou ROCm, voilà ce que j'en retire si ça peut servir à quelqu'un (attention, niveau super débutant du LLM en local ) :

- Ollama (fourni par AMD avec la "AI Suite" quand on installe les drivers) : c'est tout pourri. Le paramétrage est limité, le support Vulkan moyen (j'avais fréquemment des erreurs et les perfs sont bof, cf mon post initial), et par défaut il n'est pas activé, ce qui est quand même un comble pour un truc poussé dans un driver de GPU . Bref on se demande pourquoi AMD met ça en avant.

- Lemonade : c'est mieux, ça tourne correctement en Vulkan, mais ça me semble beaucoup trop user friendly, on ne peut pas paramétrer grand chose. Truc appréciable, le catalogue de modèles est bien fourni et ils sont triés par usage (dont la génération d'image / audio, etc). Ca doit être sympa pour découvrir quand on ne sait pas ce qu'on cherche précisément. Les modèles Stable Diffusion ne fonctionnent pas (il ne trouve pas hipmachin, donc encore une histoire de ROCm, mais j'ai un driver AMD de retard)

- LM Studio : ça marche du feu de dieu . Aussi bien en Vulkan qu'en ROCm (les deux s'installent en un clic), c'est performant, très paramétrable, et ça tourne nickel . Plutôt orienté LLM que Diffusion et cie par contre à première vue contrairement à Lemonade qui fait tout. Et quelques modèles qui ne se chargent pas sans raison avec un message d'erreur ultra vague. De ce côté là Lemonade semble plus polyvalent et plus cohérent.

gros fan de LM studio aussi que ce soit sur Mac ou linux. Merci pour ton retour

Moi c'est tout l'inverse, j'ai testé Ollama, LlamaCPP, AnythingLLM et LMStudio sur Windows et Mac, et celui qui marche le moins bien est systématiquement LMStudio, chaque fois que je teste un model dessus ça bug ou crash (model qui fonctionne avec les autres solutions) aussi bien sur MAC que Windows, pourtant sur le papier il réuni le meilleur des 3 autres produits. Du coup j'ai laissé tombé.

tu as regardé les logs ? mois les seuls fois où ça merdait c'était des out of memory et faut penser à aller chercher des frameworks à jours dans config / runtime

Lemonade a quand même l'air de garder le gros avantage de la polyvalence, mais j'ai vraiment du mal avec l'interface qui ne donne accès à rien.
 
J'ai édité mon post pour compléter un poil mais j'ai aussi eu des petits pb avec LM Studio sur certains modèles (les gros du marché fonctionnent parfaitement par contre : Qwen, Gemma...)

Rien dans les logs, dans la plupart des cas ça me mettait des erreurs du type "unable to load the model" sans justifications, sur des petits model (<12B) qui passaient crèmes sur les autres outils.
J'ai même demandé de l'aide à l'IA qui a fini par me répondre qu'effectivement LMStudio était buggué   .

Pauvre IA, si t'as pas arrêté de la harceler en affirmant qu'un truc est buggué tu sais bien qu'à la fin elle va toujours chercher à te faire plaisir et te confirmer que t'as raison .

llama.cpp. FTW
Perso j'aime bien avoir mes config dans des fichiers .bat et j'y ajoute des commentaires et autres tunings.
 
 
NVidia NVFP4 vs llama.cpp Q4: Faster Local LLMs But At What Quality?
https://www.youtube.com/watch?v=5daRawqNpaE
 
(il est sur Ollama)
Intéressant de voir un gain en perf coté NVFP4 pour une taille similaire, mais moi je suis en Q6 en ce moment ...
Surprennant de savoir que le format NVFP4 marche aussi avec MLX!

 
J'essaye de faire une jolie config .
D'ailleurs le web UI de llama.cpp supporte des tools maintenant, une fois que ma config (re)marchera bien, je vais lui demander de se documenter lui même

Documentation : Configuration llama-server en mode cluster
 
Commande de lancement :

 
Commande de lancement server RPC:

 
Détail des paramètres :
 

• --no-mmap : Désactive le mappage mémoire (mmap) pour le chargement du modèle. Évite les conflits de RAM/VRAM et force le chargement en VRAM uniquement.
• --flash-attn on : Active l'attention flash pour accélérer l'inférence et optimiser l'utilisation de la VRAM.
• --alias default : Nom de référence du modèle, pas besoin de changer la config coté client quand on change de modèle.
• --host 0.0.0.0 : Bind sur toutes les interfaces réseau. Rend le serveur accessible depuis le LAN.
• --rpc 192.168.0.40:50000 : Endpoint RPC pour le routage MoE distribué, la synchronisation d'état ou la communication inter-nœuds.
• --port 8080 : Port TCP d'écoute du serveur HTTP/OpenAI-compatible.
• --jinja : Active le moteur Jinja2 pour le rendu des templates de conversation (nécessaire pour les templates complexes).
• -m ... : Chemin absolu vers le fichier modèle GGUF (Qwen3.6-35B-A3B-UD-Q6_K).
• -ngl 99 : Nombre maximal de couches à décharger sur le(s) GPU. 99 force le déchargement de toutes les couches disponibles.
• -ts 20,21 : Répartition des tenseurs (tensor split) sur les GPUs. Exemple : 20 couches sur le GPU rpc0, 21 sur le GPU CUDA 1.
• --n-cpu-moe 0 : Désactive les workers CPU pour les couches MoE. Le traitement est entièrement délégué aux GPU.
• --ctx-size 131072 : Taille du contexte en tokens (128K tokens).
• --temp 0.6 : Température. 0.6 offre un bon compromis entre créativité et cohérence.
• --top-p 0.95 : Échantillonnage par noyau (nucleus sampling). Conserve les tokens dont la probabilité cumulée atteint 95%.
• --min-p 0.0 : Seuil min-p désactivé (aucun filtre par probabilité minimale).
• --top-k 20 : Limite l'échantillonnage aux 20 tokens les plus probables à chaque étape.
• --presence-penalty 0.0 : Pénalité de présence désactivée (le modèle n'est pas pénalisé pour avoir déjà utilisé un token).
• --repeat_penalty 1.0 : Pénalité de répétition désactivée (valeur par défaut).
• --chat-template-kwargs ... : Arguments JSON passés au template de conversation. preserve_thinking: true conserve les balises <think>...</think> pour les modèles entraînés avec des phases de raisonnement explicite.
• -ctk q8_0 -ctv q8_0 : Quantification du cache KV (Key/Value) en format q8_0. Réduit significativement l'empreinte mémoire du cache tout en préservant la qualité de génération.

Notes & Recommandations :
Cette configuration est optimisée pour un environnement multi-GPU (répartition via -ts 20,21).
Le cache KV quantifié (q8_0) est essentiel pour maintenir un contexte de 128K tokens sans saturer la VRAM.
 
Mettre un auto restart sur le server RPC; il crash si on envoie trop de layers avec -ts.
 
Avec cette config je suis a plus de 40 tg/s avec une 4060Ti 16GB et une BC250.

nickel merci !

Une des limitations actuelles est que l’exécution des layers est séquentielle, plus on a de cartes plus c'est lent. Llama.cpp a une option "--split-mode" pour split les modèles par "row" (deprecated) ou "tensors" (CUDA), et exécuter en parallèle mais aucune des deux ne fonctionne pour moi, je pense que c'est a cause de mon mix CUDA/Vulkan.
 
J'ai prévu de regarder vLLM, mais j'ai peu de chance que ça marche. J'ai Windows d'un coté qui n'est supporté que dans un fork et ROCm de l'autre qui ne supporte la BC250 que partiellement.

pourquoi pas une VM Linux via hyperV (avec GPU passthrough) ou wsl2 avec windowc 11 pro (pas du vrai passthrough mais cuda fonctionne quand même
 
Ca ne règle que la moitié du problème mais tu peux focuser ton action sur le BC250 avec ça

C'est un Windows Server 2019 (via esxi8), donc pas de WSL il me semble et je pense pas pouvoir mettre hyperV en plus a cause du passthrough dans l'esxi8.
 
Je pense que https://github.com/SystemPanic/vllm-windows doit bien marcher avec CUDA, j'ai plus de doutes avec la BC250

ah bah une VM linux avec ESXi et GPU passthrough je savais pas que tu avais ta carte Nvidia sur un hyperviseur déjà
 
C'est aussi ta machine de jeu vidéo il me semble ? elle est à distance par rapport à ton bureau ou tu voulais ESXi pour d'autres raisons ?

C'est un serveur ESXi avec 5/6 VMs qui est dans mon sous-sol. Ma VM Windows a le GPU, il est utilisé aussi pour d'autres trucs genre Jellyfin, Tdarr et d'autre bidouilles genre ComfyUI ou d'autre trucs IA du moment. Elle sert aussi de NAS. Je voulais aussi faire du Steam cast et retirer mon HTPC de jeu, mais ça marche pas bien.
 
Ça fait un moment que j'ai cette config migrée de machine en machine, j'ai encore une VM Windows Server 2003 qui tourne dessus . Je voudrais bouger sur Proxmox, mais trop la flemme pour le moment.

Pour du passthrough il faut un iGP car le GPU deviendra exclusif à la VM...
 
Édit : sauf si ça a changé depuis...

 
C'est pas un soucis pour ESXi, j'ai pas d'iGPU. L'écran se désactive quand le GPU est assigné a la VM, et une fois que Windows le réinitialise la sortie écran affiche le bureau Windows. Pour hyperV je sais pas par contre.

Test de vLLM ...
https://github.com/SystemPanic/vllm-windows
 
Comme d'hab' avec les trucs en python, grosse galère pour les dépendances, en fait il faut (entre autres) Cuda 13.0 et 13.2 et patcher l'install de Cuda ...
 
 
Finalement ça se lance avec un modèle en carton  
 
Test de Qwen3.5-27B-Q3_K_M.gguf qui devrait tenir dans 16GB de VRAM:

 

 
Et dire qu'au taf' ya un mec qui me saoule en disant que vLLM est plus simple et plus rapide que llama.cpp ...