LiquidCodec biến lời nói thành token: 80 mili giây nói lên điều gì?

Trong bài kỹ thuật ngày 12/11/2026, Liquid AI mô tả LiquidCodec, bộ mã hóa âm thanh khoảng 74 triệu tham số được thiết kế cho xử lý giọng nói dạng luồng. Công cụ chuyển âm thanh thành các token mà mô hình có thể dự đoán, rồi dựng âm thanh trở lại. Một khung mới xuất hiện sau mỗi 80 mili giây, nhưng con số đó không trả lời trực tiếp người dùng sẽ phải chờ bao lâu trước khi nghe trợ lý nói.

Vì sao mô hình cần token thay vì đọc từng mẫu âm thanh?

Với tín hiệu lấy mẫu ở 24 kHz, có 24.000 mẫu mỗi giây trên một kênh. Nếu xử lý từng mẫu như một đơn vị cần dự đoán, mô hình sẽ đối mặt một chuỗi dài và nhiều chi tiết lặp. Một bộ mã hóa có thể gom thông tin thành các đặc trưng, rồi chuyển chúng thành những mã rời rạc. Mô hình học cách đọc hoặc dự đoán chuỗi mã. Phần giải mã dùng chuỗi đó để dựng dạng sóng có thể phát qua loa.

Liquid AI giữ nhịp 12,5 khung mỗi giây từ thiết kế âm thanh trước và chọn tái tạo dạng sóng 24 kHz. Hai con số mô tả hai tầng khác nhau: số mẫu trong tín hiệu và nhịp làm mới đặc trưng nén. Một khung cũng có thể tạo nhiều mã, nên 12,5 khung mỗi giây không đồng nghĩa với 12,5 token mỗi giây. Khi muốn so yêu cầu băng thông hoặc chi phí dự đoán giữa hai codec, cần xem số nhóm mã trong khung và cách chúng được biểu diễn.

Đổi cách lượng tử hóa thay đổi việc mô hình phải dự đoán

Lượng tử hóa ở đây là đưa giá trị đặc trưng liên tục về một tập giá trị hữu hạn. Bộ mã Mimi từng dùng trong dòng mô hình của hãng áp dụng lượng tử hóa véc-tơ phần dư. Có thể hình dung nó như việc chọn một mẫu đại diện trước, rồi chọn các mẫu tiếp theo để bù phần sai khác chưa được mô tả. Mỗi bước bổ sung nhận đầu vào là phần còn lại từ bước trước. Cấu trúc đó giúp biểu diễn tín hiệu bằng nhiều tầng tinh chỉnh, nhưng cách bố trí các mã có thể ảnh hưởng thứ tự mô hình dự đoán.

LiquidCodec dùng lượng tử hóa vô hướng hữu hạn theo nhóm. Mỗi chiều được làm tròn về một trong số các mức cố định, các chiều được chia thành nhóm và mỗi nhóm tạo một mã. Thiết kế này cho phép tổ chức nhóm sao cho mô hình có thể dự đoán linh hoạt hơn, thay vì bắt buộc lặp lại cách biểu diễn phần dư của thiết kế cũ. Chất lượng cuối cùng vẫn phụ thuộc đặc trưng nào được giữ, mô hình dự đoán sai ở đâu và bộ giải mã làm gì với mã nhận được.

Khung 80 mili giây không phải đồng hồ đo cả cuộc hội thoại

Hãng mô tả bộ mã hóa là nhân quả: phần xử lý không cần nhìn vào mẫu tương lai để tạo đặc trưng hiện tại theo thiết kế. Đó là tính chất thuận lợi cho xử lý luồng vì hệ thống không cần đợi ghi xong toàn bộ câu. Tuy nhiên, ứng dụng còn phải nhận âm thanh từ micro, xác định khi nào người nói dừng, đưa thông tin vào mô hình và đưa dữ liệu đã giải mã vào bộ đệm phát. Nếu mô hình chạy từ xa, thời gian truyền mạng và xếp hàng cũng ảnh hưởng phản hồi.

Vì vậy, một phép thử nên tách thời gian từ lúc người dùng ngừng nói đến âm thanh phản hồi đầu tiên khỏi khả năng duy trì âm thanh liền mạch sau đó. Hệ thống có thể cho câu đầu nhanh nhưng thường xuyên ngắt vì mỗi khung tiếp theo đến chậm hơn tốc độ phát. Ngược lại, bộ đệm lớn có thể làm câu trả lời trơn tru nhưng bắt đầu muộn. Người dùng sẽ cảm nhận hai vấn đề này khác nhau, nhất là khi họ muốn ngắt lời trợ lý để sửa thông tin.

Thử với giọng Việt và thiết bị sẽ dùng thật

Liquid AI báo cáo tốc độ và chất lượng tái tạo cạnh tranh trong thử nghiệm của hãng. Để đánh giá ứng dụng tiếng Việt, nên chọn giọng đọc nhiều vùng, từ ít gặp, tên riêng và tình huống có tiếng quạt hoặc xe cộ. Một bản tái tạo có thể nghe rõ tổng thể nhưng làm đổi dấu thanh ở một từ quan trọng. Ngoài đánh giá âm thanh, nên thử cả nhiệm vụ cuối: cuộc gọi có hiểu đúng địa chỉ hoặc tổng đài có xác nhận đúng mã đơn hay không.

Thử nghiệm nên chạy trên nhóm điện thoại hoặc thiết bị nhúng ở dải cấu hình thật và kéo dài đủ để quan sát nóng máy, giới hạn pin và dao động hiệu năng. Nếu kết quả phụ thuộc vào định dạng số rút gọn, cần so bản giảm độ chính xác với bản tham chiếu bằng chính dữ liệu thử. Tốc độ giải mã tốt là một lợi thế, nhưng phần cần đo trước khi tích hợp là thời gian và độ rõ của câu trả lời trong toàn bộ hệ thống, nhất là khi người dùng nói ngắt quãng.

Một kịch bản bổ sung là bắt đầu phát, để người dùng cắt ngang rồi kiểm tra âm thanh cũ có bị hủy ngay không. Trường hợp đó đánh giá luồng hai chiều, nơi các khung đang chờ có thể tiếp tục phát sau khi mô hình đã nhận yêu cầu dừng. Cũng nên ghi riêng thời gian phát hiện người nói và thời gian xóa âm thanh đã lên lịch ở thiết bị. Khả năng phản hồi tự nhiên phụ thuộc cả vào cách ứng dụng quản lý những khung còn trong hàng chờ.

Nguồn: Bài kỹ thuật của Liquid AI ngày 12/11/2026, kèm liên kết đến mô hình và phương pháp thử.

Ảnh minh họa: Micro trong phòng thu, minh họa khâu lấy tín hiệu âm thanh trước khi mã hóa. Shixart1985 qua Wikimedia Commons, CC BY 2.0.