v0.4، فك ترميز مُخطط من غير التضحية بالـ hooks

معظم عمل فك token واحد هو تقرير ما لازم فعله، لا فعله. v0.4 أخرج داك القرار من الحلقة، من غير إخراج الـ hooks معه.

المشكلة: الحلقة تعيد تقرير كل شيء

ترك v0.3 الـ decode على المسار الأمامي المربوط العام: لكل token، لكل طبقة، يُعاد اكتشاف الشغل نفسه. أي tensor يقرأه هذا الإسقاط؟ أي kernel يتعامل مع dtype؟ أين يذهب المخرج؟ هل يستهدف أي hook هذي المرحلة؟ جمد عقد v0.4 (docs/v04-execution-contract.md) التسلسل المرجعي قبل لمسه، embedding، لكل طبقة RMSNorm → Q/K/V → RoPE → تخزين KV → attention → إسقاط المخرجات → residual → MLP → residual → norm نهائية → رأس، ثم سمّى الهدر (القسم 9): إعادة اكتشاف الشكل/التوزيع لكل token، فحوص hook ديناميكية ضد سجل، وتخصيص مساحة عمل لكل token.

لا شيء من داك الشغل يتغير بين الـ tokens. لا يحصل النموذج على معمارية جديدة عند الخطوة 42. الشيء الوحيد اللي يتغير لكل token هو الـ token نفسه.

قيد التصميم

كان بإمكان إصدار v0.4 أن يسلك الطريق المعتاد: أبقِ المسار العام، أضف مسارًا سريعًا بجانبه، وآمل أن يطابقه. حرم العقد داك بطريقتين. أولًا، قائمة خارج النطاق تشمل عدم وجود محرك خفي ثانٍ يتجاوز الـ hooks، مسار مُحسَّن ما يقدر الباحثون يربطوه مو تحسين؛ إنه برنامج آخر. ثانيًا، لا تُكرَّر الـ kernels: matvecs Q4_K/Q6_K العددية وAVX2 في v0.3 هي التنفيذات الوحيدة، ويحل مسار الخطة kernel لكل tensor عبر دالة resolve_kernel نفسها اللي يستخدمها المسار القديم، مع تأكيد المساواة بالاختبارات (قرار D6 في العقد).

القيد، بعبارة واحدة: خطط للعمل مرة واحدة لكل نموذج؛ نفّذه لكل token؛ أبقِ مواقع الـ hooks الدلالي الست تلاحظ الـ tensors نفسها بالضبط في مواقع النداء نفسها.

التنفيذ

• خطة تنفيذ غير قابلة للتغيير. تُبنى مرة واحدة فور التحميل، بواسطة خلفية النموذج اللي تملك الـ tensors. تخزن فهارس مستقرة وبيانات وصفية متحققة، لا مؤشرات خام، فالوصول الوزني هيكلي ولا ممكن يتدلى (D2). تحمل الخطة جدول الـ tensors وقوائم العمليات لكل طبقة وترتيب الـ scratch وترتيب KV وحل مواقع الـ hooks وقرارات التوزيع والمصدر (القسم 10، مخطط v04-plan/1). ember inspect-plan يطبعها؛ تشغيلات القياس تكتب execution-plan.json.
• ثلاثة مفاهيم تنفيذ. --execution reference يُبقي مسار v0.3 المربوط العام كمرجع مقروء؛ planned يشغّل التسلسل نفسه عبر مشغّل الخطة من غير fusion؛ planned-fused يطبق مجموعة الـ fusion المجمّدة (القسم 9). الثلاثة تبقى منفصلة للتحقق.
• ساحة scratch قابلة لإعادة الاستخدام. تخصيص محاذٍ واحد لكل جلسة decode، بحجم الخطة، بمحاذاة 64 بايت، مع مناطق مُثبت عدم تداخلها بالعمر وتقرير ساحة يذكر كل تداخل وبرهانه (القسم 11). حلقة الـ token في الحالة المستقرة لا تخصص شيء على الكومة.
• مجموعة fusion مجمّدة F1–F5. RMSNorm+إسقاط؛ residual+RMSNorm؛ تنسيق QKV؛ RoPE داخل attention؛ إسقاط المخرجات يتراكم في وجهة الـ residual (القسم 6). كل fusion يسمي ما يلغي وليش هو آمن واختبار التوازي اللي لازم يجتازه.
• defusion بقيادة الـ hooks. F5 يلغي tensor o المستقل، وهو موقع hook after_attention. إذا كان داك الـ hook نشطًا على طبقة، يختار المخطط المسار غير المدمج لتلك الطبقة، ويُسجَّل السبب في الخطة وفي المصدر (القسمان 6–7). لازم ألا يلاحظ الـ hook tensor دلاليًا مختلفًا بصمت عشان الـ fusion غيّر الرسم البياني.
• matvec متوازي الأعمدة. matvecs decode أحادية الصف الكبيرة تقسم بُعد المخرجات عبر تجمع rayon، كل عمود يتراكم مطابقًا للـ kernel التسلسلي، مطابق للبت بالاختبار (Gate A)، لا متساويًا تقريبًا.
• تنميط العوامل. bench-decode --profile-operators يسجّل توقيت كل عامل على المسار المخطط، فتُختار الخطوة التالية من جدول لا من تخمين.

لما أصبحت وحدة المعالجة شاهدًا غير موثوق

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

1. الضجيج الحراري جعل الـ fusion المدمج يبدو أبطأ. هذا الجهاز يشتغل بحاكم powersave، مسجّل في run_metadata لكل قياس (artifacts/benchmark-v03/bench-summary.json)، لذا فإن الـ tokens/ثانية المطلقة متغيرة حرارياً، ووقعت جلسات مدمجة مبكرة في نافذة خنق وبدت تراجعًا. الإصلاح بروتوكول لا كود: أذرع متتالية لكل نموذج حتى تشترك أوضاع التنفيذ كلها في حالة الجهاز، ووسطيات على 5 تكرارات مقاسة، لا مقارنات عبر الجلسات (artifacts/benchmark-v04/2026-08-04/SUMMARY.md).
2. وضع قياس نفّذ المسار المرجعي بالصدفة. يسجله الـ changelog بصراحة: "planned-fused نفّذ المسار المرجعي بصمت حتى قبل planned_decode_eligible الوضعَ" (CHANGELOG.md، v0.4 Fixed). علم يسمي وضع تنفيذ من غير ما يبوّبه علم يقدر الكذب.
3. اجتازت اختبارات الـ fusion من غير تشغيل المسار المقصود. إعادة بناء من نفس إدخال الـ changelog واختبارات التوازي (tests/k_parity.rs): اختبارات Gate B على مستوى النموذج لـ planned/fused موجودة وتجتاز، بس جلسة مدمجة طُلبت عبر CLI كانت تقدر السقوط إلى المسار المرجعي قبل الإصلاح، فمجموعة اختبارات خضراء بينما الوضع المسمّى لا يشتغل أبدًا. الاستجابة كانت بوابة الأهلية إضافة إلى اختبارات توازٍ تحدد وضع التنفيذ صراحةً وتؤكد الـ tokens الجشعة (k_parity.rs، v04_planned_matches_reference_real_model).
4. بوابة تخصيص اختبرت مسار trait محجوبًا. تعليق اختبار Gate E هو الدليل: "Trait path (ForwardModel) حتى يشتغل توزيع وضع التنفيذ v0.4؛ طريقة Llama الذاتية كانت ستحجبه" (tests/k_parity.rs). نداء طريقة ذاتية ممكن يتجاوز مشغّل الخطة بالكامل؛ اختبار التخصيص لم يعنِ شيء إلا بعد المرور عبر الـ trait اللي يوزّع فعلًا.
5. تشويه الجلسات المثبّتة على النوى. التثبيت على أربع نوى مادية يقلل من شأن matvec الأعمدة المتوازي، وهو ذراع الأداء. البروتوكول النهائي يشغّل الجهاز الكامل 8 الخيوط من غير taskset، والملخص يقول داك صراحةً (artifacts/benchmark-v04/2026-08-04/SUMMARY.md).
6. كشف تكرار الـ attention لاحقًا تخصيصًا زائفًا إضافيًا. بعد الإصدار، دمج تمرير إزالة التكرار الـ kernels الثلاثة المتكررة وأزال تخصيصات Vec لكل مهمة "قد تظهر كتخصيص زائف على خيط يسرق rayon" (الالتزام 624a216، main، 2026-08-04، بعد v0.4.0، لذا "لاحقًا"). أرقام Gate E كانت صحيحة؛ الحساب ما كان قد التقط كل موقع تخصيص لا يزوره إلا تجمع خيوط دافئ.

الخيط المشترك: كل واحد من هذي حالة يُقاس فيها الـ harness لا المحرك. المحرك الأسرع غير جدير بالثقة ما لم يُتحقق كمان من الـ harness ومن مسار التنفيذ الدلالي.

النتيجة المثبتة

سُجّلت البوابات A–G مسبقًا في العقد قبل التنفيذ (القسم 13) ومو ممكن إلا تشديدها:

• Gate A (توازي kernel/عملية)، مخرجات planned وfused مقابل المسار المرجعي المستقل، max_abs ≤ 1e-4، عبر بطارية الأشكال؛ الـ matvec المتوازي الأعمدة مطابق للبت للـ kernel التسلسلي (نفس ترتيب تراكم كل عمود)، وkernel توزيع الخطة يساوي التوزيع الديناميعشان القديم (تأكيد debug + اختبارات).
• Gate B (توازي النموذج)، reference/planned/planned-fused تنتج تسلسلات tokens جشعة متطابقة على الـ prompts الستة المجمّدة (إنجليزية + عربية) ضمن مغلفات logits المجمّدة، على المجموعات الأربع (tests/k_parity.rs، اختبار نموذج حقيقي بوابات env).
• Gate C (hooks)، المواقع الست تطلق في مواقع النداء نفسها بالمراحل والطبقات والأشكال نفسها على المسار المخطط؛ hooks غير نشطة مطابقة للبت للمعطلة؛ تدخل صفر-مخرجات-طبقة يهبط مطابقًا؛ planned-fused يفك F5 لما يكون after_attention نشطًا فيرى الـ hook tensor o ماديًا.
• Gate D (ذاكرة)، أوزان K-quant المضغوطة تبقى مقيمة عبر mmap على المسار المخطط؛ ذروة RSS reference 844,840 KB مقابل planned 847,952 KB على Llama-3.2-1B Q4_K_M في الإصدار (+0.37%)، والساحة المسماة هي الفرق كله.
• Gate E (تخصيص)، بعد الإحماء، حلقة decode المخططة لا تؤدي أكثر من 3 تخصيصات كومة لكل token، كلها تفصيل الـ logits الموثق (الشكل + الخطوات + البيانات)، مُتحقق عليها على نموذج حقيقي بالعداد المخصص (src/llama.rs، planned_decode_is_zero_steady_state_allocation).
• Gate F (أداء)، المصفوفة أدناه؛ كان السقف ≥1.75× على ≥3/4، تحقق على 4/4.
• Gate G (خارجي)، سلم golden لـ v0.3 محفوظ؛ planned وfused يعيدان إنتاج مخرجات reference الجشعة ضمن المغلفات، فينتقل توافق 100% في top-1 مع llama.cpp المثبّت بالتبعية.

مصفوفة زمن الإصدار (artifacts/benchmark-v04/2026-08-04/SUMMARY.md؛ decode 64 token، إحماء 1، 5 تكرارات، وسطيات، 8 خيوط، جهاز كامل):

هذا هو ادعاء "نحو 2.0–2.7×" بدقته: مقابل مسار v0.3 المرجعي على الثنائي نفسه، نفس البروتوكول، أربع مجموعات أولية. مو ادعاءً ضد llama.cpp، مصفوفة v0.4 لا تسجل ذراع llama.cpp، وصياغة العقد النهائية تكرر أنه لا توازٍ تنافسي يُدّعى ما لم يُظهره دليل غير متوقع (القسم 19).

أُعيد في 2026-08-04 من بناء tag v0.4.0 (sha الثنائي 23322cd3…، مسجّل في artifacts/benchmark-v04/2026-08-04/part4-reproduction.md)، Llama-3.2-1B Q4_K_M بنفس البروتوكول:

إعادة الإنتاج أعلى من مصفوفة الإصدار في tps المطلق (حالة الجهاز مختلفة؛ الإصدار شغل نفس البروتوكول على نفس الجهاز)، بس الشكل نفسه: ذروة RSS مسطحة عبر الأوضاع، وإنتاجية تتضاعف تقريبًا. أُعيد تشغيل المجموعات الثلاث المتبقية تحت نفس البروتوكول؛ قيمها في ملف الأدلة. المخرجات الدلالية الحتمية مو قابلية استنساخ زمنية، tokens متطابقة وhidden states متطابقة لا تعني أزمنة حائط متطابقة، وهو بالضبط ما يتحدث عنه قسم الشاهد غير الموثوق.

إيش اللي لا يشتغل بعد

• لازم الوضع المدمج يفك كل طبقة كلما احتاج hook tensor مدمجًا بعيدًا؛ الـ fusion امتياز تمنحه مجموعة الـ hooks، لا افتراضي.
• مسار Q8_0 السريع في v0.3 يحتفظ بالأولوية ولا يُمرَّر عبر الخطة أبدًا، ينطبق تسريع الخطة على المجموعات الأربع K-quant لا على كل مسار.
• اثنان من إخفاقات الشاهد الستة (مسار الـ fusion والـ trait المحجوب) مُعاد بناؤهما من الاختبارات والـ changelog وتاريخ git لا من تقرير مكتوب بعد الوفاة؛ إعادة البناء معلَّمة في النص وتستشهد بأدلتها.
• kernels العددية تبقى مرجعية بس؛ لا مسار ARM/NEON؛ attention لسه استعلامًا واحدًا في الـ decode.
• gemma 4 تبقى غير موثوقة رقميًا وخارج النطاق المخطط؛ "مدعوم" لسه مو معناه مُتحققًا golden.

إيش اللي أطلق هذا

آلات تجارب v0.5 تركب مشغّل الخطة: تحل مواصفات الالتقاط والتدخل إلى حل مواقع الـ hooks في الخطة، ومجموعة الـ fusion المجمّدة هي ما يستدل به سياسة defusion في v0.5. الـ token أصبح مُخططًا مرة واحدة؛ الإصدار التالي يجعل الخطة نفسها artifact ممكن التحقق منه ومقارنته واستنساخه من قبل شخص لا يقرأ Rust أبدًا.