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

معظم المهام لا تحتاج نموذجًا طليعيًا

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

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

ابنِ بتكلفة عالية، انقل التنسيق إلى الكود، شغّل بتكلفة منخفضة

النمط الذي نتّبعه فعليًا يتكوّن من ثلاث خطوات.

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

سنُظهر لماذا هذا النمط آمن من خلال كود فعلي. فيما يلي نتيجة تشغيل بوابة التحقق الخاصة بمهارة تُلخِّص خط زمن تويتر إلى Slack، على مخرجات حقيقية. هذه المهارة تعمل خمس مرات يوميًا، وأنتجت أكثر من 1000 سجل تراكمي، وكانت تعتمد سابقًا على Opus لكل تغريدة، أما الآن فتعمل بـSonnet.

$ tweet_validate.py --dir outputs/twitter/hjguyhan
validated: 2/2 passed; decisions=1 (code-capped)
{"status": "ok", "passed": 2, "total": 2, "decisions": 1, "failed_ids": []}

هنا، عدد الأحرف وعدد الروابط وحالة الـenum ونتيجة النجاح ليست قيمًا زعمها النموذج، بل قيمًا أعاد الكود حسابها فعليًا من النص نفسه. وحتى أعلام القرار (decision flags) قصّها الكود إلى أعلى عدد محدد. هذه البوابة تعمل بالطريقة نفسها بغض النظر عن النموذج الذي كتب المحتوى. لهذا لم تهتز الجودة عند خفض العامل من Opus إلى Sonnet.

الموجز اليومي الخاص بفريق مبيعات CRM يتبع البنية ذاتها. فيما يلي مخرجات فعلية من عارض (renderer) يستقبل JSON البيانات ويُخرج تنسيق Slack مباشرة عبر الكود.

$ sales_crm_render_brief.py --data brief.json --print-slack
:sunny: *ThakiCloud 영업 데일리 브리프* — 2026-07-03 (목)
*③ 긴급 액션*
1. [A사] GPU 증설 RFP 마감 임박 <전자신문 2026-07-02>
...

أرقام العناوين، وصياغة الروابط، وبنية السلاسل النصية (threads) — كلها يضيفها الكود. وبذلك انتقلت الأرشفة والتنسيق إلى Sonnet والكود، بينما احتُفظ عمدًا بمستوى نموذج أعلى فقط لتوليد النص الموجَّه مباشرة إلى العميل. لا يختلط ما يُخفَّض بما يُبقى كما هو.

مهارة تحسين التكلفة: قِس، خفّض، تراجع

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

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

المهم هنا أن هذه البوابة ليست “آلة خفض”، بل “آلة حقيقة”. قِسنا فعليًا إمكانية خفض مهارة humanizer (المهارة التي تُزيل آثار الكتابة الآلية) المستخدمة كثيرًا، من Sonnet إلى Haiku. وكانت النتيجة كالتالي:

$ cost_evolve.py evolve --skill humanizer
{ "skill": "humanizer", "current": "sonnet", "candidate": "haiku",
  "headline_gap": 2.0, "reasoning_gaps": 1, "decision": "hold",
  "reason": "1 reasoning gap(s): rephrasing_naturalness",
  "recommend": "먼저 포맷 갭을 코드로 프로그램화하라" }

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

Paxis يُنفّذ هذا القرار تلقائيًا كل ليلة

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

وهذا يعمل فعليًا الآن. مخرجات المرشحين لآخر ثلاثة أيام لا تزال محفوظة كما هي.

# cost-evolve candidates — 2026-07-03
10 candidate(s), ranked by est. savings.
| lever            | target   | action                              |
| model-deescalate | sod-ship | opus -> sonnet, apply only if PASS  |
| model-deescalate | eod-ship | opus -> sonnet, apply only if PASS  |
| mcp-prune        | codegraph| 미사용 MCP 서버 비활성화             |
| format-determinism | ...    | 포맷을 코드로 추출 후 강등 재시도    |

ثمة نقطة نودّ الإشارة إليها بصراحة هنا: هذا النظام لا يخفّض التكلفة بعدوانية. sod-ship وeod-ship أعلاه كانا قد رُقّيا إلى نموذج أعلى قبل يوم واحد فقط، فقررت البوابة تأجيل الخفض بحجة أن “التراجع الآن مبكر جدًا”. النظام لا يخفّض فعليًا إلا حين يتوفر يقين كافٍ. في المقابل، القيمة الافتراضية لمعظم المهارات هي أصلًا المستوى الرخيص. المهارات القليلة المثبَّتة على نموذج أعلى هي فقط تلك التي تكون الجودة فيها حاسمة (تحسين المقالات، الرسوم الكاريكاتورية الإخبارية، النصوص الموجهة مباشرة للعملاء)، أما الباقي فيصعد مؤقتًا فقط حين تتطلب البيانات ذلك.

خلاصة الوضع كالتالي:

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

إن كان لديك GPU محلي، يمكنك تشغيل المستوى الرخيص بنفسك

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

نموذج Gemma 4 من Google مُتاح بترخيص Apache 2.0، وتعمل نسخه الصغيرة مثل E2B وE4B على الأجهزة المحمولة أو اللوحات من فئة Jetson مباشرة على الجهاز نفسه (on-device). هذا الحجم مناسب تمامًا للتوجيه والتصنيف واستدعاء الأدوات البسيط كعامل. ونموذج GLM 5.2 من Zhipu مفتوح الأوزان برخصة MIT، ويُبرز استخدامًا وكيليًا للأدوات يجعله يقترب في الأداء من النماذج الطليعية المغلقة. أما Kimi K2.7-Code من Moonshot فهو نموذج مفتوح الأوزان متخصص في البرمجة وتنفيذ الأدوات متعدد الخطوات. وقد ترسّخ في الصناعة بالفعل نمط يُوجَّه فيه 60 إلى 80 بالمئة من حركة مرور الوكلاء إلى هذه النماذج المفتوحة الأوزان، بينما تُرفَع فقط النسبة الصعبة فعلًا، أي نحو 20 بالمئة، إلى واجهات النماذج الطليعية.

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

إن احتجت مساعدة

إن كنت تدير فريقًا يريد تحسين التكلفة عبر الجمع بين أحدث النماذج المفتوحة الأوزان مثل GLM 5.2 وKimi K2.7-Code، تواصل معنا. سنساعدك في تصميم أي المهام تُخفَّض إلى أي مستوى، وما الذي يجب أن يحرسه الكود.

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

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

نظرة عامة

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

عالج فريق GEAR في NVIDIA هذا الأمر تحديدًا عبر ASPIRE (Agentic /Skills Discovery for Robotics، arXiv 2607.00272)، الذي أُطلق في 30 يونيو 2026. الفكرة بسيطة لكنها قوية. فبدلًا من حقن سياسة ثابتة في الروبوت، يكتب نموذج لغوي كبير (LLM) كود تحكّم الروبوت بنفسه، ويشغّل ذلك الكود في بيئة التنفيذ الحقيقية، ويراقب حالات الفشل، ويصلحه تكراريًا، ثم يقطّر خبرة الإصلاح المُتحقَّق منها في مهارات (Skills) قابلة لإعادة الاستخدام. الخبرة لا تُهدر بل تتراكم.

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

ما هو ASPIRE

يضع ASPIRE حلقة تعلّم مستمر فوق نمط code-as-policy. غالبًا ما يدرّب تعلّم الروبوتات التقليدي سياسةً عصبية على كميات كبيرة من بيانات العرض، ثم يعيد جمع البيانات وإعادة التدريب كلما ظهر موقف جديد. وهذا يحمل عبأين: جمع البيانات مكلف، والمعرفة المكتسبة مرة تنهار بسهولة أمام تغيّرات جديدة.

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

flowchart TB
    A[تعليمات المهمة] --> B[نموذج LLM يكتب كود التحكم<br/>code-as-policy]
    B --> C[تنفيذ حقيقي<br/>محاكاة أو روبوت]
    C --> D{نجاح؟}
    D -- فشل --> E[تسجيل المسار وتحليل سبب الفشل]
    E --> F[إصلاح البرنامج]
    F --> C
    D -- نجاح --> G[تقطير خبرة الإصلاح المُتحقَّق منها]
    G --> H[مكتبة مهارات قابلة لإعادة الاستخدام]
    H -.المهمة التالية ترجع إليها.-> B

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

تقطير الفشل إلى مهارات

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

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

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

النتائج التجريبية الفعلية

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

وتظلّ الميزة قائمة مع اتّساع أنواع المهام. تُبلّغ الورقة بأن ASPIRE يتفوّق على الطرق السابقة بما يصل إلى 77% على LIBERO-Pro (مهمة تلاعب تحت اضطراب)، وبـ72% على تسليم Robosuite بذراعين، وبما يصل إلى 32% على BEHAVIOR-1K (مهمة منزلية طويلة الأفق). وعلى وجه الخصوص، في تجارب التعميم طويلة الأفق، ارتفع معدّل النجاح باطّراد مع نمو مكتبة المهارات. وكون نمو المكتبة وارتفاع الأداء يسيران معًا يدعم الادّعاء المركزي لهذا النظام بأن الخبرة تتراكم فعلًا.

يضمّ الفريق البحثي مختبر GEAR في NVIDIA إلى جانب باحثين من جامعة ميشيغان (UMich) وجامعة إلينوي (UIUC) وجامعة كاليفورنيا في بيركلي وجامعة كارنيغي ميلون (CMU). وقد أفادت NVIDIA بأن مكتبة مهارات ASPIRE ستكون مفتوحة المصدر عند الإطلاق، مع التفاصيل على صفحة المشروع (research.nvidia.com/labs/gear/aspire). ومع ذلك، لم يتأكّد بوضوح رخصة مستودع الكود وقت الإطلاق، لذا يُستحسن التحقق مباشرةً من شروط رخصة المستودع الفعلي قبل تبنّيه.

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

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

تعامل Paxis المهارات والأدوات والسياسات وسجلّات التدقيق (Skills وTools وPolicies وAudit Logs) بوصفها موارد من الدرجة الأولى. فمكتبة مهارات ASPIRE تقابل في Paxis منصة مهارات تضمّ نحو 960 مهارة تُنتقى عبر BM25، وتنفيذ ASPIRE بنمط code-as-policy يقابل تنفيذ Paxis في صندوق رمل معزول. وكما يسجّل ASPIRE مسارات الفشل ويحلّلها، تمرّر Paxis كل فعل للوكيل عبر بوابة سياسة وسجلّ تدقيق حتى يمكن تتبّع ما فشل ولماذا بأثر رجعي. وأمّا التحسّن الذاتي الذي تهدف إليه حلقة تقطير ASPIRE فيتحقّق في Paxis بوصفه مهارات ذاتية التطوّر: تعود الدروس المستخلصة من التنفيذ إلى مهارات جديدة أو تنقيحات للمهارات، فلا يبدأ التشغيل التالي بيدين فارغتين.

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

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

على إثارة نتائج ASPIRE للإعجاب، ثمة تحفّظات في محلّها. أولًا، تأتي الأرقام المُبلَّغ عنها في معظمها من معايير محاكاة (Robosuite وLIBERO-Pro وBEHAVIOR-1K). فالتنقيح التكراري في المحاكاة رخيص وآمن، لكن على العتاد الحقيقي تحمل كل محاولة وقتًا وتآكلًا ومخاطر سلامة. وما إذا كانت اقتصاديات حلقة التنفيذ والفشل والإصلاح تصمد على الروبوتات المادية يحتاج إلى تحقّق منفصل.

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

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

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

المصادر

• ASPIRE: Agentic /Skills Discovery for Robotics، arXiv 2607.00272: https://arxiv.org/abs/2607.00272
• صفحة المشروع (NVIDIA GEAR): https://research.nvidia.com/labs/gear/aspire/
• صفحة الورقة (Hugging Face): https://huggingface.co/papers/2607.00272

