لماذا تفصل أنظمة الاستدلال الحديثة مرحلتي Prefill و Decode على معالجات رسومية مختلفة

أبرز النقاط

• مرحلة Prefill تستهلك قدرة الحوسبة، بينما Decode تستهلك عرض نطاق الذاكرة — فصلهما يوقف التداخل
• أنظمة إنتاجية مثل Mooncake من Moonshot AI و DeepSeek و NVIDIA Dynamo تعتمد هذه البنية فعلياً
• الفصل يضيف تعقيداً تشغيلياً ونقل KV Cache عبر الشبكة، لذا لا يناسب كل حالة استخدام

عندما ترسل طلباً إلى نموذج لغوي كبير مثل GPT-4 أو Claude أو Llama، يحدث أمران متتاليان: أولاً يقرأ النموذج كامل المحادثة السابقة ويعالجها دفعة واحدة (مرحلة Prefill)، ثم يبدأ بتوليد الردّ كلمة بكلمة (مرحلة Decode). حتى وقت قريب، كانت معظم الفرق تُشغّل المرحلتين على نفس وحدة معالجة الرسومات GPU، وهو ما يشبه أن تطلب من طاهٍ واحد تقطيع الخضار لوجبة ضخمة وتقديم الأطباق الجاهزة للزبائن في الوقت ذاته — كل عملية تقطيع كبيرة تُبطئ كل طبق ينتظر.

هذا النمط بدأ يتغيّر. أنظمة الاستدلال الأكثر تطوراً في الإنتاج اليوم — من Moonshot AI و DeepSeek وداخل حزمة NVIDIA Dynamo — اتخذت قراراً استراتيجياً بفصل المرحلتين على عتاد منفصل فعلياً. هذا المقال يشرح السبب، وآلية العمل، ومتى لا يستحق الأمر هذا التعقيد.

ما الفرق بين مرحلتي Prefill و Decode؟

مرحلة Prefill تحدث حين يقرأ النموذج مُدخلك الكامل. يعالج كل الرموز (tokens) دفعة واحدة، بالتوازي، في موجة ضخمة من عمليات المصفوفات. وحدات GPU تتألق هنا؛ هذا بالضبط ما صُمّمت له. نوى الحوسبة تعمل بأقصى طاقتها، نظام الذاكرة بالكاد يُجهَد، والمهمة تنتهي بسرعة نسبية مقارنة بحجمها.

مرحلة Decode تحدث حين يكتب النموذج إجابته. يولّد رمزاً واحداً في كل خطوة، ولكل رمز جديد على GPU إعادة قراءة كمية هائلة من البيانات المخزّنة: أوزان النموذج، بالإضافة إلى كل ما يتذكره عن المحادثة حتى الآن (ما يُعرف بـ KV Cache). الحوسبة لكل رمز صغيرة، لكن معظم الوقت يُهدر في نقل البيانات من الذاكرة وإليها، بينما نوى الحوسبة تجلس شبه خاملة.

لماذا يتنافس Prefill و Decode على موارد متعاكسة؟

المرحلتان تريدان شيئين مختلفين تماماً من العتاد. Prefill تتعطّش للحوسبة (FLOPS)، بينما Decode تتعطّش لعرض نطاق الذاكرة (memory bandwidth). حين تُشغّلهما على نفس GPU، يحدث تداخل: طلب طويل في مرحلة Prefill يحتجز الموارد ويُبطئ توليد الرموز لكل المستخدمين الآخرين الذين ينتظرون ردودهم.

محركات الاستدلال الحديثة تجمع طلبات عدة مستخدمين معاً على نفس مجموعة GPU لتحسين الكفاءة. لكن هذا التجميع يزيد التداخل: مستخدم أرسل مستنداً من 50 ألف رمز يُبطئ عشرات المستخدمين الذين ينتظرون جملة واحدة. الفصل يحلّ هذه المشكلة بتخصيص كل مرحلة لعتاد مُحسَّن لها.

كيف يعمل فصل Prefill/Decode عملياً؟

بنية Prefill/Decode Disaggregation تعني ببساطة تشغيل كل مرحلة على مجموعة GPU منفصلة. مجموعة Prefill تتلقى الطلبات الجديدة، تعالج المُدخل الكامل، ثم تُنشئ KV Cache — وهو تمثيل مضغوط لكل ما فهمه النموذج عن المحادثة. هذا الـ KV Cache يُنقل عبر الشبكة إلى مجموعة Decode، التي تتولى توليد الرد رمزاً برمز.

• مجموعة Prefill: وحدات GPU عالية الحوسبة (مثل H100) تعالج المُدخلات الطويلة بالتوازي
• مجموعة Decode: وحدات GPU عالية عرض نطاق الذاكرة (مثل H200) تولّد الرموز بكفاءة
• طبقة شبكية: تنقل KV Cache بين المجموعتين بأقل زمن تأخير ممكن

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

من يستخدم هذه البنية في الإنتاج اليوم؟

ثلاثة أنظمة بارزة تعتمد Prefill/Decode Disaggregation في بيئات إنتاجية فعلية:

• Mooncake من Moonshot AI: نظام استدلال مفتوح المصدر صُمّم من الأساس لفصل المرحلتين
• DeepSeek: عناقيد الاستدلال الداخلية لديهم تفصل Prefill و Decode على عتاد مختلف
• NVIDIA Dynamo: إطار عمل جديد من NVIDIA يدعم هذه البنية كخيار أساسي

على عتاد DigitalOcean، يُترجم الفصل إلى مجموعات H100 لمرحلة Prefill ومجموعات H200 لمرحلة Decode، مستفيداً من الفوارق في مواصفات كل جيل.

متى يستحق الفصل هذا التعقيد؟

ليس كل نظام يحتاج هذه البنية. ثلاث إشارات تُحدد ما إذا كان الفصل يستحق الاستثمار:

• مُدخلات طويلة ومتفاوتة: إذا كان متوسط طول المُدخل قصيراً وثابتاً، التداخل محدود ولا يستحق التعقيد
• حساسية عالية لزمن أول رمز (Time-to-First-Token): إذا كان المستخدمون يتحملون ثانية أو ثانيتين انتظار، الفصل قد يكون مبالغة
• حجم طلبات كبير: الفصل يتطلب عتاداً مضاعفاً، فلا يجدي إلا حين يكون حجم الطلبات كافياً لملء كلتا المجموعتين

إذا كنت تُشغّل تطبيقاً داخلياً بعشرات المستخدمين ومُدخلات قصيرة، GPU واحدة مع محرك استدلال جيد مثل vLLM أو TensorRT-LLM تكفي. الفصل يتألق حين تخدم آلاف المستخدمين المتزامنين بمُدخلات متفاوتة الطول.

هل يُغني الفصل عن تحسينات الاستدلال الأخرى؟

بالتأكيد لا. Prefill/Decode Disaggregation هو تحسين واحد ضمن منظومة كاملة. تقنيات مثل Continuous Batching و PagedAttention و Speculative Decoding تظل ضرورية. الفصل لا يُلغي الحاجة لها، بل يُكمّلها بحلّ مشكلة التداخل بين المرحلتين التي لا تستطيع هذه التقنيات حلّها وحدها.

الأسئلة الشائعة

ما هو KV Cache ولماذا يُنقل بين مجموعتي GPU؟

KV Cache هو تمثيل مضغوط لكل ما فهمه النموذج عن المحادثة أثناء مرحلة Prefill. عند فصل المرحلتين، يجب نقله عبر الشبكة لأن مجموعة Decode تحتاجه لتوليد الرموز التالية دون إعادة معالجة المُدخل.

هل يمكن تطبيق Prefill/Decode Disaggregation على أي نموذج LLM؟

نظرياً نعم، لكن عملياً يتطلب دعماً من إطار الاستدلال. أطر مثل NVIDIA Dynamo و Mooncake تدعمه مباشرة، بينما أطر أخرى قد تحتاج تعديلات.

ما الفرق بين H100 و H200 في سياق هذه البنية؟

H100 تتفوق في الحوسبة الخام (FLOPS) مما يجعلها مثالية لـ Prefill. H200 تضيف ذاكرة HBM3e أكبر وعرض نطاق أعلى، مما يجعلها أنسب لـ Decode حيث نقل البيانات هو العائق.

ما البدائل إذا كان الفصل معقداً جداً لفريقي؟

vLLM مع Continuous Batching يوفر أداءً ممتازاً على GPU واحدة أو عدة وحدات دون تعقيد الفصل. للفرق الأصغر، خدمات الاستدلال المُدارة مثل Amazon Bedrock أو Azure OpenAI تُخفي هذا التعقيد تماماً.