Xing4_0 llega a SGLang: un sexto PR, y el primer tamaño declarado, para el próximo MoE de China Telecom

Con dos horas de diferencia, el 16 de septiembre de 2026, los dos stacks de servicio de código abierto dominantes dejaron de discrepar sobre el nombre. vLLM presentó «[Model] Add Xing4_0 support» por la mañana; sgl-project/sglang le siguió con «feat: add Xing4_0 model support» a las 10:38 UTC y, tras seis semanas con tres nombres en juego, ambos frameworks ahora dicen Xing4_0. El pull request de SGLang incluye algo que ningún otro anterior tenía: un tamaño. Describe el modelo como Xing4.0-29B-A4B, un «MoE de 29B parámetros con ~4B parámetros activados», y ofrece un comando de lanzamiento que indica una ruta de checkpoint, un contexto de 262.144 tokens y decodificación especulativa EAGLE. Este es el MoE no publicado de China Telecom, el mismo en torno al cual han girado los pull requests de XingChen4 desde agosto, y sigue sin publicarse: los pesos no son públicos, la ruta de checkpoint que menciona el PR no resuelve para nadie fuera del proyecto, ningún proveedor ha confirmado el nombre ni la cifra, y nada en este artículo está verificado de forma independiente. Los datos tomados de los pull requests se etiquetan como tales; el resto es historia e inferencia. El modelo más cercano que se puede invocar hoy es DeepSeek V4 Flash.

Esta es una pieza de lo que sabemos hasta ahora, que se mantiene actualizada en lugar de empezar de cero. Cubre el rastro de PR de seis semanas y cómo se resolvió la cuestión del nombre, qué añaden realmente las dos pull requests del 16 de septiembre, la arquitectura que los archivos de configuración ahora filtran con gran detalle, y qué hay que observar a continuación. La versión en una frase: el próximo MoE de China Telecom es lo suficientemente real como para haber acumulado seis integraciones de servicio, una fila de tabla en vLLM marcada como TBA, una entrada de documentación en SGLang marcada como "próximamente" y un recuento de parámetros declarado — y aún no lo suficientemente real como para ejecutarse en cualquier lugar al que puedas acceder.

La señal: seis integraciones, tres nombres, seis semanas

El rastro comienza antes de la versión de este artículo que se reportó en un primer momento, y su registro de commits sigue siendo el artefacto más revelador de la filtración. El primer PR de vLLM fue #51237, abierto el 6 de agosto de 2026 con el título «[WIP][Model] Add upcoming XingChen4 model support». Sus tres commits cuentan la historia por sí solos. El primero se titula «Add TeleChat4 model support». El segundo, apenas una hora después, es «chore: revert premature docs and test entry for telechat4» — la documentación y la entrada de prueba del registro se retiraron por considerarse prematuras. El tercero, el 27 de agosto, es «rename xingchen4». Un minuto después se cerró el PR sin fusionarlo, y once minutos más tarde #54051 se abrió con el mismo título, la misma rama del fork (supported_telechat4) y un único commit en squash. Entre medias se había añadido una etiqueta needs-rebase, así que esto se interpreta como un cierre y una reapertura tras una limpieza, más que como un cambio de opinión. Todo ello se presentó desde la cuenta de GitHub zyp2014, y cada commit fue escrito y firmado por zhangyp26 <zhangyp26@chinatelecom.com.cn>.

Ese segundo PR es aquel en torno al cual se construyó originalmente este artículo, y ya no está abierto. #54051 fue cerrado por su propio autor el 7 de septiembre de 2026, sin fusionarse. Aun así, vale la pena citar su descripción, porque es la frase que ha sobrevivido a cada cambio de nombre y a cada reapertura:

Los pesos del modelo aún no son públicos en Hugging Face Hub. Este PR está abierto para una revisión de código anticipada. Una vez que se publiquen los pesos, añadiré una entrada de prueba en tests/models/registry.py, actualizaré docs/models/supported_models.md y marcaré el PR como listo para revisión.

Esa frase es la forma de toda la historia: el código va por delante de los pesos. La captura de pantalla a continuación es la página #54051 tal como estaba el 27 de agosto de 2026, el día en que se abrió — una instantánea fechada, conservada porque la solicitud de extracción que muestra se ha cerrado desde entonces. Léela como un registro de la señal en ese momento, no de su estado actual.

Después, el 16 de septiembre, el patrón se repitió: dos veces en un solo día. #57135, «[Modelo] Añadir compatibilidad con Xing4_0», se abrió esa mañana desde la misma cuenta, zyp2014, con un único commit ahora firmado por otro ingeniero de China Telecom: xiongji <xiongj9@chinatelecom.cn>. Once archivos modificados, unas 1.300 inserciones, un nombre nuevo por todas partes y la misma advertencia en el mismo sitio: «Los pesos del modelo aún no son públicos en Hugging Face Hub».

