- Giới thiệu trường hợp phát triển tác nhân giọng nói tự xây dựng giúp giảm độ trễ của hệ thống AI dựa trên giọng nói xuống mức khoảng 400ms
- Kết nối STT, LLM và TTS thành một pipeline thời gian thực để đạt tốc độ phản hồi nhanh gấp 2 lần so với các nền tảng thương mại hiện có như Vapi
- Dùng Deepgram Flux để xử lý phát hiện phát ngôn và chuyển lượt, đồng thời sử dụng mô hình Groq llama-3.3-70b để rút ngắn đáng kể thời gian tạo token đầu tiên
- Tối ưu triển khai theo vị trí địa lý và mạng giúp giảm độ trễ xuống dưới một nửa khi triển khai tại khu vực EU
- Cốt lõi của tác nhân giọng nói là điều phối thời gian thực và thiết kế pipeline; khi tự triển khai, có thể xác định rõ các điểm nghẽn hiệu năng
Bối cảnh xây dựng tác nhân giọng nói
- Dựa trên kinh nghiệm phát triển nguyên mẫu tác nhân giọng nói cho một tập đoàn hàng tiêu dùng lớn, tác giả thử tự xây dựng để trực tiếp xử lý sự phức tạp của các nền tảng thương mại
- Các nền tảng như ElevenLabs và Vapi tuy tiện lợi, nhưng khó hiểu được cách vận hành bên trong và không thể kiểm soát độ trễ ở mức chi tiết
- Mục tiêu là tự hiện thực hiệu năng ngang tầm Vapi, và đã làm được chỉ với một ngày cùng khoảng 100 USD credit API
Độ phức tạp của tác nhân giọng nói
- Khác với chatbot dựa trên văn bản, giọng nói cần quản lý chuyển lượt theo thời gian thực (turn-taking)
- Ngay khi người dùng bắt đầu nói, hệ thống phải lập tức dừng phát ngôn; khi người dùng dừng lại thì phải nhanh chóng bắt đầu phản hồi
- Chỉ dùng phát hiện hoạt động giọng nói đơn thuần (VAD) thì khó xác định chính xác thời điểm kết thúc phát ngôn, dễ gây ra độ trễ, chồng lấn phát ngôn và khoảng lặng không cần thiết
Triển khai lần 1: kiểm thử dựa trên VAD
- Sử dụng máy chủ FastAPI và Twilio WebSocket để nhận luồng âm thanh μ-law
- Dùng Silero VAD để xác định có giọng nói hay không, và khi phát hiện phát ngôn kết thúc thì phát một tệp WAV đã ghi âm sẵn
- Dù đơn giản, cách này vẫn cho thấy khả năng phản hồi tức thì và luồng hội thoại tự nhiên
- Ở giai đoạn này, tác giả thiết lập được mốc đo giới hạn dưới của độ trễ
Triển khai lần 2: Deepgram Flux và pipeline thời gian thực
- Đưa Deepgram Flux vào để tích hợp phiên âm streaming và phát hiện lượt nói
- Khi Flux phát hiện phát ngôn kết thúc, hệ thống xử lý theo thứ tự sau
- Gửi kết quả phiên âm và lịch sử hội thoại vào LLM
- Ngay khi token đầu tiên được tạo ra thì streaming sang TTS (WebSocket)
- Truyền âm thanh đã tạo tới Twilio theo thời gian thực
- Giữ sẵn kết nối TTS (warm pool) giúp tiết kiệm khoảng 300ms độ trễ
- Khi người dùng bắt đầu nói, hệ thống hủy ngay LLM, TTS và truyền âm thanh để xử lý ngắt lời một cách tự nhiên
Đo độ trễ và triển khai theo khu vực
- Khi chạy cục bộ tại Thổ Nhĩ Kỳ, độ trễ trung bình là 1,6~1,7 giây
- Khi triển khai lên Railway region EU và đồng bộ Twilio, Deepgram, ElevenLabs về region EU
- Độ trễ giảm xuống còn trung bình 690ms (tổng 790ms), nhanh hơn Vapi khoảng 50ms
- Nhờ độ trễ giảm, độ phản hồi của hội thoại được cải thiện đáng kể, và việc xử lý ngắt lời cũng mượt hơn
Lựa chọn mô hình và cải thiện hiệu năng
- Ban đầu dùng gpt-4o-mini, sau đó thay bằng Groq llama-3.3-70b
- Kết quả thử nghiệm cho thấy thời gian tạo token đầu tiên (TTFT) của mô hình Groq nhanh hơn OpenAI tối đa 3 lần
- Đạt độ trễ đầu-cuối trung bình dưới 400ms, với âm thanh đầu tiên đến trong vòng 500ms
- Ở mức này, cảm nhận thực tế là tác nhân phản ứng còn nhanh hơn con người
Những bài học kỹ thuật chính
- Tối ưu độ trễ cốt lõi là quản lý toàn bộ đường đi từ lúc kết thúc phát ngôn đến khi phát ra âm thanh đầu tiên
- Vì TTFT chiếm hơn một nửa tổng độ trễ, nên việc chọn mô hình độ trễ thấp là rất quan trọng
- Cần biến STT→LLM→TTS thành pipeline streaming thay vì xử lý tuần tự
- Khi bị ngắt lời, phải hủy ngay mọi thành phần trong hệ thống để duy trì hội thoại tự nhiên
- Độ gần về mặt địa lý giữa các dịch vụ có ảnh hưởng mang tính quyết định đến độ trễ
So sánh với nền tảng thương mại
- Vapi và ElevenLabs vẫn hữu ích với đa số đội ngũ vì cung cấp API, độ ổn định, khả năng quan sát và các tính năng bổ sung
- Tuy nhiên, tự xây dựng giúp hiểu rõ các điểm nghẽn thực tế và ý nghĩa của từng tham số, đồng thời
có thể thực hiện điều phối tùy biến phù hợp với nhu cầu cụ thể
- Xét cho cùng, hệ thống giọng nói là bài toán điều phối; nếu nhìn rõ cấu trúc, đây là một bài toán kỹ thuật có thể giải quyết được
Mã nguồn
1 bình luận
Ý kiến Hacker News
Bài này thực sự rất thú vị. Trước đây đội Amazon Alexa đã nghiên cứu vấn đề này và cũng có các bằng sáng chế liên quan
Trong hội thoại, độ trễ trung bình giữa người với người là 0ms, tức là người tiếp theo đã bắt đầu nói trước khi đối phương nói xong. Vì não bộ dự đoán lời nói của đối phương và đồng thời chuẩn bị câu trả lời
Ngược lại, mọi người lại kỳ vọng có độ trễ ở trợ lý giọng nói. Có hai lý do — nhận thức rằng máy tính cần phải “suy nghĩ”, và độ trễ của cuộc gọi di động
Hầu như không có phản hồi nào của Alexa dưới 500ms. Trước đây người ta chỉ đơn giản coi 300ms im lặng là “kết thúc lượt nói”, nhưng điều thực sự cốt lõi là semantic end-of-turn
Bây giờ tài nguyên tính toán đã đủ dồi dào, nên tôi tò mò không biết phần này đã tiến bộ đến đâu. Xử lý gần vị trí địa lý hơn (edge computing) từng là một bước ngoặt lớn
Cuối cùng thì giọng nói là bài toán turn-taking. Có một điểm cải thiện dễ thấy mà chưa ai đụng tới — đó là từ đệm và điều chỉnh nhịp độ
Khi LLM phát hiện một khoảng im lặng ngắn, nó có thể chèn các từ đệm phù hợp ngữ cảnh như “ừm”, “đúng rồi” trong lúc phản hồi thực sự đang được tạo ra. Làm vậy cuộc hội thoại sẽ tự nhiên hơn nhiều
Một bài viết rất xuất sắc. OpenAI Responses client gần đây đã đưa vào websocket nên độ trễ giảm xuống.
Một cách khác là chạy trực tiếp LLM siêu nhỏ ngay trên máy cục bộ. Tôi đã tạo một pipeline hoàn toàn local qua dự án ova, và kể cả không streaming vẫn đạt thời gian khứ hồi dưới 1 giây
Cấu trúc streaming pipeline và phần phân tích độ trễ theo từng bước trong bài rất hữu ích. Việc tự triển khai vòng lặp turn-taking đặc biệt ấn tượng
Tuy vậy, so sánh “nhanh gấp 2 lần Vapi” thì hơi thiếu chính xác. Vapi còn thực hiện nhiều việc hơn hẳn như tool calling, webhook, multi-tenant routing
Giá trị thực sự của bài này nằm ở “những hiểu biết rút ra từ vòng lặp orchestration tự xây”. Nếu chỉ tổng kết là “những điều học được khi tự làm” thì đã hoàn hảo
Tôi cũng đang xây một voice agent thương mại với tổ hợp Twilio + Deepgram + ElevenLabs + LLM API
Điểm mấu chốt không phải độ chính xác STT mà là UX turn-taking. Khi đổi từ ngưỡng im lặng cố định sang semantic end-of-turn, cảm nhận thay đổi hoàn toàn
Độ trễ liên vùng cũng quan trọng. Khi kết nối từ Ấn Độ đến máy chủ ở Mỹ, chỉ riêng edge hop của Twilio cũng đã cộng thêm 150~250ms. Tôi đã cải thiện bằng định tuyến theo khu vực
Xử lý barge-in (chen ngang giữa chừng) cũng rất phức tạp. Không chỉ phải dừng LLM và TTS mà còn phải đảo ngược cả workflow tự động hóa đã chạy. Trước đây từng có lỗi là nếu chen ngang trong lúc xác nhận đặt chỗ thì việc đặt chỗ vẫn bị hoàn tất thật
Soniox Real-time (hỗ trợ 60 ngôn ngữ) xử lý endpoint detection ở cấp độ mô hình. Chính xác hơn VAD rất nhiều
Có thể tham khảo tài liệu kỹ thuật, benchmark của Daily, trang demo
Trước đây tôi từng làm ở Soniox. Đây là dịch vụ đầu tiên triển khai real-time endpoint detection
Cá nhân tôi thấy kiến trúc STT → LLM → TTS có giới hạn. Tương lai là mô hình giọng nói end-to-end
Hai năm trước tôi đã làm demo Chirpy, nhưng để đạt mức thực sự dùng được thì cần huấn luyện chuyên biệt. Với một side project thì không kham nổi
Khách hàng doanh nghiệp coi trọng khả năng kiểm toán (auditability) và độ tin cậy. Trong các ngành bị quản lý như y tế hay tài chính, cần phải kiểm chứng riêng đầu ra của STT và LLM
Trong khi đó, mô hình giọng nói end-to-end phù hợp hơn với các mục đích mang tính tường thuật như phỏng vấn hoặc khảo sát. Khách hàng thực tế muốn độ hoàn thiện kỹ thuật hơn là mô hình mới nhất
Cách tiếp cận lần này khiến tôi nhớ đến giai đoạn đầu phát triển netcode của game engine. Độ trễ không phải là vấn đề của mô hình mà là vấn đề orchestration
Bài báo VR năm 2013 của Carmack cũng đưa ra lập luận tương tự — phải lần theo toàn bộ pipeline thì mới tìm ra được nút thắt cổ chai ở cấp mili giây
Latency Mitigation Strategies là tài liệu đáng tham khảo. Ví dụ mở sẵn pool websocket cho TTS để tiết kiệm 300ms là một minh họa hoàn hảo
Tôi muốn giới thiệu ứng dụng nhận dạng giọng nói mã nguồn mở Handy. Nó hoạt động hoàn toàn offline và có thể mở rộng
Tôi dùng nó hằng ngày cùng với Claude, và nó chạy tốt hơn nhiều so với tính năng đọc chính tả mặc định của macOS
Bài viết hay, nhưng giải thích hội thoại chỉ bằng turn-taking thì quá đơn giản
Hội thoại thực tế còn có lời nói chồng lấn, tín hiệu xác nhận, phát ngôn duy trì lắng nghe (phatic messages), thậm chí cả hành vi hợp tác hoàn thiện nốt lời của đối phương
Những yếu tố này khó được biểu đạt tốt chỉ bằng mô hình turn-taking đơn giản, và mô hình cần có khả năng tạo ra cũng như hiểu được chúng