أصدرت شركة Moonshot AI هذا الأسبوع تحديثاً جديداً ضمن عائلة نماذج البرمجة الخاصة بها يحمل اسم Kimi K2.7-Code، في خطوة تستهدف تحسين كفاءة الاستدلال وتقليل الكلفة التشغيلية لدى الفرق التي تعتمد على النماذج اللغوية في مهام البرمجة الوكيلية وأتمتة العمل البرمجي.
وتقول الشركة إن الإصدار الجديد يعتمد على البنية نفسها تقريباً التي قام عليها K2.6، وهي بنية mixture-of-experts ضخمة تصل إلى تريليون معامل تقريباً، مع إمكانية التشغيل عبر واجهة متوافقة مع OpenAI. هذه النقطة تجعل التحديث عملياً بالنسبة للجهات التي تستخدم K2.6 بالفعل داخل بوابات إنتاجية أو أنظمة تنسيق النماذج.
لكن الجدل حول K2.7-Code لا يقتصر على ما تعد به Moonshot AI من تحسينات، بل يمتد إلى السؤال التقليدي في سوق الذكاء الاصطناعي: هل تعكس أرقام الشركة نفسها الأداء الحقيقي خارج مختبرات المطور؟
ما الذي يقدمه Kimi K2.7-Code
النموذج الجديد متاح بترخيص Modified MIT، مع إتاحة الأوزان على HuggingFace، ويمكن نشره عبر أدوات مثل vLLM وSGLang. ويعمل K2.7-Code في وضع التفكير فقط، من دون دعم لتغيير درجة الحرارة، إذ ثبّتته الشركة عند 1.0. هذا يعني أن فرق التطوير لا تستطيع ضبط مستوى الحتمية بالطريقة المعتادة مع بعض النماذج الأخرى.
وتقول Moonshot AI إن التغيير الأهم يتمثل في الطريقة التي ينتج بها النموذج الشيفرة على المستوى المنخفض. فبدلاً من الاعتماد على تغليف المكتبات الجاهزة أو تمرير التنفيذ عبر أطر برمجية قائمة، أصبح النموذج يكتب التطبيقات بصورة مباشرة. ووفق الشركة، ينعكس ذلك على قدرة أفضل في التعميم عبر Rust وGo وPython، وكذلك في سيناريوهات مثل تطوير الواجهات الأمامية، وعمليات DevOps، وتحسين الأداء.
من الناحية التشغيلية، يبدو هذا التحول مهماً للمؤسسات التي تبحث عن نموذج لا يكتفي بكتابة أجزاء من الكود، بل يفهم السياق ويولد التنفيذ بشكل أقرب إلى بنية المشروع الحقيقية. ومع ذلك، يبقى الاختبار العملي هو المعيار الحاسم في قرارات النشر والتوجيه داخل البنى الإنتاجية.
وعد بخفض tokens التفكير بنسبة 30%
أبرز ما تروّج له الشركة في هذا الإصدار هو خفض استخدام tokens التفكير بنسبة 30% مقارنةً بـ K2.6. ويعني ذلك، من منظور الأعمال، استهلاكاً أقل لقدرة المعالجة وتكلفة أدنى للاستدلال، خصوصاً في workflows تعتمد على وكلاء ذكاء اصطناعي ينفذون مهام متتابعة أو طويلة نسبياً.
في سوق تتزايد فيه حساسية التكاليف مع ارتفاع حجم الاستخدام، يمكن لمثل هذا الخفض أن يكون مؤثراً جداً. فكل تقليص في tokens التفكير قد ينعكس على فاتورة الاستدلال، وعلى سرعة الاستجابة، وعلى قابلية تشغيل النموذج على نطاق واسع. لكن هذه الفائدة، رغم أهميتها، لا تصبح ذات قيمة كاملة إلا إذا ثبتت تحت أحمال عمل واقعية وليس فقط داخل اختبارات الشركة.
ولهذا السبب، ينظر كثير من الفرق التقنية إلى مؤشرات الكفاءة باعتبارها بداية التقييم لا نهايته. فالنموذج الذي يبدو أكثر اقتصاداً على الورق قد يختلف أداؤه حين يدخل في بيئات فيها ضوضاء بيانات، أو طلبات متداخلة، أو مهام تحتاج إلى قرارات طويلة السلسلة.
مقاييس الشركة مقابل الاختبارات المستقلة
تقول Moonshot AI إن K2.7-Code حقق تحسينات ملحوظة على مقاييسها الداخلية، من بينها زيادة 21.8% على Kimi Code Bench v2، و11% على Program Bench، و31.5% على MLS Bench Lite. غير أن هذه النتائج تستند إلى مقاييس مملوكة للشركة نفسها، وهو ما يحد من قدرتها على تقديم صورة نهائية عن مستوى النموذج مقارنة بالمنافسين.
المشكلة هنا ليست في وجود benchmark داخلي، بل في اعتماده وحده لتأكيد التفوق. فالمجتمع التقني غالباً ما يطالب باختبارات مستقلة يمكن مقارنتها عبر نماذج مختلفة وبمعايير أكثر شفافية. وفي هذه الحالة، لم يُعرض K2.7-Code بعد على DeepSWE، وهو معيار مستقل في البرمجة يُنظر إليه على أنه أكثر تمييزاً بين النماذج من بعض المقاييس الأخرى.
وتزداد أهمية هذه النقطة لأن بعض الباحثين والمطورين بدأوا بالفعل في اختبار النموذج خارج إطار الشركة. ومن بين الملاحظات الأولية المتداولة أن التحسن في السلوك لا يعني بالضرورة قفزة مماثلة في القدرة. بعبارة أخرى، قد يصبح النموذج أكثر التزاماً بطريقة كتابة الكود، لكنه لا يضمن تلقائياً نتائج أقوى في كل فئة من المهام.
قراءات أولية من المجتمع التقني
أحد الباحثين اختبر K2.7-Code إلى جانب K2.6 ونموذج آخر منافس على KernelBench-Hard، وهو معيار عام يركز على تحسين kernel الخاصة بالـ GPU. ووفق ما نُشر من سجلات التشغيل، أنتج K2.7-Code في معظم المهام شيفرة فعلية كتبها بنفسه بدلاً من الاعتماد على طبقات تغليف، وهو ما اعتبره البعض تقدماً في الصراحة التقنية.
لكن هذا التقدم لم ينعكس بالضرورة على النتائج النهائية. ففي بعض الحالات فشلت النوى التي أنشأها النموذج بسبب أخطاء داخلية، كما تراجع أداء النموذج في إحدى مسائل MoE مقارنة بالإصدار السابق. هذا النوع من النتائج يوضح الفارق بين أن يكون النموذج أكثر مباشرة في التوليد، وبين أن يكون بالفعل أفضل في الإنجاز.
كما ظهرت اعتراضات أخرى من مطورين يعملون على توجيه النماذج داخل منصات الوكلاء، إذ أشار بعضهم إلى أن كل نموذج تقريباً يبدو أفضل عندما يُقاس على مجموعات الاختبار الخاصة به. وفي بيئة تعتمد على routers ذكية لتوزيع المهام بين النماذج، تصبح المقارنة على أساس مستقل أمراً بالغ الأهمية قبل تغيير أوزان التوجيه أو اعتماد النموذج في الإنتاج.
ماذا يعني ذلك للشركات والمؤسسات
بالنسبة للمؤسسات التي تشغل K2.6 حالياً، تمنح Moonshot AI مسار ترقية يبدو منخفض المخاطر من ناحية التكامل، لأن الانتقال إلى K2.7-Code لا يتطلب تغييراً جذرياً في البنية أو البوابات البرمجية. وهذا يمنح فرق المنصات مجالاً لاختبار النموذج على بياناتها وأعبائها الخاصة، ثم مقارنة الكلفة والجودة قبل اتخاذ قرار أوسع.
الأرجح أن الفرق التقنية ستتعامل مع الإصدار الجديد على أنه خيار يستحق التجربة أكثر من كونه حُكماً نهائياً على تفوق عائلة Kimi. فإذا ثبتت مزاعم خفض الاستدلال وظهرت نتائج متماسكة على مهام المؤسسة نفسها، فقد يصبح K2.7-Code مرشحاً عملياً في بعض مسارات البرمجة المؤتمتة. أما إذا لم تتكرر النتائج خارج الاختبارات الخاصة، فقد يبقى التحديث مهماً من ناحية الهندسة لكنه محدود الأثر تجارياً.
وفي سوق الذكاء الاصطناعي الذي يتنافس فيه المطورون على خفض التكلفة ورفع الجودة في الوقت نفسه، يبدو K2.7-Code مثالاً جديداً على معادلة مألوفة: تحسينات لافتة في بيانات الشركة، وحكم نهائي لا يزال معلقاً حتى تظهر المقارنات المستقلة الأوسع.