Dos horas y veinte minutos después, la otra pila de servicio dejó de estar un renombrado por detrás. sgl-project/sglang #39793, "feat: agregar soporte para el modelo Xing4_0", abierto desde una rama llamada support_xing4_0, y su único commit lleva la misma dirección xiongji que el renombrado de vLLM. Catorce archivos y alrededor de 1.400 inserciones, de las cuales poco más de mil corresponden a un solo archivo de modelo. Es la sexta integración presentada para este modelo en seis semanas, y la primera que no se presenta como borrador: GitHub la muestra como abierta y lista para revisión, con diez revisores solicitados, y sus tres ejecuciones de CI ya en rojo.

El lado de SGLang, antes de hoy, funcionaba igual que el de vLLM. #33982, «feat(model): añadir soporte para el modelo TeleChat4», se abrió el 7 de agosto de 2026 por el colaborador PaddyXj y se cerró sin fusionar el 31 de agosto — el mismo día en que #37228, «feat: añadir soporte para el modelo XingChen4», se abrió en su lugar. Ese sigue abierto como borrador a nombre de PaddyXj, en una rama llamada support_xingchen4, con tres commits acumulados y última modificación el 8 de septiembre. Su lista de verificación es lo más interesante de cualquiera de los dos frameworks: que el modelo cargue y genere «localmente, con pesos internos» está marcado, la invocación de herramientas está marcada, el análisis de razonamiento está marcado — y la CI pública no está marcada, porque está «bloqueada a la espera de la publicación de los pesos». Alguien tiene un checkpoint. Nadie lo ha publicado. Y a diferencia de vLLM, donde cada nueva presentación cerraba primero la anterior, SGLang ahora tiene dos solicitudes de extracción activas abiertas para el mismo modelo, con dos nombres diferentes.

Lo que suman seis integraciones en seis semanas no es una versión más fuerte de la misma señal; es una diferente. Seis integraciones serían consistentes con un equipo iterando. Seis integraciones bajo tres nombres —TeleChat4, XingChen4, Xing4_0— es un equipo iterando sobre el nombre con el que se lanzará el modelo, en público, mientras los pesos permanecen privados. Esa es una inferencia no verificada, y es lo más trascendental que el rastro de PR muestra ahora.

Lo que realmente añaden los dos PRs de septiembre

La pull request de vLLM es un cambio de nombre del trabajo de agosto, más que una reescritura de este. El archivo del modelo ahora es vllm/model_executor/models/xing4_0.py, la clase es Xing4_0ForCausalLM y el model_type xing4_0 está asignado a DeepseekV3Config —la misma configuración de Deep​Seek-V3 que usaba la versión XingChen4. Lo que incluye:

• Una implementación completa del modelo en vllm/model_executor/models/xing4_0.py — clase Xing4_0ForCausalLM, con pasada hacia adelante, un adaptador mHC y una implementación de load_weights() con paralelismo de tensores. El mensaje de commit señala que se admiten tanto variantes DSA como no DSA, reutilizando las ops compartidas mhc_pre / mhc_post.

• Registro de Xing4_0ForCausalLM en vllm/model_executor/models/registry.py, para que vLLM conozca la arquitectura por su nombre.

• Un analizador de razonamiento (vllm/reasoning/xing4_0_reasoning_parser.py) "para variantes con capacidad de razonamiento", y un analizador de herramientas (vllm/tool_parsers/xing4_0_tool_parser.py) para la llamada automática a herramientas.

• Registro en vllm/config/speculative.py, vllm/transformers_utils/model_arch_config_convertor.py y vllm/transformers_utils/config.py — con el mensaje de commit que indica que se habilita una cabeza MTP compatible con Deep​Seek-V3 para la decodificación especulativa.

• Dos archivos de documentación: la parte genuinamente nueva y una reversión directa de lo de agosto. El commit original incluía una entrada de documentación y pruebas que se revirtió una hora después por prematura; el PR de septiembre vuelve a incorporar la documentación y está etiquetado como documentación, nuevo modelo y llamada a herramientas.

Las entradas de la documentación de vLLM son donde un lector aprendió por primera vez algo concreto. En docs/models/supported_models.md, la nueva fila dice `Xing4_0ForCausalLM` | Xing4_0 | TBA — la columna del checkpoint dice literalmente TBA, que es el mismo "aún no" en una tipografía diferente. Y en docs/features/tool_calling.md, bajo el encabezado "Modelos Xing4_0 (xing4_0)", el PR documenta el formato de llamada a herramientas del modelo: las llamadas se emiten dentro de bloques <tool_call>...</tool_call>, ya sea como JSON ({"name": ..., "arguments": {...}}) o como una forma basada en etiquetas que usa <param_key>...</param_key> y <param_value>...</param_value>. Ese es un nivel de especificidad que los PR anteriores no alcanzaron — un detalle de implementación del formato de chat del modelo, escrito en la documentación pública de un framework importante, para un checkpoint que nadie puede descargar.

