語音模型與開發者 API
Gemini 3.5 Transcribe Splits Streaming and File Endpoints, Cuts Non-Streaming WER to 2.6%
Google has introduced two speech-to-text endpoints featuring automatic language detection, custom vocabulary biasing, and smart formatting. The non-streaming model is more accurate, while the real-time version does not support speaker diarization or word-level timestamps.
Google launched the preview of Gemini 3.5 Transcribe on August 26, separating recorded-file processing and real-time speech recognition into two endpoints: `gemini-3.5-transcribe` and `gemini-3.5-transcribe-live`. Both support more than 85 languages, mid-conversation language switching, smart formatting, and recognition biasing for up to 1,000 vocabulary terms. Their model cards indicate that they are based on Gemini 3 Pro, with maximum input and output limits of 96K and 32K tokens, respectively.
The non-streaming endpoint can process audio up to one hour long and provides word-level timestamps and diarization for up to eight speakers. When these features are enabled, the per-request audio limit drops to 30 minutes, and speaker attribution for three or more speakers remains experimental. The Live version instead uses bidirectional WebSocket streaming, limits each session to ten minutes, and provides neither timestamps nor speaker diarization, meaning it cannot directly replace meeting-archiving pipelines.
Artificial Analysis measured average word error rates of 4.0% for the Live version and 2.6% for the non-streaming version. The latter did not top the leaderboard at launch and still trailed some specialized speech-recognition models. In Google's own multilingual FLEURS evaluation, the two models scored 5.50% and 5.04%, respectively, showing that language mix and testing methodology can significantly affect results. Estimated paid API costs are approximately $0.009 and $0.005 per minute, respectively, but billing includes audio, output, and hidden processing tokens, so actual charges will vary with output length.
Engineering teams should be especially careful to distinguish between “verbatim transcripts” and smart transcription. The latter removes filler words, cleans up self-corrections, and restructures formatting, making transcripts easier to read but potentially altering the original wording required for legal, medical, or audit records. Before deployment, teams should retest the models using their own data covering accents, noise, domain-specific terminology, and overlapping speakers rather than relying solely on aggregate WER.