Xing4_0 lên SGLang: PR thứ sáu, và kích thước được công bố đầu tiên, cho MoE kế tiếp của China Telecom

Cách nhau hai giờ vào ngày 16 tháng 9 năm 2026, hai ngăn xếp phục vụ mã nguồn mở thống trị đã thôi bất đồng về cái tên. vLLM đã gửi "[Model] Add Xing4_0 support" vào buổi sáng; sgl-project/sglang tiếp nối với "feat: add Xing4_0 model support" lúc 10:38 UTC, và sau sáu tuần có ba cái tên được sử dụng, cả hai framework giờ đây đều nói Xing4_0. Yêu cầu pull request của SGLang mang theo một thứ mà không có cái nào trước đó có: một kích cỡ. Nó mô tả mô hình là Xing4.0-29B-A4B, một "MoE 29 tỷ tham số với ~4 tỷ tham số được kích hoạt," và đưa ra một lệnh khởi chạy nêu tên đường dẫn checkpoint, ngữ cảnh 262.144 token và giải mã suy đoán EAGLE. Đây là MoE chưa phát hành của China Telecom, cùng một mô hình mà các pull request XingChen4 đã xoay quanh từ tháng 8, và nó vẫn chưa được phát hành: trọng số không công khai, đường dẫn checkpoint mà PR nêu tên không phân giải được với bất kỳ ai ngoài dự án, không nhà cung cấp nào xác nhận cái tên hay con số, và không có gì trong bài viết này được xác minh độc lập. Các sự kiện lấy từ pull request được dán nhãn như vậy; phần còn lại là lịch sử và suy luận. Mô hình gần nhất mà bạn thực sự có thể gọi hôm nay là DeepSeek V4 Flash.

Đây là bài viết kiểu những gì chúng ta biết đến nay, được cập nhật liên tục thay vì bắt đầu lại từ đầu. Bài viết bao quát dấu vết PR kéo dài sáu tuần và cách câu hỏi đặt tên đã được giải quyết, hai pull request ngày 16 tháng 9 thực sự bổ sung những gì, kiến trúc mà các tệp cấu hình giờ tiết lộ khá chi tiết, và những gì cần theo dõi tiếp theo. Phiên bản một câu: MoE tiếp theo của China Telecom đủ thật để đã tích lũy được sáu tích hợp serving, một hàng trong bảng của vLLM được đánh dấu TBA, một mục tài liệu trong SGLang được đánh dấu "coming soon" và một số lượng tham số được công bố — và vẫn chưa đủ thật để chạy ở bất cứ đâu bạn có thể với tới.

Tín hiệu: sáu tích hợp, ba cái tên, sáu tuần

Dấu vết bắt đầu sớm hơn phiên bản của bài viết này được báo cáo lần đầu, và nhật ký commit của nó vẫn là hiện vật tiết lộ nhiều nhất trong vụ rò rỉ. PR vLLM đầu tiên là #51237, được mở vào ngày 6 tháng 8 năm 2026 với tiêu đề "[WIP][Model] Add upcoming XingChen4 model support." Ba commit của nó tự kể câu chuyện. Commit đầu tiên có tiêu đề "Add TeleChat4 model support." Commit thứ hai, chỉ hơn một giờ sau, là "chore: revert premature docs and test entry for telechat4" — tài liệu và mục kiểm thử trong registry đã bị rút lại vì bị coi là quá sớm. Commit thứ ba, vào ngày 27 tháng 8, là "rename xingchen4." Một phút sau, PR bị đóng mà không được hợp nhất, và mười một phút sau đó #54051 được mở với cùng tiêu đề, cùng nhánh fork (supported_telechat4) và một commit đã squash duy nhất. Nhãn needs-rebase đã được gắn vào trong khoảng thời gian giữa, nên điều này giống như việc đóng rồi mở lại sau khi dọn dẹp hơn là đổi ý. Tất cả đều được gửi từ tài khoản GitHub zyp2014, với mọi commit được tác giả và ký xác nhận bởi zhangyp26 <zhangyp26@chinatelecom.com.cn>.

PR thứ hai đó chính là cái mà bài viết này ban đầu được xây dựng xoay quanh, và nó không còn mở nữa. #54051 đã bị chính tác giả của nó đóng vào ngày 7 tháng 9 năm 2026, khi chưa được hợp nhất.Dù sao thì phần mô tả của nó vẫn đáng để trích dẫn, vì đó là câu đã trụ lại qua mọi lần đổi tên và mọi lần mở lại:

• "Trọng số mô hình chưa được công khai trên Hugging Face Hub. PR này được mở ra để review mã nguồn sớm. Khi trọng số được phát hành, tôi sẽ thêm mục kiểm thử vào tests/models/registry.py, cập nhật docs/models/supported_models.md, và đánh dấu PR sẵn sàng để review."

Câu đó chính là hình hài của toàn bộ câu chuyện: mã đang đi trước trọng số. Ảnh chụp màn hình bên dưới là trang #54051 đúng như nó tồn tại vào ngày 27 tháng 8 năm 2026, ngày nó mở — một ảnh chụp đã cũ, được giữ lại vì pull request mà nó hiển thị đã bị đóng kể từ đó. Hãy đọc nó như một ghi chép về tín hiệu ở thời điểm đó, chứ không phải về trạng thái của nó hiện giờ.

Sau đó, vào ngày 16 tháng 9, mô thức ấy lại lặp lại — hai lần trong cùng một ngày. #57135, "[Model] Add Xing4_0 support," được mở vào sáng hôm đó từ cùng tài khoản, zyp2014, với một commit duy nhất mà nay do một kỹ sư China Telecom khác thực hiện — xiongji <xiongj9@chinatelecom.cn>. Mười một tệp đã thay đổi, khoảng 1.300 dòng được chèn, một cái tên mới xuyên suốt, và cùng một lời lưu ý ở đúng một chỗ: "Trọng số mô hình vẫn chưa được công khai trên Hugging Face Hub."