El PR de SGLang es más interesante, porque incluye una implementación y una configuración en lugar de una entrada de registro más documentación. Su fila en la documentación es la primera vez que un framework ha puesto el nombre del proveedor en su propia documentación. En docs/docs/supported-models/generative_models.mdx, la nueva fila enumera Xing4_0, con la columna de checkpoint indicando `Xing4_0` (próximamente) y una descripción: "modelo MoE de China Telecom con atención MLA y flujos residuales mHC (Hyper-Connection restringida por manifold); admite decodificación especulativa MTP nativa, llamadas a herramientas y razonamiento." La fila de vLLM decía TBA y no nombraba a ningún proveedor; la de SGLang nombra a China Telecom y dice próximamente. Ninguna de las dos es una fecha de lanzamiento, y una fila en la documentación de un framework no es un producto.

La descripción del PR añade el número que faltaba en todas las versiones anteriores de esta historia. «Esta PR añade soporte para Xing4.0-29B-A4B (MoE de 29B parámetros con ~4B parámetros activados).» También proporciona un comando de lanzamiento — --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 indica que la configuración se verificó con paralelismo tensorial 2, un contexto de 262.144 tokens y decodificación especulativa EAGLE MTP, con transcripciones de una respuesta de razonamiento y una llamada a la herramienta get_weather pegadas en la descripción como evidencia. Los pesos detrás de esa verificación son del propio autor: la ruta del repositorio que indica la PR no es accesible públicamente, y la organización de Hugging Face a la que apunta no enumera ningún modelo público en absoluto. Considera el tamaño, la longitud de contexto y las transcripciones como afirmaciones reportadas en la PR asociadas a un checkpoint privado, no como mediciones que cualquiera pueda repetir. Todo esto es según la pull request y no ha sido reproducido.

El hecho de que los analizadores de razonamiento y de herramientas aparezcan bajo ambos nombres importa por la misma razón que importó en agosto. Un analizador de razonamiento existe para eliminar los marcadores de pensamiento de la salida de un modelo: la cadena de pensamiento interna que un modelo emite antes de su respuesta final. Un analizador diseñado específicamente para este modelo significa que se espera que la familia tenga variantes capaces de razonar, del mismo modo que TeleChat3 lanzó ediciones Thinking. El analizador de herramientas, junto con el formato de llamada ahora documentado, significa que también se espera la llamada nativa a funciones. Ninguno de los dos es una garantía sobre el producto final; ambos son las pistas más sólidas que contienen los PR acerca de a lo que apunta China Telecom.

Lo que sabemos hasta ahora, de un vistazo

El marcador que aparece a continuación es el que se compiló para este artículo el 27 de agosto de 2026, a partir del PR de vLLM tal como estaba entonces. Se conserva aquí deliberadamente como una instantánea fechada en lugar de redibujarse, porque cada línea de él sigue siendo cierta tres semanas después: sin publicar, pesos no públicos, backbone de DeepSeek, residual mHC, ambos parsers incluidos. Lo que ha cambiado no es un valor de la tarjeta, sino todo lo que la rodea: el PR de vLLM que cita se cerró el 7 de septiembre, el trabajo reapareció bajo un nuevo nombre el 16 de septiembre, SGLang siguió el cambio de nombre horas después y el primer recuento de parámetros declarado llegó con él. Nada en la tarjeta es incorrecto. Simplemente tiene tres semanas de antigüedad, y la historia ya lo ha superado. Las cifras de FlagGems en su última fila pasaron al nuevo PR de vLLM sin cambios, todavía reportadas en el PR y todavía sin reproducir.

La arquitectura que filtran los PRs

Renombrar un archivo no renombra una arquitectura, y el texto de resumen en el PR de vLLM de septiembre es el texto de agosto con Xing4_0 en sustitución de XingChen4 — cláusula por cláusula. Dos frases llevan la señal:

"Xing4_0 reutiliza la columna vertebral de Deep​Seek-V2/V3 (atención MLA, bloque MoE, indexador DSA opcional)."

Reemplaza la conexión residual estándar con Hiperconexiones restringidas por variedad (mHC): el flujo residual se expande en num_residual_streams flujos paralelos mezclados mediante matrices doblemente estocásticas dependientes de la entrada, producidas vía proyección de Sinkhorn-Knopp.

