هزینهٔ مهندسیِ هرس مدل‌های زبانی لبهٔ پذیرش در رایانش ابری را تغییر داد

تصور کنید می‌خواهید یک مدل ۷۰ میلیارد پارامتری را روی سخت‌افزاری جای دهید که تنها ۱۶ گیگابایت حافظه دارد؛ این شکاف عظیم، توسعه‌دهندگان را در وضعیتی دشوار قرار می‌دهد. اگر امروز برای استقرار مدل روی دستگاه (On-device) برنامه‌ریزی می‌کنید، باید بدانید که «مالیات مهندسی» این مسیر احتمالاً از هزینهٔ استفاده از سرویس‌های ابری بیشتر است.

بر اساس مستندات فنی وب‌سایت dev.to در ۷ جولای ۲۰۲۶، تلاش برای کوچک‌سازی مدل‌ها برای تیم‌هایی که مهندس متخصص سیستم‌های یادگیری ماشین ندارند، اغلب به بن‌بست می‌رسد. استقرار هوش مصنوعی در لبه (Edge Computing) — یعنی اجرای مدل روی دستگاه‌هایی مثل گوشی یا حسگرها، شبیه به این است که بخواهید یک کتابخانه کامل را در یک جعبه کفش جای دهید — دیگر فقط بحث حافظه نیست؛ بلکه یک مسئلهٔ طراحی کامل شامل بودجه حرارتی و مصرف انرژی است. هر وات برق که از باتری گرفته می‌شود، بر بقای دستگاه اثر می‌گذارد. همان‌طور که در تحلیل قبلی ما درباره‌ی چالش‌های مدل‌ها در تولید کدهای تکراری جنگو اشاره کردیم، مشکل اینجا فیزیکی است: گنجاندن یک ترنسفورمر (Transformer) چند میلیارد پارامتری در محیطی که فقط یک گرم‌کن غیرفعال برای خنک‌سازی دارد.

مکانیسم‌های هرس مدل

هرس کردن (Pruning) — که شبیه به هرس کردن شاخه‌های اضافی یک درخت برای تقویت تنه است — با حذف وزن‌های زائد یا کل ساختارها، اندازه مدل را کم و سرعت استنتاج را بالا می‌برد. به گزارش dev.to، توسعه‌دهندگان با دو مسیر روبروند:

• هرس غیرساختاری (Unstructured Pruning): حذف وزن‌های تک‌به‌تک. این روش می‌تواند ۵۰٪ وزن‌ها را بدون افت شدید صحت حذف کند، اما سخت‌افزارهای لبه به‌ندرت می‌توانند این الگوهای نامنظم را سریع‌تر پردازش کنند.
• هرس ساختاری (Structured Pruning): حذف کامل سرها (Heads) یا لایه‌ها. این روش با سخت‌افزار سازگار است و سرعت واقعی ایجاد می‌کند، هرچند برای رسیدن به تأخیر کم، نیاز به نرخ حذف بالاتری دارد.

تکنیک‌های هرس در ترنسفورمرها

الگوریتم‌های مختلف، توازن متفاوتی میان تلاش، سرعت و کیفیت ایجاد می‌کنند:

• هرس بر اساس مقدار (Magnitude Pruning): وزن‌ها را بر اساس مقدار مطلق رتبه‌بندی کرده و کوچک‌ترین‌ها را صفر می‌کند.
• هرس حرکتی (Movement Pruning): فرآیندی پویا که در مرحلهٔ تنظیم دقیق (Fine-tuning) — مثل وقتی که یک پزشک عمومی را برای تخصص پوست آموزش می‌دهیم — یاد می‌گیرد کدام وزن‌ها حذف شوند.
• Wanda: از یک دسته دادهٔ کالیبراسیون برای سنجش اهمیت وزن‌ها بدون نیاز به پس‌انتشار استفاده می‌کند.
• SparseGPT: روشی پس از آموزش است که به دلیل حذف هزینه‌های هنگفت بازآموزی، برای مدل‌های زبانی بزرگ ترجیح داده می‌شود.

به‌طور کلی، یک مدل را می‌توان ۲۰ تا ۳۰ درصد به‌صورت ساختاری هرس کرد بدون اینکه perplexity (معیار پیش‌بینی‌پذیری متن) افزایش یابد. اما کاهش بیش از ۵۰٪ معمولاً باعث فروپاشی توانایی استدلال مدل می‌شود و نیاز به تنظیم دقیق مجدد با لورا (LoRA) دارد. در همین راستا، برخی مدل‌های بسیار کوچک توانسته‌اند نتایج غافلگیرکننده‌ای ارائه دهند؛ برای مثال مدل ۲۳۰ میلیون پارامتری Liquid AI توانست در استخراج داده از رقبای یک میلیارد پارامتری پیشی بگیرد که نشان‌دهنده پتانسیل بالای مدل‌های کوچک در صورت بهینه‌سازی درست است.

پیاده‌سازی عملی: یک مثال ساده

برای درک این مکانیسم، یک پیاده‌سازی در PyTorch برای هرس ساختاری یک لایه MLP را بررسی کنید:

import torch
import torch.nn.utils.prune as prune
from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "meta-llama/Llama-3.2-1B"
model = AutoModelForCausalLM.from_pretrained(
    model_name, torch_dtype=torch.float16, device_map="cpu"
)
tokenizer = AutoTokenizer.from_pretrained(model_name)

layer = model.model.layers[0]
mlp_up = layer.mlp.up_proj

importance = mlp_up.weight.abs().mean(dim=1)
num_prune = int(0.2 * importance.size(0))

_, indices = torch.topk(importance, k=num_prune, largest=False)
mask = torch.ones_like(mlp_up.weight)
mask[indices, :] = 0
prune.custom_from_mask(mlp_up, name="weight", mask=mask)
print(f"Pruned {num_prune} neurons from layer 0 MLP up-projection")

در خط تولید واقعی، توسعه‌دهندگان از کتابخانه‌هایی مثل LLM-Pruner استفاده می‌کنند تا قبل از خروجی گرفتن به فرمت ONNX، دقت مدل را بازیابی کنند.

پشتهٔ کوانتش و استقرار

هرس کردن و کوانتش (Quantization) — که مثل تبدیل یک عکس با کیفیت بالا به یک فرمت فشرده برای کاهش حجم است — مکمل یکدیگرند. هرس تعداد پارامترها را کم می‌کند و کوانتش دقت هر پارامتر را (مثلاً از FP16 به INT4) کاهش می‌دهد.

• هم‌افزایی: مدلی که ۷۰٪ هرس شده و سپس به INT4 کوانتیده شده است، مدل‌های کلاس ۷ میلیارد پارامتری را روی تراشه‌های موبایل (SoC) قابل اجرا می‌کند.
• پشتیبانی runtime: محیط‌هایی مثل llama.cpp و ExecuTorch از تنسورهای کوانتیده پشتیبانی می‌کنند، اما اغلب نیاز به نمایش دنس (Dense) دارند.

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

صادرات یک مدل هرس‌شده به محیط لبه به‌ندرت یک عملیات تک‌خطی است. توسعه‌دهندگان با موانع فنی متعددی روبروند:

• خطاهای تبدیل: تنسورهای پراکنده (Sparse) در PyTorch ممکن است به‌راحتی به ONNX تبدیل نشوند.
• محدودیت‌های فرمت: llama.cpp منتظر فایل‌های GGUF با طرح‌های کوانتش خاص است.
• برنامه‌ریزی حافظه: ExecuTorch به اشکال استاتیک و برنامه‌ریزی دقیق حافظه نیاز دارد.
• بهینه‌سازی: مدیریت اندازهٔ KV Cache (حافظه کلیدی-ارزشی) و ماسک‌های توجه ضروری است.

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

جایگزین ابری: Oxlo.ai

برای کاربردهایی که به پنجرهٔ زمینه (Context Window) — یعنی میز کاری مدل که تعیین می‌کند چه مقدار متن را هم‌زمان در ذهن نگه دارد — بزرگ یا استدلال‌های عمیق نیاز دارند، هرس کردن یک سقف کیفی ایجاد می‌کند. شما نمی‌توانید یک مدل ۷۰ میلیارد پارامتری را به ۱ میلیارد کاهش دهید و انتظار عملکرد یکسان در کدنویسی داشته باشید. اینجا جایی است که Oxlo.ai یک جایگزین عملی ارائه می‌دهد.

این پلتفرم با قیمت‌گذاری مبتنی بر درخواست (Request-based) عمل می‌کند؛ یعنی هزینه هر درخواست ثابت است، فارغ از طول پرامپت. این مدل برخلاف ارائه‌دهندگان توکن‌محور، برای کارهای عامل‌محور (Agentic) بسیار ارزان‌تر است. علاوه بر مدل قیمت‌گذاری، Oxlo.ai با بهینه‌سازی پهنای باند حافظه توانسته است مصرف برق LLMها را به‌طور چشم‌گیری کاهش دهد که دغدغه‌ای همسو با چالش‌های رایانش لبه است.

ویژگی‌های فنی کلیدی:

• تنوع مدل‌ها: میزبانی بیش از ۴۵ مدل شامل Llama 3.3 70B و DeepSeek R1 671B.
• سازگاری SDK: کاملاً سازگار با OpenAI SDK از طریق URL پایه.
• دسترسی: نبودِ راه‌اندازی سرد (Cold Start) در مدل‌های محبوب و سطح رایگان ۶۰ درخواست در روز.

تحلیل: هزینه کل مالکیت (TCO)

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

بهترین مسیر برای سیستم‌های ترکیبی (Hybrid) این است: یک مدل بسیار کوچک و هرس‌شده روی دستگاه برای شناسایی محرک‌های ساده قرار دهید و کارهای پیچیده مولد را از طریق یک فراخوانی HTTPS به یک مدل کامل در ابر بفرستید.

گام بعدی شما

• ابتدا هزینه کل مالکیت (TCO) خود را محاسبه کنید: زمان مهندسی + هزینه سخت‌افزار در برابر هزینه API.
• اگر نیاز به آفلاین بودن مطلق ندارید، مدل‌های لبه را فقط برای لایهٔ Trigger (محرک) استفاده کنید.
• برای کاهش هزینه در پرامپت‌های طولانی، مدل‌های با قیمت ثابت به‌جای مدل‌های توکن‌محور را تست کنید.

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