Execução do ASR Privado no Ascend 910B: Configuração, Adaptação do Operador e Transferência de Dados

Este post caminha através do desembarque de um motor chinês de fala para texto em NPUs Huawei Ascend em um ambiente privado - versões de ambiente, conversão de modelo, comandos de implantação, armadilhas e números de desempenho de referência.

Sobre os números: os números marcados com "especificação" vêm do produto publicado Especificações. A tabela de desempenho fornece o Referência magnitude em condições típicas; os valores reais variam com as condições de áudio, o tamanho do modelo e a estratégia de concurrença. Medir sempre em sua própria carga de trabalho.

Por que ele tem que ser executado em hardware doméstico

No governo, finanças e defesa, os sistemas não devem ser apenas "dados no local ", mas também" tecnologicamente auto-suficientes. Isso significa mudar a computação subjacente de GPUs importadas para chips domésticos Ascend, Cambricon e Hygon, e o sistema operacional para Kylin, UnionTech e outros sistemas domésticos.

Em termos de engenharia, isso se torna três restrições difíceis:

• Residência de dados - áudio de reuniões contém discussão interna, e muitas organizações proíbem explicitamente o áudio de sair da intranet.
• Compras Xinchuang - GPUs importadas podem não aparecer na lista de compra aprovada
• Operação Air-gapped - alguns sites não têm conectividade externa, então os pesos do modelo devem ser embalados no ambiente inicialmente

Ponto central: implantação local responde "onde estão os dados"; localização responde "quem controla a tecnologia. Juntos, eles convergem em uma única tarefa - obter ASR em em NPUs domésticos, e em rápido o suficiente.

Aceleradores suportados

Construído com base na pesquisa da NEU NLP (Universidade do Northeastern), o motor VoiVision suporta nativamente aceleradores tradicionais:

Tipo	Representantes	Use
NVIDIA	T4 / L4 / A10 / A100	General, alto desempenho
Ascend	PRODUÇÃO 310P / 910B	Localizados, servidores domésticos
Cambricon	MLU370 / MLU590	Localizados, servidores domésticos
Hygão DCU	Série DCU	Caminho x86 doméstico
Apenas CPU	x86 e ARM	Reutilização existente, baixa concorrência

O Ascend tem atualmente o Ecossistema mais completo entre os aceleradores domésticos (CANN + MindSpore + modelo zoológico). O 910B tem como alvo treinamento e inferência de alto rendimento, enquanto o 310P tem como alvo uso de borda e baixa potência. Para a reunião simultânea sustentada transcrição de fala, um padrão comum é 910B para inferência central e 310P para nós de borda.

Configuração do ambiente: alinhamento de versão é a maior armadilha

A dor no Ascend Ecossistema não é computação, é o Versão Matrix. Driver, firmware, CANN, framework e formato de modelo - qualquer um dos cinco estar fora de sincronização produz falhas confusas.

Uma combinação que geralmente vemos estável:

Componente	Versão	Nota
Driver / Firmware	Fica ligada ao CANN	Verifique a tabela oficial de compatibilidade antes de atualizar
CANNÃO	Série 8.x	Biblioteca de operadores e ferramentas de conversão de modelos ao vivo aqui
Container	Ascend Docker Tempo de Execução	Requerido - Docker simples não pode montar o NPU
Estrutura de Inferência	ONNX Runtime + ACL	Modelos OM funcionam bem sem MindSpore
Os	OpenEuler / Kylin V10 / UnionTech UOS (em inglês)	Comum em ambientes Xinchuang

O primeiro passo é sempre confirmar que a NPU é visível:

# 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

Problema: em alguns sistemas Kylin V10, o npu-smi info relata um erro do daemon dmp logo após a instalação do driver. A causa acabou por ser um conflito entre a versão dkms do sistema e o instalador de drivers. A solução é remover o dkms do sistema e reinstalar usando a versão incluída com o pacote de drivers. Problemas de adaptação em nível de distribuição como este são raramente documentados e estão entre os bloqueadores no site mais comuns.

Conversão de modelo: ONNX para OM

Os modelos ASR são tipicamente treinados em PyTorch, exportados para ONNX, e depois convertidos para o formato OM do Ascend.

Três coisas a observar ao exportar 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"},
    },
)

Três lugares onde isso geralmente vai errado:

1. Versão Opset - mais novo não é melhor. As versões de opset alto atingem operadores não suportados com mais frequência durante a conversão; 14 é uma escolha bem testada.
2. eixos dinâmicos - o comprimento de áudio é inerentemente variável, então dynamic_axes deve ser declarado, caso contrário, você está limitado a entrada de comprimento fixo e o resultado é inutilizável em produção.
3. Folding constante - do_constant_folding=True encolhe notavelmente o gráfico e melhora o sucesso da conversão.

Conversão com 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

O que os parâmetros realmente significam:

• --soc_version - deve corresponder exatamente ao hardware físico. A especificação de 910A em um 910B falha no tempo de carga com um erro vago.
• --dynamic_dims - perfis de forma dinâmica. Para áudio, perfil por duração; muitos perfis aumentam o tempo de compilação, poucos desencadeiam recompilação frequente e jitter de latência.
• --precision_mode - allow_fp16 normalmente custa precisão insignificante em ASR, enquanto melhora a taxa de transferência claramente.

