راهنمای انتخاب مدل هوش مصنوعی برای خودمیزبانی

چه چیزی تعیین می‌کند کدام مدل‌های هوش مصنوعی را می‌توانید خودمیزبانی کنید

اینکه کدام مدل‌های هوش مصنوعی را می‌توانید خودمیزبانی کنید، تنها با یک عدد تعیین می‌شود: مقدار RAM موجود در سرور. خانوادهٔ مدل و فریم‌ورک، اهمیت بسیار کمتری نسبت به این موضوع دارند که آیا وزن‌های مدل در حافظه جا می‌شوند و فضای خالی باقی می‌ماند یا خیر. این مطلب محاسبات لازم برای تعیین این موضوع را ارائه می‌دهد. نصب یک محیط اجرا (runtime)، کاری جداگانه است که در راهنمای اجرای Ollama روی VPS به آن پرداخته شده است.

دو هزینه، پاسخ این پرسش را تعیین می‌کنند. وزن‌ها هزینهٔ ثابت هستند که توسط تعداد پارامترها و کوانتایزیشن (quantisation) تعیین می‌شوند. پنجرهٔ متن (context window) هزینهٔ جاری است؛ همان موردی که افراد فراموش می‌کنند تا زمانی که مدلی که دیروز بارگذاری شده بود، امروز از بارگذاری سر باز می‌زند.

محاسبات حجم: بیت به ازای هر پارامتر

فایل مدل تقریباً به‌طور کامل از وزن‌ها تشکیل شده است. هر وزن با تعداد مشخصی بیت ذخیره می‌شود. کوانتیزاسیون (Quantisation) به معنای ذخیره‌سازی وزن‌ها با تعداد بیت کمتر از دقت زمان آموزش است؛ این کار باعث کاهش جزئی دقت و صرفه‌جویی قابل‌توجه در حافظه می‌شود. حجم مدل مستقیماً از همین قاعده پیروی می‌کند:

weights in GB = (parameters in billions x bits per weight) / 8

مدل‌ها در حالت پیش‌فرض با دقت 16 بیت عرضه می‌شوند که معادل 2 گیگابایت به ازای هر میلیارد پارامتر است. به همین دلیل است که تقریباً هیچ‌کس مدل‌ها را با دقت اصلی روی VPS اجرا نمی‌کند. این‌ها کوانتیزاسیون‌هایی هستند که در عمل با آن‌ها مواجه خواهید شد، به همراه میانگین واقعی بیت به ازای هر وزن:

• Q8_0 حدود 8.5 بیت به ازای هر وزن ذخیره می‌کند، یعنی تقریباً 1.1 گیگابایت به ازای هر میلیارد پارامتر.
• Q6_K حدود 6.6 بیت ذخیره می‌کند، یعنی تقریباً 0.83 گیگابایت به ازای هر میلیارد.
• Q5_K_M حدود 5.7 بیت ذخیره می‌کند، یعنی تقریباً 0.71 گیگابایت به ازای هر میلیارد.
• Q4_K_M حدود 4.8 بیت ذخیره می‌کند، یعنی تقریباً 0.6 گیگابایت به ازای هر میلیارد.

عدد 0.6 گیگابایت به ازای هر میلیارد پارامتر را به‌عنوان مبنای محاسبات خود در نظر بگیرید. Q4_K_M گزینه پیش‌فرض منطقی برای سرورهایی است که با محدودیت حافظه مواجه‌اند: افت کیفیت در مقایسه با 8 بیت در اکثر وظایف ناچیز است و حجم فایل تقریباً به نصف کاهش می‌یابد. زیر 4 بیت، افت کیفیت به‌سرعت افزایش می‌یابد؛ بنابراین یک مدل 70B که در 2 بیت فشرده شده، معمولاً عملکرد ضعیف‌تری نسبت به یک مدل 32B در 4 بیت از همان نسل دارد. زمانی که حافظه محدود است، پیش از آنکه به زیر 4 بیت بروید، یک رده اندازه مدل را کاهش دهید.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

ستون وزن در بالا، حاصل اعمال قانون 0.6 گیگابایت به ازای هر میلیارد است. فایل‌های GGUF واقعی با اختلاف چند درصد در همین محدوده قرار می‌گیرند، زیرا لایه‌های embedding و output با دقت بالاتری نسبت به سایر بخش‌ها نگهداری می‌شوند. یک مدل 3B در 4 بیت حدود 1.8 گیگابایت است. یک مدل 8B حدود 4.8 گیگابایت است. یک مدل 32B حدود 19.2 گیگابایت و یک مدل 70B حدود 42 گیگابایت است.

چرا طول کانتکست (context length) رم بیشتری نسبت به وزن‌های مدل اشغال می‌کند

حافظه کش KV (یا همان Key Value Cache، یعنی وضعیت توجهی که مدل برای هر توکن در مکالمه فعلی نگه می‌دارد) دومین هزینه حافظه است. این حافظه در زمان بارگذاری مدل تخصیص می‌یابد، اندازه آن بر اساس طول کانتکستی که درخواست کرده‌اید تعیین می‌شود و با افزایش آن طول، به‌صورت خطی رشد می‌کند.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

در کانتکست پیش‌فرض Ollama، آن مدل 8B نیم گیگابایت برای کش هزینه می‌کند. در 8192 توکن، این مقدار به 1 گیگابایت می‌رسد. در کانتکست 128k که در کارت مدل تبلیغ شده است، این مقدار 16 گیگابایت خواهد بود که بیش از سه برابر وزن‌های مدل است. مدل 70B حالت معکوس دارد: کش آن در 128k برابر با 40 گیگابایت است که کمتر از وزن‌های خود مدل است، زیرا مکانیزم Grouped Query Attention باعث می‌شود هزینه به ازای هر توکن با سرعتی بسیار کمتر از تعداد پارامترها رشد کند.

طول کانتکست پیش‌فرض Ollama روی سرورهای فقط CPU برابر با 4096 توکن است. هنگامی که GPU موجود باشد، مقدار پیش‌فرض را بر اساس VRAM انتخاب می‌کند: 32k برای بین 24 تا 48 گیگابایت، و 256k برای 48 گیگابایت و بالاتر. می‌توانید آن را با متغیر OLLAMA_CONTEXT_LENGTH روی سرور افزایش دهید، سپس بررسی کنید که مدل در حال اجرا واقعاً چه مقداری را در ستون CONTEXT از ollama ps دریافت کرده است. محاسبات حافظه پشت این تنظیم خاص در مطلب مربوط به num_ctx و طول کانتکست بررسی شده است.

دو راه برای کاهش مصرف حافظه کش وجود دارد. به‌جای کانتکستی که کارت مدل تبلیغ می‌کند، فقط کانتکستی را که واقعاً نیاز دارید درخواست کنید، زیرا اکثر کارهای چت و برنامه‌نویسی در محدوده 8k تا 32k جای می‌گیرند. یا اینکه خودِ کش را به 8 بیت کوانتایز (quantise) کنید که حجم آن را نصف می‌کند، هرچند این کار هزینه‌ای در دقت بازیابی کانتکست‌های طولانی خواهد داشت.

مدل مقیم، آن حافظه RAM را تا زمانی که چیزی آن را تخلیه نکند، اشغال نگه می‌دارد

Ollama یک مدل را تا 5 دقیقه پس از آخرین درخواست در حافظه نگه می‌دارد و سپس آن را تخلیه می‌کند. این رفتار پیش‌فرض برای لپ‌تاپ مناسب است، اما برای سرور اشتباه است؛ چرا که در سرور، اولین درخواست پس از هر دوره بیکاری، دوباره متحمل زمان بارگذاری می‌شود.

ollama ps
ollama stop qwen3:4b

