Xing4_0 chega ao SGLang: um sexto PR, e o primeiro tamanho declarado, para o próximo MoE da China Telecom

Separadas por duas horas, em 16 de setembro de 2026, as duas stacks dominantes de serving de código aberto pararam de divergir sobre o nome. O vLLM registrou "[Model] Add Xing4_0 support" pela manhã; sgl-project/sglang seguiu com "feat: add Xing4_0 model support" às 10:38 UTC e, depois de seis semanas com três nomes em jogo, ambas as frameworks agora dizem Xing4_0. O pull request do SGLang traz algo que nenhum anterior trouxe: um tamanho. Ele descreve o modelo como Xing4.0-29B-A4B, um "MoE de 29B de parâmetros com ~4B de parâmetros ativados", e fornece um comando de lançamento que especifica um caminho de checkpoint, um contexto de 262.144 tokens e decodificação especulativa EAGLE. Este é o MoE ainda não lançado da China Telecom, o mesmo em torno do qual os pull requests do XingChen4 vêm girando desde agosto, e ele continua não lançado: os pesos não são públicos, o caminho de checkpoint indicado pelo PR não resolve para ninguém fora do projeto, nenhum fornecedor confirmou o nome nem o número, e nada nesta matéria foi verificado de forma independente. Fatos extraídos de pull requests são rotulados como tal; o resto é histórico e inferência. O modelo mais próximo que você pode realmente chamar hoje é o DeepSeek V4 Flash.

Este é um texto do tipo “o que sabemos até agora”, mantido atualizado em vez de recomeçado. Ele cobre a trilha de PR de seis semanas e como a questão de nomenclatura foi resolvida, o que os dois pull requests de 16 de setembro realmente acrescentam, a arquitetura que os arquivos de configuração agora vazam em detalhes concretos, e o que observar a seguir. A versão em uma frase: o próximo MoE da China Telecom é real o suficiente para ter acumulado seis integrações de serving, uma linha de tabela no vLLM marcada como TBA, uma entrada de documentação no SGLang marcada como “em breve” e uma contagem de parâmetros declarada — e ainda não é real o suficiente para rodar em qualquer lugar que você consiga acessar.

O sinal: seis integrações, três nomes, seis semanas

A trilha começa antes da versão desta matéria que foi noticiada inicialmente, e seu log de commits continua sendo o artefato mais revelador do vazamento. O primeiro PR do vLLM foi #51237, aberto em 6 de agosto de 2026 sob o título "[WIP][Model] Add upcoming XingChen4 model support". Seus três commits contam a história por si sós. O primeiro tem o título "Add TeleChat4 model support". O segundo, pouco mais de uma hora depois, é "chore: revert premature docs and test entry for telechat4" — a documentação e a entrada de teste no registro foram retiradas por serem prematuras. O terceiro, em 27 de agosto, é "rename xingchen4". Um minuto depois, o PR foi fechado sem ser mesclado e, onze minutos depois disso, #54051 foi aberto com o mesmo título, o mesmo branch do fork (supported_telechat4) e um único commit comprimido (squashed). Nesse intervalo, uma label needs-rebase havia sido adicionada, então isso se lê como um fechar e reabrir após a limpeza, e não como uma mudança de ideia. Tudo isso foi registrado a partir da conta do GitHub zyp2014, com cada commit tendo autoria e assinatura de zhangyp26 <zhangyp26@chinatelecom.com.cn>.

Esse segundo PR é aquele em torno do qual este artigo foi originalmente construído, e ele não está mais aberto. #54051 foi fechado pelo próprio autor em 7 de setembro de 2026, sem ter sido mesclado. Ainda assim, vale a pena citar sua descrição, porque é a frase que sobreviveu a todas as renomeações e a todas as reaberturas:

Os pesos do modelo ainda não são públicos no Hugging Face Hub. Este PR foi aberto para revisão antecipada do código. Assim que os pesos forem liberados, adicionarei uma entrada de teste em tests/models/registry.py, atualizarei docs/models/supported_models.md e marcarei o PR como pronto para revisão.

Essa frase é a forma de toda a história: o código está à frente dos pesos. A captura de tela abaixo é a página #54051 como estava em 27 de agosto de 2026, o dia em que foi aberta — um instantâneo datado, mantido porque o pull request que ela mostra foi fechado desde então. Leia-a como um registro do sinal naquele momento, não do seu status atual.

Então, em 16 de setembro, o padrão se repetiu — duas vezes em um único dia. #57135, "[Model] Adicionar suporte a Xing4_0," foi aberto naquela manhã pela mesma conta, zyp2014, com um único commit agora de autoria de um engenheiro diferente da China Telecom — xiongji <xiongj9@chinatelecom.cn>. Onze arquivos alterados, cerca de 1.300 inserções, um novo nome por toda parte, e a mesma ressalva no mesmo lugar: "Os pesos do modelo ainda não são públicos no Hugging Face Hub."

