> GGUF مقابل safetensors — بيئة التشغيل هي من تقرر، لا الصيغة▋

يُكمل DuckDuckGo تلقائيًا gguf vs safetensors وكأنها مباراة قفص بين امتدادَي ملفين. إنها بوابة تحقق. تختر GGUF فيُفتح رفٌّ من بيئات التشغيل — llama.cpp وOllama وLM Studio وJan. وتختر safetensors فيُفتح رف مختلف — transformers وvLLM وComfyUI. الصيغة هي قائمة الأبواب التي ستُفتح؛ وكل ما عداها يتبع. الكذبة التي يرفضها هذا المقال: أن المواجهة تُحسم بأرقام سرعة لم يحاذِها أحد على الجهاز نفسه. ما يمنحك إياه السجل مجانًا — وما تتخطاه معظم الحجج — هو وزن كل حاوية، وأين يمكن فتحها أصلًا.

بين ماذا تختار فعلًا؟

GGUF حاوية من ملف واحد بناها مؤلفو llama.cpp، والضغط مخبوز فيها لكل موتر — سلَّم الضغط الذي يتجادل حوله الجميع لا يوجد إلا داخل هذه الصيغة. ملف واحد يحمل الأوزان والمُرمِّز وقالب المحادثة: الملف هو التوزيعة. أما safetensors فحاوية تسلسل — ترويسة JSON زائد بايتات الموتر الخام — ويحمل الدقة التي شحنها مستودع التدريب، عادة BF16 أو FP16. لا يضغط؛ يخزّن.

اسم safetensors جاء من وظيفته الوحيدة: ضمان ألا يُخلَّل أحدٌ عند تحميل النموذج عبر pickle. فبايثون، عبر pickle، ينفّذ شيفرة عند فك التغليف؛ وsafetensors لا ينفّذ شيئًا — هذه هي حجة الأمان كلها، ولهذا اعتمدتها منظومة Hugging Face معيارًا.

زِن النموذج نفسه في كل حاوية وتظهر الفلسفات في البايتات. في 14 أكتوبر 2026، شُحن Qwen3-0.6B نفسه هكذا: GGUF ‏Q4_K_M: 396,705,472 بايت (397 MB) · GGUF ‏BF16: 1,198,182,848 بايت (1.20 GB) · safetensors ‏BF16: 1,503,300,328 بايت (1.50 GB). الحاوية المضغوطة تحوي ربع ما تحويه كاملة الدقة لأنها تحتفظ بربع الدقة — وكل رقم من هذه الأرقام يبعد عن طرفيتك أمرَ curl -I واحدًا، بلا منصة اختبار. أما هل تكلّفك الدقة الناقصة جودةً، فهذا سؤال صدق لا تجيب عنه البايتات؛ مقال مستويات الضغط يغطي ما تتنازل عنه كل درجة.

الصيغة ليست تفضيلًا. إنها قائمة بيئات التشغيل التي ستفتح ملفك.

ماذا تقول البايتات؟

القاعدة الصادقة لمقال يقرأ السجل: أرقام السجل وحدها، منسوبة، بلا تمثيل للاختبارات. الجدول نموذج واحد وثلاث حاويات وبايتات دقيقة كما شُحنت — تحقق منها بنفسك قبل أن تثق بأي منها.

الحاوية	الدقة	البايتات كما شُحنت	النسبة من كاملة الدقة
GGUF Q4_K_M	مضغوط 4 بت	396,705,472 (397 MB)	26%
GGUF BF16	كاملة، تغليف llama.cpp	1,198,182,848 (1.20 GB)	80%
safetensors BF16	كاملة، موترات خام	1,503,300,328 (1.50 GB)	100%

تحقق: curl -sIL https://huggingface.co/unsloth/Qwen3-0.6B-GGUF/resolve/main/Qwen3-0.6B-Q4_K_M.gguf | grep -i content-length → عدد البايتات، اليوم أو أي يوم · الأمر نفسه ضد ملفي BF16 وsafetensors

اقرأ الجدول بالقراءة الصادقة. نسبة 26% هي وعد سلّم الضغط كله: أربعة بتات حيث كانت ستة عشر، على القرص وفي الذاكرة. الفجوة بين صفَّي الدقة الكاملة — 1.20 مقابل 1.50 GB — هي كلفة تغليف لا فيزياء: تغليف BF16 في llama.cpp يخزّن الموترات نفسها أنحف من التفريغ الخام. ما لا تستطيع البايتات قوله هو السرعة أو الجودة؛ عمود tokens-per-second بلا جهاز محاذٍ خلفه ضجيج منتديات، وهذا المقال يرفض طبعه. قراءة llama.cpp مقابل Ollama اصطدمت بالجدار نفسه من جهة المحرك: الملف نفسه، والرياضيات نفسها، وغلاف مختلف.

