Anthropic تتيح FlashProve: التحقق من النموذج يكلف 70–95 ضعف تكلفة الاستدلال

تشتري الوصول إلى نموذج مرتفع التكلفة عبر وسيط. تصلك الإجابة، ويظهر اسم النموذج، وتصدر الفاتورة. كيف تتحقق من أن هذا النموذج هو الذي عالج الطلب فعلًا؟ يصعب الجزم بذلك اعتمادًا على جودة النص وحدها. في 2 نوفمبر، قدمت Anthropic مشروع FlashProve، وهو نموذج أولي مفتوح يتيح التحقق من ارتباط النتيجة بأوزان محددة مسبقًا. ما يهم المطور هنا هو طريقة تدقيق المورّد، وإن كانت التكلفة لا تزال تحول دون تطبيقها على كل طلب. إعلان Anthropic.

ما الذي يؤكده البرهان تحديدًا؟

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

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

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

بالنسبة إلى فريق المنتج، يضيف ذلك متطلبًا إلى الاتفاقات مع المورّد: لا يكفي الحصول على ملف يتضمن البرهان. بل يجب معرفة المرجع الذي يُقارَن به، والجهة المسؤولة عن ذلك المرجع.

لماذا قد يُساء فهم رقم 110 توكن في الثانية؟

أُجريت التجربة على Llama 4 Maverick بأوزان من أربعة بتات وسياق من 1024 توكن. ومع دفعة تضم 24 طلبًا، كانت وحدة H100 واحدة تعالج نحو 110 توكن إدخال في الثانية أثناء إنتاج البراهين. هذه سرعة معالجة المطالبات، وليست سرعة إرسال توكنات جديدة إلى المستخدم. وكان كل طلب في هذا القياس يقدم برهانًا على توكن تالٍ واحد. شروط القياس.

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

بحسب تقدير Anthropic، يتطلب إنتاج البراهين وقت GPU يعادل نحو 70–95 ضعف ما يتطلبه الاستدلال التقليدي عبر vLLM. ويبلغ حجم برهان طلب الاختبار نحو 19 ميغابايت. وبالنسبة إلى API تُستخدم على نطاق واسع، يغيّر ذلك بصورة ملموسة تكاليف الحوسبة ونقل البيانات. تقدير الباحثين.

ما الذي ينبغي التحقق منه قبل التجربة؟

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

خلاصتي العملية: يُستحسن البدء بالتحقق من مثال محفوظ وتحليل نتيجة برنامج التحقق. يتيح المستودع هذا المسار دون GPU، والكود منشور بترخيص Apache 2.0. لكن الباحثين يصفون المشروع بأنه مُخرج بحثي لا يخضع للصيانة. مستودع FlashProve.

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