هل يخفض Paritok تكلفة وكيل البرمجة؟

ما الذي يفعله Paritok بالطلب

Paritok هو بوابة للرموز: وهو وكيل وسيط يقع بين وكيل البرمجة وواجهة API الخاصة بالنموذج، ويضغط كل طلب قبل إعادة توجيهه. يتصل وكيلك بـ http://127.0.0.1:8080 بدلاً من موفّر الخدمة. يعيد الوكيل الوسيط كتابة مخططات الأدوات، وعمليات قراءة الملفات، ومخرجات الأدوات، والأدوار الأقدم، ثم يرسل الحمولة الأصغر إلى الجهة المزوّدة ويعيد الرد دون تغيير.

يحتسب موفّر الخدمة الرسوم على ما يصل إليه، لذلك تؤدي الحمولة الأصغر إلى فاتورة أقل. هذه هي الفكرة بالكامل. وهذا ادعاء مختلف عن أن «سياقك يستمر مدة أطول»، وهو سبب أهمية هذه الأداة، لا مجرد كونها مرتبة.

المشروع حديث العهد. تعود أولى وسماته العامة إلى July 2026، والوسم الحالي هو v1.3.0، المؤرخ في 5 August 2026. تخضع الأوزان وشفرة البوابة لترخيص Apache 2.0. نموذج الضغط هو محوّل LoRA (تكييف منخفض الرتبة) مبني على Qwen3-4B-Instruct-2507، وقد دُرِّب على 45,000 عينة مقطّرة من معلّمين، مأخوذة من مسارات عمل فعلية لوكلاء البرمجة.

لماذا لا يُعدّ هذا تقليماً للسياق

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

يستبدل Paritok مقطعاً بصيغة أقصر مع وسم، [REF:id]، ويحتفظ بالنص الكامل على الـproxy. يستعيد النموذج المقطع باستدعاء read_original أو expand_context. وهذا يغيّر نمط الفشل. يفشل المقلم بسبب النسيان، ولا يخبرك بذلك مطلقاً. أما الضاغط فيفشل بتسليم النموذج ملخصاً فاقداً للمعلومات، ويمكن للنموذج طلب النص الأصلي عندما لا يكون الملخص كافياً.

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

الرافعتان الثلاث، وأيٌّ منها مجاني

الرافعة الأولى هي مرشح مخطط الأدوات. يحمل كل طلب مصفوفة tools كاملة. في إحدى جولات Claude Code مع إرفاق عدة خوادم MCP (بروتوكول سياق النموذج)، يقيس المشروع هذا الجزء بنحو 29,000 رمز مميز. يضمّن المرشح طلب المستخدم ووصف كل أداة باستخدام BAAI/bge-small-en-v1.5، وهو نموذج تضمين حجمه 130 MB، ثم يحتفظ بالأدوات المطابقة ويستبدل الباقي بقوالب فارغة. ينخفض حجم الجزء إلى نحو 8,000 رمز مميز. يعمل نموذج التضمين هذا على CPU.

الرافعة الثانية هي ضغط المحتوى، وهي الجزء الذي يحتاج إلى نموذج 4B على GPU. تُعاد كتابة قراءات الملفات ومخرجات الأدوات والسجل لتصبح 25.7% من حجمها الأصلي. من هنا تأتي النسبة المعلنة البالغة 74%. اقرأها بعناية: نسبة 74% هي معدل الضغط للمحتوى الذي يُضغط، وليست مقدار الخفض في فاتورتك.

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

الرافعة الثانية وحدها تحتاج إلى GPU. هذه أهم جملة في هذه الصفحة. تمنحك pip install "paritok[toolselect]" مرشح الأدوات على VPS عادي يعمل بـCPU، وهي نصف المنتج الذي لا يكلفك شيئاً شهرياً. جرّبه قبل استئجار بطاقة.

ما الذي قاسه المشروع، وعلى أي أداة اختبار

[
  {
    "label": "Paritok-4B-v1",
    "compressed_to_pct": 25.7,
    "quality_retained_pct": 86.5
  },
  {
    "label": "gpt-4.1-mini",
    "compressed_to_pct": 50.2,
    "quality_retained_pct": 85.6
  },
  {
    "label": "gpt-5",
    "compressed_to_pct": 61.9,
    "quality_retained_pct": 93.6
  }
]

