تصور کنید می‌خواهید یک مدل تشخیص کلاهبرداری بانکی را اجرا کنید، اما نه بانک و نه ارائه‌دهندهٔ مدل، هیچ‌کدام نباید به داده‌های واقعی دسترسی داشته باشند. این رویای حریم خصوصی مطلق، بهای سنگینی دارد: سرعت اجرای مدل روی یک پردازندهٔ تک‌رشته‌ای، ۴۰۰۰ برابر کندتر از حالت عادی است. این جریمهٔ عملکردی برای اجرای یک تشخیص‌دهنده کلاهبرداری کارت اعتباری از طریق HEIR روی یک CPU تک‌رشته‌ای است.
به نقل از جرمی کان، مهندس گوگل، در گزارش منتشر شده در ۱۴ اوت ۲۰۲۶، اجرای یک استنتاج (Inference) — یعنی همان لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه به خودِ آشپزی است نه دوره‌ی آموزش آشپز — در این حالت ۲ ثانیه زمان می‌برد. این عدد شکاف عمیق عملکردی در حوزهٔ رمزنگاری همومورفیک (Homomorphic Encryption یا HE) را به رخ می‌کشد.
رمزنگاری همومورفیک «جام مقدس» حریم خصوصی داده است؛ زیرا به کامپیوتر اجازه می‌دهد داده‌ها را بدون رمزگشایی پردازش کند. در مدل‌های ابری فعلی، شما باید به ارائه‌دهنده اعتماد کنید تا داده‌های خام شما را پردازش کند. اما با HE، سرور هرگز حتی یک بیت از اطلاعات متن ساده (Cleartext) را نمی‌بیند؛ این شامل ورودی‌ها، خروجی‌ها و حتی مقادیر میانی محاسبات است. تضمین این است که تا زمانی که رمزنگاری شکسته نشود، کامپیوتری که برنامه را اجرا می‌کند نسبت به داده‌های مورد استفاده برای تولید ورودی‌های رمزنگاری‌شده، کاملاً کور باقی می‌ماند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، حذف نیاز به اعتماد به واسطه‌ها، بزرگ‌ترین چالش زیرساختی هوش مصنوعی است.
در این میان، HEIR به عنوان یک کامپایلر وارد عمل می‌شود تا برنامه‌های استاندارد را به نسخه‌هایی تبدیل کند که روی متون رمزنگاری‌شده (Ciphertexts) کار می‌کنند. در حالی که صنعت همواره به دنبال «LLMهای خصوصی» است، وضعیت فعلی فناوری برای مدل‌هایی با میلیاردها پارامتر غیرعملی است. تلاش‌های آکادمیک بر روی استنتاج رمزنگاری‌شده برای LLMها متمرکز است، اما تأخیرها هنوز بر حسب ثانیه برای هر توکن (Token) — تکه‌های کوچکی از متن، شبیه برش‌های یک کیک — اندازه‌گیری می‌شود. اکثر این راهکارها حتی با استفاده از شتاب‌دهنده‌های سخت‌افزاری مانند ۸ عدد GPU، نیازمند یک رفت‌وبرگشت به کلاینت هستند تا خروجی یک مرحله استنتاج را رمزگشایی کرده و سپس مرحله بعدی را آماده کنند.
شکاف عملکردی و اعداد
بر اساس گزارش jeremykun.com، میزان کندی بسته به پیچیدگی مدل و سخت‌افزار به‌شدت تغییر می‌کند. مثال تشخیص کلاهبرداری کارت اعتباری، یک شبکه پیش‌خور (Feed-forward) سه لایه با توابع فعال‌ساز سیگموئید است که روی یک مجموعه داده Kaggle آموزش دیده است. لایه‌های خطی آن دارای ابعاد ۱۲۸، ۶۴ و ۲ هستند (عدد ۲ مربوط به لوجیت‌های مربوط به کلاهبرداری یا عدم کلاهبرداری است).
جزئیات عملکردی این مدل‌ها به شرح زیر است:
- تشخیص کلاهبرداری کارت اعتباری: یک شبکه کوچک که حدود ۲ ثانیه زمان می‌برد (۴۰۰۰ برابر کندتر از ۰.۵ میلی‌ثانیه در حالت متن ساده). این فرآیند شامل دو ضرب ماتریس-بردار و دو ارزیابی سیگموئید است. جزئیات زمانی شامل یک مرحله پیش‌پردازش ۵۷۳.۵۳ میلی‌ثانیه‌ای و یک ارزیابی FHE حدود ۲.۰۲ ثانیه‌ای است. ویژگی‌های ورودی (با اندازه ۸۲) در ۱۹.۴۳ میلی‌ثانیه رمزنگاری می‌شوند و رمزگشایی نهایی لوجیت‌ها ۴۸۸.۲۳ میکروثانیه زمان می‌برد.
- تشخیص ناهنجاری شبکه: مجموعه‌ای از خودرمزگذارها (Auto-encoders) که هر استنتاج حدود ۳۰ ثانیه زمان می‌برد.
- سیستم توصیه‌گر Criteo: یک مدل تخصصی HE که اجرای آن روی CPU حدود ۵ دقیقه طول می‌کشد.
- تشخیص کلمات کلیدی (Hotword): یک شبکه کانولوشنی ۱۰ لایه که ۲۰ دقیقه زمان می‌برد.
این مدل‌های پیچیده‌تر به حافظهٔ عظیمی بین ۶۰ تا ۹۰ گیگابایت (GiB) نیاز دارند.
البته چندین نکته در مورد این بنچمارک‌ها وجود دارد. مدل تشخیص کلاهبرداری به قدری کوچک است که اطلاعات خصوصی در یک متن رمزنگاری‌شده CKKS جای می‌گیرند؛ تانسورهایی که بیش از ۳۲ هزار المان داشته باشند، به چندین متن رمزنگاری‌شده و سربار بیشتر نیاز دارند. علاوه بر این، این مدل خاص به قدری کوچک است که نیازی به «بوت‌استرپینگ» (Bootstrapping) — که کندترین بخش رمزنگاری همومورفیک است — ندارد. همچنین، این بنچمارک‌ها سربار شبیه‌سازی شده شبکه و تنظیمات یک‌باره هر کاربر برای تولید و آپلود متریال کلیدها را حذف کرده‌اند. سرور همچنین مقدار قابل توجهی پیش‌محاسبات مدل-محور را در مرحله پیش‌پردازش انجام می‌دهد.
اما تغییر سخت‌افزار، معادلات را عوض می‌کند. تست‌های داخلی گوگل نشان می‌دهد بار کاری Criteo از ۵ دقیقه در CPU به حدود ۵۰۰ میلی‌ثانیه در یک GPU H100 کاهش می‌یابد. این یعنی جریمهٔ سرعت از ۴۰۰۰ برابر به ۵۰ برابر (نسبت به خط پایه ۱۰ میلی‌ثانیه‌ای متن ساده) می‌رسد. این موضوع نشان می‌دهد در حالی که عملکرد خام CPU کند است، ادغام GPU/TPU پلی به سوی تولید صنعتی است، پیش از آنکه ASICهای سفارشی در دیتاسنترها گسترش یابند.
سازوکار کامپایلر HEIR
HEIR برای نمایش برنامه‌ها از MLIR (نمایش میانی چندسطحی) استفاده می‌کند. فرآیند وارد کردن یک مدل به کامپایلر در حال حاضر دستی است و دو مرحله اصلی دارد:
۱. تبدیل: تبدیل مدل پیش‌کامپایل شده (از PyTorch یا JAX) به MLIR. اگرچه PyTorch و JAX ابزارهایی برای این کار دارند، اما HEIR هنوز از linalg.generic در حالت کلی پشتیبانی نمی‌کند. بخش زیادی از خط لوله اولیه — مانند ادغام لایه‌های خطی و شناسایی فعال‌سازها — بر اساس نحوه خروجی گرفتن torch-mlir از مدل‌ها است.
۲. حاشیه‌نویسی: تعیین دستی اینکه کدام ورودی‌ها محرمانه هستند و تعریف محدوده‌ها برای توابع فعال‌ساز. تیم HEIR در حال همکاری با نگهدارندگان torch-mlir است تا این فرآیند را با استفاده از مجموعه‌های اعتبارسنجی برای تخمین محدوده‌ها، خودکار کند.
معماری این ابزار شبیه LLVM است و از دو فایل اجرایی اصلی استفاده می‌کند:
heir-opt: مدیریت اجرای پاس‌های کامپایلر.heir-translate: مدیریت تولید کد (Codegen).
این‌ها در قالب قوانین Bazel (rules_heir) بسته‌بندی شده‌اند تا کتابخانه‌های Go، C++ یا Rust تولید کنند. برای مثال، مدل کلاهبرداری از فلگ‌های خاصی مانند --torch-linalg-to-ckks با تنظیماتی چون min-slot-count=8192 ، greedy-level-budget=15 ، greedy-modulus-switch-after-mul=true ، experimental-disable-loop-unroll=true ، first-mod-bits=30 و scaling-mod-bits=24 برای مدیریت طرح CKKS استفاده می‌کند. قوانین ساخت همچنین اجازه می‌دهند تا بک‌اِندهای متعددی مانند Lattigo و OpenFHE هدف قرار گیرند.
همچنین HEIR یک کتابخانه فرانت-اند به نام heir_py ارائه می‌دهد. این ابزار زیرمجموعه محدودی از بایت‌کد پایتون را (از طریق numba) به HE کامپایل می‌کند، کد C++ مربوط به OpenFHE را تولید می‌کند، آن را با clang کامپایل کرده و کد ماشین را دوباره به یک ماژول پایتون بارگذاری می‌کند. در حال حاضر، این بخش برای حفظ عملیات numpy به عنوان عملیات linalg در MLIR به توسعه بیشتری نیاز دارد.
دقت و عیب‌یابی
توسعه‌دهندگان می‌توانند از طریق کال‌بک‌های عیب‌یابی، موازنه بین عملکرد و دقت را بررسی کنند:
- زمان‌بندی هر لایه: کاربران می‌توانند گلوگاه‌ها را شناسایی کنند. در مدل تشخیص کلاهبرداری، لایه خطی اول حدود ۱.۲ ثانیه از کل ۲ ثانیه زمان را می‌گیرد.
- کاهش دقت: عیب‌یابی‌ها نشان می‌دهد که HE می‌تواند باعث کاهش دقت (Precision) شود. در دموی کلاهبرداری، استفاده از HE باعث کاهش حدود ۲ بیتی دقت در مقایسه با مدل متن ساده شد. این مقدار را می‌توان از طریق فلگ‌های کامپایلر تنظیم کرد، هرچند این کار نیازمند تخصص در رمزنگاری همومورفیک است.
محدودیت‌های «برنامهٔ طلایی»
جرمی کان معتقد است برای اینکه HE امروز کاربردی باشد، باید چهار شرط یا اکتشاف (Heuristics) خاص را برآورده کند:
۱. مدل‌های سال ۲۰۲۰: معماری‌ها باید به اندازه کافی کوچک باشند تا از «بوت‌استرپینگ» (کندترین بخش HE) اجتناب شود. این موضوع ترنسفورمرهای کاربردی را حذف می‌کند اما مدل‌های کانولوشنی را ترجیح می‌دهد. بسیاری از حوزه‌ها از سال ۲۰۲۰ تغییرات معماری چشمگیری نداشته‌اند، به این معنی که مدل‌های کوچک و کاربردی هنوز وجود دارند که می‌توانند به سرعت مناسب در HE دست یابند.
۲. حریم خصوصی متقابل: هم داده‌های کاربر و هم وزن‌های مدل ارائه‌دهنده باید به شدت حساس باشند. اگر فقط داده‌های کاربر حساس است، پردازش روی دستگاه (On-device) — مانند تغییر گوگل مپس در سال ۲۰۲۴ برای انتقال تاریخچه مکان به روی دستگاه در پاسخ به حکم‌های Geofence پلیس آمریکا — جایگزین ساده‌تری است. HE زمانی ضروری است که ارسال مدل به دستگاه، ریسک لو رفتن وزن‌های اختصاصی در برابر رقبا را داشته باشد یا به مهاجمان اجازه دهد در محیطی بدون محدودیت، حملاتی را علیه مدل تولیدی مهندسی کنند. در برخی موارد، محافظت از مالکیت معنوی (مدل) مهم‌تر از حریم خصوصی کاربر است.
۳. تعداد کاربر کم: مدیریت کلیدها یک گلوگاه عظیم است. HE به «کلیدهای ارزیابی» (رمزنگاری‌شده‌های کلید مخفی کاربر) نیاز دارد که برای هر کاربر منحصر‌به‌فرد است و با اندازه برنامه مقیاس می‌یابد.
- ذخیره‌سازی: مدل‌های بزرگ می‌توانند برای هر کاربر به ۴۰ گیگابایت کلید ارزیابی نیاز داشته باشند. یک سرویس با یک میلیون کاربر به ۵۱۲ عدد هارد ۲۰ ترابایتی نیاز دارد که هزینه ذخیره‌سازی آن (با قیمت مصرف‌کننده حدود ۵۰۰ دلار برای هر درایو) تقریباً ۲۵۰ هزار دلار خواهد بود.
- تأخیر: انتقال ۴۰ گیگابایت کلید از دیسک به GPU می‌تواند صدها میلی‌ثانیه زمان ببرد — یعنی در همان مرتبه بزرگیِ خودِ محاسبات — و درخواست‌های سایر کاربران را مسدود کند.
در حالی که مقداری از RAM برای وزن‌های پیش‌پردازش شده مدل استفاده می‌شود، بخش عمده نیازها مربوط به بوت‌استرپینگ است. اگر بتوان از بوت‌استرپینگ اجتناب کرد، متریال کلید ممکن است به ۱ گیگابایت کاهش یابد که احتمالاً اجازه می‌دهد ۵۰ کاربر روی یک GPU قدرتمند دیتاسنتر قرار گیرند. با این حال، طرح‌های جدیدتر HE اغلب اندازه کلید را برای بهبود تأخیر افزایش می‌دهند.
۴. خروجی‌های کور: سرور نباید نیازی به دیدن نتیجه داشته باشد. اگر سرور مجبور باشد بر اساس خروجی اقدامی کند (مثلاً احراز هویت بیومتریک)، کلاینت باید نتیجه را رمزگشایی کرده و بازگرداند. برای جلوگیری از دروغ گفتن کلاینت، او باید یک «اثبات با دانش صفر» (Zero-knowledge proof) تولید کند که نشان دهد مقدار رمزگشایی شده درست است. این کار ممکن است اما مقیاس‌بندی آن برای طرح‌هایی مانند CKKS دشوار است و تأخیر بیشتری اضافه می‌کند.
کاربردهای عملی
با توجه به این محدودیت‌ها، چندین کاربرد در حال حاضر عملی هستند:
- عیب‌یابی از راه دور: تولیدکنندگانی که ماشین‌آلات گران‌قیمت را عیب‌یابی می‌کنند. خروجی یک پردازش دسته‌ای (Batch job) است که سرور نیازی ندارد فوراً آن را ببیند و تعداد کاربران (کارخانه‌ها) کم است. این مشابه دموی تشخیص نفوذ شبکه است که در آن محتوای بسته‌ها داده‌های حساس هستند.
- تحلیل‌های B2B: معیارهای کسب‌وکار به کسب‌وکار که در آن هر دو طرف نیاز به حریم خصوصی دارند اما تنها دو کاربر وجود دارد و متریال کلیدها قابل مدیریت است. این موارد اغلب نسبت به تأخیر مقاوم هستند (مثلاً گزارش‌های ماهانه). یک متخصص اشاره کرد که اگر گزارشی فقط یک بار در ماه نیاز باشد، یک هفته محاسبه نیز پذیرفتنی است.
- بیومتریک‌های تخصصی: بازیابی حساب یا پذیرش کاربر به صورت حضوری که در آن تأخیر بالا پذیرفتنی است و کارفرما از ذخیره یک دیتابیس بیومتریک اجتناب می‌کند. این اتفاقات به اندازه کافی نادر هستند که نیاز به QPS (تعداد درخواست در ثانیه) بالا نباشد.
نقشه راه آینده
گوگل در حال حرکت دادن HEIR به سمت یک بک‌اِند واقعی کامپایلر است که در آن رمزنگاری به جای فراخوانی کتابخانه‌های خارجی، به صورت «پاس‌های کامپایلر» پیاده‌سازی می‌شود. این طراحی چندلایه اجازه می‌دهد کامپایل را به APIهای سطح بالای کتابخانه، حساب‌های چندجمله‌ای ماژولار، یا حساب‌های ماژولار برداری (ریاضیات اعداد صحیح ۶۴ بیتی مودو اعداد اول سفارشی) برای GPUها و TPUها کاهش دهد. این امر بهینه‌سازی‌هایی مانند ادغام کرنل (Kernel Fusion) و زمان‌بندی (Scheduling) را ممکن می‌سازد.
این تحول به HEIR اجازه می‌دهد تا سخت‌افزارهای تخصصی شرکای گوگل از جمله Niobium، Cornami و Optalysys را هدف قرار دهد.
پشتیبانی‌های آتی شامل طرح‌های رمزنگاری جدید است:
- Gentry-Lee: بهینه‌شده برای ضرب ماتریسی با هم‌افزایی در GPU/TPU.
- Poulpy: ساده‌سازی ریاضیات چندجمله‌ای CKKS و جابجایی بین طرح‌ها.
- Gao-Zheng: امکان اجرای هر دو عملیات حسابی و منطقی در یک طرح واحد.
برای ردیابی پیشرفت‌های صنعتی، تیم در حال همسویی با fhe-benchmarking.org به رهبری شروتی گورانتالا است تا نحوه اندازه‌گیری سخت‌افزارها و طرح‌های مختلف را استاندارد کند. HEIR در نهایت کدهایی تولید خواهد کرد که به طور خاص برای این مخزن بنچمارک ساختار یافته‌اند تا به محققان در نمایش بهینه‌سازی‌ها کمک کند. این پروژه کاملاً متن‌باز است و جلسات هفتگی و ماهانه برای بررسی طراحی‌ها دارد. تا به امروز، چهار مقاله منتشر شده بر اساس تحقیقاتی که مستقیماً در HEIR انجام شده، نوشته شده‌اند.
گام بعدی شما
- اگر روی داده‌های حساس پزشکی یا مالی کار می‌کنید، مستندات Open Source پروژه HEIR را برای مدل‌های کوچک بررسی کنید.
- برای کاهش تأخیر، استراتژی‌های حذف بوت‌استرپینگ در مدل‌های پیش از ۲۰۲۰ را مطالعه کنید.
- منتظر پشتیبانی از طرح‌های رمزنگاری Gentry-Lee برای بهینه‌سازی ضرب ماتریسی در GPU باشید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو