ما الذي تحتاجه لتشغيل Kimi K3 على خادمك؟

متطلبات الاستضافة الذاتية لـ Kimi K3

تعني الاستضافة الذاتية لـ Kimi K3 توفير مساحة لـ2.8 تريليون مُعامِل. نشرت Moonshot الأوزان المفتوحة بتنسيق MXFP4، الذي يستهلك نحو نصف بايت لكل وزن، لذلك تبلغ الأوزان وحدها تقريباً 1.4 TB قبل تخصيص رمز واحد من ذاكرة التخزين المؤقت. لا توجد اليوم أي وحدة تسريع معروضة للبيع تستوعب ذلك بمفردها. بالنسبة إلى GPU واحد، الإجابة هي لا. أما بالنسبة إلى خادم واحد، فالإجابة هي نعم، بطريقتين. الأولى هي عقدة تضم 8 وحدات تسريع GPU، سعة كل واحدة منها 288 GB، وهذا هو التكوين الذي تستخدمه أصغر وصفات الخدمة المنشورة متعددة المستخدمين. والثانية هي جهاز واحد يضم نحو 1.6 TB من إجمالي RAM وVRAM ويشغّل GGUF Q8 غير الفاقد من Unsloth في llama.cpp، مع GPU أو من دونه، ويخدم مستخدماً واحداً في كل مرة.

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

إجمالي المعلمات والمعلمات النشطة ليسا العدد نفسه

K3 هو نموذج من نوع مزيج الخبراء. يقسم MoE (مزيج الخبراء) الشبكة إلى عدة شبكات فرعية، ويتيح لموجّه اختيار عدد قليل منها لكل رمز. تذكر بطاقة النموذج وجود 2.8T من المعلمات الإجمالية و104B من المعلمات المفعّلة لكل رمز، وذلك من بين 896 خبيراً موجهاً، يُفعَّل 16 منها لأي رمز، عبر 93 طبقة.

يجيب هذان العددان عن المعلمات عن سؤالين مختلفين، واستبدال أحدهما بالآخر هو الخطأ الأكثر شيوعاً في كل نقاش من نوع «هل يمكنني تشغيل هذا؟».

تحدد المعلمات النشطة تكلفة الحوسبة. يمر الرمز عبر نحو 104B من المعلمات، لذلك يُفترض أن يشبه معدل النقل لديك معدل نموذج كثيف بحجم 104B، لا نموذجاً بحجم 2.8T. وهذا هو السبب الأساسي لبناء نموذج MoE.

تحدد المعلمات الإجمالية تكلفة الذاكرة. قد يختار الموجّه أي خبير لأي رمز، لذلك يجب تخزين كل خبير في مكان سريع قبل وصول الطلب الأول. يوجد أسلوب يقتصر فيه تخزين الخبراء النشطين على VRAM، مع جلب الباقي عند الطلب: يحتفظ --moe-cache-mib الخاص بـ llama.cpp بذاكرة مؤقتة للخبراء على GPU، بينما يبقى الخبراء الآخرون في ذاكرة النظام، ويرفع الخبراء غير الموجودين فيها عند اختيار الموجّه لهم. لكن هذا لا يقلل الحجم الإجمالي. فما زال يجب أن تبقى بقية الخبراء في RAM، كما أن وصلة PCIe تنقل عشرات الجيجابايت في الثانية، مقابل تيرابايتات في الثانية عبر HBM، ولذلك يستغرق كل فقد في الذاكرة المؤقتة وقتاً. ويصبح بث الخبراء من NVMe أبطأ من ذلك أيضاً إذا كان النموذج لا يتسع في RAM، ويحذّر دليل K3 من Unsloth من أن التفريغ إلى القرص يعمل بسرعة أقل بكثير.

لذلك تكون تكلفة الحوسبة منخفضة، بينما تكون تكلفة التخزين مرتفعة. حدّد مواصفات العتاد على أساس 2.8T. وحدّد توقعات السرعة على أساس 104B.

