نظرة عامة

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

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

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

ما هي Artifacts في Claude Code

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

المصادر

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

Overview

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

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

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

What Claude Code Artifacts Are

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

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

The flow from work to publication looks like this.

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

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

Why the Pro and Max Expansion Matters

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

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

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

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

How It Works in Practice

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

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

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

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

What It Means for ThakiCloud

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

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

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

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

Limitations and Counterpoints

There are clear points where expectations should be tempered.

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

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

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

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

Sources

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

개요

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

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

왜 이 실험을 했나

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

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

실험 환경

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

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

측정 방법

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

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

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

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

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

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

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

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

결과: Qwen3.6-27B-NVFP4

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

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

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

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

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

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

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

분리가 이기는 조건

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

DP/TP가 나은 조건

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

판정을 가르는 네 변수

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

근거 요약

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

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

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

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

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

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

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

ThakiCloud 관점에서

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

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

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

결론과 한계

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

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

참고 자료

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

개요

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

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

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

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

Claude Code 아티팩트란 무엇인가

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

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

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

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

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

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

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

Pro·Max 확대가 의미하는 것

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

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

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

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

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

실제 사용 흐름

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

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

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

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

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

ThakiCloud 제품 적용 시사점

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

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

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

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

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

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

한계 및 반론

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

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

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

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

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

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

출처

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

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

المصدر: RT @DeRonin_: My entire AI stack is now Chinese 🇨🇳 · twitter

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

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

هذا الكوميك مسودة مُولّدة تلقائياً استناداً إلى أخبار الصناعة لهذا الأسبوع.

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

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

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

ما الذي تغيّر

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

flowchart TB
    A["Fable 5<br/>استقلالية عالية"] --> B["1. التخفيف<br/>إزالة التعليمات الزائدة"]
    A --> C["2. مراجعة عبر نتائج الأدوات<br/>ممنوع التقرير الذاتي"]
    A --> D["3. الاعتماد على الوكلاء الفرعيين<br/>تفويض غير متزامن"]
    A --> E["4. التعلم من التشغيلات السابقة<br/>تسجيل الدروس"]
    A --> F["5. تحديد القيود<br/>ما يجب وما لا يجب فعله"]
    B --> G["توجيهات تحدد الاتجاه<br/>وتترك الحكم للنموذج"]
    C --> G
    D --> G
    E --> G
    F --> G

المبدأ الأول: خفّف التعليمات

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

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

المبدأ الثاني: راجع التقدم عبر نتائج الأدوات

خلال التشغيلات الطويلة المستقلة، ينبغي توجيه Fable 5 لمراجعة تقدمه بنفسه بالاستناد إلى نتائج الأدوات الفعلية. التوجيه المثال الذي يقدمه الدليل هو التالي.

Before reporting progress, audit each claim against a tool result
from this session. Only report work you can point to evidence for.

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

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

المبدأ الثالث: اعتمد بثقة على الوكلاء الفرعيين

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

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

المبدأ الرابع: تعلّم من التشغيلات السابقة

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

Store one lesson per file with a one-line summary at the top.
Record corrections and confirmed approaches alike, including why
they mattered.

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

المبدأ الخامس: حدّد القيود بوضوح

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

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

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

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

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

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

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

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

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

المصادر

• Prompting Claude Fable 5، الوثائق الرسمية لشركة Anthropic (platform.claude.com)
• Redeploying Claude Fable 5، أخبار Anthropic

إذا أمكنك خدمة نموذج من فئة 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)