Raft تحلل مواضع التأخير الزائد في MCP وThin MCP لدى وكلاء الذكاء الاصطناعي

كثيرًا ما يُقدَّم MCP بوصفه وسيلة شاملة لربط الأدوات بتطبيقات LLM بصورة منظمة، لكنه يفرض في الممارسة العملية ثمنًا لهذه الوحدوية (modularity) على شكل تأخير. وفي تحليل جديد، قارنت Raft بين عدة بنى معمارية، وبيّنت أن المشكلة لا تكمن عادةً في مكوّن واحد بعينه، بل في طريقة بناء مسار الطلب كله، من الوكيل إلى الأداة والعودة.

أين ينشأ التأخير (latency)

بدأ كاتب التحليل بسؤال أساسي: كم من التأخير يضيفه MCP نفسه إذا أزلنا الشبكة وأبقينا كل شيء داخل عملية واحدة؟ ولهذا قارن بين تطبيق متجانس (monolith) بلا MCP وآخر مع MCP داخل العملية (in-process). تبيّن أن النمط نفسه يضيف حملًا إضافيًا (overhead) صغيرًا نسبيًا: نحو 10–11 مللي ثانية في المتوسط، وأحيانًا حتى 35 مللي ثانية. وهذه نقطة انطلاق مهمة: فإذا كان الوكيل يتباطأ بمئات المللي ثانية، فالسبب عادةً ليس استخدام MCP في حد ذاته، بل الطبقة الخارجية المحيطة به.

بعد ذلك نُقلت المقارنة إلى بنية أقرب إلى الواقع، تُفصل فيها خوادم MCP في حاويات Docker مستقلة. هنا يتغير المشهد بوضوح: ارتفع متوسط التأخير الإضافي للأدوات الرئيسية إلى نحو 169 مللي ثانية لكل استدعاء. ومع ذلك أظهرت التتبّعات (traces) أن هذا ليس المستهلك الأكبر للوقت. فأثقل المراحل هي الحصول على التضمينات (embeddings) وعمل reranker، أما البحث في قاعدة البيانات المتجهية فيستغرق وقتًا قليلًا نسبيًا. وبعبارة أخرى، MCP يضيف كلفة، لكنه ليس دائمًا السبب الأكبر في بطء السلسلة بأكملها.

ماذا أظهرت الاختبارات

استعرض المقال عدة سيناريوهات لفصل تأثير النقل (transport) والتسلسل (serialization) والـ runtime نفسه بعضها عن بعض.

• S1، MCP داخل العملية (in-process): نحو 10–11 مللي ثانية من التأخير الإضافي، أي إن الـ runtime نفسه خفيف نسبيًا.
• S2، خوادم MCP منفصلة عبر شبكة Docker: متوسط overhead يبلغ نحو 169 مللي ثانية لكل استدعاء بسبب الشبكة والتسلسل والتفاعل بين العمليات.
• S3a، Thin MCP عبر HTTP + JSON: انخفض الـ overhead في سلسلة قياسات واحدة إلى نحو 128 مللي ثانية، لكن النتيجة جاءت غير مستقرة، وفي التشغيلات المتكررة قد تكون أسوأ بوضوح.
• S3b، Thin MCP عبر HTTP + YAML: ارتفع التأخير إلى نحو 274 مللي ثانية، ما يشير إلى كلفة إضافية للتسلسل وفك التسلسل (serialization/deserialization).
• S4 وS5: حقق ZeroMQ نحو 200 مللي ثانية، لكن بسلوك أكثر قابلية للتنبؤ، بينما خفّض C++ runtime الـ overhead إلى نحو 130–145 مللي ثانية دون تحوّل جذري في رتبة الحجم.

الخلاصة الرئيسية من هذه الأرقام أن التحسينات البديهية لا تعمل دائمًا كما نتوقع. فاستبدال JSON بـ YAML لم يُسرّع النظام، بل جعله أسوأ. والانتقال من HTTP إلى IPC لم يحقق مكسبًا تلقائيًا أيضًا: فتطبيق iceoryx2 لم يُظهر المكسب المتوقع، ولم يكن مفيدًا عمليًا إلا خيار ZeroMQ بفضل نموذجه غير المتزامن. وحتى C++ أفاد بصورة معتدلة، لا دراماتيكية.

لماذا لا يُنقذ Thin الموقف

يظهر Thin MCP في المقال لا بوصفه زر تسريع سحريًا، بل وسيلة لتبسيط البنية المعمارية. في هذا المخطط تبقى طبقة الـ proxy في حدها الأدنى، فتكتفي بترجمة الاستدعاءات، بينما تنتقل منطق الأعمال إلى خدمات HTTP مستقلة. ويمنح هذا النهج استقلالية عن اللغة، ويسهّل التوسّع (scaling)، ويتيح كتابة المنفّذات بـ Go أو Rust أو C++ حتى لو لم يتوفر لها بعد MCP SDK كامل.

Thin MCP أداة معمارية أكثر منه وسيلة لتحسين latency.

ثمة ملاحظة عملية هنا: قد يبدو نهج thin أسرع في تشغيل واحد، لكنه لا يتكرر بثبات في تشغيل آخر. وهذا حاسم لأي نظام إنتاجي: فأحيانًا لا تكون القيمة الدنيا لمرة واحدة في p95 هي الأهم، بل السلوك القابل للتنبؤ تحت حمل متكرر. لذلك تخلص Raft إلى استنتاج صارم لكنه مفيد: إذا أردنا فعلًا تسريع وكيل الذكاء الاصطناعي، فلا يكفي تغيير اللغة أو البروتوكول، بل يجب إعادة بناء مخطط التفاعل نفسه بين الـ proxy ومكوّنات الـ backend ومراحل الحوسبة الثقيلة.

ماذا يعني هذا

بالنسبة إلى الفرق التي تبني وكلاء الذكاء الاصطناعي، يمثّل هذا ترياقًا جيدًا ضد التحسين السطحي. فإذا كان النظام بطيئًا، فينبغي أولًا النظر في عدد الانتقالات بين المكوّنات، والعمليات الحاجبة (blocking)، ونموذج التنفيذ المتزامن، والمراحل الثقيلة مثل التضمينات وإعادة الترتيب (reranking). قد يجعل Thin MCP النظام أنظف وأكثر مرونة، وقد يمنح C++ أو IPC مكسبًا إضافيًا، لكن الأثر الحاسم لا يظهر إلا عندما تتوقف البنية المعمارية نفسها عن تمرير الطلب عبر طبقات زائدة.