پرش به محتوای اصلی
پرش به محتوای مقاله

کوانتش یکپارچه در برابر ترکیبی؛ تفاوت در حفظ جزئیات تصویر

·۲۴ مرداد ۱۴۰۵۶ دقیقه مطالعه۱ بازدید
راهنما
کوانتیزاسیون مدل بینایی-زبانی: تفاوت‌ها در چیست؟
کوانتیزاسیون مدل بینایی-زبانی: تفاوت‌ها در چیست؟
اشتراک‌گذاری
واقعاً چه چیز جدید است؟

معرفی متدولوژی «کوانتش انتخابی» برای VLMها؛ اثبات اینکه حفظ دقت کامل در کمتر از ۱ گیگابایت از پارامترها (برج بینایی و سازگارساز) می‌تواند از تخریب کامل قابلیت‌های بصری جلوگیری کند.

تصور کنید مدل بینایی-زبانی شما به شدت روان صحبت می‌کند، اما در واقع نسبت به جزئیات تصویری که توصیف می‌کند، تقریباً نابیناست. این پارادوکس زمانی رخ می‌دهد که عملیات کوانتش (Quantization) — یعنی کاهش دقت اعداد برای اشغال حافظه کمتر — به‌صورت یک بلوک یکپارچه و یکنواخت روی کل مدل اعمال شود.

به نقل از راهنمای فنی منتشر شده در dev.to در ۱۵ اوت ۲۰۲۶، کلید حفظ دقت بصری در این است که با مدل نه به‌عنوان یک واحد، بلکه به‌عنوان سه جزء مجزا با تحمل‌های متفاوت نسبت به خطای گرد کردن برخورد کنیم.

بسیاری از توسعه‌دهندگان با مدل‌های VLM (Vision-Language Model) — مدل‌هایی که هم‌زمان متن و تصویر را می‌فهمند، مثل ما که با چند حس دنیا را می‌خوانیم — به‌عنوان یک فایل یا چک‌پوینت واحد برخورد می‌کنند. اما این مدل‌ها در واقع ترکیبی از یک رمزگذار بینایی، یک لایه سازگارساز و یک بدنه زبانی هستند. با تکیه بر پوشش‌های قبلی ما درباره اینکه مدل‌های بازگشتی مانند Prime Agent چگونه کدها را بهینه می‌کنند، همین اصل «آگاهی ساختاری» در اینجا نیز صدق می‌کند: شما نمی‌توانید یک بهینه‌سازی کلی و یکسان را روی یک معماری ناهمگن اعمال کنید بدون اینکه قابلیت‌های حیاتی مدل را از دست بدهید.

یک مدل VLM را شبیه به مترجمی تصور کنید که عکسی را می‌بیند و گزارشی می‌نویسد. اگر چشم‌ها (برج بینایی) و مسیر عصبی (لایه سازگارساز) را تضعیف کنید، مغز (مدل زبانی) همچنان گزارشی زیبا و سلیس می‌نویسد، اما این گزارش بر اساس تصویری تار و دگرگون است. در دنیای هوش مصنوعی، این وضعیت به‌صورت مدلی ظاهر می‌شود که شکل کلی یک نمودار را درست توصیف می‌کند، اما اعداد داخل آن را اشتباه می‌گوید.

معماری یک مدل بینایی-زبانی

یک VLM صرفاً یک مدل با ورودی‌های اضافی نیست، بلکه سه بخش است که به هم جوش خورده‌اند و هر کدام بودجه پارامتری متفاوتی دارند:

  • برج بینایی (Vision Tower): معمولاً یک رمزگذار از خانواده ViT است. این بخش تصویر را به شبکه‌ای از بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که می‌گوید این کلمه همسایه چه کلمات دیگری است — تبدیل می‌کند. این برج معمولاً شامل چند صد میلیون پارامتر است که تنها کسری از یک درصد تا چند درصد از کل چک‌پوینت را تشکیل می‌دهد. در این راستا، ابزارهایی مانند Oxlo.ai با تبدیل زبان طبیعی به مختصات مکانی تلاش کرده‌اند تا دقت در تفکیک اجزای تصویر را افزایش دهند.
  • لایه سازگارساز (Projector): ماژول کوچکی که بردارهای بصری را به فضای توکن‌های مدل زبانی منتقل می‌کند. این لایه می‌تواند یک لایه خطی ساده، یک MLP دو لایه یا یک resampler با پرس‌وجوهای یادگرفته شده باشد. با داشتن تنها چند میلیون پارامتر، این بخش تنگ‌ترین گلوگاه مدل است؛ هر بیت از اطلاعات بصری باید از این مسیر عبور کند.
  • بدنه زبانی (Language Backbone): ترنسفورمری که توکن‌های تصویرِ تبدیل‌شده را در کنار توکن‌های متنی مصرف می‌کند. این جزء تقریباً همیشه اکثریت مطلق پارامترهای مدل را در اختیار دارد.

