Xing4_0 มาถึง SGLang: PR ฉบับที่หก และขนาดที่ระบุไว้เป็นครั้งแรก สำหรับ MoE ตัวถัดไปของ China Telecom

ห่างกันสองชั่วโมงเมื่อวันที่ 16 กันยายน 2026 สแตกเซิร์ฟเวอร์โอเพนซอร์สสองตัวที่ครองตลาดก็เลิกขัดแย้งกันเรื่องชื่อเสียที vLLM ยื่น "[Model] Add Xing4_0 support" ในช่วงเช้า ตามด้วย sgl-project/sglang ที่ยื่น "feat: add Xing4_0 model support" เมื่อเวลา 10:38 UTC และหลังจากหกสัปดาห์ที่มีสามชื่อวนเวียนอยู่ ตอนนี้ทั้งสองเฟรมเวิร์กต่างก็เรียกมันว่า Xing4_0 พูลรีเควสต์ของ SGLang มีสิ่งหนึ่งที่ฉบับก่อนหน้าไม่มี นั่นคือขนาด โดยระบุว่าโมเดลนี้คือ Xing4.0-29B-A4B ซึ่งเป็น "MoE ขนาด 29B พารามิเตอร์ ที่เปิดใช้งานจริงราว 4B พารามิเตอร์" พร้อมคำสั่งรันที่ระบุพาธเช็กพอยต์ คอนเท็กซ์ 262,144 โทเคน และการถอดรหัสเชิงคาดการณ์แบบ EAGLE นี่คือ MoE ที่ยังไม่เปิดตัวของ China Telecom ตัวเดียวกับที่พูลรีเควสต์ XingChen4 วนเวียนอยู่ตั้งแต่เดือนสิงหาคม และมันก็ยังไม่เปิดตัวอยู่ดี: น้ำหนักโมเดลยังไม่เปิดเผย พาธเช็กพอยต์ที่พูลรีเควสต์ระบุไว้ไม่สามารถเข้าถึงได้สำหรับคนนอกโปรเจกต์ ไม่มีผู้จำหน่ายรายใดยืนยันชื่อหรือตัวเลขนี้ และไม่มีสิ่งใดในบทความนี้ที่ผ่านการตรวจสอบอย่างอิสระ ข้อเท็จจริงที่ดึงมาจากพูลรีเควสต์จะถูกกำกับไว้เช่นนั้น ส่วนที่เหลือคือภูมิหลังและการอนุมาน โมเดลที่ใกล้เคียงที่สุดที่คุณเรียกใช้ได้จริงในวันนี้คือ DeepSeek V4 Flash

นี่คือบทความแบบ "เท่าที่เรารู้จนถึงตอนนี้" ที่อัปเดตให้ทันสมัยอยู่เสมอ มากกว่าจะเริ่มเขียนใหม่ทั้งหมด มันครอบคลุมเส้นทาง PR ตลอดหกสัปดาห์และคำถามเรื่องการตั้งชื่อได้รับการคลี่คลายอย่างไร สอง pull request วันที่ 16 กันยายนเพิ่มอะไรเข้าไปจริง ๆ สถาปัตยกรรมที่ไฟล์คอนฟิกตอนนี้เผยรายละเอียดจริง และสิ่งที่ควรจับตาต่อไป ฉบับหนึ่งประโยค: MoE ตัวถัดไปของ China Telecom เป็นของจริงมากพอจนสะสมการผสานรวมการให้บริการได้หกรายการ มีแถวในตารางของ vLLM ที่ทำเครื่องหมายว่า TBA มีรายการเอกสารใน SGLang ที่ระบุว่า "เร็ว ๆ นี้" และมีจำนวนพารามิเตอร์ที่ระบุไว้ — แต่ก็ยังไม่จริงพอที่จะรันในที่ใดก็ตามที่คุณเข้าถึงได้

สัญญาณ: การผสานรวมหกอย่าง สามชื่อ หกสัปดาห์

ร่องรอยเริ่มขึ้นเร็วกว่าเวอร์ชันของเรื่องนี้ที่รายงานไว้ครั้งแรก และบันทึกคอมมิตของมันยังคงเป็นหลักฐานที่เปิดเผยมากที่สุดในข้อมูลที่รั่วไหล PR vLLM ฉบับแรกคือ #51237 เปิดเมื่อวันที่ 6 สิงหาคม 2026 ภายใต้ชื่อ "[WIP][Model] เพิ่มการรองรับโมเดล XingChen4 ที่กำลังจะมาถึง" สามคอมมิตของมันเล่าเรื่องได้ด้วยตัวเอง อันแรกมีชื่อว่า "เพิ่มการรองรับโมเดล TeleChat4" อันที่สอง มากกว่าหนึ่งชั่วโมงถัดมา มีชื่อว่า "chore: ย้อนกลับเอกสารและรายการทดสอบสำหรับ telechat4 ที่ทำก่อนกำหนด" — เอกสารและรายการทดสอบใน registry ถูกถอนกลับออกไปเนื่องจากยังเร็วเกินไป อันที่สาม เมื่อวันที่ 27 สิงหาคม มีชื่อว่า "เปลี่ยนชื่อ xingchen4" หนึ่งนาทีต่อมา PR ถูกปิดโดยไม่ได้ merge และสิบเอ็ดนาทีหลังจากนั้น #54051 เปิดด้วยชื่อเดียวกัน สาขา fork เดียวกัน (supported_telechat4) และคอมมิตที่ squash รวมเป็นหนึ่งเดียว ในระหว่างนั้นมีป้าย needs-rebase ถูกติดไว้ ดังนั้นเรื่องนี้อ่านได้ว่าเป็นการปิดแล้วเปิดใหม่หลังทำความสะอาด มากกว่าการเปลี่ยนใจ ทั้งหมดถูกยื่นจากบัญชี GitHub zyp2014 โดยทุกคอมมิตเขียนและลงนามรับรองโดย zhangyp26 <zhangyp26@chinatelecom.com.cn>

PR ที่สองนั้นคือ PR ที่บทความชิ้นนี้ถูกสร้างขึ้นมาโดยอ้างอิงเป็นหลักตั้งแต่แรก และตอนนี้ก็ไม่ได้เปิดอยู่อีกต่อไป #54051 ถูกปิดโดยผู้เขียนเองเมื่อวันที่ 7 กันยายน 2026 โดยไม่ได้ถูก merge คำอธิบายของมันก็ยังคุ้มค่าที่จะยกมาอ้างอยู่ดี เพราะมันเป็นประโยคที่ผ่านการเปลี่ยนชื่อและการเปิดใหม่ทุกครั้งมาได้:

น้ำหนักของโมเดลยังไม่เปิดเผยต่อสาธารณะบน Hugging Face Hub PR นี้เปิดขึ้นเพื่อการตรวจสอบโค้ดล่วงหน้า เมื่อมีการเผยแพร่น้ำหนักโมเดลแล้ว ฉันจะเพิ่มรายการทดสอบใน tests/models/registry.py อัปเดต docs/models/supported_models.md และทำเครื่องหมาย PR ว่าพร้อมสำหรับการตรวจสอบ

ประโยคนั้นคือรูปทรงของเรื่องราวทั้งหมด: โค้ดนำหน้าน้ำหนัก ภาพหน้าจอด้านล่างคือหน้า #54051 อย่างที่ปรากฏเมื่อวันที่ 27 สิงหาคม 2026 วันที่มันเปิดขึ้น — เป็นสแนปช็อตที่ระบุวันที่ ซึ่งเก็บไว้เพราะ pull request ที่มันแสดงได้ถูกปิดไปแล้วตั้งแต่นั้น อ่านมันเป็นบันทึกของสัญญาณ ณ ขณะนั้น ไม่ใช่สถานะของมันในตอนนี้

จากนั้น ในวันที่ 16 กันยายน รูปแบบเดิมก็เกิดซ้ำ — สองครั้งในวันเดียว #57135, "[Model] เพิ่มการรองรับ Xing4_0" เปิดขึ้นในเช้าวันนั้นจากบัญชีเดียวกัน zyp2014 โดยมีคอมมิตเดียวที่ปัจจุบันมีผู้เขียนเป็นวิศวกร China Telecom คนละคน — xiongji <xiongj9@chinatelecom.cn> มีไฟล์เปลี่ยนแปลงสิบเอ็ดไฟล์ เพิ่มราว 1,300 บรรทัด ชื่อใหม่ตลอดทั้งฉบับ และข้อแม้เดิมในตำแหน่งเดิม: "น้ำหนักโมเดลยังไม่เปิดเผยต่อสาธารณะบน Hugging Face Hub"

