چگونه مدل‌های GGUF اکنون از طریق هسته‌های ggml اجرا می‌شوند؟

اگر امروز برای اجرای مدل‌های محلی از ابزارهای جانبی استفاده می‌کنید، احتمالاً می‌دانید که جابه‌جایی بین محیط‌های مختلف توسعه و اجرا چقدر خسته‌کننده است. حالا می‌توانید یک مدل GGUF را از هاب انتخاب کنید، آن را با دستور from_pretrained بارگذاری کنید و بلافاصله روی سیستم خود تولید متن را آغاز کنید. این جریان کاری ساده‌شده به دلیل ادغام مستقیم پشتیبانی از مدل‌های کوانتیده (Quantized) GGUF در کتابخانه transformers ممکن شده است. با اجازه دادن به توسعه‌دهندگان برای بارگذاری نقاط بازرسی کم‌حجم با استفاده از APIهای استاندارد PyTorch، اجرای یک مدل زبانی بزرگ (LLM) با کارایی بالا روی یک لپ‌تاپ دیگر نیازی به تغییر بین پشته‌های نرم‌افزاری مجزا ندارد.

این به‌روزرسانی در حالی می‌رسد که استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه خودِ آشپزی و نه دوره‌ی آموزش آشپز — به یک جریان کاری اصلی برای برنامه‌نویسان تبدیل شده است. ابزارهایی مثل Ollama، LM Studio و Jan استفاده از هوش مصنوعی محلی را رایج کردند، اما این‌ها معمولاً به عنوان محیط‌های اجرای مجزا عمل می‌کنند. این ابزارها از موتور استنتاج llama.cpp قدرت می‌گیرند که در کنار پروژه‌هایی مثل MLX، اجرای محلی را به گزینه‌ای کاربردی برای استفاده روزمره تبدیل کرده است. یک مثال اخیر از این قابلیت توسط ژولین شوموند در ۲۴ آوریل ۲۰۲۶ به اشتراک گذاشته شد؛ او اجرای مدل Qwen3.6 27B را درون یک عامل کدنویسی Pi از طریق llama.cpp روی یک MacBook Pro نمایش داد و اشاره کرد که برای وظایف غیربدیهی روی پایگاه‌های کد Hugging Face، این تجربه بسیار نزدیک به استفاده از Claude Opus است. این رویکرد با روند کاهش هزینه‌های استنتاج در عامل‌های هوش مصنوعی از طریق مدل‌های کوچک‌تر همسو است که بهره‌وری را در محیط‌های محلی افزایش می‌دهد.

هگینگ‌فیس با آوردن پشتیبانی GGUF به هسته کتابخانه خود، شکاف بین تعریف مدل و اجرای محلی را پر می‌کند. این اقدام در راستای روند گسترده‌تری برای دسترس‌پذیرتر کردن ساختار داخلی مدل‌هاست، مشابه همان‌طور که پیش‌تر بررسی کردیم که چگونه Transformer Explainer سازوکارهای داخلی GPT-2 را بصری‌سازی می‌کند. برای درک عمیق‌تر این ساختارها، می‌توان به مبانی مدل‌های ترنسفورمر و نحوه درک زمینه در مدل‌های مدرن اشاره کرد که موتور محرک این فناوری‌هاست.

سازوکار ادغام GGUF

برای رسیدن به عملکردی مشابه با llama.cpp، هگینگ‌فیس صرفاً فایل‌ها را وارد نمی‌کند؛ بلکه از هسته‌های (Kernels) زیربنایی ggml از طریق یک کتابخانه اختصاصی هسته‌ها استفاده می‌کند. این رویکرد سربار معمول در تابع generate را کاهش می‌دهد. فرمت GGUF که توسط تیم llama.cpp توسعه یافته، استانداردی بسیار رایج برای استنتاج محلی است. تیم توسعه‌دهنده، نقاط بازرسی کوانتیده را تحت نام ggml-org در هاب به اشتراک می‌گذارند، در حالی که ناشرانی مانند Unsloth، LM Studio Community و bartowski نقاط بازرسی آماده‌ای را در کوانتش‌های مختلف ارائه می‌دهند. این مدل‌های GGUF تاکنون میلیون‌ها بار دانلود شده‌اند.

