AesCode-32B: نموذج Microsoft الهادئ بحجم 33B الذي يكتب العروض التقديمية بصيغة HTML قابلة للتحرير

الطوابع الزمنية على AesCode-32B تتعارض مع بعضها البعض، والتعارض هو معظم ما هناك للإبلاغ عنه. مستودع Hugging Face microsoft/AesCode-32B أُنشئ في 29 سبتمبر 2026، لكن كل شيء فيه وصل في التزام واحد بتاريخ 7 أكتوبر 2026 رسالته ببساطة "Release AesCode-32B" — وقد تم دفع حزمة التدريب التي تجعل النتيجة قابلة للتكرار إلى github.com/microsoft/AesCode في 8 أكتوبر. لم تعلن Microsoft أي شيء: لا منشور مدونة، لا نسخة أولية على arXiv، لا تقديم إلى لوحة المتصدرين، لا صفحة نموذج على موقعها الخاص. الموجود هو نموذج رؤية ولغة بـ 33 مليار معامل يأخذ موجهًا ويصدر مستند HTML كاملًا ومكتفيًا بذاته — شريحة عرض، ملصق، لوحة معلومات — بالإضافة إلى رفيق أصغر، microsoft/AesCode-8B. كلاهما مضبوط بدقة من نماذج رؤية Qwen3-VL — Qwen3-VL-32B-Instruct و Qwen3-VL-8B-Instruct على التوالي — كلاهما بترخيص Apache 2.0، وكلاهما قابل للتنزيل اليوم.

يقرأ معرّف المستودع microsoft/AesCode-32B وتُفتتح البطاقة بالحيلة: يقرن AesCode مطالبتك بصورة مولّدة من تلك المطالبة نفسها، ويستخدم الصورة كمرجع جمالي، ويتبع النص للمحتوى الفعلي. مولّدات الصور تُنشئ صفحة أنيقة وتُخطئ في عرض الأرقام عليها؛ أما نماذج البرمجة فتُصيب الأرقام ولا تستطيع رؤية كيف تبدو الصفحة. AesCode محاولة للجمع بين الاثنين، والخلاصة الصادقة عنه حتى 11 أكتوبر 2026 هي أن الأوزان حقيقية وقابلة للتحقق، وأن أرقام المعايير هي أرقام المختبر نفسه على أداة اختبار كتبها المختبر، وأنه لم ينشر أحد خارج Microsoft رقمًا له حتى الآن. تُبقي هذه المقالة تلك الفئات الثلاث منفصلة حتى النهاية.

ما الذي يوجد فعليًا في المستودع، بايتًا بايتًا؟

ابدأ بما يمكنك التحقق منه دون أن تثق بكلمة واحدة من بطاقة النموذج. يحتوي مستودع 32B على أربع عشرة شظية safetensors يبلغ مجموعها 66,714,912,704 بايت، وهو ما يعادل عند BF16 نحو 33.4 مليار معامل — بما يتوافق مع ما ورد في البطاقة من "33B params" وتحذيرها من أن الأوزان وحدها تحتاج إلى نحو 65 غيغابايت من ذاكرة المسرّع. ويصرّح الإعداد بأن Qwen3VLForConditionalGeneration هي البنية المعمارية وqwen3_vl هي نوع النموذج، لذا هذه ليست بنية معمارية جديدة ولا تحتاج إلى واحدة: فهو يُحمَّل باستخدام transformers>=4.57، وتُرفق البطاقة أمر vLLM يقدّمه عبر أربع مراتب توازٍ للتوترات مع السماح بصورتين لكل طلب وسقف قدره 24,576 رمزًا.

عدّادات التفاعل هي أهدأ جزء في الإصدار. تحميلان وإعجاب واحد على مستودع 32B وقت كتابة هذه السطور. لا يوجد مُدخل في خريطة مزوّدي الاستدلال لدى Hugging Face، ما يعني أنه لا توجد نقطة نهاية مستضافة موصولة خلف صفحة المستودع، ولا يُعلَن في أي مكان عن أي إصدار من GGUF أو MLX أو llama.cpp. وبالنسبة لنموذج يحمل اسم Microsoft ويقدّم نتائج تتفوق على GPT-5.5 في جدول المورّد نفسه، فهذه بصمة صغيرة بشكل لافت — وهي أقوى دليل متاح على أن هذا نُشر من دون إطلاق يقف خلفه.