Cada cláusula corresponde a algo concreto. MLA es Multi-head Latent Attention, el esquema de atención comprimida que DeepSeek introdujo en V2 que permite que la caché KV se mantenga pequeña; MoE es el enrutamiento de mezcla de expertos, que mantiene un gran número de parámetros con una pequeña huella activa. El indexador DSA opcional es el mecanismo DeepSeek Sparse Attention de la línea V3.2: un módulo de puntuación ligero que selecciona los tokens top-k a los que prestar atención, lo que reduce el coste de atención de cuadrático a aproximadamente lineal en la longitud del contexto. Y la frase de mHC es el titular: este modelo adopta la arquitectura residual que la propia DeepSeek solo introdujo en esta generación.

La PR de SGLang es la primera que publica la forma de la cosa en lugar de describirla. Su archivo de configuración, python/sglang/srt/configs/xing4_0.py, declara 40 capas ocultas, un tamaño oculto de 3.584 y un vocabulario de 131.072 tokens; MLA con un rango de LoRA de KV de 512 y un rango de LoRA de consulta de 768 en 32 cabezas; y un MoE disperso con 64 expertos enrutados más un experto compartido, enrutamiento top-4, puntuación sigmoide, un factor de escala enrutado de 2,0 y selección de expertos noaux_tc. Los campos de mHC también son explícitos: hc_mult 4, veinte iteraciones de Sinkhorn-Knopp, un clamp de h_res en más o menos 30, y un rope_theta de 10.000 con un embedding de posición máximo de 262.144. Estos son los valores predeterminados en una integración que no se ha lanzado, según la pull request — un archivo de configuración es una declaración de intenciones, no una tarjeta de modelo, y la cifra 29B-A4B en la descripción de la PR no se deriva de ellos en ningún lugar público.

Un campo vale más que los demás, porque es el primer lugar donde este modelo deja visiblemente de ser una copia de DeepSeek. La configuración de SGLang establece hc_contract_for_draft, que fusiona los flujos de mHC de vuelta al tamaño oculto propio del modelo antes de la normalización final y alimenta ese tensor contraído a la cabeza de borrador Eagle. DeepSeek V4 alimenta en su lugar el tensor n-times-hidden_size aplanado por mHC. El comentario de la configuración lo dice explícitamente, y es el tipo de detalle que solo aparece cuando una implementación se ha moldeado contra un checkpoint real —que es lo que la lista de verificación del PR anterior de SGLang afirma tener, sin publicarlo.

La matemática de mHC es donde los dos stacks divergen en la implementación y coinciden en el supuesto. El PR de vLLM señala que "coincide con las operaciones compartidas en vllm.model_executor.layers.mhc, por lo que no se introducen kernels privados" — ese módulo existe porque vLLM ya admite mHC para DeepSeek V4, así que el costo incremental de añadir este modelo es pequeño. SGLang llega al mismo punto por un camino distinto: su módulo de mHC usa kernels fusionados de TileLang registrados como operaciones personalizadas de torch, y el PR amplía el kernel split-K mhc_pre existente para aceptar hc_hidden_size 14,336 junto con los dos tamaños que ya manejaba. También desactiva la ruta tf32_hc_prenorm_gemm de DeepGEMM para esta arquitectura, porque esa ruta es una extensión C sin procesar que torch.compile no puede trazar; en su lugar, mHC recurre al kernel de TileLang. La ventaja práctica es la misma en ambos frameworks: si hoy sirves DeepSeek V4 en vLLM o SGLang, la maquinaria que servirá el próximo MoE de China Telecom ya está instalada.

mHC, el truco de Deep​Seek en el centro de todo

Merece la pena desglosar Manifold-constrained Hyper-Connections, porque es el aspecto más interesante de este modelo —y no es un invento de China Telecom. Es de DeepSeek.

La historia comienza con Hyper-Connections, propuesto por el equipo de Ki​mi en 2024. Un Transformer estándar mantiene un único flujo residual por capa: la entrada se suma a la salida de la capa, lo que da a los gradientes una ruta limpia y permite que la red aprenda una corrección residual. Hyper-Connections reemplaza ese único flujo por varios flujos paralelos que se mezclan mediante matrices aprendidas en cada capa, lo que da al modelo una ruta mucho más rica para que viaje la información. El problema es la estabilidad: las matrices de mezcla sin restricciones rompen la propiedad de mapeo identidad que hace que las conexiones residuales sean entrenables y, a escala de billones de parámetros, la pérdida de entrenamiento se vuelve inestable.

