Menjalankan ASR Pribadi di Ascend 910B: Setup, Adaptasi Operator dan Throughput

Posting ini berjalan melalui pendaratan mesin ucapan-ke - teks Cina pada NPU Huawei Ascend di lingkungan pribadi - versi lingkungan, konversi model, perintah penyebaran, perangkap dan angka kinerja referensi.

Pada angka-angka tersebut: angka yang ditandai "spesifikasi" berasal dari produk yang diterbitkan Spesifikasi. Tabel kinerja memberikan Referensi magnitudo dalam kondisi khas; nilai aktual bervariasi dengan kondisi audio, ukuran model dan strategi concurrency. Selalu mengukur pada beban kerja Anda sendiri.

Mengapa harus berjalan pada perangkat keras domestik

Dalam pemerintahan, keuangan, dan pertahanan, sistem harus tidak hanya "data di tempat " tetapi juga" mandiri secara teknologi. "Itu berarti mengalihkan perhitungan yang mendasari dari GPU impor ke chip domestik Ascend, Cambricon, dan Hygon, dan OS ke Kylin, UnionTech, dan sistem domestik lainnya.

Dalam istilah teknik ini menjadi tiga kendala keras:

• Data Residensi Data Residensi - audio rapat berisi diskusi internal, dan banyak organisasi secara eksplisit melarang audio dari meninggalkan intranet.
• Pengadaan Xinchuang - GPU yang diimpor mungkin tidak muncul pada daftar pembelian yang disetujui sama sekali
• Operasi udara-gapped - beberapa situs tidak memiliki konektivitas eksternal, sehingga bobot model harus dikemas ke lingkungan di depan

Titik inti: penerapan on-premise menjawab "di mana data berada "; jawaban lokalisasi" siapa yang mengendalikan teknologi. Bersama-sama mereka berkumpul pada satu tugas - mendapatkan ASR berjalan di NPU domestik, dan berjalan cukup cepat.

Akselerator yang didukung

Dibangun di atas penelitian NEU NLP (Northeastern University), mesin VoiVision secara native mendukung akselerator utama:

Jenis:	Perwakilan dari	Penggunaan
NVIDIA	T4 / L4 / A10 / A100	Umum, kinerja tinggi
Ascend	310P / 910B / 310P / 910B	Lokalisasi, server domestik
Cambricon	MLU370 / MLU590	Lokalisasi, server domestik
Hygon DCU (Hygon DCU)	Seri DCU	Jalur x86 domestik
Hanya CPU saja	x86 / ARM	Menggunakan kembali yang ada, concurrency rendah

Ascend saat ini memiliki Ekosistem yang paling lengkap di antara akselerator domestik (CANN + MindSpore + kebun binatang model). 910B menargetkan pelatihan dan inferensi throughput tinggi, sementara 310P menargetkan penggunaan edge dan daya rendah. Untuk pertemuan bersamaan yang berkelanjutan transkripsi suara, pola umum adalah 910B untuk inferensi pusat dan 310P untuk node tepi.

Setup Lingkungan: Penyelarasan Versi Adalah Perangkap Terbesar

Rasa sakit di Ascend Ekosistem bukan perhitungan, itu adalah Versi Matriks (Version Matrix). Driver, firmware, CANN, framework dan format model - salah satu dari lima yang tidak sinkron menghasilkan kegagalan yang membingungkan.

Kombinasi yang biasanya kita lihat stabil:

komponen komponen	Versi versi	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 model hidup di sini
Container adalah sebuah wadah	Ascend Docker Runtime	Diperlukan - Docker polos tidak dapat memasang NPU
Kerangka Inferensi (Inference Framework)	ONNX Runtime + ACL	Model OM bekerja dengan baik tanpa MindSpore
OS OS	openEuler / Kylin V10 / UnionTech UOS	Umum di Lingkungan Xinchuang

Langkah pertama adalah selalu mengkonfirmasi bahwa NPU terlihat:

# 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

