在端侧 WebGPU 大模型或高性能计算着色器的实际运行中，许多前端工程师往往只在顺风顺水的理想环境下测试：电脑插着电源、独显常开、屏幕常亮。然而一旦推向成千上万的真实用户，控制台日志里便会频繁冒出一种极其诡异且无法被普通 try / catch 捕获的致命故障：

DOMException: Device lost: The WebGPU device was lost due to an unknown reason.
Uncaught (in promise) Error: Cannot write to buffer because device is lost.

伴随着这个错误，用户眼前的模型推理打字机瞬间哑火，点击“重新生成”或发送新问题毫无反应，整个页面的 WebGPU 能力彻底脑死亡，用户除了 F5 刷新整个页面外别无他法。

这个噩梦的根源就是 WebGPU 规范中最核心也最残酷的底层机制——设备丢失（Device Lost）。

在现实世界中，用户合上笔记本盖子休眠、外接扩展坞拔掉 HDMI 线切换集成显卡、电脑电量低于 20% 触发操作系统激进省电策略、甚至大模型矩阵计算耗时稍长触发了 Windows 的显卡超时检测与恢复机制（TDR，Timeout Detection and Recovery），操作系统都会毫不留情地重置显卡驱动上下文。

在这一瞬间，之前分配的所有 GPUBuffer、GPUTexture、ComputePipeline 和 BindGroup 全部被物理作废！

如果不为端侧推理引擎构建一套能够自动感知、安全释放并静默重建的自愈系统，端侧 AI 的高可用性就只是一句空话。本文详解如何攻克这一底层死结。

Device Lost 的物理真相与捕获机制

在 WebGPU 架构中，GPUDevice 是浏览器向操作系统图形驱动借用的计算句柄。

• 普通的显存越界或着色器语法错误，可以通过 device.pushErrorScope() 捕获；
• 但当操作系统层面发生驱动重置或硬件脱机时，驱动与硬件的连接被瞬间切断，GPUDevice 会直接转变为“Lost 状态”。此时任何向命令编码器（Command Encoder）或缓冲区（Queue）写入数据的调用都会无情抛出异常。

最关键的是：Device Lost 是一个异步的全局事件，它绝不可能被局部的 try/catch 所阻断。

正确的监听方式是在初始化 Device 的第一时间，监听其内置的 device.lost Promise：

// 规范的 Device Lost 监听骨架
const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();

device.lost.then((info) => {
  console.error(`[WebGPU Critical] 显卡设备丢失！原因: ${info.reason}, 信息: ${info.message}`);
  
  if (info.reason === 'destroyed') {
    // 开发者主动调用了 device.destroy()，属于正常受控释放
  } else {
    // 硬件脱机、驱动重置、休眠唤醒等不可抗力触发异常丢失！必须启动紧急自愈！
    triggerDeviceAutoRecovery();
  }
});

显存安全释放与防泄漏铁律（Buffer Destruction）

在启动重建之前，千万不能直接不管不顾地 new WebGpuEngine()。
虽然旧的 device 已经失效，但它内部引用的 JavaScript 包装对象如果依然被全局变量或事件闭包持有，V8 堆内存中的大量外部物理显存引用（External Memory）将无法被垃圾回收，极易造成严重的显存内存双重泄漏。

我们必须执行递归物理销毁（Explicit Resource Tear-down）：

// src/ai/gpuResourceManager.ts

export class GpuResourceManager {
  private buffers = new Set<GPUBuffer>();
  private pipelines = new Set<GPUComputePipeline>();

  public trackBuffer(buffer: GPUBuffer): GPUBuffer {
    this.buffers.add(buffer);
    return buffer;
  }

  /**
   * 彻底清扫所有残留硬件资源
   */
  public purgeAll(): void {
    console.log(`[GPU Manager] 正在安全释放 ${this.buffers.size} 个显存缓冲区...`);
    
    for (const buffer of this.buffers) {
      try {
        // 显式调用规范级物理销毁方法，立即向驱动交还显存
        buffer.destroy();
      } catch (e) {
        // 忽略已经处于销毁状态的异常
      }
    }

    this.buffers.clear();
    this.pipelines.clear();
  }
}

核心工程实现：生产级自愈重建控制器

我们封装了一套具备会话上下文保留、静默重建重试与指数退避的 WebGpuLifecycleController：

// src/ai/webGpuLifecycle.ts
import { GpuResourceManager } from './gpuResourceManager';

export type RebuildCallback = (newDevice: GPUDevice) => Promise<void>;

export class WebGpuLifecycleController {
  private adapter: GPUAdapter | null = null;
  private device: GPUDevice | null = null;
  private resourceManager = new GpuResourceManager();
  private onRebuild: RebuildCallback;
  private isRecovering = false;

  constructor(onRebuild: RebuildCallback) {
    this.onRebuild = onRebuild;
  }

  public async init(): Promise<GPUDevice> {
    if (!navigator.gpu) throw new Error('WebGPU not supported');

    this.adapter = await navigator.gpu.requestAdapter({
      powerPreference: 'high-performance'
    });
    if (!this.adapter) throw new Error('No appropriate GPUAdapter found');

    this.device = await this.adapter.requestDevice();
    this.bindDeviceLostListener(this.device);

    return this.device;
  }

  private bindDeviceLostListener(device: GPUDevice): void {
    device.lost.then(async (info) => {
      console.warn(`[WebGPU] 捕获到硬件上下文断开 [Reason: ${info.reason}]`);

      if (info.reason === 'destroyed') return; // 主动销毁，无需恢复

      await this.handleDeviceLostRecovery();
    });
  }

  private async handleDeviceLostRecovery(): Promise<void> {
    if (this.isRecovering) return;
    this.isRecovering = true;

    console.log('[WebGPU Auto-Heal] 启动设备丢失平滑自愈管线...');

    // 1. 强制清理全部旧显存资源，防止泄漏
    this.resourceManager.purgeAll();
    this.device = null;

    // 2. 给予操作系统与显卡驱动 1 秒的稳态恢复期（避免连续重试震荡）
    await new Promise((r) => setTimeout(r, 1000));

    let retryCount = 0;
    const maxRetries = 3;

    while (retryCount < maxRetries) {
      try {
        console.log(`[WebGPU Auto-Heal] 正在尝试第 ${retryCount + 1} 次静默重建 Device...`);
        // 重新请求 Adapter 与 Device
        const newDevice = await this.init();
        
        // 3. 执行业务层管道与模型权重的热重载
        await this.onRebuild(newDevice);
        
        console.log('[WebGPU Auto-Heal] 恭喜！WebGPU 算力管线已完全自愈复活！');
        this.isRecovering = false;
        return;
      } catch (err) {
        retryCount++;
        console.error(`[WebGPU Auto-Heal] 重建失败，将在指数退避后重试...`, err);
        await new Promise((r) => setTimeout(r, 1500 * Math.pow(2, retryCount)));
      }
    }

    this.isRecovering = false;
    console.error('[WebGPU Fatal] 硬件严重故障或被拔除，触发终极回退：全面切换云端推理！');
    // 派发全局事件，通知路由层切换至云端
    window.dispatchEvent(new CustomEvent('webgpu:fatal-fallback-to-cloud'));
  }

  public getResourceManager(): GpuResourceManager {
    return this.resourceManager;
  }
}

业务层会话无感恢复体验

配合这套自愈控制器，业务层在遇到“笔记本合盖再开”或“拔插显示器”等极端情况时：

1. 控制器在后台静默完成显存释放与驱动重连；
2. 由于前文介绍的 Cache API 本地持久化缓存，模型权重不需要重新走网络下载，直接从磁盘秒级重新映射进新显卡；
3. 用户在几秒钟的短暂等待后，再次点击生成按钮，推理立刻无缝继续，页面无需任何强制刷新。
4. 若显卡驱动彻底瘫痪（如重试 3 次均失败），系统平滑切入云端 API 兜底，彻底终结了死锁白屏。

结语

在现代 Web 前端进入系统级图形与 AI 编程的新纪元后，架构师的思维必须从“纯 JavaScript 运行环境”跨越到“操作系统硬件与图形驱动”的广阔物理世界。敬畏硬件的脆弱性，把异常处理从简单的条件判断升华为具备物理资源回收与自愈能力的弹性架构，我们的端侧 WebGPU 应用才能经受住数以亿计真实设备的长尾考验。