Clef-omni يفهم الصوت والفيديو في طلب واحد خلال نحو 300 مللي ثانية

بحسب سجل تحديثات Workers AI، أتاحت Cloudflare نموذج Clef-omni في 9 أكتوبر 2026 ليقيّم الصوت والفيديو مع النص والصور في طلب واحد، وذكرت زمناً يقارب 300 مللي ثانية لمقطع فيديو مدته 21 ثانية مصحوب بالصوت. يقبل النموذج صوت WAV أو MP3 وفيديو MP4 أو WebM، ويعيد درجات لإجابات محددة مسبقاً بدلاً من كتابة نص حر.

وتذكر مدونة Cloudflare التقنية نحو 1.5 ثانية لمقطع فيديو مدته 21 ثانية مع الصوت، ونحو 130 مللي ثانية عند الوسيط للطلبات النصية، كما تشرح أن النموذج يستند إلى جزء الفهم من Qwen3-Omni-30B-A3B-Instruct. لذلك يصف الرقم الأسرع ما أورده سجل الإطلاق، ولا يصلح وحده وعداً بزمن استجابة لكل ملف أو تطبيق. الاختلاف بين الرقمين المنشورين يهم من يريد بناء قرار فوري على تسجيل حي، حتى مع إتاحة الاستدعاء عبر المنصة.

قرار بدرجات، لا تفريغ للتسجيل

يعمل Clef-omni عندما يحدد التطبيق السؤال والإجابات المقبولة قبل إرسال الطلب. يفحص النموذج المحتوى المرفق ثم يمنح الخيارات درجات يمكن للتطبيق أن يستخدمها في اختيار مسار لاحق. إذا كان السؤال عمّا إذا كانت مروحة جهاز تدور في الفيديو، فقد تكون الإجابة قراراً محدود الخيارات؛ أما النص الحرفي لما قيل في التسجيل فليس من مخرجات هذا النموذج.

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

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

الوسائط وصيغة طلب Workers AI

يجمع الاستدعاء سياق المهمة في الحقل state والأسئلة في questions، ويضع الوسائط في images وaudio وvideos بحسب نوعها. يستخدم التطبيق معرّف Workers AI ‏@cf/cloudflare/clef-omni ويضبط قيمة model على clef-omni. تعرض صيغة الاستدعاء الوسائط بوصفها روابط بيانات مشفرة بـbase64؛ وإرسال عنوان بعيد للملف ليس هو طريقة الإدخال المعروضة لهذا النموذج.

• النص: يحدد سياق الحالة والسؤال المطلوب حسمه، ويمكن أن يحمل بيانات منظمة إلى جانب الوصف المكتوب.
• الصورة: تقدم دليلاً ثابتاً، مثل ظهور ملصق الجهاز، عندما يتعلق أحد الأسئلة بشيء مرئي في لقطة.
• الصوت: يدخل بصيغة WAV أو MP3 عندما تعتمد الإجابة على الكلام المسموع أو صوت التشغيل.
• الفيديو: يدخل بصيغة MP4 أو WebM عندما تكون الحركة أو العلاقة بين المشهد وصوته جزءاً من القرار.

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

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

متى يوفر الاستدعاء الموحد سلسلة معالجة؟

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

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

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

لماذا تختلف أزمنة الفيديو المنشورة؟

في اختبار مستقل من Worker في طوكيو أُجري في 10 أكتوبر 2026، بلغ وسيط استدعاء النموذج داخل العامل 1319 مللي ثانية لفيديو بدقة 480p مدته 21 ثانية مع الصوت، عبر 15 محاولة؛ وبلغ وسيط الرحلة الكاملة 1830 مللي ثانية. لم يُعِد هذا الاختبار إنتاج زمن 300 مللي ثانية الوارد في سجل التحديثات. وهو أقرب إلى تقدير المدونة، لكن الصفحات الرسمية لا تعرض تفاصيل كافية لإثبات أن القياسات الثلاثة استخدمت الحمولة نفسها أو حدّدت بداية التوقيت ونهايته بالطريقة ذاتها.

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

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

اقرأ أيضًا:

• Alma يَعِد بزمن استجابة 182 مللي ثانية، والقياس من Phonely نفسها
• Gemini 3.5 Transcribe يفهم 85 لغة، لكن التوقيتات تخفض الدقة
• Vercel أم Netlify؟ زمن p99 المنشور بلغ 1.18 مقابل 3.27 ثانية