مستودع الشيفرة المرافق يكمل النصف الآخر من الجدول الزمني، وهو الموضع الذي يصبح فيه سؤال تاريخ الإصدار غامضًا حقًا. microsoft/AesCode أُنشئ في 23 يوليو 2026 — أي قبل الأوزان بعشرة أسابيع — ويضم أربعة عشر إيداعًا، كل واحد منها من تأليف المساهم نفسه، وكل واحد منها يحمل طابعًا زمنيًا لا يبعد أكثر من عشرين ثانية عن الأخرى في 8 أكتوبر 2026، بين 23:14:04 و23:14:24 بالتوقيت العالمي المنسق. وهي تشمل مواصفة توليد المطالبات والمتطلبات القابلة للتحقق، وخط أنابيب البيانات الذي يبني مخططات التصميم وأسئلة معايير التقييم، ومرحلة SFT للبداية الباردة، وحلقة التعلم المعزز GDPO، ومدقق عرض قائم على Playwright، واختبارات، وملف README الذي يوثق كل ذلك. لا توجد إصدارات ولا وسوم، ووصف المستودع فارغ، ولديه نجمة واحدة.

إذن، ما هو تاريخ الإصدار؟ يقول سجل المستودع 29 سبتمبر. ويقول الإيداع الذي يحمل النموذج 7 أكتوبر. ويقول الكود الذي يوضّح كيف صُنع النموذج 8 أكتوبر. ثلاثة طوابع زمنية داخل نافذة واحدة مدتها أسبوعان، ولا يصاحب أياً منها جملة من مايكروسوفت تقول «نحن نطرح هذا». تعامل مع 7–8 أكتوبر باعتباره التاريخ العملي للمخرجات التي سيحمّلها معظم الناس فعلاً، ومع 29 سبتمبر باعتباره تاريخ حجز المستودع. أي شخص يخبرك بأن AesCode-32B «أُطلق» في يوم محدد فهو يختار أحد تلك الطوابع الزمنية نيابة عنك.

الآلية: صورة بوصفها توجيهًا جماليًا، ورسم بياني بوصفه المكافأة.

الادعاء التقني للبطاقة ضيق ومحدد، وهذه نقطة لصالحه. يُدرَّب النموذج بالضبط الدقيق الخاضع للإشراف ببداية باردة على 3,000 عرض توضيحي بمعدل تعلم 1e-5، ثم باستخدام GDPO — وهو متغير لتحسين السياسة النسبي للمجموعة — على 7,408 مُطالبة لمدة 520 خطوة. استخدم نموذج 8B نفس الوصفة وتوقف عند 400 خطوة. استخدم تشغيل التعلم المعزز (RL) محرك verl الهجين FSDP-vLLM دون ناقد ودون نموذج مكافأة مُدرَّب بشكل منفصل، وAdamW بمعدل ثابت 5e-6 دون تسخين، و128 مُطالبة لكل خطوة مع ثماني عمليات توليد لكل منها، وتم تحديد سقف كل من المُطالبة والاستجابة عند 8,192 رمزًا.

ما يجعل المكافأة غير عادية هو أنها ليست قيمة عددية مفردة. يُوصف كل هدف تدريبي بأنه رسم بياني تصميمي يغطي كامل اللوحة، بحيث يمكن نسب الخصائص الفردية بشكل منفصل. من هذا الرسم البياني تأتي سبع قنوات — التنفيذ، النص، الحدود، مخطط الجدول، التخطيط، المساحة البيضاء، والتصميم — يتم تطبيع كل منها ضمن مجموعة التدحرج الخاصة به قبل التجميع بحيث لا يمكن لإشارة مهيمنة واحدة أن تطغى على الأخرى. تقوم المدققات الحتمية بتقييم ما يمكن تحليله من الكود وعرضه؛ ويقوم حكم الرؤية واللغة بتقييم ما لا يمكن، باستخدام معيار مرتبط بعناصر الرسم البياني نفسه وعلاقاته. يتم تقييم HTML المرشح من خلال عرضه في متصفح Playwright معزول مع حظر الطلبات الخارجية، والذي يُصدر DOM، والأنماط المحسوبة، ومربعات الإحاطة، وحالة وحدة التحكم، ولقطة شاشة.

تجدر الإشارة إلى النتيجة الهندسية لأنها تظهر في المخرجات التي تتلقاها: فالنموذج مُدرَّب على إخراج الجداول كهياكل جداول HTML حقيقية والرسوم البيانية كمواصفات ECharts، لذا يمكن فحص كليهما مباشرةً بدل أن يكونا مطمورين في البكسلات. وهذا هو الفرق بين عرض تقديمي يمكنك تسليمه لمصمّم وعرض تقديمي يمكنك تسليمه لمدقّق. وبالتالي فإن متطلبات إعادة الإنتاج ثقيلة بالمقابل — يطلب README توفير Python 3.10 وCUDA 12.6 وعقدة من ثماني وحدات B200 GPU، ويثبّت commit معيّنًا من verl ويذكر صراحةً أن رقعة عليه مطلوبة لأن verl الأساسي يفتقر إلى دعم Qwen3-VL، ويحذّر من أنه بدون مكتبات نظام Playwright يفشل المتصفح عند الإطلاق وتحصل الصفحات على درجة صفر، وأنه بدون مكدس OCR المثبّت على إصدار محدد، تُعيد قناة المكافأة المقابلة صفرًا بدلًا من الامتناع وتُفسد الإشارة بصمت.

