Tối ưu mô hình chuyển văn bản thành giọng nói đạt phản hồi dưới 50 ms

21 tháng 8, 2026·6 phút đọc

Bài viết phân tích phương pháp tối ưu hệ thống phục vụ mô hình Qwen3-TTS 1.7B để đạt độ trễ phản hồi âm thanh đầu tiên (TTFA) dưới 50 ms với tốc độ 10 request/giây trên một GPU H100, đồng thời so sánh hiệu năng với các nền tảng phổ biến khác. Tác giả trình bày chi tiết kiến trúc ba giai đoạn của mô hình, các kỹ thuật lập lịch thông minh và tinh chỉnh Codec nhằm cân bằng giữa độ trễ, hiệu suất và chi phí.

Tối ưu mô hình chuyển văn bản thành giọng nói đạt phản hồi dưới 50 ms

Đưa mô hình chuyển văn bản thành giọng nói đạt phản hồi dưới 50 ms

assets/tts-latency-terms.svgassets/tts-latency-terms.svg

Trong bối cảnh các ứng dụng thời gian thực ngày càng phổ biến — từ trợ lý ảo, tổng đài thông minh cho đến công cụ hỗ trợ người khuyết tật — việc tối ưu độ trễ của mô hình text-to-speech (TTS) đang trở thành một bài toán quan trọng. Nhóm nghiên cứu tại Nari Labs vừa công bố một giải pháp đáng chú ý: triển khai mô hình Qwen3-TTS 1.7B CustomVoice trên một GPU NVIDIA H100 duy nhất, đạt tốc độ 10 request/giây và thời gian đến âm thanh đầu tiên (TTFA) chỉ dưới 50 ms ở phân vị 95.

Yếu tố cốt lõi không chỉ nằm ở sức mạnh phần cứng mà ở thiết kế hệ thống thông minh, chia nhỏ quy trình suy luận thành ba nhiệm vụ có thể lập lịch độc lập. Nhờ đó, hệ thống có thể ưu tiên các luồng xử lý khẩn cấp ngay khi nhận yêu cầu, đồng thời vẫn duy trì hiệu suất batching tốt khi tải tăng cao.

So sánh hiệu năng giữa các nền tảng phục vụ TTS

Để khẳng định tính vượt trội, nhóm tác giả đã tiến hành kiểm thử so sánh trên năm hệ thống khác nhau, bao gồm: vLLM-Omni, SGLang-Omni, VoxServe, M* và giải pháp của họ. Toàn bộ bài kiểm tra chạy trong 5 phút với lưu lượng mô phỏng theo phân phối Poisson (mô phỏng truy cập thực tế), sử dụng một HTTP request chứa toàn bộ văn bản và phát trả về âm thanh dạng stream.

Khi chạy với cấu hình mặc định, tất cả các nền tảng đều cho kết quả TTFA khá cao, thậm chí vLLM-Omni ghi nhận 100% request bị underrun (gián đoạn phát lại). Sau khi áp dụng loạt tinh chỉnh gồm loại bỏ khoảng lặng ở đầu và điều chỉnh khung tích lũy codec, kết quả đã được cải thiện rõ rệt.

Enginep95 TTFA (1 RPS)p95 TTFA (6 RPS)
vLLM-Omni56.8 ms93.5 ms
SGLang-Omni120.9 ms273.7 ms
VoxServe49.3 ms363.2 ms
M*104.0 ms179.5 ms

Chỉ có giải pháp của Nari Labs mới duy trì được mức dưới 50 ms ở phân vị 95 khi tải tăng lên 10 request/giây, tương đương khoảng 630 ký tự mỗi giây. Với chi phí thuê GPU khoảng 4,29 USD/giờ, hệ thống tiết kiệm đáng kể so với ElevenLabs V3 (100 USD/1 triệu ký tự) hay Cartesia Sonic 3.5 (49 USD/1 triệu ký tự).

Kiến trúc ba giai đoạn với bộ lập lịch tập trung

assets/image.pngassets/image.png