Duas horas e vinte minutos depois, a outra stack de serving deixou de estar um rename atrás. sgl-project/sglang #39793, "feat: add Xing4_0 model support", aberto a partir de um branch chamado support_xing4_0, e seu único commit carrega o mesmo endereço xiongji do rename do vLLM. Catorze arquivos e cerca de 1.400 inserções, das quais pouco mais de mil estão em um único arquivo de modelo. É a sexta integração protocolada para este modelo em seis semanas, e a primeira protocolada como não um rascunho: o GitHub o lista como aberto e pronto para revisão, com dez revisores solicitados — e todas as suas três execuções de CI já vermelhas.

O lado do SGLang antes de hoje funcionava da mesma forma que o da vLLM. #33982, “feat(model): adicionar suporte ao modelo TeleChat4”, foi aberto em 7 de agosto de 2026 pelo colaborador PaddyXj e fechado sem merge em 31 de agosto — no mesmo dia em que #37228, “feat: adicionar suporte ao modelo XingChen4”, foi aberto em seu lugar. Esse ainda está aberto como rascunho sob PaddyXj, em um branch chamado support_xingchen4, três commits à frente e com a última alteração em 8 de setembro. A checklist dele é a coisa mais interessante em qualquer um dos dois frameworks: o modelo carrega e gera “localmente, em pesos internos” está marcado, chamada de ferramentas está marcada, parsing de raciocínio está marcado — e a CI pública não está marcada, porque está “bloqueada na liberação dos pesos”. Alguém tem um checkpoint. Ninguém o publicou. E, ao contrário da vLLM, onde cada reenvio fechava o anterior primeiro, o SGLang agora tem dois pull requests ativos e abertos para o mesmo modelo, sob dois nomes diferentes.

O que seis integrações em seis semanas representam não é uma versão mais forte do mesmo sinal; é um sinal diferente. Seis integrações seriam consistentes com uma equipe iterando. Seis integrações sob três nomes — TeleChat4, XingChen4, Xing4_0 — são uma equipe iterando sobre o nome com que o modelo será lançado, em público, enquanto os pesos permanecem privados. Isso é uma inferência não verificada, e é a coisa de maior consequência que o rastro de PRs agora mostra.

O que os dois PRs de setembro realmente adicionam

O pull request do vLLM é uma renomeação do trabalho de agosto, e não uma reescrita dele. O arquivo do modelo agora é vllm/model_executor/models/xing4_0.py, a classe é Xing4_0ForCausalLM, e o model_type xing4_0 está mapeado para DeepseekV3Config — a mesma configuração do DeepSeek-V3 que a versão XingChen4 usava. O que ele traz:

• Uma implementação completa de modelo em vllm/model_executor/models/xing4_0.py — classe Xing4_0ForCausalLM, com forward pass, um adaptador mHC e uma implementação de load_weights() com paralelismo de tensores. A mensagem de commit observa que tanto as variantes DSA quanto as não DSA são suportadas, reutilizando as ops compartilhadas mhc_pre / mhc_post.

• Registro de Xing4_0ForCausalLM em vllm/model_executor/models/registry.py, para que o vLLM reconheça a arquitetura pelo nome.

• Um parser de raciocínio (vllm/reasoning/xing4_0_reasoning_parser.py) "para variantes com capacidade de raciocínio," e um parser de ferramentas (vllm/tool_parsers/xing4_0_tool_parser.py) para chamada automática de ferramentas.

• Registro em vllm/config/speculative.py, vllm/transformers_utils/model_arch_config_convertor.py e vllm/transformers_utils/config.py — com a mensagem de commit afirmando que um cabeçalho MTP compatível com o Deep​Seek-V3 está habilitado para decodificação especulativa.

• Dois arquivos de documentação — a parte genuinamente nova, e uma reversão direta de agosto. O commit original continha uma entrada de documentação e de teste que foi revertida uma hora depois, por ser prematura; o PR de setembro recoloca a documentação e está rotulado como documentação, novo modelo e chamada de ferramentas.

