تشغيل Qwen3.8-Flash-Next محليًا: ماذا تعني المعلمات النشطة البالغ عددها 6 مليارات فعلًا لذاكرة RAM وVRAM وNVMe؟

إيفا وونغ

IceWhale author

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

Qwen3.8-Flash-Next Locally: What 6B Active Parameters Really Mean for RAM, VRAM, and NVMe

لا، لا يتوافق Qwen3.8-Flash-Next مع الذاكرة كما لو كان نموذجًا بحجم 6 مليارات مُعامِل لمجرد أنه يفعّل نحو 6 مليارات مُعامِل لكل رمز. تصف Qwen نموذجًا رئيسيًا يضم 125 مليار مُعامِل، مع تفعيل 6 مليارات منها، بالإضافة إلى 51 مليارًا من تضمينات n-gram ومكوّن MTP يضم نحو 4 مليارات مُعامِل. ويبلغ حجم المستودع الرسمي لـ Qwen3.8-Flash-Next حاليًا نحو 360 جيجابايت بصيغة BF16 المُصدرة. ويمكن لتحويلات GGUF التي ينفذها المجتمع تقليل هذا الحجم بدرجة كبيرة، لكنها لا تجعل Flash-Next نموذجًا تقليديًا بحجم 6 مليارات مُعامِل.

الطريقة المفيدة للتفكير في النشر المحلي هي اعتباره تسلسلًا هرميًا للذاكرة. تحدد ذاكرة VRAM مقدار تنفيذ النموذج عالي السرعة الذي يمكن أن يبقى على وحدة معالجة الرسومات. وتوفر ذاكرة النظام RAM سعةً للمكوّنات المقيمة على وحدة المعالجة المركزية والمكوّنات المُرحّلة إليها، بما في ذلك جدول n-gram الكبير على نحو غير معتاد، والذي صمّمته Qwen صراحةً للعمل من ذاكرة المضيف. وتوفر NVMe تخزينًا محليًا سريعًا ودعمًا مُسنَدًا إلى خرائط الذاكرة للملفات التي تقترب من 100 جيجابايت أو تتجاوزها، لكنها ليست بديلًا عن RAM أو VRAM. لذلك، يتمثل السؤال الحقيقي في تحديد ما الذي يزيله رقم 6 مليارات النشطة من عبء العتاد، وما الذي لا يزيله.

هل يعني تفعيل 6 مليارات مُعامِل أن Qwen3.8-Flash-Next يحتاج إلى ذاكرة نموذج بسعة 6 مليارات فقط؟

لا. تصف المُعامِلات النشطة مقدار الحساب لكل رمز، وليس إجمالي حالة النموذج الموجودة. ويكتسب هذا الفرق أهمية خاصة في Qwen3.8-Flash-Next لأن الفارق بين عدد مُعامِلاته النشطة وعدد مُعامِلاته المخزّنة كبير على نحو غير معتاد.

وفقًا لـ بطاقة النموذج الرسمية لـ Qwen3.8-Flash-Next، يحتوي نموذج اللغة على 125 مليار مُعامِل، مع تفعيل نحو 6 مليارات لكل رمز، بالإضافة إلى 51 مليار مُعامِل لتضمينات n-gram ونحو 4 مليارات من المُعامِلات المرتبطة بـ MTP. ويحتوي نموذج MoE الرئيسي على 512 خبيرًا موجّهًا، ويختار 10 خبراء موجّهين بالإضافة إلى خبير مشترك واحد لكل رمز.

وهذا ينتج ثلاثة أعداد مختلفة لا ينبغي الخلط بينها:

العدد	ما الذي يصفه	ما الذي لا يخبرك به ذلك
نحو 6 مليارات نشطة	ما مقدار النموذج الرئيسي الذي يشارك تقريبًا في الحساب لمعالجة رمز واحد؟	ما مقدار الذاكرة المطلوبة لتخزين النموذج الكامل؟
النموذج الرئيسي: 125 مليارًا	العدد الأساسي لمُعامِلات نموذج اللغة	حجم نقطة التحقق المُصدرة بالكامل
+51 مليارًا من n-gram + نحو 4 مليارات من MTP	مكوّنات إضافية ذات مُعامِلات في الإصدار	إضافة 55 مليار مُعامِل من ضرب المصفوفات الكثيفة لكل رمز

