Xing4_0 достигает SGLang: шестой пул-реквест и первый заявленный размер для следующего MoE от China Telecom

С разницей в два часа, 16 сентября 2026 года, два доминирующих открытых стека для обслуживания моделей перестали расходиться в вопросе названия. Утром vLLM подал «[Model] Add Xing4_0 support»; sgl-project/sglang последовал за ним с «feat: add Xing4_0 model support» в 10:38 UTC, и после шести недель, в течение которых в ходу было три названия, оба фреймворка теперь говорят Xing4_0. Пул-реквест SGLang несёт в себе то, чего не было ни в одном из более ранних: размер. В нём модель описывается как Xing4.0-29B-A4B — «MoE на 29 млрд параметров с примерно 4 млрд активируемых параметров», — и приводится команда запуска, в которой указаны путь к чекпойнту, контекст в 262 144 токена и спекулятивное декодирование EAGLE. Это невыпущенная MoE от China Telecom — та самая, вокруг которой с августа кружат пул-реквесты XingChen4, — и она по-прежнему не выпущена: веса не опубликованы, путь к чекпойнту, указанный в PR, не открывается ни у кого за пределами проекта, ни один вендор не подтвердил ни название, ни число, и ничто в этом материале не проверено независимо. Факты, взятые из пул-реквестов, помечены как таковые; всё остальное — история и предположения. Самая близкая модель, которую сегодня действительно можно вызвать, — DeepSeek V4 Flash.

Это материал в формате «что мы знаем на данный момент», который поддерживают в актуальном состоянии, а не пишут заново. В нём рассказывается о шестинедельной цепочке PR и о том, как разрешился вопрос с названием, что на самом деле добавляют два пул-реквеста от 16 сентября, какую архитектуру конфигурационные файлы теперь раскрывают весьма детально, и за чем стоит следить дальше. Версия в одном предложении: следующий MoE от China Telecom достаточно реален, чтобы накопить шесть интеграций для сервинга, строку в таблице vLLM с пометкой TBA, запись в документации SGLang с пометкой «coming soon» и заявленное число параметров — и всё ещё недостаточно реален, чтобы запуститься где-либо, куда у вас есть доступ.

Сигнал: шесть интеграций, три названия, шесть недель

След начинается раньше, чем в первоначально опубликованной версии этой статьи, и журнал коммитов по-прежнему остаётся самым показательным артефактом утечки. Первым PR в vLLM был #51237, открытый 6 августа 2026 года под заголовком «[WIP][Model] Add upcoming XingChen4 model support». Три его коммита говорят сами за себя. Первый называется «Add TeleChat4 model support». Второй, чуть более чем через час, — «chore: revert premature docs and test entry for telechat4»: документацию и тестовую запись в реестре убрали обратно как преждевременные. Третий, 27 августа, — «rename xingchen4». Через минуту PR закрыли без слияния, а ещё через одиннадцать минут #54051 открылся с тем же заголовком, той же веткой форка (supported_telechat4) и единственным сквош-коммитом. Тем временем появилась метка needs-rebase, так что это читается как закрытие и повторное открытие после уборки, а не как смена решения. Всё это было оформлено с аккаунта GitHub zyp2014, причём автором и подписантом каждого коммита указан zhangyp26 <zhangyp26@chinatelecom.com.cn>.

Тот второй PR — именно вокруг него изначально строилась эта статья, и он больше не открыт. #54051 был закрыт его собственным автором 7 сентября 2026 года, так и не будучи слитым. Его описание всё равно стоит процитировать, потому что это предложение пережило каждое переименование и каждое повторное открытие:

Веса модели ещё не опубликованы на Hugging Face Hub. Этот PR открыт для раннего ревью кода. Когда веса будут выпущены, я добавлю тестовую запись в tests/models/registry.py, обновлю docs/models/supported_models.md и пометлю PR как готовый к ревью.

Это предложение — форма всей истории: код опережает веса. Скриншот ниже — это страница #54051 в том виде, в каком она была 27 августа 2026 года, в день её открытия — датированный снимок, сохранённый потому, что показанный на нём пул-реквест с тех пор был закрыт. Читайте его как запись сигнала на тот момент, а не как его нынешний статус.

Затем, 16 сентября, ситуация повторилась — дважды за один день. #57135, «[Model] Добавить поддержку Xing4_0», открытый тем утром с той же учётной записи zyp2014, с единственным коммитом, автором которого теперь был другой инженер China Telecom — xiongji <xiongj9@chinatelecom.cn>. Одиннадцать изменённых файлов, примерно 1300 добавлений, новое название повсюду и та же оговорка в том же месте: «Веса модели пока не опубликованы на Hugging Face Hub».

Спустя два часа двадцать минут другой стек обслуживания перестал отставать на одно переименование. sgl-project/sglang #39793, «feat: добавить поддержку модели Xing4_0», открыт из ветки под названием support_xing4_0, и его единственный коммит содержит тот же адрес xiongji, что и переименование vLLM. Четырнадцать файлов и около 1400 добавлений, из которых чуть больше тысячи — это один файл модели. Это шестая интеграция, поданная для этой модели за шесть недель, и первая, поданная не как черновик: GitHub отображает его как открытый и готовый к проверке, запрошены десять рецензентов — а все три его запуска CI уже красные.

Сторона SGLang до сегодняшнего дня работала так же, как у vLLM. #33982, «feat(model): добавить поддержку модели TeleChat4», был открыт 7 августа 2026 года контрибьютором PaddyXj и закрыт без слияния 31 августа — в тот же день #37228, «feat: добавить поддержку модели XingChen4», открылся вместо него. Тот всё ещё открыт как черновик под авторством PaddyXj, в ветке под названием support_xingchen4, в которой три коммита и которая последний раз изменялась 8 сентября. Его чек-лист — самое интересное в обоих фреймворках: пункт о том, что модель загружается и генерирует «локально, на внутренних весах», отмечен, вызов инструментов отмечен, парсинг рассуждений отмечен — а публичный CI — нет, потому что он «заблокирован до выпуска весов». У кого-то есть чекпойнт. Никто его не опубликовал. И в отличие от vLLM, где каждый повторный PR сначала закрывал своего предшественника, в SGLang теперь открыты два активных пул-реквеста для одной и той же модели под двумя разными названиями.

То, во что складываются шесть интеграций за шесть недель, — это не более сильная версия того же сигнала, а другой сигнал. Шесть интеграций согласовывались бы с тем, что команда итерирует. Шесть интеграций под тремя именами — TeleChat4, XingChen4, Xing4_0 — это команда, которая публично перебирает имя, под которым модель будет выпущена, пока веса остаются закрытыми. Это непроверенный вывод, и это самое значимое из того, что теперь показывает след PR.

Что на самом деле добавляют два сентябрьских PR

Пул-реквест vLLM — это переименование августовской работы, а не её переписывание. Файл модели теперь — vllm/model_executor/models/xing4_0.py, класс — Xing4_0ForCausalLM, а model_type xing4_0 сопоставлен с DeepseekV3Config — той же конфигурацией Deep​Seek-V3, которую использовала версия XingChen4. Что он несёт:

• Полная реализация модели в vllm/model_executor/models/xing4_0.py — класс Xing4_0ForCausalLM, с прямым проходом, адаптером mHC и тензорно-параллельной реализацией load_weights(). В сообщении коммита отмечается, что поддерживаются как варианты DSA, так и не-DSA, с повторным использованием общих операций mhc_pre / mhc_post.

• Регистрация Xing4_0ForCausalLM в vllm/model_executor/models/registry.py, чтобы 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 — с сообщением коммита, указывающим, что для спекулятивного декодирования включена MTP-голова, совместимая с Deep​Seek-V3.

• Два файла документации — действительно новая часть и прямой откат августовского изменения. Исходный коммит содержал запись в документации и тестах, которую через час откатили как преждевременную; сентябрьский 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 (xing4_0)», PR описывает формат вызова инструментов модели: вызовы выводятся внутри блоков <tool_call>...</tool_call>, либо в виде JSON ({"name": ..., "arguments": {...}}), либо в виде формы на основе тегов с использованием <param_key>...</param_key> и <param_value>...</param_value>. Это уровень конкретики, которого не достигали более ранние PR, — деталь реализации формата чата модели, записанная в публичной документации крупного фреймворка, для чекпоинта, который никто не может скачать.