สองชั่วโมงยี่สิบนาทีต่อมา สแตกการให้บริการอีกตัวหนึ่งก็เลิกเป็นฝ่ายตามหลังอยู่แค่การเปลี่ยนชื่อครั้งเดียว sgl-project/sglang #39793 "feat: add Xing4_0 model support" ถูกเปิดจากแบรนช์ที่ชื่อ support_xing4_0 และคอมมิตเดียวของมันมีที่อยู่ xiongji เดียวกันกับการเปลี่ยนชื่อใน vLLM สิบสี่ไฟล์กับการเพิ่มโค้ดราว 1,400 บรรทัด ซึ่งมากกว่าหนึ่งพันบรรทัดเป็นไฟล์โมเดลไฟล์เดียว มันคือการผสานรวมครั้งที่หกที่ถูกยื่นสำหรับโมเดลนี้ในรอบหกสัปดาห์ และเป็นครั้งแรกที่ถูกยื่นแบบไม่ใช่ฉบับร่าง: GitHub ระบุว่ามันเปิดอยู่และพร้อมสำหรับการรีวิว โดยขอผู้รีวิวมาสิบคน — และการรัน CI ทั้งสามครั้งของมันก็แดงไปหมดแล้ว

ฝั่ง SGLang ก่อนวันนี้ดำเนินไปในแบบเดียวกับที่ฝั่งของ vLLM ทำ#33982, "feat(model): add TeleChat4 model support," ถูกเปิดเมื่อวันที่ 7 สิงหาคม 2026 โดยผู้ร่วมพัฒนา PaddyXj และถูกปิดโดยไม่ถูก merge เมื่อวันที่ 31 สิงหาคม — วันเดียวกับที่#37228, "feat: add XingChen4 model support," ถูกเปิดขึ้นแทนที่ อันนั้นยังคงเปิดอยู่เป็นฉบับร่างภายใต้ชื่อ PaddyXj บนแบรนช์ที่ชื่อsupport_xingchen4, ลึกไปสามคอมมิต และถูกแตะครั้งล่าสุดเมื่อวันที่ 8 กันยายน เช็กลิสต์ของมันคือสิ่งที่น่าสนใจที่สุดในทั้งสองเฟรมเวิร์ก: การที่โมเดลโหลดและสร้างผลลัพธ์ "ในเครื่อง บนเวทต์ภายใน" ถูกติ๊กแล้ว การเรียกใช้เครื่องมือถูกติ๊กแล้ว การแยกวิเคราะห์การให้เหตุผลถูกติ๊กแล้ว — และ CI สาธารณะยังไม่ถูกติ๊ก เพราะมัน "ถูกบล็อกอยู่ที่การปล่อยเวทต์" มีใครสักคนถือเช็กพอยต์อยู่ แต่ไม่มีใครเผยแพร่มัน และต่างจาก vLLM ที่ทุกการยื่นเรื่องใหม่จะปิดตัวก่อนหน้าไปก่อน ตอนนี้ SGLang มีพูลรีเควสต์ที่ยังเปิดอยู่สองอันสำหรับโมเดลเดียวกัน ภายใต้ชื่อที่ต่างกันสองชื่อ

สิ่งที่การผสานรวมหกครั้งในหกสัปดาห์รวมกันแล้วกลายเป็น ไม่ใช่สัญญาณเดิมที่แข็งแกร่งขึ้น แต่เป็นสัญญาณที่แตกต่างออกไป การผสานรวมหกครั้งจะสอดคล้องกับทีมที่กำลังวนซ้ำ การผสานรวมหกครั้งภายใต้สามชื่อ — TeleChat4, XingChen4, Xing4_0 — คือทีมที่กำลังวนซ้ำกับชื่อที่โมเดลจะเปิดตัวภายใต้นั้น ต่อสาธารณะ ในขณะที่ค่าน้ำหนักยังคงเป็นส่วนตัว นั่นคือการอนุมานที่ยังไม่ได้รับการยืนยัน และมันเป็นสิ่งที่มีนัยสำคัญที่สุดที่ร่องรอย PR แสดงให้เห็นในตอนนี้

สิ่งที่ PR สองรายการในเดือนกันยายนเพิ่มเข้ามาจริง ๆ

pull request ของ vLLM นี้เป็นการเปลี่ยนชื่อของงานเดือนสิงหาคม มากกว่าจะเป็นการเขียนงานนั้นใหม่ ไฟล์โมเดลตอนนี้คือ vllm/model_executor/models/xing4_0.py คลาสคือ Xing4_0ForCausalLM และ model_type xing4_0 ถูกแมปไปยัง DeepseekV3Config — ซึ่งเป็นคอนฟิก Deep​Seek-V3 ตัวเดียวกับที่เวอร์ชัน XingChen4 ใช้ สิ่งที่มันบรรจุ:

• การนำโมเดลไปใช้แบบเต็มรูปแบบใน vllm/model_executor/models/xing4_0.py — คลาส Xing4_0ForCausalLM พร้อม forward pass, อะแดปเตอร์ mHC และการนำ load_weights() แบบ tensor-parallel ไปใช้ ข้อความ commit ระบุว่ารองรับทั้งรูปแบบ DSA และ non-DSA โดยนำ ops mhc_pre / mhc_post ที่ใช้ร่วมกันกลับมาใช้

• การลงทะเบียน Xing4_0ForCausalLM ใน vllm/model_executor/models/registry.py เพื่อให้ vLLM รู้จักสถาปัตยกรรมนี้ตามชื่อ

• ตัวแยกวิเคราะห์การให้เหตุผล (vllm/reasoning/xing4_0_reasoning_parser.py) "สำหรับตัวแปรที่รองรับการให้เหตุผล" และตัวแยกวิเคราะห์เครื่องมือ (vllm/tool_parsers/xing4_0_tool_parser.py) สำหรับการเรียกใช้เครื่องมืออัตโนมัติ

• การลงทะเบียนใน vllm/config/speculative.py, vllm/transformers_utils/model_arch_config_convertor.py และ vllm/transformers_utils/config.py — โดยข้อความ commit ระบุว่าเปิดใช้งาน MTP head ที่เข้ากันได้กับ Deep​Seek-V3 สำหรับการถอดรหัสแบบ speculative

• ไฟล์เอกสารสองไฟล์ — ส่วนที่เป็นของใหม่จริง ๆ และการย้อนกลับสิ่งที่ทำในเดือนสิงหาคมโดยตรง คอมมิตต้นฉบับมีรายการเอกสารและเทสต์ที่ถูกย้อนกลับในอีกหนึ่งชั่วโมงต่อมาเพราะยังเร็วเกินไป; PR เดือนกันยายนนำเอกสารกลับเข้ามา และมีป้ายกำกับว่า documentation, new-model และ tool-calling

รายการเอกสาร vLLM เป็นจุดที่ผู้อ่านได้เรียนรู้สิ่งที่เป็นรูปธรรมเป็นครั้งแรก ใน docs/models/supported_models.md แถวใหม่ระบุว่า `Xing4_0ForCausalLM` | Xing4_0 | TBA — คอลัมน์เช็กพอยต์ระบุตามตัวอักษรว่า TBA ซึ่งก็คือ "ยังไม่" แบบเดียวกันในฟอนต์ที่ต่างออกไป และใน docs/features/tool_calling.md ภายใต้หัวข้อ "Xing4_0 Models (xing4_0)" PR นี้ได้บันทึกรูปแบบการเรียกเครื่องมือของโมเดล: การเรียกจะถูกส่งออกภายในบล็อก <tool_call>...</tool_call> โดยเป็นได้ทั้ง JSON ({"name": ..., "arguments": {...}}) หรือรูปแบบที่อิงแท็กซึ่งใช้ <param_key>...</param_key> และ <param_value>...</param_value> นั่นคือระดับความเฉพาะเจาะจงที่ PR ก่อนหน้าไปไม่ถึง — รายละเอียดการนำไปใช้ของรูปแบบแชตของโมเดล ที่เขียนไว้ในเอกสารสาธารณะของเฟรมเวิร์กชั้นนำ สำหรับเช็กพอยต์ที่ไม่มีใครดาวน์โหลดได้

PR ของ SGLang น่าสนใจกว่า เพราะมันมาพร้อมอิมพลีเมนเทชันและคอนฟิก ไม่ใช่แค่รายการในรีจิสทรีบวกเอกสาร แถวในเอกสารของมันเป็นครั้งแรกที่เฟรมเวิร์กหนึ่งนำชื่อของผู้ผลิตมาใส่ไว้ในเอกสารของตัวเอง ในdocs/docs/supported-models/generative_models.mdx แถวใหม่ระบุ Xing4_0 โดยคอลัมน์เช็กพอยต์เขียนว่า `Xing4_0` (เร็ว ๆ นี้) และคำอธิบายว่า "โมเดล MoE ของ China Telecom ที่ใช้ MLA attention และ mHC (Manifold-constrained Hyper-Connection) residual streams; รองรับการถอดรหัสเชิงคาดการณ์แบบ MTP แบบเนทีฟ การเรียกใช้เครื่องมือ และการให้เหตุผล" แถวของ vLLM ระบุว่า TBA และไม่เอ่ยชื่อผู้ผลิตเลย ส่วนของ SGLang ระบุชื่อ China Telecom และบอกว่าเร็ว ๆ นี้ ทั้งสองอย่างไม่ใช่วันเปิดตัว และแถวในเอกสารของเฟรมเวิร์กก็ไม่ใช่ผลิตภัณฑ์

คำอธิบาย PR เพิ่มตัวเลขที่ทุกเวอร์ชันก่อนหน้าของเรื่องนี้ขาดไป "PR นี้เพิ่มการรองรับ Xing4.0-29B-A4B (MoE ขนาด 29B พารามิเตอร์ ที่มีพารามิเตอร์ถูกเปิดใช้งานประมาณ 4B)" นอกจากนี้ยังให้คำสั่งสำหรับเปิดใช้งาน — --model-path XingChen-AGI/Xing4.0-29B-A4B --trust-remote-code --tp-size 2 --context-length 262144 --reasoning-parser xing4_0 --tool-call-parser xing4_0 --speculative-algorithm EAGLE — และระบุว่าคอนฟิกูเรชันนี้ได้รับการตรวจสอบที่ tensor parallelism 2, คอนเท็กซ์ 262,144 โทเคน และการถอดรหัสแบบ speculative ด้วย EAGLE MTP โดยมีทรานสคริปต์ของคำตอบเชิงเหตุผลและการเรียกเครื่องมือ get_weather ถูกแปะไว้ในคำอธิบายเป็นหลักฐาน น้ำหนักโมเดลที่รองรับการตรวจสอบนั้นเป็นของผู้เขียนเอง: เส้นทางที่เก็บข้อมูลที่ PR ระบุไว้นั้นไม่สามารถอ่านได้แบบสาธารณะ และองค์กร Hugging Face ที่มันชี้ไปนั้นไม่ได้ระบุโมเดลสาธารณะใด ๆ เลย ให้ถือว่าขนาด ความยาวคอนเท็กซ์ และทรานสคริปต์เหล่านั้นเป็นข้ออ้างที่รายงานใน PR ซึ่งผูกกับเช็กพอยต์ส่วนตัว ไม่ใช่การวัดที่ใคร ๆ ก็ทำซ้ำได้ ทั้งหมดนี้เป็นไปตาม pull request และยังไม่ถูกทำซ้ำ

การที่ตัวแยกวิเคราะห์สำหรับการให้เหตุผลและสำหรับเครื่องมือปรากฏอยู่ภายใต้ทั้งสองชื่อนั้นมีความสำคัญด้วยเหตุผลเดียวกับที่มันเคยสำคัญในเดือนสิงหาคม ตัวแยกวิเคราะห์สำหรับการให้เหตุผลมีไว้เพื่อตัดเครื่องหมายการคิดออกจากเอาต์พุตของโมเดล — ซึ่งก็คือสายความคิดภายในที่โมเดลปล่อยออกมาก่อนคำตอบสุดท้าย ตัวแยกวิเคราะห์ที่สร้างขึ้นโดยเฉพาะสำหรับโมเดลนี้หมายความว่าคาดว่าตระกูลนี้จะมีตัวแปรที่สามารถให้เหตุผลได้ เช่นเดียวกับที่ TeleChat3 เปิดตัวฉบับ Thinking ตัวแยกวิเคราะห์สำหรับเครื่องมือ บวกกับรูปแบบการเรียกที่ได้รับการบันทึกไว้แล้วในตอนนี้ หมายความว่าคาดว่าจะมีการเรียกฟังก์ชันแบบเนทีฟด้วยเช่นกัน ทั้งสองอย่างไม่ใช่การรับประกันเกี่ยวกับผลิตภัณฑ์สุดท้าย แต่ทั้งคู่เป็นเบาะแสที่ชัดเจนที่สุดที่ PRs มีเกี่ยวกับสิ่งที่ China Telecom กำลังมุ่งเป้า

สิ่งที่เรารู้จนถึงตอนนี้ โดยสรุป

สกอร์บอร์ดด้านล่างคืออันที่จัดทำขึ้นสำหรับบทความนี้เมื่อวันที่ 27 สิงหาคม 2026 จาก vLLM PR ในสภาพที่เป็นอยู่ในตอนนั้น มันถูกเก็บไว้ที่นี่โดยเจตนาในฐานะสแนปช็อตที่ระบุวันที่ แทนที่จะวาดใหม่ เพราะทุกบรรทัดของมันยังคงเป็นจริงแม้เวลาผ่านไปสามสัปดาห์ — ยังไม่เปิดตัว, น้ำหนักโมเดลยังไม่เปิดเผย, แบ็กโบน DeepSeek, mHC residual, รวม parser ทั้งสองตัวไว้ด้วย สิ่งที่เปลี่ยนไปไม่ใช่ค่าบนการ์ด แต่เป็นทุกสิ่งรอบ ๆ มัน: vLLM PR ที่มันอ้างถึงถูกปิดเมื่อวันที่ 7 กันยายน งานนี้ปรากฏขึ้นอีกครั้งภายใต้ชื่อใหม่เมื่อวันที่ 16 กันยายน SGLang ทำตามการเปลี่ยนชื่อในอีกไม่กี่ชั่วโมงต่อมา และจำนวนพารามิเตอร์ที่ระบุไว้เป็นครั้งแรกก็มาพร้อมกับมัน ไม่มีอะไรบนการ์ดที่ผิด มันแค่มีอายุสามสัปดาห์ และเรื่องราวได้เคลื่อนผ่านมันไปแล้ว ตัวเลข FlagGems ในแถวสุดท้ายของมันถูกยกไปยัง vLLM PR ใหม่โดยไม่เปลี่ยนแปลง ยังคงเป็นตัวเลขที่รายงานใน PR และยังไม่ถูกทำซ้ำให้ได้ผลเดิม

สถาปัตยกรรมที่ PRs เปิดเผย

การเปลี่ยนชื่อไฟล์ไม่ใช่การเปลี่ยนชื่อสถาปัตยกรรม และข้อความสรุปใน PR ของ vLLM ฉบับเดือนกันยายนก็คือข้อความฉบับเดือนสิงหาคมที่เอา Xing4_0 มาแทน XingChen4 — ทีละอนุประโยค มีสองประโยคที่ส่งสัญญาณ:

• "Xing4_0 นำแกนหลัก (backbone) ของ Deep​Seek-V2/V3 มาใช้ซ้ำ (attention แบบ MLA, บล็อก MoE, ตัวจัดทำดัชนี DSA ที่เลือกใช้ได้)"

มันแทนที่การเชื่อมต่อ residual แบบมาตรฐานด้วย Manifold-constrained Hyper-Connections (mHC): โดย residual stream จะถูกขยายออกเป็นสตรีมขนานจำนวน num_residual_streams สตรีม ซึ่งถูกผสมกันด้วยเมทริกซ์ doubly-stochastic ที่ขึ้นอยู่กับอินพุต ซึ่งสร้างขึ้นผ่านการฉายแบบ Sinkhorn-Knopp

