Tin tức

Qwen3-TTS ở 10 RPS với TTFA dưới 50 ms: Nari Labs đẩy lùi ranh giới tốc độ-chi phí

Nari Labs tuyên bố một ngăn xếp phục vụ Qwen3-TTS 1.7B CustomVoice đạt 10 RPS với p95 time-to-first-audio dưới 50 ms trên một H100 duy nhất, đánh bại vLLM-Omni, SGLang-Omni, VoxServe và M* sau khi tinh chỉnh. Chìa khóa: một bộ lập lịch thống nhất cho Talker, Code Predictor và Codec.

August 21, 2026· 4 min read· Nguồn: Nari Labs
Qwen3-TTS ở 10 RPS với TTFA dưới 50 ms: Nari Labs đẩy lùi ranh giới tốc độ-chi phí

Nari Labs đã công bố điểm chuẩn và triển khai mã nguồn mở để phục vụ Qwen3-TTS 1.7B CustomVoice, tuyên bố chiến thắng đáng kể về tốc độ-chi phí. Ngăn xếp của họ đạt 10 yêu cầu mỗi giây (RPS) với p95 time-to-first-audio (TTFA) dưới 50 ms trên một NVIDIA H100 SXM duy nhất, đồng thời duy trì phát lại thời gian thực với không có underrun. Ở mức sử dụng đầy đủ, điều đó tương đương với khoảng $2 mỗi 1 triệu ký tự, so với $100/1M cho ElevenLabs V3 và $49/1M cho Cartesia Sonic 3.5.

“Thời gian thực” ở đây nghĩa là gì

Các tác giả định nghĩa TTS thời gian thực là một bài toán bốn phần: TTFA nghe được thấp, không có underrun khi phát bắt đầu, dung lượng giữ vững khi RPS tăng và đầu ra không bị lỗi định dạng. Họ đo điểm chuẩn dưới lưu lượng vòng hở Poisson trong năm phút, theo phương pháp điểm chuẩn LLM của Fireworks AI. Mỗi engine nhận toàn bộ văn bản trong một yêu cầu HTTP duy nhất, với âm thanh được truyền trực tiếp về.

Hiệu suất cơ sở: còn chỗ để cải thiện

Ở 1 RPS với cấu hình mặc định, bốn engine được so sánh cho thấy sự khác biệt lớn về p95 TTFA nghe được: vLLM-Omni ở 277,9 ms, SGLang-Omni ở 1.140,7 ms, VoxServe ở 315,1 ms và M* ở 1.160,0 ms. Tất cả đều có khoảng im lặng đầu đáng kể (30–90 ms) và trong trường hợp của vLLM-Omni, 100% yêu cầu có underrun.

Sau khi tinh chỉnh cho độ trễ thấp—loại bỏ khoảng im lặng đầu và điều chỉnh tích lũy khung—bức tranh thay đổi. Ở 1 RPS, VoxServe đạt p95 TTFA 49,3 ms, nhưng đến 6 RPS nó suy giảm xuống 363,2 ms. Các engine khác vẫn trên 100 ms ngay cả ở 1 RPS. Triển khai của Nari Labs là triển khai duy nhất duy trì p95 TTFA dưới 50 ms qua 10 RPS, vẫn dưới 100 ms ngay cả ở 20 RPS.

Tối ưu hóa chính: một bộ lập lịch cho ba mô-đun

Qwen3-TTS là một mô hình ba phần: Talker dự đoán token codebook đầu tiên cho mỗi khung âm thanh, Code Predictor tạo ra 15 token còn lại và một Codec nhân quả chuyển đổi token thành mẫu dạng sóng. Hầu hết các ngăn xếp phục vụ chia mô hình này thành hai giai đoạn—Talker+Code Predictor cùng nhau, Codec riêng biệt—để chồng lấp việc tạo và giải mã giữa các yêu cầu.

Thay vào đó, Nari Labs phơi bày cả ba như các tác vụ có thể lập lịch độc lập trên một bề mặt lập lịch duy nhất, lấy cảm hứng từ M*. Điều này cho phép bộ lập lịch ưu tiên dựa trên mức độ khẩn cấp: trước khi có âm thanh đầu tiên, mỗi mili giây đều quan trọng; sau khi phát bắt đầu, khối tiếp theo chỉ cần đến trước khi âm thanh hiện tại kết thúc. Bộ lập lịch có thể gộp các yêu cầu chờ cùng một mô-đun và sắp xếp lại công việc để đáp ứng thời hạn phát lại.

Các tác giả lập luận rằng việc kết hợp Talker và Code Predictor, mặc dù có vẻ hiệu quả hơn, tạo ra một đơn vị không thể chiếm quyền ưu tiên, chặn các công việc khẩn cấp hơn. Giữ chúng riêng biệt tạo ra các đơn vị ngắn hơn và nhiều cơ hội xen kẽ hơn.

Chi phí và mã nguồn mở

Với $4,29/giờ cho một phiên bản 1× H100 SXM (giá Lambda), thông lượng tuyên bố ~630 ký tự mỗi giây ở 10 RPS tương đương khoảng $2 mỗi 1 triệu ký tự. Triển khai và bộ công cụ điểm chuẩn được mã nguồn mở trên GitHub.

Chìa khóa không chỉ là chia chúng thành các phần, mà là đưa cả ba lên một bề mặt lập lịch dùng chung được quản lý bởi một bộ lập lịch duy nhất.
Ban biên tập Manul X
p95 TTFA đã tinh chỉnh (ms) ở 1 và 6 RPS giữa các engine
So sánh nhanh
Enginep95 TTFA @ 1 RPSp95 TTFA @ 6 RPS
Nari Labs (của chúng tôi)<50<50
vLLM-Omni56.893.5
SGLang-Omni120.9273.7
VoxServe49.3363.2
M*104.0179.5