Soup: تنظیم دقیق مدل‌های ۸ میلیارد پارامتری با حافظه ۴ گیگابایتی GPU

تصور کنید یک کارت گرافیک قدیمی RTX 3050 با تنها ۴ گیگابایت حافظه در اختیار دارید؛ اکنون می‌توانید با آن یک مدل ۸ میلیارد پارامتری را تنظیم دقیق کنید. این دستاورد مدیون Soup است، چارچوبی متن‌باز که در گیت‌هاب منتشر شده و لایه‌های مدل پایه منجمد را یکی‌یکی از رم سیستم (Host RAM) به GPU منتقل می‌کند تا نیاز به بافرهای حجیم حافظه ویدیویی (VRAM) از بین برود.

تنظیم دقیق (Fine-tuning) — مثل وقتی به یک پزشک عمومی، تخصص پوست می‌دهیم تا مدل کلی روی یک حوزه دقیق شود — همیشه دردناک‌ترین بخش چرخه حیات مدل‌های زبانی بوده است. طبق گزارش‌های فنی، تیم‌های باتجربه ۳۰ تا ۵۰ درصد زمان خود را صرف جنگ با زیرساخت‌ها، از اتصال‌های SSH قطع‌شده تا کلنجار رفتن با فایل‌های پیکربندی پیچیده می‌کنند، به جای آنکه روی بهبود وزن‌های مدل تمرکز کنند. همان‌طور که در تحلیل قبلی ما درباره‌ی نقش تخصص دامنه در کیفیت خروجی‌ها اشاره کردیم، Soup دقیقاً روی حذف اصطکاک‌های فنی تمرکز کرده تا متخصصان بتوانند سریع‌تر روی داده‌های خود آزمایش کنند. وعده اصلی این ابزار «صفر شدن نیاز به SSH» است؛ یعنی دیگر لازم نیست برای مدیریت یک سرور گرافیکی خراب یا پیکربندی‌های دشوار، وارد محیط خط فرمان سرور شوید.

برای یک توسعه‌دهنده معمولی، این یعنی سد ورود به مرحله «پس‌آموزش» (Post-training) فرو ریخته است. دیگر نیازی به خوشه‌های ابری گران‌قیمت یا GPUهای سطح بالای A100 نیست تا تکنیک‌های پیشرفته همراستاسازی را امتحان کنید. کل این مسیر اکنون در یک فایل پیکربندی و یک دستور خلاصه شده است.

سازوکار: استریمینگ دقیق لایه‌ها

در قلب Soup تکنیکی به نام «استریمینگ دقیق لایه‌ها» (Exact Layer Streaming) قرار دارد. به جای بارگذاری کل مدل پایه در VRAM، سیستم هر بار تنها یک لایه رمزگشای (Decoder Layer) مدل را به GPU می‌فرستد. این کار باعث می‌شود مدل پایه در رم سیستم یا روی دیسک NVMe باقی بماند (که توسط تنظیم stream_source: auto مدیریت می‌شود) و حافظه گران‌بهای VRAM برای آداپتورهای (Adapter) قابل آموزش آزاد شود. این رویکرد یادآور دستاوردهایی مانند پروژه Colibrì است که امکان اجرای مدل‌های بسیار حجیم را تنها با رم محدود فراهم کرد تا محدودیت‌های سخت‌افزاری دیگر مانعی برای کار با مدل‌های عظیم نباشند.

این رویکرد صرفاً یک ترفند حافظه نیست، بلکه از نظر ریاضیاتی کاملاً «بیت-دقیق» (Bit-exact) است. بر اساس مستندات پروژه و مقاله پیش‌چاپ مربوط به آن (Makazhan، ۲۰۲۶)، اجرای استریم‌شده دقیقاً همان تنسورهایی را تولید می‌کند که اجرای غیر استریم‌شده تولید می‌کند؛ یعنی اختلاف صفر (0.0). این دقیق‌ترین استانداردی است که هر انتشار در این سری باید از آن عبور کند. پژوهش منتشرشده در Zenodo پروتکل‌های صحت‌سنجی را توصیف می‌کند که تضمین می‌کند خروجی‌های استریم‌شده با مدل‌های مقیم در حافظه یکسان باشند. در این راستا، ابزارهایی نظیر Picchio برای شناسایی خطاهای احتمالی مانند پس‌نشینی خاموش مدل به CPU توسعه یافته‌اند تا از صحت اجرای مدل‌ها در محیط‌های محلی اطمینان حاصل شود.

