NVIDIA Dynamo: إدارة الجلسات للبنية التحتية الخاصة بالاستدلال الوكيلي

أحمال العمل الوكيلية تُغيّر بنية الخدمة (serving)

غيّرت أحمال العمل الوكيلية بشكل جذري شكل حركة البيانات على خوادم الاستدلال. تبدأ الجلسة بعملية prefill ضخمة — غالباً عشرات آلاف من الرموز الخاصة بالتوجيهات النظامية، ووصف الأدوات، والتعليمات الخاصة بالمستخدم. وبعد أول استدعاء، يستقبل النموذج سياقاً مُلحَقاً تُعيد الجلسة إرساله كاملاً مع كل جولة جديدة.

ويكمن الاختلاف عن روبوت المحادثة في طريقة انتشار العمل: فمهمة واحدة تولّد استدعاءات متوازية متعددة للنموذج، ووكلاء فرعيين متوازيين ذوي عمر قصير أو طويل، وأدوات تُنفَّذ بين الجولات. ولا يُصرف الجزء الأكبر من زمن الجلسة الكلي على التوليد، بل على تنفيذ الأدوات والاستدعاءات الخارجية، في حين يبقى السياق مقيماً داخل ذاكرة KV cache، ويشغل حيزاً في ذاكرة HBM دون استخدام فعلي. ويتوقف الأداء الأمثل للخدمة على مقدار السياق الذي يحتفظ به النظام ويعيد استخدامه، وعلى عدد الجلسات التي يمكنه خدمتها في آنٍ واحد دون انتهاك اتفاقيات مستوى الخدمة (SLA) الخاصة بزمن الاستجابة.

معرّف الجلسة كعنصر أساسي موحّد للبنية التحتية المدركة للبرامج

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

يحتوي كل طلب ضمن مسار الوكيل على:

• session_id — معرّف فريد وثابت لسلسلة واحدة من الاستدلال واستدعاءات الأدوات • parent_session_id — معرّف الجلسة الأم (لتتبّع التسلسل الهرمي للوكلاء والوكلاء الفرعيين)

دعم مدمج لوكلاء الترميز (يعمل دون أي إعداد):

• يرسل Claude Code رأسي `x-claude-code-session-id` (للجلسات الجذرية) و`x-claude-code-agent-id` (للجلسات الفرعية) مع `x-claude-code-parent-agent-id` • يستخدم Codex `thread-id` و`x-codex-parent-thread-id` • يرسل OpenCode `x-opencode-session-id` و`x-opencode-parent-session-id`

إضافات لأدوات تشغيل أخرى (مستودع agent-plugins):

• مزوّد Pi — لنقطة النهاية المتوافقة مع OpenAI الخاصة بـ Dynamo • البرنامج الوسيط Hermes — يربط `session_id` الخاص بـ Hermes • مزوّد OpenClaw — يربط `sessionId` الخاص بـ OpenClaw

أدوات التشغيل المخصصة تحتاج فقط إلى إرسال `X-Dynamo-Session-ID` (واختيارياً `X-Dynamo-Parent-Session-ID`)، وتقوم Dynamo بتوحيدها في `agent_context` التي يقرأها المكدّس بأكمله.

التتبّع وإعادة التشغيل والاختبار الرجعي (backtesting)

مع تفعيل العلم `DYN_REQUEST_TRACE=1`، تسجّل Dynamo تلقائياً كل طلب دون تخزين التوجيهات أو الردود (يمكن تفعيل تخزينها بشكل منفصل). وعند انتهاء تدفّق الرد، يُصدَر سجل `request_end` يحتوي على:

• حقول الجلسة (session_id وparent_session_id) • عدد الرموز الناتجة وسبب إنهاء التوليد • مقاييس ذاكرة KV cache وأسماء الأدوات • كتلة إعادة تشغيل (replay) تضم طول الإدخال وتجزئات (hashes) التسلسلات (بصيغة مشابهة لـ Mooncake)

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

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

تُشغّل AISimulate رسم بياني للطلبات مقابل جدولة ومحرّك توجيه وذاكرة KV cache مُحاكاة لمقارنة العمال (workers)، والتوبولوجيات، وسياسات التوجيه، والسعة دون أي تكلفة فعلية على وحدات GPU. وتُعيد AIPerf تشغيل نفس الرسم البياني على نقطة نهاية فعلية للحصول على مقاييس نهائية لزمن الاستجابة والإنتاجية والتخزين المؤقت.

التوجيه المدرك للجلسات وإدارة سعة الإنتاجية

يتخذ محرّك التوجيه القياسي على مستوى الطلب (بما فيه KvRouter الجاهز) قراره بشأن مكان تنفيذ كل طلب على حدة: أي عامل (worker) يوفّر أكبر تداخل في ذاكرة التخزين المؤقت. وهذه هي الوحدة الصحيحة لجولة واحدة، لكنها غير صحيحة لوكيل يعمل في ظل تزامن مرتفع، لأنها تتجاهل عاملين:

• تضخّم شغل ذاكرة التخزين المؤقت: بين الجولات، لا تُحرَّر ذاكرة التخزين المؤقت للوكيل، بل تبقى في ذاكرة HBM، وتشغل كتلاً بينما يُنفّذ الوكيل أداة خارج وحدة GPU. فمع N من الوكلاء عند الخطوة k، يصبح مجموع حجم العمل التراكمي = N × context_k، في حين لا يرى محرّك التوجيه على مستوى الطلب إلا جولة واحدة. وحالما يتجاوز حجم العمل سعة HBM وDRAM، يُخلي المحرّك ذاكرة التخزين المؤقت للجلسات الحيّة، فتدفع كل جولة لاحقة ثمن إعادة prefill كاملة بدلاً من إصابة في ذاكرة التخزين المؤقت (cache hit).

• غياب آلية الضغط العكسي (backpressure): عندما يكون العامل محمّلاً بشكل مفرط، لا يمكن لمحرّك التوجيه على مستوى الطلب إلا إلغاء الطلبات قيد التنفيذ أو وضعها في قائمة انتظار — وكلا الخيارين أسوأ من البديل: تأجيل الجلسة عند نقطة التوقف، قبل جولتها التالية مباشرة، في اللحظة التي تكون فيها على وشك أن تصبح خاملة.

كيّفت Dynamo محرّك الجدولة المستمد من ورقة بحثية بعنوان ThunderAgent (Kang وآخرون، 2026) ليعمل فوق محرّك التوجيه المدرك لذاكرة KV. وهو مُنفَّذ بلغة Rust، ويملك KvRouter مباشرة، ويتتبّع العدد الفعلي لـ prompt_tokens + completion_tokens من كل رد بدلاً من تقديره انطلاقاً من البايتات الخام. وبوصفه إضافة أصلية (native plugin) لـ Dynamo، يمكن تكييف الكود المصدري بما يلائم شكل حِمل العمل الخاص بالمستخدم دون تعديل محرّك التوجيه الأساسي.