Ejecutar ASR privado en Ascend 910B: configuración, adaptación del operador y rendimiento

Este post recorre el aterrizaje de un motor chino de voz a texto en las NPUs Huawei Ascend en un entorno privado: versiones de entorno, conversión de modelo, comandos de implementación, trampas y cifras de rendimiento de referencia.

Sobre los números: las cifras marcadas con "especificación" provienen del producto publicado Especificaciones. La tabla de rendimiento da a magnitud de referencia en condiciones típicas; los valores reales varían con las condiciones de audio, el tamaño del modelo y la estrategia de concurrencia. Siempre mide su propia carga de trabajo.

Por qué tiene que ejecutarse en hardware doméstico

En el gobierno, las finanzas y la defensa, los sistemas no solo deben ser "datos en las instalaciones ", sino también" tecnológicamente autosuficientes. Eso significa cambiar la computación subyacente de las GPUs importadas a los chips domésticos Ascend, Cambricon y Hygon, y el sistema operativo a Kylin, UnionTech y otros sistemas domésticos.

En términos de ingeniería, esto se convierte en tres restricciones duras:

• Datos de residencia - audio de la reunión contiene discusión interna, y muchas organizaciones prohíben explícitamente que el audio salga de la intranet.
• Compras de Xinchuang: las GPU importadas pueden no aparecer en la lista de compra aprobada
• Operaciones Air-gapped - algunos sitios no tienen conectividad externa, por lo que los pesos del modelo deben ser empaquetados en el entorno por adelantado

Punto central: implementación local responde "dónde están los datos "; la localización responde" quién controla la tecnología. Juntos, convergen en una sola tarea - Obtener ASR funcionando en NPUs nacionales, y funcionando lo suficientemente rápido.

Aceleradores apoyados

Construido sobre la investigación de NEU NLP (Universidad del Northeastern), el motor VoiVision admite de forma nativa aceleradores convencionales:

Tipo	Representantes	Uso
NVIDIA	T4 / L4 / A10 / A100	General, alto rendimiento
Ascend	310P y 910B	Servidores localizados, domésticos
Cambricon	MLU370 / MLU590	Servidores localizados, domésticos
El Hygon DCU	Serie DCU	Camino x86
Sólo CPU	x86 y ARM	Reutilización existente, baja concurrencia

Actualmente, Ascend tiene el Ecosistema más completo entre los aceleradores nacionales (CANN + MindSpore + modelo zoológico). El 910B se enfoca en el entrenamiento y la inferencia de alto rendimiento, mientras que el 310P se enfoca en el uso del borde y la baja potencia. Para una reunión concurrente sostenida transcripción de voz, un patrón común es 910B para la inferencia central y 310P para los nodos de borde.

Configuración del entorno: la alineación de versiones es la trampa más grande

El dolor en el Ascend Ecosistema no es computación, es el Versión Matrix. El controlador, el firmware, CANN, el marco y el formato del modelo - cualquiera de los cinco que están fuera de sincronización produce fallas desconcertantes.

Una combinación que comúnmente vemos estable:

Componente	Versión	Nota
Conductor / firmware	Fuertemente ligado a CANN	Compruebe la tabla oficial de compatibilidad antes de actualizar
CANN	Serie 8.x	La biblioteca de operadores y las herramientas de conversión de modelos están disponibles aquí
Contenedor	Ascend Docker Tiempo de ejecución	Requerido - Docker no puede montar la NPU
Marco de Inferencia	ONNX Runtime + ACL	Los modelos OM funcionan bien sin MindSpore
Os	OpenEuler / Kylin V10 / UnionTech UOS	Común en los entornos de Xinchuang

El primer paso es siempre confirmar que la NPU es visible:

# 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

Trampa: en algunos sistemas Kylin V10, npu-smi info informa de un error del daemon dmp inmediatamente después de la instalación del controlador. La causa resultó ser un conflicto entre la versión dkms del sistema y el instalador del controlador. La solución es eliminar el sistema dkms y reinstalar usando la versión incluida con el paquete de controladores. Problemas de adaptación a nivel de distribución como estos rara vez se documentan y se encuentran entre los bloqueadores más comunes en el sitio.

Conversión de modelo: ONNX a OM

Los modelos de ASR suelen ser entrenados en PyTorch, exportados a ONNX, y luego convertidos al formato OM de Ascend.

Tres cosas a observar al 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"},
    },
)

Hay tres lugares donde esto suele ir mal:

1. Versión Opset - más nuevo no es mejor. Las versiones de alto ofset golpean a los operadores no soportados con más frecuencia durante la conversión; 14 es una opción bien probada.
2. Ejes dinámicos: la longitud de audio es inherentemente variable, por lo que debe declararse dynamic_axes, de lo contrario se limita a la entrada de longitud fija y el resultado es inutilizable en producción.
3. El folding constante - do_constant_folding=True reduce notablemente el gráfico y mejora el éxito de la conversión.

Conversión 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

Lo que significan los parámetros:

• --soc_version - debe coincidir con el hardware físico exactamente. La especificación de 910A en un 910B falla en el tiempo de carga con un error vago.
• --dynamic_dims: perfiles de forma dinámica. Para el audio, perfil por duración; demasiados perfiles aumentan el tiempo de compilación, muy pocos desencadenan la recopilación frecuente y el jitter de latencia.
• --precision_mode - allow_fp16 suele costar una precisión insignificante en ASR mientras mejora claramente el rendimiento.