PR SGLang интереснее, потому что он содержит реализацию и конфиг, а не запись в реестре плюс документацию. Его строка в документации — первый случай, когда фреймворк указал имя вендора в собственной документации. В файле docs/docs/supported-models/generative_models.mdx в новой строке указана Xing4_0, при этом в столбце checkpoint указано `Xing4_0` (скоро) и описание: "MoE-модель China Telecom с MLA-вниманием и остаточными потоками mHC (Manifold-constrained Hyper-Connection); поддерживает нативное спекулятивное декодирование MTP, вызов инструментов и рассуждения." В строке vLLM было указано TBA и не назван вендор; в строке SGLang указано China Telecom и сказано «скоро». Ни то, ни другое не является датой релиза, а строка в документации фреймворка — не продукт.

В описании PR добавлено число, которого недоставало во всех предыдущих версиях этой истории. «В этом PR добавлена поддержка Xing4.0-29B-A4B (MoE на 29B параметров с ~4B активируемых параметров)». Там также приведена команда запуска — --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 утверждения, привязанные к приватному чекпоинту, а не как измерения, которые кто-либо может воспроизвести. Всё это согласно pull request и не воспроизведено.

Появление парсеров рассуждений и инструментов под обоими названиями важно по той же причине, что и в августе. Парсер рассуждений существует, чтобы удалять маркеры размышлений из вывода модели — внутреннюю цепочку рассуждений, которую модель выдаёт перед своим окончательным ответом. Парсер, созданный специально для этой модели, означает, что от семейства ожидают вариантов с поддержкой рассуждений, так же как TeleChat3 выпустила версии Thinking. Парсер инструментов вместе с теперь задокументированным форматом вызова означает, что также ожидается нативный вызов функций. Ни один из них не является гарантией относительно конечного продукта; оба — самые сильные подсказки, которые PR-ы несут о том, к чему стремится China Telecom.

Что нам известно на данный момент, с первого взгляда

Таблица результатов ниже — та, что была составлена для этой статьи 27 августа 2026 года по PR vLLM в том виде, в каком он тогда был. Она намеренно сохранена здесь как датированный снимок, а не перерисована, потому что каждая её строка остаётся верной три недели спустя — не выпущено, веса не опубликованы, бэкбон DeepSeek, остаточная связь mHC, оба парсера включены. Изменилось не значение на карточке, а всё вокруг неё: PR vLLM, на который она ссылается, был закрыт 7 сентября, работа вновь появилась под новым именем 16 сентября, SGLang последовал за переименованием через несколько часов, и вместе с ним появилось первое заявленное число параметров. На карточке нет ничего неверного. Она просто трёхнедельной давности, и история ушла дальше неё. Показатели FlagGems в её последней строке были перенесены в новый PR vLLM без изменений — по-прежнему заявлены в PR и по-прежнему невоспроизведены.

Архитектура, которую сливают PR.

Переименование файла не переименовывает архитектуру, а текст сводки в сентябрьском PR vLLM — это августовский текст, в котором Xing4_0 заменяет XingChen4, — пункт за пунктом. Сигнал несут два предложения:

• "Xing4_0 повторно использует базовую архитектуру DeepSeek-V2/V3 (внимание MLA, блок MoE, опциональный индексатор DSA)."

• «Она заменяет стандартное остаточное соединение на гиперсвязи с ограничением многообразия (mHC): остаточный поток расширяется в num_residual_streams параллельных потоков, смешиваемых входозависимыми дважды стохастическими матрицами, полученными с помощью проекции Синкхорна–Кноппа.»

За каждым пунктом стоит что-то конкретное. MLA — это Multi-head Latent Attention, схема сжатого внимания, которую DeepSeek представила в V2 и которая позволяет кэшу KV оставаться небольшим; MoE — это маршрутизация смеси экспертов, сохраняющая большое число параметров при малой активной доле. Необязательный индексатор DSA — это механизм DeepSeek Sparse Attention из линейки V3.2: лёгкий модуль скоринга, который выбирает top-k токенов для внимания, сокращая затраты на внимание с квадратичных до примерно линейных по длине контекста. А предложение про mHC — это главная новость: эта модель использует остаточную архитектуру, которую сама DeepSeek представила только в этом поколении.

