LFM3-1.7B على vLLM: بعد تسعة أيام، لا يزال الدعم الأصلي مجرد طلبَي سحب مفتوحين

أصدرت Liquid AI LFM3-1.7B في 27 أكتوبر 2026 مع بطاقة نموذج تطبع vllm serve "LiquidAI/LFM3-1.7B" وكأنه أمر عادي. وبعد تسعة أيام، لا يملك vLLM المنبع بنية Lfm3ForCausalLM لتشغيله بها. ما يوجد بدلاً من ذلك هو طلب ميزة فُتح في 30 أكتوبر، وطلب سحب واحد خاص بالنواة تتراكم عليه كل التغييرات الأخرى، وستة طلبات سحب مفتوحة خاصة بالنموذج — اثنان منها ينفذان نموذج النص LFM3-1.7B نفسه بطريقتين مختلفتين، ولم يُدمج أي منهما.

تلك الفجوة هي القصة كلها هنا، وهي فجوة ضيقة. فالنموذج حقيقي وقابل للتنزيل؛ أما دعم وقت التشغيل فهو في طابور. هذه مقالة عمّا نعرفه حتى الآن عن الطابور: ما الذي قيد التنفيذ، وما الذي يعمل فعليًا اليوم، وما الذي يجب أن يتحقق قبل أن تصبح عبارة "works with vLLM" على بطاقة نموذج صحيحة بالمعنى الذي تحتاجه خطة النشر.

تشير البطاقة إلى vLLM. ويشير جدول النماذج المدعومة إلى LFM2.

تسرد وثائق النماذج المدعومة الخاصة بـ vLLM ثلاث معماريات من Liquid AI: Lfm2ForCausalLM وLfm2MoeForCausalLM وLfm2VlForConditionalGeneration. ولا يوجد أي إدخال لـ LFM3. وفي المقابل، تذكر بطاقة LFM3-1.7B أن نقطة التحقق "تعمل مع vLLM وSGLang ونسخ llama.cpp المتوافقة مع LFM3" وتقدّم أمر تشغيل خدمة دون أي أعلام مرفقة.

التوفيق يكمن في إعدادات نقطة التحقق نفسها. يحمل LFM3-1.7B خريطة auto_map تشير إلى ملف modeling_lfm3.py المرفق به، لذا توجد شيفرة جانب Hugging Face وتستنسخ نفسها داخل المحمّلات التي تسمح بالشيفرة البعيدة. إن قضية التتبع الخاصة بـ vLLM لعملية النقل، #64645 — "[Feature]: دعم نماذج LiquidAI LFM3"، التي فتحها abhijithneilabraham في 30 أكتوبر — صريحة بشأن النتيجة: "لا يوجد في vLLM أي Lfm3ForCausalLM." والبديل المذكور فيها هو مخرج الطوارئ الذي سينتهي معظم الناس إلى استخدامه هذا الشهر: "شغّل LFM3 عبر الشيفرة البعيدة لنقطة التحقق باستخدام الواجهة الخلفية Transformers. وهذا يتخلى عن الانتباه المُقسّم إلى صفحات وذاكرة التخزين المؤقت لحالة الالتفاف."

هذه المقايضة جديرة بالذكر صراحةً، لأن «يعمل على vLLM» و«يعمل على خلفية transformers في vLLM» منتجان مختلفان. فالانتباه المُصفَّح (paged attention) هو الآلية التي تتيح لـ vLLM تجميع طلبات ذات أطوال شديدة التباين دون إهدار ذاكرة KV؛ وذاكرة حالة الالتفاف (conv state cache) هي الفكرة نفسها مطبَّقة على طبقات الالتفاف القصير في هذه البنية. وإذا أزلت الاثنين معًا، فستحصل على نقطة نهاية عاملة تخلّت عن السببين اللذين وُجد vLLM من أجلهما. وبالنسبة لنموذج بحجم 1.7B يُقدَّم عند تزامن منخفض، قد يكون ذلك مقبولًا كنموذج لعطلة نهاية الأسبوع، لا كتشكيل إنتاجي مقبول.