ریاضیات کوانتش انتخابی

راهنمای مذکور یک مثال عینی از یک VLM ارائه می‌دهد که دارای بدنه زبانی ۷ میلیارد پارامتری، برج بینایی ۴۰۰ میلیونی و سازگارساز ۲۰ میلیونی است. در یک تنظیمات استاندارد FP16، توزیع حافظه به این صورت است:

  • بدنه زبانی: 7.00e9 * 2 = ۱۴.۰۰ گیگابایت
  • برج بینایی: 4.00e8 * 2 = ۰.۸۰ گیگابایت
  • سازگارساز: 2.00e7 * 2 = ۰.۰۴ گیگابایت
  • مجموع: ۱۴.۸۴ گیگابایت

حالا وقتی دو سیاست کوانتش را با هم مقایسه می‌کنیم، تفاوت در میزان حافظه به‌طور غافلگیرکننده‌ای کوچک است:

  • سیاست الف (کوانتش ۴ بیتی برای همه): 7.42e9 * 4 / 8 = ۳.۷۱ گیگابایت.
  • سیاست ب (کوانتش فقط برای بدنه زبانی): بدنه زبانی (7.00e9 * 4 / 8 = ۳.۵۰ گیگابایت) + برج بینایی/سازگارساز (۰.۸۴ گیگابایت) = ۴.۳۴ گیگابایت.

انتخاب سیاست ب تنها ۰.۶۳ گیگابایت (۱۷٪) حافظه بیشتر از سیاست الف می‌طلبد، اما در عین حال ۱۱.۱ گیگابایت نسبت به نسخه اصلی FP16 صرفه‌جویی می‌کند. طبق گزارش dev.to، این تبادل کوچک در حافظه، تمام تردیدها را درباره اینکه آیا بردارهای بصری نسبت به تصویر اصلی وفادار می‌مانند یا خیر، از بین می‌برد. این رویکرد از اصل کلی «کوانتش با دقت ترکیبی» پیروی می‌کند: هر آنچه ارزان است اما از نظر ساختاری حساس است را در دقت بالا نگه دارید.

تله کالیبراسیون

یک نقطه شکست بحرانی در مرحله کالیبراسیون (Calibration) — یعنی تنظیم مدل برای تعیین اینکه کدام خطاهای گرد کردن قابل تحمل هستند — رخ می‌دهد. اگر توسعه‌دهنده برای این فرآیند فقط از داده‌های متنی استفاده کند، مدل هرگز فعال‌سازهای (Activations) خاصی را که بردارهای بصری تولید می‌کنند، نمی‌بیند.

بردارهای بصری در ناحیه‌ای از فضای برداری قرار دارند که با توکن‌های متنی کاملاً متفاوت است. آن‌ها توسط ماژول متفاوتی تولید می‌شوند، از لغت‌نامه (Vocabulary) مدل گرفته نشده‌اند و آمارهای هر کانال (per-channel statistics) آن‌ها متفاوت است. وقتی الگوریتم‌هایی مثل GPTQ (که یک ماتریس Hessian می‌سازد) یا AWQ (که بزرگی هر کانال را جمع‌آوری می‌کند) فقط روی متن کالیبره می‌شوند، به این نتیجه می‌رسند که کانال‌های حامل محتوای بصری «ارزان» هستند و می‌توان آن‌ها را تخریب کرد.

نتیجه این امر یک شکست خاموش است. کیفیت متن مدل بالا می‌ماند، اما مبنی‌سازی (Grounding) — یعنی اتصال پاسخ مدل به واقعیت‌های موجود در تصویر — تخریب می‌شود. مدل همچنان تصاویر را توصیف می‌کند، اما این کار را با دقت کمتری انجام می‌دهد و بنچ‌مارک‌های متنی استاندارد، این افت کیفیت را شناسایی نخواهند کرد.

پیاده‌سازی عملی و «لیست نادیده گرفتن»

برای جلوگیری از این مشکل، توسعه‌دهندگان باید از یک لیست استثنا — که اغلب modules_to_not_convert یا skip_modules نامیده می‌شود — استفاده کنند تا مسیر بصری محافظت شود. مستندات خودِ Transformers پیشنهاد می‌کند از modules_to_not_convert برای اجزایی مانند رمزگذار Llava، رمزگذار Whisper یا لایه‌های گیت Mixtral استفاده شود.

پروژه vLLM در ابزار llm-compressor از الگوهای Regex برای اطمینان از اینکه برج بینایی و سازگارساز چند-وجهی در دقت کامل باقی می‌مانند، استفاده می‌کند. یک دستورالعمل نمونه به این شکل است:

