استقرار مهم بعدی هوش مصنوعی ممکن است در یک خوشه عظیم ابری اجرا نشود. شاید درون یک دوربین، ربات کارخانه، وسیله نقلیه، دستگاه پزشکی یا پایانه خرده‌فروشی اجرا شود؛ جایی که پهنای باند، توان، تأخیر، حریم خصوصی و هزینه عملیاتی، بیش از داشتن بزرگ‌ترین مدل ممکن اهمیت دارند.

این تغییر، نوع متفاوتی از کار هوش مصنوعی را ایجاد می‌کند. تیم‌ها همچنان به سازندگان مدل نیاز دارند، اما همچنین به افرادی نیازمندند که بتوانند مدل‌ها را با سخت‌افزار واقعی سازگار کنند، کیفیت را در شرایط محدودیت بسنجند، زمان‌اجراهای بومی استنتاج را یکپارچه کنند و تصمیم بگیرند چه زمانی یک مدل کوچک‌تر برای کاری مشخص به‌اندازه کافی خوب است.

این نیمه کم‌زرق‌وبرق‌تر رقابت مدل‌هاست: نه فقط بهبود هوشمندی، بلکه قابل‌استقرار کردن هوشمندی.

چرا مدل‌های کوچک‌تر پرسش استقرار را تغییر می‌دهند

یک مدل ابری اغلب می‌تواند برای پاسخ‌دادن به یک درخواست، محاسبات بیشتری مصرف کند. یک سامانه نهفته نمی‌تواند روی اتصال شبکه‌ای قابل‌اعتماد، باتری نامحدود یا بودجه سخاوتمندانه برای هر فراخوانی حساب کند. رباتی که برای هر تصمیم ادراکی یا کنترلی چند صد میلی‌ثانیه منتظر بماند، ممکن است ناایمن یا ناکارآمد باشد. محصولی که هر تصویر یا نمونه صوتی را به یک API ارسال می‌کند، ممکن است هزینه‌های غیرقابل‌قبولی برای حریم خصوصی و انتقال داده ایجاد کند.

این محدودیت‌ها هدف مهندسی را تغییر می‌دهند. پرسش این می‌شود: کوچک‌ترین مدلی که در دستگاه واقعی، اهداف لازم برای دقت، تأخیر، حافظه، انرژی و قابلیت اطمینان را برآورده کند، کدام است؟

این پرسش بسیار فراتر از ابزارهای مصرفی کاربرد دارد. برای تولیدکنندگانی که قطعات را در خط تولید بازرسی می‌کنند، شرکت‌های لجستیکی که تجهیزات را ردیابی می‌کنند، بیمارستان‌هایی که سیگنال‌های حساس را پردازش می‌کنند و فروشندگان نرم‌افزار که می‌کوشند قابلیت‌های هوش مصنوعی ارائه دهند بدون آنکه هزینه‌های استنتاج به بزرگ‌ترین هزینه متغیرشان تبدیل شود، اهمیت دارد.

سه تکنیک پشت این تغییر

کوانتیزه‌سازی وزن‌های مدل و گاهی فعال‌سازی‌ها را با اعداد کم‌دقت‌تر نمایش می‌دهد. گذار از قالب‌هایی مانند BF16 یا FP16 به نمایش‌های 8 بیتی یا 4 بیتی می‌تواند نیازهای حافظه را کاهش دهد و بسته به سخت‌افزار و پیاده‌سازی، توان عملیاتی را بهبود ببخشد. مصالحه این است که دقت پایین‌تر می‌تواند کیفیت را کاهش دهد یا مشکلات عددی ایجاد کند؛ بنابراین باید آن را آزمایش کرد، نه اینکه بی‌ضرر فرضش کرد.

تقطیر، مدل دانش‌آموز کوچک‌تری را آموزش می‌دهد تا رفتار مفید یک مدل معلم بزرگ‌تر را بازتولید کند. دانش‌آموز می‌تواند از خروجی‌های معلم، سیگنال‌های میانی یا نمونه‌های ویژه کار یاد بگیرد. لازم نیست همه قابلیت‌های مدل بزرگ‌تر را بازآفرینی کند؛ کافی است کار هدف را به‌اندازه کافی خوب انجام دهد.