แต่ละอนุประโยคสอดคล้องกับสิ่งที่เป็นรูปธรรม MLA คือ Multi-head Latent Attention ซึ่งเป็นรูปแบบการบีบอัดความสนใจที่ DeepSeek เปิดตัวใน V2 ที่ทำให้ KV cache คงขนาดเล็กไว้ได้ MoE คือการกำหนดเส้นทางแบบ mixture-of-experts ซึ่งช่วยให้คงจำนวนพารามิเตอร์จำนวนมากไว้ได้โดยมีขนาดการใช้งานจริงที่เล็ก ส่วน DSA indexer แบบเลือกได้คือกลไก DeepSeek Sparse Attention จากสาย V3.2 — โมดูลให้คะแนนแบบน้ำหนักเบาที่เลือกโทเค็น top-k ที่จะเพ่งความสนใจ ซึ่งลดต้นทุนความสนใจจากกำลังสองเหลือประมาณเชิงเส้นตามความยาวบริบท และประโยค mHC คือพาดหัวข่าว: โมเดลนี้ใช้สถาปัตยกรรม residual ที่ DeepSeek เองเพิ่งเปิดตัวในรุ่นนี้

PR ของ SGLang เป็นฉบับแรกที่เผยแพร่รูปร่างของสิ่งนี้ แทนที่จะอธิบายมัน ไฟล์คอนฟิกของมัน python/sglang/srt/configs/xing4_0.py ประกาศ hidden layers 40 ชั้น, hidden size 3,584 และ vocabulary 131,072 โทเคน; MLA ที่มี KV LoRA rank 512 และ query LoRA rank 768 ครอบคลุม 32 heads; และ sparse MoE ที่มี routed experts 64 ตัว บวก shared expert หนึ่งตัว, top-4 routing, sigmoid scoring, routed scaling factor 2.0 และ noaux_tc expert selection ฟิลด์ mHC ก็ชัดเจนเช่นกัน: hc_mult 4, การทำ Sinkhorn-Knopp 20 รอบ, การ clamp h_res ที่บวกหรือลบ 30, และ rope_theta 10,000 พร้อม maximum position embedding 262,144 ค่าเหล่านี้เป็นค่าดีฟอลต์ในอินทิเกรชันที่ยังไม่เปิดตัว ตามที่ระบุใน pull request — ไฟล์คอนฟิกเป็นคำแถลงเจตนา ไม่ใช่ model card และตัวเลข 29B-A4B ในคำอธิบาย PR ไม่ได้ถูกอนุมานมาจากค่าเหล่านี้ที่ใดในที่สาธารณะ

มีฟิลด์หนึ่งที่มีค่ามากกว่าฟิลด์อื่น ๆ เพราะมันเป็นจุดแรกที่โมเดลนี้หยุดเป็นสำเนาของ DeepSeek อย่างเห็นได้ชัด คอนฟิกของ SGLang กำหนดค่า hc_contract_for_draft ซึ่งรวมสตรีม mHC กลับลงมาให้เหลือขนาด hidden size ของโมเดลเองก่อน final norm และป้อนนั้น ซึ่งเป็นเทนเซอร์ที่ถูกย่อส่วนไปยังหัวดราฟต์ Eagle DeepSeek V4 ป้อนเทนเซอร์ขนาด n-times-hidden_size ที่ถูกทำให้แบนด้วย mHC แทน คอมเมนต์ในคอนฟิกระบุไว้อย่างชัดเจนเช่นนั้น และมันเป็นรายละเอียดแบบที่ปรากฏขึ้นก็ต่อเมื่อการนำไปใช้งานถูกปรับให้เข้ากับ checkpoint จริงแล้วเท่านั้น — ซึ่งเป็นสิ่งที่เช็กลิสต์ของ PR SGLang ก่อนหน้านี้อ้างว่ามี โดยไม่เผยแพร่มัน

คณิตศาสตร์ของ mHC คือจุดที่สแต็กทั้งสองแตกต่างกันในด้านการนำไปใช้งาน และเห็นตรงกันในสมมติฐาน PR ของ vLLM ระบุว่า "ตรงกับ shared ops ใน vllm.model_executor.layers.mhc ดังนั้นจึงไม่มีการนำ private kernels เข้ามาใช้" — โมดูลนั้นมีอยู่เพราะ vLLM รองรับ mHC สำหรับ DeepSeek V4 อยู่แล้ว ดังนั้นต้นทุนส่วนเพิ่มในการเพิ่มโมเดลนี้จึงน้อย SGLang ไปถึงจุดเดียวกันด้วยเส้นทางที่ต่างออกไป: โมดูล mHC ของมันใช้เคอร์เนล TileLang แบบ fused ที่ลงทะเบียนเป็น torch custom ops และ PR นี้ขยายเคอร์เนล mhc_pre split-K ที่มีอยู่ให้รับ hc_hidden_size 14,336 ควบคู่ไปกับสองขนาดที่มันจัดการอยู่แล้ว นอกจากนี้ยังปิดเส้นทาง tf32_hc_prenorm_gemm ของ DeepGEMM สำหรับสถาปัตยกรรมนี้ เนื่องจากเส้นทางนั้นเป็น C extension ดิบที่ torch.compile ไม่สามารถ trace ได้; mHC จึงตกไปใช้เคอร์เนล TileLang แทน ข้อได้เปรียบในทางปฏิบัติก็เหมือนกันในทั้งสองเฟรมเวิร์ก: หากคุณให้บริการ DeepSeek V4 บน vLLM หรือ SGLang อยู่แล้วในวันนี้ กลไกที่จะให้บริการ MoE ตัวถัดไปของ China Telecom ก็ถูกติดตั้งไว้แล้ว

mHC เคล็ดลับ DeepSeek ที่เป็นศูนย์กลางของทุกสิ่ง

Manifold-constrained Hyper-Connections นั้นคุ้มค่าที่จะแกะให้เข้าใจ เพราะมันเป็นสิ่งเดียวที่น่าสนใจที่สุดเกี่ยวกับโมเดลนี้ — และมันไม่ใช่สิ่งประดิษฐ์ของ China Telecom มันเป็นของ Deep​Seek

เรื่องราวเริ่มต้นด้วย Hyper-Connections ซึ่งเสนอโดยทีม Ki​mi ในปี 2024 Transformer มาตรฐานเก็บสตรีมเรซิดวลหนึ่งสายต่อเลเยอร์: อินพุตจะถูกบวกเข้ากับเอาต์พุตของเลเยอร์ ทำให้เกรเดียนต์มีเส้นทางที่สะอาดและให้เครือข่ายเรียนรู้การแก้ไขแบบเรซิดวลได้ Hyper-Connections แทนที่สายเดี่ยวนั้นด้วยหลายสายที่ขนานกัน ซึ่งถูกผสมด้วยเมทริกซ์ที่เรียนรู้ได้ในแต่ละเลเยอร์ ทำให้โมเดลมีเส้นทางที่หลากหลายยิ่งขึ้นมากสำหรับข้อมูลในการเดินทาง จุดที่ต้องระวังคือความเสถียร: เมทริกซ์การผสมที่ไม่มีข้อจำกัดจะทำลายสมบัติการแมปเอกลักษณ์ที่ทำให้การเชื่อมต่อแบบเรซิดวลฝึกได้ และที่ระดับพารามิเตอร์ล้านล้าน ค่าความสูญเสียในการฝึกจะไม่เสถียร

