أصدرت Moonshot AI الأوزان المفتوحة لنموذج Kimi K3 في 27 يوليو، واقترب عداد التنزيلات على Hugging Face بالفعل من 100,000. العرض واضح: نموذج يضم 2.8 تريليون معلمة تغلب على Claude Opus 4.8 في كل معيار نشرته Moonshot، والآن يمكنك استضافته بنفسك.
لكن هناك عقبة واضحة بمجرد إلقاء نظرة على الأرقام. يتطلب الاستدلال بدقة كاملة 1.57 تيرابايت من مساحة القرص. حتى الأوزان الصادرة بصيغة MXFP4 هي تنزيل بحجم 594 جيجابايت. هذا نموذج يمكنك امتلاكه، لكن كلمة "محلي" تعني شيئًا مختلفًا على هذا النطاق مما كانت تعنيه لنموذج Llama بحجم 8 مليارات معلمة.
يغطي هذا الدليل ما يتطلبه تشغيل K3 على أجهزتك الخاصة، وما تمكن المجتمع من تحقيقه على الأجهزة الاستهلاكية، وكيفية ربط نقطة نهاية K3 المستضافة ذاتيًا بسير عمل واجهة برمجة التطبيقات (API) الخاصة بك باستخدام Apidog بمجرد أن تصبح جاهزة للخدمة.
ما تقوم بتنزيله
أولاً، شكل النموذج. إذا كنت تريد الخلفية الكاملة، ابدأ بـ ما هو Kimi K3؟؛ النسخة المختصرة:
- 2.8 تريليون معلمة إجمالية، 104 مليار معلمة مفعلة لكل رمز. K3 هو نموذج "مزيج من الخبراء" (Mixture-of-Experts) يضم 896 خبيرًا. يتم توجيه كل رمز عبر 16 خبيرًا مختارًا بالإضافة إلى خبيرين مشتركين، لذا فإن قوة الحوسبة لكل رمز تمثل جزءًا من الرقم المعلن.
- 93 طبقة: 69 طبقة Kimi Delta Attention (KDA) و 24 طبقة Gated MLA. تصميم KDA هو السبب في أن نافذة السياق البالغة مليون رمز قابلة للاستخدام على الإطلاق.
- رؤية أصلية عبر مُشفر MoonViT-V2 بـ 401 مليون معلمة. تتعامل الأوزان الصادرة مع إدخال النصوص والصور ومقاطع الفيديو.
- أوزان MXFP4، تنشيطات MXFP8. أجرت Moonshot تدريبًا واعيًا للكمية (quantization-aware training)، لذا فإن الإصدار ذو 4 بت هو تنسيق الخدمة المقصود، وليس مجرد فكرة لاحقة. هذا يعني أيضًا أن الأوزان تنضغط بشكل سيء بعد ذلك؛ لقد تم استهلاك الهامش المنخفض البت بالفعل.
- التفكير فقط. K3 يفكر دائمًا قبل الإجابة، بمستويات جهد منخفضة، عالية، وقصوى. لا يوجد وضع فوري.
الأوزان محاطة بترخيص Kimi K3 على مستودع Hugging Face. اقبل الترخيص، ثم اسحب باستخدام huggingface-cli. على اتصال بسرعة 1 جيجابت في الثانية، خصص حوالي 80 إلى 90 دقيقة لتنزيل 594 جيجابايت.
الخيار 1: تقديم خدمة على مستوى مركز البيانات باستخدام vLLM أو SGLang
توصي Moonshot بثلاثة محركات: vLLM و SGLang و TokenSpeed. تم تضمين مساهمتهم في ذاكرة التخزين المؤقت KDA في vLLM جنبًا إلى جنب مع الأوزان، لذا فإن vLLM هو المسار الأقل مقاومة:
vllm serve moonshotai/Kimi-K3 \
--tensor-parallel-size 8 \
--max-model-len 131072
ملاحظات من الميدان:
- الأجهزة. قامت Moonshot بالتقييم على مجموعات H20. واقعيًا، تحتاج إلى عقدة بـ 8 وحدات معالجة رسومية (GPU) مع توازي الموتر (tensor parallelism) كحد أدنى. على أجهزة من فئة B200، يمكن تحقيق إنتاجية تتجاوز 100 رمز/ثانية.
- السياق. يدعم النموذج ما يصل إلى 1,048,576 رمزًا، لكن ذاكرة التخزين المؤقت KV في السياق الكامل تبلغ حوالي 27 جيجابايت بمفردها. ابدأ بـ 131 ألفًا وارفعها فقط إذا كانت عبء العمل لديك يتطلب ذلك.
- أخذ العينات. إعدادات Moonshot الافتراضية هي درجة حرارة 1.0 وtop-p 0.95. لأعباء العمل العاملة (agentic workloads)، حافظ على درجة الحرارة عند 1.0 وحرك top-p إلى 1.0.
هذا "محلي" بمعنى سيادة البيانات: بنيتك التحتية، سجلاتك، قصة امتثالك. ليس محليًا بمعنى الكمبيوتر المحمول، ولا يمكن لأي قدر من التكميم أن يغير ذلك للاستخدام التفاعلي.
الخيار 2: كميات GGUF على محطة عمل كبيرة
نشرت Unsloth تحويلات GGUF لمستخدمي llama.cpp، وتعتبر كمياتهم الديناميكية هي الطريقة الواقعية الوحيدة لتقليص K3 دون الإصدار الرسمي:
| الكمية (Quant) | الحجم (Size) | ماذا تعني (What it means) |
|---|---|---|
| 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)، ولكن كل جيجابايت مفقود يكلفك سرعة. جهاز Mac Studio متصل بجهاز بسعة 128 جيجابايت، أو محطة DGX، يقع في الطرف الأدنى العملي.
استدعاء llama.cpp بحد أدنى، بما في ذلك عارض الرؤية:
./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
إذا كانت أجهزتك لا ترقى إلى هذا الحد، فلا تفرض عليها. قائمة أفضل نماذج LLM المحلية لعام 2026 تحتوي على نماذج مفتوحة تتناسب مع 24 إلى 128 جيجابايت وتجيب في الوقت الفعلي؛ K3 بحجم 1 بت على ذاكرة وصول عشوائي غير كافية لن يفعل ذلك.
تجربة M1 Max: نعم، ولكن 16 ثانية لكل رمز
وثّق موضوع على Hacker News هذا الأسبوع تشغيل K3 على جهاز M1 Max بسعة 64 جيجابايت عن طريق بث الأوزان من قرص SSD بسعة 2 تيرابايت بدلاً من الاحتفاظ بها في الذاكرة. تشرح الأرقام سبب نجاح ذلك وسبب عدم استخدامك له:
- يحمل K3 ما يقرب من 115 جيجابايت من المعلمات الكثيفة التي يلمسها كل رمز، بالإضافة إلى حوالي 25 جيجابايت من أوزان الخبراء الموجهة لكل رمز. يتجاوز الجزء الكثيف وحده ذاكرة الوصول العشوائي للجهاز، لذا يصبح قرص SSD ذاكرة بطيئة الحركة.
- النتيجة: حوالي 16 ثانية لكل رمز. أبلغت بعض التكوينات عن أكثر من دقيقة لكل رمز. هذا يعني فقرة في الساعة.
- إن إنتاجية القرص هي كل ما يهم. تقرأ أقراص SSD من جيل M1 أبطأ بكثير من شرائح Apple Silicon الحالية، وبث الخبراء عبر الشبكة أبطأ.
كإثبات على أن ندرة MoE بالإضافة إلى mmap يمكنها تشغيل نموذج بحجم 2.8 تريليون معلمة على جهاز كمبيوتر محمول، إنها نتيجة ممتعة حقًا. أما كطريقة لاستخدام K3، فهي ليست كذلك. إذا كنت تريد إجابات K3 على جهاز MacBook، فإن الخطط المجانية أو واجهة برمجة التطبيقات المستضافة ستخدمك بشكل أفضل.
ربط K3 المحلي الخاص بك بسير عمل واجهة برمجة التطبيقات (API)
سواء قدمت الخدمة عبر vLLM أو وضع الخادم في llama.cpp، فإنك تحصل على نفس النتيجة: نقطة نهاية HTTP متوافقة مع OpenAI على الجهاز المحلي (localhost). من هنا، هي واجهة برمجة تطبيقات (API) مثل أي واجهة أخرى، وينطبق نفس سير العمل الذي نستخدمه لـ اختبار نماذج LLM المحلية كواجهات API:
- وجه Apidog إلى نقطة النهاية. أنشئ بيئة بـ
base_urlمضبوطة علىhttp://localhost:8000/v1(الإعداد الافتراضي لـ vLLM) وقم بتبديلها مقابل نقطة نهاية Moonshot المستضافة لاحقًا. نفس الطلبات، خلفيتان، متغير واحد. - افحص تدفق التفكير. K3 يعتمد على التفكير فقط، لذا تحمل الردود محتوى استدلاليًا قبل الإجابة. تعرض واجهة تصحيح الأخطاء SSE في Apidog التدفق فور وصوله، مما يسهل كثيرًا رؤية التغييرات في مستويات جهد الاستدلال.
- تأكد من البنية، وليس الأحاسيس. أضف اختبارات آلية تتحقق من مخطط الاستجابة، وميزانيات الاستجابة، وحقول استخدام الرمز، بحيث يظهر تبديل الكمية أو ترقية المحرك التي تؤدي إلى تدهور الإخراج في اختبار فاشل بدلاً من تقرير مستخدم.
- محاكاة K3 أثناء انشغال وحدات معالجة الرسوميات (GPUs). يستغرق تحميل نموذج بحجم 594 جيجابايت وقتًا طويلاً. سجل الردود الحقيقية مرة واحدة، ثم دع خادمًا وهميًا يعيدها بحيث لا ينتظر عمل الواجهة الأمامية أبدًا على صندوق الاستدلال. قم بتنزيل Apidog لإعداد هذا مجانًا؛ تعمل أدوات المحاكاة والاختبار مع أي خادم متوافق مع OpenAI.
يتوافق تنسيق الطلب نفسه مع ما غطيناه في دليل واجهة برمجة تطبيقات Kimi K3، لذا فإن الاختبارات المكتوبة مقابل واجهة برمجة التطبيقات المستضافة تنتقل مباشرة إلى نشرك المحلي.
إذًا، هل يجب عليك تشغيله محليًا؟
جدول قرارات سريع:
| حالتك | التوصية |
|---|---|
| عقدة بأكثر من 8 وحدات معالجة رسومية (GPU)، أو حاجة لسيادة البيانات أو الامتثال | نعم. استخدم vLLM مع توازي الموتر (tensor parallelism)، وأوزان MXFP4. |
| محطة عمل بسعة 350 جيجابايت+ من ذاكرة الوصول العشوائي/ذاكرة الفيديو (RAM/VRAM) | ممكن. استخدم صيغ Unsloth GGUF بـ 1 بت، مع توقعات معتدلة. |
| جهاز Mac أو كمبيوتر شخصي بسعة 64 إلى 128 جيجابايت | لا. ستحصل على ثوانٍ لكل رمز، وليس رموزًا لكل ثانية. |
| تريد فقط K3 في منتجك | استخدم واجهة برمجة التطبيقات (API) المستضافة؛ إنها متوافقة مع OpenAI و Anthropic. |
الملخص الصريح: أوزان K3 المفتوحة مهمة لأنه يمكنك تدقيق، وضبط دقيق، واستضافة نموذج من الفئة الرائدة بنفسك، وليس لأن معظم الناس يجب أن يفعلوا ذلك. بالنسبة للفرق التي لديها الأجهزة، يعمل مسار vLLM اليوم بشكل جيد. أما بالنسبة للآخرين، فإن الإصدار المفتوح لا يزال يؤتي ثماره بشكل غير مباشر، من خلال الوصول المستضاف الأرخص ومنافسة مزودي الطرف الثالث لتقديمه.
أيًا كان الجانب الذي تقع فيه من هذا الجدول، فإن نقطة النهاية هي حيث يلتقي النموذج بشفرتك. اختبرها كما تختبر أي نقطة نهاية أخرى: تحقق من المخطط، فحص التدفق، والمحاكاة التي تحافظ على استمرار التطوير بينما يفكر النموذج.