ignore = [ "re:.*lm_head", "re:.*vision_tower.*", "re:.*multi_modal_projector.*", ]
recipe = GPTQModifier( targets="Linear", scheme="W4A16", sequential_targets=["MistralDecoderLayer"], ignore=ignore, )

قوانین کلیدی پیاده‌سازی عبارتند از:

  • حذف Head: لایه lm_head باید در کنار اجزای بینایی استثنا شود تا پایداری دقت ترکیبی حفظ شود.
  • تأیید الگوها: نام ماژول‌ها بسته به خانواده مدل متفاوت است. الگوهایی مانند vision_tower ،visual ،vision_model ،multi_modal_projector ،mm_projector و merger در مدل‌های مختلف دیده می‌شوند. توسعه‌دهندگان باید پیش از اجرای نهایی، نام ماژول‌های مدل را چاپ کنند تا مطمئن شوند الگوها با نام‌ها مطابقت دارند.
  • استفاده از جفت‌های تصویر-متن: مجموعه‌های کالیبراسیون باید شامل جفت‌های واقعی تصویر-متن باشند که از طریق پردازشگر خودِ مدل عبور کرده‌اند — یعنی با همان تغییر اندازه (resize)، تکه‌بندی (patching) و قالب چت که توکن‌های جایگزین تصویر در جایگاه واقعی خود قرار دارند.
  • استفاده از Custom Data Collators: برخی از خانواده‌های مدل به دلیل اینکه پردازشگرهایشان ورودی‌هایی تولید می‌کنند که با ابزارهای عمومی دسته‌بندی (batch) نمی‌شوند، به جمع‌آورنده‌های داده سفارشی نیاز دارند.

شناسایی شکست‌های کوانتش

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

قابلیت‌های نویسه‌خوانی نوری (OCR) و تشخیص جزئیات ریز، اولین قربانیان هستند. خواندن متن‌های کوچک به دقت در کل مسیر (از برج تا بدنه) نیاز دارد. اگر کیفیت OCR افت کرد اما توصیفات کلی ثابت ماند، احتمالاً سازگارساز یا برج بینایی به‌اشتباه کوانتیده شده‌اند.

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

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

گام بعدی شما

  • اگر از مدل‌های کوانتیده VLM استفاده می‌کنید، خروجی‌های OCR را با نسخه FP16 مقایسه کنید تا از عدم کوانتش تصادفی برج بینایی مطمئن شوید.
  • در هنگام کالیبراسیون، حتماً از مجموعه‌ای از داده‌های ترکیبی (تصویر-متن) استفاده کنید و از کالیبراسیون صرفاً متنی بپرهیزید.
  • لیست skip_modules خود را با چاپ کردن named_modules مدل تطبیق دهید تا از صحت Regexها مطمئن شوید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell و مدیریت حافظه در استنتاج مراجعه کنید.

چرا این موضوع مهم است؟

این رویکرد اجازه می‌دهد مدل‌های بینایی-زبانی قدرتمند روی سخت‌افزارهای مصرف‌کننده با کمترین افت کیفیت اجرا شوند. تخصص در مدیریت دقت ترکیبی، مرز بین یک مدل کاربردی و یک مدل «نابینا» را تعیین می‌کند.

تأثیر برای ایران

برای توسعه‌دهندگان ایرانی که با محدودیت GPU مواجه‌اند، این متد اجازه می‌دهد مدل‌های VLM را با حافظه بسیار کمتر و بدون از دست دادن دقت OCR روی سخت‌افزارهای موجود اجرا کنند.

·نگاه ما
تحریریه دات‌هوش

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

منابع

این گزارش با خط‌لولهٔ خودکار دات‌هوش از منابع معتبر جهانی تدوین و زیر نظر تحریریه منتشر شده است. روش کار ما

گفتگو

پنج‌شنبه‌های هوش‌محور

بسته‌ی هفتگی دات‌هوش

۵ خبر، ۲ ابزار، ۱ پرامپت در هر شماره. به‌زودی راه‌اندازی می‌شود — هر پنج‌شنبه صبح.

خبر کلیدی
ابزار کاربردی
پرامپت حرفه‌ای
تحلیل پژوهش
به‌زودی
زاویه‌ی ایرانی
به‌زودی
تمرین این هفته
به‌زودی

راهنماهای دات‌هوش

راهنماهای کاربردیِ دات‌هوش برای کار با هوش مصنوعی — از همین‌جا شروع کنید:

دات‌هوش

راهنمای فارسی هوش مصنوعی — با نگاه به ایران

اخبار روزانه، معرفی ابزارها و مدل‌ها، و آموزشِ کار با هوش مصنوعی؛ همیشه با این پرسش که از ایران چه چیزی کار می‌کند و چه چیزی نه.