Thử biến Google Colab thành máy chủ API để chạy hội thoại giọng nói S2S

“Tôi muốn thử nghiệm AI hội thoại giọng nói Speech-to-Speech, hay S2S, nhưng thuê riêng một máy chủ GPU chỉ để kiểm chứng thì có vẻ quá mức cần thiết.”

Có lẽ nhiều người cũng từng nghĩ như vậy.

Trong giai đoạn thử nghiệm, chúng ta chỉ muốn sử dụng GPU khi thực sự cần. Khi đó, Google Colab là một lựa chọn dễ nghĩ tới. Tuy nhiên, về bản chất, Colab không phải là một máy chủ có thể được truy cập từ bên ngoài.

Colab là môi trường dùng để chạy các cell trong notebook. Nó không được thiết kế cho mục đích kết nối qua WebSocket và trao đổi âm thanh theo thời gian thực.

Ban đầu, tôi cũng nghĩ rằng:

“Cho dù có làm được thì chắc cũng không ổn định và khó có thể sử dụng thực tế.”

Tuy nhiên, sau khi thử triển khai, hệ thống lại hoạt động ổn định hơn nhiều so với dự đoán.

Trong bài viết này, chúng tôi giới thiệu môi trường thử nghiệm AI hội thoại S2S được xây dựng bằng Google Colab và các tài khoản miễn phí, cùng với những cải tiến về độ trễ nhằm giúp nhịp hội thoại tự nhiên hơn.

Đây là những kinh nghiệm thực tế theo hướng:

“Chúng tôi đã thử xây dựng theo cấu trúc này và kết quả hoạt động khá tốt.”

1. Mở đường truy cập vào Colab bằng ngrok

Những gì chúng tôi thực hiện khá đơn giản.

Chúng tôi khởi động một tiến trình máy chủ trong cell của Colab, sử dụng dịch vụ tunneling ngrok để tạo một URL công khai tạm thời, sau đó kết nối tới URL đó từ máy tính cá nhân.

Chỉ với thao tác này, một URL tạm thời có thể được truy cập từ bên ngoài sẽ được cấp.

Tuy nhiên, khi lặp lại quá trình kiểm chứng nhiều lần, thao tác sau bắt đầu trở nên hơi bất tiện:

1. Kiểm tra URL ngrok mới mỗi lần khởi động.
2. Sao chép URL.
3. Thay đổi tham số trong script client trên máy tính cá nhân.
4. Chạy lại client.

Vì vậy, chúng tôi bổ sung một cơ chế nhỏ nhằm tự động tạo và hiển thị ngay trong log của cell một câu lệnh hoàn chỉnh, có thể sao chép và chạy trực tiếp trên môi trường local.

Sau khi cell được thực thi, log tương tự như sau sẽ xuất hiện:

🚀 S2S v2 Server (WebSocket) Ready!
URL: https://xxxx-xx-xx-xxx-xx.ngrok-free.app
📋 Client Command (Run this locally):
uv run client_s2s.py --url wss://xxxx-xx-xx-xxx-xx.ngrok-free.app

Chỉ cần sao chép nguyên câu lệnh được hiển thị, dán vào terminal trên máy tính cá nhân và chạy uv run, hệ thống sẽ ngay lập tức sẵn sàng để trò chuyện với AI.

Việc này giúp loại bỏ thao tác sửa URL thủ công mỗi lần và cho phép kiểm chứng tương đối thuận lợi chỉ với Google Colab và tài khoản ngrok miễn phí.

Cấu trúc hệ thống như sau:

[Máy tính cá nhân – Client]                [Google Colab – Máy chủ GPU T4]

       Đầu vào microphone                         faster-whisper (STT)
              │                                           │
              ▼                                           │
Phát hiện đoạn phát âm bằng VAD (Silero)                  │
              │                                           │
Gửi âm thanh qua WebSocket ───── ngrok ─────► Gemini 2.5 Flash-Lite
              ▲                                  (LLM, streaming)
              │                                           │
