تسريب Qwen 4: SGLang يجزّئ Prefill الخاص بـ Qwen4Exp لتحقيق TTFT أسرع بنسبة 18% واسترجاع GiB لكل GPU

طلب سحب فُتح في مستودع SGLang عند الساعة 03:47 بتوقيت UTC صباح هذا اليوم، 2026-10-08، يَعِد بشيء لم يُنتجه أي إعلان عن Qwen 4 حتى الآن: رقمًا. وهو بعنوان feat(qwen4-exp): تفعيل التوازي التسلسلي LayerNorm لـ GR و PLE، وعلى أربع وحدات GPU من نوع H20 تشغّل نقطة تفتيش Qwen3.8-Flash-Next مفتوحة الأوزان بدقة FP8، يذكر مؤلفها مكاسب في زمن الوصول إلى أول رمز (time-to-first-token) تتراوح بين 17.7–18.4% عند إدخال 32K و14.6–14.7% عند إدخال 235K، ونحو غيغابايت من ذروة الذاكرة المستعادة لكل GPU، وزيادة تصل إلى 22% في إنتاجية الإدخال. Qwen 4 نفسه — العائلة التي سمّاها المورّد لكنه لم يطرحها في مؤتمر Apsara في هانغتشو في 2026-09-22 — لا يزال غير صادر، بلا أوزان ولا معرّف ولا سعر. النموذج الوحيد الذي يجسّد معمارية Qwen4Exp اليوم هو Qwen3.8-Flash-Next، المنشور في 2026-08-26، وشقيقه المُدار Qwen3.8-Flash هو النسخة التي يستطيع مُستدعي API الوصول إليها فعلاً. لذا اقرأ ما يلي على أنه بالضبط ما هو: قياسات مقترنة لمهندس واحد، مرفقة بطلب سحب مفتوح ومسودة وغير مدموج، عن نطاق الخدمة لعائلة نماذج لا وجود لها بعد.

المصدر أولاً، لأن هذا نص مسرّب والتمييز هنا يؤدي دورًا حقيقيًا. الإشارة هي sgl-project/sglang#43048، فُتح في 2026-10-08 عند 03:47 UTC بواسطة حساب GitHub shiyang814-cpu، وآخر تعديل له عند 03:55 UTC، وما زال موسومًا مسودة، مع عدم تسجيل أي مراجعة موافقة وعدم الدمج. يغيّر ستة ملفات — ملفّا اختبار، وملف نموذج Qwen4Exp، ووحدة LayerNorm-SP، ومصنع حدود الطبقات، وخطاف مجموعة الوسائط — بإجمالي +345 و−50 سطرًا. كل رقم أداء أدناه مأخوذ من وصف طلب السحب، وهو قياس مزدوج OFF/ON من المؤلف نفسه، ولم يُعِد إنتاجه أحد. ثلاث عمليات تشغيل CI على المراجعة عند طرف الفرع موسومة بالفشل. لا شيء هنا قدرة مُصدَرة.

ما الذي يغيّره طلب السحب فعليًا

التوازي التسلسلي ليس تغييرًا للنموذج وليس قدرة جديدة. إنه إعادة توصيل لمكان قيام بضع طبقات بحساباتها. يعود نسبه إلى التوازي التسلسلي على نمط Megatron — الحيلة من arXiv:2205.05198 — وقد أصبح SGLang يوفره بالفعل: ونص التوثيق الخاص بالوحدة نفسها يشرح الآلية التي يعيد استخدامها، وهي أنه في ظل التوازي التنسوري الخالص، يكون موازي الصف all_reduce جبريًا reduce_scatter متبوعًا بـ all_gather. لأن هاتين العمليتين الجماعيتين تنقلان بالضبط نفس البايتات التي ينقلها الـ all_reduce الواحد الذي تحلانه محله، فإن تقسيم العملية بهذه الطريقة لا يكلف أي حجم اتصال إضافي على الإطلاق. ما يجلبه هو الحرية في ترك مناطق التطبيع والبقايا تعمل على التنشيطات المقسّمة تسلسليًا — كل رتبة توازٍ تنسوري تحمل واحدًا-1/tp من صفوف الرموز — مما يقلل ذاكرة التنشيط العابرة التي يحتاج التمهيد طويل السياق إلى إبقائها حية.