ollama ps فهرستی از موارد مقیم را نمایش می‌دهد، که در آن ستون SIZE میزان حافظه اشغال‌شده و ستون UNTIL زمان انقضای آن را نشان می‌دهد. برای ثابت نگه‌داشتن دائمی یک مدل، مقدار OLLAMA_KEEP_ALIVE=-1 را در سرویس تنظیم کنید. مقدار 0 باعث می‌شود مدل بلافاصله پس از پایان هر پاسخ، تخلیه شود.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

یک پرامپت ارسال کنید و سپس ده دقیقه بعد دوباره ollama ps را اجرا کنید. مدل همچنان در فهرست دیده می‌شود، که دقیقاً هدف همین است: مدل چه کسی از آن استفاده کند و چه نکند، آن حافظه RAM را اشغال نگه می‌دارد. یک مدل ثابت (Pinned)، ظرفیت آزاد محسوب نمی‌شود. در یک VPS با 16 گیگابایت رم، یک مدل 8B با کانتکست 8k، تقریباً 6 گیگابایت فضا را تا زمانی که سرویس در حال اجراست اشغال می‌کند؛ بنابراین ابعاد سرور را بر اساس مجموع مدل و برنامه خود تعیین کنید، نه فقط بر اساس مدل. ثابت نگه‌داشتن مدل در حافظه به بررسی توازن میان این کار و تأخیر ناشی از شروع سرد (cold start) می‌پردازد.

چه چیزی روی یک VPS با 4 GB رم اجرا می‌شود

حدود 1 GB رم را برای سیستم‌عامل و سرور مدل رزرو کنید که تقریباً 3 GB باقی می‌ماند. این مقدار برای یک مدل 1B تا 4B با کوانتایز 4 بیت و در context پیش‌فرض 4096 توکن کافی است. تا اوت 2026، این کلاس شامل Llama 3.2 در نسخه 3B، Qwen 3 در نسخه‌های 1.7B و 4B، و نسخه‌های کوچک Gemma و Phi می‌شود. این موارد را به عنوان نمونه‌های اندازه در نظر بگیرید، نه توصیه. نام مدل‌ها هر چند ماه یک‌بار تغییر می‌کند اما محاسبات ریاضی ثابت می‌ماند.

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

حالت شکست در این سطح، استفاده از swap است. اگر مدل در رم جا نشود، Linux از بارگذاری آن امتناع نمی‌کند. در عوض، حافظه را به دیسک منتقل (page out) می‌کند و از آنجا که تولید هر توکن مستلزم خواندن تمام وزن‌ها در هر مرحله است، سرعت تولید به ثانیه برای هر توکن کاهش می‌یابد. هنگام پاسخ‌دهی مدل، free -h و ستون‌های si و so در vmstat 1 را زیر نظر بگیرید. وجود swap in و swap out غیر صفر در حین تولید، به این معناست که مدل برای این پلن بیش از حد بزرگ است.

چه چیزی روی یک VPS با 8 تا 16 گیگابایت رم اجرا می‌شود

اینجاست که مدل self-hosted به‌طور کلی کاربردی می‌شود. روی 8 گیگابایت رم، می‌توانید یک مدل 7B یا 8B را با کوانتایز 4 بیت، یعنی حدود 4.8 گیگابایت وزن، با context 8k اجرا کنید. روی 16 گیگابایت رم، می‌توانید یک مدل 13B یا 14B را با کوانتایز 4 بیت، یعنی حدود 8.4 گیگابایت اجرا کنید، یا اگر ترجیح می‌دهید حافظه را به‌جای تعداد پارامترها صرف دقت مدل کنید، یک مدل 8B را با کوانتایز 8 بیت نگه دارید.

سرعت، نکته اصلی است. یک مدل 8B روی CPU حدود 3 تا 7 توکن در ثانیه تولید می‌کند و یک مدل 14B حدود 1.5 تا 3.5 توکن در ثانیه. سرعت خواندن انسان حدود 5 تا 10 توکن در ثانیه است، بنابراین اجرای یک مدل 8B روی یک VPS مبتنی بر CPU، حسی شبیه به تماشای یک تایپیست کند دارد. این وضعیت برای کارهای پس‌زمینه مناسب است اما برای چت تعاملی خسته‌کننده خواهد بود. اجراهای اندازه‌گیری‌شده Qwen 3 در ابعاد 8B و بزرگ‌تر روی یک VPS نشان می‌دهد که این موضوع در عمل چگونه است.