Qwen3-TTS được thiết kế theo mô hình phân cấp đa codebook, gồm ba thành phần chính:

  • Talker: dự đoán token codebook đầu tiên cho mỗi khung âm thanh.
  • Code Predictor: sinh 15 token còn lại để hoàn thiện khung.
  • Codec (bộ giải mã): chuyển đổi token thành dạng sóng âm thanh.

Hầu hết các hệ thống triển khai hiện nay gộp Talker và Code Predictor thành một khối duy nhất, chạy tách biệt với Codec. Tuy nhiên, Nari Labs chọn cách tách rời cả ba thành phần thành các tác vụ có thể lập lịch độc lập trên cùng một bề mặt điều phối. Cách tiếp cận này giúp giảm thời gian chiếm dụng GPU khi có luồng khẩn cấp cần ưu tiên.

Việc kết hợp Talker và Code Predictor có thể giảm chi phí ranh giới trung gian, nhưng tạo ra một khối công việc không thể ngắt giữa chừng, cản trở các tác vụ Codec khẩn cấp hơn.

Chiến lược lập lịch thông minh và tối ưu Codec

Một điểm đáng chú ý trong thiết kế hệ thống là chính sách ưu tiên hai giai đoạn: trước khi phát âm thanh đầu tiên, mọi mili-giây đều quan trọng nên khối này được ưu tiên cao nhất. Sau khi phát, các luồng chỉ thực sự khẩn cấp khi gần đến thời điểm phát lại, cho phép scheduler dồn tài nguyên cho các luồng chưa có âm thanh hoặc sắp hết bộ đệm.

Ngoài ra, nhóm phát triển còn tận dụng cấu trúc cố định của Code Predictor (luôn chạy 15 bước mỗi khung) để dự trữ KV cache và chuyển toàn bộ vòng lặp sinh thành một CUDA graph duy nhất. Điều này giúp giảm chi phí điều phối giữa CPU và GPU.

Với Codec vốn xử lý theo từng khối liên tục, việc giải mã lại toàn bộ lịch sử khung âm thanh sẽ rất tốn kém. Thay vào đó, hệ thống sử dụng state-cache để lưu trữ ngữ cảnh Transformer và trạng thái tích chập (CNN) hiện tại. Mỗi lần cập nhật chỉ xử lý các khung mới, thay vì phải chạy lại toàn bộ quá trình từ đầu. Kết hợp với việc điều chỉnh kích thước khung linh hoạt — nhỏ khi bắt đầu để giảm TTFA, lớn dần trong quá trình phát để tăng hiệu suất GPU — hệ thống đạt được sự cân bằng tối ưu.

Hướng phát triển tương lai và tác động thực tiễn

Với chi phí vận hành ước tính khoảng 2 USD cho 1 triệu ký tự ở mức sử dụng tối đa, giải pháp này mở ra cơ hội lớn cho các doanh nghiệp Việt Nam muốn triển khai trợ lý thoại thời gian thực, tổng đài chăm sóc khách hàng tự động hoặc ứng dụng giáo dục tương tác. Đây là mức giá cạnh tranh đáng kể so với các dịch vụ API quốc tế, đồng thời cho phép doanh nghiệp tự chủ về hạ tầng và dữ liệu.

Nhóm nghiên cứu cho biết sẽ tiếp tục mở rộng phương pháp tối ưu này sang các mô hình đa phương thức khác như hình ảnh, video và thế giới ảo. Họ cũng công bố mã nguồn mở và bộ công cụ benchmark để cộng đồng có thể tái hiện và phát triển dựa trên kết quả này.

Mô hình TTS mã nguồn mở của nhóm — Dia — đã đạt hơn 2 triệu lượt tải và từng đứng đầu bảng xếp hạng trên Hugging Face, cho thấy uy tín của đội ngũ trong lĩnh vực nghiên cứu trí tuệ nhân tạo đa phương thức.

Câu chuyện này cho thấy rằng việc tối ưu hiệu năng không chỉ đơn thuần nâng cấp phần cứng, mà còn là nghệ thuật thiết kế hệ thống phần mềm khéo léo. Trong bối cảnh AI tạo sinh ngày càng hiện diện trong cuộc sống hàng ngày, những cải tiến như thế này sẽ giúp công nghệ trở nên gần gũi và hữu ích hơn cho người dùng cuối.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