جاء serve-sim، الذي طوره Evan Bacon من فريق نواة Expo، ليواجه هذا الحائط مباشرة. وقد ذاع صيت هذه الأداة فعلياً عندما قدّمها المطور المستقل levelsio قائلاً إنها “تتيح رؤية تطبيق iOS الذي بناه Claude Code على Mac Mini في السحابة مباشرة عبر المتصفح في الوقت الفعلي”. وشعار serve-sim بسيط: “أمر npx serve الخاص بمحاكيات آبل”.

نظرة عامة

ما يجعل serve-sim مثيراً للاهتمام هو أنه ليس مجرد أداة لعكس الشاشة. فهذه الأداة تفتح قناتين في آن واحد: الأولى هي تدفق فيديو يرسل شاشة المحاكي إلى المتصفح، والثانية قناة تحكم تتيح للمتصفح أو للوكيل التفاعل مع المحاكي. بعبارة أخرى، تجعل “المشاهدة” و”التحكم” ممكنتين عن بُعد في آن معاً.

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

تصوير لبنية تحوّل شاشة المحاكي على خادم بدون واجهة رسومية إلى تدفق يصل إلى متصفح بعيد.

ما هو serve-sim

آلية عمل serve-sim أبسط وأذكى مما قد يبدو للوهلة الأولى. لا حاجة لتثبيت إضافة (plugin) خاصة في Xcode ولا لزرع كود قياس داخل التطبيق. بدلاً من ذلك، يشغّل serve-sim عملية مساعدة صغيرة مكتوبة بلغة Swift تلتقط الإطارات المرئية لمحاكي iOS المُقلع مسبقاً عبر واجهة simctl io التي توفرها آبل.

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

flowchart TB
    A[محاكي iOS مُقلَع] --> B[عملية مساعدة بلغة Swift]
    B --> C[التقاط الإطارات المرئية<br/>عبر simctl io]
    C --> D[تدفق فيديو MJPEG<br/>حتى 60 FPS]
    C --> E[قناة تحكم عبر WebSocket]
    D --> F[واجهة معاينة React في المتصفح]
    E --> F
    E --> G[سطر أوامر الوكيل<br/>نقر، إيماءات، دوران، كاميرا]
    F -.تحكم بشري.-> E
    G -.تحكم الوكيل.-> E

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

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

عتبة الدخول إلى serve-sim منخفضة. يكفي سطر واحد على جهاز Mac يحتوي على Node.js.

npx serve-sim

بعد التشغيل، يمكن مشاهدة المعاينة محلياً على http://localhost:3200. تدعم الأداة ثلاثة أنماط استخدام: محلياً، أو عبر الشبكة المحلية (LAN) من جهاز آخر على نفس الشبكة، أو على جهاز Mac بعيد مع نفق (tunnel) يتيح الوصول من أي مكان. حالة levelsio هي النمط الثالث تحديداً، حيث يعمل serve-sim على Mac Mini سحابي بدون واجهة رسومية بينما تجري المشاهدة عبر متصفح بعيد.

يُقدَّم دمج الوكلاء عبر مهارة وكيل (Agent Skill) منفصلة. هذه المهارة، الموجودة في skills/serve-sim ضمن المستودع، تعلّم Claude Code وCursor وCodex CLI وGemini CLI وأي مضيف آخر يطبّق معيار Agent Skills المفتوح كيفية التحكم في المحاكي عبر سطر الأوامر. وتشمل هذه القدرات النقر والإيماءات وأزرار الأجهزة الفعلية ودوران الشاشة وحقن مدخلات الكاميرا، إضافة إلى تمرير التدفق إلى نافذة المعاينة الخاصة بالمضيف.

ملاحظة حول إعادة الإنتاج

بيئة التنفيذ التي كُتب فيها هذا المقال هي جلسة معالجة دفعية بدون واجهة رسومية، حيث تشغيل Node.js محظور بموجب السياسة المتبعة، لذا لم يتسنَّ تشغيل npx serve-sim مباشرة والتقاط الشاشة فعلياً. وعليه، فإن الأوامر ووصف السلوك في هذا المقال مستندة إلى ما ورد في ملف README الخاص بالمستودع والمواد التعريفية الرسمية، دون اختلاق أي أرقام قياس أداء. يُنصح بالتحقق من مشهد بث المحاكي الفعلي وزمن الاستجابة الحقيقي عبر تشغيل الأمر أعلاه مباشرة في بيئة macOS مع محاكي Xcode مُقلَع.

دلالات على منتجات ThakiCloud

يبدو serve-sim للوهلة الأولى أداة موجهة لمطوري iOS، لكن خلفها يكمن تيار أوسع هو التطوير المصمم أصلاً للوكلاء (agent-native development).

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

عدسة ai-platform (بنية التنفيذ بدون واجهة رسومية). تكمن الجاذبية الحقيقية لـ serve-sim في عمله على جهاز Mac بعيد بدون واجهة رسومية. وفكرة البناء والبث على خادم بدون واجهة رسومية تشبه فلسفياً الطريقة التي تجدول بها منصة ai-platform من ThakiCloud أعباء العمل وتنفذها على Kubernetes دون الحاجة إلى واجهة رسومية. وأي خط أنابيب (pipeline) يُلحق فيه مشغّل macOS المطلوب لبناء تطبيقات iOS عند الطلب، يبني الوكيل عليه ويختبر تلقائياً، ثم يُبث النتيجة فقط إلى المستخدم البشري، يمكن أن يمتد إلى ما هو أبعد من التكامل المستمر (CI) نحو “ضمان جودة يقوده الوكيل”. وهذه بنية تجعل فيها البنية التحتية للتنفيذ بدون واجهة رسومية منخفضة التكلفة (ai-platform) ركيزة تدعم جدوى أتمتة الوكلاء اقتصادياً (Paxis).

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

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

أولاً، يستهدف serve-sim المحاكي وليس الجهاز الفعلي. وبما أنه محاكٍ لا جهاز مادي حقيقي، تبقى المشكلات التي تظهر فقط على الأجهزة الفعلية، كالكاميرا والحساسات وخصائص الأداء، خارج نطاق الاكتشاف. ويبقى القيد القديم قائماً: نجاح الاختبار على المحاكي لا يضمن نجاحه على الجهاز الفعلي.

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

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

مع ذلك، فإن اتجاه serve-sim واضح. لقد أرسى جسراً عملياً حقيقياً للانتقال من “مرحلة يكتفي فيها الوكيل بكتابة الكود” إلى “مرحلة يبني فيها الوكيل ويشغّل ويتحكم مباشرة في الشاشة للتحقق”. وأي فريق يريد تطوير تطبيقات جوّال بواسطة وكلاء ذكاء اصطناعي على سحابة بدون واجهة رسومية يمكنه فتح هذا العالم فوراً بسطر واحد هو npx serve-sim.

المصادر

• Evan Bacon. “serve-sim: The npx serve of Apple Simulators.” GitHub. https://github.com/EvanBacon/serve-sim
• @levelsio، تغريدة تعريفية بـ serve-sim. https://x.com/levelsio/status/2075328941317886210

نظرة عامة

إذا سبق لك تشغيل نموذج لغوي كبير محليا، فمن المرجح أنك رأيت تسميات مثل Q4_K_M وQ5_K_M وQ8_0. يتوقف معظم الناس عند فهم مفاده أن “Q4 يعني 4 بت، إذن لا بد أنه الأصغر والأسرع”، ثم يقومون بتحميل الملف وتشغيله مباشرة. لكن هذه التسمية تخفي أكثر مما تظهر. قلة قليلة من الناس فتحوا فعليا ملفا موسوما بـ Q4_K_M وتحققوا، مصفوفة تلو الأخرى، مما إذا كان ممتلئا حقا ببيانات ذات 4 بت.

هذا المقال موجه لقادة الهندسة، والممارسين المسؤولين عن تكلفة الاستدلال، والفرق التي تسعى لتقديم النماذج محليا (on-premises). قمنا بتحميل ملف GGUF لنموذج Qwen2.5-0.5B-Instruct على عدة مستويات تكميم، وقسنا أحجام الملفات الفعلية، وقمنا بتشريح ملف واحد من نوع Q4_K_M بشكل كامل مصفوفة تلو الأخرى. جاءت النتيجة مختلفة تماما عن الحدس. نوضح لماذا يهم فهم هذه الفجوة لتكلفة الخدمة وجودتها، وماذا يعني ذلك بالنسبة لبنية الاستدلال التحتية لدى ThakiCloud.

ولنذكر الخلاصة أولا: في ملف Q4_K_M الخاص بهذا النموذج، لم تشكل المصفوفات التي هي فعلا تكميم K رباعي البت (Q4_K) سوى 6.1 بالمئة من إجمالي سعة الأوزان، وكان عرض البت الفعلي للملف ليس 4 بل 6.16 بت. أي أن التسمية كانت أقرب إلى كذبة تقريبا.

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

GGUF هو صيغة نموذج أحادية الملف تستخدم في منظومة llama.cpp. يجمع ملف واحد بين البيانات الوصفية (البنية المعمارية، أداة تجزئة الرموز، المعاملات الفائقة) وأوزان جميع المصفوفات المكممة معا. النقطة الجوهرية هي أن كل مصفوفة يمكن أن تستخدم نوع تكميم مختلفا. لذلك فإن تسمية على مستوى الملف مثل Q4_K_M لا تشير إلا إلى “النوع السائد”، وليس إلى أن الملف بأكمله من ذلك النوع.

تنقسم أنواع التكميم في llama.cpp إلى فئتين رئيسيتين. الأولى هي الفئة القديمة (legacy) (Q4_0، Q5_0، Q8_0) التي تجمع 32 وزنا في كتلة واحدة. والثانية هي فئة تكميم K (Q4_K، Q5_K، Q6_K) التي تجمع 256 وزنا في كتلة فائقة واحدة (superblock). ولأن تكميم K يقسم المقياس (scale) والحد الأدنى داخل الكتلة الفائقة بشكل أدق، فإنه يقدم جودة أفضل من الفئة القديمة عند نفس عرض البت. الحرف K في Q4_K_M يشير إلى تكميم K هذا، بينما M يعني الإعداد المسبق “المتوسط” الذي يرفع بعض المصفوفات الحساسة إلى دقة أعلى (Q6_K).

بالنظر عن قرب إلى بنية الكتلة الفائقة، يتضح سبب كفاءة تكميم K الأعلى. على سبيل المثال، يخزن Q4_K 256 وزنا في 144 بايت. من ذلك، تشغل القيم النقية ذات 4 بت مساحة 256 × 4 بت = 128 بايت، أما البايتات الـ16 المتبقية فهي بيانات وصفية تقسم الكتلة الفائقة إلى 8 كتل فرعية وتعيد تكميم مقياس كل منها وحدها الأدنى بـ6 بت. بعبارة أخرى، القيم نفسها ذات 4 بت، لكن الاحتفاظ بمقاييس دقيقة لإعادة بنائها يقلل من الخطأ. وهذا يتباين مع Q4_0 القديم الذي يحتفظ بمقياس واحد فقط لكل 32 وزنا. لذا فإن عرض البت الفعلي لـ Q4_K هو 144 × 8 ÷ 256 = 4.5 بت، أكبر قليلا من 4 بت النقية، لكن الجودة أكثر استقرارا بكثير.

هناك قيد حاسم واحد هنا. لا يمكن استخدام تكميم K إلا عندما يكون عدد أعمدة المصفوفة (ne[0] بمصطلحات ggml) قابلا للقسمة على 256. والسبب أن الكتلة الفائقة تعمل بوحدات من 256. وإذا لم يتحقق هذا الشرط، فإن llama.cpp يعود بصمت إلى الفئة القديمة (غالبا Q5_0). هذه القاعدة الواحدة تفسر نتيجة تجربة اليوم بأكملها.

flowchart TB
    A["ملف GGUF (Q4_K_M)"] --> B["تحديد النوع لكل مصفوفة<br/>llama_tensor_get_type()"]
    B --> C{"هل عدد الأعمدة ne[0]<br/>قابل للقسمة على 256؟"}
    C -->|"نعم"| D["استخدام تكميم K<br/>Q4_K / Q6_K (كتلة فائقة 256)"]
    C -->|"لا"| E["العودة إلى الفئة القديمة<br/>Q5_0 (كتلة 32)"]
    B --> F["رفع الدقة للمصفوفات الحساسة"]
    F --> G["output.weight -> Q8_0<br/>attn_v.weight -> Q8_0<br/>ffn_down.weight -> Q6_K"]
    D --> H["تجميع عرض البت الفعلي"]
    E --> H
    G --> H
    H --> I["عرض البت الفعلي لكامل الملف = 6.16<br/>(التسمية 'Q4' = 4.0)"]

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

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

# 1) تثبيت أداة القراءة والتحميل
pip install gguf huggingface_hub

# 2) تحميل ملف واحد فقط من نوع Q4_K_M (أقل من 500 ميجابايت لأنه نموذج 0.5B)
hf download Qwen/Qwen2.5-0.5B-Instruct-GGUF \
  qwen2.5-0.5b-instruct-q4_k_m.gguf --local-dir ./gguf

فيما يلي الشيفرة الخاصة بفتح أنواع مصفوفات الملف المحمل. يحتوي رأس (header) ملف GGUF على اسم كل مصفوفة وأبعادها ورقم نوع ggml مباشرة، لذا فإن مجرد تجميع هذه القيم يكشف بالضبط ما الذي يملأ الملف فعليا.

from collections import Counter
from gguf import GGUFReader

r = GGUFReader("gguf/qwen2.5-0.5b-instruct-q4_k_m.gguf")
hist = Counter()
for t in r.tensors:
    hist[t.tensor_type.name] += 1
    # التحقق من النوع الفعلي لبعض المصفوفات التمثيلية
    if t.name in ("token_embd.weight", "output.weight",
                  "blk.0.attn_v.weight", "blk.0.ffn_down.weight",
                  "blk.0.attn_q.weight"):
        print(f"{t.name:26s} {t.shape} -> {t.tensor_type.name}")
print(dict(hist))

عدد البايتات لكل كتلة يأتي مباشرة من تعريفات ggml. فمثلا، يخزن Q4_K 256 وزنا في 144 بايت أي 4.5 بت لكل وزن، ويخزن Q6_K 256 وزنا في 210 بايت أي 6.5625 بت لكل وزن، بينما يخزن Q5_0 القديم 32 وزنا في 22 بايت أي 5.5 بت لكل وزن. وبجمع (عدد العناصر ÷ حجم الكتلة) × بايتات الكتلة لكل مصفوفة، يمكن حساب عرض البت الفعلي للملف بدقة.

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

أولا، أحجام الملفات. هذه هي القيم المقاسة فعليا لنفس النموذج بعد تحميله على 7 مستويات تكميم، مقارنة بالأصل بصيغة fp16 (1266 ميجابايت).

هناك ما يثير الغرابة بالفعل هنا. الفرق بين Q2_K (415 ميجابايت) و Q4_0 (429 ميجابايت) هو 14 ميجابايت فقط. خفضنا عدد البتات إلى النصف، لكن حجم الملف لم ينخفض تقريبا. بل إن Q4_K_M (491 ميجابايت) أكبر فعليا من Q4_0 (429 ميجابايت) ذي 4 بت النقية. بالنظر إلى الأسماء وحدها، هذه النتيجة غير مفهومة.

يتضح السبب الحقيقي عند فتح ملف Q4_K_M مصفوفة تلو الأخرى. فيما يلي توزيع الأنواع عبر 291 مصفوفة فيه.

على الرغم من تسمية Q4_K_M، لم يشكل تكميم K الحقيقي رباعي البت (Q4_K) سوى 6.1 بالمئة من إجمالي سعة الأوزان. وبدلا من ذلك، استحوذ النوع القديم Q5_0 ذو 5.5 بت على أكثر من النصف (54.9 بالمئة)، واستهلك Q8_0 ذو 8.5 بت نسبة 30 بالمئة. وعند حساب عرض البت الفعلي لكامل الملف، نحصل على 6.16 بت، أي أكثر من 1.5 ضعف الـ4 بت التي توحي بها التسمية.

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

• token_embd.weight (896 × 151936) -> Q5_0
• output.weight (896 × 151936) -> Q8_0
• blk.0.ffn_down.weight (4864 × 896) -> Q6_K
• blk.0.attn_v.weight (896 × 128) -> Q8_0
• blk.0.attn_q.weight (896 × 896) -> Q5_0

هل تلاحظ النمط؟ لم تظهر المصفوفات التي تحمل تكميم K (Q4_K، Q6_K) إلا حيث كان عدد الأعمدة ne[0] يساوي 4864، كما في ffn_down. والرقم 4864 قابل للقسمة على 256 (19 × 256). أما معظم المصفوفات الأخرى فعدد أعمدتها ne[0] يساوي 896، والرقم 896 غير قابل للقسمة على 256 (3.5 × 256). لذلك لم تتمكن هذه المصفوفات من استخدام تكميم K إطلاقا وعادت جميعها إلى الفئة القديمة Q5_0. وإذا أضفنا إلى ذلك رفع الدقة (Q5_0، Q8_0) للمصفوفات الحساسة للجودة مثل التضمين (embedding) والمخرجات وقيمة الانتباه (attention value)، نحصل على ملف موسوم بـ Q4_K_M لكن جوهره الفعلي كتل تتراوح بين 5.5 و8.5 بت.

هذا بالضبط مصدر عرض البت الفعلي البالغ 6.16. يحتوي هذا الملف على ما مجموعه 630 مليون وزن خاضع للتكميم، مخزنة في نحو 485 ميجابايت من البايتات. 485,452,288 بايت × 8 ÷ 630,167,424 وزنا = 6.16 بت لكل وزن. وبإضافة نحو 6 ميجابايت من البيانات الوصفية للملف وحشو المحاذاة (alignment padding)، تتطابق النتيجة تماما مع حجم الملف الفعلي البالغ 491 ميجابايت. وتطابق الحساب مع حجم الملف هو أيضا دليل على دقة قراءة أنواع المصفوفات.

هذا يفسر أيضا النقطتين الغريبتين في جدول أحجام الملفات. السبب في أن Q2_K (415 ميجابايت) أصغر بالكاد من Q4_0 (429 ميجابايت) هو أن مصفوفات التضمين والمخرجات في هذا النموذج الصغير تشكل حصة كبيرة من إجمالي الأوزان، وهي تبقى بدقة عالية عند أي مستوى تكميم. مهما خفضت عدد البتات، تبقى تكلفة ثابتة في القاع لا تنخفض. أما سبب كون Q4_K_M أكبر من Q4_0 النقي ذي 4 بت، فهو أن الإعداد المسبق M دفع ثمن رفع المصفوفات الحساسة إلى Q6_K وQ8_0 على شكل زيادة في حجم الملف. رقم التسمية أقل، لكن عرض البت الفعلي أعلى في الواقع.

وباختصار، أظهرت هذه التجربة من خلال القياس ثلاث حقائق. أولا، تشير التسمية على مستوى الملف إلى النوع السائد فقط ولا تضمن عرض البت الفعلي. ثانيا، في النماذج الصغيرة التي لا يكون فيها الحجم المخفي (hidden size) من مضاعفات 256، يتعطل تكميم K إلى حد كبير، مما يوسع الفجوة بين التسمية والجوهر. ثالثا، تشكل مصفوفات التضمين والمخرجات في النماذج الصغيرة حصة كبيرة من إجمالي السعة، وبمجرد الاحتفاظ بها بدقة عالية، تتضاءل بشكل كبير وفورات “التكميم الرباعي البت” المفترضة.

الدلالات على منتجات ThakiCloud

اقتصرت هذه التجربة على تشريح نموذج صغير واحد، لكن دروسها تنتقل مباشرة إلى بنية الخدمة الإنتاجية التحتية. تقدم منصة ai-platform التابعة لـ ThakiCloud النماذج لبيئات عملاء متنوعة فوق Kubernetes وجدولة موارد GPU القائمة على Kueue. وفي هذا السياق، فإن “أي تكميم نختار” ليس مسألة ذوق، بل قرار يحدد تخصيص ذاكرة GPU، وحجم الدُفعة (batch)، وفي النهاية التكلفة لكل رمز (token).

الثقة بالتسمية كما هي تخل بتخطيط السعة. إذا افترضت أن Q4_K_M يعني “4 بت، إذن ربع الحجم الأصلي” وخصصت ذاكرة GPU على هذا الأساس، فستجد، كما في التجربة أعلاه، أنه يستهلك فعليا نحو 40 بالمئة من الأصل، وتنفد فتحات الدُفعات أسرع مما هو متوقع. يهم هذا الأمر بشكل خاص في الخدمة متعددة المستأجرين (multi-tenant)، حيث يجب حشر العديد من النماذج الصغيرة بكثافة على عقدة واحدة. وهناك، فإن الفرق بين قياس عرض البت الفعلي فعليا والاكتفاء بالثقة بالتسمية ينعكس مباشرة على عدد النماذج التي يمكن للعقدة استيعابها. لهذا السبب بالتحديد نتحقق من ملفات GGUF مصفوفة تلو الأخرى عند بناء صور الخدمة (serving images). وبالنسبة للعملاء الذين يتطلبون استضافة ذاتية أو نشرا محليا أو سياديا على وجه الخصوص، تتحول عادة القياس هذه بدلا من الافتراض إلى ميزة تنافسية حقيقية من حيث التكلفة.

جعل هذا التحقق نفسه مهمة قابلة للتكرار هو دور Paxis. وPaxis هي منصة التحكم الخاصة بـ ThakiCloud للسحابة الأصلية للوكلاء (Agent-Native Cloud) التي تعمل فوق ai-platform، وتتعامل مع المهارات والأدوات والسياسات وسجلات التدقيق كموارد من الدرجة الأولى. فإذا تم تسجيل تجربة اليوم، أي تحميل ملف GGUF وتجميع أنواع المصفوفات وإطلاق تحذير عند تجاوز عرض البت الفعلي حدا معينا، كمهارة واحدة، فإنها تعمل في بيئة معزولة (sandbox) وتمر جميع النتائج عبر بوابات السياسات وسجلات التدقيق. وبدلا من أن يفتح شخص الملف يدويا في كل مرة يصل فيها نموذج جديد إلى السجل، يعمل هيكل معتمد (validated skeleton) تلقائيا. هكذا يترابط الاقتصاد الذي تخلقه الخدمة منخفضة التكلفة (ai-platform) مع التنسيق (Paxis) الذي يجعل تلك الخدمة قابلة للتكرار بأمان.

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

هناك بعض النقاط التي يجب توضيحها بشكل صريح.

أولا، هذه النتائج تقترب من حالة قصوى خاصة بنموذج Qwen2.5-0.5B الذي يبلغ حجمه المخفي 896. أما في النماذج الأكبر التي يكون فيها الحجم المخفي من مضاعفات 256 (مثل 4096 أو 8192)، فإن تكميم K يُطبق بشكل طبيعي، ويقترب عرض البت الفعلي لـ Q4_K_M كثيرا من التسمية، عند نحو 4.8 بت.

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

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

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

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

المصادر

• مستودع نموذج Qwen2.5-0.5B-Instruct-GGUF: huggingface.co/Qwen/Qwen2.5-0.5B-Instruct-GGUF
• وثائق التكميم في llama.cpp: github.com/ggml-org/llama.cpp
• تم قياس أحجام الملفات وتوزيعات أنواع المصفوفات وعروض البت الفعلية مباشرة من ملفات فعلية تم تحميلها من المستودع أعلاه.

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

نظرة عامة

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

أجابت ذاكرة الوكلاء حتى الآن على هذا السؤال في الغالب بمعايير وصفية: هل هذا مرتبط بالموضوع؟ هل هو بارز؟ هل يُلخَّص بشكل جيد؟ تجادل هذه الورقة، “Remember the Decision, Not the Description” (arXiv 2605.10870)، التي شارك في تأليفها باحث من Meta AI، بأن هذا المعيار نفسه خاطئ. هذا المقال موجّه للمهندسين والباحثين الذين يصممون وكلاء الذكاء الاصطناعي، وللفرق التي تحتاج إلى وضع ذاكرة طويلة المدى في الإنتاج. نلخّص هنا إعادة الصياغة الجوهرية للورقة والنتائج التجريبية الداعمة لها، ونستعرض كيف ينطبق هذا المبدأ على Paxis، منصة الوكلاء لدى ThakiCloud.

أين تكمن المشكلة

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

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

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

الفكرة الجوهرية: rate-distortion محوره القرار

ينقل المؤلفون هذه المشكلة إلى إطار نظرية المعلومات الخاص بـ rate-distortion. تتناول نظرية rate-distortion أصلاً مقدار التشويه (distortion) الناتج عن قدر معين من الضغط (rate)، والخطوة المحورية هنا هي إعادة تعريف التشويه نفسه. بدلاً من أن يكون التشويه خطأ إعادة بناء الإشارة، يُعرَّف كـ الخسارة في جودة القرار القابلة للتحقيق نتيجة الضغط (decision loss).

flowchart TB
    A["تاريخ تفاعل طويل<br/>(ميزانية ذاكرة ثابتة)"] --> B{"هل ندمج الموقفين؟"}
    B --> C["معيار محوره الوصف<br/>الصلة، البروز، جودة التلخيص"]
    B --> D["معيار محوره القرار<br/>هل تسبب الحالة المشتركة تعارضاً في القرار"]
    C --> E["الدمج إذا بدا الموقفان متشابهَين<br/>-> دمج سلوكَين متعارضَين في واحد"]
    E --> F["أخطاء قرار مستمرة"]
    D --> G["الفصل فقط عند إثبات تعارض القرار<br/>certified refinement"]
    G --> H["حدّ نسيان دقيق (exact forgetting boundary)<br/>+ حدود memory-distortion frontier"]
    H --> I["جودة قرار أفضل عند نفس الميزانية"]

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

يترتب على هذا التعريف أمران. أولاً، حد النسيان الدقيق (exact forgetting boundary)، الذي يحدد بدقة حدود ما يمكن نسيانه بأمان دون الإضرار بجودة القرار. ثانياً، حدود memory-distortion frontier، التي تصف منحنى المفاضلة الأمثل بين ميزانية الذاكرة وجودة القرار. بعبارة أخرى، تضع الورقة نظرياً حداً أدنى مفاده: “إذا خفّضت الميزانية بهذا القدر، فستنخفض جودة القرار حتماً بمقدار لا يقل عن كذا”.

DeMem: تحويل النظرية إلى خوارزمية

DeMem هي التي تنقل هذه النظرية إلى ذاكرة وكيل فعلية قائمة على الخانات (slots). DeMem خوارزمية تعلّم ذاكرة عبر الإنترنت (online)، وتعمل وفق مبدأ واحد: لا تُقسِّم قسمة الذاكرة (partition) إلا عندما تُثبت البيانات (certify) أن حالة مشتركة تسبب تعارضاً في القرار.

كلمة “تُثبت” هنا مهمة. لا يُفصل الموقفان بمجرد أن يبدوا مختلفَين، بل يُفصلان فقط بعد أن تتراكم أدلة فعلية على أن نفس حالة الذاكرة تتطلب قرارَين مختلفَين. وعلى العكس، إذا لم تتوفر مثل هذه الأدلة، يُبقى على الدمج توفيراً للميزانية. هذا التحفظ هو جوهر الطريقة. الفصل المتسرع يهدر الميزانية ولا يترك مكاناً للتمييزات المهمة فعلاً، بينما الدمج المتسرع يطمس سلوكيات متعارضة. certified refinement هو الانضباط الذي ينتظر، بين هذين الحدين، حتى تتحدث البيانات. يثبت المؤلفون أن هذا الإجراء يحقق ضماناً من نوع near-minimax regret، أي أن الندم (regret) بالمقارنة مع الأمثل يظل، حتى في أسوأ الحالات، مقيداً قريباً من الحد النظري.

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

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

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

استمرت النتائج في معايير القياس الفعلية أيضاً. فيما يلي القيم المقاسة للدرجة الإجمالية على LoCoMo (بنموذج GPT-4.1-mini الأساسي).

حقق DeMem أفضل درجة إجمالية، وكان قوياً بشكل خاص في فئات Temporal وOpen-Domain وMulti-Hop، حيث يكون الحفاظ على التمييز بين تفاعلات بعيدة زمنياً أمراً حاسماً. أما في فئة Single-Hop، التي تتعلق باسترجاع حقيقة واحدة، فقد تفوّق Mnemis (0.940) على DeMem (0.935) بفارق ضئيل، وهو ما يتفق مع تفسير أن فائدة الفصل المحوري بالقرار تكون أصغر في الاسترجاع أحادي الخطوة. وفي LongMemEval أيضاً، حقق DeMem أفضل متوسط درجات على كلا النموذجَين الأساسيَين، وكانت أكبر المكاسب في الفئات التي تتطلب دمجاً عبر جلسات متعددة. والأهم أن الأفضلية استمرت حتى على النموذج مفتوح الأوزان Llama-3.1-70B، مما يدل على أن هذه الميزة ليست مرتبطة بنموذج تجاري معين.

دلالات على منتجات ThakiCloud

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

أولاً، يمكن نقل معيار الدمج في محرك معرفة HKE Wiki ليصبح محورياً بالقرار. إذا دُمجت العناصر المتشابهة بمجرد التشابه النصي، فهناك خطر أن تُدمج حالتان تتطلبان إجراءَين متعارضَين في واحدة. وضع بوابة قبل الدمج مباشرة تسأل “هل يسبب هذان الأمران سلوكَين مختلفَين؟” هو نقل مباشر لمبدأ certified refinement في هذه الورقة.

ثانياً، يمنح هذا أساساً نظرياً لإدارة ميزانية الذاكرة الساخنة المقيمة في الجلسة (session-resident hot memory). الذاكرة الساخنة تفرض بالفعل ميزانيتها بحد أقصى من الأحرف، ومحاذاة معيار ما يُبقى وما يُحذف مع مبدأ “الحفاظ على التمييزات المؤثرة في القرار” يرفع جودة التقليم (pruning). أي إعطاء الأولوية للعناصر التي تفرّق بين القرارات، لا العناصر التي تُلخَّص بسلاسة.

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

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

لا بد من توضيح بعض النقاط.

أولاً، الإثبات (certify) له تكلفة. إثبات تعارض القرار من البيانات يتطلب تراكم ملاحظات، وفي بيئات البداية الباردة (cold start) أو التفاعل النادر، يتأخر الفصل، ولذلك يصعب الحكم من نص الورقة وحده على مصير جودة القرار في المراحل المبكرة.

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

ثالثاً، يتضمن الملحق إثباتاً لصعوبة حسابية (computational hardness)، وهو ما يعني أن إيجاد القسمة (partition) المثلى صعب بشكل عام. DeMem هو تقريب عملي لذلك، وتلزم حدود إضافية حول الشروط التي ينهار عندها هذا التقريب.

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

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

المصادر

• الورقة: Remember the Decision, Not the Description: A Rate-Distortion Framework for Agent Memory (arXiv 2605.10870)
• معايير القياس: LoCoMo، LongMemEval / النماذج الأساسية: GPT-4o-mini، GPT-4.1-mini، Qwen2.5-14B-Instruct، Llama-3.1-70B
• الأرقام في الجدول مقتبسة من الجدول 1 (LoCoMo، GPT-4.1-mini) في الورقة.

تتناول الورقة البحثية “Single-Rollout Asynchronous Optimization for Agentic Reinforcement Learning” (arXiv 2607.07508)، التي نشرها باحثون من جامعة تسينغهوا وشركة Z AI في 8 يوليو 2026، هذه النقطة مباشرة. والخلاصة أن الباحثين تخلّوا عن “أخذ العينات الجماعي” (group sampling)، وهو جوهر GRPO الشائع الاستخدام. ولم يقتصر الأمر على تجربة هذا الأسلوب في تجارب الورقة فحسب، بل طبّقوه فعلياً في خط أنابيب حقيقي لتدريب النموذج المفتوح GLM-5.2 البالغ حجمه 750B.

نظرة عامة

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

تُشغّل ThakiCloud أيضاً خمس تقنيات لما بعد التدريب، هي SFT وCPT وDPO وGRPO وGKD، ضمن نظام تدريب نماذج اللغة الكبيرة المبني على kubeflow. لذلك فإن الثمن الذي يدفعه أخذ العينات الجماعي في GRPO عند التعامل مع rollouts طويلة، والمخاطر الجديدة التي قد يجلبها أي بديل يُزيل هذا الثمن، ليست قضية بعيدة عنا. يستعرض هذا المقال ما غيّرته SAO، وما تعنيه هذه التغييرات لمؤسسة مثلنا تسعى لتدريب وكلاء على عناقيد GPU متعددة المستأجرين (multi-tenant).

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

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

يجمع اسم SAO، كما هو، بين مفهومين: “rollout واحد” (single-rollout) و”التحسين غير المتزامن” (asynchronous optimization).

كانت خطوط أنابيب التعلّم المعزز التقليدية متزامنة (synchronous). تُحدَّد دفعة من الطلبات، ويُولَّد لكل طلب عدد من الـ rollouts، وعندما تكتمل جميعها تُحسَب المكافأة ويُنفَّذ تحديث واحد للسياسة. نجح هذا الأسلوب جيداً في المهام التي تُنتج إجابات قصيرة، لأن أطوال الـ rollouts كانت متقاربة.

لكن المشكلة تظهر في مهام الوكلاء. فمهمة برمجية واحدة قد تنتهي خلال 3 جولات فقط، بينما تستمر مهمة مجاورة في استدعاء الأدوات عبر 40 جولة. وفي خط الأنابيب المتزامن، تبقى بقية وحدات GPU عاطلة حتى ينتهي أبطأ rollout في الدفعة. ظهر التعلّم المعزز غير المتزامن أصلاً لإزالة هذا الهدر: يُحدَّث النموذج فور اكتمال كل rollout، بينما يستمر المولّد (generator) دون توقف في إنتاج الـ rollout التالي.