عدد البايتات لكل وزن، ومصدر التيرابايتات

عدد المعلمات مضروباً في عدد البايتات لكل وزن. بالنسبة إلى الأوزان، هذه هي الصيغة كاملة.

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

دُرِّب K3 مع مراعاة التكميم، وأُصدر بأوزان MXFP4 وتفعيلات MXFP8، لذلك فإن صف 4-bit هو الصف الفعلي. أُدرجت الصفوف الأعلى منه للمقارنة: ففي bf16 سيحتاج النموذج نفسه إلى 5.6 TB. يخزّن MXFP4 أيضاً مقياساً مشتركاً بحجم 8-bit لكل كتلة من 32 وزناً، ما يضيف نحو 6 بالمائة. كما أن إعداد Moonshot يستثني attention والخبراء المشتركين وبرج الرؤية من تنسيق 4-bit، لذلك يصل checkpoint الكامل إلى نحو 1.56 TB وفق حساب Unsloth، بدلاً من 1.4 TB بالضبط.

يضيّق ذلك مجال التوفير المعتاد، لكنه لا يلغي إمكانه. فقد أصبح checkpoint المُصدر بتنسيق 4-bit، ولذلك تحقق التوفير السهل بالفعل، لكن الانتقال إلى مستوى أقل يظل يخفض الحجم. في 27 October 2026، تتراوح quantisations الديناميكية بتنسيق GGUF لـ K3 التي قاستها Unsloth بين 861.3 GB لـ UD-Q2_K_XL بحجم 2-bit و594 GB لـ UD-IQ1_S بحجم 1-bit. وتنشر Unsloth أثر ذلك: تبلغ مطابقة الرمز الأعلى top-1 مع النموذج الكامل 90.390 بالمائة عند استخدام UD-Q2_K_XL، و84.127 بالمائة عند استخدام UD-IQ2_XXS بحجم 711.1 GB، و78.875 بالمائة عند استخدام UD-IQ1_S. ويحتوي مستودع Hugging Face الخاص بها أيضاً على ملفات 1-bit أصغر، وصولاً إلى 466 GB لـ UD-Q1_0، من دون نشر قيمة للمطابقة معها. هذه خسارة مقاسة في الدقة، وحتى أصغر ملف لا يزال أكبر بنحو 1.6 مرة من أكبر بطاقة منفردة.

كم عدد وحدات GPU التي يحتاج إليها Kimi K3

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

اعتبر هذه الأرقام حداً أدنى، لا هدفاً. فهي تحسب الأوزان فقط: من دون ذاكرة KV، أو مخازن التنشيط، أو التجزئة الناتجة عن مخصّص الذاكرة، ومن دون مساحة لمعالجة طلب ثانٍ بالتزامن. ولا يلزم أن يكون التقسيم متساوياً. إذ يقسّم parallelism في vLLM النموذج وفق الطبقات ويدعم التقسيمات غير المتساوية، كما تشغّل وصفات prefill الخاصة بـK3 في SGLang عدد 8 و16 من مراحل pipeline عبر 93 طبقة.

تتجاوز الإرشادات المنشورة هذا الحد الأدنى. فقد أوصت Moonshot عند الإطلاق بـsupernode يضم 64 مسرّعاً أو أكثر. واعتباراً من 27 October 2026، يتضمن cookbook الخاص بـSGLang إعداد H100 مبنياً من أربع عقد، في كل منها 8 وحدات GPU، أي 32 وحدة GPU و2,560 GB من الذاكرة الإجمالية، مقابل حد أدنى قدره 18 بطاقة. كما يسرد وصفات لعقدة واحدة على عقدة B300 واحدة تضم 8 وحدات GPU، وعلى عقدة MI350X أو MI355X واحدة تضم 8 وحدات GPU، بسعة 2,304 GB، أي 288 GB لكل بطاقة. ولا تمثل هذه الزيادة عن الحد الأدنى هدراً. فهي مخصصة لذاكرة KV وذاكرة التنشيط والهامش الذي يتيح للخادم معالجة طلبات عديدة على دفعات في الوقت نفسه. أما بطاقات فئة GB300 الأكثر ملاءمة، وعددها 5، فتُقرَّب عملياً إلى عقدة من هذا النوع تضم 8 وحدات GPU، وهي أصغر آلة تنشر لها أي جهة وصفة لخدمة K3 لعدة مستخدمين.

