Les actions de Zhipu AI bondissent de 26 % après le lancement de son API à 400 jetons/s

Texte | AIDeepDive

Aujourd'hui, Zhipu (02513.HK), « la première entreprise au monde à se consacrer aux grands modèles », connaît une nouvelle forte hausse.

La hausse intrajournalière a un moment dépassé 30 %. À la clôture, le cours s'est établi à 1282 dollars de Hong Kong, enregistrant une hausse quotidienne de plus de 26 %, avec une capitalisation boursière atteignant 571,57 milliards de dollars de Hong Kong, un nouveau record historique.

Ce bond a été déclenché par un indicateur technique précis : 400 tokens/s.

Le 22 mai, Zhipu a officiellement ouvert l'API GLM-5.1 High Speed (GLM-5.1-highspeed) aux clients professionnels, avec un paramètre clé unique : la vitesse de sortie du modèle atteint 400 tokens par seconde, établissant un nouveau record mondial pour la vitesse des API de grands modèles.

Je pensais au départ qu'il s'agissait encore d'une opération de relations publiques pour un grand modèle chinois, mais après avoir examiné les détails techniques, j'ai enfin compris la logique derrière les marchés financiers.

Qu'est-ce que 400 tokens/s signifie ?

Le modèle peut générer environ 200 caractères chinois par seconde, ce qui équivaut à la production intensive d'un écrivain professionnel en une minute, compressée en une seule seconde.

La quantité de texte qu'un créateur met plusieurs jours à rédiger assis à son bureau, GLM-5.1 Speed Edition la produit en une minute ; la tâche de重构 système qu'un ingénieur met trois jours à accomplir, elle la termine pendant qu'on boit une tasse de café.

La vitesse est depuis toujours la dimension la plus souvent négligée dans la compétition entre modèles d'IA.

Au cours des trois dernières années, la course aux armements des grands modèles s'est concentrée sur deux pistes : la taille des paramètres (des modèles plus grands et plus intelligents) et la guerre des prix (des tokens plus abordables et plus accessibles). « Vitesse » n'a jamais été le protagoniste.

Cela est dû au fait que, par le passé, la « rapidité » était généralement atteinte en réduisant les paramètres du modèle. Pour accélérer, il fallait utiliser des modèles plus petits et plus légers, au prix d'une réduction des capacités.

La version rapide de GLM-5.1 est significative car elle maintient les capacités de base de taille complète de haut de gamme tout en atteignant une vitesse de 400 tokens/s.

Que ce soit en termes de modèles nationaux ou sur la scène internationale, les capacités "phare" et la "latence extrêmement faible" sont pour la première fois réalisées sans compromis.

Pourquoi la vitesse est-elle si cruciale ? Parce que le terrain de jeu principal de l'IA connaît une migration fondamentale.

Lorsque l'IA passe de la génération de réponses à l'ère des agents, les questions-réponses ne sont plus le scénario principal de l'IA. Pour accomplir une tâche, un agent nécessite souvent des dizaines, voire des centaines d'appels internes au modèle : écrire du code, appeler des API, rechercher des informations, utiliser des outils...

Dans ce mode de fonctionnement, la latence entre chaque appel est cruellement accumulée et amplifiée. Une tâche nécessitant 50 appels, en économisant 1 seconde à chaque fois, est accélérée de près d'une minute. Pour les assistants de programmation IA, les interactions vocales et les systèmes de prise de décision commerciale, cet écart peut être décisif.

À un niveau plus profond, un raisonnement plus rapide dans un budget temporel fixe permet au modèle d'effectuer des chemins de raisonnement plus profonds et plus de cycles de vérification interne. La vitesse devient elle-même la limite supérieure de l'intelligence.

Quel est le niveau actuel de vitesse dans l'industrie ?

Parmi les principaux fabricants, GPT-4o d'OpenAI se situe à environ 100–150 tokens/s, la série Claude Sonnet d'Anthropic à environ 80–120 tokens/s, et les principaux modèles phares nationaux ont généralement une vitesse de 50–100 tokens/s. 400 tokens/s représente environ 3 à 5 fois la moyenne du secteur.

Plus important encore, cet écart ne peut pas être compensé en investissant davantage de puissance de calcul.

Un serveur équipé de 8 cartes graphiques H200 peut théoriquement déplacer jusqu'à 38 To de données par seconde. Pour GLM-5.1, la génération d'un seul token nécessite de lire environ 42 Go de paramètres d'activation ; théoriquement, cela devrait permettre d'atteindre près de 1000 tokens/s.