PR в SGLang — первый, где публикуется структура этой вещи, а не её описание. Его файл конфигурации python/sglang/srt/configs/xing4_0.py объявляет 40 скрытых слоёв, размер скрытого слоя 3 584 и словарь из 131 072 токенов; MLA с рангом KV LoRA 512 и рангом query LoRA 768 на 32 головы; и разреженный MoE с 64 маршрутизируемыми экспертами плюс одним общим экспертом, маршрутизацией top-4, сигмоидной оценкой, масштабирующим коэффициентом маршрутизации 2.0 и выбором экспертов noaux_tc. Поля mHC тоже заданы явно: hc_mult 4, двадцать итераций Синкхорна — Кноппа, ограничение h_res на плюс-минус 30 и rope_theta 10 000 при максимальном позиционном эмбеддинге 262 144. Это значения по умолчанию в интеграции, которая ещё не выпущена, согласно pull request — файл конфигурации — это заявление о намерениях, а не карточка модели, и цифра 29B-A4B в описании PR нигде публично из них не выводится.

Одно поле важнее остальных, потому что именно здесь эта модель впервые заметно перестаёт быть копией DeepSeek. В конфиге SGLang задаётся hc_contract_for_draft, который объединяет потоки mHC обратно до собственного размера скрытого слоя модели перед финальной нормализацией и подаёт этот сжатый тензор в голову драфта Eagle. Вместо этого DeepSeek V4 подаёт mHC-развёрнутый тензор размером n × hidden_size. Комментарий в конфиге прямо об этом говорит, и это та деталь, которая всплывает только после того, как реализация была выверена по реальному чекпойнту, — а это, как утверждает чек-лист более раннего PR SGLang, у него есть, но он его не публикует.

Математика mHC — это то место, где два стека расходятся в реализации и совпадают в предположении. PR в vLLM отмечает, что он «соответствует общим операциям в vllm.model_executor.layers.mhc, поэтому приватные ядра не вводятся» — этот модуль существует, потому что vLLM уже поддерживает mHC для DeepSeek V4, так что дополнительные затраты на добавление этой модели невелики. SGLang приходит к тому же месту другой дорогой: его модуль mHC использует fused-ядра TileLang, зарегистрированные как пользовательские операции torch, а PR расширяет существующее ядро mhc_pre split-K, чтобы принимать hc_hidden_size 14 336 наряду с двумя размерами, которые оно уже обрабатывало. Он также отключает путь tf32_hc_prenorm_gemm в DeepGEMM для этой архитектуры, потому что этот путь — это чистое расширение C, которое torch.compile не может трассировать; вместо этого mHC переходит к ядру TileLang. Практический выигрыш одинаков в обоих фреймворках: если вы сегодня обслуживаете DeepSeek V4 на vLLM или SGLang, механизмы, которые будут обслуживать следующий MoE China Telecom, уже установлены.

mHC — трюк DeepSeek, лежащий в основе всего

Hyper-Connections с ограничением на многообразии стоит разобрать подробнее, потому что это самое интересное в этой модели — и это не изобретение China Telecom. Это изобретение DeepSeek.

История начинается с Hyper-Connections, предложенных командой Ki​mi в 2024 году. Стандартный Transformer хранит один остаточный поток на слой: вход добавляется к выходу слоя, что даёт градиентам чистый путь и позволяет сети выучить остаточную поправку. Hyper-Connections заменяет этот единственный поток несколькими параллельными потоками, которые на каждом слое смешиваются обучаемыми матрицами, предоставляя модели гораздо более богатый путь для передачи информации. Загвоздка — стабильность: неограниченные матрицы смешивания нарушают свойство тождественного отображения, которое делает остаточные связи обучаемыми, а в масштабе триллиона параметров функция потерь при обучении становится нестабильной.

Вклад DeepSeek, опубликованный в виде статьи mHC в декабре 2025 года, а затем использованный в DeepSeek V4, заключался в том, чтобы ограничить матрицы смешивания так, чтобы они были дважды стохастическими — неотрицательными, с суммами по каждой строке и каждому столбцу, равными единице, — что обеспечивалось проекцией Синкхорна — Кноппа во время обучения. Дважды стохастическая матрица имеет спектральный радиус, равный ровно единице, поэтому сигналы не могут экспоненциально усиливаться или затухать, проходя через сотни слоёв. Именно это ограничение обеспечивает стабильность обучения при масштабировании, а проекция настолько дешёвая, что DeepSeek сообщил лишь о примерно 6,7% накладных расходов на обучение при четырёх остаточных потоках. DeepSeek V4, выпущенный 24 апреля 2026 года, — флагманское применение этого подхода, с заявленным приростом примерно 15% в задачах математического рассуждения и контекстом в 1M токенов вдобавок.

