Xing4_0 يصل إلى SGLang: طلب سحب سادس، وأول حجم معلن، لـ MoE القادم الخاص بـ China Telecom

بفارق ساعتين، في 16 سبتمبر 2026، توقّف مكدسا تقديم الخدمة المهيمنان مفتوحا المصدر عن الاختلاف حول الاسم. قدّم vLLM طلب سحب بعنوان «[نموذج] إضافة دعم Xing4_0» في الصباح؛ ثم تبعه sgl-project/sglang بعنوان «ميزة: إضافة دعم نموذج Xing4_0» عند الساعة 10:38 UTC، وبعد ستة أسابيع من تداول ثلاثة أسماء، كلا الإطارين يقولان الآن Xing4_0. يحمل طلب السحب الخاص بـ SGLang شيئًا لم يحمله أي طلب سابق: حجمًا. يصف النموذج بأنه Xing4.0-29B-A4B، «نموذج MoE بـ29 مليار معامل، مع نحو 4 مليارات من المعاملات النشطة»، ويقدّم أمر تشغيل يسمّي مسار نقطة تفتيش، وسياقًا من 262,144 رمزًا، وفك التشفير التخميني EAGLE. هذا هو نموذج MoE غير المطروح الخاص بـ China Telecom، النموذج نفسه الذي تدور حوله طلبات سحب XingChen4 منذ أغسطس، ولا يزال غير مطروح: الأوزان ليست عامة، ومسار نقطة التفتيش الذي يسمّيه طلب السحب لا يمكن الوصول إليه لأي شخص خارج المشروع، ولم يؤكد أي مورّد الاسم أو الرقم، ولا شيء في هذا المقال مُتحقَّق منه بشكل مستقل. الحقائق المأخوذة من طلبات السحب موسومة بذلك؛ وما تبقى فهو تاريخ واستنتاج. أقرب نموذج يمكنك استدعاؤه فعليًا اليوم هو DeepSeek V4 Flash.

هذا مقال "ما نعرفه حتى الآن"، يُحدَّث باستمرار بدل أن يُبدأ من جديد. يغطي مسار طلبات السحب (PR) على مدى ستة أسابيع، وكيف حُلّت مسألة التسمية، وما الذي تضيفه فعلاً طلبا السحب في 16 سبتمبر، والبنية التي تكشفها ملفات الإعداد الآن بتفصيل حقيقي، وما ينبغي مراقبته لاحقاً. النسخة المختصرة بجملة واحدة: إن MoE التالي الخاص بـ China Telecom حقيقي بما يكفي ليكون قد جمع ستة تكاملات تقديم، وصفّ جدول في vLLM معلّم بـ TBA، ومدخل توثيق في SGLang معلّم بعبارة "قريباً" وعدد معاملات معلن — ومع ذلك ليس حقيقياً بما يكفي ليعمل في أي مكان يمكنك الوصول إليه.

الإشارة: ست تكاملات، ثلاثة أسماء، ستة أسابيع

يبدأ الأثر في وقت أبكر من النسخة التي أُبلغ عنها أول مرة من هذا المقال، ولا يزال سجل الالتزامات الخاص به أكثر عنصر كاشف في التسريب. كان أول PR لـ vLLM هو #51237، وقد فُتح في 6 أغسطس 2026 تحت العنوان "[WIP][Model] إضافة دعم نموذج XingChen4 القادم." التزاماته الثلاثة تروي القصة بنفسها. الأول بعنوان "إضافة دعم نموذج TeleChat4." والثاني، بعد أكثر من ساعة بقليل، هو "chore: التراجع عن الوثائق ومدخل الاختبار السابقين لأوانهما لـ telechat4" — سُحبت الوثائق ومدخل اختبار السجل مرة أخرى باعتبارهما سابقين لأوانهما. والثالث، في 27 أغسطس، هو "إعادة تسمية xingchen4." وبعد دقيقة واحدة أُغلق PR دون دمجه، وبعد إحدى عشرة دقيقة من ذلك #54051 فُتح بالعنوان نفسه، والفرع المتفرع نفسه (supported_telechat4) وبالتزام واحد مضغوط. كانت قد أُضيفت أثناء ذلك تسمية needs-rebase، لذا يُقرأ هذا كإغلاق وإعادة فتح بعد التنظيف وليس تغيّرًا في الرأي. وقد قُدّم كل ذلك من حساب GitHub zyp2014، مع كون كل التزام مؤلفًا وموقّعًا من zhangyp26 <zhangyp26@chinatelecom.com.cn>.

طلب السحب الثاني هو الذي بُني هذا المقال في الأصل حوله، ولم يعد مفتوحًا. أُغلق #54051 بواسطة مؤلفه نفسه في 7 سبتمبر 2026، دون أن يُدمج. ومع ذلك، يستحق وصفه أن يُقتبس، لأن هذا الوصف هو الجملة التي نجت من كل إعادة تسمية وكل إعادة فتح:

أوزان النموذج ليست متاحة بعد للعموم على Hugging Face Hub. هذا الـ PR مفتوح لمراجعة الكود المبكرة. بمجرد إصدار الأوزان، سأضيف إدخال اختبار في tests/models/registry.py، وسأحدّث docs/models/supported_models.md، وسأضع علامة على الـ PR بأنه جاهز للمراجعة.

تلك الجملة هي شكل القصة بأكملها: الشيفرة تسبق الأوزان. لقطة الشاشة أدناه هي صفحة #54051 كما كانت عليه في 27 أغسطس 2026، يوم فُتحت — لقطة مؤرخة، أُبقيت لأن طلب السحب الذي تعرضه أُغلق منذ ذلك الحين. اقرأها كسجل للإشارة في تلك اللحظة، لا لحالتها الآن.

ثم، في 16 سبتمبر، تكرر النمط — مرتين في يوم واحد. #57135، "[Model] إضافة دعم Xing4_0"، فُتح في ذلك الصباح من الحساب نفسه، zyp2014، بإيداع واحد أصبح مؤلفه الآن مهندسًا آخر من China Telecom — xiongji <xiongj9@chinatelecom.cn>. تغيّر أحد عشر ملفًا، ونحو 1,300 إضافة، واسم جديد في كل مكان، والتحذير نفسه في الموضع نفسه: "أوزان النموذج ليست عامة بعد على Hugging Face Hub."

بعد ساعتين وعشرين دقيقة، لم يعد مكدس الخدمة الآخر متأخرًا بإعادة تسمية واحدة. sgl-project/sglang #39793، "ميزة: إضافة دعم نموذج Xing4_0"، فُتح من فرع يُسمى support_xing4_0، والالتزام الوحيد الخاص به يحمل نفس عنوان xiongji الذي تحمله إعادة تسمية vLLM. أربعة عشر ملفًا وحوالي 1,400 إضافة، منها ما يزيد قليلًا على الألف في ملف نموذج واحد. إنه التكامل السادس المقدَّم لهذا النموذج خلال ستة أسابيع، والأول الذي قُدِّم على أنه ليس مسودة: يُدرجه GitHub كمفتوح وجاهز للمراجعة، مع طلب عشرة مراجعين — وجميع تشغيلات CI الثلاث الخاصة به حمراء بالفعل.

كان جانب SGLang قبل اليوم يسير على النحو الذي سار عليه جانب vLLM. #33982، "feat(model): إضافة دعم نموذج TeleChat4"، فُتح في 7 أغسطس 2026 من قبل المساهم PaddyXj وأُغلق دون دمج في 31 أغسطس — في اليوم نفسه #37228، "feat: إضافة دعم نموذج XingChen4"، فُتح بدلًا منه. لا يزال ذلك الطلب مفتوحًا كمسودة باسم PaddyXj، على فرع يُسمى support_xingchen4، يضم ثلاث إيداعات وآخر تعديل عليه في 8 سبتمبر. قائمة مراجعته هي أكثر ما يثير الاهتمام في كلا الإطارين: تحميل النموذج والتوليد "محليًا، على أوزان داخلية" مُعلَّم عليه، واستدعاء الأدوات مُعلَّم عليه، وتحليل الاستدلال مُعلَّم عليه — أما CI العام فليس كذلك، لأنه "محجوب بانتظار إصدار الأوزان". لدى أحدهم نقطة حفظ. لم ينشرها أحد. وعلى خلاف vLLM، حيث كانت كل إعادة إيداع تغلق سابقتها أولًا، أصبح لدى SGLang الآن طلبا سحب نشطان مفتوحان للنموذج نفسه، تحت اسمين مختلفين.

ما تجتمع إليه ست تكاملات في ستة أسابيع ليس نسخة أقوى من الإشارة نفسها؛ بل إشارة مختلفة. ست تكاملات ستكون متسقة مع فريق يكرّر التحسين. أما ست تكاملات تحت ثلاثة أسماء — TeleChat4 وXingChen4 وXing4_0 — فتعني فريقًا يكرّر التحسين على الاسم الذي سيُطرح به النموذج، علنًا، بينما تبقى الأوزان خاصة. ذلك استدلال غير مُتحقَّق منه، وهو أكثر ما يكشفه مسار العلاقات العامة الآن من حيث العواقب.

ما الذي يضيفه طلبا سحب سبتمبر فعليًا

طلب السحب الخاص بـ 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، مع تمرير أمامي، ومهايئ mHC، وتنفيذ load_weights() بالتوازي على مستوى الموترات. وتشير رسالة الالتزام إلى دعم كلٍّ من متغيّري DSA وغير DSA، مع إعادة استخدام عمليات 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 متوافق مع Deep​Seek-V3 من أجل الفك التخميني (speculative decoding).

