Reprise du message précédent :
Stop le HS
 
J'ai testé le speculative checkpointing dans llama.cpp:
https://github.com/ggml-org/llama.cpp/pull/19493
 
Aucun benef avec Qwen3.6, voir pire. Je vois que quelqu'un a posté une config différente, je verrais ce soit si j'oublie pas.

Ok bon à savoir

 
Avec cette config je vois pas de différence. Par contre je viens d'avoir le meilleur Flappy Bird que j'ai jamais eu jusqu’à présent!
 

 
https://hashed-hainanese-362n.pagedrop.io
 
Me config:

J'arrive même pas a passer le premier tube
 
Très propre, surtout pour un model local
 
J'essaye de modifier le bios pour activer un semblant de fastboot sur le bios de la bc250

fastboot? elle doit booter en 3s chrono
 
Pour la science, le flappy bird de Opus 4.7:
https://petite-trend-7yq4.pagedrop.io
 

Les bruitages de l'enfer

Les futurs artisans

https://youtube.com/shorts/gR-765jj7G0

 
Y a bien les offsets pour mais impossible de l'activer via la nvram, je tenterais un autre jours en modifiant directement le bios sur l'eeprom avec un prog externe.
Pour le moment ca stagne a 24s entre le bouton ON et l'arrivée sur le shell  

 
T'as viré le netboot? Ça prends des plombes.
T'as quoi comme distrib?
 
A oui, tu as raison:

 
Je reboot pas souvent depuis que j'ai mes bon settings grub.

Tss tsss on se reconcentre sur l'Amiga siouplé  

 
ça tourne Mais il faut que je bouge un peu les projets, la il test avec Qemu 68k, mais il faut que je le mette a bosser sur le bootloader et a utiliser fs-uae.

GPT 5.3 codex et GPT 5.4 vous disiez ici c'est pareil mais moins cher avec GPT 5.3 codex?

Ça arrive

j'ai pas

Ils avaient appuyé sur le bouton trop tôt
Ça devrait sortir ce soir ou demain

https://x.com/i/status/2046803980089536718

J'ai mis un fedora server, de base ça bootait en 32s environ, en virant tous les services inutiles et diverses optimisations je suis descendus a 24. Mais le bios a lui seul c'est presque 15s  

Qwen3.6 27B est dispo:
https://qwen.ai/blog?id=qwen3.6-27b
https://huggingface.co/unsloth/Qwen3.6-27B-GGUF
 
J'ai swap le 35B pour Qwen3.6-27B-UD-Q6_K_XL, pas de miracle, j'ai juste 10 tgs et le flappy bird est top :
https://vast-byte-r9eq.pagedrop.io
 

 
Je vais le mettre au boulot sur Linux 7.x pour Amiga 500 pour la nuit.
 
Assez content du speculative decoding finalement, après 24h de boulot, je vois des boosts en tgs a 40 alors que ma moyenne est dans les 30/35. Je vais le laisser avec 27B pour voir.

J'attend le model en APEX  

J'ai jamais réussi a tirer quoi que ce soit d'un APEX.

Agréablement surpris sur le 3.5 donc je me dit qu'on peut l'être également sur le 3.6  

 
Quelle diff avec Unsloth?
Sur Qwen3-coder il y avait des APEX plus petits, mais il faisaient n'importe quoi

Qui c'est qui a brick sa bc250 en bidouillant le bios a coup d'éditeur hexa ?  

Faudrait qu’on concentre toute les annonces sur les modèles sur le topik principal = topik news/twitter

C'est vous qui voyez

Y a tellement d'infos que on ne sait plus où donner de la tête

Qu'est-ce que tu cherchais à faire ?

une extension

 
Bien joué ... d'avoir un CH341 3.3V en rab' enfin j'imagine que t'aurais pas pris le risque sans!
 
Sinon ya un BIOS v5 qui traîne avec des trucs en plus, mais je sais pas ce que ça apporte ou quel est le risque:
https://theretroweb.com/bios?itemsP [...] chipsetIds[]=1990

Activer le fastboot, j'ai cru qu'il etait disponible mais pas activé ( et pas affiché) seulement en modifiant en hexa, j'ai bloqué la carte  
 
Bon en reflashant le bios d'origine puis reflash du custom du wiki bc250 c'est repartis comme en 40.

