LFM3-1.7B مقابل Granite 4.2 30B: نموذجان وكيلان يقسّمان الحكم حسب المحور

ضع LFM3-1.7B وGranite 4.2 30B على الصفحة نفسها، وستتجه المتوسطات الإجمالية في اتجاهين متعاكسين تبعًا للصف الذي تقرأه. في Berkeley Function Calling Leaderboard V4، يسجّل نموذج Liquid AI ذو 1.73 مليار معامل نتيجة 71.39 مقابل 61.39 لـ IBM — فوز بعشر نقاط لنموذج أصغر بنحو سبعة عشر ضعفًا. وفي SWE-bench Verified، يسجّل Granite نتيجة 57.00 مقابل 43.40 لـ LFM3-1.7B، أي فوز بـ13.6 نقطة في الاتجاه المعاكس.لا يضيف التوجيه هامشًا إلى سعر القائمة لدى المزوّد. تمرّ أسعار القائمة لدى المزوّد كما هي عند هامش ربح 0%.

كلا الطرازين مبنيان للوكلاء، وقد أُطلق كلاهما خلال شهرين من بعضهما البعض في 2026، وينشر كلا المورّدين معايير قياس متداخلة بما يكفي بحيث تصبح المقارنة الحقيقية ممكنة بدلًا من مجرد تجميعة. وهذا يجعل هذه المقارنة من الحالات النادرة التي لا يكون فيها السؤال المثير للاهتمام هو أي الطرازين أفضل، بل على أي محور يقع عبء العمل لديك فعليًا. قلة قليلة من المهام تحتاج إلى درجة 71 في BFCL ودرجة 57 في SWE-bench معًا، والمهام التي تحتاج إلى ذلك لا يخدمها أي من الطرازين جيدًا بمفرده.

الرقمان اللذان يتقاطعان

صدر Granite 4.2 30B في 25 أغسطس 2026 بموجب Apache 2.0، وهو نموذج كثيف بحجم ~30B بُني على قاعدة Granite 4.1 30B ودُرّب على نحو 15 تريليون رمز. ويأتي تأطير IBM له بصبغة مؤسسية: ثلاثة أنماط تفكير قابلة للتهيئة، واستدعاء أدوات أصلي وفق مخطط OpenAI، واثنتا عشرة لغة مختبَرة، وخط أنابيب تدريب من ثلاث مراحل ينتهي بتعلّم معزّز GRPO متعدد الأطوار.

وصل LFM3-1.7B بعد شهرين، وأُعلن عنه في 27 أكتوبر 2026، بعد تدريب لاحق خصيصًا على أُطر تشغيل الوكلاء — وتذكر Liquid أسماء Hermes Agent وPI وOpenClaw في بطاقة النموذج. وهو نموذج كثيف بحجم 1.73B وسياق بطول 256K، ويُطرح صراحةً للوكلاء المحليين واستدعاء الأدوات بدلاً من الاستدلال العام.

إن تقاطع المعايير ليس مصادفة ناتجة عن رقم ضعيف واحد. فجدول LFM3-1.7B المنشور بالكامل يميل إلى الجانب الوكيلي: 71.39 في BFCL V4، و80.36 في ToolSandbox، و68.01 في τ³-bench، و45.60 في LiveClaw، و38.42 في WebArena-Verified. أما جدول Granite فيميل إلى الهندسة: 57.00 في SWE-bench Verified، و33.29 في SWE-bench Pro، و41.89 في SWE-bench Multilingual، و38.76 في SciCode، و29.24 في TerminalBench 2.1. لقد حسّن كل بائع أداءه وفق تعريف مختلف لكلمة «وكيل»، وجداول المعايير صادقة بشأن أي تعريف.

τ³ عند 68.01 مقابل 68.05 هو العنوان الحقيقي.

تحت الفجوتين الدراماتيكيتين يكمُن تعادلٌ تام. ففي τ³-bench، تقييم استخدام الأدوات الذي يقيس إنجاز المهام متعددة الأدوار عبر محاكيات المستخدمين وسياسات النطاق، تسجّل LFM3-1.7B نتيجة 68.01 وتسجّل Granite 4.2 30B نتيجة 68.05 — بفارق أربعة أجزاء من المئة من النقطة، وهو فارق لا يمكن تمييزه عن الضجيج.

هذه نتيجة أكثر إثارة للاهتمام من كلتا الفجوتين الكبيرتين، لأن τ³ هو المعيار الأقرب إلى ما تفعله معظم عمليات نشر الوكلاء فعليًا: إدارة محادثة، واتباع سياسة، واستدعاء الدالة الصحيحة، والتعافي من خطأ. وإذا تعادل نموذج بحجم 1.73B مع نموذج كثيف بحجم 30B هناك، فإن عدد المعاملات يشتري شيئًا آخر غير الاستخدام الكفء للأدوات في المحادثات متعددة الأدوار.