ذاكرة التخزين المؤقت لـKV هي الجزء الذي يفاجئ المستخدمين

الأوزان تكلفة ثابتة. أما ذاكرة التخزين المؤقت لـKV (المفتاح والقيمة) فليست كذلك؛ إذ يزداد حجمها مع طول السياق، ثم يزداد مرة أخرى مع كل مستخدم متزامن. في آلية الانتباه العادية، تكون الصيغة هي bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element، ثم تضرب الناتج في طول السياق وفي عدد المستخدمين المتزامنين.

إليك مثالاً حسابياً، وهو مجرد مثال: 64 طبقة، و8 رؤوس KV، وبُعد للرأس مقداره 128، وتنسيق fp8. ينتج عن ذلك 2 64 8 128 1 = 131,072 بايت، أي 128 KiB لكل رمز.

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

يستهلك مستخدم واحد بسياق حجمه 128k مقدار 16 GiB. ويستهلك مستخدم واحد بالسياق الكامل البالغ مليوناً مقدار 128 GiB، وهو ما يقارب نصف بطاقة سعتها 288 GB لمحادثة واحدة، قبل تحميل أي وزن.

لا يستخدم K3 آلية الانتباه العادية، وهذا هو سبب أهمية الرقم الأخير. تتكون طبقاته البالغ عددها 93 من 69 طبقة KDA (Kimi Delta Attention) و24 طبقة Gated MLA (multi-head latent attention). تحتفظ KDA بحالة تكرارية ثابتة الحجم بدلاً من ذاكرة تخزين مؤقت يزداد حجمها مع كل رمز، بينما تضغط MLA المفتاح والقيمة في متجه كامن واحد منخفض الرتبة، لذلك تنخفض التكلفة الفعلية لكل رمز كثيراً عن المثال الحسابي. يحدد ملف config.json المنشور من Moonshot حجم هذا المتجه الكامن: kv_lora_rank مقداره 512، إضافة إلى مفتاح دوراني بعرض 64 (qk_rope_head_dim)، أي 576 قيمة لكل رمز في كل طبقة MLA. وعبر 24 طبقة وبمقدار 2 بايت لكل قيمة، يصبح الحجم 27,648 بايت، أي نحو 27 KiB لكل رمز، أو نحو 27 GiB لمحادثة كاملة تتكون من 1,048,576 رمزاً، إضافة إلى حالة KDA الثابتة. تعامل مع ذلك على أنه تقدير لا قياس؛ إذ تضيف محركات التشغيل مساحة حشو وتنسّق ذاكرة التخزين المؤقت بطرقها الخاصة، كما أن ذاكرة التخزين المؤقت ذات 8 بت تقلل الحجم إلى النصف تقريباً.

لمعرفة ما يحتفظ به النشر لديك، لا تراقب nvidia-smi أثناء زيادة --max-model-len. يخصص vLLM مسبقاً تجمّع ذاكرة التخزين المؤقت لـKV، ويحدد حجمه انطلاقاً من --gpu-memory-utilization (القيمة الافتراضية هي 0.92 في الوثائق الحالية) أو من ميزانية صريحة لذاكرة التخزين المؤقت لكل GPU، ولذلك تعرض إجمالي ذاكرة GPU حجم التجمع لا حجم محادثة واحدة. اقرأ سجل بدء التشغيل بدلاً من ذلك؛ إذ يعرض vLLM فيه حجم ذاكرة التخزين المؤقت لـKV بعدد الرموز، والحد الأقصى للتزامن عند طول السياق لديك.

