Xing4_0 atteint SGLang : une sixième PR, et la première taille déclarée, pour le prochain MoE de China Telecom

À deux heures d'intervalle, le 16 septembre 2026, les deux principales piles de serving open source ont cessé d'être en désaccord sur le nom. vLLM a déposé « [Model] Add Xing4_0 support » le matin ; sgl-project/sglang a suivi avec « feat: add Xing4_0 model support » à 10 h 38 UTC, et après six semaines où trois noms étaient en jeu, les deux frameworks disent désormais Xing4_0. La pull request SGLang contient quelque chose qu'aucune précédente n'avait : une taille. Elle décrit le modèle comme Xing4.0-29B-A4B, un « MoE à 29B de paramètres, dont ~4B activés », et fournit une commande de lancement nommant un chemin de checkpoint, un contexte de 262 144 tokens et un décodage spéculatif EAGLE. Il s'agit du MoE non publié de China Telecom, celui-là même autour duquel les pull requests XingChen4 tournent depuis août, et il reste non publié : les poids ne sont pas publics, le chemin de checkpoint indiqué dans la PR ne se résout pour personne en dehors du projet, aucun fournisseur n'a confirmé le nom ni le nombre, et rien dans cet article n'est vérifié de manière indépendante. Les faits tirés des pull requests sont signalés comme tels ; le reste relève du contexte historique et de la déduction. Le modèle le plus proche que vous puissiez réellement appeler aujourd'hui est DeepSeek V4 Flash.

Ceci est un article de type « ce que nous savons à ce jour », maintenu à jour plutôt que repris depuis zéro. Il couvre le fil des pull requests sur six semaines et la manière dont la question du nom a été tranchée, ce que les deux pull requests du 16 septembre apportent réellement, l’architecture que les fichiers de configuration laissent désormais filtrer dans le détail, et ce qu’il faut surveiller ensuite. La version en une phrase : le prochain MoE de China Telecom est assez réel pour avoir accumulé six intégrations de serving, une ligne de tableau dans vLLM marquée TBA, une entrée de documentation dans SGLang marquée « bientôt disponible » et un nombre de paramètres annoncé — et il ne l’est toujours pas assez pour tourner où que ce soit à votre portée.

Le signal : six intégrations, trois noms, six semaines

La piste commence plus tôt que la version de cet article initialement rapportée, et son journal des commits reste l'artefact le plus révélateur de la fuite. La première PR vLLM était #51237, ouverte le 6 août 2026 sous le titre « [WIP][Modèle] Ajouter la prise en charge du prochain modèle XingChen4 ». Ses trois commits racontent l'histoire à eux seuls. Le premier s'intitule « Ajouter la prise en charge du modèle TeleChat4 ». Le deuxième, un peu plus d'une heure plus tard, est « chore: annuler la documentation et l'entrée de test prématurées pour telechat4 » — la documentation et l'entrée de test du registre ont été retirées comme prématurées. Le troisième, le 27 août, est « renommer xingchen4 ». Une minute plus tard, la PR a été fermée sans être fusionnée, et onze minutes après cela #54051 a été ouverte avec le même titre, la même branche de fork (supported_telechat4) et un seul commit squashé. Une étiquette needs-rebase avait été ajoutée entre-temps, ce qui se lit comme une fermeture suivie d'une réouverture après nettoyage plutôt qu'un changement d'avis. Tout cela a été déposé depuis le compte GitHub zyp2014, chaque commit ayant été rédigé et signé par zhangyp26 <zhangyp26@chinatelecom.com.cn>.

Cette deuxième PR est celle autour de laquelle cet article a été initialement construit, et elle n'est plus ouverte. #54051 a été fermée par son propre auteur le 7 septembre 2026, sans avoir été fusionnée. Sa description vaut quand même la peine d'être citée, car c'est la phrase qui a survécu à chaque renommage et à chaque réouverture :

Les poids du modèle ne sont pas encore publics sur Hugging Face Hub. Cette PR est ouverte pour une revue de code précoce. Une fois les poids publiés, j'ajouterai une entrée de test dans tests/models/registry.py, je mettrai à jour docs/models/supported_models.md et je marquerai la PR comme prête pour la revue.

Cette phrase est la forme de toute l’histoire : le code est en avance sur les poids. La capture d’écran ci-dessous est la page #54051 telle qu’elle était le 27 août 2026, le jour de son ouverture — un instantané daté, conservé parce que la pull request qu’elle montre a depuis été fermée. Lisez-la comme un témoignage du signal à ce moment-là, et non de son statut actuel.

Puis, le 16 septembre, le schéma s'est répété — deux fois en une seule journée. #57135, « [Model] Add Xing4_0 support », ouvert ce matin-là depuis le même compte, zyp2014, avec un commit unique désormais rédigé par un ingénieur de China Telecom différent — xiongji <xiongj9@chinatelecom.cn>. Onze fichiers modifiés, environ 1 300 insertions, un nouveau nom partout, et la même mise en garde au même endroit : « Model weights are not yet public on Hugging Face Hub. »

