Gemini 3.5 Transcribe Live so với Gemini 3.5 Transcribe: ứng dụng của bạn nên gọi endpoint nào?

Khi Go​ogle ra mắt dòng sản phẩm Ge​mini 3.5 Transcribe vào ngày 26 tháng 8 năm 2026, hãng đã phát hành hai mô hình có chung tên gọi và sứ mệnh nhưng được xây dựng cho các giai đoạn khác nhau của một cuộc trò chuyện: Ge​mini 3.5 Transcribe Live, điểm cuối phát trực tiếp phục vụ qua Live API, và Ge​mini 3.5 Transcribe, điểm cuối ghi âm sẵn phục vụ qua Interactions API. Sai lầm mà hầu hết các nhóm mắc phải trong tuần đầu tiên là coi đây là một mô hình với hai nút bấm. Thực chất đây là hai SKU — khác API, khác giá, khác giới hạn cứng — và việc so sánh độ chính xác giữa chúng không phải là một cuộc so tài công bằng, bởi vì chúng được đánh giá theo những quy tắc khác nhau. Bài viết này đặt hai bên cạnh nhau để quyết định phụ thuộc vào khối lượng công việc của bạn, chứ không phải vào bảng xếp hạng.

Cả hai trong nháy mắt

• API — Ge​mini 3.5 Transcribe Live chạy trên Live API (WebSocket, truyền phát hai chiều) so với Ge​mini 3.5 Transcribe trên Interactions API (tệp đầu vào, bản phiên âm đầu ra).

• Công việc — hội thoại trực tiếp, phụ đề, trợ lý giọng nói so với cuộc họp, nhật ký cuộc gọi, âm thanh lưu trữ.

• Độ chính xác — 4,0% WER streaming so với 2,6% WER non-streaming, theo Artificial Analysis, được Google trích dẫn; các chế độ đo lường khác nhau, không thể so sánh trực tiếp.

• Độ trễ — bản phiên âm cuối cùng sau 0,40 giây khi lời nói kết thúc so với xử lý hàng loạt một tệp hoàn chỉnh.

• Phiên — giới hạn 10 phút cho mỗi phiên trực tiếp so với tệp lên đến 60 phút (30 phút nếu bật tính năng diarization và dấu thời gian).

• Người nói — không có ở phía phát trực tiếp, trong khi phía ghi âm sẵn có tối đa ba người nói với dấu thời gian theo từng từ.

• Giá — khoảng $0.009 mỗi phút pha trộn so với khoảng $0.005 mỗi phút pha trộn.

Quyết định kiến trúc: Interactions API hoặc Live API

Cả hai mô hình đều nằm trong gia đình Go​ogle Ge​mini Audio và đều đang trong bản xem trước công khai. Sự khác biệt bắt đầu từ phương thức truyền tải. gemini-3-5-transcribe-live mở một WebSocket và giữ nó mở: âm thanh thô truyền vào liên tục — khung phổ biến là các khối PCM 16-bit ở 16 kHz hoặc 24 kHz — và mô hình trả về bản ghi từng phần trong khi bạn nói, sau đó là bản ghi cuối cùng cho mỗi lượt phát biểu khi lời nói kết thúc. gemini-3-5-transcribe nhận một tệp hoàn chỉnh, xử lý nó và trả về bản ghi hoàn chỉnh với thông tin người nói và dấu thời gian ở cấp độ từ.

Quyết định về đường truyền chi phối mọi thứ khác. Nếu sản phẩm của bạn hiển thị lời nói ngay khi chúng được phát ra — một bản phụ đề trực tiếp, một trợ lý giọng nói đọc ý định giữa câu, một trợ lý cuộc gọi hành động trong khi cuộc gọi đang diễn ra — bạn đang ở nhánh Live. Nếu sản phẩm của bạn tạo ra một bản ghi — biên bản cuộc họp, nhật ký cuộc gọi, kho lưu trữ — bạn đang ở nhánh Interactions. Sự nhầm lẫn nằm ở chỗ cả hai đều tạo ra văn bản; điểm khác biệt là văn bản đó là trạng thái thời gian thực hay một tạo phẩm cuối cùng.

Độ chính xác: thuế phát trực tuyến là có thật.

Artificial Analysis, tổ chức đánh giá điểm chuẩn độc lập có số liệu được Go​ogle trích dẫn trong bài đăng ra mắt, đo tỷ lệ lỗi từ trung bình 4,0% cho endpoint phát trực tuyến và 2,6% cho endpoint không phát trực tuyến. Trên điểm chuẩn đa ngôn ngữ FLEURS, Go​ogle báo cáo 5,50% cho endpoint phát trực tuyến so với 5,04% cho endpoint không phát trực tuyến. Con số 2,6% đưa Ge​mini 3.5 Transcribe lên vị trí #5 trên bảng xếp hạng WER của AA khi ra mắt, sau ElevenLabs Scribe v2 với 2,2% và MAI-Transcribe-1.5 của Microsoft với 2,4% — đó là số liệu đo của AA, không phải tuyên bố của Go​ogle.

Số lượng phát trực tiếp không phải là phiên bản kém hơn của cùng một bài kiểm tra. Đó là một chế độ khác: mô hình cam kết với các từ trước khi nghe thấy phần cuối của câu, và nó phải trả giá cho điều đó. Đừng chọn giữa hai cái chỉ dựa trên độ chính xác, vì trên bất kỳ khối lượng công việc nào, khoảng cách có thể đảo ngược. Hãy chọn dựa trên các ràng buộc: điểm cuối phát trực tiếp có giới hạn phiên 10 phút, không có tính năng tách giọng nói, và không có dấu thời gian; điểm cuối ghi sẵn xử lý các tệp dài một giờ, gán cho tối đa ba người nói, và trả về dấu thời gian cấp độ từ. Nếu ứng dụng của bạn cần nhãn người nói, mô hình phát trực tiếp đơn giản là không thể làm được việc đó, bất kể WER của nó là bao nhiêu.

