LFM2.5-8B-A1B-DSpark مقابل LFM2.5-2.6B-Base: جزء السرعة مقابل المادة الخام

رتّب عائلة LFM2.5 حسب ما يمكن أن يفعله كل checkpoint بمفرده، فتجد LFM2.5-8B-A1B-DSpark وLFM2.5-2.6B-Base على طرفَي الخط المتقابلين — ولا يستطيع أيٌّ من الطرفين الإجابة عن سؤال. الأول نموذج مسوّدة بعدد 327.7 مليون معامل، وُجد خصيصًا ليجعل نموذج خليط الخبراء الطرفي من Liquid AI يولّد الرموز أسرع. والثاني checkpoint خام مُدرَّب مسبقًا بعدد 2.69 مليار معامل، وُجد خصيصًا ليُضبَط بدقّة ليصبح شيئًا آخر. كِلاهما صدر في أغسطس 2026 بموجب رخصة LFM Open License v1.0 من Liquid، وكِلاهما على بُعد تنزيل واحد على Hugging Face، وكِلاهما سهل جدًا أن يُلتقط بالخطأ — لأن اسميهما يوحيان بأنهما نسختان من الشيء نفسه.

الأسماء هي الفخ. "DSpark" يبدو وكأنه الرائد الجديد اللامع للعائلة، و"Base" يبدو وكأنه الخيار الافتراضي البسيط الذي يمكنك تشغيله فعليًا. كلاهما غير صحيح. نقطة التحقق DSpark لا يمكنها الإجابة على أي شيء بمفردها — إنها تقترح فقط رموزًا لـ LFM2.5-8B-A1B للتحقق منها. وBase لا يمكنها الإجابة على أي شيء أيضًا، ولكن للسبب المعاكس — فهي أساس غير مضبوط يتنبأ بالنص لكنها لم تخضع أبدًا لتدريب لاحق لتصبح نموذج محادثة أو وكيلًا. هذه ليست منافسة؛ إنها خط أنابيب. نقطة التحقق الأولى تقع في نهاية بنية التقديم، والأخرى في بداية عملية التدريب.

نقطتا تفتيش تشتركان في الاسم، لا في الوظيفة.

LFM2.5-8B-A1B-DSpark (صدر في 20 أغسطس 2026) هو نموذج مسودة لفك الترميز التخميني: شبكة تعتمد على الانتباه فقط بخمس طبقات، وكتلة من تسعة رموز مقترحة لكل خطوة، ورأس ماركوف على مفردات الهدف المكونة من 128,000 رمز. تقوم بتحميله بجانب LFM2.5-8B-A1B — وهو نموذج MoE بإجمالي 8.3 مليار معلمة ونحو 1.5 مليار معلمة نشطة، صدر في 28 مايو — وتقوم المسودة بتخمين الرموز القليلة التالية، بينما يتحقق الهدف من الكتلة بأكملها في تمرير أمامي واحد، محتفظًا بما يقبله منها. ولأن الهدف يفحص كل رمز، فإن المخرجات في فك الترميز الجشع مطابقة تمامًا لتشغيل LFM2.5-8B-A1B وحده: "بلا فقدان بحكم البناء" على حد تعبير Liquid. المسودة جزء للسرعة، وليست دماغًا. صدرت إلى جانب مسودات شقيقة لـ LFM2.5-1.2B-Instruct و LFM2.5-2.6B، كل منها بصيغتي Safetensors وGGUF، مع دعم من اليوم الأول في SGLang وllama.cpp.

LFM2.5-2.6B-Base (صدر في 4 أغسطس 2026) هو الطرف الآخر من خط الإنتاج: أساس بعدد 2.69 مليار معلمة في كومة هجينة من 30 طبقة — 22 كتلة التفاف قصير ثنائية البوابة بالإضافة إلى 8 كتل انتباه استعلامات مجمّعة — مُدرَّب مسبقًا على حوالي 34 تريليون رمز، مع مرحلة تدريب وسيطة تمدد السياق إلى 128 ألف. لا يحتوي على قالب محادثة، ولا ضبط تعليمات، ولا معايير منشورة، وبطاقة النموذج الخاصة بـ Liquid توصي به فقط للضبط الدقيق المكثف. الغرض الكامل منه هو أن يكون المادة الخام التي يحوّلها خط أنابيب ما بعد التدريب ذو المراحل الأربع — جولتا SFT، وتخصص المعلّم، والتقطير على السياسة، ثم التعلم المعزز الوكيل — إلى وكيل استدعاء الأدوات LFM2.5-2.6B. نفس العائلة، نفس الترخيص، نفس صفحة التنزيل. وظائف مختلفة تمامًا.

جنبًا إلى جنب: سبعة أبعاد، وظيفتان

لأن نقطتي التفتيش تؤديان وظائف مختلفة، فإن المقارنة النزيهة تُبقي أدوار الجانبين واضحة:

• ما هو — LFM2.5-8B-A1B-DSpark هو نموذج مسودة لفك الترميز التخميني بحجم 0.3B؛ بينما LFM2.5-2.6B-Base هو نموذج أساس خام مُدرَّب مسبقًا بحجم 2.69B.

• ما يعمل به — مسودة DSpark تقترن مع LFM2.5-8B-A1B MoE (إجمالي 8.3B، نحو 1.5B نشط لكل توكين)؛ أما Base فيعمل بمفرده، لكن فقط كتنبؤ نصي غير مضبوط.

• الاستخدام المستقل — لا ينتج DSpark شيئًا بمفرده؛ فهو فقط يسرّع هدفًا. ينتج Base نصًا لكن دون أي سلوك منتج مفيد — لا اتباع للتعليمات، ولا استدعاء للأدوات، ولا قالب محادثة.

• جودة المخرجات — ترث DSpark مخرجات الهدف الجشعة الدقيقة، لأن كل توكن مقترح يتم التحقق منه؛ ليس لدى Base أي معايير منشورة لأي مهمة، بحكم التصميم.

• السرعة — يضيف DSpark متوسطًا مُقاسًا من قبل البائع يبلغ 2.54× على H100 (حتى 3.18× على MATH500) و1.18× على M4 Max إلى هدفه، مع العلم أن هذا القياس غير مُعاد إنتاجه؛ بينما لا يقدم Base أي ادعاء بسرعة الاستدلال إطلاقًا.

• استهلاك الذاكرة — يضيف DSpark حوالي 0.3 جيجابايت من أوزان المسودة إلى جانب النموذج المستهدف؛ أما Base فهو النموذج الكامل بحجم 2.69B، ويمكن تشغيله بأقل من 2.5 جيجابايت، وهو أصغر نموذج أساسي جاد في العائلة.

{{1}}التنسيقات والتوفر{{/1}} — تأتي DSpark بصيغ Safetensors وGGUF مع دعم فوري من اليوم الأول لكل من SGLang وllama.cpp؛ بينما تأتي Base بصيغ {{2}}Safetensors إضافة إلى GGUF وONNX وMLX{{/2}}، وتعمل على Transformers وvLLM وSGLang وllama.cpp وMLX. لا يُقدَّم أي منهما عبر أي مزوّد استدلال اليوم — كلاهما نقطتا تحقق تُستضافان ذاتيًا.

الأرقام الوحيدة في هذه المواجهة جاءت من مختبر واحد

كل ما هو كمي هنا هو قياس من مورّد واحد، أُخذ في يوم إصدار المسودة ولم يُكرَّر بشكل مستقل بعد — اقرأه باعتباره واعدًا، لا مُتحقَّقًا منه. قامت Liquid بقياس LFM2.5-8B-A1B-DSpark عند حجم دفعة 1 ودرجة حرارة 0، على وحدة H100 واحدة بسعة 80 جيجابايت بصيغة BF16 عبر SGLang، وعلى MacBook Pro بشريحة M4 Max بنسق GGUF بدقة FP16 عبر نوى Metal التجريبية في llama.cpp. على H100، حقّق الزوج متوسطًا قدره 2.54× (418 → 1,074 رمزًا في الثانية)، مع أفضل نتيجة منفردة بلغت 3.18× على MATH500 (428 → 1,362 رمزًا/ثانية) ومتوسط قبول يبلغ حوالي 7 من كل 10 رموز مقترحة. على M4 Max، بلغ متوسط الزوج نفسه 1.18× فقط (90 → 106 رموز/ثانية) — وهي الحالة الحدّية على الجهاز التي نبّهت إليها Liquid نفسها، لأن التحقق من كتلة الرموز يُفعّل عددًا أكبر من الخبراء في الواجهة الخلفية الحالية لـ MoE على Metal وينقل المزيد من حركة الأوزان عبر ناقل الذاكرة.