As entradas da documentação do vLLM são onde um leitor aprendeu algo concreto pela primeira vez. Em docs/models/supported_models.md, a nova linha apresenta `Xing4_0ForCausalLM` | Xing4_0 | TBA — a coluna de checkpoint diz literalmente TBA, que é o mesmo "ainda não" em uma fonte diferente. E em docs/features/tool_calling.md, sob o título "Xing4_0 Models (xing4_0)", o PR documenta o formato de chamada de ferramenta do modelo: as chamadas são emitidas dentro de blocos <tool_call>...</tool_call>, seja como JSON ({"name": ..., "arguments": {...}}) ou como uma forma baseada em tags que usa <param_key>...</param_key> e <param_value>...</param_value>. Esse é um nível de especificidade que os PRs anteriores não alcançaram — um detalhe de implementação do formato de chat do modelo, registrado na documentação pública de um grande framework, para um checkpoint que ninguém consegue baixar.

O PR do SGLang é mais interessante, porque traz uma implementação e uma configuração em vez de uma entrada de registro mais documentação. A sua linha na documentação é a primeira vez que um framework coloca o nome do fornecedor na sua própria documentação. Em docs/docs/supported-models/generative_models.mdx, a nova linha lista Xing4_0, com a coluna de checkpoint exibindo `Xing4_0` (em breve) e uma descrição: "O modelo MoE da China Telecom com atenção MLA e fluxos residuais mHC (Manifold-constrained Hyper-Connection); oferece suporte a decodificação especulativa MTP nativa, chamadas de ferramentas e raciocínio." A linha do vLLM dizia TBA e não nomeava nenhum fornecedor; a do SGLang nomeia a China Telecom e diz em breve. Nenhuma das duas é uma data de lançamento, e uma linha na documentação de um framework não é um produto.

A descrição do PR acrescenta o número que todas as versões anteriores desta história não tinham. "Este PR adiciona suporte ao Xing4.0-29B-A4B (MoE de 29B parâmetros com ~4B parâmetros ativados)." Ela também fornece um comando de lançamento — --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 — e afirma que a configuração foi verificada com paralelismo de tensores 2, um contexto de 262.144 tokens e decodificação especulativa EAGLE MTP, com transcrições de uma resposta de raciocínio e de uma chamada de ferramenta get_weather coladas na descrição como evidência. Os pesos por trás dessa verificação são do próprio autor: o caminho do repositório que o PR nomeia não é legível publicamente, e a organização no Hugging Face para a qual ele aponta não lista nenhum modelo público. Trate o tamanho, o comprimento do contexto e as transcrições como alegações relatadas no PR vinculadas a um checkpoint privado, não como medições que qualquer pessoa possa repetir. Tudo isso é conforme o pull request e não foi reproduzido.

O aparecimento dos parsers de raciocínio e de ferramentas sob ambos os nomes importa pelo mesmo motivo que importou em agosto. Um parser de raciocínio existe para remover marcadores de pensamento da saída de um modelo — a cadeia de pensamento interna que um modelo emite antes da sua resposta final. Um parser concebido especificamente para este modelo significa que se espera que a família tenha variantes capazes de raciocínio, tal como a TeleChat3 lançou edições Thinking. O parser de ferramentas, juntamente com o formato de chamada agora documentado, significa que também se espera chamada nativa de funções. Nenhum dos dois é uma garantia sobre o produto final; ambos são as pistas mais fortes que os PRs trazem sobre o que a China Telecom tem em vista.

O que sabemos até agora, num relance

O placar abaixo é o que foi compilado para este artigo em 27 de agosto de 2026, a partir do PR do vLLM como ele estava naquele momento. Ele é mantido aqui deliberadamente como um instantâneo datado, em vez de redesenhado, porque cada linha dele ainda é verdadeira três semanas depois — não lançado, pesos não públicos, backbone DeepSeek, residual mHC, ambos os parsers incluídos. O que mudou não é um valor no cartão, mas tudo ao redor dele: o PR do vLLM que ele cita foi fechado em 7 de setembro, o trabalho reapareceu sob um novo nome em 16 de setembro, o SGLang seguiu a renomeação horas depois, e o primeiro número declarado de parâmetros chegou junto com ela. Nada no cartão está errado. Ele simplesmente tem três semanas, e a história já o ultrapassou. Os números do FlagGems em sua última linha passaram para o novo PR do vLLM sem alterações, ainda reportados em PR e ainda não reproduzidos.

A arquitetura que os PRs vazam.

Renomear um arquivo não renomeia uma arquitetura, e o texto de resumo no PR de setembro do vLLM é o texto de agosto com Xing4_0 substituído por XingChen4 — cláusula por cláusula. Duas frases carregam o sinal:

• "Xing4_0 reutiliza o backbone DeepSeek-V2/V3 (atenção MLA, bloco MoE, indexador DSA opcional)."

• "Ela substitui a conexão residual padrão por Hiperconexões com Restrição de Manifold (mHC): o fluxo residual é expandido em num_residual_streams fluxos paralelos misturados por matrizes duplamente estocásticas dependentes da entrada, produzidas via projeção de Sinkhorn-Knopp."

