آیا برای اجرای مدل‌های هوش مصنوعی به VPS با GPU نیاز

آیا به یک VPS با GPU نیاز دارید یا CPU کافی است؟

یک VPS مجهز به GPU دو مورد را در اجرای شخصی مدل‌ها تغییر می‌دهد: سرعت تولید توکن‌ها و حداکثر حجم مدلی که در حافظه جای می‌گیرد. این موضوع هیچ تأثیر دیگری ندارد. اگر حجم کاری شما شامل یک مدل چت 7B تا 27B کوانتیزه شده برای پاسخ‌گویی به یک نفر در لحظه، یک عملیات Embedding با حجم پایین، یا تبدیل گفتار به متن با مدل Whisper small باشد، یک VPS معمولی با CPU و رم کافی، کار را انجام می‌دهد. با CPU شروع کنید، عددی که باعث کندی می‌شود را اندازه‌گیری کنید و سپس در صورت نیاز ارتقا دهید.

دلیل این موضوع پهنای باند حافظه است. هنگامی که یک مدل زبانی یک توکن تولید می‌کند، تمام وزن‌های مورد نیاز خود را از حافظه می‌خواند. یک مدل 8B که به 4 بیت کوانتیزه شده، حدود 4.7 گیگابایت روی دیسک و تقریباً همین مقدار در حافظه فضا اشغال می‌کند؛ بنابراین تولید هر توکن به معنای جابه‌جایی حدود 4.7 گیگابایت داده است. پهنای باند حافظه دستگاه را بر این عدد تقسیم کنید تا سقف توکن در ثانیه به دست آید. همین یک تقسیم ساده، تقریباً تمام بنچمارک‌هایی که می‌خوانید را توضیح می‌دهد.

GPU واقعاً چه مزایایی برای شما دارد

پهنای باند. حافظه DDR5 سرور در یک میزبان مدرن، داده‌ها را با سرعت ده‌ها گیگابایت بر ثانیه جابه‌جا می‌کند. حافظه GPU (یا همان VRAM) این کار را با سرعت صدها تا بیش از هزار گیگابایت بر ثانیه انجام می‌دهد. نسبت این دو، همان میزان افزایش سرعت است که بسیار قابل‌توجه است.

ظرفیت همراه با سرعت. یک سیستم CPU با 64 گیگابایت رم می‌تواند یک مدل 70B را با کوانتایز 4 بیت بارگذاری کند. مدل اجرا می‌شود، اما سرعت آن بیشتر به سرعت خواندن متن شبیه است تا چت کردن. در اینجا GPU تنها زمانی کمک می‌کند که مدل در VRAM جا شود؛ زیرا به محض اینکه لایه‌ها به رم سیستم منتقل شوند (spill)، دوباره همان مسیر کندِ پردازش فعال می‌شود.

توان عملیاتی دسته‌ای (Batch throughput). این بخشی است که اغلب دست‌کم گرفته می‌شود. یک GPU که برای یک کاربر در حال تولید متن است، بخش بزرگی از توان محاسباتی خود را بیکار نگه می‌دارد، چون منتظر حافظه است. اگر 20 درخواست را همزمان پردازش کنید، همان خواندن وزن‌های مدل، به هر 20 درخواست سرویس می‌دهد. در این حالت، مجموع توکن‌های تولیدشده در ثانیه چندین برابر می‌شود، در حالی که سرعت برای هر کاربر به‌سختی کاهش می‌یابد. CPU چنین قابلیتی ندارد. دو کاربر همزمان روی یک سیستم CPU، سرعت یکدیگر را تقریباً نصف می‌کنند. اگر در حال ساخت API هستید که کلاینت‌های زیادی به آن متصل می‌شوند، «دسته‌بندی» (batching) دلیل اصلی استفاده از GPU است، نه فقط سرعت خام در یک جریان تکی.

پردازش پرامپت. خواندن یک پرامپت طولانی، محدود به توان محاسباتی (compute-bound) است، نه محدود به حافظه، و اینجاست که GPUها با بیشترین اختلاف برنده می‌شوند. پردازش یک کانتکست 30,000 توکنی که برای CPU یک دقیقه طول می‌کشد، روی GPU تنها چند ثانیه زمان می‌برد. در تنظیمات بازیابی اطلاعات (Retrieval) که اسناد را در هر درخواست تزریق می‌کنند، این تفاوت به‌طور مداوم احساس می‌شود.

اعداد تقریبی و نحوه خواندن آن‌ها