• ملفّا توثيق — الجزء الجديد فعليًا، وانعكاس مباشر لما حدث في أغسطس. كان الالتزام الأصلي يتضمن مدخلًا للتوثيق واختبارًا جرى التراجع عنه بعد ساعة باعتباره سابقًا لأوانه؛ أما طلب السحب (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 (xing4_0)"، يوثّق طلب السحب تنسيق استدعاء الأدوات الخاص بالنموذج: تُصدر الاستدعاءات داخل كتل <tool_call>...</tool_call>، إما بصيغة JSON ({"name": ..., "arguments": {...}}) أو بصيغة قائمة على الوسوم تستخدم <param_key>...</param_key> و<param_value>...</param_value>. وهذا مستوى من التحديد لم تصل إليه طلبات السحب السابقة — تفصيل تنفيذي من تنسيق محادثة النموذج، مكتوب في التوثيق العام لإطار عمل رئيسي، من أجل نقطة تحقق لا يستطيع أحد تنزيلها.

طلب السحب SGLang أكثر إثارة للاهتمام، لأنه يشمل تنفيذاً وإعداداً بدلاً من إدخال في السجل بالإضافة إلى الوثائق. سطر الوثائق الخاص به هو المرة الأولى التي تضع فيها إحدى الأطر اسم المورّد في وثائقها الخاصة. في docs/docs/supported-models/generative_models.mdx، السطر الجديد يسرد Xing4_0، مع عمود نقطة التحقق يقرأ `Xing4_0` (قريباً) ووصف: "نموذج MoE الخاص بـ China Telecom مع انتباه MLA وتدفقات متبقية mHC (الاتصال الفائق المقيّد بالمشعب)؛ يدعم فك التشفير التخميني MTP الأصلي، واستدعاء الأدوات، والاستدلال." سطر vLLM قال TBA ولم يذكر أي مورّد؛ سطر SGLang يذكر China Telecom ويقول قريباً. لا هذا ولا ذاك تاريخ إصدار، وسطر في وثائق إطار ليس منتجاً.

يضيف وصف طلب السحب الرقم الذي افتقرت إليه كل نسخة سابقة من هذه القصة. "يضيف طلب السحب هذا دعمًا لـ 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 — ويذكر أن الإعداد تم التحقق منه عند توازي الموترات 2، وسياق من 262,144 رمزًا، وفك ترميز EAGLE MTP التخميني، مع نصوص استجابة استدلالية واستدعاء أداة get_weather ملصقة في الوصف كدليل. الأوزان التي تقف خلف ذلك التحقق هي أوزان المؤلف نفسه: مسار المستودع الذي يسميه طلب السحب ليس متاحًا للقراءة العامة، ومنظمة Hugging Face التي يشير إليها لا تُدرج أي نماذج عامة على الإطلاق. تعامل مع الحجم وطول السياق والنصوص بوصفها ادعاءات مُبلَّغة في طلب السحب ومرتبطة بنقطة تفتيش خاصة، وليست قياسات يمكن لأي شخص تكرارها. كل ذلك وفقًا لطلب السحب وغير مُعاد إنتاجه.

إن ظهور محلّلات الاستدلال والأدوات تحت كلا الاسمين مهم للسبب نفسه الذي جعله مهمًا في أغسطس. محلّل الاستدلال موجود لتجريد علامات التفكير من مخرجات النموذج — سلسلة التفكير الداخلية التي يصدرها النموذج قبل إجابته النهائية. وجود محلّل مصمم خصيصًا لهذا النموذج يعني أن من المتوقع أن تضم العائلة متغيرات قادرة على الاستدلال، بالطريقة نفسها التي أطلقت بها TeleChat3 إصدارات Thinking. أما محلّل الأدوات، بالإضافة إلى صيغة الاستدعاء الموثّقة الآن، فيعني أن استدعاء الدوال الأصلي متوقع أيضًا. لا يعد أي منهما ضمانًا بشأن المنتج النهائي؛ بل كلاهما أقوى التلميحات التي تحملها طلبات السحب (PRs) حول ما تستهدفه China Telecom.

ما نعرفه حتى الآن في لمحة

لوحة النتائج أدناه هي التي جُمِّعت لهذا المقال في 27 أغسطس 2026، من طلب السحب (PR) الخاص بـ vLLM كما كان عليه آنذاك. وهي محفوظة هنا عمدًا كلقطة مؤرخة بدلًا من إعادة رسمها، لأن كل سطر فيها لا يزال صحيحًا بعد ثلاثة أسابيع — غير مُصدَر، والأوزان ليست عامة، والعمود الفقري DeepSeek، وmHC residual، وكلا المُحلِّلين مُضمَّنان. ما تغيّر ليس قيمة على البطاقة بل كل شيء حولها: طلب السحب الخاص بـ vLLM الذي تشير إليه أُغلق في 7 سبتمبر، وظهر العمل من جديد باسم جديد في 16 سبتمبر، ولحق SGLang بإعادة التسمية بعد ساعات، ووصل معها أول عدد معلن للمعاملات. لا يوجد أي خطأ على البطاقة. إنها ببساطة عمرها ثلاثة أسابيع، وقد تجاوزتها القصة. أرقام FlagGems في صفها الأخير انتقلت إلى طلب السحب الجديد الخاص بـ vLLM دون تغيير، ولا يزال الإبلاغ عنها في PR قائمًا، ولم يُعَد إنتاجها بعد.

البنية التي تسرّبها الـPRs

إعادة تسمية ملف لا تعيد تسمية معمارية، ونص الملخص في PR vLLM لشهر سبتمبر هو نص أغسطس مع إحلال Xing4_0 محل XingChen4 — بندًا ببند. جملتان تحملان الإشارة:

• "يعيد Xing4_0 استخدام العمود الفقري لـ DeepSeek-V2/V3 (انتباه MLA، كتلة MoE، مفهرس DSA الاختياري)."

يستبدل الاتصال المتبقي القياسي بالاتصالات الفائقة المقيدة بالمانيفولد (mHC): يتم توسيع التدفق المتبقي إلى num_residual_streams من التدفقات المتوازية الممزوجة بمصفوفات عشوائية مزدوجة تعتمد على المدخلات، منتجة عبر إسقاط سينكهورن-كنوب.

كل بند يقابل شيئًا ملموسًا. MLA هو Multi-head Latent Attention، مخطط الانتباه المضغوط الذي قدّمته DeepSeek في V2، والذي يُبقي KV cache صغيرًا؛ MoE هو توجيه mixture-of-experts routing، الذي يحافظ على عدد كبير من المعلمات مع بصمة نشطة صغيرة. ومُفهرِس DSA الاختياري هو آلية DeepSeek Sparse Attention من سلسلة V3.2 — وحدة تسجيل خفيفة تختار أفضل k من الرموز للانتباه إليها، مما يقلّص كلفة الانتباه من تربيعية إلى خطية تقريبًا في طول السياق. وجملة mHC هي العنوان الأبرز: هذا النموذج يتبنى معمارية residual التي لم تُدخلها DeepSeek نفسها إلا في هذا الجيل.

إن طلب السحب SGLang PR هو الأول الذي ينشر شكل الشيء بدلًا من وصفه. يصرّح ملف التهيئة الخاص به، python/sglang/srt/configs/xing4_0.py، بـ40 طبقة مخفية، وحجم مخفي يبلغ 3,584، ومفردات من 131,072 رمزًا؛ وMLA برتبة KV LoRA قدرها 512 ورتبة query LoRA قدرها 768 عبر 32 رأسًا؛ وMoE متناثر يضم 64 خبيرًا موجّهًا بالإضافة إلى خبير مشترك واحد، وتوجيه top-4، وتقييم sigmoid، ومعامل تحجيم موجّه قدره 2.0، واختيار خبراء noaux_tc. كما أن حقول mHC صريحة أيضًا: hc_mult 4، وعشرون تكرارًا لـ Sinkhorn-Knopp، وقصّ h_res عند زائد أو ناقص 30، وrope_theta بقيمة 10,000 مع أقصى تضمين موضعي 262,144. وهذه هي القيم الافتراضية في تكامل لم يُشحَن بعد، وفقًا لطلب السحب — فملف التهيئة بيان نية، وليس بطاقة نموذج، ورقم 29B-A4B في وصف PR لا يُستمد منها في أي مكان عام.

حقل واحد أكثر قيمة من الباقي، لأنه أول موضع يتوقف فيه هذا النموذج بوضوح عن كونه نسخة من DeepSeek. يضبط إعداد SGLang الحقل hc_contract_for_draft، وهو ما يدمج تدفقات mHC مرة أخرى نزولًا إلى الحجم المخفي للنموذج نفسه قبل التطبيع النهائي، ويغذّي ذلك الموتر المقلّص إلى رأس المسودة Eagle. أما DeepSeek V4 فيغذّي بدلًا من ذلك الموتر المسطّح بواسطة mHC n-times-hidden_size. ويقول تعليق الإعداد ذلك صراحةً، وهو من نوع التفاصيل التي لا تظهر إلا بعد أن تُصاغ عملية تنفيذ مقابل نقطة تفتيش حقيقية — وهو ما تدّعي قائمة تحقق PR الخاصة بـ SGLang السابقة امتلاكه، دون أن تنشره.

رياضيات mHC هي حيث يختلف المكدسان في التنفيذ ويتفقان في الافتراض. تشير ملاحظات PR الخاصة بـ vLLM إلى أنه "يطابق العمليات المشتركة في vllm.model_executor.layers.mhc، لذلك لا تُقدَّم نوى خاصة" — توجد هذه الوحدة لأن vLLM يدعم mHC بالفعل لـ DeepSeek V4، لذا فإن التكلفة الإضافية لإضافة هذا النموذج صغيرة. تصل SGLang إلى النقطة نفسها عبر طريق مختلف: تستخدم وحدة mHC لديها نوى TileLang المدمجة المسجّلة كعمليات مخصصة في torch، ويوسّع PR نواة mhc_pre split-K الحالية لتقبل hc_hidden_size 14,336 إلى جانب الحجمين الذين كانت تتعامل معهما بالفعل. كما يعطّل مسار tf32_hc_prenorm_gemm في DeepGEMM لهذه البنية، لأن ذلك المسار امتداد C خام لا يمكن لـ torch.compile تتبعه؛ وبدلاً من ذلك ينتقل mHC إلى نواة TileLang. الميزة العملية واحدة في كلا الإطارين: إذا كنت تشغّل DeepSeek V4 على vLLM أو SGLang اليوم، فإن الآلية التي ستشغّل نموذج MoE التالي لـ China Telecom مثبّتة بالفعل.

mHC، حيلة DeepSeek التي تقع في قلب كل شيء

يستحق Manifold-constrained Hyper-Connections أن يُفكَّك، لأنه الشيء الأكثر إثارة للاهتمام على الإطلاق في هذا النموذج — وهو ليس من ابتكار China Telecom. إنه من ابتكار DeepSeek.

تبدأ القصة مع Hyper-Connections، الذي اقترحه فريق Ki​mi في 2024. يحتفظ Transformer القياسي بمسار متبقٍّ واحد لكل طبقة: يُضاف المدخل إلى مخرجات الطبقة، مما يمنح التدرجات مسارًا نظيفًا ويتيح للشبكة تعلّم تصحيح متبقٍّ. يستبدل Hyper-Connections ذلك المسار الواحد بعدة مسارات متوازية تمزجها مصفوفات مُتعلَّمة عند كل طبقة، مما يمنح النموذج مسارًا أغنى بكثير لانتقال المعلومات. لكن المشكلة تكمن في الاستقرار: فالمصفوفات المازجة غير المقيَّدة تكسر خاصية تعيين الهوية التي تجعل الوصلات المتبقية قابلة للتدريب، وعند مقياس تريليون معامل يصبح فقدان التدريب غير مستقر.

إسهام DeepSeek، المنشور كورقة mHC في ديسمبر 2025 ثم المستخدَم في DeepSeek V4، تمثل في تقييد مصفوفات المزج لتكون عشوائية مزدوجة — غير سالبة، ومجموع كل صف وكل عمود فيها يساوي واحدًا — مفروضًا عبر إسقاط Sinkhorn-Knopp أثناء التدريب. المصفوفة العشوائية المزدوجة نصف قطرها الطيفي يساوي واحدًا بالضبط، لذا لا يمكن تضخيم الإشارات أو إضعافها أسيًا أثناء مرورها عبر مئات الطبقات. هذا الحد هو ما يحافظ على استقرار التدريب عند التوسع، والإسقاط رخيص بما يكفي لدرجة أن DeepSeek أبلغت عن عبء تدريب إضافي لا يتجاوز نحو 6.7% مع أربعة تدفقات متبقية. ويُعد DeepSeek V4، الذي صدر في 24 أبريل 2026، الاستخدام الرائد له، مع تحسن مُبلَّغ عنه بنحو 15% في مهام الاستدلال الرياضي، بالإضافة إلى سياق بطول مليون رمز.

إذن، ما تقوله هذه البيانات الصحفية، بعبارات بسيطة، هو: نموذج China Telecom التالي يأخذ العمود الفقري المُثبت لدى Deep​Seek وآلية residual الأحدث لدى Deep​Seek، بدلًا من اختراع أيٍّ منهما من الصفر. هذا خيار عملي، ويحمل تأكيدًا ضمنيًا — فثاني مختبر كبير بعد Deep​Seek نفسه يتبنى mHC يعتقد أن هذه الحيلة جاهزة للإنتاج.

لم تنتهِ طلبات السحب (PRs) مع mHC، والعناصر المفتوحة صريحة بشأن ذلك. عبر طلبات السحب الخاصة بـ vLLM، يلاحظ المؤلف أن انحيازات نقطة التحقق (bias_pre, bias_post, bias_res) ومشبك h_res (h_res clamp) إما مدمجة أو محذوفة حاليًا، وأن تأكيد المراجع لتكافؤ الصيغة هو "السؤال الرئيسي للصحة". هناك أيضًا عملية نقل (transpose op) مخصصة تحافظ على بقاء الموتر (tensor) متصلًا بنمط C (C-contiguous) من أجل نواة TileLang — أُعيدت تسميتها جنبًا إلى جنب مع كل شيء آخر، من _xingchen4_transpose_contiguous إلى _xing4_0_transpose_contiguous — وثمة قيد صارم: التوازي عبر الأنابيب (pipeline parallelism) غير مدعوم في وضع mHC عندما يكون num_residual_streams أكبر من واحد، بينما التوازي الموتر (tensor parallelism) مدعوم. لا شيء من هذا مفاجئ بالنسبة لمسودة، لكنها نفس الحافة غير المكتملة التي كانت عليها في أغسطس، وهذا بحد ذاته ذو دلالة: ستة أسابيع من إعادة التسمية لم تحرّك سؤال الصحة، وثلاث تشغيلات CI حمراء على أحدث PR لـ SGLang هي القصة نفسها بلون مختلف. ما يستقر عليه إعداد SGLang هو عدد المسارات (stream count). مع ضبط hc_mult على 4 وحجم مخفي (hidden size) قدره 3,584، فإن الرقم 14,336 في رقعة النواة (kernel patch) هو بالضبط أربعة مسارات — وتعليق النواة يقول ذلك صراحةً. كان ذلك التفسير استنتاجًا من رقم مجرّد عندما نُشر هذا المقال لأول مرة؛ وهو الآن مكتوب في ملف إعداد.

زاوية التسارع: FlagGems، مرة أخرى

يربط خيطٌ ثانٍ هذا النموذج بالعلاقة القائمة بين China Telecom وأكاديمية بكين للذكاء الاصطناعي، وهو الخيط الوحيد الذي نجا سليمًا من كل عملية إعادة تسمية. ويتيح طلب السحب (PR) الخاص بـ vLLM تسريعًا اختياريًا لـ FlagOS/FlagGems خلف علامة بيئة USE_FLAGOS، معطّلة افتراضيًا، عبر إحلال نوى المسار الساخن الخاصة بـ MoE والانتباه وsoftmax وtop-k. والعائد المزعوم، استنادًا إلى قياس H100 الذي أجراه مؤلف PR على حمل عمل طويل المطالبات عالي التزامن (أكثر من 10 آلاف رمز إدخال، تزامن 10): خفض زمن الوصول إلى أول رمز بنسبة تصل إلى 19.87% وخفض الزمن لكل رمز إخراج بنسبة تصل إلى 26.32%، مع بقاء أحمال العمل الأخرى دون تغيير. هذه الأرقام مُبلَّغ عنها في PR ولم يُعَد إنتاجها، وتأتي مع كون العلامة معطّلة افتراضيًا.

الجدير بالتسجيل هو مدى ضآلة ما طالته إعادة التسمية. يحمل طلب السحب الخاص بـ vLLM في سبتمبر الأرقام نفسها، والملاحظة نفسها ضيقة النطاق التي تقول إن العلامة لا توجد إلا داخل ملف النموذج، والتعليمة نفسها لتثبيت flagtree وflag-gems. لم تتغير الأرقام لأن الشيفرة لم تتغير؛ لم يتغير سوى الوسم. لا تحمل طلبات السحب الخاصة بـ SGLang أي خيط نقاش يخص FlagGems على الإطلاق — بل تسلك بدلًا من ذلك مسار TileLang وDeepGEMM — ما يجعل هذه جدلًا حول من يملك تحسين طبقة الخدمة، لا حول النموذج.

هذه قصة استمرارية. كان TeleChat3-36B-Thinking، اعتبارًا من أبريل 2026، أول نموذج كبير يُنقل بشكل مستقل إلى FlagOS، حزمة برمجيات الذكاء الاصطناعي مفتوحة المصدر من BAAI. ومهما تكن الصيغة التي يُطلق بها هذا النموذج، فإن مواصلة هذا الخط — مع نوى FlagGems داخل تكامله الخاص مع vLLM — تقول إن استراتيجية المكدس المحلي لدى المختبر تمتد إلى طبقة الخدمة، وليس فقط إلى التدريب.

سؤال التسمية، والعائلة التي يأتي منها

حتى 16 سبتمبر كان سؤال التسمية ملاحظة جانبية. وهو الآن شبه محسوم، ولا تزال الأدلة كلها في أسماء الفروع والسلاسل النصية المتبقية وليس في تصريحات — لكن الإطارين توصّلا إلى الإجابة نفسها من الاتجاه نفسه.

• رسائل الالتزام، بالترتيب: "إضافة دعم نموذج TeleChat4"، ثم "أعمال روتينية: التراجع عن الوثائق وإدخال الاختبار السابقين لأوانهما لـ telechat4"، ثم — بعد ثلاثة أسابيع ودقيقة واحدة قبل إغلاق طلب السحب — "إعادة تسمية xingchen4". التزام لم يكن غرضه سوى إعادة التسمية.

• الـ fork يتفرّع. أول طلبَي سحب (PRs) لـ 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) بالصينية — لكن هذا يظل استنتاجًا من السلسلة النصية، وليس شيئًا يصرّح به أي بيان صحفي مباشرة. وقد يكون الأمر بالمثل أن TeleChat4 وXingChen4 شقيقان في الجيل نفسه بدلًا من نموذج واحد باسمين، مع أن التفرع المشترك، وفقرة المعمارية المشتركة، وأرقام FlagGems المشتركة، والبنود المفتوحة المشتركة، والآن إعادة التسمية المشتركة، تجعل هذا الطرح أصعب في الدفاع عنه. لم يؤكد أحد العلاقة، ولم تعلّق China Telecom. ما تغير هو أن إعادة التسمية لم تعد خيار مساهم واحد: فقد أعاد مشروعان مستقلان لتقديم الخدمة، يديرهما شخصان مختلفان، تسمية تكاملهما إلى الاسم الثالث نفسه في غضون يوم واحد من بعضهما البعض.

