Transcrição de reuniões no Ascend 310P: matriz de versões, conversão de modelos e sete lições de campo

Este artigo documenta a implantação de um motor de fala chinês transcrição de fala no Cartão de inferência Ascend 310P. O 310P é um cartão de inferência de borda com um posicionamento diferente do 910B, e seus cenários estão mais próximos do processamento local em sala.

Base de dados: os números marcados com "especificação oficial" vêm de métricas de produto publicadas; a tabela de desempenho dá Valores de referência para um ambiente típico. Os números reais variam com as condições de áudio, o tamanho do modelo e a estratégia de concurrença - sempre adiar para suas próprias medições.

O que o 310P é bom e o que não é

Não há escassez de artigos Sobre nós o Ascend 310P, mas a maioria parou em "CANN está instalado e a demonstração é executada". A armadilha é o Colocá - lo em funcionamento uma vez e servir de forma confiável são duas coisas totalmente diferentes.

Conclusão à frente:

Dimensão	Comportamento 310P	Notas
Posicionamento	Cartão de Inferência Edge	Não é um cartão de treinamento; não espere afinar isso
Divida com o 910B	Edge Node (em inglês)	910B lida com inferência central, 310P lida com processamento local
Concurrença transcrição de fala pura por cartão	Dezenas de correntes	Base de modelo único ASR (valor de referência)
Concurrença Full-Pipeline	caiu significativamente	Uma vez que o separação de falantes e a estruturação são adicionados
Precisão chinesa transcrição de fala	≥ 98%	Cenário de reunião padrão em mandarim (especificação oficial)
Cobertura dialetal	22 Dialetos	Detecção automática (especificação oficial)

Uma armadilha de seleção vale a pena marcar: Muitos fornecedores citam a concurrença sem indicar a base. "XX fluxos por cartão" pode significar ASR puro, ou pode significar o pipeline completo. As duas podem diferir várias vezes. Pergunte sempre qual camada o número cobre. é um

Nosso Arquitetura típico é 910B no centro, 310P na borda: o áudio é transcrito localmente na sala de reuniões, e apenas o texto estruturado retorna ao centro. Isso mantém a largura de banda sob controle e atende a um requisito de "dados não saem da sala de reuniões".

Preparação do ambiente: a matriz de versões é o verdadeiro obstáculo

O ponto de dor no Ascend Ecossistema nunca é computação - é Alinhamento versão. Driver, firmware, CANN, tempo de de contêineres, estrutura de inferência, formato de modelo: Se qualquer um dos seis está desalinhado, produz uma falha desconcertante., e a mensagem de erro freqüentemente não diz o que deu errado.

Uma combinação que verificamos e encontramos estável:

Componente	Versão	Notas
Driver / Firmware	Fica ligada ao CANN	Verifique a tabela oficial de compatibilidade antes de atualizar
CANNÃO	Série 8.x	A biblioteca do operador e a ferramenta de conversão ATC estão aqui
Container Runtime	Ascend Docker Tempo de Execução	Requerido; Docker comum não pode montar o NPU
Estrutura de Inferência	ONNX Runtime + ACL	Executar modelos OM
Os	OpenEuler / Kylin V10 / UnionTech UOS (em inglês)	Comum em ambientes Xinchuang

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

# 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

Uma lição de campo: em alguns ambientes Kylin V10, o npu-smi info relatou uma exceção do daemon dmp após a instalação do driver. A causa acabou por ser um conflito entre o dkms incluído no sistema e o script de instalação do driver. A solução foi desinstalar o dkms do sistema e reinstalar usando a versão incluída com o pacote de drivers.

Problemas específicos de distribuição como este geralmente não são encontrados na documentação oficial., e eles são o bloqueador mais comum no site.

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 Ascend OM com ATC.

Três coisas a observar ao exportar 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. Opets mais novos são mais propensos a atingir operadores não suportados; 14 é uma boa escolha de compatibilidade.
2. Os eixos dinâmicos devem ser declarados. Caso contrário, você só pode executar áudio de comprimento fixo, o que é inutilizável na prática.
3. Permite o dobramento constante. do_constant_folding=True reduz substancialmente o tamanho do gráfico e melhora o sucesso da conversão.

Os parâmetros do ATC, um a um

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

Os três parâmetros mais propensos a causar problemas:

• --soc_version: Deve corresponder exatamente ao hardware real. O 310P deve ser escrito como Ascend310P; Ascend310 ou Ascend910B falharão no estágio de carga, com um erro muito vago.
• --dynamic_dims: as camadas dinâmicas. Para o áudio, o nível Duração em segundos. Muitas camadas fazem com que o tempo de compilação explode; poucas vezes acionam a recompilação frequente e a latência jittery. O conjunto acima (1s / 2s / 3s) é o ponto de equilíbrio que medimos.
• --precision_mode: O allow_fp16 tem um impacto insignificante na precisão do ASR e um claro ganho de rendimento.

Você deve quantificar?

Precisão	Throughput (em inglês)	precisão
FP16	Baselão	Baselão
INT8	Ganho claro	Perda perceptível

Conclusão: para cenários extremamente sensíveis à precisão - médico, legal - Fique no FP16. Para reuniões internas e registros de treinamento, onde a tolerância é maior, O INT8 é o melhor comércio.