بخش زیر شامل ارقام معمول منتشرشده برای یک مدل 8B با کوانتایزیشن 4-bit در حالت single-stream تا جولای 2026 است. این اعداد صرفاً راهنمایی برای درک مقیاس هستند و تضمینی برای عملکرد دقیق نیستند. نوع کوانتایزیشن، طول کانتکست و موتور استنتاج (inference engine) شما، این ارقام را تغییر خواهند داد.

[
  {
    "label": "8 vCPU, DDR4",
    "mem_bandwidth_gbs": 40,
    "tokens_per_sec": 6
  },
  {
    "label": "16 vCPU, DDR5",
    "mem_bandwidth_gbs": 75,
    "tokens_per_sec": 11
  },
  {
    "label": "24GB GPU",
    "mem_bandwidth_gbs": 300,
    "tokens_per_sec": 50
  },
  {
    "label": "40GB data-centre GPU",
    "mem_bandwidth_gbs": 1555,
    "tokens_per_sec": 130
  }
]

ردیف مربوط به GPU با 24 GB حافظه، 50 توکن در ثانیه را در مقابل 11 برای یک سیستم CPU با رم DDR5 نشان می‌دهد. این تفاوت تقریباً پنج برابر است که با نسبت پهنای باند همخوانی دارد، نه با تفاوت در قدرت پردازش خام. توان عملیاتی واقعی نیز کمتر از حاصل تقسیم پهنای باند بر اندازه مدل است، زیرا مکانیزم attention با افزایش طول کانتکست، حجم کاری را اضافه می‌کند که در یک تقسیم ساده نادیده گرفته می‌شود.

برای مقایسه، یک انسان با سرعت حدود 5 تا 10 کلمه در ثانیه مطالعه می‌کند. هر سرعتی در حد 15 توکن در ثانیه یا بیشتر، برای یک خواننده حس تایپ کردن عادی را دارد. به همین دلیل است که بسیاری از سیستم‌های مبتنی بر CPU به‌خوبی و بدون مشکل کار می‌کنند.

تخمین VRAM پیش از خرید

حجم فایل مدل، حداقل مقدار مورد نیاز است، نه مقدار نهایی. باید وزن‌ها، به علاوه KV cache (حافظه کلید-مقدار که برای هر توکن در مکانیزم attention نگهداری می‌شود) و حدود 1 گیگابایت فضای اضافی برای سربار سیستم را در نظر بگیرید.

یک قاعده کاربردی تا ژوئیه 2026 این است: حجم فایل مدل را به گیگابایت در نظر بگیرید و 20 درصد برای یک context معمولی 8k تا 16k به آن اضافه کنید. یک مدل 8B با حجم 4.7 گیگابایت، به حدود 6 گیگابایت VRAM نیاز دارد. یک مدل 27B با کوانتایز 4 بیت، حدود 16 گیگابایت است و تقریباً به 20 گیگابایت VRAM نیاز دارد. یک مدل 70B با کوانتایز 4 بیت، حدود 40 گیگابایت است و به یک کارت 48 گیگابایتی یا دو کارت کوچک‌تر نیاز دارد. همین محاسبات برای مدل‌های بزرگ‌تر نیز صادق است و محاسبات VRAM برای یک مدل 2.8 تریلیون پارامتری مانند Kimi K3 نشان می‌دهد که در چه نقطه‌ای انتخاب کارت گرافیک دیگر مسئله اصلی نخواهد بود.

contextهای طولانی این قاعده را نقض می‌کنند. حجم KV cache با افزایش طول context به‌صورت خطی رشد می‌کند و در 128k توکن، ممکن است از حجم خودِ وزن‌های مدل فراتر رود. اگر قصد استفاده از contextهای طولانی را دارید، ابتدا ظرفیت را بر اساس cache تخمین بزنید و بررسی کنید که موتور اجرایی شما چه گزینه‌هایی برای کوانتایز کردن cache ارائه می‌دهد.

بررسی سخت‌افزار موجود در ماشین

در یک instance دارای GPU، پیش از هر اقدامی تأیید کنید که درایور، کارت گرافیک را شناسایی کرده است.

nvidia-smi

شما به جدولی نیاز دارید که نام GPU، نسخه درایور و میزان حافظه مصرفی از کل حافظه را نمایش دهد. خطای NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver به این معناست که درایور نصب نیست یا ماژول هسته (kernel module) پس از ارتقای هسته بازسازی نشده است. در یک image استاندارد Ubuntu، راه حل معمول اجرای sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install و سپس reboot سیستم است تا ماژول جدید بارگذاری شود.

