GLM-5.1 (MoE 744B, n°1 SWE-Bench Pro)

Déployez GLM-5.1 (MoE 744B, 40B actifs) de Z.ai sur Clore.ai — le modèle à poids ouverts qui a dominé SWE-Bench Pro en avril 2026

Statut (avril 2026) : GLM-5.1 a été publié le 7 avril 2026 par Z.ai (anciennement Zhipu AI) comme une mise à niveau incrémentale mais sérieuse de GLM-5. C'est le premier modèle à poids ouverts à se hisser en tête de SWE-Bench Pro (58.4%), devançant GPT-5.4 (57,7) et Claude Opus 4.6 (57,3) selon les chiffres publiés par l'éditeur. Les poids sont disponibles sur huggingface.co/zai-org/GLM-5.1 sous la licence MIT.

GLM-5.1 est un modèle à mélange d'experts de 744 milliards de paramètres qui n'active que ~40B paramètres par jeton. Par rapport à son prédécesseur GLM-5, la version 5.1 conserve la même structure MoE mais propose un routage d'experts affiné, une fenêtre contextuelle de 200K jetons, un sortie maximale de 131K jetons, et un entraînement axé sur le codage agentique à long horizon — le modèle est explicitement optimisé pour enchaîner des milliers d'appels d'outils et des centaines de cycles de refactorisation sans dériver.

Pour les utilisateurs de Clore.ai, l'aspect intéressant est le 40B actifs chiffre : vous n'avez pas besoin d'un rack complet de 8×H200 pour le servir. Une configuration de parallélisme tensoriel sur 2×H100 80 Go (FP8) ou 4×A100 80 Go (BF16 avec partitionnement) suffit pour un débit pratique — mettant le codage de pointe à portée de main à bare metal sur la place de marché.

Spécifications clés

Propriété

Valeur

Paramètres totaux

744B (MoE)

Paramètres actifs

~40B par passe avant

Fenêtre de contexte

200 000 jetons

Sortie maximale

131 072 jetons

Licence

MIT

Date de sortie

7 avril 2026

Organisation

Z.ai (zai-org sur HuggingFace)

Outils principaux

vLLM, SGLang, llama.cpp (GGUF), xLLM, KTransformers

Pourquoi GLM-5.1 ?

N° 1 sur SWE-Bench Pro — 58,4 % revendiqués par l'éditeur, devant GPT-5.4 et Claude Opus 4.6
Agents à long horizon — maintient l'optimisation sur des centaines de tours et des milliers d'appels d'outils
Contexte de 200K — suffisant pour une base de code de taille moyenne entière plus la suite de tests
MoE à 40B actifs — vous payez le coût d'inférence d'un modèle dense de 40B, pas d'un modèle de 744B
licence MIT — poids entièrement ouverts, sans restrictions sur l'usage commercial ou le fine-tuning
Pile d'entraînement ouverte — Z.ai a publié le modèle, apparemment entraîné sans GPU de centre de données Nvidia

Exigences

Les configurations multi-GPU de classe 80 Go ne sont pas répertoriées sur la place de marché Clore.ai. Les plus grosses machines répertoriées aujourd’hui sont 4× RTX PRO 6000 Blackwell (96 Go chacune, 380 Go au total) et 8–11× RTX 5090 (32 Go chacune). La capacité A100 / H200 / B200 est proposée en bare metal sur demande. Consultez bare metal sur demande. Consultez Tarifs et disponibilité des GPU avant de dimensionner un déploiement.

Cela reste un gros modèle. Même si « 40B actifs » paraît rassurant, les poids complets de 744B doivent être chargés en VRAM (ou déchargés). Les poids FP8 représentent environ 860 Go ; en BF16, environ 1,5 To. Planifiez en conséquence.

Composant

Minimum (Q4 GGUF, déchargement)

Recommandé (FP8)

BF16 complet

VRAM GPU

~80 Go (Q4 + déchargement en RAM)

2× H100 80 Go actives, 8× au total

8× H200 141 Go

RAM

256 Go

512 Go

Disque

500 Go NVMe

1 To NVMe

2 To NVMe

CUDA

12.8+

Choix Clore.ai : Pour la plupart des équipes, 2× H100 80 Go exécutant le checkpoint FP8 avec un déchargement agressif constitue le juste milieu (~2,08 $/h). Si vous avez besoin du débit BF16 complet, passez à 8× H200 ou utilisez l'API Z.ai pour les appels occasionnels.

Option A — Ollama / GGUF (quantifiés, versions communautaires)

Attention : Les quants GGUF communautaires arrivent généralement 1 à 2 semaines après une version Z.ai. Si ollama pull échoue, consultez huggingface.co/models?search=glm-5.1+gguf et pointez directement llama.cpp vers le fichier.

# Une fois qu'une build Q4_K_M est disponible
docker exec ollama ollama pull glm-5.1:q4_K_M
docker exec ollama ollama run glm-5.1:q4_K_M

# Ou avec llama.cpp directement sur un fichier GGUF
docker run --gpus all -it --rm -p 8080:8080 \\
  -v $(pwd)/models:/models \\
  ghcr.io/ggerganov/llama.cpp:server-cuda \\
  -m /models/glm-5.1-q4_k_m.gguf \\
  --n-gpu-layers 80 --ctx-size 32768 \
  --port 8080 --host 0.0.0.0

Option B — vLLM (API de production, recommandé)

vLLM est la cible de service privilégiée de Z.ai. Le checkpoint FP8 (zai-org/GLM-5.1-FP8) est celui qu'il vous faut — même qualité que le BF16, pour à peu près la moitié de la mémoire.

