اجرای Qwen 3.8 27B روی VPS بدون GPU با Ollama

آیا می‌توان Qwen 3.8 27B را روی یک VPS بدون GPU اجرا کرد؟

برای اجرای Qwen 3.8 27B روی یک VPS، ابتدا به یک model tag موجود نیاز دارید. در تاریخ 4 August 2026، کتابخانه Ollama هیچ ورودی qwen3.8 ندارد. نزدیک‌ترین tag منتشرشده برای 27B، qwen3.6:27b است: 27.8 میلیارد پارامتر، quantisation از نوع Q4_K_M و مجوز Apache 2.0. همه فرمان‌ها و اعداد زیر از همین tag در Ollama v0.32.5 استفاده می‌کنند؛ این نسخه در 27 July 2026 منتشر شده است.

پاسخ کوتاه این است: بله، روی VPS با 32 GB یا بیشتر امکان‌پذیر است، اما سرعت پایین خواهد بود. یک مدل dense با 27B پارامتر و Q4، فقط برای weights به حدود 17 GB RAM نیاز دارد؛ این مقدار حتی شامل ذخیره یک token از context نیز نمی‌شود. بنابراین پلن‌های 8 GB و 16 GB کاملاً نامناسب‌اند. در یک VPS معمولی با DDR4 دوکاناله، سقف سرعت تقریباً 3 token در ثانیه است؛ این سرعت از سرعت خواندن بیشتر کاربران کمتر است.

عدد 3.8 از کجا آمده است؟ به‌احتمال زیاد از تعداد پارامترها. صفحه Ollama برای qwen3.6:27b تعداد 27.8B پارامتر را گزارش می‌کند و به‌خاطر سپردن 27.8 به‌عنوان 3.8 در آینده آسان است. همچنین یک qwen3.5:27b وجود دارد که همان build با Q4_K_M از release قبلی است. پیش از کپی‌کردن هر فرمان، فهرست زنده را در صفحه tag مربوط به qwen3.6 در Ollama بررسی کنید. اگر بعداً یک qwen3.8 واقعی منتشر شود، محاسبات اینجا همچنان معتبر خواهند بود، زیرا به تعداد پارامترها و تعداد bit برای هر weight وابسته‌اند، نه به شماره نسخه.

کدام tag را از Ollama دریافت کنیم و چگونه آن را بررسی کنیم

دریافت tagای که وجود ندارد، خطای مشخصی ایجاد می‌کند؛ بنابراین می‌توانید این موضوع را مستقیماً روی همان سیستم و به‌سرعت تعیین کنید. بااین‌حال، tagای که وجود دارد ممکن است به‌صورت محلی قابل اجرا نباشد. همین مسئله دربارهٔ GLM 5.2 که در library فهرست شده است اما فقط از cloud مربوط به Ollama ارائه می‌شود باعث سردرگمی کاربران می‌شود.

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

دستور ollama show معماری، تعداد پارامترها، طول context و quantisation مربوط به tagای را که واقعاً در اختیار دارید چاپ می‌کند. اگر خط پارامتر مقدار 27.8B و خط quantisation مقدار Q4_K_M را نشان دهد، همان build مورد استفاده در این راهنما را دارید. library برای همین weights در precision بالاتر، qwen3.6:27b-q8_0 و qwen3.6:27b-bf16 را نیز دارد. علاوه بر این، مجموعه‌ای از tagهای 35b-a3b وجود دارد که مدل‌های MoE (mixture of experts) هستند و روی CPU رفتار کاملاً متفاوتی دارند. در ادامه دربارهٔ آن‌ها بیشتر توضیح داده می‌شود.

تعداد پارامترها ضربدر بایت به‌ازای هر وزن

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

فرمول در یک خط خلاصه می‌شود: بایت‌های وزن = پارامترها * بیت به‌ازای هر وزن / 8. در 4 بیت خالص، 27.8 میلیارد پارامتر برابر با 13.9 GB خواهد بود. برچسب Q4_K_M ارائه‌شده 17 GB است؛ بنابراین در عمل، مقدار 4.89 بیت به‌ازای هر وزن به دست می‌آید.

این اختلاف خطا نیست. قالب‌های K-quant همه tensorها را با عرض اسمی یکسان ذخیره نمی‌کنند. tensorهایی که در اثر فشرده‌سازی بیشترین افت کیفیت را دارند، با 5 یا 6 بیت نگه‌داری می‌شوند و لایه‌های token embedding و output نیز معمولاً روی Q6_K یا Q8_0 باقی می‌مانند. نام قالب یک میانگین را نشان می‌دهد و این میانگین به حدود 4.9 می‌رسد. همین اثر در سوی دیگر مقیاس نیز دیده می‌شود: 56 GB برای BF16 برابر با 16.1 بیت به‌ازای هر وزن است، نه یک مقدار ثابت 16؛ زیرا فایل metadata و یک جدول embedding با دقت کامل را نیز در خود دارد.

برای این مدل، Q5_K_M برچسب منتشرشده‌ای ندارد؛ بنابراین ردیف 19.8 GB بر اساس مقدار معمول 5.7 بیت به‌ازای هر وزن در این قالب محاسبه شده و اندازه‌گیری نشده است. Q8_0 تقریباً اندازه Q4 را دو برابر می‌کند و به 30 GB می‌رسد. در یک سیستم فقط با CPU، این دو برابر شدن به‌ازای هر token، دو برابر ترافیک حافظه ایجاد می‌کند و در نتیجه سرعت را برحسب token در ثانیه نیز تقریباً نصف می‌کند. فقط به همین دلیل، Q4_K_M گزینه پیش‌فرض مناسبی است. اگر به‌جای جنبه حافظه، می‌خواهید اثر این انتخاب بر کیفیت را بررسی کنید، مقایسه‌ای دقیق‌تر میان Q4، Q8 و fp16 نشان می‌دهد که خروجی از کجا واقعاً شروع به افت می‌کند.

هزینهٔ KV cache با افزایش context

وزن‌های مدل هزینه‌ای ثابت هستند. KV cache (حافظهٔ cache مربوط به key و value؛ یعنی وضعیت attention که مدل برای هر token مشاهده‌شده نگه می‌دارد) با طول context به‌صورت خطی رشد می‌کند و بیشتر کاربران عملاً RAM را در همین بخش از دست می‌دهند.

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

این اعداد بر اساس ساختاری محاسبه شده‌اند که Qwen در مدل‌های dense اخیر خود در این ردهٔ اندازه استفاده کرده است: 64 لایه، 8 سرِ key/value در GQA (grouped-query attention) و head dimension برابر با 128. این ساختار در f16 برای هر token برابر با 256 KiB است؛ بنابراین برای 32k token مقدار 8 GB و برای 128k مقدار 32 GB خواهد بود. این محاسبه را بدون بررسی روی سیستم خودتان نپذیرید. مدل را load کنید و ستون SIZE در ollama ps را بخوانید؛ این ستون وزن‌ها، cache و سربار را در یک مقدار واحد گزارش می‌کند.

به همین دلیل، context برابر با 256K که در model card آمده است، بیشتر یک عدد تبلیغاتی است تا یک برنامهٔ عملی. پر کردن آن در f16، علاوه بر وزن‌ها، 64 GB cache مصرف می‌کند؛ آن هم روی سیستمی که همین حالا 17 GB برای وزن‌ها مصرف کرده است. Ollama به‌طور پیش‌فرض کل این window را در اختیار شما نمی‌گذارد. این برنامه window بسیار کوچک‌تری load می‌کند و شما باید آن را با OLLAMA_CONTEXT_LENGTH به‌صورت آگاهانه افزایش دهید. این متغیر در سطح server تنها اهرم موجود نیست؛ تنظیم num_ctx در درخواست جداگانه به شما اجازه می‌دهد برای همهٔ درخواست‌های دیگر یک مقدار پیش‌فرض کم‌هزینه داشته باشید و فقط برای یک job طولانی window بزرگ‌تری تعیین کنید. مقدار را مرحله‌به‌مرحله افزایش دهید و پس از هر تغییر، ollama ps را بررسی کنید.

دو تنظیم می‌توانند cache را به نصف یا کمتر کاهش دهند. OLLAMA_KV_CACHE_TYPE=q8_0، cache را به‌جای 16 بیت با 8 بیت ذخیره می‌کند و مصرف مربوط به 32k token را از 8 GB به 4 GB کاهش می‌دهد. این قابلیت به flash attention نیاز دارد؛ بنابراین OLLAMA_FLASH_ATTENTION=1 را نیز تنظیم کنید و کاهش مصرف را در ollama ps تأیید کنید، نه این‌که صرفاً فرض کنید تنظیم اعمال شده است. OLLAMA_NUM_PARALLEL=1 نیز به همان اندازه اهمیت دارد. Ollama می‌تواند چند درخواست را هم‌زمان سرویس دهد و هر slot بخش جداگانه‌ای از context را دریافت می‌کند؛ بنابراین باقی‌گذاشتن parallelism روی مقدار پیش‌فرض، cache موردنظر شما را بی‌سروصدا چند برابر می‌کند. اگر بیش از یک نفر از این سیستم استفاده می‌کند، مشکل از همین افزایش چندبرابری آغاز می‌شود؛ تعداد کاربران هم‌زمانی که یک مدل self-hosted می‌تواند سرویس دهد مدت‌ها پیش از تعداد coreها، با تعداد cache slotها و عمق صف تعیین می‌شود.

چه چیزی در 8، 16، 32 و 64 GB RAM جا می‌شود

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

این دو عدد را به‌عنوان هزار توکنِ context در نظر بگیرید که در کنار weights، با cache نوع f16، روی یک Linux VPS بدون رابط گرافیکی جا می‌گیرند؛ در این محاسبه حدود 1.5 GB برای سیستم‌عامل و مقدار کمی حاشیه در نظر گرفته شده است. صفر یعنی خود weights جا نمی‌شوند؛ بنابراین هیچ contextای نیز جا نمی‌گیرد.

8 GB و 16 GB موارد مرزی نیستند. 17 GB از weights در 16 GB RAM جا نمی‌شود و هیچ تنظیمی برای context این مشکل را برطرف نمی‌کند. افزودن swap نیز کمکی نمی‌کند. Ollama فایل GGUF را با memory-map نگاشت می‌کند؛ بنابراین وقتی صفحات resident از RAM بیشتر شوند، kernel شروع به خارج‌کردن و دوباره‌خوانی آن‌ها می‌کند و هر token چندین GB داده را از دیسک می‌خواند. در این وضعیت، سرور در iowait بالا می‌ماند و سرعت تولید به‌مراتب کمتر از 1 token در ثانیه می‌شود.

32 GB نقطه شروع است. Weights مقدار 17 GB فضا می‌گیرند و حدود 13 GB باقی می‌ماند؛ این مقدار با حاشیه، تقریباً 32k token از context نوع f16 را پوشش می‌دهد. Weights نوع Q8_0 با حجم 30 GB در این tier اصلاً جا نمی‌شوند.

64 GB وضعیت مناسبی ایجاد می‌کند. Q4 حدود 128k token فضا برای context باقی می‌گذارد و weights نوع Q8_0 نیز با حدود 64k token context در دسترس، جا می‌شوند. پیش از آن‌که برای دستیابی به Q8 هزینه 64 GB RAM را بپردازید، دقیقاً مشخص کنید چه چیزی می‌خرید: خروجی کمی بهتر، با نصف سرعت، روی ماشینی که از ابتدا نیز کند بوده است. برای تقریباً همه، استفاده از Q4 با context طولانی‌تر انتخاب بهتری است.

سرعت inference روی CPU در یک VPS چقدر است؟

تولید یک token از یک مدل dense یعنی خواندن همه وزن‌ها از حافظه، آن هم یک‌بار. نه بخشی از آن‌ها؛ همه آن‌ها. بنابراین محدودیت سرعت تعداد core نیست، بلکه پهنای‌باند حافظه تقسیم بر اندازه وزن‌ها است. در Q4، این مقدار 17 GB ترافیک حافظه برای هر token است.

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