برای کانتینرها، وجود درایور به تنهایی کافی نیست. Docker برای عبور دادن (passthrough) دستگاه به داخل کانتینر، به NVIDIA Container Toolkit نیاز دارد.

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

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

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

همان جدول باید نمایش داده شود. مشاهده خطای docker: Error response from daemon: could not select device driver که به یک قابلیت (capability) ناموجود در GPU اشاره دارد، بدین معناست که toolkit نصب شده اما Docker پیکربندی مجدد یا restart نشده است؛ بنابراین دستور nvidia-ctk را دوباره اجرا کرده و سرویس را restart کنید. در Compose، معادل آن یک ورودی deploy.resources.reservations.devices است که مقدار driver آن nvidia بوده و لیست قابلیت‌های آن شامل gpu است؛ این تنظیمات در تعاریف سرویس‌های معمولی که در Docker Compose روی یک VPS پوشش داده شده‌اند، قرار می‌گیرند.

پیش از ارتقا، اندازه‌گیری کنید

مدلی را که قصد استفاده از آن را دارید روی سخت‌افزار CPU فعلی خود اجرا کنید و اعداد به‌دست‌آمده را ثبت نمایید. با استفاده از میزبانی Ollama برای یک LLM روی VPS، این کار تنها با یک flag انجام می‌شود:

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

خروجی شامل زمان‌بندی‌ها در انتها است. eval rate سرعت تولید متن شما بر حسب توکن در ثانیه است. prompt eval rate نشان می‌دهد که دستگاه با چه سرعتی ورودی شما را خوانده است. این دو عدد به شما می‌گویند کدام ارتقا مفید است: مقدار پایین eval rate نشان‌دهنده مشکل در پهنای باند حافظه است و مقدار پایین prompt eval rate در ورودی‌های طولانی، نشان‌دهنده مشکل در توان پردازشی است.

روی دستگاهی که دارای GPU است، بررسی کنید که مدل واقعاً روی آن بارگذاری شده باشد:

ollama ps

ستون PROCESSOR در صورتی که همه چیز در حافظه جای گرفته باشد، مقدار 100% GPU را نشان می‌دهد، یا در غیر این صورت مقداری مانند 43%/57% CPU/GPU را نمایش می‌دهد. تقسیم ناقص مدل معمولاً بدتر از آن چیزی است که انتظار دارید، زیرا هر توکن همچنان منتظر بخش کندتر (CPU) می‌ماند.

پرسش هزینه

هزینه instanceهای GPU چندین برابر یک instance مشابه CPU است و صورت‌حساب آن‌ها بر اساس هر ساعت فعال بودن صادر می‌شود، نه بر اساس تعداد توکن‌های تولیدشده. یک GPU که همیشه روشن است و در روز تنها به تعداد انگشت‌شماری درخواست پاسخ می‌دهد، گران‌ترین روش ممکن برای اجرای inference است. نقطه سربه‌سر در میزان بهره‌وری (utilisation) نهفته است: یک GPU پرکار به ازای هر توکن ارزان تمام می‌شود، اما یک GPU بیکار، هدررفت محض منابع است.

سه الگوی صادقانه برای این کار وجود دارد. کارهای سبک و مداوم را روی یک CPU VPS نگه دارید. درخواست‌های سنگین و موردی را به یک API میزبانی‌شده بفرستید و به ازای هر توکن هزینه پرداخت کنید. برای کارهای دسته‌ای (batch jobs)، fine-tuning یا اجرای bulk embedding، یک GPU را به صورت ساعتی اجاره کنید و پس از پایان کار، آن را حذف نمایید. ترکیب این روش‌ها معمول است و انضباط بودجه‌بندی که در کنترل هزینه عامل هوش مصنوعی روی یک VPS همیشه روشن توضیح داده شد، در اینجا نیز کاربرد دارد؛ با این تفاوت که در اینجا زمان بیکاری (idle time) عامل نشت هزینه است، نه تعداد توکن‌ها.

چه مواردی بدون GPU همچنان به‌خوبی اجرا می‌شوند

مدل‌های Embedding با حجم پایین. یک مدل Embedding کوچک، صدها سند کوتاه را در هر دقیقه روی چند هسته CPU پردازش می‌کند و ایندکسی که یک‌بار می‌سازید، نیازی به سرعت بالا ندارد.

مدل‌های Whisper نسخه small و base برای تبدیل گفتار به متن. کتابخانه Faster-whisper روی CPU، مدل small را با سرعتی نزدیک به زمان واقعی (real-time) اجرا می‌کند که برای خط لوله‌ای که شبانه اجرا می‌شود، کافی است.

