چه سروری برای اجرای مدل زبانی در سازمان لازم است؟ محاسبهٔ GPU، حافظه و کاربر هم‌زمان

«این مدل روی سرور ما اجرا می‌شود؟» معمولاً اولین سؤال سازمانی است که می‌خواهد هوش مصنوعی خصوصی داشته باشد. جوابش تقریباً همیشه «بله» است، به شرط اینکه کارت گرافیک حافظهٔ کافی داشته باشد. سؤال مهم‌تر، که کمتر پرسیده می‌شود، این است: «چند نفر می‌توانند هم‌زمان با آن کار کنند و هر کدام چقدر منتظر می‌مانند؟»

اینجا فقط سراغ اندازه‌گیری سخت‌افزار می‌روم. بیشتر راهنماهای فارسی دربارهٔ اجرای مدل با Ollama یا LM Studio روی لپ‌تاپ‌اند؛ برای یک نفر کافی است، ولی سازمانی با ده‌ها کاربر حساب دیگری لازم دارد. حساب‌ها بر اساس فایل‌های تنظیمات (config) منتشرشدهٔ مدل‌ها و مشخصات کارت‌هاست، و هر جا عددی تخمینی است، می‌گویم.

«اجرا می‌شود؟» با «چند نفر هم‌زمان؟» فرق دارد

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

• وزن‌های مدل (weights): همان عددهایی که مدل در آموزش یاد گرفته. یک بار بارگذاری می‌شوند و بین همهٔ کاربران مشترک‌اند.
• KV cache: نتیجهٔ محاسبه‌های توکن‌های قبلی، که ذخیره می‌شود تا دوباره حساب نشود. برای هر گفت‌وگویی که در حال پردازش است جداگانه نگه داشته می‌شود و با طول متن بزرگ می‌شود.
• سربار (overhead): محاسبات میانی، کتابخانه‌های CUDA و چیزهایی از این دست.

«اجرا می‌شود؟» فقط به مورد اول مربوط است. «چند نفر هم‌زمان؟» به مورد دوم مربوط است، و در عمل همین مورد است که بودجهٔ سخت‌افزار را تعیین می‌کند.

«کاربر هم‌زمان» یعنی درخواستی که همین لحظه در حال پردازش است، نه کسی که پنجرهٔ دستیار را باز گذاشته. قانون لیتل (Little’s Law) کمک می‌کند: درخواست‌های هم‌زمان = نرخ رسیدن درخواست × مدت هر پاسخ. اگر در ساعت شلوغ ۸۰ نفر از ۲۰۰ کارمند هر سه دقیقه یک سؤال بپرسند، حدود ۰٫۴۴ درخواست در ثانیه می‌رسد؛ با پاسخ‌های ۲۰ ثانیه‌ای، میانگین حدود ۹ درخواست هم‌زمان است. اوج‌ها بیشترند، پس در مثال این نوشته ۲۰ را مبنا می‌گیرم.

حافظهٔ وزن‌ها: تعداد پارامتر ضرب در بایت

ساده‌ترین بخش حساب همین است:

weights_bytes ≈ parameters × bytes_per_parameter

FP16 / BF16      → 2 bytes
INT8 / FP8       → 1 byte
4-bit (AWQ, GPTQ) → ~0.5 byte

در عمل فایل‌های ۴ بیتی کمی از عدد نظری بزرگ‌ترند، چون بعضی لایه‌ها با دقت بالاتر می‌مانند و ضریب‌های مقیاس‌گذاری هم کنار وزن‌ها ذخیره می‌شوند. برای مثال Qwen3-32B حدود ۳۲٫۸ میلیارد پارامتر دارد. عدد نظری ۴ بیتی‌اش ۱۶٫۴ گیگابایت است، ولی فایل‌های نسخهٔ رسمی AWQ آن روی Hugging Face حدود ۱۹٫۳ گیگابایت‌اند.

مدل ۷۰ میلیاردی با دقت کامل فقط برای وزن‌هایش دو کارت ۸۰ گیگابایتی می‌خواهد. مدل ۳۲ میلیاردی ۴ بیتی در یک کارت ۲۴ گیگابایتی جا می‌شود، ولی جای زیادی برای کاربران نمی‌ماند. کوانتیزه کردن (quantization)، یعنی نگه داشتن وزن‌ها با بیت کمتر، معمولاً کمی از کیفیت کم می‌کند؛ این افت را، به‌خصوص برای فارسی، روی دادهٔ خودتان و با یک مجموعه سؤال ارزیابی اندازه بگیرید، نه از جدول‌های انگلیسی.

