أطلقت ميتا Muse Ember، المُسمى أصغر وأكثر نماذجها كفاءة. فهو ليس مصممًا لتحدي المهام الاستدلالية الأكثر تعقيدًا، بل مخصص لمعالجة المهام الأكثر تكرارًا في تنفيذ الوكلاء: الاستدعاء المتسلسل للأدوات، واسترجاع واستخراج المعلومات، وقراءة الكود، وتشغيل الاختبارات، وتعديل الملفات جزئيًا، ومعالجة المستندات الطويلة. يتمتع النموذج بسياق يصل إلى مليون رمز، ويفهم بشكل أصلي النصوص والصور والصوت والفيديو. إن تقسيم المهام عند ميتا واضح جدًا: Muse Wonder مسؤولة عن حل المشكلات الصعبة، بينما Ember مسؤولة عن إنجاز كم كبير من المهام العملية. ما يستحق حقًا الانتباه هو التكلفة. يبلغ سعر واجهة برمجة التطبيقات القياسية لـ Muse Ember 0.10 دولار لكل مليون رمز إدخال و0.50 دولار لكل مليون رمز إخراج. على مؤشر Artificial Analysis Intelligence، حصل على درجة 36، وهو ما يعادل أعلى مستوى من Claude Haiku 5.5، ويتفوق على جميع مستويات الاستدلال لـ GPT-6 Luna. لكن لإكمال مهمة اختبار قياسية، يحتاج Ember في المتوسط فقط حوالي 0.14 دولار، بينما يحتاج Haiku 5.5 إلى 0.41 دولار. المثير للاهتمام أن سعر الإدخال والإخراج للرمزين متطابق تمامًا. فلماذا يمكن لـ Ember أن يكون أرخص بثلثين؟ تشرح Artificial Analysis أن السبب هو أن سعر تخزين الإدخال أدنى، واستهلاك رموز الإخراج لا يتجاوز ثلث ما يستهلكه Haiku تقريبًا. هذا هو بالضبط التحسن في الكفاءة الذي يمتلك قوة تدميرية حقيقية في عصر الوكلاء: لا يكفي أن يكون النموذج قادرًا على العمل، بل يجب أن يتحدث أقل ويستهلك أقل، ويقلل من تكلفة كل خطوة أثناء التنفيذ المتكرر. الأمر الأكثر إثارة هو أن Ember بدأ حتى في سرقة أعمال النماذج الكبيرة الخاصة بميتا نفسها. في نفس اختبارات Artificial Analysis، كان مؤشر الذكاء لـ Muse Spark 1.3 هو 37 نقطة، وEmber 36 نقطة، لكن تكلفة المهمة الواحدة كانت 2.39 دولار لـ Spark و0.14 دولار لـ Ember، أي فرق يقارب 17 مرة. بالطبع، لا يتفوق Ember في كل شيء. في اختبار FrontierCode 2.0 الذي يقيس قابلية دمج كود البرمجة الحقيقي، لا يزال متأخرًا عن Haiku 5.5. بعد ذلك، أدخلت ميتا Ember وWonder وSpark 1.3 معًا على Google Cloud وOracle Cloud. حاليًا، توجد Google Cloud في مرحلة العرض التجريبي، وEmber متاح حاليًا فقط لإدخال النصوص والصور. أعتقد أن الإشارة الحقيقية التي أطلقتها ميتا في هذا الإطلاق هي أن المنافسة بين النماذج الكبيرة تنتقل من مسابقة ذكاء منفردة إلى نظام دقيق من تقسيم العمل. في الماضي، كان الجميع يجادل حول أي نموذج هو الأذكى، لكن في المستقبل، قد يهتم المطورون أكثر بتحديد أي المهام تستحق دفع ثمن نموذج أذكى، وأيها كافية لإنجازها بنموذج أصغر وأرخص بـ17 مرة. ففي النهاية، لا يعتمد إنشاء قيمة حقيقية من قبل الوكيل على استدلال واحد مذهل نادر الحدوث، بل على قدرته على إنجاز مئات العمليات العادية بشكل موثوق. النموذج الأذكى يحدد الحد الأقصى لقدرات الوكيل، لكن النموذج الأرخص والأذكى بما يكفي ربما هو الذي يحدد ما إذا كان الوكيل سيصبح عملًا مربحًا.