لماذا يحتاج نموذج 1.7B إلى العمل على النواة على الإطلاق

LFM3-1.7B ليس إعادة ضبط مباشرة لعائلة LFM2 التي يقدّمها vLLM بالفعل. بل هو هجين من أربع وعشرين طبقة وثلاثة أنواع من الطبقات بدلاً من نوعين: 13 طبقة التفاف قصير مُبوَّبة، و5 طبقات انتباه بنافذة منزلقة بعرض 256 رمزًا، و6 طبقات انتباه كامل. ويُفصّل إعداد نقطة التحقق الهندسة صراحةً — conv_L_cache: 7، وsliding_window: 256، ومفردات بحجم 128K — كما تضيف قائمة الفروق الواردة في مسألة vLLM نفسها QK RMSNorm، وبوابة إخراج انتباه سيغمويد لكل رأس، وتطبيع بنمط الساندويتش، وRoPE جزئي (partial_rotary_factor: 0.5) على طبقات الانتباه الكامل، مرتّبةً بالشكل ذي الذيل الصفري نفسه الذي يستخدمه Gemma 4.

الرقم الذي عطّل المنفذ هو سبعة. التلافيف القصيرة في LFM2 بعرض ثلاث نقرات؛ وسّعتها LFM3 إلى سبع. تفكّ نوى causal_conv1d في Triton ضمن vLLM مجموعة ثابتة من العروض، وكما ورد في قضية التتبع: «نواة التعبئة المسبقة causal_conv1d في Triton تفكّ العروض من 2 إلى 4، ونواة فك التشفير من 2 إلى 6، لذا لا يمكن تشغيل نموذج بعرض 7 على CUDA اليوم.»

إذن، أول طلب سحب في المكدس ليس نموذجًا على الإطلاق. #64647، «[Kernel] دعم conv1d السببي بعرض 7»، فُتح في 30 أكتوبر بواسطة abhijithneilabraham، ويمس ملفين و186 سطرًا مضافًا: يوسّع نواة prefill من العروض 2–4 إلى 2–7 ونواة decode من 2–6 إلى 2–7، ويجعل كلا الغلافين يرفعان ValueError لأي شيء خارج ذلك النطاق. يشرح وصف طلب السحب نفسه لماذا يهم الرفض بقدر ما يهم التوسيع: قبل التغيير، «كان وزن أعرض يعمل دون فرع مطابق ويعيد قيمًا خاطئة». الفساد العددي الصامت فشل أسوأ من الرفض، وهو من النوع الذي لا يظهر إلا على النموذج الذي صادف أن جربته.

ثمة تحفظ واحد يجدر أن يرافق ذلك الـPR. يصرّح مؤلفه بوضوح بأنه لا يملك جهاز CUDA: فمسار المرجع على CPU يجتاز 96 اختبارًا، وقد فُحصت نوى Triton عبر التحليل الساكن لشجرة AST الخاصة بالنوى، بينما تُرك التحقق على GPU إلى CI. هذا إفصاح صادق لا عيب، لكنه يعني أن التغيير الوحيد الذي تعتمد عليه كل طلبات PR الأخرى الخاصة بـLFM3 لم يُجرَّب بعد على العتاد الذي سيشغّله عليه معظم القراء.

تنفيذان لنفس نموذج النص

خلال ستة أيام، كتبت مجموعتان منفصلتان دعمًا أصليًا لـ LFM3 في vLLM. وهما ليستا نسختين مختلفتين من رقعة واحدة؛ بل تصميمان مستقلان يصادف أنهما يثبّتان اسم البنية نفسه.

PR #64959، "[Model] إضافة LiquidAI LFM3 (Lfm3ForCausalLM)"، الذي فُتح في 1 نوفمبر بواسطة atmikshetty، هو الخيار المحافظ: سبعة ملفات، ووفقًا لوصفه الخاص يعيد استخدام ShortConv بعرض 7، وLfm2MLP، ومُعيّن أوزان LFM2، وRoPE النسبي الموجود، دون تغيير أي مكونات أساسية. يسجّل النموذج في السجل، ويضيفه إلى مجموعة اختبارات النماذج الهجينة وجدول النماذج المدعومة، ويوثّق — بشكل مفيد لأي شخص يشغّله — أعلام الخدمة التي تحقق منها: --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice. يذكر قسم التحقق الخاص به نجاح 324 اختبار نواة على A100-SXM4-40GB بدقة BF16، ونجاح اختبارات السجل والتهيئة، ومقارنة لوغاريتم الاحتمال مقابل مرجع الشيفرة البعيدة على Hugging Face.

PR #65826، "[Model] Add LFM3-Text"، فُتح في 5 نوفمبر بواسطة paulpak58 — وهو من Liquid AI — وهو النسخة الخاصة بالمورّد: عشرة ملفات و829 سطرًا مضافًا، بما في ذلك فئة الإعداد الخاصة به ضمن transformers_utils/configs/lfm3.py ووحدة الاختبار الخاصة به. وقد فُتح بعنوان "[Model] Add LFM3" وأُعيدت تسميته في اليوم نفسه عندما قُسّمت العائلة إلى أربعة طلبات سحب متراكبة: #65826 للنص، و#65827 للرؤية واللغة، و#65828 للصوت، و#65829 للشامل (omni)، وكل منها مبني على الذي قبله.

الاثنان ليسا في تعارض بقدر ما هما يسيران بالتوازي، ويُظهر النقاش تشابك الاعتماديات بوضوح. وفي PR الخاص بالنواة، كتب paulpak58 في 4 نوفمبر: «لدينا PRs داخلية خاصة بنا لنماذج LFM3، لكن هذه إضافة نظيفة يمكننا دعمها». وفي PR النصي المجتمعي، اقترح abhijithneilabraham أن الدمج قد يحتاج أولًا إلى دمج عمل transformers الخاص بـ Liquid — «أعتقد أن دمج هذا PR يتطلب PR الخاص بـ transformers من @paulpak58» — فأجاب atmikshetty بأن Lfm3Config ليس ضمن إصدار transformers حتى الآن، لذا فإن الفرع «يحمّل الإعداد عبر trust_remote_code من checkpoint، ويستخدم التنفيذ نموذج vLLM الأصلي». تلك هي البوابة الثانية التي لن يكون معظم القراء قد فكروا فيها: فحتى PR مدمج في vLLM يحتاج إلى فئة إعدادات config class تُشحن في مكان ما.

على جانب transformers، طلب السحب المكافئ هو #50322، «[Model] LFM3 Family: LFM3-Text»، الذي فُتح في 3 نوفمبر ولا يزال مفتوحًا، وقد اقتُطع من طلب سحب أكبر خاص بالعائلة. وتتوافق ملاحظته الخاصة عن الالتفاف مع مشكلة vLLM: فالالتفاف القصير «torch-only في LFM3 (نوى causal_conv1d على Hub تخدم عرض 2-4، بينما يستخدم LFM3 العرض 7)».

يجري تكرار العمل على الرؤية واللغة أيضًا. إلى جانب #65827 الخاص بـ Liquid، لا يزال طلب سحب LFM3-VL مستقل (#65450، الذي فُتح في 3 نوفمبر) مفتوحًا ويعتمد على طلب السحب النصي المجتمعي. لذا يوجد، حتى اليوم، ستة طلبات سحب مفتوحة لـ LFM3 موزعة على معسكرين، ولا يوجد أي منها مدموج.

ما الذي يعمل فعليًا اليوم

إذا استبعدنا التكهنات، فإن الصورة العملية في 5 نوفمبر تبدو هكذا.

• vLLM، أصلي — غير ممكن في إصدار قياسي. لا يوجد Lfm3ForCausalLM في السجل، ولا صف LFM3 في جدول النماذج المدعومة، وطلب السحب (PR) الذي سيضيفه غير مدموج.