ผลงานของ DeepSeek ซึ่งตีพิมพ์เป็นบทความ mHC ในเดือนธันวาคม 2025 และต่อมาถูกนำไปใช้ใน DeepSeek V4 คือการจำกัดเมทริกซ์การผสมให้เป็นดับเบิลสโตแคสติก — ค่าไม่เป็นลบ โดยแต่ละแถวและแต่ละคอลัมน์รวมกันได้หนึ่ง — ซึ่งบังคับผ่านการฉาย Sinkhorn-Knopp ระหว่างการฝึก เมทริกซ์ดับเบิลสโตแคสติกมีรัศมีสเปกตรัมเท่ากับหนึ่งพอดี ดังนั้นสัญญาณจึงไม่สามารถถูกขยายหรือลดทอนแบบเอกซ์โพเนนเชียลได้ขณะส่งผ่านหลายร้อยชั้น ขอบเขตนั้นคือสิ่งที่ทำให้การฝึกมีความเสถียรในระดับสเกลใหญ่ และการฉายนี้มีต้นทุนต่ำพอที่ DeepSeek รายงานว่ามีโอเวอร์เฮดการฝึกเพียงประมาณ 6.7% เมื่อใช้ residual stream สี่สาย DeepSeek V4 ซึ่งเปิดตัวเมื่อวันที่ 24 เมษายน 2026 เป็นการใช้งานระดับเรือธงของสิ่งนี้ โดยมีรายงานว่าปรับปรุงประมาณ 15% ในงานให้เหตุผลทางคณิตศาสตร์ และยังมีบริบทขนาด 1M โทเคนเพิ่มเติมด้วย

พูดง่าย ๆ สิ่งที่ PR เหล่านี้กำลังบอกก็คือ โมเดลถัดไปของ China Telecom นำแกนหลักที่พิสูจน์แล้วของ DeepSeek และกลไกเรซิดิวล่าสุดของ DeepSeek มาใช้ แทนที่จะคิดค้นอย่างใดอย่างหนึ่งขึ้นมาใหม่ตั้งแต่ต้น นั่นเป็นการเลือกที่สมจริง และมันแฝงการยืนยันที่ละเอียดอ่อน — แล็บใหญ่แห่งที่สองรองจาก DeepSeek เองที่นำ mHC ไปใช้ เชื่อว่าเทคนิคนี้พร้อมใช้งานจริงแล้ว

PR ต่าง ๆ ยังไม่เสร็จสมบูรณ์ด้วย mHC และรายการที่ค้างอยู่ก็พูดตามตรงเกี่ยวกับเรื่องนี้ ตลอด PR ของ vLLM ผู้เขียนระบุว่า checkpoint biases (bias_pre, bias_post, bias_res) และ h_res clamp ถูก merge ไว้หรือถูกละไว้ในตอนนี้ และการยืนยันจาก reviewer เกี่ยวกับความเท่าเทียมกันของสูตรคือ "คำถามหลักด้านความถูกต้อง" นอกจากนี้ยังมี custom transpose op ที่ทำให้ tensor เป็น C-contiguous สำหรับ kernel ของ TileLang — ถูกเปลี่ยนชื่อไปพร้อมกับอย่างอื่นทั้งหมด จาก _xingchen4_transpose_contiguous เป็น _xing4_0_transpose_contiguous — และมีข้อจำกัดที่เข้มงวด: pipeline parallelism ไม่รองรับในโหมด mHC เมื่อ num_residual_streams มากกว่าหนึ่ง ขณะที่ tensor parallelism รองรับ เรื่องพวกนี้ไม่น่าแปลกใจสำหรับ draft แต่ก็เป็นขอบที่ยังไม่เสร็จแบบเดียวกับที่มันเป็นเมื่อเดือนสิงหาคม ซึ่งตัวมันเองก็ให้ข้อมูล: หกสัปดาห์ของการเปลี่ยนชื่อไม่ได้ทำให้คำถามด้านความถูกต้องขยับไปไหน และการรัน CI ที่เป็นสีแดงสามครั้งบน PR ของ SGLang ใหม่ล่าสุดก็เป็นเรื่องเดียวกันในสีที่ต่างออกไป สิ่งที่ config ของ SGLang ทำให้ชัดเจนคือจำนวน stream เมื่อ hc_mult ถูกตั้งเป็น 4 และ hidden size เท่ากับ 3,584 ค่า 14,336 ใน kernel patch ก็คือสี่ stream พอดี — และคอมเมนต์ใน kernel ก็พูดไว้ตรง ๆ เช่นนั้น การตีความนั้นเป็นการอนุมานจากตัวเลขเปล่า ๆ ตอนที่ชิ้นนี้เผยแพร่ครั้งแรก ตอนนี้มันถูกเขียนไว้ในไฟล์ config แล้ว

มุมการเร่งความเร็ว: FlagGems อีกครั้ง

อีกหนึ่งเส้นเชื่อมโยงที่ผูกโมเดลนี้เข้ากับความสัมพันธ์ที่มีอยู่เดิมของ China Telecom กับ Beijing Academy of Artificial Intelligence และเป็นเส้นเชื่อมเดียวที่ยังคงอยู่ครบถ้วนหลังการเปลี่ยนชื่อทุกครั้ง PR ของ vLLM เปิดใช้งานการเร่งความเร็วแบบเลือกได้ผ่าน FlagOS/FlagGems ภายใต้แฟล็กสภาพแวดล้อม USE_FLAGOS ซึ่งปิดไว้เป็นค่าเริ่มต้น โดยสลับไปใช้เคอร์เนล hot-path สำหรับ MoE, attention, softmax และ top-k ผลตอบแทนที่กล่าวอ้าง จากเบนช์มาร์ก H100 ของผู้เขียน PR บนเวิร์กโหลดพรอมป์ยาวที่มีคอนเคอร์เรนซีสูง (อินพุตมากกว่า 10K โทเคน, คอนเคอร์เรนซี 10): time-to-first-token ลดลงสูงสุด 19.87% และ time-per-output-token ลดลงสูงสุด 26.32% โดยเวิร์กโหลดอื่น ๆ ไม่เปลี่ยนแปลง ตัวเลขเหล่านั้นเป็นตัวเลขที่ PR รายงานและยังไม่ได้ทำซ้ำ และมาพร้อมกับแฟล็กที่ปิดเป็นค่าเริ่มต้น

สิ่งที่น่าบันทึกคือการเปลี่ยนชื่อแทบไม่ได้แตะอะไรเลย PR ของ vLLM ในเดือนกันยายนมีตัวเลขชุดเดิม มีหมายเหตุขอบเขตแคบ ๆ แบบเดียวกันว่าแฟล็กนั้นอยู่เฉพาะภายในไฟล์โมเดล และมีคำแนะนำเดียวกันให้ติดตั้ง flagtree และ flag-gems ตัวเลขไม่ได้เปลี่ยนเพราะโค้ดไม่ได้เปลี่ยน มีเพียงป้ายชื่อเท่านั้นที่เปลี่ยน pull request ของ SGLang ไม่มีเธรด FlagGems เลย — พวกมันเลือกเส้นทาง TileLang และ DeepGEMM แทน — ซึ่งทำให้เรื่องนี้เป็นข้อถกเถียงว่าใครเป็นเจ้าของการปรับให้เหมาะสมของเลเยอร์ให้บริการ ไม่ใช่เกี่ยวกับตัวโมเดล

นี่คือเรื่องราวความต่อเนื่อง TeleChat3-36B-Thinking ณ เดือนเมษายน 2026 เป็นโมเดลขนาดใหญ่ตัวแรกที่ถูกพอร์ตอย่างอิสระไปยัง FlagOS ซึ่งเป็นสแต็กซอฟต์แวร์ AI โอเพนซอร์สของ BAAI ไม่ว่าโมเดลนี้จะเผยแพร่ในรูปแบบใด การสานต่อแนวทางนั้นด้วยเคอร์เนล FlagGems ภายในอินทิเกรชัน vLLM ของตัวเอง บ่งชี้ว่ากลยุทธ์สแต็กภายในประเทศของแล็บขยายเข้าสู่เลเยอร์การให้บริการ ไม่ใช่แค่การฝึกเทรน

คำถามเรื่องการตั้งชื่อ และตระกูลที่มันมาจาก

จนถึงวันที่ 16 กันยายน คำถามเรื่องการตั้งชื่อเป็นเพียงเรื่องแทรกเท่านั้น ตอนนี้เกือบจะได้ข้อสรุปแล้ว และหลักฐานทั้งหมดยังคงอยู่ในชื่อแบรนช์กับสตริงที่ตกค้างมากกว่าจะอยู่ในรูปแถลงการณ์ — แต่ทั้งสองเฟรมเวิร์กได้มาบรรจบกันที่คำตอบเดียวกันจากทิศทางเดียวกัน

