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

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

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

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

مزیت واقعی استفاده از GPU

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

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

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

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

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

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

برای مقایسه، سرعت مطالعه بی‌صدای بزرگسالان به زبان انگلیسی به‌طور میانگین حدود 4.0 تا 4.3 کلمه در ثانیه است: 238 کلمه در دقیقه برای متون غیرداستانی و 260 کلمه برای متون داستانی. هر سرعتی در حد یا بالاتر از 15 توکن در ثانیه، برای یک خواننده حس تایپ کردن عادی را دارد. به همین دلیل است که بسیاری از سیستم‌های مبتنی بر CPU به‌راحتی و بدون مشکل کار می‌کنند.

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

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

به‌جای اضافه کردن یک درصد ثابت، حافظه کش را محاسبه کنید، زیرا کوانتایز کردن وزن‌ها، کش را کوانتایز نمی‌کند. برای هر توکن، یک مدل با مکانیزم full-attention، یک کلید و یک مقدار برای هر لایه و هر KV head ذخیره می‌کند که با نرخ 2 بایت به ازای هر عدد در حالت FP16 (نوع کش پیش‌فرض Ollama) محاسبه می‌شود. متادیتای مدل‌های Ollama که در تاریخ 2026-10-27 بررسی شد، برای مدل Llama 3.1 8B تعداد 32 لایه و 8 KV head با ابعاد 128 را نشان می‌دهد که معادل 128 کیبی‌بایت (KiB) به ازای هر توکن است: حدود 1.07 گیگابایت در کانتکست 8k و 2.15 گیگابایت در 16k. بنابراین یک مدل 8B با حجم 4.9 گیگابایت، در کانتکست 8k به حدود 7 گیگابایت VRAM و در 16k به حدود 8 گیگابایت نیاز دارد. یک مدل 27B با کوانتایز 4 بیتی حدود 17 گیگابایت است (مدل Gemma 3 27B در کتابخانه Ollama). متادیتای Gemma 3 یک پنجره لغزان (sliding window) با ظرفیت 1,024 توکن را فهرست می‌کند که مانع از رشد بی‌رویه کش می‌شود، بنابراین برای 20 گیگابایت یا بیشتر برنامه‌ریزی کنید. یک مدل 70B با کوانتایز 4 بیتی حدود 43 گیگابایت است (Llama 3.3 70B). با 80 لایه، کش FP16 آن حدود 2.7 گیگابایت در 8k و 5.4 گیگابایت در 16k به حجم اضافه می‌کند؛ بنابراین به یک کارت 48 گیگابایتی با فضای خالی اندک یا دو کارت کوچک‌تر نیاز دارد. همین محاسبات برای مدل‌های بزرگ‌تر نیز صادق است و محاسبات VRAM برای مدلی با 2.8 تریلیون پارامتر مانند Kimi K3 نشان می‌دهد که در چه نقطه‌ای انتخاب کارت گرافیک دیگر مسئله اصلی نخواهد بود.

اهمیت این موضوع در کانتکست‌های طولانی بیشتر مشخص می‌شود. در مدل‌های full-attention مانند Llama 3.1، حجم KV cache به‌صورت خطی با طول کانتکست رشد می‌کند و در 128k توکن می‌تواند از حجم خودِ وزن‌ها فراتر رود. مدل‌های دارای sliding-window یا chunked attention متفاوت هستند: مستندات Transformers در Hugging Face از Mistral، Gemma 2 و Llama 4 به‌عنوان نمونه‌هایی یاد می‌کند که کش در لایه‌های آن‌ها پس از رسیدن به اندازه پنجره یا قطعه (chunk) دیگر رشد نمی‌کند، بنابراین مجموع حافظه مصرفی آن‌ها کندتر افزایش می‌یابد. اگر قصد استفاده از کانتکست‌های طولانی را دارید، ابتدا بر اساس کش اندازه‌گیری کنید و بررسی کنید که موتور اجرایی شما چه گزینه‌ای برای کوانتایز کردن کش ارائه می‌دهد. در Ollama، مقدار OLLAMA_KV_CACHE_TYPE=q8_0 حدود نیمی از حافظه f16 پیش‌فرض را مصرف می‌کند و کوانتایز کردن کش تنها زمانی اعمال می‌شود که Flash Attention فعال باشد. طول کانتکست را نیز به‌صورت صریح تنظیم کنید. Ollama مقدار پیش‌فرض خود را بر اساس VRAM انتخاب می‌کند: 4k برای کمتر از 24 گیبی‌بایت (GiB)، 32k برای 24 تا 48 گیبی‌بایت، و 256k برای 48 گیبی‌بایت و بالاتر. روی یک کارت 48 گیگابایتی که یک مدل 70B را اجرا می‌کند، این مقدار پیش‌فرض، کش بسیار بیشتری از ظرفیت کارت طلب می‌کند.

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

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

