تسريب LFM3: عائلة Liquid AI التالية تتألف من أربعة نماذج Omni صغيرة

طلب سحب فُتح على GitHub في 27 أكتوبر 2026 يريد أن يعلّم SGLang كيفية تقديم عائلة نماذج غير موجودة علنًا. يسمّي أربع نقاط حفظ — LFM3-1.7B وLFM3-VL-2B وLFM3-Audio-2B وLFM3-Omni-2B — ويُقرأ على خلفية ما صدر فعليًا من LFM2.5-2.6B وLFM2.5-24B-A2B وكأنه مخطط لما تبنيه Liquid AI لاحقًا. طلب السحب غير مدموج. جميع فحوصات CI الثلاثة الخاصة به تفشل. لم تعلن Liquid AI أيًا من ذلك. ذلك الفرق غير المدموج هو السجل العام الكامل لـ LFM3 حتى اليوم، وهو أكثر إفادة من معظم منشورات الإطلاق — بشرط أن تقرأه على حقيقته.

لنكن إذن دقيقين بشأن الأدلة، لأنها ضئيلة في اتجاه واحد ومفصّلة على نحو غير معتاد في اتجاه آخر. لا شيء هنا يمثّل تاريخ إصدار أو سعرًا أو شرط ترخيص أو درجة اختبار أداء. لا توجد بطاقة نموذج LFM3، ولا مستودع على Hugging Face، ولا منشور مدونة، ولا قائمة API. ما هو موجود هو مساهمة من tugot17 — Piotr Mazurek، الذي أضاف خلال الشهرين الماضيين دعم تشغيل LFM في SGLang وllama.cpp وmlx-vlm — إضافةً إلى المواد المنشورة من Liquid نفسها عن جيل LFM2.5 الذي هي على وشك أن يحلّ محلّه. كل ما أدناه موسوم وفقًا لذلك.

ما الذي يضعه طلب السحب فعليًا على الطاولة

عنوان الـPR هو [Feat] lfm3: إضافة دعم النص والرؤية والصوت وOmni، ويحمل علامتين توضّحان نوع التغيير: jit-kernel وMulti-modal. وهو يضيف توليد نص أصلي لعائلة مكوّنة من أربعة، لكل منها مسار checkpoint خاص به:

• LFM3-1.7B — إدخال نص وإخراج نص، النموذج اللغوي البسيط في قاعدة العائلة

• LFM3-VL-2B — إدخال النص والصور والفيديو، وإخراج النص

• LFM3-Audio-2B — إدخال نص وصوت، وإخراج نص، وموصول أيضًا بنقطة النهاية /v1/audio/transcriptions

• LFM3-Omni-2B — إدخال نص وصور وصوت وفيديو، بما في ذلك المسار الصوتي للفيديو نفسه، وإخراج نص

ثمة تفصيل واحد في تلك القائمة يستحق التوقف عنده. كل نسخة تُخرِج نصًا. لا يوجد أي مسار لإخراج الصوت في أي مكان في الـPR، والسطح غير المحادثي لنموذج الصوت هو النسخ — كلام يدخل، ونص يخرج. وهذا أضيق من خط الصوت الحالي لدى Liquid، حيث يُوثَّق LFM2.5-Audio-1.5B بأنه يتعامل مع ASR وTTS والمحادثة الصوتية المتداخلة في نموذج واحد. إما أن أول إصدار من SGLang يغطي فقط النصف المولِّد للنص من LFM3-Audio، أو أن عائلة omni تُسقِط توليف الكلام فعلًا. لا يستطيع الـPR حسم أيّهما، وأي شخص يخبرك بأنه يفعل ذلك فإنه يخمّن. تعامل مع "LFM3 speaks" على أنها غير مُثبتة.

باقي الفرق تفاصيل تنفيذية، لكنها مع ذلك تؤرخ العمل. مشفّرات الرؤية والصوت مع مُسقِطاتها، وعمود فقري مشترك، وتكامل تخزين مؤقت هجين، ونوى التفاف CuTe DSL مع بديل PyTorch، وملاحظة بأن FlashInfer يعتمد افتراضيًا على paged prefill كي تعمل انتباه النافذة المنزلقة كما ينبغي. جرى التحقق على H100s بدقة FP16 باستخدام ما يسميه الوصف نقاط تحقق تطويرية — أربع كلمات تهم لاحقًا.

جملة الهندسة المعمارية، والرقم الذي سيُخطئ الناس في قراءته