تستحق العائلة نفسها أن تبقى في الاعتبار، لأنها تفسّر البراغماتية. وقد حملت الإصدارات العامة حتى الآن العلامة التجارية TeleChat:

• TeleChat-7B وTeleChat-12B، تم إصدارهما كمصدر مفتوح في يناير 2024 بمجموعة بيانات تضم تريليون رمز.

• TeleChat2-115B (سبتمبر 2024)، الذي يُروَّج له بوصفه أول نموذج مفتوح محلي بالكامل بتريليون معامل، إلى جانب النماذج الشقيقة 35B و7B و3B.

• TeleChat2-39B-A12B (مارس 2025)، أول نموذج MoE في العائلة.

• TeleChat3-105B-A4.7-Thinking (ديسمبر 2025)، نموذج خليط خبراء (MoE) دقيق التحبب بإجمالي 105 مليار معامل و4.7 مليار معامل نشط، مدرَّب على 15 تريليون رمز، إلى جانب نموذج TeleChat3-36B الكثيف ولاحقًا نموذج TeleChat3-Coder-36B-Thinking.

إذا ثبت رقم 29B-A4B، فسيقع هذا النموذج دون TeleChat3-105B-A4.7-Thinking في كل من إجمالي المعاملات والمعاملات النشطة — شقيق أصغر وأرخص بدلًا من أن يكون طرازًا رائدًا بديلًا. هذه قراءة، وليست حقيقة؛ فلا شيء في أي من البيانين الصحفيين يقول ما الفئة التي يستهدفها النموذج. علامة Xingchen هي حيث تضع الشركة جهودها في الذكاء الاصطناعي: فقد تأسس مختبر Xingchen AGI رسميًا في بكين في مارس 2026، بانطلاقًا من عائلة النماذج نفسها، وتصف China Telecom نظامها "三全" (متعدد الأنماط بالكامل، كامل الأحجام، محلي بالكامل) بأنه يمتد عبر نماذج دلالية وصوتية وبصرية ومتعددة الأنماط من 1B إلى 1T+ معامل. إن إعادة التسمية من TeleChat إلى Xingchen هي بالضبط ما يفعله المختبر عندما يريد أن تحمل عائلة النماذج علامة المختبر بدلًا من علامة خط الإنتاج.

