Транскрипция совещаний на Ascend 310P: матрица версий, конвертация моделей и семь уроков с площадки

В этой статье документируется развертывание китайского языкового движка речевая транскрипция на Карта вывода Ascend 310P. 310P представляет собой краевую выводную карту с другим позиционированием от 910B, и ее сценарии ближе к внутренней локальной обработке.

База данных: цифры, обозначенные «официальными спецификациями», взяты из опубликованных показателей производительности продукции; таблица производительности дает исходные значения для типичной среды.Фактические цифры варьируются в зависимости от условий аудио, размера модели и стратегии одновременности - всегда откладывайте свои собственные измерения.

Чем хорош 310P, а чем нет

Нет недостатка в статьях О нас и Ascend 310P, но большинство останавливаются на "CANN установлена и демо запускается".Настоящая ловушка - это Запустить его один раз и надежно обслуживать - это две совершенно разные вещи..

Заключение впереди:

Размер	310P Поведение	Замечания
Позиционирование	Edge inference card	Не тренировочная карточка; не ожидайте тонкой настройки на нее
Раздел с 910B	Edge node	910B обрабатывает центральные выводы, 310P - локальную обработку.
Чистое одновременное использование речевая транскрипция на карту	Десятки потоков	Одномодельная база ASR (основное значение)
Полная параллельность трубопроводов	значительно падает	После добавления разделение по спикерам и структурирования
Китайская точность речевая транскрипция	≥98%	Стандартный сценарий встреч на мандаринском языке (официальная спецификация)
Диалектное покрытие	22 диалекта	Автоматическое обнаружение (официальная спецификация)

Один выбор ловушка стоит флагировать: многие поставщики цитируют параллельность, не указывая основы.«XX потоков на карту» может означать чистый ASR, или это может означать полный трубопровод.Эти два могут различаться несколько раз.

Нашим типичным Архитектура является 910B в центре, 310P на краю: аудио транскрибируется локально в зале заседаний, а в центр возвращается только структурированный текст.Это позволяет контролировать пропускную способность и удовлетворяет требованию "данные не покидают зал заседаний".

Подготовка окружающей среды: матрица версий - это реальное препятствие

Болезненной точкой в Ascend Экосистема никогда не является вычисление - это выравнивание версий.Драйвер, микропрограммное обеспечение, CANN, время выполнения контейнеров, схема вывода, формат модели: Если один из шести не выровнен, это создает сбивающий с толку неудачу., а сообщение об ошибке часто не говорит, что пошло не так.

Комбинация, которую мы проверили и нашли стабильной:

Компонент	Версия	Замечания
Драйвер / прошивка	Тщательно привязанный к CANN	Проверьте официальную таблицу совместимости перед обновлением
CANN	Серия 8.x	Библиотека операторов и инструмент преобразования ATC живут здесь
Время выполнения контейнеров	Время выполнения Ascend Docker	Необходимо; обычный Docker не может монтировать НПУ
Рамочная основа выводов	Время выполнения ONNX + ACL	Запускает модели OM
ОС	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. Более высокая версия Opset не лучше. Новые опсеты с большей вероятностью поражают не поддерживаемых операторов; 14 является хорошим выбором совместимости.
2. Динамические осей должны быть объявлены. В противном случае вы можете запускать только аудио фиксированной длины, что на практике непригодно.
3. Включить постоянное сгибание. do_constant_folding=True существенно уменьшает размер графика и улучшает эффективность преобразования.

Параметры АТК, один за другим

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 слепо.В сценариях встреч потеря точности проявляется как «каждое имя неправильно, каждый термин неправильно», и затраты на переработку намного превышают вычислительные вычисления, которые вы сэкономили.

Развертывание: контейнеризация - единственный разумный выбор

Установка среды на голый металл практически невозможна в средах 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:310p \
  ./asr_server --model /models/asr_om --port 8000

Отсутствие любого из этих флагов --device приводит к отказу инициализации ACL., и ошибка не говорит вам, что устройство было опущено.Это самый большой блок для новых пришельцев.

Еще один урок: Используйте стандартный RESTful (файл речевая транскрипция) плюс WebSocket (поток в режиме реального времени), или интеграция с заказчиком OA и системами собраний становится очень болезненной.

Клиенты, у которых уже есть серверы, могут развернуть pure-software speech engine напрямую, получив частный речевая транскрипция на отечественных акселераторах без покупки оборудования.

