جاء serve-sim، الذي طوره Evan Bacon من فريق نواة Expo، ليواجه هذا الحائط مباشرة. وقد ذاع صيت هذه الأداة فعلياً عندما قدّمها المطور المستقل levelsio قائلاً إنها “تتيح رؤية تطبيق iOS الذي بناه Claude Code على Mac Mini في السحابة مباشرة عبر المتصفح في الوقت الفعلي”. وشعار serve-sim بسيط: “أمر npx serve الخاص بمحاكيات آبل”.

نظرة عامة

ما يجعل serve-sim مثيراً للاهتمام هو أنه ليس مجرد أداة لعكس الشاشة. فهذه الأداة تفتح قناتين في آن واحد: الأولى هي تدفق فيديو يرسل شاشة المحاكي إلى المتصفح، والثانية قناة تحكم تتيح للمتصفح أو للوكيل التفاعل مع المحاكي. بعبارة أخرى، تجعل “المشاهدة” و”التحكم” ممكنتين عن بُعد في آن معاً.

أهمية هذا المزيج تكمن في أنه يُكمل حلقة التطوير الخاصة بوكلاء البرمجة بالذكاء الاصطناعي. يصبح بإمكان الوكيل تعديل الكود، وبناء المشروع، وتشغيله، ثم رؤية النتيجة على الشاشة، والضغط على الأزرار للانتقال إلى الخطوة التالية، وتكرار هذه الدورة الكاملة دون تدخل بشري. وهذا يتقاطع تماماً مع توجه Paxis، السحابة المخصصة للوكلاء (Agent-Native Cloud) لدى ThakiCloud، القائم على فكرة “أن ينفذ الوكيل عملاً فعلياً في بيئة معزولة”، مما يجعل من المفيد دراسة كيفية تنفيذ أداة مفتوحة المصدر واحدة لهذا النوع من سير العمل.

تصوير لبنية تحوّل شاشة المحاكي على خادم بدون واجهة رسومية إلى تدفق يصل إلى متصفح بعيد.

ما هو serve-sim

آلية عمل serve-sim أبسط وأذكى مما قد يبدو للوهلة الأولى. لا حاجة لتثبيت إضافة (plugin) خاصة في Xcode ولا لزرع كود قياس داخل التطبيق. بدلاً من ذلك، يشغّل serve-sim عملية مساعدة صغيرة مكتوبة بلغة Swift تلتقط الإطارات المرئية لمحاكي iOS المُقلع مسبقاً عبر واجهة simctl io التي توفرها آبل.

تُعرض الشاشة الملتقطة عبر مسارين. أولاً، تدفق MJPEG يرسل فيديو إلى المتصفح بمعدل يصل إلى 60 إطاراً في الثانية. ثانياً، تُفتح قناة تحكم عبر WebSocket تتيح للمتصفح إرسال مدخلات مثل النقر والإيماءات إلى المحاكي. وفوق ذلك، تُركّب واجهة معاينة مبنية بـ React تتيح للمستخدم التفاعل مع التطبيق في المتصفح وكأنه جهاز فعلي.

flowchart TB
    A[محاكي iOS مُقلَع] --> B[عملية مساعدة بلغة Swift]
    B --> C[التقاط الإطارات المرئية<br/>عبر simctl io]
    C --> D[تدفق فيديو MJPEG<br/>حتى 60 FPS]
    C --> E[قناة تحكم عبر WebSocket]
    D --> F[واجهة معاينة React في المتصفح]
    E --> F
    E --> G[سطر أوامر الوكيل<br/>نقر، إيماءات، دوران، كاميرا]
    F -.تحكم بشري.-> E
    G -.تحكم الوكيل.-> E

الجوهر هنا هو أن الأداة تعمل مع “أي محاكي مُقلَع” أياً كان. لا حاجة لتعديل التطبيق، فيمكن ربطها مباشرة بمشروع قائم بالفعل. كذلك، تنقل الأداة سجلات المحاكي إلى المتصفح، مما يتيح لأدوات MCP من فئة browser-use قراءة تلك السجلات لتقييم الحالة. وتوجد أيضاً ميزة عملية تتيح إفلات ملفات فيديو أو صور في نافذة المتصفح لتُضاف كملفات إلى جهاز المحاكي.

التثبيت والاستخدام

عتبة الدخول إلى serve-sim منخفضة. يكفي سطر واحد على جهاز Mac يحتوي على Node.js.

npx serve-sim

بعد التشغيل، يمكن مشاهدة المعاينة محلياً على http://localhost:3200. تدعم الأداة ثلاثة أنماط استخدام: محلياً، أو عبر الشبكة المحلية (LAN) من جهاز آخر على نفس الشبكة، أو على جهاز Mac بعيد مع نفق (tunnel) يتيح الوصول من أي مكان. حالة levelsio هي النمط الثالث تحديداً، حيث يعمل serve-sim على Mac Mini سحابي بدون واجهة رسومية بينما تجري المشاهدة عبر متصفح بعيد.

يُقدَّم دمج الوكلاء عبر مهارة وكيل (Agent Skill) منفصلة. هذه المهارة، الموجودة في skills/serve-sim ضمن المستودع، تعلّم Claude Code وCursor وCodex CLI وGemini CLI وأي مضيف آخر يطبّق معيار Agent Skills المفتوح كيفية التحكم في المحاكي عبر سطر الأوامر. وتشمل هذه القدرات النقر والإيماءات وأزرار الأجهزة الفعلية ودوران الشاشة وحقن مدخلات الكاميرا، إضافة إلى تمرير التدفق إلى نافذة المعاينة الخاصة بالمضيف.

ملاحظة حول إعادة الإنتاج

بيئة التنفيذ التي كُتب فيها هذا المقال هي جلسة معالجة دفعية بدون واجهة رسومية، حيث تشغيل Node.js محظور بموجب السياسة المتبعة، لذا لم يتسنَّ تشغيل npx serve-sim مباشرة والتقاط الشاشة فعلياً. وعليه، فإن الأوامر ووصف السلوك في هذا المقال مستندة إلى ما ورد في ملف README الخاص بالمستودع والمواد التعريفية الرسمية، دون اختلاق أي أرقام قياس أداء. يُنصح بالتحقق من مشهد بث المحاكي الفعلي وزمن الاستجابة الحقيقي عبر تشغيل الأمر أعلاه مباشرة في بيئة macOS مع محاكي Xcode مُقلَع.

دلالات على منتجات ThakiCloud

يبدو serve-sim للوهلة الأولى أداة موجهة لمطوري iOS، لكن خلفها يكمن تيار أوسع هو التطوير المصمم أصلاً للوكلاء (agent-native development).

عدسة Paxis (التطوير المصمم للوكلاء). Paxis من ThakiCloud هي مستوى تحكم لسحابة مخصصة للوكلاء يشغّل المهارات في صناديق رملية معزولة ويمرر كل سلوك عبر بوابات سياسات وسجلات تدقيق. ومعيار Agent Skills المفتوح الذي يعتمده serve-sim هو نفس نموذج العقد الذي تتعامل معه بنية مهارات Paxis. فكرة أن تقدّم مهارة واحدة قدرة “النقر على المحاكي وتدويره وقراءة شاشته” لعدة مضيفي وكلاء مختلفين تسير في نفس اتجاه بنية Paxis التي تختار أكثر من 960 مهارة عبر خوارزمية BM25 وتنفذها في عزل. وبشكل خاص، فإن أعباء العمل التي يتحكم فيها الوكيل فعلياً في واجهة مستخدم حقيقية، كما في قناة التحكم لدى serve-sim، لا يمكن رفعها بأمان إلى بيئة الإنتاج إلا إذا مرّ ذلك التحكم عبر بوابة سياسات وسُجّل في سجل تدقيق. إذا كان serve-sim يقدّم “القدرة”، فإن Paxis تقدّم طبقة “الضبط الآمن” لتلك القدرة.

عدسة ai-platform (بنية التنفيذ بدون واجهة رسومية). تكمن الجاذبية الحقيقية لـ serve-sim في عمله على جهاز Mac بعيد بدون واجهة رسومية. وفكرة البناء والبث على خادم بدون واجهة رسومية تشبه فلسفياً الطريقة التي تجدول بها منصة ai-platform من ThakiCloud أعباء العمل وتنفذها على Kubernetes دون الحاجة إلى واجهة رسومية. وأي خط أنابيب (pipeline) يُلحق فيه مشغّل macOS المطلوب لبناء تطبيقات iOS عند الطلب، يبني الوكيل عليه ويختبر تلقائياً، ثم يُبث النتيجة فقط إلى المستخدم البشري، يمكن أن يمتد إلى ما هو أبعد من التكامل المستمر (CI) نحو “ضمان جودة يقوده الوكيل”. وهذه بنية تجعل فيها البنية التحتية للتنفيذ بدون واجهة رسومية منخفضة التكلفة (ai-platform) ركيزة تدعم جدوى أتمتة الوكلاء اقتصادياً (Paxis).

القيود والحجج المضادة

هناك عدة نقاط ينبغي تناولها بموضوعية.

أولاً، يستهدف serve-sim المحاكي وليس الجهاز الفعلي. وبما أنه محاكٍ لا جهاز مادي حقيقي، تبقى المشكلات التي تظهر فقط على الأجهزة الفعلية، كالكاميرا والحساسات وخصائص الأداء، خارج نطاق الاكتشاف. ويبقى القيد القديم قائماً: نجاح الاختبار على المحاكي لا يضمن نجاحه على الجهاز الفعلي.

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

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

مع ذلك، فإن اتجاه serve-sim واضح. لقد أرسى جسراً عملياً حقيقياً للانتقال من “مرحلة يكتفي فيها الوكيل بكتابة الكود” إلى “مرحلة يبني فيها الوكيل ويشغّل ويتحكم مباشرة في الشاشة للتحقق”. وأي فريق يريد تطوير تطبيقات جوّال بواسطة وكلاء ذكاء اصطناعي على سحابة بدون واجهة رسومية يمكنه فتح هذا العالم فوراً بسطر واحد هو npx serve-sim.

المصادر

• Evan Bacon. “serve-sim: The npx serve of Apple Simulators.” GitHub. https://github.com/EvanBacon/serve-sim
• @levelsio، تغريدة تعريفية بـ serve-sim. https://x.com/levelsio/status/2075328941317886210

