استدعاء أدوات DeepSeek V4.1 Flash يصل إلى vLLM: ما الذي كسرته الوسوم المتباعدة

DeepSeek V4.1 Flash متاح بشكل عام منذ 10 سبتمبر 2026، وفي الأيام الاثني عشر الأولى من عمره كانت به فجوة لم يكتب عنها أحد: كان قادرًا على الاستدلال، وكان يرى الصور، وكان يستوعب مليون رمز من السياق، لكنه لم يكن قادرًا على استدعاء أداة بشكل موثوق عبر أكثر مكدسات الخدمة المفتوحة استخدامًا. وقد أُغلقت هذه الفجوة الآن في vLLM — ليس عبر مفتاح إعدادات، بل عبر إعادة كتابة المحلّل. يحمل هذا العمل طلبا سحب، والسبب في الحاجة إليهما هو الجزء المثير للاهتمام.

النسخة المختصرة: يُصدر DeepSeek V4.1 Flash استدعاءاته للأدوات بتنسيق وسوم لا يتعرف عليه كاشف DeepSeek V4 الحالي، لذا في نشر vLLM القياسي تصل وسوم استدعاء الأدوات كنص عادي بدلًا من مخرجات منظمة. لا يظهر أي خطأ. يبدو الأمر وكأن النموذج ببساطة امتنع عن استدعاء الدالة. إذا كنت تختبر حلقات الوكلاء مع DeepSeek V4.1 Flash مستضاف ذاتيًا وتستنتج أن النموذج سيئ في استخدام الأدوات، فهذا على الأرجح جدًا ما كنت تنظر إليه.

ما الذي تغيّر فعليًا في مكدس التقديم؟

ظلّ تحليل استدعاءات الأدوات في vLLM لنماذج DeepSeek موجودًا في مكانين منذ فترة: واجهة أمامية بلغة Python وواجهة أمامية أحدث بلغة Rust، مع تفويض العمل على مستوى القواعد النحوية إلى مشروع XGrammar. وقد تطلّب جلب دعم V4.1 Flash نقل C++ deepseek_xml وتحويله داخل XGrammar إلى باني Rust، ثم ربط ترميز النموذج نفسه بمجلد tokenizer الخاص بـ vLLM.

• عمل الواجهة الأمامية Rust هو PR #56235، الذي ينقل XGrammar C++ deepseek_xml تحويل إلى منشئ Rust. يتضمن 18 اختبارًا جديدًا خصيصًا لـ V4.1، وتبقى المجموعات الكاملة الحالية — 472 اختبارًا في vllm-parser و326 في vllm-chat — ناجحة.

• عمل الواجهة الأمامية بلغة Python هو PR #56408، وهو لا يزال مسودة. يعتمد على دمج تغيير XGrammar في المنبع (mlc-ai/xgrammar#885) أولاً، ويُفيد باجتياز 110 اختبارات عند تطبيق هذا الاعتماد.

• وحدة الترميز الجديدة هي vllm/tokenizers/deepseek_v41_encoding.py — ملف منفصل بدلاً من فرع داخل ترميز V4، مما يدل على أن قواعد الوسوم تختلف اختلافاً حقيقياً بدلاً من مجرد التوسيع.

• الاستدعاء صريح: --tool-parser deepseek_v41. لا توجد آلية احتياطية للكشف التلقائي تقوم بالمهمة الصحيحة في صمت.

الوسوم المتباعدة هي القصة بأكملها

السبب في وجود محلِّل جديد بدلًا من تعبير نمطي موسَّع هو المسافات البيضاء. يكتب DeepSeek V4.1 Flash وسوم أدوات DSML الخاصة به مع مسافات بين الرموز. نمط كاشف V4 يتوقع الصيغة غير المفصولة بمسافات، لذا يفشل في المطابقة، وفشل المطابقة في محلِّل استدعاء الأدوات صامت بحكم التصميم — إذ يُمرَّر النص كما هو كمحتوى بدلًا من رفع استثناء.

هذا النمط من الفشل جدير بالتوقف عنده لأنه النوع الأكثر كلفة. فالمُحلِّل الذي يُطلق استثناءً يُصلَح في ظهيرة واحدة. أما المُحلِّل الذي يعيد سلسلة سليمة الصياغة تحتوي على ترميز لم يطلبه المستدعي قط، فيبدو كمشكلة في جودة النموذج، وتستجيب الفرق له بالطريقة نفسها التي قد تستجيب بها لمشكلة في جودة النموذج: تجرّب مطالبات مختلفة، وتضيف أمثلة، وتغيّر النماذج. اثنا عشر يومًا مدة كافية ليحدث الكثير من ذلك في الخفاء.

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

لماذا يُعدّ هذا أكثر أهميةً بالنسبة إلى V4.1 Flash مما كان عليه في V4

استدعاء الأدوات ليس ترفًا اختياريًا لهذا الطراز تحديدًا. إن DeepSeek V4.1 Flash طراز مزيج خبراء بـ552 مليار معلمة، مع 8 مليارات معلمة نشطة عند الإدخال و16 مليارًا نشطة عند الإخراج، ونافذة سياق تبلغ مليون رمز وحد أقصى للإخراج يبلغ 384 ألف رمز. وتقسيم التنشيط هو الدليل: فقد بُني الطراز ليتلقى إدخالًا كبيرًا — مستودعًا، أو مجموعة مستندات، أو سجل أدوات طويلًا — ويُخرج استجابة منظمة طويلة. هذا شكل وكيل، لا شكل محادثة.

