Xing4_0がSGLangに到達：中国電信の次期MoEに向けた6件目のPR、そして初めて明示されたサイズ

2026年9月16日、2時間違いで、二大オープンソースサービングスタックは名称をめぐる不一致を解消した。vLLMは午前中に「[Model] Add Xing4_0 support」を提出し、sgl-project/sglangは10:38 UTCに「feat: add Xing4_0 model support」で続き、3つの名称が併存してから6週間後、両フレームワークは今やXing4_0と言っている。SGLangのプルリクエストには、以前のどのプルリクエストにもなかったもの、すなわちサイズが含まれている。それはモデルをXing4.0-29B-A4B、すなわち「約4Bの活性化パラメータを持つ29BパラメータのMoE」と説明し、チェックポイントパス、262,144トークンのコンテキスト、EAGLE投機的デコーディングを指定する起動コマンドを示している。これは中国電信の未リリースのMoEであり、XingChen4のプルリクエストが8月から追い続けているものと同じだが、依然として未リリースのままだ。重みは公開されておらず、PRが示すチェックポイントパスはプロジェクト外部の誰にとっても解決できず、どのベンダーも名称も数値も確認しておらず、本記事の内容は独立に検証されていない。プルリクエストから取った事実にはその旨が明記されている。残りは経緯と推測である。今日実際に呼び出せる最も近いモデルはDeepSeek V4 Flashだ。

これは「現時点でわかっていること」をまとめた記事で、一から書き直すのではなく最新の状態に保たれている。内容は、6週間にわたるPRの経緯と命名問題がどう決着したか、9月16日の2つのプルリクエストが実際に何を追加するのか、設定ファイルが今や具体的に明かしているアーキテクチャ、そして次に注目すべきことだ。一文で言えば、China Telecomの次期MoEは、6つのサービング統合を積み重ね、vLLMの表の行にはTBAと記され、SGLangのドキュメント項目には「coming soon」と記され、パラメータ数も明記されているほどには実在している——それでも、あなたがアクセスできるどこかで実行できるほどにはまだ実在していない。

シグナル：6つの統合、3つの名前、6週間

この記事で最初に報じられた版よりも、その痕跡はさらに前にさかのぼり、そのコミットログは今回のリークの中で依然として最も多くを明らかにする成果物だ。最初の vLLM PR は #51237で、2026年8月6日に「[WIP][Model] Add upcoming XingChen4 model support」というタイトルで開かれた。その3つのコミット自体が物語を語っている。1つ目は「Add TeleChat4 model support」というタイトルだ。2つ目は、それから1時間ちょっと後の「chore: revert premature docs and test entry for telechat4」で、ドキュメントとレジストリのテスト項目は時期尚早として取り下げられた。3つ目は8月27日の「rename xingchen4」だ。1分後にそのPRはマージされずにクローズされ、さらに11分後に #54051が同じタイトル、同じフォークブランチ（supported_telechat4）で、単一のsquash済みコミットで開かれた。その間に needs-rebase ラベルが付いていたので、これは気が変わったというより、クリーンアップ後のクローズ＆再オープンと読める。そのすべては GitHub アカウント zyp2014 から提出され、すべてのコミットは zhangyp26 <zhangyp26@chinatelecom.com.cn> によって作成され、サインオフされている。

2つ目のPRこそ、この記事がもともと軸にしていたものであり、もうオープンではない。#54051は2026年9月7日、投稿者自身によってマージされることなくクローズされた。 それでもその説明文は引用に値する。あらゆる名称変更と再オープンを経ても生き残ってきた一文だからだ。

"モデルの重みはまだHugging Face Hubで公開されていません。このPRは早期のコードレビューのために開かれています。重みが公開されたら、tests/models/registry.pyにテストエントリを追加し、docs/models/supported_models.mdを更新し、PRをレビュー可能としてマークします。"

その一文は物語全体の骨格だ。コードが重みより先行している。下のスクリーンショットは、2026年8月27日、それが公開された当日の時点の #54051 ページだ。日付入りのスナップショットであり、そこに写っているプルリクエストがその後クローズされたために保存されている。これはその瞬間のシグナルの記録として読み、現在のステータスの記録として読まないこと。

その後、9月16日には同じパターンが繰り返された——しかも1日に2回。#57135、「[Model] Add Xing4_0 support」はその朝、同じアカウント zyp2014 から開かれ、単一のコミットは今度は別の China Telecom のエンジニア、xiongji <xiongj9@chinatelecom.cn> が作成者となっていた。11個のファイルが変更され、約1,300行が追加され、全体を通じて新しい名前が使われ、同じ場所に同じ注意書きがあった：「モデルの重みはまだ Hugging Face Hub で公開されていません。」