این اعداد سقف نظری هستند، نه اندازه‌گیری واقعی. خروجی واقعی معمولاً حدود 50 تا 70 درصد مقدار نمایش‌داده‌شده است، چون latency حافظه و prefetching ناقص مانع رسیدن به peak نظری می‌شوند. یک VPS با DDR4-3200 دوکاناله سقفی برابر با 3 token در ثانیه دارد؛ بنابراین انتظار حدود 2 را داشته باشید. یک سرور DDR5-4800 دوکاناله سقفی برابر با 4.5 دارد؛ بنابراین انتظار حدود 3 را داشته باشید.

ردیف‌های مربوط به سرورهای بزرگ با یک هشدار همراه‌اند. یک پلتفرم EPYC دوازده‌کاناله 460.8 GB/s پهنای‌باند و سقف 27.1 token در ثانیه دارد، اما شما کل یک EPYC را اجاره نمی‌کنید. پهنای‌باند حافظه یک منبع سراسری در host است که همه tenantهای آن ماشین از آن استفاده می‌کنند؛ بنابراین یک slice با 8 vCPU دارای دوازده کانال پهنای‌باند اختصاصی نیست. راهنماهای متمرکز بر GPU معمولاً این موضوع را کاملاً نادیده می‌گیرند. همین موضوع باعث می‌شود دو پلن VPS با تعداد vCPU یکسان، روی همان مدل، تا سه برابر تفاوت سرعت داشته باشند.

vCPUهای بیشتر نیز به همین دلیل خیلی زود دیگر کمکی نمی‌کنند. وقتی coreها سریع‌تر از توان memory controller برای تحویل داده درخواست ارسال کنند، threadهای بیشتر فقط overhead زمان‌بندی ایجاد می‌کنند و مزیت دیگری ندارند. مقدار OLLAMA_NUM_THREAD را برابر با تعداد physical coreهای خود تنظیم کنید، اندازه‌گیری انجام دهید و سپس نصف آن مقدار را امتحان کنید. در بسیاری از پلن‌های اشتراکی، مقدار کمتر سریع‌تر است.

پردازش prompt رفتار متفاوتی دارد. prefill، یعنی پردازش ورودی شما پیش از نمایش نخستین token، بیشتر به توان محاسباتی وابسته است تا پهنای‌باند. بنابراین با افزایش تعداد coreها مقیاس‌پذیر است. اثر عملی آن، مکثی طولانی پیش از شروع خروجی برای promptهای بزرگ و سپس نرخ ثابت و کندی است که در بالا گفتیم. هر دو بخش را جداگانه با --verbose زمان‌گیری کنید. این دستور برای هر request یک prompt eval rate و یک eval rate چاپ می‌کند.

اگر مدل dense با 27B پارامتر بیش از حد کند است، پیش از کنار گذاشتن CPU، tagهای qwen3.6:35b-a3b را بررسی کنید. این tagها به‌جای هر 27.8 میلیارد پارامتر، در هر token تقریباً 3 میلیارد پارامتر را فعال می‌کنند. در نتیجه، با وجود بزرگ‌تر بودن فایل روی دیسک، ترافیک حافظه برای هر token تقریباً یک مرتبه بزرگی کمتر می‌شود. در این حالت، footprint حافظه را با سرعت معاوضه می‌کنید. انتخاب runtime نیز در اینجا اهمیت دارد و Ollama و llama.cpp کنترل‌های متفاوتی برای tuning CPU ارائه می‌کنند، هرچند از همان کد inference زیربنایی استفاده می‌کنند.

چه زمانی بهتر است به‌جای آن، یک ساعت GPU اجاره کنید

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