Hai giờ hai mươi phút sau, stack phục vụ còn lại không còn chậm hơn đúng một lần đổi tên nữa. sgl-project/sglang #39793, "feat: add Xing4_0 model support," được mở từ một nhánh có tên support_xing4_0, và commit duy nhất của nó mang cùng địa chỉ xiongji như lần đổi tên vLLM. Mười bốn tệp và khoảng 1.400 dòng thêm vào, trong đó chỉ hơn một nghìn dòng nằm trong một tệp mô hình duy nhất. Đây là bản tích hợp thứ sáu được nộp cho mô hình này trong vòng sáu tuần, và là bản đầu tiên được nộp dưới dạng không phải bản nháp: GitHub liệt kê nó là đang mở và sẵn sàng để review, với mười người review được yêu cầu — và cả ba lần chạy CI của nó đều đã đỏ.

Phía SGLang trước hôm nay đã vận hành theo đúng cách mà phía vLLM đã làm. #33982, "feat(model): add TeleChat4 model support," đã được mở vào ngày 7 tháng 8 năm 2026 bởi người đóng góp PaddyXj và bị đóng mà không được hợp nhất vào ngày 31 tháng 8 — cùng ngày #37228, "feat: add XingChen4 model support," được mở để thay thế. Cái đó vẫn đang mở dưới dạng bản nháp dưới tên PaddyXj, trên một nhánh có tên support_xingchen4, với ba commit và được chạm đến lần cuối vào ngày 8 tháng 9. Danh sách kiểm tra của nó là thứ thú vị nhất trong cả hai framework: mô hình tải và sinh "cục bộ, trên các trọng số nội bộ" đã được đánh dấu, gọi công cụ đã được đánh dấu, phân tích suy luận đã được đánh dấu — còn CI công khai thì không, vì nó "bị chặn bởi việc phát hành trọng số." Ai đó có một checkpoint. Không ai công bố nó. Và khác với vLLM, nơi mỗi lần nộp lại đều đóng cái tiền nhiệm trước đó, SGLang giờ có hai pull request đang mở cho cùng một mô hình, dưới hai cái tên khác nhau.

Điều mà sáu tích hợp trong sáu tuần cộng lại thành không phải là một phiên bản mạnh hơn của cùng một tín hiệu; đó là một tín hiệu khác. Sáu tích hợp sẽ phù hợp với một đội đang lặp lại quy trình. Sáu tích hợp dưới ba cái tên — TeleChat4, XingChen4, Xing4_0 — là một đội đang lặp lại việc chọn cái tên mà mô hình sẽ được phát hành dưới đó, một cách công khai, trong khi trọng số vẫn riêng tư. Đó là suy luận chưa được xác minh, và đó là điều hệ trọng nhất mà dấu vết PR hiện cho thấy.

Hai PR tháng Chín thực sự bổ sung những gì

Pull request vLLM là một lần đổi tên công trình tháng Tám chứ không phải là viết lại nó. Tệp mô hình hiện là vllm/model_executor/models/xing4_0.py, lớp là Xing4_0ForCausalLM, và model_type xing4_0 được ánh xạ tới DeepseekV3Config — cùng cấu hình DeepSeek-V3 mà phiên bản XingChen4 đã dùng. Những gì nó mang theo:

• Một triển khai mô hình đầy đủ trong vllm/model_executor/models/xing4_0.py — lớp Xing4_0ForCausalLM, với lượt truyền xuôi, một bộ chuyển đổi mHC, và một triển khai load_weights() song song tensor. Thông điệp commit lưu ý rằng cả hai biến thể DSA và không DSA đều được hỗ trợ, tái sử dụng các thao tác mhc_pre / mhc_post dùng chung.

• Đăng ký Xing4_0ForCausalLM trong vllm/model_executor/models/registry.py, để vLLM nhận biết kiến trúc này theo tên.

• Một trình phân tích lập luận (vllm/reasoning/xing4_0_reasoning_parser.py) "dành cho các biến thể có khả năng lập luận," và một trình phân tích công cụ (vllm/tool_parsers/xing4_0_tool_parser.py) để tự động gọi công cụ.

• Đăng ký trong vllm/config/speculative.py, vllm/transformers_utils/model_arch_config_convertor.py và vllm/transformers_utils/config.py — với thông điệp commit nêu rõ rằng một đầu MTP tương thích DeepSeek-V3 được bật để giải mã suy đoán.

• Hai tệp tài liệu — phần thực sự mới, và một sự đảo ngược trực tiếp của tháng Tám. Commit gốc có một mục tài liệu và kiểm thử đã bị hoàn nguyên một giờ sau đó vì bị coi là quá sớm; PR tháng Chín đưa tài liệu trở lại và được gắn nhãn documentation, new-model và tool-calling.

Các mục tài liệu vLLM là nơi người đọc lần đầu biết được điều gì đó cụ thể. Trong docs/models/supported_models.md, hàng mới ghi là `Xing4_0ForCausalLM` | Xing4_0 | TBA — cột checkpoint thực sự ghi TBA, cũng chính là ý "chưa có" nhưng ở một phông chữ khác. Và trong docs/features/tool_calling.md, dưới tiêu đề "Xing4_0 Models (xing4_0)", PR ghi lại định dạng gọi công cụ của mô hình: các lệnh gọi được phát ra bên trong khối <tool_call>...</tool_call>, dưới dạng JSON ({"name": ..., "arguments": {...}}) hoặc dạng dựa trên thẻ dùng <param_key>...</param_key> và <param_value>...</param_value>. Đó là mức độ đặc tả mà các PR trước đó không đạt tới — một chi tiết triển khai trong định dạng trò chuyện của mô hình, được ghi lại trong tài liệu công khai của một framework lớn, cho một checkpoint không ai có thể tải xuống.