هذه أرقام المشروع المنشورة، وقد قاسها باستخدام أداة الاختبار الخاصة به مقابل SWE-bench Lite. يضغط Paritok-4B-v1 المحتوى إلى 25.7% من حجمه الأصلي، مع الاحتفاظ بنسبة 86.5% من معدل الحل غير المضغوط. يؤدي استخدام gpt-5 للضغط إلى الاحتفاظ بجودة أعلى، بنسبة 93.6%، لكنه يضغط المحتوى إلى 61.9% فقط، ما يعني أنك ستدفع أسعار النماذج المتقدمة لتوفير تكاليف استخدام النماذج المتقدمة.

اقرأ عمود الجودة بموضوعية. الاحتفاظ بنسبة 86.5% من معدل الحل يعني أن عمليات التشغيل المضغوطة أخفقت في حل مسائل حلتها عمليات التشغيل غير المضغوطة، أي ما يقارب حلاً واحداً من كل سبعة. في معيار قياس الأداء، هذا رقم في جدول. أما في مستودعك، فهو مهمة ستشغّلها مرتين.

[
  {
    "label": "Turn 1",
    "saved_pct": 25
  },
  {
    "label": "Turn 5",
    "saved_pct": 39
  },
  {
    "label": "Turn 12",
    "saved_pct": 57
  },
  {
    "label": "Turn 20",
    "saved_pct": 63
  }
]

يزداد التوفير من البداية إلى النهاية مع استمرار الجلسة، لأن السجل يتراكم والسجل هو الجزء الذي يجري ضغطه. يذكر المشروع توفيراً قدره نحو 25% في دورة واحدة، و39% عند الدورة 5، و63% عند الدورة 20. كما يحدد النقطة التي يتوقف عندها النمو: فعند ميزانية قدرها 200,000 token يستقر التوفير المطلق عند نحو 48,000 token لكل دورة، في مكان ما بين الدورة 8 والدورة 12، لأن السجل يتوقف عن النمو بعد امتلاء السياق. وتصف العبارة المتداولة «أكثر من 85%» الجلسات التي امتلأ فيها السياق. هذه أفضل حالة، لذلك لا تخطط على أساسها.

هل تغطي GPU بسعة 24GB تكلفة Paritok؟

تُعد البطاقة بسعة 24 GB وحدة التأجير المعتادة لتشغيل نموذج بهذا الحجم. في 7 August 2026، بلغ السعر الوسيط المنشور عند الطلب لبطاقة RTX 4090 بسعة 24 GB مبلغ $0.44 لكل ساعة، وكانت أرخص العروض قريبة من $0.20. استخدم $0.44 في الحساب. إذا تركت البطاقة قيد التشغيل طوال الشهر، فذلك يعادل 730 ساعة، أي $321. وإذا شغّلتها خلال ساعات العمل فقط، بمعدل 8 ساعات يومياً طوال 22 يوماً، فذلك يعادل 176 ساعة، أي $77.

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

[
  {
    "label": "Turn 5 (39% saved)",
    "bill_always_on_usd": "1,030",
    "bill_workday_only_usd": 248
  },
  {
    "label": "Turn 20 (63% saved)",
    "bill_always_on_usd": 637,
    "bill_workday_only_usd": 154
  },
  {
    "label": "Saturated (85% saved)",
    "bill_always_on_usd": 472,
    "bill_workday_only_usd": 114
  }
]

عند قيمة الجلسة المشبعة البالغة 85%، تحتفظ بنسبة 68% من الفاتورة. لذلك تغطي البطاقة التي تتركها قيد التشغيل تكلفتها عندما يتجاوز إنفاقك الشهري على الوكيل نحو $472، أو نحو $114 إذا أوقفت الـinstance خارج ساعات العمل. وعند قيمة الدور 20 البالغة 63%، تصبح النقطتان $637 و$154. أما عند قيمة الدور 5 البالغة 39%، وهي القيمة التي تبدو عليها الجلسات القصيرة فعلياً، فتحتاج إلى إنفاق نحو $1,030 شهرياً قبل أن يصبح استئجار البطاقة مجدياً أصلاً.

هناك عاملان يجعلان النتيجة أفضل مما يوحي به الجدول. لا يحتاج النموذج إلى 24 GB؛ فبنية q4 تحتاج إلى نحو 2.5 GB، بينما تحتاج بنية bf16 إلى نحو 8 GB. لذلك تؤدي بطاقة أصغر، أو جهاز GPU تشغّله مسبقاً لغرض آخر، إلى خفض كل الأرقام في ذلك المخطط. كما أن إيقاف الـinstance عندما لا يكتب أحد الشيفرة هو أكبر عامل مؤثر هنا، لأنه يخفض تكلفة التأجير بنحو ثلاثة أرباع.

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

