Safari: transcribing with Parakeet (Local) locks up the whole machine

[maboa]

What happened

On macOS, Safari froze the entire MacBook Pro when transcribing with the Parakeet (Local) tab (shipped in v0.6.8). The whole OS locked up, not just the browser tab.

Environment

• Browser: Safari (macOS, Apple Silicon)
• Engine: Parakeet (Local), v0.6.8
• Chrome on the same machine works fine.

Leading hypothesis

The WebGPU fp16 encoder (~1.2 GB) exhausting Apple-Silicon unified GPU memory under Safari's WebGPU, or a Safari WebGPU issue with a model that large. mel + decode run on WASM; the encoder is the only WebGPU / large-allocation step.

Possible directions

• Reproduce in Safari while watching GPU/unified memory.
• Check navigator.gpu adapter limits in Safari.
• Consider gating Safari to the int8/WASM path (or a memory check) — mirroring the existing Firefox forced-WASM logic in js/parakeet.worker.js.

Severity

High — whole-OS lockup on a priority browser, in a shipped release.

[maboa]

New finding (Safari, small file): Safari reloads the tab with "The web page was reloaded because it was using significant memory" even on a small audio file — so this is the model/download footprint, not audio length or GPU exhaustion during transcription. It happens at model-load, before transcription.

Two stacking memory costs on the fp16/WebGPU path:

1. The 1.2 GB fp16 encoder loaded into the WebGPU session.
2. fetchModel assembles the download as parts[] (~1.2 GB) and then copies into a single Uint8Array (~1.2 GB) → ~2.5 GB peak before the session loads. Chrome tolerates this; Safari's tighter per-tab memory ceiling does not.

Revised framing: model + download footprint exceeds Safari's tab memory budget, even at idle.

Likely fixes:

• Route Safari to the int8 encoder (652 MB) instead of fp16 (~halves footprint), or force Safari to WASM like Firefox.
• Stream the download directly into Cache Storage instead of parts[] + Uint8Array, removing the ~2× peak.

[maboa]

Comparative data point: Whisper (Local) works fine on Safari.

This corroborates the footprint diagnosis rather than a Safari-WebGPU fault:

• Whisper's default model is ~10× smaller — Base English is ~80–150 MB vs Parakeet's 1.2 GB fp16 encoder, comfortably within Safari's per-tab memory budget.
• transformers.js streams models straight into Cache Storage, so Whisper never incurs the parts[] + Uint8Array ~2× peak that fetchModel creates.

Key implication: Safari's WebGPU itself is fine (Whisper uses it happily) — the issue is specifically Parakeet's model size + download peak, not Safari WebGPU being broken. That argues against forcing Safari to WASM and for shrinking the footprint:

• Stream the download into Cache Storage (removes the ~2× peak) — helps on any path.
• A smaller WebGPU-capable encoder would be ideal, but int8 doesn't run on the WebGPU EP (falls back to CPU), so the realistic Safari options are: keep fp16 but cut the load peak, or accept int8/WASM (slower, like Firefox).