PR của SGLang thú vị hơn, vì nó cung cấp một triển khai và một cấu hình thay vì một mục đăng ký cùng tài liệu. Hàng tài liệu của nó là lần đầu tiên một framework đưa tên nhà cung cấp vào tài liệu của chính nó. Trong docs/docs/supported-models/generative_models.mdx, hàng mới liệt kê Xing4_0, với cột checkpoint ghi `Xing4_0` (sắp ra mắt) và một mô tả: "Mô hình MoE của China Telecom với attention MLA và các luồng residual mHC (Manifold-constrained Hyper-Connection); hỗ trợ giải mã suy đoán MTP gốc, gọi công cụ và suy luận." Hàng của vLLM ghi TBA và không nêu tên nhà cung cấp nào; hàng của SGLang nêu tên China Telecom và nói sắp ra mắt. Cả hai đều không phải là ngày phát hành, và một hàng trong tài liệu của framework không phải là một sản phẩm.

Mô tả PR bổ sung con số mà mọi phiên bản trước đó của câu chuyện này đều thiếu. "PR này bổ sung hỗ trợ cho Xing4.0-29B-A4B (MoE 29 tỷ tham số với ~4 tỷ tham số được kích hoạt)." Nó cũng đưa ra một lệnh khởi chạy — --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 — và nêu rằng cấu hình đã được kiểm chứng ở tensor parallelism 2, ngữ cảnh 262.144 token cùng giải mã suy đoán EAGLE MTP, kèm theo bản ghi của một phản hồi suy luận và một lệnh gọi công cụ get_weather được dán vào phần mô tả làm bằng chứng. Các trọng số đằng sau kiểm chứng đó là của chính tác giả: đường dẫn kho mà PR nêu tên không thể đọc công khai, và tổ chức Hugging Face mà nó trỏ tới không liệt kê bất kỳ mô hình công khai nào. Hãy coi kích thước, độ dài ngữ cảnh và các bản ghi là những tuyên bố do PR đưa ra gắn với một checkpoint riêng tư, chứ không phải là các phép đo mà bất kỳ ai cũng có thể lặp lại. Tất cả đều theo pull request và chưa được tái lập.

Việc các bộ phân tích lập luận và công cụ xuất hiện dưới cả hai tên gọi quan trọng vì cùng lý do như hồi tháng Tám. Một bộ phân tích lập luận tồn tại để loại bỏ các dấu hiệu suy nghĩ khỏi đầu ra của mô hình — chuỗi suy luận nội bộ mà mô hình phát ra trước câu trả lời cuối cùng. Một bộ phân tích được xây dựng riêng cho mô hình này nghĩa là dòng mô hình này được kỳ vọng sẽ có các biến thể có khả năng lập luận, giống như cách TeleChat3 đã phát hành các phiên bản Thinking. Bộ phân tích công cụ, cùng với định dạng gọi hàm giờ đã được ghi tài liệu, nghĩa là khả năng gọi hàm gốc cũng được kỳ vọng. Cả hai đều không phải là bảo đảm về sản phẩm cuối cùng; cả hai là những gợi ý mạnh nhất mà các PR mang lại về mục tiêu mà China Telecom đang nhắm tới.

Những gì chúng ta biết cho đến nay, nhìn thoáng qua

Bảng điểm dưới đây là bảng được tổng hợp cho bài viết này vào ngày 27 tháng 8 năm 2026, từ PR vLLM ở trạng thái khi đó. Nó được giữ ở đây một cách có chủ đích như một ảnh chụp nhanh gắn ngày thay vì được vẽ lại, vì từng dòng của nó vẫn đúng sau ba tuần — chưa phát hành, trọng số chưa công khai, backbone DeepSeek, residual mHC, bao gồm cả hai parser. Điều đã thay đổi không phải là một giá trị trên bảng mà là mọi thứ xung quanh nó: PR vLLM mà nó trích dẫn đã bị đóng vào ngày 7 tháng 9, công trình này xuất hiện trở lại dưới một tên mới vào ngày 16 tháng 9, SGLang bắt kịp việc đổi tên vài giờ sau đó và số lượng tham số được nêu lần đầu tiên cũng đến cùng với nó. Không có gì trên bảng là sai. Nó chỉ đơn giản đã ba tuần tuổi, và câu chuyện đã vượt qua nó. Các số liệu FlagGems ở hàng cuối của nó được giữ nguyên sang PR vLLM mới, vẫn được báo cáo qua PR và vẫn chưa được tái lập.

Kiến trúc mà các PR rò rỉ

Việc đổi tên một tệp không đổi tên một kiến trúc, và văn bản tóm tắt trong PR vLLM tháng 9 chính là văn bản tháng 8 với Xing4_0 được thay cho XingChen4 — từng mệnh đề một. Hai câu mang tín hiệu:

• "Xing4_0 tái sử dụng backbone Deep​Seek-V2/V3 (attention MLA, khối MoE, indexer DSA tùy chọn)."

• "Nó thay thế kết nối dư chuẩn bằng Hyper-Kết nối bị ràng buộc đa tạp (mHC): luồng dư được mở rộng thành num_residual_streams luồng song song được trộn bởi các ma trận ngẫu nhiên kép phụ thuộc đầu vào được tạo ra thông qua phép chiếu Sinkhorn-Knopp."

Mỗi mệnh đề đều tương ứng với một thứ cụ thể. MLA là Multi-head Latent Attention, cơ chế attention nén mà DeepSeek giới thiệu trong V2, cho phép KV cache duy trì dung lượng nhỏ; MoE là định tuyến mixture-of-experts, giúp giữ tổng số tham số lớn nhưng chỉ kích hoạt một phần nhỏ. Bộ đánh chỉ mục DSA tùy chọn là cơ chế DeepSeek Sparse Attention thuộc dòng V3.2 — một mô-đun chấm điểm nhẹ, chọn top-k token để attention tới, cắt chi phí attention từ bậc hai xuống gần như tuyến tính theo độ dài ngữ cảnh. Và câu về mHC chính là điểm nhấn: mô hình này áp dụng kiến trúc residual mà chính DeepSeek chỉ mới giới thiệu trong thế hệ này.

PR SGLang là cái đầu tiên công bố hình dạng của thứ này thay vì mô tả nó. Tệp cấu hình của nó, python/sglang/srt/configs/xing4_0.py, khai báo 40 lớp ẩn, kích thước ẩn 3.584 và từ vựng 131.072 token; MLA với hạng LoRA KV là 512 và hạng LoRA truy vấn là 768 trên 32 đầu; và một MoE thưa với 64 chuyên gia được định tuyến cộng thêm một chuyên gia chia sẻ, định tuyến top-4, chấm điểm sigmoid, hệ số tỉ lệ định tuyến 2,0 và lựa chọn chuyên gia noaux_tc. Các trường mHC cũng được nêu rõ ràng: hc_mult 4, hai mươi vòng lặp Sinkhorn-Knopp, kẹp h_res ở cộng hoặc trừ 30, và rope_theta là 10.000 với embedding vị trí tối đa là 262.144. Đây là các giá trị mặc định trong một tích hợp chưa được phát hành, theo pull request — tệp cấu hình là một tuyên bố về ý định, không phải thẻ mô hình, và con số 29B-A4B trong mô tả PR không được suy ra từ chúng ở bất cứ đâu công khai.

Một trường đáng giá hơn phần còn lại, vì đây là nơi đầu tiên mô hình này rõ ràng không còn là bản sao của DeepSeek. Cấu hình SGLang đặt hc_contract_for_draft, thứ hợp nhất các luồng mHC trở lại kích thước ẩn của chính mô hình trước norm cuối và đưa cái tensor đã được contract đó vào đầu draft của Eagle. DeepSeek V4 thay vào đó đưa tensor n-times-hidden_size đã được làm phẳng mHC. Chú thích trong cấu hình nói rõ điều này, và đây là kiểu chi tiết chỉ xuất hiện khi một bản triển khai đã được định hình dựa trên một checkpoint thật — điều mà checklist của PR SGLang trước đó tự nhận là có, nhưng không công bố nó.

Toán học mHC là nơi hai stack khác nhau về triển khai nhưng thống nhất về giả định. PR của vLLM lưu ý rằng nó “khớp với các ops dùng chung trong vllm.model_executor.layers.mhc, nên không có kernel riêng nào được đưa vào” — module đó tồn tại vì vLLM đã hỗ trợ mHC cho DeepSeek V4, nên chi phí gia tăng khi thêm model này là nhỏ. SGLang đạt đến cùng đích bằng một con đường khác: module mHC của nó dùng các kernel TileLang hợp nhất được đăng ký dưới dạng torch custom ops, và PR mở rộng kernel split-K mhc_pre hiện có để chấp nhận hc_hidden_size 14,336 bên cạnh hai kích thước mà nó đã xử lý. Nó cũng tắt đường tf32_hc_prenorm_gemm của DeepGEMM cho kiến trúc này, vì đường đó là một phần mở rộng C thuần mà torch.compile không thể trace; thay vào đó, mHC rơi xuống kernel TileLang. Lợi thế thực tế là như nhau ở cả hai framework: nếu hôm nay bạn phục vụ DeepSeek V4 trên vLLM hoặc SGLang, thì bộ máy sẽ phục vụ MoE tiếp theo của China Telecom đã được cài đặt sẵn.

mHC, thủ thuật DeepSeek nằm ở trung tâm của tất cả

Manifold-constrained Hyper-Connections đáng để mổ xẻ, bởi vì đây là điều thú vị nhất về mô hình này — và nó không phải là phát minh của China Telecom. Nó là của DeepSeek.

Câu chuyện bắt đầu với Hyper-Connections, được nhóm Ki​mi đề xuất vào năm 2024. Một Transformer tiêu chuẩn giữ một luồng residual cho mỗi lớp: đầu vào được cộng với đầu ra của lớp, mang lại cho gradient một đường đi rõ ràng và cho phép mạng học một hiệu chỉnh residual. Hyper-Connections thay thế luồng đơn đó bằng nhiều luồng song song được trộn bởi các ma trận đã học ở mỗi lớp, mang đến cho mô hình một đường đi phong phú hơn nhiều để thông tin truyền đi. Vấn đề nằm ở tính ổn định: các ma trận trộn không bị ràng buộc phá vỡ tính chất ánh xạ đồng nhất khiến các kết nối residual có thể huấn luyện được, và ở quy mô nghìn tỷ tham số, loss huấn luyện trở nên bất ổn.

Đóng góp của DeepSeek, được công bố dưới dạng bài báo mHC vào tháng 12 năm 2025 và sau đó được sử dụng trong DeepSeek V4, là ràng buộc các ma trận trộn phải là đôi ngẫu — không âm, với mỗi hàng và mỗi cột đều có tổng bằng một — được áp đặt bằng phép chiếu Sinkhorn-Knopp trong quá trình huấn luyện. Một ma trận đôi ngẫu có bán kính phổ đúng bằng một, nên các tín hiệu không thể bị khuếch đại hoặc suy giảm theo cấp số nhân khi đi qua hàng trăm lớp. Chính ràng buộc đó giữ cho quá trình huấn luyện ổn định ở quy mô lớn, và phép chiếu này đủ rẻ để DeepSeek báo cáo chỉ tốn thêm khoảng 6,7% chi phí huấn luyện với bốn luồng residual. DeepSeek V4, phát hành ngày 24 tháng 4 năm 2026, là ứng dụng chủ lực của nó, với mức tăng được báo cáo khoảng 15% trên các tác vụ suy luận toán học và ngữ cảnh 1M token ở trên hết.