Deux heures et vingt minutes plus tard, l’autre stack de serving n’était plus en retard d’un renommage. sgl-project/sglang #39793, « fonctionnalité : ajout du support du modèle Xing4_0 », ouvert depuis une branche appelée support_xing4_0, et son unique commit porte la même adresse xiongji que le renommage vLLM. Quatorze fichiers et environ 1 400 insertions, dont un peu plus d’un millier provient d’un seul fichier de modèle. C’est la sixième intégration déposée pour ce modèle en six semaines, et la première à ne pas avoir été soumise en tant que brouillon : GitHub la répertorie comme ouverte et prête pour la revue, avec dix relecteurs sollicités — et ses trois exécutions CI sont déjà au rouge.

Du côté de SGLang, avant aujourd'hui, cela fonctionnait comme du côté de vLLM. #33982, « feat(model): add TeleChat4 model support », a été ouverte le 7 août 2026 par le contributeur PaddyXj et fermée sans avoir été fusionnée le 31 août — le jour même #37228, « feat: add XingChen4 model support », a été ouverte à sa place. Celle-ci est toujours ouverte en tant que brouillon sous PaddyXj, sur une branche appelée support_xingchen4, trois commits plus loin et touchée pour la dernière fois le 8 septembre. Sa checklist est l'élément le plus intéressant dans l'un ou l'autre framework : le chargement et la génération du modèle « localement, sur des poids internes » sont cochés, l'appel d'outils est coché, l'analyse du raisonnement est cochée — et l'intégration continue publique ne l'est pas, parce qu'elle est « bloquée par la publication des poids ». Quelqu'un a un checkpoint. Personne ne l'a publié. Et contrairement à vLLM, où chaque nouveau dépôt fermait d'abord son prédécesseur, SGLang a désormais deux pull requests ouvertes et actives pour le même modèle, sous deux noms différents.

Ce à quoi aboutissent six intégrations en six semaines n’est pas une version plus forte du même signal ; c’est un signal différent. Six intégrations seraient compatibles avec une équipe qui itère. Six intégrations sous trois noms — TeleChat4, XingChen4, Xing4_0 — correspondent à une équipe qui itère publiquement sur le nom sous lequel le modèle sera publié, tandis que les poids restent privés. Il s’agit là d’une inférence non vérifiée, et c’est l’élément le plus lourd de conséquences que révèle désormais la trace des PR.

Ce que les deux PR de septembre ajoutent réellement

La pull request vLLM est un renommage du travail d'août plutôt qu'une réécriture de celui-ci. Le fichier de modèle est désormais vllm/model_executor/models/xing4_0.py, la classe est Xing4_0ForCausalLM, et le model_type xing4_0 est mappé à DeepseekV3Config — la même configuration DeepSeek-V3 que celle utilisée par la version XingChen4. Ce qu'elle contient :

• Une implémentation complète du modèle dans vllm/model_executor/models/xing4_0.py — la classe Xing4_0ForCausalLM, avec une passe avant, un adaptateur mHC et une implémentation de load_weights() en parallélisme tensoriel. Le message de commit indique que les variantes DSA et non-DSA sont prises en charge, en réutilisant les opérations partagées mhc_pre / mhc_post.

• Enregistrement de Xing4_0ForCausalLM dans vllm/model_executor/models/registry.py, afin que vLLM reconnaisse l'architecture par son nom.

• Un analyseur de raisonnement (vllm/reasoning/xing4_0_reasoning_parser.py) « pour les variantes capables de raisonnement », et un analyseur d’outils (vllm/tool_parsers/xing4_0_tool_parser.py) pour l’appel automatique d’outils.

• Enregistrement dans vllm/config/speculative.py, vllm/transformers_utils/model_arch_config_convertor.py et vllm/transformers_utils/config.py — avec le message de commit indiquant qu’une tête MTP compatible DeepSeek-V3 est activée pour le décodage spéculatif.

• Deux fichiers de documentation — la partie véritablement nouvelle, et un revirement direct par rapport à août. Le commit d’origine comportait une entrée de documentation et de test qui a été annulée une heure plus tard, jugée prématurée ; la PR de septembre réintègre la documentation et est étiquetée « documentation », « new-model » et « tool-calling ».

Les entrées de la documentation vLLM sont l'endroit où un lecteur a appris pour la première fois quelque chose de concret. docs/models/supported_models.md, la nouvelle ligne indique `Xing4_0ForCausalLM` | Xing4_0 | TBA — la colonne du checkpoint dit littéralement TBA, ce qui revient au même « pas encore » dans une police différente. Et dans docs/features/tool_calling.md, sous le titre « Xing4_0 Models (xing4_0) », la PR documente le format d'appel d'outil du modèle : les appels sont émis à l'intérieur de blocs <tool_call>...</tool_call>, sous forme soit de JSON ({"name": ..., "arguments": {...}}), soit d'une forme à base de balises utilisant <param_key>...</param_key> et <param_value>...</param_value>. C'est un niveau de spécificité que les PR précédentes n'avaient pas atteint — un détail d'implémentation du format de chat du modèle, consigné dans la documentation publique d'un framework majeur, pour un checkpoint que personne ne peut télécharger.

La PR SGLang est plus intéressante, car elle livre une implémentation et une configuration plutôt qu'une entrée de registre accompagnée de documentation. Sa ligne dans la documentation est la première fois qu'un framework inscrit le nom du fournisseur dans sa propre documentation. Dans docs/docs/supported-models/generative_models.mdx, la nouvelle ligne liste Xing4_0, la colonne du checkpoint indiquant `Xing4_0` (bientôt disponible) et une description : « Le modèle MoE de China Telecom, avec attention MLA et flux résiduels mHC (Manifold-constrained Hyper-Connection) ; prend en charge le décodage spéculatif MTP natif, l'appel d'outils et le raisonnement. » La ligne de vLLM indiquait TBA et ne nommait aucun fournisseur ; celle de SGLang nomme China Telecom et indique « bientôt disponible ». Ni l'une ni l'autre n'est une date de sortie, et une ligne dans la documentation d'un framework n'est pas un produit.

La description de la PR ajoute le chiffre que toutes les versions précédentes de cette histoire n'avaient pas. « Cette PR ajoute la prise en charge de Xing4.0-29B-A4B (un MoE de 29 milliards de paramètres avec ~4 milliards de paramètres activés). » Elle fournit également une commande de lancement — --model-path XingChen-AGI/Xing4.0-29B-A4B --trust-remote-code --tp-size 2 --context-length 262144 --reasoning-parser xing4_0 --tool-call-parser xing4_0 --speculative-algorithm EAGLE — et indique que la configuration a été vérifiée avec un parallélisme de tenseurs de 2, un contexte de 262 144 jetons et un décodage spéculatif EAGLE MTP, avec, à l'appui, des transcriptions d'une réponse de raisonnement et d'un appel d'outil get_weather copiées dans la description. Les poids qui sous-tendent cette vérification appartiennent à l'auteur lui-même : le chemin de dépôt nommé par la PR n'est pas lisible publiquement, et l'organisation Hugging Face vers laquelle il pointe ne liste aucun modèle public. Considérez la taille, la longueur de contexte et les transcriptions comme des affirmations rapportées par la PR et attachées à un checkpoint privé, et non comme des mesures que quiconque peut reproduire. Tout cela provient de la pull request et n'a pas été reproduit.

L’apparition des parseurs de raisonnement et d’outils sous les deux noms compte pour la même raison qu’en août. Un parseur de raisonnement sert à retirer les marqueurs de réflexion de la sortie d’un modèle — la chaîne de raisonnement interne qu’un modèle émet avant sa réponse finale. Un parseur conçu spécialement pour ce modèle signifie qu’on s’attend à ce que la famille comporte des variantes capables de raisonnement, de la même manière que TeleChat3 a livré des éditions Thinking. Le parseur d’outils, combiné au format d’appel désormais documenté, signifie que l’appel natif de fonctions est lui aussi attendu. Ni l’un ni l’autre ne constitue une garantie quant au produit final ; tous deux sont les indices les plus forts que les PR portent sur ce que China Telecom vise.

Ce que nous savons jusqu'ici, en un coup d'œil

Le tableau des scores ci-dessous est celui qui a été compilé pour cet article le 27 août 2026, à partir de la PR vLLM telle qu'elle se présentait alors. Il est conservé ici délibérément comme un instantané daté plutôt que redessiné, car chacune de ses lignes est encore vraie trois semaines plus tard — non publié, poids non publics, backbone DeepSeek, résidu mHC, les deux parseurs inclus. Ce qui a changé n'est pas une valeur sur la fiche, mais tout ce qui l'entoure : la PR vLLM qu'il cite a été fermée le 7 septembre, le travail est réapparu sous un nouveau nom le 16 septembre, SGLang a suivi le renommage quelques heures plus tard et le premier nombre de paramètres annoncé est arrivé avec lui. Rien sur la fiche n'est faux. Elle a simplement trois semaines, et le récit l'a dépassée. Les chiffres FlagGems de sa dernière ligne ont été reportés dans la nouvelle PR vLLM sans changement, toujours rapportés par la PR et toujours non reproduits.

L'architecture que les PR divulguent

Renommer un fichier ne renomme pas une architecture, et le texte récapitulatif de la PR vLLM de septembre est le texte d’août avec Xing4_0 substitué à XingChen4 — clause pour clause. Deux phrases portent le signal :

• « Xing4_0 réutilise le backbone DeepSeek-V2/V3 (attention MLA, bloc MoE, indexeur DSA optionnel). »

• « Elle remplace la connexion résiduelle standard par des Hyper-Connexions contraintes par variété (mHC) : le flux résiduel est étendu en num_residual_streams flux parallèles mélangés par des matrices doublement stochastiques dépendant de l'entrée, produites via la projection de Sinkhorn-Knopp. »