إذا كنت تقارن عموماً بين ساعات GPU المستأجرة ورموز API، فإن نقطة التعادل بين GPU VPS ورموز API تجري الحساب نفسه للاستدلال بحد ذاته.

تشغيل بوابة Paritok على VPS

مطلوب Python 3.10 أو إصدار أحدث. يتضمن Ubuntu 24.04 إصدار Python 3.12، لذلك تكفي صورة VPS عادية للنصف الذي يعتمد على CPU فقط.

sudo apt update && sudo apt install -y python3-venv curl
python3 -m venv /opt/paritok/venv
source /opt/paritok/venv/bin/activate
pip install "paritok[proxy]==1.3.0"
pip install "paritok[toolselect]==1.3.0"

ثبّت الإصدار. وسم المستودع v1.2.8 في 29 July 2026، ثم وسم الإصدار v1.3.0 في 5 August 2026. والمشروع الذي يتغير بهذه السرعة يعيد تسمية مفاتيح الإعداد بين الإصدارات. يمنحك pip install paritok مجرداً، أو git clone من main، بوابة مختلفة في الأسبوع المقبل، ولا يترك أي سجل يوضح أي إصدار أنتج الأرقام التي قستها.

الواجهة الخلفية الافتراضية هي Ollama. اسحب النموذج، ثم امنحه الاسم المختصر الذي يبحث عنه الـproxy.

ollama pull paritok/paritok-4b-v1
ollama cp paritok/paritok-4b-v1 paritok-4b-v1

بما أن النموذج المحلي ينشئ إعادة كتابة لكل مقطع يضغطه، فإن استمرار عملية الضغط مدة طويلة يظهر على شكل توقف في دورة عمل الوكيل. ويُعد حد Ollama ‏num_predict لطول المخرجات الإعداد الذي يحدد الحد الأقصى لذلك.

اكتب paritok.yaml بجواره. use_gpu_server: false هو ما يبقي الضغط على أجهزتك الخاصة.

use_gpu_server: false
local_model:
  base_url: http://localhost:11434

paritok proxy --port 8080 --config-file paritok.yaml

يمثل paritok up اختصاراً لكل ما سبق: فهو يسحب النموذج إذا لم يكن موجوداً، ويشغّل الـproxy على المنفذ 8080. افحص الـproxy قبل توجيه وكيل إليه.

curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/stats

يعيد /health كائن JSON صغيراً يحتوي على "status":"ok" وسلسلة تمثل الإصدار. ويعيد /stats إجماليات الضغط وتقدير الـproxy نفسه لما وفّره. تعامل مع هذا التقدير على أنه تقييم الـproxy لعمله، وأكّده بمقارنته بصفحة الاستخدام لدى موفر الخدمة.

إذا كان الهدف هو معدل النقل بدلاً من سهولة الإعداد، فإن vLLM يقدّم adapter أعلى النموذج الأساسي.

vllm serve Qwen/Qwen3-4B-Instruct-2507 \
  --enable-lora \
  --lora-modules paritok-4b-v1=paritok/paritok-4b-v1 \
  --port 8000

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

وجّه الوكيل إلى الـproxy باستخدام متغيرات البيئة الخاصة بعنوان URL الأساسي.

export ANTHROPIC_BASE_URL=http://127.0.0.1:8080
export OPENAI_BASE_URL=http://127.0.0.1:8080

يتجاهل Codex CLI المتغير OPENAI_BASE_URL، لذلك ينشئ المشروع ~/.codex/config.toml لك عندما يكون codex.enabled: true مضبوطاً في paritok.yaml. ويؤدي تصدير المتغير وحده إلى إبقاء Codex متصلاً مباشرة بموفر الخدمة، ويظهر ذلك من خلال عداد /stats الذي لا يتغير أثناء عملك.

أبقِ المستمع على 127.0.0.1، ولا تضعه مطلقاً على 0.0.0.0. يمرر الـproxy مفتاح API الخاص بموفر الخدمة إلى الجهة العليا، لذلك فإن إتاحة proxy من الإنترنت تجعله relay مفتوحاً لذلك المفتاح: يستطيع أي شخص يعثر على المنفذ إنفاق أموالك من دون أن يرى المفتاح نفسه. صِل إليه من حاسوب محمول عبر نفق SSH أو VPN بدلاً من فتح المنفذ.

شغّله ضمن systemd لكي يستمر بعد إعادة التشغيل. عدّل المسارات لتطابق تثبيتك.

[Unit]
Description=Paritok compression proxy
After=network-online.target

