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

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

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

جودة المهام الروتينية في الحقيقة لا يحددها ذكاء النموذج بقدر ما تحددها حواجز الحماية. سبب تذبذب تنسيق المخرجات ليس غباء النموذج، بل أن التنسيق طُلب منه بأسلوب نثري، أي أنه “تُرجّي” لا فُرض. حين يفرض الكود سقف الطول، والقيم المسموح بها (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 يقدّم هذه الحلقة كنظام متكامل.

بروتوكول Model Context Protocol (MCP) هو واجهة قياسية أطلقتها Anthropic في نوفمبر 2024. يوفّر طريقة موحّدة لربط نماذج اللغة الكبيرة بالأدوات ومصادر البيانات والخدمات الخارجية. وخلال أشهر ظهرت مئات خوادم MCP التي بنتها المجتمعات على GitHub. ومع ذلك لم يوجد أدب في صيانة البرمجيات يصف كيف تُبنى هذه الخوادم فعليًّا في الإنتاج.

تسدّ هذه الفجوة ورقة MCP Server Architecture Patterns for LLM-Integrated Applications لـ Carson Rodrigues وزملائه، المنشورة على arXiv في 29 يونيو 2026. باستخدام مجموعة من 15 خادم MCP طُوِّرت بشكل مستقل، تصنّف الورقة خمسة أنماط معمارية متكرّرة وأربعة أنماط مضادّة، إلى جانب اهتمامات شاملة تتعلّق بالمصادقة وإدارة الإصدارات وقابلية الرصد.

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

ما هي الدراسة

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

flowchart TB
    LLM["وكيل LLM"] --> Client["عميل MCP"]
    Client --> Server["خادم MCP"]
    Server --> P1["Resource Gateway<br/>يعرض مصادر البيانات"]
    Server --> P2["Tool Orchestrator<br/>ينسّق تنفيذ الأدوات"]
    Server --> P3["Stateful Session Server<br/>يحفظ حالة الجلسة"]
    Server --> P4["Proxy Aggregator<br/>يوحّد خلفيات متعدّدة"]
    Server --> P5["Domain-Specific Adapter<br/>تغليف واعٍ بالمجال"]
    P1 -.اهتمامات شاملة.-> X["المصادقة · الإصدارات · قابلية الرصد"]
    P2 -.اهتمامات شاملة.-> X
    P3 -.اهتمامات شاملة.-> X

قيمة هذا التصنيف أنّه يجبرك على تحديد “أيّ نوع من الخوادم هذا” قبل البناء. فإذا حشرت منطق التنفيذ المعقّد لنمط Tool Orchestrator داخل Resource Gateway، جمعت عيوب النمطين معًا. اختيار النمط صراحةً هو بحدّ ذاته انضباط تصميمي.

الأنماط المعمارية الخمسة

Resource Gateway يعرض مصادر البيانات مثل قواعد البيانات وأنظمة الملفّات وواجهات API بأسلوب يركّز على القراءة. الأدوات نفسها بسيطة، والسؤال الحقيقي هو أيّ الموارد تفتحها وبأيّ صلاحيات.

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

Stateful Session Server يحفظ الحالة عبر محادثة أو جلسة عمل. استدعاءات LLM بلا حالة في جوهرها، فيحمل الخادم الحالة نيابةً عن النموذج وعليه أن يحدّد عمر الجلسة وسياسة التنظيف بوضوح.

Proxy Aggregator يدمج عدّة خلفيات أو خوادم MCP أخرى خلف واجهة واحدة. مريح، لكن مع تكاثر الأدوات خلفه يقود سريعًا إلى مشكلة إرباك الأدوات التي نناقشها أدناه.

Domain-Specific Adapter يغلّف مفاهيم مجال محدّد (المال، الرعاية الصحّية، الأنظمة الداخلية) في شكل يتعامل معه LLM جيّدًا. فيدمج مصطلحات المجال وقيوده في مخطّط الأداة كي لا يحاول النموذج تركيبات غير منطقية.

إرباك الأدوات: لماذا يتعثّر النموذج مع تعدّد الأدوات

أهمّ جزء عمليًّا في الورقة يقيس العلاقة بين عدد الأدوات ودقّة اختيار الأداة. النتيجة واضحة: بمجرّد تجاوز عدد الأدوات في السياق حدًّا معيّنًا، تنخفض دقّة النموذج في اختيار الأداة الصحيحة إلى ما دون 90%.

على وجه التحديد، تفيد الورقة بأنّ دقّة Claude Haiku 4.5 تنخفض دون 90% بين 10 و15 أداة، وبالنسبة لـ Sonnet 4 بين 20 و30 أداة. تتحمّل النماذج الأكبر عددًا أكبر من الأدوات، لكن لا توجد نقطة يصحّ عندها “أرفق ما شئت”. فمع تكاثر الأدوات وغموض أوصافها، يرتبك النموذج.

يقلب هذا القياس حدسًا شائعًا. إذ كثيرًا ما يبدأ من يضيف MCP لأوّل مرّة بـ”عرض كلّ واجهة API نملكها كأداة”. وبدمج عدّة خلفيات عبر Proxy Aggregator يصل عدد الأدوات بسرعة إلى العشرات، فتسقط من على حافّة الدقّة. عدد الأدوات ليس مجّانيًّا، بل يستهلك ميزانية حكم النموذج.

الأنماط المضادّة والاهتمامات الشاملة

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

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

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

يتطابق استنتاج الورقة حول إرباك الأدوات تمامًا مع سبب بناء ThakiCloud لـ Paxis. فـ Paxis هو مستوى تحكّم Agent-Native Cloud يعمل فوق ai-platform، ويتعامل مع المهارات (Skills) والأدوات (Tools) والسياسات (Policies) وسجلّات التدقيق (Audit Logs) كموارد من الدرجة الأولى. والعنصر الجوهري هو Skill Harness.

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

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

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

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

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

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

المصادر

• Carson Rodrigues et al., MCP Server Architecture Patterns for LLM-Integrated Applications, arXiv:2606.30317 (2026-06-29)
• مقدّمة Model Context Protocol الرسمية

نظرة عامة

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

عالج فريق 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.

The Model Context Protocol (MCP) is a standard interface Anthropic released in November 2024. It provides a common way to connect large language models to external tools, data sources, and services. Within months, hundreds of community-built MCP servers appeared on GitHub. Yet no software-maintenance literature had described how those servers were actually being structured in production.

The paper MCP Server Architecture Patterns for LLM-Integrated Applications by Carson Rodrigues et al., posted to arXiv on June 29, 2026, fills that gap. Using a corpus of 15 independently developed MCP servers, it catalogs five recurring architecture patterns and four anti-patterns, along with cross-cutting concerns around authentication, versioning, and observability.

For anyone running agent infrastructure, one part stands out. The paper actually measured how many tools you can attach, and the answer is much lower than most teams assume. Because this maps directly onto how ThakiCloud handles more than 960 skills in Paxis, our Agent-Native Cloud, this post walks through the measured results alongside our own design choices.

What the Study Is

The approach is empirical. Instead of prescribing what servers should look like, the authors dissected 15 running servers and inductively extracted their shared structure. The five resulting patterns split along two axes: what the server exposes to the LLM, and how it handles state.

flowchart TB
    LLM["LLM agent"] --> Client["MCP client"]
    Client --> Server["MCP server"]
    Server --> P1["Resource Gateway<br/>exposes data sources"]
    Server --> P2["Tool Orchestrator<br/>coordinates tool execution"]
    Server --> P3["Stateful Session Server<br/>holds session state"]
    Server --> P4["Proxy Aggregator<br/>unifies many backends"]
    Server --> P5["Domain-Specific Adapter<br/>domain-aware wrapping"]
    P1 -.cross-cutting.-> X["auth · versioning · observability"]
    P2 -.cross-cutting.-> X
    P3 -.cross-cutting.-> X

The value of this taxonomy is that it forces you to decide “what kind of server is this” before you build. Cram a Tool Orchestrator’s complex execution logic into a Resource Gateway and you combine the downsides of both. Choosing a pattern explicitly is itself a design discipline.

The Five Architecture Patterns

Resource Gateway exposes data sources such as databases, file systems, or APIs in a read-centric way. The tools themselves are simple; the real question is which resources you open, and under what permissions.

Tool Orchestrator bundles several tools and coordinates an execution flow. A single call often runs multiple internal steps, so failure handling and partial rollback are the core difficulty.

Stateful Session Server maintains state across a conversation or work session. LLM calls are essentially stateless, so the server holds the state on the model’s behalf and must define session lifetime and cleanup clearly.

Proxy Aggregator merges several backends or other MCP servers behind a single surface. Convenient, but as the tools behind it multiply, it soon leads to the tool-overload problem discussed below.

Domain-Specific Adapter wraps concepts of a specific domain (finance, healthcare, internal systems) into a shape the LLM handles well. It bakes domain terms and constraints into the tool schema so the model does not attempt nonsensical combinations.

Tool Overload: Why More Tools Make Models Wobble

The most operationally important part of the paper measures the relationship between tool count and tool-selection accuracy. The result is clear: once the number of tools in context passes a threshold, the model’s accuracy at picking the right tool drops below 90%.

Specifically, the paper reports that for Claude Haiku 4.5 accuracy falls below 90% somewhere between 10 and 15 tools, and for Sonnet 4 between 20 and 30 tools. Larger models tolerate more tools, but there is no point at which “attach as many as you like” holds. As tools multiply and descriptions grow vague, the model gets confused.

This measurement overturns a common instinct. Teams adding MCP for the first time often start by “exposing every API we have as a tool.” Merge several backends with a Proxy Aggregator and the tool count reaches dozens fast, dropping you off the accuracy cliff. Tool count is not free; it spends the model’s judgment budget.

Anti-Patterns and Cross-Cutting Concerns

The paper also catalogs four anti-patterns. The exact names are not confirmed at the abstract level, but the direction connects to the measurement above. Growing tools indiscriminately, leaving tool descriptions vague so the model has to infer intent, letting sessions drift without state management, and handling authentication and versioning inconsistently per server are the typical failure modes.

For cross-cutting concerns, it emphasizes authentication, versioning, and observability. All three are needed regardless of which pattern you choose. Observability in particular often gets pushed to the back in agent systems, yet when a tool call fails and you cannot trace why, debugging becomes practically impossible.

Implications for ThakiCloud Products

The paper’s tool-overload conclusion overlaps precisely with why ThakiCloud built Paxis. Paxis is an Agent-Native Cloud control plane running on top of ai-platform, treating Skills, Tools, Policies, and Audit Logs as first-class resources. The key piece is the Skill Harness.

Paxis holds more than 960 skills, but it never dumps all of them into the model’s context as tools. Instead, for each user request it selects only a small set of relevant skills via BM25 search and exposes those. Mapped onto the paper’s measurement, this is a design that sidesteps the accuracy cliff. The model always faces a manageable handful of tools, while the remaining hundreds of capabilities are pulled in on demand. “Many capabilities, few exposed” is our answer to the tool-overload problem.

We manage the Proxy Aggregator risk through the same lens. Paxis MCP connectors link many external services, but rather than exposing every connected tool, a policy gate filters them so only what is actually needed reaches the isolated sandbox execution path. Every tool call leaves an audit log, satisfying the observability requirement. The authentication, versioning, and observability the paper flags as cross-cutting concerns are wired in by default in Paxis, not optional.

The infrastructure layer, ai-platform, is worth noting too. As MCP servers multiply, each one eventually runs as a process somewhere. ai-platform serves these servers reliably on K8s and Kueue-based GPU scheduling with multi-tenant isolation, extending to on-prem and sovereign environments. For state-holding servers like a Stateful Session Server, placement and lifecycle management matter, and K8s operational maturity becomes a direct advantage.

Limitations and Counterpoints

The paper rests on a relatively small corpus of 15 servers. The MCP ecosystem is growing so fast that whether these five patterns remain representative is something to watch. New patterns may emerge, or today’s anti-patterns may be eased by better tooling.

The tool-selection accuracy measurement also depends on model and prompt design. Well-written tool descriptions and clear naming raise accuracy at the same tool count. In other words, there is no absolute line of “N tools is safe”; tool count is one variable among several. Even so, the direction is unambiguous. Tools are not free, and the discipline of exposing only what is needed is the foundation of agent reliability.

Sources

• Carson Rodrigues et al., MCP Server Architecture Patterns for LLM-Integrated Applications, arXiv:2606.30317 (2026-06-29)
• Model Context Protocol official introduction

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

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