نظرة عامة

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

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

ما هذه التقنية

هيكل حلقة ReAct بسيط. تنظر السياسة إلى الحالة الراهنة وتقرر ما ستفعله بعد ذلك. إن طالبت باستدعاء أداة، تعمل الأداة وتنتج ملاحظة. وإن طالبت بالانتهاء، تُعاد الإجابة. في الوكيل الحقيقي تكون السياسة نموذج لغة كبير LLM، لكن بنية التحكم في الحلقة ذاتها مستقلة عن النموذج. لهذا استُعيض في هذه التجربة عن السياسة بمحاكٍ يعمل بقواعد ثابتة - لمراقبة مستوى التحكم في الحلقة لا جودة النموذج - مما يجعل النتائج قابلة للتكرار الكامل.

تُضيف ضوابط الحماية ثلاثة شروط إيقاف إلى هذه الحلقة. حد الخطوات (max_steps) يُجبر الحلقة على التوقف بعد عدد محدد من التكرارات. ميزانية الوقت (wall_budget) تقيّد وقت الساعة الجدارية لكل مهمة. كشف التكرار (repeat_guard) يقطع الحلقة حين تتكرر الإجراء ذاته، مما يشير إلى فخ تكرار. تنتهي كل مهمة بسبب إنهاء واحد بالضبط من بين: finished أو max_steps أو wall_budget أو repeat_guard أو no_action.

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

الإعداد والتكامل

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

@dataclass
class Guards:
    max_steps: int = 6
    wall_budget_s: float = 2.0
    repeat_limit: int = 2

def run_task(task: str, g: Guards) -> Trace:
    t0 = time.perf_counter()
    tr = Trace(task=task)
    repeats: dict[str, int] = {}
    while True:
        if tr.steps >= g.max_steps:
            tr.terminal = "max_steps"; break
        if (time.perf_counter() - t0) > g.wall_budget_s:
            tr.terminal = "wall_budget"; break
        act = policy(task, tr.scratch)
        if "final" in act:
            tr.answer = act["final"]
            tr.terminal = "finished" if act["final"] is not None else "no_action"
            break
        sig = f"{act['tool']}:{act['input']}"
        repeats[sig] = repeats.get(sig, 0) + 1
        if repeats[sig] > g.repeat_limit:
            tr.terminal = "repeat_guard"; break
        obs = TOOLS[act["tool"]](act["input"])
        tr.scratch.append({"tool": act["tool"], "input": act["input"], "obs": obs})
        tr.steps += 1
    tr.latency_ms = round((time.perf_counter() - t0) * 1000, 3)
    return tr

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

.venv/bin/python scripts/experiments/minimal-guarded-agent-loop/agent_loop.py

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

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

فيما يلي النتائج الحقيقية لتشغيل خمس مهام. ضُبطت ضوابط الحماية على: حد خطوات 6، وميزانية وقت 2.0 ثانية، وحد تكرار 2.

{
  "n_tasks": 5,
  "by_terminal": { "finished": 4, "repeat_guard": 1 },
  "total_latency_ms": 0.115,
  "total_steps": 7
}

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

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

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

التطبيق على منصة ThakiCloud للذكاء الاصطناعي وتعلم الآلة على Kubernetes

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

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

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

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

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

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

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

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

المصادر

• الخيط التعريفي الأصلي: How to build your first AI agent by @eng_khairallah1
• مفهوم حلقة تنفيذ الوكيل: The Agent Execution Loop (Victor Dibia)
• نظرة عامة على ReAct ونماذج اللغة الكبيرة LLM: Prompt Engineering Guide - LLM Agents
• كود التجربة: scripts/experiments/minimal-guarded-agent-loop/agent_loop.py (هذا المستودع)

نظرة عامة

كلتا الأداتين محرك استدلال لتشغيل نماذج لغوية كبيرة محلياً أو على بنية تحتية خاصة، غير أن أهدافهما التصميمية تختلف. Ollama مصنوع ليتيح لشخص واحد سحب نموذج بسرعة وتشغيله بأدنى احتكاك. التثبيت بسيط وإدارة النماذج مدمجة فيه، والخادم الخفيف المكتوب بـGo يبدأ سريعاً. أما vLLM فهو محرك خدمة إنتاجي مصمم من الأساس لإشباع GPU واحد بطلبات متزامنة متعددة وتعظيم الإنتاجية، وأبرز أسلحته PagedAttention والتجميع المستمر (continuous batching).

لماذا يعود هذا التمييز إلى الواجهة الآن؟ خضعت كلتا الأداتين لتغييرات معمارية جوهرية بعد عام 2024. حسّن Ollama تحسينات نواة llama.cpp ومسارات الاستدلال بالتكميم لرفع أداء التدفق الواحد، بينما بسّط vLLM تجربة التثبيت مع مواصلة تطوير PagedAttention والتشفير التخميني. معايير الأداء القديمة لم تعد تعكس الواقع الحالي، لذا يستحق الأمر مراجعة بأرقام حديثة.

تعالج ThakiCloud طلبات استدلال من عملاء متعددين على مجمع GPU مشترك في بيئة متعددة المستأجرين. في هذا السياق، سؤال “هل هو سريع لمستخدم واحد؟” شبه عديم المعنى؛ ما يهم هو “هل يصمد حين يتدفق المستخدمون في آن واحد؟”. من هذه الزاوية نستعرض منحنيات التوسع لكلتا الأداتين.

ماهية كل أداة

الفارق الحاسم بين المحركين يكمن في طريقة إدارة ذاكرة تخزين KV المؤقتة. خلال التوليد، يتراكم في المحول مفاتيح وقيم الرموز السابقة في ذاكرة مؤقتة. هذه الذاكرة هي المستهلك الأكبر لذاكرة GPU. يخصص Ollama وllama.cpp كتلة ذاكرة متجاورة لكل طلب مسبقاً. التنفيذ بسيط، لكن مع تزايد الطلبات المتزامنة يتراكم التشرذم وتصطدم القدرة على المعالجة الموازية بسقف سريع.

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

يوضح المخطط أدناه الفارق في كيفية معالجة كل محرك للطلبات المتزامنة.

flowchart TB
    subgraph OLLAMA["Ollama / llama.cpp - FIFO Queue"]
      Q1["Request 1"] --> EXEC1["Sequential Execution"]
      Q2["Request 2"] --> WAIT["Queue Wait"]
      Q3["Request N"] --> WAIT
      WAIT --> EXEC1
      EXEC1 --> KVC["Contiguous KV Cache (fixed block per request)"]
    end
    subgraph VLLM["vLLM - Continuous Batching + PagedAttention"]
      R1["Request 1"] --> BATCH["Unified Batch"]
      R2["Request 2"] --> BATCH
      R3["Request N"] --> BATCH
      BATCH --> PAGED["PagedAttention KV Pages (dynamic allocation)"]
      PAGED --> GPU["Merged into Single GPU Compute"]
    end

باختصار، Ollama محسّن لمعالجة طلب واحد بشكل نظيف في كل مرة؛ vLLM محسّن لدمج طلبات متعددة في عملية GPU واحدة. هذا الفارق التصميمي يظهر مباشرة في أرقام معايير الأداء.

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

تشغيل كلتا الأداتين عبر Docker هو الأسلوب الأنظف من حيث قابلية الإعادة. Ollama يبدأ هكذا:

docker run -d --gpus=all -v ollama:/root/.ollama \
  -p 11434:11434 --name ollama ollama/ollama
docker exec -it ollama ollama run llama3.1:8b

يمكن تشغيل vLLM مباشرة من صورة الخادم المتوافقة مع OpenAI:

docker run --gpus all -p 8000:8000 \
  --ipc=host vllm/vllm-openai:latest \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --dtype auto

كلا الخادمين يكشفان واجهة برمجية متوافقة مع OpenAI، فيمكن الإبقاء على كود العميل متطابقاً لكليهما:

curl http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"meta-llama/Llama-3.1-8B-Instruct","prompt":"مرحباً","max_tokens":64}'

لضمان قابلية الإعادة، يُنصح بتثبيت digests الصور. توصي معايير الأداء العامة بتسجيل RepoDigest عبر docker inspect ollama/ollama:<tag> وdocker inspect vllm/vllm-openai:<tag>، وحفظ مخرجات ollama --version وpip show vllm جنباً إلى جنب مع النتائج. حتى تغيير إصدار واحد قد يزعزع الأرقام.

إفصاح ضروري: كُتب هذا المقال على Apple Silicon (macOS, MPS)، لذا لم يكن بالإمكان إعادة إنتاج معايير أداء vLLM المستندة إلى CUDA مباشرة. الأرقام أدناه مستشهد بها من معيار أداء عام على نفس العتاد (SitePoint، مارس 2026، RTX 4090). المصدر مذكور في نهاية المقال. الأرقام المأخوذة من قياسات الآخرين تُبقى متمايزة عن أي ادعاء بأنها قياساتنا.

نتائج معايير الأداء (استشهاد بمعيار أداء عام)

بيئة معيار الأداء المستشهد به: GPU - NVIDIA RTX 4090 (24GB)، CPU - AMD Ryzen 9 7950X، ذاكرة عشوائية 64GB DDR5، Ubuntu 24.04، CUDA 12.6، Python 3.12. النماذج المقارنة هي Llama 3.1 8B وDeepSeek-R1-Distill-Llama-8B بموجّهات متطابقة.

أولاً، إنتاجية المستخدم الواحد التسلسلية. خلافاً للاعتقاد الشائع، لا يتفوق vLLM تفوقاً ساحقاً. لنموذج Llama 3.1 8B، أنتج Ollama (Q4_K_M) نحو 62 رمزاً/ث، وأنتج vLLM (FP16) نحو 71 رمزاً/ث، وvLLM AWQ نحو 68 رمزاً/ث. الفجوة البالغة نحو 13% تأتي من اختلافات التكميم أكثر مما تأتي من المزايا المعمارية. مع مستخدم واحد، يعوّض انخفاض حمل خادم Ollama وتحسينات نواة التكميم المزايا البنيوية لـvLLM.

تتغير الصورة كلياً تحت ضغط التزامن. الجدول أدناه يُظهر إجمالي إنتاجية الرموز (رمز/ث) بحسب عدد المستخدمين المتزامنين.

عند 10 مستخدمين متزامنين يتقدم vLLM بنحو 3.3 أضعاف، وعند 50 مستخدماً يصل التقدم إلى نحو 6 أضعاف. Ollama يعالج عبر قائمة انتظار FIFO - أي بشكل تسلسلي فعلياً - لذا يكاد إجمالي الإنتاجية يبقى ثابتاً مع ازدياد التزامن. في المقابل، يمتص vLLM الطلبات المتزامنة بالتجميع المستمر ويتوسع قريباً من التناسب الخطي.

الكمون يروي القصة ذاتها من زاوية مختلفة. عند مستخدم واحد، يبلغ زمن الاستجابة الأولى (TTFR) نحو 45 مللي ثانية لـOllama ونحو 82 مللي ثانية لـvLLM، أي Ollama أسرع. عند 50 مستخدماً متزامناً تنعكس الأدوار. يقفز TTFR الخاص بـOllama إلى نحو 3200 مللي ثانية مع تكدس الطلبات في الانتظار، بينما يحافظ vLLM على نحو 145 مللي ثانية بفضل التجميع المستمر. الأداة الأسرع في العزل تصبح الأبطأ تحت الحمل.

