Contexte et contraintes

Le modèle NVIDIA GLM‑5.3 NVFP4 compte 753 milliards de paramètres, dont 40 milliards sont activés pour chaque token grâce à une architecture mixture‑of‑experts (MoE). Le checkpoint complet pèse environ 464 Go, bien au‑delà des 252 Go de mémoire HBM3e d’une seule carte GB300. Cette taille impose de placer les poids sur plusieurs GPU, sinon le chargement échoue.

Architecture de la distribution

Deux stations DGX Station, chacune équipée d’une GB300, sont reliées par un lien RDMA ConnectX‑8. Le test de bande passante indique 400 000 Mb/s (≈ 400 Gb/s) avec MTU 9000, ce qui garantit la transmission de gros paquets de paramètres entre les rails cx8r0 ou cx8r1. Le parallélisme tensoriel (TP=2) divise chaque tenseur du modèle en deux parties égales, chaque partie étant stockée et calculée sur un GPU distinct. Le schéma reste symétrique : la station A (rank 0) expose l’API OpenAI‑compatible, la station B (rank 1) agit uniquement comme worker.

Mise en œuvre avec vLLM

Le conteneur vllm/vllm-openai:v0.30.0-aarch64 (sha256 4864d466…) est tiré sur les deux stations pour garantir une identité binaire. Le fichier d’environnement suivant, créé sur chaque nœud, centralise les paramètres réseau et le chemin du modèle :

RANK="0"                     # 0 sur A, 1 sur B
HEAD_IP="192.168.101.1"
WORKER_IP="192.168.101.2"
RAIL_IFACE="cx8r1"
RAIL_HCA="mlx5_1"
IMG=vllm/vllm-openai:v0.30.0-aarch64
MODEL_REPO=nvidia/GLM-5.3-NVFP4
MODEL_REV=e3b8f9f2fad29727dfa95e766c5cac18ea1414bf
MODEL_HOST="$HOME/models/GLM-5.3-NVFP4"
PORT=8000

Après avoir synchronisé le checkpoint (≈ 464 Go) via rsync, chaque station lance le conteneur avec la même image :

docker run --rm --network host -v "$MODEL_HOST:/model" \
  --entrypoint bash "$IMG" -lc \
  "exec hf download '$MODEL_REPO' --revision '$MODEL_REV' --local-dir /model"

Le lancement du serveur vLLM inclut les variables RANK, les adresses IP et le nom de l’interface RDMA, ce qui active automatiquement le backend NCCL pour la communication inter‑GPU.

Analyse des performances et limites

Le benchmark interne (SPEED‑Bench) mesure 607,8 tokens par seconde sur le point d’accès unique, soit une latence moyenne d’environ 1,6 ms par token. Cette performance provient de la combinaison de deux facteurs : la réduction de la charge de calcul grâce à la sparsité MoE (40 M paramètres actifs) et le débit RDMA qui évite les goulots d’étranglement du PCIe. Cependant, chaque token nécessite toujours l’accès aux 464 Go de poids, ce qui impose que chaque station conserve une copie locale du checkpoint. La désactivation du offload CPU élimine les pénalités de transfert, mais augmente la consommation de stockage disque (≈ 1 To au total). En cas de panne d’une station, le service devient indisponible, car le modèle ne peut plus être reconstitué à partir d’une seule carte.

En résumé, le déploiement montre que le parallélisme tensoriel combiné à une interconnexion RDMA de pointe permet de servir un modèle de plus de 750 B paramètres sans recourir à la quantisation supplémentaire. La solution reste sensible à la disponibilité du réseau et à la capacité de stockage, deux aspects à surveiller lors d’une mise en production à grande échelle.