Семь уроков из поля

Это самая ценная часть статьи.Каждый элемент был выучен тяжелым способом, не скопирован из документации.

1.Динамические формы вызывают частую перекомпиляцию Сначала мы не установили --dynamic_dims, поэтому каждый аудиоклип разного размера запускал компиляцию графика и задержку, которая увеличивалась до секунд.После конфигурации уровней задержка установилась в субсекундном диапазоне.

2.Длинный аудио истощает память Введение двухчасовой записи встречи в модель за один проход вызвало немедленную ООМ.Вы должны использовать сегментированный инкрементальный вывод - cut by VAD и подавать декодер сегмент за сегментом вместо того, чтобы загружать все.Позже мы добавили Вынужденный 60-секундный поток на аудиобуфер, что полностью устранило риск OOM.

3.Неисправность тихого оператора В одном из вариантов LayerNorm не было соответствующего оператора на Ascend. ATC не сообщал никаких ошибок во время преобразования, и время выполнения возвращало все нули. Это самый опасный класс неудач, потому что это выглядит как успех. Вы должны проверить эквивалентность: подача того же аудио через ONNX Runtime на CPU и OM на NPU, а затем сравнить выходные данные.Это единственный вариант - не пропускайте его.

4.Контекстная утечка при многопоточной параллельности Предыдущие версии создавали отдельный контекст ACL для каждого запроса, исчерпывающий контекст при высокой параллельности. Контекстное объединение исправил это.

5.Модернизация драйвера означает повторное преобразование модели После крупного обновления CANN старые модели OM могут не загружаться или регрессировать в производительности. Перевод модели в CI вместо того, чтобы конвертировать вручную и называть это сделано.

6.Офлайн упаковка для воздушных зазоров В физически изолированной среде все Зависимости CANN, драйверы, вес модели, китайские шрифты и сертификаты должны быть упакованы заранее.Однажды мы попали на это: Пропавший китайский шрифт на сайте, и каждый результат речевая транскрипция выходил в виде ящиков. Офлайн-пакеты должны быть репетированы в рамках полного процесса развертывания в эквивалентной среде.

7.Вводящие в заблуждение сообщения об ошибках срывают диагностику Некоторые ошибки Ascend дают только код, а не коренную причину.Однажды мы провели три дня на сбое загрузки без прогресса, и это оказалось неправильным soc_version. Урок: когда вы попадете на неопределенную ошибку, перепроверьте матрицу версий сверху - это гораздо быстрее, чем чтение журналов строка за строкой.

Полный трубопровод: от речи до протокол совещания

Один заключительный момент: Речь речевая транскрипция - это только первый шаг.

То, что нужно реальному сценарию, - это «протокол совещания, когда встреча закончится».Это требует разделение по спикерам, семантической структурирования (темы, решения, действия) и генерации протокол совещания после стадии ASR.Условия этих трех на Значительно снижает уровень конкуренции - именно поэтому мы постоянно подчеркиваем, что вы должны спросить, какой слой охватывает число одновременности.

Наш подход запускает полный конвейер на одном сервере, при этом аудио и текст никогда не покидают внутреннюю сеть.Для правительственных, финансовых и оборонных сценариев это жесткое требование.

Когда не выбирать отечественные ускорители

Давайте будем прямо говорить об этом, а не толкать его.

Если ваша ситуация соответствует одному из следующих, Используйте вместо этого GPU:

• Нет обязательных требований к Xinchuang или отечественным технологиям → GPU Экосистема гораздо более зрелый; не создавайте для себя проблем
• Никто в команде не знает, что может быть → эксплуатационная стоимость будет намного превышать деньги, сэкономленные на оборудование

Ценность отечественных ускорителей - Соблюдение, а не рентабельность.Если соблюдение не является жестким ограничением, арифметика не работает.

Приложение: полный список совместимости

Компонент	Поддерживаемый диапазон
Ascend	310P / 910B
Cambricon	MLU370 / MLU590
Hygon	DCU
NVIDIA	T4 / L4 / A10 / A100 и полный ассортимент
Только CPU	Поддерживается (низкая параллельность / повторное использование существующего оборудования)

Развертывание с помощью Docker и Kubernetes, работая на bare-metal, правительственных облачных средах и средах Xinchuang, интеграция с OA и системами встреч по стандартным интерфейсам RESTful / WebSocket

Читать далее: Private ASR on the Ascend 910B | How to choose a private-deployment ASR