تشغيل ASR الخاصة على Ascend 910B: الإعداد، التكيف مع المشغل والإنتاجية
دليل كامل على هبوط محرك الكلام الصيني إلى النص على وحدات Huawei Ascend NPU في مصفوفة إصدار بيئة خاصة مغلقة في الهواء ، وتحويل نموذج ONNX-to-OM ، وأوامر نشر الحاويات ، وستة مزالق ضربت على عمليات النشر الحقيقية ، وأرقام الأداء المرجعية.للمهندسين الذين يقومون بنشر ASR في بيئات Xinchuang.

يتناول هذا المنشور هبوط محرك الكلام الصيني إلى النص على وحدات NPU Huawei Ascend في بيئة خاصة - إصدارات البيئة ، وتحويل النموذج ، وأوامر النشر ، والمخاطر وأرقام الأداء المرجعية.
على الأرقام: الأرقام التي تحمل علامة "المواصفات" تأتي من المنتج المنشور المواصفات.يعطي جدول الأداء حجم المرجعية في ظل الظروف النموذجية ؛ تختلف القيم الفعلية مع ظروف الصوت وحجم النموذج واستراتيجية التزامب.قياس دائمًا على عبء عملك.
لماذا يجب تشغيله على الأجهزة المحلية
في الحكومة والتمويل والدفاع ، يجب ألا تكون الأنظمة "بيانات في الموقع" فحسب ، بل يجب أيضًا "اعتمادًا على الذات تكنولوجياً.وهذا يعني تحويل الحوسبة الأساسية من وحدات معالجة الرسومات المستوردة إلى رقائق Ascend, Cambricon, and Hygon المحلية ، ونظام التشغيل إلى Kylin و UnionTech والأنظمة المحلية الأخرى.
من الناحية الهندسية ، يصبح هذا ثلاثة قيود صعبة:
- إقامة البيانات - يحتوي صوت الاجتماع على مناقشة داخلية ، وتحظر العديد من المنظمات صراحة الصوت من مغادرة الإنترانت
- Xinchuang المشتريات - قد لا تظهر وحدات الرسومات المستوردة في قائمة الشراء المعتمدة على الإطلاق
- العملية الهوائية - بعض المواقع ليس لديها اتصال خارجي ، لذلك يجب تعبئة أوزان النموذج في البيئة مقدما
النقطة الأساسية: النشر المحلي يجيب على "أين البيانات" ؛ يجيب التوطين على "من يتحكم في التكنولوجيا.معاً يتقافون على مهمة واحدة - الحصول على ASR تشغيل على NPUs المحلية، وتشغيل بسرعة كافية.
مسرع مدعوم
مبني على أبحاث NEU NLP (جامعة الشمال الشرقية) ، يدعم محرك VoiVision أصليًا مسرعات التيار السائد:
| النوع | Representatives | استخدام |
|---|---|---|
| NVIDIA | T4 / L4 / A10 / A100 | عامة، عالية الأداء |
| Ascend | 310P / 910B | الخوادم المحلية المحلية |
| Cambricon | MLU370 / MLU590 | الخوادم المحلية المحلية |
| Hygon DCU | سلسلة DCU | مسار x86 المحلي |
| CPU فقط | x86 / ARM | إعادة استخدام الموجودة ، التزامن المنخفض |
تمتلك Ascend حاليًا النظام البيئي الأكثر اكتمالًا بين المسرعات المحلية (CANN + MindSpore + نموذج حيوان).يستهدف 910B التدريب والاستدلال العالي الإنتاجية ، في حين يستهدف 310P الحافة واستخدام الطاقة المنخفضة.بالنسبة للاجتماع المتزامن المستدام تفريغ الصوت ، فإن النمط الشائع هو 910B للاستدلال المركزي و 310P للعقد الحافة.
إعداد البيئة: محاذاة الإصدار هو أكبر فخ
الألم في Ascend النظام البيئي ليس حسابًا ، إنه مصفوفة الإصدار.برنامج التشغيل ، البرامج الثابتة ، CANN ، الإطار وتنسيق النموذج - أي واحد من الخمسة غير متزامنة ينتج فشلًا محيرًا.
مزيج نراه مستقرا عادة:
| المكون | Version | ملاحظة |
|---|---|---|
| برنامج التشغيل / البرامج الثابتة | ملزمة بإحكام إلى CANN | تحقق من جدول التوافق الرسمي قبل الترقية |
| CANN | سلسلة 8.x | مكتبة المشغل وأدوات تحويل النماذج تعيش هنا |
| حاوية | Ascend Docker وقت التشغيل | مطلوب - لا يمكن لـ Docker العادي تركيب NPU |
| إطار الاستدلال | أونكس وقت التشغيل + ACL | نماذج OM تعمل بشكل جيد دون MindSpore |
| OS | openEuler / Kylin V10 / UnionTech UOS | شائع في بيئات Xinchuang |
الخطوة الأولى هي دائمًا تأكيد أن NPU مرئي:
# List NPU devices and status
npu-smi info
# Expect a device list with 910B entries in a healthy state
# If the card is not visible here, nothing downstream matters — fix the driver first
المأزق: على بعض أنظمة Kylin V10 ، تبلغ npu-smi info عن خطأ في الوثيقة dmp مباشرة بعد تثبيت برنامج التشغيل.تبين أن السبب هو تعارض بين إصدار dkms الخاص بالنظام وبرنامج التثبيت.الإصلاح هو إزالة dkms النظام وإعادة التثبيت باستخدام الإصدار المرفق مع حزمة برنامج التشغيل. نادراً ما يتم توثيق قضايا التكيف على مستوى التوزيع مثل هذه وهي من بين الحاصرات الأكثر شيوعًا في الموقع.
تحويل الموديل: ONNX إلى OM
عادة ما يتم تدريب نماذج ASR في PyTorch ، وتصديرها إلى ONNX ، ثم تحويلها إلى تنسيق OM من Ascend.
ثلاثة أشياء يجب مراقبتها عند تصدير ONNX
torch.onnx.export(
model, dummy_input,
"asr.onnx",
opset_version=14, # Ascend supports lower opsets better — avoid the newest
do_constant_folding=True,
input_names=["audio", "audio_len"],
output_names=["logits"],
dynamic_axes={ # critical: audio length is variable
"audio": {0: "batch", 1: "time"},
"logits": {0: "batch", 1: "time"},
},
)
ثلاثة أماكن حيث يحدث هذا خطأ عادة:
- نسخة مضطربة - الأحدث ليس أفضل.تضرب إصدارات opset عالية المشغلين غير المدعومين في كثير من الأحيان أثناء التحويل ؛ 14 هو خيار تم اختباره جيدًا.
- المحاور الديناميكية - طول الصوت متغير بطبيعته ، لذلك يجب الإعلان عن
dynamic_axes، وإلا فإنك تقتصر على الإدخال ذي الطول الثابت والنتيجة غير قابلة للاستخدام في الإنتاج. - مطوي ثابت -
do_constant_folding=Trueيقلص بشكل ملحوظ الرسم البياني ويحسن نجاح التحويل.
التحويل مع ATC
atc --model=asr.onnx \
--framework=5 \
--output=asr_om \
--input_format=ND \
--input_shape="audio:-1,-1;audio_len:-1" \
--dynamic_dims="1,16000;1,32000;1,48000" \
--soc_version=Ascend910B \
--precision_mode=allow_fp16 \
--log=error
ما تعنيه المعلمات في الواقع:
--soc_version- يجب أن تتطابق مع الأجهزة المادية بالضبط.يفشل تحديد 910A على 910B في وقت التحميل مع خطأ غامض.--dynamic_dims- ملامح الشكل الديناميكي.بالنسبة للصوت ، الملف الشخصي حسب المدة ؛ يزيد عدد كبير جداً من الملفات الشخصية من وقت التجميع ، وعدد قليل جداً من المحفزات على إعادة التجميع المتكررة وتذبذب الكمون.--precision_mode-allow_fp16عادة ما تكلف دقة ضئيلة على ASR مع تحسين الإنتاجية بوضوح.
هل يجب أن تحدد الكم؟
| الدقة | الإنتاجية | الدقة |
|---|---|---|
| FP16 | خط الأساس | خط الأساس |
| INT8 | مكاسب واضحة | تكلفة ملحوظة |
الحكم: الحفاظ على FP16 حيث تكون الدقة حاسمة (الاجتماعات الطبية والقانونية) ؛ INT8 هي التجارة الأفضل حيث يكون التسامح مع الأخطاء أعلى ، مثل الوقوف الداخلي وتسجيلات التدريب.
النشر: الحاويات هي الخيار الوحيد المعقول
تثبيتات المعدن العاري لا يمكن صيانتها تقريبًا في مواقع Xinchuang.نحن نوصل الحاويات:
docker run -it --name asr_server \
--device /dev/davinci0 \
--device /dev/davinci_manager \
--device /dev/devmm_svm \
--device /dev/hisi_hdc \
-v /usr/local/Ascend/driver:/usr/local/Ascend/driver \
-v /data/models:/models \
-p 8000:8000 \
asr-server:910b \
./asr_server --model /models/asr_om --port 8000
- يعمل على المعادن العارية والسحابة الحكومية والبيئات المحلية ؛
- يتكامل مع OA وأنظمة الاجتماعات عبر واجهات برمجة التطبيقات RESTful / WebSocket القياسية ؛
- المقاييس مرنة عن طريق التزامن.
لاحظ إدخالات --device تلك: فقدان أي واحد منهم ينتج فشل في تهيئة ACL ، ولن يخبرك الخطأ أن الجهاز مفقود.هذه هي حجر العثرة الأكثر شيوعا للوافدين الجدد.
أيضا - لا تخترع بروتوكول خاص.استخدام REST القياسي (ملف تفريغ الصوت) و WebSocket (البث في الوقت الحقيقي) ، أو التكامل مع أنظمة OA والاجتماعات الخاصة بالعميل يصبح مؤلمًا.
إذا كان لديك بالفعل خوادم ، فقم بنشر software-only engine للحصول على تفريغ الصوت الخاصة على مسرعات محلية دون شراء الأجهزة.
الأداء المرجعي
شروط الاختبار: Ascend 910B ، FP16 ، الصوت الاجتماع الصيني ، 16 كيلو هرتز أحادي.
| متري | المرجع | ملاحظة |
|---|---|---|
| عامل الوقت الحقيقي (RTF) | ~0.1 أمر | ساعة واحدة من الصوت في بضعة محضر الاجتماع |
| تيارات متزامنة لكل بطاقة | عشرات | Pure تفريغ الصوت ، التزامن المستدام للاجتماعات |
| الكمون المميز الأول | فرع الثانية | وضع التدفق ؛ عادة أقل من 1 ثانية في الممارسة العملية |
| الصينية تفريغ الصوت دقة | ≥98٪ | سيناريوهات اجتماعات الماندرين القياسية (مواصفات) |
| تغطية اللهجة | 22 | الكشف التلقائي (مواصفات) |
المرفق الأول️ الرقم التزامن أعلاه هو تفريغ الصوت فقط (بطاقة ASR واحدة ، لا فصل المتحدثين أو هيكلة دقيقة). إن إضافة فصل المتكلم بالإضافة إلى استخراج الموضوع / عنصر الإجراء يقلل من سعة البطاقة الواحدة بشكل كبير - يتم تصنيف الجهاز في 10 اجتماعات متزامنة ، الذي يشير إلى خط الأنابيب الكامل (تفريغ الصوت + فصل + هيكلة) ؛ يتم تصنيف شكل العنقود في 50+ تيارات. اسأل دائمًا عن الطبقة التي يقتبسها البائع - تختلف الثلاثة عن طريق المضاعفات.
ستة مزالق من عمليات النشر الحقيقية
هذا هو الجزء الأكثر قيمة من المنصب.كل واحد من هؤلاء أصيب في الموقع.
1.الأشكال الديناميكية التي تسبب إعادة التجميع المستمرة بدون --dynamic_dims ، يؤدي كل طول صوت جديد إلى إعادة تجميع الرسم البياني وارتفاع الكمون إلى ثوانٍ.التنميط حسب المدة أعادته إلى أقل من ثانية.
2.الذاكرة الصوتية الطويلة المستنفدة تغذية تسجيل اجتماع لمدة ساعتين مباشرة في نموذج OOMs الجهاز.تحتاج إلى الاستدلال التزايدي المقطوع -segment بواسطة VAD وفك الشفرة قطاعاً بعد قطاع بدلاً من تحميل الملف بأكمله.
3.المشغلين غير المدعومين يفشلون بصمت A LayerNorm variant had no Ascend equivalent.لم يثير ATC أي خطأ أثناء التحويل ، وكان النموذج يخرج جميع الأصفار في وقت التشغيل. قم دائمًا بتشغيل فحص التكافؤ بعد التحويل: قم بتشغيل نفس الصوت من خلال وقت تشغيل ONNX (CPU) و OM (NPU) ومقارنة المخرجات.
4.تسربات السياق تحت التزامن متعدد الخيوط أنشأ الإصدار الأول سياق ACL منفصل لكل طلب وسياقات مستنفدة تحت التحميل.تجميع السياق أصلح ذلك.
5.يجب إعادة تحويل النماذج بعد ترقية سائق بعد ترقية CANN كبيرة ، قد تفشل طرازات OM القديمة في التحميل أو تفقد الأداء. ضع تحويل النموذج في CI بدلاً من التحويل يدويًا مرة واحدة.
6.التعبئة والتغليف غير المتصلة بالمواقع المفتوحة الهواء في البيئات المعزولة جسديًا ، يجب تعبئة اعتمادات CANN وبرامج التشغيل وأوزان النماذج والخطوط والشهادات جميعًا مسبقًا.وصلنا مرة واحدة إلى الموقع للعثور على خط CJK المفقود ، وعاد كل نص كصناديق توفو. تدرب على النشر الكامل على بيئة معادلة قبل شحن الحزمة غير المتصلة بالإنترنت.
متى لا تختار المسرعات المحلية
أن أكون مستقيمًا معك.تخطي ذلك إذا:
- لا يوجد Xinchuang أو تفويض التوطين → GPU النظام البيئي أكثر نضجا بكثير ، لا تجعل العمل لنفسك
- لا أحد في الفريق يعرف أن تكلفة عمليات CANN ستتجاوز بكثير كل ما توفره الأجهزة
- التنافس هو رقم واحد → عادي CPU يكفي، تخطي المسرع
المسرعات المحلية هي النداء الصحيح عندما: هناك تفويض واضح للامتثال + ضغط متزامن مستمر + القدرة الهندسية لدعمها.
نصائح الحجم
- مجموعة محلية جديدة: VV05 / VV10+ Ascend أو Cambricon مسرع ؛
- إعادة استخدام x86 الموجودة: محرك على CPU أو Hygon DCU ؛
- بيئة مختلطة: توحيد NVIDIA والمسرعات المحلية ، الجدول الزمني حسب التحميل.
إذا كنت توازن بين السحابة الخاصة ، فانظر on-premise ASR selection guide.
انظر إلى private deployment guide و MLPS Level 3 compliance.
الأسئلة الشائعة
Q: ما هي الرقائق المحلية التي تدعمها تفريغ الصوت؟
A: يدعم محرك VoiVision أصليًا Ascend (310P / 910B) و Cambricon (MLU370 / MLU590) و Hygon DCU وتشكيلة NVIDIA الكاملة ؛ كما أنه يعمل على CPU وحده ، مما يغطي المكدس المحلي والمحلي بأكمله.
Q: لماذا يجب على ASR تشغيل على المسرعات المحلية على الإطلاق؟
A: تتطلب البرامج الحكومية والمالية والدفاعية عادةً إقامة البيانات والامتثال للمشتريات في شينتشوانغ والتشغيل المفتوح الهواء في نفس الوقت.مجتمعة ، غالبًا ما تستبعد هذه وحدات معالجة الرسومات المستوردة تمامًا ، مما يترك وحدات NPU المحلية باعتبارها المسار الوحيد القابل للتطبيق.
Q: ما هي نقاط الفشل الشائعة في تحويل ONNX إلى Ascend OM؟
A: ثلاثة أهمها: إصدار opset مرتفع جدًا مما يسبب مشغلين غير مدعومين (14 هو خيار آمن) ، وإعلانات dynamic_axes المفقودة التي تقيدك على الصوت ذي الطول الثابت ، و soc_version الذي لا يتطابق مع الأجهزة الفعلية ، والذي يفشل في وقت التحميل مع خطأ غامض.قم دائمًا بتشغيل فحص معادلة الإخراج بين وقت تشغيل CPU ONNX و NPU OM بعد التحويل.
Q: هل الكمية INT8 على Ascend تستحق ذلك؟
A: هذا يعتمد على مقدار الخطأ الذي يتسامح معه السيناريو.يجلب INT8 زيادة واضحة في الإنتاجية ولكن تكلفة الدقة ملحوظة.حافظ على FP16 لسيناريوهات حساسة للدقة مثل الاجتماعات الطبية أو القانونية ؛ INT8 هي تجارة أفضل للوقوف الداخلي وتسجيلات التدريب.
Q: ما هي الأجهزة التي يجب تركيبها لتشغيل Ascend في حاوية؟
A: أربعة منها: /dev/davinci0، /dev/davinci_manager، /dev/devmm_svm و /dev/hisi_hdc، بالإضافة إلى دليل سائق.يؤدي فقدان أي منها إلى فشل في تهيئة ACL ، ولن تخبرك رسالة الخطأ بوجود جهاز مفقود.
Q: هل يمكن تشغيل الكلام تفريغ الصوت على CPU فقط؟
A: نعم.تم تحسين المحرك للاستدلال لـ CPU ، لذلك يعمل على خوادم محلية أو عامة دون مسرع منفصل - مثالي للتزامن المنخفض أو إعادة استخدام الأجهزة الحالية.
Q: كيف يتم نشره مع Docker / K8s؟
A: تسافر VoiVision كصورة حاوية مع نشر Docker و Kubernetes بأوامر واحدة ، وتعمل على المعادن العارية والسحابة الحكومية والبيئات المحلية ، وتتكامل عبر واجهات برمجة التطبيقات RESTful / WebSocket القياسية.
Q: هل تنخفض الدقة على المسرعات المحلية؟
A: لا. تم بناء النموذج على أبحاث NEU NLP (جامعة الشمال الشرقية) ؛ تؤثر المسرعات فقط على الإنتاجية والكمن.بعد الكمية والتكيف مع المشغل على Ascend / Cambricon ، تبقى دقة تفريغ الصوت الصينية على نفس المستوى.