ما الذي يعود به ذلك يظهر في BFCL وSWE-bench، وهما يقيسان أشياء مختلفة. يختبر BFCL V4 صحة استدعاء الدالة في الجولة الواحدة وفق مخطط — وتشير نتيجة LFM3-1.7B البالغة 71.39 إلى أن التدريب اللاحق من Liquid على أُطر وكلاء حقيقية قد أثمر مباشرة. يختبر SWE-bench Verified إصلاح مشكلة GitHub حقيقية من البداية إلى النهاية، وهو ما يتطلب إبقاء مستودع في السياق، والتخطيط عبر الملفات، وإنتاج رقعة تجتاز الاختبارات — وتعكس نتيجة Granite البالغة 57.00 نموذجًا يمتلك القدرة على ذلك ومجموعة تدريب صُممت له.

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

السياق هو حيث تختلف المواصفات بأشد ما يكون.

• السياق — 262,144 رمزًا لـ LFM3-1.7B؛ و128K أصلية لـ Granite 4.2 30B، وقابلة للتوسعة إلى 512K. التوسعة ليست مجانية، وتصرّح IBM بصدق بأنها توسعة وليست نافذة أصلية.

• الاحتفاظ بالسياق الطويل — 65.56 على RULER عند 128K لـ LFM3-1.7B مقابل 81.4 لـ Granite 4.2 30B ضمن عائلة المعايير نفسها. يحتفظ النموذج الأكبر بقدر أكبر من مستند طويل، وهو عكس ما توحي به أرقام السياق الرئيسية.

• البصمة — نحو 1 غيغابايت بدقة 4-بت مقابل قرابة 30B من أوزان BF16، مع إصدارات رسمية بـ FP8 وNVFP4 وMXFP4. هذا نموذج لبطاقة رسومات واحدة، وليس نموذجًا لحاسوب محمول.

• اللغات — ست عشرة لغة لـ LFM3-1.7B مقابل اثنتي عشرة لغة جرى اختبارها لـ Granite، مع تداخل مختلف. تشمل الاثنتا عشرة لدى Granite التشيكية والهولندية؛ بينما تشمل لدى Liquid التايلاندية والفيتنامية والإندونيسية.

• أوضاع التفكير — يأتي Granite 4.2 30B مزوّدًا بأوضاع التفكير الكامل والجهد المنخفض وعدم التفكير. لا يوفّر LFM3-1.7B واجهة مماثلة، وتشير بطاقته إلى أنه غير مخصّص أصلًا للاستدلال المعقّد متعدد الخطوات.

• الترخيص — Apache 2.0 لـ Granite مقابل LFM Open License v1.0، وهو مجاني عندما تقل الإيرادات السنوية عن 10 ملايين دولار ويتطلب ترخيصًا تجاريًا إذا تجاوزت ذلك.

ما الذي يكلّفه النموذج الكثيف 30B ولا يكلّفه 1.73B؟

إن Granite 4.2 30B كثيف، ما يعني أن جميع معاملاته الثلاثين مليارًا تعمل على كل توكن. لا يوجد هنا خصم على المعاملات النشطة: فتكلفة الحساب لكل توكن تعادل نحو سبعة عشر ضعف تكلفة النموذج الصغير، وتكلفة الذاكرة هي ملف الأوزان كاملًا. توفر IBM نسخًا مكمّمة لجعل ذلك عمليًا، لكن لا توجد أي تهيئة يعمل فيها على هاتف.

ميزة LFM3-1.7B ليست السرعة في المقام الأول، بل إن النموذج يتسع ضمن ميزانية الذاكرة نفسها التي تتسع لها بقية تطبيقك. فنموذج بحجم 1 GB يترك مساحة لمخزن مستندات وذاكرة تخزين مؤقت ونموذج ثانٍ على الجهاز نفسه — وهذا ما يجعل الوكيل المحلي ممكنًا بدلًا من أن يكون محليًا نظريًا فقط. وتذكر Liquid أن فك الترميز أسرع من سابقيه بمقدار 1.8 إلى 2.8 ضعف على الأجهزة المختبرة، مع ذاكرة KV cache بسعة 1.6 GB عند 128K، وكلاهما مهم لوكيل يعمل على الجهاز ويجري محادثة طويلة.

في المقابل، فإن سعة Granite البالغة 30B تؤدي عملًا حقيقيًا في أرقام SWE-bench. وإذا كانت مهمة وكيلك هي تغيير الشيفرة عبر مستودع، فإن الفجوة البالغة 13.6 نقطة ليست شيئًا يستطيع نموذج أصغر تعويضه عبر التوجيه النصي، كما أن التوفير في الحوسبة يجلب لك نتيجة أسوأ.

