يعتمد Kimi API الفوترة حسب الاستهلاك، ولا يوفر نظام اشتراك. عند المقارنة، فإن النظر إلى «كم تبلغ تكلفة كل مليون رمز» وحده يؤدي غالبًا إلى اختيار خاطئ: ما يحدد الفاتورة فعليًا هو الطراز وطول السياق ونسبة إصابة التخزين المؤقت وطول الإخراج. توفر سلسلة K2 سياقًا يبلغ 262,144 رمزًا، وتصل K3 إلى 1,048,576، أي قدرة قوية على السياق الطويل، لكنها تعني أيضًا أن جانب الإدخال أكثر عرضة لتراكم التكلفة.

تفكك هذه المقالة بنية الفوترة في سلسلة K2، ومصادر التكلفة في السياق الطويل، وطريقة تقدير قابلة للتكرار، وترتيب خفض التكلفة، دون تثبيت أسعار الوحدة. تُراجع الأسعار الفعلية في الوثائق الرسمية وصفحة الأسعار.

ملاحظة: Moonshot وKimi علامتان تجاريتان مملوكتان لمالكيهما. قد تتغير أسماء الطرازات وأطوال السياق وقواعد الفوترة، وتعتمد هذه المقالة على الوضع الشائع في أكتوبر 2026؛ يُرجى التحقق من الصفحة الرسمية مرة أخرى قبل الشراء.

أولًا: كيف تتوزع طرازات سلسلة K2

الطراز التصنيف السياق المهام المناسبة نقطة التكلفة
kimi-k2.6 عام 262,144 المحادثة والاستخراج وخدمة العملاء ومعالجة المستندات نسبة إصابة التخزين المؤقت
kimi-k2.7-code برمجة 262,144 توليد الكود والأسئلة حول المستودع والوكلاء إدخال طويل ونتائج أدوات كثيرة
kimi-k2.7-code-highspeed نسخة برمجة عالية السرعة 262,144 الإكمال منخفض التأخير والبرمجة التفاعلية التوازن بين السعر والإنتاجية
kimi-k3 الجيل الجديد 1,048,576 المستندات الطويلة جدًا والمهام المركبة متعددة الخطوات السياق الطويل وكتابة الذاكرة المؤقتة

تتطور الطرازات، وقد تضيف سلسلة K2 إصدارات جديدة لاحقًا. عند الشراء، المرجع هو قائمة الطرازات الرسمية وصفحة الأسعار، ولا تُعامل أسماء الطرازات في هذه المقالة كالتزام دائم.

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

ثانيًا: تتكون الفاتورة من ثلاثة أجزاء

تُحاسب سلسلة K2 على ثلاثة بنود: «الإدخال المطابق للذاكرة، والإدخال غير المطابق، والإخراج». وتحتسب K3 كتابة الذاكرة المؤقتة بشكل منفصل وفق فترتي صلاحية: 5 دقائق وساعة واحدة، لذا لا يمكن ضرب متوسط سعر واحد في إجمالي الرموز.

البند متى ينشأ أثره في التكلفة وسيلة الضبط
الإدخال غير المطابق الموجهات والمستندات ونتائج الأدوات عند ظهورها أول مرة ينمو خطيًا مع السياق الاسترجاع والتلخيص واقتطاع السجل
الإدخال المطابق موجه النظام المتكرر والبادئة الثابتة أقل من غير المطابق عادةً وبوضوح تثبيت البادئة وترتيب الأدوات
رموز الإخراج المحتوى المولد والتفكير الإخراج الطويل يضخم الفاتورة تحديد max_completion_tokens
كتابة الذاكرة (K3) كتابة بادئة في الذاكرة تُحتسب وفق فئة مدة الاحتفاظ تخزين المحتوى المستقر المتكرر فقط

بتفكيك الطلب الواحد تصبح معادلة التكلفة:

تكلفة الطلب الواحد =
  رموز الإدخال غير المطابقة × سعر عدم الإصابة
+ رموز الإدخال المطابقة × سعر الإصابة
+ رموز الإخراج × سعر الإخراج

تُضاف إلى K3 تكلفة كتابة الذاكرة. يعرض حقل usage في الاستجابة prompt_tokens وcompletion_tokens وprompt_tokens_details؛ وتُحتسب إصابة الذاكرة وكتابتها ضمن prompt_tokens، ويُطرح مجموعهما من الإجمالي للحصول على الجزء غير المخزن.

ثالثًا: لماذا يصبح السياق الطويل مكلفًا

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

يعود الاختلاف عادةً إلى خمسة مواضع:

  1. تراكم الإدخال مع الجولات: إعادة إرسال النص كاملًا في كل جولة تضاعف الفاتورة تقريبًا مع عدد الجولات.
  2. نسبة إصابة التخزين المؤقت: البادئة الثابتة قابلة لإعادة الاستخدام؛ أما الطوابع الزمنية والمعرّفات العشوائية والترتيب الديناميكي المتغير في كل مرة فتبطل الذاكرة.
  3. نتائج الأدوات: إرجاع سجل كامل من بحث أو تنفيذ كود ثم إعادته كما هو في الجولة التالية يراكم التكلفة.
  4. طول الإخراج: طلبات «التحليل المفصل» المفتوحة أكثر ما ينتج إخراجًا طويلًا، والإخراج أغلى عادةً من الإدخال المطابق للذاكرة.
  5. سوء مطابقة الطراز: استخدام طراز كبير لتصنيف بسيط، أو إعادة المحاولة مرارًا على مهمة معقدة بطراز غير مناسب، يضخم التكلفة.

رابعًا: إجراء تقدير قابل للتكرار

  1. اختر 20 إلى 50 مهمة حقيقية تغطي المستويات البسيط والمتوسط والمعقد، وحدد معايير القبول بوضوح.
  2. استخدم واجهة تقدير الرموز لقياس الإدخال، ولا تخمّنه من عدد الكلمات.
  3. شغّل المجموعة نفسها على kimi-k2.6 وعلى طراز البرمجة، وسجّل الجودة والتأخير وعدد مرات إعادة العمل.
  4. اقرأ الإدخال والإخراج وإصابة الذاكرة وكتابتها من حقل usage في الاستجابة.
  5. قارن بتكلفة «إنجاز مهمة مقبولة واحدة»، لا بالسعر المعلن لكل مليون رمز.
  6. أدرج إعادة المحاولة والطلبات الفاشلة وكتابة الذاكرة ضمن تكلفة المهمة الواحدة.
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.cn/v1",
)

resp = client.chat.completions.create(
    model="kimi-k2.6",
    messages=[{"role": "user", "content": "استخرج بيانات هذا العقد بصيغة JSON: ……"}],
    max_completion_tokens=1024,
)

u = resp.usage
print("الإدخال", u.prompt_tokens, "الإخراج", u.completion_tokens)
print("تفاصيل الذاكرة", getattr(u, "prompt_tokens_details", None))

في الاستدعاء المتدفق أضف stream_options={"include_usage": True}، إذ لا يُعاد الاستخدام الكامل إلا في الكتلة الأخيرة. تُضرب المبالغ في سعر الوحدة الفعلي من العقد أو صفحة الأسعار، لا في لقطة شاشة قديمة.

خامسًا: ترتيب خفض التكلفة

  1. ابدأ بالذاكرة المؤقتة: ثبّت موجه النظام وتعريفات الأدوات وبادئة قاعدة المعرفة، وتحقق من الإصابة الفعلية عبر cached_tokens.
  2. ثم قلل الإدخال: اجعل الاسترجاع يعيد المقاطع ذات الصلة فقط، ولخّص الرسائل السابقة، ولا تضع المكتبة كاملة في السياق.
  3. حدّد الإخراج: اضبط max_completion_tokens بقيمة معقولة، واطلب JSON أو حقولًا ثابتة، وقلل عبارات المجاملة.
  4. وزّع الطرازات: استخدم kimi-k2.6 للمهام العامة، ونسخة K2.7 للبرمجة، ولا تلجأ إلى K3 إلا للمواد الطويلة جدًا.
  5. حوّل الطلبات الطويلة إلى البث: لا يغيّر البث سعر الوحدة مباشرة، لكنه يقلل إعادة المحاولة الناتجة عن انتهاء المهلة وانقطاع الاتصال.
  6. المراقبة والتنبيه: راقب الاستخدام حسب المشروع والطراز والسيناريو، واضبط سقف الميزانية، وراجع ترتيب الاستهلاك أسبوعيًا.

لا تعكس الترتيب: ابدأ بالذاكرة وضبط الإدخال، ثم فكر في طراز أرخص؛ وإلا فستجعل الإجابة الخاطئة أرخص فقط.

سادسًا: كيف تُدار الميزانية والفاتورة

  • مفتاح واحد لكل مشروع، وميزانية يومية لكل مشروع، لتجنب استنزاف نشاط واحد لكامل الحصة.
  • تسوية شهرية وفق ثلاثة أبعاد: المشروع والطراز والسيناريو، لتحديد الاستدعاءات الأسرع نموًا.
  • تسجيل نسبة إصابة الذاكرة وعدد المحاولات ومتوسط طول الإخراج بشكل منفصل، وإلا تعذر إثبات أثر التحسين.
  • الفرق التي تحتاج الدفع بالعملة المحلية والفواتير يمكنها توحيد فاتورة عدة طرازات عبر بوابة API محلية؛ وتُراجع الأسعار وقواعد الفواتير في صفحة الأسعار.

الأسئلة الشائعة

أيهما أفضل قيمة: K2 أم K3؟

يعتمد على المهمة. توفر سلسلة K2 سياقًا يبلغ 262,144 رمزًا وتغطي معظم سيناريوهات المستندات والكود؛ أما K3 فسياقها أكبر وتناسب المواد الطويلة جدًا. قارن التكلفة الإجمالية «لإنجاز مهمة مقبولة»، لا سعر الوحدة وحده.

كم يوفر التخزين المؤقت؟

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

هل البث أرخص؟

لا يغيّر سعر الوحدة مباشرة. تتمثل قيمته في تقليل التكلفة الخفية الناتجة عن انتهاء مهلة الطلبات الطويلة وانقطاع الاتصال وإعادة المحاولة.

لماذا الفاتورة أعلى من التقدير؟

من البنود المنسية الشائعة الرسائل السابقة ونتائج الأدوات والنص الكامل للمستند وإعادة المحاولة والإخراج الطويل وعدم إصابة الذاكرة. طابق سجلات الطلبات مع usage لتحديد الفرق.

كيف تسوي الفرق المحلية بالعملة المحلية؟

يمكن استدعاء Kimi عبر بوابة API توفر الشحن بالعملة المحلية وإصدار الفواتير، لتوحيد فاتورة عدة طرازات. تُراجع الطرازات المتاحة والأسعار وقواعد الفواتير في صفحة الأسعار.

الخطوة التالية

أنشئ مفتاح اختبار في بوابة ZSQH AI، وشغّل دفعة مهام حقيقية على kimi-k2.6 وعلى طراز البرمجة، وسجّل الرموز وإصابة الذاكرة والجودة، ثم اختر الطراز الأساسي. تتحدد توفر الطرازات وأسعارها وفق صفحة الأسعار.

قراءات ذات صلة: