مقایسه کوانتیزاسیون Ollama: تفاوت q4_K_M و q8_0 و fp16

تغییرات کوانتیزاسیون در Ollama

کوانتیزاسیون در Ollama هر وزن در مدل را با تعداد بیت کمتری نسبت به فایلی که در آن آموزش دیده است، ذخیره می‌کند. تگی که به q4_K_M ختم می‌شود، حدود چهار بیت برای هر وزن نگه می‌دارد، در حالی که fp16 شانزده بیت را حفظ می‌کند؛ بنابراین حجم دانلود تقریباً یک‌چهارم است و دستگاه برای تولید هر توکن، یک‌چهارم بایت کمتری می‌خواند. وزن‌ها روی یک شبکه خشن‌تر گرد می‌شوند و دور ریخته نمی‌شوند؛ در چهار بیت، اکثر مدل‌ها تقریباً مشابه زمانی که با دقت کامل (full precision) بودند، پاسخ می‌دهند.

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

اگر Ollama هنوز در حال اجرا نیست، با نصب Ollama روی یک VPS شروع کنید. این صفحه فرض می‌کند که ollama ls هم‌اکنون کار می‌کند.

نحوه خواندن تگ کوانتایزیشن Ollama مانند q4_K_M

مدل‌های محلی در قالب فایل‌های GGUF عرضه می‌شوند؛ فرمتی که llama.cpp برای ذخیره وزن‌ها روی دیسک استفاده می‌کند. Ollama بر پایه llama.cpp ساخته شده است، بنابراین تگ‌های Ollama نام‌های کوانتایزیشن llama.cpp را بدون تغییر حمل می‌کنند.

عدد، نشان‌دهنده عرض هدف است. q4 به این معنی است که اکثر تانسورهای وزن در بسته‌های 4 بیتی فشرده شده‌اند. q8 به معنای 8 بیت است. fp16 اصلاً کوانتایز نشده است: این مدل در قالب 16 بیتی ممیز شناور (floating point) قرار دارد که دقتی است که اکثر مدل‌ها با آن منتشر می‌شوند.

K نشان‌دهنده K-quant است. وزن‌ها در بلوک‌های کوچک دسته‌بندی می‌شوند و هر بلوک مقیاس (scale) مخصوص به خود را در کنار مقادیر فشرده‌شده ذخیره می‌کند. بلوکی که وزن‌های آن همگی نزدیک به 0.01 هستند، مقیاس دقیق‌تری دریافت می‌کند. بلوکی که یک مقدار پرت (outlier) بزرگ دارد، مقیاس کلی‌تری دریافت می‌کند. این مقیاس‌های بلوک‌محور همان چیزی هستند که باعث می‌شوند یک فایل 4 بیتی قابل استفاده باقی بماند و همچنین دلیل این است که یک فایل 4 بیتی هرگز دقیقاً 4 بیت به ازای هر وزن نیست.

حرف آخر، نشان‌دهنده ترکیب (mixture) است. S، M و L تعیین می‌کنند که چه تعداد تانسور به عرضی بالاتر از عرض هدف ارتقا یابند. در q4_K_M، تانسورهایی که گرد کردن آن‌ها بیشترین آسیب را به مدل می‌زند، با عرض بیشتری ذخیره می‌شوند، در حالی که بخش عمده مدل در 4 بیت باقی می‌ماند. به همین دلیل است که q4_K_M خروجی بهتری نسبت به q4_0 قدیمی‌تر در تقریباً همان اندازه فایل تولید می‌کند.

به‌جای حدس زدن از روی نامی که تایپ کرده‌اید، از Ollama بپرسید چه چیزی روی دیسک دارد:

ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_M

ollama show مقادیر architecture، parameters، quantization، context length و embedding length را چاپ می‌کند. خط quantization حقیقت محض برای مدلی است که ماه‌ها پیش دریافت کرده‌اید و دیگر به یاد نمی‌آورید کدام نسخه را انتخاب کرده بودید.

تعداد بیت به ازای هر وزن، عامل تعیین‌کننده حجم فایل است

