Xing4_0, SGLang에 진입: China Telecom의 차세대 MoE를 위한 여섯 번째 PR이자 처음으로 명시된 규모

2026년 9월 16일, 두 시간 간격을 두고 두 주요 오픈소스 서빙 스택이 더는 이름을 두고 엇갈리지 않게 되었다. vLLM은 아침에 "[Model] Add Xing4_0 support"를 올렸고, sgl-project/sglang이 10:38 UTC에 "feat: add Xing4_0 model support"로 뒤를 이었으며, 세 개의 이름이 오간 6주 끝에 이제 두 프레임워크 모두 Xing4_0라고 말한다. SGLang 풀 리퀘스트에는 이전의 어떤 PR에도 없던 것이 담겨 있다: 바로 크기다. 이 PR은 모델을 Xing4.0-29B-A4B, "약 4B의 활성 파라미터를 지닌 29B 파라미터 MoE"라고 설명하고, 체크포인트 경로와 262,144 토큰 컨텍스트, EAGLE 추측 디코딩을 명시한 실행 명령을 제시한다. 이는 중국텔레콤의 미공개 MoE로, 8월부터 XingChen4 풀 리퀘스트들이 맴돌던 바로 그 모델이며, 여전히 미공개 상태다: 가중치는 공개되지 않았고, PR이 명시한 체크포인트 경로는 프로젝트 외부의 누구에게도 열리지 않으며, 어떤 벤더도 이름이나 수치를 확인해 주지 않았고, 이 글의 어떤 내용도 독립적으로 검증되지 않았다. 풀 리퀘스트에서 가져온 사실은 그렇게 표시했으며, 나머지는 배경 설명과 추론이다. 오늘 실제로 호출할 수 있는 가장 가까운 모델은 DeepSeek V4 Flash다.

이 글은 지금까지 파악된 내용을 정리한 것으로, 처음부터 다시 쓰기보다 최신 상태로 유지되는 글입니다. 6주간의 PR 흔적과 명명 문제가 어떻게 해결되었는지, 9월 16일 풀 리퀘스트 두 건이 실제로 무엇을 추가하는지, 이제 구성 파일들이 꽤 구체적으로 드러내는 아키텍처, 그리고 다음에 무엇을 지켜봐야 하는지를 다룹니다. 한 문장 요약: China Telecom의 차기 MoE는 서빙 통합 여섯 건, vLLM에서 TBA로 표시된 표 행 하나, SGLang에서 “coming soon”으로 표시된 문서 항목 하나, 그리고 명시된 파라미터 수를 축적할 만큼 충분히 실체가 있지만 — 당신이 접근할 수 있는 어디에서도 실행할 만큼 충분히 실체가 있지는 않습니다.

신호: 6개의 통합, 3개의 이름, 6주

이 작품이 처음 보도된 버전보다 그 흔적은 더 이른 시점에서 시작되며, 그 커밋 로그는 여전히 이번 유출에서 가장 많은 것을 드러내는 산출물이다. 첫 vLLM PR은 #51237로, 2026년 8월 6일에 "[WIP][Model] 곧 출시될 XingChen4 모델 지원 추가"라는 제목으로 열렸다. 세 개의 커밋이 그 자체로 이야기를 들려준다. 첫 번째는 "TeleChat4 모델 지원 추가"라는 제목이다. 한 시간 조금 넘은 뒤의 두 번째는 "chore: telechat4에 대한 성급한 문서 및 테스트 항목 되돌리기"로, 문서와 레지스트리 테스트 항목이 성급하다는 이유로 다시 빠졌다. 8월 27일의 세 번째는 "rename xingchen4"이다. 1분 뒤 그 PR은 병합되지 않은 채 닫혔고, 그로부터 11분 후 #54051이 같은 제목, 같은 포크 브랜치(supported_telechat4), 그리고 하나로 스쿼시된 커밋 하나로 열렸다. 그 사이에 needs-rebase 라벨이 붙었으므로, 이는 마음이 바뀐 것이라기보다 정리 후에 닫고 다시 연 것으로 읽힌다. 이 모든 것은 GitHub 계정 zyp2014에서 제출되었으며, 모든 커밋의 작성자이자 서명자는 zhangyp26 <zhangyp26@chinatelecom.com.cn>이다.

두 번째 PR은 이 글을 처음 쓸 때 중심에 두었던 바로 그 PR인데, 이제는 열려 있지 않습니다. #54051은 2026년 9월 7일에 작성자 본인이 병합하지 않은 채 닫았습니다. 그래도 그 설명은 인용할 가치가 있습니다. 이름이 바뀌고 다시 열릴 때마다 살아남은 문장이 바로 그것이기 때문입니다:

• 모델 가중치는 아직 Hugging Face Hub에 공개되지 않았습니다. 이 PR은 조기 코드 리뷰를 위해 열렸습니다. 가중치가 공개되면 tests/models/registry.py에 테스트 항목을 추가하고 docs/models/supported_models.md를 업데이트한 후 PR을 리뷰 준비 완료로 표시하겠습니다.

그 문장은 전체 이야기의 윤곽이다: 코드가 가중치보다 앞서 있다. 아래 스크린샷은 2026년 8월 27일, 페이지가 열린 날 당시의 모습 그대로인 #54051 페이지다 — 날짜가 남은 스냅샷이며, 그것이 보여 주는 풀 리퀘스트가 이후 닫혔기 때문에 보관된 것이다. 그것을 지금의 상태가 아니라 그 순간의 신호를 기록한 것으로 읽어라.

