Ascend 310P에서의 회의 전사: 버전 매트릭스, 모델 변환, 현장에서 겪은 7가지 함정

이 문서에서는 Ascend 310 P 추론 카드 에 중국어 음성 음성 전사 엔진을 배포하는 문서입니다. 310 P 는 910 B 와 다른 포지셔닝을 가진 에지 추론 카드이며, 그 시나리오는 실내 로컬 처리와 더 가깝습니다.

데이터베이스: "공식 사양" 으로 표시된 수치는 발표된 제품 측정 단위에서 가져온 것입니다. 성능 표에서는 일반적인 환경에 대한 참조 값 를 제공합니다.실제 수치는 오디오 조건, 모델 크기 및 동시작업 전략에 따라 달라집니다. 항상 사용자 측정을 보류하십시오.

310 P 가 좋은 것과 그렇지 않은 것은 무엇입니까?

회사 소개 Ascend 310 P 에 대한 기사 부족하지 않지만 대부분의 경우 "CANN 이 설치되고 데모가 실행됩니다."진짜 덫은 한 번 실행하는 것과 신뢰할 수 있는 서비스를 제공하는 것은 완전히 다른 두 가지입니다.

결론은 앞에:

치수	310 P 동작	주석
위치 지정	가장자리 추론 카드	교육 카드가 아닙니다. 미세 조정할 수 없습니다.
910 B 와 분리	가장자리 노드	910 B 는 중앙 추론을 처리하고 310 P 는 로컬 처리를 처리합니다.
카드당 Pure 음성 전사 동시 실행	수십 개의 개울	ASR 단일 모델 기준 (참조 값)
전체 파이프라인 동시작업	크게 떨어지다.	화자 분리 및 구조화 추가
중국어 음성 전사 정확도	≥ 98%	표준 중국어 회의 시나리오 (공식 사양)
방언 범위	22 방언	자동 탐지 (공식 사양)

플래그를 지정할 가치가 있는 선택 트랩 하나: 많은 공급업체들은 기준을 밝히지 않고 동시성을 제시합니다. "카드당 XX 스트림" 은 순수한 ASR 를 의미하거나 전체 파이프라인을 의미 할 수 있습니다.둘은 여러 번 다를 수 있다. 항상 숫자가 어떤 레이어를 덮는지 물어보십시오.

우리의 전형적인 아키텍처 는 중앙에 910 B, 가장자리에 310 P 입니다: 오디오는 회의실에서 로컬로 전사되며, 구조화된 텍스트만 센터로 반환됩니다.따라서 대역폭을 제어하고 "데이터가 회의실을 떠나지 않음" 요구 사항을 충족합니다.

환경 준비: 버전 매트릭스가 실제 장애물입니다.

Ascend 에코시스템 의 고통 지점은 결코 계산되지 않습니다 - 그것은 버전 정렬 입니다.드라이버, 펌웨어, CANN, 컨테이너 런타임, 추론 프레임워크, 모델 형식: 6 개 중 어느 하나라도 잘못 정렬되면 혼란스러운 고장이 발생합니다., 그리고 오류 메시지는 종종 무엇이 잘못되었는지 말하지 않습니다.

우리가 확인하고 안정적으로 발견 한 조합:

구성요소	버전	주석
드라이버 / 펌웨어	CANN 에 단단히 묶여있다	업그레이드하기 전에 공식 호환성 표를 확인합니다.
CANN	8. x 시리즈	운영자 라이브러리 및 ATC 변환 도구가 여기에 있습니다.
컨테이너 런타임	Ascend Docker 런타임	필수 사항; 일반 Docker 는 NPU 를 마운트할 수 없습니다.
추론 프레임워크	ONNX 런타임 + ACL	OM 모델 실행
운영 체제	openEuler / Kylin V 10 / UnionTech UOS	신창환경에서 일반적

첫 번째 단계는 항상 NPU 가 표시되는지 확인하는 것입니다.

# 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

현장 수업 A field lesson: 일부 Kylin V 10 환경에서 npu-smi info 가 드라이버를 설치한 후 dmp 데몬 예외를 보고했습니다.그 원인은 시스템에 번들로 제공된 dkms 와 드라이버 설치 스크립트 간의 충돌로 밝혀졌습니다.수정 사항은 시스템 dkms 를 제거한 다음 드라이버 패키지와 함께 번들로 제공된 버전을 사용하여 다시 설치하는 것이었습니다.

이 일반적으로 공식 문서에서 찾을 수 없습니다. 와 같은 배포 특정 문제는 사이트에서 가장 일반적인 차단기입니다.

모델 변환: ONNX 에서 OM

ASR 모델은 일반적으로 PyTorch 에서 교육되고 ONNX 로 내보낸 다음 ATC 를 사용하여 Ascend OM 형식으로 변환됩니다.

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. 더 높은 오프셋 버전은 더 좋지 않습니다. 최신 오퍼셋은 지원되지 않는 연산자를 타격할 가능성이 더 높으며, 14 은 호환성이 좋은 선택입니다.
2. 동적 축을 선언해야 합니다. 그렇지 않으면 고정 길이 오디오만 실행할 수 있으며 실제로는 사용할 수 없습니다.
3. 상수 접기를 활성화합니다. do_constant_folding=True 는 그래프 크기를 크게 줄이고 변환 성공률을 향상시킵니다.

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=Ascend310P \
    --precision_mode=allow_fp16 \
    --log=error

문제를 일으킬 가능성이 가장 높은 세 가지 매개 변수:

• --soc_version: 실제 하드웨어와 정확히 일치해야 합니다. 310 P 는 Ascend310P 로 작성되어야 하며, Ascend310 또는 Ascend910B 는 모두 로드 단계에서 매우 모호한 오류로 실패합니다.
• --dynamic_dims: 동적 계층.오디오의 경우 기간별 (초) 계층을 지정하십시오.너무 많은 계층은 컴파일 시간이 폭발하고, 너무 적은 계층은 빈번한 재컴파일과 지터리 지연을 유발합니다.위의 세트 (1 s / 2 s / 3 s) 는 우리가 측정한 균형점입니다.
• --precision_mode: allow_fp16 는 ASR 에 대한 정확도에 거의 영향을 미치지 않으며 처리량 증가는 분명합니다.

양자화해야 하나요?

정밀도 (precision)	처리량	정확성 Accuracy
FP 16	기준선	기준선
INT8	명확한 이득	인식된 손실

결론: 정확성에 매우 민감한 시나리오 - 의료, 법률 - FP 16 에 머물다.내부 회의 및 교육 레코드의 경우 허용한도가 높은 경우 INT8 는 더 나은 거래입니다..

INT8 로 맹목적으로 벤치마크 수치를 쫓아다니지 마십시오.회의 시나리오에서 정확도 손실은 "모든 이름, 모든 용어 잘못" 으로 나타나며 재작업 비용은 저장한 계산을 훨씬 초과합니다.

배포: 컨테이너화는 유일하게 합리적인 선택입니다.

베어 메탈에 환경을 설치하는 것은 신창 환경에서는 사실상 유지 관리할 수 없습니다.우리는 컨테이너로 배달합니다:

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

이러한 --device 플래그 중 하나를 누락하면 ACL 초기화 실패가 발생합니다., 오류는 장치가 생략되었음을 알려주지 않습니다.이것은 신입자들에게 가장 큰 장애물이다.

한 가지 더 교훈: 개인 프로토콜을 만들지 마십시오. 표준 RESTful (파일 음성 전사) + WebSocket (실시간 스트리밍) 를 사용하거나 고객의 OA 및 회의 시스템과 통합하는 것은 매우 고통스럽습니다.

이미 서버를 보유하고 있는 고객은 pure-software speech engine 를 직접 배포할 수 있으며 하드웨어를 구입하지 않고도 국내 가속기에 개인 음성 전사 를 얻을 수 있습니다.

현장에서 얻은 7 가지 교훈

이것은 이 글의 가장 가치 있는 부분이다.모든 항목은 문서에서 복사하지 않고 어려운 방법으로 배웠습니다.

1.동적 쉐이프가 자주 다시 컴파일됩니다. 처음에는 --dynamic_dims 를 설정하지 않았으므로 크기가 다른 오디오 클립마다 그래프 컴파일과 지연 시간이 초까지 증가했습니다.계층이 구성되면 대기 시간이 초 이하로 설정됩니다.

2.긴 오디오로 인해 메모리가 고갈됩니다. 한 번의 패스로 2 시간 동안의 회의 녹음을 모델에 공급하면 즉시 OOM 이 발생합니다. 세그먼트 증분 추론 - cut by VAD 를 사용해야 하며 전체 물건을 로드하는 대신 세그먼트별로 디코더를 공급해야 합니다.나중에 오디오 버퍼에 강제 60 초 캡 를 추가하여 OOM 위험을 완전히 제거했습니다.

3.무음 연산자 실패 특정 LayerNorm 변형은 Ascend 에 해당하는 연산자가 없습니다. ATC 는 변환 시 오류가 보고되지 않았으며 런타임에서 모든 0 을 반환했습니다. 이것은 실패의 가장 위험한 클래스입니다, 왜냐하면 그것은 성공처럼 보이기 때문입니다. 동등성 검사를 실행해야 합니다.: CPU 의 ONNX 런타임과 NPU 의 OM 을 통해 동일한 오디오를 공급한 다음 출력을 비교합니다.이것은 유일한 후퇴입니다 - 그것을 건너뛰지 마십시오.

4.다중 스레드 동시작업 시 컨텍스트 누출 이전 버전에서는 요청당 별도의 ACL 컨텍스트를 생성하여 고동시성 하에서 컨텍스트를 배제했습니다. 컨텍스트 풀링 는 그것을 고쳐 놓았습니다.

5.드라이버 업그레이드는 모델을 다시 변환합니다. 주요 CANN 업그레이드 후 이전 OM 모델이 로드하지 않거나 성능이 저하될 수 있습니다. 모델 변환을 CI 에 넣음 대신 손으로 변환하고 완료를 호출합니다.

6.공기 간격이 많은 환경을 위한 오프라인 패키징 물리적으로 격리된 환경에서 CANN 종속성, 드라이버, 모델 가중치, 중국 글꼴 및 인증서 는 모두 사전에 패키지화되어야 합니다.우리는 한번에 그것을 hit: 사이트에 중국어 글꼴이 없습니다., 모든 음성 전사 결과는 상자로 나왔습니다. 오프라인 번드는 동등한 환경에서 전체 배포 프로세스를 통해 리허설되어야 합니다.

7.잘못된 오류 메시지가 진단에서 벗어납니다. 일부 Ascend 오류는 루트 원인은 아닌 코드만 제공합니다.한번은 3 일 동안 진행되지 않은 로드 장애를 겪었는데, 잘못된 soc_version 로 판명되었습니다. 레슨: 모호한 오류가 발생하면 맨 위에서 버전 매트릭스를 다시 확인합니다. - 로그를 줄로 읽는 것보다 훨씬 빠릅니다.

전체 파이프라인: 연설에서 회의록 까지

마지막 요점: 음성 전사 연설은 첫걸음에 불과합니다.

실제 시나리오에 필요한 것은 "회의가 끝날 때 회의록" 입니다.이를 위해서는 ASR 단계 이후 회의록, 의미 구조화 (주제, 결정, 작업 항목) 및 회의록 생성이 필요합니다.이 세 가지를 동시작업 시간 대폭 감소 에 계층화 - 이것이 바로 우리가 동시작업 번호가 어떤 계층을 포함하는지 물어봐야 한다는 것을 계속 강조하는 이유입니다.

우리의 접근 방식은 단일 서버에서 전체 파이프라인을 실행하며 오디오와 텍스트는 내부 네트워크를 떠나지 않습니다.정부, 금융 및 방위 시나리오를 위해, 그것은 어려운 요구 사항입니다.

국내 가속기를 선택하지 않을 때

우리는 그것을 밀어 넣기보다는 그것을 똑바로 회사 소개 하자.

다음 중 하나에 해당하는 경우, 대신 GPU 를 사용합니다.:

• 의무적인 신창 또는 국내 기술 요구 사항 없음 → GPU 에코시스템 는 훨씬 더 성숙합니다; 자신을 위해 문제를 만들지 마십시오.
• 팀의 누구도 CANN 을 모른다. → 운영 비용은 하드웨어 비용 절감보다 훨씬 높습니다.

국내 가속기의 가치는 규정 준수, 비용 효율성이 아니다.준수가 단단한 구속조건이 아니라면 산술이 작동하지 않습니다.

부록: 전체 호환성 목록

구성요소	지원되는 범위
Ascend	310 P / 910 B
Cambricon	MLU370 / MLU590
하이곤 (Hygon)	DCU
NVIDIA	/ L4 / A10 / A100 및 전체 범위
CPU 만	지원됨 (동시작성 감소 / 기존 하드웨어 재사용)

베어 메탈, 정부 클라우드 및 Xinchuang 환경에서 실행되는 Docker 및 Kubernetes 를 통해 배포, 표준 RESTful / WebSocket 인터페이스를 통해 OA 및 회의 시스템과 통합

더 읽어보기: Private ASR on the Ascend 910B | 자카브츠