نظرة عامة

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

في يوليو 2026، وسّعت Anthropic ميزة Artifacts في Claude Code لتشمل خطتي Pro وMax. فقدرة كانت محصورة في خطتي Team وEnterprise باتت متاحة الآن للمطورين الأفراد. الفكرة بسيطة: حين تطلب artifact، يكتب Claude الشيفرة وينشرها مباشرةً على claude.ai، ويواصل تحديث تلك الصفحة في الوقت الفعلي بينما تستمر الجلسة. الصفحة خاصة بحسابك ومكتفية ذاتياً بالكامل.

يشرح هذا المقال ما هي Artifacts في Claude Code بدقة، ولماذا يهمّ توسّعها إلى Pro وMax، وكيف يمكن استيعاب هذا النمط من منظور منصة الوكلاء Paxis وبنية الذكاء الاصطناعي ai-platform لدى ThakiCloud.

ما هي Artifacts في Claude Code

كانت Artifacts في الأصل تعرض الشيفرة أو المستندات في لوحة منفصلة داخل محادثة claude.ai. أما Artifacts التي وصلت للتو إلى Claude Code فمختلفة قليلاً. فبدلاً من مخرَج تبادل واحد، تحوّل تقدّم جلسة برمجية كاملة إلى صفحة بصرية حية واحدة.

تسرد Anthropic أربعة استخدامات نموذجية: شروحات طلبات الدمج (PR walkthroughs)، وصفحات شرح النظام، ولوحات المعلومات، وقوائم مراجعة الإصدار. القاسم المشترك بينها أن كلّاً منها ملخّص يقرأه الإنسان لما يجري الآن. وبينما تواصل الجلسة عملها، تحدّث تلك الصفحة نفسها.

يبدو المسار من العمل إلى النشر على النحو التالي.

flowchart TB
    A[المطور يطلب artifact] --> B[Claude Code يكتب الشيفرة]
    B --> C[النشر المباشر على claude.ai]
    C --> D{الجلسة تستمر}
    D -->|تغيّر حالة العمل| E[تحديث الصفحة في الوقت الفعلي]
    E --> D
    D -->|اكتمال| F[تثبيت صفحة مكتفية ذاتياً]
    F --> G[مشاركة رابط النشر]
    G --> H[المتلقّي يطّلع دون حساب]
    G --> I[صاحب الحساب ينسخ عبر remix]

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

لماذا يهمّ التوسّع إلى Pro وMax

كانت الميزة نفسها متاحة على Team وEnterprise منذ بضعة أشهر. التغيير الأساسي الآن هو أن حدّ الخطة انخفض.

بدقّة: كانت Artifacts العادية المُنشأة في محادثة claude.ai قابلة للنشر أصلاً على كل الخطط بما فيها Free وPro وMax. أما Artifacts التي تحوّل جلسة Claude Code إلى صفحة حية فكانت حصراً على Team وEnterprise. وقد امتدّ هذا الحدّ الآن إلى Pro وMax. فبدون مقعد مؤسسي، يستطيع المطور الفرد تحويل جلسته إلى صفحة قابلة للمشاركة.

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

ملاحظة إضافية: خلال الفترة نفسها، رفعت Anthropic مؤقتاً الحدود الأسبوعية لاستخدام Claude Code لخطط Pro وMax وTeam. فُتح الوصول والهامش معاً، ما يمنح المطورين الأفراد مساحة حقيقية لتجربة الميزة.

كيف تعمل عملياً

استخدامها أقرب إلى المحادثة. أثناء الجلسة، حين تقول “حوّل هذا العمل إلى artifact”، يولّد Claude Code صفحة تلتقط التقدّم الحالي وينشرها على claude.ai. افتح الرابط المُعاد وسترى صفحة بصرية تلخّص العمل حتى الآن، وبينما تستمر الجلسة تتحدّث الصفحة دون إعادة تحميل.

تجري المشاركة عبر زر النشر أسفل لوحة artifact. ومن يتلقّى الرابط يستطيع الاطلاع على الصفحة دون حساب Claude. ومن يملك حساباً يمكنه استخدام remix لإنشاء نسخته القابلة للتحرير. بعبارة أخرى، يكون artifact واحد مادةً مشتركة للقراءة فقط ونقطة انطلاق يمكن لشخص آخر التقاطها وتطويرها.

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

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

ماذا يعني ذلك لـ ThakiCloud

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

عدسة Paxis (مخرَج الوكيل كمورد من الدرجة الأولى). إن Paxis من ThakiCloud هي مستوى تحكّم Agent-Native Cloud يعمل فوق ai-platform ويتعامل مع Skills وTools وPolicies وAudit Logs كموارد من الدرجة الأولى. وما تُظهره Artifacts في Claude Code هو طريقة لكشف مخرَج الوكيل الوسيط والنهائي كقناة مراقبة منفصلة. فحين تنفّذ شبكة DAG من وكلاء متعددين في Paxis مهمة طويلة، يتيح تكثيف تقدّم كل عقدة في صفحة حية يقرأها الإنسان للمشغّل أن يستوعب المسار دون تمرير السجلات. وبدمج ذلك مع بوابات السياسات وسجلات التدقيق في Paxis، يصبح الأثر مخرَجاً محكوماً يمكن تتبّعه حتى “مَن أنشأ وشارك ماذا ومتى”. وبالروح نفسها لأثر Anthropic الخاص افتراضياً، يمكن لـ Paxis إضافة تحكّم بالوصول قائم على السياسات لمشاركة المخرَجات وتوسيعه إلى مستوى المؤسسة.

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

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

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

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

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

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

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

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

المصادر

• منشور إعلان ClaudeDevs (@ClaudeDevs)
• Publish and share artifacts (Claude Help Center)
• What are artifacts and how do I use them? (Claude Help Center)

Here’s the short version. Expensive models earn their keep while you’re building a skill. Once the skill’s format has been pushed down into code, actually running it is a job for a much cheaper model. And “cheap enough” should never be a matter of gut feel. It has to be a verdict that code measures.

Most of the work doesn’t need a frontier model

Break down what an agent handles in a given day and the work splits into two very different buckets. One bucket holds genuinely hard reasoning: ambiguous architecture calls, subtle debugging, decomposing a problem nobody has framed before. The other bucket holds routine, repetitive work: routing, classification, summarization, rendering, spec checking. The trouble starts when both buckets get handed to the same frontier model and billed at the same top rate every time.

Quality on the routine side isn’t actually driven by model intelligence. It’s driven by guardrails. When output format wobbles, it’s not because the model is dumb, it’s because the format was requested in prose instead of enforced. Once length caps, allowed enums, rendering rules, and pass criteria are owned by code, that same task comes out reliably even on a cheap model. What protects quality here isn’t a pricier model, it’s the code gate around it.

Build expensive, push the format into code, run cheap

The pattern we actually use has three steps.

First, build the skill with an expensive model. Early on there’s a lot of judgment to exercise and failure cases to work through, so a strong model earns its cost. Second, extract the deterministic parts of the skill into code: rendering, enum normalization, length checks, deduplication, JSON assembly, anything the model shouldn’t have to solve fresh every single time. Third, drop the worker model down to a cheap tier. At this point the model is only generating body content, while the numbers, the format, and the pass/fail verdict all belong to code.

Here’s real code showing why this is safe. Below is a validation gate for a skill that turns a Twitter timeline into a Slack digest, run against an actual production artifact. This skill fires five times a day and has produced more than 1,000 records cumulatively. It used to run Opus on every tweet; now it runs on Sonnet.

$ tweet_validate.py --dir outputs/twitter/hjguyhan
validated: 2/2 passed; decisions=1 (code-capped)
{"status": "ok", "passed": 2, "total": 2, "decisions": 1, "failed_ids": []}

Character count, link count, status enum, and pass/fail here aren’t values the model claimed. They’re values code recomputed straight from the actual strings. The decision flags were also capped by code to the top few. This gate behaves identically no matter which model wrote the content, which is exactly why dropping the worker from Opus to Sonnet didn’t cost us any quality.

The sales CRM briefing follows the same structure. Below is real output from a renderer that takes a data JSON file and stamps out the Slack format deterministically.

$ sales_crm_render_brief.py --data brief.json --print-slack
:sunny: *ThakiCloud Sales Daily Brief* — 2026-07-03 (Thu)
*③ Urgent Actions*
1. [Company A] GPU expansion RFP deadline approaching <Electronic Times 2026-07-02>
...

Header numbering, link syntax, and thread structure are all glued on by code. That’s why orchestration and formatting have been pushed down to Sonnet plus code, while only the copy that reaches the customer directly is deliberately kept on a stronger model. Where you downgrade and where you hold the line stays cleanly separated.

A cost-optimization skill: measure, downgrade, roll back

Once the format is in code, the next question is whether the skill can actually move to a cheaper model. That’s not a call a person should make by eyeballing outputs. So we built a cost-optimization skill that runs a real task on both the current tier and a cheaper candidate tier, and lets code score the results and render the verdict.

The mechanics are simple. Pick one representative task, run it on both the cheap model and the current model, have a judge model score each dimension, and let code compute the verdict from those scores. If there’s no real reasoning gap and the overall score difference falls within a threshold, the skill downgrades. If there is a reasoning gap, it stays put. Every downgrade gets recorded in a central policy file, and if that skill later fails repeatedly, it’s automatically escalated back up to the stronger model. It’s a two-way policy: it saves money, but the moment quality wobbles it climbs back to the expensive model.

The key point is that this gate is a truth machine, not a downgrade machine. We tested whether our humanizer skill (which strips AI-sounding phrasing from writing) could move from Sonnet to Haiku. Here’s what came back.

$ cost_evolve.py evolve --skill humanizer
{ "skill": "humanizer", "current": "sonnet", "candidate": "haiku",
  "headline_gap": 2.0, "reasoning_gaps": 1, "decision": "hold",
  "reason": "1 reasoning gap(s): rephrasing_naturalness",
  "recommend": "Codify the format gaps first" }

The gate refused the downgrade. Haiku genuinely fell short at rewriting sentences to sound natural. At the same time, it flagged three formatting gaps and told us those can be pushed into code. That’s precisely the judgment we want: not downgrading indiscriminately, but picking out only what the data says is safe to downgrade.

Paxis runs this decision automatically, every night

A one-time manual optimization pass doesn’t stay useful for long. Skills keep multiplying and models keep changing underneath them. So inside Paxis, this decision runs on autopilot every night. Each night it surfaces downgrade candidates, runs them through the code gate, applies the downgrades that pass, and reports the rest along with the reasoning.

This is live today. Here’s an actual candidate report from the last few days, unedited.

# cost-evolve candidates — 2026-07-03
10 candidate(s), ranked by est. savings.
| lever            | target   | action                              |
| model-deescalate | sod-ship | opus -> sonnet, apply only if PASS  |
| model-deescalate | eod-ship | opus -> sonnet, apply only if PASS  |
| mcp-prune        | codegraph| disable unused MCP server            |
| format-determinism | ...    | extract format into code, retry downgrade |

Worth being honest about one thing here: this system doesn’t cut costs aggressively. The sod-ship and eod-ship skills above had just been promoted to a stronger model the day before, and the gate held off downgrading them, reasoning it was still too soon to reverse course. It only acts when it’s actually confident. Meanwhile, the default tier for the bulk of our skills is already cheap. The handful pinned to a stronger model are the ones where quality genuinely matters, like blog editing, news comics, and customer-facing copy, and everything else only climbs up when the data demands it.

Here’s the current state of things:

Expensive models are the exception. Cheap models are the default. And that line gets redrawn by data every single night.

If you have local GPUs, you can run the cheap tier yourself

Everything so far has been about moving tiers inside commercial APIs. Teams with local GPUs can take this a step further, because a meaningful chunk of that cheap tier can now be run directly on small open-weight models. Tool-calling capability in small and mid-sized open-weight models has recently reached a level that actually holds up in production.

