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

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

ما هذا النهج

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

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

flowchart TB
    A[طلب مهمة الوكيل] --> B{تصنيف نوع المهمة}
    B -->|استدلال واتخاذ قرار عالي المستوى| C[نماذج الحدود المميزة]
    B -->|توليد الشيفرة| D[نماذج مفتوحة الأوزان - فئة البرمجة]
    B -->|استدعاء أدوات وخطوط أنابيب| E[نماذج مفتوحة الأوزان - فئة الوكلاء<br/>Gemma 4]
    B -->|استخراج وتصنيف ضخم| F[نماذج مفتوحة الأوزان - الفئة الاقتصادية]
    C --> G[بوابة السياسة + سجل التدقيق]
    D --> G
    E --> G
    F --> G
    G --> H[إرجاع النتيجة + تسجيل التكلفة]

التثبيت والتكامل

بدأنا بالتحقق من قدرة النماذج مفتوحة الأوزان على أداء المهمة الجوهرية للوكيل، وهي تحويل الطلبات اللغوية الطبيعية إلى استدعاءات أدوات منظمة. كان الهدف التحقق من Gemma 4 بحجم 26 مليار معامل عبر واجهة برمجة تطبيقات مُدارة. صُممت التجربة باستخدام المكتبات القياسية فقط (urllib) دون أي تبعيات إضافية.

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

TOOL_SPEC = """You are an operations automation agent. Convert the user request into a single tool-call JSON.
Output only the JSON object, with no explanation or markdown fences.

Available tools and required parameters:
- query_metrics: {metric, window_days, threshold?, region?}
- restart_pods: {region, selector, only_failed(bool)}
- aggregate_cost: {group_by, month, service?}
- scale_deployment: {name, region, replicas}
- rotate_secret: {name, namespace}

Output schema: {"tool": "<name>", "params": { ... }}"""

def call(prompt):
    body = {
        "contents": [{"role": "user",
                      "parts": [{"text": TOOL_SPEC + "\n\nRequest: " + prompt}]}],
        "generationConfig": {"temperature": 0.0, "maxOutputTokens": 1024},
    }
    # call gemma-4-26b-a4b-it via generateContent, capture latency, tokens, and output

اصطدمنا هنا بمشكلة عملية تستحق التنبيه. ينتج Gemma 4 رموزاً مميزة للتفكير قبل الإجابة النهائية، وحين يُحدد سقف الإخراج بـ 256 رمزاً تنقطع مرحلة التفكير وتأتي النتيجة الأخيرة فارغة. بمجرد رفع السقف إلى 1024 وتصفية الأجزاء التي تحمل علامة thought واستخراج الإجابة الفعلية فقط، عمل النموذج بصورة صحيحة. هذا خطأ شائع يغفل عنه كثيرون عند دمج النماذج مفتوحة الأوزان في خطوط الأنابيب، ولهذا آثرنا توثيقه بكود قياسي فعلي.

أما جانب المنصة فتتولاه كتالوج نماذج Paxis. تتيح Paxis إدارة النموذج المستخدم من أي مزود في ملف تعريفي واحد (models.yaml) يتضمن سعر الإدخال والإخراج لكل رمز مميز إلى جانب الدرجة، وهو الأساس الذي يقوم عليه التوجيه.

# models.yaml: tier and actual cost per token are the basis for routing (USD / 1M tokens)
- id: claude-opus-4-8      # premium
  tier: premium
  costInput: 5.0
  costOutput: 25.0
- id: claude-sonnet-5      # standard (default)
  tier: standard
  costInput: 3.0
  costOutput: 15.0
# Add open-weight providers (Ollama, vLLM, etc.) with the same schema
# and CostRouter will automatically route tasks to the matching tier.

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

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

قدمنا ستة طلبات تشغيل حقيقية إلى Gemma 4 وقيّمنا النتائج مباشرة بمعيارين: هل الإخراج JSON صالح، وهل يتضمن الأداة الصحيحة مع المعاملات الإلزامية كاملة؟

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

{"tool": "query_metrics", "params": {"metric": "gpu_utilization", "window_days": 7, "threshold": 80}}

كان threshold معاملاً اختيارياً في المخطط، لكن النموذج استخلص قيمة “80%” من الطلب ووضعها في موضعها الصحيح. وللطلب “زد نسخ نشر inference-api في منطقة ap-northeast إلى 6”، ربط scale_deployment بالاسم والمنطقة وعدد النسخ بدقة تامة. هذا قياس نظيف يثبت أن نماذج مفتوحة الأوزان قادرة فعلاً على أداء المهمة الجوهرية لأتمتة الوكلاء، وهي استدعاء الأدوات وتنفيذ خطوط الأنابيب.

متوسط 15.3 ثانية قُيس على نقطة نهاية مشتركة مجانية تشمل رموز التفكير. في بيئة خدمة ذاتية أو معالجة دفعية، ينخفض هذا الرقم بشكل ملحوظ. المهم هنا ليس الكمون المطلق بل الحقيقة الأساسية: الجودة لم تتراجع.

الآن نصل إلى التكلفة. انطلاقاً من ملف تعريف الرموز المميزة المقاسة، افترضنا أن كل مهمة تستهلك 1000 رمز إدخال و300 رمز إخراج وهو سيناريو واقعي لجولة واحدة تشمل موجه النظام ومخطط الأدوات والسياق، مع أسطول وكلاء يعالج 10000 مهمة يومياً على مدى 30 يوماً. استخدمنا أسعار نماذج الحدود من models.yaml الفعلي في Paxis، وأسعاراً تقديرية تمثيلية للاستدلال المُدار بالنماذج مفتوحة الأوزان في منتصف عام 2026.

نفس عبء العمل يكلف $3,750 شهرياً مع النماذج المميزة، مقابل $86 شهرياً مع نماذج مفتوحة الأوزان من مستوى Gemma، أي فارق يبلغ نحو 44 مرة. وكما أثبتت التجربة، بلغت جودة هذه الفئة مفتوحة الأوزان في مهام استدعاء الأدوات 100%. بمعنى آخر، هذا التوفير لم يأتِ على حساب الجودة بل من إزالة المواصفات الفائضة عن الحاجة. قد تتفاوت أسعار النماذج مفتوحة الأوزان بحسب المزود وما إذا كانت ذاتية الاستضافة أم مُدارة، لذلك أشرنا إليها صراحةً بوصفها تقديرية، إلا أن الاتجاه الجوهري، أي وفورات تغير رتبة كاملة، يبقى راسخاً.

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

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

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

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

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

لهذا النهج حدود واضحة لا يمكن إغفالها.

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

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

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

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

المصادر

• كود التجربة وسجلات النتائج: تجربة Gemma 4 لاستدعاء الأدوات (6/6 نجاح) موثقة في سجلات قياسية حقيقية ضمن outputs/blog-impl/open-weight-agent-cost-routing/.
• أسعار نماذج الحدود: Paxis models.yaml (costInput/costOutput، USD لكل مليون رمز مميز).
• أسعار النماذج مفتوحة الأوزان: تقديرات تمثيلية للاستدلال المُدار في منتصف عام 2026 [تقديري].

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

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

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

ما هي الذاكرة الإجرائية

من منظور معرفي، تُقسَّم الذاكرة عادة إلى ثلاثة أنواع: الذاكرة الدلالية (semantic) التي تحفظ الحقائق، والذاكرة العرضية (episodic) التي تحفظ الأحداث، والذاكرة الإجرائية (procedural) التي تحفظ الطرق. وفي أدبيات الوكلاء، تتولى الذاكرة الإجرائية مسؤولية الإجابة عن سؤال “كيف يُنفَّذ الأمر”، إذ تُجرّد تسلسلات الحركة المعقّدة إلى أنماط قابلة لإعادة الاستخدام، بما يتيح التنفيذ دون تخطيط من الصفر في كل مرة.

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

flowchart TB
    A[مسارات التنفيذ السابقة] --> B[استخلاص الإجراء<br/>Build]
    B --> C{شكل التخزين}
    C --> D[غير بارامتري<br/>نص برمجي]
    C --> E[بارامتري<br/>سياسة عصبية]
    D --> F[الاسترجاع والاختيار<br/>Retrieval]
    E --> F
    F --> G[تنفيذ المهمة]
    G --> H[التحديث وفق التغذية الراجعة<br/>إضافة وتعديل وحذف Update]
    H --> B

ما وراء استرجاع المطالبات: فصل التخزين والاسترجاع والتحديث

أبرز الأبحاث التي تناولت هذا التوجه بشكل مباشر هي Memp: Exploring Agent Procedural Memory (arXiv 2508.06433). يضع Memp الذاكرة الإجرائية كهدف تحسين من الدرجة الأولى، ويقطّر المسارات السابقة إلى طبقتين: تعليمات دقيقة خطوة بخطوة من جهة، وإجراءات عالية المستوى أشبه بنص برمجي من جهة أخرى. كما يفصل حلقة الذاكرة إلى ثلاث مراحل هي البناء (build) والاسترجاع (retrieval) والتحديث (update). وفي مرحلة التحديث، تُضاف العناصر أو تُعدَّل أو تُحذف وفق التغذية الراجعة من التنفيذ.

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

لماذا يهم هذا الآن: صعوبة التقييم

لم يُفهم بعد بشكل كافٍ ما إذا كانت الذاكرة الإجرائية تُنتج فعلاً مهارات صالحة للاستخدام. والبحث الذي يستهدف هذه الفجوة هو Managing Procedural Memory in LLM Agents (arXiv 2606.23127)، الذي يقترح معياراً بعنوان AFTER. يتألف هذا المعيار من 382 مهمة مؤسسية واقعية موزعة على 6 أدوار وظيفية، و22 مهارة إجرائية، ويقيس مدى قابلية انتقال المهارات عبر المهام والأدوار وبنية النماذج الأساسية.

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

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