يبقى منطق التحليل صالحاً في الإصدار التالي. إذا أعلن نموذج عن سياق حجمه مليون رمز ولم يذكر شيئاً عن تصميم آلية الانتباه فيه، فافترض أن ذاكرة التخزين المؤقت هي العامل المقيّد إلى أن يثبت أحد خلاف ذلك.

المستوى 1: استئجار العنقود بالساعة

هذا هو المستوى الذي يشغّل K3 بدقته المُصدرة لعدة مستخدمين في الوقت نفسه. ويمكن لجهاز واحد بذاكرة RAM كافية أن يشغّل K3 بدقته المُصدرة أيضاً عبر Unsloth's Q8 GGUF، الذي تصفه Unsloth بأنه بلا فقدان مقارنة بالدقة الكاملة، لكن هذا المسار يخدم مستخدماً واحداً في كل مرة، وتغطيه الطبقة 2. في هذا المستوى لا تشتري العتاد. بل تستأجره للساعات التي تحتاج إليها ثم توقفه بعد ذلك.

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

السعر افتراض وليس عرضاً ملزماً. تختلف أسعار التشغيل عند الطلب اختلافاً كبيراً حسب المزود وجيل GPU، كما أن الأجزاء بسعة 288 GB التي تحتاج إليها وصفات العقدة المفردة تكلف في الساعة أكثر من H100، بينما تكون السعة المحجوزة أرخص. استخدم السعر الفعلي لدى مزودك وأعد إجراء العملية الحسابية: عدد GPUs مضروباً في عدد الساعات مضروباً في السعر. يوضح المخطط النسبة فقط. فتشغيل عقدة تضم 8 GPUs لمدة أربع ساعات يومياً يكلف 2,400 USD شهرياً، بينما يكلف إبقاء إعداد SGLang الذي يتطلب 32 GPU من نوع H100 قيد التشغيل 57,600 USD.

ينشر كلا الخادمين الشائعين أمر تشغيل في بطاقة النموذج.

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

لا يشغّل أي من الأمرين المجردين العنقود الفعلي كما هو. أضف علامات التوازي التي تطابق عتادك: يستخدم SGLang العلامة --tp-size للتوازي الموترِي، والعلامة --pp-size للتوازي عبر خطوط المعالجة، والعلامة --ep-size للتوازي عبر الخبراء. يجب أن يساوي حاصل ضرب التوازي الموترِي في التوازي عبر خطوط المعالجة عدد GPUs الموجودة لديك فعلياً، بينما يقسم التوازي عبر الخبراء الخبراء داخل تلك المجموعة. لذلك تضبط وصفة 32 GPU من نوع H100 كلاً من --tp-size 32 و--ep-size 32.

تحقق من أن الخادم بدأ قبل أن ترسل حركة مرور فعلية:

curl http://127.0.0.1:30000/v1/models

يرد الخادم السليم بكائن JSON يتضمن معرّف النموذج. يعني Connection refused أن العملية لا تزال تحمّل الأوزان أو أنها خرجت بالفعل، لذا اقرأ سجل الخادم قبل إعادة المحاولة.

كان الفشل الشائع في الأسابيع الأولى هو استخدام بيئة تشغيل أقدم من النموذج. صدر K3 مع KDA وطبقة MoE جديدة لم تكن إصدارات vLLM وSGLang المستقرة تتضمنها عند الإطلاق، ويتمثل العَرَض في خروج الخادم أثناء بدء التشغيل مع سطر من الشكل Model architectures [...] are not supported for now. لا يصلح أي تغيير في الإعدادات هذه المشكلة، لأن الكود اللازم لتشغيل تلك الطبقات غير موجود في الإصدار المثبت لديك. وقد تغير ذلك منذ ذلك الحين: اعتباراً من 27 October 2026، يتضمن SGLang دعم K3 في إصداراته منذ v0.5.17، وأحدثها v0.5.22، كما تتضمن ملاحظات إصدار vLLM من v0.28.0 إلى v0.32.0 أعمالاً تخص K3. ثبّت إصداراً حديثاً. لا تزال بعض المسارات الخاصة بالعتاد تتطلب صورة مخصصة، مثل إصدارات SGLang المبنية على NVFP4 في Blackwell، لذلك راجع الوصفة الخاصة ببطاقتك.