يصف PR نموذج LFM3 بأنه عمود فقري مشترك من الالتفافات القصيرة المبوّبة مع انتباه كامل وانتباه بنافذة منزلقة. وهذا استمرار لسلالة LFM2 لا استبدال لها: فـ LFM2.5-24B-A2B موثّق بأنه مزيج هجين من الالتفافات القصيرة المبوّبة والانتباه المجمّع للاستعلامات عبر 40 طبقة. وما يبدو جديدًا في التسريب هو مكوّن النافذة المنزلقة الصريح الذي يجاور الانتباه الكامل.

تشير ملاحظات التحقق إلى مُوجّه (prompt) يعمل بما يتجاوز نافذة منزلقة بطول 256 رمزًا، وهذا هو الرقم الذي سيُقتبس خارج سياقه طوال الأسبوع. إنه ليس طول سياق LFM3. في التصميم الهجين، لا تحتاج طبقات الانتباه إلا إلى الرؤية محليًا لأن طبقات الالتفاف تحمل الإشارة طويلة المدى — هذا هو المفهوم الأساسي للبنية، وهو سبب قدرة العائلة على الاحتفاظ بـ 131,072 رمزًا من السياق على LFM2.5-24B-A2B بينما معظم طبقاتها لا تقوم بانتباه تربيعي إطلاقًا. نافذة انتباه بطول 256 رمزًا هي عبارة عن بيان حول المكان الذي ينظر إليه النموذج داخل طبقة واحدة، وليس حول مقدار النص الذي يمكنه قبوله. لا يذكر PR إجمالي سياق LFM3، ولا أحد خارج Liquid يعرفه بعد.

لماذا يُعد طلب السحب في وقت التشغيل إشارةً وليس ضوضاءً؟

من المعقول أن ننظر بارتياب إلى استنتاج استراتيجية المنتج من فروق البنية التحتية. لكن في هذه الحالة تحديدًا، النمط متسق أكثر من أن يُتجاهل، لأن Liquid تُطلق دعم المحركات مع الأوزان بدلًا من أن يأتي بعدها. يُدرج LFM2.5-2.6B كلاً من llama.cpp وMLX وvLLM وSGLang وONNX وTransformers 5.0+ ضمن أهداف اليوم الأول. وكان LFM2.5-24B-A2B مدعومًا في llama.cpp وMLX وvLLM وSGLang وONNX عند الإطلاق. أي عائلة تصل وخمس بيئات تشغيل جاهزة لا بد أن تكون نوى الحوسبة (kernels) الخاصة بها قد كُتبت قبل الإعلان، ما يعني أن طلبات السحب (PRs) تصل أولًا ثم تأتي تدوينة المدونة بعد ذلك.

يتوافق المؤلف مع ذلك التسلسل الزمني تمامًا. إن تاريخ مازوريك العلني سلسلة من أعمال دمج LFM: فك التشفير التخميني DSpark لـ LFM2-VL في SGLang في سبتمبر، وإصلاحات نموذج المسودة LFM2.5-VL-3B وDSpark في llama.cpp في الشهر نفسه، وفك التشفير التخميني الموروث من النموذج النصي في mlx-vlm، وإعادة استخدام تكوين LFM2-MoE في SGLang في 13 أكتوبر. وLFM3 هو المدخل التالي في ذلك التسلسل، وقد سُجّل في عطلة نهاية الأسبوع التي غيّرت فيها العائلة أسماءها.

الغيابان دالّان بقدر ما الحضور دال. فلا يوجد طلب سحب مطابق في Hugging Face Transformers لـ LFM3 — إذ لا يُعيد البحث في ذلك المستودع شيئًا — كما أن طلب السحب الخاص بـ SGLang يحمّل نقاط التحقق الخاصة به عبر إصدار Transformers 5.19.0 القياسي باستخدام --trust-remote-code، وهو ما تفعله عندما لا تكون البنية بعد أصلية في المكتبة. وهناك أيضًا commit يرفض صراحةً فك التشفير التخميني لـ LFM3، لذا لم يُنقل بعد عمل DSpark الذي شُحن مع الجيل 2.5. مبكر، وغير مكتمل بحكم التصميم.

السؤال المتعلق بالحجم الذي لم يُجب عنه أحد

هنا يتجه التسريب والطموح المعلن في اتجاهين متعاكسين، والتوتر هو أكثر ما يثير الاهتمام في الوثيقة.

