Esecuzione di Private ASR su Ascend 910B: configurazione, adattamento dell 'operatore e throughput

Questo post descrive l'atterraggio di un motore di testo-parole cinese sulle NPU Huawei Ascend in un ambiente privato - versioni di ambiente, conversione del modello, comandi di distribuzione, trappole e cifre di prestazioni di riferimento.

sui numeri: cifre contrassegnate "spec" provengono dal prodotto pubblicato Specifiche. La tabella delle prestazioni dà Riferimento magnitudo in condizioni tipiche; i valori effettivi variano in base alle condizioni audio, alle dimensioni del modello e alla strategia di concurrency. Misurare sempre il proprio carico di lavoro.

Perché deve essere eseguito su hardware domestico

Nel governo, nella finanza e nella difesa, i sistemi non devono essere solo "data on-premise", ma anche "tecnologicamente autosufficienti". Ciò significa spostare il calcolo sottostante dalle GPU importate ai chip domestici Ascend, Cambricon e Hygon, e il sistema operativo a Kylin, UnionTech e altri sistemi domestici.

In termini ingegneristici, questo diventa tre vincoli difficili:

• Dati di residenza - audio riunione contiene discussioni interne, e molte organizzazioni vietano esplicitamente audio da lasciare l'intranet
• Approvvigionamento Xinchuang - le GPU importate non apparire affatto nell 'elenco di acquisto approvato
• Operazione Air-Gapped - alcuni siti non hanno connettività esterna, quindi i pesi del modello devono essere confezionati all 'interno dell' ambiente in anticipo

Punto centrale: distribuzione on-premise risponde "dove si trovano i dati"; la localizzazione risponde "chi controlla la tecnologia. Insieme convergono su un unico compito - ottenere ASR in esecuzione su NPU nazionali, e in esecuzione abbastanza veloce.

Acceleratori supportati

Basato sulla ricerca di NEU NLP (Northeastern University), il motore VoiVision supporta nativamente gli acceleratori tradizionali:

Tipo	Rappresentanti	Utilizzare
NVIDIA	T4 / L4 / A10 / A100	Generale, alte prestazioni
Ascend	310P e 910B	Localizzazioni, server domestici
Cambricon	MLU370 / MLU590	Localizzazioni, server domestici
Hygon DCU è il	Serie DCU	Il percorso x86
Solo CPU	x86 e ARM	Riutilizzo esistente, bassa concorrenza

Lo Ascend ha attualmente lo Ecosistema più completo tra gli acceleratori nazionali (CANN + MindSpore + model zoo). Il 910B si rivolge all ' allenamento e all ' inferenza ad alto throughput, mentre il 310P si rivolge all ' uso edge e a bassa potenza. Per sostenuto simultanea riunione trascrizione vocale, un modello comune è 910B per l'inferenza centrale e 310P per i nodi di bordo.

Configurazione dell 'ambiente: l'allineamento delle versioni è la più grande trappola

Il dolore nella Ascend Ecosistema non è il calcolo, è la Versione Matrix. Driver, firmware, CANN, framework e formato del modello - uno qualsiasi dei cinque non sincronizzati produce guasti sconcertanti.

Una combinazione che di solito vediamo stabile:

Componente	Versione	Nota
Driver / Firmware	Strettamente legato a Cannes	Controllare la tabella di compatibilità ufficiale prima di aggiornare
CANN	Serie 8.x	La libreria operatore e gli strumenti di conversione dei modelli sono disponibili qui
contenitore	Ascend Docker Runtime	Richiesto - Docker semplice non può montare la NPU
Quadro di inferenza	ONNX Runtime + ACL	I modelli OM funzionano bene senza MindSpore
OS	OpenEuler / Kylin V10 / UnionTech UOS	Ambienti comuni a Xinchuang

Il primo passo è confermare sempre che la NPU è visibile:

# 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

Problemi: su alcuni sistemi Kylin V10, npu-smi info segnala un errore del demone dmp subito dopo l'installazione del driver. La causa si è rivelata essere un conflitto tra la versione dkms del sistema e l'installatore del driver. La soluzione è quella di rimuovere il dkms di sistema e reinstallare utilizzando la versione fornita con il pacchetto driver. Problemi di adattamento a livello di distribuzione come questo sono raramente documentati e sono tra i bloccatori più comuni sul sito.

Conversione di modello: ONNX a OM

I modelli ASR sono tipicamente addestrati in PyTorch, esportati in ONNX, quindi convertiti nel formato OM di Ascend.

Tre cose da osservare quando si esporta 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"},
    },
)

Tre posti in cui questo spesso va storto:

1. Versione Opset - più nuovo non è meglio. Le versioni ad alto opset colpiscono più spesso gli operatori non supportati durante la conversione; 14 è una scelta ben testata.
2. Assi dinamici - la lunghezza audio è intrinsecamente variabile, quindi dynamic_axes deve essere dichiarato, altrimenti si è limitati all 'ingresso a lunghezza fissa e il risultato è inutilizzabile in produzione.
3. Costante Folding - do_constant_folding=True riduce notevolmente il grafico e migliora il successo della conversione.

Conversione con 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

Cosa significano i parametri:

• --soc_version - deve corrispondere esattamente all 'hardware fisico. La specificazione di 910A su un 910B non riesce al momento del caricamento con un errore vago.
• --dynamic_dims - profili di forma dinamici. Per l'audio, il profilo per durata; troppi profili aumentano il tempo di compilazione, troppi pochi innescano ricompilazione frequente e jitter di latenza.
• --precision_mode - allow_fp16 in genere costa una precisione trascurabile su ASR, migliorando chiaramente il throughput.