Итак, если говорить простыми словами, эти PR-материалы сообщают следующее: следующая модель China Telecom берёт проверенную базовую архитектуру DeepSeek и новейший механизм остаточных связей DeepSeek, а не изобретает и то и другое с нуля. Это прагматичный выбор, и в нём есть тонкое подтверждение: вторая крупная лаборатория после самого DeepSeek, внедрившая mHC, считает этот приём готовым к продакшену.

В PR-ах mHC ещё не доведён до конца, и открытые пункты честно об этом говорят. Во всех PR-ах vLLM автор отмечает, что смещения чекпоинта (bias_pre, bias_post, bias_res) и ограничение h_res в настоящее время либо объединены, либо опущены, и что подтверждение рецензентом эквивалентности формул — это «главный вопрос корректности». Есть также пользовательская операция транспонирования, которая сохраняет тензор C-непрерывным для ядра TileLang, — переименованная вместе со всем остальным, из _xingchen4_transpose_contiguous в _xing4_0_transpose_contiguous, — и жёсткое ограничение: конвейерный параллелизм не поддерживается в режиме mHC, когда num_residual_streams больше единицы, тогда как тензорный параллелизм поддерживается. Ничто из этого не удивительно для черновика, но это та же незавершённая грань, что и в августе, и это само по себе показательно: шесть недель переименований не сдвинули с места вопрос корректности, а три красных прогона CI в новейшем PR SGLang — та же история в другом цвете. Что конфигурация SGLang действительно проясняет, так это количество потоков. При hc_mult, установленном в 4, и размере скрытого слоя 3 584, число 14 336 в патче ядра — это ровно четыре потока, и комментарий в ядре говорит об этом прямым текстом. Эта интерпретация была выводом из голого числа, когда этот материал впервые вышел; теперь она записана в конфигурационном файле.

Угол ускорения: FlagGems, снова

Вторая нить связывает эту модель с существующими отношениями China Telecom с Пекинской академией искусственного интеллекта, и это единственная нить, которая пережила все переименования без изменений. PR для vLLM включает опциональное ускорение FlagOS/FlagGems за флагом окружения USE_FLAGOS, отключённым по умолчанию, подставляя ядра горячего пути для MoE, attention, softmax и top-k. Заявленный выигрыш, по данным бенчмарка автора PR на H100 с высококонкурентной рабочей нагрузкой с длинными промптами (более 10 тыс. входных токенов, конкурентность 10): снижение времени до первого токена до 19,87% и снижение времени на выходной токен до 26,32%, при этом другие нагрузки остаются без изменений. Эти цифры заявлены в PR и не воспроизведены, и они сопровождаются флагом, отключённым по умолчанию.

Стоит зафиксировать, как мало затронуло переименование. Сентябрьский пул-реквест vLLM содержит те же цифры, ту же узкую оговорку о том, что флаг существует только внутри файла модели, и ту же инструкцию установить flagtree и flag-gems. Числа не изменились, потому что код не изменился; изменилась только метка. В пул-реквестах SGLang вообще нет никакой связи с FlagGems — вместо этого они идут по пути TileLang и DeepGEMM — что делает это спором о том, кому принадлежит оптимизация сервинг-слоя, а не о модели.

Это история преемственности. TeleChat3-36B-Thinking по состоянию на апрель 2026 года был первой крупной моделью, независимо портированной на FlagOS — открытый программный стек BAAI для ИИ. В каком бы виде эта модель ни выпускалась, продолжение этой линии — с ядрами FlagGems внутри её собственной интеграции с vLLM — говорит о том, что стратегия лаборатории в области отечественного стека распространяется и на сервисный слой, а не только на обучение.

Вопрос именования и семья, из которой он происходит

До 16 сентября вопрос об именовании был второстепенным. Теперь он почти закрыт, и все доказательства по-прежнему содержатся в названиях веток и оставшихся строках, а не в заявлениях, — но оба фреймворка сошлись на одном и том же ответе, двигаясь в одном и том же направлении.

• Сообщения коммитов, по порядку: «Добавить поддержку модели TeleChat4», затем «chore: откатить преждевременную документацию и тестовую запись для telechat4», затем — три недели спустя и за минуту до закрытия PR — «переименовать xingchen4». Коммит, единственной целью которого было переименование.