وصف ماكسيم لابون، رئيس التدريب المسبق في Liquid، هدف LFM3 بأنه اختبار ما إذا كان نهج الالتفاف القصير الذي ينجح على نطاق يتراوح من 350 مليونًا إلى 1.2 مليار معلمة يمكن أن يصمد بما يتجاوز 10 مليارات معلمة — وهو النطاق الذي كانت فيه معماريات الانتباه تتمتع بالميزة تاريخيًا. وهذه مسألة تتعلق بالتوسع، وهي تستلزم نموذجًا كبيرًا.

نقاط التحقق المسرّبة هي 1.7B وثلاث بحجم 2B. ولا واحدة منها تتجاوز العتبة التي يتعلق بها السؤال.

تظل قراءتان قائمتين. الأولى أن هذه هي الموجة الأولى المدمجة — عائلة omni للهواتف والسيارات قبل وصول نظير أكبر، وهو ما يتطابق مع طريقة Liquid في الريادة دائمًا بالنماذج الصغيرة، ومع وصف الـ PR لها بأنها نقاط تحقق تطويرية لا إصدارات نهائية. والثانية أن 1.7B و2B هما ببساطة الحجمان الملائمان للتحقق من النوى مقابلها، ولا يخبراننا شيئًا عمّا سيُطرح. الموقف الصادق هو أن التسريب يثبت وجود العائلة ويثبت شكلها؛ لكنه لا يثبت سقفها. إذا كنت تنتظر نموذج Liquid بحجم >10B، فإن هذا الـ PR لا يَعِد بواحد ولا يستبعده.

ما الذي يرثه LFM3، للأفضل أو للأسوأ

خط الأساس الذي يتعيّن تجاوزه حديث وموثّق جيدًا. صدر LFM2.5-24B-A2B في 13 أكتوبر 2026 بإجمالي 24B من المعاملات مع 2B نشطة، و40 طبقة، و64 خبيرًا، وتوجيه top-4، وسياق من 131,072 رمزًا، ومفردات من 128K، و33T من رموز التدريب المسبق. أما LFM2.5-2.6B، من أوائل أغسطس، فيتسع في أقل من 2.5GB مع سياق 128K. ويجمع LFM2.5-VL-3B بين أساس 2.6B ومشفّر رؤية SigLIP2.

من الجدير القول صراحةً: كل معيار قياس تنشره Liquid لهذه الطُرز تُشغّله الجهة المصنّعة على أدوات الاختبار الخاصة بـ Liquid، دون أي تقييم مستقل مرفق. الأرقام الرئيسية لـ LFM2.5-24B-A2B — AutomationBench 27.69، وBFCLv4 65.01، وToolSandbox 80.71، وIFEval 96.75 — هي أرقام Liquid، ويُظهر الجدول نفسه خسارتها أمام Qwen3.6-35B-A3B في WebArena Verified (26.75 مقابل 37.62)، وGPQA Diamond، وSWE-Bench Verified. جداول الجهات المصنّعة التي تتضمن خسائر أكثر مصداقية من تلك التي لا تتضمنها، لكن كونها مصداقية لا يعني أنها مُتحقّق منها. لا يوجد أي رقم LFM3 من أي نوع، لذا لا يوجد شيء للمقارنة بعد.

سيستمر تطبيق شروط الترخيص أيضًا. كل نقاط التحقق الحديثة الخاصة بـ LFM من Liquid على Hugging Face موسومة بـ license: other — وهو ترخيص LFM مخصص، وليس Apache-2.0 أو MIT. وأيًا كان الترخيص الذي تُطرح به LFM3، فافترض الشروط المخصصة نفسها إلى أن تنص بطاقة النموذج على خلاف ذلك، واقرأها قبل أن تبني منتجًا على الأوزان.

متى قد يصل فعليًا

لا أحد يملك موعدًا محددًا، حتى أولئك الذين يخمّنون باحتراف. سؤال على Manifold Markets حول موعد إصدار LiquidAI LFM3 يضع الربع الرابع 2026 عند 40٪، والربع الأول 2027 عند 21٪، والربع الثاني 2027 عند 21٪، والربع الثالث 2026 عند 11٪، والربع الثاني 2026 عند 7٪ — على إجمالي حجم يقارب Ṁ160، وهو صغير بما يكفي لتعكس النسب المئوية بضعة متداولين لا إجماعًا. اقرأه على أنه «في وقت ما خلال الربعين القادمين، على الأرجح»، ولا أكثر دقة من ذلك.