جدول المعايير المرجعية، والأسباب الأربعة للتعامل معه بمرونة

تأتي الأرقام الرئيسية لـ AesCode-32B من 300 عيّنة إنفوجرافيك، بثلاث توليدات لكل موجّه عند درجة حرارة 0.8 وtop-p 0.95، وبما يصل إلى 12,000 رمز إخراج لكل توليد، دون أي انتقاء بين التوليدات. الدرجات بالنسب المئوية. في الوضع المشروط بمرجع، يسجّل نموذج 32B النص 95.34، والحدود 97.27، والجدول/المخطط 90.37، ومتوسط القواعد 94.33؛ وعلى الجانب البصري المحتوى 85.76، والتخطيط 90.58، والنمط 55.99، بمتوسط بصري 77.44 وإجمالي 85.89. وفي الجدول نفسه، يسجّل GPT-5.5 مع مرجع درجة إجمالية قدرها 81.28، ويسجّل Claude Opus 4.8 مع مرجع 80.39، بينما يسجّل النموذج الأساسي Qwen3-VL-32B-Instruct، الذي دُرّب منه النموذج، 61.10.

هناك أربع ملاحظات تحفّظية يجب ذكرها في السياق نفسه مع تلك الأرقام، ولا تشكّل أي منها قدحًا في العمل. أولًا، كل صف، بما في ذلك صفّا GPT-5.5 وClaude Opus 4.8، شغّلته Microsoft على أداة الاختبار الخاصة بـMicrosoft وفق معايير التقييم الخاصة بـMicrosoft — فهذه ليست أرقام المختبرات الأخرى، بل هي قياسات Microsoft لنماذج منافسة، كما أن البطاقة نفسها تصف معايير التقييم بأنها "خاصة بالعينة" لكل مخطط تصميم. ثانيًا، تُنتَج معايير التقييم بواسطة المسار نفسه الذي ولّد بيانات التدريب، وهو بالضبط الإعداد الذي قد ينحرف فيه معيار قياس نحو نقاط قوة النموذج؛ والبطاقة صريحة بشأن حدود معايير التقييم تلك — فبُعد Style، الذي يشترط ألّا يحتاج التصميم إلى أي مراجعة بصرية إضافية قبل التسليم، يوصف بأنه "السقف المشترك لكل نظام"، ولا يتجاوز أي نموذج في الجدول 60. ثالثًا، لا يوجد أي قياس مستقل لهذا النموذج في أي مكان: لا إدخال في لوحة صدارة من طرف ثالث، ولا إعادة إنتاج، وبالنظر إلى عمليتَي تنزيل، فمن المؤكد تقريبًا أنه لا أحد خارج المختبر يشغّله بعد. رابعًا، المقارنة غير متناظرة بشكل خفي، بطريقة تستحق الملاحظة — فكل صفوف AesCode-32B مشروطة بمرجع، أي أن النموذج يُقاس في الإعداد الذي دُرِّب من أجله، وهو ما تعترف به البطاقة عبر إظهار أن الجودة لا تزال الأعلى عند توفير مرجع.

النتيجة الوحيدة في الجدول التي تصمد أفضل من العنوان الرئيسي هي ادعاء متانة وليست ادعاء جودة. حجب الصورة المرجعية عند الاستدلال يكلّف AesCode-8B فقط 1.00 نقطة بصرية، مقابل 19.55 لـ Qwen3-VL-8B-Instruct، نموذجه الأساسي، و10.04 لـ GPT-5.5. وتقول البطاقة إن التدريب المشرّط بالمرجع يدمج التخطيط البصري في السياسة بدلاً من تعليم النموذج نسخ ما يراه. هذا مُبلّغ عنه من المورّد ولم يُعَد إنتاجه، وهو أيضاً نوع الادعاء الذي تحسمه تجربة مستقلة واحدة — والنوع الأهم في الإنتاج، حيث لن تكون لديك دائماً صورة مرجعية في متناول اليد.

ما تكلفة تشغيله، وما يعنيه ذلك بالنسبة للمقارنة

