Reprise du message précédent :

 
Tu as combien de context dispo sur 16GB ?  

Contexte 100k, mais il reste de la VRAM dispo. J'ai pu re activer l'accélération hardware de Firefox.
 
Dans l'onglet Community (47 commentaires), qq1 propose une ligne de commande avec MTP 3 et contexte 128k.

 
J'ai testé ya un moment, mais au bout d'un moment j'avais une boucle et il générait plus que des ///////////
J'ai eu le même soucis avec sa version de Qwen Flash Next.

y'a un modèle "chouchou" sur une carte avec 8GB de VRAM ?  
 
j'ai mon laptop de gaming qui fou rien (enfants en bas âge tout ça   ) avec un 12700 / 32GB ddr5 et une 3070ti (de laptop) qui pourrait peut être faire tourner du tooling ou une sous routine si y'a un p'tit modèle qui peut fonctionner dessus
 
usages en tête :
=> chat avec l'utilisateur quand le Strix Halo chauffe sur une autre tâche (avec des droits de lecture des fichiers des sessions en cours). Il faut que tout tienne en vram
=> résumé d'articles de sites web pour un morning briefing (osef de la vitesse la qualité prime un peu)
=> soyons fous : revue de code avec OCR histoire de mettre le bordel au strix halo avec un modele inférieur qui hallucine pleine balle ou avec gros modèle lent en dépannage ?

Pas eu ce pb. Je fais tourner pi avec deux plug-ins empêchant les boucles (installé quand un précédent modèle Qwen tournait en rond à lire un fichier puis un autre puis.. puis re le premier...).

EDIT - les plugins que j'utilise dans pi :

Une petite machine qui sert que pour l'ocr c'est pas mal.
Quand j'ai des gros batch j'ai une des bc250 qui sert que a ça dans le workflow.
Sinon le dernier qwen image 2.1 j'ai vus des models en 4gb passer

 
Un Qwen 35B?  
 

 
J'avais ça avec little-coder, mais au final quand ton modèle part en couille, ça sert a rien ce genre de trucs, c'est que ton contexte est pourris et il reviendra pas dans la bonne direction.
 
Après j'ai ce soucis quand le prompt tourne longtemps, genre 20h+. Mais je trouve que c'est une bonne indication qu'il y a un soucis a long terme.

j'ai eu 10h+ de génération avec le gsq rco 27B et à la limite, ce que je peux lui reprocher, c'est plus la qualité du raisonnement (enfin, ça, je l'ai vu dans le doc de sortie...)
j'avais laissé le thinking "ON" mais j'étais passé en température 0.7, en temp = 1 je trouve qu'il tourne trop facilement en rond.

edit: j'ai retesté rapido hier soir un UD3 d'unsloth avec un llama.cpp récent (dernière ou avant dernière release) mais j'ai du me chier la config, il charge mais au 1er message, le modèle crash et se vide de la VRAM.

 
 
Version du moteur de LLama.cpp de LMSTUDIO est actuellement:
 

Vulkan llama.cpp (Windows): v2.44.0
 
Vulkan accelerated llama.cpp engine
 
- llama.cpp release b11139 (commit 42916d83f)

 
 

 
 
b11139 ça doit correspondre à celle-ci: https://github.com/ggml-org/llama.c [...] ase-b11139
github-actions released this 20 hours ago
 
Donc 20 heures c'est antédiluvien, d'accord !!!!

Les vrais tournent avec un fork personnalisé

 
Ya des flags qui ont changés, t'as quoi comme erreur?
 

 
 
Il n'y a pas de build "llama.cpp-win-x86_64-vulkan-avx2" et LMSTUDIO est closed source (pas tout, mais le UI/moteur n'est pas dispo). LMSTUDIO a son propre build de llama.cpp et il ne correspond pas aux sources officielles. UD3 a été ajouté il y a plus d'un mois, ça devrait marcher depuis le temps.
 
moyen_moins n'est pas le premier a avoir des soucis avec LMSTUDIO, en tout cas chez moi ça marche

 
Je suis en train de bosser la dessus

Donc sinon quel modele MoE je dois utiliser sur du cpu avec 192Go et 384Go ? Parce que l'ia me sort des trucs qui ne passent pas ou chargent plus de ram que "prévu"
 
avec llama.cpp bien sur, je ne vois pas l'intérêt de mettre autre chose pour ce que ça va faire

je regarderai ça demain, je passe par un gui pour config tout ça

j'avoue ça commence un peu à me souler mais en 1er pas en local, ça reste très pratique
et faut que je vérifie si llamaserver fonctionne en local sur mon poc : d'une pierre 2 coups.

 
Utilise ik_llama.cpp, pas llama.cpp.
 
Un 35B devrait passer, mais peut être un DS4 ou Qwen 3.8 Next pour le fun

j'avais fait ça sur le bc-250 (enfin, pas moi, l'ia l'avait fait pour moi)

les performances avec ce ik_llama sont réellement supérieures ?

 
Moi je veux ça:
RPC: add -sm tensor
https://github.com/ggml-org/llama.cpp/pull/26610
 

 
Je sais pas, mais en tout cas c'est écris dans le titre!
Le fait que le fork ait plus de 2 ans et soit toujours actif me fait penser que c'est pas juste un vibeslop
 
Sinon ya aussi https://github.com/JustVugg/colibri a regarder

pas sûr de tout comprendre
c'est pour remplacer le split ? pour que ça tourne en // et pas en série (ou un truc comme ça) ?

 
Oui c'est ça. Le mode RPC envoie un nombre de layers au premier nœud RPC, un autre au second, ... et a la fin le reste au server avec l'attention et les MoE. Tout se fait séquentiellement par batch (le ubatch). A un moment T il n'y a qu'nœud qui bosse (en PP) le TG est en parallèle il me semble.
 
