Việc triển khai dịch vụ Tổng hợp giọng nói (TTS) trên các thiết bị di động và biên thường đối mặt với hai thách thức cốt lõi: giới hạn năng lực tính toán của chip ARM dẫn đến tốc độ tổng hợp chậm và yêu cầu nghiêm ngặt về độ trễ đầu cuối trong các tình huống tương tác thời gian thực. Dữ liệu thực nghiệm cho thấy, trên các thiết bị ARM điển hình như Raspberry Pi 4B, độ trễ đầu cuối của dịch vụ TTS chưa được tối ưu hóa có thể vượt quá 500ms, với mức sử dụng CPU lên tới hơn 70%, gây ảnh hưởng nghiêm trọng đến trải nghiệm người dùng.

Thiết kế giải pháp kỹ thuật

Tối ưu hóa trích xuất đặc trưng MFCC bằng tập lệnh NEON trên kiến trúc ARM

Quy trình trích xuất đặc trưng MFCC truyền thống, đặc biệt là các tính toán FFT và bộ lọc Mel, thường là điểm nghẽn hiệu năng. Việc xử lý song song bằng tập lệnh NEON có thể cải thiện đáng kể hiệu quả tính toán:

1. Vector hóa tính toán FFT: Chuyển đổi các phép toán nhân, cộng số phức thành các hàm tích hợp của NEON. Thực nghiệm cho thấy tốc độ tăng tới 3.2 lần đối với FFT 128 điểm.
2. Bộ lọc Mel song song: Sử dụng 4 luồng xử lý song song cho tính toán năng lượng logarit, tránh tổn thất hiệu năng do xử lý tuần tự từng điểm.
3. Tối ưu hóa căn chỉnh bộ nhớ: Sử dụng __attribute__((aligned(16))) để đảm bảo dữ liệu tải bởi NEON đáp ứng yêu cầu căn chỉnh.

// Ví dụ triển khai bộ lọc Mel được tối ưu hóa bằng NEON
void neon_mel_filterbank(const float* fft_mag, float* mel_bands) {
    float32x4_t sum = vdupq_n_f32(0.0f);
    // Giả định NUM_BANDS chia hết cho 4
    for (int i = 0; i < NUM_BANDS; i += 4) {
        // Tải 4 float từ fft_mag với căn chỉnh 16 byte
        float32x4_t band = vld1q_f32_aligned(&fft_mag[i]);
        // Nhân với trọng số bộ lọc đã được tải tương ứng
        sum = vaddq_f32(sum, vmulq_f32(band, vld1q_f32(&filter_weights[i])));
    }
    // Tính logarit cơ số 10 của tổng và lưu kết quả
    vst1q_f32(mel_bands, vlog10q_f32(sum));
}

So sánh hiệu năng các framework suy luận

So sánh hiệu năng của các framework suy luận phổ biến trên kiến trúc Cortex-A72:

1. TensorFlow Lite: Kích hoạt tăng tốc NEON mặc định, nhưng giai đoạn tối ưu hóa đồ thị tốn nhiều thời gian.
2. ONNX Runtime: Hỗ trợ kiểm soát luồng chi tiết hơn, phù hợp cho bộ xử lý ARM đa nhân.
3. Toán tử tùy chỉnh: Viết các nhân NEON thủ công cho cấu trúc mô hình cụ thể có thể mang lại hiệu năng tốt nhất.

Dữ liệu thực nghiệm cho thấy, đối với mô hình TTS có khoảng 5 triệu tham số, ONNX Runtime nhanh hơn khoảng 15% so với TensorFlow Lite, giảm độ trễ đầu cuối từ 180ms xuống còn 153ms.

Cơ chế phát lại âm thanh đệm kép

Để đảm bảo phát lại âm thanh liền mạch, áp dụng cơ chế đệm kép để giải quyết vấn đề âm thanh bị giật cục:

1. Mô hình Sản xuất-Tiêu thụ: Một luồng chịu trách nhiệm nạp dữ liệu âm thanh, luồng còn lại chuyên trách việc phát.
2. Bộ đệm vòng không khóa: Sử dụng thao tác nguyên tử để đảm bảo an toàn luồng, kích thước bộ đệm được đặt bằng dữ liệu âm thanh cho 500ms.
3. Bù trễ động: Tự động điều chỉnh ngưỡng bộ đệm dựa trên tải hệ thống.