گسترش قابلیت‌های همراستاسازی

در نسخه ۰.۷۲.۴، Soup استریمینگ لایه‌ها را از تنظیم نظارت‌شده (SFT) به توابع زیان ترجیحی (Preference Losses) گسترش داد. پیش از این، استریمینگ فقط برای SFT کاربرد داشت، اما اکنون موارد زیر را پشتیبانی می‌کند:

• بهینه‌سازی مستقیم ترجیح (DPO): در حالت عادی، DPO به یک مدل مرجع برای مقایسه نیاز دارد که حافظه را دو برابر می‌کند و هدف استریمینگ را باطل می‌سازد. Soup با استفاده از همان مدل استریم‌شده اما با آداپتورهای خاموش، مشکل را حل می‌کند؛ یعنی یک مجموعه وزن و یک استریم. این کار مدل مرجع را در VRAM «رایگان» می‌کند.
• بهینه‌سازی كانمن-تورسکی (KTO): در حالی که اغلب به عنوان روشی بدون مرجع توصیف می‌شود، KTO مرجع خود را به همان روش DPO انتخاب می‌کند. بنابراین، در Soup از همان سازوکار استریم‌شده بهره می‌برد.
• ORPO و SimPO: این متدها اساساً بدون نیاز به مرجع هستند و اکنون کاملاً با استریمینگ لایه‌ها سازگار شده‌اند.

به نقل از داده‌های تست، در یک RTX 3050 با ۴ گیگابایت حافظه، اوج مصرف حافظه در DPO استریم‌شده تنها ۰.۹۱۴ برابر SFT بود. در مقابل، اجبار به استفاده از یک مدل دوم واقعی در همان تست، ۷۳۰ مگابایت حافظه بیشتر (دقیقاً معادل یک کپی از وزن‌ها) می‌طلبید. سیستم پیش‌پرواز VRAM این واقعیت را در نظر می‌گیرد که زیان‌های جفت‌شده (Paired Losses) دو برابر ردیف دارند، زیرا نمونه‌های «برگزیده» و «رد شده» به عنوان یک تنسور واحد از مدل عبور می‌کنند.

تبادل در اینجا روی «زمان» است نه «حافظه»: DPO در هر گام، پشته لایه‌ها را ۱.۵۲ برابر بیشتر از SFT می‌خواند. شایان ذکر است که روش‌های GRPO و PPO به دلیل اینکه تولید توکن در هر مرحله نیاز به بازخوانی تمام لایه‌ها دارد و استریمینگ نمی‌تواند این هزینه را کاهش دهد، عمداً از این قابلیت مستثنی شده‌اند.

گردش کار «تک دستوری»

Soup جهنمِ پیکربندی را با یک ابزار خط فرمان (CLI) ساده جایگزین کرده است. کاربران می‌توانند با pip install soup-cli هسته سبک را نصب کنند، اما برای استقرار پشته آموزشی به pip install "soup-cli[train]" نیاز دارند. برای محیط کامل شامل سرویس‌دهی و رابط کاربری، دستور pip install "soup-cli[all]" به کار می‌رود. همچنین توسعه‌دهندگان می‌توانند برای دسترسی به آخرین نسخه‌های توسعه، مستقیماً از گیت‌هاب نصب کنند: pip install git+https://github.com/MakazhanAlpamys/Soup.git.

برای جلوگیری از خطاهای شل (Shell) در محیط cmd.exe ویندوز (که از تک-کوتیشن پشتیبانی نمی‌کند) یا zsh (که کروشه‌ها را به عنوان glob می‌خواند)، استفاده از کوتیشن دوتایی برای بسته‌های اضافی اجباری است. آموزش‌های قدیمی که از تک-کوتیشن ('soup-cli[train]') استفاده می‌کردند، در ویندوز منجر به خطای ERROR: Invalid requirement می‌شوند زیرا شل کوتیشن‌ها را مستقیماً به pip می‌فرستد. اگرچه حذف کامل کوتیشن‌ها در ویندوز جواب می‌دهد، اما در zsh باعث شناسایی کروشه به عنوان glob و شکست عملیات می‌شود.

