PyTorch Blog: تعليم NVIDIA Dynamo التعامل مع جلسات وكلاء الذكاء الاصطناعي

تغيّر التطبيقات الوكيلية صورة الحمل الواقع على خادم الاستدلال. هذا ما تكتبه مدونة PyTorch في مادتها عن الاستدلال الموجّه بالجلسات على NVIDIA Dynamo. يعدّد الإعلان ثلاث سمات: prefill أولي كبير، واستدعاءات متكررة للنموذج داخل الجلسة الواحدة، ووكلاء فرعيون يعملون بالتوازي. كل سمة منها مألوفة للمهندسين على حدة، لكنها مجتمعة تكسر النموذج المعتاد «وصل الطلب، فخُدم الطلب».

لا تتضمن الجزء المتاح من المنشور أي اختبارات أداء (benchmarks)، لذلك لا نورد هنا أرقامًا محددة للتسريع. وفيما يلي عرض لما هو معروف عن المسألة وعن المنصة.

لماذا لا يشبه الوكيل المحادثة؟

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

إذا تعامل الخادم مع كل استدعاء على أنه مستقل، فإنه يعيد حساب البادئة نفسها مرة بعد مرة، أو يرسل الطلب إلى عقدة عمل (worker) لا يوجد عليها KV-cache المطلوب. وتزيد الوكلاء الفرعيون المتوازون المشكلة سوءًا: إذ تتشارك عدة فروع سياقًا واحدًا، لكنها تتباعد في المتابعة وتتنافس على ذاكرة GPU.

ماذا تفعل Dynamo هنا؟

NVIDIA Dynamo إطار عمل مفتوح المصدر للاستدلال الموزّع، قدّمته الشركة بوصفه خليفة Triton Inference Server. وتقوم على أفكار مهمة للوكلاء على وجه الخصوص: فصل prefill عن decode في مجموعات GPU مختلفة، والتوجيه بحسب محتوى KV-cache، ونقل الذاكرة المؤقتة من ذاكرة GPU إلى مستويات تخزين أرخص. وتعمل فوق محركات مثل vLLM وSGLang وTensorRT-LLM.

فكرة المنشور أن مفهوم الجلسة يُضاف إلى هذه الآليات. يعرف المجدول (scheduler) أن سلسلة الاستدعاءات تعود إلى وكيل واحد، ويمكنه إبقاء سياقها قرب موارد الحوسبة بدل تخمين التطابقات في كل طلب على حدة.

ما الذي يتغير بالنسبة إلى الخادم عند الانتقال من المحادثة إلى الوكيل:

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

ما الذي ينبغي فحصه في منظومتك؟

إذا كنت تشغّل وكلاء على نماذج خاصة بك، فابدأ بالقياس. انظر إلى النسبة التي تشكّلها البادئة المتكررة من الرموز (tokens)، وإلى عدد المرات التي يصل فيها الاستدعاء التالي من الجلسة إلى عقدة العمل نفسها. إذا كانت النسبة مرتفعة بينما إصابات الذاكرة المؤقتة (cache hits) قليلة، فأنت تدفع ثمن prefill زائد.

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

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

تفاصيل التنفيذ الكاملة والقياسات منشورة في المنشور الأصلي على PyTorch Blog. وقبل بناء أي استنتاجات في البنية المعمارية، ينبغي مطابقتها مع الأرقام الواردة في المصدر الأول.