هناك ملاحظة مهمة بشأن التكلفة. يبدأ احتساب الوقت عند بدء المثيل، لا عند جهوزية النموذج. يستغرق تنزيل بحجم 1.56 TB بسرعة 1 GB/s نحو 26 دقيقة من وقت العنقود قبل ظهور الرمز الأول. جهّز الأوزان على وحدة تخزين تبقى بعد انتهاء المثيل، حتى يبدأ التشغيل الثاني خلال دقائق.

المستوى 2: شغّل نموذجاً أصغر على مسرّع واحد

لن تشغّل K3 في هذا المستوى. اذكر ذلك صراحة قبل أن تبدأ، لأن معظم نقاشات «تشغيل K3 محلياً» تنتهي هنا من دون الاعتراف بذلك.

قاعدة الملاءمة هي الصيغة نفسها ولكن على نطاق أصغر: يجب أن يكون عدد المعاملات مضروباً في عدد البايتات لكل وزن، مضافاً إليه KV cache ونحو 2 GB من الحمل الزائد لوقت التشغيل، أقل من VRAM المتاحة. عند استخدام 4-bit، يعادل ذلك تقريباً نصف بايت لكل معامل، ما يوفّر التوافقات المريحة التالية:

• بطاقة بسعة 16 GB: نموذج 7B بدقة 4-bit مع مساحة لسياق طويل
• بطاقة بسعة 24 GB: نموذج 14B بدقة 4-bit
• بطاقة بسعة 48 GB: نموذج 32B بدقة 4-bit
• بطاقة بسعة 80 GB: نموذج 70B بدقة 4-bit، أو نموذج MoE من فئة 30B بدقة 8-bit

تفترض كل التوافقات أعلاه معالجة طلب واحد في كل مرة. وعندما يرسل شخص ثانٍ مطالبة، يحتاج كل موضع متزامن إلى KV cache خاص به. وهذا هو المفاضلة التي تتولاها إعدادات NUM_PARALLEL وMAX_QUEUE في Ollama بين المواضع المتوازية والطلبات الموضوعة في قائمة الانتظار وVRAM المتبقية لديك.

توجد طريقة واحدة لتشغيل K3 نفسه على جهاز واحد كبير، وهي تقع بين هذا المستوى والمستوى الأخير. توثّق Unsloth إصدارات GGUF من K3 في llama.cpp، بدءاً من quantisations بدقة 1-bit و2-bit وصولاً إلى UD-Q8_K_XL، الذي تصفه بأنه بلا فقدان في الدقة الكاملة، وتذكر NVIDIA DGX Station كعتاد يمكنه تشغيلها. وتقدّر القاعدة التقريبية أن مجموع RAM وVRAM يجب أن يساوي حجم quant تقريباً، من نحو 610 GB لإصدار UD-IQ1_S بدقة 1-bit إلى نحو 1.6 TB لإصدار Q8. وإذا كانت الذاكرة أقل من ذلك، يُنقل النموذج إلى القرص ويصبح أبطأ بدرجة كبيرة. وحدة GPU اختيارية؛ إذ تحوّل تعليمات البناء في Unsloth CUDA إلى الوضع المعطّل «إذا لم تكن لديك GPU أو كنت تريد استدلالاً باستخدام CPU فقط». إصدارات 1-bit و2-bit هي K3 بعد تطبيق quantisation شديد، على حساب الدقة كما قيس أعلاه. أما إصدار Q8 فهو K3 بدقته المُصدرة، ويُقدَّم لمستخدم واحد بسرعة RAM. ولا يُعد أيٌّ منهما نموذجاً أصغر.

