moeru-ai/airi · warning

[KokoroAdapter] ${deviceLossCount} device-loss events record

Error message

[KokoroAdapter] ${deviceLossCount} device-loss events recorded, promoting load from webgpu to wasm.

What it means

The Kokoro adapter counts WebGPU 'device-lost' events; once deviceLossCount reaches DEVICE_LOSS_WASM_THRESHOLD, load() no longer honors a requested 'webgpu' device and silently substitutes 'wasm', warning first. This is proactive degradation: per-load fallback chains inside the worker handle one-off losses, while this guard stops retrying a GPU that is persistently unstable on this machine.

Source

Thrown at packages/stage-ui/src/libs/inference/adapters/kokoro.ts:332

  async function loadModel(
    quantization: string,
    device: string,
    options?: {
      onProgress?: (p: ProgressPayload) => void
      signal?: AbortSignal
    },
  ): Promise<Voices> {
    // NOTICE: Proactive WASM promotion. If this adapter has suffered repeated
    // WebGPU device-loss events, webgpu is unreliable on this device and we
    // should not keep retrying. The worker's per-load dtype/device fallback
    // chain handles transient failures; this guard handles persistent ones.
    let effectiveDevice = device
    if (
      device === 'webgpu'
      && deviceLossCount >= DEVICE_LOSS_WASM_THRESHOLD
    ) {
      console.warn(
        `[KokoroAdapter] ${deviceLossCount} device-loss events recorded, `
        + `promoting load from webgpu to wasm.`,
      )
      effectiveDevice = 'wasm'
    }
    throwIfAborted(options?.signal)
    await ensureStarted()

    return defaultPerfTracer.withMeasure('inference', 'kokoro-load-model', () => operationMutex.runExclusive(async () => {
      throwIfAborted(options?.signal)
      state = 'loading'
      const modelStatusId = `kokoro-${quantization}`

      // Clear previous model status when switching models
      if (currentModelStatusId && currentModelStatusId !== modelStatusId)
        removeInferenceStatus(currentModelStatusId)
      currentModelStatusId = modelStatusId

View on GitHub (pinned to 677329427f)

Solutions

1. Accept the wasm promotion — inference continues, only slower.
2. Update GPU drivers and the browser (WebGPU stability improves release over release).
3. If you control the request path, request device: 'wasm' from the start on machines known to be unstable, avoiding the warn entirely.
4. Report persistent device-loss patterns to the browser vendor if tied to a specific GPU.

Example fix

// before
await kokoro.load(progress, { signal }) // device: 'webgpu' default, flaky GPU

// after
await kokoro.loadDevice?.({ device: 'wasm' }, progress, { signal }) // or pass wasm explicitly per adapter API

if (navigator.gpu) {
  // still expect possible promotion; device-loss counter decides
} else {
  requestWasmFromStart()
}

When it happens

Trigger: Repeated WebGPU device loss (driver reset, GPU hung, browser WebGPU implementation bugs) during kokoro loads on the same session; hardware/driver combos where webgpu init succeeds but compute dies mid-run.

Common situations: Laptops with hybrid graphics and flaky drivers; older browser versions with immature WebGPU; long sessions that eventually trigger a driver-level reset.

Related errors

• [WhisperAdapter] ${deviceLossCount} device-loss events recor
• WebGPU is required for this model but is not available in yo
• Failed to initialize speech provider
• [Kokoro Worker] Failed with dtype=${attempt.dtype} device=${
• [KokoroAdapter] Restarting in ${delay}ms (attempt ${restartA

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