[Service]
User=paritok
WorkingDirectory=/opt/paritok
ExecStart=/opt/paritok/venv/bin/paritok proxy --port 8080 --config-file /opt/paritok/paritok.yaml
Restart=on-failure

[Install]
WantedBy=multi-user.target

فعّله باستخدام sudo systemctl enable --now paritok، ثم نفّذ curl على /health مرة أخرى. تعني الوحدة التي تبدأ ثم تخرج فوراً عادةً أن مسار ملف الإعداد غير صحيح، ويطبع journalctl -u paritok -n 50 السبب.

الخيار المستضاف، وما يترتب عليه

يقدّم المشروع أيضاً خدمة الضغط. اضبط use_gpu_server: true باستخدام مفتاح API، وسيعمل نموذج 4B على أجهزته مقابل $0.30 لكل مليون رمز تتم معالجته، مع إتاحته مجاناً حتى نهاية أغسطس 2026 وفقاً لوثائقه الخاصة. يلغي ذلك تكلفة استئجار GPU وكل أعمال التشغيل المذكورة أعلاه.

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

كيفية قياس نتائجك قبل التغيير وبعده

الأرقام المنشورة هي أرقام المشروع، باستخدام أداة القياس الخاصة بالمشروع، على SWE-bench Lite. أما مستودعك فليس SWE-bench Lite. قِس نتائجك أنت.

• شغّل أسبوعاً عادياً من دون وجود proxy في المسار. سجّل input tokens وcache-read tokens وoutput tokens في أسطر منفصلة من صفحة الاستخدام لدى موفّر الخدمة، وليس كمجموع واحد بالدولار.
• شغّل الأسبوع التالي مع وضع proxy أمام الخدمة، ونفّذ النوع نفسه من العمل.
• قارن سطري input وcache-read. يجب أن يبقى output ثابتاً تقريباً، لأن أي شيء لا يضغطه. إذا تغيّر output كثيراً، فقد تغيّر شيء آخر غير proxy.
• أحصِ المهام التي اضطررت إلى إعادة تنفيذها. هذا هو جانب الجودة في المقايضة، ولا تعرضه أي لوحة معلومات في أي مكان.
• أضف ساعات GPU إلى الأسبوع الثاني قبل مقارنة الإجماليات.

يفيد فصل input عن output لأن تسعيرهما مختلف جداً، ولأن الضاغط يؤثر في أحدهما فقط. اعتباراً من August 2026، تبلغ تكلفة Claude Sonnet 4.6 مقدار $3 لكل مليون input tokens و$15 لكل مليون output tokens، بينما تبلغ تكلفة قراءة prompt-cache نسبة 10% من سعر input، أي $0.30 لكل مليون. الفارق بين تكلفة input وoutput tokens هو ما يحدد ما إذا كان ضاغط جانب input مفيداً لك. يوضح أين تذهب tokens في Claude Code فعلياً أي جزء من السياق كبير بما يكفي لتبرير ضغطه.

يزيد prompt caching من تعقيد حسابات تصفية الأدوات تحديداً. توجد كتلة الأدوات في بداية الطلب، ولذلك تكون عادةً cache hit بعد الدور الأول بسعر يبلغ 10% من سعر input. يؤدي حذف 21,000 token من كتلة مخزّنة مؤقتاً إلى توفير تكلفة 21,000 token بسعر $0.30 لكل مليون، أي نحو $0.006 لكل دور، بدلاً من $0.063 الذي يوحي به السعر من دون التخزين المؤقت. يُبقي المشروع الكتلة المصفّاة ثابتة طوال الجلسة حتى لا تتغير البادئة المخزّنة مؤقتاً. أما المرشح الذي يعيد اختيار الأدوات في كل دور، فسيفقد صلاحية تلك البادئة، وقد يكلّف أكثر مما يوفّر.

ما الذي لم يُتحقق منه بعد

تأتي كل أرقام الأداء الواردة أعلاه من المشروع نفسه. لا توجد إعادة إنتاج مستقلة لنتائج SWE-bench Lite، ومع كون أولى الوسوم مؤرخة في July 2026، لا تتوفر أيضاً إلا خبرة تشغيلية محدودة جداً حول الشيفرة. قاس الطرف المستفيد من ظهور معدل الضغط ونسبة الجودة المحتفظ بها بمستوى جيد كلاً من هذين المؤشرين. هذا لا يعني أنهما خاطئان، بل يعني أنه لم يُتحقق منهما بعد. لذلك يجب أن تتعامل معهما بصورة مختلفة عن رقم قسته بنفسك.