استهلاك الموارد يجلّي المفاضلة بوضوح. في وضع الخمول مع Llama 3.1 8B، يستخدم Ollama نحو 5.2GB VRAM ويستخدم vLLM FP16 نحو 16.1GB. عند 50 مستخدماً متزامناً يبقى Ollama قرب 5.4GB بينما يرتفع vLLM FP16 إلى نحو 21.8GB بسبب التخصيص الديناميكي للصفحات لذاكرة KV المؤقتة للتسلسلات النشطة. النسخة AWQ أكثر تحفظاً عند نحو 12.4GB تحت نفس الحمل. استهلاك ذاكرة النظام ووحدة المعالجة المركزية أيضاً أقل لـOllama (نحو 1.8GB مقابل 4.6GB في الخمول). الإنتاجية الأعلى لـvLLM ليست مجانية بل تُدفع ثمناً من VRAM وذاكرة نظام أكبر.

تجربة المطور والنظام البيئي

إلى جانب الأداء، تجربة المطور تحكم التكلفة التشغيلية. Ollama يُثبَّت بأمر واحد، وollama run يشغّل نموذجاً مع إدارة تحميل وتكميم مدمجة. انخفاض حاجز الدخول جعله يبدو أداة هواة في البداية، غير أنه يظهر اليوم على نطاق واسع في خطوط CI لموجّهات مراجعة الكود وعمليات النشر على الحافة كـJetson Orin وسلاسل أدوات المطورين الداخلية.

كان vLLM يستلزم في السابق إلماماً بأدوات ML بـPython، لكن تجربة التثبيت تبسّطت كثيراً في الإصدارات الأخيرة. سحب صورة الخادم المتوافقة مع OpenAI وتشغيلها يتيح ربط كود عميل OpenAI الحالي بتغييرات طفيفة. الميزات الإنتاجية الثرية - التوازي التنسوري، والتشفير التخميني، ومحولات LoRA القابلة للتبادل السريع - تمثّل ميزة بيئية واضحة. وبما أن كلتا الأداتين تتشاركان واجهة OpenAI المتوافقة، يكون الانتقال من Ollama في التطوير إلى vLLM في الإنتاج سلساً نسبياً.

منصة ThakiCloud K8s AI/ML SaaS - التطبيق والاستخلاصات

هذه المقارنة تشرح بدقة لماذا تعتمد ThakiCloud محركات عائلة vLLM معياراً للخدمة متعددة المستأجرين. منصتنا ليست مستخدماً واحداً يحتكر نموذجاً واحداً. طلبات عملاء متعددين تتدفق بشكل متزامن عبر مجمع GPU مشترك. في هذا السياق، المهم ليس سرعة التدفق الواحد بل منحنى توسع التزامن واستقرار الكمون تحت الحمل. عند 50 مستخدماً متزامناً، 6 أضعاف الإنتاجية وكمون أقل بأكثر من 20 مرة يُترجمان مباشرة إلى عدد المستأجرين الذين يمكن لـGPU واحد خدمتهم، أي تكلفة الوحدة.

تشغيلياً، نشر ThakiCloud حاويات خدمة vLLM على Kubernetes ويُنظّم أحمال عمل GPU بـKueue. حمل عمل الخدمة يبدو تقريباً هكذا:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-llama31-8b
spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          args:
            - "--model=meta-llama/Llama-3.1-8B-Instruct"
            - "--max-num-seqs=64"
            - "--gpu-memory-utilization=0.90"
          resources:
            limits:
              nvidia.com/gpu: "1"
          ports:
            - containerPort: 8000

--max-num-seqs و--gpu-memory-utilization هما مقبضا الضبط الرئيسيان. التغير الديناميكي في VRAM الخاص بـPagedAttention متغير لا بد من حسابه عند تصميم حدود ذاكرة الحاوية وسياسة تقسيم GPU. كما تُظهر الأرقام أعلاه، ينتقل VRAM من 16GB إلى 22GB مع ارتفاع التزامن، لذا التخصيص الثابت يُوقعك إما في نفاد الذاكرة أو الاستغلال الناقص. لذلك نقيس الحد الأقصى للتسلسلات المتزامنة وسقف ذاكرة KV المؤقتة لكل نموذج ونحدد موارد الحاوية وفقاً لذلك. Kueue يُبقي المهام في الانتظار حتى تتوفر طاقة GPU ويُوزّعها عند الإفراج، مما يمنع الاشتراك الزائد في GPU حتى حين يتدفق مستأجرون كثيرون في آن واحد.

هذا لا يجعل Ollama عديم الجدوى. لاختبار النماذج الأولية محلياً من قِبل المطورين الداخليين، وبيئات العرض التجريبي للمستخدم الواحد، وموجّهات مراجعة الكود الخفيفة في خطوط CI، تُعدّ سرعة بدء Ollama وانخفاض حد موارده ميزة حقيقية. بالنسبة لـThakiCloud الحد واضح: الاستدلال الإنتاجي المتعدد المستأجرين الموجّه للعملاء يستخدم vLLM؛ سير عمل المطور الفردي وعروض الحافة تستخدم Ollama. للعملاء الذين يشترطون الاستضافة الذاتية داخل مقارّهم حيث لا يمكن نقل البيانات خارجها (متطلبات أمنية حكومية وما شابهها)، حقيقة أن كلا المحركين يمكن تشغيلهما على GPU خاص بهم تُعدّ في حد ذاتها جوهر عرض القيمة.

القيود والتحفظات

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

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

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

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

المصادر

• SitePoint، “Ollama vs vLLM: Performance Benchmark 2026” (2026-03-05): https://www.sitepoint.com/ollama-vs-vllm-performance-benchmark-2026/
• التوثيق الرسمي لـvLLM: https://docs.vllm.ai
• Ollama: https://ollama.com

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

جميع الأرقام الواردة في هذا المقال مستقاة من قياسات نشرتها Z.ai ووسائل إعلام متعددة، أو محسوبة رياضياً من عدد المعاملات المُعلنة. لم يتسن لنا تشغيل نموذج 744B مباشرة في بيئتنا، لذا نستشهد بالأرقام العلنية بدلاً من معايير ذاتية، وأي تقدير رياضي نشير إليه بـ [تقديري].

نظرة عامة

GLM-5.2 نموذج لغوي ضخم بأوزان مفتوحة، أطلقته Z.ai (المعروفة سابقاً بـ Zhipu AI، مؤسسة تأسست عام 2019 انبثقت من مختبر الهندسة المعرفية بجامعة تسينغهوا في بكين) في 13 يونيو 2026. يعتمد النموذج بنية Mixture-of-Experts (MoE) بإجمالي نحو 744B معامل، يُفعَّل منها نحو 40B معامل لكل رمز، مع دعم لسياق يصل إلى مليون رمز وإخراج يبلغ 128 ألف رمز كحد أقصى. الأوزان منشورة بموجب رخصة MIT، مما يتيح لأي جهة تحميلها وتشغيلها تجارياً على بنيتها التحتية الخاصة.

للتوقيت دلالة بالغة. أفادت وسائل إعلام عديدة بأن GLM-5.2 صدر بعد يومين فقط من أمر أمريكي يقضي بمنع Anthropic من إتاحة نموذجَي Fable 5 وMythos 5 للوصول الدولي. بمعنى آخر، تزامنت في الأسبوع ذاته موجة تقييد وصول النماذج الحدودية المغلقة بقيود التصدير، مع ظهور نموذج مفتوح قوي قابل للاستضافة الذاتية برخصة MIT. بالنسبة للمنظمات التي تفكر في سيادة البيانات والنماذج معاً، هذا التناقض ليس قضية سياسية مجردة، بل خيار معماري آني.

الأداء أيضاً موضع تقدير عالٍ. وفقاً للمعايير المستقلة التي أوردها The Decoder وغيره، فضلاً عن بطاقة التقنية الصادرة عن Z.ai، اقترب GLM-5.2 من الصدارة في مهام الترميز الطويلة:

حقق GLM-5.2 نتيجة 62.1 في SWE-bench Pro، متفوقاً على GPT-5.5 (58.6) وعلى الجيل السابق GLM-5.1 (58.4)، فيما قفز أداؤه في Terminal-Bench 2.1 من 63.5 إلى 81.0. يحتل بذلك المرتبة الأولى بين النماذج المفتوحة في جميع هذه البنود. (تتفاوت نتيجة FrontierSWE بين المصادر المختلفة في نطاق 73 إلى 75%.)

كيف يسعى GLM-5.2 إلى تقليص استهلاك الرموز

اللافت أن تصميم GLM-5.2 يواجه مباشرة مسألة “كيف نعالج سياقاً طويلاً ورموزاً كثيرة بتكلفة أقل”. كل نموذج يتبنى سياقاً بمليون رمز يصطدم بالعائق الهندسي ذاته: حين يمتد السياق، ينتقل عنق الزجاجة من الحساب الخالص إلى سعة ذاكرة التخزين المؤقتة للمفاتيح والقيم (KV cache) ومصاريف النواة. تعالج Z.ai هذا بآليتين.

الأولى هي IndexShare. في آلية DeepSeek Sparse Attention (DSA) القياسية، تشغّل كل طبقة محول مفهرساً مستقلاً لتحديد الرموز التي تستحق الاهتمام، وهو ما يُكلّف كثيراً عند التوسع. يحل IndexShare هذه المشكلة بتشغيل المفهرس في الطبقة الأولى من كل مجموعة رباعية فقط، ثم تُعيد الطبقات الثلاث التالية استخدام مؤشرات top-k ذاتها. النتيجة: انخفاض تكلفة الفهرسة الداخلية بنسبة 75% في تلك الطبقات، وتراجع عمليات الحساب لكل رمز بمقدار 2.9 مرة عند طول السياق مليون رمز. الثانية هي الجمع بين KVShare والتنبؤ بعدة رموز في آنٍ واحد (MTP)، مما يرفع سرعة فك التشفير بالتنبؤ بعدة رموز دفعة واحدة خلال تمريرة أمامية واحدة.

أما الرافعة التي يتحكم بها المستخدم مباشرة فهي إعداد مستوى الجهد. يوفر GLM-5.2 مستويَين: High وMax، وتوصي Z.ai باستخدام Max في مهام الترميز. القيمة الافتراضية لجلسة جديدة هي High. وفق القياسات المنشورة، يستهلك مستوى Max نحو 85 ألف رمز إخراج للمهمة الواحدة لاستخلاص أعلى جودة، فيما يتنازل مستوى High عن نقاط قليلة في الأداء مقابل خفض يبلغ فعلياً النصف في رموز الإخراج. بعبارة أخرى، استهلاك الرموز ليس قراراً داخلياً تلقائياً للنموذج، بل هو متغير يمكن للمشغّل ضبطه صراحةً. وهذا المتغير هو المفتاح المحوري في حسابات التكلفة التي نناقشها لاحقاً.

ما كشفته /teach: الاستدلال يلتهم الرموز

لنعد إلى ملاحظة Matt Pocock. في أدنى مستوى جهد، استغرق حل مكعب روبيك واحد ثلاث جولات وما يقارب 220 ألف رمز. ولو رُفع مستوى الجهد إلى Max، لارتفع هذا العدد أكثر. هذا ليس قصوراً في النموذج، بل هو طبيعة نماذج الاستدلال. كلما “فكر” النموذج أطول قبل الوصول إلى إجابة، ارتفعت جودة المخرجات، وكل ذلك التفكير يُحاسَب عليه كرموز إخراج.

المسألة هي: أين تُسوَّى تكلفة هذه الرموز؟ الـ220 ألف رمز ذاتها تُكلّف بأسعار مختلفة جذرياً بحسب هيكل المحاسبة. سعر إخراج واجهة Z.ai هو 4.40 دولار لكل مليون رمز (و1.40 دولار للإدخال، و0.26 دولار للإدخال المخزَّن مؤقتاً). النماذج الأمريكية الحدودية المغلقة تبلغ تكلفة الإخراج فيها نحو 50 دولاراً لكل مليون رمز. حين نحوّل هذين السعرين إلى تكلفة لكل مهمة وفق مستويات الجهد، يتضح الفارق:

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

