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

تقارن هذه المقالة الخيارات الشائعة، وتقدم قائمة ترحيل وتحقق. تُعتمد الأسعار وأسماء الطرازات والتوفر على أسعار الطرازات وعلى تعليمات مزود الخدمة.

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

أولًا: التعريف أولًا: الوسيط والوكيل والبوابة ليست شيئًا واحدًا

  • وسيط API (relay): يمرر الطلبات إلى خدمة طراز المنبع، وقد يوفر الفوترة والحدود والسجلات. بعض «الوسطاء» في السوق مجرد مفاتيح مشتركة أو معاد بيعها، ويعتمد استقرارها وامتثالها على المشغل.
  • وكيل الشبكة: وكيل HTTP أو SOCKS أو عكسي، يحل إمكانية الوصول الشبكي فقط ولا يغير دلالة API؛ ويبقى المفتاح مفتاحك.
  • الوكيل الذاتي: ينشر الفريق وكيلًا عكسيًا أو بوابة مفتوحة المصدر على خادمه، ويتحكم في المفتاح والسجلات والتوجيه، لكنه يتحمل حساب المنبع والنطاق الترددي والتشغيل.
  • بوابة AI موحدة: مدخل متوافق مع OpenAI يجمع عدة طرازات ويوفر مفتاحًا وفاتورة ولوحة تحكم موحدة. قد تنتمي البوابات التجارية والبوابات المفتوحة ذاتية النشر إلى هذه الفئة.

خلط المفاهيم الأربعة يجعل مشكلة الشبكة تبدو مشكلة طراز. قبل التعاقد، اسأل بوضوح: أي طبقة خدمة يقدم الطرف الآخر، ولمن يعود المفتاح؟

ثانيًا: أربعة خيارات في جدول واحد

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

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

ثالثًا: السعر: لا تنظر إلى «المعامل» وحده

تسعير الوسطاء الشائع هو «سعر رسمي × معامل» أو «باقة رموز». انخفاض المعامل لا يعني انخفاض التكلفة الإجمالية، ويجب السؤال عن ثمانية أمور على الأقل:

  1. هل تُسعّر المدخلات والمخرجات منفصلة، وهل المعامل واحد؟
  2. هل يحصل الإدخال المصيب للتخزين المؤقت على خصم، وكيف يُحسب؟
  3. هل تُحتسب رموز الاستدلال الناتجة عن thinking ضمن الإخراج؟
  4. هل تُفوتر الطلبات الفاشلة وطلبات إعادة المحاولة؟
  5. هل يُعاد usage كاملًا في الطلبات المتدفقة؟
  6. هل يوجد حد أدنى للشحن ومدة صلاحية وقواعد استرداد؟
  7. هل تُصدر فواتير، وما سعر الصرف وعملة التسوية؟
  8. هل يمكن تقسيم إحصاءات الاستخدام والفواتير حسب المشروع والمفتاح والطراز؟

اكتب هذه المعايير في جدول مقارنة، ثم اختبر بالطلبات نفسها لتحسب التكلفة الحقيقية. تُعتمد الأسعار وطريقة الفوترة على أسعار الطرازات وفاتورة الطرف الآخر.

رابعًا: الاستقرار: تحقق بالبيانات لا بالإعلان

يُقاس الاستقرار بستة مؤشرات على الأقل: معدل النجاح، وزمن P50/P95، وزمن الرمز الأول، ومعدل المهلة، ونسبة 429، وسرعة الإخراج. استخدم مطالبات بطول واقعي، وغطِّ البث والسياق الطويل والتزامن.

import os
import statistics
import time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["RELAY_API_KEY"],
    base_url=os.environ["RELAY_BASE_URL"],
    max_retries=0,
    timeout=60,
)

prompt = "اشرح في مئتي كلمة المراحل الرئيسية لتنفيذ طلبات التجارة الإلكترونية العابرة للحدود."
latencies, errors, usage = [], 0, []

for i in range(20):
    start = time.perf_counter()
    try:
        resp = client.chat.completions.create(
            model=os.environ["RELAY_MODEL"],
            messages=[{"role": "user", "content": prompt}],
            max_tokens=512,
        )
        latencies.append((time.perf_counter() - start) * 1000)
        usage.append(resp.usage.total_tokens if resp.usage else 0)
        print(i, resp.model, resp.usage)
    except Exception as exc:
        errors += 1
        print(i, type(exc).__name__, exc)

if latencies:
    print("نجاح", len(latencies), "فشل", errors)
    print("P50", statistics.median(latencies), "ms")
    print("الأقصى", max(latencies), "ms")
    print("متوسط الرموز", sum(usage) / len(usage))

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

خامسًا: مخاطر المفتاح والامتثال: أهم من السعر

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

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

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