Chaque clause correspond à quelque chose de concret. MLA est Multi-head Latent Attention, le schéma d’attention compressée que DeepSeek a introduit avec V2 et qui permet de garder un cache KV de petite taille ; MoE désigne le routage mixture-of-experts, qui conserve un grand nombre de paramètres tout en n’ayant qu’une faible empreinte active. L’indexeur DSA optionnel est le mécanisme DeepSeek Sparse Attention issu de la lignée V3.2 — un module de scoring léger qui sélectionne les top-k tokens auxquels prêter attention, faisant passer le coût de l’attention d’un ordre quadratique à un ordre à peu près linéaire en fonction de la longueur du contexte. Et la phrase sur mHC est l’annonce principale : ce modèle adopte l’architecture résiduelle que DeepSeek n’a lui-même introduite que cette génération.

La PR SGLang est la première à publier la forme de la chose plutôt qu'à la décrire. Son fichier de configuration, python/sglang/srt/configs/xing4_0.py, déclare 40 couches cachées, une taille cachée de 3 584 et un vocabulaire de 131 072 jetons ; MLA avec un rang LoRA KV de 512 et un rang LoRA de requête de 768 sur 32 têtes ; et un MoE sparse avec 64 experts routés plus un expert partagé, un routage top-4, un scoring sigmoïde, un facteur d'échelle routé de 2,0 et une sélection d'experts noaux_tc. Les champs mHC sont eux aussi explicites : hc_mult 4, vingt itérations de Sinkhorn-Knopp, un écrêtage h_res à plus ou moins 30, et un rope_theta de 10 000 avec un embedding de position maximal de 262 144. Ce sont les valeurs par défaut d'une intégration qui n'a pas encore été livrée, selon la pull request — un fichier de configuration est une déclaration d'intention, pas une fiche de modèle, et le chiffre 29B-A4B de la description de la PR n'est dérivé de ces valeurs nulle part dans le domaine public.

Un champ vaut plus que tous les autres, car c'est le premier endroit où ce modèle cesse manifestement d'être une copie de DeepSeek. La configuration SGLang définit hc_contract_for_draft, qui recombine les flux mHC pour les ramener à la taille cachée propre du modèle avant la normalisation finale et transmet ce tenseur contracté à la tête de draft Eagle. DeepSeek V4 transmet à la place le tenseur mHC aplati de taille n-times-hidden_size. Le commentaire de la configuration le dit explicitement, et c'est le genre de détail qui n'apparaît qu'une fois qu'une implémentation a été façonnée à partir d'un vrai checkpoint — ce que la checklist de la PR SGLang précédente prétend avoir, sans le publier.

Les mathématiques de mHC sont le point où les deux stacks divergent dans l’implémentation et partagent la même hypothèse. La PR vLLM note qu’elle « correspond aux opérations partagées dans vllm.model_executor.layers.mhc, donc aucun kernel privé n’est introduit » — ce module existe parce que vLLM prend déjà en charge mHC pour DeepSeek V4, de sorte que le coût incrémental d’ajout de ce modèle est faible. SGLang arrive au même point par une autre voie : son module mHC utilise des kernels TileLang fusionnés enregistrés comme opérations personnalisées torch, et la PR étend le kernel mhc_pre split-K existant pour qu’il accepte hc_hidden_size 14,336 aux côtés des deux tailles qu’il gérait déjà. Elle désactive également le chemin tf32_hc_prenorm_gemm de DeepGEMM pour cette architecture, car ce chemin est une extension C brute que torch.compile ne peut pas tracer ; mHC se rabat alors sur le kernel TileLang. L’avantage pratique est le même dans les deux frameworks : si vous servez DeepSeek V4 sur vLLM ou SGLang aujourd’hui, la machinerie qui servira le prochain MoE de China Telecom est déjà installée.

mHC, l'astuce DeepSeek au cœur de tout cela

Il vaut la peine de décortiquer les Hyper-Connections contraintes par variété, car c'est l'élément le plus intéressant de ce modèle — et ce n'est pas une invention de China Telecom. C'est celle de DeepSeek.

L’histoire commence avec les Hyper-Connections, proposées par l’équipe Ki​mi en 2024. Un Transformer standard conserve un flux résiduel par couche : l’entrée est ajoutée à la sortie de la couche, ce qui donne aux gradients un chemin propre et permet au réseau d’apprendre une correction résiduelle. Hyper-Connections remplace ce flux unique par plusieurs flux parallèles qui sont mélangés par des matrices apprises à chaque couche, offrant au modèle un chemin beaucoup plus riche pour la circulation de l’information. Le piège, c’est la stabilité : des matrices de mélange non contraintes brisent la propriété d’application identité qui rend les connexions résiduelles entraînables, et à l’échelle de mille milliards de paramètres, la perte d’entraînement devient instable.

