moeru-ai/airi · warning

[Kokoro Worker] Failed with dtype=${attempt.dtype} device=${

Error message

[Kokoro Worker] Failed with dtype=${attempt.dtype} device=${attempt.device}, trying next fallback...

What it means

Inside the Kokoro TTS worker, one dtype/device load attempt (e.g. fp32 on webgpu) failed; the loop moves to the next fallback combination and logs the pair that failed. If every combination fails, the worker posts a sendError(requestId, lastError, 'load') message. On success, the ready message reports actualDtype/actualDevice of the winning attempt, so callers can see what was actually used.

Source

Thrown at packages/stage-ui/src/workers/kokoro/worker.ts:206

          return
        }
        const ready: ModelReadyResponse = {
          type: 'model-ready',
          requestId,
          modelId: MODEL_NAMES.KOKORO,
          device: attempt.device as 'webgpu' | 'wasm' | 'cpu',
          metadata: {
            voices: ttsModel.voices,
            actualDtype: attempt.dtype,
            actualDevice: attempt.device,
          },
        }
        globalThis.postMessage(ready)
        return
      }
      catch (error) {
        lastError = error
        console.warn(
          `[Kokoro Worker] Failed with dtype=${attempt.dtype} device=${attempt.device}, trying next fallback...`,
          errorMessageFromValue(error),
        )
      }
    }

    // All attempts exhausted
    if (isCancelled(requestId))
      clearCancelled(requestId)
    else
      sendError(requestId, lastError ?? new Error('All dtype/device combinations failed'), 'load')
  }
  catch (error) {
    if (isCancelled(requestId))
      clearCancelled(requestId)
    else
      sendError(requestId, error, 'load')
  }

View on GitHub (pinned to 677329427f)

Solutions

  1. Use a WebGPU-capable browser (recent Chrome/Edge with WebGPU enabled) for GPU inference
  2. Let the fallback chain reach wasm/cpu — slower but works everywhere
  3. Free memory (close tabs, reduce parallel loads) if wasm attempts OOM
  4. Verify network access to the model host when a specific dtype's shards fail to fetch
  5. If all combos fail, read the worker's sendError 'load' payload: lastError holds the root cause

Example fix

// before
for (const attempt of attempts) {
  try { /* load with attempt.dtype / attempt.device */ }
  catch (error) {
    console.warn(`[Kokoro Worker] Failed with dtype=${attempt.dtype} device=${attempt.device}, trying next fallback...`)
  }
}

// after: skip doomed webgpu attempts before paying the load cost
const viable = attempts.filter(a => a.device !== 'webgpu' || (typeof navigator !== 'undefined' && 'gpu' in navigator))
for (const attempt of viable) { /* ... */ }
Defensive patterns

Strategy: fallback

Validate before calling

const supportsWebGPU = typeof navigator !== 'undefined' && 'gpu' in navigator
// skip webgpu dtype/device attempts up front when the adapter is missing

Type guard

function supportsWebGPU(): boolean {
  return typeof navigator !== 'undefined' && 'gpu' in navigator
}

Try / catch

for (const attempt of attempts) {
  try {
    /* load model with attempt.dtype / attempt.device */
  }
  catch (error) {
    lastError = error
    console.warn(`[Kokoro Worker] Failed with dtype=${attempt.dtype} device=${attempt.device}, trying next fallback...`, errorMessageFromValue(error))
  }
}
// exhausted: sendError(requestId, lastError ?? new Error('All dtype/device combinations failed'), 'load')

Prevention

When it happens

Trigger: No WebGPU adapter (older browser, VM, Linux without GPU, flags disabled) so webgpu pairs fail; fp16 unsupported on the GPU; out-of-memory under wasm; model shard fetch failing for one dtype but not another.

Common situations: Running in a VM or on Linux without GPU drivers; older Safari; memory-constrained devices where even wasm OOMs; corporate proxy blocking some model downloads.

Related errors


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