Reprise du message précédent :

 
Au contraire le SLI est très utile pour l'IA, ça te permet d'avoir une BP bien plus élevée que le bus PCIe.  
Si tu mets tes cartes en split-mode=tensor tu pourrais avoir un bon gain en PP et TG.
 
Après c'est la théorie, je sais pas trop ce que ça donne, surtout avec des 1080.

 
La HBM n'a aucun intérêt pour replacer de la DDR (ou de la GDDR), la latence est beaucoup trop élevée, elle coûte plus chère et le gain en BP est inutile.

 
 
Gemini en Mode Pro réflexion étendu dit ceci: https://share.gemini.google/Kdg1UGscEoBJ
 
Génération,Latence typique (estimée),Bande passante (par puce/pile),Architecture du Bus
HBM1,~30 ns,128 Go/s,1024-bit (Très large)
HBM2 / 2E,~32 - 34 ns,256 à 460 Go/s,1024-bit
HBM3 / 3E,~35 ns,819 à 1 200 Go/s,1024-bit
HBM4 (2026+),~36 ns,1 500 à 2 000+ Go/s,2048-bit
,,,
GDDR5,~45 ns,32 Go/s,32-bit (Étroit)
GDDR5X,~48 ns,40 à 56 Go/s,32-bit
GDDR6,~52 ns,56 à 72 Go/s,32-bit
GDDR6X,~55 ns,76 à 94 Go/s,32-bit
GDDR7,~50 ns,112 à 128 Go/s,32-bit
 
Pour comprendre la latence de ces différentes mémoires, il faut d'abord saisir la différence fondamentale de conception entre la famille HBM et la famille GDDR.
 
HBM (High Bandwidth Memory) : C'est une autoroute extrêmement large (jusqu'à 2048 voies) avec une limite de vitesse modérée.
GDDR (Graphics Double Data Rate) : C'est une route très étroite (32 voies par puce) mais avec une limite de vitesse colossale.
 
La latence absolue (le temps physique réel mesuré en nanosecondes entre une requête du processeur et l'arrivée des données) dépend des cellules de mémoire (DRAM), de la distance physique, et du temps de traitement du signal (contrôleur et correction d'erreurs).
 
 HBM : Une latence structurellement plus basse
 
La famille HBM (de la HBM1 à la future HBM4) maintient une latence absolue très basse et stable, généralement comprise entre 30 et 40 nanosecondes (ns).
 
Cela s'explique principalement par son intégration physique :
 
1. Proximité extrême : La mémoire HBM est empilée en 3D et placée sur le même interposer (substrat de silicium) que le processeur graphique (GPU). La distance électrique n'est que de quelques centaines de micromètres (contre plusieurs centimètres pour la GDDR).
2. Fréquences basses : Parce que le bus est immense grâce aux connexions verticales TSV (*Through-Silicon Vias*), la mémoire n'a pas besoin de tourner à des fréquences extrêmes pour fournir une bande passante massive. Cela simplifie grandement le travail du contrôleur mémoire et réduit le temps de traitement.
 
GDDR : Le prix de la fréquence
 
Les mémoires GDDR ont une latence absolue plus élevée, qui se situe généralement entre 40 et 60 nanosecondes (ns).
 
Paradoxalement, à mesure que les générations avancent et que la bande passante explose, la latence n'a pas diminué de manière drastique. Elle a même eu tendance à légèrement augmenter à cause de la complexité du signal :
 