그러던 9월 16일, 그 패턴이 반복되었다 — 하루에 두 번이나. #57135, "[모델] Xing4_0 지원 추가"는 그날 아침 같은 계정 zyp2014에서 열렸고, 이제 단일 커밋의 작성자는 다른 China Telecom 엔지니어인 xiongji <xiongj9@chinatelecom.cn>로 바뀌었다. 파일 11개가 변경되고 약 1,300줄이 추가되었으며, 전반적으로 새 이름이 사용되었고, 같은 위치에 같은 주의 문구가 있었다: "모델 가중치는 아직 Hugging Face Hub에 공개되지 않았습니다."

2시간 20분 후, 다른 서빙 스택은 더 이상 이름 변경 하나만큼 뒤처져 있지 않게 되었다. sgl-project/sglang #39793, "feat: add Xing4_0 model support"라는 제목의 support_xing4_0 브랜치에서 열렸으며, 그 단일 커밋은 vLLM 이름 변경과 동일한 xiongji 주소를 담고 있다. 파일 14개와 약 1,400줄의 추가 사항으로, 그중 1,000줄이 조금 넘는 분량이 단일 모델 파일이다. 이 모델을 위해 6주 동안 제출된 여섯 번째 통합이며, 처음으로 초안이 아닌 상태로 제출된 사례이다. GitHub는 이를 열려 있고 검토 준비가 된 것으로 표시하며 리뷰어 10명을 요청했는데 — 세 번의 CI 실행은 이미 모두 실패 상태이다.

오늘 이전까지 SGLang 쪽은 vLLM이 그랬던 방식대로 흘러갔다. #33982, "feat(model): add TeleChat4 model support"는 2026년 8월 7일 기여자 PaddyXj에 의해 열렸고, 8월 31일 병합되지 않은 채 닫혔다 — 바로 그날 #37228, "feat: add XingChen4 model support"가 그 자리를 대신해 열렸다. 그 PR은 여전히 PaddyXj 명의의 초안으로 열려 있으며, support_xingchen4라는 브랜치에서 커밋 세 개까지 진행되었고 마지막으로 손댄 것은 9월 8일이다. 그 체크리스트는 두 프레임워크를 통틀어 가장 흥미로운 부분이다. 모델이 "로컬에서, 내부 가중치로" 로드되고 생성된다는 항목은 체크되어 있고, 도구 호출도 체크, 추론 파싱도 체크 — 그리고 공개 CI는 체크되어 있지 않은데, "가중치 공개에 막혀" 있기 때문이다. 누군가 체크포인트를 갖고 있다. 아무도 그것을 공개하지 않았다. 그리고 재제출할 때마다 이전 PR을 먼저 닫았던 vLLM과 달리, SGLang에는 이제 같은 모델에 대해 서로 다른 두 이름으로 열린 두 개의 살아 있는 풀 리퀘스트가 있다.

6주 동안 6개의 통합이 합쳐져 의미하는 바는 같은 신호의 더 강력한 버전이 아니라, 다른 신호이다. 6개 통합은 팀이 반복 개선하고 있다는 해석과 부합할 것이다. TeleChat4, XingChen4, Xing4_0이라는 세 가지 이름 아래의 6개 통합은, 가중치는 비공개로 둔 채 모델이 출시될 이름을 공개적으로 반복해 다듬고 있음을 뜻한다. 이는 검증되지 않은 추론이며, 지금 PR 기록이 보여주는 것 중 가장 중대한 사안이다.

9월의 두 PR이 실제로 추가하는 것

vLLM 풀 리퀘스트는 8월 작업을 다시 작성한 것이 아니라 이름만 바꾼 것입니다. 모델 파일은 이제 vllm/model_executor/models/xing4_0.py이고, 클래스는 Xing4_0ForCausalLM이며, model_type xing4_0은 DeepseekV3Config에 매핑됩니다 — XingChen4 버전이 사용했던 것과 동일한 Deep​Seek-V3 구성입니다. 이것이 담고 있는 내용은 다음과 같습니다:

• vllm/model_executor/models/xing4_0.py의 전체 모델 구현 — Xing4_0ForCausalLM 클래스, 순전파, mHC 어댑터, 텐서 병렬 load_weights() 구현 포함. 커밋 메시지는 DSA 및 비-DSA 변형이 모두 지원되며, 공유 mhc_pre / mhc_post 연산을 재사용한다고 명시합니다.

• vllm/model_executor/models/registry.py에 Xing4_0ForCausalLM을 등록하여, vLLM이 해당 아키텍처를 이름으로 인식할 수 있도록 합니다.

• 추론 가능한 변형을 위한 추론 파서(vllm/reasoning/xing4_0_reasoning_parser.py)와 자동 도구 호출을 위한 도구 파서(vllm/tool_parsers/xing4_0_tool_parser.py).

• vllm/config/speculative.py, vllm/transformers_utils/model_arch_config_convertor.py 및 vllm/transformers_utils/config.py에 등록 — 커밋 메시지에는 추측 디코딩을 위해 Deep​Seek-V3 호환 MTP 헤드가 활성화된다고 명시되어 있습니다.

• 두 개의 문서 파일 — 진짜로 새로운 부분이자 8월의 직접적인 반전입니다. 원래 커밋에는 문서와 테스트 항목이 포함되어 있었지만 한 시간 뒤 시기상조라는 이유로 되돌려졌습니다. 9월 PR은 문서를 다시 포함시키며 문서화, 새 모델, 도구 호출 레이블이 붙어 있습니다.