تمرکز اولیه این قابلیت روی استنتاج محلی در سخت‌افزار Apple Silicon و به‌طور خاص هدف قرار دادن معماری Qwen3.5 است. اهمیت فرمت GGUF در اینجا حیاتی است زیرا وزن‌های مدل و متادیتا — شامل اطلاعات توکن‌ساز (Tokenizer) و یک قالب چت اختیاری — را در یک فایل واحد بسته‌بندی می‌کند.

موازنه در کوانتش

کوانتش (Quantization) — شبیه فشرده‌سازی یک عکس برای اشغال فضای کمتر بدون از دست دادن زیاد کیفیت — به کاربران اجازه می‌دهد مقدار کمی از دقت را فدای کاهش شدید مصرف حافظه کنند. نسخه‌هایی مثل Q4_K_M از دقت‌های ترکیبی تانسورها استفاده می‌کنند؛ به این معنا که بیشتر وزن‌ها ۴ بیتی هستند اما تانسورهای حساس در دقت بالاتر نگه داشته می‌شوند. برای مثال، مدل Qwen3.5-4B از شرکت Unsloth تغییرات شدیدی در اندازه بر اساس سطح کوانتش نشان می‌دهد:

• BF16 (مرجع بدون کوانتش): ۸.۴۲ گیگابایت
• Q6_K (دقت بیشتر نسبت به نسخه‌های کوچک‌تر): ۳.۵۳ گیگابایت
• Q5_K_M (حد وسط بین اندازه و دقت): ۳.۱۴ گیگابایت
• Q4_K_M (یک نقطه شروع کاربردی برای استنتاج محلی): ۲.۷۴ گیگابایت

هگینگ‌فیس پیشنهاد می‌کند برای شروع از نسخه Q4_K_M به عنوان یک خط پایه کاربردی برای اکثر ماشین‌های محلی استفاده کنید. کاربران سپس می‌توانند در صورت در دسترس بودن حافظه بیشتر، نسخه‌های Q5_K_M یا Q6_K را امتحان کنند. اگرچه کوانتش‌های تهاجمی‌تر به جا دادن مدل‌های بزرگ‌تر در حافظه کمک می‌کند، اما موازنه کیفیت به مدل خاص و تسک مورد نظر بستگی دارد؛ کاربران باید آن را روی کاری که قصد دارند مدل انجام دهد ارزیابی کنند. مستندات GGUF در هاب جزئیات بیشتری درباره انواع کوانتش‌های موجود ارائه می‌دهد. این بهینه‌سازی‌ها یادآور موفقیت مدل‌هایی مانند ZGCM-1 است که توانست با پارامترهای کمتر، بر مدل‌های بسیار بزرگ‌تر غلبه کند.

پیاده‌سازی فنی و راه‌اندازی

برای استفاده از این ویژگی، توسعه‌دهندگان به یک مک با تراشه اپل (Apple Silicon) و نسخه‌ای از PyTorch نیاز دارند که توسط بیلد‌های منتشر شده‌ی هسته ggml-quantization پشتیبانی شود (معمولاً دو نسخه اخیر PyTorch). راه‌اندازی مستلزم نصب آخرین نسخه transformers از شاخه اصلی گیت‌هاب و کتابخانه kernels است:

pip install -U "git+https://github.com/huggingface/transformers.git" kernels

بارگذاری مدل اکنون یک فرآیند تک‌مرحله‌ای است. با ارسال model_id هاب و نام فایل خاص .gguf به تابع from_pretrained از طریق آرگومان gguf_file، کتابخانه به‌طور خودکار هسته‌های لایه سازگار ggml/Metal را بارگذاری می‌کند. وقتی وزن‌ها به‌صورت بسته‌بندی شده روی Metal می‌مانند، transformers از ggml-org/ggml-attn به عنوان پیاده‌سازی Attention استفاده می‌کند. اگر این هسته قابل دریافت نباشد، سیستم با یک هشدار به حالت "sdpa" (Scaled Dot Product Attention) باز می‌گردد. کاربران می‌توانند با ارسال صریح attn_implementation="sdpa" این بازگشت را اجبار کنند.

بدون یک هسته کوانتش سازگار، لودر به حالت دکوانتیده کردن (Dequantizing) مدل باز می‌گردد که حافظه بسیار بیشتری مصرف می‌کند. برای کسانی که از API استاندارد استفاده می‌کنند، فرآیند به این شکل است:

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "unsloth/Qwen3.5-4B-GGUF"
filename = "Qwen3.5-4B-Q4_K_M.gguf"

tokenizer = AutoTokenizer.from_pretrained(model_id, gguf_file=filename)
model = AutoModelForCausalLM.from_pretrained(model_id, gguf_file=filename)

بنچمارک‌های عملکرد

در تست‌های رودررو روی MacBook Pro M2 Max (۳۲ گیگابایت حافظه یکپارچه، macOS 26.6، PyTorch 2.12.1، kernels 0.17.0)، عملکرد transformers تقریباً با llama.cpp برابر بود. این بنچمارک‌ها نرخ تولید توکن را برای ۱۲۸ توکن رمزگشایی شده از یک پرامپت ۱۲ توکنی اندازه‌گیری کردند.

در این مقایسه از ابزار llama-bench (بیلد 5f55650a7، ریلیز b10200، بک‌اند Metal از ggml 0.18.0) با دستور llama-bench -m <file> -p 0 -n 128 -r 3 استفاده شد. این ابزار مقدار tg128 را گزارش می‌کند که میانگین نرخ تولید توکن در سه تکرار، بدون احتساب پردازش پرامپت است. در مقابل، اندازه‌گیری‌های transformers شامل مرحله پیش‌پُرکردن (Prefill) است و بهترین نتیجه از سه اجرای گرم‌شده (Warmed runs) را نشان می‌دهد.

با وجود این سربار اضافی، عملکرد در مدل‌های متراکم کوچک، مدل‌های متراکم بزرگتر و معماری‌های ترکیب خبره‌ها (MoE) نزدیک باقی ماند. برای اطمینان از دقت، اسکریپت بنچمارک شامل یک وقفه ۹۰ ثانیه‌ای بین اجراها بود تا دستگاه خنک شود، زیرا اجراهای پشت‌سر‌هم می‌توانند عملکرد را ۱۰٪ یا بیشتر کاهش دهند. منطق بنچمارک از یک پرامپت ساده استفاده کرد: "The capital of France is Paris. The capital of Germany is" و ۱۲۸ توکن را با do_sample=False تولید کرد.

بهینه‌سازی حلقه تولید

بهبودهای عملکردی از دو مسیر اصلی حاصل شده است: هسته‌های تخصصی و یک حلقه تولید سبک‌تر. تیم توسعه چندین هسته خاص ggml را برای مدیریت کارهای سنگین روی GPU پیاده کرده است:

• ggml-quantization: خواندن وزن‌های کوانتیده بسته‌بندی شده برای عملیات ماتریسی، از جمله خبره‌های منتخب در یک مدل MoE. این هسته از باز کردن کل ماتریس وزن‌ها قبل از هر عملیات رمزگشایی جلوگیری می‌کند.
• ggml-norm: ادغام عملیات نرمال‌سازی، از جمله RMSNorm متمرکز-صفر که توسط Qwen3.5 و Qwen3.8 استفاده می‌شود.
• ggml-attn: ارائه Metal flash attention متعلق به ggml برای پردازش پرامپت و رمزگشایی توکن.
• ggml-gated-delta-net: شتاب‌دهی به شبکه دلتای گیت‌شده که در لایه‌های توجه خطی معماری‌های هیبریدی Qwen3.5 و Qwen3.8 استفاده می‌شود.
• topk: یک پیاده‌سازی سفارشی Metal برای رفع گلوگاه‌های مسیریابی در MoE از طریق ترکیب softmax و مسیریابی top-k.

