ربط تصديق GPU TEE بتوقيعات النماذج: الاستدلال السري الموثّق للذكاء الاصطناعي السيادي متعدد المستأجرين

من يجب أن يقرأ هذا المقال

هذا المقال موجّه للمهندسين الذين يشغّلون خدمات استدلال النماذج اللغوية الكبيرة (LLM) في بيئات محلية (on premises) أو معزولة عن الشبكة (air gapped)، أو الذين يصممون منصات ذكاء اصطناعي لعملاء في قطاعات منظمة مثل المستشفيات والبنوك والجهات الحكومية التي لا يمكنها إخراج بياناتها إلى الخارج. يتناول ما تضمنه الحوسبة السرية لوحدات معالجة الرسومات (GPU confidential computing) والتصديق عن بُعد (remote attestation) وما لا تضمنه، وكيف يجب ربط هذا الضمان بسؤال “ما هي أوزان النموذج التي خدمت هذا الطلب فعلياً” حتى يتحول إلى دليل تقبله الجهات التنظيمية. هذا الموضوع وثيق الصلة بشكل خاص بالمؤسسات التي تشغّل عناقيد (clusters) GPU متعددة المستأجرين على Kubernetes وKueue.

المشكلة: عبارة “ثقوا بنا” لا تُقنع الجهات التنظيمية

السبب الذي يدفع المستشفيات والجهات الحكومية والبنوك إلى تشغيل نماذج لغوية كبيرة على خوادمها الخاصة بسيط: منع خروج البيانات إلى الخارج. لكن الهدف الحقيقي من النشر المحلي لا يتوقف عند استبعاد أطراف ثالثة. المطلوب بشكل متزايد هو ضمان أن الشركة المشغّلة للمنصة نفسها لا تستطيع الاطلاع على بيانات المستأجر (tenant)، ولا تستطيع استبدال النموذج خلسة. المشكلة أن مشغّل المنصة يملك صلاحيات الجذر (root) على العنقود، ويتحكم في المجدول (scheduler)، وينشر صور النموذج مباشرة. أمام حمل عمل (workload) خاضع للتنظيم، لا يمكن لعبارة “ثقوا بنا” أن تكون دليل امتثال. ما تريده الجهات التنظيمية ليس وعداً، بل إثباتاً.

وبشكل ملموس، يجب أن تكون المنصة السيادية قادرة على أن تثبت، بعد وقوع أي طلب استدلال، ولطرف ثالث لا يثق بالمشغّل، أمرين. الأول هو ادعاء سرية البيانات: أن قيم إدخال المستأجر وقيم تنشيط النموذج (activations) ومخرجاته لم تخرج قط بصيغة نص صريح خارج الحاوية الآمنة (enclave) للحوسبة السرية على GPU. لا يجب أن يتمكن مشغّل فضولي، ولا مستأجر آخر يشارك العنقود نفسه، ولا مهاجم على الشبكة، من الاطلاع على هذه القيم. والثاني هو ادعاء مصدر منشأ النموذج (model provenance): أن الأوزان التي أنتجت المخرَج هي بالضبط تلك القطعة (artifact) التي اجتازت بوابة التدقيق والإصدار في المؤسسة، وأنه لم يُزرع فيها باب خلفي، ولم تخضع لضبط دقيق (fine tuning) خفي، ولم تُستبدل بنسخة أخرى.

كل من هاتين المشكلتين له أعمال بحثية سابقة راسخة، لكنهما تطورا بشكل منفصل. توفر وحدات TEE على GPU من جيلي NVIDIA Hopper وBlackwell جذر ثقة على مستوى العتاد وتصديقاً عن بُعد يمكن أن يدعم الادعاء الأول، كما يمكن للأبحاث المتعلقة بمصدر منشأ النموذج وإثبات سلسلة التوريد أن تربط ادعاءات التدريب والإصدار بقطع النموذج لدعم الادعاء الثاني. توجد بالفعل أنظمة تنفذ تقديم نماذج لغوية سرية فوق وحدات TEE تجارية. لكن على حد علمنا، لا يوجد نظام يربط تشفيرياً سلسلة أدلة التصديق بسجل مصدر منشأ نموذج موقّع، ويفرض ذلك داخل مجدول GPU متعدد المستأجرين. التصديق عن بُعد يخبرك أين جرت العملية الحسابية، ومصدر المنشأ يخبرك أي كود وأي أوزان تم إصدارها، لكن لا أحدهما يخبر الجهة التنظيمية أن “الأوزان المدققة الخاصة بهذا الطلب عملت داخل الحاوية الآمنة المصدَّقة”. هذا هو الفراغ الدقيق الغائب تماماً.