همین فرمول، وقتی روی پهنای‌باند حافظهٔ GPU منتشرشده اعمال شود، به پاسخ متفاوتی در یک دستهٔ دیگر منجر می‌شود. یک کارت مصرفی 24 GB در این وزن‌ها سقف 59 توکن در ثانیه دارد. یک کارت فعلی مرکز داده به 197 می‌رسد. این فاصله با تنظیم تعداد threadها جبران نمی‌شود. کارت حافظهٔ خود را با سرعت 1008 GB/s اجرا می‌کند، درحالی‌که VPS شما به چند ده GB/s محدود است.

بنابراین مرز تصمیم‌گیری را بر اساس workload تعیین کنید، نه ترجیح شخصی. CPU inference زمانی انتخاب مناسبی است که کار asynchronous باشد و کسی منتظر نتیجه نباشد؛ برای مثال، خلاصه‌سازی شبانهٔ مجموعه‌ای از اسناد یا یک کار classification شبانه که هنگام خواب شما اجرا می‌شود. به‌محض آن‌که فردی منتظر خروجی باشد، یا درخواست‌ها با فاصله‌ای کمتر از هر 30 ثانیه برسند، GPU اجاره کنید؛ چون یک سیستم CPU-only ظرفیت batching ندارد و صف به‌سادگی بزرگ‌تر می‌شود.

مقایسهٔ هزینه آن‌قدر که به نظر می‌رسد ساده نیست. یک VPS با 64 GB در تمام ساعت‌های ماه هزینه ایجاد می‌کند، چه model در حافظه load شده باشد و چه نباشد؛ اما یک GPU instance فقط برای ساعت‌هایی هزینه دارد که آن را روشن نگه می‌دارید. اگر مصرف واقعی شما روزانه 2 ساعت است، GPU اجاره‌ای می‌تواند هم سریع‌تر و هم ارزان‌تر باشد. ابتدا duty cycle خود را محاسبه کنید و سپس هزینه را مقایسه کنید. انتخاب VPS دارای GPU مواردی را که باید در خود instance بررسی کنید پوشش می‌دهد و vLLM هنگام ارائهٔ درخواست‌های هم‌زمان روی GPU از Ollama جلو می‌افتد، چون آن‌ها را به‌درستی batch می‌کند.

گزینهٔ سومی هم وجود دارد که اغلب فراموش می‌شود. مدل 27B را برای کارهای batch روی CPU نگه دارید و یک مدل hosted API را در مسیر interactive قرار دهید. هیچ الزامی وجود ندارد که یک model هر دو نوع کار را ارائه کند.

نصب Ollama و اندازه‌گیری سیستم خودتان

اسکریپت نصب، اسکریپت رسمی است و یک سرویس systemd ایجاد می‌کند که با کاربر اختصاصی ollama اجرا می‌شود.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

دستور ollama --version باید 0.32.5 یا نسخه‌ای جدیدتر را نمایش دهد. پیش از دریافت هر چیزی، free -g را بررسی کنید. اگر ستون total در خط Mem مقداری کمتر از 32 نشان می‌دهد، همین‌جا متوقف شوید و مدل کوچک‌تری انتخاب کنید؛ زیرا دریافت 17 GB داده‌ای که نمی‌توانید اجرا کنید، یک ساعت زمان و مقدار زیادی فضای دیسک را هدر می‌دهد.

گزینه‌های runtime را به‌جای shell، در یک override برای systemd تنظیم کنید. مدل داخل سرویس اجرا می‌شود؛ بنابراین محیط تعاملی شما را نمی‌بیند.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

خروجی --verbose همان اندازه‌گیری موردنظر شماست. eval rate تعداد توکن‌هایی است که در هر ثانیه هنگام تولید پردازش می‌کنید. prompt eval rate سرعت prefill است. load duration مدت‌زمان خواندن weights از دیسک را نشان می‌دهد؛ به همین دلیل OLLAMA_KEEP_ALIVE=60m تنظیم شده است: در CPU، بارگذاری دوباره 17 GB از دیسک در هر درخواست، بیشتر از خود درخواست زمان می‌برد. timeout پیش‌فرض برای idle پنج دقیقه است. بنابراین یک صف batch که بین آیتم‌ها فاصله دارد، این هزینه بارگذاری را بارها پرداخت می‌کند. گزینه‌های resident نگه‌داشتن مدل هم فیلد keep_alive را برای هر درخواست پوشش می‌دهند و هم امکان ماندگارکردن این تنظیم پس از reboot را فراهم می‌کنند.

