Comment exécuter GLM-5.2 en local

 (unsloth.ai)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Le nouveau modèle ouvert GLM-5.2 de Z.ai se distingue surtout comme un cas d’usage de très grand modèle manipulable en local, avec 744B de paramètres, 40B de paramètres actifs et une fenêtre de contexte de 1M
  • Unsloth propose une voie d’exécution locale via Dynamic GGUF, et la quantization recommandée en 2-bit UD-IQ2_M exige 239 Go de disque et un environnement avec au minimum environ 245 Go de RAM
  • Le Dynamic 1-bit affiche environ 76,2 % de top-1 accuracy avec une réduction de taille de 86 %, et le Dynamic 2-bit environ 82 % d’accuracy avec une réduction de 84 %, ce qui ne correspond pas à l’interprétation « les performances baissent dans la même proportion que la taille »
  • Deux méthodes d’exécution sont proposées : Unsloth Studio et llama.cpp. Studio permet sur MacOS, Windows et Linux de rechercher, télécharger et exécuter des modèles, avec prise en charge du RAM offloading et de la détection multiGPU
  • Pour utiliser réellement un long contexte, il faut réduire l’usage mémoire avec la quantization du cache KV dans llama.cpp ; q4_0 permet un contexte environ 3,5 fois plus long, et q4_1 environ 3,2 fois plus long

Vue d’ensemble du modèle GLM-5.2

  • GLM-5.2 est le nouveau modèle ouvert de Z.ai, exécutable sur du matériel local via Unsloth Dynamic GGUF
  • Les spécifications du modèle sont les suivantes
    • Paramètres totaux : 744B
    • Paramètres actifs : 40B
    • Fenêtre de contexte maximale : 1,048,576
  • Il est présenté comme offrant des performances SOTA sur le long-horizon coding, le raisonnement et les agentic tasks
  • Selon Artificial Analysis et plusieurs benchmarks, il atteindrait un niveau comparable à Claude 4.8 Opus, GPT-5.5 et Gemini 3.1 Pro
  • Unsloth indique avoir bénéficié d’un day-zero access de la part de Z.ai
  • Les fichiers modèle GGUF pour GLM-5.2 peuvent être téléchargés sur Hugging Face via GLM-5.2-GGUF

Quantization recommandée et besoins mémoire

  • Pour équilibrer accessibilité et précision, l’usage de la quantization dynamique 2-bit UD-IQ2_M est recommandé
    • Espace disque : 239 Go
    • Tient directement dans un Mac à mémoire unifiée de 256 Go
    • Avec MoE offloading, cela fonctionnerait aussi correctement avec 1x24GB GPU + 256GB RAM
  • La quantization 1-bit tient dans 223 Go de RAM, tandis que la 8-bit demande 810 Go de RAM
  • Dans le tableau des exigences matérielles pour l’inférence, la mémoire totale désigne RAM + VRAM ou bien la mémoire unifiée
    • Valeurs totales affichées : 223 Go, 245 Go, 290–360 Go, 372–475 Go, 570 Go, 810 Go
  • Pour obtenir les meilleures performances, la mémoire disponible entre VRAM et RAM système doit dépasser largement la taille du fichier modèle quantifié

Mode Thinking et paramètres d’échantillonnage

  • GLM-5.2 propose 3 thinking modes
    • non-thinking
    • thinking High
    • thinking Max
  • Pour les tâches complexes, l’usage de Max Thinking est recommandé
  • Dans Unsloth Studio, l’interface permet d’activer ou désactiver High/Max Thinking et le mode non-Thinking
  • Les réglages recommandés pour la plupart des usages sont les suivants
    • temperature = 1.0
    • top_p = 0.95
    • Dans les autres modes, top_p = 1.0
  • GLM-5.2 utilise le raisonnement par défaut, et reasoning_effort peut être réglé sur "high", "max" ou désactivé
  • Exemple de désactivation du thinking
    • Shell classique : --chat-template-kwargs '{"enable_thinking":false}'
    • Windows PowerShell : --chat-template-kwargs "{\"enable_thinking\":false}"
  • Dans llama.cpp, on peut aussi utiliser --reasoning on ou --reasoning off
  • Exemples de réglage du reasoning effort
    • --chat-template-kwargs '{"reasoning_effort":"max"}'
    • --chat-template-kwargs '{"reasoning_effort":"high"}'
    • --chat-template-kwargs '{"enable_thinking":false}'

Précision de Dynamic GGUF et interprétation du KLD

  • Unsloth utilise le benchmark KLD (KL Divergence) pour évaluer la précision de la quantization GLM-5.2-GGUF
  • Dynamic 4-bit UD-Q4_K_XL et Dynamic 5-bit UD-Q5_K_XL sont présentés comme généralement lossless
  • Même les quantizations plus petites fonctionnent via une allocation dynamique de précision, où les couches importantes restent en précision plus élevée et les moins importantes en peu de bits
  • Les chiffres en pure top-1% accuracy sont les suivants
    • Dynamic 1-bit : environ 76,2 % accuracy, réduction de taille de 86 %
    • Dynamic 2-bit : environ 82 % accuracy, réduction de taille de 84 %
    • Comparaison d’accuracy : {b:76,82}
  • Dire qu’un modèle est 86 % plus petit ne signifie pas qu’il est 86 % moins bon ; pour le Dynamic 1-bit, l’interprétation donnée est une précision d’environ 24 % inférieure au modèle complet de 1,5 To
  • « 76 % accuracy » ne signifie pas que pour une question comme « The capital of France is », le modèle choisirait Paris à 76 % et Sydney à 24 %
    • Dans cet exemple, Paris serait toujours à 100 % et Sydney à 0 %
    • Le chiffre de 76 % inclut aussi les changements de distribution sur l’ensemble du corpus, y compris les filler words et stop words
  • Pour un prompt comme « Create a novel », où plusieurs débuts peuvent être corrects, la distribution de tokens du modèle de base et du modèle quantifié peut diverger
    • Le modèle de base peut choisir [I] à 100 %, tandis que le modèle quantifié répartit par exemple [I] 76 % et [The] 24 %
    • Cela ne signifie pas qu’il produira du charabia ou une sortie incorrecte avec 24 % de probabilité
  • Le KLD correspond à la distance entre les probabilités de la baseline BF16 ou Q8_0 et celles de la version quantifiée
    • L’objectif de la quantization est de minimiser la moyenne de la divergence KL entre f(q(W)) et f(W)
    • f désigne le forward du language model, q l’opération de quantization et W les paramètres ou weights du modèle
    • Un KLD de 0 signifie que le modèle a été parfaitement reconstruit
  • Exécuter le KLD sur l’intégralité d’un corpus d’entraînement de 15T tokens serait trop coûteux ; Unsloth optimise donc avec une moyenne de KLD et un petit representative subset sampling
  • Un KLD à 99,9 % est aussi jugé généralement bon, et à partir du 4-bit le gain supplémentaire devient plus important, ce qui ferait probablement du Dynamic 4-bit le meilleur choix pour des massive out-of-distribution tasks

Exécution avec Unsloth Studio

  • Unsloth Studio est une web UI open source pour l’IA locale et prend en charge l’exécution de GLM-5.2
  • Principales fonctionnalités
    • Exécution de modèles locaux sur MacOS, Windows et Linux
    • Recherche, téléchargement et exécution de modèles GGUF et safetensor
    • Détection automatique du RAM offloading et des configurations multiGPU
    • Inférence rapide CPU + GPU via llama.cpp
  • Commandes d’installation
  • Commande de lancement
    • unsloth studio -H 0.0.0.0 -p 8888
    • Une fois lancé, il suffit d’ouvrir http://127.0.0.1:8888 dans le navigateur, ou l’URL spécifique à l’utilisateur
  • Une méthode d’exécution sécurisée de Studio en HTTPS est aussi proposée
    • Sous Windows, Mac et Linux : unsloth studio --secure
    • Avec un tunnel Cloudflare gratuit
  • Lors du premier lancement, il faut créer un password pour sécuriser le compte, puis se reconnecter ensuite
  • Dans l’onglet Studio Chat, il faut chercher GLM-5.2 dans la barre de recherche, puis télécharger le modèle et la quantization souhaités
  • Avant de lancer le modèle, il faut vérifier qu’il y a suffisamment de compute disponible
  • Dans Studio, les paramètres d’inférence devraient être configurés automatiquement, mais l’utilisateur peut modifier manuellement la longueur de contexte, le chat template et d’autres réglages
  • Plus d’informations sont disponibles dans le guide d’inférence Unsloth Studio