Điều họ chia sẻ

Hai điểm cuối dùng chung công cụ {{1}}'intelligent transcription'{{/1}}, và ở các tính năng dùng chung, lựa chọn giữa chúng là trung lập:

• Hơn 85 ngôn ngữ với khả năng tự động phát hiện, bao gồm chuyển đổi ngôn ngữ giữa luồng trên đường Live.

• Dọn dẹp sự không trôi chảy — bỏ các từ đệm, xử lý các lần tự sửa ("Thứ Ba — không, Thứ Tư" được ghi nhận là ngày đã sửa).

• Tự động định dạng — dấu câu, cách viết hoa và cấu trúc đoạn văn được áp dụng cho kết quả đầu ra.

• Từ vựng tùy chỉnh — tối đa 1.000 thuật ngữ cho biệt ngữ và tên sản phẩm, với tài liệu của Google khuyến nghị khoảng 100 để có kết quả tốt nhất.

Một lưu ý áp dụng cho cả hai: tính năng dọn dẹp "thông minh" giúp đầu ra dễ đọc là một quyết định thiết kế đánh đổi độ trung thực nguyên văn. Cách diễn đạt vụng về sẽ được làm mượt; văn bản là sự diễn giải ý định của mô hình, không phải biên bản tòa án. Để có bản ghi nguyên văn chính xác, bạn sẽ muốn dùng tùy chọn verbatim (nguyên văn) khi có, và dù thế nào bạn cũng nên tự kiểm tra hành vi trên audio của chính mình.

Chi phí mỗi phút: phụ phí trực tiếp

Google định giá âm thanh theo token ở mức 25 token âm thanh mỗi giây, với đầu ra khoảng 175 token văn bản mỗi phút âm thanh. Theo giá niêm yết, chi phí kết hợp mỗi phút âm thanh là khoảng 0,005 đô la cho gemini-3-5-transcribe và khoảng 0,009 đô la cho gemini-3-5-transcribe-live — đầu vào 2 đô la so với 3,50 đô la mỗi triệu token, đầu ra 12 đô la so với 21 đô la mỗi triệu token. Cả hai hiện đều có gói miễn phí.

Gói cao cấp mua đường thời gian thực, không phải độ chính xác cao hơn: bạn trả thêm khoảng 80% mỗi phút cho endpoint phát trực tuyến, và nó phiên âm với WER cao hơn. Đó là khung trung thực. Mô hình ghi âm trước vừa rẻ hơn vừa chính xác hơn; mô hình phát trực tuyến tồn tại vì một số sản phẩm không thể chờ tệp xử lý xong.

Bạn nên xây dựng dựa trên endpoint nào?

• Chú thích trực tiếp và phụ đề — Ge​mini 3.5 Transcribe Live, và nếu bạn cần đầu ra đồng bộ theo thời gian, hãy kiểm tra giới hạn không dấu thời gian.

• Voice agent — Gemini 3.5 Transcribe Live để nhận diện ý định giữa câu; lên kế hoạch theo giới hạn 10 phút cho các phiên dài.

• Họp, phỏng vấn, lưu trữ — Ge​mini 3.5 Transcribe, với WER 2,6%, gán nhãn người nói và mốc thời gian theo từng từ.

• Phân tích sau cuộc gọi — Ge​mini 3.5 Transcribe cho bản ghi hoàn tất; Ge​mini 3.5 Transcribe Live chỉ khi phân tích cần chạy trong cuộc gọi.

• Âm thanh liên tục dài — Gemini 3.5 Transcribe, vì một tệp 60 phút tốt hơn hẳn việc tự tay ghép nối các phiên trực tiếp mười phút.

Lớp phía trên bản ghi

Cả hai mô hình đều không phải thứ mà OrcaRouter lưu trữ — hiện tại chúng tôi không định tuyến dịch vụ chuyển giọng nói thành văn bản, và bạn sẽ gọi trực tiếp API của Go​ogle cho cả hai endpoint. Vai trò của lớp định tuyến trong một pipeline giọng nói là nằm phía trên bản transcript: bộ tóm tắt, bộ trích xuất thực thể, mô hình xác định hạng mục hành động — thứ biến một luồng dữ liệu thành quyết định. Đó chính là nơi OrcaRouter chứng tỏ giá trị của mình: một API duy nhất truy cập hơn 200 mô hình với giá niêm yết của nhà cung cấp, không cộng thêm bất kỳ khoản nào, tự động chuyển đổi dự phòng giữa các nhà cung cấp, cùng một DSL định tuyến kết hợp nhiều mô hình thành một lần gọi duy nhất. Hãy chọn endpoint chuyển đổi giọng nói tùy theo khối lượng công việc, rồi chạy mô hình đọc transcript chỉ với một khóa API.

Kết luận

Ge​mini 3.5 Transcribe Live và Ge​mini 3.5 Transcribe cùng một dòng sản phẩm nhưng là các sản phẩm khác nhau. Chọn Live khi bản ghi phải có trước khi cuộc trò chuyện kết thúc và bạn có thể chấp nhận phiên 10 phút, không có nhãn người nói và không có dấu thời gian. Chọn Transcribe khi đầu ra là một bản ghi và độ chính xác cùng khả năng gán nguồn quan trọng hơn tốc độ — nó rẻ hơn, chính xác hơn và ít bị ràng buộc hơn nhiều. Sai lầm duy nhất là cho rằng một endpoint đảm nhiệm cả hai.