vLLM 문서 항목은 독자가 처음으로 구체적인 내용을 알게 된 곳이다. 다음 문서인 docs/models/supported_models.md에서 새 행은 `Xing4_0ForCausalLM` | Xing4_0 | TBA — 체크포인트 열에는 말 그대로 TBA라고 적혀 있는데, 이는 다른 글꼴로 표현된 같은 "아직 아님"이다. 그리고 docs/features/tool_calling.md에서는 "Xing4_0 Models (xing4_0)"이라는 제목 아래, 해당 PR은 모델의 도구 호출 형식을 다음과 같이 문서화한다: 호출은 <tool_call>...</tool_call> 블록 안에 JSON ({"name": ..., "arguments": {...}}) 또는 <param_key>...</param_key>와 <param_value>...</param_value>를 사용하는 태그 기반 형식으로 출력된다. 이는 이전 PR들이 도달하지 못한 수준의 구체성이다 — 아무도 다운로드할 수 없는 체크포인트를 위해, 주요 프레임워크의 공개 문서에 기록된 모델의 채팅 형식 구현 세부 사항이다.

SGLang PR은 더 흥미롭습니다. 레지스트리 항목과 문서가 아니라 구현과 구성을 함께 제공하기 때문입니다. 그 문서 행은 한 프레임워크가 자체 문서에 벤더 이름을 올린 첫 사례입니다. docs/docs/supported-models/generative_models.mdx에서 새 행은 Xing4_0을 나열하며, 체크포인트 열에는 `Xing4_0` (출시 예정)이라고 적혀 있고 설명은 다음과 같습니다: "China Telecom의 MoE 모델로 MLA 어텐션과 mHC (Manifold-constrained Hyper-Connection) 잔차 스트림을 사용하며, 네이티브 MTP 추측 디코딩, 도구 호출, 추론을 지원합니다." vLLM의 행은 TBA라고만 했고 벤더를 명시하지 않았습니다; SGLang의 행은 China Telecom을 명시하며 출시 예정이라고 합니다. 둘 다 출시일이 아니며, 프레임워크 문서의 한 행은 제품이 아닙니다.

이 PR 설명은 이 이야기의 이전 모든 버전에 없던 숫자를 추가합니다. "이 PR은 Xing4.0-29B-A4B(약 4B 활성 파라미터를 가진 29B 파라미터 MoE)에 대한 지원을 추가합니다." 또한 실행 명령도 제공합니다 — --model-path XingChen-AGI/Xing4.0-29B-A4B --trust-remote-code --tp-size 2 --context-length 262144 --reasoning-parser xing4_0 --tool-call-parser xing4_0 --speculative-algorithm EAGLE — 그리고 이 구성이 텐서 병렬성 2, 262,144 토큰 컨텍스트, EAGLE MTP 추측 디코딩에서 검증되었다고 밝히며, 추론 응답과 get_weather 도구 호출의 트랜스크립트를 증거로 설명에 붙여 넣었습니다. 그 검증을 뒷받침하는 가중치는 작성자 본인의 것입니다. 즉, 이 PR이 명시한 저장소 경로는 공개적으로 읽을 수 없고, 그것이 가리키는 Hugging Face 조직은 공개 모델을 전혀 나열하지 않습니다. 크기, 컨텍스트 길이, 트랜스크립트는 누구나 재현할 수 있는 측정값이 아니라 비공개 체크포인트에 딸린 PR 보고 주장으로 취급하십시오. 이 모든 것은 해당 풀 리퀘스트에 따른 것이며 재현되지 않았습니다.

두 이름 아래에서 모두 나타나는 추론 파서와 도구 파서는 8월에 그랬던 것과 같은 이유로 중요하다. 추론 파서는 모델의 출력에서 사고 표식을 제거하기 위해 존재한다 — 모델이 최종 답변 전에 내보내는 내부 사고 연쇄(chain-of-thought)다. 이 모델을 위해 특별히 만들어진 파서는, TeleChat3가 Thinking 에디션을 출시했던 것과 같은 방식으로, 이 제품군에 추론 기능을 갖춘 변형이 있을 것으로 예상된다는 뜻이다. 도구 파서와 이제 문서화된 호출 형식은 네이티브 함수 호출도 예상된다는 뜻이다. 둘 중 어느 것도 최종 제품에 대한 보장은 아니다. 둘 다 PR들이 China Telecom이 무엇을 목표로 하는지에 관해 담고 있는 가장 강력한 단서다.

지금까지 우리가 아는 것, 한눈에 보기

아래 스코어보드는 2026년 8월 27일 당시의 vLLM PR을 바탕으로 이 글을 위해 작성된 것이다. 이것은 다시 그리지 않고 날짜가 표시된 스냅샷으로 의도적으로 여기에 남겨 두는데, 3주가 지난 뒤에도 그 각 줄이 여전히 사실이기 때문이다 — 미출시, 가중치 비공개, DeepSeek 백본, mHC 잔차, 두 파서 모두 포함. 바뀐 것은 카드의 값이 아니라 그 주변의 모든 것이다: 인용된 vLLM PR은 9월 7일에 닫혔고, 그 작업은 9월 16일에 새 이름으로 다시 나타났으며, SGLang은 몇 시간 뒤 그 이름 변경을 따라갔고, 처음으로 명시된 파라미터 수가 그것과 함께 나왔다. 카드에 틀린 것은 없다. 단지 3주 된 것이고, 이야기는 그 너머로 나아갔다. 마지막 행의 FlagGems 수치는 변경 없이 새 vLLM PR로 그대로 이어졌으며, 여전히 PR에서 보고된 값이고 여전히 재현되지 않았다.