Cada cláusula corresponde a algo concreto. MLA é Multi-head Latent Attention, o esquema de atenção comprimida que a DeepSeek introduziu na V2 e que permite manter o cache KV pequeno; MoE é o roteamento mixture-of-experts, que mantém uma grande contagem de parâmetros com uma pequena pegada ativa. O indexador DSA opcional é o mecanismo DeepSeek Sparse Attention da linha V3.2 — um módulo de pontuação leve que seleciona os top-k tokens nos quais prestar atenção, reduzindo o custo de atenção de quadrático para aproximadamente linear no comprimento do contexto. E a frase sobre mHC é a manchete: este modelo adota a arquitetura residual que a própria DeepSeek só introduziu nesta geração.

O PR do SGLang é o primeiro a publicar a forma da coisa em vez de descrevê-la. Seu arquivo de configuração, python/sglang/srt/configs/xing4_0.py, declara 40 camadas ocultas, um tamanho oculto de 3.584 e um vocabulário de 131.072 tokens; MLA com um rank de LoRA de KV de 512 e um rank de LoRA de consulta de 768 em 32 cabeças; e um MoE esparso com 64 especialistas roteados mais um especialista compartilhado, roteamento top-4, pontuação sigmoide, um fator de escala de roteamento de 2,0 e seleção de especialistas noaux_tc. Os campos do mHC também são explícitos: hc_mult 4, vinte iterações de Sinkhorn-Knopp, um clamp de h_res em mais ou menos 30, e um rope_theta de 10.000 com um embedding de posição máximo de 262.144. Esses são os valores padrão em uma integração que ainda não foi lançada, de acordo com o pull request — um arquivo de configuração é uma declaração de intenção, não um cartão de modelo, e o número 29B-A4B na descrição do PR não é derivado deles em nenhum lugar público.

Um campo vale mais do que os outros, porque é o primeiro ponto em que este modelo deixa visivelmente de ser uma cópia do DeepSeek. A configuração do SGLang define hc_contract_for_draft, que funde os fluxos mHC de volta ao próprio tamanho oculto do modelo antes da normalização final e alimenta esse tensor contraído à cabeça de rascunho Eagle. O DeepSeek V4, em vez disso, alimenta o tensor achatado por mHC n-times-hidden_size. O comentário da configuração diz isso explicitamente, e é o tipo de detalhe que só aparece depois que uma implementação foi moldada contra um checkpoint real — que é o que a checklist do PR anterior do SGLang afirma ter, sem publicá-lo.

A matemática do mHC é onde as duas stacks divergem na implementação e concordam na premissa. O PR do vLLM observa que ele "corresponde às ops compartilhadas em vllm.model_executor.layers.mhc, então nenhum kernel privado é introduzido" — esse módulo existe porque o vLLM já dá suporte a mHC para o DeepSeek V4, então o custo incremental de adicionar este modelo é pequeno. O SGLang chega ao mesmo lugar por um caminho diferente: seu módulo mHC usa kernels TileLang fundidos registrados como ops customizadas do torch, e o PR estende o kernel mhc_pre split-K existente para aceitar hc_hidden_size 14.336, ao lado dos dois tamanhos que ele já tratava. Ele também desativa o caminho tf32_hc_prenorm_gemm do DeepGEMM para esta arquitetura, porque esse caminho é uma extensão C bruta que o torch.compile não consegue rastrear; o mHC recorre ao kernel TileLang em vez disso. A vantagem prática é a mesma nos dois frameworks: se você serve o DeepSeek V4 no vLLM ou no SGLang hoje, a maquinaria que servirá o próximo MoE da China Telecom já está instalada.

mHC, o truque da DeepSeek no centro de tudo

Vale a pena destrinchar as Hiperconexões com Restrição de Variedade, porque é a coisa mais interessante deste modelo — e não é invenção da China Telecom. É da DeepSeek.

A história começa com Hyper-Connections, proposto pela equipe Ki​mi em 2024. Um Transformer padrão mantém um fluxo residual por camada: a entrada é adicionada à saída da camada, dando aos gradientes um caminho limpo e permitindo que a rede aprenda uma correção residual. Hyper-Connections substitui esse único fluxo por vários fluxos paralelos que são misturados por matrizes aprendidas em cada camada, dando ao modelo um caminho muito mais rico para a informação percorrer. O problema é a estabilidade: matrizes de mistura irrestritas quebram a propriedade de mapeamento identidade que torna as conexões residuais treináveis e, em escala de trilhões de parâmetros, a perda de treinamento fica instável.