چه چیزی روی یک VPS با 32 تا 64 گیگابایت رم اجرا می‌شود

یک مدل 32B با کوانتایز 4 بیت، حدود 19.2 گیگابایت حجم دارد؛ بنابراین در یک پلن 32 گیگابایتی با context کوتاه جا می‌شود و روی 48 یا 64 گیگابایت رم به‌راحتی اجرا می‌گردد. یک مدل 70B با کوانتایز 4 بیت، حدود 42 گیگابایت است؛ پس پیش از آنکه حتی ذره‌ای حافظه برای cache در نظر بگیرید، به 64 گیگابایت رم نیاز دارد.

سپس سرعت را واقع‌بینانه ارزیابی کنید. اجرای یک مدل 32B روی CPU حدود 0.6 تا 1.5 توکن در ثانیه است و مدل 70B حدود 0.2 تا 0.5 توکن در ثانیه تولید می‌کند. تولید یک پاسخ 500 توکنی با مدل 70B حدود 20 دقیقه زمان می‌برد. با این سرعت، درخواست معمولاً پیش از پایان کار مدل قطع می‌شود؛ زیرا timeout مربوط به client یا proxy در مقابل Ollama زودتر فعال می‌شود و خطای عبارت «context deadline exceeded» از همین‌جا ناشی می‌شود. این ابزارها برای پردازش دسته‌ای ساخته شده‌اند. اگر شبانه صفی از اسناد را به آن‌ها بدهید، سرعت اهمیت چندانی ندارد. اما اگر آن‌ها را پشت یک پنجرهٔ چت قرار دهید، سرعت اهمیت زیادی پیدا می‌کند.

مسیریابی در Mixture of Experts (MoE) این محاسبات را تغییر می‌دهد و این تنها جزئیات معماری است که ارزش یادگیری دارد. یک مدل MoE هر توکن را تنها از بخش کوچکی از وزن‌های خود عبور می‌دهد. مدلی با 30 میلیارد پارامتر کل و 3 میلیارد پارامتر فعال در هر توکن، به حافظه‌ای در حد یک مدل 30B نیاز دارد اما سرعتی نزدیک به یک مدل 3B متراکم (dense) ارائه می‌دهد، زیرا هر توکن فقط وزن‌های فعال (experts) را می‌خواند. روی یک سرور 32 گیگابایتی، یک مدل MoE با این مشخصات بسیار کاربردی‌تر از یک مدل 30B متراکم است. قاعده‌ای که باید به خاطر بسپارید این است: پارامترهای کل، میزان حافظه را تعیین می‌کنند و پارامترهای فعال، سرعت را.

سرعت استنتاج CPU واقعاً چقدر است؟

تولید هر توکن مستلزم خواندن یک‌بارهٔ تمام وزن‌های فعال از حافظه است. هیچ راهی برای دور زدن این موضوع وجود ندارد، بنابراین سرعت تولید در CPU توسط پهنای باند حافظه تعیین می‌شود، نه تعداد هسته‌ها. سقف سرعت از این تقسیم به دست می‌آید: پهنای باند حافظهٔ قابل‌استفاده تقسیم بر حجم وزن‌ها به بایت. یک VPS اشتراکی کوچک به‌طور واقع‌بینانه بین 10 تا 25 گیگابایت بر ثانیه از طریق vCPUهای خود ارائه می‌دهد، بنابراین یک مدل 4.8 گیگابایتی در نهایت به سرعتی نزدیک به 2 تا 5 توکن در ثانیه می‌رسد.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

این‌ها بازه‌هایی هستند که معمولاً در سخت‌افزارهای معمولی VPS گزارش می‌شوند و نه بنچمارک یک ماشین خاص. عدد شما به نسل حافظه، تعداد کانال‌های میزبان و تعداد همسایگانی که برای آن رقابت می‌کنند بستگی دارد. سرعت خود را با استفاده از هر تگ مدلی که از قبل دارید، اندازه‌گیری کنید:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