هر تخمین حجم از یک عدد شروع می‌شود: فرمت مورد نظر به‌طور میانگین در کل فایل، چند بیت به ازای هر وزن اختصاص می‌دهد. پروژه llama.cpp ارقام اندازه‌گیری‌شده برای مدل Llama 3.1 8B را در مستندات quantize خود منتشر کرده است که برای هر مدل متراکم (dense) با ساختار مشابه، قابل تعمیم است.

[
  {
    "label": "F16",
    "bits_per_weight": 16,
    "file_gib": 14.96
  },
  {
    "label": "Q8_0",
    "bits_per_weight": 8.5,
    "file_gib": 7.95
  },
  {
    "label": "Q6_K",
    "bits_per_weight": 6.56,
    "file_gib": 6.14
  },
  {
    "label": "Q5_K_M",
    "bits_per_weight": 5.7,
    "file_gib": 5.33
  },
  {
    "label": "Q4_K_M",
    "bits_per_weight": 4.89,
    "file_gib": 4.58
  },
  {
    "label": "Q3_K_M",
    "bits_per_weight": 3.99,
    "file_gib": 3.74
  }
]

نکته غافلگیرکننده در این جدول، ستون دوم است. فرمت Q4_K_M دقیقاً 4 بیت به ازای هر وزن نیست. این فرمت 4.89 بیت را اشغال می‌کند، زیرا مقیاس‌بندی بلوک‌ها (block scales) و تانسورهای ارتقایافته (promoted tensors) هر دو فضای واقعی مصرف می‌کنند. به همین دلیل، Q8_0 نیز به جای 8 بیت، 8.5 بیت را اشغال می‌کند. با استفاده از این اعداد اندازه‌گیری‌شده، محاسبات شما با اختلاف بسیار کمی (در حد چند درصد) به حجم واقعی فایل نزدیک خواهد بود:

weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiB

این همان فایل Q4_K_M با حجم 4.58 GiB است که از طریق دو عدد به دست آمده است. این مقدار همچنین تقریباً معادل حافظه‌ای است که وزن‌ها پس از بارگذاری اشغال می‌کنند. Ollama هنگام بارگذاری هیچ داده‌ای را unpack نمی‌کند: وزن‌های کوانتایز شده با همان فرمت فشرده در حافظه باقی می‌مانند و هر بلوک در لحظه استفاده، تبدیل می‌شود.

آنچه Ollama در واقع برای هر اندازه مدل ارائه می‌دهد

این کتابخانه برای اکثر خانواده‌های مدل، تگ‌های q4_K_M، q8_0 و fp16 منتشر می‌کند. برخی از خانواده‌های جدیدتر از این الگو پیروی نمی‌کنند و در کتابخانه فقط به عنوان تگ‌های ابری (cloud only) ظاهر می‌شوند که هیچ فایلی برای دانلود در هیچ اندازه‌ای ندارند؛ این همان بن‌بستی است که هنگام تلاش برای اجرای GLM 5.2 روی یک VPS با آن مواجه می‌شوید. این‌ها اندازه‌های Qwen3 تا اوت 2026 هستند که از لیست تگ‌ها در صفحه مدل خوانده شده‌اند. هر رقمی که در ادامه می‌آید، فضای دیسک مورد نیاز پیش از بارگذاری در RAM است و ترکیب دو یا سه مورد از آن‌ها می‌تواند حجم root یک VPS کوچک را پر کند؛ بنابراین پیش از شروع به جمع‌آوری تگ‌ها، بهتر است بدانید Ollama مدل‌های دانلود شده را کجا ذخیره می‌کند.

[
  {
    "label": "Qwen3 4B",
    "q4_K_M_gb": 2.6,
    "q8_0_gb": 4.4,
    "fp16_gb": 8.1
  },
  {
    "label": "Qwen3 8B",
    "q4_K_M_gb": 5.2,
    "q8_0_gb": 8.9,
    "fp16_gb": 16
  },
  {
    "label": "Qwen3 14B",
    "q4_K_M_gb": 9.3,
    "q8_0_gb": 16,
    "fp16_gb": 30
  },
  {
    "label": "Qwen3 32B",
    "q4_K_M_gb": 20,
    "q8_0_gb": 35,
    "fp16_gb": 66
  }
]