A contribuição da DeepSeek, publicada como o artigo mHC em dezembro de 2025 e depois usada no DeepSeek V4, foi restringir as matrizes de mistura a serem duplamente estocásticas — não negativas, com linhas e colunas somando um —, imposto pela projeção de Sinkhorn-Knopp durante o treinamento. Uma matriz duplamente estocástica tem raio espectral exatamente igual a um, então os sinais não podem ser amplificados ou atenuados exponencialmente ao passarem por centenas de camadas. Esse limite é o que mantém o treinamento estável em escala, e a projeção é barata o suficiente para que a DeepSeek relatasse apenas cerca de 6,7% de sobrecarga de treinamento com quatro fluxos residuais. O DeepSeek V4, lançado em 24 de abril de 2026, é o uso principal disso, com um ganho relatado de aproximadamente 15% em tarefas de raciocínio matemático e, além disso, um contexto de 1M de tokens.

Então, em termos simples, o que esses comunicados de imprensa estão dizendo é: o próximo modelo da China Telecom usa o backbone comprovado da Deep​Seek e o mecanismo residual mais recente da Deep​Seek, em vez de inventar qualquer um dos dois do zero. Essa é uma escolha pragmática, e carrega uma confirmação sutil — o segundo grande laboratório, depois da própria Deep​Seek, a adotar o mHC acredita que o truque está pronto para produção.

Os PRs não estão concluídos com mHC, e os itens em aberto são honestos quanto a isso. Nos PRs do vLLM, o autor observa que os biases de checkpoint (bias_pre, bias_post, bias_res) e um clamp de h_res estão atualmente mesclados ou omitidos, e que a confirmação do revisor sobre a equivalência da fórmula é "a principal questão de correção". Há também um operador de transposição personalizado que mantém um tensor C-contíguo para um kernel TileLang — renomeado junto com todo o resto, de _xingchen4_transpose_contiguous para _xing4_0_transpose_contiguous — e uma limitação rígida: o paralelismo de pipeline não é suportado no modo mHC quando num_residual_streams é maior que um, enquanto o paralelismo de tensor é suportado. Nada disso é surpreendente para um rascunho, mas é a mesma aresta inacabada que era em agosto, o que é, por si só, informativo: seis semanas de renomeações não moveram a questão de correção, e as três execuções de CI em vermelho no PR mais recente do SGLang são a mesma história em uma cor diferente. O que a configuração do SGLang resolve é a contagem de streams. Com hc_mult definido como 4 e um tamanho oculto de 3.584, o 14.336 no patch do kernel é exatamente quatro streams — e o comentário do kernel diz isso com todas as letras. Essa leitura era uma inferência a partir de um número bruto quando este artigo foi publicado pela primeira vez; agora está registrada em um arquivo de configuração.

O ângulo de aceleração: FlagGems, novamente

Um segundo fio conecta este modelo ao relacionamento existente da China Telecom com a Academia de Inteligência Artificial de Pequim, e é o único fio que sobreviveu intacto a todas as renomeações. O PR do vLLM habilita a aceleração opcional do FlagOS/FlagGems por trás de uma flag de ambiente USE_FLAGOS, desativada por padrão, substituindo kernels de hot-path para MoE, atenção, softmax e top-k. O ganho alegado, a partir do benchmark H100 do autor do PR em uma carga de trabalho de prompt longo com alta concorrência (mais de 10 mil tokens de entrada, concorrência 10): até 19,87% menos tempo até o primeiro token e até 26,32% menos tempo por token de saída, com outras cargas de trabalho neutras. Esses números são relatados pelo PR e não reproduzidos, e vêm com a flag desativada por padrão.

O que vale a pena registrar é quão pouco a renomeação tocou. O PR de setembro do vLLM traz os mesmos números, a mesma nota de escopo restrito sobre a flag existir apenas dentro do arquivo do modelo, e a mesma instrução para instalar flagtree e flag-gems. Os números não mudaram porque o código não mudou; apenas o rótulo mudou. Os pull requests do SGLang não trazem nenhuma thread do FlagGems — eles seguem o caminho do TileLang e do DeepGEMM — o que faz disto um argumento sobre quem é dono da otimização da camada de serving, e não sobre o modelo.

Esta é uma história de continuidade. O TeleChat3-36B-Thinking era, em abril de 2026, o primeiro grande modelo portado de forma independente para o FlagOS, a pilha de software de IA de código aberto da BAAI. Independentemente da forma como este modelo for lançado, dar continuidade a esse fio — com kernels FlagGems dentro de sua própria integração com o vLLM — indica que a estratégia de stack doméstico do laboratório se estende até a camada de serving, e não apenas ao treinamento.

A questão da nomenclatura, e a família de onde ela vem

