نسخه ۰٫۷۴٫۰ Soup یک خطای مدیریت حافظه را اصلاح کرده که میتوانست آموزش با LoRA را بسیار پرمصرفتر از چیزی نشان دهد که از تنظیمات مدل انتظار میرود. این نسخه در ۴ سپتامبر منتشر شد و سه مسیر بارگذاری مدل را تغییر داد؛ مسیرهایی که مدل پایه منجمد را با دقت fp32 در حافظه میساختند، در حالی که وزنهای آن اصلاً در فرایند بهینهسازی تغییر نمیکردند.
طبق یادداشت انتشار نسخه ۰٫۷۴٫۰، در آزمایش خود پروژه روی H100 با Llama-3.1-8B و LoRA، اوج مصرف حافظه از ۴۸٬۲۴۱ به ۱۸٬۶۵۸ MiB رسید. Soup این کاهش را ۲٫۵۹ برابر گزارش کرده و میگوید نتیجه در سه اجرای تکراری از نظر بایتی یکسان بوده است. این اعداد هنوز بازتولید مستقل ندارند و باید بهعنوان اندازهگیری خود پروژه خوانده شوند. بسته soup-cli 0.74.0 در PyPI نیز منتشر شده است.
مشکل از یک پیشفرض بارگذاری بود، نه از بزرگتر شدن مدل
نکته فنی اصلی این است که مدل پایه منجمد با دقت عددی بیش از نیاز بارگذاری میشد. توضیح Soup نشان میدهد سه مسیر from_pretrained برای متن، تصویر و صوت، نوع داده را صریح تعیین نمیکردند و در نتیجه وزنهای پایه با fp32 در حافظه قرار میگرفتند. در تنظیم دقیق مبتنی بر LoRA، همین مدل پایه ثابت میماند و تنها مجموعه بسیار کوچکتری از پارامترهای افزوده آموزش میبیند.
در نسخه جدید، مدل پایه منجمد با دقت ثبتشده در فایل وزنهای مدل بارگذاری میشود؛ اما اگر خود مدل پایه قرار باشد بهطور کامل آموزش ببیند، fp32 عمداً حفظ میشود. بنابراین کاهش حافظه حاصل فشردهسازی تازه یا تغییر معماری نیست؛ مشکل، نحوه نمایش وزنهایی بود که اصلاً قرار نبود بهروزرسانی شوند.
همزمان، منطق تشخیص «تنظیم دقیق کامل» نیز یکپارچه شده است. پیش از این، بخش آموزش و برآورد اولیه حافظه هر کدام پیادهسازی جداگانهای داشتند و ممکن بود درباره قابلآموزش بودن مدل پایه به نتیجه متفاوت برسند. اکنون برآورد پیش از اجرا و مسیر واقعی بارگذاری از یک تصمیم مشترک استفاده میکنند.
اختلاف ۲۸٫۹ گیگابایتی میتواند انتخاب سختافزار را عوض کند
جمعبندی مهندسی Aipolix این است که پیشفرضهای چارچوب آموزش باید بخشی از برنامهریزی ظرفیت باشند، نه موضوعی که فقط هنگام عیبیابی بررسی میشود. ممکن است تیم اندازه مدل، شیوه کمدقتسازی و تنظیمات LoRA را درست انتخاب کرده باشد، اما اگر چارچوب هنگام بارگذاری نوع داده مؤثر را تغییر دهد، برآورد نیاز GPU همچنان اشتباه از آب درآید.
در آزمایش H100 خود Soup، تفاوت گزارششده در اوج مصرف حافظه ۲۸٫۹ گیگابایت بود. چنین اختلافی میتواند تعیین کند یک کار روی شتابدهنده موجود جا میشود یا به نمونه بزرگتری نیاز دارد و حتی میتواند بر محاسبه هزینه تنظیم دقیق اثر بگذارد.
این نکته محدود به Soup نیست. برای برآورد واقعی ظرفیت GPU باید نوع دادهای که وزنها واقعاً با آن در حافظه قرار گرفتهاند و قابلآموزش بودن مدل پایه بررسی شود و سپس اوج مصرف اندازهگیریشده با برآورد اولیه مقایسه شود. صرف وجود یک مقدار در فایل تنظیمات، تضمین نمیکند همان تصمیم در زمان اجرا اعمال شده باشد.
نسخه جدید مرزهای خطا و امنیت را هم سختگیرانهتر کرده است
نسخه ۰٫۷۴٫۰ فقط به حافظه مربوط نیست. چند کنترل در بخش سرویسدهی و ابزارهای Soup نیز تغییر کردهاند.
پروژه اعلام کرده مسیر /v1/tools/bash دوباره فعال شده، اما این بار اجرای فرمان در فضای نام و محیط ایزوله سیستمعامل انجام میشود. چون این مسیر واقعاً کد اجرا میکند، soup serve در صورت اتصال به نشانی غیرمحلی بدون --tool-auth-token دیگر فقط هشدار نمیدهد و با کد خروج ۲ متوقف میشود. این نسخه همچنین چهار شیوه جایگزین نوشتن نشانی IPv4 را که میتوانستند کنترل نشانیهای تلهمتری، وبهوک و OTLP را دور بزنند مسدود کرده و در SGLang، اجرای کد راهدور مدل را به گزینه صریح --trust-remote-code وابسته کرده است.
این موارد ادعاهای عملکردی مستندشده در یادداشت انتشار هستند. اهمیتشان در این است که شرایط پرخطر از حالت «هشدار» یا «پیشفرض ضمنی» به توقف صریح یا انتخاب آگاهانه کاربر نزدیک شدهاند.
سازگاری بهتر شده، اما یک محدودیت وابستگی باقی مانده است
Soup 0.74.0 پشتیبانی از Transformers 5.x، TRL 0.29 و PEFT 0.20 را اضافه کرده، ترکیب افزونههای train,mlx را دوباره قابل نصب کرده و مسیر Transformers را برای رمزگشاهای خانواده Qwen3.5 گسترش داده است. فرمان تازه آموزش روی Lambda نیز ابتدا برنامه اجرا را میسازد و کلید API را روی دستگاه محلی نگه میدارد؛ کنترل پایان دادن به نمونه ابری هم در اختیار یک کنترلکننده محلی است.
در عین حال، خود پروژه یک محدودیت روشن را ثبت کرده است: حداقل نسخه اعلامشده torch>=2.5.0 در عمل با trl>=0.29 سازگار نیست. Soup خرابی را روی torch 2.5.1 اندازهگیری کرده، زیرا نماد لازم FSDPModule وجود ندارد. نصب تازهای که نسخه جدیدتری از Torch میگیرد ممکن است این مشکل را نبیند، اما محیطی که روی شاخه ۲٫۵ قفل شده میتواند پشتیبانی از DPO، KTO، GRPO و BCO را از دست بدهد.
این اعتراف فنی نکته مهمی دارد: اینکه مدیر بستهها وابستگیها را بدون خطا حل میکند، به معنی آزموده شدن آن ترکیب در عمل نیست.
عدد ۲٫۵۹ برابر را باید در محدوده همان آزمایش خواند
کاهش حافظه قابل توجه است، اما دامنه ادعا باید محدود بماند. عدد منتشرشده از آزمایش داخلی پروژه روی H100 با Llama-3.1-8B و LoRA میآید. Soup سه اجرای یکسان از نظر بایتی را گزارش کرده، ولی Aipolix بازتولید مستقلی برای نتیجه نسخه ۰٫۷۴٫۰ پیدا نکرد.
بنابراین نمیتوان انتظار کاهش ۲٫۵۹ برابری را به همه مدلها، GPUها، روشهای کمدقتسازی یا مسیرهای آموزش تعمیم داد. ادعای قابل دفاع این است که یک مسیر بارگذاری fp32 اصلاح شده و پروژه در یک پیکربندی مشخص کاهش بزرگی اندازهگیری کرده است.
قابلیت «بارگذاری لایهای» Soup که برای آموزش مدلهای پایه بزرگ روی GPUهای کوچک طراحی شده نیز همچنان صریحاً در وضعیت آزمایشی است و این نسخه آن وضعیت را تغییر نمیدهد.
پس از ارتقا چه چیزی را اندازه بگیریم؟
تیمی که از Soup استفاده میکند بهتر است همان کاری را که مبنای برآورد ظرفیت بوده دوباره اجرا کند و نوع داده واقعی وزنها، اوج حافظه تخصیصیافته و رزروشده GPU، منجمد یا قابلآموزش بودن مدل پایه، تنظیمات LoRA و نسخه دقیق Soup، Torch، Transformers، TRL و PEFT را ثبت کند.
پرسش مفید فقط این نیست که نسخه جدید حافظه کمتری مصرف میکند یا نه. مهمتر این است که مصرف واقعی حالا تا چه حد با فرضهای برنامهریزی ظرفیت همخوان شده و آیا میتوان بر همان مبنا اندازه نمونه GPU و هزینه را پیشبینی کرد.
این انتشار یادآوری میکند که بهرهوری تنظیم دقیق میتواند در لایهای پایینتر از الگوریتم از بین برود. ممکن است LoRA روی کاغذ کمهزینه باشد، اما یک پیشفرض چارچوب وزنهای ثابت را با دقتی گرانتر در حافظه قرار دهد. اصلاح چنین مرزی میتواند به اندازه تغییر روش آموزش، بر اقتصاد اجرای کار اثر بگذارد.