Google’s Gemma 4 is released under Apache 2.0, and its small E2B and E4B variants run on-device on phones and Jetson-class boards, a good fit for routing, classification, and simple tool-calling workers. Zhipu’s GLM 5.2 is MIT-licensed and open-weight, leans hard into agentic tool use, and gets close to closed frontier model performance. Moonshot’s Kimi K2.7-Code is an open-weight model built specifically for coding and multi-step tool execution. Across the industry, teams are already routing 60 to 80 percent of agent traffic to open-weight models like these, and sending only the genuinely hard remainder up to a frontier API.

Our point here is simple. Most of what a team’s agents do isn’t high-difficulty creative work, so that portion runs fine on a small model on your own hardware. Keep the frontier model around, and reserve it for the small slice of work that’s genuinely hard.

If you need help

If your team wants to combine recent open-weight models like GLM 5.2 and Kimi K2.7-Code to optimize cost, get in touch. We’ll work with you to decide which tasks move to which tier, and what gets locked down with a code gate.

If your team has any local GPU capacity, we recommend our Metis inference platform. It optimizes inference for the hardware you already own, so small open-weight models run as efficiently as possible on your own infrastructure.

A structure where cheap models are the default and expensive models are the exception doesn’t stay that way after a single setup pass. It needs a loop that measures every night, downgrades only when it’s safe, and rolls back the moment something slips. Paxis provides that loop as a system.

Overview

Anyone who has run robots for a while sees a familiar waste. Even when a robot painstakingly succeeds at a task, most of the trial and error it went through is thrown away. On the next task it fumbles from scratch again. The fine-grained know-how earned through failure, such as how to recover when a gripper slips or the right approach angle for a particular object, is left nowhere in the system. A person reuses a knack once learned; a robot does not.

NVIDIA’s GEAR team addressed exactly this with ASPIRE (Agentic /Skills Discovery for Robotics, arXiv 2607.00272), released on June 30, 2026. The idea is simple but powerful. Instead of injecting a fixed policy into the robot, a large language model (LLM) writes the robot control code itself, runs that code in the real execution environment, observes the failures, repairs it iteratively, and then distills the verified repair experience into reusable Skills. Experience is not discarded; it compounds.

This post lays out ASPIRE’s architecture and measured results based on the verified paper and project page. It then argues that this is not a robotics-only story: the same pattern applies to software agents, and we close by connecting it to how ThakiCloud’s Agent-Native Cloud, Paxis, treats skills as first-class resources.

What ASPIRE Is

ASPIRE lays a continual-learning loop on top of the code-as-policy paradigm. Traditional robot learning often trains a neural policy on large volumes of demonstration data, then recollects data and retrains whenever a new situation appears. That carries two burdens: data collection is expensive, and knowledge learned once breaks easily in the face of new variations.

ASPIRE represents the policy not as neural-network weights but as executable code. When the LLM receives a task and writes a control program, that program runs in simulation or on a real robot. If execution fails, ASPIRE records the execution trajectory, analyzes the cause of failure, fixes the program, and tries again. Once this loop reaches success, the verified repair knowledge is stored in the skill library. The next task starts not empty-handed but by referencing that library.

flowchart TB
    A[Task instruction] --> B[LLM writes control code<br/>code-as-policy]
    B --> C[Real execution<br/>simulation or robot]
    C --> D{Success?}
    D -- Fail --> E[Log trajectory, analyze failure cause]
    E --> F[Repair the program]
    F --> C
    D -- Success --> G[Distill verified repair experience]
    G --> H[Reusable skill library]
    H -.next task references.-> B

The key is that last arrow. As the skill library feeds back into writing the next task, the system writes better code faster over time. The paper describes how this accumulated knowledge transfers across tasks in the form of grasp-recovery heuristics, navigation strategies, prompting recipes, and procedural fixes. It is not about solving one particular task well; the capacity to solve tasks itself accumulates.

Distilling Failure Into Skills

What sets ASPIRE apart from other robot learning is how it treats failure. In most pipelines, failure is something to discard, or at best a negative signal that trims a reward. ASPIRE treats failure as learning material. A failed execution’s trajectory contains the information of “what went wrong and why,” and the LLM reads it to reason about where and how to fix the code.

If that repair ended as a one-off improvisation, its value would be limited. ASPIRE’s contribution is distilling the verified repair into a generalizable skill. For example, if a slip while picking up a particular object is fixed into a success, the recovery procedure is abstracted into a form that is not tied to that object alone but can be reapplied to similar grasping situations. Because a skill is a code fragment expressed as text, a person can read and audit it, and it can be managed and versioned as a library. This is a major advantage over black-box neural policies.

Thanks to this structure, ASPIRE lifts performance with no additional training data. Instead of collecting new demonstrations to retrain the model, simply repeating the execute-fail-repair-distill loop raises the success rate. In robotics, where data collection is the bottleneck, this is a practically important property.

Real Experimental Results

The numbers reported in the paper and project page show this loop is more than a concept. The most striking result is Robosuite’s bimanual object handover task. Starting from a baseline success rate of 20%, it climbed to 92% through iterative debugging alone, a figure reached with zero additional demonstration data, using only the execute-repair loop.

The advantage holds as task types broaden. The paper reports that ASPIRE outperforms prior methods by up to 77% on LIBERO-Pro (a manipulation task under perturbation), by 72% on Robosuite bimanual handover, and by up to 32% on BEHAVIOR-1K (a long-horizon household task). In particular, in the long-horizon generalization experiments, the success rate rose steadily as the skill library grew. The fact that library growth and performance rise together supports this system’s central claim that experience genuinely compounds.

The research team spans NVIDIA’s GEAR lab together with researchers from the University of Michigan (UMich), the University of Illinois (UIUC), UC Berkeley, and Carnegie Mellon (CMU). NVIDIA stated that ASPIRE’s skill library would be open-sourced at release, with details on the project page (research.nvidia.com/labs/gear/aspire). That said, the specific license of the code repository was not confirmed as clearly stated at release time, so it is safer to check the actual repository’s license terms directly before adopting it.

Implications for ThakiCloud Products

ASPIRE targets a robot arm, but the message its architecture sends carries straight over to software agents. Take the sentence “an agent writes code, learns from failure, and distills verified experience into reusable skills stacked in a library,” swap “robot” for “cloud agent,” and you get exactly the structure ThakiCloud’s Agent-Native Cloud, Paxis, is built toward.

Paxis treats Skills, Tools, Policies, and Audit Logs as first-class resources. ASPIRE’s skill library corresponds in Paxis to a skill harness of some 960 skills selected via BM25, and ASPIRE’s code-as-policy execution corresponds to Paxis’s isolated sandbox execution. Just as ASPIRE records and analyzes failure trajectories, Paxis passes every agent action through a policy gate and audit log so that what failed and why can be traced retroactively. And the self-improvement that ASPIRE’s distillation loop aims for is realized in Paxis as self-evolving skills: the lessons drawn from execution feed back into new skills or skill revisions, so the next run does not start empty-handed.

From an infrastructure standpoint, ThakiCloud’s ai-platform provides the foundation for this loop. An ASPIRE-style repeated execute-repair loop has to run simulation and inference in bulk, which presupposes elastic scheduling of GPU resources. ai-platform is designed to absorb such repetitive workloads cost-effectively on top of Kueue-based GPU scheduling and multi-tenant isolation. Low-cost serving makes the agent’s execute-repair repetition economical, and the skills accumulated that way in turn raise the agent’s autonomy, a virtuous cycle. For customers who require on-premises and sovereign environments, being able to run this entire loop inside their own infrastructure is especially meaningful.

Limitations and Counterarguments

Impressive as ASPIRE’s results are, a few reservations are in order. First, the reported numbers come mostly from simulation benchmarks (Robosuite, LIBERO-Pro, BEHAVIOR-1K). Iterative debugging in simulation is cheap and safe, but on real hardware every attempt carries time, wear, and safety risk. Whether the economics of the execute-fail-repair loop hold on physical robots needs separate validation.

Second, code-as-policy is strong on tasks where the LLM can write valid control code, but for precise continuous control or actions needing high-frequency feedback, there remains a region hard to express as code. ASPIRE appears to delegate such low-level control to existing skills or primitives, and the quality of those primitives may cap overall performance.

Third, as the skill library grows, the burden of retrieval and selection increases. The result that library growth tracks with performance gains is encouraging, but whether picking a wrong skill or a stale skill triggering wrong answers becomes a problem at larger scale bears continued watching. This is a challenge Paxis’s skill harness has already faced, and BM25 selection, the policy gate, and audit logs are precisely the mechanisms for managing that risk.

Even so, the direction ASPIRE points to, not discarding failure but compounding it as verified skills, is likely to become a standard on both the robotics and software-agent sides. The real contribution of this work is the shift in perspective: growing capability through accumulated skills rather than through data.

Sources

• ASPIRE: Agentic /Skills Discovery for Robotics, arXiv 2607.00272: https://arxiv.org/abs/2607.00272
• Project page (NVIDIA GEAR): https://research.nvidia.com/labs/gear/aspire/
• Paper page (Hugging Face): https://huggingface.co/papers/2607.00272

Overview

When a coding agent finishes hours of work, showing the result to someone else is still surprisingly clumsy. You capture terminal logs and paste them, summarize the changes by hand, or build a separate dashboard. Explaining the work often takes more effort than the work itself.

In July 2026, Anthropic expanded the Artifacts feature in Claude Code to the Pro and Max plans. A capability that had been limited to Team and Enterprise is now open to individual developers. The idea is simple. When you ask for an artifact, Claude writes the code, publishes it live to claude.ai, and keeps updating that page in real time while the session runs. The page is private to your account and fully self-contained.

This post explains exactly what Claude Code artifacts are, why the Pro and Max expansion matters, and how the pattern can be absorbed from the perspective of ThakiCloud’s agent platform Paxis and its AI infrastructure ai-platform.

What Claude Code Artifacts Are

Artifacts originally rendered code or documents in a separate panel inside a claude.ai conversation. The artifacts that just arrived in Claude Code are a little different. Instead of the output of a single exchange, they turn the progress of an entire coding session into one living visual page.

Anthropic lists four example uses: PR walkthroughs, system explainer pages, dashboards, and release checklists. What they share is that each is a human-readable summary of what is happening right now. And while the session continues its work, that page updates itself.

The flow from work to publication looks like this.

flowchart TB
    A[Developer requests an artifact] --> B[Claude Code writes the code]
    B --> C[Publish live to claude.ai]
    C --> D{Session keeps running}
    D -->|work state changes| E[Page updates in real time]
    E --> D
    D -->|complete| F[Self-contained page finalized]
    F --> G[Share the published link]
    G --> H[Recipient views without an account]
    G --> I[Account holder remixes an editable copy]

Two design decisions stand out here. First, the page is self-contained. Without an external build pipeline or hosting setup, everything it needs lives in the single published page. Second, the default is private. The page belongs to your account, and nobody else can see it until you press publish and share the link.

Why the Pro and Max Expansion Matters

The feature itself had been available on Team and Enterprise for a few months. The key change now is that the plan boundary has moved down.

To be precise: regular artifacts created in a claude.ai conversation could already be published on every plan, including Free, Pro, and Max. The artifacts that turn a Claude Code session into a live page, on the other hand, were Team and Enterprise only. That boundary has now extended to Pro and Max. Without an organization seat, an individual developer can turn their own session into a shareable page.

Why this matters becomes clear when you look at how individual developers actually work. When an open-source contributor finishes a long refactor, they need a way to convey the context of the change to a reviewer. The same holds for a solo developer running a side project who wants to track their own progress or demo it to a peer. Until now, these users could not touch the feature unless they were tied to an organization plan. The Pro and Max expansion closes that gap.

