خرید GPU برای یک دستیار سازمانی معمولاً با نامهایی مثل H100 و H200 شروع میشود؛ در حالی که هنوز مشخص نیست مدل قرار است چه کاری انجام دهد، چند درخواست را همزمان پاسخ دهد و چه مقدار متن را در هر درخواست بخواند. برای پاسخگویی به پرسشهای کارکنان، جستوجو در مستندات، استخراج اطلاعات یا کمک به برنامهنویسان، یک مدل کوچک یا میانرده روی RTX 4090 میتواند نقطهٔ شروع کاملاً عملی باشد. هزینهٔ کارتهای دیتاسنتری زمانی توجیه پیدا میکند که ظرفیت حافظه، سرعت سرویس یا الزامات بهرهبرداری واقعاً به آن نیاز داشته باشد.
RTX 4090 با حافظهٔ استاندارد ۲۴ گیگابایت، دامنهٔ قابلتوجهی از مدلهای زبانی کوانتیزهشده را پوشش میدهد. افزایش حافظه به ۴۸ گیگابایت، مدلهای بزرگتر و درخواستهای طولانیتر را در دسترس قرار میدهد، اما معنای آن دو برابر شدن سرعت نیست. تصمیم درست از کنار هم گذاشتن سه موضوع به دست میآید: کیفیت مدل برای کاربرد، حافظهٔ لازم برای اجرای آن و ظرفیت پاسخگویی سرویس. جزئیات مدلها و پیکربندیها را میتوان در جدول مقایسهٔ مدلها بر اساس حافظه و سختافزار مقایسه کرد؛ این یادداشت منطق انتخاب میان آنها را توضیح میدهد.
اول روشن کنیم: 4090 با ۴۸ گیگابایت چیست؟
مشخصات رسمی NVIDIA برای RTX 4090 شامل ۲۴ گیگابایت حافظهٔ GDDR6X است؛ نسخههایی که با حافظهٔ ۴۸ گیگابایت عرضه میشوند، محصول اصلاح سختافزار توسط عرضهکنندگان دیگر هستند. بنابراین عنوان «4090 با ۴۸ گیگابایت» در این مقاله به یک کارت اصلاحشده اشاره دارد و مشخصات آن باید برای همان محصول بررسی شود. مشخصات رسمی RTX 4090 و یک بررسی دستاول از نمونهٔ اصلاحشدهٔ ۴۸ گیگابایتی این تفاوت را روشن میکنند.
حافظهٔ اضافه میتواند مشکل جا نشدن مدل را حل کند، اما تعداد واحدهای پردازشی و معماری GPU را تغییر نمیدهد. در نمونهٔ بررسیشده نیز توان محاسباتی و پهنای باند در محدودهٔ مشابه کارت معمولی گزارش شده است. برای خرید چنین کارتی، مقدار حافظهٔ قابل استفاده، پایداری زیر بار طولانی، خنککاری حافظه و شرایط پشتیبانی همان فروشنده اهمیت دارند؛ برچسب ۴۸ گیگابایت بهتنهایی مشخصات یک محصول استاندارد و یکسان را تضمین نمیکند. این نکات در انتخاب سرور چندکارت، که دفع گرما و دسترسی برای تعمیر دشوارتر میشود، اهمیت بیشتری پیدا میکنند.
چه مدلهایی روی یک 4090 جا میشوند؟
جدول زیر چند نمونهٔ مشخص را از مدل کوچک تا مدل ۷۰ میلیاردی نشان میدهد. مبنای برآورد، یک درخواست فعال با مجموع زمینه و خروجی در حدود ۸ هزار توکن، قرارگیری وزنها و KV cache روی GPU و یک موتور سازگار با فایل منتخب است. برای فایلهای Q4_K_M، محاسبه با KV شانزدهبیتی و ۲ GiB فضای ذخیره برای موتور انجام شده است؛ مصرف واقعی موتور میتواند بیشتر باشد و بهویژه در ردیفهای کمحاشیه اهمیت دارد. اندازههای فایل از مخازن پیوندشده آمدهاند و با واحد GiB، معادل ۲ به توان ۳۰ بایت نوشته شدهاند؛ این عدد فقط حجم فایل وزن است و حافظهٔ کامل اجرای مدل را نشان نمیدهد. نتیجهٔ ستونهای کارت، برآورد ظرفیت حافظه برای این سناریو است؛ سرعت و تعداد کاربران از این جدول بهتنهایی استخراج نمیشود.
| مدل و صفحهٔ اصلی | فایل منتخب و حجم تقریبی | روی ۲۴ گیگابایت | روی ۴۸ گیگابایت | کاربرد پیشنهادی برای شروع |
|---|---|---|---|---|
| Qwen3-4B | GGUF / Q4_K_M؛ ۲٫۳۳ GiB | جا میشود؛ فضای زیاد برای حافظهٔ اجرا | جا میشود؛ انتخاب آن بیشتر تابع بار سرویس است | چت محدود، استخراج اطلاعات و پاسخ از متن بازیابیشده |
| Llama-3.1-8B-Instruct | GGUF / Q4_K_M؛ ۴٫۵۸ GiB | جا میشود؛ حاشیهٔ حافظهٔ مناسب | جا میشود؛ فضای بیشتر برای درخواستهای فعال | دستیار عمومی و RAG، با بررسی کیفیت زبان هدف |
| Aya Expanse 8B | GGUF / Q4_K_M؛ ۴٫۷۱ GiB | جا میشود؛ حاشیهٔ حافظهٔ مناسب | جا میشود؛ زمینهٔ خود مدل همچنان ۸ هزار توکن است | دستیار چندزبانه، از جمله فارسی |
| Qwen3-14B | GGUF / Q4_K_M؛ ۸٫۳۸ GiB | جا میشود؛ گزینهای میان اندازه و ظرفیت سرویس | جا میشود؛ دست بازتر برای زمینه و همزمانی | کار عمومی و تحلیل با پیچیدگی متوسط |
| DeepSeek-R1-Distill-Qwen-14B | GGUF / Q4_K_M؛ ۸٫۳۷ GiB | جا میشود؛ طول استدلال در بودجهٔ خروجی حساب شود | جا میشود؛ ظرفیت حافظهٔ بیشتر برای درخواست بلند | مسائل استدلالی؛ با سنجش کیفیت و زمان پاسخ |
| gpt-oss-20b | GGUF / MXFP4؛ ۱۱٫۲۸ GiB | ناشر اجرای ۱۶ گیگابایتی را برای مسیر سازگار گزارش کرده؛ بودجهٔ این GGUF وابسته به موتور است | حافظهٔ بیشتر؛ ظرفیت درخواست به کش و مسیر اجرا وابسته است | استدلال و کار با ابزار، با قالب گفتوگوی صحیح |
| Qwen3-Coder-30B-A3B-Instruct | GGUF / Q4_K_M؛ ۱۷٫۲۸ GiB | جا میشود؛ برای زمینه و همزمانی باید بودجه گذاشت | جا میشود؛ مناسبتر برای درخواستهای بلند کدنویسی | دستیار کد و گردشکارهای مبتنی بر ابزار |
| Qwen3-32B | GGUF / Q4_K_M؛ ۱۸٫۴۰ GiB | قابل جا دادن، با حاشیهٔ محدود و تنظیم حافظهٔ موتور | جا میشود؛ حاشیهٔ بیشتر برای سرویس | وظایف دشوارتر، وقتی کیفیت مدل کوچک کافی نیست |
| Llama-3.1-70B-Instruct | GGUF / Q4_K_M؛ ۳۹٫۶۰ GiB | اجرای کامل این فایل روی یک GPU جا نمیشود | برای سناریوی جدول قابل جا دادن است؛ حاشیهٔ محدود | کار دشوار و کمهمزمان؛ پس از بررسی زمان پاسخ |
Q4_K_M یک قالب کوانتیزهسازی ترکیبی است و همهٔ اجزای آن دقیقاً چهار بیت نیستند؛ به همین دلیل حجم فایل واقعی از ضرب سادهٔ تعداد پارامتر در نیم بایت دقیقتر است. فایلهای GGUF جدول، نقطهٔ شروع مشخصی برای مسیرهایی مثل llama.cpp و ابزارهای سازگار فراهم میکنند. برای vLLM یا موتور دیگر باید قالب، روش کوانتیزهسازی و پشتیبانی همان نسخه انتخاب شود؛ وجود یک فایل کمحجم بهتنهایی سازگاری همهٔ موتورهای اجرا را ثابت نمیکند. ناشر gpt-oss-20b امکان اجرای مدل در ۱۶ گیگابایت حافظه را مطرح کرده است، این گزارش، تضمین حافظه برای هر GGUF، طول ورودی یا موتور نیست؛ attention ترکیبی این مدل نیز در فرمول عمومی KV جدول حافظه قرار نمیگیرد. اجرای وزن MXFP4 روی 4090 به مسیر نرمافزاری سازگار وابسته است و نباید با پشتیبانی بومی محاسبات FP4 در نسلهای جدیدتر GPU اشتباه گرفته شود. برای انتخاب مسیر اجرا، جدول سازگاری مدل، قالب وزن و موتور این ترکیبها را تفکیک میکند.
نام خانوادهٔ مدل هم کافی نیست: مدل DeepSeek این جدول نسخهٔ تقطیرشدهٔ ۱۴ میلیاردی است و نیاز سختافزاری آن را نمیتوان به DeepSeek-R1 اصلی تعمیم داد. همچنین در Qwen3-Coder، حدود ۳٫۳ میلیارد پارامتر در پردازش هر توکن فعال میشود، اما مدل در مجموع حدود ۳۰٫۵ میلیارد پارامتر دارد؛ برای نگهداری وزنها باید کل مدل را حساب کرد. مشخصات این دو مورد در کارت مدل DeepSeek و کارت مدل Qwen3-Coder آمده است. پیوند مدل اصلی نیز برای بررسی زبان، قالب ورودی و مجوز مفید است؛ برای نمونه Aya Expanse با مجوز CC-BY-NC منتشر شده است و همهٔ مدلهای دارای وزن قابل دریافت، مجوز یکسانی ندارند.
عدد زمینه را از نیاز حافظه جدا کنید
در مشخصات Qwen3-4B-Instruct-2507، زمینهٔ بومی 262,144 توکن اعلام شده، اما خودِ راهنمای اجرا هنگام OOM کاهش آن به 32,768 را پیشنهاد میکند. پشتیبانی معماری از طول متن، تضمین جا شدن آن همراه KV cache و فضای کاری روی یک GPU نیست. برای مقایسهٔ ۲۴ و ۴۸ گیگابایت، قالب وزن، طول ورودی و خروجی، تعداد درخواست همزمان و backend را یکسان نگه دارید. بدون این اطلاعات، یک عدد «حافظهٔ لازم» قابل انتقال به کاربر دیگر نیست.
تفاوت اصلی ۲۴ و ۴۸ گیگابایت بعد از بارگذاری مدل دیده میشود
حافظهٔ اجرای مدل دستکم سه مصرفکننده دارد: وزنها، حافظهٔ توجه یا KV cache و فضای کاری موتور برای محاسبات و مدیریت درخواستها. با طولانی شدن گفتوگو و افزایش درخواستهای فعال، سهم KV cache بالا میرود؛ در حالی که وزن یک نسخهٔ بارگذاریشده ثابت میماند. به همین دلیل ممکن است افزایش حافظه از ۲۴ به ۴۸ گیگابایت، فضای باقیمانده برای درخواستها را بیش از دو برابر کند، بدون آنکه توان تولید توکن به همان نسبت زیاد شود.
برای دیدن ابعاد مسئله، Qwen3-Coder-30B-A3B-Instruct را در نظر بگیریم. در پیکربندی رسمی این نسخه، مدل ۴۸ لایه، ۴ سرِ KV و بُعد ۱۲۸ برای هر سر دارد. اگر KV با FP16 یا BF16 ذخیره شود، هر مقدار دو بایت میگیرد و برای درخواستهای هماندازه، حافظهٔ خام آن از رابطهٔ زیر به دست میآید؛ در این رابطه T تعداد توکنهای نگهداریشده برای هر درخواست و N تعداد درخواستهای فعال است.
| مجموع توکنهای زمینه و خروجی هر درخواست | KV برای یک درخواست | KV برای چهار درخواست فعال |
|---|---|---|
| ۸٬۱۹۲ توکن | ۰٫۷۵ GiB | ۳ GiB |
| ۳۲٬۷۶۸ توکن | ۳ GiB | ۱۲ GiB |
| ۶۵٬۵۳۶ توکن | ۶ GiB | ۲۴ GiB |
این اعداد محاسبهٔ حافظهٔ خام همین معماری هستند و فرض میکنند KV کوانتیزه نشده و میان درخواستها پیشوند مشترک به اشتراک گذاشته نمیشود؛ فضای کاری موتور نیز جداست. برای نمونه، فایل ۱۷٫۲۸ GiB این مدل همراه با KV چهار درخواست ۳۲ هزار توکنی، پیش از اضافه شدن سربار اجرا حدود ۲۹٫۲۸ GiB میخواهد. این سناریو روی یک کارت ۲۴ گیگابایتی بهصورت کامل در GPU جا نمیشود، اما از نظر حافظه در محدودهٔ قابل بررسی برای کارت ۴۸ گیگابایتی قرار میگیرد. رسیدن به زمان پاسخ مطلوب همچنان به ظرفیت محاسباتی و زمانبندی درخواستها وابسته است.
کوانتیزهسازی KV، اشتراک پیشوند و تنظیم تعداد درخواستهای همزمان میتوانند این بودجه را تغییر دهند؛ مستندات Ollama نمونههایی از تنظیم همزمانی و دقت KV را توضیح میدهد. در مقابل، افزایش VRAM محدودیت زمینهٔ خود مدل را برطرف نمیکند: Aya Expanse 8B طبق کارت مدل، زمینهٔ ۸ هزار توکن دارد و صرفاً با نصب آن روی کارت ۴۸ گیگابایتی به مدلی با زمینهٔ ۳۲ هزار توکن تبدیل نمیشود. طول زمینه باید هم با معماری و تنظیم مدل سازگار باشد و هم در حافظهٔ سرویس جا بگیرد.
دو کارت ۲۴ گیگابایتی چه تفاوتی با یک کارت ۴۸ گیگابایتی دارند؟
دو کارت ۲۴ گیگابایتی، دو پردازنده و دو فضای حافظهٔ مستقل در اختیار میگذارند. اگر یک مدل بزرگ میان آنها تقسیم شود، موتور باید محاسبات و جابهجایی داده را میان GPUها مدیریت کند؛ جمع ظرفیت حافظه به معنی تبدیل شدن آنها به یک کارت با حافظهٔ یکپارچه نیست. RTX 4090 نیز طبق مشخصات رسمی NVLink ندارد، بنابراین ارتباط کارتها به مسیرهای موجود در پلتفرم، از جمله PCIe، وابسته میشود. نوع تقسیم مدل و توپولوژی سرور بر نتیجه اثر میگذارند و باید همراه با ظرفیت حافظه بررسی شوند.
محدودیت 4090 فقط نبود NVLink نیست: پاسخ فنی NVIDIA نبود پشتیبانی P2P روی RTX 4090 را هم تصریح میکند. در تقسیم مدل میان این کارتها، وجود اسلات PCIe بهتنهایی انتقال مستقیم میان GPUها را تضمین نمیکند؛ مسیر واقعی انتقال و سربار آن باید در همان سرور بررسی شوند.
اما برای یک مدل ۸ میلیاردی که کامل روی هر کارت جا میشود، میتوان دو نسخهٔ مستقل اجرا کرد و درخواستها را میان آنها پخش کرد. در این چیدمان، محاسبهٔ توکنهای هر درخواست داخل همان GPU انجام میشود و کارتها برای اجرای هر لایه به تبادل داده با یکدیگر نیاز ندارند. این یکی از دلایلی است که چند کارت ارزانتر میتوانند برای سرویسدهی جذاب باشند: بودجه به ظرفیت پردازش درخواستهای مستقل تبدیل میشود. الگوی تکثیر مدل و توزیع درخواست در مستندات استقرار دادهموازی vLLM و تفاوت آن با تقسیم یک مدل در راهنمای موازیسازی vLLM توضیح داده شده است.
این انتخاب به هدف سرویس بستگی دارد. یک کارت ۴۸ گیگابایتی برای نگهداری مدل بزرگتر یا KV بیشتر مزیت دارد؛ دو کارت ۲۴ گیگابایتی برای دو نسخه از یک مدل کوچک، منابع محاسباتی مستقلی فراهم میکنند. افزایش ظرفیت نهایی الزاماً دو برابر نیست، چون طول درخواستها، توزیع بار و اجزای دیگر سامانه نیز دخیلاند. همچنین دو GPU در یک سرور، افزونگی در برابر خرابی همان سرور ایجاد نمیکنند؛ برای چنین هدفی باید نمونههای سرویس روی میزبانهای مستقل قرار گیرند. ملاحظات این انتخاب در راهنمای انتخاب سرور GPU و PCIe بررسی شده است.
برای کدام کاربرد سازمانی، 4090 نقطهٔ شروع مناسبی است؟
اندازهٔ مدل را باید از دشواری کار انتخاب کرد. پاسخگویی بر اساس چند بند از آییننامه، دستهبندی تیکت و استخراج شمارهٔ سفارش، الزاماً همان توانایی لازم برای تحلیل چند قرارداد متعارض یا تغییر گسترده در یک مخزن کد را نمیخواهند. دامنههای جدول زیر پیشنهاد اولیه برای طراحی هستند؛ معیار عبور به مدل بزرگتر، بهبود کیفیت روی نمونههای واقعی همان کار است. منطق این انتخاب در «برای هر کاربرد واقعاً چه اندازه مدلی لازم داریم؟ از مدل تخصصی و SLM تا LLM» با جزئیات بیشتری توضیح داده شده است.
| کاربرد | نقطهٔ شروع پیشنهادی | اثر بر انتخاب سختافزار |
|---|---|---|
| دستهبندی، مسیریابی و استخراج فیلدهای محدود | مدل تخصصی یا مدل کوچک حدود ۱ تا ۴ میلیارد پارامتر | ابتدا CPU یا GPU کوچکتر هم بررسی شود؛ 4090 ممکن است بیش از نیاز یک سرویس کمبار باشد |
| چت داخلی و پاسخ به پرسشهای مستند با RAG | مدل حدود ۴ تا ۱۴ میلیاردی، همراه با بازیابی و بازرتبهبندی مناسب | ۲۴ گیگابایت نقطهٔ شروع عملی است؛ رشد بار میتواند با تکثیر سرویس پاسخ داده شود |
| ترجمه، بازنویسی و خلاصهسازی معمول | مدل چندزبانهٔ حدود ۸ تا ۱۴ میلیاردی | طول سند و کیفیت فارسی تعیینکنندهاند؛ برای متن بلند، حافظهٔ KV زودتر محدود میکند |
| دستیار کد و کار با ابزار | از مدل کوچک تخصصی برای کار محدود تا مدل کدنویسی ۳۰ میلیاردی MoE | ۲۴ گیگابایت برای برخی پیکربندیها کافی است؛ زمینهٔ بلند و کاربران فعال بیشتر، مزیت ۴۸ گیگابایت را آشکار میکند |
| تحلیل چندمرحلهای دشوار و تلفیق اسناد متعدد | مقایسهٔ مستقیم مدلهای استدلالی و مدلهای بزرگتر روی نمونهٔ کار | کیفیت میتواند ارتقای مدل را لازم کند؛ اگر زمینه و بار سرویس نیز زیاد باشند، کارت حرفهای ارزش بیشتری پیدا میکند |
در RAG، مدل مولد فقط یکی از اجزاست. بازیابی متن درست، قطعهبندی اسناد، کنترل دسترسی و انتخاب بازرتبهبند میتوانند کیفیت پاسخ را بیش از تعویض فوری یک مدل ۸ میلیاردی با مدل ۷۰ میلیاردی تغییر دهند؛ این یک اولویت پیشنهادی برای عیبیابی است و به منشأ خطای سامانه بستگی دارد. اگر پاسخ در سند بازیابیشده وجود ندارد، ابتدا باید مسیر بازیابی اصلاح شود؛ اگر سند درست حاضر است ولی مدل استدلال یا دستور را غلط اجرا میکند، بررسی مدل قویتر معنا پیدا میکند. برای افزودن دانش سازمانی نیز RAG معمولاً گزینهای برای بررسی پیش از آموزش مجدد است؛ تمایز آن با CAG، KAG، Fine-tuning و Instruction-tuning در مقالهٔ مقایسهٔ این روشها توضیح داده شده است.
اجرای مدل با ارائهٔ سرویس تفاوت دارد
پاسخ گرفتن از یک مدل در ترمینال فقط آغاز کار است. سرویس سازمانی باید زمان رسیدن اولین توکن، سرعت ادامهٔ پاسخ، زمان انتظار در صف و رفتار زیر بار را مدیریت کند؛ صد کاربر ثبتشده هم با صد درخواست در حال تولید پاسخ یکسان نیست. ممکن است سازمانی با کارکنان زیاد، در بیشتر ساعات تنها چند درخواست فعال داشته باشد؛ در مقابل، یک ابزار تحلیل خودکار با کاربران انسانی کم، پیوسته GPU را مشغول نگه دارد. رشد تعداد کارتها در استنتاج تابع چنین باری و نیاز به افزونگی است، و از عنوان «سازمانی» بهتنهایی به دست نمیآید.
این تفاوت را در سرویس ترگمان روی RTX 4090 با حافظهٔ ۲۴ گیگابایت تجربه کردیم. وقتی یکی از دو سرور در حال بارگذاری مجدد مدل بود، کارت باقیمانده ترجمه، خلاصهسازی و چت را ادامه داد و درخواستهای همزمان سامانه به حدود ۳۰۰ رسید؛ اما پاسخها کندتر شدند و درخواستهای بدون شروع پاسخ پس از ۲۰ ثانیه لغو میشدند. پس این گزارش نمونهٔ استفادهٔ عملی از 4090 است، نه مبنایی برای وعدهٔ ۳۰۰ پاسخ موفق همزمان؛ ظرفیت موردنیاز را باید همراه با زمان انتظار و ریزش درخواستها سنجید.
انتخاب نرمافزار در استفاده از این ظرفیت اثر دارد. llama.cpp مسیر مهمی برای GGUF و اجرای ترکیبی CPU و GPU فراهم میکند؛ Ollama دریافت، بارگذاری و ارائهٔ مدل را ساده میکند و تنظیمات پردازش همزمان دارد؛ موتورهایی مانند vLLM نیز ابزارهای تخصصی زمانبندی و مقیاسدادن سرویس را در اختیار میگذارند. انتخاب بین آنها باید با مدل، قالب وزن و الگوی درخواست هماهنگ باشد. قابلیتهای این ابزارها را در جدول نرمافزارهای اجرا و سرویسدهی مقایسه کنید؛ سپس زمان آغاز پاسخ، فاصلهٔ توکنها و تعداد درخواستهای موفق را زیر بار مورد انتظار بسنجید.
اگر مدل در VRAM جا نشود، انتقال بخشی از وزنها به RAM یا استفاده از روشهایی مانند AirLLM دامنهٔ مدلهای قابل اجرا را گسترش میدهد. AirLLM با بارگذاری لایهبهلایه، نیاز به نگهداری همزمان همهٔ وزنها در GPU را کاهش میدهد؛ در عوض، مسیر انتقال داده و ذخیرهسازی وارد هزینهٔ اجرا میشود. چنین روشی میتواند برای آزمایش، پژوهش یا پردازش آفلاین قابل استفاده باشد، اما کافی بودن آن برای چت تعاملی باید با زمان پاسخ موردنیاز سنجیده شود.
چه زمانی H100، H200 یا کارت حرفهای ارزش هزینهٔ بیشتر را دارند؟
مدل بزرگ، زمینهٔ بلند و بار همزمان زیاد میتوانند مزیت حافظه و پهنای باند کارت دیتاسنتری را به ظرفیت قابل استفاده تبدیل کنند. برای نمونه، H200 طبق مشخصات NVIDIA دارای ۱۴۱ گیگابایت HBM3e با پهنای باند ۴٫۸ ترابایتبرثانیه است و در پیکربندیهای مربوط از ارتباط NVLink بهره میبرد. این امکانات در استنتاج هم ارزش دارند: میتوانند نگهداری مدل و KV بزرگتر، پردازش بار متراکمتر یا تقسیم کار میان GPUها را تسهیل کنند. بنابراین H100 و H200 صرفاً کارت آموزش نیستند؛ توجیه خریدشان برای سرویسدهی به بار واقعی و محدودیتی بستگی دارد که برطرف میکنند.
میان 4090 و این کارتها، گزینههای دیگری هم وجود دارند. RTX 6000 Ada با ۴۸ گیگابایت حافظهٔ ECC و RTX PRO 6000 Blackwell Workstation با ۹۶ گیگابایت حافظهٔ ECC، نمونههایی از کارتهای حرفهای با ظرفیت بالاتر هستند. نام «۶۰۰۰» بدون نسل و نسخه برای مقایسه کافی نیست؛ ویژگیهای ارتباطی کارتهای دیتاسنتری را نیز نباید به همهٔ کارتهای حرفهای تعمیم داد. اگر مشکل اصلی حافظه، ابعاد نصب یا الزامات پشتیبانی باشد، بررسی این رده میتواند به انتخاب متناسبتری منجر شود؛ مشخصات بیشتر در راهنمای مقایسهٔ GPU و سرور آمده است.
از سوی دیگر، چند 4090 هزینههای پلتفرم خود را دارند: فضای اسلات، مسیر PCIe، منبع تغذیه، سرمایش و نگهداری. توان نامی کل کارت مرجع 4090 برابر ۴۵۰ وات است، اما این عدد مصرف واقعی هر درخواست یا مصرف کل سرور را نشان نمیدهد. در بار مداوم و متراکم، یک راهکار حرفهای ممکن است از نظر توان مصرفی به ازای کار مفید، فضای رک یا زمان مدیریت برتری داشته باشد؛ در بار سبکتر، استفاده نشدن از ظرفیت اضافه میتواند هزینهٔ هر پاسخ را بالا ببرد. برای همین، مقایسه باید در سطح سامانه انجام شود و اجزای پلتفرم سرور GPU نیز در آن حضور داشته باشند.
با 4090 میتوان آموزش هم انجام داد؟
بله؛ بهویژه برای آموزش مدلهای کوچک و تنظیم کمپارامتر مدلهای زبانی. در LoRA و QLoRA، بخش محدودی از پارامترها آموزش میبیند و در QLoRA وزنهای اصلی بهشکل کوانتیزه و ثابت نگهداری میشوند. این روشها اجرای پروژههایی مانند تنظیم مدل ۷ یا ۸ میلیاردی روی کارت ۲۴ گیگابایتی را، با کنترل طول توالی، اندازهٔ دسته و حافظهٔ فعالسازیها، عملی میکنند. مقالهٔ QLoRA حتی تنظیم یک مدل ۶۵ میلیاردی روی یک GPU با حافظهٔ ۴۸ گیگابایت را گزارش کرده است؛ این نتیجه مربوط به تنظیم آداپترها در شرایط مقاله است و به معنی آموزش کامل تمام وزنهای آن مدل روی 4090 نیست.
آموزش همهٔ پارامترها، علاوه بر وزنها به حافظهٔ گرادیان، وضعیت بهینهساز و فعالسازیها نیاز دارد؛ پیشآموزش یک مدل بزرگ نیز مسئلهٔ زمان محاسباتی بسیار متفاوتی ایجاد میکند. اگر کار شامل آموزش مکرر، توالیهای بلند یا تبادل زیاد داده میان GPUها باشد، حافظهٔ بیشتر، ارتباط سریعتر در پلتفرم مناسب و بهرهبرداری پایدار میتوانند هزینهٔ بالاتر سختافزار حرفهای را جبران کنند. در مقابل، برای تنظیم محدود و گاهبهگاه یک مدل کوچک، همان 4090 یا اجارهٔ موقت GPU میتواند متناسبتر باشد. مستندات کوانتیزهسازی و PEFT روشهای این رده را توضیح میدهد؛ انتخاب اقتصادی باید با زمان پایان آموزش و دفعات تکرار پروژه انجام شود.
هزینهٔ هر پاسخ قابلقبول را مقایسه کنیم
قیمت کارت تنها بخشی از مقایسه است. برای یک دورهٔ مشخص باید هزینهٔ خرید یا استهلاک ــ یا اجاره ــ را همراه با میزبان، برق، سرمایش، نگهداری و توقف سرویس در نظر گرفت و آن را بر تعداد پاسخهایی تقسیم کرد که هم کیفیت موردنیاز و هم تعهد زمانی سرویس را برآورده کردهاند. پاسخ سریع اما اشتباه، یا پاسخ درست پس از انتظار غیرقابلقبول، همان ارزش اقتصادی پاسخ قابل استفاده را ندارد. در سرویسهایی با طول پاسخ متفاوت، هزینهٔ هر وظیفهٔ تکمیلشده نیز معیار مفیدی در کنار هزینهٔ توکن است.
برای مثال، اگر بهصورت فرضی هزینهٔ کل یک راهکار H200 در دورهٔ مقایسه چهار برابر راهکار 4090 باشد، برای رسیدن به هزینهٔ کمتر به ازای پاسخ باید بیش از چهار برابر پاسخ قابلقبول تولید کند؛ با فرض یکسان بودن ارزش پاسخها و سایر شرایط. ممکن است زیر بار کافی این اتفاق بیفتد، یا H200 تنها گزینهای باشد که مدل و سطح خدمت لازم را تأمین میکند. اما اگر تقاضا محدود باشد و بخش بزرگی از ظرفیت آن خالی بماند، توان بالقوهٔ بیشتر بهتنهایی بازگشت سرمایه ایجاد نمیکند. این مثال نسبت قیمت بازار نیست؛ رابطهای برای مقایسه با قیمتها و بار کاری واقعی خریدار است.
مسیر عملی خرید، انتخاب کوچکترین مدلی است که کیفیت لازم را تأمین میکند، سپس تعیین بودجهٔ زمینه و اندازهگیری سرویس در بار مورد انتظار. اگر آن مدل روی ۲۴ گیگابایت جا میشود و زمان پاسخ مناسب دارد، میتوان توسعه را با همان رده و در صورت نیاز با نمونههای بیشتر پیش برد. اگر حافظه محدود میکند، ۴۸ یا ۹۶ گیگابایت بررسی میشود؛ اگر ظرفیت محاسبات، ارتباط میان کارتها یا الزامات بهرهبرداری تعیینکنندهاند، مقایسهٔ H100 و H200 معنا پیدا میکند. جدولهای تناسب مدل با کاربرد و امکان اجرا روی سختافزار برای انتخاب این نقطهٔ شروع در نظر گرفته شدهاند.