2時間20分後、もう一方のサービングスタックは、1回のリネーム分遅れている状態ではなくなった。sgl-project/sglang #39793、「feat: add Xing4_0 model support,」は、次のブランチからオープンされた：support_xing4_0。その単一のコミットは、vLLMのリネームと同じxiongjiアドレスを持っている。14ファイル、約1,400行の追加で、うち1,000行強は単一のモデルファイルだ。これは6週間でこのモデルに対して提出された6件目の統合であり、最初の非ドラフトとして提出されたものだ：GitHubではオープンでレビュー準備完了と表示され、10人のレビュアーがリクエストされている——そして3回のCI実行はすでにすべて赤だ。

今日より前のSGLang側は、vLLM側と同じように進んでいた。#33982「feat(model): add TeleChat4 model support」は、2026年8月7日にコントリビューターのPaddyXjによってオープンされ、8月31日にマージされないままクローズされた——それと同じ日に#37228「feat: add XingChen4 model support」がその後任としてオープンした。こちらはPaddyXjのもとでドラフトとして今もオープンのままで、support_xingchen4というブランチ上にあり、コミットは3つ、最後に触られたのは9月8日だ。そのチェックリストは、どちらのフレームワークの中でも最も興味深いものだ。「モデルが『ローカルで、内部ウェイト上で』ロードして生成する」はチェック済み、ツール呼び出しもチェック済み、推論のパースもチェック済み——そして公開CIはチェックされていない。なぜなら「ウェイトのリリース待ち」だからだ。誰かがチェックポイントを持っている。しかし誰もそれを公開していない。そして、再提出のたびに必ず前任を先にクローズしていたvLLMとは違い、SGLangには今、同じモデルに対して、2つの異なる名前で、2つの生きたプルリクエストがオープンしている。

6週間で6つの統合が積み上げるものは、同じシグナルのより強い版ではない。別のシグナルだ。6つの統合は、チームが反復していることと整合する。3つの名前 — TeleChat4、XingChen4、Xing4_0 — の下での6つの統合は、モデルが出荷される際の名前を、公開の場で反復検討しているチームだ。一方で重みは非公開のままである。それは検証されていない推論であり、PRの軌跡が今示している最も重大な事柄だ。

9月の2つのPRが実際に追加するもの

vLLM のプルリクエストは、8月の作業を書き直したものではなく、名称を変更したものです。モデルファイルは現在 vllm/model_executor/models/xing4_0.py で、クラスは Xing4_0ForCausalLM、model_type xing4_0 は DeepseekV3Config にマッピングされています — XingChen4 版が使用していたのと同じ Deep​Seek-V3 設定です。それが含むものは次のとおりです：

• vllm/model_executor/models/xing4_0.py における完全なモデル実装 — クラス Xing4_0ForCausalLM。フォワードパス、mHC アダプター、テンソル並列の load_weights() 実装を備えています。コミットメッセージは、DSA と非 DSA の両方のバリアントがサポートされ、共有の mhc_pre / mhc_post 演算を再利用していることに言及しています。

• vllm/model_executor/models/registry.py への Xing4_0ForCausalLM の登録。これにより vLLM はアーキテクチャを名前で認識できるようになります。

• 推論対応バリアント向けの推論パーサー（vllm/reasoning/xing4_0_reasoning_parser.py）と、自動ツール呼び出し用のツールパーサー（vllm/tool_parsers/xing4_0_tool_parser.py）

• vllm/config/speculative.py、vllm/transformers_utils/model_arch_config_convertor.py、および vllm/transformers_utils/config.py への登録 — コミットメッセージには、投機的デコーディング用に Deep​Seek-V3 互換の MTP ヘッドが有効化されたと記載されています。

• ドキュメントファイルが2つ — 真に新しい部分であり、8月の内容を真っ向から覆すものでもある。元のコミットにはdocsとテストのエントリが含まれていたが、時期尚早として1時間後にリバートされた。9月のPRはドキュメントを再び取り込み、documentation、new-model、tool-callingというラベルが付けられている。