يتخذ هذا التوجه البحثي شكله العملي بالكامل في Paxis التابعة لـThakiCloud. Paxis سحابة أصيلة للوكلاء (Agent-Native Cloud) تتعامل مع المهارات والأدوات والسياسات وسجلات التدقيق بوصفها موارد من الدرجة الأولى. وهنا تُعد بيئة المهارات (Skill Harness) بمثابة الذاكرة الإجرائية الإنتاجية فعلياً.

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

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

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

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

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

المصادر

• Memp: Exploring Agent Procedural Memory (arXiv 2508.06433)
• Managing Procedural Memory in LLM Agents: Control, Adaptation, and Evaluation (arXiv 2606.23127)
• Rethinking Memory Mechanisms of Foundation Agents in the Second Half: A Survey (arXiv 2602.06052)

عندما تشغّل خدمة LLM لفترة طويلة، تصل إلى نقطة غريبة. تنشر vLLM، وتراقب استخدام GPU، وتضبط حجم الدفعات (batch size)، لكنك في لحظة ما لا تستطيع أن تشرح بجملة واحدة “لماذا يستهلك هذا الطلب هذا القدر من KV Cache”، أو “ما الذي يقلّصه GQA بالضبط ليوفّر عرض النطاق الترددي للذاكرة”. تعرف كيف تستخدم الأدوات، لكن المبادئ التي تقوم عليها تبقى ضبابية. هذه الفجوة تجعل التحسين يعتمد على الحدس، وتمنعك من استنتاج السبب الجذري عندما يحدث عطل.

المصدر التعليمي amitshekhariitbhu/llm-internals يستهدف هذه المشكلة مباشرة. إنه مستودع تعلّم متدرج يجمع مقالات ومقاطع فيديو بترتيب يبدأ من التوكنة ويمر بالانتباه وبنية الترانسفورمر وKV Cache وصولاً إلى تحسين الاستدلال. المؤلف الأصلي هو Amit Shekhar، وقد رتّب المواضيع بحيث تبني نموذجاً ذهنياً واحداً متماسكاً بدلاً من مجموعة دروس متفرقة وعابرة.

تشغّل ThakiCloud منصة ai-platform لتقديم النماذج لعملاء متنوعين فوق Kubernetes. معظم العوامل التي تحدد تكلفة الخدمة وزمن الاستجابة تنبع من هذه البنية الداخلية التي يتناولها هذا المستودع. لذلك، هذا المقال ليس مجرد تعريف بمصدر تعليمي، بل محاولة لتوضيح لماذا يشكّل كل موضوع منها سلاحاً مباشراً لمهندس البنية التحتية.

ما هو هذا المصدر

llm-internals ليس إطار عمل لتشغيل الكود، بل هو مسار تعلّم (learning path). يتتبع خط الأنابيب الذي يمر به LLM من استقبال المدخل حتى إنتاج التوكن التالي، ويعرض المفاهيم اللازمة في كل مرحلة بترتيب مدعوم بمصادر خارجية. جوهر المستودع هو تصميم المنهج نفسه: “ما الذي يجب فهمه، وبأي ترتيب، حتى تكتمل الصورة الكاملة”.

المواضيع الرئيسية التي يغطيها المستودع تتبع التدفق التالي.

flowchart TB
    A[النص المدخل] --> B[التوكنة<br/>BPE Byte Pair Encoding]
    B --> C[التضمين<br/>تحويل التوكن إلى متجه]
    C --> D[الانتباه<br/>Query Key Value]
    D --> E[كتلة الترانسفورمر<br/>الانتباه + FFN بشكل متكرر]
    E --> F[KV Cache<br/>تسريع التوليد]
    E --> G[MoE<br/>توجيه الخبراء]
    D --> H[GQA<br/>مشاركة رؤوس KV]
    F --> I[تحسين الاستدلال<br/>كفاءة الخدمة]
    G --> I
    H --> I

أهمية هذا الترتيب تكمن في أن المواضيع اللاحقة لا يمكن فهمها دون المواضيع السابقة. فـ KV Cache لا يكتسب معناه إلا بعد فهم ما هما Key وValue في الانتباه، وGQA لا يظهر معناه إلا بعد فهم بنية الرؤوس في الانتباه متعدد الرؤوس، أي “ما الذي يتم مشاركته بالضبط”. قيمة هذا المستودع لا تكمن في عمق كل مصدر على حدة، بل في هذا الترتيب الذي لا يكسر سلسلة الاعتماد بين المفاهيم.

استعراض المواضيع الأساسية

التوكنة: نقطة البداية لكل شيء

لا يتعامل LLM مباشرة مع الحروف أو الكلمات، بل يعالج النص على شكل توكنات. تستخدم معظم النماذج الحديثة عائلة BPE (Byte Pair Encoding)، وهي طريقة تدمج بشكل متكرر أزواج البايتات الأكثر تكرراً معاً لبناء المفردات. قد تبدو التوكنة أمراً بسيطاً، لكنها من منظور الخدمة عامل تكلفة مباشر. نفس الجملة يمكن أن يختلف عدد توكناتها اختلافاً كبيراً باختلاف اللغة والمُرمِّز (tokenizer)، وعدد التوكنات ينعكس مباشرة على استهلاك KV Cache وحجم العمليات الحسابية. ظاهرة استهلاك اللغات غير الإنجليزية مثل الكورية والعربية عدداً أكبر من التوكنات مقارنة بالإنجليزية هي نقطة يجب مراعاتها بالضرورة عند احتساب تكلفة الخدمة.

الانتباه: Query وKey وValue

قلب الترانسفورمر هو الانتباه الذاتي (self-attention). يُسقَط كل توكن إلى ثلاثة متجهات. Query يمثل “ما الذي أبحث عنه”، وKey يمثل “ما الذي أقدّمه”، وValue يمثل “المحتوى الفعلي الذي سيُنقل”. يُحسب مقياس الانتباه عبر الضرب الداخلي بين Query وKey، ثم يمرّ عبر عملية القياس (scaling) والدالة softmax لإنتاج مجموع مرجّح لـ Value.

Attention(Q, K, V) = softmax( (Q · Kᵀ) / √d_k ) · V

هذه المعادلة بسيطة في ظاهرها، لكن حقيقة أن عملية الانتباه تنمو بمعدل O(n²) بالنسبة لطول التسلسل n هي ما ينتج عنه كل عمليات التحسين اللاحقة. من هنا تبدأ الإجابة عن سبب ارتفاع تكلفة السياقات الطويلة، وسبب حساسية بنية الخدمة لطول السياق.

كتلة الترانسفورمر وKV Cache

الترانسفورمر هو بنية من طبقات متعددة، تجمع كل طبقة منها الانتباه مع شبكة تغذية أمامية (FFN). في التوليد ذاتي الانحدار (autoregressive)، يُنتج التوكن واحداً تلو الآخر، وإعادة حساب Key وValue لكل التوكنات السابقة في كل خطوة يمثل هدراً كبيراً. KV Cache يخزّن قيم Key وValue التي حُسبت سابقاً ويعيد استخدامها، مما يرفع سرعة التوليد.

المشكلة هي أن هذه الذاكرة المؤقتة تستهلك ذاكرة كبيرة. يتناسب حجم الذاكرة المؤقتة تقريباً مع 2 × عدد الطبقات × عدد رؤوس KV × أبعاد الرأس × طول التسلسل × حجم الدفعة. السياقات الطويلة وكثرة الطلبات المتزامنة تضخّم هذه القيمة بشكل انفجاري. هذا هو بالضبط الضغط البنيوي الذي يجعل تقنية PagedAttention في vLLM تدير KV Cache على شكل صفحات لتقليل التجزئة.

MoE وGQA: تغييرات بنيوية لأجل الكفاءة

مزيج الخبراء (Mixture of Experts، MoE) يقسّم شبكة FFN إلى عدة “خبراء”، ويقوم موجّه (router) بتفعيل جزء فقط من الخبراء لكل توكن. إجمالي عدد المعاملات كبير، لكن حجم العمليات الحسابية الفعلي لكل توكن يصبح صغيراً. في المقابل، يفرض هذا على الخدمة تحديات جديدة: التوازي بين الخبراء، وعدم توازن التوجيه، وتوزيع الذاكرة.

الانتباه المُجمَّع الاستعلام (Grouped-Query Attention، GQA) هو حل وسط بين الانتباه متعدد الرؤوس (MHA) والانتباه متعدد الاستعلامات (MQA). في MHA، يملك كل رأس Key وValue خاصين به، بينما في MQA تشترك جميع الرؤوس في Key وValue واحد. أما GQA فيجمّع الرؤوس في عدد قليل من المجموعات، وتشترك كل مجموعة في KV خاص بها. والنتيجة أن حجم KV Cache وعرض النطاق الترددي للذاكرة ينخفضان بينما يبقى فقدان الجودة عند حدّه الأدنى. فهم GQA يوضّح لماذا تعتمد النماذج مفتوحة الأوزان الحديثة هذه البنية، ولماذا تختلف موازنة الذاكرة عند الخدمة تبعاً لذلك.

لماذا تهم هذه المعرفة مهندس البنية التحتية

المواضيع أعلاه ليست موضع فضول أكاديمي، بل هي السبب المباشر لتكلفة الخدمة. فهم معادلة حجم KV Cache يتيح توقّع كيف يصطدم عدد الطلبات المتزامنة وطول السياق بذاكرة GPU. وفهم GQA يفسّر لماذا يستطيع بعض النماذج معالجة عدد أكبر من الطلبات على نفس GPU. وفهم MoE يسمح بالاستعداد لسبب تعقيد الجدولة الناتج عن التوزيع المتوازي للخبراء.