تتناول الورقة البحثية “Single-Rollout Asynchronous Optimization for Agentic Reinforcement Learning” (arXiv 2607.07508)، التي نشرها باحثون من جامعة تسينغهوا وشركة Z AI في 8 يوليو 2026، هذه النقطة مباشرة. والخلاصة أن الباحثين تخلّوا عن “أخذ العينات الجماعي” (group sampling)، وهو جوهر GRPO الشائع الاستخدام. ولم يقتصر الأمر على تجربة هذا الأسلوب في تجارب الورقة فحسب، بل طبّقوه فعلياً في خط أنابيب حقيقي لتدريب النموذج المفتوح GLM-5.2 البالغ حجمه 750B.

نظرة عامة

سبب أهمية هذه الورقة الآن هو أن عنق الزجاجة في تكلفة التدريب انتقل من الخوارزمية إلى معدل استغلال البنية التحتية. فدوال الخسارة التي تجعل النموذج أكثر ذكاءً موجودة بالفعل بأشكال متعددة. المشكلة الحقيقية هي أنه حتى مع تشغيل مئات وحدات GPU معاً، يُنفَق معظم الوقت في “الانتظار” لإنتاج خطوة تدريب واحدة فقط.

تُشغّل ThakiCloud أيضاً خمس تقنيات لما بعد التدريب، هي SFT وCPT وDPO وGRPO وGKD، ضمن نظام تدريب نماذج اللغة الكبيرة المبني على kubeflow. لذلك فإن الثمن الذي يدفعه أخذ العينات الجماعي في GRPO عند التعامل مع rollouts طويلة، والمخاطر الجديدة التي قد يجلبها أي بديل يُزيل هذا الثمن، ليست قضية بعيدة عنا. يستعرض هذا المقال ما غيّرته SAO، وما تعنيه هذه التغييرات لمؤسسة مثلنا تسعى لتدريب وكلاء على عناقيد GPU متعددة المستأجرين (multi-tenant).

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

ما هي هذه التقنية؟

يجمع اسم SAO، كما هو، بين مفهومين: “rollout واحد” (single-rollout) و”التحسين غير المتزامن” (asynchronous optimization).

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

لكن المشكلة تظهر في مهام الوكلاء. فمهمة برمجية واحدة قد تنتهي خلال 3 جولات فقط، بينما تستمر مهمة مجاورة في استدعاء الأدوات عبر 40 جولة. وفي خط الأنابيب المتزامن، تبقى بقية وحدات GPU عاطلة حتى ينتهي أبطأ rollout في الدفعة. ظهر التعلّم المعزز غير المتزامن أصلاً لإزالة هذا الهدر: يُحدَّث النموذج فور اكتمال كل rollout، بينما يستمر المولّد (generator) دون توقف في إنتاج الـ rollout التالي.

flowchart TB
    subgraph SYNC[GRPO المتزامن]
        A1[دفعة من الطلبات] --> A2[توليد G من الـ rollouts<br/>لكل طلب كمجموعة]
        A2 --> A3[الانتظار حتى اكتمال<br/>أبطأ rollout]
        A3 --> A4[حساب المكافأة النسبية للمجموعة<br/>تحديث واحد للسياسة]
        A4 -.توقف GPU.-> A2
    end
    subgraph SAO[SAO غير المتزامن]
        B1[توليد rollout واحد<br/>لكل طلب] --> B2[وصول فوري<br/>عند الاكتمال]
        B2 --> B3[كبح تحديثات off-policy<br/>عبر تقليم الرموز ثنائي الاتجاه]
        B3 --> B4[تحديث مستمر للسياسة]
        B4 --> B1
    end
    SYNC -->|إزالة حاجز المجموعة| SAO

هنا ينشأ التعارض الجوهري. فاسم GRPO (Group Relative Policy Optimization) يحمل معنى “النسبية الجماعية” منذ البداية. تُجمَع عدة rollouts لطلب واحد في مجموعة واحدة، وتُقارَن داخل هذه المجموعة الـ rollouts الأفضل نسبياً بالأسوأ لحساب الأفضلية (advantage). وميزة GRPO، التي هي في الوقت نفسه قيدها، أنها تُنتج إشارة التدريب من المقارنة داخل المجموعة فقط دون الحاجة إلى دالة قيمة (critic) منفصلة. فإن لم تكتمل المجموعة، يستحيل حساب الأفضلية. وهكذا يتعارض جوهرياً البناء غير المتزامن الذي يتعلّم فور وصول كل rollout مع GRPO الذي يفرض الانتظار حتى تكتمل المجموعة.

لماذا لا يتناسب GRPO مع التعلّم غير المتزامن؟

لنتأمل هذا التعارض بمزيد من التفصيل. فللحفاظ على المجموعة داخل خط أنابيب غير متزامن، لا مفر من أحد خيارين سيئين.

الأول هو الانتظار على مستوى المجموعة، وحينها تتلاشى ميزة اللاتزامن، وينتهي الأمر بالعودة فعلياً إلى النمط المتزامن الذي ينتظر أبطأ rollout.

والثاني هو توليد rollouts المجموعة الواحدة بسياسات (policies) مختلفة زمنياً. فإذا أنتجت سياسة قديمة بعض rollouts المجموعة، وأنتجت سياسة مُحدَّثة بعد بضع خطوات rollouts أخرى ضمن المجموعة نفسها، فإن تجميعها ومقارنتها نسبياً كمجموعة واحدة يصبح ملوّثاً إحصائياً من الأساس. فحين تتفاوت درجة off-policy من rollout إلى آخر، لكنها تُعامَل كأنها baseline واحد متجانس، يصبح التدريب غير مستقر.

إجابة SAO بسيطة: إلغاء المجموعة تماماً. يُولَّد rollout واحد فقط لكل طلب، وحالما يصل يُستخدَم مباشرة في التدريب. وبزوال حاجز المجموعة، لا يضطر المولّد إلى الانتظار إطلاقاً، فيتقلّص وقت خمول GPU بشكل كبير.

ركيزتا SAO: rollout واحد وتقليم الرموز ثنائي الاتجاه

لكن إلغاء المجموعة يعني فقدان ما كانت GRPO تحصل عليه مجاناً. فالمقارنة داخل المجموعة كانت تلعب بحد ذاتها دور baseline يُقلّل التباين. وحين يكون هناك rollout واحد فقط، يختفي معيار المقارنة القائم على “هل تفوّق هذا الـ rollout على متوسط المجموعة؟”. فضلاً عن ذلك، في البنية غير المتزامنة تنشأ فجوة زمنية بين السياسة التي أنتجت الـ rollout والسياسة التي يُراد تحديثها الآن. وهذه الفجوة، أي مشكلة off-policy، هي الخطر الثاني الذي يهدد استقرار التدريب.

تتصدى SAO لمشكلة الاستقرار هذه عبر “تقليم صارم ثنائي الاتجاه على مستوى الرمز” (strict double-side token-level clipping). فالتقليم (clipping) الذي كانت تستخدمه عائلة PPO أصلاً هو آلية تقصّ التدرّج (gradient) عندما تخرج نسبة الأهمية (importance ratio) عن نطاق محدد. وتُطبّق SAO هذا التقليم على مستوى كل رمز (token) على حدة، وبصرامة في الاتجاهين الأعلى والأسفل معاً. فعند الرموز التي تباعدت فيها rollout السياسة القديمة كثيراً عن السياسة الحالية، يُكبَح التحديث بقوة، مما يمنع الإشارات ذات الفجوة الزمنية الكبيرة من إفساد التدريب.

ونتيجة هذا المزيج، تُفيد الورقة بأن SAO واصلت التدريب باستقرار على مدى 1,000 خطوة. وإذا أخذنا بعين الاعتبار أن حالات التباعد أو الانهيار شائعة في التعلّم المعزز غير المتزامن بعد تجاوز بضع مئات من الخطوات، فإن استقرار التدريب لـ 1,000 خطوة يُعدّ دليلاً داعماً للمزاعم الأساسية لهذه الطريقة.

النتائج الفعلية والتحقق

قارنت الورقة SAO بـ GRPO ومتغيراتها، وأفادت بتفوّقها باستمرار في معايير قياس الترميز والاستدلال الخاصة بالوكلاء. والمعايير المذكورة هي SWE-Bench Verified (حل مشكلات GitHub الحقيقية)، وBeyondAIME (رياضيات عالية الصعوبة)، وIMOAnswerBench (رياضيات بمستوى الأولمبياد). وتشترك المعايير الثلاثة في كونها مهام متعددة الخطوات وطويلة النَفَس، وليست إجابات قصيرة مباشرة، وهو بالضبط المجال الذي تستهدفه SAO.

أما التحقق الأكثر إقناعاً فليس في جداول المعايير، بل في واقعة النشر ذاتها. فقد استُخدِمت SAO في خط أنابيب فعلي للتعلّم المعزز للوكلاء لتدريب النموذج المفتوح GLM-5.2 (نموذج MoE بحجم إجمالي 750B وحجم فعّال 40B من المعاملات النشطة، 750B-A40B). وكون طريقة بحثية لم تبقَ حبيسة الورقة العلمية، بل استُخدِمت في تدريب إنتاجي لنموذج بحجم مئات المليارات، إشارة قوية على أن هذه الطريقة تصمد عند المقياس الحقيقي، لا في إعدادات تجريبية صغيرة فقط.

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

دلالات التطبيق على منتجات ThakiCloud

لا يقتصر درس SAO على كونه ورقة خوارزمية واحدة، بل يمسّ مباشرة طريقة تشغيل عناقيد GPU.

عدسة ai-platform (البنية التحتية لتدريب GPU). تجدول منصة ai-platform التابعة لـ ThakiCloud تدريب GPU متعدد المستأجرين فوق Kubernetes وKueue. ونظام تدريب نماذج اللغة الكبيرة المبني على kubeflow يدعم بالفعل GRPO كأحد تقنيات ما بعد التدريب. والسؤال الذي تطرحه SAO واضح: كم يتراجع معدل استغلال GPU في مهام تدريبنا بسبب التفاوت في أطوال الـ rollouts؟ ففي المهام المتفاوتة الطول كـ rollouts الوكلاء، يتحوّل انتظار المجموعة المتزامن إلى تكلفة مباشرة. وفصل توليد الـ rollouts غير المتزامن عن التدريب يتيح استخلاص خطوات تدريب فعّالة أكثر من العدد نفسه من وحدات GPU، وهو ما يشكّل رافعة مباشرة لخفض تكلفة التدريب لكل مستأجر في بيئة متعددة المستأجرين. كما أن التحقق مما إذا كانت جدولة gang scheduling وإدارة الطوابير في Kueue تفرض نمط “الانتظار حتى تكتمل المجموعة” يُعدّ نقطة تحسين عملية أخرى.