مدل‌های چت کوانتایز شده (Quantized) تا حدود 27B برای یک یا دو کاربر. سرعت پایین است، اما خروجی خوانا و قابل استفاده است.

هر کاری که آن را یک batch job می‌نامید. اگر کسی منتظر مشاهده خروجی روی صفحه نیست، سرعت پردازش (wall-clock speed) صرفاً یک جزئیات زمان‌بندی است، نه یک الزام فنی.

مواردی که واقعاً به GPU نیاز دارند: آموزش یا fine-tuning فراتر از یک adapter کوچک، سرویس‌دهی به تعداد زیادی کاربر همزمان، تولید تصویر و ویدیو، و پردازش گفتار در زمان واقعی که در آن تأخیر (latency) مستقیماً بر کیفیت محصول تأثیر می‌گذارد.

FAQ

برای یک مدل 7B یا 8B به چه مقدار VRAM نیاز دارم؟

حدود 6 GB برای یک مدل 8B با کوانتیزاسیون 4-bit در یک context معمولی 8k تا 16k. وزن‌های مدل تقریباً 4.7 GB هستند و باقی‌مانده شامل KV cache به اضافه حدود 1 GB سربار است. یک کارت 12 GB فضای مناسبی برای contextهای طولانی‌تر فراهم می‌کند. اگر قصد دارید با context 128k کار کنید، اندازه cache را جداگانه محاسبه کنید، زیرا می‌تواند از وزن‌های مدل بزرگ‌تر شود.

آیا می‌توانم Ollama را بدون GPU اجرا کنم؟

بله. Ollama به‌طور خودکار به CPU سوئیچ می‌کند و تنها به RAM کافی برای بارگذاری مدل نیاز دارد. برای یک مدل 8B با کوانتیزاسیون 4-bit، بسته به سرعت حافظه، انتظار حدود 5 تا 12 توکن در ثانیه را داشته باشید که برای یک کاربر نزدیک به سرعت خواندن است. پرامپت‌های طولانی در CPU نقطه ضعف اصلی هستند، زیرا خواندن 30,000 توکن context محدود به توان پردازشی است و بسیار طولانی‌تر از تولید پاسخ زمان می‌برد.

چرا GPU من به‌سختی سریع‌تر از CPU است؟

دلیل معمول این است که مدل به‌طور کامل در VRAM جا نشده است، بنابراین برخی لایه‌ها روی CPU اجرا می‌شوند و هر توکن منتظر بخش کندتر می‌ماند. دستور ollama ps را اجرا کنید و بررسی کنید که ستون PROCESSOR مقدار 100% GPU را نشان می‌دهد یا خیر. اگر تقسیم‌بندی (split) مشاهده کردید، از کوانتیزاسیون کوچک‌تر یا مدل کوچک‌تری استفاده کنید. دلیل رایج دیگر، بنچمارک کوتاه است که در آن زمان بارگذاری مدل بر اندازه‌گیری تأثیر می‌گذارد.

آیا GPU VPS برای یک کاربر تکی ارزش دارد؟

معمولاً خیر. یک نفر با سرعت 5 تا 10 کلمه در ثانیه می‌خواند و یک سرور CPU برای مدل‌هایی تا حدود 13B، توکن‌ها را سریع‌تر از این سرعت تولید می‌کند. مواردی که هزینه را برای یک کاربر تکی توجیه می‌کند شامل پرامپت‌های طولانی، تولید تصویر و fine-tuning است. سرویس‌دهی به کاربران زیاد به‌طور همزمان، قوی‌ترین دلیل است، زیرا batching اجازه می‌دهد یک GPU بیست درخواست را تقریباً با هزینه پاسخ به یک درخواست، پردازش کند.

آیا باید GPU را ساعتی اجاره کنم یا همیشه روشن نگه دارم؟

زمانی که کارها به‌صورت مقطعی هستند (مانند fine-tuning، اجرای انبوه embedding یا پردازش دسته‌ای transcription) به‌صورت ساعتی اجاره کنید. تنها زمانی GPU را همیشه روشن نگه دارید که کارت همیشه درگیر باشد، زیرا هزینه instanceهای GPU برای زمان وجود داشتن محاسبه می‌شود، نه برای توکن‌های تولید شده. یک دستیار با ترافیک پایین روی یک CPU VPS یا یک API میزبانی‌شده که بر اساس توکن هزینه دریافت می‌کند، ارزان‌تر از یک GPU بلااستفاده است.