كشفت JetBrains تفاصيل هندسية عن تشغيل الإصدار الأول من Junie Local محلياً على جهاز MacBook M5 باستخدام النموذج Qwen3.6-27B، موضحة أن الوصول إلى أداء عملي لم يكن نتيجة اختيار نموذج مضغوط فحسب، بل تطلب تعديلات على وكيل البرمجة نفسه، ومحرك الاستدلال، وإعدادات النموذج، وطريقة إدارة السياق.
وتقول الشركة إن مشروع تشغيل Junie بالكامل على الجهاز، من دون استدلال سحابي، هو مشروع طويل الأمد يستهدف مجموعة واسعة من تكوينات العتاد. أما الإصدار الأول المتاح حالياً فيركز على أجهزة MacBook M5، وهو ما يفسر تركيز التحسينات المعلنة على خصائص هذه الشرائح.
إبقاء سياق المهام داخل الجلسة
يعمل Junie، مثل وكلاء البرمجة الآخرين، عبر حلقة تنفيذ يرسل فيها المستخدم مهمة إلى النموذج، ثم ينفذ النموذج استدعاءات للأدوات مثل أوامر Bash وقراءة الملفات وكتابتها، قبل أن يعيد نتائج تلك العمليات إلى النموذج. ومع كل طلب جديد يتوسع السياق، ويمكن إعادة استخدام بيانات KV-cache التي عالجها النموذج في الطلب السابق.
في النماذج السحابية، يمكن للوكيل إعادة طلب ملف عند الحاجة لأن مرحلة prefill، أي معالجة السياق الأولي قبل توليد الرد، تكون سريعة نسبياً. لكن JetBrains وجدت أن قراءة الملفات مكلفة زمنياً في النماذج المحلية. لذلك عدّلت منطق الاستدلال المحلي بحيث يضيف كل طلب جديد مباشرة إلى السياق المتحرك، بدلاً من الاكتفاء بالأجزاء التي يراها ملائمة للمهمة الجديدة. وبهذه الطريقة يبقى الملف الذي قرأه النموذج داخل السياق، ويمكن إعادة استخدام ذاكرة KV-cache بدلاً من معالجته مرة أخرى.
كما غيّرت الشركة ترتيب البيانات التي يرسلها Junie عند بدء جلسة ترميز جديدة، وأضافت إلى محرك الاستدلال منطقاً لتخزين البادئة حتى طلب المستخدم. ونتيجة لذلك يمكن إعادة استخدام هذه البادئة في المهام اللاحقة داخل المشروع نفسه. أما سياق المشروع الذي يأتي بعد طلب المستخدم فلم يُخزّن بالطريقة ذاتها، لأنه صغير نسبياً ويتكون في الغالب من ملفات المستوى الأعلى التي قد تتغير كثيراً.
تعديلات مرتبطة بسلوك النموذج
لم يتعامل Qwen3.6 مع تحديثات التقدم بالطريقة التي يتوقعها Junie من النماذج السحابية؛ إذ كان يتجاهل غالباً الكتلة الخاصة بتحديثات الحالة بصيغة شبيهة بـ XML، لكنه كان يكتب وصفاً نصياً لأفعاله إلى جانب استدعاءات الأدوات. استغلت JetBrains هذا السلوك وعرضت النص الناتج بوصفه تحديثاً للمستخدم. وتوضح الشركة أن هذا التكيف خاص بالنموذج، إذ قد لا تطبع نماذج أخرى أي نص، أو قد تنتج نصاً مفرطاً.
وعطّلت JetBrains أيضاً طلبات اختيارية من النموذج، من بينها المنطق الذي ينشئ وصفاً قصيراً للمهمة. وترى الشركة أن التنازل المحدود في تجربة الاستخدام مقبول مقابل تقليل الطلبات. كما أوقفت وضع الوكلاء المتعددين، لأن المعالجة المتسلسلة أكثر كفاءة على جهاز M5 وفق اختباراتها، بينما ستظل الطلبات المتوازية مقيدة بسرعة الاستدلال.
لماذا اختير Qwen3.6-27B؟
قررت JetBrains تعطيل reasoning بالكامل في النسخة المحلية. وبحسب اختباراتها الداخلية للنسخة السحابية من Qwen3.6-27B، لم يحقق تفعيل الاستدلال زيادة كبيرة في الجودة. وبما أن رموز الاستدلال تُحتسب ضمن الرموز التي يولدها محرك الاستدلال، أدى تعطيلها إلى تقليل عدد الرموز المطلوبة بنحو ضعفين إلى ثلاثة أضعاف، وهو ما ترجمته الشركة إلى تسريع يقارب الضعف في تنفيذ المهام، مع تأثير وصفته بأنه غير مهم على الجودة.
استخدمت الشركة النسخة ذات التكميم 4-bit، لأنها أسوأ بقليل فقط من نسخة 8-bit في الاختبارات المعيارية، ولأن توليد الرموز المرتبط بالذاكرة كان أسرع بنحو الضعف مقارنة بنسخة 8-bit. لكن سرعة prefill لم تختلف بين نسخ 4-bit و8-bit و16-bit في الاختبارات الأولية، ما دفع الفريق إلى فحص العمليات الحسابية داخل المحرك.
العنق غير المرئي: مرحلة prefill
وفق أرقام JetBrains، يمكن أن تصل سرعة prefill إلى نحو 3,700 رمز في الثانية على بطاقة RTX 5090 ضمن الإعدادات الافتراضية، مقابل نحو 650 رمزاً في الثانية على M5 قبل التحسين. وفي مهام التحقيق داخل الملفات، كان الجزء الأكبر من الزمن يذهب إلى معالجة السياق، لا إلى توليد الرد نفسه.
وجد الفريق أن جزءاً كبيراً من عمليات المصفوفات أثناء prefill كان يُنفذ بدقة 16-bit، حتى عندما تكون الأوزان مضغوطة إلى 4-bit، لأن الأوزان كانت تُحوّل إلى 16-bit قبل تنفيذ العمليات. وبما أن M5 يملك تعليمات خاصة للحساب بدقة 8-bit، طبقت JetBrains تصحيحاً على حزمة MLX-VLM لنقل بعض عمليات المصفوفات في طبقات self-attention إلى 8-bit، فحصلت على زيادة تقارب 40% في سرعة prefill. لم يشمل التعديل طبقات full-attention التي تبقى أوزانها بدقة 16-bit حتى مع التكميم.
وتربط الشركة تركيزها الحالي على M5 بهذه التعليمات الحسابية تحديداً؛ فشرائح M4 لا تملكها، وتقول JetBrains إن حسابات 16-bit على M4 أبطأ بنسبة 20% إلى 30% في مرحلة prefill مقارنة بـ M5.
تسريع التوليد واختيار النموذج
فعّلت JetBrains أسلوبي speculative decoding معاً: التنبؤ متعدد الرموز MTP باستخدام نموذج مسودة منفصل، ومطابقة n-gram التي تبحث عن تسلسلات متكررة في السياق لتوقع الرموز التالية. وفي بعض الحالات يمكن قبول نحو ثلاثة رموز مقترحة عبر MTP وما يصل إلى ثمانية رموز إضافية عبر مطابقة n-gram، ما منح التوليد تسريعاً يصل إلى الضعف.
تشرح الشركة أن Qwen3.8-27B لم يكن الخيار الأفضل على أجهزة Mac، لأنه يحتاج إلى reasoning ليعمل جيداً. وعند تعطيله تتدهور الجودة بشدة، وقد يعلق النموذج في حلقة يكرر فيها استدعاء الأداة نفسه. أما تفعيله بمستوى متوسط فيزيد عدد الرموز المولدة بنحو خمسة أضعاف، ما يؤدي عملياً إلى تباطؤ يقارب أربعة أضعاف لأن زمن prefill لا يتغير كثيراً. لذلك بقي Qwen3.6-27B، في الوقت الحالي، الخيار الأنسب لتشغيل Junie محلياً على عتاد Mac وفق تقييم JetBrains.
قراءة certi.news: ما الذي يتغير فعلاً؟
توضح هذه التجربة أن قياس وكيل برمجة محلي بعدد الرموز المولدة في الثانية وحده قد يعطي صورة ناقصة. فالمستخدم ينتظر أيضاً تحميل الملفات، وإعادة استخدام السياق، وتنفيذ استدعاءات الأدوات، وهي مراحل يمكن أن تصبح عنق زجاجة قبل بدء التوليد. عملياً، تقلل تعديلات Junie الحاجة إلى إعادة قراءة الملفات، بينما يرفع تصحيح MLX-VLM سرعة معالجة السياق على M5، ويخفض تعطيل reasoning عدد الرموز المطلوبة.
لكن القيود واضحة أيضاً: الإصدار الأول يركز على M5، وتعطيل reasoning قد لا يناسب النماذج التي تعتمد عليه للحفاظ على الجودة، كما أن الاستفادة من تحديثات التقدم مرتبطة بسلوك Qwen3.6. وتقول JetBrains إنها تملك نماذج أولية لدعم DGX Spark وRTX 5090، وتدرس أيضاً بطاقات بسعة 24 GB، لكن المادة لا تقدم موعداً أو مواصفات لإتاحة هذه النسخ. لذلك يمثل Junie Local خطوة تقنية مهمة نحو وكلاء برمجة محليين أكثر قابلية للاستخدام، لا دليلاً على أن التجربة أصبحت متكافئة مع جميع النماذج السحابية أو متاحة على كل أنواع العتاد.