خلاصه‌ای که پس از پایان پاسخ چاپ می‌شود، با خطی شامل eval rate: ... tokens/s به پایان می‌رسد. این همان سرعت تولید شماست. اجرای اول هر نشست را نادیده بگیرید، زیرا load duration در همان خلاصه، شامل خواندن وزن‌ها از دیسک نیز می‌شود. اندازه‌گیری دقیق توکن بر ثانیه توضیح می‌دهد که چگونه عددی قابل‌مقایسه به دست آورید.

دو نتیجه در اینجا افراد را غافلگیر می‌کند. افزودن vCPU خیلی زود تأثیر خود را از دست می‌دهد، زیرا پس از حدود 8 هسته، هسته‌های اضافی به‌جای انجام محاسبات، منتظر حافظه می‌مانند. همچنین در یک پلن اشتراکی، همان دستور در ساعات مختلف اعداد متفاوتی برمی‌گرداند که ناشی از CPU steal time از یک همسایه پرمصرف است و ربطی به پیکربندی اشتباه شما ندارد.

خواندن پرامپت شما کاری متفاوت از تولید پاسخ است. پردازش پرامپت محدود به توان محاسباتی (compute bound) است، بنابراین با تعداد هسته‌ها مقیاس‌پذیر است و این همان جایی است که GPU بیشترین برتری را پیدا می‌کند. خواندن یک سند طولانی برای CPU چند دقیقه و برای GPU چند ثانیه زمان می‌برد. این اولین مانعی است که هنگام اتصال یک coding agent به مدلی که میزبانی می‌کنید با آن مواجه می‌شوید، زیرا در هر نوبت، پیش از آنکه حتی یک توکن از پاسخ بازگردد، کل محتوای فایل و تعاریف ابزارها دوباره ارسال می‌شود.

تغییرات هنگام افزودن GPU

محاسبات تغییری نمی‌کند، فقط استخری که محاسبات در آن انجام می‌شود متفاوت است. حافظه VRAM یک محدودیت سخت است، بنابراین پیش از اجاره، محاسبه کنید چه چیزی در آن جای می‌گیرد:

• 8 گیگابایت VRAM یک مدل 7B یا 8B با کوانتایز 4 بیت و context کوتاه را در خود جای می‌دهد.
• 16 گیگابایت یک مدل 14B با کوانتایز 4 بیت و context واقعی، یا یک مدل 8B با کوانتایز 8 بیت را پشتیبانی می‌کند.
• 24 گیگابایت یک مدل 32B با کوانتایز 4 بیت و context کوتاه را در خود جای می‌دهد.
• 48 گیگابایت و بالاتر، یک مدل 70B با کوانتایز 4 بیت را به همراه فضای کافی برای cache و هم‌زمانی (concurrency) پشتیبانی می‌کند.

وقتی یک مدل در حافظه جا نمی‌شود، Ollama آن را تقسیم می‌کند: بخشی از لایه‌ها روی GPU و باقی‌مانده روی CPU قرار می‌گیرند. ollama ps این تقسیم‌بندی را در ستون PROCESSOR به صورت چیزی شبیه به 78%/22% CPU/GPU گزارش می‌کند. این مورد را به عنوان یک هشدار در نظر بگیرید، نه یک قابلیت. نیمهٔ CPU سرعت کل فرآیند را تعیین می‌کند، زیرا هر توکن همچنان باید منتظر پردازش آن لایه‌ها بماند؛ بنابراین مدلی که یک‌چهارم لایه‌هایش روی CPU است، سرعتی بسیار نزدیک‌تر به CPU دارد تا GPU. اگر تقسیم‌بندی ناخواسته‌ای مشاهده کردید، ابتدا طول context را کاهش دهید. معمولاً حافظهٔ cache همان عاملی است که باعث عبور از حد مجاز می‌شود.