فراتر از هسته‌ها، هگینگ‌فیس همگام‌سازی CPU-GPU را بهینه کرد تا اطمینان حاصل شود که GPU در حالی که CPU عملیات بعدی را زمان‌بندی می‌کند، مشغول بماند. دو تغییر خاص در generate باعث بهبود تمام مدل‌های transformers شد:

۱. بهینه‌سازی ماسک توجه (#48814): برای ورودی‌های decoder-only پشتیبانی شده بدون پدینگ، ماسک پدینگ تمام-یک در ابتدای تولید حذف می‌شود. این کار از بررسی مکرر ماسک توسط کد توجه جلوگیری می‌کند، در حالی که توجه علی (Causal attention) همچنان حفظ می‌شود.
۲. بررسی‌های توقف به تعویق افتاده (#47975): تصمیم توقف به‌طور نامتقارن کپی شده و در مرحله بعد مصرف می‌شود. این به CPU اجازه می‌دهد در حالی که GPU در حال اجراست، به زمان‌بندی کارها ادامه دهد. این رویکرد برای توکن‌های استریمینگ نیز اعمال می‌شود و هر مرحله اضافی پس از شرط توقف از نتیجه حذف می‌گردد.

این تغییرات مکمل کار روی هسته‌ها هستند: هسته‌ها هزینه یک عملیات را کاهش می‌دهند، در حالی که نقاط همگام‌سازی کمتر اجازه می‌دهد زمان‌بندی CPU و اجرای GPU هم‌پوشانی داشته باشند.

جریان‌های کاری توسعه‌دهندگان و انعطاف‌پذیری

این ادغام قرار نیست جایگزین llama.cpp شود، که همچنان موتور توصیه شده برای زمانی است که اولویت استنتاج محلی کارآمد به دلیل محیط اجرای اختصاصی، مدیریت حافظه و پشتیبانی گسترده سخت‌افزاری است. در عوض، این قابلیت یک محیط بومی PyTorch برای نقاط بازرسی GGUF فراهم می‌کند.

توسعه‌دهندگان اکنون می‌توانند از مدل‌های GGUF برای موارد زیر استفاده کنند:
۱. آزمایش در پایتون: استفاده از ابزارهای PyTorch برای بررسی فعال‌سازهای میانی با Hookها یا تغییر مسیر forward مدل.
۲. نمونه‌سازی (Prototype): ایجاد لایه‌های سفارشی با استفاده از جریان‌های کاری آشنای PyTorch.
۳. ارزیابی کیفیت: استفاده از جریان‌های ارزیابی موجود در transformers برای اندازه‌گیری کیفیت نقاط بازرسی کوانتیده.
۴. اعتبارسنجی تبدیل‌ها: مقایسه نقطه بازرسی اصلی و تبدیل GGUF آن برای بررسی خطای کوانتش.
۵. امتحان ایده‌های جدید رمزگشایی: پیاده‌سازی پردازشگرهای لاجیت (Logits Processors) و معیارهای توقف سفارشی در generate یا نوشتن یک حلقه تولید سفارشی در پایتون.
۶. تنظیم دقیق (Fine-tune): دکوانتیده کردن وزن‌ها و ادامه با یک جریان آموزشی استاندارد با استفاده از GgufConfig(dequantize=True) و dtype=torch.bfloat16.

سرویس‌دهی و سازگاری

برای کسانی که به API نیاز دارند، دستور transformers serve اکنون یک نقطه اتصال (Endpoint) سازگار با OpenAI برای مدل‌های GGUF فراهم می‌کند. این به کاربران اجازه می‌دهد کلاینت‌هایی مانند Jan یا Pi را به بک‌اندی متصل کنند که روی مک خودشان اجرا می‌شود.

برای راه‌اندازی این سیستم، افزونه serving را نصب کنید:
pip install -U "transformers[serving] @ git+https://github.com/huggingface/transformers.git" kernels

دستور transformers serve "unsloth/Qwen3.5-4B-GGUF:Qwen3.5-4B-Q4_K_M.gguf" فرآیند بارگذاری را مدیریت می‌کند. فرمت آرگومان <model_id>:<filename>.gguf به کاربران اجازه می‌دهد یک کوانتش خاص را از مخزنی که شامل چندین نسخه است انتخاب کنند.

برای مدل‌هایی با قالب‌های چت که از تفکر (Thinking) پشتیبانی می‌کنند، سرور شامل گزینه‌های استدلال است: --reasoning off برای نادیده گرفتن، --reasoning on برای فعال‌سازی، یا حالت پیش‌فرض --reasoning auto. برای اتصال یک کلاینت، کاربران می‌توانند Base URL را روی http://localhost:8000/v1 و Model ID را روی مسیر خاص GGUF (مثلاً unsloth/Qwen3.5-4B-GGUF:Qwen3.5-4B-Q4_K_M.gguf) تنظیم کنند.

محدودیت‌های فعلی و مسیر آینده

هنوز محدودیت‌هایی در این پیاده‌سازی وجود دارد. مسیر استنتاج فشرده (Packed inference) در حال حاضر محدود به MPS (Metal Performance Shaders) است. در حالی که وارد کردن GGUF از طریق دکوانتیده کردن روی دستگاه‌های دیگر کار می‌کند، اما هسته‌های فشرده با کارایی بالا در دسترس نیستند.

علاوه بر این، دسته‌بندی (Batching) و پدینگ هنوز در حال اصلاح هستند. ورودی‌های بدون پدینگ از بهینه‌سازی‌های جدید ماسک بهره می‌برند، اما دسته‌های پدینگ‌شده ممکن است عملکرد پایین‌تری داشته باشند. تیم هدف دارد این کار را به generate_batch روی MPS گسترش دهد. پشتیبانی از معماری‌ها نیز محدود است و در حال حاضر معماری‌های متراکم و MoE مدل Qwen3.5 و همچنین نقاط بازرسی سازگار Qwen3.8 را پوشش می‌دهد. افزودن پشتیبانی برای سایر معماری‌ها نسبتاً ساده است و پوشش به‌تدریج گسترش خواهد یافت.

این حرکت نشان‌دهنده چرخش به سمت یک اکوسیستم هوش مصنوعی یکپارچه‌تر است. با آوردن هسته‌های ggml به PyTorch، هگینگ‌فیس می‌تواند مدل‌هایی را شتاب دهد که llama.cpp هنوز پشتیبانی نمی‌کند، از جمله معماری‌های تحقیقاتی جدید و نسخه‌های سفارشی. این فرصت فراتر از متن است؛ مدل‌های بینایی کامپیوتر، صوتی و چندوجهی (Multimodal) در نهایت می‌توانند از هسته‌های سازگار توجه، نرمال‌سازی و ضرب ماتریسی بدون نیاز به پیاده‌سازی کامل llama.cpp استفاده کنند. هر معماری همچنان به ادغام و اعتبارسنجی نیاز دارد، اما مثال‌های فعلی GGUF برای تولید متن، زیربنای این مسیر را فراهم کرده‌اند.

گام بعدی شما

• اگر مک با تراشه M دارید، کتابخانه kernels را نصب کنید و مدل‌های Qwen3.5-GGUF را مستقیماً در محیط پایتون تست کنید.
• برای کاهش مصرف VRAM، تفاوت عملکرد بین نسخه‌های Q4_K_M و Q6_K را روی تسک‌های خاص خود بسنجید.
• از دستور transformers serve برای تبدیل لپ‌تاپ خود به یک سرور مدل محلی سازگار با OpenAI استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.