Exécution avec llama.cpp

  • Le tutoriel llama.cpp traite de l’exécution de la quantization UD-IQ2_M et nécessite au minimum 245 Go de RAM
  • Pour une inférence locale rapide, il s’appuie sur llama.cpp
  • Sans GPU, ou pour de l’inférence CPU uniquement, il faut remplacer -DGGML_CUDA=ON par -DGGML_CUDA=OFF
  • Sur Apple Mac / Metal, il faut aussi utiliser -DGGML_CUDA=OFF, le support Metal étant activé par défaut
  • La procédure de build suit ce flux
    • apt-get update
    • apt-get install pciutils build-essential cmake curl libcurl4-openssl-dev -y
    • git clone https://github.com/ggml-org/llama.cpp
    • cmake ... -DGGML_CUDA=ON
    • cmake --build ... --target llama-cli llama-mtmd-cli llama-server llama-gguf-split
    • cp llama.cpp/build/bin/llama-* llama.cpp
  • llama.cpp peut aussi charger et télécharger directement des modèles, à la manière de ollama run
  • Parmi les exemples de type de quantization, UD-IQ2_M est retenu, et export LLAMA_CACHE="unsloth/GLM-5.2-GGUF" permet de forcer l’emplacement de stockage
  • Le téléchargement direct via llama.cpp peut être très lent, et le téléchargement manuel est présenté comme préférable

Exemples de téléchargement manuel et d’exécution

  • Pour un téléchargement manuel plus rapide, il est recommandé d’utiliser huggingface_hub
    • pip install huggingface_hub
    • hf download unsloth/GLM-5.2-GGUF --local-dir unsloth/GLM-5.2-GGUF --include "*UD-IQ2_M*"
  • Pour une précision proche du full precision, on peut utiliser --include "*UD-Q8_K_XL*"
  • Si le téléchargement se bloque, il est conseillé de consulter Hugging Face Hub, XET debugging
  • La commande de téléchargement du Dynamic 1-bit est la suivante
    • hf download unsloth/GLM-5.2-GGUF --local-dir unsloth/GLM-5.2-GGUF --include "*UD-IQ1_S*"
  • Chemins du modèle en mode conversation
    • 2-bit : unsloth/GLM-5.2-GGUF/UD-IQ2_M/GLM-5.2-UD-IQ2_M-00001-of-00006.gguf
    • 1-bit : unsloth/GLM-5.2-GGUF/UD-IQ1_S/GLM-5.2-UD-IQ1_S-00001-of-00006.gguf
  • L’exemple d’exécution llama-cli pointe le premier shard du GGUF 2-bit avec --model et utilise les paramètres suivants
    • --temp 1.0
    • --top-p 0.95
    • --min-p 0.01
  • L’exemple d’exécution directe utilise aussi -hf unsloth/GLM-5.2-GGUF:UD-IQ2_M

Comportement vérifié à partir d’un exemple de génération

  • La documentation inclut un exemple où GLM-5.2 en 2-bit réalise du tool-calling et de la génération SVG
  • Après l’exécution de llama-cli, une demande de création d’un « short Flappy Bird game » est montrée
  • Le jeu HTML/JavaScript généré en un seul fichier porte le nom Sunset Flier
    • Il comprend un canvas, un écran de démarrage, un écran de game over, un HUD de score, NEW BEST! et un bouton RETRY
    • Les effets sonores flap, score, hit et die sont générés avec la Web Audio API, sans ressource externe
    • L’état du jeu est géré en quatre étapes : READY, PLAYING, DYING, OVER
    • Le meilleur score est enregistré avec localStorage.getItem('sunsetFlierBest') et localStorage.setItem()
  • La logique du jeu inclut gravité, impulsion de flap, tuyaux aléatoires, collisions, particules, secousses d’écran et système de médailles
    • GRAVITY = 0.42
    • MAX_FALL = 9
    • PIPE_W = 68
    • PIPE_GAP = 180
    • PIPE_SPEED = 2.6
    • PIPE_SPACING = 220
  • Les entrées prises en charge sont la souris, le tactile et le clavier avec Space, ArrowUp, Enter
  • Cet exemple de jeu est présenté dans le contexte où il fonctionnait aussi correctement en quantization 1-bit, y compris pour le son

