اجرای مدل Qwen 27B روی VPS با Ollama

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

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

پاسخ کوتاه این است: بله، روی یک VPS با 32 گیگابایت رم یا بیشتر، اما با سرعت پایین. یک مدل متراکم 27B با کوانتایزیشن Q4، تنها برای وزن‌ها به حدود 17 گیگابایت رم نیاز دارد، آن هم پیش از اینکه حتی یک توکن از کانتکست ذخیره شود. این موضوع پلن‌های 8 و 16 گیگابایتی را کاملاً از رده خارج می‌کند. روی یک VPS معمولی با DDR4 دوکاناله، سقف سرعت تقریباً 3 توکن در ثانیه است که از سرعت خواندن اکثر افراد کمتر است.

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

کدام تگ 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 معماری، تعداد پارامترها، طول کانتکست و کوانتیزاسیون تگی که در حال حاضر دارید را چاپ می‌کند. اگر خط پارامترها 27.8B و خط کوانتیزاسیون Q4_K_M را نشان می‌دهد، شما همان نسخه‌ای را دارید که این راهنما بر اساس آن نوشته شده است. کتابخانه همچنین شامل qwen3.6:27b-q8_0 و qwen3.6:27b-bf16 برای همان وزن‌ها با دقت بالاتر است؛ به‌علاوه مجموعه‌ای از تگ‌های 35b-a3b که مدل‌های MoE (ترکیب متخصصان) هستند و روی 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 گیگابایت خواهد بود. تگ Q4_K_M که عرضه شده است 17 گیگابایت است که در عمل به 4.89 بیت به ازای هر وزن می‌رسد.

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

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

هزینه حافظه KV با افزایش طول متن (context)

وزن‌های مدل هزینه‌ای ثابت دارند. حافظه KV (حافظه کلید و مقدار، یعنی وضعیت توجهی که مدل برای هر توکن دیده‌شده نگه می‌دارد) با افزایش طول متن به‌صورت خطی رشد می‌کند و این همان بخشی است که اکثر کاربران در آن با کمبود 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 در مدل‌های متراکم اخیر خود در این کلاس اندازه استفاده کرده است: 64 لایه، 8 هد کلید/مقدار تحت GQA (توجه گروهی-پرسشی) و ابعاد هد 128. این مقادیر به 256 KiB برای هر توکن در حالت f16 می‌رسد، بنابراین 8 گیگابایت برای 32k توکن و 32 گیگابایت برای 128k توکن نیاز است. به محاسبات من اکتفا نکنید و محاسبات خود را روی سیستم خود انجام دهید. مدل را بارگذاری کنید و ستون SIZE را در ollama ps بخوانید که وزن‌ها، حافظه کش و سربار را به عنوان یک عدد واحد گزارش می‌کند.

به همین دلیل است که عدد 256K برای طول متن در کارت مدل، بیشتر یک تیتر تبلیغاتی است تا یک برنامه عملیاتی. پر کردن آن در حالت f16، علاوه بر وزن‌های مدل، 64 گیگابایت حافظه کش اضافی نیاز دارد؛ آن هم روی ماشینی که همین حالا 17 گیگابایت برای وزن‌ها هزینه کرده است. Ollama به‌صورت پیش‌فرض کل پنجره متن را در اختیار شما نمی‌گذارد. این ابزار یک پنجره بسیار کوچک‌تر را بارگذاری می‌کند و شما باید آن را به‌صورت دستی با OLLAMA_CONTEXT_LENGTH افزایش دهید. این کار را مرحله‌به‌مرحله انجام دهید و پس از هر تغییر، ollama ps را بررسی کنید.

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

چه چیزی در 8، 16، 32 و 64 گیگابایت رم جای می‌گیرد

[
  {
    "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."
  }
]

این دو عدد را به عنوان هزاران توکن از کانتکست در نظر بگیرید که در کنار وزن‌ها، با کش f16، روی یک VPS لینوکسی بدون رابط گرافیکی (headless) با حدود 1.5 گیگابایت فضای باقی‌مانده برای سیستم‌عامل و مقداری حاشیه اطمینان، جای می‌گیرند. عدد صفر به این معناست که خودِ وزن‌ها در رم جا نمی‌شوند، بنابراین هیچ کانتکستی قابل اجرا نیست.

مقادیر 8 و 16 گیگابایت برای این کار مناسب نیستند. 17 گیگابایت وزن در 16 گیگابایت رم جا نمی‌شود و هیچ تغییری در تنظیمات کانتکست این موضوع را حل نمی‌کند. افزودن swap نیز کمکی نمی‌کند. Ollama فایل GGUF را memory-map می‌کند، بنابراین به محض اینکه صفحات مقیم (resident pages) از رم فراتر روند، کرنل شروع به تخلیه و خواندن مجدد آن‌ها می‌کند و هر توکن، گیگابایت‌ها داده را از دیسک فراخوانی می‌کند. در این حالت، سرور با iowait بالا مواجه شده و سرعتی بسیار کمتر از یک توکن در ثانیه خواهد داشت.

