VPS با GPU یا CPU؛ برای اجرای مدل به کدام نیاز دارید؟

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

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

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

یک GPU واقعاً چه چیزی در اختیار شما می‌گذارد

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

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

توان عملیاتی دسته‌ای. این همان بخشی است که معمولاً دست‌کم گرفته می‌شود. GPU هنگام تولید خروجی برای یک کاربر، بیشتر توان محاسباتی خود را بلااستفاده می‌گذارد، زیرا منتظر داده از حافظه است. اگر 20 درخواست را هم‌زمان پاسخ دهید، همان خواندن وزن‌ها برای هر 20 درخواست استفاده می‌شود. نرخ کلی تولید توکن چند برابر افزایش می‌یابد، درحالی‌که سرعت هر کاربر فقط اندکی کاهش پیدا می‌کند. CPU چنین رفتاری ندارد. دو کاربر هم‌زمان روی یک سیستم CPU تقریباً سرعت یکدیگر را نصف می‌کنند. اگر در حال ساخت API هستید که تعداد زیادی client آن را فراخوانی می‌کنند، batching دلیل اصلی استفاده از GPU است؛ حتی مهم‌تر از سرعت خام در یک جریان واحد.

پردازش prompt. خواندن یک prompt طولانی به توان محاسباتی وابسته است، نه پهنای‌باند حافظه؛ و GPU در همین بخش بیشترین برتری را دارد. پردازش یک context با 30,000 توکن که CPU در یک دقیقه انجام می‌دهد، روی GPU چند ثانیه طول می‌کشد. در سامانه‌های retrieval که اسناد را در هر درخواست وارد می‌کنند، این تفاوت دائماً محسوس است.

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

بلوک زیر اعداد معمولاً منتشرشده برای اجرای تک‌جریانی یک مدل 8B با کوانتیزه‌سازی 4-bit را تا ژوئیه 2026 نشان می‌دهد. این اعداد فقط راهنمایی در حد مرتبه بزرگی هستند و تضمین محسوب نمی‌شوند. کوانتیزه‌سازی، طول context و موتور inference شما می‌توانند این اعداد را تغییر دهند.

[
  {
    "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 روی context در حال رشد، کاری اضافه ایجاد می‌کند که این تقسیم ساده در نظر نمی‌گیرد.

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

برآورد VRAM پیش از خرید

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

یک قاعده عملی تا July 2026 این است: اندازه فایل مدل را برحسب gigabyte در نظر بگیرید و برای context معمولی 8k تا 16k، حدود 20 percent به آن اضافه کنید. یک مدل 8B با اندازه 4.7 GB به حدود 6 GB از VRAM نیاز دارد. یک مدل 27B با دقت 4 bits حدود 16 GB است و تقریباً به 20 GB نیاز دارد. یک مدل 70B با دقت 4 bits حدود 40 GB است و به یک کارت 48 GB یا دو کارت کوچک‌تر نیاز دارد.

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

بررسی آنچه ماشین واقعاً دارد

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

nvidia-smi

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

برای containerها، وجود درایور به‌تنهایی کافی نیست. Docker برای عبور دادن دستگاه به 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

سپس از داخل یک container، کارکرد passthrough را اثبات کنید:

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

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

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

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

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

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

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

ollama ps

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

مسئله هزینه

نمونه‌های GPU چند برابر نمونه‌های CPU مشابه هزینه دارند و برای هر ساعتی که فعال هستند هزینه دریافت می‌کنند، نه بر اساس تعداد tokenهایی که تولید می‌کنند. یک GPU همیشه‌فعال که روزانه فقط به چند درخواست پاسخ می‌دهد، پرهزینه‌ترین روش اجرای inference است. نقطه سر‌به‌سر به میزان استفاده بستگی دارد: GPU پُرمصرف به‌ازای هر token ارزان است، اما GPU بیکار اتلاف کامل منابع است.

سه الگوی عملی و شفاف وجود دارد. کارهای کم‌حجم و پیوسته را روی یک CPU VPS نگه دارید. درخواست‌های دشوار و گهگاهی را به یک API میزبانی‌شده ارسال کنید و به‌ازای token هزینه بپردازید. برای jobهای batch، fine-tuning یا اجرای bulk embedding، یک GPU را ساعتی اجاره کنید و پس از پایان کار آن را حذف کنید. ترکیب این روش‌ها معمول است و انضباط بودجه‌ای توضیح‌داده‌شده در کنترل هزینه AI agent روی یک VPS همیشه‌فعال در اینجا نیز کاربرد دارد؛ با این تفاوت که در اینجا زمان بیکاری عامل نشت هزینه است، نه تعداد tokenها.

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

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

Whisper small و base برای transcription. Faster-whisper روی CPU با مدل small، transcription را تقریباً در زمان واقعی انجام می‌دهد. این سرعت برای pipelineای که شبانه اجرا می‌شود کافی است.

مدل‌های chat کوانتیزه تا حدود 27B، برای یک یا دو کاربر. کند، خوانا و قابل استفاده.

هر کاری که آن را batch job بنامید. اگر کسی صفحه را مشاهده نمی‌کند، سرعت wall-clock بیشتر یک جزئیات زمان‌بندی است تا یک الزام.

مواردی که واقعاً به GPU نیاز دارند: training یا fine-tuning فراتر از یک adapter کوچک، ارائه سرویس به کاربران هم‌زمان متعدد، تولید تصویر و ویدئو، و speech بلادرنگ که latency در آن خود محصول است.

FAQ

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

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

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

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

چرا GPU من فقط اندکی از CPU سریع‌تر است؟

علت معمول این است که مدل به‌طور کامل در VRAM جا نشده است؛ بنابراین بعضی لایه‌ها روی CPU اجرا می‌شوند و هر token باید منتظر بخش کندتر بماند. ollama ps را اجرا کنید و بررسی کنید که ستون PROCESSOR مقدار 100% GPU را نشان می‌دهد. اگر تقسیم بار را نشان می‌دهد، از کوانتش کوچک‌تر یا مدل کوچک‌تری استفاده کنید. علت رایج دیگر، benchmark کوتاهی است که در آن زمان بارگذاری مدل بر اندازه‌گیری غالب می‌شود.

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

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

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

وقتی workload مقطعی است، GPU را ساعتی اجاره کنید؛ برای مثال در fine-tuning، اجرای bulk embedding یا کار batch transcription. فقط زمانی آن را همیشه روشن نگه دارید که کارت دائماً مشغول باشد، زیرا هزینه GPU instance بر اساس زمان فعال‌بودن محاسبه می‌شود، نه تعداد tokenهای تولیدشده. برای یک دستیار کم‌ترافیک، استفاده از CPU VPS یا hosted API با پرداخت به‌ازای token، از استفاده از GPU بیکار ارزان‌تر است.