Vậy nên, nói một cách dễ hiểu, điều mà những PR này đang nói là: mô hình tiếp theo của China Telecom dùng bộ xương sống đã được chứng minh của DeepSeek và cơ chế residual mới nhất của DeepSeek thay vì tự phát minh cả hai từ đầu. Đó là một lựa chọn thực dụng, và nó mang theo một sự xác nhận tinh tế — phòng thí nghiệm lớn thứ hai sau chính DeepSeek áp dụng mHC tin rằng thủ thuật này đã sẵn sàng để đưa vào sản xuất.

Các PR vẫn chưa hoàn thiện mHC, và các hạng mục còn mở cũng trung thực về điều đó. Trong các PR vLLM, tác giả lưu ý rằng các bias checkpoint (bias_pre, bias_post, bias_res) và một clamp h_res hiện đang được hợp nhất hoặc bị lược bỏ, và rằng việc người phản biện xác nhận tính tương đương của công thức là "câu hỏi chính về tính đúng đắn". Ngoài ra còn có một toán tử chuyển vị tùy chỉnh giữ một tensor ở dạng C-contiguous cho kernel TileLang — được đổi tên cùng với mọi thứ khác, từ _xingchen4_transpose_contiguous thành _xing4_0_transpose_contiguous — và một hạn chế cứng: song song hóa pipeline không được hỗ trợ trong chế độ mHC khi num_residual_streams lớn hơn một, trong khi song song hóa tensor được hỗ trợ. Không có gì trong số này đáng ngạc nhiên đối với một bản nháp, nhưng nó vẫn là cùng một điểm chưa hoàn thiện như hồi tháng Tám, và điều đó tự nó đã mang tính thông tin: sáu tuần đổi tên vẫn chưa làm nhích câu hỏi về tính đúng đắn, và ba lần chạy CI đỏ trên PR SGLang mới nhất cũng là câu chuyện đó với một màu khác. Điều mà cấu hình SGLang thực sự giải quyết được là số lượng stream. Với hc_mult được đặt thành 4 và kích thước ẩn là 3.584, con số 14.336 trong bản vá kernel đúng là bốn stream — và bình luận trong kernel nói thẳng ra như vậy. Cách hiểu đó từng là suy luận từ một con số trần khi bài viết này lần đầu xuất hiện; giờ đây nó đã được ghi lại trong một tệp cấu hình.

Góc tăng tốc: FlagGems, một lần nữa

Một mối liên hệ thứ hai gắn mô hình này với mối quan hệ hiện có của China Telecom với Viện Hàn lâm Trí tuệ Nhân tạo Bắc Kinh, và đây là mối liên hệ duy nhất vẫn còn nguyên vẹn qua mọi lần đổi tên. PR của vLLM cho phép tăng tốc FlagOS/FlagGems tùy chọn đằng sau cờ môi trường USE_FLAGOS, mặc định bị tắt, thay thế bằng các kernel hot-path cho MoE, attention, softmax và top-k. Lợi ích được tuyên bố, từ bài benchmark H100 của tác giả PR trên khối lượng công việc prompt dài có độ đồng thời cao (hơn 10K token đầu vào, độ đồng thời 10): giảm tới 19,87% thời gian đến token đầu tiên và giảm tới 26,32% thời gian trên mỗi token đầu ra, trong khi các khối lượng công việc khác không thay đổi. Những con số đó do PR báo cáo và chưa được tái lập, và chúng đi kèm với việc cờ mặc định bị tắt.

Điều đáng ghi nhận là việc đổi tên đã động đến rất ít. PR vLLM tháng 9 mang cùng những con số, cùng ghi chú phạm vi hẹp rằng cờ chỉ nằm bên trong tệp mô hình, và cùng chỉ dẫn cài đặt flagtree và flag-gems. Các con số không thay đổi vì mã nguồn không thay đổi; chỉ có nhãn thay đổi. Các pull request SGLang không hề có luồng FlagGems nào — thay vào đó chúng đi theo hướng TileLang và DeepGEMM — khiến đây trở thành một cuộc tranh luận về việc ai sở hữu phần tối ưu hóa của lớp phục vụ, chứ không phải về mô hình.

Đây là một câu chuyện tiếp nối. TeleChat3-36B-Thinking, tính đến tháng 4 năm 2026, là mô hình lớn đầu tiên được chuyển độc lập sang FlagOS, ngăn xếp phần mềm AI mã nguồn mở của BAAI. Dù mô hình này được phát hành dưới hình thức nào, việc tiếp nối mạch đó — với các kernel FlagGems nằm trong tích hợp vLLM của chính nó — cho thấy chiến lược ngăn xếp nội địa của phòng thí nghiệm mở rộng sang cả lớp phục vụ, chứ không chỉ huấn luyện.

Câu hỏi về việc đặt tên, và gia đình mà nó đến từ

Cho đến ngày 16 tháng 9, câu hỏi về tên gọi vẫn chỉ là một ghi chú bên lề. Giờ đây nó gần như đã khép lại, và bằng chứng vẫn nằm tất cả ở tên nhánh và những chuỗi còn sót lại thay vì các tuyên bố — nhưng hai framework đã hội tụ về cùng một câu trả lời từ cùng một hướng.

