Skip to content

Can whisper_full reuse the encoder output from language auto-detection for the first chunk? #3954

Open

Description

@sumerc

whisper_full_with_state() first calls whisper_lang_auto_detect_with_state() when the language is auto. That call encodes the first audio window. The main transcription loop then calls whisper_encode_internal() again at seek == 0.

For short dictation clips, this second encoder pass appears to account for almost all of the auto-detection overhead.

I tested a small prototype that reuses the encoder state from language detection for the first chunk, restricted to offset_ms == 0 and the default audio_ctx.

Test configuration: Apple M5 Pro, Metal, Flash Attention, large-v3-turbo-q5_0, five iterations per case.

Audio Auto before Auto with reuse Reduction
1.86 s 511 ms 265 ms 48.2%
5.16 s 511 ms 265 ms 48.1%
182.7 s 2658 ms 2443 ms 8.1%

After reuse, auto detection was effectively as fast as an explicit language on the short clips (265 ms versus 263 ms). The transcript text was byte-identical before and after for all three clips, and the existing transcription tests passed with both an explicit language and auto detection.

This is only a narrow experiment. I have not established that reuse is safe with nonzero offsets, custom audio_ctx, VAD, parallel processing, Core ML, or every callback/backend combination. In particular, reuse would need to preserve the encoder_begin_callback and abort semantics discussed in #3888 and #3936.

Is the second encoder pass intentional because language detection leaves some state unsuitable for decoding, or would reusing its encoder output for the first chunk be valid under appropriately restricted conditions?

Activity

  1. sumerc commented on Aug 15, 2026

    @sumerc
    Author

    Quick update: I implemented this downstream in Zee PR #31 (sumerc/zee#31). The exact whisper.cpp change is in this patch

    It has been working well for me (for ~10 days local usage): about 1.9x faster on short auto-detect clips, with unchanged transcripts. I realize auto-detect performance may not be a high priority, but would you be open to upstreaming something like this? Is there any edge case or implementation detail you would want changed first?

    cc @ggerganov, maybe?

  2. github-actions commented on Sep 15, 2026

    @github-actions
    Contributor

    This issue was marked as stale because it has been inactive for 30 days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions