نموذج LLM محلي خارج VRAM؟ شاهد الأوزان مقابل KV cache مع gputaskman

نموذجك المحلي حُمّل بسلاسة أمس، واليوم يتعطل عند التحميل أو يصبح بطيئًا للغاية، والشيء الوحيد الذي غيّرته هو طول السياق. أحد الأسباب الشائعة هو ذاكرة KV cache، وأداة طرفية مجانية تُسمى gputaskman يمكنها أن تُظهر لك ذلك بدلًا من تركك تخمّن.

مراقب GPU النموذجي يخبرك بمدى امتلاء VRAM. هذا هو "ماذا"، وليس "لماذا". يصف README الخاص بـ gputaskman نفسه (تم التحقق في 5 نوفمبر 2026) بأنه "An htop for what's inside your GPU, not just how full it is." إنه مشروع مبكر وتجريبي مرخّص بـ MIT، لذا تعامل معه كعدسة مفيدة، لا كحكم نهائي.

ما الذي يملأ VRAM فعليًا#

تخيّل VRAM كحقيبة سفر. ثلاثة أشياء تدخل فيها:

• الأوزان (Weights): النموذج نفسه. حجم ثابت لنموذج وتكميم معينين.
• ذاكرة KV cache: الذاكرة قصيرة المدى للنموذج عن محادثتك. تنمو مع نمو السياق.
• مخازن الحوسبة (Compute buffers): مساحة عمل مؤقتة يحتاجها وقت التشغيل أثناء عمله.

عندما يقول الناس "النموذج لا يتسع"، فإنهم غالبًا يقصدون أن الأوزان تتسع لكن الذاكرة المؤقتة التي طلبتها فوقها لم تتسع. هذا التمييز يحدد الحل، وهو بالضبط ما يخفيه المراقب العادي.

ثبّت gputaskman وانظر لكل عملية#

يسرد README ثلاث طرق للدخول: ملف ZIP محمول لنظام Windows، أو استنساخ يُشغَّل بـ uv run --locked gputaskman، أو pip داخل بيئة Python 3.11+ افتراضية. المنصات، كما يصفها README:

• Windows 10/11 64-bit مع GPU من NVIDIA أو AMD (ملفات ZIP لـ x64 وARM64 على صفحة Releases)؛
• Linux وWSL مع GPU من NVIDIA (glibc 2.35+؛ يمكن لـ WSL قراءة عدادات مضيف Windows)؛
• macOS على Apple Silicon فقط من استنساخ المصدر، بدون بناء محمول.

ملفات ZIP الخاصة بـ Windows غير موقّعة. نزّلها فقط من صفحة Releases في المستودع الرسمي، github.com/shanselman/gputaskman. انسخ الأوامر الدقيقة من README: المشروع حديث وقد تتغير الخيارات.

بمجرد تشغيله، يهمّانك عرضان لهذه المشكلة:

1. عرض الجهاز: استخدام VRAM، ونشاط GPU، وPCIe، ودرجة الحرارة، والطاقة، والترددات، ومخططات السجل. جيد لسؤال "هل ارتفع شيء ما؟"
2. عرض العمليات: ذاكرة GPU المحلية لكل عملية، وذاكرة النظام المتاحة لـ GPU، ونشاط المحرك، ووقت التشغيل المكتشف (CUDA، HIP، Vulkan، Direct3D، ggml، ONNX Runtime).

في عرض العمليات، اعثر على خادم نموذجك (بالنسبة لـ Ollama، المشغّل المرفق به). ثم تحقق من بقية القائمة. إذا كان متصفح أو لعبة يحتفظ ببضعة جيجابايت، فقد وجدت إجابتك دون المساس بالنموذج.

الأوزان، وKV cache، والمخازن: من أين تأتي الأرقام#

يعرض فاحص النموذج البنية والتكميم وأحجام المخازن حيث تتوفر. هناك تحذير مهم: وفقًا لـ README، تأتي الأوزان وKV cache ومخازن الحوسبة من سجلات تحميل وقت التشغيل عند تفعيل التسجيل المتوافق. بالنسبة لـ llama.cpp، شغّل llama-server الخاص بك مع التسجيل (--log-file server.log -lv 4؛ يقول README إن المستوى 4 مطلوب لأحجام المخازن). بالنسبة لـ Ollama، يستخدم gputaskman server.log الخاص بـ Ollama إذا كان متاحًا. وإلا فهي تقديرات من بيانات GGUF الوصفية وحجم السياق، بافتراض توزيع على نمط llama.cpp. محاسبة KV لكل نموذج داخل عملية واحدة غير مدعومة بعد.