• Các thông điệp commit, theo thứ tự: "Add TeleChat4 model support," rồi "chore: revert premature docs and test entry for telechat4," rồi — ba tuần sau và một phút trước khi PR bị đóng — "rename xingchen4." Một commit mà toàn bộ mục đích chỉ là việc đổi tên.

• Fork phân nhánh. Hai PR vLLM đầu tiên, #51237 và #54051, được tách ra từ zyp2014:supported_telechat4. PR thứ ba, #57135, là zyp2014:support_xing4_0. Nhánh đã được đổi tên trong cùng thao tác đã đổi tên mô hình — và phía SGLang giờ đã đi cùng một con đường hệt như vậy qua ba bước, từ support_telechat4 qua support_xingchen4 đến support_xing4_0.

• Phần nội dung của #51237, trong đó nói rằng tăng tốc FlagGems là “dành cho TeleChat4”, trong khi cũng chính đoạn văn đó lại gọi mô hình là XingChen4. Hai cái tên ấy đã vốn xung đột với nhau ngay trong phần tóm tắt của chính tác giả vào ngày 6 tháng 8.

• Việc đổi tên tương ứng từng tệp ở cả hai phía. Trong vLLM, đó là xingchen4.py thành xing4_0.py và XingChen4ForCausalLM thành Xing4_0ForCausalLM; trong SGLang, đó là xingchen4.py thành xing4_0.py và XingChen4Config thành Xing4_0Config, trên một nhánh cũng đổi tên theo. Không PR nào để lại tên cũ ở bất cứ đâu trong diff của nó.

Vậy là ba cái tên đã xuất hiện xuyên suốt hai framework, và mô thức này khớp với việc một mô hình duy nhất được đổi tên khi nó tiến gần tới cái tên công khai cuối cùng của nó. “Xing4_0” đọc lên tự nhiên như Xingchen 4.0 — dòng mô hình này được đặt thương hiệu là 星辰 (Xingchen) trong tiếng Trung — nhưng đó vẫn là suy luận từ chuỗi ký tự, không phải điều mà bất kỳ thông cáo nào nói thẳng ra. Cũng có thể TeleChat4 và XingChen4 là anh em cùng một thế hệ chứ không phải một mô hình dưới hai cái tên, dù việc cùng chung bản fork, cùng đoạn mô tả kiến trúc, cùng các con số FlagGems, cùng các mục mở và giờ là cùng một lần đổi tên khiến lập luận đó khó đứng vững hơn. Chưa ai xác nhận mối quan hệ này và China Telecom chưa bình luận. Điều đã thay đổi là việc đổi tên không còn là lựa chọn của một người đóng góp: hai dự án serving độc lập, do những người khác nhau duy trì, đều đã dán lại nhãn phần tích hợp của họ sang cùng cái tên thứ ba trong vòng một ngày của nhau.

Bản thân họ này đáng để lưu tâm, vì nó giải thích cho tính thực dụng. Các bản phát hành công khai cho đến nay đều mang thương hiệu TeleChat:

TeleChat-7B và TeleChat-12B, được mã nguồn mở vào tháng 1 năm 2024 với kho ngữ liệu 1 nghìn tỷ token.

• TeleChat2-115B (tháng 9 năm 2024), được giới thiệu là mô hình mở nghìn tỷ tham số hoàn toàn nội địa đầu tiên, cùng với các phiên bản anh em 35B, 7B và 3B.

• TeleChat2-39B-A12B (tháng 3 năm 2025), MoE đầu tiên của dòng sản phẩm.

• TeleChat3-105B-A4.7-Thinking (tháng 12 năm 2025), một mô hình MoE hạt mịn với tổng 105B tham số và 4.7B tham số hoạt động, được huấn luyện trên 15 nghìn tỷ token, cùng với mô hình dense TeleChat3-36B và sau đó là TeleChat3-Coder-36B-Thinking.

Nếu con số 29B-A4B là đúng, thì mô hình này sẽ nằm dưới TeleChat3-105B-A4.7-Thinking về cả tổng tham số lẫn tham số hoạt động — một phiên bản em nhỏ hơn, rẻ hơn thay vì một mẫu flagship thay thế. Đó là một cách diễn giải, không phải sự thật; không có gì trong cả hai PR nói rõ mô hình nhắm đến phân khúc nào. Thương hiệu Xingchen là nơi công ty dồn nỗ lực AI: Xingchen AGI Lab được chính thức thành lập tại Bắc Kinh vào tháng 3 năm 2026, dựa trên cùng dòng mô hình, và China Telecom mô tả hệ thống “三全” (toàn phương thức, toàn kích cỡ, hoàn toàn nội địa) của mình là bao trùm các mô hình ngữ nghĩa, giọng nói, thị giác và đa phương thức từ 1B đến hơn 1T tham số. Việc đổi tên từ TeleChat thành Xingchen chính là điều một phòng thí nghiệm làm khi muốn dòng mô hình mang thương hiệu của phòng thí nghiệm thay vì thương hiệu của dòng sản phẩm.

Những gì chúng ta vẫn chưa biết

Với một mô hình còn ở giai đoạn đầu như thế này, danh sách trung thực vẫn dài hơn danh sách đã biết, dù nó đã thu hẹp ở hai chỗ trong tuần này:

• Không có ngày phát hành. Năm trong số sáu bản tích hợp là bản nháp được mở để đánh giá mã sớm, chính xác là vì trọng số chưa được công khai. Bản thứ sáu, SGLang #39793, đang mở để đánh giá thay vì ở dạng nháp — nhưng nó chưa được hợp nhất, cả ba lần chạy CI của nó đều đang thất bại và nó cần một người đánh giá phê duyệt. Không có lịch trình nào được công bố.

• Số lượng tham số, nhưng chỉ là con số được tuyên bố. Mọi phiên bản trước đó của bài viết này đều liệt kê cấu hình MoE là không được tiết lộ. PR của SGLang thay đổi điều đó trên giấy tờ: Xing4.0-29B-A4B, tổng 29B, khoảng 4B hoạt động. Con số này đến từ một pull request, không gắn với checkpoint công khai nào, không được tệp cấu hình nào xác nhận và chưa được ai ngoài dự án tái lập. Hãy coi đó là ý định được nêu ra, không phải thông số kỹ thuật.

• Không có con số benchmark nào, dù do nhà cung cấp báo cáo hay từ nguồn khác, và cũng không có điểm số độc lập nào. Các bản ghi xác minh trong PR của SGLang cho thấy mô hình trả lời một lời nhắc suy luận và phát ra một lệnh gọi công cụ đúng định dạng; chúng cũng không cho thấy gì về việc mô hình làm hai việc đó tốt đến đâu.

• Không có thông tin về giá và cũng không có giấy phép được xác nhận. Mọi bản phát hành TeleChat trước đây đều là Apache-2.0, điều này rất đáng khích lệ, nhưng chưa có giấy phép nào được nêu cho bản này.

• Không có trọng số công khai — được xác nhận chứ không phải giả định. Tính đến ngày 16 tháng 9 năm 2026, đường dẫn Hugging Face mà PR SGLang nêu tên không thể đọc công khai và tổ chức mà nó trỏ tới không liệt kê mô hình công khai nào; mục công khai mới nhất trong dòng họ này là TeleChat3-Coder-36B-Thinking từ tháng Một. Bảng mô hình được hỗ trợ của vLLM ghi TBA ở cột checkpoint, còn của SGLang ghi "sắp ra mắt", và cả hai PR SGLang đều có CI công khai đang thất bại.

• Không có thông tin chính thức nào từ China Telecom — không có thông báo, không có trọng số, không có xác nhận về tên hay kích thước. Hãy lưu ý kỹ sự bất đối xứng: dòng tài liệu SGLang gán mô hình cho China Telecom, nhưng đó là mô tả của một người đóng góp bên trong một pull request, không phải tuyên bố của công ty, và mô tả PR mới nhất đã loại bỏ hoàn toàn tên nhà cung cấp. Sáu tích hợp đang được xây dựng cho mô hình này là bằng chứng mạnh mẽ nhất cho đến nay rằng nó có thật, nhưng các tích hợp có thể bị đóng và tên mã có thể thay đổi; hai đã như vậy. Không có gì được xác nhận cho đến khi phòng thí nghiệm nói như vậy.

Cách diễn giải đúng về tất cả những điều này không phải là sự hoài nghi về mô hình; mà là một bức tranh chính xác về một tín hiệu ban đầu. Những gì tồn tại ngày nay là một sản phẩm kỹ thuật thực sự — sáu sản phẩm như vậy, trải rộng trên hai framework — với một kiến trúc thực sự và, lần đầu tiên, một hình dạng đã được nêu rõ gắn kèm theo. Điều chưa tồn tại là bất cứ thứ gì bạn có thể tải xuống, gọi hoặc benchmark.

Điều gần nhất bạn có thể chạy hôm nay

Mô hình này không thể phục vụ ở bất cứ đâu — không qua API, cũng không chạy cục bộ, vì trọng số không được công khai. Mô hình gần nhất mà người đọc thực sự có thể gọi hôm nay có chung DNA kiến trúc là DeepSeek V4 Flash, sử dụng cùng sơ đồ residual mHC trên nền MLA và MoE, và đây chính là bản triển khai tham chiếu mà các mô-đun mHC dùng chung trong cả hai framework được xây dựng cho. Trang mô hình của OrcaRouter cho deepseek/deepseek-v4-flash liệt kê ngữ cảnh 1M token, đầu ra tối đa 384K và giá niêm yết $0.15 mỗi triệu token đầu vào cùng $0.29 mỗi triệu token đầu ra — đúng những con số mà chính Deep​Seek công bố, được chuyển tiếp với mức markup 0%, nên khi nhà cung cấp thay đổi giá thì tại đây cập nhật ngay trong cùng ngày. Một khóa API bao trùm toàn bộ danh mục, khiến việc so sánh nó với phần còn lại của nhóm mô hình suy luận trở thành một quy tắc định tuyến thay vì một tích hợp mới.

Đó cũng là câu trả lời thực tế cho câu hỏi "làm sao để tôi thử mô hình này khi nó ra mắt." Một checkpoint hoàn toàn mới, chưa được chứng minh chính là nơi failover tự động chứng minh được giá trị của nó: định tuyến một phần nhỏ lưu lượng đến nó, giữ một mô hình đã được chứng minh làm phương án dự phòng, và để lớp định tuyến đưa ra quyết định thay vì đánh cược một luồng production vào hành vi ngay ngày đầu. Một MoE 29B với khoảng 4B tham số hoạt động, nếu đó là thứ sẽ xuất hiện, là một thứ rẻ để định tuyến đối chiếu với một mô hình tiên phong, chính vì quá ít phần của nó được kích hoạt trên mỗi token. Nếu cái tên lại thay đổi một lần nữa từ giờ đến lúc phát hành — và sáu tuần qua cho thấy điều đó có thể xảy ra — thì quy tắc định tuyến mới là thứ bạn viết lại, không phải phần tích hợp.

Các câu hỏi thường gặp

Tại sao PR của vLLM lại bị đóng?

