يشير Moonshot API إلى واجهات النماذج التي توفرها منصة Moonshot AI المفتوحة، أي منصة المطورين وراء Kimi. يُحاسب على استهلاك الرموز، ولا يقدم باقات اشتراك. كثير من الفرق يخطئ في مكانين عند إعداد الميزانية: الأول أنه ما زال يستدعي طراز moonshot-v1 المتوقف، والثاني أنه يخلط الإدخال وكتابة التخزين المؤقت والإخراج وإعادة المحاولة في سعر وحدة متوسط واحد. يفكك هذا المقال بنية الفوترة وفق الوثائق العامة في أكتوبر 2026، والأسعار الفعلية مرجعها صفحة أسعار النماذج والوثائق الرسمية.

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

أولًا: ميّز «النماذج الحالية» من «النماذج المتوقفة»

حتى أكتوبر 2026، تضم الوثائق الرسمية للمنصة المفتوحة الطرازات الأساسية kimi-k3 وkimi-k2.6 وkimi-k2.7-code وkimi-k2.7-code-highspeed. أما سلسلة moonshot-v1 القديمة فقد خرجت: moonshot-v1-8k و-32k و-128k و-auto وإصدارات المعاينة البصرية المقابلة توقفت جميعًا في 31 أغسطس 2026، وتوقف في اليوم نفسه kimi-k2.5. كما توقفت خدمة إصدارات أقدم مثل kimi-k2 للمعاينة وkimi-latest.

النموذج السياق بنية الفوترة الحالة وما يجب الانتباه إليه
kimi-k3 1,048,576 الإدخال، إصابة التخزين المؤقت، كتابة التخزين المؤقت، الإخراج الرائد الحالي، وتوصي الوثائق بالانتقال إليه
kimi-k2.6 262,144 الإدخال، إصابة التخزين المؤقت، الإخراج عام ومتعدد الوسائط، شائع في السيناريوهات الحساسة للتكلفة
kimi-k2.7-code 262,144 الإدخال، إصابة التخزين المؤقت، الإخراج توليد الشيفرة والأسئلة عن المستودعات والوكيل
kimi-k2.7-code-highspeed 262,144 الإدخال، إصابة التخزين المؤقت، الإخراج مهام شيفرة منخفضة الكمون
moonshot-v1-8k/32k/128k حسب اسم الطراز الإصدار القديم مقسم حسب الطول توقف في 2026-08-31

لا تنسخ أسماء الطرازات من دروس قديمة. فـ «8k» في moonshot-v1-8k هو نفسه فئة السياق، وفشل الاستدعاء ليس مشكلة في المفتاح بل لأن الطراز لم يعد موجودًا. عند الانتقال غيّر اسم النموذج أولًا، ثم تحقق من السياق وبنود الفوترة، ولا تكتفِ باستبدال نصي.

ثانيًا: وحدة الفوترة: الطلب الواحد إلى أربعة بنود

تتكون الفاتورة الحالية عادة من أربعة أنواع من الرموز: إدخال غير مصيب في التخزين المؤقت، وإدخال مصيب، وكتابة تخزين مؤقت، وإخراج. تُسعَّر كتابة التخزين المؤقت في K3 منفصلة حسب مدة TTL من 5 دقائق أو ساعة واحدة؛ ولا تعرض صفحة أسعار سلسلة K2 بندًا منفصلًا لكتابة التخزين المؤقت. تُكتب تكلفة الطلب على الشكل:

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

تقدم الوثائق الرسمية تحويلًا مفيدًا: في النص الصيني القياسي يقابل الرمز الواحد نحو 1.5 إلى 2 حرف صيني. الضرب المباشر في سعر الوحدة يقلل تقدير الإدخال، لذا استخدم واجهة التقدير POST /v1/tokenizers/estimate-token-count أو اقرأ usage من الاستجابة مباشرة.

حقول استخدام Chat Completions هي usage.prompt_tokens وusage.completion_tokens، وتفاصيل التخزين المؤقت في usage.prompt_tokens_details.cached_tokens وcache_write_tokens. أما input_tokens في Messages API فلا يشمل التخزين المؤقت، ويجب جمع input_tokens وcache_read_input_tokens وcache_creation_input_tokens للحصول على الإدخال الكلي. في الاستدعاء المتدفق اضبط stream_options.include_usage=true.

ثالثًا: كيف يُحاسب التخزين المؤقت، ولماذا لا يصيب

يطابق التخزين المؤقت للسياق البادئة لا المحادثة كاملة. أي تغيير في مكان من البادئة يمنع إعادة استخدام ما بعده. من السلوكيات التي تكسر البادئة: إدخال طابع زمني أو معرّف عشوائي في موجه النظام، وإعادة ترتيب تعريفات الأدوات كل مرة، ودمج مقاطع قاعدة المعرفة ديناميكيًا، وتغيير فئة TTL. كما يُعزل التخزين المؤقت حسب المؤسسة، فلا يُشارك بين مؤسستين.

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

التخزين المؤقت ليس مفتاحًا يُشغَّل فيوفر المال، بل هندسة بادئات. ضع موجه النظام وتعريفات الأدوات والأمثلة الثابتة والجزء العام من قاعدة المعرفة في المقدمة، والمتغيرات في النهاية، ثم تحقق من نسبة الإصابة عبر cached_tokens.

رابعًا: تكلفة السياق الطويل: الغلاء في النقل المتكرر