flowchart TB
    subgraph SYNC[GRPO المتزامن]
        A1[دفعة من الطلبات] --> A2[توليد G من الـ rollouts<br/>لكل طلب كمجموعة]
        A2 --> A3[الانتظار حتى اكتمال<br/>أبطأ rollout]
        A3 --> A4[حساب المكافأة النسبية للمجموعة<br/>تحديث واحد للسياسة]
        A4 -.توقف GPU.-> A2
    end
    subgraph SAO[SAO غير المتزامن]
        B1[توليد rollout واحد<br/>لكل طلب] --> B2[وصول فوري<br/>عند الاكتمال]
        B2 --> B3[كبح تحديثات off-policy<br/>عبر تقليم الرموز ثنائي الاتجاه]
        B3 --> B4[تحديث مستمر للسياسة]
        B4 --> B1
    end
    SYNC -->|إزالة حاجز المجموعة| SAO

هنا ينشأ التعارض الجوهري. فاسم GRPO (Group Relative Policy Optimization) يحمل معنى “النسبية الجماعية” منذ البداية. تُجمَع عدة rollouts لطلب واحد في مجموعة واحدة، وتُقارَن داخل هذه المجموعة الـ rollouts الأفضل نسبياً بالأسوأ لحساب الأفضلية (advantage). وميزة GRPO، التي هي في الوقت نفسه قيدها، أنها تُنتج إشارة التدريب من المقارنة داخل المجموعة فقط دون الحاجة إلى دالة قيمة (critic) منفصلة. فإن لم تكتمل المجموعة، يستحيل حساب الأفضلية. وهكذا يتعارض جوهرياً البناء غير المتزامن الذي يتعلّم فور وصول كل rollout مع GRPO الذي يفرض الانتظار حتى تكتمل المجموعة.

لماذا لا يتناسب GRPO مع التعلّم غير المتزامن؟

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

الأول هو الانتظار على مستوى المجموعة، وحينها تتلاشى ميزة اللاتزامن، وينتهي الأمر بالعودة فعلياً إلى النمط المتزامن الذي ينتظر أبطأ rollout.

والثاني هو توليد rollouts المجموعة الواحدة بسياسات (policies) مختلفة زمنياً. فإذا أنتجت سياسة قديمة بعض rollouts المجموعة، وأنتجت سياسة مُحدَّثة بعد بضع خطوات rollouts أخرى ضمن المجموعة نفسها، فإن تجميعها ومقارنتها نسبياً كمجموعة واحدة يصبح ملوّثاً إحصائياً من الأساس. فحين تتفاوت درجة off-policy من rollout إلى آخر، لكنها تُعامَل كأنها baseline واحد متجانس، يصبح التدريب غير مستقر.

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

ركيزتا SAO: rollout واحد وتقليم الرموز ثنائي الاتجاه

لكن إلغاء المجموعة يعني فقدان ما كانت GRPO تحصل عليه مجاناً. فالمقارنة داخل المجموعة كانت تلعب بحد ذاتها دور baseline يُقلّل التباين. وحين يكون هناك rollout واحد فقط، يختفي معيار المقارنة القائم على “هل تفوّق هذا الـ rollout على متوسط المجموعة؟”. فضلاً عن ذلك، في البنية غير المتزامنة تنشأ فجوة زمنية بين السياسة التي أنتجت الـ rollout والسياسة التي يُراد تحديثها الآن. وهذه الفجوة، أي مشكلة off-policy، هي الخطر الثاني الذي يهدد استقرار التدريب.

تتصدى SAO لمشكلة الاستقرار هذه عبر “تقليم صارم ثنائي الاتجاه على مستوى الرمز” (strict double-side token-level clipping). فالتقليم (clipping) الذي كانت تستخدمه عائلة PPO أصلاً هو آلية تقصّ التدرّج (gradient) عندما تخرج نسبة الأهمية (importance ratio) عن نطاق محدد. وتُطبّق SAO هذا التقليم على مستوى كل رمز (token) على حدة، وبصرامة في الاتجاهين الأعلى والأسفل معاً. فعند الرموز التي تباعدت فيها rollout السياسة القديمة كثيراً عن السياسة الحالية، يُكبَح التحديث بقوة، مما يمنع الإشارات ذات الفجوة الزمنية الكبيرة من إفساد التدريب.

ونتيجة هذا المزيج، تُفيد الورقة بأن SAO واصلت التدريب باستقرار على مدى 1,000 خطوة. وإذا أخذنا بعين الاعتبار أن حالات التباعد أو الانهيار شائعة في التعلّم المعزز غير المتزامن بعد تجاوز بضع مئات من الخطوات، فإن استقرار التدريب لـ 1,000 خطوة يُعدّ دليلاً داعماً للمزاعم الأساسية لهذه الطريقة.

النتائج الفعلية والتحقق

قارنت الورقة SAO بـ GRPO ومتغيراتها، وأفادت بتفوّقها باستمرار في معايير قياس الترميز والاستدلال الخاصة بالوكلاء. والمعايير المذكورة هي SWE-Bench Verified (حل مشكلات GitHub الحقيقية)، وBeyondAIME (رياضيات عالية الصعوبة)، وIMOAnswerBench (رياضيات بمستوى الأولمبياد). وتشترك المعايير الثلاثة في كونها مهام متعددة الخطوات وطويلة النَفَس، وليست إجابات قصيرة مباشرة، وهو بالضبط المجال الذي تستهدفه SAO.

أما التحقق الأكثر إقناعاً فليس في جداول المعايير، بل في واقعة النشر ذاتها. فقد استُخدِمت SAO في خط أنابيب فعلي للتعلّم المعزز للوكلاء لتدريب النموذج المفتوح GLM-5.2 (نموذج MoE بحجم إجمالي 750B وحجم فعّال 40B من المعاملات النشطة، 750B-A40B). وكون طريقة بحثية لم تبقَ حبيسة الورقة العلمية، بل استُخدِمت في تدريب إنتاجي لنموذج بحجم مئات المليارات، إشارة قوية على أن هذه الطريقة تصمد عند المقياس الحقيقي، لا في إعدادات تجريبية صغيرة فقط.

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

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

لا يقتصر درس SAO على كونه ورقة خوارزمية واحدة، بل يمسّ مباشرة طريقة تشغيل عناقيد GPU.

عدسة ai-platform (البنية التحتية لتدريب GPU). تجدول منصة ai-platform التابعة لـ ThakiCloud تدريب GPU متعدد المستأجرين فوق Kubernetes وKueue. ونظام تدريب نماذج اللغة الكبيرة المبني على kubeflow يدعم بالفعل GRPO كأحد تقنيات ما بعد التدريب. والسؤال الذي تطرحه SAO واضح: كم يتراجع معدل استغلال GPU في مهام تدريبنا بسبب التفاوت في أطوال الـ rollouts؟ ففي المهام المتفاوتة الطول كـ rollouts الوكلاء، يتحوّل انتظار المجموعة المتزامن إلى تكلفة مباشرة. وفصل توليد الـ rollouts غير المتزامن عن التدريب يتيح استخلاص خطوات تدريب فعّالة أكثر من العدد نفسه من وحدات GPU، وهو ما يشكّل رافعة مباشرة لخفض تكلفة التدريب لكل مستأجر في بيئة متعددة المستأجرين. كما أن التحقق مما إذا كانت جدولة gang scheduling وإدارة الطوابير في Kueue تفرض نمط “الانتظار حتى تكتمل المجموعة” يُعدّ نقطة تحسين عملية أخرى.

عدسة Paxis (نتاج تدريب الوكلاء). Paxis، وهي منصة Agent-Native Cloud التابعة لـ ThakiCloud، مستوى تحكّم يُشغّل المهارات (skills) في صناديق رملية معزولة (sandbox) ويمرّر كل سلوك عبر بوابات سياسات وسجلات تدقيق. والوكيل الذي تسعى SAO لتدريبه جيداً، أي وكيل يستدعي الأدوات عبر جولات متعددة ويُصلح قواعد الأكواد، هو بالضبط عبء العمل الذي تُشغّله Paxis. بل إن آثار الوكلاء (agent traces) الفعلية التي تُولّدها Paxis داخل الصناديق الرملية المعزولة يمكن أن تكون بحدّ ذاتها مصدر rollouts للتعلّم المعزز غير المتزامن على غرار SAO. وبذلك تكتمل حلقة: تُنتج ai-platform الـ rollouts وتدرّب عليها بتكلفة منخفضة، وتُشغّل Paxis الوكيل الناتج بأمان، لتُولّد بدورها بيانات تدريب جديدة. إنها بنية تقوم فيها بنية التدريب منخفضة التكلفة (ai-platform) بدعم جدوى الوكلاء الاقتصادية (Paxis).

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

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

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

ثانياً، التحقق عبر تدريب نموذج بحجم 750B مثير للإعجاب، لكن نجاحه عند هذا المقياس لا يعني أنه الأمثل بالضرورة في إعدادات المؤسسات الصغيرة. فخط الأنابيب غير المتزامن يتطلّب تعقيداً إضافياً في البنية التحتية لفصل المولّد عن المدرّب. وبالنسبة للفرق التي تُجري ضبطاً دقيقاً قصيراً بعدد محدود من الـ rollouts، قد يكون GRPO المتزامن أبسط وكافياً.

ثالثاً، توجد مقاربات نشطة في الاتجاه المعاكس أيضاً. فقد ظهرت في الفترة نفسها دراسة تتناول العلاقة بين staleness ومعدل التعلّم في RLHF غير المتزامن عبر قوانين تحجيم (scaling laws) (arXiv 2607.01083)، كما ظهرت مقاربات تُثبّت التدريب غير المتزامن عبر محاذاة التدرّجات (gradient alignment). ولذلك فالأدق أن نعتبر مبدأ SAO القائم على “إلغاء المجموعة وكبح ذلك بالتقليم” واحداً من عدة إجابات قوية محتملة على مسألة مفتوحة هي التعلّم المعزز غير المتزامن للوكلاء، لا الإجابة الوحيدة الصحيحة.

ومع ذلك، فإن إسهام SAO واضح. فقد حدّدت المشكلة بدقة (عدم كفاءة أخذ العينات الجماعي عند طول الـ rollouts)، وتحقّقت من الحل (rollout واحد مع تقليم ثنائي الاتجاه) عبر تدريب إنتاجي فعلي بمقياس مئات المليارات من المعاملات. وأي مؤسسة يمثّل فيها معدل استغلال GPU تكلفة التدريب مباشرة، لديها سبب وجيه لحساب المبلغ الذي يُهدَر في خط أنابيبها بسبب “انتظار المجموعة”.

المصادر

• Zhenyu Hou, Yujiang Li, Jie Tang, Yuxiao Dong. “Single-Rollout Asynchronous Optimization for Agentic Reinforcement Learning.” arXiv 2607.07508 (2026-07-08). https://arxiv.org/abs/2607.07508
• ذو صلة: “Staleness-Learning Rate Scaling Laws for Asynchronous RLHF.” arXiv 2607.01083. https://arxiv.org/abs/2607.01083

Source: RT @hangoo_kang: “TRACE: Capability-Targeted Agentic Training” got Spotlight @ ICML AIWILD 🎉 · twitter

What this means for ThakiCloud

This lines up neatly with what ThakiCloud has been building. Paxis conducts the agents; Metis retrains the ones that come up short. TRACE says: diagnose your failures and retrain just the weak spot. But those failure logs are among the most sensitive things a company owns. Ship them to someone else’s cloud to train on, and both the weakness and the fix leak out with them. That is the case for on-prem and for sovereignty: keeping your models, data, and infrastructure under your own roof. Fix your flaws at home and they stay home. For what it is worth, this very blog runs on a self-improvement loop that reviews its own misses and resharpens.