لا شيء في هذا النموذج رخيص عند استضافته ذاتيًا. عشرة آلاف إلى اثني عشر ألف رمز إخراجي هو الحجم العملي لمخرَج واحد، ومستند HTML كامل يتضمن مواصفة ECharts أقرب إلى الطرف الأعلى من هذا النطاق منه إلى الطرف الأدنى، لذا فإن كل توليد هو فك ترميز طويل. تتطلب وصفة الخدمة الواردة في بطاقة النموذج نفسها أربع وحدات GPU بالتوازي التنسوري لتستوعب نحو 65 غيغابايت من معاملات BF16، وتتطلب وصفة التدريب ثماني وحدات B200. تلك آلة حقيقية، وليست عملية نشر للهواة، وهي تحدد شروط المقارنة: النماذج التي يُقاس عليها AesCode-32B تُستأجر حسب الرمز، والنموذج نفسه يُستأجر بساعة GPU، سواء كنت تملك العتاد أم لا.

الشكل العملي لتلك المقارنة هو الغاية التي توجد من أجلها طبقة التوجيه، ويستحق الأمر أن نكون دقيقين بشأن ما نستضيفه وما لا نستضيفه. AesCode-32B ليس ضمن كتالوج OrcaRouter ونحن لا نقدّمه — لا توجد نقطة نهاية مستضافة له في أي مكان أستطيع التحقق منه، بما في ذلك لدى Microsoft. أما ما هو في الكتالوج فهو الجانب الآخر من الطاولة: النماذج المستضافة التي ستقارن مقابلها مولّد مخرجات مستضافًا ذاتيًا، بما في ذلك GPT-5.5 ونماذج Qwen3-VL البصرية الأصغر، يمكن الوصول إليها عبر مفتاح API واحد بسعر قائمة المزوّد مع هامش ربح 0%، ما يعني أن تغيير سعر المزوّد يصبح ساريًا لدينا في اليوم نفسه.مقارنة نقطة نهاية مستأجرة بنموذج تشغّله بنفسك لا تحتاج إلى عقد ثانٍ أو SDK ثانٍ، كما أن لغة DSL للتوجيه تتيح لاستدعاء مستضاف ذاتيًا أن يجلس إلى جانب الاستدعاءات المستضافة خلف نقطة نهاية واحدة. إذا تبيّن أن AesCode-32B جيد في الشيء الوحيد الذي تدّعيه بطاقته، فإن تكلفة اكتشاف ذلك هي فاتورة GPU، وتكلفة البدائل التي تقارنه بها هي مفتاح واحد على الأرجح لديك بالفعل.

ما يمكنك فعله به اليوم، وما الذي لا وجود له

• قم بتنزيله وتشغيله — الأوزان بموجب Apache 2.0، وفقًا لبنية Qwen3-VL الأساسية، مع أربعة عشر جزءًا من BF16 ومسار transformers عامل فوق الإصدار 4.57 ووصفة vLLM في البطاقة.

• أعِد إنتاج التدريب — الكود مرخّص بموجب MIT ومكتمل بما يكفي ليكون ذا معنى: مدقّق المكافأة، وباني معايير التقييم، ومرحلتا SFT وGDPO، وcommit مثبّت من verl بالإضافة إلى التصحيح الذي يضيف دعم Qwen3-VL، وملف README يسرد أنماط الفشل بدلًا من إخفائها.

• قيّمه دون مرجع — يقبل النموذج الأوامر النصية مع الصورة المرجعية أو بدونها، وأكثر ادعاء قابل للاختبار في البطاقة يكمن في هذا الإعداد.

• الحصول على API له — لا يمكنك ذلك. لا توجد نقطة نهاية مستضافة، ولا ربط بمزوّد استدلال على المستودع، ولا إصدار GGUF أو MLX؛ تشغيل هذا يعني تشغيل العتاد نفسه.

• اقرأ الورقة — لا يمكنك ذلك بعد. تربط البطاقة ورقة بعنوان AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards، ويعطي إدخال BibTeX الخاص بها المكان على أنه "Under review" والسنة 2027. ولا يُرجع البحث في arXiv أي ورقة بهذا العنوان. وهناك ورقة مختلفة أقدم من Microsoft باسم شبه مطابق — Code Aesthetics with Agentic Reward Feedback من أكتوبر 2025، أصدرت نموذج AesCoder-4B ومجموعة بيانات AesCode-358K — ولا شيء في بطاقة AesCode-32B يستشهد بها أو يذكر علاقة بها. إذا ذهبت باحثًا عن قراءة خلفية ووقعت على تلك بدلًا منها، فأنت تقرأ عن نموذج مختلف بناه مؤلفون متداخلون.