ما يفعله طلب السحب هذا تحديدًا هو توسيع ذلك المسار الموجود من البنية التي تم التحقق منها عليها إلى بنية Qwen4Exp. أثناء التعبئة المسبقة، تظل تنشيطات المتبقي المُبوَّب والتضمين لكل طبقة مقسمة إلى شظايا على طول بُعد الرمز عبر مجموعة TP. قبل تشغيل الانتباه، وقبل GDN، وقبل QSA، وقبل تشغيل كتلة خليط الخبراء، يتم تجميع صفوف الرموز الكاملة مرة أخرى، ويعمل حساب التوازي الموتر للصف الكامل الموجود دون تغيير خلف احتياطي مشترك، ثم يقوم التقليل-التوزيع بجمع المساهمات الجزئية واستعادة شظية كل رتبة. لا يلمس فك التشفير المسار الجديد على الإطلاق. يتم الوصول إلى الميزة عبر الخيار الموجود بالفعل — --enable-layernorm-sp — مع عدم وجود علامة خاصة بـ Qwen4Exp، وعند غياب العلامة، يتصرف الكود تمامًا كما كان يفعل من قبل.

لماذا Qwen4Exp هي البنية التي تحتاج إلى هذا

السبب في أن هذا مهم لـ Qwen4Exp تحديدًا، وليس بالقدر نفسه لكل نموذج، يكمن في تصميم البنية نفسها. يطبّق Qwen3.8-Flash-Next إسقاطات Gated Residual على كل صفوف الرموز في كل طبقة فك ترميز — يعلن الإعداد عن أربعة مسارات متبقية ورتبة عنق زجاجة 320 عبر 48 طبقة — وتضيف التضمين لكل طبقة (Per-Layer Embedding) إسقاطًا ثانيًا مُكرَّرًا، صفًا تلو صف من الرموز، فوق ذلك. في ظل التوازي الموتر، تُكرَّر كلتا العمليتين بشكل مماثل على كل رتبة، لأنها لا تحمل مصفوفة أوزان مقسّمة حسب TP خاصة بها لفرض الانقسام. تؤدي تقطيع بُعد الرموز الخاص بها إلى إزالة العمل المكرر مباشرةً، وكما تقول فقرة الدافع في PR، يحدث ذلك مع الحفاظ على تخطيط التوازي الموتر الحالي ودلالات التقليل الخاصة بالانتباه وGDN/QSA وMoE — وهو الجزء الذي يجعل التغيير آمنًا بدلًا من كونه بارعًا.

يجدر القول بوضوح ما يعنيه ذلك للقارئ. الشيء المثير للاهتمام في طلب السحب هذا ليس أن SGLang يصبح أسرع. بل إن معمارية Qwen4 تحمل تكاليف لكل طبقة تتدرّج مع عدد الرموزبدلًا من عدد المعاملات، وهذه التكاليف هي التي تُلقي بثقلها على عمليات التعبئة المسبقة الطويلة. إنها بصمة تصميمية، وهي من الأمور التي لا تذكرها ورقة المواصفات أبدًا.

الفروق المقاسة

يثبّت معيار الكاتب إعدادًا واحدًا ويبدّل العَلَم: أربع وحدات معالجة رسومات NVIDIA H20، وQwen3.8-Flash-Next-FP8، والتوازي على مستوى الموتر 4 والتوازي على مستوى الخبراء 4، وحجم التعبئة المقطّعة 8192، وخلفيات التعبئة وفك التشفير للانتباه الخطي في FlashInfer، ونفس إعداد الخادم لـ OFF وON، مع إعادات تشغيل الخدمة بالتناوب OFF → ON → OFF → ON، ومدخلات رموز ثابتة مع طلبات تسخين. كل رقم أدناه مأخوذ من ذلك الإعداد وغير مُدقّق:

• إدخال بحجم 32K، حجم الدفعة 1 — تحسّن TTFT بنسبة 17.72–18.36%، وزمن الاستجابة من البداية إلى النهاية نحو 16%، وإنتاجية الإدخال نحو 20%

• مدخلات 235 ألف، حجم الدفعة 1 — تحسّن TTFT بنسبة 14.63–14.71%، وزمن الاستجابة من البداية إلى النهاية بنحو 14%، وإنتاجية المدخلات بنحو 17%

• إدخال 32K، حجم الدفعة 4 — تحسّن TTFT بنسبة 18.74%، وزمن الاستجابة من طرف إلى طرف 18.14%، وإنتاجية الإدخال 22.14%

• ذروة الذاكرة — انخفاض بنحو 1.0 GiB لكل GPU

• فك التشفير، حجم الدفعة 1 — الوقت لكل رمز ناتج لم يتغير فعليًا

السطر الأخير هو الذي يستحق القراءة مرتين، والمؤلف صريح في سبب ذلك: هذا التحسين مُفعَّل فقط لمرحلة التمهيد (prefill)، لذا لا يستفيد فك التشفير أحادي التدفق منه بشيء. والتحسّن في زمن كل رمز مع حجم دفعة 4، حيث يظهر أصلاً، إنما يعكس تقلّص تأخيرات الجدولة الناتجة عن عمليات التمهيد الطويلة المتزامنة، لا أي نواة فك تشفير أسرع. وإن كنت تأمل أن تكون هذه قصة إنتاجية، فهي ليست كذلك — إنها قصة زمن الوصول إلى أول رمز والذاكرة، وهذان هما القيدان اللذان يحسمان ما إذا كان طلب بحجم 235 ألف رمز قابلاً للخدمة أصلاً.