تگ پیش‌فرض در اینجا اهمیت دارد. ollama pull qwen3:8b دقیقاً همان 5.2 گیگابایت را دانلود می‌کند که ollama pull qwen3:8b-q4_K_M دانلود می‌کند، زیرا تگ بدون پسوند، همان نسخه q4_K_M است. نسخه Q4_K_M یک مصالحه نیست که کتابخانه با اکراه ارائه دهد. این همان پیش‌فرضی است که توسعه‌دهنده اصلی انتخاب کرده است، بنابراین برای هر مدلی که خودتان تست نکرده‌اید، مطابقت با آن منطقی‌ترین گام نخست است. همین استدلال، انتخاب تگ‌ها در اجرای Qwen 3 روی یک VPS را هدایت می‌کند.

این نسبت‌ها در تمام ردیف‌ها برقرار است. حرکت از q4_K_M به q8_0 حدود هفتاد درصد هزینه بیشتری دارد و نه دقیقاً دو برابر، زیرا تانسورهای embedding و output به همان شکلی که بقیه مدل مقیاس‌پذیرند، تغییر نمی‌کنند. نسخه fp16 تقریباً سه برابر q4_K_M است. یک مدل 32B در نسخه q4_K_M دارای 20 گیگابایت وزن است که از ظرفیت یک سرور 16 گیگابایتی با هر نوع پنجره متنی (context window) فراتر می‌رود. برای مشاهده دیدگاه جامع‌تری از اینکه چه مدلی روی چه دستگاهی اجرا می‌شود، مدل‌هایی که می‌توانید خودتان میزبانی کنید را ببینید.

چرا KV cache یک هزینه ثانویه و وابسته به متن است

وزن‌ها هزینه ثابت هستند. KV cache (کش کلید و مقدار) هزینه متغیر است. هر توکن در پنجره متن (context window)، بردارهای کلید و مقدار خود را برای هر لایه حفظ می‌کند، بنابراین حجم کش به‌صورت خطی با پنجره‌ای که مجاز می‌دانید افزایش می‌یابد. این فضا هنگام بارگذاری مدل برای کل پنجره تخصیص می‌یابد، نه با پر شدن گفتگو؛ به همین دلیل است که یک پنجره طولانی، حتی با یک پرامپت تک‌کلمه‌ای، حافظه مصرف می‌کند.

KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16:  2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per token

آن اعداد مدل از پیکربندی خود مدل می‌آیند: 36 لایه، 8 هد کلید/مقدار، و ابعاد هد 128. ollama show معماری و تعداد پارامترها را به شما می‌دهد و config.json مدل در Hugging Face بقیه اطلاعات را در اختیارتان می‌گذارد. هزینه هر توکن را در اندازه پنجره ضرب کنید تا متوجه شوید که کش دیگر یک خطای گرد کردن ساده نیست.

[
  {
    "label": "4k",
    "kv_cache_gb": 0.6,
    "floor_ram_gb": 5.8
  },
  {
    "label": "8k",
    "kv_cache_gb": 1.21,
    "floor_ram_gb": 6.4
  },
  {
    "label": "16k",
    "kv_cache_gb": 2.42,
    "floor_ram_gb": 7.6
  },
  {
    "label": "32k",
    "kv_cache_gb": 4.83,
    "floor_ram_gb": 10
  }
]

در پنجره پیش‌فرض 4096 توکنی Ollama، این کش 0.6 گیگابایت به وزن‌ها اضافه می‌کند. اگر پنجره را به 32k افزایش دهید، کش به‌تنهایی به 4.83 گیگابایت می‌رسد که تقریباً معادل حافظه مورد نیاز برای وزن‌های کوانتیزه شده است و کف حافظه برای کل مدل به 10 گیگابایت می‌رسد. به این مقدار «کف» می‌گوییم، زیرا بافرهای محاسباتی و سیستم‌عامل نیز روی آن قرار می‌گیرند. پس از بارگذاری مدل، عدد واقعی را از ستون SIZE در ollama ps بخوانید.

هنگامی که Ollama را به‌عنوان یک سرویس اجرا می‌کنید، پنجره در سطح سرور تنظیم می‌شود، نه برای هر درخواست:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

برای نصب از طریق systemd، آن را در یک فایل drop-in قرار دهید:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