يُعد Ollama أقصر طريق إلى خادم عامل على VPS موصول بها GPU:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ينزّل ollama run النموذج عند أول استخدام، ثم يعرض لك مطالبة. إذا لم توجد العلامة، فسيُرجع Error: model "..." not found. لذلك انسخ العلامات من صفحة المكتبة بدلاً من كتابتها اعتماداً على الذاكرة. يوجد الشرح الكامل، بما في ذلك وحدة systemd والوصول عن بُعد، في تشغيل Ollama على VPS.

يمنحك llama.cpp تحكماً أكبر في quantisation وoffload:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

يطلب -ngl 99 تحميل كل طبقة على GPU. راجع سجل التحميل؛ فهو يطبع عدد الطبقات التي جرى تفريغها. تعمل الطبقات التي تمتد إلى RAM النظام بسرعة نطاق RAM بدلاً من سرعة نطاق HBM، ولذلك تنخفض سرعة التوليد بمقدار كبير بمجرد أن يتوقف النموذج عن الملاءمة. تتناول مقارنة Ollama وllama.cpp جنباً إلى جنب المفاضلات بين الأداتين.

المستوى 3: واجهة API مستضافة، وتنسيق مستضاف ذاتياً

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

نقطة النهاية متوافقة مع OpenAI، لذلك يعمل العميل الحالي بعد تغيير عنوان URL الأساسي.

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

يعيد المفتاح العامل كائناً بتنسيق JSON يحتوي على مصفوفة choices. تعني 401 فشل المصادقة: تحقق من صحة المفتاح، ومن أنه لم تنتهِ صلاحيته أو يُعطَّل، ومن أن الترويسة تحتوي على Authorization: Bearer متبوعةً بالمفتاح. يعني الخطأ الذي يفيد بعدم العثور على النموذج عادةً أن المعرّف تغيّر، لأن موفري الخدمة يوقفون استخدام المعرّفات بين نقاط التحقق.

نحسب الآن نقطة التعادل باستخدام معدل الاستئجار المفترض أعلاه. تكلّف عقدة تحتوي على 8 وحدات GPU وتعمل دائماً 14,400 USD شهرياً. وبسعر 15.00 USD لكل مليون رمز إخراج، يشتري المبلغ نفسه نحو 960 مليون رمز إخراج من API. لتحقيق وفر في التكلفة، يجب أن تُنشئ ما يقارب مليار رمز إخراج شهرياً، أي نحو 30 مليوناً يومياً، وأن تُبقي العنقود مشغّلاً بكامل طاقته طوال الوقت، لأن وحدات GPU غير النشطة تُحاسَب بالمعدل نفسه المطبق على الوحدات النشطة. وتبتعد نقطة التعادل أكثر مع أحمال عمل الوكلاء التي تعتمد بكثافة على المطالبات: إذ تُحاسَب السياقات المتكررة بمعدل إصابة ذاكرة التخزين المؤقت البالغ 0.30 USD لكل مليون، بدلاً من معدل عدم إصابة ذاكرة التخزين المؤقت البالغ 3.00 USD.

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

أي مكدس تقديم يناسب كل طبقة

تنتمي خوادم vLLM وSGLang إلى الطبقة 1. وهي مخصّصة لمعالجة طلبات كثيرة في الوقت نفسه، باستخدام التجميع المستمر وذاكرة KV مخزّنة بنظام الصفحات، إضافة إلى التوازي على مستوى الموتر والخبراء موزّعاً على عدة عقد. وهي تفترض استخدام مسرّعات مراكز البيانات ووصلة ربط سريعة بينها. أما على بطاقة استهلاكية واحدة، فتكون أصعب في التثبيت ولا تقدّم مزايا كثيرة ستلاحظها.