ما زلنا لا نعرفه

بالنسبة لنموذج في هذه المرحلة المبكرة، لا تزال القائمة الصادقة أطول من القائمة المعروفة، وإن كانت قد تضيّقت في موضعين هذا الأسبوع:

• لا يوجد تاريخ إصدار. خمس من التكاملات الستة هي مسودات فُتحت لمراجعة الكود مبكرًا، تحديدًا لأن الأوزان ليست عامة. أما السادس، SGLang #39793، فهو مفتوح للمراجعة بدلًا من كونه مسودة — لكنه غير مدمج، وجميع تشغيلات CI الثلاثة له تفشل، ويحتاج إلى مراجع يوافق عليه. لا يوجد جدول زمني معلن.

• عدد من المعلمات، لكنه مجرد عدد مُدَّعى. كل نسخة سابقة من هذا الجزء أدرجت تهيئة MoE على أنها غير معلنة. يغيّر طلب السحب الخاص بـ SGLang ذلك على الورق: Xing4.0-29B-A4B، بإجمالي 29B، ونحو 4B نشطة. الرقم مصدره طلب سحب، وغير مرتبط بأي نقطة تحقق عامة، ولا يؤكده أي ملف إعدادات، ولم يعِد إنتاجه أحد خارج المشروع. اعتبره نية معلنة، لا مواصفة.