La contribution de DeepSeek, publiée sous le nom d'article mHC en décembre 2025 puis utilisée dans DeepSeek V4, a été de contraindre les matrices de mélange à être doublement stochastiques — non négatives, avec des lignes et des colonnes sommant chacune à un — imposé par projection de Sinkhorn-Knopp pendant l'entraînement. Une matrice doublement stochastique a un rayon spectral exactement égal à un, de sorte que les signaux ne peuvent pas être amplifiés ou atténués exponentiellement lorsqu'ils traversent des centaines de couches. Cette borne est ce qui maintient la stabilité de l'entraînement à grande échelle, et la projection est suffisamment peu coûteuse pour que DeepSeek n'ait signalé qu'environ 6,7 % de surcoût d'entraînement avec quatre flux résiduels. DeepSeek V4, publié le 24 avril 2026, en est l'utilisation phare, avec un gain rapporté d'environ 15 % sur les tâches de raisonnement mathématique et un contexte de 1 million de tokens en prime.

Donc, en termes simples, ce que ces PR disent, c'est : le prochain modèle de China Telecom reprend l'architecture éprouvée de DeepSeek et le tout nouveau mécanisme résiduel de DeepSeek plutôt que d'inventer l'un ou l'autre à partir de zéro. C'est un choix pragmatique, et il comporte une confirmation subtile — le deuxième grand laboratoire après DeepSeek lui-même à adopter mHC estime que l'astuce est prête pour la production.

Les PR n’en ont pas fini avec mHC, et les points en suspens le reconnaissent honnêtement. Dans l’ensemble des PR vLLM, l’auteur note que les biais de checkpoint (bias_pre, bias_post, bias_res) et un clamp de h_res sont actuellement fusionnés ou omis, et que la confirmation par les relecteurs de l’équivalence des formules est « la principale question de correction ». Il y a aussi une opération de transposition personnalisée qui maintient un tenseur C-contigu pour un noyau TileLang — renommée en même temps que tout le reste, de _xingchen4_transpose_contiguous à _xing4_0_transpose_contiguous — et une limitation stricte : le parallélisme de pipeline n’est pas pris en charge en mode mHC lorsque num_residual_streams est supérieur à un, tandis que le parallélisme de tenseurs est pris en charge. Rien de tout cela n’est surprenant pour un brouillon, mais c’est le même angle inachevé qu’en août, ce qui est en soi instructif : six semaines de renommages n’ont pas fait avancer la question de la correction, et les trois exécutions CI en rouge sur la PR SGLang la plus récente racontent la même histoire sous une autre couleur. Ce que la configuration SGLang tranche, c’est le nombre de flux. Avec hc_mult défini à 4 et une taille cachée de 3 584, le 14 336 dans le patch du noyau correspond exactement à quatre flux — et le commentaire du noyau le dit en toutes lettres. Cette lecture était une inférence à partir d’un nombre brut lors de la première parution de ce texte ; elle est désormais consignée dans un fichier de configuration.

L'angle d'accélération : FlagGems, encore

Un second fil relie ce modèle à la relation existante de China Telecom avec la Beijing Academy of Artificial Intelligence, et c'est le seul fil qui a survécu intact à tous les changements de nom. La PR vLLM active une accélération optionnelle FlagOS/FlagGems derrière un indicateur d'environnement USE_FLAGOS, désactivé par défaut, en substituant des noyaux de chemin critique pour le MoE, l'attention, softmax et top-k. Le gain annoncé, d'après le benchmark H100 de l'auteur de la PR sur une charge de travail à prompt long et à forte concurrence (plus de 10 000 jetons d'entrée, concurrence 10) : jusqu'à 19,87 % de réduction du temps jusqu'au premier jeton et jusqu'à 26,32 % de réduction du temps par jeton de sortie, les autres charges de travail restant neutres. Ces chiffres sont rapportés par la PR et non reproduits, et ils s'accompagnent d'un indicateur désactivé par défaut.

Ce qui mérite d’être noté, c’est à quel point le renommage a peu touché de choses. La PR vLLM de septembre porte les mêmes chiffres, la même note de périmètre restreint indiquant que le flag ne vit qu’à l’intérieur du fichier du modèle, et la même instruction d’installer flagtree et flag-gems. Les chiffres n’ont pas changé parce que le code n’a pas changé ; seul le libellé l’a fait. Les pull requests SGLang ne comportent aucun fil FlagGems — elles empruntent plutôt la voie TileLang et DeepGEMM —, ce qui en fait un débat sur qui possède l’optimisation de la couche de service, et non sur le modèle.

C’est une histoire de continuité. TeleChat3-36B-Thinking était, en avril 2026, le premier grand modèle porté indépendamment sur FlagOS, la pile logicielle d’IA open source de BAAI. Quelle que soit la forme sous laquelle ce modèle est livré, la poursuite de ce fil — avec des noyaux FlagGems au sein de sa propre intégration vLLM — indique que la stratégie de pile domestique du laboratoire s’étend à la couche de service, et pas seulement à l’entraînement.

La question du nom, et la famille dont elle vient