ما لا يقدر عليه السجل

ثلاثة جدران، مقالة بصراحة. أولًا: الجودة — Q4 مقابل BF16 مقايضة صدق، ولا عدد بايتات يقيسها. ثانيًا: السرعة — أزمنة التحميل والتوكنات في الثانية تعود لاختبار محاذٍ على جهاز مسمّى، وهذا المقال لا يملكه، فلا يطبع شيئًا. ثالثًا: الحجم — نسب البايتات في نموذج 0.6B تبقى بصيغتها عند 70B، لكن الانتظار المطلق الذي ستلمسه عند 70B مقال آخر على عتاد آخر.

أين تعمل كل صيغة فعلًا؟

هذا هو الجزء الذي يحسم فعلًا. GGUF يفتح في llama.cpp وOllama وLM Studio وJan — منظومة المحلية ذات الملف الواحد. vLLM يقرأ GGUF أيضًا، عبر إضافته، على GPU، مع تحفظات. safetensors يفتح في transformers وvLLM أصلًا وComfyUI وأدوات MLX من Apple. التقاطع عند الأطراف مفيد: Ollama — الجهاز المنزلي المبني على محرك GGUF — يشحن مع ذلك runner لـ MLX ليحمّل مستخدمو Apple Silicon أوزانًا مشتقة من safetensors. حتى الجهاز المنزلي يحتاط.

تشغّل أصلًا	تختار صيغتك وحدها	لماذا
Ollama أو LM Studio أو llama-server	GGUF	محركاتها تلتهم GGUF أصلًا؛ الملفات المضغوطة تتسع في أقراص صغيرة
خط Python/transformers	safetensors	from_pretrained هو المسار الأصلي؛ لا خطوة تحويل لصيانتها
vLLM على خادم GPU	safetensors	أصلي، بلا إضافة، بلا تحفظات GGUF — التحفظات نفسها
ComfyUI أو خط صور	safetensors	منظومة الانتشار تتاجر بـ checkpoints صيغة safetensors
قرص صغير وجهاز صغير	GGUF Q4_K_M	397 MB مقابل 1.50 GB للأوزان نفسها

GGUF يجعل الضغط هو الافتراضي؛ safetensors يجعل الدقة الكاملة هي الافتراضي. وهذا الافتراضي وحده معظم القرار.

أيها يجب أن تشغّل؟

افحص ما هو مثبَّت فعلًا قبل فحص أي جدول. إن كانت الآلة تستجيب لـ ollama run فأنت تسكن بلاد GGUF — خذ ملف Q4_K_M وكفَّ عن المنتديات. وإن كان يومك بايثون، أو طبقة خدمتك vLLM، فsafetensors لم يكن اختيارًا قط؛ إنها لغة المنظومة الأم. التحويل بينهما ممكن ولا يستحق العناء شبه دائمًا: كل تحويل هو مكان جديد قد تختلف فيه الأوزان بصمت.

سطر الصدق الإلزامي، على طريقة البيت: قرأت السجل، ولم أشغّله. كل رقم في هذه الصفحة يأتي من الملفات كما شُحنت، مسحوبة صباح يوم نشر المقال — بلا منصة اختبار، بلا تمثيل tokens-per-second. ما يثبته السجل فعلًا هو شكل المقايضة — ربع البايتات للحاوية المضغوطة، وبيئتا تشغيل تكادان لا يتقاطعان، ودقة افتراضية على كل جانب تحسم الأمر بصمت لمعظم الناس. والعنقود كله — runners وصيغ ومستويات ضغط وكل ما يليق — مفهرس في مركز local-LLM.

ما من أحد بدّل الصيغة من أجل السرعة قط. بدّل الناس بيئة التشغيل من أجل ميزة، وجاءت الصيغة معها كالتذكرة.

إذن، سؤالان يعودان فوق الجدار: أي صيغة يفتح جهازك اليومي فعلًا — وكيف سيبدو اختبار عادل لهذه الحاويات الثلاث على عتادك؟ سمِّ الجهاز والنموذج في التعليقات؛ الأكثر تحديدًا يضع ورقة مواصفات المقال التالي.