تفريغ نصي للاجتماعات على Ascend 310P: مصفوفة الإصدارات وتحويل النموذج وسبعة دروس ميدانية

توثق هذه المقالة نشر محرك تفريغ الصوت للخطاب الصيني على بطاقة الاستدلال Ascend 310P. 310P هي بطاقة استنتاجية حافة ذات موقع مختلف عن 910B ، وسيناريوهاتها أقرب إلى المعالجة المحلية في الغرفة.

Data base: الأرقام التي تحمل علامة "المواصفات الرسمية" تأتي من مقاييس المنتج المنشورة ؛ يعطي جدول الأداء القيم المرجعية لبيئة نموذجية.تختلف الأرقام الفعلية مع ظروف الصوت وحجم النموذج واستراتيجية التزامن - تأجيل دائمًا لقياساتك الخاصة.

ما هو جيد في 310P ، وما هو ليس كذلك

لا يوجد نقص في مقالات من نحن Ascend 310P ، ولكن معظمها يتوقف عند "تم تثبيت CANN وتشغيل العرض التجريبي".الفخ الحقيقي هو أن الحصول على تشغيله مرة واحدة والخدمة بشكل موثوق هو شيئين مختلفين تماما.

الاستنتاج إلى الأمام:

البعد	310P السلوك	الملاحظات
تحديد المواقع	بطاقة الاستدلال الحافة	ليست بطاقة تدريبية ؛ لا تتوقع ضبطها بشكل دقيق
تقسيم مع 910B	حافة عقدة	يتعامل 910B مع الاستدلال المركزي ، و 310P يتعامل مع المعالجة المحلية
التزام تفريغ الصوت Pure لكل بطاقة	عشرات الجداول	ASR أساس نموذج واحد (القيمة المرجعية)
التزامن الكامل للأنابيب	انخفاضات كبيرة	بمجرد إضافة فصل المتحدثين والهيكلة
الصينية تفريغ الصوت دقة	≥98٪	سيناريو اجتماع الماندرين القياسي (المواصفات الرسمية)
تغطية اللهجة	22 لهجة	الكشف التلقائي (المواصفات الرسمية)

فخ اختيار واحد يستحق الإبلاغ: العديد من البائعين يقتبسون التزامن دون ذكر الأساس.قد تعني "XX تيارات لكل بطاقة" ASR النقية ، أو قد تعني خط الأنابيب الكامل.يمكن أن تختلف الاثنان عدة مرات. اسأل دائمًا عن الطبقة التي يغطيها الرقم.

البنية النموذجي لدينا هو 910B في الوسط، 310P في الحافة: يتم نسخ الصوت محليًا في غرفة الاجتماعات ، ويعود فقط النص المنظم إلى المركز.وهذا يبقي عرض النطاق الترددي تحت السيطرة ويلبي شرط "البيانات لا تغادر غرفة الاجتماعات".

إعداد البيئة: مصفوفة الإصدار هي العقبة الحقيقية

نقطة الألم في Ascend النظام البيئي لا يتم حسابها أبدًا - إنها إصدار محاذاة.برنامج التشغيل ، البرامج الثابتة ، CANN ، وقت تشغيل الحاوية ، إطار الاستدلال ، تنسيق النموذج: إذا كان أي واحد من الستة غير محاذا فإنه ينتج فشل محير ، ورسالة الخطأ في كثير من الأحيان لا تقول ما حدث خطأ.

مزيج تم التحقق منه ووجدنا مستقرا:

المكون	Version	الملاحظات
برنامج التشغيل / البرامج الثابتة	ملزمة بإحكام إلى CANN	تحقق من جدول التوافق الرسمي قبل الترقية
CANN	سلسلة 8.x	مكتبة المشغل وأداة تحويل ATC تعيش هنا
وقت تشغيل الحاويات	Ascend Docker وقت التشغيل	مطلوب ؛ لا يمكن لـ Docker العادي تركيب NPU
إطار الاستدلال	أونكس وقت التشغيل + ACL	يعمل نماذج OM
OS	openEuler / Kylin V10 / UnionTech UOS	شائع في بيئات Xinchuang