المساهمة الأساسية: بروتوكول ACI الذي يربط التصديق ومصدر المنشأ على مستوى كل طلب

يقترح فريق ThakiCloud AI Research بروتوكول ACI (Attested Confidential Inference)، الذي يربط أدلة التصديق عن بُعد بأسلوب RATS بسجلات مصدر منشأ النموذج الموقّعة، ويفرض هذا الربط عند حدود قبول مهام Kubernetes (job admission). إذا قسّمنا الفكرة الأساسية إلى خمسة مكونات منطقية، نجد أولاً مسجّل مصدر المنشأ (Provenance Registrar)، الذي يوقّع عند لحظة الإصدار ادعاءات مثل بصمة (digest) الأوزان المدققة، وسلالة التدريب (training lineage)، وبيئة البناء، ونتائج الفحص، لإنتاج سجل مصدر منشأ $P$. يليه وسيط التصديق (Attestation Broker)، الذي يقوم بدور مُتحقق RATS (RATS Verifier)، ويصدر رمزاً عشوائياً طازجاً (nonce) لكل طلب، ويستقبل الأدلة من TEE الخاص بـ GPU/CPU ويتحقق منها، لينتج نتيجة تصديق $A$ تحتوي على قياس الحاوية الآمنة (enclave measurement).

النقطة التي يلتقي فيها هذان العنصران هي الكائن الأساسي في البحث، وهو دفتر الربط (Binding Ledger). يقوم بتوقيع تجزئة (hash) كل من $A$ و$P$، مع معرّف المستأجر ورقم الطلب، معاً، لإنتاج سجل ربط $B$، ويسجَّل ذلك في دفتر إلحاق فقط (append only ledger). هذا الربط هو بذاته الدليل الموقَّع الوحيد على أن “الأوزان المدققة قد عملت داخل الحاوية الآمنة المصدَّقة”. يُفرض هذا التحقق عند بوابة قبول Kueue (Kueue admission gate) قبل جدولة مهمة GPU فعلياً، بحيث لا تُقبل مهمة GPU المطابقة لهوية المستأجر ما لم يوجد ربط صالح. وأخيراً، توجد واجهة برمجية للتحقق الخاصة بالجهات التنظيمية (Regulator Verification API) للقراءة فقط، تتيح للجهة التنظيمية استرجاع مجموعة ${A, P, B}$ كاملة باستخدام رقم الطلب فقط، وإعادة التحقق من التوقيعات وقياسات الحاوية الآمنة بشكل مستقل عن المشغّل.

رسم توضيحي مفاهيمي لعملية الربط على مستوى كل طلب في ACI. تلتقي نتيجة التصديق $A$ مع بصمة الأوزان $P$ المتحقق من مصدر منشئها عند بوابة قبول Kueue لإنتاج ربط موقّع $B$. هذا تصميم للبروتوكول وليس قياساً لعتاد فعلي.

هناك نقطة أمانة يجب توضيحها هنا. مقارنة بصمة قيد التشغيل بقيمة مرجعية موقّعة ليست بحد ذاتها أسلوباً تشفيرياً جديداً. فهي من نفس نوع الأنماط الراسخة بالفعل مثل الإقلاع المقيس (measured boot)، وDICE، ومقارنة قيم TPM quote بالقيمة الذهبية (golden value)، كما أن ربط ادعاءات الإصدار الموقّعة بالقطع الرقمية أمر تناولته أبحاث سابقة أيضاً. المساهمة التي يمكن لهذا البحث الدفاع عنها بأمانة ليست أسلوباً تشفيرياً جديداً، بل التركيب (composition). فعلى حد علمنا، هذا هو العمل الأول الذي يجمع بين التصديق عن بُعد لـ GPU TEE والتحقق من مصدر منشأ النموذج الموقّع، ليصبح بوابة قابلة للتحقق من الجهة التنظيمية على مستوى كل طلب، تُفرض عند لحظة قبول المجدول داخل نظام Kubernetes وKueue متعدد المستأجرين.