vLLM のドキュメント項目は、読者が初めて具体的な何かを知った場所だ。次に、docs/models/supported_models.mdでは、新しい行は `Xing4_0ForCausalLM` | Xing4_0 | TBA と記載されている — チェックポイント列には文字通り TBA と書かれており、それは別のフォントで表されたのと同じ「まだ」だ。そして、docs/features/tool_calling.mdでは、「Xing4_0 Models (xing4_0)」という見出しの下で、PR はモデルのツール呼び出し形式を文書化している。呼び出しは <tool_call>...</tool_call> ブロック内に、JSON ({"name": ..., "arguments": {...}}) として、または <param_key>...</param_key> と <param_value>...</param_value> を使うタグベース形式として出力される。それは以前の PR が到達しなかった具体性のレベルだ — 誰もダウンロードできないチェックポイントのために、大手フレームワークの公開ドキュメントに書き留められた、そのモデルのチャット形式の実装詳細である。

SGLangのPRのほうがより興味深い。なぜなら、レジストリの項目とドキュメントではなく、実装と設定を提供しているからだ。そのドキュメントの行は、フレームワークが自社のドキュメントにベンダー名を記載した初めての例である。docs/docs/supported-models/generative_models.mdxでは、新しい行にXing4_0が記載され、チェックポイント列には `Xing4_0` （近日公開）とあり、説明は「中国電信のMoEモデルで、MLAアテンションとmHC（Manifold-constrained Hyper-Connection）残差ストリームを備える。ネイティブのMTP投機的デコーディング、ツール呼び出し、推論をサポートする」となっている。vLLMの行はTBAとだけ記され、ベンダー名はなかった。SGLangの行は中国電信の名を挙げ、近日公開と述べている。どちらもリリース日ではなく、フレームワークのドキュメントにある一行は製品ではない。

このPRの説明には、この話のこれまでのどのバージョンにも欠けていた数値が加えられている。「このPRはXing4.0-29B-A4B（約4Bの活性化パラメータを持つ29BパラメータのMoE）のサポートを追加する。」また起動コマンドも示している—— --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 ——そして、構成はテンソル並列2、262,144トークンのコンテキスト、EAGLE MTP投機的デコーディングで検証済みだと述べており、推論応答とget_weatherツール呼び出しのトランスクリプトが証拠として説明に貼り付けられている。その検証の背後にある重みは著者自身のものである。PRが示すリポジトリパスは公開されておらず、それが指すHugging Face組織には公開モデルが一切掲載されていない。サイズ、コンテキスト長、トランスクリプトは、誰でも再現できる測定値ではなく、非公開チェックポイントに付随するPR報告の主張として扱うこと。以上はすべてプルリクエストによるもので、再現されていない。

推論パーサーとツールパーサーが両方の名前で登場していることは、8月のときと同じ理由で重要である。推論パーサーは、モデルの出力から思考マーカーを取り除くために存在する — モデルが最終回答の前に出力する内部的な思考の連鎖である。このモデル専用に作られたパーサーは、TeleChat3がThinkingエディションを出荷したのと同じように、このファミリーに推論対応のバリアントが存在すると想定されていることを意味する。ツールパーサーと、今や文書化された呼び出し形式は、ネイティブの関数呼び出しも想定されていることを意味する。どちらも最終製品に関する保証ではないが、両方とも、China Telecomが何を狙っているかについてPRが持つ最も強いヒントである。

一目でわかる、これまでに判明していること

下のスコアボードは、2026年8月27日に本稿のために、当時の状態だったvLLM PRからまとめられたものである。これは描き直すのではなく、日付入りのスナップショットとして意図的にここに置かれている。3週間後もその各行が依然として正しいからだ——未リリース、重みは非公開、DeepSeekバックボーン、mHC残差、両方のパーサーを含む。変わったのはカード上の値ではなく、その周辺のすべてである。それが引用するvLLM PRは9月7日にクローズされ、その作業は9月16日に新しい名前で再び現れ、SGLangは数時間後にその改名に追随し、最初に明示されたパラメータ数もそれとともに現れた。カード上の何も間違ってはいない。ただ3週間前のものであり、物語はその先へ進んでしまっている。その最後の行にあるFlagGemsの数値は、変わらず新しいvLLM PRに引き継がれており、依然としてPRで報告されたままで、依然として再現されていない。

PRsが漏らすアーキテクチャ

ファイル名を変更してもアーキテクチャの名前が変わるわけではなく、9月のvLLM PRの要約テキストは、XingChen4をXing4_0に置き換えた8月のテキストと、節単位で一致している。シグナルを担っているのは2つの文である：

• 「Xing4_0 は DeepSeek-V2/V3 のバックボーン（MLA attention、MoE ブロック、オプションの DSA インデクサー）を再利用します。」

これは標準の残差接続を Manifold-constrained Hyper-Connections (mHC) に置き換える。残差ストリームは num_residual_streams 個の並列ストリームに拡張され、Sinkhorn-Knopp 射影によって生成される入力依存の二重確率行列によって混合される。