تا زمانی که مدل در حافظه بارگذاری شده است، footprint را از یک terminal دوم بررسی کنید.

ollama ps

ستون SIZE، footprint واقعی حافظه را شامل KV cache نشان می‌دهد و باید تقریباً به مجموع weights و ردیف مربوط به طول context شما در نمودار KV نزدیک باشد. در 8192 توکن و cache هشت‌بیتی، انتظار می‌رود حدود یک گیگابایت علاوه بر weights مصرف شود؛ اگر cache روی f16 باقی می‌ماند، این مقدار 2 GB بود. ستون PROCESSOR باید 100% CPU را نشان دهد. اگر مقدار دیگری نمایش داده شود، چیزی از GPU استفاده کرده است و اعداد سرعت این راهنما وضعیت سیستم شما را توصیف نمی‌کنند.

حالت‌های خرابی و رشته‌های دقیقی که مشاهده خواهید کرد

مدل بارگذاری نمی‌شود. Ollama خطی چاپ می‌کند که هر دو مقدار را نام می‌برد و قالب آن به‌شکل model requires more system memory (18.6 GiB) than is available (15.2 GiB) است. این حالت، خرابی مطلوب است؛ زیرا Ollama پیش از تخصیص حافظه بررسی را انجام داده است و اجازه نداده kernel وضعیت را مدیریت کند. طول context را کاهش دهید، به یک tag کوچک‌تر بروید یا از plan بزرگ‌تری استفاده کنید.

فرایند در میانهٔ پاسخ ناپدید می‌شود. client اطلاعات مفیدی نمایش نمی‌دهد و journalctl -u ollama -n 50 نشان می‌دهد که سرویس در حال restart شدن است. dmesg -T | tail را اجرا کنید. وجود خطی با متن Out of memory: Killed process ... (ollama) یعنی kernel OOM killer فرایند را متوقف کرده است. این وضعیت زمانی رخ می‌دهد که بررسی پیش از load موفق بوده، اما cache در جریان یک گفت‌وگوی طولانی از مقدار برآوردشده بزرگ‌تر شده است. طول context را کاهش دهید.

pull بلافاصله شکست می‌خورد. Error: pull model manifest: file does not exist یعنی tag در library وجود ندارد. وارد کردن qwen3.8:27b دقیقاً همین نتیجه را ایجاد می‌کند؛ هر اشتباه تایپی در شمارهٔ version نیز همین اثر را دارد. پیش از آن‌که شبکه را مقصر بدانید، tag را در صفحهٔ library تأیید کنید.

همه‌چیز کار می‌کند، اما سرعت به‌شدت کم است. سرعت کمتر از 1 token در ثانیه روی سیستمی با RAM کافی، بیشتر به paging اشاره دارد تا به کمبود توان پردازشی. هنگام تولید خروجی vmstat 1 را اجرا کنید. مقدار غیرصفر در ستون si یا so یعنی kernel در حال swapping است. راه‌حل، context کمتر یا مدل‌های بارگذاری‌شدهٔ کمتر است. مقدار بالای پایدار در wa بدون فعالیت swap یعنی weightهای memory-mapped دوباره از disk خوانده می‌شوند؛ بنابراین واقعاً در حافظه جا نمی‌گیرند.

اولین token پس از 30 ثانیه ظاهر می‌شود و سپس خروجی سریع‌تر می‌شود. این مرحله prefill است و طبیعی محسوب می‌شود. هزینهٔ یک system prompt طولانی در هر درخواستی که از cache استفاده نکند دوباره پرداخت می‌شود. بنابراین پیش از هر تنظیم دیگری، system prompt را کوتاه‌تر کنید.

یک مدل 27B که فقط با CPU اجرا می‌شود، واقعاً برای چه کاری مناسب است