النقطة الأساسية هي أن الخبراء غير النشطين لا يتوقفون عن الوجود. إذ يمكن لرموز مختلفة توجيهها إلى خبراء مختلفين، ولذلك لا يزال وقت التشغيل بحاجة إلى الوصول إلى مجموعة الأوزان الأوسع، رغم أن جزءًا صغيرًا منها فقط يشارك في المرور الأمامي لرمز معين. وهذا هو السبب العام نفسه الذي يجعل نماذج MoE الكبيرة الأخرى قادرة على امتلاك حساب نشط متواضع نسبيًا مع الاحتفاظ ببصمات ذاكرة كبيرة جدًا، وهو تمييز مهم أيضًا في تحليل العتاد المحلي لـ GLM-5.3-Flash.

يضيف Flash-Next تعقيدًا آخر. فجدول تضمين n-gram البالغ 51 مليارًا لا يُستخدم مثل مصفوفة أوزان عادية لشبكة عصبية كثيفة. في النظرة العامة الرسمية من Qwen على بنية Flash-Next، يوضح الفريق أنه يمكن تحديد مواقع البحث عن n-gram مسبقًا. ولذلك يمكن أن يقيم الجدول في ذاكرة المضيف، مع جلبه مسبقًا وبصورة غير متزامنة أثناء تشغيل عمليات حسابية أخرى للنموذج.

لهذا السبب يُعد رقم 6 مليارات معلمة نشطة ذا دلالة، رغم أنه لا يمثل متطلبًا للذاكرة. صُمم Flash-Next للفصل بين سعة النموذج والحساب لكل رمز بدرجة أكبر من نموذج كثيف تقليدي. وبالنسبة إلى الاستدلال المحلي، ينقل ذلك سؤال العتاد من رقم واحد لذاكرة VRAM إلى مدى كفاءة عمل VRAM وذاكرة RAM للنظام والتخزين معًا.

ما حجم Qwen3.8-Flash-Next بعد التكميم؟

يبلغ حجم إصدار BF16 الرسمي نحو 360 غيغابايت، ما يعني فورًا أن نشر النموذج غير المكمّم بالكامل والمقيم في الذاكرة يتجاوز إمكانات أجهزة سطح المكتب العادية. ويغيّر التكميم هذا الوضع تغييرًا كبيرًا.

اعتبارًا من 1 سبتمبر 2026، تتراوح إصدارات GGUF الحالية من Unsloth لـ Flash-Next بين إصدارات منخفضة البِتات شديدة الضغط ومتغيرات أكبر بكثير وعالية الجودة. ومن النماذج المرجعية المفيدة إصدار UD-IQ4_XS بحجم يقارب 93.7 غيغابايت، وإصدار UD-Q4_K_XL بحجم يقارب 111 غيغابايت.

التمثيل	الحجم التقريبي	المعنى العملي
مستودع BF16 الرسمي	~360 غيغابايت	إصدار مرجعي؛ يتطلب ذاكرة بمستوى الخوادم
Q8_0 GGUF من المجتمع	~188 غيغابايت	لا يزال يتطلب سعة ذاكرة كبيرة جدًا
UD-Q6_K_XL من المجتمع	~169 غيغابايت	تكميم عالي الجودة مع متطلبات كبيرة من الذاكرة
UD-Q5_K_XL مجتمعي	~158 جيجابايت	لا يزال أعلى من معظم تكوينات ذاكرة محطات العمل الاستهلاكية
UD-Q4_K_XL مجتمعي	~111 جيجابايت	أكثر واقعية للأنظمة الهجينة ذات الذاكرة الكبيرة
UD-IQ4_XS مجتمعي	~93.7 جيجابايت	هدف محلي تجريبي أصغر من فئة الأربعة بتات

أحجام GGUF هذه تحويلات مجتمعية وليست توصيات رسمية من Qwen للحد الأدنى من ذاكرة RAM أو VRAM. ومع ذلك، فهي مفيدة لتخطيط السعة لأنها توضح حجم المشكلة قبل إضافة المخازن المؤقتة لوقت التشغيل، وحالة السياق، ومعالجة الرؤية، ونظام التشغيل، والتطبيقات الأخرى.

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

ما مقدار VRAM التي يحتاجها Qwen3.8-Flash-Next؟

لا يوجد رقم واحد مفيد لـ«الحد الأدنى من VRAM» لـ Flash-Next، لأن الاستدلال المحلي قد يتراوح بين تنفيذ مقيم بالكامل تقريبًا على CPU ونموذج موزع على وحدة GPU واحدة أو عدة وحدات. تحدد VRAM أساسًا مقدار عبء الاستدلال ذي النطاق الترددي العالي الذي يمكن إبقاؤه على GPU، وبالتالي مدى سرعة تشغيل النظام.

لا يمكن لوحدة GPU استهلاكية بسعة 24 أو 32 جيجابايت استيعاب ملف GGUF رباعي البتات حاليًا بحجم 94–111 جيجابايت بمفردها. لكن هذا لا يعني بالضرورة أن GPU عديمة الفائدة. إذ يمكن لوقت تشغيل قادر على الإلغاء الجزئي إلى GPU إبقاء موترات أو طبقات محددة في VRAM، بينما تحتفظ ذاكرة النظام بالباقي.

تتضمن خيارات تحميل النماذج الحالية في llama.cpp وضع الطبقات على GPU، وتحديد الجهاز صراحةً، وتجاوزات الموترات، وعناصر تحكم CPU MoE. وهذا يعني أن السؤالين «هل يمكن لـGPU تشغيله؟» و«هل يمكن لـGPU استيعاب النموذج بالكامل؟» مختلفان.

ذاكرة VRAM المتاحة	كيفية التفكير في الأمر
16 جيجابايت	تسريع لنشر يعتمد بدرجة كبيرة على ذاكرة RAM؛ وهو أقل بكثير من حجم GGUF الحالي رباعي البتات
24 جيجابايت	إلغاء تحميل جزئي مفيد إلى GPU، لكن معظم نموذج بحجم نحو 94–111 جيجابايت سيبقى في مكان آخر
32 جيجابايت	مساحة أكبر للطبقات المقيمة على GPU وحالة وقت التشغيل، لكنه يظل إعدادًا هجينًا في جوهره
48 جيجابايت	سيناريو هجين جاد، مع إمكانية إبقاء جزء أكبر بكثير من مسار المعالجة مقيمًا على GPU
64 جيجابايت	تسريع محلي قوي، لكنه لا يزال أقل من حجم النموذج الرباعي البتات الحالي البالغ نحو 94 جيجابايت
96 جيجابايت	قريب من حجم أصغر ملف GGUF رباعي البتات حاليًا، لكن المخازن المؤقتة والسياق لا يتركان سببًا وجيهًا لاعتبار 96 جيجابايت هدفًا مضمونًا لتشغيل النموذج بالكامل على GPU
وحدات معالجة رسومية متعددة	يمكن لذاكرة VRAM الإجمالية تقليل الاعتماد على ذاكرة النظام، مع تعقيد إضافي في البنية والطرف التشغيلي

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

لذلك ينبغي التعامل مع ذاكرة الفيديو في Flash-Next باعتبارها تخصيصًا للأداء، لا رقمًا ثنائيًا للتوافق.

كم تحتاج Qwen3.8-Flash-Next من ذاكرة الوصول العشوائي لتفريغ الحمل بين وحدة المعالجة المركزية ووحدة معالجة الرسومات؟

يمكن القول إن ذاكرة النظام أهم بالنسبة إلى Flash-Next مما يوحي به عنوان «6 مليارات نشطة». فالجهاز المزود بوحدة معالجة رسومات استهلاكية، لكن بذاكرة وصول عشوائي قليلة جدًا، لا يملك مكانًا مفيدًا لوضع الكمية الكبيرة من حالة النموذج التي لا تتسع لها ذاكرة الفيديو.

يجعل تضمين n-gram هذا الأمر مثيرًا للاهتمام على نحو خاص. تقول Qwen إن جدول 51 مليارًا يمكن وضعه في ذاكرة المضيف لأن عمليات الوصول إليه حتمية ويمكن جلبها مسبقًا. وعندما دُمج تنفيذ Flash-Next في llama.cpp في 27 أغسطس، وصفت ملاحظات التنفيذ جدول تضمين n-gram لكل طبقة بأنه يبلغ نحو 97.7 جيبيبايت بصيغة BF16، وتعاملت مع البحث عن صفوفه من جانب المضيف.

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

بالنسبة إلى استدلال GGUF العملي، ينبغي التخطيط لذاكرة النظام انطلاقًا من حجم النموذج المكمَّم الفعلي، إضافةً إلى هامش كافٍ لنظام التشغيل ووقت التشغيل. ومع تكميم يبلغ نحو 94 جيجابايت، تُعد ذاكرة بسعة 128 جيجابايت هدفًا تجريبيًا ممكنًا، لكنها ليست سخية بعد احتساب نظام التشغيل والسياق والمخازن المؤقتة وسلوك تخصيص الذاكرة بين وحدة معالجة الرسومات والمضيف. ويوفر نظام بسعة 192 أو 256 جيجابايت هامشًا أكثر أمانًا بكثير للاستدلال الهجين الجاد.

ذاكرة النظام	التقييم العملي
32 جيجابايت	صغير جدًا مقارنة بأحجام Flash-Next GGUF العملية الحالية
64 جيجابايت	لا يزال أقل من أصغر ملف GGUF حالي بأربعة بتات؛ وسيصبح ترحيل الصفحات إلى القرص مشكلة كبيرة
96 جيجابايت	قريب من أصغر حجم لملف تكمين، مع مساحة تشغيل مريحة شبه معدومة
128 جيجابايت	ممكن لتكميم صغير بأربعة بتات مع تفريغ الحسابات إلى وحدة معالجة الرسومات وسياق محافظ، لكن الهوامش تظل ضيقة
192 جيجابايت	هدف هجين أقوى بكثير، مع مساحة للتكميمات الأكبر والنفقات الإضافية أثناء التشغيل
256 جيجابايت فأكثر	أنسب للتكميمات الأكبر، والسياقات الطويلة، والخدمات المتعددة، والتجريب

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

هل يمكن لتفريغ النموذج إلى SSD من نوع NVMe أن يجعل Qwen3.8-Flash-Next عمليًا؟

يمكن لـ NVMe أن يجعل تخزين نموذج أكبر من اللازم وتحميله أسهل، لكنه لا يحوّل سعة SSD إلى ذاكرة استدلال سريعة. وتزداد أهمية هذا التمييز مع تجاوز النماذج المحلية حاجز 100 غيغابايت.

يفيد محرك NVMe السريع في تخزين عدة تنويعات من GGUF، وتحميل نموذج كبير دون الانتظار على تخزين شبكي أو قرص صلب أبطأ، ودعم الوصول إلى النماذج المعينة في الذاكرة. يستخدم llama.cpp تعيين الذاكرة كوضع لتحميل النموذج، ما يتيح تعيين صفحات النموذج من ملف بدلًا من نسخ الملف بأكمله إلى تخصيص منفصل في ذاكرة RAM عند بدء التشغيل.

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

دور NVMe	مفيد؟	لماذا
تخزين نموذج بحجم 94–360 غيغابايت	نعم	تجعل نقاط التحقق الكبيرة التخزين المحلي السريع ذا قيمة
تخزين عدة إصدارات مكمّمة	نعم	يمكن للاختبار المحلي أن يستهلك مئات الغيغابايتات بسرعة
تعيين ملفات النموذج في الذاكرة	نعم	يتيح سلوك تحميل فعّالًا للملفات المدعومة
استبدال ذاكرة النظام RAM المفقودة	لا، ليس بكفاءة	يمكن لأخطاء الصفحات وزمن استجابة التخزين تدمير الأداء التفاعلي
استبدال ذاكرة VRAM الخاصة بوحدة معالجة الرسومات	لا	لا يُعد NVMe بديلًا عن عرض نطاق ذاكرة وحدة معالجة الرسومات

قاعدة مفيدة: يمكن لـ NVMe أن يجعل تحميل نموذج أكبر من اللازم ممكنًا؛ لكنه لا يجعله تفاعليًا تلقائيًا.

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

كيف يغيّر سياق بحجم 262 ألفًا متطلبات الذاكرة؟

يدعم Qwen3.8-Flash-Next أصلاً طول سياق يبلغ 262,144 رمزًا، ويمكن تمديده إلى نحو مليون رمز باستخدام YaRN. لكن هذا لا يعني أن كل عملية نشر محلية ينبغي أن تضبط الحد الأقصى للسياق افتراضيًا.

يستخدم النموذج بنية هجينة بدلًا من الانتباه الكامل التقليدي في كل طبقة. إذ يضغط Gated DeltaNet السجل السابق، بينما يستخدم Qwen Sparse Attention مفهرسًا لاختيار كتل السياق ذات الصلة. وقد صُمم ذلك تحديدًا لتقليل الضغط الحسابي وضغط الذاكرة المرتبطين بالتسلسلات الطويلة.

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

هناك أيضًا فرق بين حد السياق المعماري للنموذج ونضج التنفيذ الحالي لبيئة التشغيل. واعتبارًا من 1 سبتمبر 2026، لم يمضِ على دعم llama.cpp للبنية الجديدة سوى أيام قليلة. وتُبلغ مشكلة CUDA الحالية عند سياق 262K عن فشل إطلاق النواة عند 262,144 رمزًا بالضبط، بينما تنجح العملية عند 261,888 رمزًا على نظام الاختبار. ويحدد التقرير أن السبب قيد في النواة وليس نفاد ذاكرة VRAM.

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

للنشر المحلي، ابدأ بطول السياق الذي يحتاجه حمل العمل فعلًا. فجلسة برمجة أو مهمة تحليل مستندات أو سير عمل RAG خاص يناسب 16K أو 32K أو 64K لا يصبح أفضل لمجرد أن بيئة التشغيل تحجز مئات الآلاف من الرموز.

qwen3.8-flash unsloth لسطح المكتب

ما الأجهزة القادرة فعليًا على تشغيل Qwen3.8-Flash-Next محليًا؟

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

لذلك يُعد الجدول أدناه دليلًا للتخطيط استنادًا إلى أحجام النماذج وملفات GGUF الحالية، وليس توصية رسمية بأجهزة Qwen.

فئة الأجهزة النموذجية	التقييم	ما يمكن توقعه
وحدة معالجة رسومات بسعة 16–24 جيجابايت + ذاكرة وصول عشوائي بسعة 64 جيجابايت	ملاءمة ضعيفة	تتجاوز ملفات GGUF العملية الحالية سعة ذاكرة الوصول العشوائي قبل احتساب هامش تشغيل مريح
وحدة معالجة رسومات بسعة 24 جيجابايت + ذاكرة وصول عشوائي بسعة 128 جيجابايت	هجين تجريبي	قد تتسع نسخة الكمّية بنحو 94 جيجابايت مع سياق محافظ، لكن هامش الذاكرة ضيق ويبقى جزء كبير من النموذج في ذاكرة وحدة المعالجة المركزية
وحدة معالجة رسومات بسعة 32 جيجابايت + ذاكرة وصول عشوائي بسعة 128 جيجابايت	هجين قابل للتنفيذ	إمكانية أكبر لتوزيع الحمل على وحدة معالجة الرسومات مقارنة ببطاقة سعة 24 جيجابايت، لكنه يظل معتمدًا بدرجة كبيرة على ذاكرة الجهاز
وحدة معالجة رسومات بسعة 24–48 جيجابايت + ذاكرة وصول عشوائي بسعة 192 جيجابايت	هجين قوي	هامش سعة أكثر أمانًا بكثير لنماذج الفئة الرباعية البتات وتوزيع الحمل بين وحدة المعالجة المركزية ووحدة معالجة الرسومات
وحدة معالجة رسومات بسعة 48 جيجابايت + ذاكرة وصول عشوائي بسعة 256 جيجابايت	هجين عالي المستوى	تسريع كبير عبر وحدة معالجة الرسوميات مع مساحة لعمليات تكميم أكبر، وسياق أطول، وخدمات تعمل في الخلفية
وحدة معالجة رسوميات بسعة 96 جيجابايت + ذاكرة RAM بسعة 128–192 جيجابايت	محطة عمل محلية متطورة	يقترب أصغر إصدار حالي بأربعة بتات من سعة وحدة معالجة الرسوميات، لكن سعة التخزين المؤقت والنفقات العامة لوقت التشغيل تظل مهمة
نظام بذاكرة موحّدة سعتها 128 جيجابايت	قابل للتنفيذ محتملًا	تكون السعة مهمة لأصغر عمليات التكميم، بينما تحدد كفاءة الواجهة الخلفية وعرض النطاق الترددي الأداء الفعلي
ذاكرة موحّدة بسعة 192–256 جيجابايت أو خادم متعدد وحدات معالجة الرسوميات	أفضل مسار للسعة	مساحة أكبر لأوزان أعلى جودة، وسياق طويل، وتنازلات أقل حدة في النقل إلى الذاكرة الخارجية

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