• قارنه على لوحة صدارة عامة — ليس بعد. لا يبدو أن أي فهرس من طرف ثالث قد قيّمه، وهو أمر غير مفاجئ لمستودع لديه تنزيلان.

من ينبغي أن يهتم، ومن ينبغي أن ينتظر

الجمهور المستهدف لهذا أضيق مما يوحي به جدول العناوين الرئيسية وأكثر تحديدًا من "أي شخص يبني باستخدام النماذج". إذا كان منتجك يحوّل المطالبات إلى عروض تقديمية أو ملصقات أو تقارير أو لوحات معلومات يجب على شخص ما تحريرها لاحقًا، فقد اكتشفت بالفعل الخيار الذي يستهدفه هذا النموذج: توليد الصور يمنحك مستطيلًا جميلًا لا يمكنك تغييره، وتوليد الكود يمنحك شيئًا قابلًا للتحرير يبدو وكأن مُجمّعًا قد جمّعه. نموذج مفتوح الأوزان بحجم 33B يُصدر مستند HTML كاملًا بجداول حقيقية ومواصفات ECharts، ويبقى ضمن حوالي نقطة واحدة من جودته المشروطة بالمرجع عندما لا يكون لديك مرجع تقدمه له، ويمكنك ضبطه بدقة وفق أسلوب مؤسستك تحت رخصة Apache 2.0، هو أمر مفيد حقًا أن يكون موجودًا. لا يوجد نموذج آخر يقوم بهذه المهمة تحديدًا بهذا الحجم وبهذه الشروط.

في مقابل ذلك: كل ما تعرفه عن الجودة يأتي من جدول بناه المورّد، ومعايير التقييم التي يقوم عليها أنتجها نفس خط المعالجة الذي أنتج بيانات التدريب، والسقف الوحيد الذي تعترف به البطاقة — درجة Style دون 60 لكل نظام تم اختباره — هو بالتحديد البُعد الذي يهم أكثر من غيره منتجًا حساسًا للتصميم. الفريق الذي لديه سبب امتثال يدفعه إلى إبقاء التوليد داخليًا ولديه عقدة إضافية بثماني وحدات GPU لديه ما يكفي للبدء اليوم. أما الفريق الذي يختار نموذجًا للإنتاج الأسبوع المقبل فليس لديه رقم مستقل يختار على أساسه، ولا ينبغي أن يقرأ 85.89 مقابل 81.28 كنتيجة محسومة.

ما الذي قد يحوّل هذا إلى قصة؟

أربعة أشياء، لا وجود لأي منها بعد. إعلان — لم تقل مايكروسوفت شيئًا، والورقة التي تشير إليها البطاقة تخضع للمراجعة صراحةً، لذا قد يظهر تقرير تقني يتضمن تفاصيل تدريب تتجاوز ملخص البطاقة في أي وقت. تشغيل مستقل — ادعاء المتانة الخالي من المرجع ودرجة Boundary، التي تقول البطاقة إنها تهبط إلى فشل حاد في 4.3% من العينات مقابل 34.7% لدى GPT-5.5، كلاهما رخيص الاختبار وكلاهما يستحق الاختبار. دعم التشغيل خارج وصفة المورّد — بناء GGUF أو بيئة تشغيل سائدة قد يغيّر الصورة المتعلقة بالعتاد أكثر مما يفعل أي معيار أداء. ونقطة بيانات ثانية في مسألة الحجم: نموذج 8B يسجل 82.94 في الإجمالي مقابل 85.89 لنموذج 32B في الجدول نفسه، وهو فارق نقطتين مقابل ربع عدد المعاملات، وهو من النوع الذي إما يُعاد إنتاجه أو يتوقف ذكره بهدوء.

إلى أن يتحقق أحد تلك الأمور، فالوصف الدقيق لـ AesCode-32B هو هذا: أوزان حقيقية بموجب ترخيص متساهل، ومكدس تدريب مُفصّل بما يكفي ليتمكن مختبر جيد التجهيز من إعادة إنتاجه، وجدول قياسات يمثّل قياس شركة واحدة لنموذجها الخاص ولنموذجَي منافسين، وتاريخ مستودع لا يسمح لك بتسمية أي يوم واحد بوصفه تاريخ الإطلاق. إنه أثر أكثر إثارة للاهتمام مما يوحي به عدّاد تنزيلاته البالغ اثنين، وأقل إثباتًا مما يوحي به الرقم 85.89. وكلا نصفَي تلك الجملة هو القراءة الصادقة في 11 أكتوبر 2026.