لا يخفي البحث ثغرة واحدة، بل يتناولها مباشرة. توجد فجوة TOCTOU (time of check to time of use) لا يمكن إزالتها بين لحظة إنشاء الدليل (الخطوة 3) ولحظة تحميل الأوزان وخدمة الطلب فعلياً (الخطوات 4 إلى 6). يُضيّق البحث هذه النافذة عبر ترتيب فحص التحميل والبصمة بعد التصديق، وربط الاثنين معاً في ربط واحد $B$، لكنه يوضح صراحة أن هذا لا يزيل الفجوة تماماً. كما يعترف بأمانة بأن هذه البوابة لا تستطيع منع مشغّل يملك صلاحيات الجذر بذاته. فإن قام المشغّل بتجاوز البوابة لمعالجة طلب خفي (shadow request)، فلن يُنشأ ربط صالح $B$، وغياب السجل في دفتر الربط الناتج عن ذلك يصبح بحد ذاته دليلاً يمكن للجهة التنظيمية اكتشافه لاحقاً عبر مقارنة سجلات الفوترة أو عدد طلبات بوابة الواجهة البرمجية (API gateway) مع الدفتر. أي أن هذه البوابة صُممت لا كوقاية (prevention) تمنع مشغّلاً خبيثاً مسبقاً، بل كآلية كشف (detection) تترك فجوة قابلة للتحقق عند تجاوزها.

ما مقدار التكلفة الإضافية: التكلفة البرمجية المقاسة على عنقود H200 فعلي

كانت أكثر النقاط أمانة في هذا البحث هي ادعاءات الأداء الأصلية. نظراً لأن الباحثين لم يتمكنوا من الوصول إلى عتاد مفعّل عليه وضع TEE السري لـ GPU (وضع CC)، فقد قاموا بتفكيك زمن الاستجابة الكلي إلى نموذج جمعي (additive model): $L_{\text{ACI}} = L_{\text{base}} + L_{\text{TEE}} + L_{\text{att}}/N + L_{\text{ledger}}$، وملأوا قيمة كل حد باستخدام نطاقات مقتبَسة فقط من أبحاث سابقة. أعدنا لاحقاً النظر في هذا النموذج على عنقود العرض التوضيحي الفعلي لدى ThakiCloud، وهو tkai-prod-compute-h200. يضم هذا العنقود أربع وحدات NVIDIA H200-NVL (Hopper، تعريف 580.65.06، CUDA 13.0)، ومعالج AMD EPYC 9335 بـ32 نواة، لكن حالة CC التي تم التحقق منها عبر nvidia-smi conf-compute -f هي OFF (متوقفة)، ولا توجد آلات افتراضية سرية قائمة على SEV أو TDX مُهيّأة. أي أن $L_{\text{TEE}}$، أي عقوبة الإنتاجية الخاصة بالحوسبة السرية لـ GPU نفسها، لا تزال غير قابلة للقياس على هذا العنقود. لكن المسار البرمجي الجديد الذي يضيفه ACI، أي إلحاق دفتر التوقيع، والتحقق من مصدر المنشأ، وتدفق التصديق، أمكن قياسه فعلياً على خط أنابيب تقديم vLLM الفعلي بغض النظر عن حالة وضع CC.

قسنا خط الأساس أولاً. عند تقديم نموذج Qwen3.6-35B-A3B باستخدام vLLM على العنقود ذاته من طراز H200، بلغ متوسط زمن الاستجابة من طرف إلى طرف لكل طلب ($L_{\text{base}}$) 4286 ميلي ثانية، وبلغ متوسط الإنتاجية 29.9 رمزاً (token) في الثانية.

التكلفة الإضافية المقاسة التي يضيفها مسار الربط البرمجي في ACI فوق خط أساس H200 وvLLM (نحو 4286 ميلي ثانية لكل طلب). حتى مع جمع إلحاق دفتر التوقيع والتحقق من مصدر المنشأ وتدفق التصديق البرمجي، يبلغ المجموع نحو 0.01 ميلي ثانية لكل طلب، أي نحو 0.0002 بالمئة من خط الأساس.

