LFM2.5-VL-DSpark: كيف تتعامل مع مسود الرؤية من Liquid AI كمرافق جانبي متحقق منه، لا كنموذج ثان

ما الذي أصدرته Liquid AI فعليا: مرافق جانبي لمسود رؤية مخصص لـ LFM2.5-VL-3B

أصدرت Liquid AI مسود الرؤية التجريبي LFM2.5-VL-DSpark في 24 سبتمبر 2026. من السهل إساءة قراءته. يبدو عنصر DSpark الصغير كشيء يمكن للفريق نشره بجانب نموذج أكبر للرؤية واللغة، أو ربما بدلا منه. هذه قراءة خاطئة. السؤال المفيد ليس: ما مدى سرعة النموذج الصغير؟ السؤال المفيد هو ما إذا كان الهدف، والمرافق الجانبي، والعارض، وبيئة التشغيل، ونقطة الالتقاط، ومنطق التحقق، ومسار الاسترجاع متطابقة بإحكام يكفي بحيث يكون الهدف قد أنتج الإجابة نفسها.

تصف Liquid AI LFM2.5-VL-DSpark بأنه مسود تجريبي لـ LiquidAI/LFM2.5-VL-3B. يبلغ حجم المسود نحو 279.5M معامل BF16، ولديه أربع طبقات انتباه، ويستخدم رؤوس Markov ورؤوس ثقة. يقرأ حالات الهدف المخفية عند طبقات التقاط ثابتة بعد دخول مدخلات الصورة والنص إلى التمثيل المشترك. بعبارات بسيطة، هو ليس نموذج رؤية ولغة مستقلا. وليس بديلا مضغوطا عن LFM2.5-VL-3B. وليس اختصارا حول مشفر الرؤية. إنه مرافق جانبي لفك ترميز تخميني، ولا يكون مفيدا إلا عندما يتحقق الهدف غير المعدل من الرموز المقترحة.

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

إذا كنت لا تزال تقيم النموذج الأساسي، فإن اختبار قبول الرؤية المحلي لـ LFM2.5-VL-3B من Optijara هو السياق الأب. هذه المقالة أضيق نطاقا. إنها عن DSpark كمرافق جانبي متحقق منه. وللفرق التي تعمل بالفعل مع عناصر محلية مكممة، يشرح دليل Optijara لمسار Transformers GGUF llama.cpp المعبأ أيضا لماذا لا يكفي اسم ملف يبدو معقولا.

عقد تنفيذ DSpark: صغ مسودة، تحقق، استرجع، ثم اقبل الرموز

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

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

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

للمكاسب شكل أيضا. لا يزيل DSpark معالجة الصور المسبقة أو prefill الرؤية. يمكنه المساعدة عندما تقبل رموز فك ترميز كافية لتعويض تكلفة الصياغة، وتجميع التحقق، والمقترحات المرفوضة، وحركة الذاكرة المخبأة. يرتبط ذلك بتوقيت المراحل، لكنه ليس المشكلة نفسها التي يعالجها رسم خريطة توقيت encode وdecode باستخدام OpenVINO GenAI.

الإطار الأصلي: خريطة توافق المسودة والهدف

الإطار الذي توصي به Optijara لهذا الإصدار هو خريطة توافق المسودة والهدف. املأها قبل توقيت DSpark. إذا كان أي صف مجهولا، فالمعيار ليس موثوقا بعد.

بالنسبة إلى GGUF، فضل زوج VL الرسمي الحالي: LiquidAI/LFM2.5-VL-3B-GGUF:F16 مع LiquidAI/LFM2.5-VL-3B-DSpark-GGUF:F16، باستخدام أعلام مسودة DSpark الموضحة في بطاقة النموذج. تجنب أوامر Hub العامة التي توحي بأن المسود يمكن خدمته وحده. وتجنب أيضا نسخ مثال مسود نصي إلى إصدار رؤية. المرافق الجانبي DSpark النصي وهدف VL غير قابلين للتبادل لمجرد أن الأسماء تبدو متقاربة.