انتظارات را بر اساس اعداد تنظیم کنید، نه امید. با سرعت 2 تا 4 توکن در ثانیه، تولید یک پاسخ 500 توکنی بین 2 تا 4 دقیقه طول می‌کشد. این سرعت برای چت قابل‌استفاده نیست، اما برای صف پردازش کاملاً مناسب است. مدلی که پیش از پاسخ‌دادن فکر می‌کند، این محاسبه را بدتر می‌کند؛ زیرا توکن‌های reasoning پنهان نیز با همان سرعت پایین پاسخ تولید می‌شوند. بنابراین، هماهنگ‌کردن سطح تلاش reasoning با کار یکی از معدود اهرم‌هایی است که بدون تعویض مدل، زمان پاسخ را کوتاه می‌کند. خلاصه‌سازی اسناد، برچسب‌گذاری انبوه، استخراج فیلد از انباشت فایل‌ها و code review بدون نظارت، این تأخیر را تحمل می‌کنند؛ زیرا هیچ‌کس منتظر پاسخ نیست. کمک در کدنویسی دقیقاً در مرز این کاربردها قرار دارد. بنابراین، سپردن یک coding agent به مدلی که خودتان میزبانی می‌کنید برای کارهای پس‌زمینه مانند تولید پیام commit و test scaffolding مفید است، نه برای پیشنهادهای inline که باید منتظرشان بمانید.

استدلال اصلی، حریم خصوصی است. مدل روی سخت‌افزاری اجرا می‌شود که آن را اجاره کرده‌اید و کنترل می‌کنید. هیچ درخواستی از سیستم خارج نمی‌شود و هزینه‌ای نیز به‌ازای هر توکن وجود ندارد. حتی با سرعت 3 توکن در ثانیه، این مزیت برای داده‌های مشمول مقررات ارزش زیادی دارد. بااین‌حال، آن را صادقانه با گزینه جایگزین مقایسه کنید: میزبانی شخصی یک مدل در مقیاس frontier به سخت‌افزاری با یک مرتبه بزرگی بیشتر نیاز دارد و مدل 27B روی CPU ارزان‌ترین نقطه در این منحنی است که خروجی آن هنوز ارزش خواندن دارد.

برای benchmark کردن هر یک از این کاربردها، به ورودی ساختاریافته واقعی نیاز دارید. بیشتر APIهای داده عمومی پیش از آن‌که حتی بتوانید throughput را اندازه‌گیری کنید، حساب کاربری می‌خواهند. endpoint نمایشی Strasmore که آن را اجرا می‌کنیم، بدون key و بدون signup، SQL فقط‌خواندنی را روی 22 سال داده بازار ایالات متحده اجرا می‌کند: یک GET به https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5، JSON را برمی‌گرداند که می‌توانید مستقیماً به یک حلقه prompt بدهید. این پاسخ، SQL دقیق تولیدکننده داده را نیز شامل می‌شود تا مدل چیزی برای خلاصه‌سازی داشته باشد و بتوانید نتیجه را مستقل بررسی کنید. محدودیت هر فراخوانی 500 ردیف و 20 ثانیه است و این مقدار بسیار بیشتر از چیزی است که یک سیستم با سرعت 2 توکن در ثانیه مصرف می‌کند. فهرست کامل ستون‌ها در https://api.strasmore.com/v1/schema قرار دارد.

اگر این نخستین نصب Ollama شماست، راهنمای کامل اجرای Ollama روی VPS راه‌اندازی سرویس، HTTP API و قواعد firewall موردنیاز این راهنما را پوشش می‌دهد. پورت 11434 را در اینترنت expose نکنید. Ollama به‌صورت پیش‌فرض authentication ندارد؛ بنابراین هر چیزی که به این پورت دسترسی پیدا کند، می‌تواند از مدل شما استفاده کند و promptهای شما را بخواند.

FAQ

آیا مدل Qwen 3.8 27B در Ollama وجود دارد؟