عدسة Paxis (نتاج تدريب الوكلاء). Paxis، وهي منصة Agent-Native Cloud التابعة لـ ThakiCloud، مستوى تحكّم يُشغّل المهارات (skills) في صناديق رملية معزولة (sandbox) ويمرّر كل سلوك عبر بوابات سياسات وسجلات تدقيق. والوكيل الذي تسعى SAO لتدريبه جيداً، أي وكيل يستدعي الأدوات عبر جولات متعددة ويُصلح قواعد الأكواد، هو بالضبط عبء العمل الذي تُشغّله Paxis. بل إن آثار الوكلاء (agent traces) الفعلية التي تُولّدها Paxis داخل الصناديق الرملية المعزولة يمكن أن تكون بحدّ ذاتها مصدر rollouts للتعلّم المعزز غير المتزامن على غرار SAO. وبذلك تكتمل حلقة: تُنتج ai-platform الـ rollouts وتدرّب عليها بتكلفة منخفضة، وتُشغّل Paxis الوكيل الناتج بأمان، لتُولّد بدورها بيانات تدريب جديدة. إنها بنية تقوم فيها بنية التدريب منخفضة التكلفة (ai-platform) بدعم جدوى الوكلاء الاقتصادية (Paxis).

القيود والاعتراضات

قبل تبنّي هذه الطريقة دون تمحيص، ينبغي التوقف عند بضع نقاط.

أولاً، يتخلّى الـ rollout الواحد عن تقليل التباين الذي كانت توفّره المجموعة. وتُعوّض SAO عن ذلك بالتقليم، لكن التقليم بطبيعته آلية تقصّ إشارة التدريب. فالتقليم الصارم أكثر مما ينبغي قد يُلقي حتى بالتدرّجات الصالحة، مما يُبطئ التدريب. ونقطة التوازن بين “الاستقرار” و”سرعة التعلّم” قابلة للتغيّر بشكل كبير تبعاً للمهمة والمقياس.

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

ثالثاً، توجد مقاربات نشطة في الاتجاه المعاكس أيضاً. فقد ظهرت في الفترة نفسها دراسة تتناول العلاقة بين staleness ومعدل التعلّم في RLHF غير المتزامن عبر قوانين تحجيم (scaling laws) (arXiv 2607.01083)، كما ظهرت مقاربات تُثبّت التدريب غير المتزامن عبر محاذاة التدرّجات (gradient alignment). ولذلك فالأدق أن نعتبر مبدأ SAO القائم على “إلغاء المجموعة وكبح ذلك بالتقليم” واحداً من عدة إجابات قوية محتملة على مسألة مفتوحة هي التعلّم المعزز غير المتزامن للوكلاء، لا الإجابة الوحيدة الصحيحة.

ومع ذلك، فإن إسهام SAO واضح. فقد حدّدت المشكلة بدقة (عدم كفاءة أخذ العينات الجماعي عند طول الـ rollouts)، وتحقّقت من الحل (rollout واحد مع تقليم ثنائي الاتجاه) عبر تدريب إنتاجي فعلي بمقياس مئات المليارات من المعاملات. وأي مؤسسة يمثّل فيها معدل استغلال GPU تكلفة التدريب مباشرة، لديها سبب وجيه لحساب المبلغ الذي يُهدَر في خط أنابيبها بسبب “انتظار المجموعة”.

المصادر

• Zhenyu Hou, Yujiang Li, Jie Tang, Yuxiao Dong. “Single-Rollout Asynchronous Optimization for Agentic Reinforcement Learning.” arXiv 2607.07508 (2026-07-08). https://arxiv.org/abs/2607.07508
• ذو صلة: “Staleness-Learning Rate Scaling Laws for Asynchronous RLHF.” arXiv 2607.01083. https://arxiv.org/abs/2607.01083

Source: RT @hangoo_kang: “TRACE: Capability-Targeted Agentic Training” got Spotlight @ ICML AIWILD 🎉 · twitter

What this means for ThakiCloud

This lines up neatly with what ThakiCloud has been building. Paxis conducts the agents; Metis retrains the ones that come up short. TRACE says: diagnose your failures and retrain just the weak spot. But those failure logs are among the most sensitive things a company owns. Ship them to someone else’s cloud to train on, and both the weakness and the fix leak out with them. That is the case for on-prem and for sovereignty: keeping your models, data, and infrastructure under your own roof. Fix your flaws at home and they stay home. For what it is worth, this very blog runs on a self-improvement loop that reviews its own misses and resharpens.

An auto-generated comic riffing on this week’s industry news.

serve-sim, built by Evan Bacon of the Expo core team, aims straight at that wall. It became widely known after indie developer levelsio showed it off, saying it let him “watch, in a browser, in real time, an iOS app that Claude Code built on a cloud Mac Mini.” Its slogan is simple: “npx serve for Apple Simulators.”

Overview

What makes serve-sim interesting is that it is not just a screen-mirroring tool. It opens two things at once: a video stream that sends the simulator screen to a browser, and a control channel that lets a browser or an agent operate the simulator. In other words, it makes both “watching” and “operating” possible remotely.

That combination matters because it completes the development loop for AI coding agents. An agent can fix code, build it, run it, look at the resulting screen, tap a button to move to the next step, and cycle through all of that without a human in the loop. This lines up exactly with what ThakiCloud’s Agent-Native Cloud, Paxis, is aiming for: agents doing real work inside isolated environments. That makes it worth a closer look at how one open-source tool implements that workflow.

A visualization of a headless server’s simulator screen becoming a stream that flows into a remote browser.

What serve-sim Is

The way serve-sim works is simpler and more clever than it sounds. There is no separate Xcode plugin to install, and no instrumentation code to embed in the app. Instead it spins up a small Swift helper process that captures the framebuffer of an already-booted iOS Simulator through Apple’s own simctl io interface.

The captured screen is exposed in two ways. First, it sends the video to the browser as an MJPEG stream at up to 60 FPS. Second, it opens a WebSocket control channel alongside it, so input from the browser side, taps and gestures, can be sent back to the simulator. On top of that sits a React-based preview UI, so a person can operate the app in the browser as if it were a real device.

flowchart TB
    A[Booted iOS Simulator] --> B[Swift helper process]
    B --> C[Captures framebuffer<br/>via simctl io]
    C --> D[MJPEG video stream<br/>up to 60 FPS]
    C --> E[WebSocket control channel]
    D --> F[Browser React preview UI]
    E --> F
    E --> G[Agent CLI<br/>tap, gesture, rotate, camera]
    F -.human operates.-> E
    G -.agent operates.-> E

The key point is that it targets “any booted simulator.” Since it requires no modification to the app, it can be attached to an existing project as-is. It can also forward simulator logs to the browser, so browser-use style MCP tools can read those logs to judge state. There is even a convenience feature where dragging a video or image into the browser window adds it as a file on the simulator device.

Installation and Use

The barrier to entry for serve-sim is low. On a Mac with Node.js, one line is enough.

npx serve-sim

Once running, you can view the preview at http://localhost:3200 locally. It supports three modes: using it locally, connecting from another device on the same LAN, or hosting it on a remote Mac and reaching it from anywhere through a tunnel. levelsio’s case is the third mode: running it on a headless Mac Mini in the cloud and viewing it through a remote browser.

Agent integration is provided as a separate Agent Skill. This skill, packaged at skills/serve-sim in the repository, teaches any host that implements the open Agent Skills standard, including Claude Code, Cursor, Codex CLI, and Gemini CLI, how to operate the simulator through the CLI. That includes taps, gestures, hardware buttons, screen rotation, injecting camera input, and handing the stream off to the host’s own preview window.

A Note on Reproduction

This post was written in a headless batch session with no GUI, where running Node.js is blocked by policy, so we were not able to run npx serve-sim directly ourselves and capture the screen. The commands and behavior described in this post are therefore based on facts confirmed in the repository README and the official announcement material, and we have not fabricated any benchmark numbers. Please verify the actual simulator streaming screen and latency yourself, on a macOS machine with a booted Xcode Simulator, using the commands above.

Implications for ThakiCloud Products

On the surface, serve-sim is a tool for iOS developers, but underneath it sits a much bigger trend: agent-native development.

Paxis lens (agent-native development). ThakiCloud’s Paxis is an Agent-Native Cloud control plane that runs skills in isolated sandboxes and passes every action through policy gates and audit logs. The open Agent Skills standard that serve-sim adopts is the same kind of contract model that Paxis’s skill harness handles. The idea that a single skill can give “tap, rotate, and read the screen of a simulator” capability to multiple agent hosts points in exactly the same direction as Paxis’s structure of selecting from 960-plus skills via BM25 and running them in isolation. In particular, workloads where an agent operates a real UI, like serve-sim’s control channel, need those operations to pass through policy gates and be recorded in audit logs before they can safely go into production. If serve-sim provides the “capability,” Paxis provides the layer that “safely governs” that capability.

ai-platform lens (headless execution infrastructure). What really makes serve-sim compelling is that it runs on a headless, remote Mac. The idea of building and streaming from a GUI-less server shares its philosophy with how ThakiCloud’s ai-platform schedules and runs workloads on Kubernetes without a GUI. A pipeline that attaches macOS runners on demand for iOS builds, lets an agent automatically build and test on top of them, and streams only the results back to a human, could extend beyond CI into “agent-driven QA.” It is a structure where low-cost headless execution infrastructure (ai-platform) underpins the economics of agent automation (Paxis).

Limits and Counterarguments

A few things deserve a sober look.

First, serve-sim targets the simulator. Because it is a simulator and not a physical device, issues that only surface on real hardware, camera, sensors, performance characteristics, still go uncaught. The old limitation that passing on the simulator does not guarantee passing on a real device remains unchanged.

Second, MJPEG streaming is simple and compatible but not very efficient at compression. Continuously streaming a 60 FPS, high-quality feed over a remote tunnel can turn bandwidth and latency into a bottleneck. For gesture testing where responsiveness matters, network round-trip delay translates directly into input lag.