نموذج تكلفة الخدمة: الاستضافة الذاتية تعكس المعادلة

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

غير أن الاستضافة الذاتية تنطوي على حاجز دخول. لا بد من تحميل أوزان 744B في مكان ما. فيما يخص بصمة الذاكرة المحسوبة رياضياً من عدد المعاملات المُعلن (مع استثناء ذاكرة KV cache، وهي حسابات رياضية خالصة [تقديري]):

تبلغ البصمة نحو 1,488 جيجابايت بدقة BF16، ونحو 744 جيجابايت بدقة FP8، ونحو 372 جيجابايت بدقة FP4/NVFP4. ربط ثمانية معالجات H100 (80 جيجابايت) يوفر 640 جيجابايت، وربط ثمانية معالجات H200 (141 جيجابايت) يوفر 1,128 جيجابايت. بمعنى أن أوزان FP8 تدخل في عقدة H200 واحدة بارتياح، بينما تكون الأمور حرجة في عقدة H100 حين نأخذ بالاعتبار احتياطي ذاكرة KV cache. بالنزول إلى FP4 تُصبح عقدة H100 الواحدة كافية بمرونة. بمعنى آخر، استضافة نموذج استدلال على مستوى الحدود في عقدة معالج رسومي واحدة لم تعد فكرة بعيدة المنال.

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

التطبيق على منصة ThakiCloud للذكاء الاصطناعي والتعلم الآلي على K8s والدلالات

تشغّل ThakiCloud منصة SaaS للذكاء الاصطناعي والتعلم الآلي متعددة المستأجرين قائمة على K8s، وتتولى خدمة النماذج داخل المقر وفي البيئات المعزولة (VPC) دون إخراج بيانات العملاء إلى الخارج. نماذج الاستدلال ذات الأوزان المفتوحة القوية كـGLM-5.2 تتوافق تماماً مع هذه القيمة المقدَّمة.

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

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