Triển khai mã nguồn chính

Lập trình kết hợp Python và C++

Sử dụng thư viện ctypes để gọi các module C++ đã được tối ưu hóa:

import ctypes
import numpy as np

# Tải thư viện NEON đã biên dịch
tts_engine = ctypes.CDLL('./libtts_neon.so')

# Định nghĩa kiểu dữ liệu cho các tham số hàm
tts_engine.neon_synthesize.argtypes = [
    ctypes.c_char_p,  # Văn bản đầu vào
    np.ctypeslib.ndpointer(dtype=np.float32),  # Âm thanh đầu ra
    ctypes.c_int      # Số mẫu tối đa
]

def synthesize(text):
    # Phân bổ trước bộ đệm 2 giây cho âm thanh đầu ra
    audio_out = np.zeros(16000*2, dtype=np.float32)
    # Gọi hàm C++ đã tối ưu hóa NEON
    tts_engine.neon_synthesize(text.encode(), audio_out, len(audio_out))
    return audio_out

Kết quả tối ưu hóa hiệu năng

Sau khi tối ưu hóa ở cấp độ hệ thống, kết quả kiểm tra trên Raspberry Pi 4B như sau:

1. Phân bố độ trễ: Thời gian xử lý 95% yêu cầu được kiểm soát trong vòng 200ms.
2. Sử dụng CPU: Giảm từ 70% xuống còn 42%, cho phép xử lý nhiều yêu cầu đồng thời hơn.
3. Hiệu suất tiêu thụ điện: Dòng điện làm việc trung bình giảm từ 1.2A xuống 0.8A (với nguồn 5V).

Hướng dẫn tránh lỗi

1. Xử lý vấn đề Endianness:
   • Kiến trúc ARM mặc định sử dụng Little-endian, cần chú ý thứ tự byte khi tương tác với phần cứng âm thanh.
   • Sử dụng các hàm thuộc họ htonl/ntohl để chuyển đổi khi cần thiết.
2. Điểm cần lưu ý khi thiết kế bộ đệm vòng:
   • Kích thước bộ đệm nên là lũy thừa của 2 để tối ưu hóa bằng các phép toán bit.
   • Cần chèn các lệnh rào cản bộ nhớ sau khi cập nhật con trỏ ghi.
3. Mẹo đảm bảo tính thời gian thực:
   • Thiết lập CPU affinity cho các luồng để tránh chi phí chuyển đổi lõi.
   • Sử dụng chính sách lập lịch SCHED_FIFO để tăng độ ưu tiên cho các luồng quan trọng.

Thảo luận các vấn đề mở

Trên các nền tảng ARM có tài nguyên hạn chế, nhà phát triển cần cân bằng giữa chất lượng giọng nói và tốc độ suy luận:

• Có thể áp dụng chiến lược lượng tử hóa mạnh mẽ hơn (ví dụ: INT4) không?
• Làm thế nào để thiết kế cơ chế suy giảm động, tự động chuyển sang mô hình nhẹ hơn khi tải cao?
• Kỹ thuật chưng cất mô hình phía biên (model distillation) có thể giảm 30% khối lượng tính toán mà vẫn duy trì chất lượng âm thanh không?

Việc khám phá các câu hỏi này có thể kết hợp với các kỹ thuật tối ưu hóa mô hình trong thí nghiệm "Tự tay xây dựng ứng dụng gọi thoại thời gian thực với mô hình Doubao của Volcano Engine", thí nghiệm này cung cấp một chuỗi tối ưu hóa hoàn chỉnh từ nhận dạng đến tổng hợp giọng nói. Tôi nhận thấy giải pháp điều chỉnh cho ARM của họ rất đáng tham khảo. Bằng cách điều chỉnh cấu trúc mô hình và các tham số suy luận, tôi cuối cùng đã đạt được hiệu quả tương tác giọng nói thời gian thực mượt mà trên bo mạch phát triển của mình.