تُملي الاعتبارات العملية أن يكون ذلك عاجلًا لا آجلًا. إن وصول أعمال النواة إلى بيئة تشغيل رئيسية يُعد هندسةً في مرحلة متأخرة، لا في مرحلة مبكرة — فأنت لا تكتب نوى الالتفاف CuTe وتربط ذاكرة تخزين مؤقت هجينة لنموذج يبعد سنة كاملة عن الإطلاق. لقد استقر اسم العائلة على LFM3 عبر أربعة متغيّرات وأربعة مسارات لنقاط التحقق. لكن طلب السحب (PR) غير مدموج، والفحوص الثلاثة كلها حمراء، ويحتاج إلى مراجعة موافِقة لا يملكها، ولا يزال اثنان من أصل 22 من فحوص التحقق omni واثنان من أصل 16 من فحوص الرؤية يفشلان في مقارنة ROUGE الخاصة بهما. هذا فرع قيد العمل، وليس مرشح إصدار.

ماذا يعني هذا إذا كنت تختار نموذجًا هذا الأسبوع

لا شيء بشأن LFM3 ينبغي أن يغيّر قرارًا تتخذه اليوم. فهو غير متاح، وغير مسعّر، وغير مُقاس بمعايير، وغير مرخّص علنًا. وإذا كنت بحاجة إلى نموذج صغير متعدد الوسائط الآن، فإن جيل LFM2.5 هو الإجابة الحقيقية، وقيوده — الدرجات التي يعلنها المورّد، والترخيص المخصص، وملف البرمجة الذي تصفه جداول Liquid نفسها والتغطية الخارجية بأنه نقطة الضعف — هي الأمور التي ينبغي أن توازنها.

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

إن تشتت وقت التشغيل هو المشكلة العملية التي ستُحدثها هذه العائلة. عادة Liquid في الطرح داخل llama.cpp وMLX وvLLM وSGLang وONNX في آنٍ واحد جيدة من حيث قابلية النقل، ومربكة لأي شخص يريد نقطة نهاية واحدة: خمسة محركات تعني خمسة أشكال نشر، وخمس مجموعات من الخصائص الغريبة للمعالجة المسبقة، وخمسة تواريخ مختلفة يصل فيها الإصلاح. أما OrcaRouter فكتالوجه الذي يضم أكثر من 200 نموذج فلا يتضمن أي نقطة تحقق LFM واحدة اليوم، لذا لا توجد طريقة لاستدعاء LFM3 عبره، ولا ينبغي قراءة أي شيء هنا على أنه وعد بأن ذلك سيتحقق. إن الغرض الفعلي من طبقة التوجيه في هذه الحالة هو أن تكون الوصلة بين نموذج لم تُثبت جدارته بعد ومسار إنتاجي — فإرسال شريحة من حركة المرور إلى شيء جديد بينما يبقى نموذج معروف خلفه، مع سدّ الفجوة عبر التحويل الاحتياطي عند الفشل، هو كيفية تقييم خليفة عائلة غير مُطلَقة دون المراهنة بميزة موجهة للعملاء على سوق تنبؤات باحتمال 40%.

الأسئلة المفتوحة الجديرة بالمتابعة

أربعة أمور ستحسم هذا أسرع من أي تكهن إضافي. ما إذا كانت مسارات نقاط التحقق الأربعة ستصبح مستودعات حقيقية قابلة للتنزيل على Hugging Face — فحاليًا لا يُرجع البحث في منظمة LiquidAI أي شيء تحت LFM3، والمستودعات المذكورة في PR ليست قابلة للحل علنًا. وما إذا كان سيظهر PR لـ Transformers، وهو ما سيشير إلى أن البنية يجري رفعها إلى المنبع بشكل صحيح بدل تشغيلها عبر remote code. وما إذا كانت فحوصات التحقق الفاشلة ستُغلق، لأن إخفاقين من أصل 22 إخفاقًا في omni هما الفرق بين عرض تجريبي وعملية دمج. وما إذا كان سيظهر عضو من العائلة بحجم >10B، وهو السؤال الذي قال Labonne إن LFM3 موجود للإجابة عنه.

حتى ذلك الحين، فإنّ أدقّ جملة يمكن لأي أحد أن يكتبها عن LFM3 هي تلك التي استُهلّت بها هذه المقالة: ثمة طلب سحب (pull request) قائم، لم يُدمج بعد، ويسمّي أربعة نماذج omni صغيرة لم تُعلن عنها Liquid AI. تلك إشارة حقيقية — لكنها مبكرة فحسب، والإشارات المبكرة جديرة بأن تُقرأ على هذا النحو تمامًا.