• Ветки форка. Первые два PR vLLM, #51237 и #54051, были ответвлены от zyp2014:supported_telechat4. Третий, #57135, — это zyp2014:support_xing4_0. Ветка была переименована тем же действием, которым переименовали модель, — и сторона SGLang теперь прошла идентичный путь в три шага: от support_telechat4 через support_xingchen4 к support_xing4_0.

• Основной текст #51237, в котором говорилось, что ускорение FlagGems было «для TeleChat4», тогда как в том же самом абзаце модель называлась XingChen4. Эти два названия уже конфликтовали в собственной сводке автора от 6 августа.

• Переименование файлов один к одному с обеих сторон. В vLLM это было переименование xingchen4.py в xing4_0.py и XingChen4ForCausalLM в Xing4_0ForCausalLM; в SGLang — xingchen4.py в xing4_0.py и XingChen4Config в Xing4_0Config, в ветке, которая вместе с этим тоже была переименована. Ни один из PR не оставил старое имя где-либо в своём diff.

Итак, в двух фреймворках фигурировали три имени, и картина согласуется с тем, что одну модель переименовывают по мере приближения к её будущему публичному названию. «Xing4_0» естественно читается как Xingchen 4.0 — семейство модели носит китайское название 星辰 (Xingchen) — но это всё ещё вывод из строки, а не то, что прямо утверждается в каком-либо PR. Не исключено и то, что TeleChat4 и XingChen4 — родственные модели одного поколения, а не одна модель под двумя именами, хотя общий форк, общий абзац об архитектуре, общие цифры FlagGems, общие открытые пункты и теперь общее переименование делают эту версию менее убедительной. Никто не подтвердил эту связь, а China Telecom не прокомментировала. Что изменилось — так это то, что переименование больше не является выбором одного контрибьютора: два независимых проекта по обслуживанию моделей, поддерживаемые разными людьми, оба с интервалом менее суток переименовали свою интеграцию, присвоив ей одно и то же третье имя.

Само семейство стоит держать в поле зрения, потому что оно объясняет прагматизм. Публичные релизы на данный момент выходили под брендом TeleChat:

• TeleChat-7B и TeleChat-12B, выпущенные в открытый доступ в январе 2024 года, с корпусом из 1 триллиона токенов.

• TeleChat2-115B (сентябрь 2024 г.), представленная как первая полностью отечественная открытая модель с триллионом параметров, а также её модели-собратья на 35B, 7B и 3B.

• TeleChat2-39B-A12B (март 2025 года), первая MoE в семействе.

• TeleChat3-105B-A4.7-Thinking (декабрь 2025 года), мелкозернистая модель MoE с общим количеством 105B и 4.7B активных параметров, обученная на 15 триллионах токенов, наряду с плотной моделью TeleChat3-36B и более поздней TeleChat3-Coder-36B-Thinking.

Если показатель 29B-A4B подтвердится, эта модель будет уступать TeleChat3-105B-A4.7-Thinking как по общему числу параметров, так и по числу активных параметров — это меньший и более дешёвый собрат, а не заменяющий флагман. Это трактовка, а не факт; ни в одном из двух PR не сказано, на какой уровень нацелена модель. Бренд Xingchen — это то, куда компания направляет свои усилия в области ИИ: лаборатория Xingchen AGI Lab была официально основана в Пекине в марте 2026 года, развивая то же семейство моделей, а China Telecom описывает свою систему «三全» (полномодальную, полноразмерную, полностью отечественную) как охватывающую семантические, речевые, визуальные и мультимодальные модели с числом параметров от 1B до 1T+. Переименование с TeleChat на Xingchen — именно то, что делает лаборатория, когда хочет, чтобы семейство моделей несло бренд лаборатории, а не бренд продуктовой линейки.

Чего мы до сих пор не знаем

Для модели на столь раннем этапе честный список всё ещё длиннее известного списка, хотя на этой неделе он сузился в двух местах:

• Дата выпуска не объявлена. Пять из шести интеграций — это черновики, открытые для раннего ревью кода, именно потому, что веса не опубликованы. Шестая, SGLang #39793, открыта для ревью, а не как черновик, — но она не смержена, все три её запуска CI падают, и ей нужен ревьюер, чтобы её одобрить. Объявленного графика нет.

