طريقة تشغيل Kimi K3 محليًا ومخاطرها

أصدرت Moonshot AI الأوزان المفتوحة لنموذج Kimi K3 في 27 يوليو، واقترب عداد التنزيلات على Hugging Face من 100,000. العرض واضح: نموذج يضم 2.8 تريليون معلمة تغلب على Claude Opus 4.8 في كل معيار نشرته Moonshot، ويمكنك الآن استضافته بنفسك.

جرّب Apidog اليوم

لكن يجب أن تبدأ بالأرقام: يحتاج الاستدلال بالدقة الكاملة إلى 1.57 تيرابايت من مساحة القرص، وحتى أوزان MXFP4 الرسمية تتطلب تنزيلًا بحجم 594 جيجابايت. هنا لا تعني كلمة «محلي» تشغيل النموذج على حاسوب محمول كما تفعل مع Llama بحجم 8 مليارات معلمة.

يوضح هذا الدليل متطلبات تشغيل K3 على بنيتك التحتية، وخيارات التكميم المتاحة، وكيفية توصيل نقطة النهاية المحلية بسير عمل API واختبارها عبر Apidog.

ما الذي تقوم بتنزيله؟

للتفاصيل المعمارية الكاملة، راجع ما هو Kimi K3؟. عمليًا، هذه هي النقاط التي تحدد طريقة النشر:

• 2.8 تريليون معلمة إجمالية، و104 مليارات معلمة مفعلة لكل رمز. النموذج من نوع Mixture-of-Experts ويحتوي على 896 خبيرًا. يُوجَّه كل رمز عبر 16 خبيرًا مختارًا، إضافة إلى خبيرين مشتركين.
• 93 طبقة: 69 طبقة Kimi Delta Attention ‏(KDA) و24 طبقة Gated MLA. تصميم KDA هو ما يجعل نافذة السياق التي تصل إلى مليون رمز قابلة للاستخدام.
• دعم رؤية أصلي عبر المشفر MoonViT-V2 ذي 401 مليون معلمة، مع دعم إدخال النصوص والصور والفيديو.
• أوزان MXFP4 وتنشيطات MXFP8. استخدمت Moonshot تدريبًا واعيًا بالتكميم، لذلك إصدار 4 بت هو تنسيق الخدمة المقصود، لا مجرد تحويل لاحق.
• وضع التفكير فقط. يفكر K3 قبل الإجابة مع مستويات جهد منخفضة وعالية وقصوى، ولا يوفر وضع إجابة فورية.

الأوزان متاحة بموجب ترخيص Kimi K3 في مستودع Hugging Face. اقبل الترخيص أولًا، ثم نزّل الأوزان باستخدام huggingface-cli. على اتصال بسرعة 1 جيجابت/ثانية، خصص تقريبًا 80–90 دقيقة لتنزيل 594 جيجابايت.

الخيار 1: خدمة على مستوى مركز البيانات باستخدام vLLM أو SGLang

توصي Moonshot بمحركات vLLM وSGLang وTokenSpeed. إذا أردت المسار المباشر، استخدم vLLM، إذ إن دعم ذاكرة التخزين المؤقت KDA متاح معه بجانب الأوزان.

ابدأ بخادم vLLM على 8 وحدات GPU:

vllm serve moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --max-model-len 131072

قائمة تحقق قبل التشغيل

1. وفّر عقدة تضم 8 وحدات GPU على الأقل. استخدم --tensor-parallel-size 8 لتوزيع النموذج عبر البطاقات.
2. ابدأ بسياق 131072 رمزًا. رغم أن الحد الأقصى هو 1,048,576 رمزًا، فإن KV cache للسياق الكامل تحتاج إلى نحو 27 جيجابايت بمفردها.
3. اضبط أخذ العينات وفق الحمل:
   • الإعدادات الافتراضية لـ Moonshot: temperature=1.0 وtop_p=0.95.
   • للأحمال الوكيلة (agentic workloads): أبقِ temperature=1.0 وارفع top_p إلى 1.0.
