Ascend 310P での会議文字起こし：バージョンマトリクス、モデル変換、現場で踏んだ 7 つの落とし穴

この記事では、 Ascend 310P 推論カード 上で中国語音声音声文字起こしエンジンのデプロイを文書化します。310 P は、 910 B とは異なる位置づけのエッジ推論カードであり、そのシナリオは室内ローカル処理に近い。

データベース： 「公式仕様」と表示された数字は、公表された製品指標から取得されています。実際の数は、オーディオ条件、モデルサイズ、並行戦略によって異なります。

310 P の得意点と得意点

会社概要記事の不足はありません Ascend 310P， しかし、ほとんどの停止 "CANN がインストールされ、デモが実行されます".本当の罠は 一度稼働させると信頼性の高いサービスとは全く違うものです です

前面の結論：

ディメンション	310 P の挙動	注釈
ポジショニング	エッジ推論カード	トレーニングカードではありません。微調整を期待しないでください。
910 B と分割	エッジノード	910 B は中央推論、 310 P はローカル処理
カードあたりの純粋な音声文字起こし並列性	数十のストリーム	ASR 単一モデルベース （ 基準値 ）
フルパイプライン並行性	大幅な落下	話者分離と構造化が追加されると
中国語音声文字起こし精度	≥ 98%	標準中国語ミーティングシナリオ （ 公式仕様 ）
方言カバー	22 の方言	自動検出 （ 公式仕様 ）

フラグを付ける価値のある選択トラップ： 多くのベンダーは基礎を述べずに並行性を引用します。「 1 カードあたり XX ストリーム」は純粋な ASR を意味するか、フルパイプラインを意味するかもしれません。2 つは何度か異なることがある。番号がカバーする層を常に尋ねなさい。

典型的なアーキテクチャは 中央は 910 B 、端は 310 P です。オーディオは会議室でローカルに転写され、構造化されたテキストのみがセンターに戻ります。これにより、帯域幅を制御し、「データが会議室を出ない」要件を満たします。

環境準備： バージョンマトリックスが本当の障害です

Ascend エコシステムの痛みは決して計算されません —バージョンアラインメント です。ドライバ、ファームウェア、 CANN 、コンテナランタイム、推論フレームワーク、モデルフォーマット： 6 つのうちの 1 つが位置を合わせないと混乱します 、エラーメッセージはしばしば何が間違っていたかを言っていません。

私たちが検証し安定した組み合わせ：

コンポーネント	バージョン	注釈
ドライバ / ファームウェア	Tightly bound to CANN	アップグレードする前に公式の互換性表を確認する
CANN	8.x シリーズ	オペレータライブラリと ATC 変換ツールはここにあります
コンテナランタイム	Ascend Docker ランタイム	必須； 通常の Docker は NPU をマウントできません
推論フレームワーク	ONNX ランタイム + 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 にエクスポートされ、 ATC で Ascend OM フォーマットに変換されます。

ONNX をエクスポートする際に注意すべき 3 つのこと

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 パラメータ、 1 つずつ

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

トラブルを引き起こす可能性が最も高い 3 つのパラメータ：

• --soc_version： 実際のハードウェアと正確に一致する必要があります 310P は Ascend310P と書く必要があります。 Ascend310 または Ascend910B はどちらもロード段階で非常に曖昧なエラーで失敗します。
• --dynamic_dims： ダイナミックな階層。オーディオの場合は、 秒単位で 階層。層が多すぎるとコンパイル時間が爆発し、少すぎると頻繁な再コンパイルとジッタリーレイテンシーが発生します。上のセット （ 1 s / 2 s / 3 s ） は、測定したバランスポイントです。
• --precision_mode： allow_fp16 は ASR に対する精度への影響は無視でき、スループット利得は明らかです。

量子化すべきか？

精度	スループット	精度
FP 16	ベースライン	ベースライン
INT8	クリアゲイン	感知損失

結論： 精度に非常に敏感なシナリオ向け — 医療、法律 — FP 16 に滞在。内部ミーティングやトレーニング記録では、許容度が高い場合は、 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 を直接デプロイでき、ハードウェアを購入せずに国内アクセラレータにプライベート音声文字起こしを獲得できます。

現場からの 7 つの教訓

これは記事の最も貴重な部分です。すべての項目は、ドキュメントからコピーするのではなく、ハード方法で学びました。

1.ダイナミックシェイプは頻繁な再コンパイルを引き起こす --dynamic_dims は最初は設定していなかったため、異なるサイズのオーディオクリップごとにグラフコンパイルがトリガーされ、レイテンシが秒に急増しました。階層が設定されると、レイテンシはサブ秒の範囲に落ち着きました。

2.長いオーディオはメモリを枯渇させる 2 時間の会議録音を 1 回でモデルに供給すると、即座に OOM が発生しました。分節増分推論—cut by VAD を使用し、全体をロードする代わりにセグメントごとにデコーダにフィードする必要があります。その後、オーディオバッファに 強制 60 秒キャップ を追加し、 OOM リスクを完全に排除しました。

3.サイレントオペレータ障害 特定の LayerNorm バリアントは Ascend に対応する演算子を持っていなかった。ATC は変換時にエラーを報告せず、ランタイムはすべてのゼロを返しました。 これは失敗の最も危険なクラスです成功のように見えるからです相当性チェックを実行する必要があります： CPU 上の ONNX Runtime と NPU 上の OM を通じて同じオーディオをフィードし、出力を比較します。これは唯一のフォールバックです。スキップしないでください。

4.マルチスレッド並行時のコンテキスト漏れ 初期のバージョンはリクエストごとに別個の ACL コンテキストを作成し、高並行性下でのコンテキストを枯渇させた。コンテキストプール はそれを修正した。

5.ドライバのアップグレードは、モデルを再変換することを意味します 大規模な CANN アップグレード後、古い OM モデルのロードに失敗したり、パフォーマンスが低下したりすることがあります。CI でのモデル変換 手動で変換し、それを呼び出すのではなく。

6.エアギャップ環境向けオフラインパッケージング 物理的に隔離された環境では、 CANN 依存関係、ドライバ、モデルウェイト、中国語フォント、証明書 はすべて事前にパッケージ化する必要があります。missing 中国語フォント が現場に来て、すべての音声文字起こしの結果はボックスとして出てきました。オフラインバンドルは、同等の環境で完全なデプロイメントフローを通してリハーサルする必要があります。

7.誤ったエラーメッセージが診断を妨げる いくつかの Ascend エラーはコードのみを与え、根本原因ではありません。3 日間ロード障害で進捗がないことがありましたが、誤った soc_version であることが判明しました。レッスン： 曖昧なエラーが発生した場合は、上部からバージョンマトリックスを再確認します。— ログを 1 行ずつ読むよりもはるかに高速です。

フルパイプライン： スピーチから議事録まで

最後のポイント： スピーチ音声文字起こしは第一歩に過ぎません。

実際のシナリオに必要なのは、「会議が終わるときに議事録 」です。そのためには、 ASR 段階後の議事録 、意味構造化 （ トピック、決定、アクションアイテム ） 、および議事録生成が必要です。これら 3 つを 並列性を大幅に削減します にレイヤーする — だからこそ、並行番号がカバーするレイヤーを尋ねなければならないと強調し続けています。

私たちのアプローチは、オーディオとテキストが内部ネットワークを離れることはありません。政府、金融、防衛のシナリオにとって、それは厳しい要件です。

国内アクセラレータを選択しない場合

これを押し付けるのではなく、まっすぐ会社概要にしましょう。

状況が以下のいずれかに該当する場合、 代わりに GPU を使用する：

• 必須 Xinchuang または国内技術要件なし → GPU エコシステムははるかに成熟した； 自分でトラブルを起こすな
• チームの誰も CANN を知らない → 運用コストはハードウェアの節約コストをはるかに上回る

国産アクセラレータの価値は、費用対効果ではなく、 コンプライアンス です。コンプライアンスがハード制約でなければ、演算はうまくいかない。

付録： 完全な互換性リスト

コンポーネント	サポート範囲
Ascend	310P / 910B
Cambricon	MLU370 / MLU590
ヒゴン	DCU
NVIDIA	T4 / L4 / A10 / A100 およびフルレンジ
CPU のみ	サポート （ 低並行性 / 既存のハードウェアの再利用 ）

ベアメタル、政府クラウド、 Xinchuang 環境で動作する Docker と Kubernetes 経由のデプロイメント、標準の RESTful / WebSocket インターフェースを介して OA とミーティングシステムと統合。

続きを読む： Private ASR on the Ascend 910B | How to choose a private-deployment ASR