نتيجة 76x لوكيل المتصفح من GPT-6.1 Sol: ما قاسته Asana فعليًا

نشرت Asana في 8 أكتوبر 2026 دراسة عن تكلفة وكيل المتصفح، وكتب مطوّر GPT-6.1 Sol عنها في اليوم التالي تحت عنوان «Asana تقلّص تكاليف النموذج 76 ضعفًا في اختبارات المتصفح باستخدام GPT-6.1 Sol». الرقم 76 ضعفًا حقيقي بمعنى أن أحدًا قاسه، لكنه ليس حقيقة عن سعر GPT-6.1 Sol. إنه حقيقة عمّا يحدث عندما تصلح ذاكرة تخزين مؤقت معطوبة للمطالبات (prompt cache) في وكيل متصفح ثم تستبدل النموذج الذي يقف خلفها. والتحسين نفسه، عند تشغيله على النموذج الذي كان لدى Asana بالفعل في الإنتاج — وهو نموذج تسميه Model B — خفّض التكلفة 29 ضعفًا بمفرده. وقد قدّم GPT-6.1 Sol الـ 2.6 ضعفًا المتبقية. أجرى التجارب GPT-6 Astra وهو يعمل في Codex، والنموذج الذي يقف خلف خط الأساس هو نموذج منافس تسميه Asana Model B، لذا تظهر في القصة فئتان من المورّد نفسه ومنافس واحد لم يُسمَّ. ما يلي يفصل الجزء من النتيجة الذي يمكنك نسخه يوم الاثنين عن الجزء الذي يخص منظومة Asana تحديدًا.

المقارنة، كما وردت بالضبط

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

كان التصميم ست سياسات للتخزين المؤقت ولقطات الشاشة، مع ميزانيتين لسجل المحادثة، وثلاث تشغيلات لكل حالة، عبر أربعة نماذج — 144 تشغيلًا، إضافة إلى متابعة من 12 تشغيلًا. حُسبت التكاليف من عدّادات الرموز الخاصة بكل مزوّد، وتم تقييم كل إجابة مقابل مرجع أُعدّ بشكل مستقل. كانت النماذج الأربعة ثلاثة نماذج حدودية غير مسمّاة (النماذج A وB وC) وGPT-6.1 Sol. النموذج A أصغر وأرخص من مختبر آخر، صدر في خريف 2025، وبسعر يعادل نصف سعر GPT-6.1 Sol. النموذج B هو النموذج الذي كان قيد الإنتاج، من المختبر نفسه الذي طوّر A، وصدر في صيف 2026، وبالسعر نفسه الذي به يسعّر GPT-6.1 Sol. النموذج C هو نسخة أحدث من النموذج B، صدر في خريف 2026، ويسعّر أيضًا بالسعر نفسه الذي به يسعّر GPT-6.1 Sol. النماذج الثلاثة غير مسمّاة في كلا التقريرين، لذا لا يمكن للقارئ إعادة إنتاج المقارنة — وهذا أمر يجدر معرفته قبل أن تتعامل مع 29x كرقم يتعلق بنموذج جهة أخرى. هذه أرقام منشورة تخص Asana وOpenAI، وليست أرقامًا خضعت لتدقيق مستقل.

سلّم النتائج، وكلها أرقام Asana الخاصة:

• الإنتاج الأساسي على Model B — ما لا يقل عن 36.21 دولارًا لكل تشغيل، وما لا يقل عن 22.5 دقيقة لكل تشغيل. بعض عمليات التشغيل الأساسية تصل إلى حد الخطوات قبل الانتهاء، لذا فإن المتوسط يُعد حدًا أدنى وليس متوسطًا حقيقيًا.

• Model B، وكيل مُحسَّن — 1.24 دولار لكل تشغيل، أسرع 4 أضعاف من خط الأساس، وخفض للتكلفة بمقدار 29 ضعفًا.

• GPT-6.1 Sol، الوكيل المُحسَّن نفسه — 0.47 دولار لكل تشغيل، حوالي أربع دقائق، خفض في التكلفة بمقدار 76 ضعفًا وأسرع 5 مرات.

• GPT-6.1 Sol، قبل الإصلاح مقابل بعده — من 1.97$ إلى 0.47$ لكل تشغيل، خفض بمقدار 4 أضعاف بفعل تغييرات ذاكرة التخزين المؤقت والتقليم وحدها.

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

ما الذي تغيّر فعليًا، ولماذا لا يُعد ميزة في النموذج

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

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

يتكوّن الإصلاح من شقّين. أولًا، خزّن السجل في الذاكرة المؤقتة أيضًا، مع علامة تخزين مؤقت على أحدث نتيجة أداة. ثانيًا، توقّف عن تعديله في كل استدعاء: احتفظ بلقطات الشاشة وقلّمها على دفعات بنسبة 20 إلى 1، بحيث يحتفظ الوكيل بما يصل إلى 20 لقطة ثم يقلّصها إلى الأحدث فقط. عندئذٍ تعيد نحو 19 استدعاءً متتاليًا استخدام بادئة غير متغيّرة. ارفع ميزانية السجل من 120,000 إلى 480,000 حرف حتى يتوقف تقليم النص القديم، وتستقيم الحسابات: على GPT-6.1 Sol، كانت تكلفة كل استدعاء أقل بنحو 3 أضعاف لأن 89% من المدخلات جاءت من الذاكرة المؤقتة.

الاكتشاف المهم هنا سلبي. تخزين السجل مؤقتًا دون دفعات، عند الميزانية الأكبر، يكلفأكثر من عدم التخزين المؤقت إطلاقًا على ثلاثة من النماذج الأربعة — كانت الذاكرة المؤقتة تُعاد كتابتها وتُقرأ باستمرار. إن البنية التحتية للتخزين المؤقت التي تُشغَّل دون انضباط سجل الإلحاق فقط هي وسيلة لدفع علاوة كتابة مقابل لا شيء. نمط الفشل هذا مستقل عن النموذج، وهو السبب في أن الإصلاح نفسه حرّك Model B بمقدار 29 ضعفًا.

حيث أثمر اختيار النموذج فعليًا

استبعد إصلاح سير العمل وقارن المتماثل بالمتماثل: عند نفس الوكيل المُحسَّن، كان تشغيل GPT-6.1 Sol أرخص بمقدار 2.6x من Model B، وبالسعر المعلن نفسه. العامل الإضافي هو سلوك إصابة الذاكرة المؤقتة، لا بطاقة الأسعار. قرأ Sol 89% من مدخلاته من الذاكرة المؤقتة؛ ولا تنشر Asana النسبة المكافئة الخاصة بـ Model B، لذا فإن 2.6x نتيجة مقيسة دون تفكيك منشور. تعامل معها على أنها «هذا النموذج، على حمل العمل هذا، استخدم ذاكرته المؤقتة على نحو أفضل»، لا كميزة عامة قدرها 2.6x على نموذج لا نستطيع تسميته.

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

لمن يحسب ذلك: أسعار واجهة برمجة التطبيقات القياسية لـ GPT-6.1 Sol هي 2.00 دولار لكل مليون رمز إدخال، و0.10 دولار لكل مليون رمز إدخال مخزّن مؤقتًا، و10.00 دولارات لكل مليون رمز إخراج، وخصم قراءة الذاكرة المؤقتة الخاص به هو 0.05x من سعر الإدخال — وهو الأعمق في بطاقة أسعار OpenAI الحالية. أما GPT-6 Astra، النموذج الذي قام بالعمل الهندسي في Codex، فيكلف 10.00 دولارات إدخال و50.00 دولارًا إخراج، وهو فارق الخمسة أضعاف الذي استندت إليه صياغة إطلاق OpenAI. السبب في أن الدراسة أنتجت تكاليف تشغيل بقيمة 0.47 دولار بدلًا من 2 دولار ليس بطاقة الأسعار؛ بل أن 89% من طلب شديد التكرار تمت فوترته بعُشر سعر الإدخال. في وكيل يعتمد كثيرًا على التخزين المؤقت، يؤدي سطر الخصم دورًا أكبر من السعر المعلن، وفي الكتالوج الخاص بنا تُمرَّر أسعار قائمة المزوّدين مع هامش ربح 0%، لذا فإن أي بائع يغيّر عدّاد الإدخال المخزّن مؤقتًا يغيّره على فاتورتك في اليوم نفسه.

الرقم الآخر في الدراسة: ميزانية السجل هي التي حدّدت ما إذا كان الوكيل سيجيب أصلًا.

التكلفة لكل تشغيل هي الرقم الذي يستشهد به الجميع، لكن النتيجة الأكثر فائدة في الدراسة تتعلق بالموثوقية، وهي النتيجة التي ينبغي للمشغّل أن يقرأها أولًا.

• عند حد 120,000 حرف، لم يجب Model C في أي من تشغيلاته الـ18 وأجاب GPT-6.1 Sol في 3 من 18 — معظم التشغيلات وصلت إلى حد الخطوات دون إنتاج إجابة.

• عند 480,000 حرف، أجاب كل تشغيل على كلا النموذجين، وكلٌّ منها بالإجابة الصحيحة.

• أحرقت الطرازات الأحدث الميزانية الأصغر بوتيرة أسرع: قلّص Model C سجلّه أول مرة عند الاستدعاء رقم 10، وModel A عند الاستدعاء رقم 64.

• في سير العمل المُحسَّن، أكملت كل عملية تشغيل المهمة وأعادت الإجابة الصحيحة، وصادفت كل عملية تشغيل في أفضل الظروف على كل نموذج جميع الحقائق الـ192 التي كان من المفترض جمعها.

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

ما الذي يجب أخذه من هذا، بالترتيب

إذا كنت تشغّل وكيلاً لاستخدام الحاسوب، فثمة ثلاث روافع في دراسة Asana تستحق الانتباه قبل أن تنظر إلى معدل:

• اجعل بادئة الطلب قابلة للإضافة فقط. أي تعديل يخص كل استدعاء في منتصف السجل يُصفّر إعادة استخدام ذاكرة التخزين المؤقت من تلك النقطة فصاعدًا.

• قلّم على دفعات. وجدت المتابعة التي أجرتها Asana أن الاحتفاظ بكل لقطة شاشة كان أقل تكلفةً لكل استدعاء بمقدار 1.2x من أفضل حالة تقليم على Model B وGPT-6.1 Sol، وأقل بنحو 5% على Model C. لا يزال التقليم مهمًا للمهام الطويلة، ونوافذ السياق الصغيرة، وقراءات الذاكرة المؤقتة المكلفة — لكن الحجة الداعية إلى نسبة دفعات 20:1 تتعلق باستقرار الذاكرة المؤقتة، وليس بلقطات الشاشة نفسها.

• حدِّد ميزانية السجل لكل نموذج، وتحقق منها مقابل الحد الأقصى لخطواتك. الميزانية التي تلائم نموذجًا واحدًا قد تحرم النموذج التالي من موارده.

ضابطان وقائيان من الدراسة يسهل تجاهلهما ولا ينبغي تجاهلهما. لم يصل أي تشغيل إلى ميزانية 480,000 حرف، لذا لم تقيّد الميزانية هذه التشغيلات قط — لكن الوكيل المنحرف ينمو نحو حد سياقه، وإذا انكسرت الذاكرة المؤقتة، تدفع كل استدعاء التكلفة كاملة. الحدود القصوى لعدد الخطوات والرموز والتكلفة لكل تشغيل هي ما يضع حدًا لتشغيل سيئ. وبشكل منفصل، استخدمت الدراسة ثلاث أو أربع تشغيلات لكل شرط بأعداد استدعاءات متغيرة، وهو ما تقول Asana نفسها إنه كافٍ لإظهار أنماط عامة وغير كافٍ للتمييز بين شروط يفصل بينها بضعة بالمئة. لا تستنتج فارقًا بنسبة 5% من هذا وتعيد بناء خط أنابيبك حوله.

الجزء الجديد حقًا، والجزء الذي ليس كذلك

يستحق التحفظات على الإعداد أن تُذكر بوضوح: أربعة نماذج، ثلاثة منها بلا أسماء، مهمة ضيقة من 32 كتابًا، وعدادات Asana المُجهّزة الخاصة بها، وكتابة المورّد نفسه التي تستضيف النتيجة. لم يُعَد إنتاج أي شيء هنا خارج Asana. لكن الآلية محددة بالكامل — تاريخ لا يُلحق إلا بالإضافة، وعلامة ذاكرة تخزين مؤقت على آخر نتيجة أداة، وتقليم على دفعات، وميزانية أكبر، وقياس قراءات الذاكرة المؤقتة بعدادات المزوّد — وهو نوع من الاكتشافات التي تصمد حتى عند نسبتها إلى مختبر خاطئ. إن 76x رقم يخص Asana على عبء عمل يخص Asana. وسبب استحقاقه للقراءة أنه يوضح قاعدة يمكنك اختبارها خلال فترة بعد الظهر: إن وكيلًا يحرّر تاريخه الخاص في كل خطوة يدفع الثمن الكامل مقابل محادثة أجراها بالفعل.