Transkripsi rapat pada Ascend 310P: matriks versi, konversi model dan tujuh pelajaran lapangan

Artikel ini mendokumentasikan penyebaran mesin transkripsi suara ucapan Cina pada Kartu inferensi Ascend 310P. 310P adalah kartu inferensi tepi dengan posisi yang berbeda dari 910B, dan skenario yang lebih dekat dengan pemrosesan lokal di dalam ruangan.

Dasar Data: angka yang ditandai "spesifikasi resmi" berasal dari metrik produk yang diterbitkan; tabel kinerja memberikan Nilai-nilai referensi untuk lingkungan yang khas. Angka aktual bervariasi dengan kondisi audio, ukuran model, dan strategi concurrency - selalu menunda pengukuran Anda sendiri.

Apa yang baik dari 310P, dan apa yang tidak

Tidak ada kekurangan artikel Tentang Kami yang Ascend 310P, tetapi sebagian besar berhenti di "CANN diinstal dan demo berjalan". Perangkap sebenarnya adalah bahwa Membuatnya berjalan sekali dan melayani dengan andal adalah dua hal yang sama sekali berbeda.

Kesimpulan di depan:

Dimension (dimensi)	Perilaku 310P	Catatan-catatan:
Posisi Posisi	Kartu Inferensi Edge (Edge Inference Card)	Bukan kartu pelatihan; jangan berharap untuk fine-tune di atasnya
Berpisah dengan 910B	Edge node	910B menangani inferensi pusat, 310P menangani pemrosesan lokal
Pure transkripsi suara concurrency per kartu	Puluhan stream yang mengalir	ASR dasar model tunggal (nilai referensi)
Kompetisi Full-pipeline	turun secara signifikan	Setelah pemisahan pembicara dan struktur ditambahkan
Akurasi transkripsi suara Cina	≥ 98%	Skenario pertemuan Mandarin Standar (spesifikasi resmi)
Cakupan dialek	22 dialek	Deteksi otomatis (spesifikasi resmi)

Satu perangkap pilihan yang layak ditandai: Banyak vendor mengutip concurrency tanpa menyatakan alasannya. "XX aliran per kartu " mungkin berarti ASR murni, atau mungkin berarti pipa penuh. Keduanya bisa berbeda beberapa kali lebih. Selalu tanyakan pada orang-orang yang memiliki jumlah yang sama.

Arsitektur khas kami adalah 910B di tengah, 310P di tepi: audio ditranskripsi secara lokal di ruang rapat, dan hanya teks terstruktur yang dikembalikan ke pusat. Hal ini membuat bandwidth di bawah kontrol dan memenuhi persyaratan "data tidak meninggalkan ruang pertemuan".

Persiapan lingkungan: matriks versi adalah hambatan yang sebenarnya

Titik rasa sakit di Ascend Ekosistem tidak pernah menghitung - itu adalah Versi Alignment. Driver, firmware, CANN, runtime kontainer, inference framework, format model: Jika salah satu dari enam itu tidak selaras, maka akan terjadi kegagalan yang membingungkan., dan pesan kesalahan sering tidak mengatakan apa yang salah.

Kombinasi yang telah kami verifikasi dan temukan stabil:

komponen komponen	Versi versi	Catatan-catatan:
Driver / Firmware	Terikat dengan ketat untuk CANN	Periksa tabel kompatibilitas resmi sebelum melakukan upgrade
CANN dapat	Seri 8.x	Perpustakaan operator dan alat konversi ATC hidup di sini
Container Runtime (Runtime Kontainer)	Ascend Docker Runtime	Diperlukan; Docker biasa tidak dapat memasang NPU
Kerangka Inferensi (Inference Framework)	ONNX Runtime + ACL	Menjalankan model OM
OS OS	openEuler / Kylin V10 / UnionTech UOS	Umum di Lingkungan Xinchuang

Langkah pertama adalah selalu untuk memastikan bahwa NPU terlihat:

# 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

Pelajaran lapangan (field lesson): pada beberapa lingkungan Kylin V10, npu-smi info melaporkan pengecualian daemon dmp setelah driver diinstal. Penyebabnya ternyata adalah konflik antara dkms yang dibundel sistem dan script instalasi driver. Perbaiki adalah untuk uninstall sistem dkms dan menginstal ulang menggunakan versi yang dibundel dengan paket driver.

Distribusi-spesifik masalah seperti ini Biasanya tidak dapat ditemukan dalam dokumentasi resmi., dan mereka adalah blocker yang paling umum di situs.

