Qwen3.8-27B يستطيع قراءة مليون توكن، لكن فقط إذا فعّلت الأعلام الصحيحة

النموذج الذي يفكر أقل من المفترض أن يجيب أسرع. دليل علي بابا العملي الخاص بـ Qwen3.8-27B، المنشور على مدونة Alibaba Cloud، يحذر من أن هذا الافتراض لا يصمد عند استخدام وكيل: «في المهام الوكيلية متعددة الجولات، لا يعني انخفاض الجهد دائمًا سرعة أكبر من البداية إلى النهاية.» الاستجابات الأسرع لكل جولة قد تجلب المزيد من الإخفاقات وإعادة المحاولات، وهذا يرفع زمن الاستجابة الإجمالي واستهلاك التوكنات. المقبض الذي يبدو وكأنه أداة تحكم في السرعة هو في الحقيقة أداة تحكم في الميزانية، والشركة المصنّعة تقول ذلك في مواد الإطلاق الخاصة بها.

النموذج الذي يقف خلف هذا التحذير هو نموذج كثيف بحجم 27B على معمارية Qwen3.5 مع فهم بصري-لغوي أصلي. تصفه علي بابا بأنه مضغوط وسهل النشر، وهو يفكر افتراضيًا قبل الإجابة. الجديد بالنسبة إلى المطورين هو الدعم الرسمي لمعامل reasoning_effort بمستوياته الثلاثة: xhigh وmedium وlow، في واجهة Chat Completions المتوافقة مع OpenAI، بحيث يمكن للفرق الموازنة بين الدقة والسرعة والتكلفة لكل طلب.

ميزانية تفكير تكشفها الواجهة البرمجية فعليًا

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

262,144 توكنًا أصليًا، ومليون توكن عبر YaRN

قصة السياق هي النصف الآخر. يدعم Qwen3.8-27B أصلًا أطوال سياق تصل إلى 262,144 توكنًا. وعندما يتجاوز الطول الإجمالي, المدخلات زائد المخرجات, هذا الحد، يحتاج النموذج إلى تحجيم RoPE، والمسار المدعوم هو YaRN، المتاح في vLLM وSGLang وTokenSpeed. بالنسبة إلى vLLM، يقدّم الدليل سطرًا واحدًا لبدء التشغيل يضبط الحد الأقصى لطول النموذج على 1,000,000 ويتجاوز معاملات rope، بما في ذلك وضع yarn، وtheta بقيمة 10,000,000، ومعامل دوراني جزئي بقيمة 0.25، ومعامل مقياس بقيمة 4.0:

VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 vllm serve ..., hf-overrides '{"text_config": {"rope_parameters": {"mrope_interleaved": true, "mrope_section": [11, 11, 10], "rope_type": "yarn", "rope_theta": 10000000, "partial_rotary_factor": 0.25, "factor": 4.0, "original_max_position_embeddings": 262144}}}', max-model-len 1000000

يمكن وضع المعاملات نفسها مباشرة في قسم text_config من ملف config.json الخاص بالنموذج، وهو ما يناسب محركات مثل Unsloth. في كلتا الحالتين، مليون توكن ليس مجرد مربع اختيار: يجب أن يتفق النموذج ومكدس الخدمة على ترميز موضعي موسّع، وهذا القرار مكانه مراجعة فنية، لا مكالمة استكشافية.

لماذا يمكن لإعداد الجهد المنخفض أن يجعل الوكلاء أبطأ

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

يصل النموذج وسط توجه قوي نحو المؤسسات. مؤتمر Qwen في هونغ كونغ في 26 أغسطس 2026 جمع أكثر من 300 عميل مؤسسي ومطور تحت شعار «QwenCloud: سحابة أصلية بالذكاء الاصطناعي، مبنية لعصر الوكلاء». سجّل أكثر من عشرة عملاء محتملين مؤهلين من قطاعي الإنتاج السينمائي والخدمات المالية اهتمامهم في الموقع. نموذج كثيف بحجم 27B مع تفكير قابل للتحكم يناسب هذا الطرح: إنه بحجم أعباء عمل حقيقية، لا بحجم عناوين المعايير.

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