One more note: over the same period, Anthropic also temporarily raised the weekly Claude Code usage limits for Pro, Max, and Team. Access and headroom opened together, which gives individual developers real room to try the feature.

How It Works in Practice

Using it feels conversational. During a session, when you say “turn this work into an artifact,” Claude Code generates a page capturing the current progress and publishes it to claude.ai. Open the returned link and you see a visual page summarizing the work so far, and as the session keeps running, the page updates without a refresh.

Sharing happens through the publish button at the bottom of the artifact panel. Whoever receives the link can view the page without a Claude account. Someone who does have an account can use remix to make their own editable copy. In other words, a single artifact is both a read-only shared object and a starting point that someone else can pick up and develop.

The privacy model is also clear. A page created in Claude Code is private to your account by default. It is exposed externally only the moment you publish and hand over a link, and until then only you can see it. For developers handling sensitive internal work, this default matters, because there is no path to accidental exposure.

The most practical combination in this flow is the PR walkthrough. After finishing a long change, requesting an artifact yields a page covering what changed and why, which files are affected, and how it was verified. The reviewer can grasp the context from this page before reading the diff. Incident response pages and release checklists work the same way, letting the agent maintain a human-readable summary on its own.

What It Means for ThakiCloud

The real implication of this feature goes beyond the convenience of a single tool. The pattern itself, “keep an agent’s work output as a human-readable, shareable artifact, and keep it live,” is a core challenge for any agent platform.

The Paxis lens (agent output as a first-class resource). ThakiCloud’s Paxis is an Agent-Native Cloud control plane that runs on top of ai-platform and treats Skills, Tools, Policies, and Audit Logs as first-class resources. What Claude Code artifacts demonstrate is a way to expose an agent’s intermediate and final output as a separate observation channel. When a DAG of multiple agents in Paxis performs a long task, condensing each node’s progress into a human-readable live page lets an operator grasp the flow without scrolling logs. Combine that with Paxis’s policy gates and audit logs, and the artifact becomes a controlled output that is traceable down to “who made and shared what, and when.” In the same spirit as Anthropic’s default-private artifacts, Paxis can layer policy-based access control onto output sharing and scale it to the organization level.

The ai-platform lens (internal operations pages). On the infrastructure side, self-contained pages fit internal dashboards and incident pages well. ThakiCloud’s ai-platform runs K8s, Kueue GPU scheduling, and multi-tenant vLLM serving, and the batch and serving workloads that run on it need a channel to convey state to people. If you let an agent maintain a release checklist or a deployment progress page on its own, you gain operational visibility in on-prem and sovereign environments without adding a separate observability stack. Because self-containment reduces the dependence on external hosting, it is a light burden even in customer environments with strong air-gap requirements.

The two lenses complement each other. If ai-platform runs agent workloads at low cost and Paxis treats their output as shareable artifacts under policy and audit, you can reproduce the experience of “an agent works and its result immediately becomes something a human can read” on your own platform.

Limitations and Counterpoints

There are clear points where expectations should be tempered.

First, the feature is tied to publishing on claude.ai. Because the page is hosted on Anthropic infrastructure, it is hard to use as-is in a fully air-gapped environment or where data exfiltration is prohibited. Customers with strong sovereignty requirements need a self-hosted alternative, and that is precisely the gap an on-prem-oriented platform like ThakiCloud can fill.

Second, self-contained pages are excellent for simple summaries and dashboards, but they are limited for complex interactions or large-scale data integration. A published artifact is essentially a lightweight frontend and does not replace heavy backend logic.

Third, real-time updates hold only while the session is alive. Once the session ends, the page freezes as a snapshot from that moment. If you need a continuously updating operations dashboard, you still need a separate pipeline.

In short, the Pro and Max expansion of Claude Code artifacts significantly lowers the barrier for individual developers to turn agent work into shareable output. The constraints of hosting and persistence remain, and that is exactly where an agent platform with policy, audit, and on-prem capabilities offers complementary value. Absorb the convenience of the tool, and fill the areas that require control and sovereignty with your own platform. That is the realistic approach.

Sources

• ClaudeDevs (@ClaudeDevs) announcement post
• Publish and share artifacts (Claude Help Center)
• What are artifacts and how do I use them? (Claude Help Center)

개요

“GPU가 두 장 있으니 Prefill과 Decode를 따로 태우면 더 빠르지 않을까”는 서빙을 만지는 사람이라면 한 번쯤 떠올리는 생각입니다. 저희도 그 가설을 실제 하드웨어에서 검증했습니다. NVIDIA B200 두 장 위에서 vLLM 0.24로 세 가지 배치를 같은 워크로드로 돌려 초당 생성 토큰(TPS)을 쟀습니다. 대상 모델은 NVIDIA가 공개한 Qwen3.6-27B-NVFP4와 RedHat이 공개한 gemma-4-26B-A4B-it-FP8-Dynamic 두 가지입니다.

결론을 먼저 말씀드리면, 두 장뿐인 환경에서 총 처리량의 승자는 Prefill/Decode 분리가 아니었습니다. 분리는 오히려 총 TPS가 가장 낮았고, 대신 입력이 길고 출력이 짧은 트래픽에서 토큰 간 지연을 서너 배 낮추는 데서 값을 했습니다. 그런데 이 결과는 NVIDIA나 중국 대규모 서빙 사례가 보고하는 큰 성능 향상과 모순되지 않습니다. 분리의 이득은 규모와 SLO에 달린 최적화이고, 우리는 그 곡선의 작은 끝을 잰 것이기 때문입니다. 그래서 이 글은 우리 실측 수치와 맨바닥 B200를 돌게 만든 과정에 더해, DistServe와 Splitwise, Mooncake, DeepSeek, NVIDIA Dynamo의 근거를 놓고 언제 분리하고 언제 그냥 데이터병렬이나 텐서병렬로 가야 하는지를 판정하는 가이드까지 함께 정리합니다.

왜 이 실험을 했나

Prefill과 Decode는 성격이 다른 연산입니다. Prefill은 입력 전체를 한 번에 밀어 넣는 연산 집약적 단계이고, Decode는 토큰을 하나씩 뽑는 메모리 대역폭 집약적 단계입니다. 한 GPU에서 둘을 섞으면 무거운 Prefill이 Decode 스트림 사이에 끼어들어 토큰이 끊깁니다. 그래서 큰 클러스터에서는 Prefill 전용 노드와 Decode 전용 노드를 나누는 분리(disaggregation) 구조가 표준이 되어가고 있습니다.

문제는 “GPU가 딱 두 장”일 때입니다. 한 장을 Prefill 전용으로 묶으면 Decode가 바쁠 때 그 장이 놀고, Prefill이 한가할 때도 Decode를 도울 수 없습니다. 그래서 저희는 분리가 이득이라고 가정하지 않고, 같은 모델을 두 장에 그냥 복제하는 데이터병렬을 정식 경쟁자로 세워 측정으로 판정하기로 했습니다.

실험 환경

호스트는 드라이버만 깔린 베어메탈이었고, 나머지 소프트웨어 스택은 실행하면서 확인하고 확정했습니다.

두 모델 모두 가중치가 B200 한 장에 들어갑니다. NVFP4는 약 15GB, FP8은 약 27GB이므로 텐서병렬로 굳이 쪼갤 필요가 없습니다. 그래서 두 장을 쓰는 세 가지 배치를 비교했습니다. 한 인스턴스를 두 장에 텐서병렬로 펴는 TP=2, 두 복제를 각 장에 올리는 데이터병렬 DP=2, 그리고 Prefill을 GPU0에 Decode를 GPU1에 두고 KV 캐시를 NIXL로 넘기는 분리 1P1D입니다.

측정 방법

부하 생성은 vLLM 내장 vllm bench serve를 썼고, 워크로드는 두 축으로 잡았습니다. 하나는 Decode가 무거운 트래픽(입력 512, 출력 2048), 다른 하나는 Prefill이 무거운 트래픽(입력 7500, 출력 200)입니다. 요청은 전량을 한 번에 투입해 포화 처리량을 봤습니다. 읽은 지표는 총 출력 처리량(TPS)과 토큰 간 지연(TPOT)입니다.

서버 기동과 벤치는 아래와 같은 형태로 돌렸습니다. 백엔드 환경 변수는 이 박스에서 필수였는데, 그 이유는 뒤에서 설명합니다.

# 공통 환경 (nvcc 부재 대응)
export VLLM_ATTENTION_BACKEND=TRITON_ATTN
export VLLM_USE_FLASHINFER_SAMPLER=0

# 데이터병렬 2복제 (한 엔드포인트, 두 장)
vllm serve $MODEL --data-parallel-size 2 --gpu-memory-utilization 0.90 \
  --max-model-len 32768 --trust-remote-code

# 벤치 (Decode 무거운 워크로드 예시)
vllm bench serve --model $MODEL --dataset-name random \
  --random-input-len 512 --random-output-len 2048 \
  --num-prompts 128 --request-rate inf --ignore-eos

분리는 Prefill 서버와 Decode 서버를 따로 띄우고 --kv-transfer-config로 NixlConnector를 물린 뒤, vLLM이 제공하는 프록시로 묶었습니다.

# Prefill (GPU0, producer)
CUDA_VISIBLE_DEVICES=0 VLLM_NIXL_SIDE_CHANNEL_PORT=5600 \
vllm serve $MODEL --port 8100 --tensor-parallel-size 1 \
  --kv-transfer-config '{"kv_connector":"NixlConnector","kv_role":"kv_producer"}'

# Decode (GPU1, consumer)
CUDA_VISIBLE_DEVICES=1 VLLM_NIXL_SIDE_CHANNEL_PORT=5601 \
vllm serve $MODEL --port 8200 --tensor-parallel-size 1 \
  --kv-transfer-config '{"kv_connector":"NixlConnector","kv_role":"kv_consumer"}'

결과: Qwen3.6-27B-NVFP4

그림이 선명합니다. 총 TPS는 데이터병렬이 두 워크로드 모두에서 1등이고, 분리가 꼴찌입니다. Decode 무거운 워크로드에서 데이터병렬은 텐서병렬보다 8% 높고 분리보다 37% 높습니다. Prefill 무거운 워크로드에서는 격차가 더 벌어져 데이터병렬이 분리의 1.7배입니다. 두 장뿐인데 한 장을 Prefill 전용으로 묶은 대가를, 노는 시간이 그대로 청구한 셈입니다.

그런데 분리가 유일하게 이긴 칸이 있습니다. Prefill 무거운 워크로드의 토큰 간 지연이 9.9ms로, 텐서병렬 44ms나 데이터병렬 33ms의 4분의 1 수준입니다. 이것이 분리의 존재 이유입니다. 섞인 구성에서는 무거운 Prefill이 Decode 사이에 끼어들어 토큰이 끊기는데, 분리 구성에서는 Decode 전용 장이 Prefill에 방해받지 않아 토큰이 매끄럽게 나옵니다. 분리는 “많이”가 아니라 “고르게”를 위한 기술이라는 교과서적 설명이, 그대로 숫자로 나타났습니다.

결과: gemma-4-26B-A4B-it-FP8-Dynamic

gemma는 MoE 모델이라 서빙 스택이 dense 모델보다 까다로웠습니다. 텐서병렬과 분리는 정상 측정됐지만, 데이터병렬은 두 번 시도했는데 모두 vLLM 0.24의 MoE와 데이터병렬을 함께 쓰는 경로에서 기동에 실패했습니다. 첫 시도는 CUTLASS MoE 워밍업 단정에서, 배치 토큰 상한을 낮춘 두 번째 시도는 KV 캐시 메모리 프로파일링의 MoE 순전파에서 죽었습니다. 즉 이 버전에서 gemma를 데이터병렬로 띄우는 것은 현재 지원되지 않으며, 그 자체가 유의미한 발견입니다. MoE 모델은 데이터병렬 안정성이 dense 모델보다 낮습니다. 측정 가능한 두 구성만 비교하면, 총 TPS는 텐서병렬이 분리보다 높다는 패턴이 gemma에서도 그대로 유지됩니다. 그리고 분리의 Prefill TPOT가 8.7ms로 텐서병렬 40.9ms를 압도하는 점도 Qwen과 동일합니다.