• vLLM، الواجهة الخلفية transformers — الحل البديل الموثّق، باستخدام الشيفرة البعيدة المضمّنة في نقطة التحقق و trust_remote_code. تخسر الانتباه المقسم إلى صفحات وذاكرة الحالة التلافيفية؛ لكنك تحتفظ بالخادم المتوافق مع OpenAI.

• SGLang — مسار الخادم الخاص بالبائع نفسه. يقيس منشور الإطلاق من Liquid أرقام إنتاجيته على وحدة NVIDIA B300 واحدة بدقة BF16 باستخدام SGLang، بما في ذلك 3.6 مليار رمز يوميًا عند 1,024 طلبًا متزامنًا. لا يظهر vLLM في ذلك المنشور إلا كبيئة التشغيل التي قُدّمت عليها النماذج المنافسة.

• llama.cpp — تشير البطاقة إلى "إصدارات llama.cpp المتوافقة مع LFM3"، وهو وصف تأهيلي حقيقي وليس نصًا إنشائيًا؛ فأرقام Liquid على الجهاز هي llama.cpp بدقة Q4_0 مع سياق 32K.

• MLX — تُدرج ملاحظات إصدار 0.33.0 الخاصة بمشروع vLLM-Metal المنفصل نقاط تفتيش MLX لنصوص LFM3، وذلك خلف --trust-remote-code. وهي قاعدة شيفرة مختلفة عن vLLM الأصلية ولا تعني دعم CUDA.

• Hosted — واجهة برمجة التطبيقات (API) وساحة التجارب الخاصة بـ Liquid. لا تقدّم هذه البطاقة أي جدول أسعار، لذا فإن التكلفة لكل رمز (token) ليست أمرًا يمكنك التخطيط لميزانيته استنادًا إلى مواد متاحة للعموم.

رقمان يضعان جدوى الاستضافة الذاتية في منظورها الصحيح. فالأوزان صغيرة بما يكفي بحيث لا تكون الذاكرة هي القيد — إذ تدّعي Liquid أنها نحو 1 GB عند 4-bit — ويقول المورّد إن سياقًا بطول 128K رمزًا يكلّف نحو 1.6 GB من ذاكرة KV المخبئية. القيد هو مكدّس الخدمة، وليس وحدة معالجة الرسوميات.

ما الذي قد يغيّر هذا، بالترتيب؟

سلسلة التبعيات نظيفة على نحو غير معتاد، وهو ما يجعل الأمر الجدير بالمتابعة محددًا على نحو غير معتاد. أولًا، يجب دمج #64647، لأن كل طلب سحب (PR) آخر خاص بـ LFM3 إما يتضمن ذلك الإيداع أو مبني عليه. بعد ذلك، يجب أن يحظى أحد طلبي السحب الخاصين بالنص بالقبول في المراجعة — فطلب المجتمع لديه سجل تحقق أكمل، وطلب Liquid لديه المؤلف الذي يتولى أيضًا جانب transformers. ثم يجب أن يُدرج Lfm3Config في أحد إصدارات transformers، وإلا فسيظل كل نشر يمرر trust_remote_code. وعندها فقط تصبح LFM3-VL-2B وLFM3-Audio-2B وLFM3-Omni-2B واقعية، وهذه متوقفة على مزيد من طلبات السحب التي تفترض أن نموذج النص قد أصبح مدمجًا بالفعل.

لا ينبغي قراءة أي من هذا على أنه انتقاد للوتيرة. تسعة أيام من الإطلاق إلى حزمة طلبات سحب (PR) متكاملة ومُختبرة للنواة والنموذج أمر سريع، وكون فريقين مستقلين أنتجا تطبيقات عاملة في أقل من أسبوع يقول أكثر عن مدى قرب LFM3 من LFM2 مما يقول عن أي تأخير. لكن بطاقة النموذج ادعاء توافق، والقراءة الصادقة لوضع LFM3-1.7B اليوم هي "متوافق مع vLLM عبر خلفية transformers"، وليس "مدعومًا من vLLM".

