حين يفتح معظم الفرق فاتورة تشغيل وكلائهم، يقعون في الوهم ذاته: “وكلاؤنا يجرون استدلالاً معقداً، إذاً لا بد من استخدام أفضل النماذج في قمة الهرم.” غير أن فحص حركة البيانات الفعلية يكشف صورة مختلفة تماماً. الغالبية العظمى من الطلبات تتمحور حول تحويل اللغة الطبيعية إلى استدعاءات 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 [تقديري].

إذا أمكنك خدمة نموذج من فئة 27B على GPU واحدة وبدقة شبه خالية من الخسارة، يتغير اقتصاد الاستدلال في البيئات المحلية. تعيد نقطة التحقق nvidia/Qwen3.6-27B-NVFP4 تكميم Qwen3.6-27B إلى نوع بيانات NVFP4 ليعمل على vLLM حديث دون أي إعداد إضافي. هذه هي خلفية إعلان مشروع vLLM أن نقطة التحقق هذه جاهزة للاستدلال على وحدات Blackwell.

الجوهر ليس مجرد “التخفيض إلى 4 بت” بل ما الذي خُفّض وما الذي بقي. يشرّح هذا المقال تصميم الدقة المختلطة في إعادة تكميم NVFP4، ويعرض كيفية خدمته فعليًا عبر vLLM، ثم يستعرض ماذا يعني ذلك لبنية تكلفة خدمة GPU متعددة المستأجرين في ThakiCloud ai-platform. وحيثما يلزم القياس، نُشير إليه بصدق.

ما هذا

NVFP4 صيغة عائمة بأربع بتات تخفض عدد البتات لكل معامِل من 16 إلى 4، فتقلّص متطلبات القرص وذاكرة GPU بنحو 2.5 مرة. لكن التصميم الفعلي لـ nvidia/Qwen3.6-27B-NVFP4 لا يسحق كل شيء إلى 4 بت. فإعادة تكميم NVIDIA ModelOpt تخفض طبقات MLP الخطية فقط إلى NVFP4 (W4A16)، مع إبقاء طبقات الانتباه الخطية وذاكرة KV بصيغة FP8. ونتيجة لذلك تتّسع نحو 22GB من الأوزان على GPU واحدة من Blackwell. وتُبلّغ NVIDIA بأن هذا التكوين شبه خالٍ من الخسارة في الدقة مقارنةً بخط أساس FP8.

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

flowchart TB
    A[أوزان Qwen3.6-27B الأصلية FP16] --> B[إعادة تكميم NVIDIA ModelOpt]
    B --> C[طبقات MLP الخطية<br/>NVFP4 W4A16]
    B --> D[طبقات الانتباه الخطية<br/>تبقى FP8]
    B --> E[ذاكرة KV<br/>تبقى FP8]
    C --> F[نحو 22GB من الأوزان]
    D --> F
    E --> F
    F --> G[تُحمَّل على GPU واحدة من Blackwell]
    G --> H[vLLM يكتشف تلقائيًا<br/>quantization modelopt]
    H --> I[نقطة استدلال متوافقة مع OpenAI]

مقارنةً بتكميم موحّد إلى 4 بت (مثل W4 عبر كل الطبقات)، يلتقط هذا النهج معظم وفر الذاكرة مع الدفاع عن الجودة بإبقاء الطبقات الحساسة بصيغة FP8. وضبط مقايضة الوفر مقابل الدقة لكل طبقة هو الميزة الفارقة لإعادة تكميم NVFP4.

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

يكتشف vLLM تكميم ModelOpt تلقائيًّا من نقطة التحقق، فلا حاجة صارمة لتمرير راية تكميم. لكنك تحتاج vLLM حديثًا يدعم NVFP4/W4A16، وتوصي NVIDIA بإصدار nightly أو بناء من المصدر يتضمن دعم ModelOpt. شغّل صورة nightly عبر Docker وقدّم الخدمة كالتالي.

# vLLM حديث بدعم NVFP4/ModelOpt (صورة nightly)
docker run --gpus all -p 8000:8000 \
  vllm/vllm-openai:nightly \
  vllm serve nvidia/Qwen3.6-27B-NVFP4 \
    --port 8000 \
    --quantization modelopt \
    --max-model-len 262144 \
    --reasoning-parser qwen3

تستخدم --max-model-len 262144 السياق الطويل لعائلة Qwen3.6 كما هو، وتتولى --reasoning-parser qwen3 تحليل رموز الاستدلال. والنقطة متوافقة مع OpenAI، فتتصل بها العملاء القائمة دون تغيير.

نتائج التجربة

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

• تُبلّغ NVIDIA بأن تكوين NVFP4 المُعاد تكميمه شبه خالٍ من الخسارة في الدقة مقارنةً بخط أساس FP8 (بحسب بطاقة النموذج).
• حجم الأوزان نحو 22GB، يتّسع على GPU واحدة من Blackwell (بحسب بطاقة النموذج).
• يُبلّغ أحد المعايير الخارجية (loFT LLC) بنحو 190 tok/s من إنتاجية التوليد بتكوين NVFP4+MTP على RTX PRO 6000 Blackwell Max-Q مزدوجة. وهذا قياس خارجي بدرجة [تقديري]، لا قيمة بيئتنا.

ما أمكننا التحقق منه هو حقائق مسار الخدمة. فكون vLLM يكتشف تكميم ModelOpt تلقائيًّا، وأن التكوين مختلط الدقة (MLP بصيغة NVFP4 والانتباه وKV بصيغة FP8)، وأن نحو 22GB من الأوزان تتّسع على GPU واحدة من Blackwell، كلها مؤكدة في بطاقة النموذج العامة ووصفة vLLM. أما الإنتاجية والكمون الفعليان فيبقيان مسألة تُقاس حين يتوفر العتاد.

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

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

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

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

الحدود والاعتراضات

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

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

ثالثًا، رقم الإنتاجية في هذا المقال ليس قياسنا. فالمعايير الخارجية تعتمد بشدة على تكوين العتاد (RTX PRO 6000 مزدوجة، واستخدام MTP من عدمه) وعلى حجم الدفعة وطول السياق، لذا تبقى قيمة عنقودنا الفعلية غير محددة حتى نقيسها مباشرةً. وتبلغ خلاصة هذا المقال فقط “الخدمة على GPU واحدة بصيغة NVFP4 تملك إمكان تحويل اقتصاد الخدمة”؛ أما “كم tok/s في بيئتنا” فمسألة تُقال بعد تحقق منفصل.

المصادر