¿Deberías cuantificar?

precisión	throughput	Precisión
FP16	Baselín	Baselín
INT8	ganancia clara	Costo notable

por Veredicto Mantener el FP16 donde la precisión es crítica (reuniones médicas, legales); INT8 es el mejor comercio donde la tolerancia a los errores es mayor, como los stands-ups internos y las grabaciones de entrenamiento.

Despliegue: los contenedores son la única opción sensata

Las instalaciones de metal desnudo son casi insostenibles en los sitios de Xinchuang. Entrega de contenedores:

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

• Se ejecuta en bare metal, nube gubernamental y entornos localizados;
• Integración con OA y sistemas de reuniones a través de las API RESTful / WebSocket estándar;
• Escala elástica por concurrencia.

Tenga en cuenta las entradas --device: La falta de cualquiera de ellos produce un fallo de inicialización ACL., y el error no le dirá que falta un dispositivo. Este es el obstáculo más común para los recién llegados.

Y también: No invente un protocolo privado. Utilice REST estándar (archivo transcripción de voz) y WebSocket (transmisión en tiempo real), o la integración con los sistemas OA y reuniones del cliente se vuelve dolorosa.

Si ya tiene servidores, implementa el software-only engine para obtener transcripción de voz privado en aceleradores nacionales sin comprar hardware.

Rendimiento de referencia

Condiciones de prueba: Ascend 910B, FP16, audio de reunión chino, 16 kHz mono.

Métrica	Referencia	Nota
Factor de tiempo real (RTF)	~ 0.1 orden	Una hora de audio en unos pocos acta de reunión
Flujos concurrentes por tarjeta	Diez	Pure transcripción de voz, concurrencia de reuniones sostenida
Primer token latencia	Subsegundo	Modo de transmisión; típicamente menos de 1s en la práctica
Precisión china transcripción de voz	≥ 98%	Escenarios de reuniones estándar en mandarín (especificación)
Cobertura dialectal	22	Auto-detección (especificación)

✪️ La figura de concurrencia anterior es Sólo transcripción de voz (tarjeta ASR única, sin separación de hablantes o estructuración de minutos). La adición de separación de altavoces más la extracción de temas / elementos de acción reduce significativamente la capacidad por tarjeta: el dispositivo está calificado en 10 reuniones concurrentes, que se refiere a la tubería completa (transcripción de voz + separación + estructuración); la forma de clúster está clasificada en más de 50 flujos. Siempre pregunte qué capa un vendedor está citando - los tres difieren por múltiples.

Seis trampas de implementaciones reales

Esta es la parte más valiosa del post. Cada uno de ellos fue golpeado en el sitio.

1. Formas dinámicas que causan una recopilación constante Sin --dynamic_dims, cada nueva longitud de audio desencadenaba una recompilación de gráficos y la latencia aumentaba a segundos. El perfil por duración lo devolvió a menos de un segundo.

2. Memoria de audio agotadora La alimentación de una grabación de una reunión de dos horas directamente en el modelo OOMs el dispositivo. Necesita Inferencia incremental chunked - segmento por VAD y decodificar segmento por segmento en lugar de cargar todo el archivo.

3. Operadores no soportados fallan silenciosamente Una variante LayerNorm no tenía contraparte Ascend. ATC no produjo ningún error durante la conversión, y el modelo produce todos los ceros en tiempo de ejecución. Ejecutar siempre una verificación de equivalencia después de la conversión: ejecuta el mismo audio a través de ONNX Runtime (CPU) y OM (NPU) y compara los resultados.

4. Fugas de contexto bajo concurrencia multi-hilo Una versión anterior creó un contexto ACL separado por solicitud y los contextos agotados bajo carga. Context pooling lo arregló.

5. Los modelos deben ser reconvertidos después de actualizar los controladores Después de una actualización importante de CANN, los modelos OM más antiguos pueden no cargar o perder rendimiento. Poner la conversión de modelo en CI en lugar de convertir a mano una vez.

En entornos físicamente aislados, las dependencias CANN, los controladores, los pesos del modelo, las fuentes y los certificados deben ser empaquetados de antemano. Una vez llegamos al sitio para encontrar una fuente CJK faltante, y cada transcripción regresó como cajas de tofu. Ensayo de la implementación completa en un entorno equivalente antes de enviar el paquete sin conexión.

Cuándo no elegir aceleradores nacionales

Ser directo contigo. Saltarlo si:

• No hay Xinchuang o mandato de localización → el GPU Ecosistema es mucho más maduro, no hagas el trabajo para ti mismo
• Nadie en el equipo sabe que el costo de las operaciones de CANN excederá con creces lo que ahorra el hardware.
• Concurrencia es de un solo dígito → CPU simple es suficiente, saltar el acelerador

Los aceleradores nacionales son la llamada correcta cuando: Hay un mandato claro de cumplimiento + presión de concurrencia sostenida + capacidad de ingeniería para respaldarlo.

Consejos de tamaño

• Nuevo cluster localizado: acelerador VV05 / VV10+ Ascend o Cambricon;
• Reutilización de x86 existente: motor en CPU o Hygon DCU;
• Ambiente mixto: unificar NVIDIA y aceleradores nacionales, horario por carga.

Si está sopesando la nube privada, consulte el on-premise ASR selection guide.

Ver private deployment guide y MLPS Level 3 compliance.