يمكن لوحدة معالجة رسوميات بسعة 24 جيجابايت مقترنة بذاكرة نظام سريعة سعتها 192 جيجابايت أن توفر تجربة Flash-Next أكثر واقعية من وحدة معالجة رسوميات بسعة 24 جيجابايت مقترنة بذاكرة RAM سعتها 32 أو 64 جيجابايت فقط. وبالعكس، فإن إضافة قدر هائل من ذاكرة RAM لا تجعل الاستدلال المعتمد بكثافة على وحدة المعالجة المركزية مكافئًا لتشغيل الموترات نفسها في ذاكرة وحدة معالجة الرسوميات ذات النطاق الترددي العالي.

بالنسبة إلى معظم مستخدمي الحواسيب المكتبية العاديين المهتمين بعائلة Qwen3.8، لا بهذه البنية تحديدًا، يُعد Qwen3.8-27B الهدف المحلي الأكثر تقليدية. ويكون Flash-Next منطقيًا أكثر للمستخدمين الذين يريدون عمدًا تجربة نموذج متناثر أكبر بكثير، أو ذاكرة غير متجانسة، أو بنية ذات سياق طويل، أو التقنية التي تقول Qwen إنها تستعرض اتجاه Qwen4.

هل يستحق Qwen3.8-Flash-Next التشغيل محليًا؟

نعم، لمحطة العمل المناسبة وللسبب المناسب—لكن ليس لأن «6 مليارات نشطة» تجعل إصدارًا يضم نحو 180 مليار معلمة يتصرف فجأة كنموذج صغير لحاسوب مكتبي.

يكتسب Flash-Next أهمية خاصة إذا كانت لديك ذاكرة نظام أو ذاكرة موحّدة بسعة 128–256 جيجابايت، وتسريع ملحوظ عبر وحدة معالجة الرسوميات، ووحدة تخزين NVMe سريعة، وسبب يدفعك إلى تجربة أعباء عمل محلية كبيرة للبرمجة أو متعددة الوسائط أو مكتبية أو قائمة على الوكلاء. وتُعد بنيته ملائمة على نحو استثنائي للذكاء الاصطناعي المحلي، لأنها تفصل عمدًا بين المعاملات التي تُحسب بشكل متكرر والهياكل الكبيرة الموجهة للسعة، والتي يمكن أن تعيش خارج ذاكرة وحدة معالجة الرسوميات.

إنه أقل ملاءمة بكثير لحاسوب عادي مزود بذاكرة RAM سعتها 32–64 جيجابايت، حيث تعتمد الخطة على جعل نظام التشغيل يجلب باستمرار صفحات النموذج المفقودة من SSD. قد يثبت هذا الجهاز أن النموذج يمكنه بدء التشغيل تقنيًا، لكن «يُحمَّل بنجاح» و«يعمل بشكل مفيد» معياران مختلفان.

الدرس الأوسع يتجاوز هذا الطراز. أصبحت عتاديات الذكاء الاصطناعي المحلية أقل اعتمادًا على طلب رقم واحد للحد الأدنى من ذاكرة VRAM، وأكثر اعتمادًا على تصميم تسلسل هرمي: ذاكرة VRAM للحوسبة عالية السرعة، وذاكرة RAM لسعة النماذج المتاحة، وذاكرة NVMe لتخزين النماذج والبيانات المحلية بشكل دائم. يجعل Qwen3.8-Flash-Next هذا التحول واضحًا على نحو استثنائي.

