[Whisper Worker] fp16 encoder failed, falling back to fp32:

Error message

[Whisper Worker] fp16 encoder failed, falling back to fp32:

What it means

The Whisper web worker (transformers.js WhisperForConditionalGeneration) first tries to load the model with dtype fp16 encoder + q4 decoder; if that load fails it warns and retries with an fp32 encoder. fp16 failures are typical on devices/WebGPU adapters without shader-f16 support or on WASM fallback paths where fp16 weights cannot be decoded — the fp32 retry trades download size/speed for compatibility.

Source

Thrown at packages/stage-ui/src/libs/workers/worker.ts:135

      progress_callback,
    })

    // NOTICE: fp16 encoder may fail on some devices/browsers. Fall back to fp32
    // if the initial load fails. Decoder fp16 is known broken (see Issue #989).
    // https://github.com/huggingface/transformers.js/issues/989
    this.model ??= (async () => {
      try {
        return await WhisperForConditionalGeneration.from_pretrained(this.model_id!, {
          dtype: {
            encoder_model: 'fp16',
            decoder_model_merged: 'q4',
          },
          device: actualDevice,
          progress_callback,
        })
      }
      catch (error) {
        console.warn(
          '[Whisper Worker] fp16 encoder failed, falling back to fp32:',
          errorMessageFromValue(error),
        )
        return await WhisperForConditionalGeneration.from_pretrained(this.model_id!, {
          dtype: {
            encoder_model: 'fp32',
            decoder_model_merged: 'q4',
          },
          device: actualDevice,
          progress_callback,
        })
      }
    })()

    return Promise.all([this.tokenizer, this.processor, this.model])
  }
}

View on GitHub (pinned to 677329427f)

Solutions

Accept the fallback — fp32 works everywhere; it just downloads more bytes and runs slower.
Check navigator.gpu && adapter.features.has('shader-f16') before expecting fp16 to work.
Clear the transformers.js model cache and retry if the fp16 error looks like a corrupt download (fetch/CRC errors rather than dtype errors).
Update GPU drivers / use a Chromium build with WebGPU to get fp16 back.

Example fix

// before
dtype: { encoder_model: 'fp16', decoder_model_merged: 'q4' }

// after — pick dtype from adapter capability
const wantsFp16 = adapter?.features?.has('shader-f16') ?? false
dtype: { encoder_model: wantsFp16 ? 'fp16' : 'fp32', decoder_model_merged: 'q4' }

Defensive patterns

Strategy: fallback

Validate before calling

async function supportsShaderFp16(): Promise<boolean> {
  const gpu = (navigator as any).gpu
  if (!gpu) return false
  const adapter = await gpu.requestAdapter()
  return !!adapter?.features?.has('shader-f16')
}

Try / catch

try {
  return await WhisperForConditionalGeneration.from_pretrained(id, { dtype: { encoder_model: 'fp16', decoder_model_merged: 'q4' }, device })
}
catch {
  return await WhisperForConditionalGeneration.from_pretrained(id, { dtype: { encoder_model: 'fp32', decoder_model_merged: 'q4' }, device })
}

Prevention

Probe adapter.features.has('shader-f16') up front and choose dtype accordingly.
Clear the model cache on suspicious fetch/decode errors before retrying.
Keep the fp32 fallback path (already present) so unsupported GPUs still work.

When it happens

Trigger: Loading the whisper model in a browser whose WebGPU adapter lacks 'shader-f16' feature, or where WebGPU is unavailable and the WASM/device backend cannot handle fp16 encoder weights; also transient model-file fetch corruption.

Common situations: Older GPUs/drivers, VMs, remote desktops, some Linux Mesa setups; browser without WebGPU enabled falling back to WASM; first-run download interrupted, leaving a corrupt fp16 weight shard in cache.

Related errors

AI-assisted analysis of moeru-ai/airi@677329427f (2026-08-18). Data as JSON: /api/errors/92df9a5882c6da62. Report an issue: GitHub.