Nhận và phát âm thanh                                     ▼
              │                                  VOICEVOX Engine (TTS)
       Đầu ra loa

Vai trò của phía GPU và phía máy tính cá nhân được tách biệt hoàn toàn.

Các tác vụ nặng như nhận dạng giọng nói, STT, và tổng hợp giọng nói, TTS, được xử lý bằng GPU T4 trên Colab.

Máy tính cá nhân chỉ đảm nhiệm việc thu âm từ microphone và phát âm thanh qua loa.

2. Thiết lập phía máy chủ và lựa chọn model

Môi trường phía Colab được thiết lập bằng cách chạy các cell Python để cài đặt thư viện cần thiết và tải các model AI.

Lần đầu tiên cần vài phút để hoàn tất quá trình thiết lập. Tuy nhiên, sau khi khởi động xong, cùng một session có thể được tái sử dụng cho nhiều lượt hội thoại.

Nếu kết nối bị ngắt hoặc môi trường gặp lỗi, chỉ cần chạy lại cell tương ứng.

VOICEVOX Engine phiên bản GPU dùng cho tổng hợp giọng nói cũng được khởi động dưới dạng tiến trình chạy nền trên Colab.

Quá trình lựa chọn model nhận dạng giọng nói

Việc chọn model STT đã gây ra nhiều tranh luận và thử nghiệm hơn dự kiến.

Ban đầu, chúng tôi nghĩ rằng một model nhẹ ở cấp độ medium là đủ.

Chúng tôi đã đánh giá rằng:

“Đây chỉ là việc chuyển giọng nói tiếng Nhật thành văn bản, có lẽ không cần độ chính xác quá cao.”

Tuy nhiên, nhận định đó quá lạc quan.

Khi thử với tiếng Nhật thực tế, cả model medium và phiên bản nhẹ distil-whisper-large-v3 đều có nhiều trường hợp nhận dạng không chính xác và chưa đạt mức có thể sử dụng trong mục đích thử nghiệm này.

Cuối cùng, trong môi trường kiểm chứng của chúng tôi, large-v3 là model duy nhất đạt được độ chính xác cần thiết.

Đổi lại, thay vì giảm kích thước model để tăng tốc độ, chúng tôi giữ nguyên model lớn nhất và sử dụng lượng tử hóa kiểu int8_float16 để cải thiện tốc độ xử lý.

Chiến lược cuối cùng là:

Không làm model nhỏ hơn để tăng tốc. Sử dụng model lớn có độ chính xác cao nhất và tăng tốc bằng lượng tử hóa.

Để đi đến kết luận này, chúng tôi đã phải thực sự nói chuyện và so sánh nhiều model khác nhau.

Lựa chọn LLM để tạo nội dung hội thoại

Đối với LLM tạo phản hồi, phương hướng lựa chọn rõ ràng hơn.

Nếu chạy một LLM riêng trên GPU, tải xử lý của Colab sẽ tăng mạnh và khiến toàn bộ hệ thống chậm lại.

Vì vậy, chúng tôi lựa chọn Gemini 2.5 Flash-Lite, một model có tốc độ phản hồi nhanh khi sử dụng qua API.

Trong quá trình thử nghiệm, JSON output và Function Calling cũng hoạt động ổn định.

Bằng cách quyết định không sử dụng GPU của Colab cho LLM, chúng tôi có thể giới hạn tải GPU vào hai tác vụ chính:

• Nhận dạng giọng nói
• Tổng hợp giọng nói

3. Rút ngắn khoảng chờ: Buffer theo câu và tổng hợp giọng nói song song

Sau khi cấu trúc cơ bản bắt đầu hoạt động, vấn đề đầu tiên chúng tôi nhận thấy là khoảng chờ trong hội thoại.

Nếu đợi LLM tạo xong toàn bộ nội dung phản hồi rồi mới bắt đầu tổng hợp giọng nói, khoảng thời gian im lặng sẽ kéo dài theo độ dài câu trả lời.