Pitfall: pada beberapa sistem Kylin V10, npu-smi info melaporkan kesalahan daemon dmp tepat setelah instalasi driver. Penyebabnya ternyata adalah konflik antara sistem versi dkms sendiri dan penginstal driver. Perbaiki adalah untuk menghapus sistem dkms dan menginstal ulang menggunakan versi yang dibundel dengan paket driver. Masalah adaptasi tingkat distribusi seperti ini jarang didokumentasikan dan merupakan salah satu pemblokir di tempat yang paling umum.

Konversi Model: ONNX ke OM

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

Tiga Hal yang Harus Perhatikan Saat Mengekspor 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"},
    },
)

Tiga tempat di mana ini biasanya salah:

1. Versi Opset - yang lebih baru tidak lebih baik. Versi opset tinggi memukul operator yang tidak didukung lebih sering selama konversi; 14 adalah pilihan yang teruji dengan baik.
2. Dynamic axes (Dinamika sumbu) - panjang audio secara inheren variabel, sehingga dynamic_axes harus dinyatakan, jika tidak Anda dibatasi untuk input panjang tetap dan hasilnya tidak dapat digunakan dalam produksi.
3. Konstan melipat - do_constant_folding=True secara nyata menyusut grafik dan meningkatkan keberhasilan konversi.

Konversi dengan 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

Apa yang sebenarnya dimaksudkan oleh parameter:

• --soc_version - harus sesuai dengan hardware fisik yang tepat. --soc_version - harus sesuai dengan hardware fisik yang tepat. Menentukan 910A pada 910B gagal pada waktu muat dengan kesalahan samar.
• --dynamic_dims - profil bentuk yang dinamis. Untuk audio, profil berdasarkan durasi; terlalu banyak profil meningkatkan waktu kompilasi, terlalu sedikit memicu rekompilasi yang sering dan jitter latensi.
• --precision_mode - allow_fp16 biasanya biaya akurasi diabaikan pada ASR sementara meningkatkan throughput dengan jelas.

Apakah Anda harus mengukur?

Precision (Ketepatan)	Throughput (Troughput)	Akurasi (accuracy)
FP16 FP16	Baseline (baseline)	Baseline (baseline)
INT8	Keuntungan yang jelas	Biaya yang luar biasa

Penghakiman (Verdict): menjaga FP16 di mana akurasi sangat penting (pertemuan medis, hukum); INT8 adalah perdagangan yang lebih baik di mana toleransi kesalahan lebih tinggi, seperti stand-up internal dan rekaman pelatihan.

Deployment: Container adalah satu-satunya pilihan yang masuk akal

Pemasangan bare-metal hampir tidak dapat dipertahankan di situs Xinchuang. Kami menyediakan kontainer:

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

• Berjalan pada bare metal, cloud pemerintah, dan lingkungan lokal;
• Terintegrasi dengan OA dan sistem pertemuan melalui API standar RESTful / WebSocket;
• Skala secara elastis dengan concurrency.

Perhatikan entri --device: kehilangan salah satu dari mereka menghasilkan kegagalan inisialisasi ACL., dan kesalahan tidak akan memberi tahu Anda bahwa perangkat hilang. Ini adalah batu sandungan yang paling umum bagi pendatang baru.

Juga - Jangan membuat protokol pribadi.. Menggunakan standar REST (file transkripsi suara) dan WebSocket (streaming real-time), atau mengintegrasikan dengan pelanggan OA dan sistem pertemuan menjadi menyakitkan.

Jika Anda sudah memiliki server, menyebarkan software-only engine untuk mendapatkan transkripsi suara pribadi pada akselerator domestik tanpa membeli perangkat keras.

Referensi kinerja kinerja

Kondisi uji: Ascend 910B, FP16, audio pertemuan Cina, 16 kHz mono.

Metrik (metric)	Referensi (Reference)	Catatan:
Faktor waktu nyata (RTF)	~ 0.1 perintah	satu jam audio dalam beberapa notulen rapat
Streams bersamaan per kartu	Sepuluh-puluh	Pure transkripsi suara, concurrency pertemuan yang berkelanjutan
Token pertama latensi	Sub-second	Streaming mode; biasanya di bawah 1s dalam praktek
Akurasi transkripsi suara Cina	≥ 98%	Skenario pertemuan Mandarin Standar (spec)
Cakupan dialek	22	Deteksi otomatis (spec)