الأسئلة الشائعة: متطلبات العتاد المحلي لتشغيل Qwen3.8-Flash-Next

هل يمكن تشغيل Qwen3.8-Flash-Next على RTX 4090 أو RTX 5090؟

نعم، يمكن لوحدات معالجة الرسومات هذه المشاركة في نشر محلي هجين، لكن لا تستطيع لا بطاقة RTX 4090 بسعة 24 GB ولا RTX 5090 بسعة 32 GB استيعاب إصدار GGUF رباعي البتات الحالي من Flash-Next، الذي يبلغ حجمه نحو 94–111 GB، بالكامل في VRAM. ستحتاج إلى قدر كبير من ذاكرة النظام وإلى تفريغ الحمل إلى المعالج المركزي/وحدة معالجة الرسومات. ولا تزال وحدة معالجة الرسومات قادرة على تسريع الجزء الموضوع فيها من النموذج، لذا يختلف هذا كثيرًا عن القول إن البطاقات لا يمكن استخدامها.

هل يمكن تشغيل Qwen3.8-Flash-Next بذاكرة RAM سعتها 64GB؟

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

هل تكفي ذاكرة RAM بسعة 128GB لتشغيل Qwen3.8-Flash-Next؟

تُعد سعة 128 GB نقطة بداية معقولة لأحد إصدارات GGUF الأصغر بحجم يقارب أربعة بتات، عند دمجها مع تفريغ إلى وحدة معالجة الرسومات ونافذة سياق محافظة. لكنها ليست توصية عامة مريحة. يترك نموذج بحجم يقارب 94 GB مساحة أقل بكثير من 34 GB لنظام التشغيل، ومخازن بيئة التشغيل المؤقتة، وحالة السياق، ومعالجة الرؤية، والخدمات الأخرى؛ لذلك توفر سعة 192 GB أو أكثر هامشًا أكبر بكثير.

هل يمكن تشغيل Qwen3.8-Flash-Next بالكامل من قرص NVMe SSD؟

يمكن لبيئة التشغيل إجراء تخطيط للملفات النموذجية المخزنة على NVMe في الذاكرة، كما يمكن لنظام التشغيل جلب الصفحات عند الحاجة. لكن ذلك لا يعادل تشغيل النموذج «من SSD» بسرعات ذاكرة الوصول العشوائي أو وحدة معالجة الرسومات. يُعد NVMe ممتازًا لتخزين النماذج وتحميلها، لكن الاعتماد عليه باستمرار بسبب نفاد الذاكرة الفعلية قد يخفض أداء التوليد بشكل كبير.

هل يعني تفعيل 6B أن Qwen3.8-Flash-Next يعمل بسرعة نموذج بحجم 6B؟

لا. يصف رقم 6B العدد التقريبي للمعاملات المُفعّلة في النموذج الرئيسي لكل رمز. لا يزال لدى Flash-Next بنية أكبر بكثير، ومنطق توجيه، وحركة بيانات في الذاكرة، وبحث n-gram، وحالة انتباه متناثر، وغير ذلك من أعمال وقت التشغيل. قد تؤدي قلة المعاملات المُفعّلة إلى خفض الحوسبة بشكل كبير، لكنها لا تجعل النظام الكامل مكافئًا لنموذج كثيف بحجم 6B.

هل يمكن لـ Ollama أو llama.cpp تشغيل Qwen3.8-Flash-Next محليًا؟

دعم llama.cpp لـ Qwen3.8-Flash-Next qwen4exp تم دمج بنية architecture في master بتاريخ 27 أغسطس 2026، أي بعد يوم واحد من إصدار النموذج. كما توفر مستودعات GGUF المجتمعية الحالية إصدارات مخصصة لسير عمل الاستدلال المحلي المستند إلى llama.cpp. ونظرًا إلى أن التنفيذ لا يزال جديدًا جدًا، تحقّق من إصدارات بيئات التشغيل الحالية وتعليمات النموذج قبل افتراض أن كل واجهة خلفية لوحدة معالجة الرسومات، أو طول للسياق، أو مسار للرؤية، أو إعداد للتفريغ تتمتع بالدرجة نفسها من النضج.