fastboot c'est pas un truc Windows seulement?

Profitez

27B c'est nul
 
Je suis repassé sur 35B pour la nuit, je pense qu'il a un soucis avec le speculative decoding, il s’arrête tout seul.

 
Je l'ai vus apres avoir commencé a bidouiller le 3.00    
Non j'ai pas utilisé de CH341, le mien est full 5V ( pour certaines vieille cm) , j'ai soudé à l'arrache des pin header sur un rp2040 zero qui traînais dans un tiroir    
 

 
Je voulais dire le "boot rapide" dispo dans certains bios/EFI, ca permet de skip certaines étapes du boot, m'enfin je pense que je vais pas chercher plus... 20 minutes pour reflasher proprement la carte a chaque fois
 
Sinon j'ai continué a jouer avec les optimisations sur la conso, il y a un beau delta entre la 1ere carte peu optimisée avec juste le patch kernel et governor non tuné, et la deuxième ou j'ai poussé au max :  
 

Pour ceux qui sont limités en RAM, il y a des techniques de turboquant qui arrivent et permettent de jouer avec des modèles de taille respectable avec peu de VRAM :  
https://youtu.be/XLlQDfhyBjc?is=KrNWtbzMtYYLNguZ
 
J’ai pas testé personnellement comme les modèles 3.6 / 3.6 plus passent nickel dans 40GB.
 
Je joue d’ailleurs avec une version non officielle 3.6 plus. La partie thinking est assez bluffante de détails et ça améliore bien l’output même avec des prompts de départ assez courts.
 
Je galère à trouver le temps de monter le CI/CD mais j’ai mon cluster K8s dans OCI de prêt (4 cpu et 24 GO de ram gratuits au total pour le cluster. Un peu à mes risques et périls comme j’ai vu des gens se faire avoir sur Reddit et recevoir des factures parce qu’ils avaient activé par accident des produits non gratuits).

J'ai tenté les turboquant, mais comme j'ai une config split CUDA/Vulkan j'ai pas trouvé de fork qui supporte les deux.
 
Après, il faut relativiser les gains annoncés par les "créateurs". La perplexité est aux fraises si tu mets les keys en TQ et souvent les configs sont en q8 pour les keys et tq4 pour les values. Le gain final est pas si énorme pour les modèles Qwen en tout cas, genre 10/15% par rapport a du q8/q8. De plus il y a un coût en décodage et on perds en tokens/s.

https://github.com/usestrix/strix

En fait ça a l’air surtout efficace pour la partie cache ( donc augmenter in fine la fenêtre de contexte max même sur un gpu limite en vram ). La vidéo reprend les résultats sur un bench « qualité » (retrouver les mots cachés dans un texte super long) et si le gpu n’est pas à l’agonie en q8 tu arrives à une perte assez négligeable en performance ( de l’ordre de 10% vs sans turboquant) largement rattrapé par le fait que désormais tout le modèle et son cache peut être hébergé en vram plutôt que décharger une partie sur cpu    
 
Mon impression c’est que, si la qualité ne part pas dans les fraises, on devrait pouvoir tester dans de très bonnes conditions des modèles qui initialement étaient très limités en jetons max par session à cause de leur taille de départ

 
Pour le moment le TQ n'est appliqué qu'au KV, j'ai vu des forks qui essayent de l'appliquer au modèle, mais ça marche juste pas du tout. La vidéo est pas mal pour de la vulgarisation, mais le TQ est très loin d'être au point, ça à l'air d'aller pour quelques tests, mais ya quand même pas mal de retours négatif ou le contexte fini pas être corrompus. Il n'y a pas de fork qui couvre les archis principales a la fois, CUDA, Metal ET Vulkan. Chacun a sa petite popote et la hype semble être passée. Je pense qu'il faudrait qu'une boite s'y mette sérieusement avec pas mal de dev en plus derrière. Bref c'est pas pour tout de suite un merge dans llama.cpp.
 
Si tu veux voir plein de benchs et résultats, c'est la que ça se passe:
https://github.com/ggml-org/llama.cpp/discussions/20969

Même constat de mon côté, plus le fait d'avoir une configuration boiteuse qui exige beaucoup de test pour peu de gain... Je suis repassé sur llama officiel et basta