استنتاج بهینه‌سازی‌شده، اجرا را با یک زمان‌اجرا و پردازنده مشخص سازگار می‌کند. این کار می‌تواند شامل انتخاب کرنل، کامپایل گراف، دسته‌بندی، برنامه‌ریزی حافظه، کش‌گذاری و شتاب‌دهی ویژه سخت‌افزار باشد. TensorRT Model Connect شرکت NVIDIA که به‌صورت پیش‌نمایش عمومی معرفی شده، نمونه‌ای از ابزارهایی است که با هدف تبدیل چک‌پوینت‌های پشتیبانی‌شده Hugging Face یا محلی به استنتاج سرتاسری TensorRT، بدون خروجی‌گرفتن میانی به ONNX، طراحی شده‌اند. هدف اعلام‌شده آن شامل بارهای کاری رباتیک، دستگاهی و پلتفرمی است.

این تکنیک‌ها یکدیگر را تقویت می‌کنند. تقطیر می‌تواند مدلی فشرده تولید کند؛ کوانتیزه‌سازی می‌تواند حجم آن را باز هم کاهش دهد؛ و یک زمان‌اجرای بهینه‌سازی‌شده می‌تواند مشخص کند که آیا مدل حاصل واقعاً روی تراشه موردنظر سریع است یا نه.

نتیجه مفید با فایل کوچک‌تر یکسان نیست

فشرده‌سازی مدل باید به‌عنوان کاری محصولی و سامانه‌ای تلقی شود، نه ترفندی برای جدول رتبه‌بندی. مدلی که 40 درصد کوچک‌تر است اما در نور نامناسب اشیای حیاتی را از دست می‌دهد، ممکن است برای یک ربات انبار بدتر باشد. یک مدل زبانی که به‌ازای هر توکن ارزان است اما خروجی ساختاریافته ناقص تولید می‌کند، ممکن است کار تعمیر در مراحل بعدی را افزایش دهد. مدلی که در یک محک عملکرد خوبی دارد، ممکن است با ورود کاهش سرعت حرارتی، نویز دوربین، اتصال ناپایدار یا ورودی‌های غیرمعمول کاربر شکست بخورد.

گزارش Liquid AI درباره تقطیر آگاه از کوانتیزه‌سازی برای مدل‌های کوچک LFM2.5 آن، نمونه مفیدی از این هدف است. این شرکت گزارش کرد که ضمن حفظ مصرف حافظه و توان عملیاتی Q4_0، بین 96.5% تا 97.4% عملکرد BF16 را حفظ کرده است. این ارقام از سوی شرکت گزارش شده‌اند و مختص این مدل هستند؛ نباید آن‌ها را به هر معماری تعمیم داد. اما نشان می‌دهند متخصصان باید به‌دنبال چه نوع مقایسه‌ای باشند: سنجش حفظ کیفیت در کنار حافظه و سرعت، نه صرفاً نسبت فشرده‌سازی.

برای یک استقرار، آزمون پذیرش باید دست‌کم شامل موارد زیر باشد:

  • کیفیت کار روی نمونه‌های دشوار و نماینده؛
  • نیازهای حافظه و فضای ذخیره‌سازی اوج؛
  • تأخیر پاسخ نخست و حالت پایدار؛
  • توان عملیاتی در شرایط هم‌زمانی واقع‌گرایانه؛
  • مصرف انرژی یا رفتار حرارتی، در صورت مرتبط بودن؛
  • رفتار هنگام شکست، وقتی ورودی‌ها ناقص، نویزی یا خارج از توزیع هستند؛
  • هزینه و بار عملیاتی به‌روزرسانی مدل.

معیارهای دقیق بسته به محصول متفاوت‌اند. یک دوربین ممکن است به نرخ فریم بر ثانیه و موارد منفی کاذب اهمیت دهد. یک رابط صوتی ممکن است زمان پاسخ سرتاسری را مهم بداند. یک ربات ممکن است به مهلت‌های حلقه کنترل و رفتار بازگشت ایمن اهمیت دهد. نکته این است که ارزیابی مدل را به پیامدهای فیزیکی یا مالی شکست پیوند بزنیم.