PR들이 유출하는 아키텍처

파일 이름을 바꾼다고 아키텍처 이름이 바뀌는 것은 아니며, 9월 vLLM PR의 요약 텍스트는 XingChen4 자리에 Xing4_0을 치환한 8월 텍스트와 절 하나하나까지 같다. 신호를 담고 있는 것은 두 문장이다:

• "Xing4_0은 Deep​Seek-V2/V3 백본(MLA 어텐션, MoE 블록, 선택적 DSA 인덱서)을 재사용합니다."

이는 표준 잔차 연결을 매니폴드 제약 하이퍼 연결(mHC)로 대체합니다: 잔차 스트림은 Sinkhorn-Knopp 투영을 통해 생성된 입력 종속적 이중 확률 행렬에 의해 혼합되는 num_residual_streams 병렬 스트림으로 확장됩니다.

각 절은 구체적인 요소와 맞닿아 있다. MLA는 DeepSeek가 V2에서 도입한 압축 어텐션 방식인 Multi-head Latent Attention으로, KV 캐시를 작게 유지할 수 있게 해준다. MoE는 전문가 혼합(mixture-of-experts) 라우팅으로, 많은 파라미터 수를 유지하면서도 활성 풋프린트는 작게 가져간다. 선택적 DSA 인덱서는 V3.2 계열의 DeepSeek Sparse Attention 메커니즘, 즉 어텐션할 top-k 토큰을 선택하는 경량 스코어링 모듈이며, 컨텍스트 길이에 대해 어텐션 비용을 이차에서 거의 선형으로 줄여준다. 그리고 mHC 문장이 핵심이다. 이 모델은 DeepSeek 자체가 이번 세대에야 처음 도입한 잔차 아키텍처를 채택한다.

SGLang PR은 그 대상의 형태를 설명하기보다 처음으로 공개한 사례다. 이 PR의 구성 파일인 python/sglang/srt/configs/xing4_0.py는 40개의 은닉층, 3,584의 은닉 크기, 131,072 토큰의 어휘를 선언한다. 32개 헤드에 걸쳐 KV LoRA 랭크 512와 쿼리 LoRA 랭크 768을 사용하는 MLA, 그리고 64개의 라우팅된 전문가와 하나의 공유 전문가, top-4 라우팅, 시그모이드 스코어링, 2.0의 라우팅된 스케일링 계수, noaux_tc 전문가 선택을 갖춘 희소 MoE를 선언한다. mHC 필드도 명시적이다. hc_mult 4, 20회의 Sinkhorn-Knopp 반복, ±30의 h_res 클램프, 그리고 최대 위치 임베딩 262,144을 갖는 rope_theta 10,000이다. 풀 리퀘스트에 따르면 이는 아직 출시되지 않은 통합에서의 기본값이다 — 구성 파일은 의도 선언이지 모델 카드가 아니며, PR 설명의 29B-A4B 수치는 공개된 어디에서도 이들로부터 도출되지 않는다.

하나의 필드는 나머지보다 더 가치가 있습니다. 왜냐하면 이 모델이 DeepSeek의 복사본이기를 눈에 띄게 멈추는 첫 번째 지점이기 때문입니다. SGLang 설정은 hc_contract_for_draft를 설정하는데, 이는 mHC 스트림을 최종 norm 전에 모델 자체의 hidden size로 다시 병합하고, 그 축약된 텐서를 Eagle 드래프트 헤드에 공급합니다. DeepSeek V4는 대신 mHC-flattened n-times-hidden_size 텐서를 공급합니다. 설정 주석은 이를 명시적으로 말하고 있으며, 이는 구현이 실제 체크포인트에 맞춰진 후에야 드러나는 종류의 세부 사항입니다 — 이는 이전 SGLang PR의 체크리스트가 공개하지 않은 채 가지고 있다고 주장하는 바로 그 것입니다.

mHC 수학은 두 스택이 구현에서는 갈라지고 가정에서는 일치하는 지점이다. vLLM PR은 "vllm.model_executor.layers.mhc의 공유 ops와 일치하므로 비공개 커널이 도입되지 않는다"라고 언급한다. 그 모듈이 존재하는 이유는 vLLM이 이미 DeepSeek V4용 mHC를 지원하므로, 이 모델을 추가하는 증분 비용이 작기 때문이다. SGLang은 다른 길로 같은 지점에 도달한다. SGLang의 mHC 모듈은 torch 커스텀 ops로 등록된 융합 TileLang 커널을 사용하며, PR은 기존 mhc_pre split-K 커널이 이미 처리하던 두 크기와 함께 hc_hidden_size 14,336도 받아들이도록 확장한다. 또한 이 아키텍처에 대해서는 DeepGEMM의 tf32_hc_prenorm_gemm 경로를 비활성화한다. 그 경로는 torch.compile이 추적할 수 없는 로우 C 확장이기 때문이며, 대신 mHC는 TileLang 커널로 폴백한다. 실질적인 이점은 두 프레임워크에서 동일하다. 오늘 vLLM이나 SGLang에서 DeepSeek V4를 서빙한다면, China Telecom의 차기 MoE를 서빙할 메커니즘은 이미 설치되어 있는 셈이다.

mHC, 모든 것의 중심에 있는 DeepSeek의 비결

매니폴드 제약 하이퍼 커넥션(Manifold-constrained Hyper-Connections)은 파헤쳐 볼 가치가 있습니다. 왜냐하면 그것은 이 모델에서 단연 가장 흥미로운 점이며 — China Telecom의 발명이 아니기 때문입니다. 그것은 Deep​Seek의 것입니다.