Third, an agent being able to “see and operate” the screen is a separate matter from that judgment being correct. It remains entirely possible for an agent to misread the stream and tap the wrong button, and this is exactly why policy gates and human review are needed. The more capability a tool opens up, the more important the layer that governs that capability becomes.

Even so, serve-sim’s direction is clear. It has built a real bridge needed to move from “the agent only writes code” to “the agent builds, runs, and verifies by directly operating the screen.” If you are a team trying to develop mobile apps with agents from a headless cloud, you can open that world right now with a single line: npx serve-sim.

Sources

• Evan Bacon. “serve-sim: The npx serve of Apple Simulators.” GitHub. https://github.com/EvanBacon/serve-sim
• @levelsio, tweet introducing serve-sim. https://x.com/levelsio/status/2075328941317886210

A paper released on July 8, 2026 by researchers at Tsinghua University and Z AI, “Single-Rollout Asynchronous Optimization for Agentic Reinforcement Learning” (arXiv 2607.07508), confronts exactly this problem. The short version: the authors dropped “group sampling,” the core mechanism behind the widely used GRPO. And they did not leave this idea confined to a paper’s experiments section. They put it into the actual pipeline used to train GLM-5.2, a 750B-scale open model.

Overview

This paper matters right now because the cost bottleneck in training has shifted from algorithms to infrastructure utilization. Plenty of loss functions already exist to make models smarter. The real problem is that even with hundreds of GPUs wired together, most of the time it takes to produce a single training step is spent waiting.

ThakiCloud also runs five post-training techniques (SFT, CPT, DPO, GRPO, GKD) on our kubeflow-based LLM training system. So the price GRPO’s group sampling pays on long rollouts, and the new risks that arise from the alternative that removes that price, are not someone else’s problem. This post lays out what SAO changed, and what that change means for organizations like ours trying to train agents on multi-tenant GPU clusters.

A visualization contrasting single rollouts arriving continuously, one after another, against rollouts frozen in a queue while waiting for the rest of a group to arrive.

What Is This Technology

As the name suggests, SAO combines two ideas: “single-rollout” and “asynchronous optimization.”

The standard RL pipeline used to be synchronous. You fix a batch of prompts, generate multiple rollouts per prompt, wait until every rollout in the batch finishes, compute the rewards, and perform a single policy update. This worked fine for tasks that generate short answers, because rollout lengths were roughly uniform.

The problem is agentic tasks. One coding task finishes in 3 turns; the task next to it runs 40 turns, calling tools the whole way. A synchronous pipeline idles the rest of the GPUs until the slowest rollout in the batch finishes. Asynchronous RL emerged to eliminate this waste: the moment a rollout completes, the model is updated immediately, and the generator never stops, moving straight on to the next rollout.

flowchart TB
    subgraph SYNC[Synchronous GRPO]
        A1[Prompt batch] --> A2[Generate G rollouts<br/>per prompt as a group]
        A2 --> A3[Wait for<br/>the slowest rollout]
        A3 --> A4[Compute group-relative reward<br/>single policy update]
        A4 -.GPU idle.-> A2
    end
    subgraph SAO[SAO Async]
        B1[Generate 1 rollout<br/>per prompt] --> B2[Arrives immediately<br/>upon completion]
        B2 --> B3[Suppress off-policy updates<br/>via double-side token clipping]
        B3 --> B4[Continuous policy updates]
        B4 --> B1
    end
    SYNC -->|Remove the group barrier| SAO

Here a fundamental conflict emerges. GRPO (Group Relative Policy Optimization) is “group-relative” by name. It bundles multiple rollouts for a single prompt into a group, and computes advantage by comparing the relatively better and worse rollouts within that group. Making learning signal from nothing but intra-group comparison, with no separate value function (critic), is both GRPO’s strength and its shackle. Without a full group, you cannot compute an advantage. An asynchronous structure that learns from rollouts as they arrive, and GRPO’s requirement to wait until the group fills, are fundamentally at odds.

Why GRPO Doesn’t Fit Asynchronous Training

Let’s look at this conflict more concretely. To preserve groups in an asynchronous pipeline, you are forced into one of two bad choices.

First, you could wait group by group. But then the benefit of asynchrony disappears. You end up back at synchronous training, waiting for the slowest rollout.

Second, you could let the rollouts within a group be generated by policies from different points in time. If one rollout in a group was produced by an old policy and another by a policy updated several steps later, grouping them together for relative comparison is statistically contaminated from the start. The degree of off-policy drift differs rollout by rollout, and treating them as a single shared baseline while ignoring that difference destabilizes training.

SAO’s answer is simple. Remove the group entirely. Generate exactly one rollout per prompt, and the moment that single rollout arrives, use it for training right away. With the group barrier gone, the generator never waits, and GPU idle time drops sharply.

SAO’s Two Pillars: Single Rollout and Double-Side Token Clipping

But removing the group also removes something GRPO got for free. The intra-group comparison itself served as a variance-reducing baseline. With only one rollout, there is no longer a “did this rollout beat the group average” comparison to lean on. On top of that, in an asynchronous structure, a time lag opens up between the policy that produced the rollout and the policy currently being updated. This lag, the off-policy problem, is the second risk that can destabilize training.

SAO blocks this stability problem with what it calls “strict double-side token-level clipping.” The clipping used in the PPO family originally cuts the gradient when the importance ratio strays outside a certain range. SAO applies this at the token level, and strictly on both the upper and lower sides. Where a rollout produced by an old policy has drifted too far from the current policy at a given token, the update is strongly suppressed there, preventing a high-staleness signal from corrupting training.

The paper reports that this combination let SAO train stably for 1,000 steps. Given that asynchronous RL runs commonly diverge or collapse after a few hundred steps, 1,000 stable steps is solid evidence backing the method’s central claim.

Results and Verification

The paper compares SAO against GRPO and its variants, and reports consistent gains on agentic coding and reasoning benchmarks. The benchmarks named are SWE-Bench Verified (resolving real GitHub issues), BeyondAIME (hard math), and IMOAnswerBench (olympiad-level math). All three share a common trait: they are long-horizon, multi-step tasks rather than short one-shot answers, exactly the territory SAO targets.

The most convincing validation is not a benchmark table, but the deployment itself. SAO was put into the actual agentic RL pipeline used to train GLM-5.2, a 750B-A40B MoE open model with 40B active parameters. A research method that does not stay confined to a paper, but gets used in production training at hundreds-of-billions-of-parameters scale, is a strong signal that it holds up beyond toy settings.

That said, this post does not cite specific benchmark numbers. If we cannot reproduce the exact figures verified in the original paper here, the honest choice is to convey the method’s structure and the named benchmarks without inventing numbers. If you need the precise scores, please check the source paper directly.

Implications for ThakiCloud’s Product Lineup

SAO’s lesson reaches beyond a single algorithms paper, touching directly on how we operate our GPU clusters.

ai-platform lens (GPU training infrastructure). ThakiCloud’s ai-platform schedules multi-tenant GPU training on top of Kubernetes and Kueue. Our kubeflow-based LLM training system already supports GRPO as one of its post-training techniques. SAO raises a clear question: how much is our training jobs’ GPU utilization being eroded by variance in rollout length? For workloads with jagged lengths, like agentic rollouts, synchronous group waiting is a direct cost. Decoupling asynchronous rollout generation from training lets us extract more effective steps from the same GPUs, a direct lever for lowering the per-tenant cost of training in a multi-tenant environment. It is also worth checking whether Kueue’s gang scheduling and queue management inadvertently enforce the “wait until the group fills” pattern.

Paxis lens (the output of agentic training). ThakiCloud’s Agent-Native Cloud, Paxis, is a control plane that runs skills inside isolated sandboxes and routes every action through policy gates and audit logs. The target SAO is trying to train well, an agent that calls tools across many turns to fix a codebase, is exactly the kind of workload Paxis runs. Going further, the real agent traces Paxis generates inside its isolated sandboxes can themselves become a rollout source for asynchronous RL like SAO. In other words, a loop forms: ai-platform generates and trains on rollouts cheaply, and Paxis operates the resulting agents safely while producing more training data in the process. Low-cost training infrastructure (ai-platform) underpins agent economics (Paxis).

Limitations and Counterarguments

Before accepting this method uncritically, a few things need to be flagged.

First, single-rollout training gives up the variance reduction that groups used to provide. SAO compensates with clipping, but clipping is fundamentally a mechanism that cuts learning signal. Overly strict clipping can throw away valid gradients along with the noise, slowing training down. Where the balance point between “stability” and “training speed” lands likely varies by task and scale.

Second, validation on a 750B model is impressive, but that it works at that scale does not mean it is optimal for smaller organizations’ setups. An asynchronous pipeline requires separate infrastructure complexity to decouple the generator from the trainer. For a team doing short tuning runs with a handful of rollouts, synchronous GRPO may simply be simpler and sufficient.

Third, the opposite direction is also being actively explored. Around the same time, other work has treated the relationship between async RLHF staleness and learning rate as a scaling law (arXiv 2607.01083), and other approaches stabilize asynchronous training through gradient alignment. It is more accurate to view SAO’s “remove the group, hold the line with clipping” not as the one correct answer, but as one strong answer among several to the open problem of asynchronous agentic RL.

Even so, SAO’s contribution is clear. It identified the problem precisely (the inefficiency of group sampling on long rollouts), and validated its solution (single rollout plus double-side clipping) through actual hundreds-of-billions-scale production training. For any organization where GPU utilization is training cost, this is reason enough to calculate how much your own pipeline is burning by “waiting for the group.”

Sources

• Zhenyu Hou, Yujiang Li, Jie Tang, Yuxiao Dong. “Single-Rollout Asynchronous Optimization for Agentic Reinforcement Learning.” arXiv 2607.07508 (2026-07-08). https://arxiv.org/abs/2607.07508
• Related: “Staleness-Learning Rate Scaling Laws for Asynchronous RLHF.” arXiv 2607.01083. https://arxiv.org/abs/2607.01083

Expo 코어 팀의 Evan Bacon이 만든 serve-sim은 이 벽을 정면으로 겨냥합니다. 실제로 이 도구는 인디 개발자 levelsio가 “클라우드의 Mac Mini에서 Claude Code가 빌드한 iOS 앱을 브라우저로 실시간 확인할 수 있게 됐다”고 소개하면서 널리 알려졌습니다. serve-sim의 슬로건은 간단합니다. “Apple 시뮬레이터의 npx serve.”

개요