يستحق دعم بيئة التشغيل التشكيك نفسه. تذكر بطاقة نموذج DSpark دعم إصدار SGLang ودعم MLX-VLM، لكن على الفرق التحقق من أن البناء المثبت يحتوي على قدرة الرؤية ذات الصلة، لا مجرد سلسلة الإصدار. يكشف SGLang PR الخاص بالرؤية وصولا متداخلا إلى رأس LM في نموذج اللغة ودعم طبقة الالتقاط. يربط MLX-VLM PR نقاط التقاط الحالة المخفية بأسلوب DSpark، والتحقق التخميني، واسترجاع ذاكرة حالة الالتفاف المخبأة. يعالج llama.cpp PR معمارية مفردات الهدف وإعادة ترتيب RoPE المزدوجة في التحويل. هذه قدرات يجب التحقق منها، لا تسميات تقتبس في شريحة.

ما الذي يجب اختباره قبل أن تثق بجدول التسريع

فحصت Optijara بطاقات النماذج العامة وكود التكامل لهذه المقالة. لم نشغل هذه النماذج ولم نعد إنتاج المعايير؛ وخطة الاختبار أدناه عمل مقترح.

ابدأ بالتكافؤ. ثم قس زمن الاستجابة. يثبت اختبار دخان مفيد النموذج، والمجزئ، والمعالج، والعارض، وقالب المحادثة، وcommit بيئة التشغيل أو إصدار الحزمة، والدقة، ومعالجة الصور المسبقة، وإعدادات التوليد، وإعداد الكتلة. شغل مخرج greedy للهدف فقط أولا. شغل مخرج greedy لـ DSpark ثانيا. قارن النص بدقة. إذا تباعد، فسجل المطالبة، وتجزئة الصورة، والإعدادات، ومراجعة بيئة التشغيل، وفرق المخرجات قبل تقديم أي ادعاء سرعة.

أرقام الأداء التي أبلغت عنها Liquid AI مفيدة، لكنها نتائج موردي محددة الظروف. تؤطر بطاقة النموذج النتائج حول batch 1، وtemperature 0، وإعدادات encoder وbackbone بدقة 16-bit، وH100 BF16 مع block 9، وApple FP16 مع block 8؛ وتستخدم قياسات Apple ما يصل إلى 2,048 رمز مخرج. تورد أمثلة مثل نسب COCO decode ونسب النهاية إلى النهاية على H100، إضافة إلى نتائج Apple التي تشمل صفوف M5 Max وM3 Ultra. تعامل معها كدليل اتجاهي للإصدار، لا كوعد لعبء عملك. إذا ستقارن أدلة المعايير عبر أنظمة، فاستخدم انضباط بروتوكول مثل دليل بطاقات التقييم وبروتوكولات المعايير من Optijara: يجب أن ينتقل المقياس، ومجموعة المطالبات، وبيئة التشغيل، والدقة، وقواعد القياس معا.

متوسط الرموز المقبولة في كل تمريرة تحقق ليس نسبة قبول بحد ذاته. طول القبول، والعمل المرفوض، وتكلفة المسود، وسلوك تجميع التحقق، وحركة الذاكرة المخبأة، وطول المخرج كلها تحدد السرعة المحققة. يمكن لإجابة قصيرة أن تنفق معظم وقتها في معالجة الرؤية المسبقة وprefill. أما إجابة أطول كثيفة decode فتمنح رموز المسودة المقبولة مجالا أكبر لتكون مهمة.

هذه هي القاعدة العملية: إذا بدأ تقييم DSpark لديك من جدول التسريع، فهو يتجه في الاتجاه الخطأ. ابدأ بتكافؤ المخرجات واقتران العناصر. تأتي السرعة لاحقا، وفقط إذا نجحت فحوص التوافق.

أخطاء شائعة عند اعتماد LFM2.5-VL-DSpark

الخطأ الأول هو التعامل مع المرافق الجانبي كنموذج رؤية ثان قابل للنشر. إنه مسود لمسار هدف مطابق. إذا كانت خطة النشر تقول: اخدم ملف DSpark كنموذج، فالخطة خاطئة.