nvidia-smi

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

برای کانتینرها، وجود درایور به تنهایی کافی نیست. 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) ناموجود اشاره دارد، به این معناست که Docker نتوانسته درایوری منطبق با درخواست پیدا کند؛ بررسی کنید که toolkit نصب شده باشد، سپس دستور nvidia-ctk را مجدداً اجرا کرده و سرویس را restart کنید. در Compose، معادل آن یک ورودی deploy.resources.reservations.devices است که driver آن برابر با nvidia بوده و لیست قابلیت‌های آن شامل gpu است؛ این تنظیمات در تعریف سرویس‌های معمولی که در Docker Compose on a 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) می‌ماند.

پرسش هزینه‌ها

نمونه‌های GPU به جای توکن، بر اساس زمان پردازش تخصیص‌یافته صورت‌حساب صادر می‌کنند و نرخ‌ها و هزینه‌های مربوط به نمونه‌های متوقف‌شده توسط ارائه‌دهنده تعیین می‌شود. یک GPU که همیشه روشن است و در روز تنها تعداد انگشت‌شماری درخواست را پردازش می‌کند، بیشتر زمان پرداختی خود را در حالت بیکار (idle) سپری می‌کند. نقطه سر‌به‌سر در میزان بهره‌وری است: یک GPU پرکار به ازای هر توکن ارزان است، اما یک GPU بیکار صرفاً هدررفت منابع است.

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

چه مواردی بدون 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 نیاز دارم؟

برای یک مدل 8B با کوانتیزاسیون 4-bit در context 8k، حدود 7 گیگابایت و در 16k حدود 8 گیگابایت VRAM نیاز است؛ این محاسبات با فرض استفاده از کش FP16 پیش‌فرض در Ollama انجام شده است. وزن‌های مدل تقریباً 4.9 گیگابایت هستند، کش KV در 8k حدود 1.07 گیگابایت و در 16k حدود 2.15 گیگابایت فضا اشغال می‌کند و حدود 1 گیگابایت نیز برای سربار سیستم در نظر گرفته می‌شود. یک کارت گرافیک 8 گیگابایتی برای context 8k مناسب است اما در 16k با محدودیت مواجه می‌شود، در حالی که کارت 12 گیگابایتی فضای کافی برای contextهای طولانی‌تر فراهم می‌کند. تغییر کش به q8_0 سهم کش را تقریباً به نصف کاهش می‌دهد. اگر قصد دارید با context 128k کار کنید، باید فضا را جداگانه برای کش در نظر بگیرید، زیرا ممکن است حجم آن از وزن‌های مدل بیشتر شود.

آیا می‌توانم 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 برای یک کاربر تکی صرفه اقتصادی دارد؟

معمولاً خیر. سرعت مطالعه صامت بزرگسالان به زبان انگلیسی به‌طور میانگین حدود 4.0 تا 4.3 کلمه در ثانیه است؛ پیش از مقایسه یک سرور CPU با این سرعت، باید توکن در ثانیه را به کلمه در ثانیه تبدیل کنید. مواردی که هزینه آن را برای یک کاربر توجیه می‌کند شامل پرامپت‌های طولانی، تولید تصویر و fine-tuning است. قوی‌ترین استدلال برای استفاده از GPU، سرویس‌دهی به کاربران متعدد به‌طور همزمان است، زیرا batching اجازه می‌دهد یک GPU خواندن وزن‌ها را بین درخواست‌ها به اشتراک بگذارد.

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

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