SubQ Snap 1.1 مقابل LFM2.5 2.6B Base: اشترِ القرار أم ابنِه من نقطة تفتيش

أهم كلمة في مقارنة بين SubQ Snap 1.1 وLFM2.5 2.6B Base هي الكلمة الأخيرة. تعني Base «مدرَّب مسبقًا». وهي تعني أن Liquid AI نشرت نقطة التحقق بعد نحو 34 تريليون رمز من التدريب، وقبل أي ضبط دقيق خاضع للإشراف أو تقطير أو تعلم معزز يحوّل نموذج اللغة إلى شيء يتبع التعليمات. لن يجيب عن سؤال. ولن يختار وسمًا. اطلب منه توجيه تذكرة دعم وسيواصل الموجّه الخاص بك بأسلوب النص الذي دُرّب عليه، وهذا ليس خللًا — بل هو الغرض من نقطة تحقق أساسية.

SubQ Snap 1.1، في المقابل، منتج مكتمل: نموذج القرار من Subquadratic، الذي أُطلق في 22 أكتوبر 2026، ويستقبل ما يصل إلى 384 ألف توكن من النصوص والصور إضافةً إلى مجموعة إجابات ثابتة، ثم يعيد اختيارًا معايرًا. إن وضعهما وجهًا لوجه كما لو كانا بديلين خطأ فئوي، وهو خطأ مفيد، لأنه يمثل بالضبط القرار الذي يواجهه الفريق عندما يريد تصنيفًا يعمل على عتاد يتحكم فيه. السؤال ليس "أي النموذجين أفضل". بل "هل تشتري القرار، أم تبنيه انطلاقًا من نقطة بداية؟"

ما الذي أصدرته Liquid AI فعليًا

وصل LFM2.5-2.6B Base في 4 أغسطس 2026 إلى جانب نظيره الخاضع للتدريب اللاحق، LFM2.5-2.6B، ضمن عائلة تمتد من 230 مليون معامل وصولًا إلى مزيج خبراء بحجم 24B. والمعمارية هي تصميم LFM2 من Liquid: ثلاثون طبقة، اثنتان وعشرون منها كتل التفافية قصيرة مزدوجة البوابات وثماني طبقات انتباه مجمعة الاستعلامات، ومفردات من 128,000 رمز، ونافذة سياق 128K أُضيفت في مرحلة تمديد أثناء التدريب. وعند 2.69 مليار معامل، يشغل نحو 2.5 غيغابايت، ويعمل بسرعة نحو 220 رمزًا في الثانية على Apple M5 Max، ونحو 113 على Ryzen AI Max+، وحوالي 30 على هاتف.

الشقيق instruct هو حيث توجد الأرقام المثيرة، وهي جديرة بالقراءة كمقياس لقيمة التدريب اللاحق. تُبلغ Liquid عن AIME25 عند 51.87، وLiveCodeBench v6 عند 59.41، وIFBench عند 59.17، وMulti-IF عند 80.07، وBFCLv4 عند 56.88، وToolSandbox عند 77.83 — جميعها مُبلَّغ عنها من المورّد، وجميعها على النموذج المدرَّب لاحقًا. لا يملك نقطة التحقق الأساسية درجات مماثلة في اتباع التعليمات لأنه لا يستطيع اتباع التعليمات. تلك الفجوة، بين نقطة تحقق ونموذج يمكنك طرح سؤال عليه، هي أربع مراحل من التدريب اللاحق: جولتان من الضبط الدقيق الخاضع للإشراف، وتخصص المعلم حسب المجال، والتقطير متعدد المجالات على السياسة، والتعلم المعزز الوكيلي داخل أُطر عمل حقيقية.

تقول Liquid أيضًا بوضوح ما لا يصلح له النموذج: البرمجة الوكيلية، والأعمال الكثيفة المعرفة. وهذا بيان تموضع أكثر صدقًا مما تنشره معظم المختبرات، ويستحق أن يؤخذ على ظاهره.

المواصفات، جنبًا إلى جنب

• ما هو — LFM2.5 2.6B Base هو نقطة تحقق مدربة مسبقًا دون ضبط بالتعليمات؛ أما SubQ Snap 1.1 فهو نموذج قرار مستضاف بواجهة API ذات إجابات ثابتة.

• السياق — 128K توكن لـ LFM2.5 2.6B Base؛ 384K توكن لـ Snap 1.1.

• المدخلات — نص فقط لـ LFM2.5 2.6B Base؛ نص وصور لـ Snap 1.1.

• المُخرَج — توليد رموز حرّ الشكل، أو أي رأس تدرّبه فوق ذلك، بالنسبة إلى LFM2.5 2.6B Base؛ اختيار أو درجة مصحوبة باحتمال بالنسبة إلى Snap 1.1.

• السعر — للاستضافة الذاتية فقط، بلا فاتورة لكل رمز، لـ LFM2.5 2.6B Base؛ $0.04 لكل 1M رمز إدخال، والإخراج مجاني، لـ Snap 1.1.

• الترخيص — LFM Open License v1.0، يُسمح بالاستخدام التجاري مع حدّ إيرادات، لنموذج Liquid؛ لا توجد أوزان على الإطلاق لـ Snap.

• البصمة — نحو 2.5 غيغابايت وقابل للتشغيل على هاتف لـ LFM2.5 2.6B Base؛ استدعاء شبكي لـ Snap 1.1.

الفجوة بين نقطة حفظ (checkpoint) ومصنّف

لتحويل LFM2.5 2.6B Base إلى شيء يفعل ما يفعله Snap 1.1، تحتاج إلى خمسة أشياء، وواحد منها فقط هو النموذج.

تحتاج إلى بيانات موسومة — بضعة آلاف من الأمثلة لكل فئة نقطة بداية معقولة لمهمة توجيه ضيقة، وأكثر من ذلك بكثير إذا كانت الفئات غير متوازنة أو كان الحد الفاصل دقيقًا. وتحتاج إلى جولة تدريب: رأس تصنيف أو محوّل LoRA، فوق نقطة تحقق أساسية لم ترَ أي تعليمة قط، ما يعني أن الضبط الدقيق يقوم بعمل تكييف المهمة واتباع التعليمات في آن واحد. وتحتاج إلى معايرة، لأن درجة softmax ليست احتمالًا معايَرًا، وحدّ التوجيه المحدَّد على درجة غير معايَرة هو حدّ تحدده التخمين. وتحتاج إلى حزمة تقييم تتولى صيانتها، لأن النموذج سينحرف مع تغيّر حركة المرور لديك. وتحتاج إلى بنية تحتية للتقديم — llama.cpp أو MLX أو vLLM أو ONNX، وكلها تدعم هذه البنية.

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

الترخيص ليس Apache

تُطلق Liquid نموذج LFM2.5 بموجب LFM Open License v1.0. يُسمح بالاستخدام التجاري، لكن المنظمات التي تتجاوز إيراداتها السنوية 10 ملايين دولار تحتاج إلى ترخيص تجاري منفصل. هذا طرح مختلف جوهريًا عن Apache 2.0 الخاص بـ Granite أو Apache 2.0 الخاص بـ Gemma، وهو نوع البند الذي يُكتشف متأخرًا، من قبل القسم القانوني، بعد أن يعمل النموذج الأولي. إذا كنت شركة ناشئة تحت الحد، فلن يكلفك شيئًا اليوم وقد يكلفك شيئًا لاحقًا. وإذا كنت فوقه، فسعّر الترخيص قبل أن تسعّر وحدة معالجة الرسومات.

حيث تتفوق نقطة التحقق الأساسية تفوقًا قاطعًا

النشر المعزول هو الحالة الأقوى، وليست مجرد حالة قريبة. فطراز بحجم 2.5 جيجابايت يعمل على هاتف أو حاسوب محمول أو حاوية دون أي مسار شبكي هو الخيار الوحيد لتطبيق ميداني، أو بيئة مصنفة، أو جهاز يُشحن إلى العملاء. ولا يستطيع Snap 1.1 الدخول إلى أي من تلك الحالات. فهو واجهة برمجية (API)، ولا يوجد إصدار منه يعمل محليًا.