Jusqu'au 16 septembre, la question du nom était un détail. Elle est désormais presque tranchée, et les indices se trouvent encore tous dans des noms de branches et des chaînes résiduelles plutôt que dans des déclarations — mais les deux frameworks ont convergé vers la même réponse, à partir de la même direction.

• Les messages de commit, dans l’ordre : « Add TeleChat4 model support », puis « chore: revert premature docs and test entry for telechat4 », puis — trois semaines plus tard et une minute avant la fermeture de la PR — « rename xingchen4 ». Un commit dont l’unique objectif était le renommage.

• Le fork se ramifie. Les deux premières PR vLLM, #51237 et #54051, ont été extraites de zyp2014:supported_telechat4. La troisième, #57135, est zyp2014:support_xing4_0. La branche a été renommée dans le même mouvement qui a renommé le modèle — et le côté SGLang a désormais parcouru exactement le même chemin en trois étapes, de support_telechat4 à support_xingchen4 puis à support_xing4_0.

• Le corps du texte de #51237, qui indiquait que l’accélération FlagGems était « pour TeleChat4 », alors que ce même paragraphe appelait le modèle XingChen4. Les deux noms étaient déjà en collision dans le résumé de l’auteur lui-même, le 6 août.

• Le renommage fichier par fichier des deux côtés. Dans vLLM, il s'agissait de xingchen4.py vers xing4_0.py et de XingChen4ForCausalLM vers Xing4_0ForCausalLM ; dans SGLang, il s'agit de xingchen4.py vers xing4_0.py et de XingChen4Config vers Xing4_0Config, sur une branche qui a été renommée en même temps. Aucune des deux PR n'a laissé l'ancien nom où que ce soit dans son diff.

Ainsi, trois noms ont circulé dans deux frameworks, et le schéma est cohérent avec un seul modèle renommé à l’approche de ce que sera son nom public. « Xing4_0 » se lit naturellement comme Xingchen 4.0 — la famille du modèle porte la marque 星辰 (Xingchen) en chinois — mais cela reste une déduction à partir de la chaîne, et non quelque chose qu’un communiqué de presse affirme explicitement. Il se pourrait tout aussi bien que TeleChat4 et XingChen4 soient des modèles frères de la même génération plutôt qu’un seul modèle sous deux noms, bien que le fork partagé, le paragraphe d’architecture partagé, les chiffres FlagGems partagés, les points ouverts partagés et désormais un renommage partagé rendent cela plus difficile à défendre. Personne n’a confirmé la relation et China Telecom n’a pas commenté. Ce qui a changé, c’est que le renommage n’est plus le choix d’un seul contributeur : deux projets de serving indépendants, maintenus par des personnes différentes, ont tous deux rebaptisé leur intégration sous le même troisième nom à un jour d’intervalle.

La famille elle-même mérite d’être gardée à l’esprit, car elle explique le pragmatisme. Les versions publiques diffusées jusqu’à présent ont été baptisées TeleChat :

TeleChat-7B et TeleChat-12B, publiés en open source en janvier 2024 avec un corpus d'un billion de jetons.

• TeleChat2-115B (septembre 2024), présenté comme le premier modèle ouvert à mille milliards de paramètres entièrement national, ainsi que ses déclinaisons 35B, 7B et 3B.

• TeleChat2-39B-A12B (mars 2025), le premier MoE de la famille.

• TeleChat3-105B-A4.7-Thinking (décembre 2025), un MoE à granularité fine avec 105B de paramètres au total et 4.7B de paramètres actifs, entraîné sur 15 billions de jetons, aux côtés du dense TeleChat3-36B et plus tard du TeleChat3-Coder-36B-Thinking.

Si le chiffre de 29B-A4B se confirme, ce modèle se situerait sous TeleChat3-105B-A4.7-Thinking tant en paramètres totaux qu'actifs — un petit frère plus petit et moins coûteux plutôt qu'un nouveau porte-drapeau. C'est une interprétation, pas un fait ; rien dans l'un ou l'autre des PR n'indique le segment auquel le modèle est destiné. La marque Xingchen est là où l'entreprise concentre ses efforts en IA : le Xingchen AGI Lab a été officiellement créé à Pékin en mars 2026, en s'appuyant sur la même famille de modèles, et China Telecom décrit son système « 三全 » (tous les modes, toutes les tailles, entièrement national) comme couvrant des modèles sémantiques, vocaux, visuels et multimodaux de 1B à plus de 1T de paramètres. Rebaptiser TeleChat en Xingchen est exactement ce que fait un laboratoire lorsqu'il veut que la famille de modèles porte la marque du laboratoire plutôt que celle de la gamme de produits.

Ce que nous ne savons toujours pas

Pour un modèle à un stade aussi précoce, la liste honnête reste encore plus longue que la liste connue, même si elle s’est resserrée sur deux points cette semaine :