Avec le mode tensor les layers sont slicés "verticalement" et tout peut se faire en parallèle. Le problème c'est qu'au d'envoyer une requête avec un seul batch, tu en envoie des tonnes et la latence est importante, il est conseillé d'utiliser RDMA.
 
Mais je me demande si dans mon cas, je gagnerais pas en vitesse de PP, je suis autour de 70/s avec Qwen4 . Je me demande aussi si la répartition serait pas plus facile, avec certains split j'ai que 10GB sur une carte et l'autre se bouffe 15GB.

Qwen4 et tu partages pas avec le tôlier ?

 
OK mais tu le gardes pour toi:
https://tinyurl.com/bdfmwxdx
 

Ou alors https://huggingface.co/unsloth/Qwen [...] /tree/main

pi qui vibecode tout seul la visu des metrics des endpoints....  

Bon finalement :

• Qwen3.8-27B-GSQ-RCO-IQ3_S-mtp a en effet des pbs; même si mon modèle ne se bloque pas dans une boucle infinie; mais les compaction de contexte finissent par toujours foirer, impossible de le faire travailler longtemps
• Qwen3.8-27B-Uncensored-IQ4_XS_4BPW est une valeur sure; par contre contexte de 50k seulement, certains appels d'outils nécessitent plus et vont foirer.
• Qwen3.8-27B-4.2BPW-16GB est mon préféré pour l'instant : ses couches de connaissance sont plus compressées, mais ses couches de logique restent similaires à Uncensored-IQ4_XS. Ce qui permet d'avoir un contexte de 120k.

Par contre si je pousse trop le contexte, ne gardant que quelques centaines de mb de VRAM libre, l'affichage de mon PC refuse parfois de sortir de veille - VRAM libre probablement trop fragmentée. Le LLM continue de bosser, mais sans affichage.

Tu n’as pas un chipset vidéo basique sur la carte mère ou tu pourrais en ajouter un pour libérer totalement ta vram ? Je suis pas certain que ça vaille la peine d’aller chercher 50 mo mais si tu veux maximiser ta VRAM …

Non. Et je préfère n'utiliser que mon GPU - pour le jeu, la VR, le dév de mon moteur 3D; et juste plus simple. Je baisserai le contexte size à 110k.
Mon contexte est déjà limité à 100k dans ma config pi.dev - je lui laisse une marge car parfois il dépasse sa limite en lançant d'autres outils (ça évite de les relancer après le compactage).

c'est là qu'on voit qu'il faut mini 24Go de VRAM.
à moins, ça devient compliquer de faire des trucs "ambitieux"

Bah je viens de dire que Qwen3.8-27B-4.2BPW-16GB passe très bien sur 16gb.
Par contre 3.8-Next / 4.0, ça va être plus que chaud...

 
En fait il a juste renommé l'ancien IQ3_M d'Unsloth, il s'en même pas fait chié a changer les metadata:
 
https://huggingface.co/hitsfmdj/Qwe [...] -16GB.gguf

 
Et c'est pas 4.2BPW:
https://huggingface.co/hitsfmdj/Qwe [...] ation.json

Oooh bien vu.

100k de contexte, ça peut être vite explosé et les compactions...

Ya un truc que je comprenais pas avec llama.cpp. Je me fais chier a faire une config aux petit oignons, pour charger Qwen3.8-Flash-Next en UD-IQ3_XXS avec RPC, ça passe au poil de cul, j'ai des layers en CPU, OK.
 
Je fais la même avec juste -fit on, et pouf il me dit qu'il mets tout en GPU. J'avais des OOM avec UD-IQ4_XS jamais réussi a le charger, la pareil, avec -fit on ça passe...
   
 

 
Et il donne ça:

 
Mais en réalité on a la vrai répartition des layers avant:

 
Donc 11 sur RPC0, 10 sur RPC1, 8 sur Vulkan0 et 20 en CPU! La j'ai 24GB de RAM pris sur 32GB.
 
Je lui ai demandé de faire un clone de Celeste pour changer, je suis un peu au dessus de 5/s en TG:

 
Bref c'était l'info inutile du dredi

Bordel  
 
Qwen Next s'est mis a faire des /////////
 
J'ai oublié de pin la version de Mesa sur ma nouvelle VM Linux. Donc si ça se trouve les quants RCO marchaient bien, c'était peut être le bug Mesa
 
Pour info Mesa 26.1.5-1 marche bien, et j'avais des soucis avec 26.2.
 
edit: encore pire, j'ai des /// tout de suite, étrange, peut être un soucis avec llama.cpp

Fichier corrompu

J'ai DL avec le cli HF, il est censé vérifier les hashs. Mais je vais tester un autre quant pour voir.

En tout cas, Qwen3.8-27B-4.2BPW-16GB reste mon favori parmi ceux que j'ai testé : il vient de me créer, puis implémenté, un gros refactoring en 17 étapes sur plusieurs heures. Et ça fonctionne. Content de la qualité et de la vitesse d'exécution sur 5060 Ti 16gb.
Si je suis bien, un Q3 par Unsloth (ou Q3++ si 4.2BPW-16GB est amélioré depuis IQ3_M) donnerait environ 96% de "l'intelligence" du modèle de base, vs 98% pour un Q4 ?

J'ai reçu l'adaptateur occulink.
Je reteste le bc-250 ce weekend.

Allez on est tous derrière toi