• ข้อความคอมมิต เรียงตามลำดับ: "Add TeleChat4 model support," จากนั้น "chore: revert premature docs and test entry for telechat4," จากนั้น — สามสัปดาห์ต่อมา และหนึ่งนาทีก่อนที่ PR จะถูกปิด — "rename xingchen4." คอมมิตซึ่งมีจุดประสงค์ทั้งหมดเพียงเพื่อการเปลี่ยนชื่อ

• สาขาของฟอร์กมีดังนี้ PR สองรายการแรกของ vLLM คือ #51237 และ #54051 ถูกแยกมาจาก zyp2014:supported_telechat4 ส่วนรายการที่สามคือ #57135 เป็น zyp2014:support_xing4_0 สาขานี้ถูกเปลี่ยนชื่อในคราวเดียวกับการเปลี่ยนชื่อโมเดล — และฝั่ง SGLang ตอนนี้ได้เดินตามเส้นทางเดียวกันในสามขั้นตอน จาก support_telechat4 ผ่าน support_xingchen4 ไปยัง support_xing4_0

• เนื้อความของ #51237 ซึ่งระบุว่าการเร่งความเร็วด้วย FlagGems นั้น "สำหรับ TeleChat4" ขณะที่ย่อหน้าเดียวกันนั้นกลับเรียกโมเดลนี้ว่า XingChen4 ชื่อทั้งสองนี้ขัดแย้งกันอยู่แล้วในบทสรุปของผู้เขียนเองเมื่อวันที่ 6 สิงหาคม

• การเปลี่ยนชื่อแบบไฟล์ต่อไฟล์ทั้งสองฝั่ง ใน vLLM นั้นเป็น xingchen4.py ไปเป็น xing4_0.py และ XingChen4ForCausalLM ไปเป็น Xing4_0ForCausalLM; ใน SGLang เป็น xingchen4.py ไปเป็น xing4_0.py และ XingChen4Config ไปเป็น Xing4_0Config บนแบรนช์ที่เปลี่ยนชื่อไปพร้อมกัน ไม่มี PR ใดทิ้งชื่อเดิมไว้ที่ไหนเลยใน diff ของตน

ดังนั้นจึงมีชื่อสามชื่อที่ถูกใช้อยู่ในสองเฟรมเวิร์ก และรูปแบบนี้สอดคล้องกับโมเดลเดียวที่กำลังถูกเปลี่ยนชื่อเมื่อมันเข้าใกล้ชื่อสาธารณะของมัน "Xing4_0" อ่านได้เป็นธรรมชาติว่า Xingchen 4.0 — ครอบครัวของโมเดลใช้ชื่อแบรนด์ 星辰 (Xingchen) ในภาษาจีน — แต่นั่นก็ยังเป็นการอนุมานจากสตริง ไม่ใช่สิ่งที่ PR ฉบับใดระบุตรง ๆ ในทางกลับกัน ก็อาจเป็นได้เช่นกันว่า TeleChat4 และ XingChen4 เป็นพี่น้องในรุ่นเดียวกัน มากกว่าจะเป็นโมเดลเดียวที่ใช้สองชื่อ แม้ว่าการ fork ที่ใช้ร่วมกัน ย่อหน้าสถาปัตยกรรมที่ใช้ร่วมกัน ตัวเลข FlagGems ที่ใช้ร่วมกัน รายการเปิดที่ใช้ร่วมกัน และตอนนี้การเปลี่ยนชื่อที่ใช้ร่วมกัน จะทำให้ข้อโต้แย้งนั้นยากขึ้น ยังไม่มีใครยืนยันความสัมพันธ์นี้ และ China Telecom ก็ไม่ได้ให้ความเห็น สิ่งที่เปลี่ยนไปคือ การเปลี่ยนชื่อไม่ใช่ทางเลือกของผู้มีส่วนร่วมเพียงคนเดียวอีกต่อไป: โครงการ serving อิสระสองโครงการที่ดูแลโดยคนละคน ต่างก็เปลี่ยนชื่อการผสานรวมของตนเป็นชื่อที่สามชื่อเดียวกัน ภายในหนึ่งวันของกันและกัน

ตัวตระกูลนี้เองก็คุ้มค่าที่จะจับตามอง เพราะมันอธิบายถึงแนวทางปฏิบัติจริง การเปิดตัวสู่สาธารณะจนถึงตอนนี้ได้รับการใช้ชื่อแบรนด์ว่า TeleChat:

TeleChat-7B และ TeleChat-12B เผยแพร่เป็นโอเพนซอร์สในเดือนมกราคม 2024 พร้อมคลังข้อมูลขนาด 1 ล้านล้านโทเคน

• TeleChat2-115B (กันยายน 2024) ถูกนำเสนอว่าเป็นโมเดลเปิดขนาดล้านล้านพารามิเตอร์ที่พัฒนาในประเทศทั้งหมดเป็นรุ่นแรก พร้อมด้วยรุ่นพี่น้องขนาด 35B, 7B และ 3B

• TeleChat2-39B-A12B (มีนาคม 2025) โมเดล MoE ตัวแรกของตระกูล

• TeleChat3-105B-A4.7-Thinking (ธันวาคม 2025) โมเดล MoE แบบละเอียด (fine-grained MoE) ที่มีพารามิเตอร์รวม 105B และพารามิเตอร์ที่ใช้งานจริง 4.7B ฝึกด้วยโทเคน 15 ล้านล้านโทเคน พร้อมกับ TeleChat3-36B แบบ dense และ TeleChat3-Coder-36B-Thinking ที่ตามมาในภายหลัง

หากตัวเลข 29B-A4B ยังคงเป็นจริง โมเดลนี้จะอยู่ต่ำกว่า TeleChat3-105B-A4.7-Thinking ทั้งในด้านพารามิเตอร์ทั้งหมดและพารามิเตอร์ที่ใช้งาน — เป็นรุ่นน้องที่เล็กกว่าและถูกกว่า มากกว่าจะเป็นเรือธงที่มาแทนที่ นั่นเป็นการตีความ ไม่ใช่ข้อเท็จจริง; ไม่มีอะไรในข่าวประชาสัมพันธ์ทั้งสองฉบับที่ระบุว่าโมเดลนี้มุ่งเป้าไปที่ระดับใด แบรนด์ Xingchen คือจุดที่บริษัททุ่มความพยายามด้าน AI: Xingchen AGI Lab ก่อตั้งขึ้นอย่างเป็นทางการในกรุงปักกิ่งเมื่อเดือนมีนาคม 2026 โดยต่อยอดจากตระกูลโมเดลเดียวกัน และ China Telecom อธิบายระบบ "三全" (ครอบคลุมทุกโมดัล ครบทุกขนาด และพึ่งพาในประเทศทั้งหมด) ของตนว่าครอบคลุมโมเดลเชิงความหมาย เสียงพูด ภาพ และมัลติโมดัลตั้งแต่ขนาด 1B ไปจนถึง 1T+ พารามิเตอร์ การเปลี่ยนชื่อจาก TeleChat เป็น Xingchen คือสิ่งที่ห้องปฏิบัติการทำเมื่อต้องการให้ตระกูลโมเดลมีแบรนด์ของห้องปฏิบัติการแทนที่จะเป็นแบรนด์ของสายผลิตภัณฑ์

สิ่งที่เรายังไม่รู้

สำหรับโมเดลที่ยังใหม่ขนาดนี้ รายการที่ตรงไปตรงมายังคงยาวกว่ารายการที่รู้แล้ว แม้ว่าสัปดาห์นี้จะแคบลงในสองจุด:

• ยังไม่มีวันเปิดตัว ห้าในหกการผสานรวมเป็นฉบับร่างที่เปิดไว้เพื่อการตรวจสอบโค้ดตั้งแต่เนิ่น ๆ เนื่องจากเวตยังไม่เปิดเผยต่อสาธารณะ ส่วนอันที่หก SGLang #39793 เปิดให้ตรวจสอบแทนที่จะเป็นฉบับร่าง — แต่ยังไม่ถูกผสาน การรัน CI ทั้งสามครั้งของมันล้มเหลวทั้งหมด และต้องมีผู้ตรวจสอบอนุมัติ จึงยังไม่มีกำหนดการที่ประกาศออกมา

