المراجعة والاختبار النهائي — ONNX Runtime

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

الدورة في لمحة

الوحدة	الجوهر الواجب حفظه
1. صيغة ONNX	صيغة تبادل لا محرّك؛ رسم موجّه من عُقد (Conv، Gemm، إلخ) وحوافّ (تنسورات)؛ opset هو العقد بين المُصدِّر والمحرّك
2. تصدير PyTorch	torch.onnx.export بتتبّع؛ dynamic_axes لكلّ محور متغيّر؛ input_names/output_names واجبة؛ eval() قبل التصدير
3. تصدير TensorFlow	tf2onnx من SavedModel/Keras؛ input_signature مقابل dynamic_axes؛ --inputs-as-nchw لتفادي Transpose زائدة
4. التحقّق العدديّ	np.allclose(rtol=1e-4, atol=1e-5)؛ عدّة إدخالات ممثّلة، لا واحدة؛ اتّفاق المهمّة (الصنف) هو المعيار الحقيقيّ
5. تحسين الرسم	دمج Conv+BN+ReLU، طيّ الثوابت؛ ORT_ENABLE_ALL افتراضيّ؛ optimized_model_filepath لحفظ الرسم المُحسَّن
6. التكميم	ديناميكيّ للنصّ، ثابت للرؤية؛ صيغة QDQ الموصى بها؛ معايرة Entropy أو Percentile؛ عتاد حديث ضروريّ لتحقيق المكسب
7. مزوّدو التنفيذ	الأسرع أوّلًا، CPU أخيرًا كضامن؛ فحص get_providers() واجب لتفادي الاعتماد الصامت؛ ذاكرة كاش TensorRT توفّر دقائق البناء
8. القياس المقارن	تسخين 20-50 استدلال؛ p50، p95، p99 بدل المتوسّط؛ عدّة أحجام حزم؛ onnxruntime_perf_test كأداة مرجعيّة
9. العمليّات غير المدعومة	رتّب المحاولات: opset، dynamo، إعادة كتابة، تقسيم، عمليّة مخصّصة؛ إعادة الكتابة تحلّ 70% من الحالات
10. التقديم في الإنتاج	جلسة مشتركة، معالجة قبلية مطابقة للتدريب، FastAPI مع lifespan؛ ONNX Runtime Web للنماذج الصغيرة في المتصفّح

الخيوط التي تعبر الدورة

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

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

الاعتماد الصامت هو العدوّ الأوّل في ONNX Runtime. ثلاث حالات كلاسيكيّة: CUDA يسقط بصمت إلى CPU، تكميم يعمل على نصف الرسم فقط، معالجة قبلية في الإنتاج لا تطابق التدريب. لا رسالة، لا خطأ، لا حتى تحذير في السجلّ. الفحص الصريح المُبرمَج (get_providers()، عرض عُقد الرسم بعد التكميم، توثيق المعالجة القبلية جنبًا إلى جنب مع النموذج) هو الحاجز الوحيد.

تصدير النموذج قرار تصميم، لا خطوة نهائيّة. نموذج يُبنى بذهنيّة «سيُصدَّر لاحقًا» يخلق مشاكل قابلة للتفادي: أشكال ديناميكيّة داخل forward، شروط بايثون على قيم تنسور، عمليّات مخصّصة C++. اعتمد التصدير المبكّر في مسار التطوير: أوّل تصدير في الأسبوع الأوّل، لا بعد أشهر. النماذج التي تُصدَّر بسهولة تُبنى، لا تُنقذ.

قائمة تحقّق التصدير الجاهزة

كلّ نموذج جديد يمرّ بهذه القائمة قبل أن يُعتَبر جاهزًا للإنتاج:

1. قبل التصدير: النموذج في eval()، الإدخال المرجعيّ ممثّل، شكل الحزمة 1، opset_version مطابق لمحرّك الإنتاج.
2. بعد التصدير: onnx.checker.check_model ينجح، إنشاء الجلسة ينجح، get_providers() يعرض المزوّدين المتوقّعين.
3. التحقّق العدديّ: np.allclose(rtol=1e-4, atol=1e-5) على 200 إدخال ممثّل، اتّفاق المهمّة > 99.9%.
4. التحسين: ORT_ENABLE_ALL مفعَّل، حفظ الرسم المُحسَّن، عدد العُقد يُظهر انخفاضًا في Netron.
5. التكميم (اختياريّ): معايرة على 200-500 عيّنة تمثيليّة، صيغة QDQ، اختبار الدقّة يُظهر خسارة ≤ 0.5 نقطة.
6. القياس: p50، p95، p99 على العتاد الإنتاجيّ، عدّة أحجام حزم، مقارنة مع PyTorch/TensorRT في جدول.
7. الخدمة: FastAPI مع lifespan، جلسة مشتركة، معالجة قبلية موثَّقة، نقطة /sante، سجلّ JSON منظّم.
8. الوثيقة: ملفّ README.md مع النموذج يُوثّق: مصدر التدريب، إصدار opset، معاملات المعالجة القبلية، مقاييس الأداء المرجعيّة.

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

اختبار الأربعين سؤالًا

يتضمّن الاختبار 40 سؤالًا موزّعة على الوحدات العشر: صيغة ONNX ومجموعات العمليّات، تصدير PyTorch وTensorFlow، التحقّق العدديّ، تحسين الرسم، التكميم، مزوّدو التنفيذ، القياس المقارن، العمليّات غير المدعومة، والتقديم في الإنتاج.

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

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

قبل أن تبدأ

استعِد الجدول أعلاه، واسأل نفسك عن كلّ سطر: «كيف سأرى أنّني مخطئ هنا؟». إن عرفت أن تُبيّن لماذا dynamic_axes ضروريّ حتى لو صدَّرت بحزمة 1، ولماذا التكميم الديناميكيّ يناسب النصّ أكثر من الرؤية، ولماذا get_providers() أهمّ من قائمة providers المُقدَّمة، ولماذا الحزمة الديناميكيّة تُحسّن الإنتاجيّة بدل التأخير، فأنت مستعدّ. حظًّا موفّقًا!

في الخلاصة

• الجودة قبل السرعة: تحقّق عدديّ على مئات الإدخالات الحقيقيّة، اتّفاق مهمّة > 99.9%.
• القياس بلا وهم: تسخين، نسب مئويّة، عدّة أحجام حزم، عتاد إنتاج.
• فحص صريح لكلّ اعتماد صامت: مزوّدو التنفيذ، دقّة التكميم، معالجة قبلية.
• الشهادة تُمنَح فورًا عند النجاح في اختبار الأربعين سؤالًا، ورقمها قابل للتحقّق. حظًّا سعيدًا.

الامتحان النهائي

هل أنت مستعدّ لاعتماد هذه الدورة؟

40 سؤالًا تُختار عشوائيًّا من بنك أسئلة الدورة · حدّ النجاح 70 % · شهادة PDF قابلة للتحقّق تُصدَر فورًا عند النجاح.

ابدأ الامتحان

يلزم تسجيل الدخول إلى حسابك في InSkillML مع اشتراك نشط. يمكنك أيضًا بدء الامتحان من دوراتي.