• Aucune date de sortie. Cinq des six intégrations sont des brouillons ouverts pour une première revue de code, précisément parce que les poids ne sont pas publics. La sixième, SGLang #39793, est ouverte à la revue plutôt qu'en brouillon — mais elle n'est pas fusionnée, ses trois exécutions CI échouent et elle a besoin d'un relecteur pour l'approuver. Aucun calendrier n'a été annoncé.

• Un nombre de paramètres, mais qui n’est que revendiqué. Chaque version précédente de cet article listait la configuration MoE comme non divulguée. La PR SGLang change cela sur le papier : Xing4.0-29B-A4B, 29B au total, environ 4B actifs. Ce chiffre provient d’une pull request, n’est attaché à aucun checkpoint public, n’est corroboré par aucun fichier de configuration et n’a été reproduit par personne en dehors du projet. Considérez-le comme une intention déclarée, pas comme une spécification.

• Aucun chiffre de benchmark, qu’il soit rapporté par le fournisseur ou non, et aucun score indépendant. Les transcriptions de vérification dans la PR SGLang montrent le modèle répondant à une invite de raisonnement et émettant un appel d’outil bien formé ; elles ne disent rien non plus de sa performance dans l’un ou l’autre cas.

• Aucun prix, et aucune licence confirmée. Toutes les versions précédentes de TeleChat sont sous Apache-2.0, ce qui est encourageant, mais aucune licence n’a été indiquée pour celle-ci.

• Aucun poids public — confirmé plutôt que supposé. Au 16 septembre 2026, le chemin Hugging Face cité par la PR SGLang n'est pas accessible publiquement et l'organisation vers laquelle il pointe ne répertorie aucun modèle public ; l'entrée publique la plus récente de la famille est TeleChat3-Coder-36B-Thinking, datant de janvier. Le tableau des modèles pris en charge de vLLM indique « à annoncer » dans la colonne checkpoint, celui de SGLang indique « bientôt disponible », et les deux PR SGLang ont une CI publique en échec.

• Aucune communication officielle de China Telecom — pas d'annonce, pas de poids, aucune confirmation du nom ni de la taille. Notez bien l'asymétrie : la ligne de documentation de SGLang attribue le modèle à China Telecom, mais il s'agit de la description d'un contributeur dans une pull request, pas d'une déclaration de l'entreprise, et la description de la plus récente PR omet entièrement le nom du fournisseur. Six intégrations en cours de développement pour ce modèle constituent la preuve la plus solide à ce jour qu'il est bien réel, mais les intégrations finissent par être fermées et les noms de code changent ; deux l'ont déjà été. Rien n'est confirmé tant que le laboratoire ne l'a pas dit.

La bonne lecture de tout cela n’est pas le scepticisme à l’égard du modèle ; c’est une image fidèle d’un signal précoce. Ce qui existe aujourd’hui est un véritable artefact d’ingénierie — en réalité, six — répartis sur deux frameworks — avec une architecture réelle et, pour la première fois, une forme déclarée qui y est attachée. Ce qui n’existe pas encore, c’est quoi que ce soit que vous puissiez télécharger, appeler ou évaluer.

La chose la plus proche que vous puissiez exécuter aujourd'hui

Ce modèle ne peut être servi nulle part — ni via une API, ni en local, car les poids ne sont pas publics. Le modèle le plus proche qu'un lecteur peut réellement appeler aujourd'hui et qui partage son ADN architectural est DeepSeek V4 Flash, qui utilise le même schéma résiduel mHC au-dessus de MLA et MoE, et c'est l'implémentation de référence pour laquelle les modules mHC partagés dans les deux frameworks ont été conçus. La page modèle d'OrcaRouter pour deepseek/deepseek-v4-flash indique un contexte de 1 M de tokens, une sortie maximale de 384 K et un tarif catalogue de 0,15 $ par million de tokens d'entrée et de 0,29 $ par million de tokens de sortie — les mêmes chiffres que ceux publiés par DeepSeek lui-même, transmis avec 0 % de marge, de sorte qu'une modification de prix du fournisseur se répercute ici le jour même. Une seule clé API couvre le catalogue, ce qui fait de sa comparaison avec le reste de la gamme de raisonnement une règle de routage plutôt qu'une nouvelle intégration.

C'est aussi la réponse pratique à « comment essayer ce modèle quand il sortira ». Un checkpoint tout nouveau et non éprouvé est exactement le cas où le basculement automatique en cas de défaillance justifie son existence : acheminez une fraction du trafic vers lui, gardez un modèle éprouvé comme solution de repli, et laissez la couche de routage prendre la décision au lieu de parier un chemin de production sur le comportement du premier jour. Un MoE de 29B avec environ 4B de paramètres actifs, si c'est ce qui arrive, est une chose peu coûteuse à router face à un modèle de pointe précisément parce que si peu de celui-ci s'active par token. Si le nom change encore d'ici la sortie — et les six dernières semaines suggèrent que c'est possible —, c'est la règle de routage que vous réécrivez, pas l'intégration.

Foire aux questions

Pourquoi la PR vLLM a-t-elle été fermée ?