با sudo systemctl restart ollama سرویس را مجدداً راه‌اندازی کنید، سپس ستون CONTEXT در ollama ps را بررسی کنید تا تأیید کنید مدل در حال اجرا با چه پنجره‌ای بارگذاری شده است. OLLAMA_KV_CACHE_TYPE خودِ کش را کوانتیزه می‌کند: f16 مقدار پیش‌فرض است، q8_0 حدود نصف حافظه f16 را مصرف می‌کند و q4_0 حدود یک‌چهارم آن را. این یک گزینه سراسری است، بنابراین تمام مدل‌های موجود روی آن سرور از همین تنظیمات پیروی می‌کنند. در یک سیستم کوچک با پنجره طولانی، نصف کردن کش بیش از هر تغییر دیگری حافظه آزاد می‌کند. تنظیم num_ctx و هزینه‌های آن جزئیات مربوط به خود پنجره را پوشش می‌دهد. همچنین، کش به‌ازای هر اسلات درخواست همزمان اندازه‌گیری می‌شود، نه یک‌بار برای کل سرور؛ بنابراین اجازه دادن به Ollama برای پاسخگویی به دو پرامپت همزمان، عددی را که محاسبه کرده‌اید دوبرابر می‌کند. این همان منطق ریاضی پشت انتخاب تعداد اسلات موازی و محدودیت صف است.

چه مدل‌هایی روی VPS با 8، 16 یا 32 گیگابایت رم اجرا می‌شوند

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

8 گیگابایت. یک مدل 4B با کوانتایز q4_K_M حجمی معادل 2.6 گیگابایت دارد و فضای کافی برای یک پنجره متنی (context window) طولانی باقی می‌گذارد. یک مدل 8B با کوانتایز q4_K_M با پنجره پیش‌فرض 4k و فضای خالی بسیار کم، روی این سیستم جا می‌شود. برای مدل 8B با پنجره 32k روی این سیستم برنامه‌ریزی نکنید، زیرا حداقل رم مورد نیاز یعنی 10 گیگابایت، از ظرفیت این سرور فراتر می‌رود.

16 گیگابایت. مدل 8B با کوانتایز q4_K_M و پنجره 16k یا 32k به راحتی اجرا می‌شود. مدل 14B با کوانتایز q4_K_M دارای 9.3 گیگابایت وزن است و با یک پنجره متنی متوسط اجرا می‌شود. مدل 8B با کوانتایز q8_0 حجمی معادل 8.9 گیگابایت دارد، بنابراین این مدل نیز جا می‌شود. مقایسه این دو مدل با پرامپت‌های خودتان، مفیدترین کاری است که می‌توانید در این زمینه انجام دهید.

32 گیگابایت. مدل 14B با کوانتایز q8_0 (16 گیگابایت) و مدل 32B با کوانتایز q4_K_M (20 گیگابایت) هر دو بارگذاری می‌شوند. مدل 32B با پنجره متنی بزرگ، رم را تا نزدیکی سقف اشغال می‌کند، بنابراین به جای فرض کردن، ollama ps را مانیتور کنید.

کدام بخش از کوانتیزاسیون زودتر دچار افت کیفیت می‌شود

خطای کوانتیزاسیون به‌طور یکنواخت در عملکرد مدل پخش نمی‌شود. روانی متن (Fluency) بیشترین مقاومت را دارد و دقیقاً به همین دلیل است که تشخیص آسیب ناشی از آن دشوار است: مدلی که به‌شدت کوانتیزه شده باشد، همچنان جملات تمیزی می‌نویسد. دقت (Precision) اولین چیزی است که از دست می‌رود. بازیابی دقیق یک شماره نسخه، امضای یک API یا یک تاریخ. زنجیره‌های طولانی استدلال، جایی که یک خطای کوچک در مرحله دوم به پاسخی اشتباه در مرحله هشتم تبدیل می‌شود. فرمت‌های خروجی سخت‌گیرانه، جایی که یک براکت اشتباه باعث شکست در فراخوانی ابزار (tool call) می‌شود.