کار جدید کجا پدیدار می‌شود

فرصتِ رو‌به‌گسترش به افرادی که معماری طراحی می‌کنند محدود نیست و چندین نقش عملی را نیز دربرمی‌گیرد:

  • مهندسان استنتاج مدل‌ها را روی شتاب‌دهنده‌های هدف ارزیابی می‌کنند، محیط‌های اجرا را انتخاب می‌کنند، گراف‌ها را بهینه می‌کنند و گلوگاه‌های تأخیر یا حافظه را تشخیص می‌دهند.
  • مهندسان فشرده‌سازی مدل خط‌لوله‌های کوانتیزه‌سازی و تقطیر را طراحی می‌کنند، داده‌های کالیبراسیون را برمی‌گزینند و افت کیفیت را بر اساس وظیفه و بخش اندازه‌گیری می‌کنند.
  • مهندسان یادگیری ماشین لبه مدل‌ها را برای محیط‌های موبایل، نهفته، صنعتی یا خودرویی بسته‌بندی می‌کنند و به‌روزرسانی‌ها را با وجود اتصال محدود مدیریت می‌کنند.
  • مهندسان نرم‌افزار رباتیک مدل‌های ادراک را در جاهایی که زمان‌بندی اهمیت دارد، به حسگرها، سامانه‌های برنامه‌ریزی و محدودیت‌های ایمنی متصل می‌کنند.
  • مهندسان محصولِ آگاه از سخت‌افزار تصمیم می‌گیرند یک بارِ کاری باید روی دستگاه، در لبه یا در ابر اجرا شود—و انتقال‌های روان میان آن‌ها را طراحی می‌کنند.
  • متخصصان استقرار و اعتبارسنجی مجموعه‌آزمون‌هایی می‌سازند که شرایط حرارتی، توان، شبکه و محیط واقعی را نیز شامل می‌شود.

کاربردها نیز برای توسعه‌دهندگان نرم‌افزار کار ایجاد می‌کنند. ممکن است یک تیم محصول مدلی را آموزش ندهد، اما همچنان باید قالب مدل را انتخاب کند، یک کتابخانه استنتاج را یکپارچه کند، با عملگرهای پشتیبانی‌نشده کنار بیاید، رفتار اطمینان یا خودداری از پاسخ را در معرض استفاده قرار دهد و امکان بازگشت‌پذیر بودن ارتقاها را فراهم کند.

تفکیک ابر و لبه در حال تبدیل شدن به یک مهارت طراحی است

مدل‌های کوچک، مدل‌های ابری را حذف نمی‌کنند؛ بلکه سیستم‌های ترکیبی را جذاب‌تر می‌سازند. یک دستگاه ممکن است برای تشخیص فوری از مدلی فشرده استفاده کند و سپس رویدادهای منتخب را برای توضیح یا تحلیل عمیق‌تر به مدلی بزرگ‌تر بفرستد. یک ربات ممکن است ادراکِ حیاتی برای ایمنی را به‌صورت محلی نگه دارد و در عین حال برای یادگیری در سطح ناوگان از ابر استفاده کند. یک محصول پشتیبانی مشتری ممکن است دسته‌بندی‌های معمول را به مدلی کوچک بسپارد و موارد مبهم را به مدل توانمندتری ارجاع دهد.

این معماری می‌تواند پهنای باند و تأخیر را کاهش دهد، اما تصمیم‌هایی را وارد می‌کند که به مالکیت مشخص نیاز دارند. چه اطلاعاتی از دستگاه خارج می‌شود؟ بدون اتصال چه اتفاقی می‌افتد؟ کدام نسخه مدل یک اقدام را تولید کرده است؟ آیا دستگاه می‌تواند با ایمنی به نسخه قبلی بازگردد؟ وقتی هر پیکربندی سخت‌افزاری رفتار متفاوتی دارد، عملکرد چگونه پایش می‌شود؟

این‌ها پرسش‌های استقرارند، نه صرفاً پرسش‌های مدل. این مسائل به متخصصانی پاداش می‌دهند که رابط‌های میان یادگیری ماشین، سامانه‌های نهفته، شبکه، نیازمندی‌های محصول و عملیات را درک می‌کنند.

