خمس حيل لتسريع نماذج MoE على GTX 1070: البادئة التلقائية تخفض زمن الاستجابة من 13.3 إلى 6.1 ثانية

إذا كنت تحاول تشغيل نموذج MoE كبير على بطاقة رسوميات منزلية، فإن العائق ليس الحوسبة بل الذاكرة. أوزان الخبراء لا تتسع في VRAM، فيذهب جزء منها إلى RAM وإلى SSD، وكل وصول إلى خبير «بارد» يكلّف ميلي ثوانٍ ثمينة. جمع مطوّر محرك Strata، الذي يشغّل Qwen3.8-Flash-Next على GTX 1070 بذاكرة 8 غيغابايت، خمس حيل تساعد في التغلب على ذلك. أربع منها مدمجة أصلًا في المحرك، أما الخامسة فكتبها بنفسه وعرض قياساتها.

أربع حيل موجودة أصلًا في المحرك

الأولى هي فك الترميز التخميني (--spec N --mtp <المسار>). تتنبأ طبقة مسودة صغيرة بعدة رموز مسبقًا، ويتحقق النموذج الكبير منها في تمريرة واحدة. فإذا أصابت المسودة، تحصل على عدة رموز بثمن رمز واحد. يبلغ المكسب عادةً 1.3 إلى 1.6 ضعف. تُحسن المسودة تخمين الشيفرة البرمجية والأنماط المتكررة، وتكون أضعف مع النثر الحر. والثمن قدر قليل من VRAM لطبقة المسودة والمخازن المؤقتة.

الثانية هي --kv-resident N. يبقى في VRAM فقط نافذة انتباه منزلقة بطول N رمزًا، بينما تنتقل ذاكرة KV كلها إلى ذاكرة RAM المثبّتة (pinned). الانتباه نفسه لا يتسارع بذلك. المكسب في مكان آخر: الذاكرة المحرَّرة تذهب إلى ذاكرة الخبراء المؤقتة. وفي نماذج MoE يكون غيغابايت إضافي للخبراء المقيمين أنفع عادةً من التوفير في KV. والتحقق سهل: قارن نسبة الإصابات في expert cache في السجل قبل التفعيل وبعده.

الثالثة هي التجميع الدفعي (--batch، --parallel). إنه continuous batching: تُفك شيفرة عدة محادثات في نوافذ مشتركة، وتُقرأ الأوزان المشتركة مرة واحدة للجميع. على بطاقة واحدة ينخفض الإنتاج (throughput) لكل مستخدم قليلًا. لكن في المقابل لا ينتظر أحد في الطابور بينما يُخدَّم جاره. وإذا كان لديك عدة وحدات GPU بنمط layer-split أو وكلاء متوازون، فراجع docs/BATCHING.md.

الرابعة هي الإقامة التكيفية للخبراء (--adapt-every، --adapt-swaps). تنقل الذاكرة المؤقتة الأوزان بنفسها بين VRAM وRAM وSSD بحسب تكرار الوصول، أثناء التوليد مباشرة. وبحسب قياسات المطوّر، تراوح الفرق بين الذاكرة الثابتة و«الحيّة» بين 1.5 و2 ضعف، تبعًا لمدى تجانس سيل الأوامر (prompts).

الحيلة الخامسة: البادئة المشتركة التلقائية

يملك Strata آلية strata_prefix: يحدد العميل صراحةً أين ينتهي الجزء المشترك من الأمر، فيحفظ المحرك نقطة تحقق عند هذا الحد. والطلبات اللاحقة التي تبدأ بالمطلع نفسه لا تعيد قراءته. المشكلة أن أي عميل تقريبًا، لا روبوت دردشة ولا إطار عمل للوكلاء، لا يفعل ذلك.

أضاف المطوّر طبقة على جانب الخادم (STRATA_AUTO_PREFIX=1، وهي معطّلة افتراضيًا). تحتفظ هذه الطبقة بشجرة radix-trie على معرّفات رموز الأوامر الأخيرة، وتدير ميزانية لعدد «الدبابيس» (pins) المتزامنة. كل دبوس يأخذ VRAM من ذاكرة الخبراء، فلا توجد دبابيس مجانية. وإذا وصل طلب بلا بادئة صريحة، يجد الخادم التطابق بنفسه ويضع الحد. ولا يلاحظ المحرك أي فرق.

القياس: Strata 0.2.12، بطاقة GTX 1070 واحدة بذاكرة 8 غيغابايت، وQwen3.8-Flash-Next UD-IQ4_XS، وعميلان بوثيقة طويلة واحدة.

• وسيط الرموز المُعاد قراءتها: 886 ← 468.
• وسيط الرموز المأخوذة من الذاكرة المؤقتة: 0 ← 413.
• وسيط الزمن حتى الرمز الأول: 13.3 ثانية ← 6.1 ثانية.

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

القيود وما يجب فعله

أولًا التحفظات. جميع الأرقام مأخوذة من إعداد واحد وسيناريو واحد بعميلين، ويعتمد مكسب البادئة التلقائية على مقدار المطلع المشترك بين طلباتك. التصحيح موجود في فرع من نسخة مشتقة (fork) ولم يُقبل في المصدر الأصلي (upstream). فتح المطوّر issue بدلًا من PR لأن CONTRIBUTING.md يشترط الاتفاق أولًا على النطاق. وتتنافس الدبابيس مع ذاكرة الخبراء على VRAM، لذا سيتعين ضبط الميزانية.

والترتيب العملي كالتالي. إذا كان لديك MoE على بطاقة متواضعة، فابدأ بـ --kv-resident و--spec/--mtp: هذا أسرع مكسب دون سطر برمجي واحد. ثم تأكد من تفعيل تكيّف الخبراء. وإذا كنت تعمل بـ RAG أو بوكلاء بأمر نظام مشترك طويل، فجرّب البادئة التلقائية على حركة بياناتك. والدرس الأهم أوسع من محرك واحد: ففي ظل VRAM محدودة يؤول أي تحسين تقريبًا إلى سؤال: فيمَ ننفق كل غيغابايت؟ ويجب التحقق من ذلك بالقياس لا بالحدس.