La contribución de DeepSeek, publicada como el artículo mHC en diciembre de 2025 y luego usada en DeepSeek V4, consistió en restringir las matrices de mezcla para que fueran doblemente estocásticas —no negativas, con filas y columnas que suman uno cada una—, algo impuesto mediante la proyección de Sinkhorn-Knopp durante el entrenamiento. Una matriz doblemente estocástica tiene un radio espectral de exactamente uno, por lo que las señales no pueden amplificarse ni atenuarse exponencialmente a medida que atraviesan cientos de capas. Esa cota es lo que mantiene estable el entrenamiento a escala, y la proyección es lo bastante barata como para que DeepSeek informara de solo alrededor del 6,7 % de sobrecarga de entrenamiento con cuatro flujos residuales. DeepSeek V4, lanzado el 24 de abril de 2026, es su aplicación insignia, con una ganancia reportada de aproximadamente el 15 % en tareas de razonamiento matemático y, además, un contexto de 1 millón de tokens.

Así que lo que dicen estos PRs, en términos sencillos, es: el próximo modelo de China Telecom toma la arquitectura troncal probada de DeepSeek y el mecanismo residual más reciente de DeepSeek en lugar de inventar cualquiera de los dos desde cero. Es una elección pragmática y conlleva una confirmación sutil: el segundo gran laboratorio en adoptar mHC, después del propio DeepSeek, cree que el truco está listo para producción.

Las PR no están terminadas con mHC, y los puntos abiertos son honestos al respecto. En las PR de vLLM, el autor señala que los sesgos del checkpoint (bias_pre, bias_post, bias_res) y un clamp de h_res actualmente están fusionados u omitidos, y que la confirmación por parte de los revisores de la equivalencia de fórmulas es "la principal cuestión de corrección". También hay una operación de transposición personalizada que mantiene un tensor C-contiguo para un kernel de TileLang —renombrada junto con todo lo demás, de _xingchen4_transpose_contiguous a _xing4_0_transpose_contiguous— y una limitación severa: el paralelismo de pipeline no es compatible con el modo mHC cuando num_residual_streams es mayor que uno, mientras que el paralelismo de tensores sí es compatible. Nada de esto es sorprendente para un borrador, pero sigue siendo el mismo borde inacabado que era en agosto, lo cual es informativo en sí mismo: seis semanas de renombrados no han movido la cuestión de corrección, y las tres ejecuciones rojas de CI en la PR más reciente de SGLang son la misma historia en otro color. Lo que sí resuelve la configuración de SGLang es el número de streams. Con hc_mult establecido en 4 y un tamaño oculto de 3.584, el 14.336 del parche del kernel son exactamente cuatro streams —y el comentario del kernel lo dice con todas las letras. Esa lectura era una inferencia a partir de un número a secas cuando este artículo se publicó por primera vez; ahora está escrita en un archivo de configuración.

El ángulo de aceleración: FlagGems, de nuevo.

Un segundo hilo vincula este modelo con la relación existente de China Telecom con la Academia de Inteligencia Artificial de Pekín, y es el único hilo que ha sobrevivido intacto a todos los cambios de nombre. La PR de vLLM habilita la aceleración opcional de FlagOS/FlagGems tras un flag de entorno USE_FLAGOS, desactivado por defecto, sustituyendo kernels de ruta crítica para MoE, atención, softmax y top-k. El beneficio declarado, según el benchmark en H100 del autor de la PR sobre una carga de trabajo de prompt largo y alta concurrencia (más de 10 000 tokens de entrada, concurrencia 10): hasta un 19,87 % menos de tiempo hasta el primer token y hasta un 26,32 % menos de tiempo por token de salida, con otras cargas de trabajo neutrales. Esas cifras las reporta la PR y no han sido reproducidas, y vienen con el flag desactivado por defecto.

Lo que vale la pena registrar es lo poco que tocó el cambio de nombre. El PR de vLLM de septiembre lleva las mismas cifras, la misma nota de alcance limitado sobre que el flag solo vive dentro del archivo del modelo, y la misma instrucción de instalar flagtree y flag-gems. Los números no cambiaron porque el código no cambió; solo lo hizo la etiqueta. Los pull requests de SGLang no llevan ningún hilo de FlagGems en absoluto —en su lugar, toman la ruta de TileLang y DeepGEMM—, lo que convierte esto en una discusión sobre quién posee la optimización de la capa de servicio, no sobre el modelo.

Esta es una historia de continuidad. TeleChat3-36B-Thinking era, en abril de 2026, el primer modelo grande portado de forma independiente a FlagOS, la pila de software de IA de código abierto de BAAI. Sea cual sea la forma en que se entregue este modelo, continuar esa línea —con kernels de FlagGems dentro de su propia integración con vLLM— indica que la estrategia de pila nacional del laboratorio se extiende hasta la capa de servicio, no solo al entrenamiento.

La cuestión del nombre, y la familia de la que procede