4. اختبر الإنتاجية على عتادك. تم تقييم النموذج على مجموعات H20، وعلى عتاد من فئة B200 يمكن أن تتجاوز الإنتاجية 100 رمز/ثانية.

هذا هو التشغيل المحلي من منظور سيادة البيانات والامتثال: البنية التحتية والسجلات داخل بيئتك. لكنه ليس تشغيلًا محليًا بمعنى حاسوب مكتبي أو محمول.

الخيار 2: كميات GGUF على محطة عمل كبيرة

إذا لم تكن لديك عقدة من 8 وحدات GPU، فخيارك العملي هو استخدام تحويلات GGUF التي نشرتها Unsloth لمستخدمي llama.cpp.

الكمية	الحجم	ماذا تعني
UD-IQ1_M	~345 جيجابايت	الحد الأدنى؛ تكميم ديناميكي شديد بـ 1 بت.
UD-IQ1_S	~650 جيجابايت	نقطة التوازن الموصى بها من Unsloth.
UD-Q4_K_XL	~1.55 تيرابايت	دقة شبه كاملة.
UD-Q8_K_XL	~1.6 تيرابايت	غير فاقد فعليًا.

قاعدة التخطيط الأساسية: يجب أن يساوي مجموع RAM وVRAM حجم الكمية تقريبًا. يستطيع llama.cpp الاستمرار عند نقص الذاكرة عبر offloading، لكن كل جيجابايت غير متاح يضيف تكلفة مباشرة إلى سرعة التوليد.

لتشغيل النموذج مع دعم الرؤية، استخدم مثلًا:

./llama.cpp/llama-cli \
  --model unsloth/Kimi-K3-GGUF/UD-IQ1_S/Kimi-K3-UD-IQ1_M-00001-of-00015.gguf \
  --mmproj unsloth/Kimi-K3-GGUF/mmproj-F16.gguf \
  --temp 1.0 \
  --top-p 0.95

إذا كانت سعة جهازك بين 24 و128 جيجابايت فقط، فلا تحاول فرض K3 عليه. راجع أفضل نماذج LLM المحلية لعام 2026 لاختيار نموذج مفتوح يعمل بزمن استجابة عملي على هذا المستوى من العتاد.

تجربة M1 Max: ممكنة، لكن بسرعة 16 ثانية لكل رمز

وثّق موضوع على Hacker News تشغيل K3 على جهاز M1 Max بسعة 64 جيجابايت عبر بث الأوزان من قرص SSD بسعة 2 تيرابايت بدل الاحتفاظ بها في الذاكرة.

هذه التجربة مفيدة لفهم الحدود، لا كنمط نشر:

• يلمس K3 نحو 115 جيجابايت من المعلمات الكثيفة لكل رمز، بالإضافة إلى نحو 25 جيجابايت من أوزان الخبراء الموجهة.
• يتجاوز الجزء الكثيف وحده ذاكرة الجهاز، لذلك يتحول SSD إلى طبقة ذاكرة بطيئة.
• النتيجة المسجلة تقارب 16 ثانية لكل رمز، بينما أبلغت بعض الإعدادات عن أكثر من دقيقة لكل رمز.
• إنتاجية القرص هي العامل الحاسم؛ بث الخبراء عبر الشبكة أبطأ أيضًا.

تثبت التجربة أن MoE مع mmap يمكن أن يشغّل نموذجًا بحجم 2.8 تريليون معلمة على جهاز شخصي، لكنها ليست طريقة مناسبة للاستخدام التفاعلي. إذا كنت تريد إجابات K3 على MacBook، فاستخدم الخطط المجانية أو API مستضافة.

ربط K3 المحلي بسير عمل API

سواء شغّلت K3 عبر vLLM أو وضع الخادم في llama.cpp، ستحصل على نقطة نهاية HTTP متوافقة مع OpenAI، غالبًا على localhost.

يمكنك تطبيق نفس النهج المستخدم في اختبار نماذج LLM المحلية كواجهات API:

1. أنشئ بيئة API للنموذج المحلي

في Apidog، أنشئ متغير بيئة باسم base_url:

http://localhost:8000/v1

استخدمه في الطلبات بدل تثبيت الرابط داخل كل طلب:

POST {{base_url}}/chat/completions
Content-Type: application/json

{
  "model": "moonshotai/Kimi-K3",
  "messages": [
    {
      "role": "user",
      "content": "اشرح الفرق بين tensor parallelism وpipeline parallelism."
    }
  ],
  "temperature": 1,
  "top_p": 0.95,
  "stream": true
}

بهذا يمكنك لاحقًا تبديل base_url إلى نقطة نهاية Moonshot المستضافة دون تعديل جسم الطلب أو اختباراتك.

2. افحص الردود المتدفقة

K3 نموذج يعتمد على التفكير فقط، لذلك قد يتضمن الرد محتوى استدلاليًا قبل الإجابة النهائية. استخدم واجهة تصحيح SSE في Apidog لمراقبة الأجزاء المتدفقة فور وصولها.

اختبر على الأقل:

• زمن وصول أول رمز.
• زمن اكتمال الاستجابة.
• اختلاف السلوك بين مستويات جهد الاستدلال.
• بنية الأحداث المتدفقة عند استخدام stream: true.

3. أضف اختبارات بنيوية تلقائية

لا تعتمد على التقييم اليدوي فقط. أضف اختبارات تتحقق من:

• وجود الحقول المطلوبة في الاستجابة.
• صحة مخطط JSON.
• حقول استخدام الرموز.
• حدود زمن الاستجابة.
• عدم تجاوز ميزانية الرموز المتوقعة.

هذا يجعل تدهور المخرجات بعد تغيير كمية GGUF أو ترقية محرك الاستدلال يظهر كاختبار فاشل بدل أن يصبح بلاغًا من المستخدمين.

4. استخدم المحاكاة أثناء تحميل النموذج

تحميل نموذج بحجم 594 جيجابايت يستغرق وقتًا. سجّل استجابات حقيقية مرة واحدة، ثم استخدم خادمًا وهميًا لإرجاعها أثناء تطوير الواجهة الأمامية أو تنفيذ اختبارات التكامل.

يمكنك تنزيل Apidog لإعداد المحاكاة والاختبارات مجانًا مع أي خادم متوافق مع OpenAI.

تنسيق الطلب متوافق مع ما ورد في دليل واجهة برمجة تطبيقات Kimi K3، لذا يمكن نقل الاختبارات المكتوبة للواجهة المستضافة مباشرة إلى النشر المحلي.

هل يجب تشغيله محليًا؟

استخدم هذا الجدول لاتخاذ القرار:

حالتك	التوصية
عقدة تضم 8 وحدات GPU أو أكثر، أو لديك متطلبات سيادة بيانات وامتثال	نعم. استخدم vLLM مع tensor parallelism وأوزان MXFP4.
محطة عمل تضم 350 جيجابايت أو أكثر من RAM/VRAM	ممكن. استخدم صيغ Unsloth GGUF بـ1 بت مع توقعات أداء معتدلة.
جهاز Mac أو PC بسعة 64–128 جيجابايت	لا. ستحصل على ثوانٍ لكل رمز بدل رموز لكل ثانية.
تريد فقط دمج K3 في منتجك	استخدم API مستضافة؛ فهي متوافقة مع OpenAI وAnthropic.

الخلاصة: أوزان K3 المفتوحة مهمة لأنك تستطيع تدقيق نموذج رائد وضبطه بدقة واستضافته بنفسك، لا لأن معظم المطورين يجب أن يشغلوه محليًا. إذا كانت لديك البنية التحتية المناسبة، فإن مسار vLLM عملي اليوم. أما إذا لم تكن لديك، فاختبر نقطة النهاية المستضافة بنفس انضباطك المعتاد: تحقق من المخطط، راقب التدفق، واستخدم المحاكاة حتى لا يتوقف التطوير أثناء تحميل النموذج أو استدلاله.