• لا توجد أرقام مقاييس أداء، سواء المبلَّغ عنها من المورّد أو من غيره، ولا درجات مستقلة. تُظهر نصوص التحقق في SGLang PR النموذج وهو يجيب عن مطالبة استدلالية ويصدر استدعاء أداة سليم البنية؛ لكنها لا تُظهر شيئًا عن مدى إجادته لأيٍّ منهما.

• لا يوجد تسعير، ولا ترخيص مؤكد. جميع إصدارات TeleChat السابقة هي Apache-2.0، وهو أمر مشجع، لكن لم يُذكر أي ترخيص لهذا الإصدار.

• لا توجد أوزان عامة — وهذا مؤكَّد لا مفترض. اعتبارًا من 16 سبتمبر 2026، المسار على Hugging Face الذي يذكره PR الخاص بـ SGLang ليس متاحًا للقراءة العامة، والمنظمة التي يشير إليها لا تُدرج أي نماذج عامة؛ وأحدث إدخال عام في العائلة هو TeleChat3-Coder-36B-Thinking من يناير. ويقول جدول النماذج المدعومة لدى vLLM إن خانة نقطة التحقق TBA، ويقول جدول SGLang «قريبًا»، كما يعاني كلا الـ PRs الخاصين بـ SGLang من CI عام فاشل.

