Phiên âm cuộc họp trên Ascend 310P: ma trận phiên bản, chuyển đổi mô hình và bảy bài học thực địa

Bài viết này tài liệu triển khai một công cụ nói tiếng Trung phiên âm giọng nói trên Thẻ suy luận Ascend 310P. 310P là một thẻ suy luận cạnh với một vị trí khác so với 910B, và các kịch bản của nó gần hơn với xử lý cục bộ trong phòng.

Cơ sở dữ liệu: các con số được đánh dấu "kỹ thuật chính thức" đến từ các số liệu sản phẩm được công bố; bảng hiệu suất cung cấp cho giá trị tham chiếu cho một môi trường điển hình. Con số thực tế thay đổi tùy theo điều kiện âm thanh, kích thước mô hình và chiến lược đồng thời - luôn luôn hoãn các phép đo của riêng bạn.

Những gì 310P là tốt, và những gì nó không phải là

Không có sự thiếu hụt của các bài viết Về chúng tôi Ascend 310P, nhưng hầu hết dừng lại ở "CANN được cài đặt và bản demo chạy". Cái bẫy thật sự là Làm cho nó chạy một lần và phục vụ đáng tin cậy là hai điều hoàn toàn khác nhau.

Kết luận phía trước:

Kích thước	Hành vi 310P	Lưu ý
Định vị	Thẻ suy luận Edge	Không phải là một thẻ đào tạo; đừng mong đợi để tinh chỉnh nó
Chia với 910B	Edge nút	910B xử lý suy luận trung tâm, 310P xử lý xử lý cục bộ
Đồng thời Pure phiên âm giọng nói trên mỗi thẻ	Hàng chục dòng chảy	ASR cơ sở mô hình đơn (giá trị tham chiếu)
Đồng thời đầy đủ đường ống	Giảm đáng kể	Khi phân tách người nói và cấu trúc được thêm vào
Trung Quốc phiên âm giọng nói chính xác	≥98%	Kịch bản cuộc họp Tiêu chuẩn tiếng Quan Thoại (đặc số kỹ thuật chính thức)
Phạm vi phủ sóng phương ngữ	22 phương ngữ	Tự động phát hiện (đặc số kỹ thuật chính thức)

Một cái bẫy lựa chọn đáng để đánh cờ: nhiều nhà cung cấp báo giá đồng thời mà không nói cơ sở. "XX luồng trên mỗi thẻ" có thể có nghĩa là ASR tinh khiết, hoặc nó có thể có nghĩa là đường ống đầy đủ. Cả hai có thể khác nhau nhiều lần. Luôn luôn hỏi số bao gồm lớp nào. (Tạm dịch: )

Kiến trúc điển hình của chúng tôi là 910B ở trung tâm, 310P ở cạnh: âm thanh được ghi âm cục bộ trong phòng họp, và chỉ có văn bản có cấu trúc trở lại trung tâm.Điều này giữ băng thông dưới sự kiểm soát và đáp ứng yêu cầu "dữ liệu không rời khỏi phòng họp".

Chuẩn bị môi trường: ma trận phiên bản là trở ngại thực sự

Điểm đau trong Ascend Hệ sinh thái không bao giờ được tính toán - đó là phiên bản căn chỉnh. Driver, firmware, CANN, container runtime, inference framework, model format: Nếu bất kỳ một trong sáu là không liên kết, nó tạo ra một thất bại khó hiểu, và thông báo lỗi thường không nói những gì đã sai.

Một sự kết hợp mà chúng tôi đã xác minh và tìm thấy ổn định:

Thành phần	Phiên bản	Lưu ý
Trình điều khiển / firmware	Tắt chặt với CANN	Kiểm tra bảng tương thích chính thức trước khi nâng cấp
CANN (Cần)	Dòng 8.x	Thư viện vận hành và công cụ chuyển đổi ATC sống ở đây
Thời gian chạy container	Ascend Docker Thời gian chạy	Yêu cầu; Docker thông thường không thể gắn kết NPU
khung suy luận	Thời gian chạy ONNX + ACL	Chạy các mô hình OM
Hệ điều hành	mởEuler / Kylin V10 / UnionTech UOS	Thông thường trong môi trường Xinchuang

Bước đầu tiên là luôn xác nhận NPU có thể nhìn thấy:

# 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

Bài học thực địa: trên một số môi trường Kylin V10, npu-smi info đã báo cáo một ngoại lệ daemon dmp sau khi trình điều khiển được cài đặt. Nguyên nhân hóa ra là một xung đột giữa dkms được đóng gói của hệ thống và kịch bản cài đặt trình điều khiển. Việc sửa chữa là gỡ bỏ cài đặt dkms hệ thống và cài đặt lại bằng cách sử dụng phiên bản đi kèm với gói trình điều khiển.

