Michael Johnsonمنذ 3 نوفمبر 2026، بات بإمكان مسؤولي المؤسسات والشركات الاطلاع على استخدام المفاتيح الخاصة والنماذج المؤسسية كلًّا على حدة في تقارير GitHub Copilot. ويساعد تحديث واجهة Copilot usage metrics API على التمييز بين الطلبات الموجّهة إلى النماذج المستضافة لدى GitHub وبين الاستخدام عبر BYOK — أي «أحضر مفتاحك الخاص» — أو عبر نموذج تضبطه المؤسسة.
يمثل هذا تغييرًا عمليًا في المحاسبة لدى الشركات: إذ يمكن فصل تكاليف المزوّد الخارجي والتشغيل المحلي عن استخدام النماذج التي تستضيفها GitHub. ويحصل المديرون والمسؤولون على صورة أنسب للرقابة عن أساليب استخدام الذكاء الاصطناعي في الفرق. وتوضح GitHub أن الحقول الجديدة تفصل BYOK عن المؤشرات الإجمالية الحالية من دون تغيير العدادات نفسها.
حالات الاستخدام التي تعرضها الواجهة كلًّا على حدة
تقسم GitHub BYOK إلى حالتين. في حالة BYOK المحلي، يضبط المطوّر مفتاحه الخاص أو نموذجًا محليًا في Copilot CLI أو تطبيق GitHub Copilot، ويُرسل الطلب مباشرةً إلى المزوّد أو الخادم المحلي. وقد أُضيف لهذه الطلبات حقل المستخدم used_local_byok، والمؤشرات المجمّعة totals_by_local_byok، فضلًا عن عدادات المستخدمين النشطين الذين يستخدمون BYOK المحلي.
تذكر GitHub ضمن النماذج والأدوات المحلية Ollama وFoundry Local وLM Studio وllama-server. وتخص حقول تفصيل BYOK المحلي الجديدة Copilot CLI وتطبيق Copilot؛ فهي تقسّم الجلسات والطلبات والمطالبات والرموز بحسب نوع BYOK وواجهة الاستخدام، إذا أرسل المزوّد البيانات المناسبة. ولا يُصنّف استخدام BYOK المحلي بحسب اسم النموذج، لذا يعرض التقرير حدوث هذا النشاط وحجمه، لا اسم النموذج المحلي بعينه.
أما الحالة الثانية فهي نموذج مخصص للمؤسسة يحدده المسؤول في إعدادات المؤسسة أو الشركة، وتُوجَّه الطلبات عبر GitHub إلى المزوّد. وقد أضافت GitHub الحقل المنطقي is_custom_enterprise_model إلى سجلات النماذج ضمن totals_by_client. وبما أن هذه الطلبات تُرصَد على مستوى الخادم، يشمل الحقل عملاء مختلفين، بما في ذلك بيئات التطوير المتكاملة.
ما الذي سيتغير في التعامل مع التقارير
في السابق، كان من الممكن أن يختلط استخدام BYOK بمؤشرات نماذج Copilot المستضافة، ولا سيما عندما تتشابه أسماء النماذج. وتتيح الحقول الجديدة فصل هذه الفئات عند مراجعة السياسات الداخلية وتحليل الاستخدام. وتشير GitHub إلى أن البيانات متاحة لتقاريري اليوم الواحد و28 يومًا، على مستوى المستخدم وفي المؤشرات المجمّعة للمؤسسة أو الشركة.
يُستحسن أن يبدأ المسؤول بتحديد السؤال الذي ينبغي للتقرير الإجابة عنه: من يستخدم مفتاحه الخاص؟ وما حصة الطلبات الموجّهة إلى النماذج المحلية؟ وإلى أي مدى يؤثر ذلك في تقدير التكاليف؟ بعد ذلك، يمكن مقارنة الحقول الجديدة بالمؤشرات الحالية والسياسات الداخلية الخاصة بـ BYOK. ويوفر هذا أساسًا ملموسًا للنقاش حول اختيار النماذج والدفع، أفضل من عدّاد عام لنشاط Copilot.
يعتمد الوصول إلى المقاييس على دور المستخدم: فالواجهة مخصصة لمالكي الشركات، ومديري الفوترة فيها، ومالكي المؤسسات، والمستخدمين الذين يملكون صلاحية View Copilot Metrics. ويجب أيضًا تفعيل سياسة استخدام مقاييس Copilot. وتُظهر هذه البيانات النشاط المسجل، لا جودة الإجابات أو مدى ملاءمة النموذج لمهمة بعينها.
لماذا تختلف دقة المؤشرين الجديدين
لـ BYOK المحلي حدّ واضح في طريقة احتسابه: تحسب GitHub حقوله بالاستناد إلى بيانات القياس عن بُعد من العميل. وإذا عُطّلت هذه البيانات، فسيكون عدد الطلبات أقل من العدد الفعلي؛ كما أن بعض المزوّدين المحليين لا يبلّغون عن عدد الرموز. لذلك تفيد هذه البيانات في رصد الاستخدام وتقدير حجمه، لكنها لا تكفي وحدها للتسوية المالية الدقيقة.
أما النماذج المخصصة للمؤسسات فتُحتسب على مستوى الخادم، وتقول GitHub إنها لا تتأثر بهذا القيد المتعلق ببيانات القياس عن بُعد. وقد يظهر النموذج نفسه في سطرين منفصلين إذا استُخدم نموذجًا مستضافًا من Copilot ونموذجًا مخصصًا للمؤسسة. ويمنع هذا الفصل دمج قناتين مختلفتين لمجرد تطابق اسميهما.
وهناك قيد زمني أيضًا: لا تضيف GitHub الحقل is_custom_enterprise_model إلى تقارير الأيام السابقة لإصدار التحديث. لذا لا يمكن افتراض قابلية مقارنة البيانات التاريخية بالفئات الجديدة تلقائيًا؛ وينبغي تسجيل تاريخ الانتقال ومقارنة الفترات مع مراعاة تغيير بنية البيانات.
يساعد التحديث المؤسسات على تصنيف استخدام Copilot مع النماذج الخاصة أو المحلية بدقة أكبر. لكن إعداد الميزانية لـ BYOK المحلي يظل يتطلب أخذ النقص في بيانات القياس عن بُعد من العميل وبيانات المزوّد في الحسبان، فيما بات للنماذج المخصصة للمؤسسات مؤشر منفصل على مستوى الخادم في التقرير.