Nếu đây là cuộc trò chuyện giữa hai người, khoảng chờ đó dài đến mức khiến hội thoại trở nên thiếu tự nhiên.

Để giải quyết vấn đề này, chúng tôi buffer phản hồi streaming của Gemini theo ranh giới câu, chẳng hạn như dấu chấm hoặc ký tự xuống dòng.

Ngay khi một câu được xác định hoàn chỉnh, câu đó sẽ được gửi ngay tới VOICEVOX.

Ngoài ra, chúng tôi triển khai một cơ chế “Asynchronous TTS Manager”, cho phép các tác vụ tổng hợp giọng nói bằng VOICEVOX chạy song song trong thread pool nền.

Nhờ đó, quy trình xử lý song song sau được thực hiện:

Trong khi LLM tiếp tục tạo phần sau của câu trả lời, VOICEVOX đã bắt đầu tổng hợp câu đầu tiên được xác định hoàn chỉnh. Ngay khi âm thanh hoàn tất, dữ liệu sẽ được gửi streaming tới client.

Hiệu quả rõ ràng đến mức có thể cảm nhận bằng tai mà không cần xem log.

Nhịp độ hội thoại được cải thiện đáng kể.

4. Cải thiện quá trình tải VOICEVOX để phòng tránh lỗi

Tại thời điểm thử nghiệm, phiên bản GPU của VOICEVOX Engine được phân phối trên GitHub dưới dạng năm tệp được chia nhỏ.

Ban đầu, chúng tôi viết một quy trình đơn giản để tải tuần tự từ tệp số 1 đến tệp số 5.

Tuy nhiên, nếu mạng của Colab không ổn định, quá trình giải nén đôi khi bắt đầu trong khi một trong các tệp vẫn chưa được tải đầy đủ.

Khi đó, hệ thống sẽ dừng lại do lỗi.

Nếu tệp bị thiếu nằm ở giữa chuỗi, việc xác định nguyên nhân còn tốn thêm thời gian.

Vì vậy, chúng tôi bổ sung một cơ chế chắc chắn hơn:

• Tải đồng thời năm tệp
• Tự động thử lại khi phát sinh lỗi
• Kiểm tra xem có thiếu số thứ tự nào hay không
• Chỉ bắt đầu giải nén sau khi xác nhận toàn bộ tệp đã được tải đầy đủ

Trong quá trình kiểm chứng, chúng tôi đã chạy lại các cell của Colab hàng chục lần.

Việc sớm bổ sung khả năng chống chịu đối với các lỗi tải xuống chỉ thỉnh thoảng mới xảy ra đã mang lại hiệu quả rất lớn.

5. Máy tính cá nhân chỉ cần xử lý microphone và loa

Ở phía client, chúng tôi sử dụng chức năng của công cụ quản lý package Python uv, cho phép khởi động hệ thống bằng một câu lệnh mà gần như không cần chuẩn bị trước.

Client chủ yếu thực hiện ba nhiệm vụ.

Phát hiện thời điểm người dùng bắt đầu và kết thúc phát âm

Client sử dụng thư viện Silero VAD để phát hiện chính xác:

• Thời điểm người dùng bắt đầu nói
• Thời điểm người dùng nói xong và bắt đầu im lặng

Gửi dữ liệu âm thanh đến máy chủ Colab

Dữ liệu âm thanh được gửi đến máy chủ Colab thông qua WebSocket.

Nhận và phát âm thanh

Client nhận lần lượt dữ liệu âm thanh dạng binary được gửi từ máy chủ và phát theo đúng thứ tự.

Điều chỉnh tham số VAD trong môi trường thực tế

Các giá trị như ngưỡng VAD hoặc số giây im lặng cần thiết để xác định người dùng đã kết thúc câu nói không thể chỉ được quyết định bằng thiết kế lý thuyết.

Ví dụ:

• Nếu người dùng thường nói nhanh và chèn nhiều câu phản hồi ngắn, thời gian xác định im lặng nên ngắn hơn.
• Nếu người dùng nói chậm trong khi suy nghĩ, thời gian chờ nên dài hơn.