على النقيض، غياب هذه المعرفة يعني أنك ستكتفي، عند حدوث عطل، بملاحظة عرض “نفدت الذاكرة” فقط، وتكرر الاستجابة المكلفة المتمثلة في تقليل حجم الدفعة عشوائياً أو إضافة المزيد من وحدات GPU. المهندس الذي يعرف البنية الداخلية يملك رافعات أدق: ترقيم KV Cache، وسقف طول السياق، والتكميم (quantization)، واختيار نماذج تعتمد GQA.

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

تقدّم منصة ai-platform من ThakiCloud استدلالاً قائماً على vLLM لعدة مستأجرين فوق Kubernetes وجدولة GPU عبر Kueue. تنعكس البنية الداخلية التي استعرضناها في هذا المقال مباشرة على رافعات التشغيل الفعلية.

• KV Cache: استناداً إلى PagedAttention ومعادلة حجم KV Cache، نحدّد سقف طول السياق وميزانية التزامن لكل مستأجر. توقّع استهلاك الذاكرة المؤقتة يتيح رفع الإنتاجية دون الإفراط في حجز ذاكرة GPU.
• GQA والتكميم: من أجل استيعاب عدد أكبر من الطلبات على نفس العتاد، نُعطي الأولوية في المراجعة للنماذج مفتوحة الأوزان التي تعتمد GQA، وندمج ذلك مع التكميم بهدف تحقيق تكلفة خدمة منخفضة في البيئات المحلية (on-premise) والسيادية.
• خدمة MoE: نراعي مسبقاً أن نماذج MoE التي تحتاج توازياً بين الخبراء تتطلب معاملة خاصة في تصميم طوابير Kueue وتوزيع العُقد.

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

القيود ووجهات النظر المضادة

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

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

المصادر

• amitshekhariitbhu/llm-internals (GitHub)
• التغريدة الأصلية المُوصية: Dan Kornas, “Stop learning LLM internals from random one-off tutorials”

Most teams that open their agent billing statement share the same misconception: “Our agents do a lot of hard reasoning, so we need the top-tier model.” Look at actual production traffic, though, and the picture is different. The overwhelming majority of requests are repetitive work: translating natural language into API calls, classifying logs, chaining pipeline steps, summarizing results. None of that requires world-class reasoning. Running all of it through a frontier premium model means paying a premium price for capability you are not using.

This post documents how we measured that waste and eliminated it. We ran real production requests through an open-weight model (Gemma 4) as structured tool calls to validate quality, then used Paxis CostRouter to calculate exactly how far costs drop when each task is routed to the right model tier. The short answer: the same workload that costs one amount on a frontier premium model costs about 44 times less on a managed open-weight tier.

What This Approach Does

The core idea is straightforward. Rather than sending every agent task to a single model, you route each task to a different model tier based on its nature. Hard reasoning and judgment go to the frontier premium. Code generation goes to an open-weight model strong at code. Tool calls and pipeline execution go to an open-weight agent tier. High-volume extraction and classification go to the cheapest economy tier. Sending each task to the model that wins at it preserves quality while shrinking the bill.

Two things need to be true for this to work. First, open-weight models must genuinely handle a meaningful share of agent tasks. Second, the routing must happen automatically at the platform level, not by a human picking a model for every request. The sections below confirm each with an experiment and a real configuration.

flowchart TB
    A[Agent task request] --> B{Classify task type}
    B -->|Reasoning and judgment, top tier| C[Frontier premium]
    B -->|Code generation| D[Open-weight code tier]
    B -->|Tool calls and pipelines| E[Open-weight agent tier<br/>Gemma 4]
    B -->|Extraction, classification, bulk| F[Open-weight economy]
    C --> G[Policy gate + audit log]
    D --> G
    E --> G
    F --> G
    G --> H[Return result + log cost]

Setup and Integration

The first question was whether an open-weight model can handle the real core task of an agent: converting a natural-language request into a structured tool call. We tested Gemma 4 26B via a managed API. The experiment was written with no external dependencies, just the standard library (urllib).

We gave the model a tool schema for a cloud operations pipeline: five tools covering metric queries, pod restarts, cost aggregation, deployment scaling, and secret rotation. The instruction was to receive a natural-language request and output exactly one JSON object with the correct tool name and all required parameters.

TOOL_SPEC = """You are an operations automation agent. Convert user requests into a single tool-call JSON object.
Output only the JSON object, no explanation or markdown fences.

Available tools and required parameters:
- query_metrics: {metric, window_days, threshold?, region?}
- restart_pods: {region, selector, only_failed(bool)}
- aggregate_cost: {group_by, month, service?}
- scale_deployment: {name, region, replicas}
- rotate_secret: {name, namespace}

Output schema: {"tool": "<name>", "params": { ... }}"""

def call(prompt):
    body = {
        "contents": [{"role": "user",
                      "parts": [{"text": TOOL_SPEC + "\n\nRequest: " + prompt}]}],
        "generationConfig": {"temperature": 0.0, "maxOutputTokens": 1024},
    }
    # calls gemma-4-26b-a4b-it generateContent, captures latency, tokens, and output

We hit one practical issue worth documenting. Gemma 4 generates thinking tokens before its final response. With an output cap of 256, the thinking phase consumed the budget and the final JSON came back empty. Raising the cap to 1024 and filtering out response parts flagged as thought gave the correct final answer. This is a commonly missed step when integrating open-weight models with thinking output into pipelines, so measuring it directly was worthwhile.

On the platform side, Paxis manages model selection through a single declarative catalog file (models.yaml). Each model entry carries its input and output price per million tokens and its tier label. Routing decisions are made from this catalog.

# models.yaml: tier and real unit prices drive routing decisions (USD / 1M tokens)
- id: claude-opus-4-8      # premium
  tier: premium
  costInput: 5.0
  costOutput: 25.0
- id: claude-sonnet-5      # standard (default)
  tier: standard
  costInput: 3.0
  costOutput: 15.0
# Add open-weight providers (Ollama, vLLM, etc.) with the same schema
# and CostRouter will automatically send task-tier-matched requests to the cheapest eligible model.

When a task arrives, CostRouter evaluates its tier and selects the cheapest eligible model from the catalog. Register an open-weight provider using the same schema and tool calls, plus bulk processing work, will flow automatically to the cheaper tier. That is why humans do not need to choose a model for every request.

Experiment Results

We ran six real production operations requests through Gemma 4 and scored the output directly. The scoring criteria were two: is the output valid JSON, and does it contain the correct tool name and all required parameters.

All six requests produced the correct tool selection with every required parameter filled in. For example, the request “Show me nodes where GPU utilization exceeded 80% over the last 7 days” produced:

{"tool": "query_metrics", "params": {"metric": "gpu_utilization", "window_days": 7, "threshold": 80}}

The threshold field is optional in the schema, yet the model read “80%” from the request and populated it correctly. For “Scale the inference-api deployment in ap-northeast to 6 replicas,” the model mapped name, region, and replica count precisely to scale_deployment. These are unmanipulated measurements confirming that an open-weight model handles the core tasks of agent automation, tool calling and pipeline execution, without quality loss.

The 15.3-second average latency is measured on a free shared endpoint with thinking tokens included. That number drops considerably in a self-hosted or batch processing environment. The key point here is not the absolute latency but that quality did not degrade.

Now for the cost. Using the measured token profile as a starting point, we modeled a realistic single turn at 1,000 input tokens and 300 output tokens (accounting for system prompt, tool schema, and context), run at 10,000 tasks per day for 30 days. Frontier prices come from the actual values in Paxis models.yaml. Open-weight prices come from representative mid-2026 managed inference estimates.

The same workload costs $3,750 per month at the frontier premium tier and $86 per month at the Gemma-class open-weight tier. That is roughly a 44x difference. And as the experiment shows, open-weight quality on tool-call tasks was 100%. This saving does not come from degrading quality. It comes from removing overspec. Open-weight unit prices vary by provider and whether you self-host (which is why they are labeled as estimates), but the order-of-magnitude savings direction is solid.

Implications for ThakiCloud Products

This pattern fits precisely with how Paxis, ThakiCloud’s Agent-Native Cloud, is designed. Paxis treats skills, tools, policies, and audit logs as first-class resources, the same way traditional cloud treats servers and networks. CostRouter sits on top of that as the layer that picks the right model for each task.

• Per-task routing is a first-class feature. A single models.yaml is the one source of truth for which provider and model to use. Register an open-weight provider using the same schema and tool calls plus bulk processing work will flow automatically to the cheaper tier. Standard tier is the default and premium requires an explicit selection, so overspec routing cannot happen by accident.
• Isolated execution and governance are built in. Regardless of which tier a task is sent to, the result passes through the policy gate and audit log. Using a cheaper model does not loosen control. In fact, because every task’s model, token count, and cost are recorded, you can retrospectively identify which task types are using an expensive tier unnecessarily and reroute them.
• The design is compatible with on-premises and sovereign requirements. Open-weight models can be served on your own GPUs, which lets you control both cost and data residency for customers whose data cannot leave their environment. ThakiCloud’s ai-platform runs this open-weight tier in multi-tenant mode using Kueue-based GPU scheduling and vLLM serving. Efficient serving directly enables agent economics, which means ai-platform’s infrastructure advantage underpins Paxis’s routing economics.

The core principle is not “use expensive models less.” It is “route every task to the model that wins at it.” Most agent tasks are tool calls and pipeline execution, and the vast majority of those are well within reach of open-weight models.

Limitations and Counterarguments

This approach has clear boundaries.

On tasks that require the hardest reasoning and the broadest world knowledge, open-weight models still fall behind frontier. That is why routing must be “open-weight where it wins” and not “open-weight everywhere.” Difficult judgment calls belong at the premium tier. Routing them to a cheap tier because of the cost savings produces quality failures, not savings.