هناك سلوك موثق يستحق معرفته قبل أن تلقي اللوم على إعدادك. يُحمّل نموذج embedding الذي يستخدمه مرشح الأدوات عند الطلب الأول، وليس عند بدء التشغيل. لذلك يوثق المشروع فترة تهيئة مدتها 10 إلى 15 ثانية، ثم نحو 15 ms لكل استدعاء بعد ذلك. أرسل طلباً تجريبياً يمكن تجاهل نتيجته بعد بدء الـproxy، حتى لا تبدو أول جولة فعلية للوكيل وكأنها متوقفة.

يمكنك حسم أربعة أمور بنفسك خلال فترة بعد الظهر: هل يبدأ الـproxy ويظل قيد التشغيل، وهل يتحرك /stats أثناء العمل، وهل ينخفض فعلاً بند input-token لدى مزود الخدمة، وهل يواصل الوكيل إكمال العمل. هذه الأمور تحسم مدى ملاءمته لإعدادك بدرجة أفضل بكثير من أي معيار أداء منشور.

أما موضع ذلك بجوار أدواتك الأخرى، فإن بوابة LiteLLM مستضافة ذاتياً توجّه الطلبات وتقيسها دون تغيير محتواها، ولذلك يحلّ كل منهما مشكلة مختلفة ويمكن تشغيلهما معاً، مع وضع Paritok الأقرب إلى الوكيل. وإذا كان الهدف الفعلي هو خفض الفاتورة بدلاً من استخدام هذه الأداة تحديداً، فإن المجموعة الأوسع من ضوابط التكلفة لوكيل على VPS تتضمن عدة تغييرات لا تكلّف شيئاً لتجربتها أولاً.

FAQ

هل يقلل Paritok فاتورة API أم يقلل استخدام السياق فقط؟

يقلل الفاتورة، لأن الـproxy يعيد كتابة الطلب قبل وصوله إلى موفر الخدمة، ويفوتر الموفر ما يستلمه. لكن حجم التخفيض أصغر مما يوحي به العنوان. تمثل نسبة 74% معدل ضغط المحتوى الذي يخضع للضغط. وعلى امتداد الطلب والاستجابة، يذكر المشروع نسبة تقارب 25% في دورة واحدة و63% بحلول الدورة 20، ولا تتغير إلا رموز الإدخال. تمرر رموز الإخراج دون تعديل.

ما مقدار GPU الذي أحتاج إليه لاستضافة نموذج الضغط بنفسي؟

يبلغ حجم إصدار q4 نحو 2.5 GB، بينما يبلغ حجم إصدار bf16 نحو 8 GB، لذلك يعمل النموذج ضمن بطاقة بسعة 24 GB مع مساحة كبيرة متبقية. وتعمل بطاقة أصغر أيضاً، كما تجعل حساب نقطة التعادل في صالحك. لا يحتاج مرشح مخطط الأدوات إلى GPU إطلاقاً؛ فهو يستخدم BAAI/bge-small-en-v1.5، وهو نموذج تضمين حجمه 130 MB ويعمل على CPU. ثبّت paritok[toolselect] على VPS عادي، وستحصل على تقليل كتل الأدوات مقابل قدر قليل من RAM.

ماذا يحدث إذا أزال الضاغط شيئاً يحتاج إليه الوكيل؟

لا تتم إزالة أي شيء. تحمل المقاطع المضغوطة وسم [REF:id]، ويستعيد النموذج النص الكامل باستخدام read_original أو expand_context. تُنشأ بدائل مؤقتة لمخططات الأدوات التي تمت تصفيتها بدلاً من حذفها، ويستعيد النموذج أحدها باستخدام gateway_search_tools. يكمن الخطر الحقيقي في أمر أقل وضوحاً من فقدان ملف: يعمل النموذج انطلاقاً من ملخص فاقد للمعلومات، ولا يدرك أنه ينبغي أن يطلب النص الأصلي. وهذا ما تقيسه نسبة الاحتفاظ بالجودة البالغة 86.5% على SWE-bench Lite.

لماذا يستغرق طلبي الأول 15 ثانية؟

يُحمّل نموذج التضمين الذي يقف وراء مرشح الأدوات عند الطلب الأول بدلاً من تحميله عند بدء التشغيل. يوثق المشروع عملية تهيئة تستغرق من 10 إلى 15 ثانية، ثم نحو 15 ms لكل استدعاء بعد ذلك. أرسل طلباً تجريبياً واحداً باستخدام curl بعد بدء الـproxy، ولن تتوقف أول دورة فعلية للوكيل.

هل ينبغي أن أستخدم خادم GPU المستضاف بدلاً من الاستضافة الذاتية؟

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