Đánh giá API suy luận độ trễ thấp cho tác nhân AI giọng nói: Tại sao TTFT chưa đủ?

Time to first token (TTFT) là chỉ số mà các đội ngũ sử dụng để chọn API suy luận (inference API) cho giọng nói. Đây cũng chính là chỉ số gây hiểu lầm cho họ. TTFT đánh dấu thời điểm quá trình tạo văn bản bắt đầu; một mô hình chuyển đổi văn bản thành giọng nói (text-to-speech) không thể phát âm cho đến khi nhận được trọn vẹn một mệnh đề. Khoảng cách giữa hai thời điểm đó chính là sự khác biệt giữa một tác nhân (agent) mang lại cảm giác đàm thoại tự nhiên và một tác nhân thường xuyên bị ngắt quãng. Bài viết này đánh giá mọi lớp trong hệ thống giọng nói, bao gồm LLM, chuyển đổi giọng nói thành văn bản (speech-to-text), chuyển đổi văn bản thành giọng nói (text-to-speech) và chuyển đổi giọng nói thành giọng nói (speech-to-speech).

Tại sao TTFT là điểm khởi đầu đúng đắn nhưng lại là vạch đích sai lầm

Một tác nhân giọng nói thực chất là một ngân sách độ trễ (latency budget) với một mô hình ngôn ngữ bên trong. Mỗi giai đoạn đều tiêu tốn những mili giây mà người dùng có thể cảm nhận được.

Time to first token (TTFT) là khoảng thời gian giữa việc gửi yêu cầu suy luận và nhận lại token đầu tiên. Định nghĩa của IBM coi đây là khoảnh khắc hệ thống chuyển từ trạng thái nhàn rỗi sang trạng thái hoạt động rõ rệt.

Đối với chatbot, TTFT gần như là toàn bộ câu chuyện. Nhưng đối với giọng nói, nó chỉ là một hạng mục trong tổng số.

Lý do nằm ở cơ chế vận hành. Một mô hình text-to-speech không thể tổng hợp nửa từ. Nó cần một mệnh đề hoặc câu hoàn chỉnh trước khi tạo ra âm thanh. LiveKit gọi chỉ số kết quả này là time-to-first-sentence (TTFS) và lập luận trong bài đăng về việc triển khai Gemma 4 rằng TTFS mới là thứ mà người dùng thực sự cảm nhận được.

Điều đó mang lại cho bạn hai nút điều chỉnh thay vì một. TTFT kiểm soát thời điểm bắt đầu tạo văn bản. Số token mỗi giây (tokens per second) kiểm soát tốc độ hoàn thành câu đầu tiên. Một nhà cung cấp thắng ở chỉ số này nhưng thua ở chỉ số kia sẽ không mang lại cảm giác phản hồi nhanh.

Ngân sách độ trễ: Một lượt phản hồi giọng nói thực sự tiêu tốn bao nhiêu?

Tổng quan về tác nhân giọng nói của LiveKit chia một lượt phản hồi thành: STT mất khoảng 100–200ms, LLM mất 300–500ms với cơ chế streaming, TTS mất 100–200ms và mạng mất 50–150ms qua WebRTC. Tổng mục tiêu thực tế từ đầu đến cuối (end-to-end) là từ 700ms đến 1,2 giây.

Kwindla Hultman Kramer, đồng sáng tạo của Pipecat, đã khuyên nên đặt mục tiêu độ trễ giọng nói-đến-giọng nói trung vị là 800ms, với mức 1.500ms là chấp nhận được cho bản thử nghiệm (proof of concept). Phép tính sơ bộ của ông chia con số này thành bốn phần, mỗi phần khoảng 200ms: vận chuyển và xử lý phương tiện, STT cộng với xác định kết thúc cụm từ (phrase endpointing), suy luận LLM và TTS.