Các vấn đề phân phối cụ thể như Thường không được tìm thấy trong tài liệu chính thức này, và chúng là trình chặn phổ biến nhất trên trang web.

Chuyển đổi mô hình: ONNX sang OM

Các mô hình ASR thường được đào tạo trong PyTorch, xuất sang ONNX, sau đó chuyển đổi sang định dạng Ascend OM với ATC.

Ba điều cần xem xét khi xuất 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. Một phiên bản opset cao hơn không tốt hơn. Các opsets mới có nhiều khả năng tấn công các nhà khai thác không được hỗ trợ; 14 là một lựa chọn tương thích tốt.
2. Dynamic axes phải được khai báo. Nếu không, bạn chỉ có thể chạy âm thanh có độ dài cố định, không thể sử dụng trong thực tế.
3. Cho phép gấp liên tục. do_constant_folding=True làm giảm đáng kể kích thước đồ thị và cải thiện thành công chuyển đổi.

Các thông số ATC, từng cái một

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

Ba thông số có khả năng gây ra rắc rối nhất:

• --soc_version: Nó phải phù hợp với phần cứng thực tế. 310P phải được viết là Ascend310P; Ascend310 hoặc Ascend910B đều sẽ thất bại ở giai đoạn tải, với một lỗi rất mơ hồ.
• --dynamic_dims: các tầng động.Đối với âm thanh, tầng theo thời gian trong giây. Quá nhiều tầng làm cho thời gian biên dịch bùng nổ; quá ít kích hoạt biên dịch lại thường xuyên và độ trễ run rẩy. Bộ trên (1s / 2s / 3s) là điểm cân bằng chúng tôi đo.
• --precision_mode: allow_fp16 có tác động chính xác không đáng kể đối với ASR và tăng thông lượng rõ ràng.

Bạn có nên quantize không?

Độ chính xác	Thông lượng	Độ chính xác
FP16 - FP16	Cơ sở	Cơ sở
INT8	Lợi ích rõ ràng	Mất mát cảm nhận được

Kết luận: cho các kịch bản cực kỳ nhạy cảm với độ chính xác - y tế, pháp lý - Ở lại trên FP16.Đối với các cuộc họp nội bộ và hồ sơ đào tạo, nơi dung nạp cao hơn, INT8 là thương mại tốt hơn.

Đừng theo đuổi những con số chuẩn với INT8 một cách mù quáng. Trong các kịch bản gặp gỡ, sự mất chính xác xuất hiện như "mỗi tên sai, mỗi thuật ngữ sai", và chi phí làm lại vượt quá nhiều so với tính toán bạn đã tiết kiệm.

Deployment: containerization là sự lựa chọn hợp lý duy nhất

Lắp đặt môi trường trên kim loại trần là thực tế không thể duy trì trong môi trường Xinchuang. Chúng tôi cung cấp như một 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

Mất bất kỳ một trong những lá cờ --device đó tạo ra lỗi khởi tạo ACL, và lỗi không cho bạn biết một thiết bị đã bị bỏ qua.Đây là rào cản lớn nhất đối với những người mới đến.

Một bài học khác: Đừng tạo ra một giao thức riêng tư. Sử dụng RESTful tiêu chuẩn (tệp phiên âm giọng nói) cộng với WebSocket (trực-time streaming), hoặc tích hợp với OA của khách hàng và các hệ thống họp trở nên rất đau đớn.

Khách hàng đã có máy chủ có thể triển khai pure-software speech engine trực tiếp, có được phiên âm giọng nói riêng tư trên các bộ tăng tốc trong nước mà không cần mua phần cứng.

Bảy bài học từ lĩnh vực

Đây là phần có giá trị nhất của bài viết. Mỗi mục được học theo cách khó khăn, không sao chép từ tài liệu.

1. Hình dạng động gây ra việc biên dịch lại thường xuyên Chúng tôi đã không đặt --dynamic_dims lúc đầu, vì vậy mỗi clip âm thanh có kích thước khác nhau sẽ kích hoạt một biểu đồ biên dịch và độ trễ tăng lên đến vài giây. Một khi các tầng được cấu hình, độ trễ được giải quyết trong phạm vi dưới giây.

2.Âm thanh dài làm cạn kiệt bộ nhớ Nạp một bản ghi âm cuộc họp kéo dài hai giờ cho mô hình trong một lần vượt qua gây ra một OOM ngay lập tức. Bạn phải sử dụng Segmented Incremental Inference -cut bởi VAD và cung cấp cho đoạn giải mã theo đoạn thay vì tải toàn bộ. Sau đó, chúng tôi thêm một Cưỡng bức 60 giây cap vào bộ đệm âm thanh, loại bỏ hoàn toàn rủi ro OOM.