이 이야기는 2024년 Ki​mi 팀이 제안한 Hyper-Connections에서 시작된다. 표준 Transformer는 레이어마다 하나의 잔차 스트림을 유지한다: 입력이 레이어의 출력에 더해져 그래디언트에 깨끗한 경로를 제공하고, 네트워크가 잔차 보정을 학습할 수 있게 한다. Hyper-Connections는 그 단일 스트림을 여러 병렬 스트림으로 대체하며, 각 레이어에서 학습된 행렬에 의해 혼합되어 모델이 정보를 이동시킬 수 있는 훨씬 풍부한 경로를 제공한다. 문제는 안정성이다: 제약 없는 혼합 행렬은 잔차 연결을 학습 가능하게 만드는 항등 매핑 속성을 깨뜨리며, 조 단위 파라미터 규모에서는 학습 손실이 불안정해진다.

DeepSeek의 기여는 2025년 12월 mHC 논문으로 발표된 뒤 DeepSeek V4에 사용되었는데, 혼합 행렬을 이중 확률 행렬, 즉 음수가 아니고 각 행과 열의 합이 1인 행렬로 제약하는 것이었으며, 이는 학습 중 Sinkhorn-Knopp 투영으로 강제되었습니다. 이중 확률 행렬의 스펙트럼 반지름은 정확히 1이므로, 신호는 수백 개의 층을 통과할 때 지수적으로 증폭되거나 감쇠될 수 없습니다. 이 한계가 대규모에서 학습을 안정적으로 유지해 주며, 이 투영은 비용이 충분히 저렴해서 DeepSeek은 네 개의 잔차 스트림에서 약 6.7%의 학습 오버헤드만 보고했습니다. 2026년 4월 24일 출시된 DeepSeek V4는 이를 대표적으로 활용한 사례로, 수학 추론 작업에서 약 15%의 향상과 100만 토큰 컨텍스트를 추가로 갖춘 것으로 보고되었습니다.

그러니까 이 PR들이 쉬운 말로 말하는 바는 다음과 같습니다: China Telecom의 차세대 모델은 DeepSeek의 검증된 백본과 DeepSeek의 최신 잔차 메커니즘을 가져오는 것이지, 둘 중 어느 하나를 처음부터 새로 발명하는 게 아닙니다. 이는 실용적인 선택이며, 미묘한 확인을 담고 있습니다 — DeepSeek 자체 다음으로 mHC를 도입한 두 번째 주요 연구소가 이 기법이 프로덕션 준비 완료라고 믿는다는 것입니다.

PR들은 mHC와 관련해 아직 완료되지 않았고, 미해결 항목들은 이를 솔직히 드러낸다. vLLM PR 전반에서 작성자는 체크포인트 바이어스(bias_pre, bias_post, bias_res)와 h_res 클램프가 현재 병합되었거나 생략되었다고 언급하며, 수식 동등성에 대한 리뷰어 확인이 "주요 정확성 문제"라고 밝힌다. 또한 TileLang 커널을 위해 텐서를 C-contiguous 상태로 유지하는 사용자 정의 transpose 연산이 있는데, 이는 다른 모든 것과 함께 _xingchen4_transpose_contiguous에서 _xing4_0_transpose_contiguous로 이름이 변경되었으며, 하나의 확고한 한계가 있다: num_residual_streams가 1보다 클 때 mHC 모드에서는 파이프라인 병렬 처리가 지원되지 않는 반면, 텐서 병렬 처리는 지원된다. 초안으로서 이 중 놀라운 것은 없지만, 8월 당시와 같은 미완의 경계이며, 그 자체로 시사하는 바가 있다: 6주간의 이름 변경은 정확성 문제를 진전시키지 못했고, 최신 SGLang PR에서의 세 번의 빨간 CI 실행은 다른 색으로 표현된 같은 이야기다. SGLang 구성이 확정하는 것은 스트림 수다. hc_mult가 4로 설정되고 hidden size가 3,584일 때, 커널 패치의 14,336은 정확히 네 개의 스트림이며, 커널 주석도 바로 그렇게 말한다. 그 해석은 이 글이 처음 게재되었을 때 단순한 숫자에서 추론한 것이었으나, 이제 구성 파일에 기록되어 있다.

가속 각도: FlagGems, 다시

두 번째 연결고리는 이 모델을 China Telecom이 Beijing Academy of Artificial Intelligence와 맺은 기존 관계에 묶으며, 이는 모든 이름 변경에서 온전히 살아남은 유일한 연결고리다. vLLM PR은 USE_FLAGOS 환경 플래그 뒤에서 선택적 FlagOS/FlagGems 가속을 활성화하며, 이 플래그는 기본적으로 비활성화되어 있고, MoE, 어텐션, softmax, top-k의 핫패스 커널을 교체한다. PR 작성자가 고동시성 장문 프롬프트 워크로드(입력 토큰 10K 이상, 동시성 10)에서 수행한 H100 벤치마크에 따르면, 주장된 이득은 최대 19.87% 더 낮은 첫 토큰까지의 시간(time-to-first-token)과 최대 26.32% 더 낮은 출력 토큰당 시간(time-per-output-token)이며, 다른 워크로드에서는 변화가 없다. 이 수치는 PR에서 보고된 것이고 재현되지 않았으며, 플래그가 기본적으로 꺼져 있는 상태로 나온다.