Mais les systèmes réels ne peuvent souvent produire que quelques dizaines de tokens/s.

C'est un écart d'ordre de grandeur. Les GPU ne sont pas assez rapides, mais passent une grande partie du temps à attendre, à tourner à vide et à effectuer des planifications inutiles.

ZhiPu a innové simultanément au niveau du moteur d'inférence, des stratégies parallèles et de l'architecture réseau, réalisant une percée en termes de vitesse finale.

Les grands modèles fonctionnent ainsi : ils sont décomposés en opérateurs indépendants, chaque opérateur démarre un noyau de calcul (kernel) séparément, effectue son calcul, s'arrête, attend en synchronisation, puis démarre le suivant.

Pendant la phase d'entraînement, chaque calcul prend plusieurs secondes voire plusieurs minutes ; ces coûts de démarrage et d'attente sont entièrement négligeables. Toutefois, lors de l'inférence, la génération d'un seul token peut ne prendre que quelques dizaines de microsecondes pour une étape critique, rendant les coûts de démarrage et d'attente relativement significatifs.

L'idée centrale de TileRT : compiler le modèle entier en un moteur en cours d'exécution continue, démarré une fois, jamais arrêté.

TileRT étend statiquement, pendant la phase de compilation du code, toute la logique de calcul du modèle en un pipeline continu. Pendant l'exécution, le GPU reste constamment à pleine vitesse, avec le calcul, le transfert de données et la communication avançant en parallèle ; les résultats intermédiaires sont conservés autant que possible dans le cache rapide du GPU, évitant ainsi les écritures répétées vers la mémoire vidéo lente et leurs lectures ultérieures.

Il y a un détail de conception clé : la spécialisation Warp.

Pour comprendre Warp, il faut d'abord comprendre le fonctionnement du GPU. La principale différence entre un GPU et un CPU réside dans le fait que le GPU contient des milliers d'unités de calcul relativement simples, regroupées par paquets de 32, appelés Warp.

Les 32 unités dans le même Warp doivent toujours agir de manière synchronisée et exécuter la même instruction, comme une équipe dans une armée, où le chef donne l'ordre à tout le monde d'effectuer simultanément le même mouvement.

Dans les architectures traditionnelles, tous les Warp exécutent la même séquence d'instructions ; TileRT attribue des rôles différents à des groupes de Warp distincts : certains se consacrent exclusivement à précharger les prochaines données, d'autres à effectuer des calculs mathématiques, et d'autres encore à communiquer avec d'autres GPU. Les trois équipes travaillent simultanément, en flux continu, sans attendre l'une l'autre.

C'est comme passer d'un ouvrier qui transporte des briques, construit des murs et inspecte les travaux en série, à des équipes distinctes qui travaillent simultanément : une équipe pour transporter les briques, une autre pour construire les murs, et une troisième pour l'inspection.

L'efficacité à l'intérieur d'une seule carte est résolue, mais le parallélisme sur plusieurs cartes présente de nouveaux défis.

La pratique courante dans l'industrie est le parallélisme tensoriel (Tensor Parallel) : diviser les matrices de poids du modèle en plusieurs parties, chaque GPU gérant une partie, puis regrouper les résultats via une interconnexion rapide (NVLink).

Cette solution fonctionne très bien pour les calculs denses et réguliers comme la multiplication matricielle, et constitue la solution multi-GPU standard pour presque tous les frameworks d'inférence de grands modèles actuels.

GLM-5.1 utilise **MLA (Multi-head Latent Attention), un mécanisme d'attention proposé par DeepSeek.

L'attention traditionnelle nécessite de sauvegarder intégralement les grandes quantités de données intermédiaires calculées à chaque étape (KV Cache) pour une utilisation ultérieure, ce qui consomme beaucoup de mémoire vidéo ; la méthode MLA consiste à compresser ces données intermédiaires en un "vecteur latent" compact, puis à les décompresser et les restaurer lors de l'utilisation, réduisant considérablement la demande en mémoire vidéo et augmentant l'efficacité de l'inférence.

Mais le processus de calcul de MLA comprend une étape particulière : il faut établir un index clair à partir d'une grande quantité d'informations historiques : comme trouver rapidement quelques livres les plus pertinents dans une immense bibliothèque, puis les lire en détail.

L'étape « chercher le livre » dépend des informations globales et n'est pas adaptée à une répartition sur plusieurs cartes ; c'est « la lecture approfondie » qui convient au calcul parallèle sur plusieurs cartes. Forcer les 8 GPU à participer à « chercher le livre » gaspillerait une grande partie du temps en synchronisation et communication entre GPU.