مورد آخر، آزمون عملی است. وقتی مدل باید خروجی JSON بازگرداند که کد شما آن را پارس می‌کند، آسیب کوانتیزاسیون به‌صورت خطای پارس ظاهر می‌شود، نه به‌صورت متنی که کمی ضعیف‌تر شده است؛ بنابراین همان روز متوجه آن می‌شوید. یک عامل کدنویسی (coding agent) سخت‌گیرانه‌ترین نسخه از این آزمون است، زیرا مدل را وادار به فراخوانی‌های پیاپی ابزار می‌کند؛ بنابراین اتصال یک عامل به سرور Ollama، کوانتیزاسیون بیش‌ازحد تهاجمی را در عرض یک بعدازظهر آشکار خواهد کرد.

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

چه زمانی استفاده از q8_0 یا fp16 ارزش مصرف RAM را دارد

زمانی که حافظه واقعاً مازاد دارید و ماهیت وظیفه به‌گونه‌ای است که خطاهای کوچک را برنمی‌تابد، از q8_0 استفاده کنید؛ مواردی مانند استخراج ساختاریافته داده، فراخوانی ابزار (tool calling) و کدی که باید کامپایل شود. در اینجا شما در حال خرید بیمه هستید، نه دستیابی به مدلی که به‌طور محسوس هوشمندتر باشد.

فقط به دو دلیل از fp16 استفاده کنید. یا خودتان در حال کوانتایز کردن مدل هستید و به فایل منبع نیاز دارید، یا در حال اندازه‌گیری یک مبنا (baseline) هستید تا متوجه شوید نسخه 4-bit شما چه میزان از دقت را فدا کرده است. سرویس‌دهی از fp16 سه برابر بیشتر از q4_K_M حافظه مصرف می‌کند، در حالی که تفاوت آن برای اکثر افراد در تست کور (blind test) قابل تشخیص نیست؛ همچنین در سیستم‌های مبتنی بر CPU، این کار نرخ تولید توکن شما را به یک‌سوم کاهش می‌دهد.

قانون قوی‌تر در یک بودجه حافظه ثابت این است: یک مدل بزرگ‌تر با کوانتایز q4_K_M معمولاً عملکرد بهتری نسبت به یک مدل کوچک‌تر با q8_0 دارد. 9.3 گیگابایت وزن‌های مدل 14B در مقابل 8.9 گیگابایت وزن‌های مدل 8B، تقریباً مقدار یکسانی از RAM (حافظه دسترسی تصادفی) اشغال می‌کنند و مدل بزرگ‌تر دانش بیشتری دارد. به‌جای اعتماد محض، این موضوع را با پرامپت‌های خودتان تست کنید.

استنتاج فقط با CPU توسط پهنای باند حافظه محدود می‌شود

بیشتر پلن‌های VPS فاقد GPU هستند، بنابراین مدل در حافظه سیستم روی CPU میزبان اجرا می‌شود. در این حالت، تولید متن به‌جای محاسبات، توسط پهنای باند حافظه محدود می‌شود، زیرا تولید هر توکن مستلزم خواندن تمامی وزن‌ها در هر مرحله است. این موضوع سقفی ایجاد می‌کند که هیچ ارتباطی به تعداد هسته‌های خریداری‌شده ندارد.

tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB  =  9.6 tokens/s    qwen3 8B q4_K_M
50 GB/s / 8.9 GB  =  5.6 tokens/s    qwen3 8B q8_0
50 GB/s / 16 GB   =  3.1 tokens/s    qwen3 8B fp16

50 گیگابایت بر ثانیه تقریباً عدد تئوری برای یک سیستم میزبان با حافظه دوکاناله DDR4-3200 است. سهم شما از این مقدار کمتر است، زیرا یک VPS این گذرگاه را با تمام مستأجران دیگر روی آن ماشین به اشتراک می‌گذارد؛ بنابراین با این اعداد به‌عنوان سقفی برخورد کنید که هیچ‌کس به آن نمی‌رسد. نکته کاربردی این است: روی CPU، نصف کردن بیت‌های هر وزن، تقریباً نرخ تولید توکن را دو برابر می‌کند. کوانتایزیشن (Quantization) بزرگ‌ترین اهرم سرعت در سیستمی است که GPU ندارد. اینکه آیا نرخ نهایی برای شما قابل‌تحمل است یا خیر، به مدل بستگی دارد و Nemotron 3.5 Lightning روی یک VPS این تقسیم‌بندی را برای یک ساخت، تگ و مقدار RAM مشخص بررسی می‌کند. نیمه دیگر زمان انتظار به میزان متنی که مدل تصمیم به نوشتن آن می‌گیرد بستگی دارد؛ چرا که با سرعت 10 توکن در ثانیه، یک پاسخ 600 توکنی یک دقیقه کامل زمان می‌برد، بنابراین محدود کردن پاسخ با num_predict اغلب زمان انتظار بیشتری نسبت به کاهش یک پله‌ای دقت (precision) برای شما ذخیره می‌کند.