قسنا كل بند من البنود التي يضيفها ACI فوق هذا الأساس على حدة. بلغت تكلفة إلحاق سجل الربط $B$ إلى دفتر التوقيع ($L_{\text{ledger}}$) في المتوسط 0.0037 ميلي ثانية عبر 3000 قياس متكرر، منها 0.0014 ميلي ثانية للتوقيع نفسه. أما جانب مصدر المنشأ فينقسم إلى مرحلتين. أعطى حساب بصمة SHA-256 لشظية (shard) كاملة بحجم 512 ميغابايت إنتاجية بلغت 2.15 غيغابايت في الثانية، وهذه تكلفة تُنفَّذ مرة واحدة فقط عند تحميل النموذج وتُستهلك (amortized) على مدى عمر النموذج بأكمله. أما تكلفة التحقق الفعلي لكل طلب، فبلغت في المتوسط 0.00014 ميلي ثانية فقط عبر 20000 قياس. وأخيراً، بلغ متوسط تدفق مصافحة التصديق البرمجي (attestation handshake) الكامل 0.0062 ميلي ثانية لكل طلب، لكنه انخفض إلى نحو 0.00005 ميلي ثانية لكل طلب عند استهلاكه (amortization) على مدى جلسة التصديق نفسها التي تعالج 128 طلباً.

كيف تنخفض تكلفة التصديق لكل طلب مع زيادة عدد الطلبات $N$ التي تُستهلك عليها جلسة التصديق. تنخفض التكلفة من 0.0062 ميلي ثانية عند $N$=1 إلى 0.00005 ميلي ثانية عند $N$=128، وإلى 0.000012 ميلي ثانية عند $N$=512.

عند جمع هذه البنود تصبح النتيجة واضحة. مسار الربط البرمجي الكامل لـ ACI، أي إلحاق دفتر التوقيع، والتحقق من مصدر المنشأ لكل طلب، وتدفق التصديق البرمجي، يضيف مجتمعاً نحو 0.01 ميلي ثانية فقط لكل طلب، وهو ما يمثل نحو 0.0002 بالمئة من خط الأساس البالغ 4286 ميلي ثانية، أي أقل من 0.001 بالمئة. من الناحية العملية، هذه تكلفة يمكن تجاهلها فعلياً.

كيف تتوزع التكلفة الإضافية البرمجية لـ ACI البالغة نحو 0.01 ميلي ثانية لكل طلب على بنود إلحاق الدفتر والتحقق من مصدر المنشأ وتدفق التصديق. استُبعد حساب بصمة الشظية بحجم 512 ميغابايت من هذا التوزيع لأنه تكلفة تُدفع مرة واحدة وتُستهلك على مدى عمر النموذج.

بالطبع، لا يكمّل هذا القياس الصورة الكاملة. لا تزال عقوبة الإنتاجية الخاصة بالحوسبة السرية لـ GPU نفسها ($L_{\text{TEE}}$) غير قابلة للقياس على هذا العنقود بسبب إيقاف وضع CC، وتبقى قيمة غير مقاسة مقتبَسة من النطاق الذي أوردته أبحاث سابقة بين 4 و8 بالمئة (chrapek2025confidential، zhu2024hopperbenchmark). كما أن توليد دليل التصديق الخاص بالعتاد نفسه لا يمكن قياسه بعد، لأنه يتطلب بيئة Hopper أو Blackwell في وضع CC. بعبارة أخرى، ما تم تضييقه بهذا القياس هو التكلفة البرمجية الجديدة التي يضيفها ACI، والمجهول المتبقي الوحيد أصبح مقتصراً على تكلفة عتاد GPU TEE نفسه.

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

مصفوفة توضح أي نوع من المهاجمين يقابل كل متطلب من متطلبات ACI الخمسة. متطلب عزل المجدول (R4) يغطي كلا نوعي المستأجر المشارك والمشغّل. هذه نتيجة تحليل نموذج تهديد، وليست قياساً فعلياً.

