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

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

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

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

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

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

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

مدل‌ها در حالت انتشار با دقت 16 بیت عرضه می‌شوند که معادل 2 گیگابایت به ازای هر میلیارد پارامتر است. به همین دلیل است که تقریباً هیچ‌کس از دقت اصلی (release precision) روی 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 انتخاب پیش‌فرض منطقی برای سرورهای محدود به حافظه (memory bound) است: افت کیفیت نسبت به 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 که وضعیت توجه یا attention مدل برای هر توکن در مکالمه است)، دومین هزینه حافظه محسوب می‌شود. این حافظه هنگام بارگذاری مدل تخصیص می‌یابد، اندازه آن بر اساس طول کانتکستی که درخواست کرده‌اید تعیین می‌شود و با افزایش آن طول، به‌صورت خطی رشد می‌کند.

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-bit و در context پیش‌فرض 4096 توکن کافی است. تا اوت 2026، این کلاس شامل Llama 3.2 با 3B، Qwen 3 با 1.7B و 4B، و نسخه‌های کوچک Gemma و Phi می‌شود. این موارد را به‌عنوان نمونه‌های اندازه در نظر بگیرید، نه توصیه. نام مدل‌ها هر چند ماه یک‌بار تغییر می‌کند، اما محاسبات ریاضی ثابت می‌ماند.

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

حالت شکست در این سطح، استفاده از swap است. اگر مدل در حافظه جا نشود، لینوکس از بارگذاری آن امتناع نمی‌کند. در عوض، حافظه را به دیسک منتقل می‌کند (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 گیگابایت است، اجرا کنید یا اگر ترجیح می‌دهید حافظه را به‌جای تعداد پارامترها صرف دقت (precision) کنید، یک مدل 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 گیگابایت حجم دارد؛ بنابراین با یک context کوتاه در پلن 32 گیگابایتی جا می‌شود و روی سرورهای 48 یا 64 گیگابایتی به‌راحتی اجرا می‌گردد. یک مدل 70B با کوانتایز 4 بیت، حدود 42 گیگابایت حجم دارد؛ پس پیش از آنکه حتی ذره‌ای حافظه برای cache در نظر بگیرید، به 64 گیگابایت رم نیاز دارد.

سپس سرعت را واقع‌بینانه بررسی کنید. یک مدل 32B روی CPU با سرعتی بین 0.6 تا 1.5 توکن در ثانیه اجرا می‌شود و مدل 70B سرعتی بین 0.2 تا 0.5 دارد. پاسخ 500 توکنی از آن مدل 70B حدود بیست دقیقه زمان می‌برد. این‌ها ابزارهای دسته‌ای (batch) هستند. اگر صف اسناد را شبانه به آن‌ها بدهید، سرعت اهمیتی ندارد. اما اگر آن‌ها را پشت یک پنجره چت قرار دهید، سرعت اهمیت بسیار زیادی پیدا می‌کند.

مسیریابی در Mixture of Experts (MoE) این محاسبات را تغییر می‌دهد و این تنها جزئیات معماری است که ارزش یادگیری دارد. یک مدل MoE هر توکن را تنها از بخش کوچکی از وزن‌های خود عبور می‌دهد. مدلی با 30B پارامتر کل و 3B پارامتر فعال برای هر توکن، به حافظه‌ای در حد یک مدل 30B نیاز دارد اما سرعتی نزدیک به یک مدل متراکم 3B ارائه می‌دهد، زیرا هر توکن فقط expertهای فعال را می‌خواند. روی یک سرور 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 ایجاد می‌کند. خواندن یک سند طولانی برای CPU چند دقیقه و برای GPU چند ثانیه زمان می‌برد. این اولین مانعی است که هنگام اتصال یک عامل کدنویسی به مدلی که میزبانی می‌کنید با آن مواجه می‌شوید، زیرا در هر نوبت، پیش از آنکه حتی یک توکن از پاسخ بازگردد، کل محتوای فایل و تعاریف ابزارها دوباره ارسال می‌شود.

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

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

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

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

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

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

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

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

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

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

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

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

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، و حدود 1 گیگابایت برای سیستم‌عامل و سرور مدل. در context با 8192 توکن، حافظه کش حدود 1 گیگابایت اضافه می‌کند، بنابراین پلن 8 گیگابایتی مناسب است اما پلن 4 گیگابایتی کافی نیست. اگر به دنبال context کامل 128k هستید که در کارت مدل ذکر شده، حافظه کش به‌تنهایی 16 گیگابایت خواهد بود و باید به فکر پلن 32 گیگابایتی باشید.

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

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

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

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

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

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

آیا می‌توانم مدلی به توانمندی مدل‌های تجاری بزرگ را به‌صورت self-hosted اجرا کنم؟

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