الترخيص والتوقيع ومسألة الشراء

Apache 2.0 هو السبب الذي يمكّن مؤسسة كبيرة من تبنّي Granite 4.2 30B دون مراجعة قانونية. لا يوجد حدّ إيرادات، ولا محفّز تجاري، ولا تفاوض. كما أن IBM توقّع تشفيريًا نماذج Granite الصادرة منذ أبريل 2026، وهو ما يبدو تفصيلًا صغيرًا حتى تصبح أنت الشخص الذي عليه إثبات أن الأوزان في بيئة الإنتاج هي الأوزان التي جرى تدقيقها.

يُعدّ ترخيص LFM Open License v1.0 من Liquid متساهلًا حقًا على نطاق الشركات الناشئة — مجاني للاستخدام التجاري دون 10 ملايين دولار من الإيرادات السنوية — لكنه فوق هذا الحد يتطلب ترخيصًا تجاريًا مدفوعًا. بالنسبة لمطور فردي أو فريق صغير، هذه ليست مشكلة. أما بالنسبة لوحدة أعمال داخل شركة أكبر، فهي محادثة تبدأ قبل أول عملية نشر وقد لا تنتهي سريعًا. هذا التفاوت لا ينعكس في أي معيار أداء وغالبًا ما يحسم المسألة بمفرده.

تشغيل كليهما دون تبديل

النمط العملي لفريق يقيّم هذين النموذجين ليس أن يختار أحدهما أولًا. فكلاهما مفتوح الأوزان، وكلاهما لم يثبته مقيّمون مستقلون، ما يعني أن المعيار الوحيد المهم هو معيارك أنت. مرّر النماذج المرشحة عبر نقطة نهاية واحدة، وشغّل نفس تتبعات الوكيل عبر كليهما، وقارن على مهمتك لا على BFCL أو SWE-bench.

يكون OrcaRouter مفيدًا هنا بصفته واجهة تحكم أكثر من كونه مضيفًا: مفتاح واحد وفاتورة واحدة عبر أكثر من 200 طراز، مع تمرير أسعار قوائم المزوّدين بهامش ربح 0%، وتجاوز فشل تلقائي حتى لا يتوقف تشغيل تقييم لأن أحد المزوّدين مرّ بساعة سيئة. لا يوجد LFM3-1.7B ولا Granite 4.2 30B في كتالوجنا اليوم — فكلاهما نموذجان قابلان للتنزيل بأوزان مفتوحة، والاستضافة الذاتية هي المسار لكل منهما. وتتجلى فائدة التوجيه في المنظومة المحيطة: النموذج المتقدم الذي يصعّد إليه وكيلك، أو الرأي الثاني الذي تقارن به عندما تفشل رقعة النموذج المحلي في اختباراتها.

من ينبغي أن يأخذ أيًّا؟

اختر LFM3-1.7B إذا كان الوكيل يعمل على جهاز المستخدم، وإذا كان العمل عبارة عن استدعاء الأدوات والاستخراج المنظم عبر API، وإذا كان سياق 256K ببصمة 1 GB هو ما يجعل المنتج ممكنًا. اقبل تحذير البائع نفسه بأنه غير مخصص للبرمجة الوكيلية، وأبقِ نموذجًا أكبر خلفه للحالات التي تحتاج إلى ذلك.

اختر Granite 4.2 30B إذا كان الوكيل يتعامل مع قاعدة شيفرة، وإذا كنت بحاجة إلى Apache 2.0 وأوزان موقّعة لأغراض الشراء، وإذا كان عبء العمل يستفيد من جهد تفكير قابل للضبط، وإذا كانت لديك وحدة GPU لتقديمه منها. إن عجز BFCL حقيقي لكنه ضيق: فهو يقيس صحة المخطط في استدعاء واحد، ونموذج 30B مع مخطط أدوات مصمم جيدًا يسد الكثير من تلك الفجوة عمليًا.

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

السؤال الجدير بالمتابعة هو ما إذا كانت وصفة التدريب اللاحق الوكيلية لدى Liquid تنتقل إلى نقطة تحقق أكبر. إذا حافظ نموذج LFM مستقبلي على سلوك BFCL من فئة 71.39 وأضاف قدرة على العمل في المستودعات، فإن تقسيم المحاور ينهار ويصبح هذا التعارض قرارًا مباشرًا بشأن الحجم. وإلى أن يحدث ذلك، فإن النموذجين لا يتنافسان على الوظيفة نفسها — بل هما نصفان لنموذج واحد.