الجانب الأساسي في هذه المقارنة لا يملك أي أرقام على الإطلاق، وهذا الغياب هو بحد ذاته المواصفة. لقد خضع LFM2.5-2.6B-Base للتدريب المسبق، وليس للتدريب اللاحق؛ ولم يُقيَّم أبدًا من حيث المحادثة أو استخدام الأدوات أو سلوك الوكلاء، لأن أحدًا لم يقصد استخدامه بتلك الطريقة. أرقامه ذات الدلالة معمارية بطبيعتها: 2.69 مليار معلمة، وسياق من 128 ألف رمز، ومُقسِّم رموز يدعم 16 لغة، وأقل من 2.5 جيجابايت للتشغيل. أنت لا تختبر نموذجًا أساسيًا؛ بل تختبر ما يتحول إليه عبر الضبط الدقيق.

هناك مفارقة عائلية واحدة جديرة بالذكر قبل أن تقرر أي شيء. المسودة التي تدور حولها هذه المقالة — تلك الخاصة بـ 8B-A1B — هي تحديدًا الأقل كسبًا على جهاز محمول (1.18×)، بينما المسودة الشقيقة لعائلة 2.6B، التي تسرّع الشقيق المدرب لاحقًا لهذه القاعدة ذاتها، تحقق متوسط 2.27× على M4 Max مع خفضٍ بنسبة 57% في زمن استدعاء الوظائف متعددة الأدوات. إذا كان الجهاز المعني هاتفًا أو حاسوبًا محمولًا بدلًا من صندوق GPU، فإن مسار 2.6B هو حيث تكمن قصة السرعة.

إذن أي واحد تقوم بتحميله؟

لست مضطرًا أبدًا للاختيار بين هذين مباشرة، لأنهما ليسا بديلين — لكن عليك أن تعرف أيَّ وظيفةٍ أنت فيها:

إذا كنت تشغّل نموذج LFM2.5-8B-A1B على وحدات معالجة رسومية (GPUs) تملكها، وترغب في الحصول على مزيد من الرموز (tokens) في الثانية من نفس السيليكون، فإن LFM2.5-8B-A1B-DSpark هو إضافة عكوسة: قم ببناء SGLang أو llama.cpp مع تكاملات DSpark الصادرة في 20 أغسطس، وحدد اسم نموذج المسودة (draft) في أمر الإطلاق، وحافظ على فك الترميز الجشع (greedy decoding)، وسيتم قراءة حجم الكتلة تلقائيًا من إعدادات نموذج المسودة. الجانب الإيجابي هو إنتاجية أعلى بنحو 2.5 مرة مع عدم تغيير المخرجات إطلاقًا؛ أما الجانب السلبي فهو زيادة وزن النموذج بمقدار 0.3 جيجابايت وبناء جديد بما يكفي لاحتواء طلبات السحب (PRs). أزل الخيارين الخاصين بالتخمين (speculative flags) وستعود إلى النموذج المستهدف العادي.

إذا كنت تريد بناء مختص خاص بك — نموذج مجال، أو مساعدًا بلغة مخصصة، أو ضبطًا دقيقًا على بيانات مملوكة — فإن LFM2.5-2.6B-Base يُعد أحد أرخص نقاط الانطلاق الجادة في نظام الأوزان المفتوحة: 2.6B، وأقل من 2.5GB، وسياق 128K، ومجزئ نصوص متعدد اللغات. لا يمكن لنقطة تفتيش DSpark مساعدتك في ذلك على الإطلاق، لأنها ليست نموذجًا أساسيًا.

إذا كنت تريد حقًا وكيل Liquid الذي يعمل على الجهاز — استدعاء الأدوات، المهام متعددة الخطوات — فأنت لا تريد أيًا من هذين. أنت تريد نموذج LFM2.5-2.6B المُدرَّب لاحقًا، ويمكنك بعد ذلك أن تقرر ما إذا كنت سترفق به مسودته الخاصة. النموذج Base هو مادة خام لمن يريدون التدريب؛ أما مسودة 8B-A1B فهي جزء تسريع لمن يوزعون MoE بالفعل. الخطوة الخاطئة هي تنزيل Base لأنك أردت وكيلًا أسرع، أو تنزيل نموذج المسودة لأنك أردت أساسًا للتدريب.

