LFM2.5-24B-A2B-DSpark مقابل LFM2.5-24B-A2B: هل يجب عليك فعلاً إرفاق نموذج الصياغة؟

هذا هو القرار في سطر واحد: LFM2.5-24B-A2B-DSpark هو ملف بمعاملات 327.7 مليونًا تضعه بجوار LFM2.5-24B-A2Bحتى يُنتج نموذج الـ24B النوع نفسه من المخرجات بسرعة أكبر. وهو ليس بديلًا عن النموذج وليس شيئًا تختاره بدلًا منه. السؤال الحقيقي الوحيد الذي يطرحه الاسمان هو سؤال هندسي — هل تُرفق مُقترِح المسودة بنشرك أم تتركه معطلًا — والجواب يعتمد بشكل أقل على السرعة المعلنة من Liquid AI وأكثر على رقمين لا يعلن عنهما أحد: كم عدد الرموز التي تُقبل للمسودة على حركة المرور الخاصة بك، وكم مستوى التزامن الذي تشغّله بالفعل. إخفاقات الذكاء الاصطناعي وحوادث الوكلاء الموثقة وراء إصدارات مثل هذا الإصدار مجموعة في OrcaRouter AI Incident Archive حيث يحمل كل مدخل مصادره الخاصة ودرجة خطورته ودرجة ثقته وعلامة النزاع الخاصة به.

لم تنشر Liquid AI منشور إطلاق لنموذج المسودة. أُتيح المستودع للعموم في 2026-10-19 مع الأوزان، وملف CSV لنتائج القياس، وأعلام إطلاق SGLang، بينما لا تزال بطاقة النموذج الخاصة بالنموذج الهدف تصف نموذج المسودة بأنه «قريبًا»، ولا تُدرج صفحة وثائق فك الترميز التخميني الخاصة بـ Liquid سوى النماذج الهدف 1.2B و2.6B و8B وVL-3B. لذا فالمقارنة هنا بين مُخرَج مُصدَر ونموذج مُصدَر، مكتوبة اعتمادًا على المستودع لا على بيان صحفي — ما يعني أن كل رقم أداء أدناه مُبلّغ عنه من المورّد، ولم يُعَد إنتاج أيٍّ منه بشكل مستقل.

ما الذي يغيّره مُعِدّ المسودة فعليًا، وما الذي لا يغيّره.

تستحق هذه الآلية ثلاثين ثانية من وقتك لأنها تحدد كل ما سواها. فك ترميز الرمز (token) عملية مقيّدة بالذاكرة: إذ تقضي وحدة معالجة الرسومات معظم وقتها في بثّ الأوزان إلى ذاكرة SRAM، لا في إجراء العمليات الحسابية. ويستغل فك الترميز التخميني ذلك بأن يجعل نموذجًا صغيرًا يخمّن الرموز العديدة التالية دفعة واحدة، ثم يجعل النموذج الحقيقي يتحقق من التخمين كله في تمريرة أمامية واحدة. فإن كان التخمين جيدًا، أنتجت تسعة رموز بتكلفة رمز واحد تقريبًا. وإن كان سيئًا، يحتفظ النموذج المستهدف برمزه الخاص، وتدفع قليلًا من التكلفة الإضافية.

ما الذي يتغيّر: عدد الرموز في الثانية، وشكل استغلال GPU لديك. وما لا يتغيّر: أوزان النموذج، ونافذة السياق، وسلوكه في استدعاء الأدوات، أو أسعاره حيث يُباع. يحتفظ LFM2.5-24B-A2B بإجمالي 24.0B من المعاملات مع 2.45B نشطة لكل رمز، و40 طبقة موزعة بين التفافات قصيرة مُبوّبة وانتباه مجمّع للاستعلامات، و64 خبيرًا لكل كتلة مع توجيه top-4، وسياق من 131,072 رمزًا ومفردات من 128,000 رمز. يضيف نموذج المسودة خمس طبقات انتباه، ورأس ماركوف برتبة 256، ورأس ثقة، ويعيد استخدام تضمينات النموذج الهدف ورأس LM الخاص به بدلًا من حمل نسخته الخاصة منهما.