KV cache: هزینهٔ حافظهٔ هر کاربر

مدل برای تولید هر توکن جدید به کلیدها و مقدارهای (keys و values) همهٔ توکن‌های قبلی در هر لایه نیاز دارد. برای اینکه هر بار از اول حساب نشوند، در حافظه نگه داشته می‌شوند. حجم این حافظه برای هر توکن از این فرمول به دست می‌آید:

kv_bytes_per_token = 2 × num_layers × num_kv_heads × head_dim × bytes_per_value

عدد ۲ برای کلید و مقدار است. بقیهٔ عددها را از فایل config.json مدل بردارید: num_hidden_layers، num_key_value_heads و head_dim.

مثال: Qwen3-32B

طبق پیکربندی منتشرشدهٔ این مدل، ۶۴ لایه دارد، ۶۴ سر توجه (attention head) برای پرسش‌ها، ولی فقط ۸ سر برای کلید و مقدار، و اندازهٔ هر سر ۱۲۸ است. اگر KV cache با دقت BF16، یعنی دو بایت، نگه داشته شود:

2 × 64 × 8 × 128 × 2 = 262,144 bytes ≈ 256 KiB per token

8,192 tokens × 256 KiB = 2 GiB  per conversation
20 conversations × 2 GiB = 40 GiB

یعنی ۲۰ گفت‌وگوی پر با متن ۸ هزار توکنی، دو برابر خود وزن‌های ۴ بیتی مدل حافظه می‌خواهد. این همان چیزی است که در راهنماهای اجرای تک‌کاربره دیده نمی‌شود.

چرا GQA این‌قدر مهم است

در GQA (Grouped-Query Attention) چند سر پرسش یک سر کلید-مقدار مشترک دارند. در Qwen3-32B هر ۸ سر پرسش یک سر کلید-مقدار مشترک دارند. اگر هر کدام از ۶۴ سر کلید-مقدار جدای خودش را داشت، همهٔ عددهای بالا ۸ برابر می‌شد: ۲ مگابایت برای هر توکن، ۱۶ گیگابایت برای هر گفت‌وگوی ۸ هزار توکنی و ۳۲۰ گیگابایت برای ۲۰ کاربر. تقریباً همهٔ مدل‌های باز جدید از GQA استفاده می‌کنند، ولی قبل از انتخاب مدل یک نگاه به num_key_value_heads بیندازید.

نکتهٔ جالب این جدول این است که KV cache مدل ۷۰ میلیاردی برای هر توکن فقط کمی از مدل ۳۲ میلیاردی بیشتر است. فاصلهٔ اصلی این دو مدل در وزن‌هاست.

دو اهرم دارید. اول، KV cache با دقت FP8 که حجمش را نصف می‌کند (در vLLM گزینهٔ --kv-cache-dtype fp8)؛ اثرش بر کیفیت را آزمایش کنید. دوم، سقف معقول برای طول context، یعنی بیشترین متنی که مدل در یک درخواست می‌بیند. فقط یادتان باشد که متن فارسی توکن بیشتری مصرف می‌کند، پس ۸ هزار توکن فارسی متن کمتری جا می‌دهد. در RAG هم، که مدل از روی سندهای پیداشده جواب می‌دهد، همین سندها بخش بزرگی از این بودجه را می‌گیرند.

سرعت: prefill و decode دو مسئلهٔ جدا هستند

پاسخ دادن به هر درخواست دو مرحله دارد. در prefill کل ورودی، یعنی دستور سیستم، سؤال و سندهای پیداشده، یک‌جا و به‌صورت موازی پردازش می‌شود. این مرحله محدود به توان محاسباتی کارت است و زمان رسیدن اولین توکن (time to first token) را تعیین می‌کند. در decode توکن‌های جواب یکی‌یکی ساخته می‌شوند و برای هر توکن باید همهٔ وزن‌ها از حافظه خوانده شود. این مرحله بیشتر به پهنای باند حافظه (memory bandwidth) بسته است.

قاعدهٔ پهنای باند

یک قاعدهٔ سرانگشتی برای سقف سرعت تولید یک کاربر تنها:

max_tokens_per_sec ≈ memory_bandwidth / bytes_read_per_step

Qwen3-32B-AWQ on L40S:     864 GB/s  / 19.3 GB ≈ 45 tokens/s
Qwen3-32B-AWQ on H100 SXM: 3350 GB/s / 19.3 GB ≈ 170 tokens/s

این‌ها سقف نظری‌اند و عدد واقعی پایین‌تر است، ولی منطقشان مهم است: در تولید، کارت با پهنای باند بیشتر سریع‌تر است.