기록할 가치가 있는 것은 그 이름 변경이 얼마나 적게 건드렸는가이다. 9월 vLLM PR은 같은 수치, 해당 플래그가 모델 파일 내부에만 존재한다는 것에 관한 동일한 좁은 범위의 주석, 그리고 flagtree와 flag-gems를 설치하라는 동일한 지시를 담고 있다. 숫자는 바뀌지 않았는데, 코드가 바뀌지 않았기 때문이다. 바뀐 것은 라벨뿐이었다. SGLang 풀 리퀘스트에는 FlagGems의 흔적이 전혀 없다 — 대신 TileLang과 DeepGEMM 경로를 택한다 — 이는 이것이 모델에 관한 논쟁이 아니라 서빙 계층의 최적화를 누가 소유하는가에 관한 논쟁임을 말해준다.

이것은 연속선상의 이야기다. TeleChat3-36B-Thinking은 2026년 4월 기준으로 BAAI의 오픈소스 AI 소프트웨어 스택인 FlagOS에 독립적으로 포팅된 최초의 대규모 모델이었다. 이 모델이 어떤 형태로 출시되든, 자체 vLLM 통합 내부에 FlagGems 커널을 포함시켜 그 흐름을 이어간다는 것은 이 연구소의 자국 스택 전략이 훈련뿐 아니라 서빙 계층까지 확장된다는 것을 말해준다.

이름 짓기 문제, 그리고 그것이 비롯된 가족

9월 16일까지 명명 문제는 부차적인 사안이었다. 이제 그것은 거의 종결되었고, 증거는 여전히 진술이 아니라 브랜치 이름과 남겨진 문자열에만 있다 — 그러나 두 프레임워크는 같은 방향에서 같은 답으로 수렴했다.

• 커밋 메시지는 순서대로: "TeleChat4 모델 지원 추가", 그다음 "chore: telechat4에 대한 성급한 문서 및 테스트 항목 되돌리기", 그런 다음 — 3주 후이자 PR이 닫히기 1분 전 — "xingchen4 이름 변경". 전체 목적이 이름 변경이었던 커밋.

• 포크가 분기한다. 처음 두 vLLM PR인 #51237과 #54051은 zyp2014:supported_telechat4에서 분기했다. 세 번째인 #57135는 zyp2014:support_xing4_0이다. 브랜치는 모델 이름을 바꾼 것과 같은 작업에서 이름이 바뀌었다 — 그리고 SGLang 쪽은 이제 support_telechat4에서 support_xingchen4를 거쳐 support_xing4_0에 이르기까지 세 단계로 동일한 경로를 걸어왔다.

• #51237의 본문 텍스트는 FlagGems 가속이 "TeleChat4용"이라고 말했지만, 바로 그 같은 문단에서는 그 모델을 XingChen4라고 불렀습니다. 두 이름은 이미 8월 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이라는 브랜드가 붙어 있습니다:

• 2024년 1월에 1조 토큰 규모의 말뭉치로 오픈소스 공개된 TeleChat-7B 및 TeleChat-12B

• TeleChat2-115B(2024년 9월)는 최초의 완전 국산 1조 파라미터 오픈 모델로 소개되었으며, 35B, 7B, 3B 형제 모델도 함께 있습니다.

• TeleChat2-39B-A12B (2025년 3월), 이 제품군 최초의 MoE.

• TeleChat3-105B-A4.7-Thinking(2025년 12월)은 총 1,050억 개의 매개변수 중 47억 개만 활성화되는 세분화된(fine-grained) MoE 모델로, 15조 개의 토큰으로 학습되었으며, 밀집 모델인 TeleChat3-36B 및 이후 출시된 TeleChat3-Coder-36B-Thinking과 함께 공개되었습니다.

29B-A4B 수치가 맞는다면, 이 모델은 총 파라미터와 활성 파라미터 모두에서 TeleChat3-105B-A4.7-Thinking보다 아래에 놓이게 된다. 이는 대체 플래그십이 아니라 더 작고 더 저렴한 형제 모델인 셈이다. 이는 하나의 해석일 뿐, 사실이 아니다. 두 PR 어디에도 이 모델이 어느 등급을 겨냥하는지는 나와 있지 않다. Xingchen 브랜드는 회사가 AI 역량을 쏟는 곳이다. Xingchen AGI Lab은 2026년 3월 베이징에 공식 설립되어 같은 모델 패밀리를 기반으로 하며, China Telecom은 자사의 "三全"(풀모달, 풀사이즈, 완전 국산) 시스템이 1B에서 1T+ 파라미터에 이르는 시맨틱, 음성, 비전 및 멀티모달 모델을 아우른다고 설명한다. TeleChat에서 Xingchen으로의 이름 변경은 연구소가 모델 패밀리에 제품 라인의 브랜드가 아니라 연구소의 브랜드를 실리게 하고 싶을 때 하는 바로 그 일이다.

우리가 아직 모르는 것

이렇게 초기 단계의 모델이라면, 솔직한 목록이 알려진 목록보다 여전히 길지만, 이번 주에 두 곳에서는 좁혀졌습니다:

• 릴리스 날짜는 없습니다. 여섯 개 통합 중 다섯 개는 초기 코드 리뷰를 위해 열린 드래프트이며, 이는 바로 가중치가 공개되지 않았기 때문입니다. 여섯 번째인 SGLang #39793은 드래프트가 아니라 리뷰를 위해 열려 있지만, 아직 병합되지 않았고 세 번의 CI 실행이 모두 실패 중이며 승인해 줄 리뷰어가 필요합니다. 발표된 일정은 없습니다.

