BitCPM-CANN: Native 1.58-Bit Large Language Model Training on Ascend NPU

## BitCPM-CANN : La quantification ternaire native sur NPU Ascend, et ce que ça implique vraiment

### 1. Ce qui se passe concrètement

OpenBMB (Tsinghua) publie BitCPM-CANN, un pipeline complet d'entraînement en quantification ternaire (1.58-bit) porté nativement sur les NPU Huawei Ascend via CANN, MindSpeed et Megatron-LM. Quatre modèles sont entraînés from scratch — 0.5B, 1B, 3B, 8B — en stricte parité architecturale avec MiniCPM4, sur les mêmes données de pré-entraînement. Ce n'est pas un post-training quantization ni un fine-tuning : les poids ternaires {-1, 0, +1} sont appris dès le départ via QAT.

Le résultat central : les variantes 1B, 3B et 8B conservent **95.7 à 97.2 %** des performances full-precision sur 11 benchmarks couvrant raisonnement commun, connaissances domaine, mathématiques (GSM8K) et raisonnement complexe (BBH). La variante 3B atteint la parité sur BBH ; les variantes 3B et 8B récupèrent quasi-intégralement le score GSM8K. Seul le 0.5B décroche à 90.1 %, et les auteurs identifient explicitement la capacité du modèle — pas le quantificateur — comme goulot d'étranglement en dessous du milliard de paramètres.

### 2. Les chiffres qui comptent

**Surcoût d'entraînement : 4.5 %** — 148 vs 155 TFLOP/s par NPU. C'est le chiffre le plus important de ce papier pour les praticiens. Un overhead de 4.5 % signifie que la configuration ternaire devient viable comme **configuration par défaut**, pas comme compromis exceptionnel. Avant ce travail, les pipelines QAT sur GPU montraient des overheads bien plus élevés dès qu'on sortait des kernels CUDA optimisés.

**Réduction mémoire : 8× sur les poids, ~6× end-to-end** (en incluant les scaling factors). Pour un modèle 8B, cela ramène l'empreinte mémoire des poids de ~16 Go (BF16) à ~2 Go, avec une dégradation de performance inférieure à 5 %. Aucune technique de quantization post-entraînement (GPTQ, AWQ, GGUF Q2) n'atteint ce ratio à cette précision de rétention sur des tâches de raisonnement.

**Contexte MiniCPM4** : le modèle de base 8B full-precision atteint des performances comparables à Qwen3-8B entraîné sur 36 trillions de tokens, en utilisant seulement 8 trillions de tokens. BitCPM-CANN hérite de cette efficacité data, ce qui amplifie la pertinence des chiffres de rétention.

### 3. Pourquoi le choix Ascend est structurellement significatif

Jusqu'ici, l'écosystème 1.58-bit (BitNet b1.58, BitCPM GPU) était exclusivement CUDA. Tout le travail de kernels ternaires optimisés — matmul avec accumulation entière, gestion des scaling factors — reposait sur des primitives NVIDIA. Porter ce pipeline sur CANN/MindSpeed n'est pas trivial : il faut réécrire les opérateurs custom, gérer les différences de précision numérique entre architectures, et valider la convergence sur une plateforme où le debugging est moins mature.

L'enjeu géopolitique est lisible : la Chine dispose d'une base installée massive de NPU Ascend (séries 910, 910B, 910C) dans ses datacenters, mais l'écosystème logiciel LLM restait largement dépendant de CUDA via des couches de compatibilité. BitCPM-CANN fournit une infrastructure réutilisable — les auteurs le disent explicitement — pour que d'autres équipes entraînent des modèles low-bit sur Ascend sans repartir de zéro.

### 4. Perdants potentiels et limites

**NVIDIA** : chaque pipeline QAT natif sur Ascend qui fonctionne est une démonstration que le moat CUDA sur l'entraînement LLM se réduit. Ce n'est pas une rupture immédiate, mais c'est une preuve de concept industriellement sérieuse à 8B paramètres.

**Fournisseurs de quantization post-entraînement** : si le QAT ternaire devient une configuration par défaut avec 4.5 % d'overhead, la valeur ajoutée des outils PTQ (llama.cpp Q2_K, AutoGPTQ, etc.) sur les modèles entraînés en ternaire natif devient marginale. Le modèle sort déjà quantifié de l'entraînement.

**Limites réelles** : le papier ne publie pas de benchmarks d'inférence (latence, débit tokens/s) sur Ascend avec les poids ternaires. La réduction mémoire 8× est validée, mais l'accélération effective dépend de l'implémentation des kernels d'inférence ternaire sur NPU — non documentée ici. Le 0.5B à 90.1 % de rétention reste problématique pour les cas d'usage edge où c'est précisément cette taille qui est ciblée. Enfin, les modèles et le code sont disponibles sur HuggingFace et GitHub, mais la reproductibilité complète nécessite un accès à du matériel Ascend, ce qui limite la validation communautaire indépendante.