Task-type classification itself becomes a new failure point. If classification is wrong, routing is wrong. That means you need a feedback loop: continuously observe classification results alongside actual quality, and bump task types back to a higher tier if failures start accumulating at the cheaper one.

The open-weight unit prices in the cost table are estimates. Absolute values depend on the provider and whether you self-host. The frontier prices are real, the experiment quality is measured, and the conclusion that savings are order-of-magnitude in scale is robust. We recommend running the same calculation with your own actual unit prices.

Finally, latency. Fifteen seconds on a free shared endpoint is a burden for real-time conversational UX. For batch pipelines and background automation it is fine. For user-facing paths where someone is waiting, you need either self-hosted serving to reduce latency or routing that sends only that segment to a faster tier.

Sources

• Experiment code and result logs: The Gemma 4 tool-call experiment (6/6 success) described in this post is based on measured logs in outputs/blog-impl/open-weight-agent-cost-routing/.
• Frontier unit prices: Paxis models.yaml (costInput/costOutput, USD per 1M tokens).
• Open-weight unit prices: Representative mid-2026 managed inference estimates [estimated].

Anyone who has run LLM agents for a while hits the same wall. The agent reasons from scratch every time, fumbling its way back through a procedure it already solved last week. A common fix is to cram frequently used skills straight into the prompt. But this approach is fragile for two reasons. First, as skills accumulate they eat up the context window, leaving less room for the actual task. Second, prompt templates break easily the moment the situation shifts even slightly.

Recent research on agent memory reframes this problem through the lens of procedural memory. Just as human procedural memory holds skilled actions that execute without conscious thought, like riding a bike, an agent’s procedural memory compresses the execution steps of recurring tasks into a reusable form. The core shift is moving procedural knowledge beyond prompt retrieval, into a separate storage, retrieval, and update architecture, and ultimately into a neural policy embedded in the model’s own parameters.

This post maps that shift through peer-reviewed papers. Since ThakiCloud’s Agent-Native Cloud, Paxis, treats skills as first-class resources in exactly the way this research line points toward, we close by drawing that connection.

What Is Procedural Memory

From a cognitive-science standpoint, memory is commonly split into three kinds: semantic memory for facts, episodic memory for events, and procedural memory for methods. In the agent literature, procedural memory covers the “how”: it abstracts complex action sequences into reusable patterns, so the agent doesn’t have to plan from the ground up every single time.

The trouble is that in most agents today, this procedural knowledge exists in one of three forms: hand-crafted by a person, embedded in a brittle prompt template, or implicitly entangled in the model’s parameters where it is expensive to update. What this research targets is lifting that knowledge into a learnable, updatable, first-class object.

flowchart TB
    A[Past execution trajectories] --> B[Procedure extraction<br/>Build]
    B --> C{Storage form}
    C --> D[Non-parametric<br/>text scripts]
    C --> E[Parametric<br/>neural policy]
    D --> F[Retrieval and selection<br/>Retrieval]
    E --> F
    F --> G[Task execution]
    G --> H[Feedback-driven update<br/>add, revise, delete Update]
    H --> B

Beyond Prompt Retrieval: Separating Build, Retrieval, and Update

The paper that takes this shift on directly is Memp: Exploring Agent Procedural Memory (arXiv 2508.06433). Memp treats procedural memory as a first-class optimization target and distills past trajectories into two layers: fine-grained, step-by-step instructions, and higher-level, script-like procedures. It then splits the memory loop into three distinct phases: build, retrieval, and update. In the update phase, entries are added, revised, or deleted based on execution feedback.

This separation matters because it is fundamentally different from stuffing skills into a prompt. In the prompt-based approach, storage and retrieval are collapsed into one, and the very concept of “update” barely exists. Once you separate the three phases, when and how a procedure enters or leaves the pool, and what gets fixed after a failure, become explicit design decisions. According to the literature, the broader direction of this shift is summarized as a move from explicit non-parametric templates toward implicit parametric neural policies (the Foundation Agents memory survey, arXiv 2602.06052). In other words, the field is moving past storing and retrieving procedures as text, toward folding experience directly into the model’s own policy.

Why This Matters Now: The Evaluation Problem

Whether procedural memory actually produces usable skills is still not well understood. The paper aimed at this gap is Managing Procedural Memory in LLM Agents (arXiv 2606.23127). It proposes a benchmark called AFTER: 382 realistic enterprise tasks spanning 6 job roles, paired with 22 procedural skills, built to measure how well a skill transfers across tasks, roles, and model backbones.

The question this benchmark raises is the crux of the matter. Does a procedure learned in one context hold up in another? Does a skill still work once the underlying model changes? The moment you introduce procedural memory, you need a way to measure whether a given skill is actually reusable. Even with a solid build-retrieve-update architecture in place, a skill that fails to transfer ends up no better than an expensive prompt template.

Implications for ThakiCloud’s Products

This line of research already has a concrete production shape in ThakiCloud’s Paxis. Paxis is an Agent-Native Cloud that treats skills, tools, policies, and audit logs as first-class resources. Its skill harness is, in effect, procedural memory running in production.

• A practical counterpart to build, retrieval, and update: Paxis’s skill harness selects (retrieves) from more than 960 skills via BM25, executes them in isolated sandboxes, and improves (updates) them through a self-evolution loop. The three-phase separation that Memp proposed shows up here as an operating system.
• An architecture that moves past prompt retrieval: Instead of stuffing skills into every prompt, Paxis selectively pulls in verified skills, which preserves the context budget while keeping the procedure consistent. This lines up exactly with the “beyond prompt retrieval” direction covered in this post.
• Evaluation and audit: Paxis manages the “transferability” that the AFTER benchmark emphasizes through policy gates and audit logs. Because which skill was selected, when, and what it did is all tracked, there is a data-backed basis for telling reusable procedures apart from ones that are not.

From an infrastructure standpoint, ai-platform underpins this skill execution. Because agents run skills on top of Kueue GPU scheduling and multi-tenant serving, the execution cost of procedural memory feeds directly into serving efficiency. Low-cost serving (ai-platform) is what makes agent economics (Paxis) sustainable.

Limitations and Counterarguments

Moving procedural memory toward a parametric neural policy comes with a clear cost. A text script can be read and edited by a human, but a procedure folded into parameters is hard to audit and hard to update. It is difficult to inspect what has actually been stored, and just as difficult to pick out and delete a bad procedure. In regulated or sovereign environments where explainability matters, that opacity becomes a risk in its own right.

Non-parametric retrieval is not a silver bullet either. Retrieval can still surface the wrong procedure, and selection quality can degrade as the storage pool grows. As benchmarks like AFTER show, skill transferability is still at an early stage of validation, and there is no guarantee that a procedure that works in one domain will work in another. Procedural memory is a promising direction for keeping agents from starting over from a blank slate every time, but it will only become a trustworthy production asset once storage form, retrieval quality, update safety, and evaluation methodology mature together.

Sources

• Memp: Exploring Agent Procedural Memory (arXiv 2508.06433)
• Managing Procedural Memory in LLM Agents: Control, Adaptation, and Evaluation (arXiv 2606.23127)
• Rethinking Memory Mechanisms of Foundation Agents in the Second Half: A Survey (arXiv 2602.06052)

If you operate LLM serving long enough, you eventually hit an odd spot. You’ve deployed vLLM, you monitor GPU utilization, you tune batch sizes, and yet you still can’t put into words why a given request occupies this much KV cache, or exactly what GQA trims away to save memory bandwidth. You know how to operate the tools, but the principles underneath stay blurry. That gap forces optimization to run on intuition, and it leaves you unable to reason about root causes when something breaks.

A learning resource that takes this problem head-on is amitshekhariitbhu/llm-internals. It’s a step-by-step repository that strings together blog posts and videos in a deliberate order, starting from tokenization and moving through attention, transformer architecture, KV cache, and inference optimization. The original author is Amit Shekhar, and the topics are arranged to build a single coherent mental model rather than leaving readers with a pile of disconnected one-off tutorials.

ThakiCloud operates ai-platform, which serves models across diverse customer environments on Kubernetes. Most of what determines serving cost and latency traces back to the internals this repository covers. So this post isn’t just a resource pointer: it walks through why each topic becomes a direct, usable weapon for an infrastructure engineer.

What This Resource Actually Is

llm-internals isn’t a framework you run code with, it’s a learning path. It follows the pipeline an LLM goes through from receiving input to producing the next token, presenting the concepts needed at each stage alongside external references, in order. The core value lies in the curriculum design itself: deciding what needs to be understood, and in what sequence, for the full picture to click into place.

The main topics the repository covers follow this flow:

flowchart TB
    A[Input text] --> B[Tokenization<br/>BPE Byte Pair Encoding]
    B --> C[Embedding<br/>Tokens to vectors]
    C --> D[Attention<br/>Query Key Value]
    D --> E[Transformer block<br/>Attention + FFN repeated]
    E --> F[KV Cache<br/>Speeds up generation]
    E --> G[MoE<br/>Expert routing]
    D --> H[GQA<br/>KV head sharing]
    F --> I[Inference optimization<br/>Serving efficiency]
    G --> I
    H --> I

This order matters because later topics don’t make sense without the earlier ones. The KV cache only means something once you know what the Key and Value in attention actually are, and GQA only shows “what’s being shared” once you understand the head structure of multi-head attention. The repository’s value isn’t the depth of any single article, it’s the sequencing that never breaks this dependency chain.

A Closer Look at the Core Topics

Tokenization: Where Everything Starts

LLMs don’t work directly with letters or words, they process tokens. Most modern models use some variant of BPE (Byte Pair Encoding), which builds a vocabulary by repeatedly merging byte pairs that frequently appear together. Tokenization looks trivial, but from a serving standpoint it’s a direct cost driver. The same sentence can produce very different token counts depending on the language and the tokenizer, and token count directly maps to KV cache occupancy and compute. The fact that non-English text (Korean, Arabic, and similar languages) tends to consume more tokens than English is something you have to account for when estimating serving costs.