• Количество параметров, но лишь заявленное. Во всех предыдущих версиях этого материала конфигурация MoE указывалась как нераскрытая. Пул-реквест в SGLang меняет это на бумаге: Xing4.0-29B-A4B, всего 29B, примерно 4B активных. Эта цифра взята из пул-реквеста, не привязана ни к одному публичному чекпоинту, не подтверждается ни одним конфигурационным файлом и не была воспроизведена никем за пределами проекта. Считайте это заявленным намерением, а не спецификацией.

• Никаких чисел бенчмарков — ни заявленных вендором, ни каких-либо иных, — и никаких независимых оценок. Проверочные стенограммы в PR SGLang показывают, как модель отвечает на промпт с рассуждением и выдаёт корректно оформленный вызов инструмента; они ничего не говорят о том, насколько хорошо она справляется ни с тем, ни с другим.

• Цена не указана, и лицензия не подтверждена. Все предыдущие выпуски TeleChat выходили под Apache-2.0, что обнадёживает, но для этого выпуска лицензия не заявлена.

• Публичных весов нет — подтверждено, а не предположено. По состоянию на 16 сентября 2026 года путь на Hugging Face, указанный в PR SGLang, публично недоступен для чтения, а организация, на которую он указывает, не перечисляет ни одной публичной модели; самая новая публичная запись в семействе — TeleChat3-Coder-36B-Thinking, появившаяся в январе. В таблице поддерживаемых моделей vLLM в столбце checkpoint указано TBA, у SGLang — «скоро», и в обоих PR SGLang не проходит публичный CI.

• Никаких официальных заявлений от China Telecom — ни анонса, ни весов, ни подтверждения названия или размера. Обратите внимание на эту асимметрию: строка в документации SGLang приписывает модель China Telecom, но это описание участника внутри пул-реквеста, а не заявление компании, а в описании самого нового PR имя вендора вообще не упоминается. Шесть интеграций, создаваемых для этой модели, — самое сильное на данный момент доказательство того, что она реальна, но интеграции закрывают, а кодовые имена меняются; две уже были закрыты. Ничего не подтверждено, пока лаборатория не скажет об этом.

Правильное прочтение всего этого — не скептицизм по отношению к модели; это точная картина раннего сигнала. То, что существует сегодня, — это реальный инженерный артефакт — шесть таких артефактов, в рамках двух фреймворков — с реальной архитектурой и впервые с приданной заявленной формой. Чего пока не существует — так это чего-либо, что можно скачать, вызвать или подвергнуть бенчмаркингу.

Самое близкое, что можно запустить сегодня.

Эту модель нигде нельзя запустить как сервис — ни через API, ни локально, потому что её веса не опубликованы. Ближайшая модель, которую читатель действительно может вызвать сегодня и которая обладает той же архитектурной ДНК, — это DeepSeek V4 Flash, которая использует ту же остаточную схему mHC поверх MLA и MoE, и именно она является эталонной реализацией, для которой создавались общие модули mHC в обоих фреймворках. Страница модели OrcaRouter для deepseek/deepseek-v4-flash указывает контекст в 1M токенов, максимальный вывод 384K и цены по прайс-листу: $0,15 за миллион входных токенов и $0,29 за миллион выходных — те же цифры, которые публикует сама DeepSeek, переданные с наценкой 0%, поэтому изменение цены у поставщика становится здесь актуальным в тот же день. Один API-ключ покрывает весь каталог, что делает сравнение её с остальной частью уровня моделей рассуждения правилом маршрутизации, а не новой интеграцией.

Это также практический ответ на вопрос «как мне опробовать эту модель, когда она выйдет». Совершенно новый, непроверенный чекпоинт — как раз тот случай, когда автоматическое переключение при сбое оправдывает себя: направьте на него долю трафика, оставьте проверенную модель в качестве резервной и позвольте слою маршрутизации принимать решение вместо того, чтобы делать ставку в продакшене на поведение первого дня. MoE на 29B с примерно 4B активных параметров, если появится именно такая модель, — дешёвый вариант для маршрутизации рядом с фронтирной моделью именно потому, что на каждый токен активируется так мало её частей. Если название снова изменится до релиза — а последние шесть недель намекают, что это возможно, — переписывать придётся правило маршрутизации, а не интеграцию.

Часто задаваемые вопросы

Почему PR в vLLM был закрыт?

