هندسة أداء الذكاء الاصطناعي: سلم أدلة الأداء من وحدة معالجة الرسومات إلى الإنتاج لاختناقات الاستدلال

لماذا لا يعد استخدام وحدة معالجة الرسومات تشخيصا للأداء

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

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

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

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

تظهر هذه الوضعية القائمة أولا على الأدلة نفسها في أدلة بنية Optijara التحتية ذات الصلة، بما في ذلك اختبار قبول مسار الذكاء الاصطناعي في RAN، واختبار قبول الانتقال من checkpoint إلى bundle في TensorRT Model Connect، ودليل Qwen3.8-27B QRAT. المبدأ هنا هو نفسه. حدد حزمة الأدلة قبل تغيير النظام. بالنسبة إلى منتجات الذكاء الاصطناعي المواجهة للبحث، يقترن هذا الانضباط أيضا مع تحديث Google لمكافحة البريد العشوائي في أغسطس وقائمة تحقق GEO، حيث تكون الادعاءات المدعومة بالمصادر أهم من درجة واحدة مرتبة.

سلم أدلة الأداء من Optijara (PEL)

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

المرحلة 1: أثر الطلب وعبء العمل

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

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

المرحلة 2: أدلة تنفيذ وحدة معالجة الرسومات والذاكرة

تسأل المرحلة 2 عما يفعله الجهاز والمضيف فعليا. تمنح وثائق CUDA النموذج الذهني للتنفيذ، وتسلسل الخيوط، وتسلسل الذاكرة، والمزامنة. يساعد Nsight Systems الفرق على فحص نشاط CPU، واستدعاءات CUDA API، ونوى GPU، وعمليات الذاكرة، والفجوات بينها على خط زمني واحد.

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

المرحلة 3: أدلة النوى والمعاملات

تنتقل المرحلة 3 من الخطوط الزمنية إلى المعاملات والنوى. يمكن لملف تعريف PyTorch أن يظهر مسارات المعاملات، ووقت CPU وCUDA، وسلوك الذاكرة، والآثار التي تكشف عمليات النموذج التي تهيمن على التشغيل. تهم تشخيصات PyTorch compile عندما يغير التقاط الرسم البياني أو الدمج أو سلوك الرجوع مسار التنفيذ. يدخل Triton إلى الصورة عندما يحتاج الفريق إلى فحص نوى مخصصة، وأشكال البلاطات، وحركة الذاكرة، والحد بين المنطق على مستوى Python والعمل على مستوى الجهاز.

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

المرحلة 4: أدلة جدولة محرك الاستدلال والذاكرة المؤقتة

تنظر المرحلة 4 إلى محرك الخدمة. تكشف أنظمة مثل vLLM مقاييس حول الطلبات، والرموز، وسلوك المجدول، وحالة الذاكرة المؤقتة، والاصطفاف. هذه الطبقة مهمة لأن خدمة LLM ليست مجرد تنفيذ للنموذج. فهي تشمل prefill وdecode والتجميع المستمر وقبول الطلبات وضغط KV cache ومزيج أطوال المطالبات والمخرجات والسلوك البارد والسلوك الدافئ وقرارات المجدول.

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

المرحلة 5: أدلة الخدمة الموزعة والسعة

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

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

مصفوفة قرار الاختناق للاستدلال في الإنتاج

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

قائمة تنفيذ: من تشغيل معيار الأداء إلى تغيير إنتاجي مقبول

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

الأدلة الخاصة بكل أداة: موضع كل مصدر في PEL

تدعم وثائق CUDA المرحلة 2 لأنها تمنح النموذج للخيوط والكتل وتسلسل الذاكرة والمزامنة وسلوك التنفيذ. يدعم Nsight Systems المرحلة نفسها من زاوية الخط الزمني، وخاصة عندما تحتاج الفرق إلى رؤية عمل CPU، ونوى GPU، وواجهات CUDA API، وعمليات الذاكرة، والفجوات معا.

يدعم ملف تعريف PyTorch المرحلة 3 بجعل السلوك على مستوى المعاملات مرئيا. يمكن أن تهم تشخيصات PyTorch compile عندما يغير المسار المترجم سلوك الرسم البياني أو الدمج أو مسارات الرجوع. يناسب Triton المرحلة 3 عندما لا تكفي المعاملات القياسية أو عندما يحتاج مسار نواة مخصصة إلى فحص. هذا لا يعني أن كل اختناق يستحق نواة مخصصة. يطلب PEL من الفرق إثبات أن الاختناق يعيش في تلك الطبقة أولا.

تلائم مقاييس vLLM المرحلة 4 لأن سلوك الخدمة يفسر غالبا أعراضا لا تستطيع المقاييس على مستوى GPU تفسيرها. يمكن لحالة المجدول، وسلوك الذاكرة المؤقتة، ومقاييس الطلبات، ومقاييس الرموز، والاصطفاف أن تظهر ما إذا كانت المشكلة في القبول أو التجميع أو prefill أو decode أو ضغط الذاكرة المؤقتة. يلائم NCCL المرحلة 5 عندما يكون الاتصال الموزع جزءا من مسار الخدمة.

ما تخطئ فيه الفرق عند تحسين استدلال GPU

معاملة الاستخدام كإجابة

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

تحسين رموز معيار الأداء بدلا من المهام المقبولة

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

تغيير التجميع دون حماية زمن التأخير في الذيل

يمكن للتجميع والتجميع المستمر أن يحسنا استخدام العتاد في بعض أعباء العمل. كما أنهما يتفاعلان مع وقت الطابور، وTTFT، وطول المخرج، وp99. قيم تغيير التجميع حسب نوع المهمة ونطاق التزامن، لا حسب الإنتاجية الإجمالية فقط.

تجاهل قدم الذاكرة المؤقتة وانجراف عبء العمل

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

التنميط بطرق تغير عبء العمل

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

التحفظات والمفاضلات: عمل الأداء نظام هندسي

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

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

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

PEL في الممارسة: تدفق أدلة موجز وملخص قابل للقراءة آليا

{
  "framework": "Optijara Performance Evidence Ladder",
  "stages": [
    {"stage": 1, "name": "request_trace", "signals": ["p50", "p95", "p99", "TTFT", "queue_time", "acceptance_rate"]},
    {"stage": 2, "name": "gpu_execution_memory", "signals": ["kernel_gaps", "memory_movement", "occupancy", "synchronization"]},
    {"stage": 3, "name": "kernel_operator", "signals": ["operator_time", "arithmetic_intensity", "bandwidth_pressure", "compile_path"]},
    {"stage": 4, "name": "serving_scheduler_cache", "signals": ["prefill", "decode", "KV_cache", "batching", "admission"]},
    {"stage": 5, "name": "distributed_capacity", "signals": ["collectives", "network_movement", "placement", "canary", "rollback"]}
  ],
  "acceptance_unit": "cost_per_accepted_task_under_workload_contract",
  "stop_conditions": ["reproduced_bottleneck", "owner_layer_identified", "acceptance_impact_visible", "rollback_threshold_defined"]
}

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