• لا يوجد أي تصريح رسمي من China Telecom — لا إعلان، ولا أوزان، ولا تأكيد للاسم أو الحجم. لاحظ عدم التماثل بعناية: صفّ توثيق SGLang ينسب النموذج إلى China Telecom، لكن ذلك وصف مساهم داخل طلب سحب، وليس بيانًا من الشركة، كما أن وصف أحدث طلب سحب يحذف اسم المزوّد بالكامل. وجود ست تكاملات قيد البناء لهذا النموذج هو أقوى دليل حتى الآن على أنه حقيقي، لكن التكاملات تُغلق وتتغيّر الأسماء الرمزية؛ وقد حدث ذلك مع اثنين بالفعل. لا شيء مؤكد حتى يصرّح المختبر بذلك.

القراءة الصحيحة لكل هذا ليست شكًا في النموذج؛ بل هي صورة دقيقة لإشارة مبكرة. ما هو موجود اليوم هو أثر هندسي حقيقي — ستة منها، عبر إطارين — بمعمارية حقيقية، ولأول مرة، شكل معلن مرتبط به. وما لا يوجد بعد هو أي شيء يمكنك تنزيله أو استدعاؤه أو قياس أدائه.

أقرب شيء يمكنك تشغيله اليوم

هذا النموذج غير قابل للتشغيل في أي مكان — لا عبر 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 دون أن يُدمج، ثم عاد العمل بعد تسعة أيام باسم جديد برقم #57135. وكان طلب سابق إلى vLLM، هو #51237، قد أُغلق وأُعيد تقديمه في اليوم نفسه وبالعنوان ذاته، فالإغلاق وإعادة التقديم إذن نمط متبع لدى هذا المؤلف لا علامة على مشكلة — لكن نصوص الطلبات لا تذكر أي سبب، ولن نختلق سببًا من عندنا.

متى سيتم إصدار Xing4_0؟