32 گیگابایت نقطه شروع است. وزن‌ها 17 گیگابایت را اشغال می‌کنند و شما حدود 13 گیگابایت فضای خالی دارید که حدود 32k توکن کانتکست f16 را با در نظر گرفتن حاشیه اطمینان پوشش می‌دهد. وزن‌های Q8_0 با حجم 30 گیگابایت به هیچ وجه در این سطح جای نمی‌گیرند.

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

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

تولید هر توکن از یک مدل متراکم (dense)، مستلزم خواندن تمام وزن‌ها از حافظه در هر مرحله است. نه فقط بخشی از آن‌ها، بلکه تمام آن‌ها. بنابراین محدودیت سرعت، تعداد هسته‌های شما نیست؛ بلکه پهنای باند حافظه تقسیم بر حجم وزن‌هاست. در کوانتایز Q4، این مقدار برابر با 17 گیگابایت ترافیک حافظه به ازای هر توکن است.

[
  {
    "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) ناقص باعث می‌شود هرگز به اوج نظری نرسید. یک VPS با حافظه دوکاناله DDR4-3200 سقفی معادل 3 توکن در ثانیه دارد، بنابراین انتظار حدود 2 توکن را داشته باشید. یک سرور با حافظه دوکاناله DDR5-4800 سقفی معادل 4.5 دارد، پس انتظار حدود 3 توکن را داشته باشید.

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

افزایش تعداد vCPUها نیز به همین دلیل خیلی زود تأثیر خود را از دست می‌دهد. وقتی هسته‌ها داده‌ها را سریع‌تر از توان کنترلر حافظه درخواست کنند، ترد‌های اضافی فقط سربار زمان‌بندی (scheduling overhead) ایجاد می‌کنند و هیچ فایده‌ای ندارند. مقدار OLLAMA_NUM_THREAD را روی تعداد هسته‌های فیزیکی خود تنظیم کنید، اندازه‌گیری کنید و سپس نصف آن عدد را امتحان کنید. در بسیاری از پلن‌های اشتراکی، تنظیمات پایین‌تر سریع‌تر عمل می‌کنند.

پردازش پرامپت (Prompt processing) رفتار متفاوتی دارد. مرحله Prefill، یعنی عبور از ورودی شما پیش از ظاهر شدن اولین توکن، محدود به توان پردازشی (compute bound) است و نه پهنای باند؛ بنابراین با افزایش تعداد هسته‌ها مقیاس‌پذیر است. نتیجه عملی این است که در پرامپت‌های بزرگ، قبل از شروع خروجی یک وقفه طولانی خواهید داشت و پس از آن، نرخ ثابت و کندِ ذکر شده در بالا آغاز می‌شود. هر دو بخش را جداگانه با --verbose زمان‌بندی کنید؛ این دستور برای هر درخواست یک prompt eval rate و یک eval rate چاپ می‌کند.

اگر مدل متراکم 27B بیش از حد کند است، پیش از ناامیدی از CPU، به تگ‌های qwen3.6:35b-a3b نگاهی بیندازید. این تگ‌ها به جای تمام 27.8 میلیارد پارامتر، حدود 3 میلیارد پارامتر را به ازای هر توکن فعال می‌کنند؛ بنابراین ترافیک حافظه به ازای هر توکن نزدیک به یک مرتبه بزرگی کاهش می‌یابد، حتی اگر حجم فایل روی دیسک بیشتر باشد. شما در واقع فضای RAM را فدای سرعت می‌کنید. انتخاب Runtime نیز در اینجا اهمیت دارد و Ollama و llama.cpp کنترل‌های تنظیم CPU متفاوتی را ارائه می‌دهند که همگی بر پایه یک کد استنتاج واحد هستند.

چه زمانی اجارهٔ ساعتی 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 تعیین کنید، نه بر اساس ترجیح شخصی. استنتاج (inference) روی CPU زمانی انتخاب درستی است که کار به‌صورت ناهمگام (asynchronous) باشد و کسی منتظر خروجی آن نباشد: مانند خلاصه‌سازی دسته‌ای از اسناد در طول شب، یا یک عملیات طبقه‌بندی شبانه که هنگام خواب شما اجرا می‌شود. به محض اینکه شخصی منتظر خروجی است، یا زمانی که نرخ درخواست‌ها سریع‌تر از یک مورد در هر 30 ثانیه است، یک GPU اجاره کنید؛ زیرا یک سرور فقط-CPU فضای کافی برای batching ندارد و صف درخواست‌ها به‌سادگی طویل می‌شود.

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

گزینهٔ سومی هم وجود دارد که افراد فراموش می‌کنند. مدل 27B را برای کارهای دسته‌ای روی CPU نگه دارید و برای مسیرهای تعاملی، از یک مدل API میزبانی‌شده استفاده کنید. هیچ قانونی وجود ندارد که بگوید یک مدل باید هر دو وظیفه را انجام دهد.

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

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

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 مدت زمانی است که خواندن وزن‌ها از دیسک طول کشیده است؛ به همین دلیل OLLAMA_KEEP_ALIVE=60m تنظیم شده است: روی CPU، بارگذاری مجدد 17 گیگابایت از دیسک در هر درخواست، هزینه‌ای بیشتر از خودِ درخواست دارد.

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

ollama ps

ستون SIZE نشان‌دهنده ردپای واقعی حافظه شامل KV cache است و باید به وزن‌ها به اضافه ردیف مربوط به طول کانتکست (context length) در جدول KV نزدیک باشد. در 8192 توکن با کش 8 بیتی، انتظار حدود یک گیگابایت حافظه اضافی علاوه بر وزن‌ها را داشته باشید، در مقایسه با 2 گیگابایت اگر کش در حالت f16 باقی می‌ماند. ستون PROCESSOR باید 100% CPU را نشان دهد. اگر مقدار دیگری نمایش داده می‌شود، یعنی چیزی GPU را اشغال کرده است و اعداد سرعت در این راهنما، وضعیت سخت‌افزار شما را توصیف نمی‌کنند.

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

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

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

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

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

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

کاربرد واقعی یک مدل 27B که فقط روی CPU اجرا می‌شود

انتظارات خود را بر اساس اعداد تنظیم کنید، نه بر اساس امیدواری. با سرعت دو تا چهار توکن در ثانیه، پاسخ به یک پرسش 500 توکنی بین دو تا چهار دقیقه زمان می‌برد. این سرعت برای چت غیرقابل استفاده است، اما برای پردازش‌های صف‌بندی‌شده کاملاً مناسب است. خلاصه‌سازی اسناد، برچسب‌گذاری انبوه، استخراج فیلدها از آرشیو فایل‌ها و بازبینی کد به‌صورت غیرهمزمان، همگی با این سرعت سازگار هستند، زیرا هیچ‌کس منتظر پاسخ فوری نیست. دستیاری کدنویسی دقیقاً در مرز این کاربرد قرار دارد؛ بنابراین اتصال یک عامل کدنویسی به مدلی که خودتان میزبانی می‌کنید برای کارهای پس‌زمینه مانند نوشتن پیام‌های commit و ایجاد ساختار اولیه تست‌ها مفید است، اما برای پیشنهادهای لحظه‌ای که باید منتظرشان بمانید، کارایی ندارد.

استدلال اصلی، حفظ حریم خصوصی است. مدل روی سخت‌افزاری اجرا می‌شود که شما اجاره کرده و کنترل می‌کنید؛ هیچ درخواستی از سرور خارج نمی‌شود و هزینه‌ای به ازای هر توکن وجود ندارد. این موضوع حتی با سرعت سه توکن در ثانیه، برای داده‌های حساس و تحت نظارت بسیار ارزشمند است. آن را صادقانه با جایگزین‌های دیگر بسنجید: میزبانی شخصی یک مدل در مقیاس پیشرو (frontier-scale) به سخت‌افزاری با مرتبه بزرگی بالاتر نیاز دارد و مدل 27B روی CPU، ارزان‌ترین نقطه در این منحنی است که خروجی آن همچنان ارزش خواندن دارد.

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

FAQ

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

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

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

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

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

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

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

در تقریباً تمام موارد، Q4_K_M. نسخه Q8_0 حجمی معادل 30 گیگابایت در برابر 17 گیگابایت دارد، بنابراین به یک پلن 64 گیگابایتی نیاز دارد و به ازای هر توکن، تقریباً دو برابر داده از حافظه جابه‌جا می‌کند که باعث می‌شود سرعت توکن در ثانیه شما تقریباً نصف شود. تفاوت کیفیت بین Q4_K_M و Q8_0 در یک مدل 27B برای اکثر کارها ناچیز است. رم را صرف افزایش طول متن (context) کنید، زیرا این کار قابلیت‌های مدل را تغییر می‌دهد، نه نحوه بیان جملات آن را.

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

زمانی که چرخه کاری شما پایین است یا کاربر منتظر پاسخ است. یک GPU با 24 گیگابایت حافظه، روی این وزن‌ها به سرعتی در حدود 59 توکن در ثانیه می‌رسد، در حالی که این مقدار در یک VPS معمولی 2 یا 3 است؛ علاوه بر این، هزینه GPU فقط برای ساعاتی که روشن است محاسبه می‌شود. یک VPS با 64 گیگابایت رم، در تمام طول ماه هزینه دارد، چه مدل روی آن بارگذاری شده باشد و چه نباشد. محاسبه کنید که در روز چند ساعت واقعاً توکن تولید می‌کنید. برای کمتر از دو یا سه ساعت، اجاره ساعتی GPU معمولاً هم از نظر سرعت و هم از نظر هزینه برنده است. کارهای دسته‌ای (batch) با اولویت پایین و مداوم، جایی است که VPS همیشه روشن برنده است.