پردازش پرامپت رفتار متفاوتی دارد. خواندن یک پرامپت طولانی بیشتر محدود به توان پردازشی (compute bound) است تا پهنای باند، بنابراین هسته‌های اضافی در اینجا کمک می‌کنند، در حالی که برای سرعت تولید متن تقریباً تأثیری ندارند. سیستمی که یک پرامپت 4k را سریع دریافت می‌کند و سپس به‌کندی پاسخ می‌دهد، رفتار طبیعی دارد.

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

کوانتایز کردن مدل توسط خودتان

Ollama می‌تواند یک مدل کوانتایز شده را از یک منبع fp16 یا fp32 بسازد. این کار زمانی اهمیت دارد که شما مدلی را fine-tune کرده‌اید و هیچ تگ کتابخانه‌ای برای آن وجود ندارد. یک Modelfile را به سمت وزن‌های کوانتایز نشده هدایت کنید:

FROM /path/to/my/model/f16

سپس آن را build کرده و تأیید کنید:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize از q8_0، q4_K_S و q4_K_M پشتیبانی می‌کند. در اینجا هیچ گزینه‌ای برای q6_K یا q5_K_M وجود ندارد، بنابراین برای این موارد باید با استفاده از ابزار اختصاصی llama.cpp کوانتایز کرده و فایل GGUF نهایی را import کنید. آن مسیر import چالش خاص خود را دارد؛ عدم تطابق در قالب چت (chat template) که باعث می‌شود مدل پاسخ‌های نامفهوم تولید کند، که در import کردن یک فایل GGUF به Ollama به آن پرداخته شده است. خط quantization از ollama show روشی است که با آن تأیید می‌کنید build دقیقاً همان کاری را انجام داده که شما درخواست کرده‌اید.

آنچه هنگام بروز خطا مشاهده خواهید کرد

همه چیز روی CPU اجرا می‌شود در حالی که انتظار داشتید روی GPU باشد. ستون PROCESSOR را بخوانید:

ollama ps

این دستور 100% GPU، 100% CPU یا حالتی ترکیبی مانند 48%/52% CPU/GPU را چاپ می‌کند. حالت ترکیبی به این معناست که وزن‌ها به همراه KV cache در VRAM (حافظه ویدیویی کارت گرافیک) جا نشده‌اند، بنابراین بخشی از مدل در حافظه سیستم قرار گرفته است. در این حالت، سرعت به نرخ اجرای صرفاً روی CPU نزدیک می‌شود، زیرا تولید هر توکن منتظر بخش کندتر می‌ماند. پنجره کانتکست (context window) را کاهش دهید، کش را کوانتیزه کنید یا نسخه کوچک‌تری از مدل را دریافت کنید. افزودن هسته‌های پردازشی کمکی نخواهد کرد.

مدل هنگام بارگذاری متوقف (kill) می‌شود. کرنل و لاگ سرویس را بررسی کنید:

sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50

خطی که شامل Out of memory: Killed process باشد به این معناست که مجموع وزن‌ها، KV cache و بافرها از حافظه موجود در دستگاه فراتر رفته است. در یک VPS که swap برای آن پیکربندی نشده باشد، ممکن است کل سیستم پیش از ظاهر شدن این خط، برای چند ثانیه کاملاً قفل شود.