KV cache هم در هر قدم خوانده می‌شود، پس روی سرعت هم اثر دارد. اگر ۲۰ کاربر به‌طور میانگین ۴ هزار توکن context داشته باشند، هر قدم حدود ۲۰ گیگابایت KV cache و ۱۹ گیگابایت وزن می‌خواند. روی L40S یعنی حدود ۲۱ قدم در ثانیه: هر کاربر حدود ۲۱ توکن در ثانیه و در مجموع حدود ۴۲۰. این هم تخمینی خوش‌بینانه است که محاسبات و سربار را حساب نکرده.

برای prefill، قاعدهٔ سرانگشتی حدود «۲ × تعداد پارامتر» عملیات برای هر توکن ورودی است. ورودی RAG با ۶ هزار توکن روی مدل ۳۲ میلیاردی حدود ۴×۱۰^۱۴ عملیات است که بسته به کارت و بار سرور از کسری از ثانیه تا چند ثانیه طول می‌کشد. قابلیت prefix caching در vLLM نتیجهٔ پردازش ابتدای مشترک درخواست‌ها را نگه می‌دارد، پس دستور سیستمِ ثابت برای هر درخواست دوباره پردازش نمی‌شود.

continuous batching و PagedAttention

چون گلوگاه تولید خواندن وزن‌هاست، جلو بردن ۲۰ درخواست در یک قدم خیلی گران‌تر از یک درخواست نیست؛ وزن‌ها یک بار خوانده می‌شوند و برای همه به کار می‌روند. در continuous batching، یعنی پردازش چند درخواست با هم در دسته‌ای که مدام عوض می‌شود، در هر قدم درخواست‌های تمام‌شده بیرون می‌روند و تازه‌ها وارد می‌شوند، پس کسی پشت پاسخ طولانی دیگری معطل نمی‌ماند.

PagedAttention، ایدهٔ اصلی vLLM، مشکل حافظه را حل می‌کند: به‌جای رزرو حداکثر طول context برای هر درخواست، KV cache در بلوک‌های کوچک، شبیه صفحه‌های حافظهٔ مجازی سیستم‌عامل، و فقط به‌اندازهٔ نیاز گرفته می‌شود. مقالهٔ این روش (Kwon و همکاران، ۲۰۲۳) با همان تأخیر، throughput (تعداد توکن تولیدشده در ثانیه) ۲ تا ۴ برابر سیستم‌های پیش از خودش گزارش می‌کند. نتیجهٔ عملی: مصرف میانگین مهم است، نه بدترین حالت هر کاربر. وقتی حافظه پر شود هم vLLM از کار نمی‌افتد؛ درخواست‌ها در صف می‌مانند یا موقتاً کنار گذاشته می‌شوند (preemption). کاربر کندی می‌بیند، نه خطا.

Ollama و llama.cpp کجا کافی‌اند

Ollama و llama.cpp برای یک نفر روی لپ‌تاپ عالی‌اند: نصب ساده، فایل GGUF و اجرا روی CPU و GPU با هم. منصفانه بگویم که سرور llama.cpp قابلیت continuous batching و اسلات موازی دارد و Ollama هم با OLLAMA_NUM_PARALLEL درخواست موازی می‌پذیرد. ولی تمرکزشان یک ماشین و چند کاربر است. برای ده‌ها کاربر هم‌زمان روی GPU، vLLM و SGLang که برای توان بالا ساخته شده‌اند معمولاً توان کل خیلی بیشتری می‌دهند. به حرف من اکتفا نکنید؛ با باری شبیه بار واقعی خودتان بسنجید.

SGLang هم‌ردهٔ vLLM است و ویژگی اصلی‌اش RadixAttention است: استفادهٔ دوباره از KV cache بین درخواست‌هایی که پیشوند مشترک دارند. TGI ساخت Hugging Face طبق صفحهٔ GitHubش در حالت نگهداری (maintenance mode) است و مخزنش در مارس ۲۰۲۶ بایگانی شده؛ پروژهٔ تازه را رویش شروع نکنید.

یک محاسبهٔ کامل: دستیار داخلی برای ۲۰۰ کارمند

فرض‌ها

• ۲۰۰ کارمند، که در ساعت اوج حداکثر ۲۰ درخواست هم‌زمان می‌فرستند.
• مدل Qwen3-32B با کوانتیزه‌سازی ۴ بیتی AWQ.
• سقف طول context برای هر گفت‌وگو ۸۱۹۲ توکن، شامل دستور سیستم، سندهای RAG و خود پاسخ.
• موتور اجرا vLLM.
• عددها گرد شده‌اند و سربار یک تخمین است.