➢️ Angka concurrency di atas adalah Hanya transkripsi suara saja (kartu ASR tunggal, tidak ada pemisahan pembicara atau penstrukturan menit). Menambahkan pemisahan pembicara ditambah ekstraksi item topik / tindakan menurunkan kapasitas per kartu secara signifikan - perangkat ini dinilai pada 10 pertemuan bersamaan, yang mengacu pada pipa penuh (transkripsi suara + pemisahan + struktur); bentuk cluster dinilai pada 50+ aliran. Selalu tanyakan lapisan mana yang dikutip oleh vendor - ketiganya berbeda dengan penggandaan.

Enam Pitfalls dari Real Deployment

Ini adalah bagian yang paling berharga dari posting ini. Masing-masing dari mereka dipukul di lokasi.

1. Bentuk dinamis yang menyebabkan rekompilasi konstan Tanpa --dynamic_dims, setiap panjang audio baru memicu rekompilasi grafik dan latensi meningkat menjadi detik. Profiling dengan durasi membawanya kembali di bawah detik.

2. Memori audio panjang yang melelahkan Memberi makan rekaman rapat dua jam langsung ke dalam model OOMs perangkat. Anda perlu Inferensi Inkremental Chunked Inferensi Inkremental - segmen oleh VAD dan decode segmen demi segmen daripada memuat seluruh file.

3. Operator yang tidak didukung gagal secara diam-diam A LayerNorm varian tidak memiliki rekan Ascend. ATC tidak menimbulkan kesalahan selama konversi, dan output model semua nol pada runtime. Selalu menjalankan pemeriksaan kesetaraan setelah konversi: menjalankan audio yang sama melalui ONNX Runtime (CPU) dan OM (NPU) dan membandingkan output.

4. Kebocoran konteks di bawah concurrency multi-threaded Versi awal membuat konteks ACL yang terpisah per permintaan dan konteks yang habis di bawah beban. Context pooling telah memperbaikinya.

5. Model harus dikonversi kembali setelah upgrade driver Setelah upgrade CANN utama, model OM yang lebih tua mungkin gagal memuat atau kehilangan kinerja. Masukkan konversi model dalam CI daripada mengkonversi dengan tangan sekali.

6. Kemasan Offline untuk situs-situs yang celah udara Dalam lingkungan yang terisolasi secara fisik, ketergantungan CANN, driver, bobot model, font, dan sertifikat semua harus dikemas terlebih dahulu. Kami pernah tiba di lokasi untuk menemukan font CJK yang hilang, dan setiap transkrip kembali sebagai kotak tahu. Latihan penyebaran penuh pada lingkungan yang setara sebelum mengirim bundel offline.

Kapan Tidak Memilih Akselerator Domestik

Menjadi lurus dengan Anda. Lewati jika:

• Tidak ada Xinchuang atau mandat lokalisasi → GPU Ekosistem jauh lebih dewasa, jangan membuat pekerjaan untuk diri sendiri
• Tidak ada seorang pun di tim yang tahu bahwa biaya operasi CANN akan jauh melebihi apa pun yang disimpan oleh perangkat keras.
• Concurrency adalah satu digit → CPU polos sudah cukup, skip the accelerator

Akselerator domestik adalah panggilan yang tepat ketika: ada mandat kepatuhan yang jelas + tekanan concurrency yang berkelanjutan + kapasitas rekayasa untuk mendukungnya.

Nasihat ukuran

• Lokalisasi cluster baru: VV05 / VV10+ Ascend atau akselerator Cambricon;
• Menggunakan kembali x86 yang ada: mesin pada CPU atau Hygon DCU;
• Lingkungan campuran: menyatukan NVIDIA dan akselerator domestik, jadwal berdasarkan beban.

Jika Anda sedang menimbang private terhadap cloud, lihatlah on-premise ASR selection guide.

Lihatlah private deployment guide dan MLPS Level 3 compliance.