Chúng ta có thể thấy việc đóng, chứ không thấy lý do. #54051 đã bị chính tác giả của nó đóng vào ngày 7 tháng 9 năm 2026 mà không được hợp nhất, và công việc này tái xuất hiện chín ngày sau đó dưới một tên mới là #57135. Một PR vLLM trước đó, #51237, đã bị đóng và gửi lại trong cùng ngày với cùng tiêu đề, nên việc đóng rồi gửi lại là mô thức của tác giả này chứ không phải dấu hiệu của rắc rối — nhưng phần nội dung PR không nêu lý do và chúng ta sẽ không tự bịa ra một lý do.

Khi nào Xing4_0 sẽ được phát hành?

Không có ngày cụ thể. Năm trong số sáu tích hợp là bản nháp được mở để xem xét mã sớm, và kế hoạch của chính các tác giả là thêm các mục kiểm thử, cập nhật tài liệu và chỉ đánh dấu các PR là sẵn sàng sau khi trọng số được phát hành. Danh sách kiểm tra cũ hơn của SGLang là tuyên bố rõ ràng nhất về tình hình hiện tại: "Mô hình tải & sinh (cục bộ, trên trọng số nội bộ)" đã được đánh dấu, và CI công khai đang "bị chặn do chưa phát hành trọng số." PR SGLang mới hơn được nộp ở trạng thái sẵn sàng xem xét thay vì bản nháp, đó là sự thay đổi về thái độ chứ không phải thay đổi về trạng thái — nó chưa được hợp nhất, CI của nó đang đỏ, và một dòng tài liệu ghi "sắp ra mắt" không phải là một sự ra mắt.

Xing4_0 có phải là cùng một mô hình với XingChen4 không?

Gần như chắc chắn là đúng, và các PR khiến việc kiểm tra trở nên dễ dàng: cùng nguồn gốc fork, cùng đoạn kiến trúc, cùng số liệu benchmark FlagGems, cùng các mục còn bỏ ngỏ, và việc đổi tên từng tệp một trong cả hai framework — xingchen4.py thành xing4_0.py, bao gồm cả lớp config, trên các nhánh được đổi tên cho khớp. Đó là cùng một công việc khoác lên mình một cái tên mới, và tính đến ngày 16 tháng 9, cả vLLM lẫn SGLang đều đã dùng cái tên đó. Điều mà không PR nào nói rõ là bản checkpoint được phát hành sẽ mang tên nào.

Đây có phải là mô hình DeepSeek không?

Không. Đó là mô hình của China Telecom, đến từ Xingchen AGI Lab. Mối liên hệ với DeepSeek mang tính kiến trúc: nó tái sử dụng xương sống DeepSeek-V2/V3 và sơ đồ residual mHC mà DeepSeek đề xuất và phát hành trong V4. Việc áp dụng kiến trúc của người khác không đồng nghĩa với việc hai dự án có liên quan với nhau.

Xem gì tiếp theo

Các PR vẫn đưa ra một danh sách kiểm tra cụ thể, và cặp ngày 16 tháng 9 đã thêm hai mục vào đó. Thứ nhất, các trọng số: mọi tác giả đều nói công trình của họ đang chờ trên Hugging Face, nên việc một repo công khai xuất hiện là sự kiện mấu chốt — và PR SGLang giờ cho bạn đường dẫn chính xác để theo dõi, XingChen-AGI/Xing4.0-29B-A4B, thứ hiện không phân giải cho bất kỳ ai. Thứ hai, bản thân các PR: PR của vLLM cần các công thức bias mHC được xác nhận, mục test trong registry được thêm vào và CI của nó xanh; #39793 của SGLang cần sửa ba lần chạy đỏ của nó và mười reviewer được yêu cầu phê duyệt, trong khi #37228 cũ hơn vẫn cần mục test của nó, benchmark tăng tốc MTP của nó và một CI không bị chặn. Thứ ba, và mới trong tuần này: liệu SGLang có đóng #37228 để chuyển sang #39793 theo cách vLLM vẫn luôn đóng một PR tiền nhiệm trước khi nộp lại hay không. Hai tích hợp đang hoạt động cho một mô hình chưa phát hành là trạng thái mà không ai duy trì lâu, và việc cái nào tồn tại sẽ nói lên điều gì đó về mức độ gần gũi thực sự của việc này. Thứ tư, các con số: liệu một checkpoint đã phát hành có khớp với hình dạng 29B-A4B, MoE 64 chuyên gia và ngữ cảnh 262.144 token mà config và mô tả PR giờ khẳng định hay không. Thứ năm, liệu PR vLLM thứ ba có tồn tại lâu hơn hai PR tiền nhiệm, lần lượt kéo dài 21 và 11 ngày trước khi bị đóng mà không được hợp nhất hay không. Và hãy để ý liệu các parser suy luận có đang mô tả một biến thể Thinking riêng biệt theo cách TeleChat3 đã phát hành một biến thể như vậy hay không.

Cho đến khi một trong những điều đó xảy ra, hãy coi mô hình này đúng như bản chất của nó: một kế hoạch được đặc tả kỹ lưỡng từ một phòng thí nghiệm nghiêm túc, bị bắt quả tang đang chuẩn bị hạ tầng phục vụ của mình — giờ đây trong cả hai ngăn xếp phục vụ mã nguồn mở lớn, dưới một cái tên mà cả hai đều đã dùng và một kích thước mà chỉ pull request của chính nó nêu rõ. Chỉ riêng kiến trúc đã khiến nó đáng theo dõi: đây là lần áp dụng lớn thứ hai của mHC sau chính Deep​Seek, đến từ một phòng thí nghiệm mà thế hệ trước đã là một MoE hạt mịn được huấn luyện trên chip nội địa. Khi trọng số được phát hành, sẽ không còn câu hỏi liệu nó chạy trong vLLM hay SGLang. Cả hai ngăn xếp đều đã viết mã đó ba lần, dưới ba cái tên khác nhau.