Long contexte et quantization du cache KV

  • Pour exploiter un long contexte dans llama.cpp, il faut réduire l’usage mémoire via la quantization du cache KV
  • llama.cpp a récemment ajouté des techniques pour améliorer la précision de cette quantization du cache KV ; la PR associée est https://github.com/ggml-org/llama.cpp/pull/21038
  • Les types pris en charge pour le cache KV sont les suivants
    • f32
    • f16
    • bf16
    • q8_0
    • q4_0
    • q4_1
    • iq4_nl
    • q5_0
    • q5_1
  • La valeur par défaut est f16
  • q4_0 représente environ 4,5 bits par weight, ce qui permet d’étendre la longueur de contexte d’un facteur 16 / 4.5, soit environ 3,5x
    • Par exemple, un modèle limité auparavant à 10K pourrait atteindre environ 35K
  • q4_1 ajoute un shifting parameter, potentiellement meilleur, et avec 5 bits par weight permet un contexte environ 3,2x plus long
  • L’exemple d’exécution avec quantization du cache KV utilise le modèle GLM-5.2 GGUF et les paramètres d’échantillonnage suivants
    • Chemin du modèle : unsloth/GLM-5.2-GGUF/UD-IQ2_M/GLM-5.2-UD-IQ2_M-00001-of-00006.gguf
    • --temp 1.0
    • --top-p 0.95
    • --min-p 0.01
    • --cache-type-k q4_1
    • --cache-type-v q4_1

