بقلم: سارة | محررة نماذج الذكاء الاصطناعي · صوت تحريري بإشراف بشري
من بيانات 3.2 مليون مستخدم و761 مليون استدعاء LLM و95 تريليون token جُمعت من GitHub Copilot خلال يونيو 2026، نشر باحثو مايكروسوفت أول توصيف إنتاجي شامل لأحمال العمل الخاصة بوكلاء البرمجة (وفقاً لبحث Microsoft Research). الخلاصة التقنية التي يقدمها هذا البحث ليست مجرد أرقام: إنها دليل على أن البنية التحتية الحالية لخدمة نماذج اللغة الكبيرة صُممت لشيء مختلف تماماً عما تفعله هذه الوكلاء اليوم.
وكلاء البرمجة مثل GitHub Copilot، وClaude Code، وCodex لا تعمل كمحادثات خطية. كل دورة يبدأها المستخدم تتفرع إلى حلقة استقلالية تتشابك فيها استدعاءات النموذج مع تنفيذ الأدوات بنسبة تكاد تكون 1:1 بين الاثنين. هذه البنية تنتج خصائص مختلفة جوهرياً عن chatbots التقليدية، وتطرح تحديات لم تأخذها الأنظمة القائمة في حسبانها.
أبرز ما كشفه البحث يتعلق بذاكرة KV cache، وهي العنصر المحوري في كفاءة خدمة النماذج. داخل الدورة الواحدة، تصل نسبة الإصابة في KV cache إلى 90% في المتوسط (وفقاً لـ Microsoft Research)، وهو معدل ممتاز يُظهر ترابطاً عالياً بين الاستدعاءات المتتالية ضمن الحلقة الاستقلالية. لكن هذه النسبة تنهار إلى 55% عند تجاوز حدود الدورة، أي بين ما يبدأه المستخدم من طلب والطلب التالي. والأشد تأثيراً هو أن أحداثاً بعينها تُمحو فعلياً كل ما هو مخزّن: التبديل بين النماذج، أو ما يُعرف بـ”context compaction”، وهو ضغط السياق عند امتلاء النافذة.
هذا التفاوت الحاد بين 90% داخل الدورة و55% بين الدورات يعني أن افتراض “إعادة الاستخدام العالية” الذي تبني عليه أنظمة التخزين المؤقت الحالية لا ينطبق بالتساوي على الوكلاء. السيناريو الذي تحرص الأنظمة على تحسينه — أي الطلبات المتكررة المتشابهة — ليس هو السيناريو السائد في هذا النوع من الأحمال.
البحث يشمل 13 مليون جلسة (وفقاً لـ Microsoft Research)، وتكشف التحليلات تنوعاً واسعاً في سلوك المستخدمين وأنماط الاستهلاك. استهلاك الـ tokens وعدد استدعاءات الأدوات ومدة الجلسة تتبع جميعها توزيعات ذات ذيول طويلة: معظم الجلسات قصيرة وبسيطة، لكن نسبة صغيرة منها ضخمة بشكل غير متوقع. هذا التوزيع يُعقّد التخطيط المسبق للموارد لأنه لا يمكن الاعتماد على متوسط معقول.
من أبرز الاكتشافات أيضاً الفجوة الزمنية بين سرعة استجابة الوكيل وفترات خمول المستخدم. الوكيل ينجز دورته بسرعة، ثم ينتظر. فترات الانتظار هذه عند حدود الدورات تمتد لدقائق في حالات كثيرة. استثمار هذا الوقت مسبقاً — بدلاً من إبقاء الموارد محجوزة بلا عمل — هو فرصة واضحة لتحسين الكفاءة. الباحثون صمموا “مؤشر خمول خفيف الوزن” يستطيع التنبؤ بهذه الفترات، ويلتقط 86 إلى 90% من إجمالي وقت الخمول (وفقاً لـ Microsoft Research)، مما يفتح الباب لقرارات استباقية في إدارة الموارد.
الدلالة الجوهرية لهذا البحث تتجاوز GitHub Copilot. أنظمة خدمة النماذج — كيفية تخصيص ذاكرة KV cache، وجدولة الطلبات، وتوزيع الحمل — بُنيت أساساً حول نموذج chatbot: طلب واحد، رد واحد، سياق يبنى خطياً. وكلاء البرمجة يكسرون هذا النموذج لأنها تُولّد حلقات استدعاء متشعبة، تستخدم أدوات خارجية، وتتخللها فترات خمول غير منتظمة. البنية التحتية التي تخدم الوكلاء بكفاءة تحتاج إلى إعادة تصميم من الأساس، لا مجرد ضبط في المعاملات.
ما يجعل هذا البحث مرجعاً تقنياً فعلياً هو أنه يستند إلى بيانات إنتاجية حقيقية، لا إلى اختبارات مُعدّة. أرقام بحجم 95 تريليون token من 3.2 مليون مستخدم نشط تعطي صورة لا تستطيع أي بيئة تجريبية أن تُنتجها. وهذا تحديداً ما يجعل استنتاجاته ذات ثقل عملي لأي فريق يبني بنية تحتية لخدمة وكلاء البرمجة، سواء كان يعمل على مستوى مايكروسوفت أو يُشغّل نماذج على نطاق أصغر. إذا كنت تبني نظام خدمة LLM يدعم وكلاء، فالأرقام هنا يجب أن تغيّر كيف تصمم التخزين المؤقت وكيف تجدول الطلبات.