Konversi Model: ONNX ke OM

Model ASR biasanya dilatih dalam PyTorch, diekspor ke ONNX, kemudian dikonversi ke format Ascend OM dengan ATC.

Tiga hal yang harus diperhatikan saat mengekspor 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 yang lebih baru lebih mungkin untuk memukul operator yang tidak didukung; 14 adalah pilihan kompatibilitas yang baik.
2. Dynamic axes harus dinyatakan. Jika tidak, Anda hanya dapat menjalankan audio dengan panjang tetap, yang tidak dapat digunakan dalam praktik.
3. Mengaktifkan folding yang konstan. do_constant_folding=True secara substansial mengurangi ukuran grafik dan meningkatkan keberhasilan konversi.

Parameter ATC, satu per satu

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

Tiga parameter yang paling mungkin menyebabkan masalah:

• --soc_version: Harus sesuai dengan hardware yang sebenarnya. 310P harus ditulis sebagai Ascend310P; Ascend310 atau Ascend910B keduanya akan gagal pada tahap beban, dengan kesalahan yang sangat samar.
• --dynamic_dims: The Dynamic Tiers (Tingkat Dinamis). Untuk audio, tingkatan dengan durasi dalam detik. Terlalu banyak lapisan membuat waktu kompilasi meledak; terlalu sedikit memicu rekompilasi yang sering dan latensi jittery. Set di atas (1s / 2s / 3s) adalah titik keseimbangan yang kami ukur.
• --precision_mode: allow_fp16 memiliki dampak akurasi yang diabaikan pada ASR dan keuntungan throughput yang jelas.

Apakah Anda harus mengukur?

Precision (Ketepatan)	Throughput (Troughput)	Akurasi (accuracy)
FP16 FP16	Baseline (baseline)	Baseline (baseline)
INT8	Keuntungan yang jelas	Perceived loss (kehilangan yang dirasakan)

Kesimpulannya adalah:: untuk skenario yang sangat sensitif terhadap akurasi - medis, hukum - Tinggal di FP16. Untuk rapat internal dan catatan pelatihan, di mana toleransi lebih tinggi, INT8 adalah perdagangan yang lebih baik.

Jangan mengejar angka-angka tolok ukur dengan INT8 secara membabi buta. Dalam skenario pertemuan, kehilangan akurasi muncul sebagai "setiap nama yang salah, setiap istilah yang salah", dan biaya pengerjaan ulang jauh melebihi perhitungan yang Anda simpan.

Deployment: containerisation adalah satu-satunya pilihan yang masuk akal

Memasang lingkungan pada logam telanjang praktis tidak dapat dipertahankan di lingkungan Xinchuang. Kami mengirimkan sebagai sebuah wadah:

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

Kehilangan salah satu bendera --device menghasilkan kegagalan inisialisasi ACL., dan kesalahan itu tidak memberi tahu Anda bahwa perangkat dihilangkan. Ini adalah pemblokir terbesar bagi pendatang baru.

Satu lagi pelajaran: Jangan membuat protokol pribadi. Menggunakan standar RESTful (file transkripsi suara) ditambah WebSocket (real-time streaming), atau mengintegrasikan dengan pelanggan OA dan sistem pertemuan menjadi sangat menyakitkan.

Pelanggan yang sudah memiliki server dapat menggunakan pure-software speech engine secara langsung, mendapatkan transkripsi suara pribadi pada akselerator domestik tanpa membeli perangkat keras.

Tujuh Pelajaran dari Lapangan

Ini adalah bagian yang paling berharga dari artikel tersebut. Setiap item dipelajari dengan cara yang sulit, tidak disalin dari dokumentasi.

1. Bentuk dinamis menyebabkan rekompilasi yang sering terjadi Kami tidak mengatur --dynamic_dims pada awalnya, jadi setiap klip audio berukuran berbeda memicu kompilasi grafik dan latensi yang meningkat menjadi detik. Setelah tingkat dikonfigurasi, latensi menetap dalam kisaran sub-detik.

2. Audio yang panjang menguras memori Memberikan rekaman pertemuan dua jam ke model dalam satu pass menyebabkan OOM langsung. Anda harus menggunakan Segmentasi Inkremental Inferensi Segmentasi Inkremental Inferensi Segmentasi Inkremental Inferensi Segmentasi Inkremental - cut by VAD dan memberi makan decoder segmen demi segmen daripada memuat semuanya. Kemudian kami menambahkan Cap 60 detik yang dipaksa pada buffer audio, yang menghilangkan risiko OOM sepenuhnya.