خلل التخطيط الذي كان عليهم إصلاحه أولاً

الجزء الأكثر إفادة في طلب السحب ليس جدول التسريع. بل هو القسم الخاص بتخطيط الصفوف الفيزيائية لـ PLE، لأنه يوضح ما لا تزال حزمة خدمة Qwen4Exp تخطئ فيه.

يعمل Per-Layer Embedding على حاوية CUDA-graph فيزيائية ثابتة، بينما قد تحمل بادئة فقط من الصفوف في تلك الحاوية رموزًا حقيقية. لذلك يجب تطبيق الحشو قبل تجزئة التسلسل، وليس بعدها. في الجزء الأخير من طلب بحجم 235K رمزًا، أرقام المؤلف هي 5,624 رمزًا معالَجًا داخل حاوية فيزيائية من 8,192 صفًا عند TP 4، والتخطيط الصحيح الوحيد هو أن تحتفظ الرتبة 0 بـ 2,048 صفًا صالحًا، والرتبة 1 بـ 2,048 صفًا صالحًا، والرتبة 2 بـ 1,528 صفًا صالحًا بالإضافة إلى 520 صف حشو، والرتبة 3 بـ 2,048 صفًا من الحشو. إن تجزئة الصفوف المعالَجة البالغ عددها 5,624 أولاً — وهو التنفيذ البديهي — تُدخل حشوًا بين نطاقات صالحة متجاورة عالميًا وتُفسد النتيجة. يسجل المؤلف أن اختبار OFF/ON حقيقيًا بحجم 235K لم يُنتج سوى مخرجات جشعة متطابقة من 16 رمزًا بعد تم إصلاح هذا التخطيط.

هذا تفصيل صغير ذو أثر كبير. أُضيف مسار PLE في SGLang حديثًا بما يكفي بحيث ظل خطأ في ترتيب الرموز بهذا الشكل قابلاً للوقوع، وكان الشخص الذي اكتشفه يكتب امتداد التوازي التسلسلي. دعم خدمة هذه المعمارية منذ اليوم الأول لم يكتمل بعد؛ بل يجري بناؤه بنشاط، علنًا، على يد المساهمين، تخطيطًا واحدًا في كل مرة.

ما يكلفك: القيود

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

• يجب أن يكون حجم التوازي الموتر أكبر من 1 — فنشر على وحدة معالجة رسومات واحدة لا يحقق أي مكسب، لأنه لا توجد رتبة لتجزئة العمل عبرها

• يجب أن يساوي حجم التوازي للخبراء حجم التوازي للموتر

• يجب أن يكون حجم التوازي الأنبوبي مساويًا لـ 1

• يجب تعطيل الانتباه المتوازي بياناتيًا

• يجب تعطيل فك التشفير التخميني

القيد الأخير هو القيد الذي يقف خلفه قرار حقيقي. بالنسبة لنموذج متناثر يفعّل نحو 6B من المعاملات لكل رمز، يُعد فك التشفير التخميني إحدى الروافع القليلة التي تسرّع فك التشفير، وهذه الميزة توقف تلك الرافعة صراحةً مقابل مكسب في التعبئة المسبقة (prefill). إذا كان عبء العمل لديك يتمثل في مطالبة طويلة وإخراج قصير — تحليل المستندات وقواعد الشيفرة، وتلخيص الفيديو، وسياق كبير يُقرأ مرة واحدة — فالمقايضة جيدة بوضوح. أما إذا كان عبء العمل لديك مطالبة قصيرة وتوليدًا طويلًا، فأنت تتخلى عن الشيء الذي كان يساعدك وتشتري رقمًا لا ينطبق عليك. ومتطلب أن يكون التوازي بين الخبراء مساويًا للتوازي التنسوري هو المتطلب الآخر الجدير بالملاحظة: فهو يعني أن هندسة تقسيم moe يجب أن تتوافق مع هندسة TP تمامًا، مما يستبعد عدة تخطيطات متعددة العقد كانت معقولة لولا ذلك.

ماذا يقول هذا عن الجدول الزمني لـ Qwen 4

اقرأ الفرق بطريقة أخرى وستحصل على تقويم. وحدة LayerNorm-SP الخاصة بـ SGLang على الفرع الرئيسي اليوم تحمل قائمة سماح صريحة بالمعماريات التي تم التحقق من الميزة فيها، واعتبارًا من كتابة هذا النص، تحتوي قائمة السماح هذه على مدخل واحد بالضبط، Qwen3ForCausalLM — يتم رفض كل معمارية أخرى عند الإنشاء إذا مررت العلامة. لذا فإن إضافة Qwen4Exp إلى هذا المسار ليست تعديلًا على تجريد ناضج؛ إنها المرة الأولى التي تُجلب فيها معمارية Qwen4 إلى تحسين يسبقها بأجيال.