serve-sim이 흥미로운 이유는 단순한 화면 미러링 도구가 아니기 때문입니다. 이 도구는 두 가지를 동시에 엽니다. 하나는 시뮬레이터 화면을 브라우저로 보내는 영상 스트림이고, 다른 하나는 브라우저나 에이전트가 시뮬레이터를 조작하도록 하는 제어 채널입니다. 즉 “보는 것”과 “조작하는 것”을 모두 원격에서 가능하게 만듭니다.

이 조합이 중요한 이유는 AI 코딩 에이전트의 개발 루프를 완성하기 때문입니다. 에이전트가 코드를 고치고, 빌드하고, 실행한 뒤, 그 결과 화면을 보고, 버튼을 눌러 다음 단계로 넘어가는 전체 순환을 사람 없이 돌릴 수 있게 됩니다. ThakiCloud의 Agent-Native Cloud인 Paxis가 지향하는 “에이전트가 격리된 환경에서 실제 작업을 수행하는” 구조와 정확히 맞닿아 있어, 하나의 오픈소스 도구가 그 워크플로를 어떻게 구현하는지 살펴볼 가치가 있습니다.

헤드리스 서버의 시뮬레이터 화면이 스트림이 되어 원격 브라우저로 흘러 들어가는 구조를 형상화했습니다.

serve-sim은 무엇인가

serve-sim의 동작 원리는 생각보다 단순하고 영리합니다. 별도의 Xcode 플러그인을 설치하거나 앱에 계측 코드를 심을 필요가 없습니다. 대신 작은 Swift 헬퍼 프로세스를 띄워, 이미 부팅된 iOS 시뮬레이터의 프레임버퍼를 애플이 제공하는 simctl io 인터페이스로 캡처합니다.

캡처한 화면은 두 갈래로 노출됩니다. 첫째, MJPEG 스트림으로 브라우저에 최대 60 FPS의 영상을 보냅니다. 둘째, WebSocket 제어 채널을 함께 열어 브라우저 쪽에서 탭·제스처 같은 입력을 시뮬레이터로 되돌려 보냅니다. 그 위에 React로 만든 프리뷰 UI가 얹혀, 사람이 브라우저에서 실제 기기처럼 앱을 만질 수 있습니다.

flowchart TB
    A[부팅된 iOS 시뮬레이터] --> B[Swift 헬퍼 프로세스]
    B --> C[simctl io로<br/>프레임버퍼 캡처]
    C --> D[MJPEG 영상 스트림<br/>최대 60 FPS]
    C --> E[WebSocket 제어 채널]
    D --> F[브라우저 React 프리뷰 UI]
    E --> F
    E --> G[에이전트 CLI<br/>탭·제스처·회전·카메라]
    F -.사람이 조작.-> E
    G -.에이전트가 조작.-> E

핵심은 “어떤 부팅된 시뮬레이터든” 대상이 된다는 점입니다. 앱을 수정할 필요가 없으므로, 이미 있는 프로젝트에 그대로 붙일 수 있습니다. 게다가 시뮬레이터 로그를 브라우저로 전달해, browser-use 계열 MCP 도구가 그 로그를 읽어 상태를 판단하게 할 수도 있습니다. 브라우저 창에 영상·이미지를 드래그 앤 드롭하면 시뮬레이터 기기에 파일로 추가되는 편의 기능도 있습니다.

설치 및 사용

serve-sim의 진입 장벽은 낮습니다. Node.js가 있는 맥에서 한 줄이면 됩니다.

npx serve-sim

실행하면 로컬 http://localhost:3200에서 프리뷰를 확인할 수 있습니다. 로컬에서 쓰거나, LAN을 통해 같은 네트워크의 다른 기기에서 접속하거나, 원격 맥에 올려 두고 터널링으로 어디서든 접속하는 세 가지 모드를 지원합니다. levelsio의 사례가 바로 세 번째로, 클라우드의 헤드리스 Mac Mini에서 실행하고 원격 브라우저로 확인하는 방식입니다.

에이전트 통합은 별도의 Agent Skill로 제공됩니다. 저장소의 skills/serve-sim에 담긴 이 스킬은 Claude Code·Cursor·Codex CLI·Gemini CLI를 비롯해 오픈 Agent Skills 표준을 구현한 모든 호스트에게 시뮬레이터를 CLI로 조작하는 방법을 가르칩니다. 탭, 제스처, 하드웨어 버튼, 화면 회전, 카메라 입력 주입, 그리고 스트림을 호스트의 프리뷰 창으로 넘기는 동작까지 포함됩니다.

재현 참고

이 글을 작성한 실행 환경은 GUI가 없는 헤드리스 배치 세션으로, Node.js 실행이 정책상 차단되어 있어 npx serve-sim을 직접 구동해 화면을 캡처하지는 못했습니다. 따라서 이 글의 명령과 동작 설명은 저장소 README와 공식 소개 자료에서 확인한 사실에 근거하며, 벤치마크 수치를 지어내지 않았습니다. 실제 시뮬레이터 스트리밍 화면과 지연 시간은 macOS + Xcode 시뮬레이터가 부팅된 환경에서 위 명령으로 직접 확인하시기 바랍니다.

ThakiCloud 제품 적용 시사점

serve-sim은 표면적으로는 iOS 개발자용 도구지만, 그 아래에는 에이전트 네이티브 개발이라는 더 큰 흐름이 깔려 있습니다.

Paxis 렌즈 (에이전트 네이티브 개발). ThakiCloud의 Paxis는 스킬을 격리 샌드박스에서 실행하고 모든 행동을 정책 게이트와 감사 로그로 통과시키는 Agent-Native Cloud 제어 평면입니다. serve-sim이 채택한 개방형 Agent Skills 표준은 Paxis의 스킬 하네스가 다루는 것과 같은 계약 모델입니다. 하나의 스킬이 “시뮬레이터를 탭하고 회전시키고 화면을 읽는” 능력을 여러 에이전트 호스트에 공통으로 제공한다는 발상은, Paxis가 960개 이상의 스킬을 BM25로 선택해 격리 실행하는 구조와 정확히 같은 방향을 향합니다. 특히 serve-sim의 제어 채널처럼 에이전트가 실제 UI를 조작하는 워크로드는, 그 조작이 정책 게이트를 통과하고 감사 로그로 기록되어야 안전하게 프로덕션에 올릴 수 있습니다. serve-sim이 “능력”을 제공한다면, Paxis는 그 능력을 “안전하게 통제”하는 계층을 제공합니다.

ai-platform 렌즈 (헤드리스 실행 인프라). serve-sim의 진짜 매력은 헤드리스 원격 맥에서 동작한다는 점입니다. GUI 없는 서버에서 빌드하고 스트리밍한다는 발상은 ThakiCloud ai-platform이 Kubernetes 위에서 워크로드를 GUI 없이 스케줄링하고 실행하는 방식과 같은 철학입니다. iOS 빌드가 요구하는 macOS 러너를 온디맨드로 붙이고, 그 위에서 에이전트가 빌드·테스트를 자동으로 돌린 뒤 결과만 사람에게 스트리밍하는 파이프라인은 CI를 넘어 “에이전트 주도 QA”로 확장될 수 있습니다. 저비용 헤드리스 실행 인프라(ai-platform)가 에이전트 자동화(Paxis)의 경제성을 떠받치는 구조입니다.

한계 및 반론

몇 가지는 냉정하게 짚어야 합니다.

첫째, serve-sim은 시뮬레이터를 대상으로 합니다. 실제 물리 기기가 아니라 시뮬레이터이므로, 카메라·센서·성능 특성처럼 실기기에서만 드러나는 문제는 여전히 잡지 못합니다. 시뮬레이터 통과가 실기기 통과를 보장하지 않는다는 오래된 한계는 그대로 남습니다.

둘째, MJPEG 스트리밍은 단순하고 호환성이 좋지만 압축 효율이 높지 않습니다. 60 FPS 고화질 스트림을 원격 터널로 계속 흘리면 대역폭과 지연이 병목이 될 수 있습니다. 반응 속도가 중요한 제스처 테스트에서는 네트워크 왕복 지연이 그대로 조작 지연으로 이어집니다.

셋째, 에이전트가 화면을 “보고 조작”할 수 있게 되는 것과, 그 판단이 정확한 것은 별개입니다. 에이전트가 스트림을 잘못 해석해 엉뚱한 버튼을 누르는 실패는 여전히 가능하며, 이 지점이 바로 정책 게이트와 사람 검토가 필요한 이유입니다. 도구가 능력을 열어 줄수록, 그 능력을 통제하는 계층의 중요성이 커집니다.

그럼에도 serve-sim의 방향은 분명합니다. “에이전트가 코드만 쓰는 단계”에서 “에이전트가 빌드하고 실행하고 직접 화면을 조작하며 검증하는 단계”로 넘어가는 데 필요한 실질적인 다리를 하나 놓았습니다. 헤드리스 클라우드에서 모바일 앱을 에이전트로 개발하려는 팀이라면, 지금 바로 npx serve-sim 한 줄로 그 세계를 열어 볼 수 있습니다.

관련 슬라이드

본문 내용을 NotebookLM(neo_swiss 스타일)으로 요약한 슬라이드입니다.

출처

• Evan Bacon. “serve-sim: The npx serve of Apple Simulators.” GitHub. https://github.com/EvanBacon/serve-sim
• @levelsio, serve-sim 소개 트윗. https://x.com/levelsio/status/2075328941317886210

칭화대와 Z AI 연구진이 2026년 7월 8일 공개한 논문 “Single-Rollout Asynchronous Optimization for Agentic Reinforcement Learning”(arXiv 2607.07508)은 바로 그 지점을 정면으로 다룹니다. 결론부터 말하면, 이들은 널리 쓰이는 GRPO의 핵심인 “그룹 샘플링”을 버렸습니다. 그리고 이 방식을 논문 속 실험에만 남겨 두지 않고, 750B 규모의 오픈 모델 GLM-5.2를 학습하는 실제 파이프라인에 투입했습니다.

개요

이 논문이 지금 중요한 이유는 학습 비용의 병목이 알고리즘이 아니라 인프라 활용률로 옮겨 갔기 때문입니다. 모델을 더 똑똑하게 만드는 손실 함수는 이미 여럿 나와 있습니다. 진짜 문제는 GPU 수백 장을 붙여 놓고도, 학습 스텝 하나를 만들기 위해 대부분의 시간을 “기다리는 데” 쓴다는 점입니다.