الخطوة الأولى هي دائمًا تأكيد أن NPU مرئي:

# Check NPU devices and status
npu-smi info

# You should see the device list with health status OK
# If no card appears here, everything downstream is wasted — fix the driver first

درس ميداني: في بعض بيئات Kylin V10 ، أبلغ npu-smi info عن استثناء من البرنامج المفتوح dmp بعد تثبيت برنامج التشغيل.تبين أن السبب هو تعارض بين dkms المزمع للنظام ونص تثبيت برنامج التشغيل.كان الإصلاح هو إلغاء تثبيت نظام dkms وإعادة التثبيت باستخدام الإصدار المرفق مع حزمة برنامج التشغيل.

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

تحويل النموذج: ONNX إلى OM

عادة ما يتم تدريب نماذج ASR في PyTorch ، وتصديرها إلى ONNX ، ثم تحويلها إلى تنسيق Ascend OM مع ATC.

ثلاثة أشياء يجب مراقبتها عند تصدير ONNX

torch.onnx.export(
    model, dummy_input,
    "asr.onnx",
    opset_version=14,          # Do not use the newest; lower opset versions are more compatible
    do_constant_folding=True,
    input_names=["audio", "audio_len"],
    output_names=["logits"],
    dynamic_axes={              # Critical: audio length is inherently dynamic
        "audio": {0: "batch", 1: "time"},
        "logits": {0: "batch", 1: "time"},
    },
)

1. من المرجح أن تضرب أوبسيت الأحدث المشغلين غير المدعومين ؛ 14 هو خيار توافق جيد.
2. يجب الإعلان عن المحاور الديناميكية. خلاف ذلك ، يمكنك تشغيل الصوت الثابت الطول فقط ، وهو أمر غير قابل للاستخدام في الممارسة العملية.
3. تمكين الطي المستمر. 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=Ascend310P \
    --precision_mode=allow_fp16 \
    --log=error

المعلمات الثلاث الأكثر احتمالاً للتسبب في المتاعب:

• --soc_version: يجب أن تتطابق مع الأجهزة الفعلية بالضبط. يجب كتابة 310P كـ Ascend310P ؛ ستفشل Ascend310 أو Ascend910B في مرحلة التحميل ، مع خطأ غامض جدًا.
• --dynamic_dims: المستويات الديناميكية.للصوت، طبقة حسب المدة في الثواني.العديد من المستويات يجعل وقت التجميع ينفجر ؛ عدد قليل جدًا من المشغلات إعادة التجميع المتكررة والكمن المتذبذب.المجموعة أعلاه (1s / 2s / 3s) هي نقطة التوازن التي قمنا بقياسها.
• --precision_mode: allow_fp16 له تأثير ضئيل على الدقة على ASR وزيادة واضحة في الإنتاجية.

هل يجب أن تحدد الكمية؟

الدقة	الإنتاجية	الدقة
FP16	خط الأساس	خط الأساس
INT8	مكاسب واضحة	الخسارة الملموسة

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

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

النشر: الحاويات هي الخيار الوحيد المعقول

إن تثبيت البيئة على المعدن العاري لا يمكن الحفاظ عليه عملياً في بيئات شينتشوانغ.نحن نقدم كحاوية:

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:310p \
  ./asr_server --model /models/asr_om --port 8000

فقدان أي من أعلام --device تنتج فشلًا في تهيئة ACL ، والخطأ لا يخبرك أنه تم حذف جهاز.هذا هو أكبر مانع للقادمين الجدد.

درس آخر: لا تخترع بروتوكول خاص. استخدام RESTful القياسية (ملف تفريغ الصوت) بالإضافة إلى WebSocket (البث في الوقت الحقيقي) ، أو التكامل مع OA العميل وأنظمة الاجتماعات يصبح مؤلمًا للغاية.