انتقل تحفّظ واحد بين الإصدارين ويستحق سطرًا. في أغسطس، قال تقرير Liquid عن DSpark إن التسلسل الصادر «مطابق للجشع الأساسي بحكم التصميم». أما بطاقة نموذج المسودة 24B فتقول بدلًا من ذلك إن فروق الفاصلة العائمة بين التحقق المُجمّع وفك الترميز العادي «يمكن أن تنتج نصًا مختلفًا، بما في ذلك في ظل أخذ العينات الجشع». العبارتان قابلتان للدفاع عنهما — الأولى صحيحة في الحساب الدقيق — لكن إذا كان إطار التقييم لديك يقارن المخرجات بايتًا ببايت، فتوقّع أن يلاحظ ذلك.

جانب التكلفة في دفتر الحسابات

نموذج الصياغة ليس مجانيًا. فهو يشغل 655 ميغابايت بصيغة BF16 على وحدة معالجة الرسومات (أو 664 ميغابايت بصيغة F16 GGUF على وحدة المعالجة المركزية)، ويقيم في تجمّع الذاكرة نفسه الذي يقيم فيه النموذج الهدف، وكل خطوة يقترحها تكلّف تمريرة أمامية للتحقق عبر كتلة من الرموز بدلًا من رمز واحد. وفي هدف MoE، يكون هذا الجزء الأخير أعلى كلفة مما يبدو: فالتحقق من تسعة رموز ينشّط خبراء أكثر من فكّ تشفير رمز واحد، لذا فإن البايتات المنقولة لكل رمز تم التحقق منه تزداد، لا تنقص. وقد أشارت Liquid إلى هذا تحديدًا كسبب أن نموذج الصياغة بحجم 8B لديها لم يحقق سوى 1.18× على M4 Max رغم معدل القبول المرتفع.

مقابل ذلك، فإن التوفيرات كبيرة بما يكفي لقياسها بساعات GPU. وباستخدام أرقام B300 الخاصة بالمورّد من benchmarks/b300-fp8.csv، ولا نفعل أكثر من قسمة مليار رمز إخراج على الإنتاجية المرصودة:

• MATH-500، التزامن 1 — {{1}}324 توكن/ث{{/1}} بمفرده (857 ساعة GPU لكل مليار توكن) مقابل {{2}}853 توكن/ث{{/2}} مع نموذج المسودة ({{3}}326 ساعة GPU{{/3}}). خفض بمقدار {{4}}2.63×{{/4}} في زمن الحوسبة.

• MATH-500، التزامن 256 — 15,423 tok/s وحده (18.0 ساعة GPU) مقابل 27,579 tok/s مع المسوّد (10.1 ساعة GPU). خفض بمقدار 1.79×.

• GSM8K، التزامن 256 — 4,491 tok/s منفردًا (61.9 ساعة GPU) مقابل 9,660 tok/s مع المُقترِح (28.8 ساعة GPU). خفض بمقدار 2.15×.

• LiveCodeBench، مع تزامن 256 — 18,812 tok/s بمفرده (14.8 ساعة GPU) مقابل 25,231 tok/s مع نموذج المسودة (11.0 ساعة GPU). خفض قدره 1.34× فقط، وهو أضعف خلية في الجدول.

تلك نسب إنتاجية محوّلة إلى زمن، لا إلى مال، لأن المال يعتمد على ما تدفعه لكل ساعة GPU، ولن تختلق هذه المقالة سعرًا. لكن الترتيب يصح عند أي سعر: إرفاق نموذج المسودة يساوي ساعتين إلى ثلاث ساعات لكل عشر ساعات من حركة الاستدلال وتوليد الشيفرة عند التزامن المنخفض، ويساوي نحو ثلث ذلك عند التزامن المرتفع. إذا كان نشرك 24B وكيلًا لمستخدم واحد على محطة عمل، فالحجة قوية. وإذا كان نقطة نهاية دفعية مشبعة، فالحجة واقعية لكنها أرق بكثير مما يوحي به العنوان الرئيسي 2.4×.

حيث تبرّر أداة الصياغة وجودها، من حيث عبء العمل

التشتت بين مجموعات البيانات الثماني في جدول المورّد ليس ضوضاء؛ بل يناظر أنواع المطالبات، وهذا التناظر هو أنفع شيء في الإصدار. تراوح معدل القبول من 6.70 رمزًا لكل خطوة على MBPP وصولًا إلى 4.02 على LiveCodeBench. مجموعات البيانات التي سجّلت قيمًا مرتفعة هي التي يكون فيها مخرجات النموذج مقيّدة بالمطالبة — دوال قصيرة بأسلوب اختبارات الوحدة، وعمليات حسابية بمسار قابل للتحقق، وإجابات اختيار من متعدد. أما التي سجّلت قيمًا منخفضة فهي التي يتعين على النموذج فيها ابتكار حل طويل غير مقيّد: مسائل البرمجة التنافسية والرياضيات على نمط AIME.

هذا هو الحدس الذي ينبغي أن تحمله معك إلى تقييمك الخاص. نموذج استدلال بحجم 24B يُباع للعمل الوكيلي يقضي معظم رموز مخرجاته داخل سلسلة تفكير، وهي تبدو أشبه بـ LiveCodeBench منها بـ MBPP. أما النموذج المستخدم للاستخراج المنظم، أو التصنيف وفق مخطط، أو صيغة ثابتة لاستدعاء الأدوات، فيبدو أقرب بكثير إلى الصفوف ذات معدلات القبول العالية. إذا كان عبء عملك من النوع الأول، فتوقّع أن تقترب أكثر من الحد الأدنى 1.34× في النطاق بدلًا من الحد الأعلى 3.28×. لم ينشر أحد معدل قبول لكل عبء عمل لهذا المُقترِح، وثماني مجموعات البيانات في بطاقة النموذج هي أقرب شيء إلى دليل إرشادي.

في المقابل: إن نموذج 24B هو نموذج استدلال فقط. وتقول Liquid إنه يفكر دائمًا قبل الإجابة — إذ يُدرج قالب المحادثة وسم <think> تلقائيًا. وهذا أسوأ شكل ممكن للتخمين، لأن نطاق الاستدلال هو بالضبط الجزء الطويل منخفض القبول. سيظل كاتب المسودة مفيدًا؛ وسيكون أكثر فائدة في الإجابة النهائية وأقلّها في الجزء الذي يستغرق أطول وقت.

كيف تعرف ذلك على عتادك الخاص في غضون فترة بعد ظهر واحدة

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

على SGLang، شغّل النموذج الهدف مع إرفاق نموذج المسودة، بحجم كتلة 9 وعشرة رموز مسودة، ثم اقرأ مقاييس فك الترميز التخميني التي يبلغ عنها الخادم لكل طلب. يقع معدل القبول في جدول المورّد بين 0.33 و0.65 وفقًا لمجموعة البيانات؛ أما أي تشغيل يهبط إلى ما دون الصف المعني بكثير فيعني أن نموذج المسودة يخمّن خطأً وأنك تدفع تكلفة التحقق دون تحصيل التسريع. على llama.cpp مع ملف F16 GGUF المرافق، تحمل توقيتات كل استجابة draft_n وdraft_n_accepted مباشرة. اقسم أحدهما على الآخر.

ثمة تفصيلان تشغيليان سيكلّفانك ساعة كاملة إن أغفلتهما. يحتاج خادم SGLang إلى بناء يتضمّن مسار LFM2-MoE DSpark المدمج في 2026-08-31 — فعلى أي إصدار أقدم تكون بنية المُسوّدة مجهولة ببساطة. أما حجم الكتلة فهو خاصية من خصائص نقطة التحقق (checkpoint) وليس معاملًا حرًا: إذ يقيّد llama.cpp الخيار --spec-draft-n-max بالقيمة 9 المذكورة في البيانات الوصفية للملف المرافق، لذا فإن طلب 12 لا يجدي شيئًا.

السؤال الذي لا تستطيع هذه المقارنة الإجابة عنه

هناك نسخة من سؤال «هل أُرفِق نموذج المسودة؟» لا علاقة لها بوحدات معالجة الرسومات (GPUs)، وهي النسخة التي تواجهها معظم الفرق فعليًا. إذا استدعيت LFM2.5-24B-A2B عبر واجهة برمجة تطبيقات مستضافة، فقرار نموذج المسودة ليس قرارك. فإما أن تربط حزمة الخدمة مفكِّك ترميز تخمينيًا أو لا تربطه؛ أنت ترى رقمًا للرموز في الثانية وسعرًا، وكلاهما حُدِّد في المراحل الأولى. وتُدرج وحدة تحكم Liquid الخاصة بالسعة 24B سعرًا قدره 0.10 دولار لكل مليون رمز إدخال، و0.05 دولار للإدخال المخزَّن مؤقتًا، و1.00 دولار لكل مليون رمز إخراج — وهو سعر منشور يعكس بالفعل مسار فك الترميز الذي يشغّلونه، ويمكن أن يتغير دون إشعار.

هذا هو المفصل الذي يساعد فيه التوجيه بدلًا من أن يعقّد الأمور. فالاستدعاء المستضاف والنشر ذاتي الاستضافة ليسا خطتين متنافستين بقدر ما هما إعدادان للمقبض نفسه الخاص بالتكلفة: فالاستضافة الذاتية مع نموذج المسودة تقلل التكلفة لكل رمز إذا كان حجم استخدامك يُبقي وحدة GPU مشغولة، بينما تقلل نقطة النهاية المستضافة العمل اللازم للحصول على إجابة. صُمم OrcaRouter للحالة الثانية — مفتاح واحد عبر أكثر من 200 نموذج بهامش ربح 0% على سعر القائمة لدى المزوّد، لذا يظهر تغيّر سعر المزوّد على جانبنا في اليوم نفسه، مع تجاوز فشل تلقائي إذا تراجعت جودة أحد المزوّدين، وDSL للتوجيه لتقسيم حركة المرور بدلًا من تثبيت خلفية واحدة بشكل صارم. لا نخدم حاليًا عائلة LFM2.5، لذا بالنسبة لهذا النموذج تحديدًا يعني الجانب المستضاف واجهة Liquid البرمجية الخاصة بها أو وحدات GPU الخاصة بك؛ والمقارنة الجديرة بالتشغيل هي مع النماذج التي نوفرها فعلًا، مثل Qwen3.6-35B-A3B — النموذج الذي تقيس Liquid الأداء مقارنةً به في المهام الوكيلية — أو Gemma 4 26B-A4B.

إذن: أُرفِقه أم لا

أرفقه إذا كنت تخدم LFM2.5-24B-A2B بنفسك عند مستوى تزامن متواضع، خصوصًا للمخرجات المنظمة أو ذات الشكل الاستخراجي، وإذا كانت لديك مساحة إضافية قدرها 655 ميجابايت إلى جانب النموذج الهدف. تقول أرقام المورّد إنك ستقلّص زمن فك التشفير هناك إلى النصف أو الثلث تقريبًا، والجانب السلبي محدود: مُقترِح المسودة الرديء يكلّف تمريرة تحقق، لا إجابة خاطئة.

اتركه معطّلًا إذا كان نقطة النهاية لديك مشبعة أصلًا عند المئات، أو إذا كان ناتجك استدلالًا حرًّا طويلًا، أو إذا كنت بحاجة إلى أرقام Apple-silicon قبل أن تلتزم — فالبطاقة لا تحتوي على أي منها، وأقرب نظير من العائلة نفسها طُرح بمعامل 1.18× على MacBook. واتركه معطّلًا بالطبع إذا كنت لا تشغّل النموذج أصلًا: فالمُسوّدة (drafter) تحسين لنشرٍ ما، ولا يوجد شيء لتحسينه قبل أن يوجد هذا النشر.

ما يحسم ما تبقّى هو منشور من المورّد وقياسٌ على جهاز Mac. لا وجود لأيّ منهما حتى تاريخ 2026-10-21، وهي حالة غريبة لإصدار أصبحت أوزانه قابلة للتنزيل بالفعل — وبالنسبة لأي شخص يرغب في تشغيل عدّاد القبول بنفسه، فهي فرصة منخفضة الكلفة على نحو غير معتاد ليكون أول رقم مستقل على لوحة النتائج.