Nous pouvons voir la clôture, pas la raison. #54051 a été fermé par son propre auteur le 7 septembre 2026 sans avoir été fusionné, et le travail est réapparu neuf jours plus tard sous le numéro #57135, sous un nouveau nom. Une PR vLLM antérieure, #51237, a été fermée et redéposée le jour même sous le même titre, donc le fait de fermer et de redéposer est une habitude de cet auteur plutôt qu'un signe de problème — mais les descriptions des PR n'indiquent aucune raison et nous n'allons pas en inventer une.

Quand Xing4_0 sortira-t-il ?

Il n'y a pas de date. Cinq des six intégrations sont des brouillons ouverts pour une revue de code anticipée, et les auteurs eux-mêmes prévoient d'ajouter des entrées de test, de mettre à jour la documentation et de marquer les PR prêtes seulement une fois les poids publiés. L'ancienne liste de contrôle de SGLang est l'énoncé le plus clair de l'état des choses : « Le modèle se charge et génère (localement, sur des poids internes) » est cochée, et la CI publique est « bloquée en attente de la publication des poids ». La PR SGLang plus récente est déposée comme prête pour relecture plutôt que comme brouillon, ce qui constitue un changement de posture plutôt qu'un changement de statut — elle n'est pas fusionnée, sa CI est rouge, et une ligne de documentation indiquant « bientôt disponible » n'est pas un lancement.

Xing4_0 est-il le même modèle que XingChen4 ?

Presque certainement oui, et les PR permettent de le vérifier facilement : même lignée de fork, même paragraphe d’architecture, mêmes chiffres de benchmark FlagGems, mêmes points ouverts, et un renommage fichier par fichier dans les deux frameworks — de xingchen4.py en xing4_0.py, classe de configuration incluse, sur des branches renommées en conséquence. C’est le même travail sous un nouveau nom, et à compter du 16 septembre, vLLM et SGLang ont tous deux adopté ce nom. Ce qu’aucune PR n’indique, c’est quel nom portera un checkpoint publié.

Est-ce un modèle Deep​Seek ?

Non. C'est le modèle de China Telecom, issu du Xingchen AGI Lab. Le lien avec DeepSeek est architectural : il réutilise le backbone DeepSeek-V2/V3 et le schéma résiduel mHC que DeepSeek a proposé et déployé dans la V4. Adopter l'architecture de quelqu'un d'autre ne signifie pas que les deux projets sont liés.

Que regarder ensuite

Les PR continuent de fournir une checklist concrète, et la paire du 16 septembre y a ajouté deux éléments. Premièrement, les poids : chaque auteur a déclaré que son travail attend sur Hugging Face, donc l'apparition d'un dépôt public est l'événement déterminant — et la PR SGLang donne désormais le chemin exact à surveiller, XingChen-AGI/Xing4.0-29B-A4B, qui actuellement ne se résout pour personne. Deuxièmement, les PR elles-mêmes : celle de vLLM a besoin que les formules de biais mHC soient confirmées, que l'entrée de test du registre soit ajoutée et que sa CI soit verte ; la #39793 de SGLang a besoin que ses trois exécutions rouges soient corrigées et que ses dix relecteurs sollicités donnent leur approbation, tandis que la plus ancienne #37228 a encore besoin de son entrée de test, de son benchmark d'accélération MTP et d'une CI débloquée. Troisièmement, et c'est nouveau cette semaine : de savoir si SGLang ferme la #37228 au profit de la #39793, comme vLLM a toujours fermé une prédécesseuse avant d'en redéposer une. Deux intégrations actives pour un seul modèle non publié, c'est un état que personne ne maintient longtemps, et celle qui survit en dit long sur le point où l'on en est réellement. Quatrièmement, les chiffres : de savoir si un checkpoint publié correspond à l'architecture 29B-A4B, au MoE à 64 experts et au contexte de 262 144 tokens que la configuration et la description de la PR affirment désormais. Cinquièmement, de savoir si la troisième PR vLLM survit plus longtemps que ses deux prédécesseuses, qui ont tenu respectivement 21 et 11 jours avant d'être fermées sans être fusionnées. Et surveillez si les parseurs de raisonnement décrivent une variante Thinking distincte, comme TeleChat3 en a livré une.

Jusqu'à ce que l'un de ces événements se produise, considérez ce modèle pour ce qu'il est : un plan bien spécifié d'un laboratoire sérieux, pris en flagrant délit de préparation de son infrastructure de serving — désormais dans les deux grandes stacks de serving open source, sous un nom que toutes deux ont adopté et une taille que seule sa propre pull request indique. L'architecture à elle seule le rend digne d'être suivi : il s'agit de la deuxième adoption majeure de mHC après DeepSeek lui-même, par un laboratoire dont la génération précédente était déjà un MoE à grain fin entraîné sur des puces nationales. Quand les poids seront publiés, il ne fera aucun doute qu'il tourne dans vLLM ou SGLang. Les deux stacks ont écrit le code à trois reprises, sous trois noms différents.