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

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

کوانتایزیشن در Ollama هر وزن (weight) در مدل را با تعداد بیت کمتری نسبت به فایلی که در آن آموزش دیده است، ذخیره می‌کند. تگی که به q4_K_M ختم می‌شود، حدود چهار بیت برای هر وزن نگه می‌دارد، در حالی که fp16 شانزده بیت را حفظ می‌کند؛ بنابراین حجم دانلود تقریباً یک‌چهارم است و دستگاه برای تولید هر توکن، یک‌چهارم بایت کمتری می‌خواند. وزن‌ها روی یک شبکه (grid) درشت‌تر گرد می‌شوند و حذف نمی‌شوند؛ در چهار بیت، اکثر مدل‌ها تقریباً مشابه حالت دقت کامل (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.89 بیت را اشغال می‌کند، زیرا مقیاس‌بندی بلوک‌ها (block scales) و تانسورهای ارتقایافته (promoted tensors) هر دو فضای واقعی اشغال می‌کنند. به همین دلیل، Q8_0 نیز به جای هشت بیت، 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 منتشر می‌کند. این‌ها اندازه‌های Qwen3 تا اوت 2026 هستند که از لیست تگ‌ها در صفحه مدل خوانده شده‌اند.

[
  {
    "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 یک مصالحه نیست که کتابخانه با اکراه ارائه دهد. این همان پیش‌فرضی است که upstream انتخاب کرده است، بنابراین برای هر مدلی که خودتان تست نکرده‌اید، تطبیق با آن منطقی‌ترین گام نخست است. همین استدلال، انتخاب تگ‌ها در اجرای Qwen 3 روی یک VPS را هدایت می‌کند.

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

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

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

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 و هزینه‌های آن جزئیات مربوط به خودِ پنجره را به‌طور کامل بررسی می‌کند.

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

وزن‌های مدل، به علاوه KV cache، به علاوه فضای خالی (headroom) برای سیستم‌عامل و هر پردازش دیگری که در حال اجراست. 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 ارزش مصرف رم را دارد

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

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

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

استنتاج فقط با 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 GB/s تقریباً رقم تئوریک برای یک حافظه DDR4-3200 دوکاناله در سیستم میزبان است. سهم شما از این مقدار کمتر است، زیرا در یک VPS، این گذرگاه (bus) بین تمام مستأجران دیگر روی آن ماشین مشترک است؛ بنابراین این اعداد را به عنوان سقفی در نظر بگیرید که هیچ‌کس به آن نمی‌رسد. نکته کاربردی این است که روی CPU، نصف کردن تعداد بیت‌های هر وزن، تقریباً نرخ تولید توکن را دو برابر می‌کند. کوانتایزیشن (Quantization) بزرگترین اهرم افزایش سرعت در سیستمی است که GPU ندارد.

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

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

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

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

FROM /path/to/my/model/f16

سپس آن را بسازید و تأیید کنید:

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 کنید. خط quantization از ollama show روشی است که با آن بررسی می‌کنید آیا عملیات ساخت، دقیقاً همان چیزی بوده که درخواست کرده‌اید یا خیر.

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

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

ollama ps

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

مدل هنگام بارگذاری متوقف (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 را تنظیم کنید تا حافظه پنهان نصف شود، یا یک کوانتیزاسیون کوچک‌تر دریافت کنید.