هم‌زمانی (concurrency) دلیل دیگر برای ارتقای ابعاد سخت‌افزار است. وزن‌های مدل بین درخواست‌های هم‌زمان به اشتراک گذاشته می‌شوند، اما هر درخواست فعال به KV cache اختصاصی خود نیاز دارد؛ بنابراین ده کاربر هم‌زمان برای یک مدل 8B با context 8k، علاوه بر وزن‌های مدل، به ده برابر 1 گیگابایت حافظه cache نیاز دارند. سرویس‌دهی به کاربران هم‌زمان از یک مدل self-hosted بررسی می‌کند که این سقف در کجا قرار می‌گیرد.

این‌که آیا اجارهٔ GPU صرفهٔ اقتصادی دارد یا خیر نیز یک مسئلهٔ محاسباتی است و به این بستگی دارد که در ماه واقعاً چند توکن تولید می‌کنید. نقطه سر به سر بین یک VPS دارای GPU و توکن‌های API این اعداد را تحلیل کرده است.

مواردی که نمی‌توانید خودمیزبانی (self-host) کنید

در اینجا دو مانع متفاوت وجود دارد و شناخت اینکه با کدام‌یک مواجه هستید، به شما کمک می‌کند.

مانع اول، وزن‌های بسته (closed weights) است. مدل‌های تجاری پیشرو توزیع نمی‌شوند، بنابراین فایلی برای دانلود وجود ندارد و هیچ تغییری در میزان RAM این موضوع را حل نمی‌کند. شما می‌توانید تمام اجزای پیرامون آن‌ها را خودمیزبانی کنید: رابط کاربری، لایه بازیابی (retrieval layer)، حلقه عامل (agent loop) و لاگ‌ها. خودِ مدل همچنان یک API از راه دور باقی می‌ماند. اینکه آیا می‌توانید Claude را خودمیزبانی کنید به طور کامل به این موضوع می‌پردازد.

مانع دوم، وزن‌های باز (open weights) هستند که بیش از حد بزرگ‌اند. بزرگ‌ترین نسخه‌های منتشرشدهٔ متن‌باز، طراحی‌هایی از نوع mixture of experts با صدها میلیارد پارامتر کل هستند. همان قانون برای آن‌ها نیز صدق می‌کند: یک مدل با 400B پارامتر کل در حالت 4-bit، پیش از در نظر گرفتن هرگونه cache، به حدود 240 GB فضا فقط برای وزن‌ها نیاز دارد. این سخت‌افزار تخصصی است و اجارهٔ ماهانهٔ آن بسیار بیشتر از هزینه‌ای است که اکثر افراد در طول یک سال برای توکن‌های API می‌پردازند. آنچه برای خودمیزبانی یک مدل در کلاس Kimi نیاز است، الزامات واقعی را بررسی می‌کند. همین تفکیک در کتابخانهٔ خود Ollama نیز دیده می‌شود، جایی که مدل GLM 5.2 تنها به عنوان یک مدل ابری فهرست شده است و نسخهٔ بسیار کوچک‌تر آن است که در واقع روی یک VPS دانلود می‌شود.

مرز صادقانه بین این دو: زمانی که بار کاری ثابت است و داده‌ها نباید سرور شما را ترک کنند، از خودمیزبانی استفاده کنید. زمانی که بار کاری نوسانی است یا کیفیت پاسخ‌دهی مدل‌های پیشرو دقیقاً همان چیزی است که به آن نیاز دارید، توکن بخرید.

پیش از انتخاب، وضعیت فعلی خود را بررسی کنید

free -h
nproc
lscpu | grep 'Model name'