各節は具体的な内容に対応している。MLAはMulti-head Latent Attentionであり、DeepSeekがV2で導入した圧縮アテンション方式で、KVキャッシュを小さく保てる。MoEはmixture-of-expertsルーティングで、大きなパラメータ数を維持しながら実際に活性化する部分を小さく抑える。オプションのDSAインデクサーはV3.2系のDeepSeek Sparse Attention機構であり、アテンション対象とするtop-kトークンを選ぶ軽量スコアリングモジュールで、アテンションコストをコンテキスト長に対して二次からほぼ線形へと削減する。そしてmHCの一文こそが最大の注目点だ：このモデルは、DeepSeek自身がまさにこの世代で初めて導入した残差アーキテクチャを採用している。

SGLangのPRは、その構成を説明するのではなく、初めてその形を公表したものだ。その設定ファイル python/sglang/srt/configs/xing4_0.py は、40の隠れ層、隠れサイズ3,584、語彙131,072トークンを宣言している。32ヘッドにわたる、KV LoRAランク512、クエリLoRAランク768のMLA。そして64のルーテッドエキスパートと1つの共有エキスパート、top-4ルーティング、シグモイドスコアリング、ルーテッドスケーリング係数2.0、noaux_tcエキスパート選択を備えたスパースMoEだ。mHCのフィールドも明示されている。hc_mult 4、Sinkhorn-Knopp反復20回、±30でのh_resクランプ、そしてrope_theta 10,000と最大位置埋め込み262,144。PRによれば、これらはまだ出荷されていない統合におけるデフォルト値である。設定ファイルは意図の表明であり、モデルカードではない。そしてPRの説明にある29B-A4Bという数字は、公開されているどこにおいても、それらから導出されたものではない。

あるフィールドは他のどれよりも価値がある。なぜなら、このモデルが目に見えて DeepSeek のコピーでなくなる最初の箇所だからだ。SGLang 設定は hc_contract_for_draft を設定し、これは mHC ストリームを最終ノルムの前にモデル自身の隠れサイズまでマージして縮小し、その縮約されたテンソルを Eagle ドラフトヘッドに供給する。DeepSeek V4 は代わりに mHC で平坦化された n-times-hidden_size テンソルを供給する。設定コメントはそのことを明示しており、これは実際のチェックポイントに合わせて実装が形作られて初めて現れる種類の詳細だ——以前の SGLang PR のチェックリストが、それを公開することなく持っていると主張しているものだ。

mHC の数学は、2 つのスタックが実装では分岐し、前提では一致する箇所である。vLLM の PR は、「vllm.model_executor.layers.mhc の共有 ops と一致するため、プライベートカーネルは導入されない」と述べている。このモジュールが存在するのは、vLLM がすでに DeepSeek V4 向けの mHC をサポートしているためであり、このモデルを追加する増分コストは小さい。SGLang は別の道筋で同じ地点に到達する。その mHC モジュールは、torch カスタムオペレーションとして登録された融合 TileLang カーネルを使用しており、PR は既存の mhc_pre split-K カーネルを拡張して、すでに扱っていた 2 つのサイズに加えて hc_hidden_size 14,336 を受け入れるようにしている。また、このアーキテクチャでは DeepGEMM の tf32_hc_prenorm_gemm パスを無効化する。そのパスは生の C 拡張であり、torch.compile がトレースできないためだ。代わりに mHC は TileLang カーネルへフォールスルーする。実用的な強みは両フレームワークで同じである。今日 vLLM または SGLang で DeepSeek V4 を提供しているなら、China Telecom の次の MoE を提供することになる仕組みはすでに導入されている。

mHC、すべての中心にあるDeepSeekの仕掛け

多様体制約付きハイパーコネクションは掘り下げて理解する価値がある。なぜなら、それはこのモデルについて最も興味深い唯一の点であり、しかも China Telecom の発明ではないからだ。DeepSeek の発明なのだ。

物語は、2024年にKimiチームが提案したHyper-Connectionsから始まる。標準的なTransformerは、層ごとに1本の残差ストリームを保つ。入力はその層の出力に加算され、勾配にクリーンな経路を与え、ネットワークが残差補正を学習できるようにする。Hyper-Connectionsは、その単一ストリームを、各層で学習された行列によって混合される複数の並列ストリームに置き換え、情報が伝わるはるかに豊かな経路をモデルに与える。問題は安定性にある。制約のない混合行列は、残差接続を訓練可能にする恒等写像の性質を壊し、1兆パラメータ規模では学習損失が不安定になる。