يمكن للعملاء الذين لديهم بالفعل خوادم نشر pure-software speech engine مباشرة ، والحصول على تفريغ الصوت الخاصة على السرعات المحلية دون شراء الأجهزة.

سبعة دروس من الميدان

هذا هو الجزء الأكثر قيمة من المقالة.تم تعلم كل عنصر بالطريقة الصعبة ، ولم يتم نسخها من الوثائق.

1.الأشكال الديناميكية تسبب إعادة التجميع المتكررة نحن لم نحدد --dynamic_dims في البداية ، لذلك كل مقطع صوتي مختلف الأحجام يؤدي إلى تجميع الرسم البياني والكمون يرتفع إلى ثوانٍ.بمجرد تكوين المستويات ، استقر الكمون في نطاق دون الثانية.

2.الصوت الطويل يستنفد الذاكرة تسبب تغذية تسجيل اجتماع لمدة ساعتين إلى النموذج في تمرير واحد في OOM فوري.يجب عليك استخدام الاستدلال التزايدي المجزأ -cut by VAD وتغذية قطاع فك الترميز عن طريق قطاع بدلا من تحميل كل شيء.أضفنا لاحقًا غطاء قسري لمدة 60 ثانية على العازل المؤقت الصوتي ، مما أدى إلى القضاء على خطر OOM تمامًا.

3.فشل المشغل الصامت لم يكن لدى متغير LayerNorm معين أي مشغل مقابل على Ascend.هذه هي أخطر فئة من الفشل ، لأنها تبدو وكأنها نجاح. يجب عليك إجراء فحص التكافؤ: تغذية نفس الصوت من خلال وقت تشغيل ONNX على CPU و OM على NPU ، ثم مقارنة المخرجات.هذا هو الاحتجاز الوحيد - لا تتخطيه.

أنشأت الإصدارات السابقة من 4.تسرب السياق تحت التزامن متعدد الخيوط سياق ACL منفصل لكل طلب ، مما أدى إلى استنفاد السياقات في ظل التزامن العالي. Context pooling أصلح ذلك.

بعد ترقية CANN كبيرة ، قد يفشل نموذج OM القديم في التحميل أو التراجع في الأداء. وضع تحويل النموذج في CI بدلاً من التحويل باليد والدعوة إلى القيام به.

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

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

خط الأنابيب الكامل: من الخطاب إلى محضر الاجتماع

نقطة أخيرة واحدة: خطاب تفريغ الصوت ليس سوى الخطوة الأولى.

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

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

متى لا تختار المسرعات المحلية

دعونا نكون مستقيمين من نحن هذا بدلاً من دفعها.

إذا كان وضعك يلبي أيًا من الشروط التالية ، فإن استخدم GPU بدلاً من ذلك:

• لا إلزامية Xinchuang أو متطلبات التكنولوجيا المحلية → GPU النظام البيئي أكثر نضجا بكثير ؛ لا تخلق المتاعب لنفسك
• لا أحد في الفريق يعرف CANN → التكلفة التشغيلية ستتجاوز بكثير الأموال المدفوعة على الأجهزة

قيمة المسرعات المحلية هي الامتثال ، وليست فعالية من حيث التكلفة.إذا لم يكن الامتثال قيدا صعبا، فإن الحساب لا يعمل.

التذييل: قائمة التوافق الكامل

المكون	نطاق مدعوم
Ascend	310P / 910B
Cambricon	MLU370 / MLU590
Hygon	DCU
NVIDIA	T4 / L4 / A10 / A100 والمجموعة الكاملة
CPU فقط	مدعوم (التزامن المنخفض / إعادة استخدام الأجهزة الحالية)

النشر عبر Docker و Kubernetes ، والتي تعمل على بيئات المعادن العارية والسحابة الحكومية و Xinchuang ، والتكامل مع OA وأنظمة الاجتماعات عبر واجهات RESTful / WebSocket القياسية.

المزيد من القراءة: Private ASR on the Ascend 910B | How to choose a private-deployment ASR