Você deve quantificar?

Precisão	Throughput (em inglês)	precisão
FP16	Baselão	Baselão
INT8	Ganho claro	Custo notável

Veredito (em inglês): Mantenha o FP16 onde a precisão é crítica (reuniões médicas, legais); INT8 é o melhor comércio onde a tolerância a erros é maior, como stand-ups internos e gravações de treinamento.

Implementação: Containers são a única opção sensata

As instalações de metal nu são quase insustentáveis nos locais da Xinchuang. Entrega de Containers:

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

• Funciona em bare metal, nuvem governamental e ambientes localizados;
• Integra-se com o OA e sistemas de reuniões através de APIs padrão RESTful / WebSocket;
• Escala elasticamente pela concorrência.

Observe essas entradas --device: A falta de qualquer um deles produz uma falha de inicialização ACL., e o erro não lhe dirá que um dispositivo está faltando. Esse é o obstáculo mais comum para os recém-chegados.

Então - Não invente um protocolo privado. Use o padrão REST (arquivo transcrição de fala) e WebSocket (streaming em tempo real), ou a integração com os sistemas OA e reuniões do cliente se torna dolorosa.

Se você já tem servidores, implante o software-only engine para obter transcrição de fala privado em aceleradores domésticos sem comprar hardware.

Desempenho de referência

Condições de teste: Ascend 910B, FP16, áudio de reunião chinesa, 16 kHz mono.

Métrica	Referência	Nota
Fator de tempo real (RTF)	~ 0.1 ordem	uma hora de áudio em alguns ata de reunião
Fluxos simultâneos por cartão	Tensão	Pure transcrição de fala, concurrença de reuniões sustentada
Primeira latência token	Subsegundo	Modo de streaming; tipicamente abaixo de 1s na prática
Precisão chinesa transcrição de fala	≥ 98%	Cenários de reunião padrão em mandarim (especificação)
Cobertura dialetal	22	Auto-detecção (especificação)

Não.️ A figura de concurrença acima é Apenas transcrição de fala (cartão único ASR, sem separação de falantes ou estruturação de minutos). Adicionando separação de alto-falantes e extração de tópicos / itens de ação reduz significativamente a capacidade por cartão - o aparelho é classificado em 10 reuniões simultâneas, que se refere ao pipeline completo (transcrição de fala + separação + estruturação); a forma de cluster é classificada em 50+ fluxos. Sempre pergunte qual camada um fornecedor está citando - os três diferem em múltiplos.

Seis armadilhas de implantações reais

Esta é a parte mais valiosa do post. Cada um deles foi atingido no local.

Sem o --dynamic_dims, cada novo comprimento de áudio desencadeia uma recompilha de gráficos e a latência aumentava para segundos. O perfil por duração o trouxe de volta a menos de um segundo.

2. Memória longa de áudio exaustiva A alimentação de uma gravação de reunião de duas horas diretamente para o modelo OOMs o dispositivo. Você precisa de Inferência incremental chunked - segmento por VAD e decodificar segmento por segmento, em vez de carregar todo o arquivo.

3. Operadores não suportados falhando silenciosamente Uma variante LayerNorm não tinha contrapartes Ascend. O ATC não levantou nenhum erro durante a conversão, e o modelo produz todos os zeros no tempo de. Execute sempre uma verificação de equivalência após a conversão: execute o mesmo áudio através do ONNX Runtime (CPU) e OM (NPU) e compare as saídas.

4. Fugas de contexto sob concurrença multi-threaded Uma versão anterior criou um contexto ACL separado por solicitação e contextos exaustos sob carga. Contextual pooling resolveu isso.

Após uma grande atualização do CANN, os modelos OM mais antigos podem falhar em carregar ou perder desempenho. Coloque a conversão de modelo em CI em vez de converter manualmente uma vez. é um

Em ambientes fisicamente isolados, as dependências CANN, drivers, pesos de modelo, fontes e certificados devem ser empacotados com antecedência. Uma vez chegamos ao local para encontrar uma fonte CJK ausente, e cada transcrição voltou como caixas de tofu. Ensaiar a implantação completa em um ambiente equivalente antes de enviar o pacote offline. é um

Quando não escolher aceleradores domésticos

Ser direto com você. Salte-o se:

• Não há Xinchuang ou mandato de localização → o GPU Ecossistema é muito mais maduro, não faça trabalho para si mesmo
• Ninguém na equipe sabe que o custo operacional do CANN excederá em muito o que o hardware economiza.
• Concurrença é de dígitos únicos → CPU simples é suficiente, pular o acelerador

Os aceleradores domésticos são a chamada certa quando: Há um mandato claro de conformidade + pressão de concorrência sustentada + capacidade de engenharia para apoiá - lo.

Conselhos de dimensionamento

• Novo cluster localizado: acelerador / VV10+ Ascend ou Cambricon;
• Reutilização do x86 existente: motor em CPU ou Hygon DCU;
• Ambiente mista: unificar NVIDIA e aceleradores domésticos, horário por carga.

Se você está pesando privados contra nuvem, veja o on-premise ASR selection guide.

Veja o private deployment guide e MLPS Level 3 compliance.