version: "3.8"
services:
  vllm:
    image: vllm/vllm-openai:latest
    ports:
      - "8000:8000"
    volumes:
      - hf_cache:/root/.cache/huggingface
    command: >
      --model zai-org/GLM-5.1-FP8
      --tensor-parallel-size 8
      --max-model-len 65536
      --gpu-memory-utilization 0.88
      --tool-call-parser glm47
      --reasoning-parser glm45
      --enable-auto-tool-choice
      --served-model-name glm-5.1
      --trust-remote-code
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    shm_size: "16gb"

volumes:
  hf_cache:

# Tester l'API
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.1",
    "messages": [
      {"role": "system", "content": "Vous êtes un ingénieur logiciel senior."},
      {"role": "user", "content": "Refactorez ce gestionnaire Go pour utiliser correctement context.Context et ajoutez des tentatives de réessai."}
    ],
    "max_tokens": 4096,
    "temperature": 1.0
  }'

Utilisez --tensor-parallel-size 2 sur 2× H100 si vous êtes à l'étroit en nombre de GPU, mais prévoyez un préremplissage plus lent sur des contextes de 200K. --enable-chunked-prefill aide beaucoup.

Option C — SGLang (alternative, souvent plus rapide sur Hopper)

docker pull lmsysorg/sglang:latest

python3 -m sglang.launch_server \
  --model-path zai-org/GLM-5.1-FP8 \\
  --tp-size 8 \
  --tool-call-parser glm47 \
  --reasoning-parser glm45 \
  --speculative-algorithm EAGLE \
  --speculative-num-steps 3 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 4 \
  --mem-fraction-static 0.88 \\
  --context-length 65536 \\
  --served-model-name glm-5.1

Le décodage spéculatif EAGLE de SGLang offre généralement un gain de débit de 1,5 à 2× sur les longues complétions de code.

Recommandations GPU Clore.ai

Configuration

VRAM

Performances attendues

Coût Clore.ai

2× H100 80 Go

160 Go

FP8 avec déchargement, ~15–25 tok/s

~2,08 $/h

4× A100 80 Go

320 Go

BF16 shardé, ~20–30 tok/s

bare metal

8× H100 80 Go

640 Go

FP8 complet, ~60+ tok/s

~8,32 $/h

8× H200 141 Go

1 128 Go

BF16 complet, débit maximal

bare metal

Meilleur rapport qualité-prix : 2× H100 80 Go avec le checkpoint FP8. Vous obtenez des performances de codage de pointe pour à peu près le prix d'un abonnement à Claude Opus — et les poids restent sur votre machine.

Cas d’usage

Agents SWE autonomes — GLM-5.1 est explicitement entraîné pour de longues boucles d'appels d'outils ; associez-le à quelque chose comme SWE-agent ou OpenHands
Compréhension de la base de code — placez plus de 100K jetons de Go/Rust/Python dans le contexte et demandez des revues architecturales
RAG à long contexte — un contexte de 200K gère d'un seul coup toute la documentation produit + les tickets de support
Pipelines de refactorisation — correction maintenue à travers des centaines de modifications de fichiers
Orchestration agent-d'agents — utilisez GLM-5.1 comme planificateur et des modèles plus petits (Qwen3.5-35B, GLM-4.7) comme exécutants

Benchmarks

Déclaré par le fournisseur — vérifiez indépendamment. Les chiffres ci-dessous proviennent de l'annonce du 7 avril 2026 de Z.ai. Les reproductions indépendantes sur SWE-Bench Pro continuent d'arriver.

Benchmark

GLM-5.1

GPT-5.4

Claude Opus 4.6

GLM-5

SWE-Bench Pro

58.4%

57.7%

57.3%

~52%

SWE-Bench Verified

~79%

~78%

~80%

77.8%

HumanEval

~94%

~95%

~94%

~93%

LiveCodeBench

~72%

~73%

~70%

~68%

Dépannage

Problème

Solution

OutOfMemoryError au chargement

Le checkpoint FP8 nécessite environ 860 Go de VRAM au total. Utilisez 8× H100/H200 ou passez à GGUF Q4 avec déchargement en RAM.

Téléchargement HuggingFace lent

Utilisez huggingface-cli download zai-org/GLM-5.1-FP8 --local-dir ./weights --resume-download. Prévoyez plus de 800 Go.

Appels d'outils ignorés silencieusement

Assurez-vous que --tool-call-parser glm47 et --enable-auto-tool-choice sont tous deux définis dans vLLM.

Mode de pensée vide

Nécessite temperature=1.0 — l'échantillonnage à température zéro casse la trace de raisonnement.

vLLM rejette la configuration

GLM-5.1 nécessite vLLM ≥ 0.7.x (version d'avril 2026). Utilisez pip install -U vllm --pre si vous êtes sur des versions plus anciennes.

OOM du contexte 200K

Commencez par --max-model-len 65536 et ajoutez --enable-chunked-prefill; augmentez ensuite une fois stable.

Étapes suivantes

Prédécesseur : GLM-5 — même structure MoE, légèrement moins axée sur le codage
Alternative moins chère: Qwen3.5 — un modèle dense de 35B tient sur une seule RTX 4090
Alternative à contexte massif: DeepSeek V4 — 1M de contexte, multimodal, ~1T de paramètres
Place de marché Clore.ai : clore.ai/marketplace — louez des H100/H200/A100 chez bare metal

Liens

PrécédentDeepSeek V4 (MoE 1,6T, multimodal)

SuivantNVIDIA Nemotron 3 Super (MoE 120B)

Mis à jour il y a 1 mois

Ce contenu vous a-t-il été utile ?