Hasta el 16 de septiembre, la cuestión del nombre era una nota al margen. Ahora está casi cerrada, y la evidencia sigue estando toda en nombres de ramas y cadenas sobrantes en lugar de declaraciones — pero los dos frameworks han convergido en la misma respuesta desde la misma dirección.

• Los mensajes de commit, en orden: «Añadir soporte para el modelo TeleChat4», luego «chore: revertir la documentación y la entrada de prueba prematuras para telechat4», luego —tres semanas después y un minuto antes de que se cerrara el PR— «renombrar xingchen4». Un commit cuyo único propósito era el cambio de nombre.

• El fork se ramifica. Los dos primeros PR de vLLM, #51237 y #54051, se crearon a partir de zyp2014:supported_telechat4. El tercero, #57135, es zyp2014:support_xing4_0. La rama se renombró en el mismo movimiento que renombró el modelo — y el lado de SGLang ahora ha recorrido la misma ruta en tres pasos, desde support_telechat4 pasando por support_xingchen4 hasta support_xing4_0.

• El cuerpo del texto de #51237, que decía que la aceleración de FlagGems era "para TeleChat4" mientras que el mismísimo párrafo llamaba al modelo XingChen4. Los dos nombres ya colisionaban en el propio resumen del autor el 6 de agosto.

• El renombrado archivo por archivo en ambos lados. En vLLM fue de xingchen4.py a xing4_0.py y de XingChen4ForCausalLM a Xing4_0ForCausalLM; en SGLang es de xingchen4.py a xing4_0.py y de XingChen4Config a Xing4_0Config, en una rama que cambió de nombre junto con ello. Ninguno de los PR dejó atrás el nombre antiguo en ninguna parte de su diff.

Así que tres nombres han estado en juego en dos frameworks, y el patrón es consistente con un único modelo que se renombra a medida que se acerca a lo que sea que vaya a ser su nombre público. «Xing4_0» se lee de forma natural como Xingchen 4.0 —la familia del modelo lleva la marca 星辰 (Xingchen) en chino—, pero eso sigue siendo una inferencia a partir de la cadena, no algo que ningún comunicado de prensa afirme abiertamente. También podría ser que TeleChat4 y XingChen4 sean hermanos de la misma generación en lugar de un solo modelo con dos nombres, aunque el fork compartido, el párrafo de arquitectura compartido, los números compartidos de FlagGems, los elementos abiertos compartidos y ahora un renombrado compartido hacen que eso sea más difícil de sostener. Nadie ha confirmado la relación y China Telecom no ha comentado. Lo que ha cambiado es que el renombrado ya no es la elección de un solo colaborador: dos proyectos de servicio independientes, mantenidos por personas distintas, han reetiquetado ambos su integración al mismo tercer nombre con un día de diferencia entre uno y otro.

La propia familia merece tenerse en cuenta, porque explica el pragmatismo. Los lanzamientos públicos hasta la fecha llevan la marca TeleChat:

TeleChat-7B y TeleChat-12B, publicados como código abierto en enero de 2024 con un corpus de un billón de tokens.

• TeleChat2-115B (septiembre de 2024), presentado como el primer modelo abierto de un billón de parámetros totalmente nacional, además de sus hermanos de 35B, 7B y 3B.

• TeleChat2-39B-A12B (marzo de 2025), el primer MoE de la familia.

TeleChat3-105B-A4.7-Thinking (diciembre de 2025), un MoE de grano fino con 105B de parámetros totales y 4.7B activos, entrenado con 15 billones de tokens, junto con el denso TeleChat3-36B y el posterior TeleChat3-Coder-36B-Thinking.

Si la cifra 29B-A4B se mantiene, este modelo se situaría por debajo de TeleChat3-105B-A4.7-Thinking tanto en parámetros totales como activos —un hermano menor y más barato en lugar de un buque insignia de reemplazo. Eso es una interpretación, no un hecho; nada en ninguno de los PR dice a qué gama está dirigido el modelo. La marca Xingchen es donde la compañía pone su esfuerzo en IA: el Xingchen AGI Lab se estableció formalmente en Pekín en marzo de 2026, construyendo sobre la misma familia de modelos, y China Telecom describe su sistema "三全" (modalidad completa, tamaño completo, totalmente nacional) como abarcando modelos semánticos, de voz, de visión y multimodales desde 1B hasta 1T+ parámetros. Un cambio de nombre de TeleChat a Xingchen es exactamente lo que hace un laboratorio cuando quiere que la familia de modelos lleve la marca del laboratorio en lugar de la marca de la línea de productos.

Lo que todavía no sabemos

Para un modelo tan temprano, la lista honesta sigue siendo más larga que la lista conocida, aunque se ha reducido en dos puntos esta semana:

• No hay fecha de lanzamiento. Cinco de las seis integraciones son borradores abiertos para una revisión temprana del código, precisamente porque los pesos no son públicos. La sexta, SGLang #39793, está abierta para revisión en lugar de ser un borrador — pero no está fusionada, sus tres ejecuciones de CI están fallando y necesita que un revisor la apruebe. No hay un calendario anunciado.

• Un conteo de parámetros, pero solo uno declarado. Todas las versiones anteriores de este artículo indicaban la configuración MoE como no divulgada. El PR de SGLang cambia eso sobre el papel: Xing4.0-29B-A4B, 29B en total, aproximadamente 4B activos. La cifra proviene de una pull request, no está vinculada a ningún checkpoint público, no la corrobora ningún archivo de configuración y nadie fuera del proyecto la ha reproducido. Trátala como una intención declarada, no como una especificación.

• Ninguna cifra de benchmark, ya sea reportada por el proveedor o de otro tipo, y ninguna puntuación independiente. Las transcripciones de verificación del PR de SGLang muestran al modelo respondiendo a un prompt de razonamiento y emitiendo una llamada a herramienta bien formada; tampoco muestran nada sobre qué tan bien hace cualquiera de las dos cosas.

• Sin precios y sin licencia confirmada. Todas las versiones anteriores de TeleChat son Apache-2.0, lo cual es alentador, pero no se ha indicado ninguna licencia para esta.

• Sin pesos públicos —confirmado, no supuesto—. A fecha de 16 de septiembre de 2026, la ruta de Hugging Face que menciona el PR de SGLang no es de acceso público, y la organización a la que apunta no enumera ningún modelo público; la entrada pública más reciente de la familia es TeleChat3-Coder-36B-Thinking, de enero. La tabla de modelos compatibles de vLLM dice TBA en la columna de checkpoint, la de SGLang dice «próximamente», y ambos PR de SGLang tienen la CI pública fallando.

• Ninguna palabra oficial de China Telecom: ningún anuncio, ningún peso, ninguna confirmación del nombre ni del tamaño. Observa la asimetría con atención: la fila de la documentación de SGLang atribuye el modelo a China Telecom, pero eso es la descripción de un colaborador dentro de una pull request, no una declaración de la empresa, y la descripción de la PR más reciente omite por completo el nombre del proveedor. Que haya seis integraciones desarrollándose para este modelo es la evidencia más sólida hasta ahora de que es real, pero las integraciones se cierran y los nombres en clave cambian; dos ya se han cerrado. Nada está confirmado hasta que el laboratorio lo diga.

La lectura correcta de todo esto no es escepticismo sobre el modelo; es una imagen precisa de una señal temprana. Lo que existe hoy es un artefacto de ingeniería real —seis de ellos, en dos frameworks— con una arquitectura real y, por primera vez, una forma declarada asociada. Lo que aún no existe es algo que puedas descargar, invocar o medir con benchmarks.

Lo más cercano que puedes ejecutar hoy

Este modelo no se puede servir en ningún sitio —ni a través de una API ni de forma local— porque los pesos no son públicos. El modelo más cercano que un lector puede invocar realmente hoy y que comparte su ADN arquitectónico es DeepSeek V4 Flash, que utiliza el mismo esquema residual mHC sobre MLA y MoE, y es la implementación de referencia para la que se crearon los módulos mHC compartidos en ambos frameworks.La página del modelo de OrcaRouter para deepseek/deepseek-v4-flash enumera un contexto de 1M de tokens, una salida máxima de 384K y precios de lista de $0.15 por millón de tokens de entrada y $0.29 por millón de salida —las mismas cifras que publica el propio DeepSeek, trasladadas con un 0 % de margen, por lo que un cambio de precio del proveedor se aplica aquí el mismo día.Una sola clave de API cubre el catálogo, lo que hace que compararlo con el resto del nivel de razonamiento sea una regla de enrutamiento en lugar de una nueva integración.

Esa es también la respuesta práctica a «cómo pruebo este modelo cuando se lance». Un checkpoint nuevo y no probado es exactamente donde la conmutación por error automática demuestra su valor: enruta una fracción del tráfico hacia él, mantén un modelo probado como respaldo y deja que la capa de enrutamiento tome la decisión en lugar de apostar una ruta de producción al comportamiento del primer día. Un MoE de 29B con aproximadamente 4B de parámetros activos, si eso es lo que llega, es algo barato contra lo que enrutar frente a un modelo de frontera precisamente porque se activa muy poco de él por token. Si el nombre vuelve a cambiar entre ahora y el lanzamiento —y las últimas seis semanas sugieren que podría—, la regla de enrutamiento es lo que reescribes, no la integración.

Preguntas frecuentes

¿Por qué se cerró el PR de vLLM?

Vemos el cierre, no el motivo. #54051 fue cerrado por su propio autor el 7 de septiembre de 2026 sin que se fusionara, y el trabajo reapareció nueve días después como #57135 bajo un nuevo nombre. Un PR anterior de vLLM, #51237, se cerró y se volvió a presentar el mismo día con el mismo título, así que cerrar y volver a presentar es el patrón de este autor más que una señal de problemas — pero los cuerpos de los PR no indican un motivo y no vamos a inventarnos uno.

¿Cuándo se lanzará Xing4_0?

No hay fecha. Cinco de las seis integraciones son borradores abiertos para una revisión temprana del código, y los planes de los propios autores son añadir entradas de prueba, actualizar la documentación y marcar los PR como listos solo cuando se publiquen los pesos. La antigua lista de verificación de SGLang es la declaración más clara de la situación: «El modelo carga y genera (localmente, con pesos internos)» está marcada, y la CI pública está «bloqueada hasta la publicación de los pesos». El PR más reciente de SGLang se presenta como listo para revisión en lugar de como borrador, lo cual es un cambio de postura más que un cambio de estado: no está fusionado, su CI está en rojo, y una fila en la documentación que diga «próximamente» no es un lanzamiento.

¿Es Xing4_0 el mismo modelo que XingChen4?

Casi con total seguridad que sí, y los PR lo ponen fácil de comprobar: el mismo linaje de fork, el mismo párrafo de arquitectura, las mismas cifras de benchmark de FlagGems, los mismos asuntos pendientes y un renombrado archivo por archivo en ambos frameworks —de xingchen4.py a xing4_0.py, incluida la clase de configuración, en ramas renombradas para que coincidan—. Es el mismo trabajo con un nuevo nombre, y a fecha de 16 de septiembre tanto vLLM como SGLang han adoptado ese nombre. Lo que ningún PR indica es qué nombre llevará un checkpoint publicado.

¿Es este un modelo de Deep​Seek?

No. Es el modelo de China Telecom, del Xingchen AGI Lab. La conexión con Deep​Seek es arquitectónica: reutiliza la arquitectura troncal de Deep​Seek-V2/V3 y el esquema residual mHC que Deep​Seek propuso y lanzó en V4. Adoptar la arquitectura de otro no es lo mismo que los dos proyectos estén relacionados.

Qué ver a continuación

Las PR siguen ofreciendo una lista de verificación concreta, y el par del 16 de septiembre le añadió dos puntos. Primero, los pesos: todos los autores han dicho que su trabajo depende de Hugging Face, así que la aparición de un repositorio público es el acontecimiento determinante —y la PR de SGLang ahora ofrece la ruta exacta que hay que vigilar, XingChen-AGI/Xing4.0-29B-A4B, que actualmente no resuelve para nadie. Segundo, las propias PR: la de vLLM necesita que se confirmen las fórmulas de sesgo de mHC, que se añada la entrada de prueba en el registro y que su CI esté en verde; la #39793 de SGLang necesita que se corrijan sus tres ejecuciones en rojo y que sus diez revisores solicitados den el visto bueno, mientras que la más antigua, la #37228, aún necesita su entrada de prueba, su benchmark de aceleración de MTP y una CI desbloqueada. Tercero, y nuevo esta semana: si SGLang cierra la #37228 en favor de la #39793 tal como vLLM siempre ha cerrado una predecesora antes de volver a presentarla. Dos integraciones activas para un modelo sin publicar es un estado que nadie mantiene durante mucho tiempo, y cuál sobreviva dice algo sobre lo cerca que está esto en realidad. Cuarto, los números: si un checkpoint publicado coincide con la forma 29B-A4B, el MoE de 64 expertos y el contexto de 262.144 tokens que ahora afirman la configuración y la descripción de la PR. Quinto, si la tercera PR de vLLM sobrevive más tiempo que sus dos predecesoras, que duraron 21 y 11 días respectivamente antes de cerrarse sin fusionar. Y hay que vigilar si los analizadores de razonamiento describen una variante Thinking separada, tal como TeleChat3 lanzó una.

Hasta que ocurra uno de esos, trata a este modelo como lo que es: un plan bien especificado de un laboratorio serio, sorprendido en plena preparación de su infraestructura de servicio —ahora en ambos stacks principales de servicio de código abierto, bajo un nombre que ambos han adoptado y un tamaño que solo indica su propia pull request. La arquitectura por sí sola hace que valga la pena seguirlo: es la segunda gran adopción de mHC después de la del propio DeepSeek, de un laboratorio cuya generación anterior ya era un MoE de grano fino entrenado en chips nacionales. Cuando se publiquen los pesos, no habrá duda de si se ejecuta en vLLM o SGLang. Ambos stacks han escrito el código tres veces, bajo tres nombres diferentes.