An auto-generated comic riffing on this week’s industry news.

serve-sim, built by Evan Bacon of the Expo core team, aims straight at that wall. It became widely known after indie developer levelsio showed it off, saying it let him “watch, in a browser, in real time, an iOS app that Claude Code built on a cloud Mac Mini.” Its slogan is simple: “npx serve for Apple Simulators.”

Overview

What makes serve-sim interesting is that it is not just a screen-mirroring tool. It opens two things at once: a video stream that sends the simulator screen to a browser, and a control channel that lets a browser or an agent operate the simulator. In other words, it makes both “watching” and “operating” possible remotely.

That combination matters because it completes the development loop for AI coding agents. An agent can fix code, build it, run it, look at the resulting screen, tap a button to move to the next step, and cycle through all of that without a human in the loop. This lines up exactly with what ThakiCloud’s Agent-Native Cloud, Paxis, is aiming for: agents doing real work inside isolated environments. That makes it worth a closer look at how one open-source tool implements that workflow.

A visualization of a headless server’s simulator screen becoming a stream that flows into a remote browser.

What serve-sim Is

The way serve-sim works is simpler and more clever than it sounds. There is no separate Xcode plugin to install, and no instrumentation code to embed in the app. Instead it spins up a small Swift helper process that captures the framebuffer of an already-booted iOS Simulator through Apple’s own simctl io interface.

The captured screen is exposed in two ways. First, it sends the video to the browser as an MJPEG stream at up to 60 FPS. Second, it opens a WebSocket control channel alongside it, so input from the browser side, taps and gestures, can be sent back to the simulator. On top of that sits a React-based preview UI, so a person can operate the app in the browser as if it were a real device.

flowchart TB
    A[Booted iOS Simulator] --> B[Swift helper process]
    B --> C[Captures framebuffer<br/>via simctl io]
    C --> D[MJPEG video stream<br/>up to 60 FPS]
    C --> E[WebSocket control channel]
    D --> F[Browser React preview UI]
    E --> F
    E --> G[Agent CLI<br/>tap, gesture, rotate, camera]
    F -.human operates.-> E
    G -.agent operates.-> E

The key point is that it targets “any booted simulator.” Since it requires no modification to the app, it can be attached to an existing project as-is. It can also forward simulator logs to the browser, so browser-use style MCP tools can read those logs to judge state. There is even a convenience feature where dragging a video or image into the browser window adds it as a file on the simulator device.

Installation and Use

The barrier to entry for serve-sim is low. On a Mac with Node.js, one line is enough.

npx serve-sim

Once running, you can view the preview at http://localhost:3200 locally. It supports three modes: using it locally, connecting from another device on the same LAN, or hosting it on a remote Mac and reaching it from anywhere through a tunnel. levelsio’s case is the third mode: running it on a headless Mac Mini in the cloud and viewing it through a remote browser.

Agent integration is provided as a separate Agent Skill. This skill, packaged at skills/serve-sim in the repository, teaches any host that implements the open Agent Skills standard, including Claude Code, Cursor, Codex CLI, and Gemini CLI, how to operate the simulator through the CLI. That includes taps, gestures, hardware buttons, screen rotation, injecting camera input, and handing the stream off to the host’s own preview window.

A Note on Reproduction

This post was written in a headless batch session with no GUI, where running Node.js is blocked by policy, so we were not able to run npx serve-sim directly ourselves and capture the screen. The commands and behavior described in this post are therefore based on facts confirmed in the repository README and the official announcement material, and we have not fabricated any benchmark numbers. Please verify the actual simulator streaming screen and latency yourself, on a macOS machine with a booted Xcode Simulator, using the commands above.

Implications for ThakiCloud Products

On the surface, serve-sim is a tool for iOS developers, but underneath it sits a much bigger trend: agent-native development.

Paxis lens (agent-native development). ThakiCloud’s Paxis is an Agent-Native Cloud control plane that runs skills in isolated sandboxes and passes every action through policy gates and audit logs. The open Agent Skills standard that serve-sim adopts is the same kind of contract model that Paxis’s skill harness handles. The idea that a single skill can give “tap, rotate, and read the screen of a simulator” capability to multiple agent hosts points in exactly the same direction as Paxis’s structure of selecting from 960-plus skills via BM25 and running them in isolation. In particular, workloads where an agent operates a real UI, like serve-sim’s control channel, need those operations to pass through policy gates and be recorded in audit logs before they can safely go into production. If serve-sim provides the “capability,” Paxis provides the layer that “safely governs” that capability.

ai-platform lens (headless execution infrastructure). What really makes serve-sim compelling is that it runs on a headless, remote Mac. The idea of building and streaming from a GUI-less server shares its philosophy with how ThakiCloud’s ai-platform schedules and runs workloads on Kubernetes without a GUI. A pipeline that attaches macOS runners on demand for iOS builds, lets an agent automatically build and test on top of them, and streams only the results back to a human, could extend beyond CI into “agent-driven QA.” It is a structure where low-cost headless execution infrastructure (ai-platform) underpins the economics of agent automation (Paxis).

Limits and Counterarguments

A few things deserve a sober look.

First, serve-sim targets the simulator. Because it is a simulator and not a physical device, issues that only surface on real hardware, camera, sensors, performance characteristics, still go uncaught. The old limitation that passing on the simulator does not guarantee passing on a real device remains unchanged.

Second, MJPEG streaming is simple and compatible but not very efficient at compression. Continuously streaming a 60 FPS, high-quality feed over a remote tunnel can turn bandwidth and latency into a bottleneck. For gesture testing where responsiveness matters, network round-trip delay translates directly into input lag.

Third, an agent being able to “see and operate” the screen is a separate matter from that judgment being correct. It remains entirely possible for an agent to misread the stream and tap the wrong button, and this is exactly why policy gates and human review are needed. The more capability a tool opens up, the more important the layer that governs that capability becomes.

Even so, serve-sim’s direction is clear. It has built a real bridge needed to move from “the agent only writes code” to “the agent builds, runs, and verifies by directly operating the screen.” If you are a team trying to develop mobile apps with agents from a headless cloud, you can open that world right now with a single line: npx serve-sim.

Sources

• Evan Bacon. “serve-sim: The npx serve of Apple Simulators.” GitHub. https://github.com/EvanBacon/serve-sim
• @levelsio, tweet introducing serve-sim. https://x.com/levelsio/status/2075328941317886210

Overview

If you have ever run an LLM locally, you have probably seen labels like Q4_K_M, Q5_K_M, or Q8_0. Most people stop at “Q4 means 4 bits, so it must be the smallest and fastest” and simply download the file and run it. But that label hides more than it reveals. Few people have actually opened a file labeled Q4_K_M and checked, tensor by tensor, whether it is really filled with 4-bit data.

This post is for engineering leaders, practitioners responsible for inference cost, and teams looking to serve models on-premises. We downloaded the GGUF file for Qwen2.5-0.5B-Instruct at several quantization levels, measured the actual file sizes, and fully dissected one Q4_K_M file tensor by tensor. The result was quite different from intuition. We explain why understanding this gap matters for serving cost and quality, and what it means for ThakiCloud’s inference infrastructure.

To state the conclusion up front: in this model’s Q4_K_M file, tensors that were genuinely 4-bit K-quantization (Q4_K) accounted for only 6.1 percent of total weight capacity, and the file’s effective bit width was not 4 but 6.16 bits. The label was, in effect, almost a lie.

What Is This Technology

GGUF is a single-file model format used in the llama.cpp ecosystem. A single file bundles metadata (architecture, tokenizer, hyperparameters) together with the quantized weights of every tensor. The key point is that each tensor can use a different quantization type. So a file-level label like Q4_K_M only indicates the “dominant type,” not that the entire file is that type.

llama.cpp’s quantization types broadly fall into two families. One is the legacy family (Q4_0, Q5_0, Q8_0), which groups 32 weights into one block. The other is the K-quantization family (Q4_K, Q5_K, Q6_K), which groups 256 weights into one superblock. Because K-quantization further subdivides and stores scales and minimums within the superblock, it delivers better quality than legacy at the same bit width. The K in Q4_K_M refers to this K-quantization, and M denotes the “medium” preset that raises some sensitive tensors to higher precision (Q6_K).

Looking a bit closer at the superblock structure reveals why K-quantization is more efficient. For example, Q4_K packs 256 weights into 144 bytes. Of that, the pure 4-bit values take up 256 x 4 bits = 128 bytes, and the remaining 16 bytes are metadata that splits the superblock into 8 sub-blocks and re-quantizes each sub-block’s scale and minimum to 6 bits. In other words, the values themselves are 4 bits, but by keeping the scales that reconstruct them finely grained, error is reduced. This contrasts with legacy Q4_0, which keeps only one scale per 32 weights. So the actual bit width of Q4_K is 144 x 8 / 256 = 4.5 bits, slightly more than pure 4 bits, but with much more stable quality.

There is one decisive constraint here. K-quantization can only be used when a tensor’s number of columns (ne[0] in ggml terms) is divisible by 256. This is because the superblock operates in units of 256. If this condition is not met, llama.cpp silently falls back to the legacy family (mostly Q5_0). This one rule explains the entire result of today’s experiment.

flowchart TB
    A["GGUF file (Q4_K_M)"] --> B["Determine type per tensor<br/>llama_tensor_get_type()"]
    B --> C{"Is column count ne[0]<br/>divisible by 256?"}
    C -->|"Yes"| D["Use K-quantization<br/>Q4_K / Q6_K (256 superblock)"]
    C -->|"No"| E["Fall back to legacy<br/>Q5_0 (32 block)"]
    B --> F["Raise precision for sensitive tensors"]
    F --> G["output.weight -> Q8_0<br/>attn_v.weight -> Q8_0<br/>ffn_down.weight -> Q6_K"]
    D --> H["Aggregate effective bit width"]
    E --> H
    G --> H
    H --> I["File-wide effective bpw = 6.16<br/>(label 'Q4' = 4.0)"]

Setup and Integration

The experiment can be reproduced without any extra dependencies. The Hugging Face API returns actual byte counts for file size, and you can read tensor types directly with the gguf reader.

# 1) Install the reader and downloader
pip install gguf huggingface_hub

# 2) Download just one Q4_K_M file (under 500MB since it's a 0.5B model)
hf download Qwen/Qwen2.5-0.5B-Instruct-GGUF \
  qwen2.5-0.5b-instruct-q4_k_m.gguf --local-dir ./gguf

Here is the code for opening the downloaded file’s tensor types. The GGUF header embeds each tensor’s name, dimensions, and ggml type integer directly, so aggregating just these values tells you exactly what the file is actually filled with.

from collections import Counter
from gguf import GGUFReader

r = GGUFReader("gguf/qwen2.5-0.5b-instruct-q4_k_m.gguf")
hist = Counter()
for t in r.tensors:
    hist[t.tensor_type.name] += 1
    # Check the actual type of a few representative tensors
    if t.name in ("token_embd.weight", "output.weight",
                  "blk.0.attn_v.weight", "blk.0.ffn_down.weight",
                  "blk.0.attn_q.weight"):
        print(f"{t.name:26s} {t.shape} -> {t.tensor_type.name}")
print(dict(hist))