DeepSeekの貢献は、2025年12月にmHC論文として発表され、その後DeepSeek V4で採用されたが、混合行列を二重確率行列——非負で、各行と各列の和が1——に制約し、訓練中にSinkhorn-Knopp射影によって強制することだった。二重確率行列のスペクトル半径はちょうど1であるため、信号が数百層を通過しても指数的に増幅または減衰することはない。この上限が大規模での訓練を安定に保つものであり、射影は十分に安価で、DeepSeekは4本の残差ストリームで約6.7%の訓練オーバーヘッドしか報告しなかった。2026年4月24日にリリースされたDeepSeek V4は、その旗艦的な使用例であり、数学推論タスクで約15%の向上、さらに1Mトークンのコンテキストを備えると報告されている。

つまり、これらのPRが平たく言っているのはこういうことだ。中国電信の次期モデルは、DeepSeekの実証済みのバックボーンとDeepSeekの最新の残差メカニズムを採用しており、どちらもゼロから発明したわけではない。これは現実的な選択であり、さりげない裏付けも伴っている——DeepSeek自身に続いてmHCを採用する2番目の主要ラボが、この仕掛けは実運用に耐えると信じているのだ。

PR 群は mHC についてはまだ完成しておらず、未解決項目もそのことを正直に示している。vLLM の PR 全体を通じて、著者はチェックポイントのバイアス（bias_pre、bias_post、bias_res）と h_res クランプが現時点ではマージされているか省略されており、式の等価性についてレビュアーの確認を得ることが「主要な正しさの問い」だと指摘している。また、TileLang カーネル向けにテンソルを C 連続に保つカスタム transpose 演算もあり、これはほかのすべてと同様に _xingchen4_transpose_contiguous から _xing4_0_transpose_contiguous へ改名された。さらに厳しい制限として、num_residual_streams が 1 より大きい場合、mHC モードではパイプライン並列がサポートされない一方、テンソル並列はサポートされる。ドラフトとしては驚くべきことではないが、8月時点と同じ未完成の端であり、それ自体が示唆的だ。6週間にわたる改名は正しさの問いを前進させておらず、最新の SGLang PR で CI が3回赤くなっているのも、別の色で語られる同じ話である。SGLang の設定が決着させたのはストリーム数だ。hc_mult を 4、hidden size を 3,584 に設定すると、カーネルパッチの 14,336 はちょうど4ストリームであり、カーネルのコメントもまさにそう述べている。この記事が最初に公開されたとき、その読みはただの数字からの推論だったが、今では設定ファイルに書き下されている。

加速角度：FlagGems、再び

第2の糸は、このモデルを、China TelecomがBeijing Academy of Artificial Intelligenceと既に築いている関係に結びつけており、あらゆる改名を経てもそのまま残った唯一の糸である。vLLMのPRは、USE_FLAGOS環境フラグの背後で、デフォルトでは無効なオプションのFlagOS/FlagGemsアクセラレーションを有効にし、MoE、attention、softmax、top-k向けのホットパスカーネルを差し替える。PR作成者による高並行・長プロンプトのワークロード（入力トークン1万以上、並行数10）でのH100ベンチマークに基づくとうたわれる効果は、time-to-first-tokenが最大19.87%短縮、time-per-output-tokenが最大26.32%短縮で、他のワークロードには影響がないというものだ。これらの数値はPRで報告されたもので、再現されておらず、しかもデフォルトではフラグがオフであるという但し書き付きである。

記録に値するのは、この名称変更がほとんど何も触れていないことだ。9月の vLLM PR は同じ数値を載せ、そのフラグがモデルファイル内にのみ存在するという同じ限定的な注記を添え、flagtree と flag-gems をインストールするよう同じ指示を出している。数値が変わらなかったのはコードが変わらなかったからであり、変わったのはラベルだけだった。SGLang のプルリクエストには FlagGems のスレッドがまったく含まれておらず、代わりに TileLang と DeepGEMM の路線を取っている。このことは、これがモデルについての議論ではなく、サービング層の最適化を誰が担うかについての議論であることを示している。

これは継続性の話だ。TeleChat3-36B-Thinkingは、2026年4月時点で、BAAIのオープンソースAIソフトウェアスタックであるFlagOSに独立して移植された最初の大規模モデルだった。このモデルがどのような形で提供されるとしても、その流れを継続すること——自身のvLLM統合内にFlagGemsカーネルを備えること——は、同ラボの国内スタック戦略が訓練だけでなくサービング層にまで及んでいることを示している。

命名の問い、そしてそれが生まれた家族

9月16日まで、命名の問題は補足事項にすぎなかった。今ではほぼ決着しかけており、証拠は依然として声明ではなく、ブランチ名や残された文字列の中にすべてある——しかし2つのフレームワークは、同じ方向から同じ答えに収束した。

