Gemini 3.1 Flash Live ra mắt — và những gì Nextain đã chuẩn bị
Hôm nay, Gemini 3.1 Flash Live đã được ra mắt. Thời điểm trùng hợp một cách kỳ lạ, nên chúng tôi quyết định công bố công nghệ đang được chuẩn bị, dù còn chưa hoàn thiện. naia-os đã hỗ trợ Gemini Live thông qua tài khoản Naia và nhà cung cấp Google, và đã ngay lập tức áp dụng Gemini 3.1 Flash Live. Bạn có thể xem trong video dưới đây.
Những mô hình này thực chất được gọi là S2S, hay mô hình Omni, hỗ trợ hội thoại nhanh chóng và tự nhiên hơn so với pipeline STT, LLM, TTS truyền thống.
Mô hình hội thoại giọng nói thời gian thực (S2S, omni model) tương tự quá trình học nói của con người
Chế độ giọng nói của GPT-4o, Gemini Live, MiniCPM-o là những ví dụ điển hình, đây là các mô hình hội thoại bằng giọng nói, thời gian thực, thậm chí truyền tải cả cảm xúc, chứ không phải bằng văn bản. Trong tiếng Anh, chúng thường được gọi là Speech to Speech (S2S) hoặc Omni Model. Tôi nghĩ rằng chúng giống con người hơn nhiều so với các mô hình STT (chuyển giọng nói thành văn bản) hoặc TTS (chuyển văn bản thành giọng nói) đơn hướng truyền thống. Lý do người khiếm thính gặp khó khăn trong việc học nói là vì họ không thể nghe được lời nói của chính mình.
Vì vậy, tôi đã đánh giá đây là tương lai và xu hướng chủ đạo của các mô hình hội thoại giọng nói, nên đã loại bỏ các tùy chọn cài đặt riêng lẻ của STT/TTS và tích hợp chúng thành 'Mô hình hội thoại trực tiếp', đồng thời thêm API Gemini Live và gpt-4o-realtime-preview. Tuy nhiên, vì cả hai API này đều có phí, nên đối với người dùng miễn phí, chúng tôi đã ghi là TTS Only và đưa Edge vào lựa chọn mô hình hội thoại. Phiên bản 0.1.2 đã được phát hành gần đây (hôm qua). Tôi đã tích hợp API Gemini Live với tài khoản Naia và thử nghiệm thực tế, phản hồi hội thoại rất hài lòng về mặt phản hồi cảm xúc và tốc độ phản ứng.
Hiểu lầm về mô hình hội thoại giọng nói thời gian thực mà tôi từng nghĩ chỉ là mô hình STT/TTS
Tuy nhiên, ở đây có một sự hiểu lầm lớn. Tôi đã hiểu Gemini Live API là mô hình tích hợp STT/TTS thế hệ tiếp theo, nhưng sau này mới biết rằng nó có một mô hình LLM cụ thể, tức là Gemini 2.5 Flash, được tích hợp sẵn và không thể thay đổi LLM.
Mô hình hội thoại giọng nói thời gian thực MiniCPM-o-4.5 có thể sử dụng cục bộ
Lý do tôi nhận ra sự hiểu lầm này là vì Naia hướng tới việc hỗ trợ các mô hình cục bộ trong phạm vi người dùng có thể sử dụng, và tôi đã tìm kiếm và áp dụng một mô hình hội thoại giọng nói thời gian thực có thể chạy trên cấp độ RTX-3090. Ban đầu, các ứng cử viên là Moshi, Qwen3-Omni-30b, MiniCPM-o-4.5. Moshi là người tiên phong trong lĩnh vực này trong mã nguồn mở nhưng chủ yếu hỗ trợ tiếng Anh/Pháp và cộng đồng không hoạt động sôi nổi nên tôi không chọn. Qwen3-omni-30b có hiệu suất xuất sắc nhất gần đây nhưng 24GB VRAM của một chiếc RTX 3090 là không đủ và chưa được kiểm chứng nên tôi đã loại bỏ. Cuối cùng, MiniCPM-o đã được quyết định. Mặc dù hiện tại không hỗ trợ tiếng Hàn, nhưng nếu có thể đầu tư một lượng vốn nhất định, chúng tôi có thể tinh chỉnh thêm ngôn ngữ, và vì nó hỗ trợ âm thanh tham chiếu, tôi đã đánh giá rằng có thể triển khai TTS theo ý muốn của người dùng.
Hơn nữa, vì kích thước nhỏ, tôi nghĩ rằng nếu chạy MiniCPM-o cùng với Qwen3-omni-30b-a3b với VRAM còn lại từ 24GB, hiệu suất LLM có thể được cải thiện đáng kể ngay cả trên cấp độ RTX-3090. Qwen3-omni là một mô hình hội thoại giọng nói thời gian thực (mô hình Omni) như đã đề cập, nhưng lý do không được chọn là vì khi lượng tử hóa, đầu ra giọng nói bị hỏng, không thể chạy trên GPU 24GB của người tiêu dùng, mặc dù các mô hình lượng tử hóa được cho là có hiệu suất tốt như một LLM.
Vì vậy, tôi đã cài đặt MiniCPM-o lên GPU cục bộ (RunPod RTX 3090) và tạo một máy chủ cầu nối Websocket để kết nối với ứng dụng Naia. Trong quá trình thực hiện, tôi nhận ra rằng mô hình không 'nhả' ra những gì nó đã nghe. Nhưng điều quan trọng tôi phát hiện ra ở đây là mô hình Qwen3-8B tích hợp đang phản hồi, và mô hình omni được huấn luyện end-to-end nên không thể thay thế. Nói cách khác, gọi MiniCPM-o là Qwen3-8b-omni sẽ phù hợp hơn. Cụ thể, nó sử dụng Whisper-medium để nghe, Qwen3-8b làm 'não', CosyVoice2 để tổng hợp giọng nói và SigLip2 cho thị giác. Các mô hình khác nhau này được ghép nối và trải qua quá trình huấn luyện lại với dữ liệu đa phương thức. Nhìn chung, đây là một dạng tinh chỉnh, nhưng vì quy mô dữ liệu đa phương thức quá lớn, chi phí có thể lên tới hàng chục đến hàng trăm tỷ won. Gần đây, có nhiều tranh cãi ở Hàn Quốc về việc liệu có phải 'from scratch' hay không, nhưng có vẻ như ngọn núi thực sự cần chinh phục không chỉ là 'from scratch'.
(→ Hồ sơ thử nghiệm MiniCPM-o)
Thử thách mã Claude để hỗ trợ MiniCPM-o-4.5, vllm-omni
Tuy nhiên, chỉ riêng Qwen3-8b tích hợp đã được cho là ngang tầm GPT-4o, nên tôi không thể bỏ qua. Hơn nữa, với khả năng tham chiếu giọng nói và tinh chỉnh LLM, tôi đã đánh giá đây là mô hình mà Nextain, đơn vị theo đuổi AI chủ quyền, nhất định phải theo đuổi. Tôi đã fork vllm và cài đặt lên RunPod, nhưng nó yêu cầu tới 48GB VRAM. Tôi đã chạy nó gần hai ngày. Sau đó, tôi mới biết rằng có một dự án riêng biệt tên là vllm-omni, và ai đó đã đang tiến hành công việc với MiniCPM-o-4.5. Vì vậy, chúng tôi đã bình luận rằng sẽ hỗ trợ thử nghiệm l3. (→ vllm-omni #1182) Vẫn chưa có phản hồi, và trong khi chờ đợi, chúng tôi tiếp tục thử nghiệm nội bộ dựa trên vllm-omni.
Lần này, chúng tôi tiếp cận đặc biệt thận trọng. Trước đây, tôi từng bị chỉ trích gay gắt khi gửi một PR được tạo bằng mã Claude cho một dự án mã nguồn mở khác mà không kiểm chứng phân tích AI một cách đầy đủ. Việc phân tích mã không hoàn chỉnh, không tuân thủ quy tắc cộng đồng, và thậm chí tạo ra thứ nằm ngoài phạm vi của dự án đó, nên điều đó là đương nhiên. Vì vậy, lần này, chúng tôi đã thu thập ngữ cảnh từ góc độ upstream của kho lưu trữ và trải qua quá trình lặp lại các đánh giá đối kháng. Sau đó, chúng tôi đã tuyên bố 'clean pass', xác nhận rằng nó hoạt động khi gắn vào naia-os và tạo tài liệu để đóng góp cho upstream rồi tiến hành đánh giá.
Thế nhưng, RunPod đã bị sập và hôm nay khi cố gắng khởi động lại thì lại không được. Những ghi chép không đầy đủ trong quá trình làm việc đã cản trở. Không thể xác nhận runtime, nên việc tái hiện trở nên bất khả thi. Tôi đã phải lục tung tất cả các bản ghi phiên trước đó để tìm kiếm, và đang trong quá trình tái hiện lại và sửa đổi các ghi chép, nhưng cuối cùng lại phát hiện ra một vấn đề nghiêm trọng khác và buộc phải dừng lại. Chúng tôi đã sử dụng một mẫu cụ thể vì nó mới, không theo mẫu của các mô hình khác của vllm-omni, và khi vllm-omni được cập nhật, tất cả đã bị hỏng. Kết quả phân tích cho thấy thất bại trong việc kiểm soát harness và ngữ cảnh, buộc chúng tôi phải viết một báo cáo giữa kỳ khác, và dựa trên đó, chúng tôi lại phải sửa đổi ngữ cảnh, harness và tiến hành phân tích mã lặp lại thay vì sử dụng RunPod đắt tiền. ㅜㅜ
https://github.com/nextain/vllm-omni/blob/main/.agents/docs/minicpm-o-midterm-review.md
Hôm nay, tôi muốn công bố video chạy MiniCpm4.5-o đúng vào dịp ra mắt Gemini 3.1 Flash Live. Nhưng thật khó để mọi thứ diễn ra suôn sẻ ngay lập tức. Hiện tại đã gần 3 rưỡi sáng. Hơn hết, mục đích của công việc này là một thử nghiệm nhằm hiện thực hóa hệ sinh thái mã nguồn mở AI-native, nơi AI có thể đóng góp đúng đắn vào mã nguồn mở mà không tạo ra 'ai slop'. Tuần tới, tôi dự định mượn thêm card đồ họa, nên hy vọng tình hình sẽ dễ dàng hơn.
Khi có thêm tiến triển, tôi sẽ chia sẻ liệu có thể thực hiện tham chiếu âm thanh hay tinh chỉnh LLM hay không.
Tham khảo
- Gemini 3.1 Flash Live — Model Card (Google DeepMind)
- Speech-to-Speech Models in 2026: Three Architectural Bets — So sánh kiến trúc mô hình tích hợp giọng nói
- Introducing gpt-realtime — Simon Willison — Phân tích mô hình gpt-realtime
- GPT-4o vs. GPT-4.1: All the differences — Sự khác biệt về vai trò giữa các mô hình
- Kết quả thử nghiệm MiniCPM-o (GitHub Issue)
- Thiết kế lại giao diện người dùng cài đặt (GitHub Issue)
- Thiết kế pipeline STT/TTS (GitHub Issue)