Bytes per block come straight from ggml’s definitions. For example, Q4_K stores 256 weights in 144 bytes, so 4.5 bits per weight; Q6_K stores 256 in 210 bytes, so 6.5625 bits per weight; legacy Q5_0 stores 32 in 22 bytes, so 5.5 bits per weight. Summing (element count / block size) x bytes per block for every tensor gives you the exact effective bit width of the file.

Actual Experiment Results

First, file sizes. Here are the measured values for the same model downloaded at 7 quantization levels, compared against the fp16 original (1266MB).

Something odd already jumps out here. The difference between Q2_K (415MB) and Q4_0 (429MB) is just 14MB. We cut the bits in half, yet the file barely shrank. And Q4_K_M (491MB) is actually larger than pure 4-bit Q4_0 (429MB). Looking at the names alone, this makes no sense.

The real reason becomes clear once you open the Q4_K_M file tensor by tensor. Here is the type distribution across its 291 tensors.

Despite the Q4_K_M label, genuine 4-bit K-quantization (Q4_K) accounted for only 6.1 percent of total weight capacity. Instead, the 5.5-bit legacy type Q5_0 took up more than half (54.9 percent), and the 8.5-bit Q8_0 consumed 30 percent. Calculating the file’s overall effective bit width gives 6.16 bits, more than 1.5 times the 4 bits the label implies.

Checking representative tensors one by one makes the pattern clear. Here are the measured types:

• token_embd.weight (896 x 151936) -> Q5_0
• output.weight (896 x 151936) -> Q8_0
• blk.0.ffn_down.weight (4864 x 896) -> Q6_K
• blk.0.attn_v.weight (896 x 128) -> Q8_0
• blk.0.attn_q.weight (896 x 896) -> Q5_0

Do you see the pattern? Tensors carrying K-quantization (Q4_K, Q6_K) appeared only where the column count ne[0] was 4864, as with ffn_down. 4864 is divisible by 256 (19 x 256). Most other tensors, however, have ne[0] of 896, and 896 is not divisible by 256 (3.5 x 256). So these tensors could not use K-quantization at all and all fell back to legacy Q5_0. Layer this together with precision boosts (Q5_0, Q8_0) on quality-sensitive tensors like embeddings, output, and attention value, and you get a file labeled Q4_K_M whose actual substance is chunks of 5.5 to 8.5 bits.

Here is exactly where the effective bit width of 6.16 comes from. This file contains a total of 630 million weights subject to quantization, stored in roughly 485MB of bytes. 485,452,288 bytes x 8 / 630,167,424 weights = 6.16 bits per weight. Add about 6MB of file metadata and alignment padding, and it matches the actual file size of 491MB exactly. The fact that the calculation matches the file size is also evidence that the tensor type readout was accurate.

This also explains the two odd points in the file size table. Q2_K (415MB) is only barely smaller than Q4_0 (429MB) because, in this small model, the embedding and output tensors take up a large share of total weights, and they stay at high precision regardless of the quantization level. No matter how much you lower the bits, a fixed cost sits at the floor and does not shrink. And Q4_K_M is larger than pure 4-bit Q4_0 because the M preset paid for pulling sensitive tensors up to Q6_K and Q8_0 in file size. The label’s number is lower, but the effective bit width is actually higher.

To summarize, this experiment demonstrated three facts through measurement. First, a file-level label only indicates the dominant type and does not guarantee the effective bit width. Second, in small models whose hidden size is not a multiple of 256, K-quantization is largely disabled, widening the gap between label and substance. Third, in small models the embedding and output tensors take up a large share of total capacity, so keeping them at high precision significantly dilutes the savings that “4-bit quantization” is supposed to deliver.

Implications for ThakiCloud Products

This experiment only dissected one small model, but its lesson carries straight through to production serving infrastructure. ThakiCloud’s ai-platform serves models to diverse customer environments on top of Kubernetes and Kueue-based GPU scheduling. In that context, “which quantization to choose” is not a matter of taste, it is a decision that determines GPU memory allocation, batch size, and ultimately cost per token.

Trusting the label as-is throws off capacity planning. If you assume Q4_K_M means “4 bits, so a quarter of the original” and allocate GPU memory accordingly, you will find, as in the experiment above, that it actually takes up around 40 percent of the original, and batch slots run out faster than expected. This matters especially in multi-tenant serving, where many small models must be packed tightly onto a single node. There, the difference between measuring the effective bit width and simply trusting the label directly translates into how many models a node can hold. This is exactly why we verify GGUF files tensor by tensor when building serving images. For customers who require self-hosted, on-premises, or sovereign deployment in particular, this habit of measuring rather than assuming becomes a genuine cost advantage.

Making this verification itself a repeatable task is where Paxis comes in. Paxis is ThakiCloud’s Agent-Native Cloud control plane running on top of ai-platform, treating skills, tools, policies, and audit logs as first-class resources. If today’s experiment, downloading a GGUF file, aggregating tensor types, and flagging a warning when effective bit width exceeds a threshold, is registered as a single skill, it runs in an isolated sandbox and every result passes through policy gates and audit logs. Instead of having someone manually open a file every time a new model lands in the registry, a validated skeleton runs automatically. This is how the economics that low-cost serving (ai-platform) creates and the orchestration (Paxis) that makes that serving safely repeatable fit together.

Limitations and Counterarguments

A few things should be made explicit.

First, these results are close to an extreme case specific to Qwen2.5-0.5B, whose hidden size is 896. In larger models whose hidden size is a multiple of 256 (for example, 4096 or 8192), K-quantization applies normally, and Q4_K_M’s effective bit width lands much closer to the label, around 4.8 bits.

In other words, the correct lesson is not “the label is always a lie,” but that “the gap between label and substance varies greatly with model architecture, and is larger for smaller models.”

Second, a larger file size is not necessarily a bad thing. Keeping embedding and output tensors at high precision is a deliberate choice to prevent quality collapse in small models. In other words, this Q4_K_M is not a “badly made” file, but a reasonable result of automatically raising precision to protect quality in a small model. The cost simply does not show up in the label.

Third, this post only measured file structure and capacity, not actual inference quality (perplexity, benchmark scores). The relationship between bit width and quality requires a separate experiment, which we leave as the topic of a future post. What we can say here is only an operational principle: do not plan capacity and memory around the label, measure it.

The difference between just clicking run on a local model and knowing what is actually inside the file comes down to exactly this habit of measurement. Five minutes spent checking the numbers behind the label can change the accuracy of your entire serving cost plan.

Sources

• Qwen2.5-0.5B-Instruct-GGUF model repository: huggingface.co/Qwen/Qwen2.5-0.5B-Instruct-GGUF
• llama.cpp quantization documentation: github.com/ggml-org/llama.cpp
• File sizes, tensor type distributions, and effective bit widths were measured directly from actual files downloaded from the repository above.

📄 Full deep review (DOCX): Download the detailed peer review on Google Drive.

Overview

Anyone who has run a conversational agent for a long stretch has seen this failure before. A preference or decision a user clearly stated days ago gets forgotten at some point, and the agent acts against it. Context windows are finite, and once a conversation grows long enough, some part of the past must be compressed or discarded. The real question is what to discard.

Agent memory to date has largely answered this question with descriptive criteria: how relevant is it, how salient is it, how well can it be summarized. This paper, “Remember the Decision, Not the Description” (arXiv 2605.10870), co-authored by a researcher at Meta AI, argues that this criterion itself is the wrong one. This piece is written for engineers and researchers designing AI agents, and for teams who need to put long-term memory into production. We summarize the paper’s core reframing and the empirical results that back it up, and look at how this principle applies to Paxis, ThakiCloud’s agent platform.

What Is the Problem

The authors start from a simple insight. Memory is valuable to an agent not because it faithfully describes the past, but because it keeps two histories that call for different actions separated, even under a fixed budget.

Consider a simple example. Yesterday the user said, “This deployment must only proceed after manual approval.” Today, in a similar context, the user said, “This script can be run automatically.” The two statements look very similar on the surface. They share words like deployment, execution, approval, and if summarized they come out almost identical. A relevance-based memory is likely to merge the two into a single lump labeled “deployment-related instruction.” The moment that happens, the agent loses track of which instruction applies to which situation, and it commits the error of pushing through an automatic deployment that actually required manual approval. The summary is descriptively correct, but the merge is decisively fatal.

The concrete failure mode looks like this. Two situations look textually similar but actually demand opposite actions. When the memory budget is tight, compression is required, and compression inevitably invites merging. If you only look at descriptive similarity, the two get combined into one. As a result, the agent consistently makes the wrong decision every time it returns to that state. Relevance or summary quality cannot answer the real question, which is whether these two can be merged at all. The criterion should not be what looks similar, but what requires different actions.

Core Idea: Decision-Centric Rate-Distortion

The authors move this problem into the information-theoretic framework of rate-distortion. Rate-distortion theory originally deals with how much distortion arises for a given amount of compression (rate), and the key move here is redefining distortion itself. Instead of a reconstruction error of the signal, distortion is defined as the loss in achievable decision quality caused by compression (decision loss).

flowchart TB
    A["Long interaction history<br/>(fixed memory budget)"] --> B{"Merge the two situations?"}
    B --> C["Description-centric criterion<br/>relevance, salience, summary quality"]
    B --> D["Decision-centric criterion<br/>does the shared state cause a decision conflict"]
    C --> E["Merge if they look similar<br/>-> collapses opposing actions together"]
    E --> F["Persistent decision errors"]
    D --> G["Split only when a decision conflict is certified<br/>certified refinement"]
    G --> H["Exact forgetting boundary<br/>+ memory-distortion frontier"]
    H --> I["Better decision quality at the same budget"]

Here is an analogy. When compressing audio, we first discard frequencies the human ear cannot hear, because the criterion for distortion is “what a person can hear.” Agent memory should work the same way, the authors argue. What should be discarded is not “the memory that looks less relevant,” but “the memory that, if discarded, would not change future decisions.” Here, rate is the memory budget, and distortion is the decision loss that compression causes. If merging two situations into the same slot does not lead to any future decision going wrong, that merge is free. Conversely, if the merge collapses opposing actions into one, it is an expensive distortion.

Two things follow from this definition. First, the exact forgetting boundary, which precisely defines the boundary of what can safely be forgotten without harming decision quality. Second, the memory-distortion frontier, which characterizes the optimal trade-off curve between memory budget and decision quality. In other words, it theoretically pins down a lower bound of the form: “if you shrink the budget by this much, decision quality is guaranteed to drop by at least this much.”

DeMem: Turning Theory into an Algorithm

DeMem is what carries this theory into a real, slot-based agent memory. DeMem is an online memory learner that operates on one principle: it refines a memory partition only when the data certifies that a shared state causes a decision conflict.

The word “certifies” matters here. Two situations are not split apart the instant they merely look different; they are split only once evidence has actually accumulated that the same memory state requires different decisions. Conversely, if no such evidence exists, the merge is kept, saving budget. This conservatism is the heart of the method. Splitting too eagerly wastes budget, leaving no room for the distinctions that actually matter, while merging too eagerly collapses opposing actions. Certified refinement is the discipline of waiting, between these two failure modes, until the data speaks. The authors prove that this procedure satisfies a near-minimax regret guarantee, meaning that even in the worst case, regret relative to the optimum is bounded close to the theoretical limit.

The authors validate this mechanism at two levels. First, in a synthetic diagnostic environment, they design tasks where descriptive similarity and decisional similarity are deliberately made to diverge. There, description-only baselines keep merging situations that look alike, accumulating regret, while DeMem avoids this trap by refining only when a decision conflict is certified. Next, they check whether this advantage transfers to real long-horizon conversation benchmarks, across both proprietary and open-weight models. This structure, moving from theory through controlled mechanism validation down to real-world benchmarks, turns the results into an explanation of “why it wins,” not just a performance table.