برنامه‌ریزی خود را بر اساس ستون available از free -h انجام دهید، نه ستون total، زیرا total شامل حافظه‌ای است که سیستم در حال حاضر از آن استفاده می‌کند. حدود 1 گیگابایت برای سیستم‌عامل و سرور مدل کنار بگذارید. مقدار باقی‌مانده را بر 0.6 تقسیم کنید تا حداکثر تعداد پارامترها (به میلیارد) که می‌توانید در حالت 4-bit نگهداری کنید، به دست آید. سپس حافظه مورد نیاز برای KV cache مربوط به context دلخواه خود را از آن کسر کنید. نتیجه نهایی، پاسخ شماست و برخلاف لیست نام مدل‌ها، این روش همیشه معتبر باقی می‌ماند.

FAQ

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

حدود 4.8 گیگابایت برای وزن‌های مدل با کوانتیزاسیون 4 بیتی، به‌علاوه حافظه کش KV برای طول کانتکست (context length) شما، و حدود 1 گیگابایت برای سیستم‌عامل و سرور مدل. در کانتکست 8192 توکنی، این کش حدود 1 گیگابایت اضافه می‌کند؛ بنابراین یک پلن 8 گیگابایتی مناسب است اما پلن 4 گیگابایتی کافی نیست. اگر به کانتکست کامل 128k که در کارت مدل ذکر شده نیاز دارید، کش به‌تنهایی 16 گیگابایت فضا اشغال می‌کند و باید به فکر تهیه یک پلن 32 گیگابایتی باشید.

چرا با وجود vCPUهای زیاد در VPS، مدل من کند است؟

زیرا سرعت تولید توکن توسط پهنای باند حافظه محدود می‌شود، نه تعداد هسته‌ها. هر توکن نیازمند فراخوانی کل مجموعه وزن‌های فعال از RAM است؛ بنابراین به‌محض اینکه چند هسته، کانال‌های حافظه را اشباع کنند، بقیه هسته‌ها در حالت انتظار باقی می‌مانند. دلیل رایج دیگر، استفاده از swap است. اگر vmstat 1 در حین پاسخ‌دهی مدل، مقادیر غیرصفر برای si و so نشان می‌دهد، یعنی وزن‌ها در RAM جا نمی‌شوند و بخشی از هر توکن از روی دیسک خوانده می‌شود که هزینه عملکردی بسیار سنگین‌تری نسبت به تصور شما دارد.

آیا کانتکست طولانی‌تر واقعاً به حافظه بیشتری نیاز دارد؟

بله، و این رشد نسبت به تعداد توکن‌ها خطی است. یک مدل 8B معمولی حدود 128 کیلوبایت از کش KV را به ازای هر توکن مصرف می‌کند؛ بنابراین 8192 توکن 1 گیگابایت و 131072 توکن 16 گیگابایت هزینه دارد. این کش هنگام بارگذاری مدل تخصیص می‌یابد، نه زمانی که مکالمه طولانی می‌شود. بنابراین درخواست کانتکست 128k باعث می‌شود این حافظه بلافاصله رزرو شود، حتی اگر تمام پرامپت‌های ارسالی شما فقط 200 توکن طول داشته باشند.

آیا باید یک مدل بزرگ را با 2 بیت اجرا کنم یا یک مدل کوچک‌تر را با 4 بیت؟

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

آیا می‌توانم مدلی به توانمندی مدل‌های تجاری بزرگ را روی سرور شخصی میزبانی کنم؟

روی یک VPS معمولی خیر. قدرتمندترین مدل‌های متن‌باز صدها میلیارد پارامتر دارند که در حالت 4 بیتی، پیش از محاسبه کش KV، به بیش از 200 گیگابایت RAM نیاز دارند؛ ضمن اینکه قدرتمندترین مدل‌های تجاری اصلاً برای دانلود عمومی منتشر نشده‌اند. کاری که سخت‌افزار معمولی به‌خوبی انجام می‌دهد، اجرای یک مدل 8B تا 32B برای یک وظیفه خاص است؛ جایی که یک مدل کوچک اما متمرکز با پرامپت‌نویسی دقیق، اغلب با مدل‌های عمومی برابری می‌کند. اگر به کیفیت در سطح مدل‌های پیشرو نیاز دارید، پیش از خرید سخت‌افزار، هزینه آن را با هزینه API مقایسه کنید.