بقية مواصفات الإطلاق تشير في الاتجاه نفسه. أوزان مرخّصة بموجب MIT، و890 بايت من ذاكرة KV المؤقتة لكل توكن، و45 تريليون توكن للتدريب المسبق، ورؤية أصلية. رقم ذاكرة KV المؤقتة هو المهم تشغيليًا عند سياق 1M: فهو ما يجعل سجل الوكيل الطويل ميسور التكلفة للإبقاء عليه مقيمًا، وهو السبب في أن النموذج معقول كعامل رخيص في حلقة يشرف عليها نموذج أكثر تكلفة.

وهو ما يجعل فجوة الاثني عشر يومًا في استدعاء الأدوات تكلفة حقيقية لا مجرد حاشية. فالنموذج الذي تقوم جدواه الاقتصادية على كونه المنفّذ عالي الحجم في خط أنابيب وكيل لا قيمة له تُذكر إن لم يتمكن خط الأنابيب من انتزاع استدعاء منظّم منه.

ما الذي لا يزال مفتوحًا؟

الوضع الصادق للأمور، اعتبارًا من 22 سبتمبر 2026:

• مسار الواجهة الأمامية Rust ‏(PR #56235) هو المسار الذي يمتلك تغطية اختبارات كاملة على كل من حالات V4.1 الجديدة والمجموعات الموجودة مسبقًا. إذا كنت تستخدم إصدارًا من vLLM يتضمنه، فإن المحلل متاح لك اليوم.

• مسار الواجهة الأمامية لـ Python (PR #56408) هو مسودة وله تبعية خارجية. إذا كنت مثبتًا على إصدار يسبق تغيير XGrammar، فلن تمنحك الواجهة الأمامية لـ Python تحليل أدوات V4.1 بعد.

• لأن الاستدعاء صريح، فإن عملية نشر تُرقّي vLLM دون تغيير رايات التشغيل الخاصة بها ستُبقي على السلوك القديم. وجود المُحلِّل واستخدامه أمران مختلفان.

• لا يوجد حتى الآن دليل علني على إجراء اختبار مرجعي مستقل لاستدعاء الأدوات على V4.1 Flash مع وجود المحلل الجديد. ما نعرفه هو أن البنية التحتية تعمل والاختبارات تنجح. أما ما إذا كانت جودة استدعاء الأدوات لدى النموذج جيدة فهو سؤال منفصل لا تجيب عنه عملية الدمج.

هذه النقطة الأخيرة هي التي يجب التمسّك بها. إن إصلاح المُحلِّل ينقل النموذج من «لا يمكن تقييمه» إلى «يمكن تقييمه». فهو شرط مسبق لإصدار حكم، وليس الحكم نفسه.

إذا كنت لا ترغب في تشغيل حزمة التقديم بنفسك

هناك مسار أقصر. DeepSeek V4.1 Flash متاح عبر نقطة النهاية الخاصة به لدى OrcaRouter، ما يعني أن سلوك استدعاء الأدوات يصل كطلب API عادي بدلًا من أن يكون مشكلة بناء — لا إصدار XGrammar يجب مطابقته، ولا واجهة أمامية يجب اختيارها، ولا عَلَم تشغيل يجب تذكّره. السبب في أن هذا مهم هنا تحديدًا هو أن الإصلاح استقر في موضعين بمستويين مختلفين من النضج، ونقطة النهاية المستضافة تُلغي ذلك القرار تمامًا.

المفتاح نفسه يصل أيضًا إلىبقية النماذج التي قد تقارن بها، وهذه هي الخاصية المفيدة عندما لا يكون السؤال "هل هذا المحلِّل صحيح" بل "هل هذا النموذج جيد بما يكفي لحلقة عملي". يمكنك وضع DeepSeek V4.1 Flash خلف قاعدة توجيه كمنفّذ رخيص، والتحويل عند الفشل إلى نموذج أقوى عندما يفشل الاستدعاء، دون عقد ثانٍ أو SDK ثانٍ. إن تجربة نموذجٍ مضى أسبوعان فقط على دعمه لاستدعاء الأدوات هي بالضبط الحالة التي وُجد التحويل التلقائي عند الفشل من أجلها.

ماذا تشاهد بعد ذلك

ثلاثة أمور ستحوّل هذا من قصة سباكة إلى حُكم:

• PR #56408 يخرج من المسودة، مما سيجعل مسار الواجهة الأمامية Python حقيقياً وينهي وضع الدعم ثنائي المستوى.

• تقييم مستقل للوكيل أو لاستدعاء الأدوات يُجرى على V4.1 Flash على منظومة خدمة ثابتة. صدر النموذج منذ اثني عشر يومًا، ولم يكن المُحلِّل صالحًا للاستخدام إلا منذ أقل من ذلك، لذا فأي نتيجة لاستدعاء الأدوات تراها منسوبة إليه الآن تستحق التساؤل عنها — فالإعداد لا يقل أهمية عن النموذج.

• ما إذا كانت مكدسات الخدمة الأخرى تحذو الحذو نفسه. vLLM هي الوحيدة التي لديها طلبات سحب عامة؛ ومشكلة الوسم المتباعد ليست خاصة بـ vLLM، لذا فإن أي مكدس تبنّى كاشف V4 دون إعادة اشتقاقه من مخرجات V4.1 يحمل في داخله الفشل الصامت نفسه.

إلى أن يتحقق أول تلك الأمور، فإن الملخص الدقيق ضيق ويستحق أن يُقال بوضوح: DeepSeek V4.1 Flash نموذج GA بأوزان MIT، وسياق 1M، وسقف إخراج 384K، واستدعاء الأدوات فيه يعمل الآن على مسار Rust في vLLM مع علامة محلل صريحة. هذه خطوة حقيقية وليست نتيجة بعد.