حساب حافظه

weights (AWQ 4-bit)            ≈ 19 GB
KV cache, BF16: 20 × 2 GiB     ≈ 40 GB
overhead (estimate)            ≈ 4–6 GB
----------------------------------------
worst case, BF16 KV cache      ≈ 64 GB
worst case, FP8 KV cache       ≈ 44 GB   (KV: 20 × 1 GiB)

«بدترین حالت» یعنی هر ۲۰ کاربر هم‌زمان با context کاملاً پر، که کم پیش می‌آید؛ با PagedAttention اگر گفت‌وگوها به‌طور میانگین نیمه‌پر باشند، KV cache هم نصف است. تصمیم با شماست: برای بدترین حالت بخرید، یا بپذیرید که در اوج‌های نادر بعضی درخواست‌ها کمی در صف بمانند.

کدام کارت؟

برای این سناریو، دو کارت ۴۸ گیگابایتی (L40S یا RTX 6000 Ada) یا یک کارت ۸۰ تا ۹۶ گیگابایتی را انتخاب معقول می‌دانم. یک کارت ۴۸ گیگابایتی هم برای شروع و دورهٔ آزمایشی کافی است، به شرطی که KV cache را FP8 کنید و بدانید در اوج کمی صف خواهید داشت.

یک کارت یا دو کارت: موازی‌سازی تانسوری

در موازی‌سازی تانسوری (tensor parallelism) ماتریس‌های هر لایه بین کارت‌ها تقسیم می‌شوند؛ هر کارت نصف وزن‌ها و نصف سرهای کلید-مقدار را دارد. حافظه و پهنای باند دو کارت جمع می‌شود، پس تولید هم سریع‌تر می‌شود. هزینه‌اش ارتباط بین کارت‌ها در هر لایه است: با NVLink (در A100 و H100 نسخهٔ SXM) کم، و روی PCIe بیشتر ولی برای دو کارت معمولاً قابل‌قبول. تعداد سرهای توجه باید بر تعداد کارت‌ها بخش‌پذیر باشد؛ Qwen3-32B با ۶۴ سر پرسش و ۸ سر کلید-مقدار روی ۲، ۴ یا ۸ کارت مشکلی ندارد.

vllm serve Qwen/Qwen3-32B-AWQ \
  --tensor-parallel-size 2 \
  --max-model-len 8192 \
  --kv-cache-dtype fp8 \
  --max-num-seqs 32

راه دیگر این است که روی هر کارت یک نسخهٔ کامل و مستقل از مدل بالا بیاید و یک load balancer جلوی آن‌ها درخواست‌ها را بین کارت‌ها پخش کند. ارتباطی بین کارت‌ها لازم نیست، ولی هر کارت فقط حافظهٔ خودش را دارد. روی کارت ۴۸ گیگابایتی، بعد از ۱۹ گیگابایت وزن و سربار، حدود ۲۲ گیگابایت برای KV cache می‌ماند: حدود ۱۱ گفت‌وگوی پر با BF16 یا ۲۲ گفت‌وگو با FP8 برای هر کارت.

برای اینکه بدانید این حساب‌ها از کجا می‌آید: خودم با این چیدمان‌ها کار کرده‌ام: یک RTX 3090، دو RTX 3090، دو RTX A6000 که با هم کار می‌کردند، و دو RTX 5080 کنار هم. هر کدام همان سؤال‌های این نوشته را جلوی آدم می‌گذارد: وزن‌ها کجا جا می‌شوند، چقدر برای KV cache می‌ماند، و چند کاربر هم‌زمان واقعاً جواب می‌گیرند.

همین سناریو با Llama 3.3 70B ۴ بیتی: ۴۰ گیگابایت وزن، ۲۰ × ۲٫۵ گیگابایت KV cache و سربار، یعنی حدود ۹۵ گیگابایت با BF16 و ۷۰ با FP8. دو کارت ۴۸ گیگابایتی با FP8 لب‌به‌لب کافی است و دو کارت ۸۰ گیگابایتی راحت.

قطعه‌هایی که معمولاً فراموش می‌شوند