المساهمة تجاه الشركة والمجتمع والعلم

من منظور ThakiCloud، تبدو أهمية هذا البحث واضحة. هوية المستأجر القائمة على Keycloak، وقبول GPU عبر Kueue، وإصدار GitOps عبر ArgoCD، وهي جميعها مشغَّلة حالياً، تعمل بالفعل كآليات عزل. بدلاً من إضافة آلية عزل جديدة فوق هذه الأصول القائمة، يضيف ACI ربطاً تشفيرياً واحداً فقط، يحوّل العزل متعدد المستأجرين الذي نملكه حالياً إلى دليل قابل للتحقق من الجهات التنظيمية. يتقاطع هذا تماماً مع توجه الأمان والاستضافة الذاتية (self hosting) المستهدف في إصدار النصف الثاني من عام 2026، ومع متطلبات فصل الشبكات (network separation) والقابلية للتدقيق المطلوبة في القطاعين العام والمالي في كوريا.

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

علمياً، كون هذا البحث لا يدّعي أسلوباً تشفيرياً جديداً هو بالضبط أساس مساهمته الأمينة. فعلى حد علمنا، الجمع بين التصديق عن بُعد لـ GPU TEE والتحقق من مصدر منشأ النموذج الموقّع، المفروض على مستوى كل طلب عند لحظة قبول المجدول متعدد المستأجرين، هو موضع لم تتناوله الأبحاث السابقة. طوّرت الأبحاث القائمة التصديق ومصدر المنشأ كل على حدة، كما عملت أبحاث حوكمة Kubernetes فقط عند طبقة التنسيق (orchestration) والقياس عن بُعد (telemetry) دون أن تكون متجذرة في تصديق العتاد. ACI هو أول من يشير صراحة إلى هذا الفراغ بينهما.

القيود: ما يعترف به هذا البحث عن نفسه

لا يخفي هذا البحث أين تنتهي قياساته وأين تبدأ الاقتباسات. مسار الربط البرمجي الجديد الذي يضيفه ACI، أي إلحاق دفتر التوقيع، والتحقق من مصدر المنشأ لكل طلب، وتدفق التصديق البرمجي، تم قياسه على عنقود H200 فعلي (tkai-prod-compute-h200)، وتم تأكيد أنه نحو 0.01 ميلي ثانية لكل طلب، وهو ما يُعد مهملاً مقارنة بخط الأساس. غير أن هذا العنقود مُوقَف فيه وضع CC، لذلك لا تزال عقوبة الإنتاجية الخاصة بالحوسبة السرية لـ GPU نفسها ($L_{\text{TEE}}$) وتوليد دليل التصديق الخاص بالعتاد غير قابلين للقياس. يبقى القياس المباشر لهذين البندين على وضع CC في Hopper أو Blackwell عملاً مستقبلياً، ويوضح البحث صراحة أن السبب هو عدم القدرة على تفعيل وضع CC على العنقود المتاح حالياً.

إلى جانب ذلك، يشير البحث بنفسه إلى عدة نقاط غير محسومة. ففي عمليات النشر الممتدة عبر عناقيد متعددة (MultiKueue)، لا يمكن لدفتر ربط عنقود واحد وحده أن يُنتج رؤية تدقيق متسقة عبر العناقيد. كما أن سياسة استهلاك مصافحة التصديق عبر طلبات متعددة تتعارض مع حالات تتطلب التخلص من الحاوية الآمنة في منتصف الجلسة، مثل الإفصاح عن ثغرة أمنية. وفي عمليات نشر RAG، يجب أن يمتد ادعاء السرية من أوزان النموذج إلى السياق (context) المسترجَع وقت الاستعلام أيضاً. علاوة على ذلك، لا يثبت ACI سوى أن الأوزان المقدَّمة تطابق سجل مصدر منشأ موقّع، أما ما إذا كان سجل مصدر المنشأ نفسه يصف نموذجاً جديراً بالثقة، أو ما إذا كان تخزين مفتاح توقيع الإصدار آمناً، فتبقى مشكلات منفصلة تخص سلسلة التوريد.

يمكن الاطلاع على مزيد من التفاصيل حول البحث في صفحة مجموعة البيانات على HuggingFace.