• コミットメッセージは順に、「Add TeleChat4 model support」、次に「chore: revert premature docs and test entry for telechat4」、そして——3週間後、PRがクローズされる1分前に——「rename xingchen4」。リネームのみを目的としたコミット。

• フォークは枝分かれする。最初の2つの vLLM PR、#51237 と #54051 は、zyp2014:supported_telechat4 から切り出された。3つ目の #57135 は、zyp2014:support_xing4_0 である。ブランチは、モデルの改名と同じ動きで改名された——そして SGLang 側は今や、support_telechat4 から support_xingchen4 を経て support_xing4_0 へと、3段階で同一の道をたどった。

• #51237 の本文は、FlagGems による高速化が「TeleChat4 向け」だと述べていた一方で、まったく同じ段落でそのモデルを XingChen4 と呼んでいた。この2つの名前は、8月6日の著者自身の要約の時点ですでに衝突していた。

• 両側でのファイル単位のリネーム。vLLM では xingchen4.py から xing4_0.py へ、そして XingChen4ForCausalLM から Xing4_0ForCausalLM へだった。SGLang では xingchen4.py から xing4_0.py へ、そして XingChen4Config から Xing4_0Config へで、それに合わせて名前が変わったブランチ上にある。どちらの PR も、その diff のどこにも古い名前を残していない。

すると、3つの名前が2つのフレームワークにまたがって登場しており、そのパターンは、単一のモデルが最終的な公開名に近づくにつれて改名されているという見方と一致している。「Xing4_0」は自然にXingchen 4.0として読める — このモデルのファミリーは中国語で星辰（Xingchen）というブランド名になっている — が、それは依然として文字列からの推測であり、どのPRも明言していることではない。TeleChat4とXingChen4が、1つのモデルが2つの名前を持つというより、同じ世代の兄弟である可能性も同様に考えられる。とはいえ、共有されたフォーク、共有されたアーキテクチャの段落、共有されたFlagGemsの数値、共有された未解決項目、そして今では共有された改名が、その説を唱えるのを難しくしている。誰もその関係を確認しておらず、China Telecomもコメントしていない。変わったのは、その改名がもはや1人のコントリビューターの選択ではないということだ。別々の人物によって維持されている2つの独立したサービングプロジェクトが、互いに1日以内に、それぞれの統合を同じ3つ目の名前に付け替えたのである。

ファミリー自体は視野に入れておく価値がある。それが実用主義を説明しているからだ。これまでに公開されたリリースには、TeleChatというブランド名が付けられている：

TeleChat-7BとTeleChat-12Bは、2024年1月に1兆トークンのコーパスとともにオープンソース化されました。

• TeleChat2-115B（2024年9月）は、初の完全国産1兆パラメータ・オープンモデルとして謳われ、さらに35B、7B、3Bの兄弟モデルが加わります。

• TeleChat2-39B-A12B（2025年3月）、ファミリー初のMoE。

• TeleChat3-105B-A4.7-Thinking（2025年12月）は、合計105Bパラメータ・アクティブパラメータ4.7Bの細粒度MoEであり、15兆トークンで学習されています。高密度モデルのTeleChat3-36B、および後続のTeleChat3-Coder-36B-Thinkingと並んでいます。

29B-A4Bという数字が正しければ、このモデルは総パラメータ数とアクティブパラメータ数の両方でTeleChat3-105B-A4.7-Thinkingを下回ることになり、フラッグシップの後継機ではなく、より小型で安価な兄弟機ということになる。これは一つの解釈であって、事実ではない。どちらのPRにも、このモデルがどの層を狙ったものかは一切書かれていない。Xingchenブランドこそ、同社がAIへの取り組みを注ぐ場所である。Xingchen AGI Labは2026年3月に北京で正式に設立され、同じモデルファミリーを基盤としており、China Telecomはその「三全」（フルモーダル、フルサイズ、フル国産）システムが、1Bから1T+パラメータにわたる意味論・音声・視覚・マルチモーダルの各モデルを包含すると説明している。TeleChatからXingchenへの改名は、ラボがモデルファミリーに製品ラインのブランドではなくラボ自身のブランドを背負わせたいと考えるときに、まさにラボが行うことである。

私たちがまだ知らないこと

これほど初期段階のモデルにとって、正直なリストは依然として既知のリストより長いが、今週は2か所で狭まっている：