ينتمي llama.cpp وOllama إلى الطبقة 2. وهما يستهدفان جهازاً واحداً، مع استخدام تكميم GGUF، وتفريغ الحسابات إلى CPU عندما لا يتسع النموذج، وتزامن منخفض. يستطيع llama.cpp تحميل نموذج MoE ضخماً جداً عبر إبقاء أوزان الخبراء في ذاكرة النظام (--cpu-moe أو --n-cpu-moe)، ومع --moe-cache-mib تخزين الخبراء الذين يستخدمهم مؤقتاً على GPU، وهذه هي الطريقة التي تعمل بها إصدارات K3 GGUF من Unsloth على جهاز واحد. تعتمد السرعة عندئذ على عرض نطاق ذاكرة RAM وعلى معدل إخفاق الموجّه في الوصول إلى ذاكرة التخزين المؤقت. وإذا كان الملف أكبر من مجموع RAM وVRAM، فسيُنقل إلى القرص. هذا إعداد عملي لمستخدم واحد. لكنه ليس خدمة يمكن إتاحتها لعدد كبير من المستخدمين. ترد المقارنة الكاملة في Ollama مقابل vLLM، ولا تتغير باختلاف النموذج: السؤال دائماً هو ما إذا كنت تقدّم الخدمة لعدة مستخدمين على عتاد مشترك، أم لمستخدم واحد على جهازك.

الأرقام الأربعة التي تظل صالحة بعد تجاوز هذه المرحلة

1. يحدد ضرب إجمالي عدد المعاملات في عدد وحدات البايت لكل وزن الحد الأدنى للذاكرة. لا يمكن تشغيل النموذج بأقل من ذلك عند الدقة التي أُصدر بها، كما أن إجراء التكميم إلى أقل من إصدار 4-bit يوفّر ما يصل إلى نحو 70 بالمئة، لكن على حساب الدقة، وليس بمقدار عشرة أضعاف.
2. تحدد المعاملات النشطة فئة معدل المعالجة. يحسب نموذج MoE بحجم 2.8T و104B من المعاملات النشطة مثل نموذج بحجم 104B.
3. تمثل ذاكرة KV cache لكل رمز، مضروبة في طول السياق ثم في عدد الطلبات المتزامنة، التكلفة التي تستمر في الارتفاع بعد دفع تكلفة الأوزان.
4. يُعد معدل الرموز في الثانية لكل دولار الرقم الوحيد الذي يحدد الفئة المناسبة. وكل ما سبق يدخل في حسابه.

طبّق هذه القواعد الأربع على أي إصدار، وستصل إلى الإجابة الصحيحة قبل فتح دليل المورد. الإصدار التالي أُعلن عنه بالفعل: أطلقت Moonshot الإصدار K3.1 Pro، المبني على K3 مع تدريب لاحق إضافي، ضمن Kimi Code في 23 October 2026، ويذكر دليل البدء السريع لواجهة API أن الأوزان الكاملة ستُطرح بحلول 4 November. بعد ذلك، اذكر تاريخ كل رقم تدوّنه. فقد تغيّرت الأسعار وقوائم البنى المدعومة خلال الأسبوعين التاليين لإطلاق K3. نُشرت أرقام الإطلاق الواردة في هذه الصفحة في July 2026، وأُعيد التحقق من وصفات التشغيل وإصدارات بيئات التشغيل وأرقام التكميم في 27 October 2026.

FAQ

هل يمكنني تشغيل Kimi K3 على GPU واحد؟

لا. يبلغ حجم الأوزان نحو 1.4 TB بدقة MXFP4 التي تُصدرها Moonshot، وحتى أصغر نسخة منشورة من K3 بعد خفض الدقة، وهي ملف UD-Q1_0 بحجم 466 GB من Unsloth، تعادل نحو 1.6 ضعف سعة 288 GB المتاحة في أكبر مسرّعات يمكن الحصول عليها على نطاق واسع. يستطيع llama.cpp إبقاء الخبراء في ذاكرة النظام وتخزين الخبراء النشطين مؤقتاً في ذاكرة GPU، لكن ذلك يتطلب مع ذلك ذاكرة RAM وVRAM بسعة تقارب حجم النسخة بعد خفض الدقة. وعند انخفاض السعة عن ذلك، يُنقل النموذج إلى القرص ويعمل بسرعة أقل بكثير. تستخدم أصغر وصفات التشغيل المنشورة عقدة واحدة تضم 8 وحدات GPU من بطاقات B300 أو MI350X/MI355X، بينما تستخدم وصفة H100 عدد 32.