Experimental Results

In the synthetic diagnostic, DeMem had the lowest cumulative regret among all budget-matched methods, and its advantage widened as the gap between descriptive and decisional similarity grew larger. While description-only baselines merged conflicting situations and produced persistent errors, DeMem avoided this by refining only when a decision conflict was certified.

The results carried over to real benchmarks as well. Below are the measured overall scores on LoCoMo (GPT-4.1-mini backbone).

DeMem posted the best overall score, and was particularly strong in the Temporal, Open-Domain, and Multi-Hop categories, where preserving distinctions across distant interactions matters most. In Single-Hop, which involves retrieving a single fact, Mnemis (0.940) narrowly edged out DeMem (0.935), which fits the interpretation that the benefit of decision-centric separation is smaller for one-shot retrieval. On LongMemEval as well, DeMem achieved the best average score on both backbones, with the largest gains in categories requiring cross-session integration. Notably, the advantage held even on the open-weight Llama-3.1-70B backbone, showing that this benefit is not tied to any particular proprietary model.

Implications for ThakiCloud’s Products

The insight of this paper connects directly with the memory design of Paxis, ThakiCloud’s Agent-Native Cloud control plane. Paxis is a control plane that runs on top of ai-platform and treats skills, tools, policies, and audit logs as first-class resources, and its knowledge engine and memory layer decide every day exactly what to merge and what to keep separate.

First, the merge criterion of the HKE wiki knowledge engine can be shifted toward being decision-centric. If similar items are merged purely by text similarity, there is a risk that two cases requiring opposite actions get combined into one. Gating the merge with the question “do these two cause different actions” is a direct translation of the paper’s certified refinement.

Second, this gives a theoretical basis for budget management in session-resident hot memory. Hot memory already enforces its budget through a character cap; aligning the criterion for what to keep and what to discard with “preserve the distinctions that affect decisions” raises the quality of pruning. It means prioritizing items that split decisions, not items that summarize smoothly.

Third, the policy gates and audit logs that Paxis leaves behind are a natural data source for proving after the fact that “the same state led to a different decision.” If it is impractical to run DeMem’s online certified refinement in real time, a practical path is to analyze these audit logs in offline batches and periodically update the merge and split policy. This is where the decision-centric memory principle and audit-based orchestration, which makes that principle safely repeatable, come together.

Limitations and Counterarguments

A few things should be made clear.

First, certification is not free. Certifying a decision conflict from data requires accumulated observations, and in cold-start or sparse-interaction settings, refinement is delayed, so it is hard to tell from the paper alone what happens to early-stage decision quality.

Second, estimating “decision quality loss” online in production requires a reward signal or a judge. Benchmarks have ground truth answers that make this signal easy to obtain, but how to secure this signal in real conversations without ground truth remains an open question. The audit-log approach suggested above could be one answer, but that is outside the scope of the paper.

Third, the appendix includes a proof of computational hardness, meaning that finding the optimal partition is generally a hard problem. DeMem is a practical approximation of that, and more bounds are needed on the conditions under which this approximation breaks down.

Even so, the principle itself, moving agent memory from description to decision, is simple and powerful, and worth considering for adoption right now. If an agent keeps forgetting its own past decisions, the problem may not be that its memory is too small, but that its memory is preserving the wrong thing.

📄 Full deep review (DOCX): Download the detailed peer review on Google Drive.

Sources

• Paper: Remember the Decision, Not the Description: A Rate-Distortion Framework for Agent Memory (arXiv 2605.10870)
• Benchmarks: LoCoMo, LongMemEval / Backbones: GPT-4o-mini, GPT-4.1-mini, Qwen2.5-14B-Instruct, Llama-3.1-70B
• Figures in the table are cited from Table 1 (LoCoMo, GPT-4.1-mini) of the paper.

A paper released on July 8, 2026 by researchers at Tsinghua University and Z AI, “Single-Rollout Asynchronous Optimization for Agentic Reinforcement Learning” (arXiv 2607.07508), confronts exactly this problem. The short version: the authors dropped “group sampling,” the core mechanism behind the widely used GRPO. And they did not leave this idea confined to a paper’s experiments section. They put it into the actual pipeline used to train GLM-5.2, a 750B-scale open model.

Overview

This paper matters right now because the cost bottleneck in training has shifted from algorithms to infrastructure utilization. Plenty of loss functions already exist to make models smarter. The real problem is that even with hundreds of GPUs wired together, most of the time it takes to produce a single training step is spent waiting.

ThakiCloud also runs five post-training techniques (SFT, CPT, DPO, GRPO, GKD) on our kubeflow-based LLM training system. So the price GRPO’s group sampling pays on long rollouts, and the new risks that arise from the alternative that removes that price, are not someone else’s problem. This post lays out what SAO changed, and what that change means for organizations like ours trying to train agents on multi-tenant GPU clusters.

A visualization contrasting single rollouts arriving continuously, one after another, against rollouts frozen in a queue while waiting for the rest of a group to arrive.

What Is This Technology

As the name suggests, SAO combines two ideas: “single-rollout” and “asynchronous optimization.”

The standard RL pipeline used to be synchronous. You fix a batch of prompts, generate multiple rollouts per prompt, wait until every rollout in the batch finishes, compute the rewards, and perform a single policy update. This worked fine for tasks that generate short answers, because rollout lengths were roughly uniform.

The problem is agentic tasks. One coding task finishes in 3 turns; the task next to it runs 40 turns, calling tools the whole way. A synchronous pipeline idles the rest of the GPUs until the slowest rollout in the batch finishes. Asynchronous RL emerged to eliminate this waste: the moment a rollout completes, the model is updated immediately, and the generator never stops, moving straight on to the next rollout.

flowchart TB
    subgraph SYNC[Synchronous GRPO]
        A1[Prompt batch] --> A2[Generate G rollouts<br/>per prompt as a group]
        A2 --> A3[Wait for<br/>the slowest rollout]
        A3 --> A4[Compute group-relative reward<br/>single policy update]
        A4 -.GPU idle.-> A2
    end
    subgraph SAO[SAO Async]
        B1[Generate 1 rollout<br/>per prompt] --> B2[Arrives immediately<br/>upon completion]
        B2 --> B3[Suppress off-policy updates<br/>via double-side token clipping]
        B3 --> B4[Continuous policy updates]
        B4 --> B1
    end
    SYNC -->|Remove the group barrier| SAO

Here a fundamental conflict emerges. GRPO (Group Relative Policy Optimization) is “group-relative” by name. It bundles multiple rollouts for a single prompt into a group, and computes advantage by comparing the relatively better and worse rollouts within that group. Making learning signal from nothing but intra-group comparison, with no separate value function (critic), is both GRPO’s strength and its shackle. Without a full group, you cannot compute an advantage. An asynchronous structure that learns from rollouts as they arrive, and GRPO’s requirement to wait until the group fills, are fundamentally at odds.

Why GRPO Doesn’t Fit Asynchronous Training

Let’s look at this conflict more concretely. To preserve groups in an asynchronous pipeline, you are forced into one of two bad choices.

First, you could wait group by group. But then the benefit of asynchrony disappears. You end up back at synchronous training, waiting for the slowest rollout.

Second, you could let the rollouts within a group be generated by policies from different points in time. If one rollout in a group was produced by an old policy and another by a policy updated several steps later, grouping them together for relative comparison is statistically contaminated from the start. The degree of off-policy drift differs rollout by rollout, and treating them as a single shared baseline while ignoring that difference destabilizes training.

SAO’s answer is simple. Remove the group entirely. Generate exactly one rollout per prompt, and the moment that single rollout arrives, use it for training right away. With the group barrier gone, the generator never waits, and GPU idle time drops sharply.

SAO’s Two Pillars: Single Rollout and Double-Side Token Clipping

But removing the group also removes something GRPO got for free. The intra-group comparison itself served as a variance-reducing baseline. With only one rollout, there is no longer a “did this rollout beat the group average” comparison to lean on. On top of that, in an asynchronous structure, a time lag opens up between the policy that produced the rollout and the policy currently being updated. This lag, the off-policy problem, is the second risk that can destabilize training.

SAO blocks this stability problem with what it calls “strict double-side token-level clipping.” The clipping used in the PPO family originally cuts the gradient when the importance ratio strays outside a certain range. SAO applies this at the token level, and strictly on both the upper and lower sides. Where a rollout produced by an old policy has drifted too far from the current policy at a given token, the update is strongly suppressed there, preventing a high-staleness signal from corrupting training.

The paper reports that this combination let SAO train stably for 1,000 steps. Given that asynchronous RL runs commonly diverge or collapse after a few hundred steps, 1,000 stable steps is solid evidence backing the method’s central claim.

Results and Verification

The paper compares SAO against GRPO and its variants, and reports consistent gains on agentic coding and reasoning benchmarks. The benchmarks named are SWE-Bench Verified (resolving real GitHub issues), BeyondAIME (hard math), and IMOAnswerBench (olympiad-level math). All three share a common trait: they are long-horizon, multi-step tasks rather than short one-shot answers, exactly the territory SAO targets.

The most convincing validation is not a benchmark table, but the deployment itself. SAO was put into the actual agentic RL pipeline used to train GLM-5.2, a 750B-A40B MoE open model with 40B active parameters. A research method that does not stay confined to a paper, but gets used in production training at hundreds-of-billions-of-parameters scale, is a strong signal that it holds up beyond toy settings.

That said, this post does not cite specific benchmark numbers. If we cannot reproduce the exact figures verified in the original paper here, the honest choice is to convey the method’s structure and the named benchmarks without inventing numbers. If you need the precise scores, please check the source paper directly.

Implications for ThakiCloud’s Product Lineup

SAO’s lesson reaches beyond a single algorithms paper, touching directly on how we operate our GPU clusters.

ai-platform lens (GPU training infrastructure). ThakiCloud’s ai-platform schedules multi-tenant GPU training on top of Kubernetes and Kueue. Our kubeflow-based LLM training system already supports GRPO as one of its post-training techniques. SAO raises a clear question: how much is our training jobs’ GPU utilization being eroded by variance in rollout length? For workloads with jagged lengths, like agentic rollouts, synchronous group waiting is a direct cost. Decoupling asynchronous rollout generation from training lets us extract more effective steps from the same GPUs, a direct lever for lowering the per-tenant cost of training in a multi-tenant environment. It is also worth checking whether Kueue’s gang scheduling and queue management inadvertently enforce the “wait until the group fills” pattern.

Paxis lens (the output of agentic training). ThakiCloud’s Agent-Native Cloud, Paxis, is a control plane that runs skills inside isolated sandboxes and routes every action through policy gates and audit logs. The target SAO is trying to train well, an agent that calls tools across many turns to fix a codebase, is exactly the kind of workload Paxis runs. Going further, the real agent traces Paxis generates inside its isolated sandboxes can themselves become a rollout source for asynchronous RL like SAO. In other words, a loop forms: ai-platform generates and trains on rollouts cheaply, and Paxis operates the resulting agents safely while producing more training data in the process. Low-cost training infrastructure (ai-platform) underpins agent economics (Paxis).

Limitations and Counterarguments

Before accepting this method uncritically, a few things need to be flagged.