ضع ذلك مقابل السجل العام وستجد الصورة متماسكة. أعلنت الشركة المورّدة في 2026-09-22 أن Qwen 4 قيد التدريب، واستعرضت أربعة أسماء لفئات — Qwen 4 Max وQwen 4 Flash وQwen 4 Plus وQwen 4 27B — دون ربط أي مواصفات بأي منها. أما المعاينة ذات الأوزان المفتوحة التي تشترك في البنية، Qwen3.8-Flash-Next، فهي متاحة للتنزيل منذ 2026-08-26. وما يحدث في الأسابيع الثلاثة منذ ذلك الحين هو بالضبط ما تتوقعه بين "قيد التدريب" و"الإطلاق": مؤلفو المحركات يضبطون بيئة التشغيل ليكون دعم اليوم الأول حقيقياً لا اسمياً. طلب سحب يجعل تحسيناً لخدمة النموذج يعمل على البنية، فُتح صباح 2026-10-08 وما زال مسودة، هو إشارة أفضل إلى مدى قرب Qwen 4 من أن يصبح قابلاً للخدمة من أي تاريخ طرحه أحد. وهو أيضاً، وبشكل قاطع، ليس تاريخ إصدار — فالمُعلَم معطّل افتراضياً، والتغيير غير مدموج، والنموذج الذي يقيس أداءه هو المعاينة، وليس Qwen 4.

ما الذي يمكنك تسميته اليوم

لا شيء من ذلك يغيّر ما هو متاح فعليًا بعد ظهر اليوم. Qwen3.8-Flash-Next حقيقي، وأوزانه متاحة على Hugging Face، ويمكنك استضافته بنفسك — لكنه ليس في كتالوجنا، ولن نتظاهر بغير ذلك. الفئة التي نقدّمها فعلًا هي qwen/qwen3.8-flash، النظير المُدار الذي يعمل على البنية نفسها Qwen4-preview مع نافذة سياق تبلغ مليون رمز وإدخال نصي وصوري وفيديو، بسعر 0.15 دولار لكل مليون رمز إدخال، و0.47 دولار لكل مليون رمز إخراج، و0.0184 دولار لكل مليون قراءة من الذاكرة المؤقتة. هذا سعر قائمة يُمرَّر بهامش ربح 0%، لذلك عندما يغيّره المورّد، يتغير الرقم في فاتورتك في اليوم نفسه بدلًا من أن يتغير وقتما يعيد وسيط نشر جدول.

هناك سبب ثانٍ أقل وضوحًا للاهتمام بطبقة توجيه هنا. كل ما في هذه المقالة يدور حول معاينة غير مُثبتة بالإضافة إلى رقعة مسودة — النوع الذي تريد اختباره دون المراهنة بمسار إنتاجي عليه. وهذا هو الغرض من تجاوز الفشل: ضع المعاينة خلف المفتاح نفسه الخاص بالطراز الذي تثق به بالفعل، وراقب كيف تتصرف مع حركة مرورك، واترك الطلب ينتقل إلى المسار المعروف بجودته عندما يتعثر مزوّد أو تكون نقطة النهاية غير موجودة. واجهة برمجية واحدة لأكثر من 200 طراز، ومجموعة واحدة من بيانات الاعتماد، ودون توقيع عقد ثانٍ لمعرفة ما إذا كانت بنية جديدة تستحق انتباهك.

هناك أمران يجب مراقبتهما من هنا، ولا يمكننا التنبؤ بأيٍّ منهما. الأول هو ما إذا كان هذا التصحيح سيُدمج أصلاً: فهو مسودة بها ثلاث عمليات تشغيل CI فاشلة على تغيير يمس ستة ملفات من حساب مساهم ليس له تاريخ سابق في المستودع، والتغيّر المستمر في العمل على تخطيط صفوف PLE يشير إلى أن المؤلف لا يزال يكرر التعديلات. والثاني هو ما إذا كانت قائمة السماح تتوسع — إذا انضم Qwen4Exp إلى Qwen3ForCausalLM كبنية معتمدة، فإن هذا يتوقف عن كونه تسريباً ويصبح الطريقة الافتراضية لخدمة نموذج من عائلة Qwen4 على سياق طويل. وإلى أن يحدث أحد هذين الأمرين، تعامل مع نسبة 18% كوعد بشأن الوجهة التي تتجه إليها بيئة التشغيل، لا كرقم يمكنك استئجاره.