ما مقدار VRAM الذي يحتاج إليه Kimi K3؟

ابدأ بسعة 1.4 TB للأوزان وحدها. وهذا يعادل 18 بطاقات H100 بسعة 80GB أو 5 بطاقات من فئة GB300. ثم أضف ذاكرة KV cache وذاكرة التنشيط. أوصت إرشادات الإطلاق من Moonshot باستخدام 64 مسرّعاً أو أكثر. واعتباراً من 27 October 2026، ينشر SGLang في دليل الوصفات إعدادات لعقدة واحدة تضم 8 بطاقات B300 أو 8 بطاقات MI350X/MI355X، بسعة إجمالية تبلغ 2,304 GB، وإعداداً يضم 32 GPU من نوع H100 بسعة إجمالية تبلغ 2,560 GB. لذلك تعامل مع سعة الأوزان باعتبارها حداً أدنى، لا متطلباً كافياً.

هل يجعل خفض الدقة Kimi K3 مناسباً لعقدة واحدة؟

تتناسب نقطة التحقق المشحونة بدقة 4-bit مع عقدة واحدة إذا كانت هذه العقدة تضم 8 بطاقات بسعة 288 GB، وهو الإعداد المستخدم في وصفتي SGLang لبطاقتي B300 وMI355X. كما تتناسب مع جهاز واحد يضم نحو 1.6 TB من RAM بالإضافة إلى VRAM باستخدام Q8 GGUF غير الفاقد من Unsloth. ويساعد خفض الدقة أكثر في الأجهزة الأصغر. تتراوح إصدارات GGUF الديناميكية التي قاستها Unsloth بين 861.3 GB عند 2-bit و594 GB عند 1-bit، كما يسرد مستودعها ملفات 1-bit بحجم يصل إلى 466 GB، مقابل نحو 1.56 TB دون فقد. وقد قيس أثر ذلك على الدقة: ينخفض التطابق من النوع الأول مع النموذج الكامل إلى 90.390 بالمئة عند UD-Q2_K_XL وإلى 78.875 بالمئة عند UD-IQ1_S. ولا تتناسب أي من هذه الإصدارات مع بطاقة واحدة.

هل يكون استئجار GPU أرخص من استخدام واجهة Kimi K3 البرمجية؟

يكون ذلك أرخص فقط عند وجود حجم استخدام كبير وثابت. بافتراض سعر قدره 2.50 USD لكل ساعة GPU، تكلف عقدة تضم 8 GPU وتعمل باستمرار 14,400 USD شهرياً. وبالمبلغ نفسه يمكنك شراء نحو 960 مليون رمز ناتج بالسعر المنشور البالغ 15.00 USD لكل مليون رمز. وستدفع أيضاً مقابل الساعات الخاملة، وتنزيلات الأوزان، والشخص المسؤول عن إبقاء العنقود قيد التشغيل. استأجر بالساعة عند وجود دفعات مؤقتة من الطلبات، وقارن ذلك بحجم الرموز الذي قسته فعلياً بدلاً من الاعتماد على تقدير.

ماذا تعني 104B من المعلمات النشطة بالنسبة إلى السرعة؟

تعني أن العمليات الحسابية لكل رمز تعادل ما يتطلبه نموذج بحجم 104B، ولذلك يقع معدل النقل ضمن هذه الفئة لا فئة 2.8T. ولا تخبرك هذه القيمة بشيء عن الذاكرة: تبقى جميع المعلمات البالغ عددها 2.8T مقيمة في الذاكرة، لأن الموجّه يستطيع استدعاء أي خبير لأي رمز. استخدم عدد المعلمات النشطة لتقدير عدد الرموز في الثانية، واستخدم العدد الإجمالي لتحديد سعة VRAM المطلوبة.