إذا كنت بحاجة إلى نموذج صغير لاستدعاء الأدوات هذا الأسبوع

إن LFM3-1.7B شيء جذاب يستحق الرغبة فيه. الأرقام التي أبلغ عنها المورّد قوية تحديدًا حيث تفشل النماذج الصغيرة عادةً — 71.39 على BFCL V4، و80.36 على ToolSandbox، و96.66 على IFEval، و43.40 على SWE-bench Verified — مقابل متوسط إجمالي قدره 49.37 تضعه Liquid متقدمًا على نموذجها الخاص LFM2.5-2.6B عند 31.55. تلك هي تقييمات المورّد نفسه، أجرتها الشركة التي بنت النموذج، دون إعادة إنتاج مستقلة ودون إدراج في Artificial Analysis تمكّنا من العثور عليه حتى تاريخ اليوم؛ تعامل مع الترتيب بوصفه فرضية ومع الأرقام الفردية بوصفها ادعاءات. ويأتي التحذير المرافق من المصدر نفسه: تنصح بطاقة النموذج بتجنب البرمجة الوكيلية والاستدلال المعقد متعدد الخطوات، وتتفق اختبارات المعرفة مع تلك النصيحة — 63.37 على GPQA Diamond و65.56 على RULER عند 128K ليست أرقام نموذج عام.

إذن القرار ليس في الحقيقة بشأن النموذج. إنه بشأن ما إذا كان يمكنك تحمّل البناء على مسار تقديم خدمة يمثّل حاليًا طلب سحب مفتوحًا. إذا كان بإمكانك تشغيل SGLang أو llama.cpp، فيمكنك استخدام LFM3-1.7B اليوم وتصبح مسألة vLLM أكاديمية. أما إذا كانت منصتك التقنية هي vLLM بحكم السياسة، فأنت تختار بين افتقاد الخلفية transformers إلى paged attention والانتظار.

هناك خيار ثالث جدير بالذكر لأحمال العمل التي لا يمكنها الانتظار: توجيه شيء آخر. لا يضم OrcaRouter النموذج LFM3-1.7B — إذ يعيد فحص كتالوجنا اليوم أكثر من 200 معرّف نموذج، ولا يوجد أي منها تابع لـ Liquid — لذا فليس هذا عرضًا ترويجيًا لاستدعائه عبرنا. النقطة الأبسط هي أن طلب سحب (PR) لنواة غير مدموج يمثل نقطة فشل واحدة سيئة لمسار إنتاجي. ووضع نموذج مستضاف خلف واجهة API واحدة مع تجاوز فشل تلقائي يكلفك تغيير إعدادات، ويتيح لك إدخال LFM3-1.7B في اليوم الذي يُدمج فيه دعمه الأصلي بدلًا من اليوم الذي تنتهي فيه من المراهنة عليه. إذا كنت تعدّل النموذج بدلًا من مجرد استدعائه، فإن إصدارنا الخاص LFM3-1.7B-abliterated هو استئصال اتجاه الرفض لنفس نقطة التحقق، ويرث بالضبط حالة الخدمة هذه.

النسخة المختصرة

صدر LFM3-1.7B، وهو صغير الحجم ومناسب جيدًا لمهام استدعاء الأدوات أحادية الدور التي دُرّب من أجلها. ويجري الآن تطوير دعمه في vLLM على يد فريقين، استنادًا إلى امتداد نواة لم يشغّله كاتبه على CUDA بعد. راقب #64647 أولًا — عندما يُدمَج التفافي العرض 7، تتحرك بقية المنظومة بسرعة، وتكفّ عبارة «يعمل مع vLLM» على بطاقة النموذج عن كونها بيانًا حول الشيفرة البعيدة لتصبح بيانًا حول الانتباه المقسم إلى صفحات والتجميع على دفعات. وحتى ذلك الحين، فإن أي شخص يردّد «دعم vLLM منذ اليوم الأول» لهذا النموذج إنما يردّد شيئًا لا يحتويه المستودع بعد.