Attention: Query, Key, Value

The heart of the transformer is self-attention. Each token gets projected into three vectors. Query represents “what am I looking for,” Key represents “what do I offer,” and Value represents “what I actually deliver.” The attention score is computed as the dot product of Query and Key, then passed through scaling and softmax to produce a weighted sum over Value.

Attention(Q, K, V) = softmax( (Q · Kᵀ) / √d_k ) · V

The formula itself is simple, but the fact that attention computation grows as O(n²) with sequence length n is what gives rise to nearly every optimization technique that follows. This is the origin point for why long context is expensive, and why serving infrastructure is so sensitive to context length.

Transformer Blocks and the KV Cache

A transformer stacks multiple layers of blocks, each combining attention with a feed-forward network (FFN). In autoregressive generation, tokens are produced one at a time, and recomputing the Key and Value of every prior token at each step would be wasteful. The KV cache solves this by storing already-computed Keys and Values and reusing them, which speeds up generation.

The catch is that this cache consumes memory. Cache size scales roughly with 2 × number of layers × number of KV heads × head dimension × sequence length × batch size. Long contexts and many concurrent requests can blow this number up fast. This structural pressure is exactly why vLLM’s PagedAttention manages the KV cache in pages: to reduce fragmentation.

MoE and GQA: Structural Changes for Efficiency

Mixture of Experts (MoE) splits the FFN into multiple experts, and a router activates only a subset of experts per token. Total parameter count is large, but the actual compute per token stays small. In exchange, serving has to deal with new challenges: expert parallelism, routing imbalance, and memory placement.

Grouped-Query Attention (GQA) is a middle ground between multi-head attention (MHA) and multi-query attention (MQA). In MHA, every head has its own Key/Value; in MQA, all heads share a single Key/Value. GQA groups heads into a handful of clusters and shares KV within each group. The result is a reduction in KV cache size and memory bandwidth with minimal quality loss. Understanding GQA clarifies why recent open-weight models adopt this structure, and why it shifts your memory budget at serving time.

Why This Knowledge Matters for Infrastructure Engineers

None of the topics above are academic curiosities, they are direct causes of serving cost. Understanding the KV cache size formula lets you predict how concurrent request count and context length collide with GPU memory. Understanding GQA lets you explain why one model handles more requests than another on the same GPU. Understanding MoE prepares you for why expert-parallel placement complicates scheduling.

Without this knowledge, the usual response to an incident is to see “out of memory” and repeatedly reach for the expensive fix: cut the batch size blindly, or throw more GPUs at it. An engineer who understands the internals has finer levers available: KV cache paging, context length caps, quantization, and choosing a GQA-based model.

Implications for ThakiCloud’s Products

ThakiCloud’s ai-platform delivers multi-tenant, vLLM-based inference on top of Kubernetes and Kueue GPU scheduling. The internals covered in this post translate directly into operational levers.

• KV cache: Using PagedAttention and the KV cache size formula as a basis, we set per-tenant context length caps and concurrency budgets. Predicting cache occupancy lets us push throughput up without over-committing GPU memory.
• GQA and quantization: To fit more requests on the same hardware, we prioritize open-weight models that adopt GQA, combining it with quantization to target low serving costs in on-premise and sovereign environments.
• MoE serving: MoE models that require expert parallelism get separate treatment in Kueue queue design and node placement, planned for in advance.

From an agent perspective, ThakiCloud’s Agent-Native Cloud, Paxis, is well suited to accumulating this kind of internal knowledge as a team asset. Because Paxis treats skills as first-class resources, a recurring judgment call like “compute the KV cache budget” can be hardened into a verified skill, reused inside an isolated sandbox, and tracked through audit logs. It becomes a channel for turning serving know-how, which otherwise tends to live only in individual engineers’ heads, into procedural knowledge the whole organization owns.

Limitations and Counterarguments

The biggest weakness of this resource is the fate of any curated repository. Because it’s built by stitching together external blog posts and videos, links can go stale or disappear, and the notation and depth vary from source to source. There’s also no guarantee that the latest architectural shifts (new attention variants, for instance) get folded in right away.

There’s also still a gap between conceptual understanding and real-world operation. Memorizing the KV cache formula doesn’t hand you the actual throughput number on a specific GPU. Real benchmarking, profiling, and workload-specific tuning all require separate hands-on experience. This learning path is genuinely valuable as a starting point for building an accurate mental model, but it isn’t, by itself, the endpoint of serving optimization. Understanding the principles has to be followed by validation against real traffic.

Sources

• amitshekhariitbhu/llm-internals (GitHub)
• Original recommending tweet: Dan Kornas, “Stop learning LLM internals from random one-off tutorials”

에이전트 운영비 청구서를 열어 보면 대부분의 팀이 같은 착각을 합니다. “우리 에이전트가 어려운 추론을 많이 하니까 최상위 모델을 써야 한다”는 것입니다. 그런데 실제 트래픽을 뜯어보면 그림이 다릅니다. 자연어 요청을 API 호출로 바꾸고, 로그를 분류하고, 파이프라인을 잇고, 결과를 요약하는 반복 작업이 압도적으로 많습니다. 이 작업들은 세계 최고 수준의 추론이 필요 없습니다. 그런데도 전부 프런티어 프리미엄 모델로 처리하면, 비싼 값을 치르고 오버스펙을 사는 셈입니다.

이 글은 그 낭비를 실측으로 확인하고 접는 과정입니다. 오픈 가중치 모델(Gemma 4)로 실제 운영 요청을 tool-call로 변환하는 실험을 돌려 품질을 확인하고, Paxis의 CostRouter로 작업마다 알맞은 모델에 라우팅했을 때 비용이 어디까지 내려가는지 실제 토큰과 실가격으로 계산합니다. 결론부터 말하면, 동일한 워크로드에서 프런티어 프리미엄 대비 약 44배까지 비용이 줄었습니다.

이 접근은 무엇인가

핵심은 단순합니다. 에이전트 작업을 하나의 모델로 다 처리하지 않고, 작업의 성격에 따라 서로 다른 등급의 모델에 나눠 보내는 것입니다. 어려운 추론과 판단은 프런티어 프리미엄에, 코드 생성은 코드에 강한 오픈 가중치 모델에, 도구 호출과 파이프라인 실행은 에이전트급 오픈 가중치 모델에, 대량 추출과 분류는 가장 저렴한 이코노미 티어에 보냅니다. 각 작업을 이기는 모델로 보내면 품질은 지키면서 청구서만 줄어듭니다.

이 발상이 성립하려면 두 가지가 참이어야 합니다. 첫째, 오픈 가중치 모델이 에이전트 작업의 상당 부분을 실제로 감당해야 합니다. 둘째, 라우팅을 사람이 매번 손으로 고르지 않고 플랫폼이 자동으로 처리해야 합니다. 아래에서 이 두 가지를 각각 실험과 실제 구성으로 확인합니다.

flowchart TB
    A[에이전트 작업 요청] --> B{작업 유형 분류}
    B -->|추론·판단 최상위| C[프런티어 프리미엄]
    B -->|코드 생성| D[오픈 가중치 코드급]
    B -->|도구 호출·파이프라인| E[오픈 가중치 에이전트급<br/>Gemma 4]
    B -->|추출·분류·대량| F[오픈 가중치 이코노미]
    C --> G[정책 게이트 + 감사 로그]
    D --> G
    E --> G
    F --> G
    G --> H[결과 반환 + 비용 기록]

설치 및 통합

먼저 오픈 가중치 모델이 에이전트의 실제 핵심 작업, 즉 자연어 요청을 구조화된 도구 호출로 바꾸는 일을 해낼 수 있는지 확인했습니다. 검증 대상은 Gemma 4 26B이고, 관리형 API로 호출했습니다. 별도 의존성 없이 표준 라이브러리(urllib)만으로 호출하도록 실험을 짰습니다.

에이전트에게 준 과제는 클라우드 운영 파이프라인의 도구 스키마입니다. 지표 조회, 파드 재시작, 비용 집계, 디플로이먼트 스케일링, 시크릿 교체 다섯 가지 도구를 정의하고, 자연어 요청을 받아 정확한 도구와 필수 파라미터를 담은 JSON 한 개만 출력하도록 지시했습니다.

TOOL_SPEC = """당신은 운영 자동화 에이전트입니다. 사용자 요청을 도구 호출 JSON 하나로 변환하세요.
JSON 객체만 출력하고, 설명이나 마크다운 펜스는 넣지 마세요.

사용 가능한 도구와 필수 파라미터:
- query_metrics: {metric, window_days, threshold?, region?}
- restart_pods: {region, selector, only_failed(bool)}
- aggregate_cost: {group_by, month, service?}
- scale_deployment: {name, region, replicas}
- rotate_secret: {name, namespace}

출력 스키마: {"tool": "<name>", "params": { ... }}"""

def call(prompt):
    body = {
        "contents": [{"role": "user",
                      "parts": [{"text": TOOL_SPEC + "\n\nRequest: " + prompt}]}],
        "generationConfig": {"temperature": 0.0, "maxOutputTokens": 1024},
    }
    # gemma-4-26b-a4b-it 로 generateContent 호출, 지연·토큰·출력 캡처

여기서 한 가지 실전 함정을 만났습니다. Gemma 4는 응답 전에 사고(thinking) 토큰을 생성하는데, 출력 상한을 256으로 두면 사고 단계에서 잘려 최종 JSON이 비어 버립니다. 상한을 1024로 올리고, 응답 파트에서 thought 플래그가 붙은 부분을 걸러내고 최종 답변만 취하도록 고치니 정상 동작했습니다. 오픈 가중치 모델을 파이프라인에 넣을 때 흔히 놓치는 부분이라, 실측 코드로 확인해 둘 가치가 있었습니다.