Мы видим закрытие, но не причину. #54051 был закрыт самим автором 7 сентября 2026 года без слияния, и эта работа вновь появилась девять дней спустя как #57135 под новым названием. Более ранний PR в vLLM, #51237, был закрыт и заново подан в тот же день под тем же заголовком, так что закрытие и повторная подача — это характерная манера этого автора, а не признак проблем, — но в текстах PR причина не указана, и мы не собираемся её выдумывать.

Когда выйдет Xing4_0?

Даты нет. Пять из шести интеграций — это черновики, открытые для раннего обзора кода, и сами авторы планируют добавить тестовые записи, обновить документацию и пометить PR как готовые только после выпуска весов. Более старый чек-лист SGLang — самое ясное свидетельство текущего положения: «Модель загружается и генерирует (локально, на внутренних весах)» отмечен галочкой, а публичный CI «заблокирован до выпуска весов». Более новый PR SGLang подан как готовый к рассмотрению, а не как черновик, что является изменением позиции, а не изменением статуса — он не смержен, его CI красный, а строка в документации со словами «скоро» — это не запуск.

Является ли Xing4_0 той же моделью, что и XingChen4?

Почти наверняка да, и по PR это легко проверить: та же линия форка, тот же абзац об архитектуре, те же показатели бенчмарка FlagGems, те же открытые пункты, и переименование файл за файлом в обоих фреймворках — xingchen4.py в xing4_0.py, включая класс конфигурации, в ветках, переименованных в соответствии с этим. Это та же работа под новым именем, и по состоянию на 16 сентября и vLLM, и SGLang приняли это имя. Чего не говорится ни в одном PR — какое имя будет у выпущенного чекпоинта.

Это модель DeepSeek?

Нет. Это модель China Telecom из лаборатории Xingchen AGI Lab. Связь с DeepSeek — архитектурная: она переиспользует базовую архитектуру DeepSeek-V2/V3 и схему остаточных связей mHC, предложенную DeepSeek и реализованную в V4. Заимствование чьей-либо архитектуры — не то же самое, что связь между двумя проектами.

Что посмотреть дальше

PR всё ещё дают конкретный чек-лист, а пара от 16 сентября добавила в него два пункта. Во-первых, веса: каждый автор говорил, что его работа ждёт Hugging Face, поэтому появление публичного репозитория — это то самое несущее событие, и PR SGLang теперь даёт точный путь для отслеживания, XingChen-AGI/Xing4.0-29B-A4B, который сейчас ни у кого не резолвится. Во-вторых, сами PR: vLLM требует подтверждения формул смещения mHC, добавления записи теста в реестр и зелёного CI; SGLang #39793 требует исправления трёх красных прогонов и одобрения десяти запрошенных рецензентов, тогда как более старому #37228 всё ещё нужны его запись теста, его бенчмарк ускорения MTP и разблокированный CI. В-третьих, и это новое на этой неделе: закроет ли SGLang #37228 в пользу #39793 так, как vLLM всегда закрывал предшественника перед повторной подачей. Две живые интеграции для одной невыпущенной модели — это состояние, которое никто долго не поддерживает, и то, какая из них выживет, кое-что говорит о том, насколько близко это на самом деле. В-четвёртых, цифры: соответствует ли выпущенный чекпойнт форме 29B-A4B, MoE с 64 экспертами и контексту в 262 144 токена, которые теперь заявлены в конфиге и описании PR. В-пятых, проживёт ли третий PR vLLM дольше двух своих предшественников, которые продержались 21 и 11 дней соответственно, прежде чем были закрыты без слияния. И следите за тем, описывают ли парсеры рассуждений отдельный вариант Thinking так, как TeleChat3 выпустил свой.

Пока не произойдёт одно из этих событий, относитесь к этой модели как к тому, чем она является: хорошо специфицированный план от серьёзной лаборатории, застигнутый за подготовкой своей инфраструктуры для обслуживания — теперь уже в обоих основных открытых стеках для обслуживания, под именем, которое приняли оба, и с размером, указанным только в собственном pull request. Уже одна архитектура делает её достойной отслеживания: это второе крупное внедрение mHC после самого DeepSeek, от лаборатории, предыдущее поколение которой уже было мелкозернистой MoE, обученной на отечественных чипах. Когда выложат веса, не будет вопроса, работает ли она в vLLM или SGLang. Оба стека написали код трижды, под тремя разными именами.