Até 16 de setembro, a questão da nomenclatura era um detalhe secundário. Agora está quase encerrada, e as evidências ainda estão todas em nomes de branches e strings remanescentes, em vez de declarações — mas os dois frameworks convergiram para a mesma resposta, vindo da mesma direção.

• As mensagens de commit, em ordem: "Adicionar suporte ao modelo TeleChat4", depois "chore: reverter documentação e entrada de teste prematuras para telechat4", então — três semanas depois e um minuto antes de o PR ser fechado — "renomear xingchen4". Um commit que tinha como único propósito a renomeação.

• O fork se ramifica. Os dois primeiros PRs do vLLM, #51237 e #54051, foram criados a partir de zyp2014:supported_telechat4. O terceiro, #57135, é zyp2014:support_xing4_0. O branch foi renomeado no mesmo movimento que renomeou o modelo — e o lado do SGLang agora percorreu o caminho idêntico em três etapas, de support_telechat4 passando por support_xingchen4 até support_xing4_0.

• O texto principal do #51237, que dizia que a aceleração do FlagGems era "para o TeleChat4", enquanto esse mesmo parágrafo chamava o modelo de XingChen4. Os dois nomes já colidiam no próprio resumo do autor, em 6 de agosto.

• A renomeação arquivo por arquivo em ambos os lados. No vLLM, foi xingchen4.py para xing4_0.py e XingChen4ForCausalLM para Xing4_0ForCausalLM; no SGLang, é xingchen4.py para xing4_0.py e XingChen4Config para Xing4_0Config, em um branch que mudou de nome junto. Nenhum dos PRs deixou o nome antigo em lugar algum do seu diff.

Portanto, três nomes estiveram em jogo em dois frameworks, e o padrão é compatível com um único modelo a ser renomeado à medida que se aproxima daquilo que será o seu nome público. «Xing4_0» lê-se naturalmente como Xingchen 4.0 — a família do modelo é comercializada como 星辰 (Xingchen) em chinês — mas isso continua a ser uma inferência a partir da string, não algo que qualquer PR declare abertamente. Poderia igualmente ser que TeleChat4 e XingChen4 sejam irmãos na mesma geração, em vez de um único modelo com dois nomes, embora o fork partilhado, o parágrafo de arquitetura partilhado, os números partilhados do FlagGems, os itens abertos partilhados e agora uma renomeação partilhada tornem isso mais difícil de sustentar. Ninguém confirmou a relação e a China Telecom não comentou. O que mudou é que a renomeação já não é uma escolha de um único contribuidor: dois projetos de serving independentes, mantidos por pessoas diferentes, mudaram ambos a etiqueta da sua integração para o mesmo terceiro nome no espaço de um dia um do outro.

A própria família vale a pena manter em vista, porque explica o pragmatismo. Os lançamentos públicos até agora receberam a marca TeleChat:

• TeleChat-7B e TeleChat-12B, disponibilizados como código aberto em janeiro de 2024 com um corpus de 1 trilhão de tokens.

• TeleChat2-115B (setembro de 2024), apresentado como o primeiro modelo aberto de um trilhão de parâmetros totalmente nacional, além dos irmãos de 35B, 7B e 3B.

• TeleChat2-39B-A12B (março de 2025), o primeiro MoE da família.

• TeleChat3-105B-A4.7-Thinking (dezembro de 2025), um MoE de granulação fina com 105B de parâmetros totais e 4.7B de parâmetros ativos, treinado em 15 trilhões de tokens, juntamente com o denso TeleChat3-36B e, posteriormente, o TeleChat3-Coder-36B-Thinking.

Se o número 29B-A4B se confirmar, este modelo ficaria abaixo do TeleChat3-105B-A4.7-Thinking tanto em parâmetros totais quanto ativos — um irmão menor e mais barato, em vez de um carro-chefe substituto. Isso é uma interpretação, não um fato; nada em nenhum dos PRs diz a que segmento o modelo se destina. A marca Xingchen é onde a empresa concentra seus esforços de IA: o Laboratório de AGI Xingchen foi formalmente estabelecido em Pequim em março de 2026, com base na mesma família de modelos, e a China Telecom descreve seu sistema "三全" (modal completo, tamanho completo, totalmente doméstico) como abrangendo modelos semânticos, de fala, de visão e multimodais, de 1B a 1T+ parâmetros. Uma mudança de nome de TeleChat para Xingchen é exatamente o que um laboratório faz quando quer que a família de modelos carregue a marca do laboratório, e não a marca da linha de produtos.

O que ainda não sabemos

Para um modelo tão recente, a lista honesta ainda é maior do que a lista conhecida, embora tenha diminuído em dois pontos esta semana:

• Sem data de lançamento. Cinco das seis integrações são rascunhos abertos para revisão antecipada de código, precisamente porque os pesos não são públicos. A sexta, SGLang #39793, está aberta para revisão em vez de rascunho — mas não foi mesclada, todas as três execuções de CI dela estão falhando e ela precisa que um revisor a aprove. Não há cronograma anunciado.

• Uma contagem de parâmetros, mas apenas alegada. Todas as versões anteriores deste texto listavam a configuração MoE como não divulgada. O PR do SGLang muda isso no papel: Xing4.0-29B-A4B, 29B no total, cerca de 4B ativos. O número vem de um pull request, não está associado a nenhum checkpoint público, não é corroborado por nenhum arquivo de configuração e não foi reproduzido por ninguém fora do projeto. Trate-o como uma intenção declarada, não como uma especificação.

• Nenhum número de benchmark, relatado pelo fornecedor ou de outra forma, e nenhuma pontuação independente. As transcrições de verificação no PR do SGLang mostram o modelo respondendo a um prompt de raciocínio e emitindo uma chamada de ferramenta bem formada; elas não mostram nada sobre quão bem ele se sai em nenhum dos dois casos.

• Sem preços e sem licença confirmada. Todas as versões anteriores do TeleChat são Apache-2.0, o que é encorajador, mas nenhuma licença foi declarada para esta.

• Nenhum peso público — confirmado, e não presumido. Em 16 de setembro de 2026, o caminho do Hugging Face que o PR do SGLang menciona não é legível publicamente, e a organização para a qual ele aponta não lista nenhum modelo público; a entrada pública mais recente da família é o TeleChat3-Coder-36B-Thinking, de janeiro. A tabela de modelos suportados do vLLM diz "a definir" na coluna de checkpoint, a do SGLang diz "em breve", e ambos os PRs do SGLang têm CI público com falhas.

• Nenhuma palavra oficial da China Telecom — nenhum anúncio, nenhum peso, nenhuma confirmação do nome ou do tamanho. Observe a assimetria com atenção: a linha da documentação do SGLang atribui o modelo à China Telecom, mas isso é a descrição de um contribuidor dentro de um pull request, não uma declaração da empresa, e a descrição do PR mais recente omite completamente o nome do fornecedor. Seis integrações sendo construídas para este modelo são a evidência mais forte até agora de que ele é real, mas integrações são encerradas e codinomes mudam; duas já foram. Nada está confirmado até que o laboratório se pronuncie.

A leitura correta de tudo isso não é ceticismo em relação ao modelo; é um retrato preciso de um sinal inicial. O que existe hoje é um artefato de engenharia real — seis deles, em dois frameworks — com uma arquitetura real e, pela primeira vez, uma forma declarada associada. O que ainda não existe é algo que você possa baixar, chamar ou avaliar em benchmark.

A coisa mais próxima que você pode executar hoje

Este modelo não pode ser servido em lugar nenhum — nem por meio de uma API, nem localmente, porque os pesos não são públicos. O modelo mais próximo que um leitor pode realmente chamar hoje e que compartilha seu DNA arquitetural é o DeepSeek V4 Flash, que usa o mesmo esquema residual mHC sobre MLA e MoE, e é a implementação de referência para a qual os módulos mHC compartilhados em ambas as estruturas foram criados.A página do modelo deepseek/deepseek-v4-flash no OrcaRouter lista um contexto de 1M de tokens, uma saída máxima de 384K e preço de tabela de US$ 0,15 por milhão de tokens de entrada e US$ 0,29 por milhão de saída — os mesmos números que a própria DeepSeek publica, repassados com 0% de margem, de modo que uma mudança de preço do fornecedor entra no ar aqui no mesmo dia.Uma única chave de API cobre o catálogo, o que torna a comparação dele com o resto do nível de raciocínio uma regra de roteamento em vez de uma nova integração.

Essa também é a resposta prática para "como eu faço para testar este modelo quando ele for lançado". Um checkpoint novinho em folha e não comprovado é exatamente onde o failover automático se justifica: encaminhe uma fração do tráfego para ele, mantenha um modelo comprovado como fallback e deixe a camada de roteamento tomar a decisão, em vez de apostar um caminho de produção no comportamento do primeiro dia. Um MoE de 29B com aproximadamente 4B parâmetros ativos, se for isso que chegar, é algo barato de rotear contra um modelo de fronteira, precisamente porque tão pouco dele é ativado por token. Se o nome mudar de novo entre agora e o lançamento — e as últimas seis semanas sugerem que pode — o que você reescreve é a regra de roteamento, não a integração.

Perguntas frequentes

Por que o PR do vLLM foi fechado?