کاربران پروژه را با soup init (که دارای یک جادوگر یا Wizard تعاملی است) یا soup init --template chat آغاز می‌کنند. قالب‌های آماده‌ای برای طیف گسترده‌ای از نیازها در دسترس است: چت (chat)، کدنویسی (code)، فراخوانی ابزار (tool-calling)، پزشکی (medical)، استدلالی (reasoning)، بینایی (vision)، و همچنین KTO، ORPO، SimPO، IPO، BCO، RLHF، pretrain، مدل‌های MoE، بافت بلند (longcontext)، embedding و صوتی (audio). در نهایت، آموزش با یک فایل YAML واحد و دستور soup train --config soup.yaml شروع می‌شود.

ابزارهای پیشرفته و جزئیات فنی

Soup چندین ابزار سطح بالا برای تضمین کیفیت مدل و ریشه‌یابی (Provenance) ارائه می‌دهد:

سنتز پاداش (Reward Synthesis):

• دستور soup reward synth با اشاره به یک فایل JSONL از خروجی‌های مرجع، تاییدکننده‌های پاداش را شناسایی می‌کند.
• این ابزار یک تاییدکننده قطعی (Deterministic) را استنباط کرده و یک تابع پاداش پایتونی (.py) قابل خواندن و قابل ثبت در گیت (committable) می‌نویسد.
• سیستم از تولید توابعی که قادر به تشخیص پاسخ‌های مرجع از پاسخ‌های غلط نیستند، خودداری می‌کند.
• چهار خانواده خاص پشتیبانی می‌شوند: عددی (numeric)، طرحواره جی‌سون (json_schema)، عبارت منظم (regex) و فراخوانی ابزار (tool_call).
• یک گزارش کالیبراسیون اجباری (calib.json) به عنوان لایه حفاظتی کیفیت عمل می‌کند.
• مجموعه‌های پاداش (Reward Ensembles) مانند reward_fn: "accuracy,format" از ایشو ۳۱۱ به بعد پشتیبانی می‌شوند.

دروازه رگرسیون (Regression Gate):