• 파라미터 수, 그러나 주장된 것에 불과하다. 이 글의 이전 모든 버전은 MoE 구성을 비공개로 기재했다. SGLang PR은 이를 서류상으로 바꾼다: Xing4.0-29B-A4B, 총 29B, 활성 약 4B. 이 수치는 풀 리퀘스트에서 나온 것이며, 어떤 공개 체크포인트에도 첨부되어 있지 않고, 어떤 구성 파일로도 뒷받침되지 않으며, 프로젝트 외부의 누구도 재현하지 않았다. 이를 명세가 아니라 표명된 의도로 취급하십시오.

• 공급업체가 보고한 것이든 그렇지 않든 벤치마크 수치가 없고, 독립적인 점수도 없습니다. SGLang PR의 검증 기록은 모델이 추론 프롬프트에 답하고 잘 구성된 툴 호출을 내보내는 모습을 보여줄 뿐, 그것이 얼마나 잘하는지에 대해서는 아무것도 보여주지 않습니다.

• 가격 책정도 없고, 확인된 라이선스도 없습니다. 이전의 모든 TeleChat 릴리스는 Apache-2.0이며 이는 고무적이지만, 이번 릴리스에 대해서는 라이선스가 명시되지 않았습니다.

• 공개 가중치 없음 — 추정이 아니라 확인된 사실. 2026년 9월 16일 기준 SGLang PR이 명시한 Hugging Face 경로는 공개적으로 열람할 수 없으며, 그것이 가리키는 조직은 공개 모델을 하나도 나열하지 않는다; 이 계열에서 가장 최신 공개 항목은 1월의 TeleChat3-Coder-36B-Thinking이다. vLLM의 지원 모델 표는 체크포인트 열에 TBA라고 적혀 있고, SGLang의 표는 "출시 예정"이라고 적혀 있으며, 두 SGLang PR 모두 공개 CI가 실패 중이다.

• China Telecom의 공식 발표는 없다 — 공지도, 가중치도, 명칭이나 크기에 대한 확인도 없다. 이 비대칭성을 주의 깊게 보라: SGLang 문서의 한 행은 이 모델을 China Telecom의 것으로 귀속시키지만, 그것은 회사 성명이 아니라 풀 리퀘스트 안의 기여자 설명이며, 최신 PR 설명에서는 벤더 이름이 완전히 빠져 있다. 이 모델을 위해 구축 중인 여섯 개의 통합은 그것이 실제로 존재한다는 가장 강력한 증거다. 하지만 통합은 닫히고 코드명은 바뀌기 마련이며, 이미 두 개가 그렇게 되었다. 연구소가 그렇다고 말하기 전까지는 아무것도 확정된 것이 아니다.

이 모든 것에 대한 올바른 해석은 모델에 대한 회의론이 아니라, 초기 신호에 대한 정확한 그림입니다. 오늘날 존재하는 것은 실제 엔지니어링 산출물입니다 — 두 프레임워크에 걸쳐 여섯 개가 — 실제 아키텍처를 갖추고 있으며, 처음으로 명시된 형태가 부착되어 있습니다. 아직 다운로드하거나 호출하거나 벤치마크할 수 있는 것은 아무것도 없습니다.

오늘 실행할 수 있는 가장 가까운 것

이 모델은 어디에서도 서빙할 수 없습니다 — API를 통해서도, 로컬에서도 안 됩니다. 가중치가 공개되어 있지 않기 때문입니다. 오늘날 독자가 실제로 호출할 수 있으면서 이 모델의 아키텍처적 DNA를 공유하는 가장 가까운 모델은 DeepSeek V4 Flash이며, 이는 MLA와 MoE 위에 동일한 mHC 잔차 방식을 사용하고, 두 프레임워크의 공유 mHC 모듈이 기반으로 삼은 참조 구현입니다. deepseek/deepseek-v4-flash에 대한 OrcaRouter의 모델 페이지에는 1M 토큰 컨텍스트, 384K 최대 출력, 그리고 백만 입력 토큰당 $0.15, 백만 출력 토큰당 $0.29의 정가가 나열되어 있습니다 — DeepSeek 자체가 공개하는 것과 동일한 수치로, 0% 마크업으로 그대로 전달되므로 공급업체의 가격 변경이 같은 날 여기에 바로 반영됩니다. API 키 하나로 카탈로그 전체를 이용할 수 있습니다, 따라서 이를 나머지 추론 등급과 비교하는 일은 새로운 통합이 아니라 라우팅 규칙이 됩니다.

“이 모델이 출시되면 어떻게 사용해 볼 수 있을까”에 대한 실용적인 답이기도 합니다. 완전히 새롭고 검증되지 않은 체크포인트야말로 자동 페일오버가 진가를 발휘하는 지점입니다. 트래픽의 일부를 여기로 라우팅하고, 검증된 모델을 폴백으로 유지하며, 프로덕션 경로를 첫날의 동작에 걸지 않고 라우팅 계층이 결정하게 하는 겁니다. 약 4B 활성 파라미터를 가진 29B MoE가 등장한다면, 토큰당 실제 활성화되는 부분이 매우 적기 때문에 프런티어 모델과 맞붙여 라우팅하기에 저렴한 선택입니다. 지금부터 출시 사이에 이름이 또 바뀐다면 — 지난 6주를 보면 그럴 가능성이 있습니다 — 다시 써야 하는 것은 통합이 아니라 라우팅 규칙입니다.

자주 묻는 질문

vLLM PR은 왜 닫혔나요?