ThakiCloud도 kubeflow 기반의 LLM 학습 시스템에서 SFT·CPT·DPO·GRPO·GKD 다섯 가지 사후학습 기법을 운용합니다. 그래서 GRPO의 그룹 샘플링이 긴 롤아웃에서 어떤 대가를 치르는지, 그리고 그 대가를 없애는 대안이 어떤 새로운 위험을 부르는지는 남의 이야기가 아닙니다. 이 글은 SAO가 무엇을 바꿨고, 그 변경이 우리처럼 멀티테넌트 GPU 클러스터에서 에이전트를 학습하려는 조직에 무엇을 의미하는지를 정리합니다.

연속적으로 하나씩 도착하는 단일 롤아웃과, 그룹이 다 찰 때까지 큐에서 얼어붙어 기다리는 롤아웃을 대비해 형상화했습니다.

이 기술은 무엇인가

SAO는 이름 그대로 두 가지를 결합합니다. “단일 롤아웃(single-rollout)”과 “비동기 최적화(asynchronous optimization)”입니다.

기존의 표준적인 RL 파이프라인은 동기식(synchronous)이었습니다. 한 배치의 프롬프트를 정하고, 각 프롬프트마다 여러 개의 롤아웃을 생성하고, 그 롤아웃이 전부 끝나면 보상을 계산해 한 번의 정책 업데이트를 수행합니다. 짧은 답변을 생성하는 작업에서는 이 방식이 잘 돌아갔습니다. 롤아웃 길이가 엇비슷했기 때문입니다.

문제는 에이전트 작업입니다. 하나의 코딩 태스크는 3턴 만에 끝나고, 옆의 태스크는 40턴을 돌면서 도구를 계속 호출합니다. 동기식 파이프라인은 배치 안에서 가장 느린 롤아웃이 끝날 때까지 나머지 GPU를 놀립니다. 비동기 RL은 이 낭비를 없애려고 등장했습니다. 롤아웃이 완성되는 대로 즉시 모델을 업데이트하고, 생성기는 멈추지 않고 다음 롤아웃을 계속 만듭니다.

flowchart TB
    subgraph SYNC[동기식 GRPO]
        A1[프롬프트 배치] --> A2[프롬프트마다<br/>그룹 롤아웃 G개 생성]
        A2 --> A3[가장 느린 롤아웃까지<br/>전부 대기]
        A3 --> A4[그룹 상대 보상 계산<br/>정책 1회 업데이트]
        A4 -.GPU 유휴.-> A2
    end
    subgraph SAO[SAO 비동기]
        B1[프롬프트마다<br/>롤아웃 1개 생성] --> B2[완성되는 대로<br/>즉시 도착]
        B2 --> B3[양방향 토큰 클리핑으로<br/>off-policy 갱신 억제]
        B3 --> B4[정책 연속 업데이트]
        B4 --> B1
    end
    SYNC -->|그룹 장벽 제거| SAO

여기서 근본적인 충돌이 발생합니다. GRPO(Group Relative Policy Optimization)는 이름부터 “그룹 상대”입니다. 한 프롬프트에 대해 여러 롤아웃을 묶어 그룹을 만들고, 그 그룹 안에서 상대적으로 잘한 롤아웃과 못한 롤아웃을 비교해 우위(advantage)를 계산합니다. 별도의 가치 함수(critic) 없이 그룹 내부 비교만으로 학습 신호를 만드는 것이 GRPO의 장점이자, 동시에 족쇄입니다. 그룹이 다 채워지지 않으면 우위를 계산할 수 없기 때문입니다. 롤아웃이 도착하는 대로 학습하는 비동기 구조와, 그룹이 다 찰 때까지 기다려야 하는 GRPO는 근본적으로 어긋납니다.

왜 GRPO는 비동기 학습에 맞지 않는가

이 어긋남을 조금 더 구체적으로 보겠습니다. 비동기 파이프라인에서 그룹을 유지하려면 두 가지 나쁜 선택 중 하나를 강요받습니다.

첫째, 그룹 단위로 기다리는 것입니다. 그러면 비동기의 이점이 사라집니다. 결국 가장 느린 롤아웃을 기다리는 동기식으로 되돌아갑니다.

둘째, 그룹의 롤아웃들을 서로 다른 시점의 정책으로 생성하는 것입니다. 하나의 그룹 안에서 어떤 롤아웃은 오래된 정책이, 어떤 롤아웃은 몇 스텝 갱신된 정책이 만들었다면, 이들을 같은 그룹으로 묶어 상대 비교하는 것 자체가 통계적으로 오염됩니다. off-policy 정도가 롤아웃마다 다른데 이를 무시하고 하나의 baseline으로 취급하면 학습이 불안정해집니다.

SAO의 답은 단순합니다. 그룹을 아예 없애는 것입니다. 프롬프트마다 롤아웃을 하나만 생성하고, 그 하나가 도착하면 바로 학습에 씁니다. 그룹 장벽이 사라지므로 생성기는 절대 기다리지 않고, GPU 유휴 시간이 크게 줄어듭니다.

SAO의 두 축: 단일 롤아웃과 양방향 토큰 클리핑

그런데 그룹을 없애면 GRPO가 공짜로 얻던 것을 잃습니다. 그룹 내부 비교는 그 자체로 분산을 줄이는 baseline 역할을 했습니다. 롤아웃이 하나뿐이면 “이 롤아웃이 그룹 평균보다 잘했는가”라는 비교 기준이 사라집니다. 게다가 비동기 구조에서는 롤아웃을 만든 정책과 지금 업데이트하려는 정책 사이에 시차가 생깁니다. 이 시차, 즉 off-policy 문제가 학습을 흔드는 두 번째 위험입니다.

SAO는 이 안정성 문제를 “엄격한 양방향 토큰 단위 클리핑(strict double-side token-level clipping)”으로 막습니다. PPO 계열이 원래 쓰던 클리핑은 중요도 비율(importance ratio)이 특정 범위를 벗어나면 그래디언트를 잘라 내는 장치입니다. SAO는 이를 토큰 단위로, 그리고 위아래 양쪽 모두에 엄격하게 적용합니다. 오래된 정책이 만든 롤아웃이 현재 정책과 지나치게 벌어진 토큰에서는 갱신을 강하게 억제해, 시차가 큰 신호가 학습을 망치는 것을 막습니다.

이 조합의 결과로 SAO는 1,000 스텝 동안 안정적으로 학습을 이어 갔다고 보고합니다. 비동기 RL에서 수백 스텝을 넘기면 발산하거나 붕괴하는 사례가 흔하다는 점을 감안하면, 1,000 스텝 안정 학습은 이 방법의 핵심 주장을 뒷받침하는 증거입니다.

실제 결과와 검증

논문은 SAO를 GRPO 및 그 변형들과 비교했고, 에이전트 코딩과 추론 벤치마크에서 일관되게 앞섰다고 보고합니다. 언급된 벤치마크는 SWE-Bench Verified(실제 GitHub 이슈 해결), BeyondAIME(고난도 수학), IMOAnswerBench(올림피아드 수준 수학)입니다. 셋 모두 짧은 단답이 아니라 긴 호흡의 다단계 작업이라는 공통점이 있습니다. 바로 SAO가 겨냥한 영역입니다.

가장 설득력 있는 검증은 벤치마크 표가 아니라 배포 사실 자체입니다. SAO는 GLM-5.2(750B-A40B, 활성 파라미터 40B 규모의 MoE) 오픈 모델을 학습하는 실제 에이전트 RL 파이프라인에 투입되었습니다. 연구용 방법이 논문에만 머물지 않고 수백 B 규모 모델의 프로덕션 학습에 쓰였다는 것은, 이 방법이 소규모 토이 세팅을 넘어 실제 스케일에서 견딘다는 강한 신호입니다.

다만 이 글에서는 벤치마크의 구체적 수치를 인용하지 않습니다. 원문에서 검증한 정확한 수치를 이 자리에서 재현할 수 없다면, 숫자를 지어내지 않고 방법의 구조와 명시된 벤치마크 이름만 전하는 것이 정직합니다. 정확한 점수가 필요하다면 아래 원문을 직접 확인하시기 바랍니다.

ThakiCloud 제품 적용 시사점

SAO의 교훈은 알고리즘 논문 한 편을 넘어, GPU 클러스터를 운용하는 방식에 직접 닿아 있습니다.

ai-platform 렌즈 (GPU 학습 인프라). ThakiCloud의 ai-platform은 Kubernetes와 Kueue 위에서 멀티테넌트 GPU 학습을 스케줄링합니다. kubeflow 기반 LLM 학습 시스템은 이미 GRPO를 사후학습 기법의 하나로 지원합니다. SAO가 던지는 질문은 명확합니다. 우리 학습 잡의 GPU 사용률은 롤아웃 길이의 편차 때문에 얼마나 깎이고 있는가. 에이전트 롤아웃처럼 길이가 들쭉날쭉한 작업에서는 동기식 그룹 대기가 곧 비용입니다. 비동기 롤아웃 생성과 학습을 분리하면 같은 GPU로 더 많은 유효 스텝을 뽑을 수 있고, 이는 멀티테넌트 환경에서 테넌트당 학습 단가를 낮추는 직접적인 지렛대가 됩니다. Kueue의 gang scheduling과 큐 관리가 “그룹이 다 찰 때까지 대기”라는 패턴을 강제하지 않는지 점검하는 것도 실질적인 최적화 포인트입니다.

Paxis 렌즈 (에이전트 학습의 산출물). ThakiCloud의 Agent-Native Cloud인 Paxis는 스킬을 격리 샌드박스에서 실행하고 모든 행동을 정책 게이트와 감사 로그로 통과시키는 제어 평면입니다. SAO가 잘 학습시키려는 대상, 즉 여러 턴에 걸쳐 도구를 호출하며 코드베이스를 고치는 에이전트가 바로 Paxis가 실행하는 워크로드입니다. 더 나아가, Paxis가 격리 샌드박스에서 생성하는 실제 에이전트 트레이스는 그 자체로 SAO 같은 비동기 RL의 롤아웃 소스가 될 수 있습니다. 즉 ai-platform이 저비용으로 롤아웃을 생성·학습하고, Paxis가 그 결과 에이전트를 안전하게 운용하며 다시 학습 데이터를 만들어 내는 순환이 성립합니다. 저비용 학습 인프라(ai-platform)가 에이전트 경제성(Paxis)을 떠받치는 구조입니다.

한계 및 반론

이 방법을 무비판적으로 받아들이기 전에 몇 가지를 짚어야 합니다.

첫째, 단일 롤아웃은 그룹이 제공하던 분산 감소를 포기합니다. SAO는 이를 클리핑으로 보완하지만, 클리핑은 본질적으로 학습 신호를 잘라 내는 장치입니다. 지나치게 엄격한 클리핑은 유효한 그래디언트까지 버려 학습을 느리게 만들 수 있습니다. “안정성”과 “학습 속도” 사이의 균형점이 태스크와 스케일에 따라 달라질 여지가 큽니다.

둘째, 750B 모델 학습이라는 검증은 인상적이지만, 그 규모에서 통한다는 것이 소규모 조직의 세팅에서도 최적이라는 뜻은 아닙니다. 비동기 파이프라인은 생성기와 학습기를 분리하는 별도의 인프라 복잡도를 요구합니다. 롤아웃 몇 개로 짧게 튜닝하는 팀에게는 오히려 동기식 GRPO가 단순하고 충분할 수 있습니다.

셋째, 반대 방향의 접근도 활발합니다. 같은 시기에 비동기 RLHF의 staleness와 학습률 관계를 스케일링 법칙으로 다룬 연구(arXiv 2607.01083)나, 그래디언트 정렬로 비동기 학습을 안정화하는 접근도 나와 있습니다. SAO의 “그룹을 없애고 클리핑으로 막는다”가 유일한 정답이라기보다, 비동기 에이전트 RL이라는 열린 문제에 대한 여러 유력한 답 중 하나로 보는 것이 정확합니다.

그럼에도 SAO의 기여는 분명합니다. 문제(긴 롤아웃에서 그룹 샘플링의 비효율)를 정확히 짚었고, 해법(단일 롤아웃 + 양방향 클리핑)을 실제 수백 B 규모 프로덕션 학습으로 검증했습니다. GPU 활용률이 곧 학습 비용인 조직이라면, 자신의 파이프라인이 “그룹을 기다리느라” 얼마를 태우고 있는지 한 번쯤 계산해 볼 이유가 됩니다.

관련 슬라이드

본문 내용을 NotebookLM(structured_mint 스타일)으로 요약한 슬라이드입니다.

출처

• Zhenyu Hou, Yujiang Li, Jie Tang, Yuxiao Dong. “Single-Rollout Asynchronous Optimization for Agentic Reinforcement Learning.” arXiv 2607.07508 (2026-07-08). https://arxiv.org/abs/2607.07508
• 관련: “Staleness-Learning Rate Scaling Laws for Asynchronous RLHF.” arXiv 2607.01083. https://arxiv.org/abs/2607.01083

원 뉴스: RT @hangoo_kang: “TRACE: Capability-Targeted Agentic Training” got Spotlight @ ICML AIWILD 🎉 · twitter

ThakiCloud 제품 적용 시사점

타키클라우드가 오래 밀어온 그림과 정확히 맞닿습니다. 파시스는 에이전트를 지휘하고, 메티스는 그 에이전트가 부족한 능력을 다시 학습시킵니다. TRACE의 교훈은 ‘실패 기록을 진단해 약점만 다시 훈련하라’인데, 그 실패 기록이야말로 회사의 가장 민감한 자산입니다. 남의 클라우드에 로그를 통째로 넘겨서 훈련시키면 약점도, 그걸 고친 노하우도 밖으로 새어 나갑니다. 온프렘(자기 시설 안에서 돌리는 방식)과 주권(모델·데이터·인프라를 내 통제 아래 두는 것)이 필요한 이유가 여기 있습니다. 실패는 집에서 고쳐야 새지 않으니까요. 참고로 이 블로그도 실패를 회고해 스킬을 다시 벼리는 자기개선 루프로 굴러갑니다.

이 만화는 업계 뉴스를 바탕으로 자동 생성된 초안입니다.

نظرة عامة

مهارة Claude Code ليست سحرًا بل إجراء تشغيل معياري (SOP). هي لا تجعل النموذج أذكى، بل تقيّد بقوة قدراتٍ يمتلكها النموذج أصلًا نحو اتجاه محدد، فترفع متوسط الجودة. في حالة مهارة صفحات الهبوط، هذا القيد هو تحديدًا مبادئ التصميم وقواعد التخطيط وصيغة المخرجات.

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

ما هذه التقنية

مهارة Claude Code هي في جوهرها ملف markdown واحد اسمه SKILL.md. بداخله المبادئ والقواعد التي ينبغي للوكيل اتباعها في مهمة معينة، إضافة إلى تفضيلات المستخدم. عندما يقدّم المستخدم طلبًا بلغة طبيعية، تُحقَن المهارة ذات الصلة في سياق الوكيل، فيتبع الوكيل تلك التعليمات كإجراء تشغيل معياري بينما يولّد HTML وCSS وJavaScript محليًا.

شكل ما تنتجه مهارات صفحات الهبوط يُلاحَظ باتساق عبر عدة مهارات عامة. إنه ملف HTML واحد مكتفٍ بذاته، بكل CSS مضمّن داخل <style> وكل JavaScript مضمّن داخل <script>. تقتصر الاعتماديات الخارجية على Google Fonts ومكتبة الرسوم المتحركة GSAP المحمّلة عبر CDN (Claude Directory). ملف واحد يكفي لاستضافته وتقديمه في أي مكان.

flowchart TB
    U[طلب بلغة طبيعية<br/>إنشاء صفحة هبوط احترافية] --> A[وكيل Claude Code]
    S[SKILL.md<br/>مبادئ التصميم · قواعد التخطيط · التفضيلات] -.حقن.-> A
    A --> G[مخرج HTML واحد<br/>CSS مضمّن · JS مضمّن]
    G --> D1[Google Fonts<br/>CDN]
    G --> D2[رسوم GSAP المتحركة<br/>CDN]
    D1 --> O[صفحة مكتفية بذاتها<br/>تُشحن كملف واحد]
    D2 --> O

الكلمة المفتاحية هي “ضربة واحدة”. حين يصف المستخدم ما يريده بجمل بسيطة، يُنتج الوكيل الصفحة كاملة في مسار واحد دون ذهاب وإياب كثير. ينجح هذا لا لأن النموذج يبدع، بل لأن المهارة اتخذت مسبقًا معظم القرارات حول “ما الذي يصنع صفحة هبوط جيدة” نيابةً عن المستخدم.

القرارات التي تتخذها المهارة نيابةً عنك

حين تطلب صفحة هبوط دون مهارة، تكون النتيجة عامة لسبب واضح: على الوكيل أن يقرر التخطيط والمسافات والطباعة وتباين الألوان وتوقيت الحركة من الصفر في كل مرة، وتتجه تلك القرارات نحو متوسط آمن. تثبّت مهارات صفحات الهبوط الاحترافية العامة هذه القرارات مسبقًا بالضبط (تحليل MindStudio).

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

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

أمور ينبغي الانتباه إليها عند بناء مهارتك

إن كتبت مثل هذه المهارة بنفسك، فبعض الأمور مهمة. أولًا، ثبّت صيغة المخرجات صراحةً. تحديد البنية بأنها “HTML واحد، CSS/JS مضمّن، اعتماديات خارجية مقتصرة على الخطوط وGSAP” يُبقي النشر والنقل بسيطين. ثانيًا، اختزل حكم التصميم إلى قواعد. كتابة مقاييس المسافات وتباين الطباعة ولوحة ألوان مسموحة وقاعدة تفضّل transform وopacity الملائمين للمُركِّب في الحركة داخل الإجراء المعياري يعني ألا يعيد الوكيل التداول في كل مرة. ثالثًا، ضمّن حالات الفشل. أكثف معلومة في المهارة هي قائمة “لا تفعل هذا”. بنود مثل منع الحركات التي تُزيح التخطيط ومنع مخالفات أساسيات إمكانية الوصول هي ما يحمي جودة المخرجات فعليًا (دليل Ryan Doser).

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

دلالات لمنتجات ThakiCloud

يتردد صدى هذه الحالة لدى ThakiCloud خصوصًا لأننا نشغّل منصة تعامل المهارات كموارد من الدرجة الأولى.

منظور Paxis (الوكلاء والمهارات). Paxis هي سحابة ThakiCloud الأصلية للوكلاء (Agent-Native Cloud)، التي تعامل Skills وTools وPolicies وAudit Logs كموارد من الدرجة الأولى. قدرة وحدوية مثل مهارة صفحات الهبوط هي بالضبط ما يديره Skill Harness في Paxis. نختار من مئات المهارات عبر BM25، ونحقن ذات الصلة فقط في سياق الوكيل، وننفّذها في صندوق رمل معزول، ونمرّر كل فعل عبر بوابة سياسة وسجل تدقيق. كون مهارة صفحة هبوط واحدة تعمل جيدًا يعني أيضًا أن النمط نفسه يمكن أن يمتد إلى مجالات أخرى مثل توليد الشرائح وعرض المستندات ونشر البنية التحتية. صور ومستندات هذه المدونة نفسها تُولَّد على منصة المهارات ذاتها.

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

منظور ai-platform (البنية التحتية). بعض العملاء يريدون تشغيل أحمال التوليد هذه على بنيتهم التحتية الخاصة بدل الاعتماد كليًا على واجهات برمجة خارجية. تقدّم منصة ai-platform لدى ThakiCloud نماذج التوليد فوق جدولة GPU قائمة على K8s وKueue، فحتى في البيئات المحلية أو السيادية يمكن استضافة مثل هذه المسارات القائمة على المهارات ذاتيًا. كلما كانت المهمة متكررة ومعيارية، مثل توليد صفحات الهبوط، تحوّلت كلفة التقديم المنخفضة مباشرةً إلى اقتصاديات وكيل.

القيود والاعتراضات

بالطبع علينا الحذر من المبالغة. عبارة “صفحة احترافية بضربة واحدة” تصحّ أكثر في ظروف العرض التوضيحي. صفحة هبوط منتج حقيقي تحمل متطلبات متداخلة مثل أصول العلامة ومراجعة النصوص والامتثال لإمكانية الوصول وميزانية أداء واختبار A/B، لذا فمخرج الضربة الواحدة مسودة ممتازة لا نسخة نهائية. وعلى وجه الخصوص، HTML واحد بكل شيء مضمّن مريح للنشر السريع لكنه قد يحتاج إلى تقسيم من جديد للتخزين المؤقت والصيانة في موقع حقيقي تتشارك فيه صفحات متعددة الأصول.

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

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