Chúng tôi đã tự nói chuyện với hệ thống hàng chục lần để kiểm tra các tình huống như:

• AI bắt đầu trả lời quá sớm và ngắt lời người dùng
• AI chờ quá lâu trước khi trả lời
• Một khoảng dừng ngắn bị hiểu nhầm là kết thúc phát âm
• Thời điểm bắt đầu phát âm thanh có tự nhiên hay không

Trong kịch bản hội thoại lần này, giá trị thời gian im lặng liên tục là 350 mili giây mang lại cảm giác cân bằng nhất.

Cuối cùng, phương pháp tốt nhất vẫn là tự nói chuyện với hệ thống và điều chỉnh dựa trên trải nghiệm thực tế.

6. Yếu tố nào thực sự quyết định tốc độ cảm nhận?

Sau khi kết hợp tất cả các thành phần và chạy thử, chúng tôi nhận ra rằng tốc độ tạo văn bản của LLM không phải là yếu tố chính quyết định nhịp hội thoại.

Yếu tố thực sự quan trọng là khoảng thời gian:

Từ khi người dùng nói xong đến khi âm thanh đầu tiên được phát trở lại.

Nói cách khác, chỉ số quan trọng nhất là độ trễ phản hồi ban đầu.

Chúng tôi ghi log khoảng thời gian từ khi kết thúc phát âm cho đến khi client nhận được dữ liệu âm thanh đầu tiên, sau đó điều chỉnh:

• Văn bản cần được chia ở vị trí nào
• Khi nào gửi một câu sang TTS
• Bao nhiêu tác vụ tổng hợp giọng nói nên được chạy song song
• VAD nên chờ bao lâu trước khi xác định kết thúc phát âm
• Client nên bắt đầu phát âm thanh vào thời điểm nào

Đây mới chính là phần chiếm phần lớn công việc thực tế của PoC.

Chỉ nhìn vào thông số kỹ thuật của từng model sẽ không thể biết được toàn bộ khoảng thời gian này có thể rút ngắn đến mức nào.

Cần kết nối toàn bộ pipeline, đo đạc từ đầu đến cuối và lặp lại việc trò chuyện thực tế mới có thể đánh giá được trải nghiệm.

7. Tổng kết

Mặc dù Google Colab là một môi trường notebook, việc sử dụng ngrok để cung cấp quyền truy cập tạm thời cho phép chạy một máy chủ API và WebSocket phục vụ kiểm chứng S2S mà không cần thuê trước một máy chủ GPU chuyên dụng.

Đối với nhận dạng giọng nói, trong môi trường thử nghiệm lần này, chúng tôi ưu tiên độ chính xác và chọn large-v3, sau đó sử dụng lượng tử hóa để cải thiện tốc độ.

Việc nhận phản hồi của LLM theo dạng streaming và gửi từng câu đã hoàn chỉnh sang TTS giúp giảm đáng kể khoảng chờ trước khi AI bắt đầu nói.

Do giá trị VAD phù hợp thay đổi tùy theo kịch bản sử dụng, tham số này cần được điều chỉnh bằng cách thực sự nói chuyện nhiều lần với hệ thống.

Chúng tôi không nghĩ rằng một môi trường chỉ sử dụng Google Colab và ngrok miễn phí lại có thể hoạt động tốt đến mức này.

Bước tiếp theo chúng tôi muốn thử nghiệm là xem cấu trúc này có thể hỗ trợ bao nhiêu kết nối đồng thời.

Nội dung đó sẽ được giới thiệu trong một dịp khác.

Công ty chúng tôi hỗ trợ từ việc xây dựng PoC ban đầu đến phát triển phiên bản thương mại hoàn chỉnh.

Ngay cả khi dự án của bạn mới chỉ ở giai đoạn:

“Trước tiên, chúng tôi muốn kiểm chứng xem ý tưởng này có khả thi hay không.”

hãy liên hệ với chúng tôi để được tư vấn.