GDDR5 et GDDR5X (~45 à 50 ns) : La latence était gérée par des fréquences très élevées mais des signaux électriques relativement simples (NRZ - Non-Return-to-Zero).
GDDR6 et GDDR6X (~50 à 60 ns) : Pour atteindre des vitesses extrêmes (jusqu'à 24 Gbps par broche), ces mémoires utilisent des encodages complexes. La GDDR6X, développée par Micron et NVIDIA, introduit le signal PAM4 (qui transmet 2 bits par cycle). Coder, décoder et vérifier les erreurs (CRC) de ce signal à travers les pistes d'un circuit imprimé ajoute un léger surcoût de temps de traitement.
GDDR7 (~45 à 55 ns) : La nouvelle norme utilise un signal PAM3. Bien qu'elle double la bande passante par rapport à la GDDR6, les optimisations du contrôleur et de l'architecture permettent de maintenir, voire de réduire très légèrement, la latence par rapport à la GDDR6X.
 
---
 
 Le cas de la "GDDR7X"
 
La GDDR7X n'existe pas à l'heure actuelle.
La désignation "X" (comme pour la GDDR5X et la GDDR6X) était historiquement utilisée pour marquer des collaborations spécifiques (souvent entre Micron et NVIDIA) visant à devancer les standards officiels du JEDEC. La norme officielle GDDR7 ayant déjà intégré nativement des technologies très avancées comme le PAM3 pour atteindre 32 Gbps par broche, une déclinaison "7X" n'est ni standardisée ni officiellement annoncée à ce jour.
 
---
 
Comparatif : Latence vs Bande Passante
 
Voici comment ces générations se positionnent en termes de compromis entre la latence typique estimée et la bande passante maximale délivrée par puce (pour la GDDR) ou par pile (pour la HBM) :
 
| Génération | Latence typique (estimée) | Bande passante (par puce/pile) | Architecture du Bus |
| --- | --- | --- | --- |
| HBM1 | ~30 ns | 128 Go/s | 1024-bit (Très large) |
| HBM2 / 2E | ~32 - 34 ns | 256 à 460 Go/s | 1024-bit |
| HBM3 / 3E | ~35 ns | 819 à 1 200 Go/s | 1024-bit |
| HBM4 (2026+) | ~36 ns | 1 500 à 2 000+ Go/s | 2048-bit |
|  |  |  |  |
| GDDR5 | ~45 ns | 32 Go/s | 32-bit (Étroit) |
| GDDR5X | ~48 ns | 40 à 56 Go/s | 32-bit |
| GDDR6 | ~52 ns | 56 à 72 Go/s | 32-bit |
| GDDR6X | ~55 ns | 76 à 94 Go/s | 32-bit |
| GDDR7 | ~50 ns | 112 à 128 Go/s | 32-bit |
 
(Note : La latence de bout en bout dépend toujours de l'architecture spécifique du contrôleur mémoire du processeur, des timings exacts et des fréquences appliquées, mais l'écart structurel entre HBM et GDDR reste constant).
 
 
 
Donc je pense que le cout prohibitif de la HBM interdit ou limite fortement l'utilisation de HBM3 ou de HBM4 et ses variantes, mais la latence n'est clairement pas un problème, c'est surtout que c'est horriblement cher à produire et donc à acheter.

c'est ce que j'utilisais mais j'avais lu pas mal de tests où le n max à 3 était le sweet spot.
faut que je teste tout ça

et tout ça pour le double du prix actuel

Mac studio ultra  

 
Clairement ça ne me dérange pas de payer un frontier en cloud pour de 20 à 100 balles par mois.
 
Mais quand tu commences à exploser des quotas, te retrouver bloqué sur des API pour faire tourner tes agents, devoir raquer encore xx euros pour faire des images / vidéos qui tiennent la route, ça commence à faire chier.  
 

Oui et puis quand tu es coincé avec des fournisseurs dont le modèle économique est extrêmement déficitaire tu sais que ça attend que la concurrence se tarisse avant de t'allumer pour récupérer la mise.  
 
Pour ça les avancées de Qwen sont quand même assez dingues (diminution des coûts d'entrainement par 9, changement d'architecture pour faciliter l’hébergement sur une infrastructure en tiers VRAM / RAM / NVME ). Au global on prend quand même une sacrée leçon par rapport à d'habitude où les boites de la tech américaine survolent sans effort particulier le domaine

Je teste Qwent Next en IQ4_ZS avec 65k de contexte:
https://huggingface.co/AtomicChat/Q [...] -Next-GGUF
 
Par contre il faut que je repense ma gestion de mémoire avec Qwen4:

 
Avant "CPU_Mapped model" c'était ce qui serait pris en RAM avec les MoE mais maintenant, on dirait que c'est juste les ngram. Vulkan_Host C'est le MoE, donc (encore) plus difficile de prédire la répartition mémoire.
Je tiens les 9.5 tg/s pour le moment.

 
Comme c'est partis ils vont nous faire tourner Qwen4 35B sur un téléphone
 

 
Qwen 3.8 Flash Next locally on simple mobile phone at 3.5 tok/s
https://www.reddit.com/r/LocalLLaMA [...] ile_phone/
 
https://github.com/Helldez/BigMoeOnEdge
 
Pas testé

Je vous présente mon nouvel agent swarm.
 

 
Le nouveau prix des smartphones dans un mois

Mon calcul du moment :
 
Un Studio M5 Max 18c CPU / 40c GPU / 64Go ram / 512 Go SSD c'est le sweet spot je pense  
4000 balles mais ça se revend 2000 disons dans 3 ans.
 
Ça ne coûte donc que réellement 56 euros par mois    
Et au tarif edu ça fait 49 euros par mois (achat à 3750 euros).
 
Est-ce que ça reste cher ? Oui.  
Est-ce que c'est hors de prix ? Non.
 
Voilà    
 

Déconne pas mets lui au moins 1TB de stockage. Ca pèse tous ces modèles  

NVME SSD en TB?
 
300 balles pour 512go de plus quand même
 
Mais oui c'est peanuts sur l'ensemble

Si la nouvelle archi de Qwen est efficace et est massivement adoptée par les autres tu me remerciera parce que c'est pas non plus tes 64GO qui vont permettre de tout mettre en RAM

 
Pas compris

Faut aussi prendre 128 go de ram  

y'a depuis quelques mois un mouvement vers une architecture en étage :  
1 la partie routage entre experts en VRAM
2 La partie chaude des experts en RAM (les deux sont unifiés sur ton futur Mac Studio)
3 la partie plus froide (experts peu utilisés genre les compétences en macramé pour une tâche de développement) en SSD
 
Avec 512GB tu vas pleurer. Le sweetspot est probablement à 2tb mais vu que la puce flash est vendu au poids de l'or par Apple

 
Tu rigoles, mais une seule colonne de S26 ça serait 84 GB de LPDDR5X, 1TB pour un panel complet. 8TB visibles sur la photo

Ouais donc un strix halo avec une carte 20-32gb en usb4 et roulez jeunesse alors pour qwen 4 preview flash next 120B ,

c'est quasi ça ouais
 

Le 128Go est trop proche du Ultra 96Go.
Donc autant prendre le Ultra

2x plus bande passante RAM
96Go de RAM donc de la place pour des agents avec beaucoup de contexte (avec 2 users en //)
1To SSD
+50% de CPU / +50% GPU

On commence à causer

Ça revient à 81 euros par mois (achat @edu store à 6200, revente à 3300 - 50% du prix public, amortissement 36 mois)  

Flappy bird
Qwen3.8-Flash-Next-AD-3.84bpw-IQ4_XS-M64
https://dochost.co/d/qbc2aq6i?v=c
 

J'ai un serveur avec une paire de xeon gold 6138 (skylake, deux unites avx 512 par cpu), je me doute que c'est pas rapide pour faire tourner un llm, mais je peux avoir 384Go de ram.
 
Ca peut se tenter pour faire tourner un gros gros modèle ?

Entre 37 et 40tk/s, je vais tester ça quelques jours pour voir si ça a un effet sur le code généré.

 
Il y a ik_llama qui est dédié au CPU, il supporte les gros modèles:
https://github.com/ikawrakow/ik_llama.cpp
 
Sinon Colibri
https://github.com/JustVugg/colibri
 
Par contre coté perfs, ça risque de piquer fort. Pour schématiser, ta config a 40 cores / 80 threads, une RTX 3060 en a 3584.
 
Donc si tu as le matos et que tu vas pas dépenser d'argent, ça se tente, je suis curieux du résultat!
 

 
Belle progression

 
Je me doute que les perfs vont être pas folles, mais en effet j'ai le matos donc il faut juste que je le sorte du garde meuble et que je le branche.
 
Je viendrais raconter ce que ça donne, je me dis qu'à défaut de rapidité, je n'aurais pas d'out of memory avec un gros contexte.

On peut faire quoi sur un macbook air M3/24Go ? C'est interessant ?  
Et sur une 3090 24Go aussi du coup ?  
Un Qwen 27B ca peut tourner sur l'un/l'autre ?

 
Tu mets les deux en RPC avec llama.cpp et tu es le roi du pétrole

un modèle 16GO passe dessus. C'est pas parfait (idéalement tu voudrais 64GO pour que ça respire avec de plus gros modèles voir 48GO) mais y'a pire
la 3090 me semble plus intéressante (tu peux utiliser les 24GO pour ton modèle et ce sera plus rapide en prime)

Donc du coup, si j'investis dans une carte 32GB, avec le bc-250 et sa carte de 16GB, en RPC je fais tourner qwen 3.8 next Flash next épouse alors

Tres tres dur de trouver un mac en > de 24Go a des prix pas stratosphériques (32 jai rien trouvé a moins de 1400€ grand minimum)
Et le GPU, cest le meilleur rapport ram/prix je crois, plus que ca j'ai pas comment justifier

Et je sais pas comment mettre les deux en RPC, la 3090 est sur un fixe windows 5900X/32Go

Moi je te conseille de démarrer sur la 3090 et si tu accroches bien peut être acheter un bsc250 en parallèle ou une seconde 3090 (avec le nvlink )

Pour la deuxieme 3090 cest pas demain la veille, deja faut adapter boitier/alim/carte mere, acheter le gpu... le BC250 faudra voir les avantages qu'il m'apporte

 
Le PP est pas top quand même, j’arrive péniblement a 50/s.

 
Par le réseau
 
ggml-rpc-server -p 5000 d'un coté
llama-server -rpc host:5000 de l'autre
 
Ca cumule la VRAM des deux hosts.

Purée cest possible ca ! folie !  
Et ca permets d'utiliser des modeles de fou ?  
quoi comme modeles en 24 et quoi en RPC ? (je sais qu'il yen a des dizaines, mais je parle des plus connus, surtout qwen 3.8)

 
Ben regarde mes posts
J'ai une 4060Ti 16GB et deux BC250 soit 44GB de VRAM en gros et je viens de charger Qwen next

Merci. Mais... pi.dev a du mal à debugger mon projet avec un contexte de 32k. Je suis obligé de monter à 45k, et n'avoir que 30tk/s, pour avoir un agent plus compétent. A explorer plus - peut-être un pb dans ma config de pi.dev, qui compresse le contexte trop vite ou mal... Mais je monte rapidement à 64% d'utilisation du contexte.

 
J'ai deux bc250 mais en load balancing ...  

Medusa halo en 2027 pfft.

Ecoutez l'oracle et attendez un an les gars