أطلقت OpenAI نموذج GPT-6.1 Sol في ٢٩ سبتمبر ٢٠٢٦ بوصفه تطويرًا لـGPT-6 Sol لأعمال البرمجة والعمل المهني والوكلاء. القصة المهمة للمطور ليست ترتيبًا واحدًا في Benchmark، بل محاولة تقديم قدرة قريبة من Astra ضمن فئة سعر Sol، مع خفض سعر Cached Input وإضافة دعم Multi-agent في مرحلة Beta.
تقول OpenAI إن النموذج يقترب من GPT-6 Astra في عدة تقييمات داخلية أو لدى شركاء، وتعلن سعرًا قياسيًا قدره دولاران لكل مليون Input Tokens، و0.10 دولار لكل مليون Cached Input Tokens، و10 دولارات لكل مليون Output Tokens ضمن حد الإدخال المذكور في سجل API. هذه نتائج وأسعار منشورة من الشركة وليست ضمانًا لمنتج بعينه؛ لذلك القرار الصحيح هو ترحيل مقاس، لا استبدال اسم النموذج فقط.
ما الذي تغيّر فعليًا؟
يصف الإعلان الرسمي GPT-6.1 Sol بأنه أقوى من Sol السابق في Agentic Coding واستخدام الكمبيوتر والمستندات المهنية وأتمتة Workflows والمهام العلمية والدقة الواقعية. وتذكر OpenAI تحسنًا قدره 6.4 نقاط على أفضل نتيجة لـGPT-6 Sol في DeepSWE، وسبع نقاط في إعداد OSWorld المذكور، وانخفاض نسبة الإجابات التي تحتوي خطأ واقعيًا في تقييم داخلي صعب عند Low Reasoning.
يؤكد سجل تغييرات API أن Model ID هو \u0060gpt-6.1-sol\u0060، وأنه متاح عبر Responses وChat Completions، مع Multi-agent في Beta. وما زالت إرشادات OpenAI توصي بـResponses API عند استخدام الاستدلال مع الأدوات. اختبر كل قدرة بصورة مستقلة؛ تحسن البرمجة لا يثبت تلقائيًا تحسن RAG أوالعربية أوالاستخراج المنظم أوأدوات منتجك.
الاقتصاديات أكبر من سعر الـToken
سعر Input وOutput القياسي يطابق GPT-6 Sol، بينما ينخفض Cached Input من 0.20 إلى 0.10 دولار لكل مليون Token وفق OpenAI. يفيد ذلك الوكلاء الذين يعيدون استخدام System Prompt ثابت أوالسياسات أوTool Schemas أوسياق المستودع. وتقل قيمته عندما يتغير Prefix في كل طلب أوتكون المخرجات هي الجزء الأكبر من الفاتورة.
احسب Cost per Completed Task بدل Cost per Token. أضف المحاولات الفاشلة وReasoning وOutput Tokens واستدعاءات الأدوات وCache Writes وReads وإعادة المحاولة والمراجعة البشرية. يقيد Changelog الأسعار المعلنة للطلبات حتى 272K Input Tokens، لذلك يجب على تطبيقات Long Context مراجعة جدول السعر الحالي بدل تعميم العنوان التسويقي.
صنّف الأحمال قبل اختيار Default
ابدأ الترحيل بتقسيم حركة الإنتاج. أنشئ Routing Table صغيرًا وواضحًا: التصنيف والاستخراج المتكرر، ومراجعة Long Context، والبرمجة متعددة الخطوات، واستخدام المتصفح أوالكمبيوتر، والإجراءات عالية الأثر لا ينبغي أن تمر تلقائيًا بالنموذج وReasoning Effort نفسيهما.
استخدم GPT-6.1 Sol عندما يمكن للاستدلال الأقوى تقليل الإعادة أوالتصحيح البشري. أبقِ نموذجًا أرخص للعمل الضيق والمستقر الذي يحقق هدف الجودة حاليًا. واحتفظ بـAstra للمهام التي تغير قدرته الأعلى معدل الاكتمال بما يبرر السعر. يخفي Default واحد هذه المفاضلات ويصعب تشخيص التراجع.
ابنِ Evaluation Set يمثل الإنتاج
ابدأ بمهام إنتاج منزوعة البيانات الحساسة وبحالات فشل معروفة. لوكيل برمجة، قس صحة Patch وحدودها واختباراتها وقابليتها للدمج. ولوكيل دعم أوتجارة، قس اختيار الأداة وصحة Arguments والالتزام بالسياسات والإجابة المستندة إلى مصدر وإكمال المهمة. أضف حالات عربية وإنجليزية إذا كان المنتج يخدم اللغتين.
شغّل Prompts والأدوات وReasoning Effort وقواعد التوقف نفسها على النموذج الحالي وGPT-6.1 Sol. سجّل نجاح المهمة وتوزيع Latency والكلفة الكاملة وعدد Tool Calls وRetries وتفضيل المراجع. تساعد ادعاءات OpenAI في بناء فرضيات، لكن تقييمك هو الذي يحسم نجاح الترحيل.
اختبر عقد الـAPI لا جودة الإجابة فقط
قد يدعم النموذج ميزة لا يدعمها Endpoint أوParameters في تنفيذك الحالي. تقول إرشادات GPT-6 إن Tool Calling لعائلة GPT-6 ينبغي أن يستخدم Responses API، وتشير إلى قيود توافق تخص Reasoning Effort وSampling Parameters. اختبر Streaming Events وStructured Outputs وترتيب Tool Calls والإلغاء وTimeouts ومعالجة الأخطاء باستخدام إصدار SDK نفسه الموجود في الإنتاج.
إذا اختبرت Multi-agent Beta، عرّف ما الذي يجوز تفويضه، وأقصى عمق وتوازٍ، وميزانية مشتركة، وكيفية التحقق من نتائج Subagents. ميزة Beta ليست معمارية كاملة؛ يبقى تطبيقك مسؤولًا عن Authorization وTenant Isolation وIdempotency وقرار تنفيذ أي أثر خارجي.
قِس سلوك الكاش مباشرة
سعر Cached Input الأرخص يصنع قيمة فقط عندما تحقق الطلبات Cache Hit حقيقيًا. ضع التعليمات الثابتة وTool Schemas في Prefix قابل لإعادة الاستخدام، وانقل بيانات المستخدم المتغيرة إلى جزء لاحق، وراقب Cached وUncached Tokens. قد يحسن Prompt Refactor القراءة لكنه يمحو التوفير المتوقع إذا غيّر Prefix في كل استدعاء.
قارن ثلاثة أرقام على الأقل: Cache Hit Rate، وكلفة المهمة الناجحة، والزمن حتى أول نتيجة مفيدة. واختبر هل تغيير Reasoning Effort أوإتاحة الأدوات يحافظ على مسار الكاش المقصود في تنفيذك. لا تبنِ الميزانية على أفضل خصم ممكن وحده.
أطلقه بعقد قابل للتراجع
ابدأ بتقييمات Shadow أومجموعة داخلية، ثم وجّه نسبة صغيرة من الطلبات المؤهلة إلى GPT-6.1 Sol. ثبّت Model ID بدل الاعتماد على Alias قد يتغير هدفه. عرّف حدود التراجع لفشل المهمة وTool Calls غير الصالحة وLatency والكلفة وحوادث السلامة قبل توسيع التعرض.
سجّل النموذج المختار وEffort وإصدار Prompt وإصدار الأدوات ومجموعة التقييم مع كل Trace، من دون تسجيل Prompts حساسة أوCredentials. إذا غيّر النموذج طول المخرجات أوسلوك الأدوات، عدّل الميزانيات والمهل عمدًا بدل إخفاء الأثر بإعادة المحاولة.
ماذا يفعل الفريق الآن؟
على الفرق التي تستخدم GPT-6 Sol أن تبدأ بتقييم GPT-6.1 Sol في المهام الصعبة ذات الإعادات المكلفة أوالسياق الثابت الكبير. وعلى مستخدمي Astra اختبار هل يصل 6.1 Sol إلى معدل الاكتمال المطلوب بكلفة أقل لكل مهمة. أما التطبيقات على نماذج أقدم، فلتتعامل معه كترحيل أوسع إلى Responses API ومنظومة Evals، لا كتغيير String فقط.
الخلاصة العملية: يبدو GPT-6.1 Sol مهمًا لأنه يغيّر حد القدرة مقابل الكلفة، خصوصًا لوكلاء البرمجة والسياق المخزن. ويبقى قرار الإنتاج معتمدًا على اختبارات ممثلة واقتصاديات المهمة الكاملة ومسار تراجع مضبوط.
المراجع الرسمية
تدعم هذه المراجع سلوك الأدوات المذكورة. الأمثلة وقرارات التصميم توضيحية، ويجب تكييفها مع متطلبات المشروع وإصداراته.
إعداد: Noor Yasser
تعمل على تحدٍ تقني مشابه؟
أساعد الفرق على تحويل القرار المعماري إلى نطاق واضح وتنفيذ يمكن تشغيله ومراجعته بثقة.