Podemos ver o fechamento, não o motivo. O #54051 foi fechado pelo próprio autor em 7 de setembro de 2026 sem ter sido mesclado, e o trabalho reapareceu nove dias depois como #57135 sob um novo nome. Um PR anterior do vLLM, o #51237, foi fechado e reenviado no mesmo dia com o mesmo título, então fechar e reenviar é o padrão deste autor, e não um sinal de problema — mas os corpos dos PRs não declaram um motivo, e não vamos inventar um.

Quando o Xing4_0 será lançado?

Não há data. Cinco das seis integrações são rascunhos abertos para revisão de código antecipada, e os planos dos próprios autores são adicionar entradas de teste, atualizar a documentação e marcar os PRs como prontos somente quando os pesos forem lançados. A lista de verificação mais antiga do SGLang é a declaração mais clara de onde as coisas estão: "O modelo carrega e gera (localmente, com pesos internos)" está marcado, e a CI pública está "bloqueada pelo lançamento dos pesos". O PR mais recente do SGLang está registrado como pronto para revisão, e não como rascunho, o que é uma mudança de postura, e não de status — ele não foi mesclado, sua CI está vermelha, e uma linha de documentação dizendo "em breve" não é um lançamento.

O Xing4_0 é o mesmo modelo que o XingChen4?

Quase certamente sim, e os PRs facilitam a verificação: mesma linhagem de fork, mesmo parágrafo de arquitetura, mesmos números de benchmark do FlagGems, mesmos itens em aberto, e uma renomeação arquivo por arquivo em ambos os frameworks — xingchen4.py para xing4_0.py, incluindo a classe de configuração, em branches renomeadas para corresponder. É o mesmo trabalho sob um novo nome, e desde 16 de setembro tanto o vLLM quanto o SGLang adotaram esse nome. O que nenhum PR declara é qual nome um checkpoint lançado carregará.

Este é um modelo DeepSeek?

Não. É o modelo da China Telecom, do Xingchen AGI Lab. A ligação com a DeepSeek é arquitetural: ele reutiliza a espinha dorsal DeepSeek-V2/V3 e o esquema residual mHC que a DeepSeek propôs e lançou no V4. Adotar a arquitetura de outra pessoa não é o mesmo que os dois projetos estarem relacionados.

O que assistir em seguida

Os PRs ainda fornecem uma lista de verificação concreta, e o par de 16 de setembro acrescentou dois itens a ela. Primeiro, os pesos: todos os autores disseram que seu trabalho depende do Hugging Face, então o aparecimento de um repositório público é o evento determinante — e o PR do SGLang agora dá o caminho exato a observar, XingChen-AGI/Xing4.0-29B-A4B, que atualmente não resolve para ninguém. Segundo, os próprios PRs: o do vLLM precisa que as fórmulas de viés mHC sejam confirmadas, que a entrada de teste do registro seja adicionada e que sua CI esteja verde; o #39793 do SGLang precisa que suas três execuções vermelhas sejam corrigidas e que seus dez revisores solicitados aprovem, enquanto o mais antigo #37228 ainda precisa de sua entrada de teste, seu benchmark de aceleração MTP e uma CI desbloqueada. Terceiro, e novo esta semana: se o SGLang fecha o #37228 em favor do #39793, assim como o vLLM sempre fechou um predecessor antes de reenviar um novo. Duas integrações ativas para um modelo não lançado é um estado que ninguém mantém por muito tempo, e qual delas sobrevive diz algo sobre o quão perto isso realmente está. Quarto, os números: se um checkpoint lançado corresponde à forma 29B-A4B, ao MoE de 64 especialistas e ao contexto de 262.144 tokens que a configuração e a descrição do PR agora afirmam. Quinto, se o terceiro PR do vLLM sobrevive mais tempo do que seus dois predecessores, que duraram 21 e 11 dias, respectivamente, antes de serem fechados sem merge. E fique atento se os analisadores de raciocínio estão descrevendo uma variante Thinking separada, assim como o TeleChat3 lançou uma.

Até que uma dessas coisas aconteça, trate este modelo pelo que ele é: um plano bem especificado de um laboratório sério, flagrado no ato de preparar sua infraestrutura de serving — agora nas duas principais stacks de serving de código aberto, sob um nome que ambas adotaram e um tamanho que apenas seu próprio pull request declara. Só a arquitetura já o torna digno de acompanhamento: é a segunda grande adoção de mHC depois da própria DeepSeek, vinda de um laboratório cuja geração anterior já era um MoE de granularidade fina treinado em chips domésticos. Quando os pesos forem liberados, não haverá dúvida sobre ele rodar em vLLM ou SGLang. Ambas as stacks escreveram o código três vezes, sob três nomes diferentes.