우리는 종료된 사실은 알 수 있지만 그 이유는 알 수 없습니다. #54051은 2026년 9월 7일 작성자 본인에 의해 병합되지 않은 채 닫혔고, 그 작업은 9일 후 #57135라는 새 이름으로 다시 나타났습니다. 더 이전의 vLLM PR인 #51237은 같은 날 같은 제목으로 닫히고 다시 제출되었습니다. 따라서 닫고 다시 제출하는 것은 문제의 징후라기보다 이 작성자의 패턴입니다. 하지만 PR 본문에는 이유가 명시되어 있지 않으며, 우리가 그 이유를 지어내지는 않겠습니다.

Xing4_0은 언제 출시되나요?

날짜는 없습니다. 6개 통합 중 5개는 초기 코드 리뷰를 위해 열린 초안이며, 작성자들 자신의 계획은 가중치가 공개된 뒤에야 테스트 항목을 추가하고 문서를 업데이트하며 PR을 준비 완료로 표시하는 것입니다. SGLang의 오래된 체크리스트가 현황을 가장 명확하게 보여줍니다. "모델 로드 및 생성(로컬, 내부 가중치 사용)"에 체크되어 있고, 공개 CI는 "가중치 공개에 막혀 있습니다." 더 새로운 SGLang PR은 초안이 아니라 리뷰 준비 완료로 제출되어 있는데, 이는 상태 변화라기보다 태도의 변화입니다. 즉, 병합되지 않았고 CI는 빨간색이며, 문서 행에 "곧 제공 예정"이라고 적힌 것은 출시가 아닙니다.

Xing4_0은 XingChen4와 동일한 모델인가요?

거의 확실히 그렇습니다. 그리고 PR들을 보면 쉽게 확인할 수 있습니다: 동일한 포크 계보, 동일한 아키텍처 문단, 동일한 FlagGems 벤치마크 수치, 동일한 미해결 항목, 그리고 두 프레임워크 모두에서 파일 단위로 동일한 이름 변경 — xingchen4.py에서 xing4_0.py로, config 클래스 포함, 이름을 맞춰 변경된 브랜치에서. 그것은 새 이름을 걸친 동일한 작업이며, 9월 16일 기준으로 vLLM과 SGLang 모두 그 이름을 채택했습니다. 어떤 PR에도 명시되지 않은 것은 출시된 체크포인트가 어떤 이름을 달게 될지입니다.

이것은 DeepSeek 모델인가요?

아니요. 그것은 Xingchen AGI Lab에서 나온 China Telecom의 모델입니다. Deep​Seek과의 연결은 아키텍처적입니다: Deep​Seek-V2/V3 백본과 Deep​Seek이 V4에서 제안하고 출시한 mHC 잔차 기법을 재사용합니다. 누군가의 아키텍처를 채택했다고 해서 두 프로젝트가 관련이 있는 것은 아닙니다.

다음에 볼 콘텐츠

PR들은 여전히 구체적인 체크리스트를 제공하며, 9월 16일의 두 건은 여기에 두 항목을 추가했다. 첫째, 가중치: 모든 작성자가 자신들의 작업이 Hugging Face에 달려 있다고 말했으므로, 공개 저장소가 나타나는 것이 핵심 이벤트이며 — SGLang PR은 이제 지켜봐야 할 정확한 경로인 XingChen-AGI/Xing4.0-29B-A4B를 제시하는데, 이는 현재 아무에게도 연결되지 않는다. 둘째, PR들 자체: vLLM의 PR은 mHC 바이어스 공식이 확인되고, 레지스트리 테스트 항목이 추가되고, CI가 녹색이어야 한다; SGLang의 #39793은 세 번의 빨간 실행이 수정되고 요청된 열 명의 리뷰어가 승인해야 하며, 더 오래된 #37228은 여전히 테스트 항목, MTP 가속 벤치마크, 차단 해제된 CI가 필요하다. 셋째, 그리고 이번 주에 새로운 것: SGLang이 vLLM이 항상 재제출 전에 선행 PR을 닫아온 방식대로 #39793을 위해 #37228을 닫을지 여부다. 하나의 미출시 모델에 대해 두 개의 살아 있는 통합이 존재하는 것은 누구도 오래 유지하지 않는 상태이며, 어느 쪽이 살아남는지는 이것이 실제로 얼마나 임박했는지를 말해준다. 넷째, 숫자: 공개된 체크포인트가 구성과 PR 설명이 이제 주장하는 29B-A4B 형태, 64개 전문가 MoE, 262,144토큰 컨텍스트와 일치하는지 여부다. 다섯째, 세 번째 vLLM PR이 각각 21일과 11일을 버티다 병합되지 못한 채 닫힌 두 선행 PR보다 더 오래 살아남는지 여부다. 그리고 추론 파서들이 TeleChat3가 하나를 출시했던 방식처럼 별도의 Thinking 변형을 설명하고 있는지 지켜보라.

그런 일 중 하나가 일어나기 전까지는, 이 모델을 실체 그대로 대하라: 진지한 연구소가 자사의 서빙 인프라를 준비하는 현장에서 포착된, 잘 명세된 계획이다. 이제 두 주요 오픈소스 서빙 스택 모두에, 두 곳이 채택한 이름과 오직 자체 풀 리퀘스트만 밝히는 크기로 들어가 있다. 구조만으로도 추적할 가치가 있다: 이는 DeepSeek 자체에 이은 mHC의 두 번째 주요 도입이며, 이전 세대가 이미 자국산 칩으로 학습된 세밀한 MoE였던 연구소에서 나왔다. 가중치가 공개되면, 그것이 vLLM이든 SGLang이든 실행될 것은 의문의 여지가 없을 것이다. 두 스택 모두 서로 다른 세 가지 이름으로 그 코드를 세 번이나 작성해 두었다.