• nvidia/Qwen3.6-27B-NVFP4 بطاقة النموذج، Hugging Face (https://huggingface.co/nvidia/Qwen3.6-27B-NVFP4)
• Qwen/Qwen3.6-27B، vLLM Recipes (https://recipes.vllm.ai/Qwen/Qwen3.6-27B)
• Measuring Qwen3.6-27B NVFP4+MTP on vLLM، loFT LLC (https://loftllc.dev/en/docs/tech/llm-research/qwen3-6-27b-nvfp4-mtp-vllm-benchmark/)

من يُشغّل عملاء 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)

يبدو أن منح الوكيل مزيدًا من المهارات ينبغي أن يجعله أكثر كفاءة، لكن الأبحاث الحديثة تُبلّغ بالعكس. فكلما كبرت مكتبة المهارات، قد ينخفض فعليًا معدل نجاح الوكيل في المهام نفسها. تواجه الورقة arXiv 2605.24050 بعنوان “More Skills, Worse Agents?” هذه المفارقة مباشرة، وتُبلّغ بأن معدل اجتياز المهام يتراجع بنسبة تصل إلى 21% عند التوسع من مجموعة صغيرة من المهارات المفيدة إلى مكتبة من 202 مهارة.

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

ما هو تظليل المهارات

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

المساهمة الجوهرية في arXiv 2605.24050 هي تفكيك تراجع الأداء إلى أثرين. الأول هو تظليل المهارات (skill shadowing): مع كبر المكتبة تتصادم المهارات المتشابهة في وصفها فيختار الوكيل المهارة الخاطئة أكثر. والثاني هو عبء السياق (context overhead): تملأ أوصاف المهارات السياق فتتدهور جودة التنفيذ حتى حين يكون الاختيار صحيحًا.

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

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

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

لماذا يهم هذا الآن

مشكلة الحجم لا تقتصر على ورقة واحدة. فمعيار SkillRet (arXiv 2605.05726) الصادر في الفترة نفسها يجمع 17,810 مهارة وكيل عامة في معيار استرجاع واسع النطاق منظَّم ضمن تصنيف من مستويين يضم 6 فئات رئيسية و18 فئة فرعية. صارت المهارات تتراكم بمقياس عشرات الآلاف، وأصبح استرجاع المهارة الصحيحة من هذا المجمع مسألة بحثية قائمة بذاتها.

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

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

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

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

تُظهر قياسات Skill Harness الفعلية أن التصميم يعمل. ففي معيارنا الداخلي SRA (63 حالة) بلغ Recall@5 نسبة 82.2%، وبلغت الدقة المُبوَّبة مع تطبيق بوابة الامتناع 66.7%، وبلغ Top-1 نسبة 40.0%، وكانت الهلوسة (اختلاق مهارة غير موجودة للمطابقة) 0%. وتحديدًا فإن الهلوسة 0% أثر مباشر لبوابة الامتناع: فمهما كبرت المكتبة، لا تختلق مهارة غائبة ولا تفرض مطابقة دون العتبة.

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

الحدود والاعتراضات

للبحث ولتصميمنا حدود واضحة. أولًا، نسبة التراجع 21% في arXiv 2605.24050 قيمة ضمن إعداد محدد (مكتبة من 202 مهارة) وتتباين كثيرًا بحسب جودة أوصاف المهارات وتداخلها ومجال المهمة. فإذا وُصفت المهارات جيدًا وحُفظت من التداخل، تقلّ نسبة التراجع عند المقياس نفسه. الدرس الدقيق ليس “لا تُضِف مهارات” بل “أدِر جودة الوصف والاسترجاع معًا”.

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

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

المصادر

• More Skills, Worse Agents? Skill Shadowing Degrades Performance When Expanding Skill Libraries, arXiv 2605.24050 (https://arxiv.org/abs/2605.24050)
• SkillRet: A Large-Scale Benchmark for Skill Retrieval in LLM Agents, arXiv 2605.05726 (https://arxiv.org/abs/2605.05726)

عندما تشغّل خدمة 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].

If you can serve a 27B-class model on a single GPU with near-lossless accuracy, the economics of on-premises inference change. The nvidia/Qwen3.6-27B-NVFP4 checkpoint re-quantizes Qwen3.6-27B into the NVFP4 data type so it runs on a recent vLLM with no extra configuration. That is the backdrop to the vLLM project announcing this checkpoint is inference-ready on Blackwell GPUs.

The point is not simply “reduced to 4-bit” but what was reduced and what was kept. This post dissects the mixed-precision design of the NVFP4 re-quantization, lays out how to actually serve it with vLLM, and then works through what this means for the multi-tenant GPU serving cost structure of ThakiCloud ai-platform. Where measurement is required, we mark it honestly.

What This Is

NVFP4 is a 4-bit floating-point format that drops bits-per-parameter from 16 to 4, cutting disk and GPU memory requirements by roughly 2.5x. But the actual design of nvidia/Qwen3.6-27B-NVFP4 does not flatten everything to 4-bit. NVIDIA ModelOpt’s re-quantization lowers only the MLP linear layers to NVFP4 (W4A16), while keeping the attention linear layers and the KV cache in FP8. As a result, about 22GB of weights fit on a single Blackwell GPU. NVIDIA reports this configuration is near-lossless in accuracy versus the FP8 baseline.

There is a reason for this mixed-precision choice. The MLP layers hold an overwhelming share of the parameters, so their memory savings are large and they tolerate 4-bit relatively well. Attention and the KV cache, by contrast, are sensitive to quality over long contexts, so they stay in FP8 to preserve accuracy. The principle: “cut the heaviest part most aggressively, and keep the most sensitive part conservatively.”

flowchart TB
    A[Qwen3.6-27B original FP16 weights] --> B[NVIDIA ModelOpt re-quantization]
    B --> C[MLP linear layers<br/>NVFP4 W4A16]
    B --> D[Attention linear layers<br/>kept in FP8]
    B --> E[KV cache<br/>kept in FP8]
    C --> F[About 22GB weights]
    D --> F
    E --> F
    F --> G[Loads on a single Blackwell GPU]
    G --> H[vLLM auto-detects<br/>quantization modelopt]
    H --> I[OpenAI-compatible inference endpoint]

Compared to a uniform 4-bit quantization (for example, W4 across all layers), this approach captures most of the memory savings while defending quality by keeping sensitive layers in FP8. Setting the savings-vs-accuracy trade-off per layer is the key differentiator of NVFP4 re-quantization.

Installation and Serving

vLLM auto-detects the ModelOpt quantization from the checkpoint, so you do not strictly need to pass a quantization flag. You do need a recent vLLM with NVFP4/W4A16 support, and NVIDIA recommends nightly or a source build that includes ModelOpt support. Bring up the nightly image with Docker and serve as follows.

# Recent vLLM with NVFP4/ModelOpt support (nightly image)
docker run --gpus all -p 8000:8000 \
  vllm/vllm-openai:nightly \
  vllm serve nvidia/Qwen3.6-27B-NVFP4 \
    --port 8000 \
    --quantization modelopt \
    --max-model-len 262144 \
    --reasoning-parser qwen3

--max-model-len 262144 uses the long context of the Qwen3.6 family as-is, and --reasoning-parser qwen3 handles reasoning-token parsing. The endpoint is OpenAI-compatible, so existing clients attach without change.

Experiment Results

To be candid: this checkpoint assumes a Blackwell-class GPU, and the environment where this post was written has no such hardware, so we could not reproduce it locally. The numbers below are therefore not our measurements but figures reported by public sources, cited as-is with attribution.

• NVIDIA reports the NVFP4 re-quantized configuration is near-lossless in accuracy versus the FP8 baseline (per the model card).
• The weight size is about 22GB, fitting on a single Blackwell GPU (per the model card).
• One third-party benchmark (loFT LLC) reports around 190 tok/s of generation throughput with an NVFP4+MTP configuration on dual RTX PRO 6000 Blackwell Max-Q. This is an [estimate]-grade external measurement, not our environment’s value.

What we could verify are the facts of the serving path. That vLLM auto-detects ModelOpt quantization, that the configuration is mixed-precision (MLP in NVFP4, attention and KV in FP8), and that ~22GB of weights fit on a single Blackwell are all confirmed in the public model card and the vLLM recipe. Actual throughput and latency remain something to measure once the hardware is in hand.

Implications for ThakiCloud Products

What makes this checkpoint interesting is less the benchmark numbers themselves and more the shift in serving economics. ThakiCloud ai-platform serves models across diverse customer environments on K8s and Kueue, and the GPU is always the most expensive resource. If a 27B-class model can fit on a single GPU, near-losslessly at that, you lower per-tenant GPU occupancy and can host more models, or more tenants, on the same hardware.

From a multi-tenant view, this saving compounds. When a model drops from 2 GPUs to 1, the cluster’s concurrent serving slots nearly double. Under Kueue-based GPU allocation, that translates directly into shorter wait queues and easier fair sharing across tenants. It matters especially for customers with strong on-premises and sovereign requirements, because the sheer number of GPUs to procure falls, lowering the barrier of upfront investment and operating cost.

The mixed-precision design also aligns with our operating philosophy. Rather than lowering precision indiscriminately, the approach of keeping the quality-sensitive parts and aggressively cutting only the heavy parts fits the goal of “cost efficiency and quality at once.” It is why, when adopting a new quantized checkpoint on ai-platform, we review not just the benchmark score but which layers were treated at which precision. NVFP4 re-quantization is a good reference case for that review, and once we secure measured throughput we plan a follow-up post on its cost-quality profile in our serving stack.

Limitations and Counterpoints

First, the hardware dependency is stark. NVFP4’s benefit is maximized on Blackwell-generation GPUs, and earlier generations should not expect the same efficiency. The appeal of single-GPU serving holds only on the premise that Blackwell was secured. In an environment where GPU procurement itself is the bottleneck, “a single GPU is enough” does not immediately convert into cost savings.

Second, near-lossless is a story about benchmark averages. In specific domains, long contexts, or precision-sensitive tasks like numerics and code, a subtle quality drop versus the FP8 baseline may surface. An NVFP4 adoption decision should be confirmed by evaluation on the actual workload you will serve, not by the model card’s summary figures.

Third, the throughput number in this post is not our measurement. Third-party benchmarks depend heavily on hardware configuration (dual RTX PRO 6000, whether MTP is used) and on batch and context length, so our cluster’s actual value is undetermined until we measure it directly. This post’s conclusion reaches only “NVFP4 single-GPU serving has the potential to shift serving economics”; “how many tok/s in our environment” is a matter to state after separate verification.

Sources

• nvidia/Qwen3.6-27B-NVFP4 model card, Hugging Face (https://huggingface.co/nvidia/Qwen3.6-27B-NVFP4)
• Qwen/Qwen3.6-27B, vLLM Recipes (https://recipes.vllm.ai/Qwen/Qwen3.6-27B)
• Measuring Qwen3.6-27B NVFP4+MTP on vLLM, loFT LLC (https://loftllc.dev/en/docs/tech/llm-research/qwen3-6-27b-nvfp4-mtp-vllm-benchmark/)

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)

Handing an agent more skills feels like it should make it more capable, but recent research reports the opposite. As a skill library grows, an agent’s success rate on the same tasks can actually fall. arXiv 2605.24050, “More Skills, Worse Agents? Skill Shadowing Degrades Performance When Expanding Skill Libraries,” confronts this paradox head-on and reports that task pass rate drops by up to 21% when scaling from a small set of helpful skills to a 202-skill library.

This is an operational reality, not an academic curiosity. ThakiCloud’s Agent-Native Cloud, Paxis, already manages over 960 skills and must decide, on every request, which of them to load. Adding skills is easy; picking the right one from a swollen library gets steadily harder. This post uses skill shadowing as a lens to name that bottleneck, then shows how the Paxis skill harness blocks it in practice with retrieval and an abstain gate, backed by real measurements.

What Is Skill Shadowing

A skill library lets an LLM agent load task-specific instructions on demand. The goal is to let a non-expert user solve domain tasks in natural language without knowing which skills exist or how they work internally. The trouble begins as the library grows.

The core contribution of arXiv 2605.24050 is to decompose the performance drop into two effects. The first is skill shadowing: as the library grows, similarly described skills collide and the agent picks the wrong skill more often. The second is context overhead: skill descriptions fill the context and degrade execution quality even when the selection was correct.

The paper’s conclusion cuts against intuition. The primary culprit is not the bloated context but the wrong skill selection itself. In other words, the bottleneck is not “the model has to read too much text” but “the model cannot pick the right skill among lookalike descriptions.” That diagnosis changes the response. Compressing context is not enough; you need a retrieval step that narrows candidates and selects precisely in the first place.

flowchart TB
    A[User request] --> B{Skill library size}
    B -->|A few useful skills| C[Relevant skill selected correctly]
    B -->|Scaled to hundreds| D[Similar skill descriptions collide]
    D --> E[Skill shadowing<br/>more wrong-skill selections]
    D --> F[Context overhead<br/>execution degrades even when correct]
    E --> G[Task pass rate falls up to 21 percent]
    F --> G
    C --> H[Retrieval narrows candidates first]
    G -.diagnosis.-> H
    H --> I[Abstain gate rejects low-score skills]
    I --> J[Execute in isolated sandbox]

This flow overlaps precisely with a problem we already faced. Stuffing the full skill list into the prompt breaks the moment the count passes a few hundred. Instead of endlessly growing the library, you must switch to retrieving only the top candidates per request.

Why This Matters Now

The scale problem is not confined to one paper. The SkillRet benchmark (arXiv 2605.05726), released around the same time, assembles 17,810 public agent skills into a large-scale retrieval benchmark organized under a two-level taxonomy of 6 major and 18 sub-categories. Skills are now accumulating at the scale of tens of thousands, and retrieving the right one from that pool has become a research problem in its own right.

In short, a gap is opening between the pace at which communities add skills and the ability to select them accurately. The shadowing work shows quantitatively that this gap turns into real performance loss, while benchmarks like SkillRet supply a common yardstick to measure it. Both point to a single practical prescription: treat retrieval and selection as first-class problems, separate from growing the library.

Implications for ThakiCloud Products

This research direction maps exactly onto a design the Paxis skill harness already implements. Paxis is ThakiCloud’s Agent-Native Cloud and treats skills as first-class resources. Rather than pushing the entire skill list on every request, it narrows candidates to the top matches with BM25 lexical retrieval and loads only those. That is the first line of defense against skill shadowing. When the candidate set shrinks from hundreds to a few, the room for lookalike descriptions to collide shrinks with it.

The second line of defense is the abstain gate. When the top retrieval score falls below a threshold, no skill is forced; the request falls through to native handling. If the essence of skill shadowing is “picking a plausible wrong skill when unsure,” the abstain gate is the mechanism that deterministically blocks that unsure match in code. Rather than trusting the model to judge “this is ambiguous,” a score threshold owns the decision.

Our skill-retrieval harness’s actual measurements show the design works. On our internal SRA bench (63 cases), Recall@5 was 82.2%, the gated accuracy with the abstain gate applied was 66.7%, Top-1 was 40.0%, and hallucination (inventing a nonexistent skill to match) was 0%. The 0% hallucination in particular is a direct effect of the abstain gate: no matter how large the library grows, it neither fabricates a missing skill nor forces a below-threshold match.

On top of this sit Paxis’s isolated sandbox execution, policy gates, and audit logs. Even if a wrong skill is occasionally selected, its execution happens in an isolated environment and every action is recorded in the audit log. Even when skill shadowing does not vanish entirely, its blast radius is contained at the execution boundary. The bottleneck the research diagnoses (selection failure) and its downstream risk (wrong execution) are blocked in three layers: retrieval, gate, and isolation.

Limitations and Counterpoints

Both the research and our design have clear limits. First, the 21% drop in arXiv 2605.24050 is a value under a specific setup (a 202-skill library) and varies greatly with the quality and overlap of skill descriptions and the task domain. Describe skills well and keep them from overlapping, and the drop shrinks at the same scale. The precise lesson is not “do not add skills” but “manage description quality and retrieval together.”

Second, BM25 lexical retrieval is not a panacea. For queries in pure Korean terminology that lack English expansion vocabulary, it can fail to surface the right skill, and our bench’s Top-1 of 40.0% leaves plenty of room to improve. Reinforcements like embedding ensembles are on the table, but whether they justify giving up the determinism and low cost of a single signal is a separate call. Before making retrieval heavier, improving the skill descriptions themselves usually yields the larger gain.

Third, the abstain gate reduces to a threshold-tuning problem. Too high, and it excludes useful skills, hurting coverage; too low, and it fails to block shadowing. The 0% hallucination result is a product of a conservatively set threshold, and it comes at the cost of missing some legitimate matches. Ultimately, running a skill library is not a question of “how much to grow it” but of “how to balance retrieval, gate, and description quality,” and the shadowing work is a quantitative warning that this balance starts to wobble at a smaller scale than you would expect.

Sources

• More Skills, Worse Agents? Skill Shadowing Degrades Performance When Expanding Skill Libraries, arXiv 2605.24050 (https://arxiv.org/abs/2605.24050)
• SkillRet: A Large-Scale Benchmark for Skill Retrieval in LLM Agents, arXiv 2605.05726 (https://arxiv.org/abs/2605.05726)

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”