• دستور soup ship یک دروازه رگرسیون سطح ۲ (leg-2) را با استفاده از یک امتیازگذار استخراجی ثابت پیاده می‌کند.
• تنظیمات در برابر هفت مجموعه آفلاین داخلی تست می‌شوند: MCQ، محاسبات عددی، فراخوانی ابزار، صحت JSON و ایمنی/رد درخواست.
• این ابزار از «فراموشی فاجعه‌بار» (Catastrophic Forgetting) جلوگیری می‌کند؛ وضعیتی که در آن مدل در یک تکلیف پیروز می‌شود اما توانایی فراخوانی ابزار را از دست می‌دهد.
• خروجی‌ها به صورت احکام باینری هستند: خروج ۰ (SHIP)، خروج ۲ (DON'T SHIP)، خروج ۳ (پرچم‌های نامعتبر) یا خروج ۱ (خطای زمان اجرا).

حاکمیت داده و CI:

• نسخه ۰.۷۱.۳۹ قابلیت اتصال ریشه‌ای (provenance-binding) را برای حکم «ship» معرفی کرد.
• پرچم --emit-evidence تضمین می‌کند که بازپخش (replay) یک اجرا، دقیقاً همان حکم را تولید کند.
• وجود eval.ship در فایل soup.yaml باعث می‌شود سیاست‌های دروازه قابل بررسی باشند.
• شواهد به دستورالعمل (recipe) دقیق متصل می‌شوند و شواهد قدیمی باعث خروج با کد ۳ می‌شوند.
• احکام از طریق soup ship --push owner/repo#N به PRها فرستاده می‌شوند تا کارت‌های SHIP/DON'T-SHIP نمایش داده شوند.

رمزگشایی گمانه‌زنانه (Speculative Decoding):

• دستور soup draft measure نرخ پذیرش مدل پیش‌نویس و سرعت واقعی توکن در ثانیه را در حالت عادی در مقابل حالت کمکی گزارش می‌کند.
• دستور soup draft distill یک مدل هدف را به یک مدل پیش‌نویس متراکم و کوچک تبدیل می‌کند که به صورت خودکار در soup serve --auto-spec سیم‌کشی می‌شود.
• تست‌های داخلی روی یک جفت مدل از یک خانواده نشان داد که تقطیر اثری بر نرخ پذیرش نداشت (۶۹.۳٪ به ۶۹.۳٪) و رمزگشایی کمکی باعث کاهش سرعت خالص شد که یک خط مبنای صادقانه برای توسعه‌دهندگان است.

سازگاری سخت‌افزاری و مدل‌ها

Soup با هر مدل تولید متن در HuggingFace Hub که با AutoModelForCausalLM بارگذاری شود، سازگار است. دستورالعمل‌های آماده‌ای برای Llama 3.x/4، Qwen 2.5/3، Gemma 3، Mistral، Mixtral، DeepSeek R1/V3 و Phi-4 وجود دارد.

نیازهای VRAM برای آموزش QLoRA ۴ بیتی (NF4) به شرح زیر است:

• ۸ گیگابایت: مدل‌های حداکثر ۷ میلیارد پارامتری (مثل Llama-3.1-8B, Mistral-7B).
• ۱۶ گیگابایت: مدل‌های حداکثر ۱۴ میلیارد پارامتری (مثل Phi-4-14B, Qwen2.5-14B).
• ۲۴ گیگابایت: مدل‌های حداکثر ۳۴ میلیارد پارامتری (مثل CodeLlama-34B, Yi-1.5-34B).
• ۴۸ گیگابایت: مدل‌های حداکثر ۷۰ میلیارد پارامتری (مثل Llama-3.3-70B).
• ۸۰ گیگابایت به بالا: مدل‌های ۷۰+ میلیاردی کامل یا معماری‌های MoE (مثل Mixtral-8x22B, DeepSeek-V3).

برای کسانی که CUDA محلی ندارند، یک ایمیج Docker آماده در ghcr.io/makazhanalpamys/soup:latest موجود است. کاربران می‌توانند با اجرای docker run --gpus all -v $(pwd):/workspace بدون نیاز به نصب PyTorch محلی، آموزش را شروع کنند. تمامی وظایف آموزشی برای تست روی CPU قابل اجرا هستند، هرچند در این حالت کوانتیزاسیون به صورت خودکار غیرفعال می‌شود.

استقرار و خروجی

پس از پایان آموزش، چارچوب انتقال به محیط تولید را مدیریت می‌کند. کاربران می‌توانند با soup merge آداپتورهای لورا را با مدل پایه ادغام کنند یا با soup export --format gguf مدل را به فرمت GGUF (مثلاً q4_k_m) برای استفاده در Ollama یا llama.cpp خروجی بگیرند.

سایر اهداف خروجی پشتیبانی شده عبارت‌اند از ONNX، TensorRT، AWQ، GPTQ و BitNet. برای تعامل زنده و استقرار، ابزارهای زیر در دسترس هستند:

• soup chat برای استفاده تعاملی.
• soup infer برای پردازش دسته‌ای از طریق پرامپت‌های ورودی (مثلاً --input prompts.jsonl).
• soup serve برای راه‌اندازی سرور API سازگار با OpenAI.
• soup push برای آپلود مدل‌ها به یک مخزن خاص.
• soup autopilot برای گردش کارهای بدون پیکربندی با دستور --model <id> --data d.jsonl --goal chat.

نکات پیاده‌سازی و عیب‌یابی

کاربران باید به یک باگ خاص در نسخه ۰.۷۲.۰ توجه کنند: آداپتورهایی که با stream_layers: true آموزش دیدند، به دلیل ذخیره‌سازی تنسورها با کلیدهایی که دارای بخش اضافی .inner. بودند، عملاً بی‌اثر بودند و لودرها مدل پایه تنظیم‌نشده را برمی‌گرداندند. این مشکل در نسخه ۰.۷۲.۱ اصلاح شد. کاربران می‌توانند با اجرای دستور زیر آداپتورهای خود را بررسی کنند:
python -c "from safetensors.torch import load_file; print([k for k in load_file('adapter_model.safetensors') if '.inner.' in k][:3])".

برای بررسی سلامت سیستم، soup doctor یک چک‌لیست جامع برای GPU، منابع سیستم، وابستگی‌ها و نسخه‌ها ارائه می‌دهد. خطاهای رایج ویندوز مانند ImportError: DLL load failed while importing _C معمولاً با نصب مجدد PyTorch برای نسخه خاص CUDA (مثلاً pip install torch --index-url https://download.pytorch.org/whl/cu121) حل می‌شوند.

اگر خروجی soup version با pip show soup-cli متفاوت بود، احتمالاً کاربر چندین نصب پایتون دارد و باید از محیط مجازی (Virtual Environment) استفاده کند. برای توسعه، این پروژه از ruff برای لینتینگ و pytest برای تست‌های واحد و تست‌های دود (Smoke Tests) پشتیبانی می‌کند.

قابلیت‌های گسترده و اکوسیستم

فراتر از آموزش‌های ساده، این پروژه یک مجموعه مستندات جامع را برای دامنه‌های پیشرفته نگهداری می‌کند:

• وظایف آموزشی: شامل SFT، DPO/GRPO/PPO/KTO/ORPO/SimPO/IPO/BCO، فراخوانی ابزار، PRM، پیش-آموزش، تقطیر (Distillation)، طبقه‌بندی، بینایی/صوت/TTS، یادگیری‌زدایی (Unlearning) و سخت‌سازی حلقه‌های RAFT/RA-DIT.
• ابزارهای بهره‌وری: پشتیبانی از DoRA، +LoRA، rsLoRA، VeRA، OLoRA، NEFTune، PiSSA، ReLoRA، GaLore و YaRN/LongLoRA. همچنین مدیریت Packing، آموزش برنامه-محور (Curriculum Training) و تنظیم خودکار.
• کوانتیزاسیون و عملکرد: پوشش QAT، FP8، NVFP4، Cut Cross-Entropy، چک‌پوینتینگ گرادینت، آفلودینگ فعال‌سازها و «منوی کوانتیزاسیون (I + II)».
• مهندسی داده: ارائه خط لوله با برابری Axolotl/LF، تولید و فورج سنتتیک، کارت‌های امتیاز کیفیت و DAGهای دستورالعمل. تشخیص خودکار فرمت‌هایی مثل Alpaca، ShareGPT، ChatML و KTO.
• حاکمیت و انطباق: شامل قالب‌هایی برای انطباق با HIPAA، SOC2 و قانون AI اتحادیه اروپا، ابزارهای ریشه‌یابی (BOM/attest/repro-receipt)، لاگ‌های حسابرسی و پشتیبانی از محیط‌های ایزوله (Air-gap). کارت‌های مدل به صورت خودکار با soup card و دروازه‌های CI با soup ci init ایجاد می‌شوند.

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

برای متخصصان، گلوگاه رسماً از محاسبات به کیفیت داده منتقل شده است. از آنجایی که زیرساخت اکنون «مدیریت شده» است، مزیت رقابتی کاملاً در اختیار کسی است که پاک‌ترین و تخصصی‌ترین جفت‌های ترجیحی (Preference Pairs) را جمع‌آوری کند. اگر هنوز دسته‌ای از سرورهای GPU را از طریق SSH مدیریت می‌کنید، زمان آن رسیده است که تست کنید آیا گردش کار شما در یک فایل YAML خلاصه می‌شود یا خیر. لیست دستورالعمل‌های soup recipes را در گیت‌هاب بررسی کنید تا بهترین نقطه شروع برای حوزه خود بیابید.

گام بعدی شما

• اگر مدل‌های کوچک (SLM) دارید، با soup init یک پروژه جدید را شروع کنید و اثر استریمینگ لایه‌ها روی VRAM خود بسنجید.
• از دستور soup doctor برای اطمینان از سازگاری درایورهای CUDA و نسخه‌ی PyTorch استفاده کنید.
• برای تبدیل مدل نهایی به فرمت‌های بهینه، دستور soup export را امتحان کنید.

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