플랫폼 쪽 통합은 Paxis의 모델 카탈로그가 담당합니다. Paxis는 어떤 공급자의 어떤 모델을 쓸지 하나의 선언 파일(models.yaml)로 관리하고, 각 모델의 입력·출력 단가와 등급을 함께 적어 둡니다. 라우팅은 이 카탈로그를 근거로 이뤄집니다.

# models.yaml: 등급과 실단가가 라우팅의 근거가 된다 (USD / 1M tokens)
- id: claude-opus-4-8      # 프리미엄
  tier: premium
  costInput: 5.0
  costOutput: 25.0
- id: claude-sonnet-5      # 표준 (기본값)
  tier: standard
  costInput: 3.0
  costOutput: 15.0
# 오픈 가중치 공급자(Ollama·vLLM 등)를 같은 스키마로 추가하면
# CostRouter가 작업 등급에 맞춰 자동으로 골라 보낸다.

작업이 들어오면 CostRouter가 작업 등급을 판단해 카탈로그에서 가장 싼 적격 모델을 고릅니다. 여기에 오픈 가중치 공급자를 같은 스키마로 얹어 두면, 도구 호출이나 대량 처리 같은 작업이 자동으로 저렴한 티어로 흘러갑니다. 라우팅을 사람이 매번 고르지 않아도 되는 이유입니다.

실제 실험 결과

여섯 개의 실제 운영 요청을 Gemma 4에 넣고 결과를 그대로 채점했습니다. 채점 기준은 두 가지입니다. 출력이 유효한 JSON인가, 그리고 올바른 도구와 필수 파라미터를 담았는가입니다.

여섯 건 모두 정확한 도구를 골랐고 필수 파라미터를 빠짐없이 채웠습니다. 예를 들어 “지난 7일간 GPU 사용률이 80%를 넘은 노드를 조회해줘”라는 요청에 대해 다음을 내놓았습니다.

{"tool": "query_metrics", "params": {"metric": "gpu_utilization", "window_days": 7, "threshold": 80}}

스키마에서 threshold는 선택 파라미터였는데도, 요청에 담긴 “80%”를 읽어 임계값으로 채워 넣었습니다. “ap-northeast 리전의 inference-api 디플로이먼트를 6개로 늘려줘”에 대해서는 scale_deployment에 이름·리전·복제 수를 정확히 매핑했습니다. 도구 호출과 파이프라인 실행이라는 에이전트 자동화의 핵심 작업을 오픈 가중치 모델이 충분히 감당한다는 것을, 조작 없는 실측으로 확인한 셈입니다.

평균 15.3초라는 지연은 무료 공유 엔드포인트에서 사고 토큰까지 포함해 측정한 값입니다. 자체 서빙이나 배치 처리 환경에서는 크게 줄어듭니다. 여기서 중요한 건 절대 지연이 아니라, 품질이 무너지지 않는다는 사실입니다.

이제 비용입니다. 실측 토큰 프로파일을 바탕으로, 작업 하나가 입력 1,000 토큰과 출력 300 토큰을 쓴다고 잡고(시스템 프롬프트와 도구 스키마, 문맥을 포함한 현실적인 한 턴), 하루 1만 건을 30일 돌리는 에이전트 함대를 가정했습니다. 프런티어 단가는 Paxis models.yaml의 실제 값을 쓰고, 오픈 가중치 단가는 2026년 중반 관리형 추론의 대표 추정치를 썼습니다.

같은 워크로드가 프리미엄에서는 월 3,750달러, Gemma급 오픈 가중치에서는 월 86달러입니다. 약 44배 차이입니다. 그리고 앞선 실험이 보여주듯, 도구 호출 작업에서 이 오픈 가중치 티어의 품질은 100%였습니다. 즉 이 44배는 품질을 깎아 얻은 절감이 아니라, 오버스펙을 걷어낸 절감입니다. 오픈 가중치 단가는 공급자와 자체 서빙 여부에 따라 달라지지만(그래서 추정치로 명시했습니다), 자릿수가 바뀌는 절감이라는 방향은 견고합니다.

ThakiCloud 제품 적용 시사점

이 패턴은 Paxis(ThakiCloud의 Agent-Native Cloud)의 설계와 정확히 맞물립니다. Paxis는 기존 클라우드가 서버와 네트워크를 일급 자원으로 다루듯, 스킬·도구·정책·감사 로그를 일급 자원으로 다룹니다. 그 위에서 CostRouter는 작업마다 모델을 고르는 계층입니다.

• 작업별 라우팅이 기본 기능입니다. models.yaml 하나가 어떤 공급자·모델을 쓸지의 단일 진실이고, 여기에 오픈 가중치 공급자를 같은 스키마로 등록하면 도구 호출·대량 처리 작업이 자동으로 저렴한 티어로 흘러갑니다. 표준 등급을 기본값으로 두고 프리미엄은 명시 선택으로만 여는 구조라, 오버스펙 라우팅이 사고로 일어나지 않습니다.
• 격리 실행과 거버넌스가 붙어 있습니다. 어떤 티어로 보내든 결과는 정책 게이트와 감사 로그를 통과합니다. 저렴한 모델을 쓴다고 통제가 느슨해지지 않습니다. 오히려 모든 작업의 모델·토큰·비용이 기록되므로, 어느 작업이 비싼 티어를 불필요하게 쓰는지 사후에 짚어 다시 라우팅할 수 있습니다.
• 온프렘·소버린 요구와 정합합니다. 오픈 가중치 모델은 자체 GPU에서 서빙할 수 있어, 데이터가 외부로 나가면 안 되는 고객 환경에서 비용과 통제를 동시에 잡습니다. ThakiCloud의 ai-platform은 Kueue 기반 GPU 스케줄링과 vLLM 서빙으로 이 오픈 가중치 티어를 멀티테넌트로 돌립니다. 저렴한 서빙이 곧 에이전트 경제성을 만든다는 점에서, ai-platform의 인프라 경쟁력이 Paxis의 라우팅 경제성을 떠받칩니다.

정리하면, “비싼 모델을 덜 쓰자”가 아니라 “작업마다 이기는 모델을 쓰자”가 핵심입니다. 대부분의 에이전트 작업은 도구 호출과 파이프라인 실행이고, 그 대부분은 오픈 가중치로 충분합니다.

한계 및 반론

이 접근에도 분명한 경계가 있습니다.

가장 어려운 추론과 폭넓은 세계 지식이 필요한 작업에서는 오픈 가중치가 여전히 프런티어에 뒤집니다. 그래서 라우팅은 “전부 오픈 가중치로”가 아니라 “이기는 곳에만 오픈 가중치로”여야 합니다. 어려운 판단은 프리미엄에 남겨 두는 것이 옳습니다. 라우팅을 잘못 설계해 어려운 작업까지 싼 티어로 보내면, 절감이 아니라 품질 사고로 돌아옵니다.

작업 유형 분류 자체가 새로운 실패 지점이 됩니다. 분류가 틀리면 라우팅도 틀립니다. 그래서 분류 결과와 실제 품질을 계속 관측하고, 저렴한 티어에서 실패가 누적되는 작업 유형은 상위 티어로 되돌리는 회고 루프가 필요합니다.

비용 수치의 오픈 가중치 단가는 추정치입니다. 관리형 API냐 자체 서빙이냐, 어느 공급자냐에 따라 절대값은 달라집니다. 다만 이 글에서 프런티어 단가는 실제 값이고 실험 품질은 실측이므로, “자릿수가 바뀌는 절감”이라는 결론의 방향은 유지됩니다. 자기 환경의 실제 단가로 같은 계산을 다시 해보시길 권합니다.

마지막으로 지연입니다. 무료 공유 엔드포인트의 15초는 실시간 대화형 UX에는 부담스럽습니다. 배치 파이프라인이나 백그라운드 자동화에는 문제가 없지만, 사용자가 기다리는 경로라면 자체 서빙으로 지연을 잡거나 그 구간만 빠른 티어로 라우팅하는 판단이 필요합니다.

출처

• 실험 코드·결과 로그: 본문의 Gemma 4 tool-call 실험(6/6 성공)은 outputs/blog-impl/open-weight-agent-cost-routing/의 실측 로그 기반입니다.
• 프런티어 단가: Paxis models.yaml (costInput/costOutput, USD per 1M tokens).
• 오픈 가중치 단가: 2026년 중반 관리형 추론 대표 추정치([추정]).

개요

LLM 에이전트를 오래 굴려 본 사람은 같은 벽에 부딪힙니다. 에이전트가 매번 처음부터 추론하고, 지난주에 이미 해결한 절차를 또다시 더듬거립니다. 흔한 대응은 자주 쓰는 스킬을 프롬프트에 통째로 밀어 넣는 것입니다. 하지만 이 방식은 두 가지 이유로 취약합니다. 첫째, 스킬이 늘수록 컨텍스트 창을 잡아먹어 정작 과제에 쓸 여지가 줄어듭니다. 둘째, 프롬프트 템플릿은 상황이 조금만 달라져도 쉽게 깨집니다.

최근 에이전트 메모리 연구는 이 문제를 절차적 메모리(procedural memory) 라는 렌즈로 다시 봅니다. 사람의 절차적 기억이 자전거 타기처럼 의식하지 않아도 실행되는 숙련된 동작을 담듯이, 에이전트의 절차적 메모리는 반복 과제의 실행 절차를 재사용 가능한 형태로 압축합니다. 핵심 흐름은 절차적 지식을 프롬프트 검색을 넘어 별도의 저장·검색·갱신 구조로, 나아가 모델 파라미터 안의 신경 정책으로 옮기는 것입니다.

이 글은 이 전환의 지형을 검증된 논문 중심으로 정리합니다. ThakiCloud의 Agent-Native Cloud인 Paxis가 스킬을 일급 리소스로 다루는 방식이 바로 이 연구 흐름의 실무 구현에 해당하므로, 마지막에 그 연결을 짚습니다.

절차적 메모리란 무엇인가

인지 관점에서 메모리는 흔히 세 가지로 나뉩니다. 사실을 담는 의미 기억(semantic), 사건을 담는 일화 기억(episodic), 그리고 방법을 담는 절차 기억(procedural)입니다. 에이전트 문헌에서 절차적 메모리는 “어떻게 하는가”를 담당합니다. 복잡한 동작 시퀀스를 재사용 가능한 패턴으로 추상화해, 매번 밑바닥부터 계획하지 않고도 실행하게 합니다.

문제는 현재 대부분의 에이전트에서 이 절차적 지식이 세 형태 중 하나로 존재한다는 점입니다. 사람이 손으로 짠 것, 깨지기 쉬운 프롬프트 템플릿에 담긴 것, 아니면 모델 파라미터에 암묵적으로 얽혀 갱신하기 비싼 것입니다. 연구가 겨냥하는 지점은 이 지식을 학습 가능하고 갱신 가능한 일급 대상으로 끌어올리는 것입니다.

flowchart TB
    A[과거 실행 궤적] --> B[절차 추출<br/>빌드 Build]
    B --> C{저장 형태}
    C --> D[비파라메트릭<br/>텍스트 스크립트]
    C --> E[파라메트릭<br/>신경 정책]
    D --> F[검색·선택<br/>Retrieval]
    E --> F
    F --> G[과제 실행]
    G --> H[피드백으로 갱신<br/>추가·수정·삭제 Update]
    H --> B

프롬프트 검색을 넘어서: 저장·검색·갱신의 분리

이 흐름을 정면으로 다룬 대표 연구가 Memp: Exploring Agent Procedural Memory(arXiv 2508.06433)입니다. Memp는 절차적 메모리를 일급 최적화 대상으로 놓고, 과거 궤적을 두 층위로 증류합니다. 하나는 세밀한 단계별 지시이고, 다른 하나는 상위 수준의 스크립트 같은 절차입니다. 그리고 메모리 루프를 빌드(build)·검색(retrieval)·갱신(update) 세 국면으로 분리합니다. 갱신 국면에서는 실행 피드백에 따라 항목을 추가·수정·삭제합니다.

이 분리가 중요한 이유는, 프롬프트에 스킬을 밀어 넣는 방식과 근본적으로 다르기 때문입니다. 프롬프트 방식에서는 저장과 검색이 하나로 뭉개져 있고 갱신이라는 개념 자체가 희박합니다. 반면 세 국면을 분리하면 절차를 언제 어떻게 넣고 뺄지, 실패에서 무엇을 고칠지가 명시적인 설계 대상이 됩니다. 자료에 따르면 이 흐름의 큰 방향은 명시적 비파라메트릭 템플릿에서 암묵적 파라메트릭 신경 정책으로의 이동으로 요약됩니다(Foundation Agents 메모리 서베이, arXiv 2602.06052). 즉 절차를 텍스트로 저장해 검색하는 단계를 넘어, 경험을 모델의 정책 자체에 녹여 넣는 방향입니다.

왜 지금 중요한가: 평가의 어려움

절차적 메모리가 실제로 쓸 만한 스킬을 만들어 내는지는 아직 충분히 이해되지 않았습니다. 이 공백을 겨냥한 연구가 Managing Procedural Memory in LLM Agents(arXiv 2606.23127)입니다. 이 논문은 AFTER라는 벤치마크를 제안합니다. 6개 직무 역할에 걸친 382개의 현실적인 기업 과제와 22개의 절차적 스킬로 구성되어, 스킬이 과제·역할·모델 백본을 가로질러 얼마나 전이되는지를 측정합니다.

이 벤치마크가 던지는 질문이 핵심입니다. 한 상황에서 학습한 절차가 다른 상황에서도 통하는가? 모델을 바꿔도 스킬이 유효한가? 절차적 메모리를 도입하는 순간 우리는 “이 스킬이 실제로 재사용 가능한가”를 측정할 수단이 필요해집니다. 저장·검색·갱신 구조를 갖췄더라도, 전이가 안 되는 스킬은 결국 비싼 프롬프트 템플릿과 다를 바 없기 때문입니다.

ThakiCloud 제품 적용 시사점

이 연구 흐름은 ThakiCloud의 Paxis에서 그대로 실무 형태를 갖춥니다. Paxis는 Agent-Native Cloud로 스킬·도구·정책·감사 로그를 일급 리소스로 다룹니다. 여기서 스킬 하니스는 사실상 프로덕션 절차적 메모리입니다.

• 빌드·검색·갱신의 실무 대응: Paxis의 스킬 하니스는 960개 이상의 스킬을 BM25로 선택(검색)하고, 격리 샌드박스에서 실행하며, 자가진화 루프로 스킬을 개선(갱신)합니다. Memp가 제시한 세 국면 분리가 운영 시스템의 형태로 구현된 셈입니다.
• 프롬프트 검색을 넘어선 구조: 스킬을 매번 프롬프트에 밀어 넣는 대신 검증된 스킬을 선택적으로 불러 쓰므로, 컨텍스트 예산을 아끼면서 절차의 일관성을 유지합니다. 이는 이 글이 다룬 “프롬프트 검색을 넘어서”라는 방향과 정확히 일치합니다.
• 평가와 감사: AFTER 벤치마크가 강조한 “전이 가능성”을 Paxis는 정책 게이트와 감사 로그로 관리합니다. 어떤 스킬이 언제 선택되어 무엇을 했는지가 추적되므로, 재사용 가능한 절차와 그렇지 않은 절차를 데이터로 구분할 근거가 남습니다.

인프라 관점에서는 ai-platform이 이 스킬 실행을 떠받칩니다. Kueue GPU 스케줄링과 멀티테넌트 서빙 위에서 에이전트가 스킬을 실행하므로, 절차적 메모리의 실행 비용이 곧 서빙 효율 문제로 이어집니다. 저비용 서빙(ai-platform)이 에이전트 경제성(Paxis)을 떠받치는 구조입니다.

한계 및 반론

절차적 메모리를 파라메트릭 신경 정책으로 옮기는 방향에는 분명한 대가가 따릅니다. 텍스트 스크립트는 사람이 읽고 고칠 수 있지만, 파라미터에 녹아든 절차는 감사와 갱신이 어렵습니다. 무엇이 저장되었는지 들여다보기 힘들고, 잘못된 절차를 골라내 삭제하기도 까다롭습니다. 규제·소버린 환경처럼 설명 가능성이 중요한 곳에서는 이 불투명성이 곧바로 위험이 됩니다.

또한 비파라메트릭 검색 방식도 만능은 아닙니다. 검색은 여전히 잘못된 절차를 불러올 수 있고, 저장소가 커질수록 선택 품질이 떨어질 수 있습니다. AFTER 같은 벤치마크가 보여주듯 스킬의 전이 가능성은 아직 검증 초기 단계이며, 한 도메인에서 통한 절차가 다른 도메인에서 통한다는 보장은 없습니다. 절차적 메모리는 에이전트를 매번 백지에서 시작하지 않게 하는 유망한 방향이지만, 저장 형태·검색 품질·갱신 안전성·평가 방법이 함께 성숙해야 실무에서 신뢰할 수 있는 자산이 됩니다.

출처

• Memp: Exploring Agent Procedural Memory (arXiv 2508.06433)
• Managing Procedural Memory in LLM Agents: Control, Adaptation, and Evaluation (arXiv 2606.23127)
• Rethinking Memory Mechanisms of Foundation Agents in the Second Half: A Survey (arXiv 2602.06052)

개요

LLM 서빙을 운영하다 보면 이상한 지점에 도달합니다. vLLM을 배포하고, GPU 사용률을 모니터링하고, 배치 크기를 조정하면서도 정작 “왜 이 요청이 KV 캐시를 이만큼 점유하는가”, “GQA가 정확히 무엇을 줄여서 메모리 대역폭을 아끼는가”를 문장으로 설명하지 못하는 순간이 옵니다. 도구는 다룰 줄 알지만 그 아래의 원리는 흐릿한 상태입니다. 이 간극은 최적화를 감에 의존하게 만들고, 장애가 났을 때 원인을 추론하지 못하게 합니다.

이 문제를 정면으로 겨냥한 학습 리소스가 amitshekhariitbhu/llm-internals입니다. 토큰화에서 시작해 어텐션, 트랜스포머 구조, KV 캐시, 그리고 추론 최적화까지 이어지는 순서로 블로그와 영상을 엮은 단계별 학습 리포지토리입니다. 원저자는 Amit Shekhar이며, 흩어진 일회성 튜토리얼 대신 하나의 정돈된 멘탈 모델을 세우도록 주제를 배열했습니다.

ThakiCloud는 K8s 위에서 다양한 고객 환경에 모델을 서빙하는 ai-platform을 운영합니다. 서빙 비용과 지연을 결정하는 요소는 대부분 이 리포지토리가 다루는 내부 구조에서 나옵니다. 그래서 이 글은 단순한 리소스 소개가 아니라, 각 주제가 인프라 엔지니어에게 왜 직접적인 무기가 되는지를 함께 정리합니다.

이 리소스는 무엇인가

llm-internals는 코드를 실행하는 프레임워크가 아니라 학습 경로(learning path) 입니다. LLM이 입력을 받아 다음 토큰을 내놓기까지의 파이프라인을 따라가면서, 각 단계에 필요한 개념을 외부 자료와 함께 순서대로 제시합니다. 핵심은 “무엇을 어떤 순서로 이해해야 전체 그림이 맞춰지는가”라는 커리큘럼 설계에 있습니다.

리포지토리가 다루는 주요 주제는 다음과 같은 흐름을 따릅니다.

flowchart TB
    A[입력 텍스트] --> B[토큰화<br/>BPE Byte Pair Encoding]
    B --> C[임베딩<br/>토큰을 벡터로]
    C --> D[어텐션<br/>Query Key Value]
    D --> E[트랜스포머 블록<br/>어텐션 + FFN 반복]
    E --> F[KV 캐시<br/>생성 속도 가속]
    E --> G[MoE<br/>전문가 라우팅]
    D --> H[GQA<br/>KV 헤드 공유]
    F --> I[추론 최적화<br/>서빙 효율]
    G --> I
    H --> I

이 순서가 중요한 이유는, 뒤쪽 주제가 앞쪽 주제 없이는 이해되지 않기 때문입니다. KV 캐시는 어텐션의 Key/Value가 무엇인지 알아야 의미가 통하고, GQA는 멀티헤드 어텐션의 헤드 구조를 알아야 “무엇을 공유하는지” 보입니다. 리포지토리의 가치는 자료 하나하나의 깊이보다 이 의존 관계를 무너뜨리지 않는 배열에 있습니다.

핵심 주제 톺아보기

토큰화: 모든 것의 출발점

LLM은 글자나 단어를 직접 다루지 않고 토큰 단위로 처리합니다. 현대 모델 대부분은 BPE(Byte Pair Encoding) 계열을 씁니다. 자주 함께 등장하는 바이트 쌍을 반복적으로 병합해 어휘를 구성하는 방식입니다. 토큰화는 사소해 보이지만 서빙 관점에서 직접적인 비용 요소입니다. 같은 문장이라도 언어와 토크나이저에 따라 토큰 수가 크게 달라지고, 토큰 수는 곧 KV 캐시 점유량과 연산량으로 이어집니다. 한국어·아랍어 같은 비영어 텍스트가 영어보다 토큰을 더 많이 소모하는 현상은 서빙 비용 산정에서 반드시 고려해야 하는 지점입니다.

어텐션: Query, Key, Value

트랜스포머의 심장은 셀프 어텐션입니다. 각 토큰은 세 벡터로 투영됩니다. Query는 “내가 무엇을 찾는가”, Key는 “나는 무엇을 제공하는가”, Value는 “실제로 전달할 내용”에 해당합니다. 어텐션 점수는 Query와 Key의 내적으로 계산되고, 스케일링과 소프트맥스를 거쳐 Value의 가중합을 만듭니다.

Attention(Q, K, V) = softmax( (Q · Kᵀ) / √d_k ) · V

이 수식 자체는 단순하지만, 시퀀스 길이 n에 대해 어텐션 연산이 O(n²)로 커진다는 사실이 이후의 모든 최적화를 낳습니다. 긴 컨텍스트가 왜 비싼지, 왜 서빙 인프라가 컨텍스트 길이에 민감한지가 여기서 출발합니다.

트랜스포머 블록과 KV 캐시

트랜스포머는 어텐션과 피드포워드 네트워크(FFN)를 묶은 블록을 여러 층 쌓은 구조입니다. 자기회귀 생성에서는 토큰을 하나씩 만들어 내는데, 매 스텝마다 이전 토큰들의 Key와 Value를 다시 계산하면 낭비가 큽니다. KV 캐시는 이미 계산한 Key/Value를 저장해 두고 재사용함으로써 생성 속도를 끌어올립니다.

문제는 이 캐시가 메모리를 먹는다는 점입니다. 캐시 크기는 대략 2 × 층 수 × KV 헤드 수 × 헤드 차원 × 시퀀스 길이 × 배치 크기에 비례합니다. 긴 컨텍스트와 많은 동시 요청은 이 값을 폭발적으로 키웁니다. vLLM의 PagedAttention이 KV 캐시를 페이지 단위로 관리해 단편화를 줄이는 이유가 바로 이 구조적 압박 때문입니다.

MoE와 GQA: 효율을 위한 구조 변화

Mixture of Experts(MoE) 는 FFN을 여러 개의 전문가(expert)로 나누고, 라우터가 토큰마다 일부 전문가만 활성화합니다. 파라미터 총량은 크지만 토큰당 실제 연산량은 작아지는 구조입니다. 대신 서빙에서는 전문가 병렬화, 라우팅 불균형, 메모리 배치라는 새로운 과제를 안깁니다.

Grouped-Query Attention(GQA) 는 멀티헤드 어텐션(MHA)과 멀티쿼리 어텐션(MQA)의 절충안입니다. MHA는 모든 헤드가 각자의 Key/Value를 가지고, MQA는 모든 헤드가 하나의 Key/Value를 공유합니다. GQA는 헤드를 몇 개의 그룹으로 묶어 그룹 단위로 KV를 공유합니다. 결과적으로 KV 캐시 크기와 메모리 대역폭이 줄어들면서 품질 손실은 최소화됩니다. GQA를 이해하면 왜 최신 오픈웨이트 모델이 이 구조를 채택하는지, 그리고 서빙 시 메모리 예산이 왜 달라지는지가 선명해집니다.

왜 인프라 엔지니어에게 이 지식이 중요한가

위 주제들은 학문적 호기심의 대상이 아니라 서빙 비용의 직접 원인입니다. KV 캐시 크기 공식을 이해하면 동시 요청 수와 컨텍스트 길이가 GPU 메모리에 어떻게 부딪히는지 예측할 수 있습니다. GQA를 이해하면 같은 GPU에서 왜 어떤 모델은 더 많은 요청을 처리하는지 설명할 수 있습니다. MoE를 이해하면 전문가 병렬 배치가 왜 스케줄링을 복잡하게 만드는지 대비할 수 있습니다.

반대로 이 지식이 없으면, 장애 상황에서 “메모리가 부족합니다”라는 증상만 보고 배치 크기를 무작정 줄이거나 GPU를 늘리는 값비싼 대응만 반복하게 됩니다. 내부 구조를 아는 엔지니어는 KV 캐시 페이징, 컨텍스트 길이 상한, 양자화, GQA 모델 선택이라는 더 정밀한 레버를 손에 쥡니다.

ThakiCloud 제품 적용 시사점

ThakiCloud의 ai-platform은 Kubernetes와 Kueue GPU 스케줄링 위에서 vLLM 기반 추론을 멀티테넌트로 제공합니다. 이 글에서 정리한 내부 구조는 그대로 운영 레버로 이어집니다.

• KV 캐시: PagedAttention과 KV 캐시 크기 공식을 근거로, 테넌트별 컨텍스트 길이 상한과 동시성 예산을 설정합니다. 캐시 점유를 예측하면 GPU 메모리 오버커밋 없이 처리량을 끌어올릴 수 있습니다.
• GQA·양자화: 같은 하드웨어에서 더 많은 요청을 담기 위해 GQA를 채택한 오픈웨이트 모델을 우선 후보로 검토하고, 양자화와 결합해 온프레미스·소버린 환경의 낮은 서빙 비용을 목표로 합니다.
• MoE 서빙: 전문가 병렬화가 필요한 MoE 모델은 Kueue 큐 설계와 노드 배치에서 별도 취급이 필요하다는 점을 사전에 반영합니다.

에이전트 관점에서는, ThakiCloud의 Agent-Native Cloud인 Paxis가 이런 내부 지식을 팀 자산으로 축적하는 데 유리합니다. Paxis는 스킬을 일급 리소스로 다루므로, “KV 캐시 예산 계산” 같은 반복 판단을 검증된 스킬로 굳혀 격리 샌드박스에서 재사용하고 감사 로그로 추적할 수 있습니다. 개별 엔지니어의 암묵지가 되기 쉬운 서빙 노하우를 조직의 절차적 지식으로 전환하는 통로가 됩니다.

한계 및 반론

이 리소스의 가장 큰 약점은 큐레이션 리포지토리의 숙명입니다. 외부 블로그와 영상을 엮는 구조이므로 링크가 낡거나 사라질 수 있고, 자료 간 표기·깊이의 편차도 존재합니다. 최신 아키텍처 변화(예: 새로운 어텐션 변형)가 즉시 반영된다는 보장도 없습니다.

또한 개념 이해와 실전 운영 사이에는 여전히 간극이 있습니다. KV 캐시 공식을 외운다고 해서 특정 GPU에서의 실제 처리량이 곧바로 나오지는 않습니다. 실측 벤치마크, 프로파일링, 워크로드별 튜닝은 별도의 실전 경험을 요구합니다. 이 학습 경로는 정확한 멘탈 모델을 세우는 출발점으로 가치가 크지만, 그 자체로 서빙 최적화의 종착점은 아닙니다. 원리를 이해한 뒤 실제 트래픽 위에서 검증하는 단계가 반드시 뒤따라야 합니다.

출처

• amitshekhariitbhu/llm-internals (GitHub)
• 원 추천 트윗: Dan Kornas, “Stop learning LLM internals from random one-off tutorials”

원 뉴스: RT @DeRonin_: My entire AI stack is now Chinese 🇨🇳 · twitter

ThakiCloud 제품 적용 시사점

저희가 굳이 이 만화를 그린 이유는 ‘싸다’와 ‘내 것이다’가 자주 헷갈리기 때문입니다. 타키클라우드는 두 가지를 한 판에서 풉니다. 파시스가 작업별로 알맞은 모델에 일을 나눠 주는 라우팅을 온프렘 위에서 돌리고, 메티스가 그 모델을 직접 학습하고 추론까지 맡습니다. 트윗 속 절감 방식을 흉내 내되, 남의 API가 아니라 내 시설에서 돌린다는 점이 다릅니다. 비용은 내리고 열쇠는 내가 쥡니다. 그게 바꿔 낀 셋방이 아니라 진짜 내 스택입니다.

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