الخطأ الثاني هو إقران مرافق DSpark نصي مع هدف VL. تتضمن مواد إطلاق Liquid AI أمثلة قد يكون من السهل نسخها خارج سياقها. بالنسبة إلى إصدار الرؤية، استخدم هدف الرؤية الحالي وعناصر DSpark البصرية الحالية، ثم تحقق من العارض ومسار بيئة التشغيل.

الخطأ الثالث هو القياس قبل إثبات التكافؤ. المسار السريع الذي يغير مخرج greedy ليس مسار تسريع صالحا لفك ترميز تخميني يحافظ على الهدف. قد يظل بحثا مثيرا للاهتمام، لكنه ليس دليلا على أن DSpark يسرع نموذجك الهدف بأمان.

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

الخطأ الخامس هو تجاهل الترخيص ومصدر العناصر. يتضمن LFM Open License v1.0 شروطا تجارية مرتبطة بالإيرادات وحدا موصوفا في نص الترخيص. هذا ليس مصدرا مفتوحا غير مقيد. راجع الترخيص الحالي واحصل على مشورة قانونية لحدود النشر التجاري.

التحفظات والحدود: أين قد لا يساعد DSpark

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

انحراف البيئة الخلفية حد آخر. يمكن أن تؤثر H100 وApple MLX وSGLang وllama.cpp وBF16 وFP16 وFlashAttention وقوالب الصور وتعامل المجزئ جميعها في التكافؤ والأداء. بيئة تشغيل تعمل لمسار واحد لا تثبت أن كل تحويل أو بيئة خلفية آمنة.

يحتاج أخذ العينات إلى حذر إضافي. من حيث المبدأ، يمكن لفك الترميز التخميني الحفاظ على توزيع الهدف عندما ينفذ أخذ العينات المطابق تنفيذا صحيحا. هذا مختلف عن إنتاج نص مطابق لكل seed عبر كل بيئة خلفية. بالنسبة إلى DSpark اليوم، اجعل تكافؤ greedy عند temperature 0 بوابة الثقة الأولى، ثم قيم أخذ العينات فقط إذا كانت بيئة التشغيل توثق الخوارزمية المطابقة وتدعمها.

مصفوفة القرار: متى ينبغي للفريق تقييم DSpark الآن

ليس القرار: هل DSpark جيد؟ بل هو: هل يناسب عقد المرافق الجانبي في هذا الإصدار هدفك، وبيئتك الخلفية، وعبء عملك، وانضباط التشغيل لديك؟ يحافظ هذا التأطير على تقنية تسريع واعدة من أن تتحول إلى اختصار نشر غير متحقق منه.

قائمة تحقق التنفيذ

استخدم هذه القائمة لسباق التقييم الأول. اختر مطالبات صور ممثلة. ثبت الهدف، والعارض، ومرافق DSpark الجانبي، والمجزئ، والمعالج، والقالب، ومراجعة بيئة التشغيل، والدقة، وإعداد الكتلة، ومعالجة الصور المسبقة. شغل خط أساس greedy للهدف فقط. شغل مخرج greedy لـ DSpark وقارن النص بدقة. قس TTFT وp50 وp95 لزمن الاستجابة من البداية إلى النهاية، وذروة الذاكرة، وطول الرموز المقبولة، والمقترحات المرفوضة، وسياسة الإحماء، وإعدادات الذاكرة المخبأة، وسلوك الرجوع إلى الهدف فقط. راجع الترخيص. قرر نطاق الطرح فقط بعد أن تكون أدلة التكافؤ والقياس في التقرير نفسه.

{
  "target": "LiquidAI/LFM2.5-VL-3B",
  "sidecar": "LiquidAI/LFM2.5-VL-3B-DSpark",
  "runtime": "pinned revision with VL DSpark taps, verification, and rollback",
  "parity_status": "greedy target-only versus DSpark comparison required",
  "latency_status": "measure TTFT and p50/p95 end-to-end after parity",
  "memory_status": "measure peak runtime memory, not parameter count only",
  "license_review": "required before commercial rollout",
  "fallback_ready": "target-only path documented"
}

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