Não persiga os números de benchmark com INT8 cegamente. Em cenários de reuniões, a perda de precisão aparece como "cada nome errado, cada termo errado", e o custo de reformulação excede em muito o cálculo que você economizou.

Implementação: a containerização é a única escolha sensata

A instalação do ambiente em metal nu é praticamente insustentável em ambientes Xinchuang. Entrega como um 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:310p \
  ./asr_server --model /models/asr_om --port 8000

A falta de qualquer um desses sinais --device produz uma falha de inicialização ACL, e o erro não diz que um dispositivo foi omitido. Esse é o maior bloqueador para os recém-chegados.

Mais uma lição: Use o RESTful padrão (arquivo transcrição de fala) mais WebSocket (streaming em tempo real), ou a integração com os sistemas OA e reuniões de um cliente se torna muito dolorosa.

Os clientes que já possuem servidores podem implantar o pure-software speech engine diretamente, ganhando transcrição de fala privado em aceleradores domésticos sem comprar hardware.

Sete lições do campo

Esta é a parte mais valiosa do artigo. Todos os itens foram aprendidos da maneira difícil, não copiados da documentação.

1. Formas dinâmicas causam recompilação frequente Nós não definimos --dynamic_dims no início, então cada clipe de áudio de tamanho diferente acionou uma compilação de gráficos e latência aumentou para segundos. Uma vez que os níveis foram configurados, a latência se estabeleceu na faixa de subsegundos.

2. O áudio longo esgota a memória A alimentação de uma gravação de reunião de duas horas para o modelo em uma passagem causou um OOM imediato. Você deve usar Inferência incremental segmentada - cut by VAD e alimentar o decodificador segmento por segmento em vez de carregar a coisa toda. Mais tarde, adicionamos um Cap de 60 segundos forçado no buffer de áudio, o que eliminou completamente o risco de OOM.

3. Falha do operador silencioso Uma variante particular do LayerNorm não tinha operador correspondente no Ascend. Esta é a classe mais perigosa de fracasso, porque parece sucesso. Você deve executar uma verificação de equivalência: alimenta o mesmo áudio através do ONNX Runtime no CPU e do OM no NPU, em seguida, compara as saídas. Esta é a única solução - não a pule.

As primeiras versões do 4. Contexto Leakage sob Concurrença Multithreaded criaram um contexto ACL separado por solicitação, exaustando contextos sob alta concurrença. O Contexto Pooling resolveu isso.

5. Uma atualização do driver significa converter o modelo novamente. Após uma grande atualização do CANN, um modelo OM antigo pode falhar em carregar ou regressar em desempenho. Coloque a conversão do modelo em CI em vez de converter manualmente e chamá - lo feito.

Em um ambiente fisicamente isolado, todos os produtos Dependências CANN, drivers, pesos de modelo, fontes chinesas e certificados devem ser embalados com antecedência. Uma vez acertamos: um Falta de fonte chinesa no local, e cada resultado do transcrição de fala saiu como caixas. O pacote offline deve ser ensaiado através do fluxo de implantação completo em um ambiente equivalente. é um

7. Mensagens de erro enganosas descarrilam o diagnóstico Alguns erros do Ascend fornecem apenas um código, não uma causa raiz. Uma vez, passamos três dias com uma falha de carga sem progresso, e acabou por ser um soc_version errado. A lição: quando você tiver um erro vago, verifique novamente a matriz de versão do topo - é muito mais rápido do que ler logs linha por linha.

O pipeline completo: do discurso ao ata de reunião

Um ponto final: O discurso transcrição de fala é apenas o primeiro passo.

O que um cenário real precisa é "ata de reunião quando a reunião terminar ". Isso requer separação de falantes, estruturação semântica (tópicos,, itens de ação) e geração ata de reunião após o estágio ASR. Camadas desses três em Reduzir significativamente a concorrência - que é exatamente por que continuamos enfatizando que você deve perguntar qual camada um número de concurrença cobre.

Nossa abordagem executa todo o pipeline em um único servidor, com áudio e texto nunca deixando a rede interna. Para cenários de governo, finanças e defesa, esse é um requisito difícil.

Quando não escolher aceleradores domésticos

Vamos ser direto Sobre nós isso, em vez de empurrá - lo.

Se a sua situação atender a qualquer um dos seguintes, Use um GPU em vez disso:

• Nenhum requisito obrigatório de Xinchuang ou tecnologia doméstica → o GPU Ecossistema é muito mais maduro; não crie problemas para si mesmo
• Ninguém na equipe conhece o canon → O custo operacional excederá em muito o dinheiro economizado em hardware

O valor dos aceleradores domésticos é Conformidade, não custo-eficácia. Se a conformidade não é uma restrição difícil, a aritmética não funciona.

Apêndice: Lista completa de compatibilidade

Componente	Range suportado
Ascend	PRODUÇÃO 310P / 910B
Cambricon	MLU370 / MLU590
Hygon	DCU
NVIDIA	/ L4 / A10 / A100 e a gama completa
Apenas CPU	Suportado (baixa concurrença / reutilização de hardware existente)

Implantação via Docker e Kubernetes, executando em bare metal, nuvem governamental e ambientes Xinchuang, integrando-se com OA e sistemas de reuniões através de interfaces padrão RESTful / WebSocket.

Leia mais: Private ASR on the Ascend 910B | How to choose a private-deployment ASR