• رم سیستم: قاعدهٔ سرانگشتی من: دست‌کم به‌اندازهٔ کل فایل‌های مدل و ترجیحاً بیشتر، چون پایگاه داده، Elasticsearch و کانتینرها هم رم می‌خواهند. برای سرور مثال بالا ۱۲۸ گیگابایت محتاطانه است.
• دیسک NVMe: بارگذاری ۱۹ گیگابایت از SSD معمولی (حدود ۰٫۵ گیگابایت در ثانیه) نزدیک ۴۰ ثانیه طول می‌کشد و از NVMe چند ثانیه. چند مدل و نسخه کنار هم، یکی دو ترابایت را زود پر می‌کند.
• CPU و خطوط PCIe: توکنایز کردن متن، زمان‌بندی درخواست‌ها و API روی CPU اجرا می‌شوند. برای چند کارت، به هر کارت خط PCIe x16 کامل برسد.
• برق و خنک‌کاری: دو L40S به‌تنهایی ۷۰۰ وات می‌کشند؛ با بقیهٔ سرور حدود ۱٫۲ تا ۱٫۵ کیلووات مصرف مداوم (تخمین). کارت‌های دیتاسنتری مثل L40S و A100 فن ندارند و به جریان هوای شاسی سرور وابسته‌اند.
• embedding و reranker برای RAG: مدل embedding (که متن را برای جست‌وجوی معنایی به بردار تبدیل می‌کند) مثل bge-m3، و reranker (که نتیجه‌های جست‌وجو را دوباره مرتب می‌کند) مثل bge-reranker-v2-m3، حدود ۵۶۸ میلیون پارامتر دارند و با FP16 یکی دو گیگابایت می‌گیرند. کوچک‌اند، ولی روی همان GPU با مدل اصلی بر سر حافظه و محاسبه رقابت می‌کنند. یا با --gpu-memory-utilization سهم vLLM را کم کنید یا آن‌ها را روی کارت جدا بگذارید. روی CPU گذاشتنشان وسوسه‌انگیز است ولی کند است: در بنچمارک RAG فارسی خودم، reranker روی CPU حدود ۱۲ ثانیه برای هر سؤال طول می‌کشید.

نکته‌های مخصوص ایران

خرید GPU زیر تحریم. کارت‌های دیتاسنتری محدودیت صادراتی دارند و از بازار خاکستری و کشورهای واسط می‌رسند. یعنی گارانتی رسمی ندارید، ممکن است کارت کارکرده یا تعمیری باشد و تحویل طول می‌کشد. قبل از پرداخت، کارت را با nvidia-smi و یک تست فشار (stress test) چندساعته بررسی کنید. قیمت‌ها هم سریع عوض می‌شوند؛ هر عددی امروز بنویسم تا شما بخوانید کهنه شده. قیمت را نزدیک زمان خرید بپرسید.

اجارهٔ سرور GPU در داخل یا خارج. اگر داده نباید از کشور خارج شود، که برای بیشتر سازمان‌های دولتی و عمومی همین‌طور است، سرور خارجی اصلاً گزینه نیست؛ بسیاری از ارائه‌دهندگان خارجی هم به‌خاطر تحریم به کاربران ایرانی سرویس نمی‌دهند. بعضی دیتاسنترها و ارائه‌دهندگان ابری داخلی سرور GPU اجاره می‌دهند. بپرسید دقیقاً چه کارتی است، اختصاصی است یا اشتراکی، چه کسی دسترسی root دارد و قرارداد دربارهٔ داده چه تعهدی می‌دهد.

دانلود وزن‌ها و بسته‌ها. دسترسی مستقیم به Hugging Face از داخل ایران همیشه پایدار نیست و ممکن است راه‌حل جایگزین لازم شود؛ همین را دربارهٔ ایمیج‌های Docker و بسته‌های pip هم پیش‌بینی کنید. راه تمیز این است که وزن‌ها را جای دیگری دانلود و بعد منتقل کنید، که برای سرور بدون اینترنت به‌هرحال لازم است. هش SHA256 فایل‌ها را با عدد Hugging Face مقایسه کنید و safetensors را به فایل‌های pickle ترجیح دهید، به‌خصوص وقتی فایل از یک mirror غیررسمی آمده.

برق. با خاموشی‌های سال‌های اخیر، UPS برای سروری که ۱ تا ۱٫۵ کیلووات می‌کشد هزینهٔ جانبی نیست، بخشی از طراحی است.

خودم برای اجارهٔ سرور GPU داخل ایران با ایران GPU کار می‌کنم و تجربه‌ام با سرویسشان از بقیه بهتر بوده است. این فقط تجربهٔ شخصی من است، نه تبلیغ؛ پیش از اجاره، کارت، حافظه، محل دیتاسنتر و شرایط پشتیبانی را خودتان مقایسه کنید.

چک‌لیست پیش از خرید

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