Dovresti quantificare?

Precisione	Il throughput	Accuratezza
FP16	Baseline	Baseline
INT8	Chiara guadagno	Costo notevole

Verdetto: tenere FP16 dove l'accuratezza è critica (incontri medici, legali); INT8 è il migliore commercio dove la tolleranza agli errori è più alta, come stand-up interne e registrazioni di allenamento.

Deployment: i container sono l'unica opzione sensata

Le installazioni in metallo nudo sono quasi insostenibili nei siti di Xinchuang. Consegniamo i container:

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

• Esegue su bare metal, cloud governativo e ambienti localizzati;
• Integrazione con OA e sistemi di meeting tramite API RESTful / WebSocket standard;
• Scala elasticamente per concorrenza.

Notare quelle voci --device: Mancando uno di essi produce un errore di inizializzazione ACL, e l'errore non ti dirà che manca un dispositivo. Questo è il blocco d'inciampo più comune per i nuovi arrivati.

di Non inventare un protocollo privato. Utilizzare standard REST (file trascrizione vocale) e WebSocket (streaming in tempo reale), o l'integrazione con il cliente OA e sistemi di riunioni diventa doloroso.

Se hai già dei server, distribuisci software-only engine per ottenere trascrizione vocale privati su acceleratori domestici senza acquistare hardware.

Performance di riferimento

Condizioni di prova: Ascend 910B, FP16, audio riunione cinese, 16 kHz mono.

Metric	Referenza	Nota
Fattore in tempo reale (RTF)	~ 0.1 Ordine	Un 'ora di audio in pochi verbale di riunione
Flussi simultanei per carta	Tens	Pure trascrizione vocale, la concurrenza dei meeting sostenuta
La latenza di First Token	Sub-secondo	Modalità streaming; tipicamente sotto 1s in pratica
Accuratezza trascrizione vocale cinese	≥ 98%	Scenari di riunione standard in mandarino (spec)
Copertura dialettica	22	Auto-rilevazione (spec)

di️ La figura di concurrenza sopra è Solo trascrizione vocale (singla scheda ASR, senza separazione dei parlanti o strutturazione minuti). L'aggiunta della separazione degli altoparlanti e l'estrazione argomento / elemento di azione riduce significativamente la capacità per scheda - l'apparecchio è valutato per 10 riunioni simultanee, che si riferisce alla pipeline completa (trascrizione vocale + separazione + strutturazione); la forma di cluster è valutata a 50+ flussi. Chiedi sempre quale strato un fornitore sta citando - i tre differiscono per multipli.

Sei trappole da implementazioni reali

Questa è la parte più preziosa del post. Ognuno di questi è stato colpito sul sito.

Senza 1. Forme dinamiche che causano costante ricompilazione, ogni nuova lunghezza audio innescava una ricompilazione del grafico e la latenza aumentava a secondi. La profilazione per durata l'ha riportata in meno di un secondo

2. Lungo audio esaurisce la memoria Inserendo una registrazione di due ore di riunioni direttamente nel modello OOMs il dispositivo. Hai bisogno di Inferenza incrementale - segmento per VAD e decodificare segmento per segmento piuttosto che caricare l'intero file.

3. Operatori non supportati che falliscono silenziosamente Una variante di LayerNorm non aveva controparte Ascend. ATC non ha sollevato alcun errore durante la conversione, e il modello emette tutti gli zeri al runtime. Eseguire sempre un controllo di equivalenza dopo la conversione: esegue lo stesso audio attraverso ONNX Runtime (CPU) e OM (NPU) e confronta le uscite.

4. Context leaks sotto la concurrenza multi-threaded Una versione precedente ha creato un contesto ACL separato per richiesta e i contesti esauriti sotto carico. Context pooling ha risolto.

5. I modelli devono essere riconvertiti dopo l'aggiornamento del driver Dopo un importante aggiornamento CANN, i modelli OM più vecchi non essere caricati o perdere prestazioni. Mettere la conversione del modello in CI piuttosto che convertire manualmente una volta.

6. Imballaggio Offline per siti con Air Gap In ambienti fisicamente isolati, le dipendenze CANN, i driver, i pesi del modello, i font e i certificati devono essere tutti confezionati in anticipo. Una volta siamo arrivati sul sito per trovare un font CJK mancante e ogni trascrizione è tornata come scatole di tofu. Prova la distribuzione completa in un ambiente equivalente prima di spedire il bundle offline.

Quando non scegliere un acceleratore domestico

Essere dritto con te. Salta se:

• Non c'è Xinchuang o mandato di localizzazione → il GPU Ecosistema è molto più maturo, non fare il lavoro per te stesso
• Nessuno nel team sa che il costo operativo di CANN supererà di gran lunga quello che risparmierà l'hardware.
• Concurrenza è a cifre singole → semplice CPU è sufficiente, saltare l'acceleratore

Gli acceleratori nazionali sono la scelta giusta quando: c'è un chiaro mandato di conformità + pressione di concorrenza sostenuta + capacità di ingegneria per supportarlo.

Consigli di dimensione

• Nuovo cluster localizzato: acceleratore VV05 / VV10+ Ascend o Cambricon;
• Riutilizzare l'esistente x86: motore su CPU o Hygon DCU;
• Ambiente misto: unificare NVIDIA e acceleratori nazionali, programma per carico.

Se stai valutando il privato contro il cloud, vedi on-premise ASR selection guide.

Vedere private deployment guide e MLPS Level 3 compliance.