Nghiên cứu trước đây của Daily về bot giọng nói nhanh nhất cung cấp tiêu chuẩn con người. Thời gian phản hồi điển hình của con người trong cuộc hội thoại là khoảng 500ms. Những khoảng dừng vượt quá 800ms bắt đầu tạo cảm giác không tự nhiên.

Điểm chuẩn LLM cho tác nhân giọng nói tháng 2 năm 2026 của Daily chuyển đổi điều đó trực tiếp thành yêu cầu đối với LLM. Cuộc hội thoại tự nhiên cần độ trễ giọng nói-đến-giọng nói dưới 1.500ms, tương đương với ngân sách TTFT khoảng 700ms cho một LLM chế độ văn bản nằm trong quy trình chuyển đổi từ phiên âm sang LLM rồi sang giọng nói.

Con số 700ms đó là thước đo để đánh giá mọi nhà cung cấp.

Cách đọc điểm chuẩn TTFT mà không bị hiểu lầm

Trước khi xem các bảng số liệu, đây là năm sự thật về phương pháp luận làm thay đổi ý nghĩa của các con số:

1. Hình thái khối lượng công việc (Workload shape) đóng vai trò chủ đạo: Artificial Analysis đã thay đổi khối lượng công việc mặc định vào tháng 3 năm 2026. Trang web hiện báo cáo các prompt đầu vào 10k token thay vì 1k. Các prompt dài hơn làm tăng cả TTFT và tốc độ đầu ra. LiveKit lập luận rằng điều này gần với thực tế hơn đối với giọng nói, vì các tác nhân trong môi trường sản xuất thường phải xử lý trước các chính sách, tính cách, quy tắc leo thang, dữ liệu được truy xuất và lược đồ công cụ.

2. Vị trí máy chủ được tích hợp sẵn: Artificial Analysis thực hiện kiểm tra từ một máy ảo trong vùng us-central1-a của Google Cloud. Họ tuyên bố rõ ràng rằng TTFT bao gồm cả độ trễ mạng và có thể mang lại lợi thế hoặc bất lợi cho các nhà cung cấp tùy thuộc vào nơi họ phục vụ.

3. Token suy luận được tính: Theo định nghĩa của Artificial Analysis, TTFT cho một mô hình suy luận là token suy luận đầu tiên, không phải token câu trả lời đầu tiên. Đó là các cột riêng biệt.

4. Đo lường từ phía người nhận: Daily lưu ý rằng các nhà cung cấp mô hình đôi khi trích dẫn TTFT nội bộ trong các ngăn xếp suy luận của họ. Daily đo lường từ lúc gửi yêu cầu đến khi nhận được token hữu dụng đầu tiên từ API.

5. Các lần chạy không thể lặp lại: Daily thẳng thắn về điều này: TTFT thay đổi đáng kể giữa các lần chạy điểm chuẩn, và các nhà cung cấp thay đổi ngăn xếp suy luận và đôi khi cả trọng số mà không thay đổi tên mô hình.

Lớp 1: Time to First Token của LLM

Các số liệu dưới đây được lấy từ bảng xếp hạng nhà cung cấp API của Artificial Analysis, truy xuất ngày 30 tháng 8 năm 2026. Cột “first chunk” chính là TTFT. Khối lượng công việc là 10k token đầu vào, một prompt duy nhất, giá trị trung vị trong 72 giờ.

Độ trễ first-chunk thấp nhất được đo lường

Cái bẫy thông lượng (throughput)

Các nhà cung cấp chip tối ưu hóa cho một chỉ số khác với nhu cầu của các tác nhân giọng nói.

Mercury 2 là minh chứng rõ ràng nhất. Đây là một mô hình ngôn ngữ dựa trên khuếch tán (diffusion-based), tạo ra 770 token mỗi giây. Tuy nhiên, phần đầu tiên của nó mất tới 3,07 giây để xuất hiện. Đó là gấp bốn lần toàn bộ ngân sách LLM cho một cuộc hội thoại tự nhiên.