그래서 언제 분리하고, 언제 그냥 DP/TP인가

여기서 자연스러운 의문이 생깁니다. NVIDIA 블로그도, 중국의 대규모 서빙 시스템들도 분리로 큰 성능 향상을 보고하는데, 왜 우리 결과는 반대일까요. 문헌을 실제로 뒤져 보면 답은 분명합니다. 우리 결과는 그들과 모순되지 않습니다. 분리의 이득은 규모와 SLO에 의존하는 최적화이지 보편적 승리가 아니며, 우리는 그 곡선의 작은 끝을 측정한 것뿐입니다.

이 크로스오버를 정면으로 연구한 논문이 있습니다. “Beyond the Buzz: A Pragmatic Take on Inference Disaggregation”(arXiv:2506.05508)는 분리의 이점이 prefill이 무거운 트래픽에서 가장 크고, 반대로 출력이 긴 decode 중심 트래픽이나 느슨한 SLO, 작은 모델에서는 오히려 같은 GPU에 얹는 편(piggybacking)이 앞선다고 정리합니다. 8B급 작은 모델은 매핑되는 GPU 수가 적어 prefill과 decode를 나눌 여지 자체가 좁고, KV 캐시도 HBM에 여유롭게 들어가 굳이 옮길 이유가 없다는 것입니다. 두 장에서 27B 모델을 돌린 우리 상황이 정확히 그 구간입니다.

분리가 이기는 조건

분리로 큰 이득을 보고한 사례들은 공통 조건을 공유합니다. 첫째, GPU가 매우 많습니다. UCSD Hao AI Lab의 회고는 분리가 필요해지는 지점을 수백에서 수천 장 규모로 설명합니다(회고 글). 둘째, 지연 SLO가 빡셉니다. 분리의 대표 논문 DistServe(OSDI 2024)의 핵심 지표는 원시 처리량이 아니라 SLO를 90% 넘게 지키면서 몇 배의 요청을 소화하느냐, 즉 goodput입니다. OPT 13B에서 175B를 NVLink로 묶은 A100 클러스터에서 훨씬 빡센 SLO를 견뎠다고 보고합니다(USENIX, arXiv:2401.09670). 셋째, 대형 또는 MoE 모델을 비대칭 병렬로 태웁니다. DeepSeek-V3/R1 계열은 prefill을 좁은 전문가 병렬로, decode를 넓은 전문가 병렬로 나눠 텐서병렬 대비 decode 처리량이 크게 올랐다고 공개했는데, 그 설정이 96장 H100에 prefill 4노드와 decode 9노드를 나눠 얹는 규모였습니다(LMSYS). 넷째, 긴 컨텍스트로 KV 캐시가 크고 재사용됩니다. Mooncake는 KV 캐시 중심 분리로 긴 컨텍스트에서 강점을 보고합니다(arXiv:2407.00079). 다섯째, KV를 싸게 옮길 고속 패브릭이 있습니다. Splitwise는 InfiniBand로, Mooncake는 수백 Gbps급 RDMA로 KV를 넘겨 전송 부담을 낮췄습니다(Microsoft Research). NVIDIA가 Dynamo와 GB200 NVL72로 보고하는 큰 배수도 671B급 초대형 모델을 수십 장 규모 랙에서 돌린 결과입니다(NVIDIA).

DP/TP가 나은 조건

반대로 아래 조건에서는 그냥 데이터병렬이나 텐서병렬로 복제하는 편이 낫습니다. 모델이 GPU 한두 장에 들어갈 만큼 작을 때, 출력이 길어 decode가 지배하는 트래픽일 때, 지연 SLO가 느슨할 때, GPU가 소수여서 prefill 풀과 decode 풀을 따로 놀지 않게 채울 여유가 없을 때, 개발이나 저QPS 일회성 워크로드라 분리 운영의 복잡도가 정당화되지 않을 때, 그리고 노드 간 대역폭이 NVLink나 InfiniBand급이 아니라 PCIe급이라 KV 전송이 오히려 병목이 될 때입니다. 우리 실험의 2×B200 환경은 이 목록의 여러 항목에 정확히 해당합니다. 27B 모델이 한 장에 들어가고, GPU가 둘뿐이며, 총 처리량이 목표였습니다.

판정을 가르는 네 변수

결국 선택은 네 가지 변수의 조합으로 결정됩니다. prefill과 decode의 연산 비율(prefill이 무거울수록 분리 유리), 지연 SLO의 빡셈(빡셀수록 분리 유리), GPU 규모(클수록 분리 유리), 그리고 KV 전송 비용 대비 절감량(캐시가 크고 재사용되거나 패브릭이 빠를수록 분리 유리)입니다. 어느 하나라도 반대쪽이면 분리의 이득은 줄고, 소수 GPU에 작은 모델에 느슨한 SLO가 겹치면 분리는 손해입니다.

근거 요약

즉 분리는 “초대형 모델을 많은 GPU에 걸쳐 얹고, 빡센 지연 목표를 고속 패브릭 위에서 맞추는” 케이스의 기술입니다. 두 장에서 중형 모델을 돌리며 총 처리량을 노린다면 데이터병렬이 정답이고, 이것이 우리 실측과 문헌이 함께 가리키는 결론입니다. 위 배수들은 각 논문이 측정한 특정 규모의 값이며 일부(Mooncake 실측치, TensorRT-LLM 자체 수치)는 원문 간 표현이 엇갈려 그대로 인용하기 전 재확인이 필요합니다.

맨바닥 B200를 돌게 만들기까지

수치만큼 값진 것이 “어떻게 돌게 만들었나”입니다. 이 호스트는 드라이버만 있고 추론 스택이 없는 상태였고, 아래 벽들을 차례로 넘었습니다.

첫째, CUDA 컴파일러 nvcc가 없어 FlashInfer가 샘플러와 어텐션 커널을 런타임에 빌드하려다 실패했습니다. 어텐션 백엔드를 Triton으로 바꾸고 FlashInfer 샘플러를 끄자 정상 동작했습니다. 이는 곧, nvcc를 설치하면 Blackwell 전용 FlashInfer 고속 커널로 더 높은 TPS를 노릴 여지가 남아 있다는 뜻이기도 합니다.

둘째, 첫 서버 기동이 800초 안팎으로 매우 길었습니다. torch.compile과 CUDA 그래프 캡처 때문인데, 데이터병렬은 엔진 코어 두 개가 동시에 컴파일하느라 vLLM 기본 준비 타임아웃 600초를 넘겨 죽었습니다. 타임아웃을 1800초로 올려 해결했습니다.

셋째, Qwen3.6의 하이브리드 어텐션은 Mamba 계열 conv 상태를 갖는데, 이를 NIXL로 전송하려면 특정 conv 상태 레이아웃이 필요했습니다. 에러 메시지가 알려준 대로 VLLM_SSM_CONV_STATE_LAYOUT=DS를 설정하자 KV 전송이 성립했고, 프록시를 통한 한 건의 정확도 확인으로 분리가 실제로 올바르게 동작함을 검증했습니다.

이 발견들은 다시 밟지 않도록 재사용 가능한 실험 스킬에 실패 사례로 박아 두었습니다. 같은 벽을 다음 사람이 다시 만나지 않는 것, 그것이 실험을 자산으로 만드는 방법이라고 생각합니다.

ThakiCloud 관점에서

저희는 쿠버네티스 위에서 GPU 추론을 서빙하는 주권형 AI 플랫폼을 만듭니다. 이 실험이 저희 운영에 주는 시사점은 분명합니다. “분리가 최신이니까 분리하자”는 유행 추종은 소수 GPU 환경에서 오히려 처리량을 깎을 수 있고, 반대로 대규모 고QPS 서비스에서 분리를 안 쓰는 것은 지연 SLO를 놓치는 일이라는 것입니다. 정답은 하나로 고정되지 않고, 앞 절의 네 변수, 곧 GPU 규모와 모델 크기, 트래픽의 prefill과 decode 비율, 지연 SLO, 그리고 패브릭 속도가 함께 정합니다.

문제는 그 크로스오버가 회사마다, 워크로드마다 다르다는 점입니다. 같은 27B 모델이라도 2장에서는 데이터병렬이 답이지만, 같은 모델을 수십 장에 얹어 긴 컨텍스트를 빡센 SLO로 서빙한다면 분리가 답이 됩니다. 그 경계를 감으로 찍으면 GPU 예산을 태우거나 SLO를 놓칩니다. 저희가 하는 일이 바로 이것입니다. 고객의 실제 하드웨어와 실제 트래픽 위에서 이번 글처럼 토폴로지별 수치를 뽑아 그 경계를 측정으로 찾고, 데이터병렬과 텐서병렬과 분리 사이를 워크로드에 맞춰 전환하는 서빙 플랫폼을 함께 구축합니다. 이번 실험에 쓴 벤치 파이프라인과 접속 자동화도 재사용 가능한 자산으로 관리해, 다음 모델과 다음 하드웨어에서 같은 판단을 며칠이 아니라 몇 시간에 내릴 수 있게 합니다.

그래서 B200이든 H200이든 새 가속기를 도입하며 “우리 워크로드에는 어떤 토폴로지가 맞는가”를 정해야 하는 팀이라면, 저희와 함께 그 답을 측정으로 내리는 것이 가장 빠른 길이라고 생각합니다. 유행이 아니라 여러분의 숫자로 결정하도록 돕는 것, 그것이 ThakiCloud가 추론 최적화에서 제공하는 가치입니다.

결론과 한계

두 모델을 2×B200에서 가장 빠르게 서빙하라는 요구에 대한 실측 답은, 총 처리량이 목표라면 데이터병렬이고 Prefill/Decode 분리는 아니라는 것입니다. 다만 입력이 길고 출력이 짧으며 낮고 고른 토큰 지연이 목표인 서비스라면 분리가 TPOT를 서너 배 낮춰 주므로 그때는 분리가 정답입니다. 선택은 처리량이냐 지연 안정이냐이며, 이 실험은 그 트레이드오프에 실제 숫자를 붙였습니다.

한계도 정직하게 남깁니다. 어텐션 백엔드가 Triton으로 고정되어 Blackwell 네이티브 FlashInfer와 NVFP4 고속 경로의 상한은 측정하지 못했습니다. nvcc 설치가 후속 과제입니다. 요청률은 포화 한 점만 봤고 지연과 처리량의 전체 곡선은 그리지 않았습니다. Qwen의 다중 토큰 예측 speculative decoding과 gemma의 expert-parallel 같은 모델별 처리량 레버도 후속 축으로 남겼습니다. 이들을 더하면 절대 수치는 올라갈 수 있으나, 두 장에서 분리는 총 처리량을 위한 것이 아니라는 이 실험의 핵심 결론은 바뀌지 않을 것으로 봅니다.

참고 자료

• 모델 A: nvidia/Qwen3.6-27B-NVFP4
• 모델 B: RedHatAI/gemma-4-26B-A4B-it-FP8-Dynamic
• vLLM 분산 서빙 문서: docs.vllm.ai
• DistServe (OSDI 2024): arXiv:2401.09670
• Splitwise (ISCA 2024): Microsoft Research
• Mooncake (Kimi/Moonshot): arXiv:2407.00079
• DeepSeek 대규모 전문가 병렬: LMSYS 블로그
• NVIDIA Dynamo: NVIDIA 개발자 블로그
• 크로스오버 연구 (Beyond the Buzz): arXiv:2506.05508
• 분리 서빙 18개월 회고: Hao AI Lab