• จำนวนพารามิเตอร์ แต่เป็นเพียงจำนวนที่อ้างเท่านั้น ทุกเวอร์ชันก่อนหน้าของงานชิ้นนี้ระบุการกำหนดค่า MoE ว่าไม่เปิดเผย PR ของ SGLang เปลี่ยนสิ่งนั้นในเชิงเอกสาร: Xing4.0-29B-A4B, รวม 29B, แอ็กทีฟประมาณ 4B ตัวเลขนี้มาจาก pull request ไม่ได้แนบมากับเช็กพอยต์สาธารณะใด ไม่มีไฟล์ config ใดยืนยัน และไม่มีใครนอกโครงการทำซ้ำได้ ให้ถือเป็นเจตนาที่ระบุไว้ ไม่ใช่ข้อกำหนดคุณลักษณะ

• ไม่มีตัวเลข benchmark ไม่ว่าจะเป็นตัวเลขที่ผู้ขายรายงานเองหรือจากแหล่งอื่น และไม่มีคะแนนจากผู้ประเมินอิสระ ทรานสคริปต์การตรวจสอบใน SGLang PR แสดงให้เห็นเพียงว่าโมเดลตอบพรอมป์การให้เหตุผลและส่งการเรียกเครื่องมือที่มีรูปแบบถูกต้อง แต่ไม่ได้แสดงอะไรเลยว่าโมเดลทำได้ดีเพียงใดในทั้งสองเรื่อง

• ไม่มีข้อมูลราคา และไม่มีใบอนุญาตที่ยืนยันได้ ทุกเวอร์ชันก่อนหน้าของ TeleChat เผยแพร่ภายใต้ Apache-2.0 ซึ่งเป็นเรื่องน่าพอใจ แต่ยังไม่มีการระบุใบอนุญาตสำหรับเวอร์ชันนี้

• ไม่มีเวตสาธารณะ — ยืนยันแล้ว ไม่ใช่สันนิษฐาน ณ วันที่ 16 กันยายน 2026 พาธ Hugging Face ที่ PR ของ SGLang ระบุไม่สามารถอ่านได้แบบสาธารณะ และองค์กรที่พาธนั้นชี้ไปก็ไม่ได้แสดงรายการโมเดลสาธารณะใด ๆ รายการสาธารณะล่าสุดในตระกูลนี้คือ TeleChat3-Coder-36B-Thinking จากเดือนมกราคม ตารางโมเดลที่รองรับของ vLLM ระบุ TBA ในคอลัมน์ checkpoint ส่วนของ SGLang ระบุว่า “เร็ว ๆ นี้” และ PR ของ SGLang ทั้งสองมี public CI ที่ล้มเหลว

• ไม่มีคำแถลงอย่างเป็นทางการจาก China Telecom — ไม่มีประกาศ ไม่มีเวตต์ ไม่มีการยืนยันชื่อหรือขนาด โปรดสังเกตความไม่สมมาตรอย่างรอบคอบ: แถวในเอกสาร SGLang ระบุว่าโมเดลนี้มาจาก China Telecom แต่ที่นั่นเป็นคำอธิบายของผู้ร่วมพัฒนาในพูลรีเควสต์ ไม่ใช่คำแถลงของบริษัท และคำอธิบาย PR ล่าสุดได้ตัดชื่อผู้ขายออกไปทั้งหมด การผสานรวมหกรายที่สร้างสำหรับโมเดลนี้เป็นหลักฐานที่แข็งแกร่งที่สุดจนถึงตอนนี้ว่ามันมีจริง แต่การผสานรวมอาจถูกปิด และชื่อรหัสอาจเปลี่ยนแปลง สองรายถูกปิดไปแล้ว ไม่มีอะไรได้รับการยืนยันจนกว่าแล็บจะกล่าวเช่นนั้น

การตีความที่ถูกต้องสำหรับทั้งหมดนี้ไม่ใช่ความสงสัยกังขาเกี่ยวกับโมเดล แต่เป็นภาพที่แม่นยำของสัญญาณเริ่มต้น สิ่งที่มีอยู่ในวันนี้คือชิ้นงานวิศวกรรมจริง — หกชิ้น ข้ามสองเฟรมเวิร์ก — พร้อมสถาปัตยกรรมจริง และเป็นครั้งแรกที่มีการระบุรูปร่างที่แน่ชัดไว้ด้วย สิ่งที่ยังไม่มีในตอนนี้คือสิ่งที่คุณจะดาวน์โหลด เรียกใช้งาน หรือวัดประสิทธิภาพได้

สิ่งที่ใกล้เคียงที่สุดที่คุณสามารถใช้งานได้ในวันนี้

โมเดลนี้ไม่สามารถให้บริการได้จากที่ใดเลย — ไม่ว่าจะผ่าน API หรือใช้งานในเครื่อง เพราะเวตของโมเดลไม่ได้เปิดเผยต่อสาธารณะ โมเดลที่ใกล้เคียงที่สุดที่ผู้อ่านสามารถเรียกใช้ได้จริงในวันนี้และมีดีเอ็นเอทางสถาปัตยกรรมร่วมกันคือ DeepSeek V4 Flash ซึ่งใช้รูปแบบเรซิดิวแบบ mHC เดียวกันบนพื้นฐานของ MLA และ MoE และเป็นต้นแบบอ้างอิงที่โมดูล mHC ซึ่งใช้ร่วมกันในทั้งสองเฟรมเวิร์กถูกสร้างขึ้นมาเพื่อรองรับ หน้าโมเดลของ OrcaRouter สำหรับ deepseek/deepseek-v4-flashระบุบริบท 1M โทเคน เอาต์พุตสูงสุด 384K และราคาตามรายการที่ 0.15 ดอลลาร์ต่อโทเคนอินพุตหนึ่งล้าน และ 0.29 ดอลลาร์ต่อโทเคนเอาต์พุตหนึ่งล้าน — เป็นตัวเลขชุดเดียวกับที่ DeepSeek เองเผยแพร่ ส่งผ่านมาด้วยส่วนบวกเพิ่ม 0% ดังนั้นการเปลี่ยนแปลงราคาของผู้ให้บริการจะมีผลที่นี่ภายในวันเดียวกัน คีย์ API เดียวครอบคลุมแค็ตตาล็อกทั้งหมดซึ่งทำให้การเปรียบเทียบกับส่วนที่เหลือของกลุ่มโมเดลการให้เหตุผลเป็นเพียงกฎการกำหนดเส้นทาง มากกว่าการผสานรวมใหม่

นี่ก็เป็นคำตอบเชิงปฏิบัติสำหรับคำถามที่ว่า "ฉันจะลองโมเดลนี้ตอนที่มันเปิดตัวได้อย่างไร" เช่นกัน เช็กพอยต์ใหม่เอี่ยมที่ยังไม่ผ่านการพิสูจน์คือจุดที่การสลับไปใช้ตัวสำรองอัตโนมัติพิสูจน์คุณค่าของตัวเองได้อย่างชัดเจน: ส่งทราฟฟิกเพียงเศษเสี้ยวไปที่มัน เก็บโมเดลที่ผ่านการพิสูจน์แล้วไว้เป็นตัวสำรอง และปล่อยให้ชั้นการจัดเส้นทางเป็นตัวตัดสินใจ แทนที่จะเดิมพันเส้นทางโปรดักชันกับพฤติกรรมในวันแรก MoE ขนาด 29B ที่มีพารามิเตอร์ทำงานจริงราว 4B หากนั่นคือสิ่งที่มาถึง ก็เป็นสิ่งที่ราคาถูกที่จะจัดเส้นทางไปเทียบกับโมเดลระดับแนวหน้า เพราะมันเปิดใช้งานเพียงเล็กน้อยต่อโทเคน หากชื่อเปลี่ยนอีกครั้งระหว่างนี้จนถึงวันเปิดตัว — และหกสัปดาห์ที่ผ่านมาบ่งชี้ว่าอาจเป็นเช่นนั้น — สิ่งที่คุณต้องเขียนใหม่คือกฎการจัดเส้นทาง ไม่ใช่การผสานรวม

คำถามที่พบบ่อย

ทำไม PR ของ vLLM จึงถูกปิด?