المصادر

• @the_cyw، “بنيت مهارة تجعل Claude Code يبني صفحات هبوط احترافية”
• Claude Directory: Landing Page Skills
• MindStudio: Claude Code Landing Page Generator Skill
• Ryan Doser: How to Build Landing Pages With Claude Code

في الأسابيع الأخيرة، تحول حديث صناعة الذكاء الاصطناعي من سؤال “من الأذكى” إلى سؤال “من الأرخص”. وجاء المشهد الأكثر دلالة من مايكروسوفت. فالشركة ذاتها التي وضعت OpenAI على المسار الذي تسير عليه اليوم، بدأت بتوجيه عشرات آلاف الطلبات الأسبوعية للذكاء الاصطناعي داخل Excel وOutlook إلى نماذجها الخاصة بدلاً من نماذج OpenAI وAnthropic. ولم يُخفِ مصطفى سليمان، مسؤول الذكاء الاصطناعي في مايكروسوفت، هذا التوجه، إذ قال: “Anthropic باهظة الثمن للغاية. هدفنا هو خفض هذه التكلفة والقضاء عليها في نهاية المطاف.”

هذا المقال موجّه لقادة الهندسة وفرق الذكاء الاصطناعي وصنّاع القرار المسؤولين عن تكلفة الاستدلال في خدماتهم. سنوضح لماذا حرب التكاليف الدائرة اليوم ليست ضجيجاً عابراً بل تحولاً بنيوياً، ونضع دليلاً عملياً لترحيل إنفاق واجهات النماذج المتقدمة نحو النماذج المفتوحة والاستضافة الذاتية، ثم نختم بموقع ThakiCloud كطبقة تحكم تُنفذ هذا الترحيل فعلياً.

ما الذي تغيّر

قرار شركة واحدة لا يصنع اتجاهاً عاماً. لكن إشارات متعددة تشير إلى الاتجاه نفسه تراكمت خلال أسابيع قليلة.

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

ثانياً، تتجه الشركات الأمريكية نحو النماذج الصينية المفتوحة هرباً من الأسعار. وبحسب تقرير CNBC، عالجت النماذج الصينية أكثر من 30 بالمئة من استخدام الذكاء الاصطناعي لدى الشركات الأمريكية على إحدى منصات التوجيه الرئيسية، وبلغت ذروتها عند 46 بالمئة، مقارنة بمتوسط 11 بالمئة قبل عام واحد فقط. وتكاليفها أقل بنسبة تتراوح بين 60 و90 بالمئة، وفي بعض اختبارات الأداء الخاصة بالوكلاء ضاقت الفجوة مع أفضل النماذج الأمريكية إلى نقطة واحدة فقط (تقرير CNBC).

ثالثاً، ظهرت إشارة إلى فائض في العرض. فقد أعلنت Meta عزمها إنشاء عمل سحابي لبيع قدرة الحوسبة “الفائضة” الخاصة بالذكاء الاصطناعي، وهو ما يعني عملياً تحويل الاعتراف بالإفراط في البناء إلى نموذج عمل (تقرير CNBC).

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

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

كما أن الأسعار نفسها تنخفض بسرعة. فنموذج GPT-5.6 Sol الذي أطلقته OpenAI مؤخراً يُسعَّر بنحو 5 دولارات لكل مليون رمز إدخال و30 دولاراً لكل مليون رمز إخراج، وهو انخفاض حاد في تكلفة الرمز مقارنة بالجيل السابق (تقرير CNBC). وهذا يعني أن مختبرات النماذج المتقدمة نفسها دخلت في حرب أسعار فيما بينها. لم تعد الجبهة الأمامية حرب ذكاء، بل تحولت إلى حرب قيمة.

لماذا الآن

اندلعت حرب التكاليف الآن بسبب طبيعة توزّع الأحمال العملية.

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

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

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

من المتقدم إلى المفتوح: دليل الترحيل العملي

فكيف يُنقل هذا النهر عملياً. تغيير النموذج بشكل ارتجالي أمر محفوف بالمخاطر. الترحيل الموثوق يمر بخمس خطوات.

أولاً، تصنيف الحمل. تُقسَّم كل طلبية على محورين: الصعوبة والحساسية. تبقى المهام الصعبة أو الحساسة على النماذج المتقدمة، بينما تُوضَع علامة على المهام النمطية عالية الحجم فقط باعتبارها هدفاً للترحيل.

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

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

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

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

flowchart TB
    A[الحمل الوارد] --> B{بوابة التصنيف<br/>الصعوبة · الحساسية}
    B -->|صعب أو حساس| C[واجهة نموذج متقدم<br/>Claude · GPT-5.6 Sol]
    B -->|مهام نمطية ضخمة| D[نماذج مفتوحة مرشحة<br/>مختارة عبر نسبة اجتياز التقييم]
    D --> E[تقديم ذاتي الاستضافة<br/>vLLM · Metis · Kueue GPU]
    C --> F[بوابة سياسات + سجل تدقيق<br/>طبقة تحكم Paxis]
    E --> F
    F --> G[النتيجة]
    F -.رصد تراجع الجودة.-> B

شارك أحد المطورين على منصة X أن هذا النهج خفّض إنفاقه الشهري على واجهات البرمجة من 60 ألف دولار إلى 12 ألف دولار عبر النماذج المفتوحة، أي بنسبة تقارب 80 بالمئة. ولم يتسنَّ التحقق من المنشور الأصلي بشكل مستقل لأن الوصول إليه كان مقيداً، لذا يُعامَل الرقم باعتباره غير مؤكد ولغرض المرجعية فقط. غير أن حجم الوفورات نفسه يتسق مع البيانات الموثقة: التكلفة الأقل بنسبة 60 إلى 90 بالمئة للنماذج الصينية المفتوحة، وحرب الأسعار الدائرة بين مختبرات النماذج المتقدمة نفسها، تشير جميعها إلى الاتجاه ذاته.

دلالات الأمر على منتجات ThakiCloud

هذا الدليل واضح من الناحية المفاهيمية، لكن تنفيذه فعلياً يتطلب أمرين: بنية تحتية تقدّم النماذج المفتوحة بتكلفة منخفضة، وطبقة تحكم تختار النموذج المناسب لكل مهمة مع ضمان الأمان عبر السياسات والتدقيق. توفر ThakiCloud هذين المحورين معاً من خلال منتجين.

ai-platform: بنية تحتية منخفضة التكلفة للتقديم

ai-platform هي بنية تحتية لتقديم أنظمة الذكاء الاصطناعي والتعلم الآلي مبنية على Kubernetes. تُجدوِل وحدات معالجة الرسوميات عبر Kueue، وتُقدّم النماذج المفتوحة عبر vLLM، وتدعم العزل متعدد المستأجرين والنشر المحلي. الخطوة الرابعة من دليل الترحيل، أي نشر النموذج المفتوح المختار على البنية التحتية الخاصة لخفض التكلفة لكل وحدة، تحدث في هذه الطبقة تحديداً. وبالنسبة للعملاء الذين لا يمكنهم إرسال بياناتهم خارج نطاقهم، مثل الجهات الحكومية أو الصناعات الخاضعة للتنظيم، يصبح النشر السيادي عاملاً حاسماً، وهو متطلب لا تستطيع واجهات النماذج المتقدمة تلبيته من الأساس.

Paxis: السحابة الأصيلة للوكلاء التي تُنفذ الترحيل

Paxis هي طبقة التحكم الأصيلة للوكلاء التي تعمل فوق ai-platform. فكما تتعامل السحابة التقليدية مع الأجهزة الافتراضية وقواعد البيانات كموارد من الدرجة الأولى، تتعامل Paxis مع المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. ومن منظور دليل الترحيل، يُعد توجيه النموذج الجزء الأهم. تستخدم Paxis ملف models.yaml كمصدر حقيقة وحيد لتوجيه Claude وOpenAI وOllama وKimi وMiniMax، بالإضافة إلى تقديم vLLM الخاص بـ ai-platform (المسمى Metis)، جميعها من مكان واحد. وهذا يقابل تماماً الخطوتين الثالثة والخامسة من الدليل المذكور أعلاه: تحديد النموذج لكل نوع مهمة، وإعادة مهمة بعينها إلى النموذج المتقدم لحظة تراجع الجودة، وهو قرار يُتخذ في هذه الطبقة.

إضافة إلى ذلك، توفر Paxis طبقة مهارات تختار من بين أكثر من 960 مهارة باستخدام خوارزمية BM25، وتنفيذاً معزولاً داخل صندوق رملي، ومحرك معرفة قائماً على الويكي، وتنسيقاً متعدد الوكلاء عبر رسم بياني موجه (DAG)، وموصلات MCP مع إعادة اتصال تلقائية عبر OAuth. ويمر كل إجراء يقوم به الوكيل عبر بوابة سياسات وسجل تدقيق. بمعنى آخر، يمكن التحول إلى نماذج أرخص مع الاحتفاظ بالقدرة على تتبع ما عولج بأي نموذج بدقة.

يمكن تلخيص العلاقة بين المنتجين في جملة واحدة: التقديم منخفض التكلفة (ai-platform) هو ما يصنع اقتصاديات الوكيل (Paxis). فبدون بنية تحتية قادرة على تشغيل النماذج المفتوحة بتكلفة منخفضة، تبقى قواعد التوجيه مجرد خطة على الورق، وبدون توجيه وسياسات، يتحول التقديم الرخيص إلى مخاطرة لا يمكن التحكم بها. تحويل الترحيل إلى عمل حقيقي يتطلب المحورين معاً في آنٍ واحد. وتجدر الإشارة إلى أن Paxis ما زالت في مرحلة إثبات المفهوم، وقد تتغير واجهاتها ومخططاتها بسرعة.

الحدود والحجج المضادة

إنهاء هذا العرض بتفاؤل مطلق لن يكون أمانة. الحجج المضادة واضحة.

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

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

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

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

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

المصادر

• Microsoft reportedly ditching OpenAI’s, Anthropic’s AI models to cut costs (SiliconANGLE)
• Chinese AI models gain ground with US companies on cost (CNBC)
• Meta plans cloud business to sell AI compute (CNBC)
• OpenAI expands GPT-5.6 Sol access and pricing (CNBC)