First, single-rollout training gives up the variance reduction that groups used to provide. SAO compensates with clipping, but clipping is fundamentally a mechanism that cuts learning signal. Overly strict clipping can throw away valid gradients along with the noise, slowing training down. Where the balance point between “stability” and “training speed” lands likely varies by task and scale.

Second, validation on a 750B model is impressive, but that it works at that scale does not mean it is optimal for smaller organizations’ setups. An asynchronous pipeline requires separate infrastructure complexity to decouple the generator from the trainer. For a team doing short tuning runs with a handful of rollouts, synchronous GRPO may simply be simpler and sufficient.

Third, the opposite direction is also being actively explored. Around the same time, other work has treated the relationship between async RLHF staleness and learning rate as a scaling law (arXiv 2607.01083), and other approaches stabilize asynchronous training through gradient alignment. It is more accurate to view SAO’s “remove the group, hold the line with clipping” not as the one correct answer, but as one strong answer among several to the open problem of asynchronous agentic RL.

Even so, SAO’s contribution is clear. It identified the problem precisely (the inefficiency of group sampling on long rollouts), and validated its solution (single rollout plus double-side clipping) through actual hundreds-of-billions-scale production training. For any organization where GPU utilization is training cost, this is reason enough to calculate how much your own pipeline is burning by “waiting for the group.”

Sources

• Zhenyu Hou, Yujiang Li, Jie Tang, Yuxiao Dong. “Single-Rollout Asynchronous Optimization for Agentic Reinforcement Learning.” arXiv 2607.07508 (2026-07-08). https://arxiv.org/abs/2607.07508
• Related: “Staleness-Learning Rate Scaling Laws for Asynchronous RLHF.” arXiv 2607.01083. https://arxiv.org/abs/2607.01083

Expo 코어 팀의 Evan Bacon이 만든 serve-sim은 이 벽을 정면으로 겨냥합니다. 실제로 이 도구는 인디 개발자 levelsio가 “클라우드의 Mac Mini에서 Claude Code가 빌드한 iOS 앱을 브라우저로 실시간 확인할 수 있게 됐다”고 소개하면서 널리 알려졌습니다. serve-sim의 슬로건은 간단합니다. “Apple 시뮬레이터의 npx serve.”

개요

serve-sim이 흥미로운 이유는 단순한 화면 미러링 도구가 아니기 때문입니다. 이 도구는 두 가지를 동시에 엽니다. 하나는 시뮬레이터 화면을 브라우저로 보내는 영상 스트림이고, 다른 하나는 브라우저나 에이전트가 시뮬레이터를 조작하도록 하는 제어 채널입니다. 즉 “보는 것”과 “조작하는 것”을 모두 원격에서 가능하게 만듭니다.

이 조합이 중요한 이유는 AI 코딩 에이전트의 개발 루프를 완성하기 때문입니다. 에이전트가 코드를 고치고, 빌드하고, 실행한 뒤, 그 결과 화면을 보고, 버튼을 눌러 다음 단계로 넘어가는 전체 순환을 사람 없이 돌릴 수 있게 됩니다. ThakiCloud의 Agent-Native Cloud인 Paxis가 지향하는 “에이전트가 격리된 환경에서 실제 작업을 수행하는” 구조와 정확히 맞닿아 있어, 하나의 오픈소스 도구가 그 워크플로를 어떻게 구현하는지 살펴볼 가치가 있습니다.

헤드리스 서버의 시뮬레이터 화면이 스트림이 되어 원격 브라우저로 흘러 들어가는 구조를 형상화했습니다.

serve-sim은 무엇인가

serve-sim의 동작 원리는 생각보다 단순하고 영리합니다. 별도의 Xcode 플러그인을 설치하거나 앱에 계측 코드를 심을 필요가 없습니다. 대신 작은 Swift 헬퍼 프로세스를 띄워, 이미 부팅된 iOS 시뮬레이터의 프레임버퍼를 애플이 제공하는 simctl io 인터페이스로 캡처합니다.

캡처한 화면은 두 갈래로 노출됩니다. 첫째, MJPEG 스트림으로 브라우저에 최대 60 FPS의 영상을 보냅니다. 둘째, WebSocket 제어 채널을 함께 열어 브라우저 쪽에서 탭·제스처 같은 입력을 시뮬레이터로 되돌려 보냅니다. 그 위에 React로 만든 프리뷰 UI가 얹혀, 사람이 브라우저에서 실제 기기처럼 앱을 만질 수 있습니다.

flowchart TB
    A[부팅된 iOS 시뮬레이터] --> B[Swift 헬퍼 프로세스]
    B --> C[simctl io로<br/>프레임버퍼 캡처]
    C --> D[MJPEG 영상 스트림<br/>최대 60 FPS]
    C --> E[WebSocket 제어 채널]
    D --> F[브라우저 React 프리뷰 UI]
    E --> F
    E --> G[에이전트 CLI<br/>탭·제스처·회전·카메라]
    F -.사람이 조작.-> E
    G -.에이전트가 조작.-> E

핵심은 “어떤 부팅된 시뮬레이터든” 대상이 된다는 점입니다. 앱을 수정할 필요가 없으므로, 이미 있는 프로젝트에 그대로 붙일 수 있습니다. 게다가 시뮬레이터 로그를 브라우저로 전달해, browser-use 계열 MCP 도구가 그 로그를 읽어 상태를 판단하게 할 수도 있습니다. 브라우저 창에 영상·이미지를 드래그 앤 드롭하면 시뮬레이터 기기에 파일로 추가되는 편의 기능도 있습니다.

설치 및 사용

serve-sim의 진입 장벽은 낮습니다. Node.js가 있는 맥에서 한 줄이면 됩니다.

npx serve-sim

실행하면 로컬 http://localhost:3200에서 프리뷰를 확인할 수 있습니다. 로컬에서 쓰거나, LAN을 통해 같은 네트워크의 다른 기기에서 접속하거나, 원격 맥에 올려 두고 터널링으로 어디서든 접속하는 세 가지 모드를 지원합니다. levelsio의 사례가 바로 세 번째로, 클라우드의 헤드리스 Mac Mini에서 실행하고 원격 브라우저로 확인하는 방식입니다.

에이전트 통합은 별도의 Agent Skill로 제공됩니다. 저장소의 skills/serve-sim에 담긴 이 스킬은 Claude Code·Cursor·Codex CLI·Gemini CLI를 비롯해 오픈 Agent Skills 표준을 구현한 모든 호스트에게 시뮬레이터를 CLI로 조작하는 방법을 가르칩니다. 탭, 제스처, 하드웨어 버튼, 화면 회전, 카메라 입력 주입, 그리고 스트림을 호스트의 프리뷰 창으로 넘기는 동작까지 포함됩니다.

재현 참고

이 글을 작성한 실행 환경은 GUI가 없는 헤드리스 배치 세션으로, Node.js 실행이 정책상 차단되어 있어 npx serve-sim을 직접 구동해 화면을 캡처하지는 못했습니다. 따라서 이 글의 명령과 동작 설명은 저장소 README와 공식 소개 자료에서 확인한 사실에 근거하며, 벤치마크 수치를 지어내지 않았습니다. 실제 시뮬레이터 스트리밍 화면과 지연 시간은 macOS + Xcode 시뮬레이터가 부팅된 환경에서 위 명령으로 직접 확인하시기 바랍니다.

ThakiCloud 제품 적용 시사점

serve-sim은 표면적으로는 iOS 개발자용 도구지만, 그 아래에는 에이전트 네이티브 개발이라는 더 큰 흐름이 깔려 있습니다.

Paxis 렌즈 (에이전트 네이티브 개발). ThakiCloud의 Paxis는 스킬을 격리 샌드박스에서 실행하고 모든 행동을 정책 게이트와 감사 로그로 통과시키는 Agent-Native Cloud 제어 평면입니다. serve-sim이 채택한 개방형 Agent Skills 표준은 Paxis의 스킬 하네스가 다루는 것과 같은 계약 모델입니다. 하나의 스킬이 “시뮬레이터를 탭하고 회전시키고 화면을 읽는” 능력을 여러 에이전트 호스트에 공통으로 제공한다는 발상은, Paxis가 960개 이상의 스킬을 BM25로 선택해 격리 실행하는 구조와 정확히 같은 방향을 향합니다. 특히 serve-sim의 제어 채널처럼 에이전트가 실제 UI를 조작하는 워크로드는, 그 조작이 정책 게이트를 통과하고 감사 로그로 기록되어야 안전하게 프로덕션에 올릴 수 있습니다. serve-sim이 “능력”을 제공한다면, Paxis는 그 능력을 “안전하게 통제”하는 계층을 제공합니다.

ai-platform 렌즈 (헤드리스 실행 인프라). serve-sim의 진짜 매력은 헤드리스 원격 맥에서 동작한다는 점입니다. GUI 없는 서버에서 빌드하고 스트리밍한다는 발상은 ThakiCloud ai-platform이 Kubernetes 위에서 워크로드를 GUI 없이 스케줄링하고 실행하는 방식과 같은 철학입니다. iOS 빌드가 요구하는 macOS 러너를 온디맨드로 붙이고, 그 위에서 에이전트가 빌드·테스트를 자동으로 돌린 뒤 결과만 사람에게 스트리밍하는 파이프라인은 CI를 넘어 “에이전트 주도 QA”로 확장될 수 있습니다. 저비용 헤드리스 실행 인프라(ai-platform)가 에이전트 자동화(Paxis)의 경제성을 떠받치는 구조입니다.

한계 및 반론

몇 가지는 냉정하게 짚어야 합니다.

첫째, serve-sim은 시뮬레이터를 대상으로 합니다. 실제 물리 기기가 아니라 시뮬레이터이므로, 카메라·센서·성능 특성처럼 실기기에서만 드러나는 문제는 여전히 잡지 못합니다. 시뮬레이터 통과가 실기기 통과를 보장하지 않는다는 오래된 한계는 그대로 남습니다.

둘째, MJPEG 스트리밍은 단순하고 호환성이 좋지만 압축 효율이 높지 않습니다. 60 FPS 고화질 스트림을 원격 터널로 계속 흘리면 대역폭과 지연이 병목이 될 수 있습니다. 반응 속도가 중요한 제스처 테스트에서는 네트워크 왕복 지연이 그대로 조작 지연으로 이어집니다.

셋째, 에이전트가 화면을 “보고 조작”할 수 있게 되는 것과, 그 판단이 정확한 것은 별개입니다. 에이전트가 스트림을 잘못 해석해 엉뚱한 버튼을 누르는 실패는 여전히 가능하며, 이 지점이 바로 정책 게이트와 사람 검토가 필요한 이유입니다. 도구가 능력을 열어 줄수록, 그 능력을 통제하는 계층의 중요성이 커집니다.

그럼에도 serve-sim의 방향은 분명합니다. “에이전트가 코드만 쓰는 단계”에서 “에이전트가 빌드하고 실행하고 직접 화면을 조작하며 검증하는 단계”로 넘어가는 데 필요한 실질적인 다리를 하나 놓았습니다. 헤드리스 클라우드에서 모바일 앱을 에이전트로 개발하려는 팀이라면, 지금 바로 npx serve-sim 한 줄로 그 세계를 열어 볼 수 있습니다.

관련 슬라이드

본문 내용을 NotebookLM(neo_swiss 스타일)으로 요약한 슬라이드입니다.

출처

• Evan Bacon. “serve-sim: The npx serve of Apple Simulators.” GitHub. https://github.com/EvanBacon/serve-sim
• @levelsio, serve-sim 소개 트윗. https://x.com/levelsio/status/2075328941317886210