결론부터 말하면 이렇습니다. 비싼 모델은 스킬을 처음 만들 때만 필요합니다. 일단 완성한 스킬의 포맷을 코드로 내리면, 실제로 돌리는 일은 훨씬 싼 모델로 충분합니다. 그리고 “충분한지”는 사람의 직관이 아니라 코드가 측정한 결과로 판정해야 합니다.

대부분의 업무는 프론티어 모델이 필요 없다

에이전트가 하루에 처리하는 일을 뜯어보면 성격이 갈립니다. 한쪽에는 진짜 어려운 추론이 있습니다. 애매한 아키텍처 결정, 미묘한 디버깅, 처음 보는 문제의 분해 같은 것들입니다. 다른 한쪽에는 정형화된 반복 작업이 있습니다. 라우팅, 분류, 요약, 렌더링, 규격 검사가 여기 속합니다. 문제는 두 종류를 같은 프론티어 모델에 몰아넣고 매번 최고가로 결제한다는 데 있습니다.

정형화된 작업의 품질은 사실 모델 지능보다 가드레일이 좌우합니다. 출력 포맷이 흔들리는 이유는 모델이 멍청해서가 아니라, 포맷을 산문으로 “부탁”했기 때문입니다. 길이 상한, 허용 enum, 렌더링 규격, 통과 기준을 코드가 강제하면 그 작업은 값싼 모델로도 안정적으로 나옵니다. 품질을 지키는 것은 더 비싼 모델이 아니라 코드 게이트입니다.

비싸게 만들고, 포맷을 코드로 내리고, 싸게 돌린다

우리가 실제로 쓰는 패턴은 세 단계입니다.

먼저 스킬을 비싼 모델로 완성합니다. 처음에는 판단의 여지가 많고 실패 사례를 발라내야 하므로 좋은 모델이 값을 합니다. 다음으로 스킬의 결정론적인 부분을 코드로 뽑아냅니다. 렌더링, enum 정규화, 길이 검사, 중복 제거, JSON 조립처럼 모델이 매번 다르게 풀 필요가 없는 것들입니다. 마지막으로 워커 모델을 싼 티어로 내립니다. 이제 모델은 본문 콘텐츠만 생성하고, 숫자와 포맷과 판정은 코드가 소유하기 때문입니다.

이 패턴이 왜 안전한지 실제 코드로 보여드리겠습니다. 아래는 트위터 타임라인을 슬랙으로 정리하는 스킬의 검증 게이트를 실제 산출물에 돌린 결과입니다. 이 스킬은 하루 다섯 번, 누적 1,000건이 넘는 레코드를 만들어 왔고, 예전에는 트윗마다 Opus를 썼지만 지금은 Sonnet으로 돌아갑니다.

$ tweet_validate.py --dir outputs/twitter/hjguyhan
validated: 2/2 passed; decisions=1 (code-capped)
{"status": "ok", "passed": 2, "total": 2, "decisions": 1, "failed_ids": []}

여기서 글자 수, 링크 수, 상태 enum, 통과 여부는 모델이 주장한 값이 아니라 코드가 실제 문자열에서 다시 계산한 값입니다. 판정 플래그도 코드가 상위 몇 개로 잘랐습니다. 이 게이트는 어떤 모델이 콘텐츠를 썼든 똑같이 동작합니다. 그래서 워커를 Opus에서 Sonnet으로 내려도 품질이 흔들리지 않았습니다.

영업 CRM 브리핑도 같은 구조입니다. 아래는 데이터 JSON을 넣으면 코드가 슬랙 포맷을 그대로 찍어내는 렌더러의 실제 출력입니다.

$ sales_crm_render_brief.py --data brief.json --print-slack
:sunny: *ThakiCloud 영업 데일리 브리프* — 2026-07-03 (목)
*③ 긴급 액션*
1. [A사] GPU 증설 RFP 마감 임박 <전자신문 2026-07-02>
...

헤더 번호, 링크 문법, 쓰레드 구조는 전부 코드가 붙입니다. 그래서 오케스트레이션과 포맷은 Sonnet과 코드로 내려가 있고, 고객에게 직접 나가는 문안 생성만 의도적으로 상위 모델을 유지합니다. 어디를 내리고 어디를 남길지가 뒤섞이지 않습니다.

비용 최적화 스킬: 측정하고, 내리고, 되돌린다

포맷을 코드로 내렸다면 다음 질문은 “그래서 이 스킬은 정말 싼 모델로 내려도 되는가”입니다. 이걸 사람이 눈대중으로 판단하면 안 됩니다. 그래서 스킬을 대상으로 실제 작업을 싼 티어와 현재 티어에 각각 돌려보고, 코드가 그 결과를 채점해 판정하는 비용 최적화 스킬을 만들었습니다.

동작은 단순합니다. 대표 작업 하나를 정해 싼 모델과 현재 모델에 각각 실행하고, 심판 모델이 차원별 점수만 매기면, 코드가 그 점수로 판정을 계산합니다. 진짜 추론 격차가 없고 전체 점수 차가 임계 안이면 강등하고, 추론 격차가 있으면 그대로 둡니다. 강등은 중앙 정책 파일에 기록되며, 나중에 그 스킬이 연속으로 실패하면 자동으로 다시 상위 모델로 되돌아갑니다. 비용을 아끼되 품질이 흔들리는 순간 다시 비싼 모델로 올라가는, 양방향 정책입니다.

핵심은 이 게이트가 “강등 기계”가 아니라 “진실 기계”라는 점입니다. 실제로 자주 쓰는 humanizer 스킬(AI 글 흔적을 지우는 스킬)을 Sonnet에서 Haiku로 내릴 수 있는지 측정해 봤습니다. 결과는 이렇습니다.

$ cost_evolve.py evolve --skill humanizer
{ "skill": "humanizer", "current": "sonnet", "candidate": "haiku",
  "headline_gap": 2.0, "reasoning_gaps": 1, "decision": "hold",
  "reason": "1 reasoning gap(s): rephrasing_naturalness",
  "recommend": "먼저 포맷 갭을 코드로 프로그램화하라" }

게이트는 강등을 거부했습니다. Haiku가 문장을 자연스럽게 다시 쓰는 능력에서 실제로 밀렸기 때문입니다. 동시에 포맷 격차 세 개를 짚으며 “이건 코드로 내리면 된다”고 알려줍니다. 이게 정확히 우리가 원하는 판단입니다. 아무거나 싸게 내리는 게 아니라, 내려도 되는 것만 데이터로 골라냅니다.

팩시스는 이 판단을 매일 밤 자동으로 돌린다

한 번 손으로 하는 최적화는 오래가지 못합니다. 스킬은 계속 늘고, 모델도 계속 바뀌기 때문입니다. 그래서 팩시스에서는 이 판단을 매일 밤 자동으로 돌립니다. 밤마다 강등 후보를 발굴하고, 코드 게이트로 검증하고, 안전한 것만 내리고, 나머지는 근거와 함께 보고합니다.

실제로 돌고 있습니다. 최근 사흘 치 후보 산출물이 그대로 남아 있습니다.

# cost-evolve candidates — 2026-07-03
10 candidate(s), ranked by est. savings.
| lever            | target   | action                              |
| model-deescalate | sod-ship | opus -> sonnet, apply only if PASS  |
| model-deescalate | eod-ship | opus -> sonnet, apply only if PASS  |
| mcp-prune        | codegraph| 미사용 MCP 서버 비활성화             |
| format-determinism | ...    | 포맷을 코드로 추출 후 강등 재시도    |

여기서 정직하게 짚을 부분이 있습니다. 이 시스템은 공격적으로 비용을 깎지 않습니다. 위의 sod-ship과 eod-ship은 하루 전에 막 상위 모델로 올라간 상태였고, 게이트는 “되돌리기엔 너무 이르다”며 강등을 보류했습니다. 시스템이 실제로 내린 것은 확신이 설 때뿐입니다. 대신 전체 스킬의 기본값은 이미 싼 티어입니다. 상위 모델에 고정된 것은 품질이 정말 중요한 소수(블로그 개선, 뉴스 만평, 고객 대면 문안)뿐이고, 나머지는 데이터가 요구할 때만 잠깐 올라갑니다.

정리하면 이렇습니다.

비싼 모델은 예외이고, 싼 모델이 기본입니다. 그리고 그 경계는 매일 밤 데이터로 다시 그어집니다.

로컬 GPU가 있다면, 싼 티어를 직접 굴려도 된다

여기까지가 상용 API 안에서 티어를 내리는 이야기라면, 로컬 GPU가 있는 팀에는 한 걸음 더 나갑니다. 싼 티어의 상당 부분을 오픈웨이트 소형 모델로 직접 돌릴 수 있기 때문입니다. 최근 소형·중형 오픈웨이트 모델의 도구 호출 능력이 실무에서 쓸 만한 수준으로 올라왔습니다.

구글의 Gemma 4는 Apache 2.0으로 열려 있고, E2B와 E4B 같은 소형 변형은 휴대폰이나 Jetson급 보드에서도 온디바이스로 돕니다. 라우팅과 분류, 간단한 도구 호출 워커로 쓰기 좋은 크기입니다. Zhipu의 GLM 5.2는 MIT 라이선스 오픈웨이트이면서 에이전트형 도구 사용을 앞세워 프론티어 폐쇄 모델에 근접한 성능을 보입니다. Moonshot의 Kimi K2.7-Code는 코딩과 다단계 도구 실행에 특화된 오픈웨이트 모델입니다. 업계에서는 이미 에이전트 트래픽의 60~80%를 이런 오픈웨이트로 흘리고, 정말 어려운 20% 남짓만 프론티어 API로 올려보내는 구성이 자리 잡고 있습니다.

우리가 하려는 말은 단순합니다. 팀 업무의 대부분은 고난도 창작이 아니므로, 그 부분은 로컬에서 도는 작은 모델로 충분합니다. 프론티어 모델은 남겨두되, 진짜 어려운 소수의 일에만 쓰면 됩니다.

도움이 필요하다면

GLM 5.2와 Kimi K2.7-Code 같은 최신 오픈웨이트 모델을 조합해 비용을 최적화하고 싶은 팀이라면 연락 주십시오. 어떤 업무를 어느 티어로 내리고, 무엇을 코드 게이트로 지킬지 함께 설계해 드립니다.

로컬 GPU를 일부라도 보유한 팀이라면 우리 메티스 추론 플랫폼을 활용하시길 권합니다. 보유한 장비에 맞춰 추론을 최적화해 제공하므로, 소형 오픈웨이트 모델을 여러분의 하드웨어에서 가장 효율적으로 돌릴 수 있습니다.

싼 모델이 기본이고 비싼 모델이 예외인 구조는 한 번 세팅으로 끝나지 않습니다. 매일 밤 측정하고, 안전할 때만 내리고, 흔들리면 되돌리는 루프가 있어야 유지됩니다. 팩시스는 그 루프를 시스템으로 제공합니다.

개요

로봇을 오래 굴려 본 사람은 익숙한 낭비를 봅니다. 로봇이 어떤 과제를 힘들게 성공시켜도, 그 과정에서 얻은 시행착오는 대부분 버려집니다. 다음 과제에서는 또 처음부터 더듬습니다. 실패를 딛고 만든 미세한 노하우, 이를테면 그리퍼가 미끄러졌을 때의 복구 방법이나 특정 물체를 다룰 때의 접근 각도 같은 것들이 시스템 어디에도 남지 않습니다. 사람이라면 한 번 배운 요령을 다음에 다시 쓰는데, 로봇은 그러지 못합니다.

NVIDIA GEAR 연구진이 2026년 6월 30일 공개한 ASPIRE(Agentic /Skills Discovery for Robotics, arXiv 2607.00272)는 정확히 이 지점을 겨냥합니다. ASPIRE의 발상은 단순하지만 강력합니다. 로봇에게 미리 정해진 정책을 주입하는 대신, 대형 언어 모델(LLM)이 로봇 제어 코드를 직접 작성하고, 그 코드를 실제 실행 환경에서 돌려 실패를 관찰하며, 반복적으로 수리한 뒤, 검증된 수리 경험을 재사용 가능한 스킬(Skill) 로 증류합니다. 경험이 버려지지 않고 복리처럼 쌓입니다.

이 글은 검증된 논문과 프로젝트 페이지를 근거로 ASPIRE의 구조와 실측 결과를 정리합니다. 그리고 이 흐름이 로봇공학만의 이야기가 아니라 소프트웨어 에이전트에도 그대로 적용된다는 점, 특히 ThakiCloud의 Agent-Native Cloud인 Paxis가 스킬을 일급 리소스로 다루는 방식과 어떻게 맞닿는지를 마지막에 짚습니다.

ASPIRE는 무엇인가

ASPIRE는 code-as-policy 패러다임 위에 지속 학습(continual learning) 루프를 얹은 시스템입니다. 전통적인 로봇 학습은 대량의 시연 데이터로 신경 정책을 훈련하고, 새 상황을 만나면 다시 데이터를 모아 재훈련하는 방식이 많았습니다. 여기에는 두 가지 부담이 따릅니다. 데이터 수집 비용이 크고, 한 번 학습한 지식이 새로운 변형 앞에서 쉽게 무너집니다.

ASPIRE는 정책을 신경망 가중치가 아니라 실행 가능한 코드로 표현합니다. LLM이 과제를 받아 제어 프로그램을 작성하면, 그 프로그램이 시뮬레이션 또는 실제 로봇에서 실행됩니다. 실행이 실패하면 ASPIRE는 실행 궤적을 기록하고, 실패 원인을 분석하며, 프로그램을 고쳐 다시 시도합니다. 이 반복이 성공에 도달하면, 그 과정에서 검증된 수리 지식이 스킬 라이브러리에 저장됩니다. 다음 과제는 빈손이 아니라 이 라이브러리를 참조해 시작합니다.

flowchart TB
    A[과제 지시] --> B[LLM이 제어 코드 작성<br/>code-as-policy]
    B --> C[실제 실행<br/>시뮬레이션 또는 로봇]
    C --> D{성공 여부}
    D -- 실패 --> E[궤적 기록·실패 원인 분석]
    E --> F[프로그램 수리]
    F --> C
    D -- 성공 --> G[검증된 수리 경험 증류]
    G --> H[재사용 가능한 스킬 라이브러리]
    H -.다음 과제가 참조.-> B

핵심은 마지막 화살표입니다. 스킬 라이브러리가 다음 과제 작성의 입력으로 되돌아가면서, 시스템은 시간이 지날수록 더 나은 코드를 더 빨리 씁니다. 논문은 이렇게 쌓인 지식이 그리퍼 복구 휴리스틱, 내비게이션 전략, 프롬프트 레시피, 절차적 수정 같은 형태로 과제를 넘나들며 전이(transfer) 된다고 설명합니다. 특정 과제 하나를 잘 푸는 것이 아니라, 푸는 능력 자체가 축적됩니다.

실패를 스킬로 증류하는 루프

ASPIRE를 다른 로봇 학습과 구분하는 지점은 실패를 다루는 방식입니다. 대부분의 파이프라인에서 실패는 폐기 대상이거나, 기껏해야 보상 신호를 깎는 음의 신호입니다. ASPIRE는 실패를 학습 재료로 봅니다. 실패한 실행의 궤적에는 “무엇이 왜 어긋났는가”라는 정보가 들어 있고, LLM은 이 정보를 읽어 코드를 어디서 어떻게 고쳐야 하는지 추론합니다.

이 수리가 한 번의 임기응변으로 끝나면 의미가 제한적입니다. ASPIRE의 기여는 검증된 수리를 일반화 가능한 스킬로 증류하는 데 있습니다. 예를 들어 특정 물체를 집다가 미끄러진 실패를 고쳐 성공했다면, 그 복구 절차는 그 물체에만 묶이지 않고 유사한 파지 상황에 재적용될 수 있는 형태로 추상화됩니다. 스킬은 텍스트로 표현된 코드 조각이므로 사람이 읽고 감사할 수 있고, 라이브러리로 관리하며 버전을 매길 수 있습니다. 이는 블랙박스 신경 정책과 대비되는 큰 장점입니다.

이 구조 덕분에 ASPIRE는 추가 학습 데이터 없이 성능을 끌어올립니다. 새 시연을 수집해 모델을 재훈련하는 대신, 실행-실패-수리-증류 루프를 반복하는 것만으로 성공률이 오릅니다. 데이터 수집이 병목인 로봇공학에서 이는 실무적으로 중요한 성질입니다.

실제 실험 결과

논문과 프로젝트 페이지가 보고한 수치는 이 루프가 단순한 개념 이상임을 보여 줍니다. 가장 인상적인 결과는 Robosuite의 양팔 물체 핸드오버(bimanual object handover) 과제입니다. 기본 성공률 20%에서 시작해, 반복적 디버깅만으로 92%까지 올랐습니다. 추가 시연 데이터를 전혀 넣지 않고, 실행-수리 루프만으로 도달한 수치입니다.

과제 유형을 넓혀도 이점이 유지됩니다. 논문은 ASPIRE가 선행 방법 대비 다음과 같은 향상을 보였다고 보고합니다. 교란(perturbation)이 가해진 조작 과제인 LIBERO-Pro에서 최대 77%, Robosuite 양팔 핸드오버에서 72%, 장기 지평(long-horizon) 가사 과제인 BEHAVIOR-1K에서 최대 32%의 성능 우위입니다. 특히 장기 과제 일반화 실험에서는 스킬 라이브러리가 커질수록 성공률이 꾸준히 올랐다고 합니다. 라이브러리의 성장과 성능의 상승이 함께 간다는 점은, 경험이 실제로 복리로 쌓인다는 이 시스템의 핵심 주장을 뒷받침합니다.

연구진은 NVIDIA GEAR 연구실을 중심으로 미시간대(UMich), 일리노이대(UIUC), UC 버클리, 카네기멜런대(CMU) 소속 연구자들로 구성됩니다. NVIDIA는 릴리스 시점에 ASPIRE의 스킬 라이브러리를 오픈소스로 공개한다고 밝혔으며, 상세는 프로젝트 페이지(research.nvidia.com/labs/gear/aspire)에서 확인할 수 있습니다. 다만 코드 저장소의 구체적 라이선스는 공개 시점 기준으로 명시가 확인되지 않아, 도입 전에는 실제 저장소의 라이선스 조항을 직접 확인하는 편이 안전합니다.

ThakiCloud 제품 적용 시사점

ASPIRE의 대상은 로봇 팔이지만, 그 아키텍처가 던지는 메시지는 소프트웨어 에이전트에 그대로 옮겨집니다. “에이전트가 코드를 쓰고, 실패에서 배우며, 검증된 경험을 재사용 가능한 스킬로 증류해 라이브러리에 쌓는다”는 문장에서 ‘로봇’을 ‘클라우드 에이전트’로 바꾸면, 그것이 바로 ThakiCloud의 Agent-Native Cloud인 Paxis가 지향하는 구조입니다.

Paxis는 Skills·Tools·Policies·Audit Logs를 일급 리소스로 다룹니다. ASPIRE의 스킬 라이브러리가 Paxis에서는 BM25로 선택되는 960여 개의 스킬 하니스에 해당하고, ASPIRE의 code-as-policy 실행은 Paxis의 격리 샌드박스 실행에 대응합니다. ASPIRE가 실패 궤적을 기록하고 분석하듯, Paxis는 모든 에이전트 행동을 정책 게이트와 감사 로그로 통과시켜 무엇이 왜 실패했는지 소급 추적할 수 있게 합니다. 그리고 ASPIRE의 증류 루프가 지향하는 자기 개선은 Paxis의 자가진화 스킬로 구현됩니다. 실행에서 얻은 교훈이 새 스킬이나 스킬 개정으로 되돌아가, 다음 실행이 빈손에서 시작하지 않게 만드는 흐름입니다.

인프라 관점에서는 ThakiCloud의 ai-platform이 이 루프의 토대를 제공합니다. ASPIRE류의 반복 실행-수리 루프는 시뮬레이션과 추론을 대량으로 돌려야 하므로 GPU 자원의 탄력적 스케줄링이 전제됩니다. ai-platform은 Kueue 기반 GPU 스케줄링과 멀티테넌트 격리 위에서 이런 반복 워크로드를 비용 효율적으로 수용하도록 설계되어 있습니다. 저비용 서빙이 에이전트의 실행-수리 반복을 경제적으로 만들고, 그렇게 쌓인 스킬이 다시 에이전트의 자율성을 높이는 선순환입니다. 온프레미스와 소버린 환경을 요구하는 고객에게는 이 전체 루프를 자체 인프라 안에서 돌릴 수 있다는 점이 특히 의미가 있습니다.

한계 및 반론

ASPIRE의 결과가 인상적이더라도 몇 가지 유보가 필요합니다. 첫째, 보고된 수치는 대부분 시뮬레이션 벤치마크(Robosuite, LIBERO-Pro, BEHAVIOR-1K)에서 나온 것입니다. 시뮬레이션에서의 반복 디버깅은 값싸고 안전하지만, 실제 하드웨어에서는 매 시도가 시간과 마모, 안전 리스크를 수반합니다. 실행-실패-수리 루프의 경제성이 실물 로봇에서도 유지되는지는 별도의 검증이 필요합니다.

둘째, code-as-policy는 LLM이 유효한 제어 코드를 쓸 수 있는 과제에서 강하지만, 정밀한 연속 제어나 고빈도 피드백이 필요한 동작에서는 코드로 표현하기 어려운 영역이 남습니다. ASPIRE는 이런 저수준 제어를 기존 스킬이나 프리미티브에 위임하는 것으로 보이며, 그 프리미티브의 품질이 전체 성능의 상한을 정할 수 있습니다.

셋째, 스킬 라이브러리가 커질수록 검색과 선택의 부담이 늘어납니다. 라이브러리 성장이 성능 상승과 함께 간다는 결과는 고무적이지만, 규모가 더 커졌을 때 잘못된 스킬을 고르거나 오래된 스킬이 오답을 유발하는 문제가 없는지는 지속적으로 지켜봐야 합니다. 이는 Paxis의 스킬 하니스가 이미 마주한 과제이기도 하며, BM25 선택과 정책 게이트, 감사 로그가 바로 이 위험을 관리하기 위한 장치입니다.

그럼에도 ASPIRE가 제시한 방향, 즉 실패를 버리지 않고 검증된 스킬로 복리처럼 쌓는다는 원칙은 로봇과 소프트웨어 에이전트 양쪽에서 앞으로 표준이 될 가능성이 큽니다. 능력을 데이터가 아니라 축적된 스킬로 키운다는 관점의 전환이 이 연구의 진짜 기여입니다.

출처

• ASPIRE: Agentic /Skills Discovery for Robotics, arXiv 2607.00272: https://arxiv.org/abs/2607.00272
• 프로젝트 페이지 (NVIDIA GEAR): https://research.nvidia.com/labs/gear/aspire/
• 논문 페이지 (Hugging Face): https://huggingface.co/papers/2607.00272

개요

코딩 에이전트가 몇 시간짜리 작업을 끝냈을 때, 정작 그 결과를 남에게 보여주는 일은 여전히 번거롭습니다. 터미널 로그를 캡처해 붙이거나, 변경 사항을 손으로 요약하거나, 별도로 대시보드를 만들어야 했습니다. 작업 자체보다 작업을 설명하는 데 시간이 더 드는 경우도 적지 않았습니다.

2026년 7월, Anthropic은 Claude Code의 아티팩트(Artifacts) 기능을 Pro와 Max 요금제까지 확대했습니다. 그동안 Team과 Enterprise에서만 쓸 수 있던 기능이 개인 개발자에게도 열린 것입니다. 핵심은 단순합니다. 아티팩트를 요청하면 Claude가 코드를 작성해 claude.ai에 라이브로 게시하고, 세션이 계속 돌아가는 동안 그 페이지를 실시간으로 갱신합니다. 페이지는 계정에 비공개로 귀속되며 완전히 자기완결적(self-contained)입니다.

이 글에서는 Claude Code 아티팩트가 정확히 무엇인지, Pro·Max 확대가 왜 의미가 있는지, 그리고 ThakiCloud가 운용하는 에이전트 플랫폼 Paxis와 AI 인프라 ai-platform의 관점에서 이 패턴을 어떻게 흡수할 수 있는지 살펴봅니다.

작업 자체보다 “지금 무슨 일이 벌어지고 있는지”를 설명하는 데 더 많은 에너지가 소모되던 문제.

Claude Code 아티팩트란 무엇인가

아티팩트는 원래 claude.ai 대화 안에서 코드나 문서를 별도 패널로 렌더링하는 기능이었습니다. 이번에 Claude Code로 들어온 아티팩트는 성격이 조금 다릅니다. 대화 한 번의 산출물이 아니라, 코딩 세션 전체의 진행 상황을 하나의 살아있는 시각 페이지로 만듭니다.

대화 한 번의 산출물이 아니라 세션 전체의 진행 상황을 실시간으로 렌더링하는 살아있는 페이지입니다.

Anthropic이 예시로 든 용도는 네 가지입니다. 풀 리퀘스트 설명(PR walkthrough), 시스템 동작을 설명하는 페이지(system explainer), 대시보드, 그리고 릴리스 체크리스트입니다. 공통점은 모두 “지금 무슨 일이 벌어지고 있는지”를 사람이 읽을 수 있게 정리한 산출물이라는 점입니다. 그리고 세션이 작업을 이어가는 동안 이 페이지가 스스로 갱신됩니다.

작업에서 게시까지의 흐름은 다음과 같습니다.

flowchart TB
    A[개발자: 아티팩트 요청] --> B[Claude Code가 코드 작성]
    B --> C[claude.ai에 라이브 게시]
    C --> D{세션 계속 진행}
    D -->|작업 상태 변화| E[페이지 실시간 갱신]
    E --> D
    D -->|완료| F[자기완결 페이지 확정]
    F --> G[게시 링크 공유]
    G --> H[수신자: 계정 없이 열람]
    G --> I[계정 보유자: 리믹스로 사본 편집]

여기서 두 가지 설계 결정이 눈에 띕니다. 첫째, 페이지가 자기완결적입니다. 외부 빌드 파이프라인이나 호스팅 설정 없이, 게시된 페이지 하나에 필요한 것이 다 들어갑니다. 둘째, 기본값이 비공개입니다. 페이지는 계정에 귀속되고, 게시 버튼을 눌러 링크를 공유하기 전까지는 남이 볼 수 없습니다.

자기완결성(외부 호스팅 불필요)과 기본 비공개(게시 전까지 계정에 귀속)라는 두 축.

Pro·Max 확대가 의미하는 것

기능 자체는 몇 달 전부터 Team과 Enterprise에서 쓸 수 있었습니다. 이번 변화의 핵심은 요금제 경계가 내려왔다는 것입니다.

정확히 구분하면 이렇습니다. claude.ai 대화에서 만드는 일반 아티팩트는 이전부터 Free·Pro·Max를 포함한 모든 요금제에서 게시할 수 있었습니다. 반면 Claude Code 세션을 라이브 페이지로 바꾸는 아티팩트는 Team·Enterprise 전용이었습니다. 이번에 그 경계가 Pro와 Max까지 확대됐습니다. 조직 단위 좌석 없이도 개인 개발자가 자기 세션을 공유 가능한 페이지로 만들 수 있게 된 것입니다.

일반 대화형 아티팩트 게시는 이전부터 전 요금제 가능. 이번 변화는 Code 세션 라이브 페이지가 Pro·Max로 내려온 것입니다.

이것이 왜 중요한지는 개인 개발자의 실제 작업 패턴을 보면 드러납니다. 오픈소스 기여자가 긴 리팩터링을 끝냈을 때, 리뷰어에게 변경의 맥락을 전달할 방법이 필요합니다. 사이드 프로젝트를 돌리는 1인 개발자가 진행 상황을 스스로 추적하거나 동료에게 데모를 보여줄 때도 마찬가지입니다. 지금까지 이런 사용자는 조직 요금제에 묶이지 않으면 이 기능을 쓸 수 없었습니다. Pro·Max 확대는 이 격차를 메웁니다.

한 가지 덧붙이면, Anthropic은 같은 기간 Pro·Max·Team의 Claude Code 주간 사용 한도를 한시적으로 상향하기도 했습니다. 기능 접근성과 사용량 여유가 함께 열린 셈이라, 개인 개발자가 실제로 이 기능을 시험해 볼 여지가 커졌습니다.

실제 사용 흐름

사용 방법은 대화에 가깝습니다. 세션 중에 “이 작업을 아티팩트로 만들어 줘”라고 요청하면, Claude Code가 현재 진행 상황을 담은 페이지를 생성해 claude.ai에 게시합니다. 반환된 링크를 열면 지금까지의 작업이 정리된 시각 페이지가 보이고, 세션이 계속 돌아가면 이 페이지가 새로고침 없이 갱신됩니다.

공유는 아티팩트 패널 하단의 게시 버튼을 통해 이뤄집니다. 링크를 받은 사람은 Claude 계정이 없어도 페이지를 열람할 수 있습니다. 계정이 있는 사람은 리믹스(remix) 기능으로 자기만의 편집 가능한 사본을 만들 수 있습니다. 즉 하나의 아티팩트가 읽기 전용 공유물이자 다른 사람이 이어받아 발전시킬 수 있는 출발점이 됩니다.

요청(Prompt) → 실시간 갱신(Live Update) → 링크 게시(Publish) → 리믹스(Remix)로 이어지는 흐름.

프라이버시 모델도 명확합니다. Claude Code에서 만든 페이지는 기본적으로 계정에 비공개입니다. 게시해 링크를 넘기는 순간에만 외부에 노출되며, 그전까지는 본인만 볼 수 있습니다. 민감한 내부 작업을 다루는 개발자에게는 이 기본값이 중요합니다. 실수로 공개되는 경로가 없기 때문입니다.

이 흐름에서 특히 실용적인 조합은 PR 설명입니다. 긴 변경을 마친 뒤 아티팩트를 요청하면, 무엇을 왜 바꿨는지, 어떤 파일이 영향을 받는지, 어떻게 검증했는지를 담은 페이지가 나옵니다. 리뷰어는 diff를 읽기 전에 이 페이지로 맥락을 먼저 잡을 수 있습니다. 인시던트 대응 페이지나 릴리스 체크리스트도 같은 방식으로, 사람이 읽을 요약을 에이전트가 스스로 유지하게 만드는 용도입니다.

ThakiCloud 제품 적용 시사점

이 기능의 진짜 함의는 단일 도구의 편의를 넘어섭니다. “에이전트의 작업 산출물을 사람이 읽을 수 있는 공유 가능한 아티팩트로, 그것도 실시간으로 유지한다”는 패턴 자체가 에이전트 플랫폼의 핵심 과제이기 때문입니다.

Paxis 관점 (에이전트 산출물의 일급 자원화). ThakiCloud의 Paxis는 ai-platform 위에서 도는 Agent-Native Cloud 제어 평면으로, Skills·Tools·Policies·Audit Logs를 일급 리소스로 다룹니다. Claude Code 아티팩트가 보여주는 것은 에이전트의 중간·최종 산출물을 별도 관측 채널로 노출하는 방식입니다. Paxis에서 DAG 멀티에이전트가 긴 작업을 수행할 때, 각 노드의 진행 상황을 사람이 읽을 수 있는 라이브 페이지로 응축하면 운영자는 로그를 스크롤하지 않고도 흐름을 파악할 수 있습니다. 여기에 Paxis의 정책 게이트와 감사 로그를 결합하면, 아티팩트가 “누가 무엇을 언제 만들고 공유했는가”까지 추적되는 통제된 산출물이 됩니다. Anthropic의 기본 아티팩트가 계정 비공개인 것과 같은 맥락에서, Paxis는 산출물 공유에 정책 기반 접근 제어를 얹어 조직 단위로 확장할 수 있습니다.

Paxis는 에이전트 산출물을 정책 게이트와 감사 로그 아래 두어 통제된 공유 아티팩트로 격상합니다.

ai-platform 관점 (내부 운영 페이지). 인프라 측면에서는 자기완결 페이지가 내부 대시보드와 인시던트 페이지에 잘 맞습니다. ThakiCloud의 ai-platform은 K8s·Kueue GPU 스케줄링·vLLM 멀티테넌트 서빙을 운용하며, 이 위에서 도는 배치·서빙 작업은 상태를 사람에게 전달할 채널이 필요합니다. 에이전트가 릴리스 체크리스트나 배포 진행 페이지를 스스로 유지하게 만들면, 온프렘·소버린 환경에서 별도 관측 스택을 늘리지 않고도 운영 가시성을 확보할 수 있습니다. 자기완결이라는 성질은 외부 호스팅 의존을 줄이므로, 폐쇄망 요구가 강한 고객 환경에서도 부담이 적습니다.

자기완결 페이지는 외부 호스팅 의존을 줄여, 온프렘·소버린 환경의 운영 가시성 확보에 유리합니다.

두 관점은 서로를 보완합니다. ai-platform이 낮은 비용으로 에이전트 워크로드를 실행하고, Paxis가 그 산출물을 정책과 감사 아래 공유 가능한 아티팩트로 다룬다면, “에이전트가 일하고 그 결과가 곧바로 사람이 읽을 산출물이 되는” 경험을 자체 플랫폼 위에서 재현할 수 있습니다.

한계 및 반론

기대를 조정할 지점도 분명합니다.

호스팅 종속·프런트엔드 한계·지속성 부재라는 제약과, 그것을 메우는 온프렘·상태 지속성·통제 접근.

첫째, 이 기능은 claude.ai 게시에 묶여 있습니다. 페이지가 Anthropic 인프라에 호스팅되므로, 완전한 폐쇄망이나 데이터 반출이 금지된 환경에서는 그대로 쓰기 어렵습니다. 소버린 요구가 강한 고객에게는 자체 호스팅 대안이 필요하며, 이것이 오히려 ThakiCloud 같은 온프렘 지향 플랫폼이 채울 수 있는 공백입니다.

둘째, 자기완결 페이지는 단순 요약과 대시보드에는 훌륭하지만, 복잡한 상호작용이나 대용량 데이터 연동에는 한계가 있습니다. 게시된 아티팩트는 본질적으로 가벼운 프런트엔드이며, 무거운 백엔드 로직을 대체하지 않습니다.

셋째, 실시간 갱신은 세션이 살아 있는 동안에만 유효합니다. 세션이 끝나면 페이지는 그 시점의 스냅샷으로 고정됩니다. 지속적으로 갱신되는 운영 대시보드가 필요하다면 별도 파이프라인이 여전히 필요합니다.

정리하면, Claude Code 아티팩트의 Pro·Max 확대는 개인 개발자가 에이전트 작업을 공유 가능한 산출물로 바꾸는 문턱을 크게 낮춘 변화입니다. 다만 호스팅과 지속성의 제약은 남아 있으며, 바로 그 지점에서 정책·감사·온프렘을 갖춘 에이전트 플랫폼이 보완적 가치를 가집니다. 도구의 편의를 흡수하되, 통제와 주권이 필요한 영역은 자체 플랫폼으로 메우는 것이 현실적인 접근입니다.

출처

• ClaudeDevs (@ClaudeDevs) 발표 게시물
• Publish and share artifacts (Claude Help Center)
• What are artifacts and how do I use them? (Claude Help Center)