La solution de TileRT consiste à faire fonctionner le GPU de manière hétérogène : le GPU 0 agit en tant que « bibliothécaire » dédié à la recherche de l'index sparse et à la prise de décisions de routage ; les GPU 1 à 7 agissent en tant que « spécialistes de l'analyse approfondie » chargés des calculs d'attention dense et des opérations matricielles. Les deux types de travailleurs utilisent chacun la stratégie de parallélisation la plus adaptée à leurs tâches pour accomplir ensemble toute la couche de calcul.

Ensuite, TileRT intègre directement les opérations de communication entre GPU dans le pipeline d'exécution, sans les traiter comme des étapes indépendantes. Pour l'extérieur, le système complet de 8 GPU n'exige qu'un seul démarrage de noyau pour accomplir un calcul d'attention, tandis que la communication et le calcul internes sont effectués de manière fluide et continue au sein du pipeline.

Les deux niveaux ci-dessus résolvent les problèmes à l'échelle d'un seul serveur. Lorsque le cluster est étendu à des centaines, voire des milliers de GPU, le transfert de données entre les GPU devient lui-même un nouveau goulot d'étranglement.

La pratique courante de l'industrie est le ROFT (Rail-Optimized Fat-Tree), une solution recommandée par NVIDIA et le standard absolu du secteur.

Sa structure est une arborescence : le serveur se connecte d'abord au commutateur Leaf de niveau inférieur (couche d'accès, directement connectée aux serveurs), puis le Leaf se connecte vers le haut au commutateur Spine (couche dorsale, chargée d'interconnecter différents Leaf, comme des carrefours autoroutiers). Pour transmettre des données entre deux GPU, il faut « monter d'abord jusqu'au Spine, puis descendre jusqu'au Leaf cible », soit au moins trois sauts.

Pour éviter que le trafic ne se concentre sur quelques liaisons, cette architecture repose sur l'algorithme ECMP pour répartir les données entre plusieurs chemins, fonctionnant efficacement sous l'hypothèse d'une répartition statistiquement uniforme du trafic Internet.

Mais le trafic des scénarios d'inférence est complètement inégal. La longueur du contexte varie de plusieurs dizaines de fois d'une requête à l'autre, et la direction de transmission du KV Cache entre les GPU est presque aléatoire. Certains commutateurs Leaf deviennent périodiquement des points chauds, déclenchant un mécanisme de rétropression qui propage la congestion localement à l'ensemble de la chaîne. Cette congestion n'est pas résoluble par un ajustement des paramètres du protocole ; elle est un produit inhérent de la topologie elle-même.

La percée fondamentale de ZCube : empêcher physiquement ce type de congestion au niveau de l'architecture.

La conception centrale se fait en deux étapes :

Étape 1 : Désactiver la couche spine, passer à une architecture platifiée. Regrouper tous les commutateurs leaf en deux groupes selon leur numéro impair ou pair, et interconnecter complètement les deux groupes : chaque commutateur impair est connecté à tous les commutateurs pairs, et vice versa. Deux GPU quelconques peuvent communiquer en passant par au maximum deux commutateurs, réduisant le nombre de sauts de 3 à 2.

Deuxième étape, et celle qui est la plus subtile : chaque carte GPU est connectée à deux ensembles de commutateurs via deux méthodes totalement différentes. Cette topologie particulière confère une propriété mathématique essentielle : entre n'importe quelles deux cartes GPU du réseau, il existe exactement un seul chemin optimal.

Le « chemin unique » élimine directement la cause de la congestion. Les architectures traditionnelles sont sujettes aux points chauds précisément parce qu'elles offrent plusieurs chemins possibles ; un algorithme d'équilibrage de charge mal choisi entraîne une concentration du trafic. ZCube élimine dès sa conception la notion même de « choix » : pas besoin d'équilibrage, car il n'existe aucune bifurcation.

Après avoir migré son cluster de production GLM-5.1 de ROFT traditionnel vers ZCube, Zhipu obtient trois chiffres :

En résumé, avec le même investissement en GPU, le cluster peut servir plus d'utilisateurs ; avec les mêmes exigences en matière d'expérience utilisateur, le cluster peut acheter un tiers de matériel réseau en moins. Une amélioration simultanée de l'efficacité et des coûts.

Plus précisément, une augmentation de 15 % du débit équivaut à obtenir gratuitement 15 % de puissance de calcul supplémentaire. Sans augmenter le nombre de GPU, une augmentation de 15 % du débit réduit le coût matériel moyen par token d’environ 13 %, ou permet de servir 15 % d’utilisateurs supplémentaires au même coût.

Si un cluster dispose de 1 000 GPU, cette mise à niveau équivaut à une augmentation soudaine de 150 cartes en capacité, ce qui représente une valeur de calcul de plusieurs centaines de millions d'euros selon les prix actuels du marché pour les cartes haut de gamme d'inférence.

La latence de queue a diminué de 40,6 %, ce qui résout la stabilité et non la vitesse moyenne. Pour une tâche Agent nécessitant 50 appels, si la latence de queue diminue de 1 seconde à chaque appel, le temps de terminaison le plus défavorable est réduit d'environ une minute.

Les coûts sont réduits d'un tiers grâce à des économies directes au niveau de la construction. ZCube a supprimé la couche Spine, réduisant directement de un tiers le nombre d'intercommutateurs et de modules optiques nécessaires pour une taille de cluster identique. Selon les estimations de ZhiPu, dans un cluster de taille de dix mille GPU, cette seule mesure permet d'économiser environ 210 à 640 millions de yuans.

À long terme, à mesure que la taille des clusters augmente de manière exponentielle, la complexité de la communication entre GPU augmente de plusieurs fois, amplifiant simultanément la probabilité et l'impact de la congestion. Cela signifie que la valeur des innovations architecturales telles que ZCube s'accélérera à mesure que les clusters d'inférence continueront de s'étendre. Les gains des clusters de niveau dix mille GPUs demain pourraient dépasser largement les 15 % d'aujourd'hui.

Après avoir lu le rapport technique de Zhipu, je me demande si cela va provoquer une tempête dans l'industrie, comme l'est apparue DeepSeek.

En y réfléchissant bien, les impacts semblent se manifester sur des plans différents. Lorsque DeepSeek est apparu, il a démontré qu’une intelligence équivalente pouvait être réalisée avec bien moins de puissance de calcul. Le marché a craint que « le nombre de GPU nécessaires diminue », ce qui a fait perdre près de 600 milliards de dollars à la capitalisation boursière de NVIDIA ce jour-là.

Mais la preuve technique de Zhipu aujourd'hui montre que, avec la même puissance de calcul, on peut produire davantage. Elle réinvente « ce que les autres infrastructures, en dehors des GPU, devraient ressembler ».

À court terme, NVIDIA ne sera pas affectée, mais à long terme, le fossé protecteur constitué par les GPU, l'interconnexion NVLink, le réseau InfiniBand et l'écosystème logiciel CUDA est en cours de « déstabilisation », en particulier concernant l'InfiniBand que NVIDIA a acquis pour 6,9 milliards de dollars en 2019 auprès de Mellanox ; la prime sur le segment réseau de NVIDIA sera fortement érodée.

En outre, ZCube a supprimé la couche Spine, mais exige une densité de ports plus élevée sur les commutateurs Leaf. Les fabricants capables de produire des commutateurs Leaf à haute densité et à nombreux ports (Ruijie, Arista, puces de commutation Broadcom) en bénéficient, tandis que ceux qui dépendent principalement des commutateurs haut de gamme Spine pour tirer des marges plus élevées en sont affectés.

En 2025, Celestica et NVIDIA représentent ensemble environ 50 % du marché des commutateurs de réseau arrière-plan AI, un équilibre qui sera réorganisé après la diffusion du paradigme ZCube.

Les modules optiques sont le secteur le plus directement bénéficiaire de ce changement de chaîne de valeur, avec un raisonnement très clair. Pour les fabricants nationaux de modules optiques (Zhongji旭创, Tianfu Communications, etc.), il s'agit d'un avantage structurel : non seulement la demande totale augmente, mais la demande dans le cadre du paradigme ZCube pour les modules optiques à haute vitesse (800G, 1,6 T) est plus concentrée et plus urgente que dans les architectures traditionnelles.

Que ce soit l'architecture TileRT ou ZCube, il s'agit d'un moteur d'inférence entièrement logiciel fonctionnant sur des GPU standards, sans dépendre des fonctionnalités matérielles propriétaires de NVIDIA, et théoriquement portable sur des puces nationales telles que les Ascend de Huawei. Une fois cette voie validée, elle réduira considérablement la barrière logicielle pour les puces AI nationales dans les scénarios d'inférence.

Cela pourrait bien être le véritable enjeu derrière cette innovation technologique.