پاسخ‌ها بدتر شده‌اند در حالی که تغییری ایجاد نکرده‌اید. دو نسخه از یک مدل می‌توانند در ollama ls با تگ‌های متفاوت کنار هم قرار بگیرند، و اسکریپتی که نام بدون پسوند را دریافت می‌کند، به هر نسخه‌ای که کتابخانه در حال حاضر به آن اشاره دارد، متصل می‌شود. دستور ollama show را برای تگ دقیقی که کلاینت شما درخواست می‌کند اجرا کنید و خط quantization را بخوانید؛ به جای آنکه به نام موجود در فایل پیکربندی خود اعتماد کنید.

FAQ

کدام کوانتیزاسیون Ollama را باید pull کنم؟

با q4_K_M شروع کنید. این همان تگی است که کتابخانه Ollama به‌صورت پیش‌فرض برای اکثر مدل‌ها ارائه می‌دهد، بنابراین ollama pull qwen3:8b و ollama pull qwen3:8b-q4_K_M فایل یکسانی را دریافت می‌کنند. تنها زمانی به سراغ q8_0 بروید که حافظه کافی در اختیار دارید و ماهیت کار به‌گونه‌ای است که خطاهای کوچک در آن تأثیر منفی می‌گذارند، مانند فراخوانی ابزار (tool calling) یا خروجی‌های ساختاریافته JSON. هنگامی که بودجه حافظه محدود است، معمولاً یک مدل بزرگ‌تر با کوانتیزاسیون q4_K_M عملکرد بهتری نسبت به یک مدل کوچک‌تر با q8_0 دارد؛ بنابراین پیش از صرف رم برای دقت بالاتر، این ترکیب را تست کنید.

آیا q4_K_M واقعاً به معنای چهار بیت برای هر وزن است؟

خیر. در مدل Llama 3.1 8B این مقدار 4.89 بیت برای هر وزن اندازه‌گیری شده است، زیرا هر بلوک از وزن‌ها مقیاس (scale) مخصوص به خود را ذخیره می‌کند و حساس‌ترین تنسورها به نوع داده‌ای دقیق‌تری ارتقا می‌یابند. به همین دلیل، Q8_0 نیز به جای هشت بیت، 8.5 بیت را اشغال می‌کند. هنگام تخمین، از عدد اندازه‌گیری‌شده استفاده کنید: تعداد پارامترها ضرب‌در بیت برای هر وزن، تقسیم بر هشت، حجم فایل را به بایت به شما می‌دهد.

یک مدل 8B روی VPS که فقط CPU دارد به چه مقدار رم نیاز دارد؟

وزن‌ها، حافظه پنهان KV (KV cache) و فضای خالی (headroom) را با هم جمع کنید. مدل Qwen3 8B با کوانتیزاسیون q4_K_M دارای 5.2 گیگابایت وزن است. در پنجره پیش‌فرض 4096 توکنی، حافظه پنهان 0.6 گیگابایت اضافه می‌کند که مجموع را پیش از در نظر گرفتن بافرهای محاسباتی و سیستم‌عامل، به حدود 5.8 گیگابایت می‌رساند. در پنجره 32k، حافظه پنهان به‌تنهایی 4.83 گیگابایت است. برای پنجره کوتاه روی 8 گیگابایت و برای پنجره طولانی روی 16 گیگابایت رم برنامه‌ریزی کنید.

چرا با وجود داشتن GPU، مدل من با 100% توان CPU اجرا می‌شود؟

دستور ollama ps را اجرا کرده و ستون PROCESSOR را بررسی کنید. مقدار 100% CPU یا تقسیم‌بندی‌هایی مانند 48%/52% CPU/GPU به این معناست که وزن‌ها به همراه حافظه پنهان KV در VRAM جا نشده‌اند و Ollama بخشی یا تمام مدل را در حافظه سیستم قرار داده است. دلیل معمول این اتفاق، بزرگ‌تر بودن پنجره متن (context window) از ظرفیت کارت گرافیک است، زیرا حافظه پنهان هنگام بارگذاری مدل برای کل پنجره تخصیص می‌یابد. پنجره را با OLLAMA_CONTEXT_LENGTH کوچک‌تر کنید، OLLAMA_KV_CACHE_TYPE=q8_0 را برای نصف کردن حافظه پنهان تنظیم کنید یا یک کوانتیزاسیون کوچک‌تر را pull کنید.