سادسًا: قائمة الترحيل: من الاتصال المباشر إلى الوسيط أو البوابة

  1. سجّل الوضع الحالي: معدل النجاح وزمن P50/P95 واستهلاك الرموز لكل ألف طلب والفاتورة.
  2. اجرد أسماء الطرازات والمعاملات: thinking وmax_tokens وtools وإخراج JSON والبث.
  3. أنشئ مفتاح اختبار ومفتاح إنتاج، واضبط لكل منهما ميزانية وتنبيهات.
  4. غيّر base_url وapi_key فقط، وشغّل أصغر طلب في بيئة التجهيز.
  5. أعد تشغيل مطالبات حقيقية، وقارن جودة الإخراج والزمن ومعايير usage.
  6. افحص تحويل 401 و402 و429 و5xx والمهل، وتأكد أن إعادة المحاولة لا تضخم العطل.
  7. حوّل 5%–10% من الحركة، وراقب 3–7 أيام، مع إبقاء الاتصال الرسمي كمسار تراجع.
  8. بعد التحويل الكامل، تابع التسوية أسبوعًا للتأكد من تطابق الفاتورة وإحصاءات الاستخدام.

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

سابعًا: كيف تتحقق من موثوقية وسيط؟

ابدأ بحقل model في الاستجابة، لكن لا تثق به وحده لأنه قابل للتعديل. الطريقة الأكثر موثوقية هي التحقق المركب:

عنصر التحقق الطريقة إشارة غير طبيعية
زمن الاستجابة كرر الطلب نفسه وقارن P50/P95 تذبذب شديد أو بطء دائم مقارنة بالاتصال المباشر
معدل الأخطاء احسب نسبة 429 و5xx والمهل فشل متركز في الذروة
الاستخدام قارن usage في الاستجابة بفاتورة الخلفية عدم تطابق أو غياب usage في البث
هوية الطراز قارن حدود القدرة وأسلوب الإخراج بمجموعة اختبار ثابتة تراجع واضح في القدرة أو قصر السياق
عزل المفتاح تأكد من استقلال المفتاح وإمكانية تدويره رفض توضيح مصدر المفتاح
العقد والدعم افحص الكيان والشروط والفواتير واستجابة التذاكر وسيلة تواصل شخصية فقط ودون شروط خدمة

تشمل العلامات الحمراء: سعر أقل بكثير من الرسمي لفترة طويلة، ووعد «بانعدام الأعطال»، ورفض تقديم تفاصيل الاستخدام، وطلب تسليم مفتاحك الرسمي، وعدم توضيح مكان الاحتفاظ بالبيانات. عند رؤية ذلك، اختبر بحركة صغيرة ولا تنقل الإنتاج دفعة واحدة.

ثامنًا: متى يكون الوكيل الذاتي أنسب؟

يناسب الوكيل الذاتي الفرق ذات القدرة الهندسية: الحاجة إلى عنوان IP ثابت للخروج، وتدقيق موحد، وتوجيه إلى عدة منابع، أو إبقاء المفتاح في اليد. الأسلوب الشائع هو وكيل عكسي مع إدارة مفاتيح وحدود وسجلات وتنبيهات، مع بقاء المنبع على حساب رسمي أو مزود متوافق.

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

تاسعًا: توصية الاختيار: رتب حسب القيود

  1. ابدأ بالشبكة والدفع: هل المدخل الرسمي متاح بثبات ويمكن الشحن بسهولة؟ إن كان نعم، فالاتصال الرسمي أولًا.
  2. ثم القدرة على التحكم: هل تحتاج منفذ خروج ثابتًا وسجلات تدقيق ومفاتيح خاصة؟ إن كان نعم، فقيّم الوكيل الذاتي.
  3. ثم نطاق الطرازات: هل تريد مدخلًا واحدًا لعدة طرازات؟ إن كان نعم، فانظر في البوابة الموحدة.
  4. أخيرًا قدرة الخدمة: هل الكيان والشروط والفواتير والتذاكر وسياسة البيانات واضحة؟

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

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

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

ما الفرق بين الوسيط والوكيل؟

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

سعر الوسيط أقل من الرسمي، هل يمكن الوثوق به؟

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

كيف نعرف أن الوسيط غيّر الطراز؟

لا يكفي حقل model في الاستجابة. قارن حدود القدرة وطول السياق وأسلوب الإخراج وبنية usage بمجموعة اختبار ثابتة، واحتفظ بالاتصال الرسمي كمرجع. عند تراجع واضح في القدرة، أوقف الحركة ثم حقق.

كم شيفرة نعدّل عند الانتقال إلى بوابة؟

معظم مشاريع OpenAI SDK تغيّر base_url وapi_key فقط، وتعدّل أسماء الطرازات وفق صفحة أسعار البوابة. عند استخدام thinking أو tools أو حقول استجابة خاصة، أجرِ اختبار توافق إضافيًا.

ما أهم ما تراقبه المؤسسات؟

انتماء المفتاح، واتفاقية معالجة البيانات، وجهة الفاتورة والعقد، واستجابة الأعطال، وآلية الخروج. السعر مهم، لكن استمرارية العمل ومسؤولية الامتثال أهم.