لا يوجد تاريخ. خمس من عمليات التكامل الست هي مسودات فُتحت لمراجعة الكود المبكرة، وخطط المؤلفين أنفسهم هي إضافة مدخلات اختبار، وتحديث الوثائق، ووسم طلبات السحب (PRs) كجاهزة فقط بعد إطلاق الأوزان. قائمة التحقق الأقدم لدى SGLang هي أوضح بيان للوضع الراهن: "النموذج يُحمَّل ويولّد (محليًا، على أوزان داخلية)" مؤشَّر عليها، و CI العام "محجوب بانتظار إطلاق الأوزان". طلب السحب الأحدث في SGLang مُقدَّم كجاهز للمراجعة بدل أن يكون مسودة، وهذا تغيّر في الموقف لا تغيّر في الحالة — فهو غير مدموج، و CI الخاص به أحمر، وسطر في الوثائق يقول "قريبًا" ليس إطلاقًا.

هل Xing4_0 هو نفس الطراز مثل XingChen4؟

على الأرجح نعم، وتجعل الـ PRs التحقق سهلاً: نفس سلالة التفرع، ونفس فقرة البنية المعمارية، ونفس أرقام قياس الأداء لـ FlagGems، ونفس البنود المفتوحة، وإعادة تسمية ملفًا بملف في كلا الإطارين — من xingchen4.py إلى xing4_0.py، بما في ذلك صنف الإعدادات، على فروع أُعيدت تسميتها لتتطابق. إنه العمل نفسه يرتدي اسمًا جديدًا، واعتبارًا من 16 سبتمبر، تبنّى كل من vLLM وSGLang ذلك الاسم. وما لا تذكره أي من الـ PRs هو الاسم الذي ستحمله نقطة تفتيش مُصدَرة.

هل هذا نموذج Deep​Seek؟

لا. إنه نموذج China Telecom، من Xingchen AGI Lab. إن الصلة بـ DeepSeek معمارية: فهو يعيد استخدام البنية الأساسية DeepSeek-V2/V3 ومخطط mHC المتبقي الذي اقترحته DeepSeek وأطلقته في V4. تبنّي معمارية شخص آخر لا يعني أن المشروعين مرتبطان.

ماذا تشاهد بعد ذلك

لا تزال طلبات السحب تقدّم قائمة تحقق ملموسة، وقد أضاف زوج 16 سبتمبر بندين إليها. أولًا، الأوزان: قال كل مؤلف إن عمله يتوقف على Hugging Face، لذا فإن ظهور مستودع عام هو الحدث المحوري — وطلب SGLang الآن يمنحك المسار الدقيق الذي يجب مراقبته، XingChen-AGI/Xing4.0-29B-A4B، والذي لا يُحلّ حاليًا لأي أحد. ثانيًا، طلبات السحب نفسها: يحتاج طلب vLLM إلى تأكيد صيغ تحيز mHC، وإضافة إدخال اختبار السجل، وأن يكون CI الخاص به أخضر؛ ويحتاج #39793 الخاص بـ SGLang إلى إصلاح تشغيلاته الحمراء الثلاث وإلى موافقة المراجعين العشرة المطلوبين، بينما لا يزال #37228 الأقدم يحتاج إلى إدخال اختباره، ومعيار تسريع MTP، وCI غير محظور. ثالثًا، وهو جديد هذا الأسبوع: ما إذا كان SGLang سيغلق #37228 لصالح #39793 بالطريقة التي طالما أغلق بها vLLM سلفًا قبل إعادة التقديم. وجود تكاملين نشطين لنموذج واحد غير مُصدَر حالة لا يحافظ عليها أحد طويلًا، وأيّهما يبقى يقول شيئًا عن مدى قرب هذا في الواقع. رابعًا، الأرقام: ما إذا كانت نقطة تحقق منشورة تطابق شكل 29B-A4B، وMoE ذا 64 خبيرًا، والسياق البالغ 262,144 رمزًا الذي يؤكده الإعداد ووصف طلب السحب الآن. خامسًا، ما إذا كان طلب vLLM الثالث سيبقى أطول من سابقيه، اللذين استمرا 21 و11 يومًا على التوالي قبل إغلاقهما دون دمج. وراقب ما إذا كانت محلّلات الاستدلال تصف نسخة Thinking منفصلة بالطريقة التي أطلقت بها TeleChat3 واحدة.

إلى أن يحدث أحد تلك الأمور، تعامل مع هذا النموذج على ما هو عليه: خطة محددة جيدًا من مختبر جاد، ضُبط متلبسًا أثناء تحضير بنيته التحتية للتقديم — الآن في كلٍ من حزمتي التقديم الرئيسيتين مفتوحتي المصدر، تحت اسمٍ تبنّاه كلاهما وحجمٍ لا يذكره سوى طلب السحب الخاص به. البنية وحدها تجعله جديرًا بالمتابعة: فهو ثاني تبنٍّ رئيسي لـ mHC بعد Deep​Seek نفسه، من مختبر كانت أجياله السابقة بالفعل MoE دقيقة التجزئة مدرَّبة على رقاقات محلية. عندما تُطرح الأوزان، لن يكون هناك سؤال حول ما إذا كان يعمل في vLLM أو SGLang. فقد كتبت كلتا الحزمتين الشيفرة ثلاث مرات، تحت ثلاثة أسماء مختلفة.