لذا اقرأ التقسيم المقدّر على أنه "تقريبًا"، والتقسيم المبني على السجلات على أنه "ما أبلغ عنه وقت التشغيل". بالنسبة لـ Ollama، يقول README إن المشغّلات المرفقة تُكتشف، وأن كتل GGUF تُسمّى من بيانات Ollama الوصفية، ويُستخدم server.log عند توفره. دعم LM Studio جزئي: تُسمّى النماذج من مجلدها وتُفحص عبر واجهة API المحلية، لكن هذا اختُبر باستجابات ثابتة، لا من البداية إلى النهاية.

يمكنك أيضًا حفظ لقطتين كـ JSON ومقارنتهما بأمر diff. هذه طريقة نظيفة للإجابة عن "ما الذي تغيّر عندما انتقلت من سياق 4K إلى 16K؟": خذ لقطة، غيّر الإعداد، أعد التحميل، خذ أخرى.

أي مِقبض تدير#

قراءة التقسيم تمنحك قرارًا، لا مجرد صورة.

الأوزان هي الشريحة الكبيرة. انتقل إلى تكميم أصغر أو نموذج أصغر. هذا هو الرافعة الوحيدة التي تصغّر الأوزان. إذا أردت حسابات الذاكرة وراء ذلك، راجع Can a 125B model run on a 16 GB GPU?

KV cache هي الشريحة الكبيرة. قصّر السياق. في Ollama يمكنك تجربته مباشرة في الجلسة:

ollama run <your-model>
>>> /set parameter num_ctx 8192

8192 مجرد قيمة مثال؛ اختر ما تحتاجه مهمتك فعلًا (الأمر وفق توثيق Ollama، تم التحقق في 5 نوفمبر 2026).

إذا لاحظت لاحقًا بطئًا غريبًا في معالجة المطالبات مع ذاكرة مؤقتة مكمّمة في llama.cpp، فإن this fix for the q5_1 KV cache هو المحطة التالية. ولمعرفة ما تحتويه نافذة السياق أصلًا، اقرأ What is a context window?

عملية أخرى هي الشريحة الكبيرة. أغلقها، أو شغّلها على GPU المدمجة. لا شيء في النموذج يحتاج إلى تغيير.

إذا لم ينجح#

• التقسيم يبدو خاطئًا. تحقق مما إذا كان تقديرًا (لا سجلات تحميل متوافقة). مع llama.cpp، شغّل llama-server الخاص بك مع --log-file server.log -lv 4 وأعد تحميل النموذج. مع Ollama، يستخدم gputaskman server.log إذا وُجد؛ وعلامة التقدير طبيعية هناك.
• LM Studio يعرض تفاصيل أقل. الدعم جزئي، كما ورد أعلاه.
• لا يوجد GPU من NVIDIA أو AMD. تغطي الأداة أحمال GPU المحلية فقط؛ الأحمال المعتمدة على CPU فقط أو NPU فقط أو السحابة خارج النطاق.
• macOS. شغّله من استنساخ المصدر؛ لا يوجد بناء محمول.

عندما يكون النموذج المستضاف هو الحل الأبسط#

لنفترض أنك تحتاج سياقًا طويلًا لمهمة واحدة، مثل تلخيص مستند كبير، وأن GPU لديك لا يتسع للنموذج إلا بسياق قصير. يمكنك مواصلة الضبط، أو إخراج VRAM من الصورة. لمهام كهذه يقدّم CheapTokens DeepSeek-V4-Flash: سياق 380K، وحتى 32,768 رمز إخراج لكل إجابة، وسعر واحد في أي وقت من اليوم، عبر واجهة API متوافقة مع OpenAI. يمتلك GLM-5.3-Flash سياقًا بحجم 390K وحتى 8,192 رمز إخراج.

الاستدعاء بالتنسيق المعتاد لـ OpenAI (ضع مفتاحك في متغير بيئة):

curl https://api.cheaptokens.dev/v1/chat/completions \
  -H "Authorization: Bearer $CHEAPTOKENS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-ai/DeepSeek-V4-Flash-0731", "messages": [{"role": "user", "content": "Summarize this document: ..."}]}'

تفاصيل الإعداد في docs. قاعدة عامة للقرار: إذا كانت مهمة ما تظل تحتاج سياقًا أكبر أو نموذجًا أكبر مما يتسع له كرت الشاشة، ويُظهر عرض العمليات أن VRAM لديك مستخدمة جيدًا بالفعل، فأرسل تلك المهمة إلى API وأبقِ المهام الصغيرة السريعة محلية. Run DeepSeek locally or use an API? يتعمق في المقايضة.

لنفترض أنك تلخّص 100 مستند كبير، كل منها 60,000 رمز إدخال و1,000 رمز إخراج (داخل نافذة 380K بفارق مريح). إليك تكلفتها اليوم:

بناءً على هذه الأرقام، $0.001 لكل مستند هو السعر الحالي لاستدعاء واحد كهذا، وإجمالًا، مع احتساب الإدخال والإخراج معًا، يأتي أقل من OpenRouter.