اقتصاديات الحجم هي الحالة الثانية، لكنها تتطلب حجمًا حقيقيًا لتكون ذات أهمية. عند مليوني قرار شهريًا مع 20,000 رمز سياق لكل منها — 40 مليار رمز إدخال — تبلغ تكلفة Snap 1.1 نحو 1,600 دولار شهريًا، أو أقل قليلًا من 20,000 دولار سنويًا. أما نموذج واحد مضبوط بدقة بحجم 2.6B يخدم هذه الحركة على عتاد تملكه بالفعل، فليس لديه تكلفة حدية. وتقع نقطة التعادل تقريبًا عند النقطة التي تتجاوز فيها فاتورة API السنوية التكلفة الهندسية للضبط الدقيق بالإضافة إلى العتاد، وهي بالنسبة لمعظم الفرق تبعد سنة أو سنتين، لا شهرًا.

التحكم الكامل هو الخيار الثالث. النموذج الذي دربته على تصنيفاتك الخاصة يفعل ما دربته عليه، ولا شيء غيره. إن Snap 1.1 نموذج قرار عام بدقة 20% على مؤشر Artificial Analysis Decision Index v1.0 — وتأتي درجة مؤشره البالغة 65 أساسًا من الامتناع عمّا لا يستطيع الإجابة عنه، بمعدل عدم اختلاق مُبلَّغ عنه 86%. ومن المرجّح أن يتفوق نموذج بحجم 2.6B مضبوط بدقة على مجالك على تلك الدقة في مهمتك، ولن يمتنع أبدًا ما لم تدربه على ذلك.

حيث يتفوق Snap 1.1 بلا منازع

يُقاس الوقت حتى أول قرار بالدقائق، لا بدورات التطوير. لا توجد بيانات تدريب لجمعها، ولا رأس نموذج لملاءمته، ولا منحنى معايرة لرسمه. ترسل مستندًا وقائمة خيارات فتحصل على احتمال، والاحتمال هو الناتج.

السياق الطويل هو الفرق الثاني، وهو فرق معماري وليس عارضًا. يعالج Snap ‏384K رمزًا في تمريرة أمامية واحدة بحساب ثابت لكل رمز. أما LFM2.5 2.6B Base فلديه نافذة 128K، وبوصفه نموذجًا يضم 2.6 مليار معامل، فإن نطاق الاسترجاع الفعلي لديه سيكون أقصر بكثير من النطاق الاسمي — يُبلّغ نموذج Liquid الشقيق عن درجة AA-Omniscience قدرها −29.50، وهي مقياس لمدى معرفة النموذج الصغير، لا لمدى جودة قراءته، لكنها تضبط التوقعات.

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

أي واحد إذن؟

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

خذ نقطة التحقق Base إذا كنت بحاجة إلى أن يعيش النموذج في مكان لا تصل إليه الشبكة، أو إذا كنت تنوي امتلاك الأوزان بشكل دائم وتملك القدرة الهندسية التي تجعل ذلك يستحق العناء. في هذه الحالة، احسب تكلفة مسألة الترخيص إلى جانب جولة التدريب.

لا يوجد أيٌّ منهما في كتالوج OrcaRouter، ولن يوجد: فـ LFM2.5 2.6B Base هو نقطة تفتيش محلية، وSnap 1.1 لا يُقدَّم إلا عبر واجهة Subquadratic API على console.subq.ai. وما تقوم به OrcaRouter في خط معالجة مبني حول أيٍّ منهما هو الطبقة التي تحوّل القرار إلى إجراء — أكثر من 200 نموذج توليد خلف مفتاح واحد، وسعر قائمة المزوّد يُمرَّر كما هو دون أي هامش ربح (0%)، وتجاوز فشل تلقائي بحيث لا يتحوّل نداء توجيه يهبط على نموذج غير متاح مؤقتًا إلى طلب مُسقَط. فلطبقة القرار وطبقة الكتابة أنماط فشل مختلفة؛ ومن الجدير عدم وضعهما على الاعتماد نفسه.

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