خیر. تا 4 August 2026، کتابخانهٔ Ollama هیچ namespaceای با نام qwen3.8 ندارد. tagهای 27B موجود، qwen3.5:27b و qwen3.6:27b هستند و هر دو buildهای Q4_K_M از یک مدل dense با 27.8 billion پارامترند. عدد 3.8 در عبارت جست‌وجو تقریباً قطعاً همان تعداد 27.8B پارامتر است که به‌اشتباه به‌عنوان شمارهٔ نسخه به یاد آورده شده است. برای فهرست فعلی، https://ollama.com/library/qwen3.6/tags را بررسی کنید و اگر جدیدترین 27B منتشرشده را می‌خواهید، qwen3.6:27b را pull کنید. استفاده از tagی که وجود ندارد با Error: pull model manifest: file does not exist شکست می‌خورد.

برای اجرای مدل Qwen 27B روی VPS به چه مقدار RAM نیاز دارم؟

برای Q4_K_M، حداقل عملی 32 GB است. حجم weights برابر با 17 GB است، سیستم‌عامل حدود 1.5 GB نیاز دارد و KV cache به‌ازای هر 4000 توکن context در f16، تقریباً 1 GB اضافه می‌کند. پلن 16 GB حتی فضای کافی برای weights ندارد و swap نیز کمکی نمی‌کند، چون فایل memory-mapped است و kernel در هر token دوباره آن را از دیسک می‌خواند. مقدار 64 GB برای context طولانی یا weights نوع Q8_0 با حجم 30 GB فضای کافی فراهم می‌کند.

مدل 27B روی CPU چند token در ثانیه تولید می‌کند؟

پهنای باند memory را بر حجم weights تقسیم کنید و سپس 50 تا 70 درصد حاصل را در نظر بگیرید. یک VPS با دو کانال DDR4-3200 سقفی نزدیک به 3 token در ثانیه دارد و حدود 2 token در ثانیه ارائه می‌دهد. یک سیستم با دو کانال DDR5-4800 سقفی نزدیک به 4.5 دارد و حدود 3 token در ثانیه ارائه می‌دهد. پلتفرم‌های server با کانال‌های بیشتر روی کاغذ بسیار بهتر به نظر می‌رسند، اما پهنای باند memory بین همهٔ tenantهای host مشترک است. بنابراین سرعت سیستم خود را با ollama run qwen3.6:27b --verbose اندازه‌گیری کنید و خط eval rate را بخوانید.

روی VPS فقط-CPU از Q4 استفاده کنم یا Q8؟

تقریباً در همهٔ موارد، Q4_K_M. حجم Q8_0 برابر 30 GB است، درحالی‌که حجم Q4_K_M برابر 17 GB است. بنابراین Q8_0 به پلن 64 GB نیاز دارد و برای هر token تقریباً دو برابر memory جابه‌جا می‌کند؛ در نتیجه سرعت تولید token تقریباً نصف می‌شود. تفاوت کیفیت Q4_K_M و Q8_0 در یک مدل 27B برای بیشتر کارها کم است. RAM را به context طولانی‌تر اختصاص دهید، چون این کار قابلیت‌های مدل را تغییر می‌دهد، نه فقط نحوهٔ بیان آن را.

چه زمانی اجارهٔ GPU از یک VPS با RAM زیاد ارزان‌تر است؟

وقتی duty cycle پایین باشد یا شخصی منتظر نتیجه بماند. یک GPU با 24 GB memory روی این weights تقریباً 59 token در ثانیه تولید می‌کند، درحالی‌که یک VPS معمولی 2 یا 3 token در ثانیه ارائه می‌دهد. GPU فقط برای ساعت‌هایی که اجرا می‌شود هزینه دارد. VPS با 64 GB تمام ماه هزینه دارد، چه مدل load شده باشد و چه نباشد. محاسبه کنید واقعاً روزانه چند ساعت token تولید می‌کنید. اگر این زمان کمتر از 2 یا 3 ساعت باشد، اجارهٔ ساعتی GPU معمولاً هم از نظر سرعت و هم از نظر هزینه بهتر است. پردازش batch کم‌اولویت و پیوسته همان جایی است که VPS همیشه‌روشن مزیت دارد.