リリース日は未定。6つの統合のうち5つは、まさに重みが公開されていないために、早期のコードレビュー用に開かれたドラフトです。6つ目、SGLang #39793 はドラフトではなくレビュー用に公開されています — ただしマージはされておらず、CI実行3件はすべて失敗しており、承認するレビュアーが必要です。公表されたスケジュールはありません。

• パラメータ数、ただし主張されているだけのものだ。この記事の以前のバージョンでは、いずれも MoE 構成を非公開と記載していた。SGLang の PR は、少なくとも書面上はそれを変える：Xing4.0-29B-A4B、合計 29B、アクティブはおよそ 4B。この数値はプルリクエストに由来し、公開チェックポイントには紐づかず、設定ファイルによる裏付けもなく、プロジェクト外部の誰にも再現されていない。仕様ではなく、表明された意図として扱うこと。

• ベンチマークの数値は、ベンダー報告であれそれ以外であれ一切なく、独立したスコアもありません。SGLang の PR にある検証トランスクリプトは、モデルが推論プロンプトに回答し、適切な形式のツール呼び出しを出力することを示していますが、そのどちらについても、どれほどうまくできているかは何も示していません。

• 価格の提示もなく、確認されたライセンスもない。これまでのTeleChatのリリースはすべてApache-2.0であり、それは心強いが、今回のリリースについてはライセンスが明示されていない。

• 公開ウェイトはない — 推測ではなく確認済み。2026年9月16日時点で、SGLangのPRが挙げているHugging Faceのパスは公開閲覧できず、それが指す組織は公開モデルを一切掲載していない。このファミリーで最新の公開エントリは1月のTeleChat3-Coder-36B-Thinkingだ。vLLMの対応モデル一覧ではチェックポイント列がTBAと記載され、SGLangの一覧では「近日公開」と記載されており、SGLangの両PRでは公開CIが失敗している。

• China Telecom からの公式な情報は一切ない — 発表も、重みも、名称やサイズの確認もない。この非対称性には注意が必要だ。SGLang のドキュメントの行はこのモデルを China Telecom に帰属させているが、それはプルリクエスト内のコントリビューターによる説明であり、企業の声明ではなく、最新の PR 説明ではベンダー名が完全に省かれている。このモデルのために構築が進む6つの統合は、それが実在することを示すこれまでで最も強い証拠だが、統合は閉じられ、コードネームは変わる。すでに2つは閉じられている。ラボがそう述べるまで、何も確認されていない。

これらすべてに対する正しい解釈は、モデルへの懐疑ではない。それは初期の兆候を正確に描いたものだ。今日存在するのは、実際のエンジニアリング成果物 —— 2つのフレームワークにまたがる6つ —— であり、実際のアーキテクチャを備え、そして初めて、明示された形態が付与されている。まだ存在しないのは、ダウンロードしたり、呼び出したり、ベンチマークしたりできるものだ。

今日実行できる最も近いもの

このモデルはどこでも配信できません — API経由でもローカルでも。重みが公開されていないからです。今日、読者が実際に呼び出せるモデルの中で、そのアーキテクチャのDNAを最も色濃く受け継いでいるのは DeepSeek V4 Flash です。これは MLA と MoE の上に同じ mHC 残差スキームを採用しており、両フレームワークの共有 mHC モジュールがまさにそのために構築されたリファレンス実装です。OrcaRouter の deepseek/deepseek-v4-flash のモデルページには、100万トークンのコンテキスト、最大出力384K、そしてリスト価格として100万入力トークンあたり $0.15、100万出力トークンあたり $0.29 が記載されています。これは DeepSeek 自身が公表している数値と同じで、0% のマークアップでそのまま通されているため、ベンダーの価格変更は同じ日にここへ反映されます。1つの API キーでカタログ全体をカバーできるので、他の推論ティアと比較するのは、新たな統合ではなくルーティングルールの話になります。

それはまた、「このモデルが正式リリースされたらどう試せばいいのか」に対する実用的な答えでもある。まったく新しく実績のないチェックポイントこそ、自動フェイルオーバーが真価を発揮する場面だ。トラフィックの一部をそこへ流し、実績のあるモデルをフォールバックとして維持し、初日から本番経路に賭けるのではなく、ルーティング層に判断を任せる。約4Bのアクティブパラメータを持つ29B MoEがもし登場するなら、トークンあたりで活性化する部分がごくわずかであるがゆえに、フロンティアモデルに対してルーティングする対象としては安価だ。今からリリースまでの間に名前がまた変わるとしても——過去6週間の様子からすると、その可能性はある——書き換えるのはルーティングルールであり、統合ではない。

よくある質問

vLLMのPRはなぜクローズされたのですか？

我々に見えるのはクローズされた事実だけで、理由は見えない。#54051は2026年9月7日、マージされることなく投稿者自身によってクローズされ、その作業は9日後に新しい名前で#57135として再登場した。以前のvLLM PRである#51237は、同じ日に同じタイトルでクローズされ、再提出された。つまり、クローズして再提出することはこの投稿者の常套手段であり、問題の兆候ではない — しかし、PR本文には理由が記載されておらず、我々が理由をでっち上げるつもりはない。

Xing4_0はいつリリースされますか？

日付はない。6つの統合のうち5つは、初期コードレビューのために開かれたドラフトであり、著者たち自身の計画では、テスト項目を追加し、ドキュメントを更新し、PRを準備完了にするのは、重みが公開されてからにすぎない。SGLangの古いチェックリストが現状を最も明確に示している。「モデルが（ローカルで、内部の重みを使って）読み込まれ、生成する」にはチェックが入っており、公開CIは「重みの公開待ちでブロックされている」となっている。より新しいSGLangのPRはドラフトではなくレビュー準備完了として提出されているが、これは状態の変化ではなく姿勢の変化だ――未マージで、そのCIは赤く、「近日公開」と書かれたドキュメントの行はローンチではない。

Xing4_0はXingChen4と同じモデルですか？

ほぼ間違いなくイエスであり、PRを見れば簡単に確認できる。同じフォーク系統、同じアーキテクチャの段落、同じFlagGemsベンチマークの数値、同じ未解決項目、そして両フレームワークでのファイル単位の改名 — xingchen4.py から xing4_0.py へ、config クラスも含めて、それに合わせて改名されたブランチ上で。それは新しい名前をまとった同じ仕事であり、9月16日時点で vLLM と SGLang の両方がその名前を採用している。どのPRにも明記されていないのは、リリースされるチェックポイントがどの名前を帯びるかだ。

これはDeepSeekモデルですか？

いいえ。それはChina Telecomのモデルで、Xingchen AGI Labのものです。DeepSeekとのつながりはアーキテクチャ上のものです。DeepSeek-V2/V3のバックボーンと、DeepSeekがV4で提案してリリースしたmHC残差方式を再利用しています。誰かのアーキテクチャを採用することは、その二つのプロジェクトが関連していることと同じではありません。

次に見るもの

PRは依然として具体的なチェックリストを与えており、9月16日の2件のPRはそこに2項目を追加した。第一に、重み：すべての著者が自らの成果はHugging Face待ちだと述べているため、公開リポジトリが現れることが決定的な出来事であり、SGLangのPRは今や監視すべき正確なパス、XingChen-AGI/Xing4.0-29B-A4Bを示しているが、これは現時点では誰にとっても解決できない。第二に、PR自体：vLLMのものはmHCバイアス式の確認、レジストリのテストエントリの追加、CIのグリーン化が必要であり、SGLangの#39793は3件のレッドランを修正し、要求された10名のレビュアーの承認を得る必要がある一方、より古い#37228は依然としてテストエントリ、MTP高速化ベンチマーク、そしてブロックされていないCIを必要としている。第三に、今週新たな点：SGLangが、vLLMが常に先行PRをクローズしてから再提出してきたのと同じように、#39793を優先して#37228をクローズするかどうか。1つの未リリースモデルに対して2つの生きた統合が存在する状態は誰も長く維持しないものであり、どちらが生き残るかは、これが実際どれほど近いかを物語っている。第四に、数字：リリースされたチェックポイントが、設定とPR説明が今や主張する29B-A4Bの形状、64エキスパートのMoE、262,144トークンのコンテキストと一致するかどうか。第五に、3番目のvLLM PRが、マージされずにクローズされるまでにそれぞれ21日と11日続いた2つの先行PRよりも長く生き残るかどうか。そして、推論パーサーが、TeleChat3がそうしたのと同じように、別個のThinkingバリアントを記述しているかどうかに注目せよ。

それが起きるまでは、このモデルを実態どおりに扱うべきだ。真剣なラボによる、仕様のしっかりした計画であり、サービング基盤を準備している最中を捉えたものだ。今や主要なオープンソースサービングスタックの両方に、両者が採用した名前で、そしてサイズはそれ自身のプルリクエストだけが示す形で存在している。アーキテクチャだけでも追跡する価値がある。DeepSeek自身に続く、mHCの2番目の主要な採用例であり、そのラボの前世代はすでに国産チップで学習された細粒度MoEだった。重みが公開されれば、vLLMで動くのかSGLangで動くのかという疑問は生じない。両スタックとも、3つの異なる名前の下でコードを3度書き上げている。