حيث يتصل الاثنان — وأين يأتي دور جهاز التوجيه

كلا نقطتي التحقق مخصصتان للاستضافة الذاتية. المسودة هي ملحق لطبقة التقديم لا يوجد إلا داخل بيئة SGLang أو llama.cpp الخاصة بك؛ أما Base فهو نتاج تدريبي. لا يظهر أي منهما في أي كتالوج مستضاف، ولا يوجد لأي منهما سعر قائمة لكل رمز. ما يعنيه هذا عمليًا هو أن أيًا من المسارين ينتهي به المطاف بجوار النماذج المستضافة التي تستدعيها بالفعل — وهذا المزيج هو بالضبط البنية التي توجد طبقة التوجيه لإزالتها.

على جانب التقديم، اقتصاديات نموذج المسودة بسيطة وحقيقية: 2.5× من التوكنات في الثانية من نفس وحدة معالجة الرسومات (GPU) تعني وقتًا أقل بمقدار 2.5×، وتقريبًا عددًا أقل بمقدار 2.5× من وحدات معالجة الرسومات لنفس عبء العمل، دون أي تغيير في الجودة. لكن هذه الرافعة لا تتوفر إلا إذا كنت تمتلك الاستدلال. فبمجرد استدعاء 8B-A1B عبر واجهة برمجة التطبيقات (API)، يبقى التسريع لدى المزوّد — وهنا تصبح المقارنة على جانب الـ API هي المهمة: ما يتقاضاه المزوّد، وما إذا كان انخفاض السعر يصل إليك في اليوم الذي يُعلن عنه. هذا هو جوهر موجّه التمرير المباشر: واجهة API واحدة عبر أكثر من 200 نموذج، وأسعار المزوّدين المدرجة تُمرَّر بهامش ربح 0%، بحيث يكون تخفيض البائع فعّالًا لديك فورًا، مع تبديل تلقائي عند الأعطال بحيث لا يتحول ارتفاع زمن الاستجابة لمزوّد واحد إلى زمن استجابة لديك. يمكنك أيضًا تمرير حزمة LFM المستضافة ذاتيًا عبر نفس نقطة النهاية، وهكذا تجرّب نموذج مسودة جديدًا كليًا على حركة مرور حقيقية دون أن تراهن على مسار إنتاجي له.

يتشارك كل من LFM2.5-8B-A1B-DSpark وLFM2.5-2.6B-Base في اسم العائلة لكن وظيفتيهما متعاكستان: أحدهما قطعة سرعة تُركَّب على حافة MoE، والآخر هو الدماغ غير المضبوط الذي ينمو منه وكيل 2.6B. لا يعمل أي منهما بمفرده. اختر المُسرِّع لتسريع MoE تقدّمه بالفعل على وحدات GPU، واختر Base لضبط أساس 2.6B وتحويله إلى ما تملكه، وتجاهل كليهما إذا كان ما تريده وكيلًا يعمل — لأن الشيء المشترك بين النقطتين أن أياً منهما، بمفرده، لا يفعل شيئًا يمكنك استخدامه.

الأسئلة الشائعة

هل يمكنني تشغيل LFM2.5-8B-A1B-DSpark بمفرده؟

لا. إنه نموذج مسودة لا يمتلك مخرجًا مستقلًا — فهو يقترح توكينات مرشحة يتحقق منها النموذج الهدف LFM2.5-8B-A1B لاحقًا، لذلك فهو موجود فقط داخل حزمة خدمة فك تخميني مبنية على تكاملات SGLang أو llama.cpp الصادرة في 20 أغسطس. تنزيله بمفرده لا يمنحك شيئًا يمكنك الاستعلام عنه.

هل LFM2.5-2.6B-Base هو نقطة التحقق التي تعمل على الجهاز كوكيل؟

ليس كما هو. قاعدة Base هي الأساس الخام المُدرَّب مسبقًا دون ضبط تعليمات ودون قالب محادثة. النموذج الذي يعمل كعميل على الجهاز من Liquid هو LFM2.5-2.6B المُدرَّب لاحقًا، وهو مُنتَج من Base عبر خط أنابيب ما بعد التدريب المكوَّن من أربع مراحل — وإذا أردته أسرع، فيُقرن مع مسودة LFM2.5-2.6B-DSpark.