3. Lỗi vận hành im lặng Một biến thể LayerNorm đặc biệt không có toán tử tương ứng trên Ascend.Đây là lớp thất bại nguy hiểm nhất, bởi vì nó trông giống như thành công. Bạn phải thực hiện kiểm tra tương đương: cung cấp cùng một âm thanh thông qua ONNX Runtime trên CPU và OM trên NPU, sau đó so sánh đầu ra.Đây là cách duy nhất để trở lại - đừng bỏ qua nó.

4. Context leakage dưới đa luồng đồng thời Các phiên bản đầu tiên tạo ra một ngữ cảnh ACL riêng biệt cho mỗi yêu cầu, các ngữ cảnh cạn kiệt dưới mức đồng thời cao. Context pooling (bổ sung ngữ cảnh) đã sửa chữa nó.

5. Nâng cấp driver có nghĩa là chuyển đổi lại mô hình Sau khi nâng cấp CANN lớn, một mô hình OM cũ có thể không tải hoặc thoái hóa hiệu suất. Đặt chuyển đổi mô hình trong CI thay vì chuyển đổi bằng tay và gọi nó đã hoàn tất.

6. Bao bì ngoại tuyến cho môi trường không khí Trong một môi trường bị cô lập về mặt vật lý, Các phụ thuộc CANN, trình điều khiển, trọng lượng mô hình, phông chữ và chứng chỉ Trung Quốc phải được đóng gói trước. Chúng tôi đã từng chạm vào nó: một thiếu phông chữ Trung Quốc trên trang web, và mọi kết quả của phiên âm giọng nói đều xuất hiện dưới dạng hộp. Gói ngoại tuyến phải được luyện tập thông qua dòng triển khai đầy đủ trong một môi trường tương đương. (Tạm dịch: )

7. Thông báo lỗi sai lệch chẩn đoán Một số lỗi Ascend chỉ đưa ra một mã, không phải là nguyên nhân gốc rễ. Chúng tôi đã từng dành ba ngày cho một lỗi tải mà không có tiến bộ, và hóa ra đó là một soc_version sai. Bài học: khi bạn gặp một lỗi mơ hồ, hãy xác minh lại ma trận phiên bản từ trên cùng - nó nhanh hơn nhiều so với đọc các bản ghi từng dòng.

Đường ống đầy đủ: từ bài phát biểu đến biên bản cuộc họp

Một điểm cuối cùng: Lời nói phiên âm giọng nói chỉ là bước đầu tiên.

Những gì một kịch bản thực sự cần là "biên bản cuộc họp khi cuộc họp kết thúc".Điều đó đòi hỏi phân tách người nói, cấu trúc ngữ nghĩa (chủ đề, quyết định, mục hành động) và thế hệ biên bản cuộc họp sau giai đoạn ASR. Lớp ba này trên Giảm đáng kể sự cạnh tranh - đó chính xác là lý do tại sao chúng tôi tiếp tục nhấn mạnh rằng bạn phải hỏi lớp nào là một số đồng thời bao gồm.

Cách tiếp cận của chúng tôi chạy toàn bộ đường ống trên một máy chủ duy nhất, với âm thanh và văn bản không bao giờ rời khỏi mạng nội bộ.Đối với các kịch bản chính phủ, tài chính và quốc phòng, đó là một yêu cầu khó khăn.

Khi nào không nên chọn gia tốc trong nước

Chúng ta hãy thẳng thắn Về chúng tôi điều này thay vì đẩy nó.

Nếu tình huống của bạn đáp ứng một trong những điều sau đây, Thay vào đó sử dụng GPU:

• Không bắt buộc Xinchuang hoặc yêu cầu công nghệ trong nước → GPU Hệ sinh thái trưởng thành hơn nhiều; đừng tạo ra rắc rối cho chính mình
• Không ai trong đội biết được Can → chi phí vận hành sẽ vượt xa số tiền tiết kiệm trên phần cứng

Giá trị của máy gia tốc trong nước là Tuân thủ, không phải hiệu quả chi phí. Nếu tuân thủ không phải là một ràng buộc cứng, thuật toán sẽ không hoạt động.

Phụ lục: danh sách tương thích đầy đủ

Thành phần	Phạm vi hỗ trợ
Ascend	310P / 910B
Cambricon	MLU370 / MLU590
Hygon (Hygon)	DCU
NVIDIA	T4 / L4 / A10 / A100 và phạm vi đầy đủ
Chỉ có CPU	Hỗ trợ (đồng thời thấp / tái sử dụng phần cứng hiện có)

Triển khai thông qua Docker và Kubernetes, chạy trên kim loại trần, đám mây chính phủ và môi trường Xinchuang, tích hợp với OA và các hệ thống họp qua giao diện RESTful / WebSocket tiêu chuẩn.

Đọc thêm: Private ASR on the Ascend 910B | How to choose a private-deployment ASR (Tạm dịch: How to choose a private-deployment ASR)