یک مسیر یادگیری عملی

اگر می‌خواهید به این حوزه وارد شوید، به‌جای گردآوری صرفِ گواهی‌نامه‌های مدل، یک استقرار کوچک اما قابل‌اندازه‌گیری بسازید. با وظیفه‌ای شروع کنید که هدفی روشن دارد؛ مانند طبقه‌بندی تصویر، تشخیص کلمه کلیدی، دسته‌بندی اسناد یا یک دستیار محلی فشرده.

  1. یک خط مبنا تعیین کنید. کیفیت، اندازه مدل، میزان استفاده از حافظه، تأخیر و توان عملیاتی را با استفاده از مجموعه‌آزمونی بازتولیدپذیر ثبت کنید.
  2. آن را کوانتیزه کنید. دست‌کم یک نسخه با دقت پایین‌تر را با خط مبنا مقایسه کنید. مستند کنید کدام نمونه‌ها تغییر می‌کنند و آیا خطاها در یک دسته مهم متمرکز می‌شوند یا نه.
  3. تقطیر یا ریزتنظیم ویژه وظیفه را امتحان کنید. اندازه‌گیری کنید که آیا یک مدل کوچک‌تر می‌تواند رفتاری را که محصول واقعاً نیاز دارد حفظ کند یا نه.
  4. آن را روی سخت‌افزار هدف اجرا کنید. یک محک‌زنی روی رایانه رومیزی درباره تلفن، ریزرایانه، GPU، شتاب‌دهنده یا رایانه رباتی هیچ مدرکی ارائه نمی‌کند.
  5. استقرار را بسته‌بندی کنید. پیش‌پردازش، پس‌پردازش، فراداده نسخه، بررسی‌های سلامت و یک مسیر جایگزین را در آن بگنجانید.
  6. گزارش بده‌بستان‌ها را بنویسید. توضیح دهید چرا مدل انتخاب‌شده از نظر کیفیت، تأخیر، حافظه، انرژی، حریم خصوصی و هزینه برتری دارد—نه فقط چرا بهترین امتیاز را کسب کرده است.

ابزارهای مفید به پشته هدف بستگی دارند، اما مهارت‌های قابل‌انتقال ثابت‌اند: پروفایل‌سازی، استدلال عددی، انتخاب داده، طراحی آزمون، اشکال‌زدایی و انتقال روشنِ بده‌بستان‌ها. یاد بگیرید گراف مدل را بخوانید، پشتیبانی از عملگرها را بررسی کنید، جابه‌جایی حافظه را به‌عنوان گلوگاه شناسایی کنید و محاسبات نظری را از تأخیر اندازه‌گیری‌شده سرتاسری متمایز کنید.

نشانه شغلی

تغییر مهم شغلی این است که به‌جای پرسیدن «کدام مدل باهوش‌تر است؟» بپرسیم «کدام سامانه با وجود محدودیت‌های واقعی، نتیجه موردنیاز را ارائه می‌دهد؟» مدل‌های بزرگ همچنان ارزشمند خواهند بود، به‌ویژه برای استدلال باز و تولید پیچیده. اما بسیاری از وظایف تجاری و دنیای فیزیکی آن‌قدر محدود هستند که یک مدل فشرده، سریع و خصوصی می‌تواند محصول بهتری باشد.

این موضوع برای متخصصانی که می‌توانند پژوهش و استقرار را به هم پیوند دهند، فضا ایجاد می‌کند. برنده‌ها همیشه تیم‌هایی نخواهند بود که بزرگ‌ترین مدل را دارند. آن‌ها ممکن است تیم‌هایی باشند که بارِ کاری را درک می‌کنند، هوشمندانه فشرده‌سازی می‌کنند، صادقانه محک‌زنی می‌کنند و سامانه‌ای قابل‌اعتماد را روی سخت‌افزار موجود به بازار عرضه می‌کنند.

برای یک مسیر شغلی در هوش مصنوعی، این درسی ماندگار است: هوشمندی فقط یک بخش از محصول تحویلی است. بخش دیگر، سازگار کردن آن است.