يدعم K3 سياقًا بطول 1,048,576 رمزًا، بينما توفر سلسلة K2 262,144 رمزًا. يعتمد K3 فوترة موحدة حسب الاستخدام، ولم يعد يقسم حسب 8k و32k و128k كما كان moonshot-v1، لذلك لا يصح استنتاج سعر K3 من جدول الفئات القديم.

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

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

خامسًا: كيف تُحسب إعادة المحاولة والطلبات الفاشلة

تصنف رموز الخطأ الرسمية 429 إلى ثلاث فئات: rate_limit_reached_error عند بلوغ حد التزامن أو RPM أو TPM أو TPD على مستوى المؤسسة؛ وexceeded_current_quota_error عند نقص الرصيد أو الحصة؛ وengine_overloaded_error عند حمل زائد على الخادم. مشكلة الرصيد وحدها تُحل بالشحن، أما الحمل الزائد فلا يزيله الشحن مباشرة. يُنصح عادة بإعادة المحاولة لاحقًا في 500 و503؛ ومهلة البوابة في الطلبات الطويلة تُعالج بالتحول إلى التدفق لا بإعادة الإرسال كما هو.

لا تقدم الوثائق الرسمية وعدًا بأن الطلبات الفاشلة مجانية. الأسلوب الآمن ألا تفترض أن إعادة المحاولة بلا تكلفة، وأن تطابق سجلات الطلبات مع usage، وأن تحسب المحاولات منفصلة. يمكن تنفيذ استراتيجية إعادة المحاولة بالترتيب التالي:

  1. صنّف حسب رمز الخطأ؛ لا تعد المحاولة في التأخر في السداد وأخطاء المعاملات وفشل مراجعة المحتوى.
  2. أعد المحاولة بعدد محدود فقط في 429 للحدود و500 و503 وانقطاع الشبكة.
  3. استخدم تباعدًا أُسّيًا مع تذبذب عشوائي واحترم Retry-After.
  4. ضع سقفًا لعدد المحاولات والمدة الكلية لتجنب احتلال التزامن.
  5. استخدم مفتاح عدم تكرار أو جدول إزالة تكرار لاستدعاءات الأدوات لمنع تكرار الطلب أو الرسالة.
  6. سجّل request_id واسم النموذج واستهلاك الرموز وعدد المحاولات لتسهيل المطابقة.

سادسًا: تقدير الميزانية: من الرموز إلى السقف الشهري

لا تُقدّر الميزانية بالعكس من «كم سعر كل مليون رمز»، بل من المهام الحقيقية. اختر من 20 إلى 50 مهمة تمثيلية تغطي المستويات البسيط والمتوسط والمعقد، واكتب معايير القبول؛ ثم قدّر الإدخال بواجهة التقدير واقرأ usage من الاستدعاءات الفعلية، وقارن النماذج بـ «التكلفة الكلية لإنجاز مهمة مقبولة».

import os
import requests

resp = requests.post(
    "https://api.moonshot.cn/v1/tokenizers/estimate-token-count",
    headers={"Authorization": f"Bearer {os.environ['MOONSHOT_API_KEY']}"},
    json={
        "model": "kimi-k3",
        "messages": [{"role": "user", "content": "استخرج من هذا العقد ملف JSON: ……"}],
    },
    timeout=30,
)
print(resp.json()["data"]["total_tokens"])

بعد تقدير الإدخال لمرة واحدة، أضف أربعة بنود: رسائل التاريخ، وعوائد الأدوات، ونسبة عدم إصابة التخزين المؤقت، والاستدعاءات الإضافية الناتجة عن إعادة المحاولة. يمكن للمعالجة الدفعية غير المتصلة تقييم Batch API، وتذكر الوثائق الرسمية أنها أقل بنحو أربعين بالمئة من الاستدعاء المتزامن، لكنها تدعم حاليًا kimi-k2.7-code وkimi-k2.6 فقط، ولا يدعمها kimi-k3 بعد.

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

سابعًا: ترتيب خفض التكلفة وعادة المطابقة

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

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

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

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

هل يمكن متابعة استدعاء moonshot-v1-8k؟

لا. توقفت سلسلة moonshot-v1 كاملة في 31 أغسطس 2026، وتوصي الوثائق بالانتقال إلى kimi-k3. عند الانتقال لا تغيّر اسم النموذج فقط، بل أعد التحقق من طول السياق وبنود الفوترة ومعاملات الإخراج.

لماذا لم تصب إصابة التخزين المؤقت؟

افحص أولًا هل كُسرت البادئة بسبب طابع زمني أو معرّف عشوائي أو ترتيب ديناميكي أو إعادة ترتيب أدوات؛ ثم تأكد أن الفاصل بين الطلبات لم يتجاوز TTL؛ وأخيرًا تأكد أن الكتابة والقراءة في المؤسسة نفسها وفئة TTL نفسها. احكم عبر cached_tokens لا بالإحساس.

هل السياق الطويل أغلى دائمًا؟

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

هل تُحاسب الطلبات الفاشلة؟

لا تقدم الوثائق الرسمية وعدًا بالمجانية عند الفشل. لا تفترض أن إعادة المحاولة بلا تكلفة، وتحقق عبر سجلات الطلبات وusage، وأدخل عدد المحاولات في تكلفة المهمة.

أين أجد أحدث الأسعار؟

في صفحة أسعار النماذج والوثائق الرسمية لـ Moonshot/Kimi. قد تتغير الأسعار وقائمة النماذج وقواعد التخزين المؤقت، فلا تعتمد على لقطة شاشة قديمة.

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

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

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