Cerebras và Groq là một trường hợp khác. TTFT của họ ở mức chấp nhận được và thông lượng của họ rất vượt trội. Đối với riêng TTFS, sự kết hợp này rất mạnh mẽ vì câu hoàn chỉnh gần như ngay lập tức sau khi token đầu tiên xuất hiện.

Các điểm cuối (endpoints) thương mại và tiên phong

Hãy lưu ý cùng một mô hình trên các máy chủ khác nhau. GPT-5.6 Luna (không suy luận) đo được 0,59s trên Amazon Bedrock và 0,74s trên API của chính OpenAI. Việc lưu trữ và định tuyến cũng quan trọng không kém gì trọng số mô hình.

Trường hợp ngoại lệ do nhà cung cấp tự đo lường

LiveKit công bố các số liệu TTFT cho sản phẩm suy luận của riêng họ. Gemma 4 31B trên LiveKit Inference đo được 192ms, so với Gemini 2.5 Flash là 911ms, GPT-5.5 là 966ms, GPT-4.1 là 1.006ms và cùng mô hình Gemma 4 31B thông qua OpenRouter là 1.876ms.

LiveKit minh bạch về cơ chế, điều này làm cho tuyên bố của họ đáng tin cậy hơn hầu hết các bên khác. Họ chạy Gemma đằng sau SGLang với giải mã suy đoán (speculative decoding) và cố tình giảm tải cho mỗi GPU để độ trễ hàng đợi luôn ở mức thấp. Họ cho biết một yêu cầu "nóng" (đã được khởi tạo) bắt đầu trả về token trong khoảng 100ms. Sự đánh đổi ở đây là chi phí, ở mức 1,20 USD cho mỗi 1 triệu token đầu ra.

Cùng bài đăng đó báo cáo TTFS trong toàn bộ cuộc hội thoại: 354ms cho Gemma 4 31B trên LiveKit, 1.034ms cho Gemini 2.5 Flash, 1.088ms cho GPT-4.1, 1.267ms cho Gemini 3.0 Flash và 1.404ms cho GPT-5.5.

Các con số về năng lực đi kèm với nó. Trên IFBench, được chấm điểm độc lập bởi Artificial Analysis, Gemma 4 31B đạt 75,6% so với GPT-5.5 là 75,9%, GPT-4.1 là 43% và Gemini 2.5 Flash là 39%. Trên τ²-bench, GPT-5.5 dẫn đầu với 93,9%, còn Gemma 4 31B đạt 76,9%.

Lớp 2: Chuyển đổi giọng nói thành văn bản (STT) và phát hiện lượt nói

Đối với giọng nói, độ trễ STT không phải là tốc độ phiên âm. Đó là khoảng thời gian từ khi người dùng ngừng nói cho đến khi hệ thống nhận biết được người dùng đã ngừng nói.

Artificial Analysis đo lường hai thứ trên bảng xếp hạng STT streaming của mình, cả hai đều bắt đầu từ thời điểm SileroVAD phát hiện kết thúc lời nói: thời gian đến bản phiên âm một phần đầu tiên và thời gian đến bản phiên âm cuối cùng. Chỉ số AA-WER Streaming của họ dựa trên khoảng 8 giờ âm thanh, với trọng số AA-AgentTalk 50%, VoxPopuli 25%, Earnings-22 25%.

Số liệu độ trễ do nhà cung cấp công bố:

Deepgram Flux là mục thú vị nhất về mặt kiến trúc. Nó tích hợp tính năng phát hiện kết thúc lượt nói (end-of-turn detection) vào mô hình nhận dạng thay vì gắn thêm VAD bên ngoài. Deepgram tuyên bố điều này có thể giảm độ trễ phản hồi của tác nhân từ 200–600ms so với quy trình STT-cộng-VAD truyền thống. Nó cung cấp các tham số eot_threshold (0,5–0,9), eager_eot_threshold (0,3–0,9) và sự kiện EagerEndOfTurn cho phép bạn bắt đầu LLM sớm hơn.