ثالثاً، يتكامل بسلاسة مع مكدّس خدمة vLLM. يوفر GLM-5.2 نقطة نهاية متوافقة مع Anthropic (https://api.z.ai/api/coding/paas/v4) تتصل بها أدوات كـClaude Code وOpenClaw وCline فوراً، لكن الأهم من ذلك إمكانية تلقّي الأوزان مباشرة وتشغيلها عبر vLLM بالتوازي الموتري لـFP8. هذا النمط ذاته الذي نطبقه بالفعل على النماذج المفتوحة الأخرى في منصتنا.

وفي مرحلة النضج، يصبح متاحاً تشغيل عوامل متخصصة بمجال معين باستخدام نماذج استدلال مفتوحة بمستوى GLM-5.2 داخلياً، مما يجمع بين انخفاض تكلفة الخدمة وعدم مغادرة البيانات للبيئة. الرسالة لعملاء المؤسسات الذين يوازنون بين التكلفة والامتثال التنظيمي: التحكم في تكلفة الاستدلال عبر استهلاك المعالج الرسومي لا عبر فاتورة الرموز ميزة تمييز واضحة.

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

ثمة نقاط ضعف ينبغي الإفصاح عنها بصدق.

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

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

نتائج المعايير تحتاج إلى سياق أيضاً. تتباين نتيجة FrontierSWE بين 73 و75% بحسب المصدر، وتفوق معيار واحد لا يضمن التفوق في مهام مجال محدد. أخيراً، أرقام استهلاك الرموز وفق مستوى الجهد (8.5k و85k وغيرها) تتفاوت تفاوتاً كبيراً بحسب نوع المهمة، لذا الصحيح قراءة اتجاه المنحنى “كلما طال الاستدلال كلما كانت محاسبة الرمز أشد وطأة” لا الاستناد إلى القيم المطلقة في الجدول.

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

المصادر (Sources)

• التغريدة الأصلية (مصدر الملخص): @hjguyhan, 2026-06-22
• تحليل GLM-5.2: felloai: GLM 5.2: Zhipu’s 1M-Context Open-Source Model Explained
• معايير وأسعار GLM-5.2: labellerr: GLM-5.2 Just Beat GPT-5.5 at a Sixth of the Cost
• الأوزان الرسمية: GitHub: zai-org/GLM-5
• مقال ذو صلة (التكميم): Unsloth GLM-5.2 1بت Dynamic GGUF تحليل داخل المقر

نظرة عامة

nvidia/Qwen3.6-35B-A3B-NVFP4 هو نموذج Qwen/Qwen3.6-35B-A3B من Alibaba بعد تكميمه باستخدام NVIDIA Model Optimizer (ModelOpt). النموذج الأساسي بنية خليط الخبراء (MoE) بإجمالي 35B معامل و3B فقط نشطة، وطول سياق يصل إلى 262K، ورخصة Apache-2.0 تتيح الاستخدام التجاري وغير التجاري. وتوضّح NVIDIA صراحةً في بطاقة النموذج أن هذا ليس نموذجاً أساسياً من بناء NVIDIA بل نسخة مكمَّمة من نموذج طرف ثالث.

تتلخّص القيمة الجوهرية في فكرتين. بنية MoE تتكفّل بالسرعة، وتكميم NVFP4 يتكفّل بالذاكرة. بفضل بنية MoE، فإن توليد رمز واحد يشغّل فقط 3B من الخبراء النشطين بدلاً من كامل الـ35B، فيعمل نموذج 35B بحِمل حسابي قريب من نموذج كثيف بحجم 3B. أضف إلى ذلك تكميم NVFP4 الذي يخفض الأوزان من 16 بت إلى 4 بت، فتنخفض متطلبات القرص وذاكرة GPU بنحو 3.06 ضعف وفق بطاقة النموذج. هذا المزيج يشغّل “ذكاء بمستوى 35B بسرعة 3B وبذاكرة أقل بكثير.”

تدير ThakiCloud منصة SaaS متعددة المستأجرين للذكاء الاصطناعي والتعلم الآلي مبنية على Kubernetes، وتخدم النماذج عبر بيئات عملاء متنوعة. القدرة على أخذ نقطة تحقّق مكمَّمة مسبقاً وتحميلها مباشرة في vLLM تعني خفض تكلفة الخدمة دون إعادة تشغيل خط تكميم في كل مرة. وفي الواقع، تشغّل ThakiCloud بالفعل خط أنابيب داخلياً يكمّم العائلة نفسها Qwen3-MoE إلى NVFP4، ونشارك هذه التجربة لاحقاً في المقالة.

ما هذه التقنية

NVFP4 صيغة فاصلة عائمة بأربع بتات عرّفتها NVIDIA. وهي لا تسحق كل قيمة إلى 4 بتات ببساطة، بل تطبّق التكميم تحديداً على أوزان وتنشيطات المعاملات الخطية داخل كتل محوّل MoE. ونقتبس من بطاقة النموذج مباشرةً: “تم الحصول على هذا النموذج بتكميم أوزان Qwen3.6-35B-A3B إلى صيغة بيانات NVFP4. تُكمَّم فقط أوزان وتنشيطات المعاملات الخطية داخل كتل المحوّل في MoE. يخفض هذا التحسين عدد البتات لكل معامل من 16 إلى 4، ما يقلّل حجم القرص ومتطلبات ذاكرة GPU بنحو 3.06 ضعف.”

المفتاح هو إدراك أن MoE والتكميم يعملان على محورين مختلفين. ويوضّح المخطط أدناه كلا المحورين.

flowchart TB
    subgraph QUANT["محور التكميم (الذاكرة)"]
      A["Qwen3.6-35B-A3B<br/>أوزان BF16"] -->|"ModelOpt PTQ<br/>معايرة NVFP4"| B["نقطة تحقّق NVFP4<br/>16→4 بت، توفير ~3.06×"]
    end
    subgraph SERVE["محور الخدمة (السرعة)"]
      C["رمز الإدخال"] --> D["الموجّه"]
      D -->|"اختيار 3B من 35B"| E["الخبراء النشطون<br/>(حساب 3B)"]
      E --> F["رمز الإخراج"]
    end
    B -->|"vLLM --quantization modelopt"| G["Blackwell / Hopper<br/>Tensor Core"]
    G --> D

على محور التكميم، تُحوَّل أوزان BF16 إلى نقطة تحقّق NVFP4 عبر التكميم بعد التدريب (PTQ) في ModelOpt. وعلى محور الخدمة، يختار الموجّه لكل رمز إدخال مجموعة فرعية فقط من خبراء الـ35B ويجري نحو 3B من الحساب. يلتقي المحوران عند عملية Tensor Core فوق vLLM، وهنا بالضبط تظهر تبعية NVFP4 للعتاد. تُسرَّع عمليات NVFP4 فقط على معماريتي NVIDIA Hopper وBlackwell. وتُدرج بطاقة النموذج NVIDIA GB300 كعتاد اختبار.

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

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

أمر الخدمة الأساسي في vLLM الذي توفّره NVIDIA في بطاقة النموذج أدناه. تشغّل صورة دوكر vllm/vllm-openai:nightly ثم تنفّذه.

vllm serve nvidia/Qwen3.6-35B-A3B-NVFP4 \
  --port 8000 \
  --quantization modelopt \
  --max-model-len 262144 \
  --reasoning-parser qwen3

الراية --quantization modelopt هي ما يجعل المحرّك يتعرّف على نقطة تحقّق NVFP4. إذا كانت ذاكرة GPU ضيقة، فإن خفض --max-model-len أولاً ثم رفعه تدريجياً نهج آمن، لأن الحفاظ على كامل سياق 262K يتطلّب ذاكرة كبيرة لمخبأ KV.

للبيئات محدودة الذاكرة مثل NVIDIA DGX Spark، توفّر بطاقة النموذج أمراً موصى به منفصلاً.

vllm serve nvidia/Qwen3.6-35B-A3B-NVFP4 \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 1 \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --attention-backend flashinfer \
  --moe-backend marlin \
  --gpu-memory-utilization 0.4 \
  --max-model-len 262144 \
  --max-num-seqs 4 \
  --max-num-batched-tokens 8192 \
  --enable-chunked-prefill \
  --async-scheduling \
  --enable-prefix-caching \
  --speculative-config '{"method":"mtp","num_speculative_tokens":3,"moe_backend":"triton"}' \
  --load-format fastsafetensors \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_xml \
  --enable-auto-tool-choice

يحتوي هذا الأمر على عدة خيارات مفيدة تشغيلياً. تُصغّر --kv-cache-dtype fp8 حتى مخبأ KV إلى 8 بت، وتُبقي --gpu-memory-utilization 0.4 بصمة الذاكرة منخفضة، وتفعّل --speculative-config الفك التخميني القائم على MTP (التنبؤ متعدد الرموز). وتجعل --tool-call-parser qwen3_xml و--enable-auto-tool-choice استدعاء الأدوات قابلاً للاستخدام فوراً في سيناريوهات الوكلاء وRAG. وحالة الاستخدام التي تذكرها NVIDIA هي بالضبط “المطوّرون الباحثون عن نماذج جاهزة مكمَّمة مسبقاً للنشر في أنظمة وكلاء الذكاء الاصطناعي وروبوتات المحادثة وأنظمة RAG”، وتعكس مجموعة الخيارات هذه ذلك الغرض مباشرةً.

نتائج تجريبية حقيقية

إعادة إنتاج ThakiCloud: تشغيل مسار تكميم NVFP4 على RunPod H100

بدلاً من مجرد إعادة سرد أرقام بطاقة النموذج، كمّمت ThakiCloud النموذج الأساسي نفسه Qwen/Qwen3.6-35B-A3B إلى NVFP4 مباشرةً، على وحدتي NVIDIA H100 NVL (Hopper، بإجمالي 191 جيجابايت) في RunPod، باستخدام NVIDIA Model Optimizer. ولأن حسابات المعايرة (calibration) تجري بدقة BF16، فإن مسار التكميم نفسه يُعاد إنتاجه على Hopper أيضاً. الحقائق المقاسة كالتالي:

النقطة الجوهرية هي أن modelopt 0.44 تعرّف تلقائياً على بنية جديدة كلياً صدرت في أواخر مايو 2026 (Qwen3.6، الاسم الداخلي qwen3_5_moe، عائلة Gated DeltaNet) وأكمل مسار التكميم بنجاح. سُجِّلت كتل خبراء MoE المدمجة وذاكرة KV للانتباه تلقائياً كأهداف للتكميم، وأُدرِج 21,743 مُكمِّماً.

لكن بكل صدق، ثمة أمر واحد: نجح مسار التكميم، إلا أن خطوة كتابة نقطة التحقّق المعبّأة بأربع بتات إلى القرص، أي export_hf_checkpoint، اصطدمت حالياً بـفجوة توافق بين modelopt 0.44 و transformers 5.x (transformers>=5.0 support is experimental). إذ يتطلّب qwen3_5_moe الإصدار transformers 5.x، وفي هذا المزيج لا يعمل تصدير HF الموحّد بعد، فتراجع الأمر إلى BF16. وهذا تأخّر في سلسلة الأدوات شائع لبنية عمرها أقل من شهر. لذلك نستشهد بنقطة التحقّق المنشورة من NVIDIA لحجم النموذج المعبّأ (توفير نحو 3.06×، نحو 18.7 مليار) ولأرقام الدقة.

جدول الدقة أدناه هو التقييم الرسمي من NVIDIA المنشور في بطاقة النموذج. قارنت NVIDIA النسخة المكمَّمة NVFP4 بالنموذج الأساسي Qwen3.6-35B-A3B (BF16) على معايير الاستدلال النصي والبرمجة.

تمثيل بصري للأرقام المنشورة في بطاقة النموذج (تسميات المحاور بالكورية). حتى بعد التكميم بأربع بتات، تبقى معظم فروق الدقة دون نقطة واحدة.

مفتاح قراءة الجدول هو حجم الخسارة. أكبر انخفاض عبر المعايير الثمانية هو -0.8 على τ²-Bench Telecom، أما GPQA Diamond فهو -0.1، وAA-LCR متعادل. بل إن IFBench وMMMU PRO يتقدّم فيهما NVFP4 قليلاً على BF16. حدث التحوّل الطفيف في التوزيع الناتج عن التكميم بشكل مواتٍ في بعض المهام مصادفةً، لكن لا ينبغي تعميم ذلك إلى “التكميم يحسّن الأداء.” إجمالاً، رسالة الجدول أن خفض 16 بت إلى الربع عند 4 بتات حافظ على قدرات الاستدلال والرياضيات والبرمجة واستخدام أدوات الوكلاء بشكل شبه كامل. وكانت شروط التقييم لـSciCode عند temperature=0.6 وtop_p=0.95 وبحد أقصى 131072 رمزاً، والبقية عند temperature=1.0 وtop_p=0.95 وبحد أقصى 131072 رمزاً.

أما من ناحية الذاكرة، فتذكر بطاقة النموذج توفيراً بنحو 3.06 ضعف. ووفق مستودع Hugging Face، يُبلَّغ عن حجم المعاملات المحزومة لنقطة تحقّق NVFP4 بنحو 18.7B، وهو شكل مخفّض كثيراً للنموذج 35B مقارنةً بـ BF16 الأصلي. ويجب التحقق من حجم الملف الدقيق مباشرةً في الشريط الجانبي للمستودع، وتحذّر بطاقة النموذج من الخلط بين إحصاءات ملفات الشريط الجانبي ومعاملات بنية النموذج الأساسي.

التطبيق والدلالات لمنصة ThakiCloud للذكاء الاصطناعي والتعلم الآلي على Kubernetes

من منظور منصة ThakiCloud، جاذبية هذا النموذج واضحة. في بيئة متعددة المستأجرين، تكون GPU أغلى مورد مشترك، وكلما تمكّنّا من تحميل مزيد من نماذج المستأجرين على نفس GPU في آنٍ واحد، انخفضت تكلفة الاستدلال للوحدة. خفض NVFP4 للذاكرة بنحو 3.06 ضعف يعني، بصيغة مبسّطة، مساحة لاستيعاب نموذج أكبر أو جلسات متزامنة أكثر في نفس ذاكرة GPU. أضف خاصية MoE المتمثّلة في تشغيل MoE بحجم 35B بحساب نحو 3B، فتصبح قيمة “نماذج عالية الجودة بتكلفة خدمة منخفضة” المحلية أكثر تجسيداً بكثير.

تعكس ThakiCloud هذا بالفعل في التشغيل. نحافظ على خط أنابيب داخلي يكمّم Qwen/Qwen3-30B-A3B، من عائلة Qwen3-MoE نفسها، إلى NVFP4 (W4A4، group_size=16) على RunPod B200 (Blackwell SM100). وفي تشغيل تحقّق في 1 مايو 2026، أنتج نقطة تحقّق بحجم 17.1GB بـ137 ثانية من حساب PTQ. بلغ إجمالي الوقت الفعلي نحو 25 دقيقة، والتكلفة نحو 3.48 دولار على B200 عند الطلب. وأثناء إعداد هذه المقالة طبّقنا خط الأنابيب نفسه على النموذج الجديد Qwen3.6-35B-A3B، فأعدنا إنتاج مسار تكميم NVFP4 على وحدتي H100 NVL في RunPod (modelopt 0.44، إدراج 21,743 مُكمِّماً، تسجيل تلقائي للـ MoE المدمج الجديد، 148 ثانية). يترتّب على هذه التجربة أمران. أولاً، تكميم NVFP4 نفسه مهمة لمرة واحدة تنتهي في وقت قصير بتكلفة منخفضة. ثانياً، عند نشر نقطة تحقّق مكمَّمة مسبقاً كما فعلت NVIDIA هنا، يمكنك تخطّي حتى تلك المهمة لمرة واحدة والانتقال مباشرةً إلى الخدمة. بعبارة أخرى، نقطة تحقّق NVIDIA العامة مدخل أشمل لخط أنابيبنا.

أما من ناحية تشغيل K8s، فيتوافق كما يلي. تُصفّ أحمال GPU وتُجدول عبر Kueue، وتُشغّل الخدمة كحُجيرات vLLM مع الراية --quantization modelopt للتعرّف على نقطة تحقّق NVFP4، ويُعالَج عزل المستأجرين بمساحات الأسماء وتقسيم GPU، مع تعديل التخصيص لكل مستأجر بقدر الذاكرة الموفَّرة. لكن يرافق ذلك شرط عتاد واحد. تسريع NVFP4 يعمل فقط على Blackwell وHopper، لذا لا يمكن لمجمّعات العقد القائمة على A100 التمتّع بفائدة الأربع بتات لهذا النموذج كما هي. وهذا قرار تشغيلي مرتبط مباشرةً بتكوين مجمّع العقد، ونشير إليه كقيد في القسم التالي.

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

أولاً، تبعية العتاد قوية. توجد نوى Tensor Core الخاصة بـNVFP4 فقط على Blackwell وHopper. على وحدات GPU من الأجيال السابقة مثل A100 أو V100، لا يُسرَّع NVFP4، فلا يمكن توقّع نفس توفير الذاكرة ويجب سلوك مسار آخر مثل INT8 أو FP8. وإذا كانت أصول GPU الحالية لعميل محلي من جيل سابق، فإن جني فائدة هذا النموذج يستلزم تكلفة إضافية لاستبدال العقد.

ثانياً، توفير الذاكرة ومكاسب الإنتاجية أمران مختلفان. تذكر بطاقة النموذج توفيراً للقرص والذاكرة بنحو 3.06 ضعف، لكنها لا تقدّم مباشرةً أرقام إنتاجية مثل الرموز/الثانية أو زمن الاستجابة. ومع أن الأوزان بأربع بتات تساعد عادةً في فك التشفير بتخفيف ضغط عرض النطاق للذاكرة، فإن الإنتاجية الفعلية تعتمد على حجم الدفعة وطول السياق وإعدادات مخبأ KV. والجزم بأنه “أسرع بـN ضعفاً” دون معيار خدمة خاص بـThakiCloud سيكون غير دقيق. كما أن تسريع NVFP4 الأصلي لا يعمل إلا على Blackwell، ولم نتمكّن وقت إعادة الإنتاج هذه من تأمين مخزون B200 على RunPod، لذا تحقّقنا من مسار التكميم على Hopper (وحدتا H100 NVL) وتركنا إنتاجية خدمة NVFP4 الأصلية مهمة قياس منفصلة بعد توفّر Blackwell.

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

رابعاً، فقدان الدقة لا يتقارب إلى الصفر. رغم أن معظم المعايير تُظهر خسارة دون نقطة واحدة، فإن السيناريوهات التي يكون فيها استخدام أدوات الوكلاء والالتزام بالسياسات محورياً، مثل -0.8 في τ²-Bench Telecom، تُظهر خسارة أكبر نسبياً. وفي مجالات مثل المالية والرعاية الصحية حيث تنعكس فروق الدقة الصغيرة مباشرةً على التكلفة، تحتاج إلى سياسة توازن بين اقتصاديات توفير الأربع بتات وفقدان الدقة لكل مستأجر، وتختار بين BF16 وFP8 وNVFP4.

إجمالاً، nvidia/Qwen3.6-35B-A3B-NVFP4 خيار عملي للغاية للفرق التي تمتلك بنية تحتية قائمة على Blackwell/Hopper لـ”خفض الذاكرة إلى الربع تقريباً دون خسارة تُذكر.” لكن هذه الفائدة لا تصمد إلا فوق شرط العتاد والتحقق من الدقة الخاص بكل مجال، وتعتزم ThakiCloud تأكيد الإنتاجية وملاءمة كل مستأجر بمعيار خدمة خاص بها قبل عكسه في سياسة مجمّع العقد.

المصادر

• بطاقة النموذج: nvidia/Qwen3.6-35B-A3B-NVFP4 · Hugging Face
• النموذج الأساسي: Qwen/Qwen3.6-35B-A3B · Hugging Face
• أداة التكميم: NVIDIA Model Optimizer (GitHub)
• محرّك الاستدلال: vLLM (GitHub)

نظرة عامة

‏GLM-5.2 نموذج لغوي كبير مفتوح الأوزان من Z.ai (Zhipu). وهو نموذج Mixture-of-Experts (MoE) بنحو 744 مليار معامل إجمالي مع نافذة سياق تصل إلى مليون رمز. ووفق وثائق Unsloth وتقارير متعددة، يسجّل نتائج موازية لـ Claude 4.8 Opus و GPT-5.5 و Gemini 3.1 Pro عبر القياسات المجمّعة بما فيها Artificial Analysis — ولهذا يوصَف بأنه أقوى نموذج مفتوح حتى الآن.

المشكلة هي الحجم. نقطة التحقق الأصلية بدقة BF16 تبلغ نحو 1.51 تيرابايت، يصعب وضعها على خادم واحد. ما فعله Unsloth هو تكميم هذه الأوزان بطريقة Dynamic 2.0 GGUF، منتجًا نسخًا من بِت واحد حتى أربعة بتات. وتنزل نسخة البِت الواحد إلى 176 جيجابايت — صغيرة بما يكفي لتحميلها على جهاز Mac Studio واحد بذاكرة موحّدة سعتها 256 جيجابايت، أو صندوق GPU واحد متعدد البطاقات. نموذج مصنّف من الفئة الرائدة بات يعمل على عتاد مكتبي بدلًا من خزانة مركز بيانات.

تشغّل ThakiCloud منصة SaaS متعددة المستأجرين للذكاء الاصطناعي وتعلّم الآلة على Kubernetes، وتتعامل مع الخدمة المحلية وداخل VPC ليستخدم العملاء نماذج قوية دون إخراج البيانات. لذا فإن سؤال «إلى أي حجم صغير يمكن تشغيل نموذج مفتوح من الفئة الرائدة» يرتبط مباشرة بتكلفة الخدمة وسيادة البيانات لدى عملائنا. لكن الخلاصة مقدمًا: تكميم GGUF قوي في السيناريوهات المحلية وأحادية المستخدم، لكنه يتصرّف بشكل مختلف تحت الخدمة متعددة المستأجرين عالية التزامن. هذه المقالة تتناول هذا الحد.

ما هذه التقنية

‏GGUF هي صيغة ملف النموذج المستخدمة في منظومة llama.cpp، والتكميم يمثّل أوزان الفاصلة العائمة 16 بت بعدد أقل من البتات لتقليل الحجم والذاكرة. والمفتاح هنا هو طريقة Dynamic 2.0 من Unsloth. فبدلًا من تقليص كل طبقة إلى بِت واحد بشكل موحّد، تحافظ على الطبقات الأكثر حساسية لفقدان المعلومات بعرض بتات أعلى وتضغط الطبقات غير الحساسة بقوة فقط. حتى عندما تُسمّى «بِت واحد»، فإن عرض البت فعليًا مختلط لكل طبقة، ولهذا تفقد دقة أقل من التكميم الساذج عند المتوسط نفسه من البتات.

كون GLM-5.2 نموذج MoE يجعل هذا المزج ذا معنى خاص. فـ MoE يفعّل فقط الخبراء الذين يختارهم الموجّه لكل رمز، وليس كامل الـ 744B، فيتناسب الحساب مع عدد المعاملات النشطة. بعبارة أخرى، ‏MoE يتولّى الحساب، و Dynamic GGUF يتولّى الذاكرة. يوضّح المخطط أدناه المحورين ومسارات الخدمة المتفرّعة من منظور ThakiCloud.

flowchart TB
    subgraph QUANT["محور التكميم (الذاكرة)"]
      A["GLM-5.2 BF16<br/>نحو 1.51 تيرابايت"] -->|"Unsloth Dynamic 2.0<br/>توزيع البتات لكل طبقة"| B["GGUF ديناميكي بِبِت واحد<br/>UD-TQ1_0 176 جيجابايت"]
    end
    subgraph SERVE["محور الخدمة (السرعة)"]
      C["رمز الإدخال"] --> D["موجّه MoE"]
      D -->|"بعض خبراء 744B فقط"| E["الخبراء النشطون"]
      E --> F["رمز الإخراج"]
    end
    B --> R{سيناريو الخدمة}
    R -->|"مستخدم واحد، محلي، إثبات مفهوم محلي"| L["llama.cpp<br/>Mac 256 جيجابايت / متعدد GPU<br/>نحو 21.6 رمز/ث"]
    R -->|"متعدد المستأجرين عالي التزامن"| V["vLLM + FP8/FP4<br/>تجميع مستمر، K8s/Kueue"]
    L --> D
    V --> D

على محور التكميم، تمر أوزان BF16 عبر معايرة Unsloth Dynamic 2.0 لتصبح GGUF بِبِت واحد. وعلى محور الخدمة، يفعّل موجّه MoE بعض الخبراء فقط لكل رمز. وحيث يلتقي المحوران يتفرّع السيناريو: llama.cpp + GGUF للتحقق المحلي أحادي المستخدم؛ و vLLM + تكميم GPU للخدمة عالية التزامن. نعود إلى هذا التفرّع لاحقًا.

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

ميزة GGUF هي انخفاض حاجز الدخول — تحتاج فقط إلى llama.cpp أو غلاف له. المسار القياسي من وثائق Unsloth كالتالي.

نزّل فقط المستوى الذي تريده من Hugging Face. لنسخة البِت الواحد UD-TQ1_0:

# تنزيل شظايا GGUF بِبِت واحد فقط عبر huggingface_hub
pip install -U huggingface_hub hf_transfer
HF_HUB_ENABLE_HF_TRANSFER=1 \
huggingface-cli download unsloth/GLM-5.2-GGUF \
  --include "*UD-TQ1_0*" \
  --local-dir GLM-5.2-GGUF

ثم شغّل خادمًا بـ llama.cpp. وبما أنه نموذج MoE، اضبط --n-gpu-layers وطول السياق وفق بيئتك.

# خادم llama.cpp (نقطة نهاية متوافقة مع OpenAI)
./llama-server \
  --model GLM-5.2-GGUF/GLM-5.2-UD-TQ1_0-00001-of-*.gguf \
  --ctx-size 16384 \
  --n-gpu-layers 999 \
  --jinja \
  --host 0.0.0.0 --port 8080

على جهاز Mac Studio (M3 Ultra) بذاكرة موحّدة 256 جيجابايت، يستطيع خلفية Metal الاحتفاظ بكل الطبقات في الذاكرة؛ وعلى إعدادات x86 متعددة الـ GPU توزّع الطبقات بين GPU و CPU/RAM. كلما ارتفع مستوى التكميم زادت حاجته للذاكرة، فتصبح سعة عتادك عمليًا السقف لاختيار مستوى التكميم.

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

من هنا فصاعدًا هذه أرقام منشورة من Unsloth و Hugging Face. لا يمكن استضافة نموذج 744B في بيئة التحليل هذه، فهذه أرقام عامة موثّقة وليست مُعاد إنتاجها ذاتيًا. أدناه جدول حجم الملف لكل مستوى تكميم.

أما الدقة، فيذكر Unsloth أن التكميم الديناميكي يفقد أقل من التكميم الساذج عند المتوسط نفسه من البتات. وتشير المواد العامة إلى أن نسخة البِت الواحد الديناميكية تحتفظ بنحو 76% [تقديري] على مقياس دقتها الداخلي، ونسخة البِتين بنحو 82%، مع كونها أصغر بأكثر من 80% من الأصل. يختلف المقياس الدقيق ومجموعة البيانات حسب النسخة ومجموعة التقييم، لذا اقرأ هذه الأرقام كاتجاه أكثر من كونها قيمًا مطلقة: يزداد الفقد تدريجيًا مع انخفاض البتات، لكن حتى البِت الواحد يبقى في نطاق قابل للاستخدام. كما ينشر Unsloth نتائج GGUF الديناميكي على معيار Aider Polyglot للبرمجة، ما يتيح التحقق المتقاطع لجودة كل مستوى في مهام البرمجة.

تعتمد السرعة بشدة على العتاد. وفق التقارير العامة، عملت نسخة البِت الواحد بنحو 21.6 رمز/ث على جهاز Mac Studio بذاكرة 256 جيجابايت (M3 Ultra). هذا كافٍ لمستخدم واحد في الاستخدام الحواري، لكن الصورة تتغيّر تحت حمل الخادم مع عشرات الطلبات المتزامنة. هذا الفرق هو جوهر القسم التالي.

التطبيق على منصة ThakiCloud للذكاء الاصطناعي على Kubernetes

تخدم ThakiCloud النماذج عبر بيئات عملاء متنوعة، وعدد لا بأس به منها يحمل قيد «لا يمكن إخراج البيانات». ففي القطاعات المالية والعامة والصحية، حيث سيادة البيانات أساسية، يكون استدعاء نموذج رائد عبر واجهة خارجية ببساطة خارج الطاولة. وهنا يصبح GLM-5.2 Dynamic GGUF ورقة قوية: فهو يحوّل نموذجًا مفتوحًا من الفئة الرائدة بحجم 1.51 تيرابايت إلى شيء قابل للتشغيل على عقدة واحدة بسعة 256 جيجابايت تقريبًا.

هناك ثلاث زوايا ملموسة. أولًا، إثبات المفهوم والتقييم محليًا. قبل الدخول إلى مركز بيانات العميل، يكون تشغيل GGUF محليًا أرخص طريقة للتحقق مما إذا كان النموذج جيدًا بما يكفي في ذلك المجال — على جهاز واحد، دون حجز عنقود GPU. ثانيًا، الأحمال منخفضة التكرار وعالية الحساسية. للتحليل الداخلي ومعالجة المستندات حيث المستخدمون المتزامنون قليلون لكن البيانات يجب ألا تخرج أبدًا، تحقّق الخدمة أحادية العقدة بصيغة GGUF التكلفة والأمان معًا. ثالثًا، استيعاب تنوّع العتاد. يدعم llama.cpp واجهة Metal على Mac، وبطاقات x86 GPU، وإزاحة الحساب إلى CPU، ما يمنح مرونة لاستخدام أي عتاد مختلط يملكه العميل أصلًا.

تصفّ منصة ThakiCloud القياسية وحدات GPU عبر Kueue على Kubernetes وتشغّل النماذج على vLLM. وإضافة مسار GGUF تتيح تقديم قائمة خدمة من مستويين تتناسب مع وضع العميل: «vLLM + FP8/FP4 للخدمة متعددة المستأجرين عالية التزامن، و llama.cpp + Dynamic GGUF للخدمة المحلية أحادية العقدة». ضمن عائلة GLM-5.2 نفسها، نبدّل طريقة التكميم وزمن التشغيل حسب طبيعة الحمل. والفرق بين مزوّد يملك هذا الخيار وآخر لا يملكه يظهر لحظة يقول العميل «هذا لن ينجح في بيئتنا».

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

لتجنّب المبالغة في تقدير هذه التقنية، يجب توضيح بضعة أمور.

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

ثانيًا، ‏GGUF ليست صيغة للخدمة متعددة المستأجرين. رقم 21.6 رمز/ث أحادي التدفّق. يجمّع التجميع المستمر في vLLM الطلبات المتزامنة لرفع الإنتاجية، و llama.cpp ضعيف في هذا المجال. للخدمة متعددة المستأجرين بنمط SaaS مع عشرات إلى مئات المستخدمين المتزامنين، عادةً ما يتفوّق تكميم GPU بصيغة FP8/FP4 + vLLM على GGUF بِبِت واحد في الإنتاجية لكل وحدة تكلفة. مكان GGUF هو «بأمان في بيئة واحدة»، لا «لكثيرين في آن واحد».

ثالثًا، العتاد لم يصبح رخيصًا. جهاز Mac Studio بذاكرة موحّدة 256 جيجابايت أرخص بكثير من وحدات GPU لمراكز البيانات مثل 8×H100، لكنه ليس جهازًا اقتصاديًا بأي حال. «يعمل على المكتب» لا تعني «في متناول الجميع».

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

باختصار، يُقيَّم Unsloth GLM-5.2 Dynamic GGUF على أفضل وجه بأنه «أداة تخفض حاجز الدخول المحلي لنموذج مفتوح من الفئة الرائدة بدرجة واحدة». ليس حلًا سحريًا يستبدل كل الخدمة، بل خيار قوي في السيناريوهات التي تهمّ فيها سيادة البيانات وتكلفة العقدة الواحدة. ولمنصة مثل ThakiCloud قادرة على تبديل أزمنة التشغيل حسب الحمل، إنها ورقة إضافية لتحويل «لا نستطيع» لدى العميل إلى «إليك الطريقة».

المصادر

• unsloth/GLM-5.2-GGUF · Hugging Face

• [GLM-5.2 - How to Run Locally

  Unsloth Documentation](https://unsloth.ai/docs/models/glm-5.2)

• [Unsloth Dynamic 2.0 GGUFs

  Unsloth Documentation](https://unsloth.ai/docs/basics/unsloth-dynamic-2.0-ggufs)

• unsloth/GLM-5.2-GGUF · GLM-5.2 GGUF Benchmarks! (Discussion)

• [Unsloth Quantizes GLM-5.2’s 1.51TB to 217GB for Local Inference

  AI Weekly](https://aiweekly.co/alerts/unsloth-quantizes-glm-52s-151tb-to-217gb-for-local-inference)

📄 المراجعة المتعمقة الكاملة (DOCX): نزّل المراجعة التفصيلية من Google Drive.

نظرة عامة

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

في الرابع والعشرين من يونيو 2026، كشف فريق Qwen في Alibaba عن Qwen-AgentWorld، وهو نهج يقلب هذه المعادلة رأساً على عقب. بدلاً من تدريب الوكيل على “أداء أفضل”، يُدرَّب النموذج على التنبؤ بالبيئة ذاتها؛ أي أنه يرسم في ذهنه ما ستؤول إليه حالة البيئة التالية انطلاقاً من الملاحظة الراهنة والفعل المُتّخذ، تماماً كلاعب الشطرنج الذي يقرأ ثلاثة أشواط مقبلة قبل أن يحرك قطعة. هذا هو نموذج عالم اللغة (Language World Model — LWM).

نحن في ThakiCloud ندير عبء عمل وكلاء متعدد المستأجرين على منصة AI/ML-SaaS المبنية على Kubernetes. ولأن الوكلاء تعمل فوق بيئات وأدوات وقيود مختلفة لكل عميل، فإن “كيفية التعامل مع البيئة” ليست موضوعاً بحثياً مجرداً بالنسبة لنا، بل إشكالية تمسّ تكاليف التشغيل مباشرة. لذا حللنا هذا النموذج اعتماداً على التقرير التقني الرسمي (arXiv 2606.24597) والمواد المنشورة على GitHub، ورصدنا أين يناسب منصتنا وما ينبغي أخذه بحذر.

ما هو Qwen-AgentWorld؟

نموذج العالم هو نموذج يتنبأ بديناميات البيئة انطلاقاً من الملاحظة الراهنة والفعل المُتّخذ. وهو مفهوم آلية معرفية جوهرية للاستدلال والتخطيط درسه الباحثون منذ أمد بعيد، غير أنه ظل في الغالب حبيس بيئات بصرية ومادية كالروبوتات والألعاب. أما Qwen-AgentWorld فيختلف في كونه يُجسّد نموذج العالم فوق نموذج لغوي، عبر استدلال سلسلة التفكير (chain-of-thought).

السمة الجوهرية هي محاكاة 7 نطاقات بنموذج واحد: MCP، وSearch، وTerminal، وSWE، وWeb، وOS، وAndroid — سبع بيئات تفاعل للوكلاء يعالجها نموذج واحد. فإذا أُعطي النموذج موجّهاً للنظام يقول “محاكاة بيئة طرفية Linux” وأمراً من المستخدم، فإنه يتنبأ بالمخرجات التي ستنتجها الطرفية دون تنفيذ الأمر فعلياً.

تصميم جوهري آخر هو كون النموذج نموذج عالم أصيل (Native World Model). فنمذجة البيئة ليست ميزة أُلحقت في نهاية التدريب، بل كانت هدفاً تدريبياً منذ المرحلة الأولى (CPT). اعتمد النموذج على أكثر من عشرة ملايين مسار تفاعل من العالم الحقيقي لغرس “قدرة نمذجة البيئة” من الصفر. بعبارة المؤلفين: دُرِّبت النماذج اللغوية الكبيرة على التصرف الجيد في البيئات، لكنها لم تُدرَّب قط على نمذجة البيئات ذاتها — وهذا هو الفراغ الذي يسعى Qwen-AgentWorld إلى ملئه.

مخطط يلخّص خط أنابيب التدريب ثلاثي المراحل (CPT/SFT/RL) ومساري الاستخدام اللاحق لـ Qwen-AgentWorld.

خط أنابيب التدريب ثلاثي المراحل

يُبنى Qwen-AgentWorld عبر ثلاث مراحل تدريب ذات أدوار متمايزة بوضوح:

• CPT (Continual Pre-Training): يغرس قدرة النمذجة العالمية العامة من ديناميات انتقال الحالة وكوربوس متخصص معزَّز. هذه هي المرحلة التي تُزرع فيها المعرفة الأساسية بكيفية استجابة البيئة للأفعال.
• SFT (Supervised Fine-Tuning): يُفعِّل استدلال التنبؤ بالحالة التالية (next-state-prediction). لا يقتصر الأمر على إصابة الحالة التالية، بل يجعل النموذج يكشف عن سبب تلك الحالة عبر سلسلة التفكير.
• RL (Reinforcement Learning): يرفع دقة المحاكاة عبر مكافآت هجينة قائمة على مسطرة تقييم وقواعد. يُضبط النموذج باستخدام إشارات مكافأة تراعي التنسيق والواقعية والاتساق.

النموذج المنشور هو Qwen-AgentWorld-35B-A3B، بنية MoE (Mixture-of-Experts) تُنشَّط منها 3 مليارات معامل من أصل 35 مليار، مع نافذة سياق تبلغ 256K. يرد في التقرير التقني أيضاً Qwen-AgentWorld-397B-A17B الأكبر حجماً، غير أن أوزان 397B لم تُنشر. لتحديد نطاق ما هو متاح بدقة: أوزان النموذج 35B-A3B ومعيار AgentWorldBench متاحان بموجب رخصة Apache-2.0، أما 397B فيحضر في النتائج داخل التقرير فحسب. وهو تمييز ينبغي استحضاره حين تُقرأ تصريحات من قبيل “جرّبه الآن محلياً”.

المعيار: AgentWorldBench

كيف يُقيَّم نموذج عالم اللغة؟ أطلق فريق Qwen معياراً مخصصاً هو AgentWorldBench. يضم تفاعلات حقيقية أنتجتها خمسة نماذج حدودية عبر تسعة معايير قائمة، ويُقيّم الملاحظات البيئية المتنبَّأ بها على خمسة محاور: Format (التنسيق)، وFactuality (الواقعية)، وConsistency (الاتساق)، وRealism (المصداقية)، وQuality (الجودة). يستعين التقييم بنموذج حكم منفصل (gpt-5.2).

فيما يلي نتائج الدرجة الإجمالية (Overall) وهي متوسط درجات المحاور الخمسة الموحَّدة (0-100) عبر النطاقات، كما نُشرت في المستودع الرسمي على GitHub:

الدرجة الإجمالية في AgentWorldBench. تقيس دقة محاكاة البيئة، وهي مؤشر مختلف عن معدل نجاح الوكيل في إنجاز المهام. المصدر: QwenLM/Qwen-AgentWorld README الرسمي.

إليك الأرقام:

• Qwen-AgentWorld-397B-A17B: 58.71، المرتبة الأولى عالمياً، متجاوزاً GPT-5.4 (58.25) وClaude Opus 4.8 (56.59) وGemini 3.1 Pro (54.57).
• Qwen-AgentWorld-35B-A3B: 56.39، يتفوق على نموذج الأساس Qwen3.5-35B-A3B (47.73) بفارق +8.66. هذا تحسّن يزيد على ثماني نقاط بفضل تدريب نموذج العالم وحده.

ثمة نقطتان ينبغي التوضيح بشأنهما. أولاً: ما يقيسه هذا المعيار ليس “قدرة الوكيل على حل المهام” بل “دقة تنبؤ النموذج بالحالة البيئية التالية”، أي دقته بوصفه محاكياً. ثانياً: الذي تجاوز النماذج الحدودية هو 397B غير المنشور، أما 35B المتاح للتنزيل فدرجته 56.39، أي أدنى قليلاً من GPT-5.4 وClaude Opus 4.8. التحسّن لافت، لكن تبسيط القول بأن “النموذج المفتوح تغلّب على جميع النماذج المغلقة” غير دقيق.

مساران لجعل نموذج العالم يُقوّي الوكلاء

لا يقف Qwen-AgentWorld عند حد المحاكاة؛ فهو يقترح مساريْن لجعل نموذج العالم يُقوّي الوكلاء.

المسار الأول: محاكي البيئة المنفصل (Controllable Sim RL). يستخدم نموذج العالم بديلاً عن البيئة لتدريب الوكلاء بالتعلم التعزيزي. بدلاً من تشغيل آلاف البيئات الحقيقية، يُنشئ النموذج بيئات محاكاة قابلة للضبط والتوسع. وفق التقرير، حين طُبِّق Sim RL على 4000 بيئة خارج التوزيع (OOD) من OpenClaw، ارتفعت النتائج من الخط الأساسي (65.4 / 47.9) إلى 69.7 / 55.0 باستخدام Qwen-AgentWorld-397B-A17B بيئةً محاكِية. والأجدر بالاهتمام أن المحاكاة “المضبوطة” تفوّقت على غير المضبوطة؛ ففي أحد الإعدادات سجّل Sim RL المضبوط تحسناً +16.29 / +10.49 قياساً بخط أساس SFT، أي نتائج أفضل من التدريب على البيئة الحقيقية وحدها.

المسار الثاني: أساس الوكيل الموحّد (LWM Warmup). يستخدم تدريب نموذج العالم نوعاً من الإحماء. نموذج أُجري له LWM RL Warmup على مسارات أحادية الدور وغير وكيلية ينتقل تلقائياً إلى مهام الوكلاء متعددة الأدوار ومتعددة مكالمات الأدوات، دون تدريب وكيلي منفصل. الادعاء الجوهري هو أن معرفة التنبؤ تنتقل ذاتياً. حين أُضيف LWM RL إلى Qwen3.5-35B-A3B-SFT، تحسّنت النتائج عبر سبعة معايير:

ظهر التحسّن في ثلاثة معايير خارج النطاق تماماً. تعلّم التنبؤ بالبيئة يُعين على تعلّم التصرف فيها — نتيجة تبدو مضادة للحدس بعض الشيء.

كيف تشغّله فعلياً؟

يمكن خدمة النموذج 35B-A3B المنشور مباشرة عبر أطر استدلال كـ SGLang وvLLM. الأوامر التي يقترحها المستودع الرسمي:

# الخدمة عبر vLLM
vllm serve Qwen/Qwen-AgentWorld-35B-A3B

# أو عبر SGLang
python -m sglang.launch_server --model-path Qwen/Qwen-AgentWorld-35B-A3B

يتبنى النموذج واجهة OpenAI المتوافقة كنماذج الدردشة المعتادة، مع ميزة تمييزية: يُحدَّد الموجّه النظامي بـ”أي بيئة يُراد محاكاتها”.

model_name = "Qwen/Qwen-AgentWorld-35B-A3B"
messages = [
    {
        "role": "system",
        "content": "You are a language world model simulating a Linux terminal environment. "
                   "Given the user's command, predict the terminal output.",
    },
    {"role": "user", "content": "ls -la /var/log"},
]

تقييم AgentWorldBench متاح أيضاً؛ يمكن تنزيل ملفات JSONL الخاصة بكل نطاق (mcp_test.jsonl، terminal_test.jsonl، إلخ) وإعادة إنتاج التقييم الخماسي المحاور بشكل مستقل. لكن تجدر الإشارة إلى أن 35B-A3B، رغم بنيته MoE، يتطلب ذاكرة GPU غير يسيرة، مما يستدعي تسريعاً ملائماً وتوازي تنسوري لبيئة الإنتاج. في هذا التحليل لم نُجرِ استدلالاً على GPU خاصة بنا؛ اقتصرنا على الأرقام المنشورة رسمياً في التقرير والمستودع دون قياسات ذاتية.

التطبيق على منصة ThakiCloud AI/ML SaaS لـ Kubernetes

نُجدوِل في ThakiCloud أعباء عمل GPU عبر Kueue فوق Kubernetes، ونُقدّم استدلالاً متعدد المستأجرين عبر vLLM، وندير وكلاء معزولة لكل عميل. من هذه الزاوية، يطرح Qwen-AgentWorld ثلاثة دلالات:

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

ثانياً: التوافق مع الاستضافة الذاتية وبيئات الاستخدام الداخلي. ترخيص Apache-2.0 لنموذج 35B-A3B يُجيز الاستخدام التجاري والاستضافة الذاتية دون قيود. بالنسبة لعملاء في القطاعين الحكومي والمالي حيث لا تستطيع البيانات مغادرة الحدود، يتيح هذا خيار إسكان محاكي البيئة الخاص بالعميل داخل مجموعتنا بدلاً من الاعتماد على واجهات API خارجية. تغليف البيئة في نموذج يُتيح تدريب الوكلاء وتقييمهم دون كشف البيئات التشغيلية الحساسة للخارج.

ثالثاً: القيمة بوصفه بنية تحتية تقييمية. التقييم الخماسي المحاور لـ AgentWorldBench (التنسيق، الواقعية، الاتساق، المصداقية، الجودة) يُشكّل بحد ذاته إطاراً جيداً لبوابة جودة وكلاء متعددي المستأجرين. يوفر محاور قابلة للقياس الكمي لتصفية الوكلاء قبل نشرها لدى العملاء بناءً على مدى دقة فهمهم للبيئة. حتى من دون خدمة 397B محلياً، يُعدّ تصميم التقييم هذا ونموذج المحاكاة 35B المتاح أصولاً قابلة للدمج فوراً في خطوط تحقق داخلية.

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

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

أول ما ينبغي الإشارة إليه هو الفجوة بين التصريحات الترويجية ونطاق ما هو منشور فعلاً. تناقلت وسائل التواصل الاجتماعي عبارات من قبيل “أطلقت Alibaba نموذجاً يتفوق على جميع النماذج المغلقة، جرّبه الآن محلياً”. لكن الذي تفوّق على النماذج الحدودية هو 397B غير المنشور، أما 35B القابل للتنزيل فأداؤه أدنى قليلاً من GPT-5.4 وClaude Opus 4.8. “التفوّق” و”النشر” لا يشيران إلى نفس النموذج — ينبغي توضيح ذلك بجلاء.

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

ثالثاً: قيود التقييم الذاتي التصميم والتحكيم الذاتي. فريق البحث الذي أنشأ المعيار هو ذاته من صمّم محاور التقييم واختار نموذج الحكم (gpt-5.2). هذا ليس عيباً بالضرورة، لكن الحكمة تقتضي قراءة الأرقام المطلقة بحذر حتى تتراكم عمليات إعادة الإنتاج المستقلة من أطراف ثالثة.

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

بعد كل هذا، يبقى التوجّه القاضي بـ”جعل النموذج يفهم البيئة قبل أن يتصرف فيها” توجهاً جديداً وواعداً. والأهم أن نموذج 35B والمعيار مفتوحان بموجب Apache-2.0، فباب التحقق والتجريب ليس موصداً. اقتلع العناوين المبالغ فيها جانباً، وما تبقى هو بحث عملي تماماً لمنصات وكلاء متعددة المستأجرين.

المصادر

• التقرير التقني لـ Qwen-AgentWorld (arXiv): arxiv.org/abs/2606.24597
• المدونة الرسمية: qwen.ai/blog?id=qwen-agentworld
• GitHub: github.com/QwenLM/Qwen-AgentWorld
• النموذج والمعيار على Hugging Face: huggingface.co/collections/Qwen/qwen-agentworld
• الإعلان الرسمي لـ Alibaba Qwen على X: x.com/Alibaba_Qwen/status/2069720365442719867

📄 المراجعة المتعمقة الكاملة (DOCX): نزّل المراجعة التفصيلية من Google Drive.

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

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

يزيل Unlimited OCR من Baidu (arXiv 2606.23050) هذا السقف بطريقة مختلفة. فهو يستبدل كل طبقة انتباه في فك التشفير بآلية Reference Sliding Window Attention (R-SWA)، محافظًا على حجم ذاكرة KV ثابتًا طوال فك التشفير. ونتيجة لذلك يمكنه نسخ عشرات الصفحات من مستند في تمريرة أمامية واحدة ضمن سياق 32K. وعبارة الورقة “التحليل أحادي اللقطة طويل الأفق” ليست مبالغة.

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

ما هو Unlimited OCR

ليس Unlimited OCR نموذجًا بُني من الصفر بل نموذج يدفع DeepSeek-OCR خطوة أبعد. فهو يحتفظ بـDeepEncoder القوي من DeepSeek-OCR كمشفّر له ويستبدل انتباه فك التشفير فقط بـ R-SWA.

يقلّص مشفّر عالي الضغط الصفحة إلى عدد قليل من الرموز البصرية، ويولّد فك تشفير R-SWA مخرجات طويلة بذاكرة KV ثابتة.

المشفّر (DeepEncoder): يُربط SAM-ViT وCLIP-ViT على التوالي مع تطبيق ضغط رموز بمقدار 16 ضعفًا. تُضغط صفحة PDF واحدة بدقة 1024×1024 إلى 256 رمزًا بصريًا فقط. ولأن عدد الرموز مُقلّص بشدة على جانب الإدخال، تكون كمية المعلومات البصرية التي يجب على فك التشفير الرجوع إليها صغيرة. ويعمل هذا التصميم عالي الضغط مع ذاكرة KV الثابتة المذكورة أدناه لتمكين معالجة المستندات الطويلة.

فك التشفير (نموذج لغوي بـ R-SWA): فك التشفير نموذج خليط خبراء (MoE) بحجم 3 مليار معامل مع نحو 500 مليون معامل مُفعّل. وبما أن مجموعة فرعية فقط من الخبراء تُفعّل لكل رمز بدلًا من الـ 3 مليار كاملة، فإن الحوسبة لكل رمز خفيفة نسبةً إلى عدد المعاملات. وعلاوة على ذلك، يُعد استبدال جميع طبقات الانتباه بـ R-SWA هو الميزة الجوهرية للنموذج.

النموذج الكامل نحو ثلاثة مليارات معامل، صدر بأوزان BF16 تحت رخصة MIT المسموح بها تجاريًا. تتوفر الأوزان على Hugging Face في baidu/Unlimited-OCR وعلى ModelScope، منشورة مع الكود على GitHub. وعند الإصدار يعمل وفق التقارير على وحدة معالجة رسوميات NVIDIA متوسطة المدى واحدة.

هذا النموذج من سلالة Baidu نفسها مثل PaddleOCR-VL الذي تناولناه سابقًا، لكن النهج يختلف. يقسم PaddleOCR-VL تحليل التخطيط والتعرف على العناصر إلى مرحلتين لتأمين الاستقرار بنماذج صغيرة، بينما يحتفظ Unlimited OCR بنموذج واحد من طرف إلى طرف لكنه يغيّر آلية الانتباه لملاحقة معالجة المستندات الطويلة دفعة واحدة. ومن الممتع مقارنة فلسفتي تصميم تحلّان المشكلة نفسها.

الآلية الجوهرية: Reference Sliding Window Attention

لفهم R-SWA انظر أولًا إلى نقاط ضعف نهجين قائمين.

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

انتباه النافذة المنزلقة العادي (SWA) يرى فقط آخر W رمزًا. تُثبَّت ذاكرة KV على حجم النافذة فتصبح الذاكرة ثابتة، لكن المعلومات التي تُدفع خارج النافذة تُنسى. ينفع هذا في توليد النص العام، لكنه قاتل في OCR حيث يجب “النظر إلى المصدر ونسخه بأمانة”. فبمجرد أن تتجاوز النافذة، تفقد دليل أي صفحة كنت تنسخها.

تجمع R-SWA بين الأمرين. وفكرتها الأساسية تأتي من طريقة نسخ البشر لمستند طويل. يكتب الشخص وهو ينظر إلى آخر بضع جمل كتبها (الذاكرة العاملة قصيرة المدى) وإلى المستند الأصلي المنشور أمامه (المرجع). و”Reference” في R-SWA هي بالضبط هذا المرجع الأصلي. فهي تحتفظ بالرموز البصرية عالية الضغط التي ينتجها المشفّر كمرساة يمكن الوصول إليها دائمًا، مع تطبيق نافذة منزلقة على رموز النص المولّد.

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

تؤكد الورقة أن R-SWA ليست حيلة خاصة بـ OCR بل انتباه تحليل عام الغرض. ينطبق الهيكل نفسه على المهام التي تقرأ مدخلًا طويلًا وتنتج مخرجًا طويلًا، مثل التعرف على الكلام (ASR) أو الترجمة. وقد يتعمم نمط تثبيت المدخل كمرجع مرساة وتطبيق نافذة منزلقة على المخرج عبر مسائل التسلسل إلى التسلسل.

نتائج القياس

تُبلَّغ الأداء على OmniDocBench، وهو معيار لتحليل المستندات يقيّم بشمولية النص الأساسي والجداول والمعادلات وترتيب القراءة.

• النتيجة الإجمالية على OmniDocBench v1.5 بنسبة 93.23%: تحسّن بمقدار 6.22 نقطة مئوية عن خط أساس DeepSeek-OCR.
• النتيجة الإجمالية على OmniDocBench v1.6 بنسبة 93.92%: مُبلَّغ عنها كأحدث ما توصلت إليه التقنية من طرف إلى طرف.

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

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

تطبيقه على منصة ThakiCloud لـ K8s AI/ML SaaS

من منظور منصتنا، سبب أهمية هذا النموذج واضح: أصعب مورد في خدمة الاستدلال متعدد المستأجرين هو بالضبط ذاكرة KV.

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

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

خارطة طريق التطبيق: على منصتنا، تدخل أحمال ذكاء المستندات كمعالجة مسبقة لفهرسة RAG وكأدوات مستندات للوكلاء. ويمكن لـ OCR ذي ذاكرة KV الثابتة أن يكون البوابة الأولى في كلا المسارين، محلّلًا مستندًا طويلًا بدقة وبالكامل قبل تقطيعه. وخاصة للمستندات الحكومية الكورية والمستندات المالية ذات الجداول العابرة للصفحات والتخطيطات متعددة الأعمدة، تساهم القدرة على المعالجة المستمرة دون تقسيم الصفحات مباشرة في جودة RAG اللاحقة. وتتمثل استراتيجية تشغيل واقعية في نشر استقرار المراحل المنفصلة في PaddleOCR-VL ومعالجة Unlimited OCR للمستندات الطويلة دفعة واحدة بشكل انتقائي وفق خصائص الحمل.

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

التصميم الأنيق لا يعني أنه يناسب كل حالة.

الحدود المتأصلة للنافذة المنزلقة: رغم احتفاظ R-SWA بالمرجع البصري كمرساة، يظل جانب النص المولّد نافذة منزلقة. فالاعتماديات بعيدة المدى جدًا بين رموز الإخراج، مثل التوسيع المتسق لاختصار عُرّف في الصفحة 1 عبر الصفحة 180، قد لا تكون مضمونة بالدرجة نفسها كالانتباه الكامل حتى مع تعزيز المرجع البصري لها. وهذه نقطة يجب تأكيدها عبر إعادة الإنتاج العملي.

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

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

الحاجة إلى التحقق: كل رقم في هذا المنشور قيمة بلّغتها الورقة وبطاقة النموذج. وما إذا كانت ذاكرة KV الثابتة تقدّم مكسب الإنتاجية الذي تَعِد به في الخدمة الحقيقية، وما إذا كانت تملأ 32K دون خسارة في الدقة، لا يمكن تأكيده إلا بقياسه بأنفسنا.

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

المصادر

• Unlimited OCR Works: Welcome the Era of One-shot Long-horizon Parsing (arXiv 2606.23050)
• صفحة الورقة على Hugging Face
• baidu/Unlimited-OCR (نموذج وأوزان Hugging Face)
• baidu/Unlimited-OCR (كود GitHub)

نظرة عامة

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

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

بنية مشكلة ذاكرة الوكيل

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

flowchart LR
    LOOP["Agent Loop"] --> FULL{"Context limit near?"}
    FULL -->|Yes| COMPACT["Compaction: summarize and restart in new window"]
    FULL -->|No| NOTE["Structured notes: write key facts to file"]
    NOTE --> STORE[("File-based memory (outside window)")]
    COMPACT --> STORE
    LOOP --> SUB["Sub-agent delegation"]
    SUB --> DISTILL["Return 1,000-2,000 token summary only"]
    DISTILL --> LOOP
    STORE -->|Reload after reset| LOOP

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

التقنيات الأربع

الضغط

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

تدوين الملاحظات المنظم

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

معمارية الوكلاء الفرعيين

الوكلاء الفرعيون هم مسار آخر للتحايل على حدود السياق. بدلا من أن يحمل وكيل واحد حالة المشروع بأكملها، يتولى وكلاء فرعيون متخصصون مهاما ضيقة بنوافذ سياق نظيفة. يتولى الوكيل الرئيسي التنسيق على مستوى عالٍ، بينما ينفذ الوكلاء الفرعيون العمل التقني العميق أو الاستكشاف. يمكن لكل وكيل فرعي استخدام عشرات الآلاف من الرموز في استكشاف واسع النطاق، لكنه لا يعيد إلى الوكيل الرئيسي إلا ملخصا منقحا يتراوح بين 1,000 و 2,000 رمز. يبقى سياق الاستكشاف التفصيلي معزولا داخل الوكيل الفرعي، وتظل نافذة الوكيل الرئيسي نظيفة ومركزة على اتخاذ القرارات.

أدوات الذاكرة المستندة إلى الملفات

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

المقارنة مع الأساليب الأبسط

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

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

كيف تطبّق ThakiCloud هذه التقنيات

هذه التقنيات الأربع ليست نظرية مجردة؛ فهي تشكل العمود الفقري للعمليات اليومية لوكلاء ThakiCloud. تنفذ منصتنا الداخلية معمارية ذاكرة مستندة إلى الملفات بثلاث طبقات: فهرس MEMORY.md يُحمَّل في كل جلسة ويحتوي على مؤشرات من سطر واحد، وتفاصيل الوقائع في memory/topics/، وسجلات العمل الطويلة في memory/sessions/. تحميل الفهرس وحده في السياق وسحب التفاصيل عند الطلب هو بالضبط دمج تدوين الملاحظات المنظم والذاكرة المستندة إلى الملفات والاسترجاع في الوقت المناسب.

يبدو الفهرس تقريبا كمجموعة مؤشرات أحادية السطر:

- [Model Routing](feedback_model_routing.md) - sub-agent model stacking: low-cost for exploration, mid-tier for implementation, high-cost for architecture
- [Hermes Ecosystem](project_hermes_ecosystem.md) - installation record for the standalone agent framework

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

التفويض إلى وكلاء فرعيين يسير بالمنهج ذاته. المسح الشامل لقواعد الكود أو عمليات البحث الضخمة لا تُنفَّذ في السياق الرئيسي؛ بل تُفوَّض إلى وكيل فرعي بنموذج منخفض التكلفة يعيد ملخصا للاستنتاجات فحسب. عدم إغراق السياق الرئيسي بالمخرجات الخام يتطابق تماما مع ما أوصت به Anthropic: “يعيد الوكيل الفرعي ملخصا من 1,000 إلى 2,000 رمز فقط.” هذا يمنع تكاليف إعادة قراءة ذاكرة التخزين المؤقت من النمو الخطي.

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

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

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

لكل تقنية تكاليفها. الضغط يفقد معلومات في مرحلة التلخيص؛ اختيار ما يُحذف بصورة خاطئة قد يُعطل العمل اللاحق. التلخيص عالي الدقة مشكلة صعبة في حد ذاتها، وتعتمد النتائج اعتمادا كبيرا على جودة تلقين التلخيص.

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

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

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

المصادر

• Anthropic، “الهندسة الفعّالة للسياق في وكلاء الذكاء الاصطناعي” (2025-09-29): https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Anthropic، كتيب إدارة الذاكرة والسياق: https://platform.claude.com/cookbook/tool-use-memory-cookbook

في الثالث والعشرين من يونيو 2026، أعلنت Anthropic عن Claude Tag. حين يكتب المستخدم طلباً موجهاً إلى @Claude داخل قناة Slack ويكلّفه بمهمة، يقوم الوكيل بتقسيم الطلب إلى خطوات، ثم ينفّذ كل خطوة مستعيناً بالأدوات والبيانات المتصلة، ويعود بالنتائج ضمن نفس الخيط. المنتج متاح حالياً في مرحلة تجريبية لعملاء Claude Enterprise وClaude Team عبر Slack، مع الإعلان عن إطلاق أوسع لاحقاً.

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

تُشغّل ThakiCloud منصة SaaS للذكاء الاصطناعي وتعلم الآلة مبنية على Kubernetes، وتُدير داخلياً فرق وكلاء بهيكلية المحور والأذرع، مع إرسال نتائج العمل إلى قنوات التقارير على Slack. لذا فإن فكرة وكيل يقيم داخل أداة التعاون ليست مجردة بالنسبة لنا، بل هي نمط نُشغّله فعلاً. يتناول هذا المقال ما الجديد حقاً في Claude Tag، وكيفية قراءة رقم الـ65%، وما يعنيه هذا النمط لمنصات الذكاء الاصطناعي متعددة المستأجرين المُشغَّلة محلياً.

ما هو Claude Tag

باختصار، Claude Tag وكيل تنفيذ مهام يعيش داخل Slack. يكتب المستخدم طلباً بلغة طبيعية موجهاً لـ@Claude، فيقسّم الوكيل العمل إلى خطوات، وينجز كلاً منها باستخدام الأدوات والبيانات المتاحة، ثم يسلّم النتائج داخل الخيط. إنه ليس أداة مساعدة تعمل على الهامش كالاقتراح التلقائي، بل يتولى مهمة كاملة ويقودها حتى نهايتها.

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

ما الجديد: الديمومة والتعددية والمبادرة

ثمة ثلاث خصائص يُركّز عليها الإعلان وتُشكّل جوهر المنتج.

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

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

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

[ الدردشة التقليدية ]                    [ Claude Tag ]
  مستخدم واحد -- محادثة خاصة 1:1          القناة (مجموعة) -- سياق مشترك
    |  يرد عند الاستدعاء ثم يختفي           |  مقيم، يعمل بشكل غير متزامن
    |  سلبي: يتحرك بالطلب فقط              +-- متعدد اللاعبين: أي عضو يكمل المهمة
                                           +-- مبادر: يتابع الخيوط غير المحسومة

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

كيف نقرأ رقم الـ65%

أبرز ما في الإعلان هو أن 65% من كود فريق المنتجات كُتب بالنسخة الداخلية. الرقم لافت، لكن ينبغي الفصل بين الوقائع والتفسير.

الوقائع هي التالية: هذا رقم تُفصح عنه الشركة عن فريقها الداخلي ذاته، ومنهجية القياس لم تُعلَن، أي ما الذي يُحسب “كتابةً”، وكيف تُعالَج المراجعات والتعديلات البشرية. لذا لا يمكن تعميم هذا الـ65% على صعيد الصناعة كلها أو افتراض أنه سيتكرر بالطريقة ذاتها في مؤسسات أخرى [تقدير: وفق تصريح الشركة].

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

التطبيق على منصة ThakiCloud K8s للذكاء الاصطناعي وتعلم الآلة

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

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

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

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

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

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

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

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

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

المصادر

• تغريدة الإعلان الرسمي من ClaudeDevs
• TechCrunch, “Anthropic’s Claude Tag is learning your company, one Slack message at a time”
• The Decoder, “Claude Tag embeds Anthropic’s AI in Slack, already writes 65 percent of internal code”
• تغريدة المصدر الأصلي (إعادة تغريد)

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

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

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

ما هي هندسة الحلقات

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

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

افتراض آخر ضروري: يجب أن تعرف الحلقة كيف تتقارب أو تتوقف. حلقة بلا شرط انتهاء ليست أتمتة؛ إنها تسرُّب. نصف تصميم الحلقة هو تعريف “متى تتوقف.”

أربعة أشياء تُصمَّم قبل التشغيل

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

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

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

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

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

[ 1. تعريف الهدف ]  شرط انتهاء قابل للتحقق (مثال: اجتياز الاختبارات)
        |
        v
[ 2. ملف الذاكرة ]  العمود الفقري: منجَز / تالٍ / جُرِّب وفشل
        |
        v
[ 3. تشغيل الحلقة ] --- إيجاد عمل -> إرسال الوكيل -> نتيجة ---+
        ^                                                        |
        |                                                        v
[ 4. فصل المُتحقِّق ]  وكيل إنتاج ≠ وكيل حكم -------> [ اجتياز البوابة؟ ]
        |                                                        |
        |  فشل -> التكرار التالي                                 | نجاح
        +--------------------------------------------------------+
        |
        v
[ 5. الحد الأقصى ]  أقصى تكرار · ميزانية الرموز · الإغلاق -> توقف

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

تكلفتان: الرموز والانتباه

تصل فاتورة الحلقة بعملتين: الرموز وانتباه الإنسان. تشغيل واحد غير مراقب قد يحرق ملايين الرموز، والحالة الوحيدة التي يُبرِّر فيها ذلك هي حين تشتري تلك الرموز شيئاً أكثر قيمة من تكلفتها.

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

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

ما تعلَّمته ThakiCloud من حادثة الـ 700 دولار

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

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

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

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

اختيار الأداة: فرِّق بين الهدف والحلقة والجدول

أكثر ما نؤكد عليه عند تصميم الحلقات هو أنه حين يأتي طلب “كرِّر / آلِّم / استمر”، ابدأ باختيار الأداة المناسبة. الثلاثة آليات مختلفة.

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

تجاهل هذه الفروق يُفضي إلى حوادث. تراكم مراقبة 24 ساعة في حلقة بفاصل زمني يُفجِّر التكاليف. وضع التكرار في أوقات محددة ضمن وضع الهدف يتركه بلا معيار تقارب فيتخبَّط. لذا قبل البدء نطلب إجابة لـ: “هل هذا هدف أم حلقة أم جدول؟”

التطبيق على منصة ThakiCloud للذكاء الاصطناعي والتعلم الآلي على K8s

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

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

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

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

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

هندسة الحلقات ليست حلاً شاملاً. أقوى اعتراض هو أن ليس كل مهمة مسألة حلقة. إدخال سؤال آني أو تعديل ملف واحد قسراً في حلقة يُضيف تكاليف تصميم دون أي مكسب. الحلقات ذات قيمة فقط للعمل المتكرر والقابل للتحقق.

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

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

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

المصادر

• التغريدة الأصلية (التصميم قبل تشغيل الحلقة)
• Addy Osmani, “Loop Engineering”
• looper: أداة لتصميم حلقات الوكلاء مع بوابات مراجعة بصرية قبل التنفيذ
• awesome-agent-loops: مجموعة حالات استخدام /loop و/goal و/schedule