Chiffres visibles dans le tableau de benchmarks

  • La documentation enchaîne avec un tableau de benchmarks GLM-5.2, mais le contenu fourni ne contient pas les en-têtes de colonnes, il n’est donc pas possible de savoir à quel modèle ou réglage correspond chaque chiffre
  • Les benchmarks de raisonnement incluent les lignes et valeurs suivantes
    • HLE : 40.5, 49.8*, 41.4*, 45, 31, 41.4, 37, 37.7
    • AIME 2026 : 99.2, 95.7, 98.3, 98.2, 95.3, 97, -, 94.6
    • GPQA-Diamond : 91.2, 93.6, 93.6, 94.3, 86.2, 90, 93, 90.1
  • Les benchmarks de code incluent les lignes et valeurs suivantes
    • SWE-bench Pro : 62.1, 69.2, 58.6, 54.2, 58.4, 60.6, 59, 55.4
    • NL2Repo : 48.9, 69.7, 50.7, 33.4, 42.7, 47.2, 42.1, 35.5
    • Terminal Bench 2.1 (Terminus-2) : 81.0, 85, 84, 74, 63.5, 75, 65, 64
  • Les benchmarks agentic incluent les lignes et valeurs suivantes
    • MCP-Atlas (Public Set) : 76.8, 77.8, 75.3, 69.2, 71.8, 76.4, 74.2, 73.6
    • Tool-Decathlon : 48.2, 59.9, 55.6, 48.8, 40.7, -, -, 52.8

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Commentaires sur Hacker News

  • Je fais tourner le Q4_K_XL. Pour obtenir environ 6 tk/sec, 512 Go de RAM et 2 RTX 3090 avec llama.cpp -cmoe, ça suffit.
    Là, c’est à cause de ma DDR4 2400 MHz un peu médiocre, mais avec de la 3200 MHz, ça monterait sans doute jusqu’à environ 9 tk/sec. Le CPU est aussi un EPYC 32 cœurs, donc c’est déjà correct, mais avec un meilleur 64 cœurs, on pourrait probablement atteindre 11 tk/sec.
    J’ai monté ça en configuration budget avant que les prix du matériel deviennent délirants, et je le regrette tous les jours, mais malgré tout, c’est formidable de pouvoir faire tourner ce modèle chez soi. C’est bien pour préparer des plans ou rassembler tout le contexte nécessaire avant un prompt one-shot.
    Le coût total du matériel était de 2 400 dollars au moment du montage, et en cherchant bien, il y a moyen de faire tourner ce genre de modèle à la maison. On me demande souvent pourquoi faire ça, ou combien on économise par rapport à une API cloud, mais à mon avis, l’affaire Fable a montré la valeur du fait de fonctionner de manière indépendante.
    Merci à l’équipe d’unsloth, et Q4_K_XL est solide. Si vous téléchargez un modèle quantifié, prenez la variante K_XL si elle tient.

    • Applaudissements pour ceux qui repoussent les limites du possible avec ce genre d’expérimentations homebrew. Comme pour la crypto, l’IA est noyée sous le bruit des marchands, mais on parle très peu de résilience.
      Même chose pour les chercheurs qui essaient de faire rentrer des modèles open source dans une brosse à dents électrique ou un Tamagotchi.
    • Si on fait tourner cette charge en continu, on est à au moins 600 W, soit environ 14 kWh par jour. À 0,2 dollar par kWh, ça fait 2,80 dollars par jour, donc environ 1 000 dollars par an rien qu’en électricité.
      Sauf si la confidentialité ou la satisfaction de tout posséder soi-même est indispensable, payer un hyperscaler est moins cher, plus pratique, et bien plus rapide en tokens par seconde.
      Cela dit, j’aime bien la direction, et j’ai hâte de voir quel matériel d’auto-hébergement existera dans deux ans.
    • J’ai presque la même configuration. 2 RTX 3090, 512 Go de DDR4 un peu plus rapide, et un EPYC 64 cœurs [0].
      Je m’en sers avec plaisir, et j’ai hâte de tester rapidement ce modèle aussi.
      Au-delà de l’exécution de modèles en local, j’utilise aussi cette machine comme principale plateforme de développement à distance. Toutes mes sessions Claude Code tournent désormais dessus dans tmux.
      Mes doigts sont ravis de ne plus avoir à toucher en permanence un laptop brûlant. Et Claude Code vide aussi énormément la batterie.
      [0] https://medium.com/@rathko/i-built-an-epyc-64-core-512gb-ram...
    • Dire « c’est ce qu’il faut pour le faire tourner » peut être vrai si ça a été acheté 2 400 dollars, mais au prix actuel, on est beaucoup plus près des 10 000 dollars au total.
      Rien que la RAM vaut presque 5 000 dollars, et les GPU tournent autour de 2 000 dollars pièce, donc selon les prix actuels, c’est un matériel assez coûteux.
    • Si j’ai bien compris, l’implémentation llama.cpp de ce modèle ne prend pas encore en charge l’attention clairsemée DSA, donc c’est encore assez incomplet.
      Du coup, on fait tourner le modèle avec un autre mécanisme que celui utilisé pendant l’entraînement, et il y a eu des résultats montrant une baisse de qualité et de performances.
      Quoi qu’il en soit, je ne trouve pas GLM 5.2 aussi intéressant que la famille DeepSeek V4 sur plusieurs aspects. DeepSeek V4 utilise un mécanisme d’attention plus avancé, ce qui économise beaucoup de mémoire de cache KV, surtout avec de longs contextes.
      Cela permet au final un traitement par lots plus large, même sur des plateformes grand public. GLM n’a pas ça, et du point de vue de l’architecture de performance sous-jacente, ça me paraît globalement proche de Kimi 2.6. Les deux sont un peu trop lourds pour tourner à pleine qualité de façon raisonnable sur du matériel grand public.

  • Pas loin. Ma machine a 192 Go de RAM + une RTX 3090 24 Go, et j’ai failli pouvoir le faire tourner.
    Pour l’offloading MoE, il faut apparemment 24 Go de VRAM et 256 Go de RAM.
    https://unsloth.ai/docs/models/glm-5.2#usage-guide
    Dans un ancien fil, quelqu’un disait qu’il fallait 500 000 dollars de matériel.
    https://news.ycombinator.com/item?id=48629970

    • 500 000 dollars, c’est une énorme surestimation. Ça peut se justifier si on vise une forte concurrence en FP8 ou BF16.
      En NVFP4, on peut actuellement obtenir une vitesse correcte, autour de 120 tok/s, avec de la concurrence, pour 80 000 à 90 000 dollars, voire moins.
      Avec ce budget, on peut acheter 6 RTX 6000 PRO Blackwell, un CPU correct, une carte mère et une alimentation. Ça fait 576 Go de VRAM.
      Si 40 tok/s en décodage et environ 1200 tok/s en préremplissage vous conviennent, on peut même descendre sous les 50 000 dollars.
    • Il est difficile d’obtenir de bons résultats en 2 bits. Pour le code, la plage idéale est au moins Q8.
    • J’espère que ce boom va relancer une évolution du matériel informatique comme dans les années 90.
      J’ai l’impression que si le matériel a relativement stagné ces 20 dernières années, c’est en partie parce que les entreprises manquaient de cas d’usage pour justifier le renouvellement.
      Sur les 15 dernières années, la majeure partie de l’argent et de l’énergie est allée vers le mobile.
      Une inférence locale bon marché pourrait devenir la source de revenus dont les fabricants de serveurs, de PC de bureau et de laptops ont besoin pour se remettre en mouvement.
    • J’ai la RAM, mais pas la VRAM. Avec une 3090 de 24 Go de RAM, à quelle vitesse ou à combien de tok/s peut-on s’attendre ?
      Je suis un peu tenté d’acheter un GPU avec 24 Go de RAM juste pour essayer.
    • Par curiosité, j’ai demandé à Gemini, et il m’a répondu qu’il fallait 500 000 dollars pour avoir un débit correct sans quantification.

  • Dire que « ça rentre » signifie que ça tient dans 256 Go de RAM, mais dans un état fortement quantifié, et que ça restera malgré tout très lent à exécuter
    Le chiffre du titre n’est pas la vitesse de génération des tokens, mais la vitesse de traitement du prompt
    Si on obtient 10 tok/s et que l’API en fait 20 à 30 tok/s, en apparence ça ne semble pas si mauvais, mais sur un Mac Studio ou sur une machine qui ne charge pas l’ensemble sur le GPU, le traitement du prompt est 20 à 50 fois plus lent qu’avec une configuration 100 % GPU
    Au final, c’est ce qui fait que, sans dépenser 50 000 dollars en GPU, ce n’est pas vraiment exploitable en pratique. Et en plus, on utilise toujours un modèle fortement quantifié

    • Des machines comme le Spark de Nvidia ont 128 Go de RAM unifiée
      Il existe aussi une version double port pour ce type de machine : https://www.nvidia.com/content/dam/en-zz/Solutions/networkin...
      Donc 2 x 100GB/s, voire peut-être 2 x 200GB/s. Il faudra sans doute en avoir une en main pour en savoir plus
      Ces machines peuvent aussi être mises en cluster. Pour 2 ou 3 unités, avec 2 sous-réseaux IP, c’est assez clair. À partir de 4, il faudra peut-être un switch selon l’impact de la latence réseau
      Apple semble avoir oublié les puces de série M avec beaucoup de RAM. Je ne trouve pas en Apple Store de configuration avec plus de 96 Go de RAM unifiée, et même ça coûte un rein

  • Ça pousse dans plusieurs directions à la fois : les nouveaux desktops IA basés sur le GB10 sont relativement abordables, et le clustering permet d’atteindre 1 To de VRAM
    Nvidia, AMD, Intel, Cerebras et d’autres poussent du nouveau matériel, et des modèles open source comme GLM 5.2 progressent à une vitesse absurde
    Les modèles flash comme DeepSeek V4 Flash s’améliorent aussi énormément, et la quantification progresse également
    Il devient aussi possible d’avoir des harnais capables d’utiliser différents modèles selon la tâche, par exemple un gros modèle pour les travaux difficiles et un petit pour les corvées
    Donc ceux qui veulent sortir des API espèrent bientôt pouvoir héberger chez eux des clusters de desktops IA à prix raisonnable et obtenir des performances de niveau Opus

    • Le mot « relativement » fait ici beaucoup de travail. Si un GB10 coûte environ 4 000 dollars, un cluster de 1 To revient à 36 000 dollars
      C’est moins cher qu’un H200 équivalent, mais ça reste hors de portée pour un homelab non financé par des RSU d’OpenAI ou d’Anthropic

  • J’ai l’impression que l’écart se réduit jusqu’au point où on peut faire tourner en local des modèles suffisamment bons, y compris pour le code, et j’imagine que certaines entreprises doivent être un peu nerveuses. Est-ce que je me trompe ?

    • Sans les limitations actuelles en RAM/GPU, ces entreprises seraient probablement encore plus nerveuses qu’aujourd’hui
      Mais à l’heure actuelle, très peu de gens peuvent se permettre le matériel nécessaire pour exécuter efficacement ce modèle. Il est peu probable que cela change beaucoup dans les prochaines années
      Si Z.ai sortait une version spécialisée pour le code, du type GLM-5.2 Flash, autour de 80B paramètres, les labos américains de pointe auraient davantage de raisons de s’inquiéter
      Plus généralement, les entreprises chinoises de l’IA montrent comment accomplir les mêmes choses avec moins de ressources, parfois beaucoup moins, et si cette tendance se poursuit, cela inquiétera les labos de pointe
      Cela dit, les entreprises chinoises de l’IA chercheront elles aussi à protéger leur fossé défensif en évitant de publier des modèles bien plus petits mais toujours puissants que leurs modèles phares actuels
      Alibaba Qwen semble être dans cette position maintenant. C’est devenu assez calme récemment, et son dernier modèle 395B est trop gros pour que la plupart des gens puissent l’exécuter chez eux. Rien n’indique non plus qu’un modèle plus petit soit prévu cette fois
    • Je ne pense pas. Il est très facile d’imaginer une entreprise décider d’héberger et d’exécuter ce type de modèle pour ses propres besoins de développement
      Avec une équipe de développement d’une dizaine de personnes, investir une fois 50 000 dollars dans un serveur LLM peut être une option assez séduisante
      On obtient des tokens illimités, des performances correctes, des options de mise à niveau et des possibilités d’intégration au produit
      En général, pour une entreprise qui veut intégrer un LLM à son produit, l’approche du LLM local semble encore plus attrayante. Même un modèle un peu bête est largement assez bon pour beaucoup d’usages d’intégration produit
    • Pour représenter une menace, il n’est même pas nécessaire de l’exécuter en local. Beaucoup d’entreprises envisagent déjà de payer un prestataire tiers pour héberger ce genre de modèles, à un prix correspondant à une fraction de celui des labos de pointe
    • Les besoins en RAM restent encore assez douloureux
    • L’exécution en local n’est pas économique. C’est excellent pour la confidentialité et c’est un hobby amusant
      Mais les options se résument à un build CPU extrêmement lent avec 10 000 dollars de RAM, ou 90 000 dollars de GPU, ou bien à un modèle fortement quantifié dont la qualité est difficile à comparer
      On peut en monter un pour le plaisir, mais cela ne change pas à lui seul l’équation économique. Le simple fait que ce soit possible reste néanmoins intéressant

  • OpenAI et Anthropic n’aimeront probablement pas le timing de sortie de GLM 5.2
    Cela montre assez bien qu’il ne s’agissait pas d’un fossé magique, mais simplement d’une avance au départ

  • On pourrait utiliser un Mac Studio 192 Go de RAM, mais c’est en dessous de la RAM minimale indiquée
    Comme c’est un MoE, est-ce qu’on pourrait s’en sortir en swappant sur un disque rapide ?

    • Avec autant de swap, cela ressemble surtout à une très bonne manière de consommer l’endurance totale en écriture (TBW) d’un SSD NVMe et de réduire fortement sa durée de vie
      Et les performances seraient catastrophiques, autour de 0,1 tok/s

  • J’ai énormément de respect pour le travail d’unsloth, qui a aidé des millions de personnes à se lancer dans l’IA locale, mais ce billet ressemble un peu à du clickbait au téléchargement
    Déporter trop de couches sur le CPU ne fonctionne tout simplement pas bien. J’ai essayé plusieurs fois, et j’ai fini par devoir faire un rm -rf sur de lourds dossiers de cache Hugging Face
    Je doute même que faire tourner une quantification 1 bit ou 2 bits de GLM 5.2 en grande partie hors VRAM soit plus utile qu’un Qwen3.6-27B Q8_0 entièrement chargé en VRAM

  • Quoi que dise l’article, je pense que quiconque essaiera de faire tourner ça sur une machine avec 256 Go de RAM passera un mauvais moment
    Un minimum bien plus réaliste, c’est 512 Go
    Heureusement, j’ai dans mon bureau à domicile deux stations de travail dual Xeon avec 512 Go de RAM, achetées à bas prix avant la hausse des tarifs, donc je peux expérimenter un peu