3. Operator Silent gagal Sebuah varian LayerNorm tertentu tidak memiliki operator yang sesuai pada Ascend. ATC melaporkan tidak ada kesalahan pada waktu konversi, dan runtime mengembalikan semua nol. Ini adalah kelas kegagalan yang paling berbahaya, karena terlihat seperti kesuksesan. Anda harus melakukan pemeriksaan kesetaraan: umpan audio yang sama melalui ONNX Runtime pada CPU dan OM pada NPU, kemudian bandingkan output. Ini adalah satu-satunya langkah mundur - jangan melewatkannya.

Versi awal 4. Kebocoran konteks di bawah concurrency multithreaded menciptakan konteks ACL terpisah per permintaan, menguras konteks di bawah concurrency tinggi. Konteks Pooling (Powling Konteks) memperbaikinya.

5. Upgrade driver berarti mengkonversi kembali model Setelah upgrade CANN besar, model OM lama mungkin gagal memuat atau mundur dalam kinerja. Tempatkan model konversi di CI daripada mengkonversi dengan tangan dan menyebutnya selesai.

6. Kemasan offline untuk lingkungan yang celah udara Dalam lingkungan yang terisolasi secara fisik, Dependensi CANN, driver, bobot model, font Cina dan sertifikat semua harus dikemas terlebih dahulu. Kami pernah memukulnya: Hilangnya font Cina di situs, dan setiap hasil transkripsi suara keluar sebagai kotak. Bundel offline harus dilatih melalui aliran penyebaran penuh dalam lingkungan yang setara.

7. Pesan kesalahan yang menyesatkan menggagalkan diagnosis Beberapa kesalahan Ascend hanya memberikan kode, bukan akar penyebab. Kami pernah menghabiskan tiga hari pada kegagalan beban tanpa kemajuan, dan ternyata menjadi soc_version yang salah. Pelajaran: ketika Anda menekan kesalahan yang samar, verifikasi ulang matriks versi dari atas - jauh lebih cepat daripada membaca log baris demi baris.

The full pipeline: dari pidato ke notulen rapat

Satu poin terakhir: Pidato transkripsi suara hanyalah langkah pertama.

Apa yang dibutuhkan skenario nyata adalah "notulen rapat ketika pertemuan berakhir". Hal ini membutuhkan pemisahan pembicara, penstrukturan semantik (topik, keputusan, item tindakan) dan generasi notulen rapat setelah tahap ASR. Lapisan ketiga ini di Mengurangi persaingan secara signifikan - itulah sebabnya kami terus menekankan bahwa Anda harus bertanya lapisan mana yang mencakup nomor concurrency.

Pendekatan kami menjalankan pipa penuh pada server tunggal, dengan audio dan teks tidak pernah meninggalkan jaringan internal. Untuk skenario pemerintah, keuangan, dan pertahanan, itu adalah persyaratan yang sulit.

Kapan tidak memilih akselerator domestik

Mari kita bersikap lurus Tentang Kami ini daripada mendorongnya.

Jika situasi Anda memenuhi salah satu dari berikut, Gunakan GPU sebagai gantinya:

• Tidak ada persyaratan wajib Xinchuang atau teknologi domestik → GPU Ekosistem jauh lebih dewasa; jangan membuat masalah untuk diri sendiri
• Tidak ada seorang pun di tim yang tahu tentang CANN. → biaya operasional akan jauh melebihi uang yang disimpan pada perangkat keras

Nilai akselerator domestik adalah Kepatuhan (Compliance), bukan efektivitas biaya. Jika kepatuhan bukanlah kendala yang keras, maka aritmatika tidak akan berhasil.

Lampiran: daftar kompatibilitas penuh

komponen komponen	Rentang yang didukung
Ascend	310P / 910B / 310P / 910B
Cambricon	MLU370 / MLU590
Hygon adalah	DCU
NVIDIA	T4 / L4 / A10 / A100 dan jangkauan penuh
Hanya CPU saja	Didukung (kerja sama rendah / penggunaan kembali perangkat keras yang ada)

Penyebaran melalui Docker dan Kubernetes, berjalan pada bare metal, cloud pemerintah dan lingkungan Xinchuang, mengintegrasikan dengan OA dan sistem pertemuan melalui antarmuka RESTful / WebSocket standar.

Baca lebih lanjut: Private ASR on the Ascend 910B | How to choose a private-deployment ASR adalah