เราเห็นการปิดได้ แต่ไม่เห็นเหตุผล #54051 ถูกปิดโดยผู้เขียนเองเมื่อวันที่ 7 กันยายน 2026 โดยไม่ถูก merge และงานดังกล่าวกลับมาปรากฏอีกครั้งในอีกเก้าวันต่อมาเป็น #57135 ภายใต้ชื่อใหม่ PR ของ vLLM ก่อนหน้านี้คือ #51237 ถูกปิดและยื่นใหม่ในวันเดียวกันภายใต้ชื่อเรื่องเดิม ดังนั้นการปิดและยื่นใหม่จึงเป็นรูปแบบการทำงานของผู้เขียนรายนี้ มากกว่าที่จะเป็นสัญญาณของปัญหา — แต่เนื้อความของ PR ไม่ได้ระบุเหตุผล และเราจะไม่แต่งเหตุผลขึ้นมาเอง

Xing4_0 จะเปิดตัวเมื่อไหร่

ยังไม่มีวันที่ ห้าในหกของการผสานรวมเป็นฉบับร่างที่เปิดไว้เพื่อการตรวจโค้ดในช่วงแรก และแผนของผู้เขียนเองคือจะเพิ่มรายการทดสอบ อัปเดตเอกสาร และทำเครื่องหมาย PR ต่างๆ ว่าพร้อมก็ต่อเมื่อมีการปล่อยเวตแล้วเท่านั้น เช็กลิสต์ฉบับเก่ากว่าของ SGLang เป็นข้อความที่ชัดเจนที่สุดว่าสถานะปัจจุบันเป็นอย่างไร: "โมเดลโหลดและสร้างผลลัพธ์ (ภายในเครื่อง โดยใช้เวตภายใน)" ถูกติ๊กแล้ว และ CI สาธารณะ "ถูกบล็อกจนกว่าจะปล่อยเวต" PR ของ SGLang ที่ใหม่กว่าถูกยื่นว่า พร้อมสำหรับการรีวิว แทนที่จะเป็นฉบับร่าง ซึ่งเป็นการเปลี่ยนท่าทีมากกว่าการเปลี่ยนสถานะ — มันยังไม่ถูก merge, CI ของมันขึ้นสีแดง และแถวเอกสารที่เขียนว่า "เร็ว ๆ นี้" ไม่ใช่การเปิดตัว

Xing4_0 เป็นโมเดลเดียวกันกับ XingChen4 หรือไม่

เกือบจะแน่นอนว่าใช่ และ PR ก็ทำให้ตรวจสอบได้ง่าย: มีสายการ fork เดียวกัน ย่อหน้าอธิบายสถาปัตยกรรมเดียวกัน ตัวเลข benchmark ของ FlagGems ชุดเดียวกัน รายการที่ยังค้างอยู่ชุดเดียวกัน และการเปลี่ยนชื่อไฟล์ทีละไฟล์ในทั้งสองเฟรมเวิร์ก — จาก xingchen4.py เป็น xing4_0.py รวมถึงคลาส config บนแบรนช์ที่ถูกเปลี่ยนชื่อให้ตรงกัน มันคืองานเดียวกันที่สวมชื่อใหม่ และ ณ วันที่ 16 กันยายน ทั้ง vLLM และ SGLang ก็ได้นำชื่อนั้นไปใช้แล้ว สิ่งที่ไม่มี PR ใดระบุก็คือ checkpoint ที่เผยแพร่จะใช้ชื่อใด

นี่คือโมเดล DeepSeek ใช่ไหม

ไม่ มันเป็นโมเดลของ China Telecom จาก Xingchen AGI Lab ความเชื่อมโยงกับ DeepSeek เป็นเรื่องทางสถาปัตยกรรม: มันนำแกนหลัก DeepSeek-V2/V3 และสคีมา residual mHC ที่ DeepSeek เสนอและปล่อยใช้ใน V4 มาใช้ซ้ำ การนำสถาปัตยกรรมของผู้อื่นมาใช้ ไม่ได้หมายความว่าทั้งสองโครงการเกี่ยวข้องกัน

สิ่งที่ควรดูต่อไป

PR ยังคงให้เช็กลิสต์ที่ชัดเจน และคู่เมื่อวันที่ 16 กันยายนก็เพิ่มสองรายการเข้าไป ประการแรก เวต ผู้เขียนทุกคนกล่าวว่างานของตนรอ Hugging Face อยู่ ดังนั้นการปรากฏของที่เก็บสาธารณะจึงเป็นเหตุการณ์ที่เป็นตัวชี้ขาด และตอนนี้ PR ของ SGLang ให้เส้นทางที่ต้องจับตาดูอย่างเจาะจง นั่นคือ XingChen-AGI/Xing4.0-29B-A4B ซึ่งปัจจุบันยัง resolve ไม่ได้สำหรับใคร ประการที่สอง ตัว PR เอง ของ vLLM ต้องมีการยืนยันสูตรไบแอส mHC เพิ่มรายการทดสอบใน registry และทำให้ CI เป็นสีเขียว ของ SGLang #39793 ต้องแก้การรันที่แดงสามครั้ง และให้ผู้ตรวจทานที่ร้องขอสิบคนอนุมัติ ขณะที่ #37228 ที่เก่ากว่ายังต้องมีรายการทดสอบ แบตช์มาร์กความเร็ว MTP และ CI ที่ไม่ถูกบล็อก ประการที่สาม และเป็นเรื่องใหม่ในสัปดาห์นี้ ว่า SGLang จะปิด #37228 เพื่อไปใช้ #39793 หรือไม่ ในแบบที่ vLLM ปิด PR ก่อนหน้าแล้วยื่นใหม่เสมอ การมีอินทิเกรชันที่ยังเปิดอยู่สองรายการสำหรับโมเดลที่ยังไม่เปิดตัวหนึ่งตัว เป็นสภาวะที่ไม่มีใครดูแลได้นาน และตัวไหนที่รอด จะบอกอะไรบางอย่างว่าเรื่องนี้ใกล้แค่ไหนจริง ๆ ประการที่สี่ ตัวเลข ว่าเช็กพอยต์ที่ปล่อยออกมาจะตรงกับขนาด 29B-A4B, MoE แบบ 64 ผู้เชี่ยวชาญ และคอนเท็กซ์ 262,144 โทเคน ที่คอนฟิกและคำอธิบาย PR ระบุไว้หรือไม่ ประการที่ห้า ว่า PR ของ vLLM ตัวที่สามจะอยู่รอดนานกว่าสองตัวก่อนหน้าหรือไม่ ซึ่งอยู่ได้ 21 และ 11 วันตามลำดับก่อนถูกปิดโดยไม่ได้ merge และจับตาว่าตัวแยกวิเคราะห์ reasoning กำลังอธิบายตัวแปร Thinking แยกต่างหาก ในแบบที่ TeleChat3 ปล่อยออกมาหนึ่งตัวหรือไม่

จนกว่าหนึ่งในสิ่งเหล่านั้นจะเกิดขึ้น ให้ถือว่าโมเดลนี้คือสิ่งที่มันเป็น: แผนที่ระบุสเปกไว้อย่างครบถ้วนจากแล็บที่จริงจัง ซึ่งถูกจับได้คาหนังคาเขาขณะกำลังเตรียมโครงสร้างพื้นฐานสำหรับการให้บริการ — ตอนนี้อยู่ในสแต็กสำหรับให้บริการโอเพนซอร์สหลักทั้งสองแห่ง ภายใต้ชื่อที่ทั้งสองนำมาใช้ และขนาดที่เฉพาะ pull request ของมันเองเท่านั้นที่ระบุไว้ แค่สถาปัตยกรรมอย่างเดียวก็ทำให้มันควรค่าแก่การจับตามอง: มันเป็นการนำ mHC มาใช้ครั้งใหญ่ครั้งที่สองถัดจาก DeepSeek เอง จากแล็บที่รุ่นก่อนหน้าก็เป็น MoE แบบละเอียดที่ฝึกบนชิปในประเทศอยู่แล้ว เมื่อน้ำหนักโมเดลเปิดให้ดาวน์โหลด จะไม่มีข้อสงสัยเลยว่ามันรันใน vLLM หรือ SGLang ทั้งสองสแต็กเขียนโค้ดไว้ถึงสามรอบ ภายใต้ชื่อที่แตกต่างกันสามชื่อ