端侧 WebGPU 显存共享实战：1.5B 语言模型与视觉小模型的分时复用架构

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

在端侧 AI 研发进入纵深阶段后，单一的“纯文本聊天机器人”已经很难满足真实的商业业务诉求。在大促导购、智能工单填报或富媒体内容创作等场景中，前端往往需要图文多模态协同——首先利用轻量级端侧视觉模型（如 MobileNetV4、Fast-SAM 或轻量 ViT）对用户上传的商品图片进行即时特征提取与目标检测，随后将提取出的结构化 Prompt 注入 1.5B 语言模型（如 Qwen2.5-1.5B）进行流畅自然的推销文案生成。

然而，一旦在浏览器端同时加载两个模型，前端工程师会立刻面临残酷的物理现实：WebGPU 可用显存配额极其匮乏。

在普通轻薄本、集显设备或主流移动端设备上，浏览器允许单页面申请的最大 GPU 存储缓冲区（maxStorageBufferBindingSize）和显存上限通常只有 1GB 到 1.5GB。一个 4-bit 量化的 1.5B 语言模型需要吃掉约 850MB 显存，一个视觉模型加上前置卷积张量需要 450MB，再加上运行时动态膨胀的 KV Cache 与输出激活张量，双模型常驻显存会瞬间突破阈值，引发 GPUBuffer allocation failed 甚至整页崩溃闪退。

为了打破这一僵局，我们设计了一套端侧 WebGPU 显存池化与分时复用（Time-sharing Multiplexing）架构。本文将深入剖析这套架构的设计思想与工程实现。

显存危机：为什么静态双模型常驻不可行？

我们先算一笔硬核的显存账：

可以看出，视觉模型与语言模型在执行时态上具有天然的顺序串行性（Sequential Pipeline）：用户一定是“先上传图片，视觉模型完成特征向量化，再交由语言模型生成文本”。两者在同一时刻根本不需要同时进行大规模矩阵乘法。

如果让两个模型各自申请独立的 GPU 显存缓冲区并永久常驻，就会造成极其严重的显存闲置与资源错配。

分时复用与显存池（Memory Pool）设计

针对上述痛点，我们设计了以统一“底座显存池（Unified Memory Pool）”为核心的分时复用引擎：

核心架构实现：WebGPU 分时显存协调器

以下为本周在生产环境沉淀的 WebGPU 分时复用协调器核心实现，支持多模型管线生命周期仲裁与共享内存借用：

// webgpu/time-sharing-memory-coordinator.ts
export type ModelType = 'VISION_VIT' | 'LANGUAGE_LLM';

export class WebGPUMemoryCoordinator {
private device: GPUDevice;
private sharedBuffer!: GPUBuffer;
private poolSizeBytes: number;
private currentActiveModel: ModelType | null = null;
private isLocked = false;

constructor(device: GPUDevice, poolSizeMB = 900) {
this.device = device;
this.poolSizeBytes = poolSizeMB * 1024 * 1024;
this.initSharedBuffer();
}

// 1. 初始化预分配统一显存池
private initSharedBuffer() {
this.sharedBuffer = this.device.createBuffer({
size: this.poolSizeBytes,
usage: GPUBufferUsage.STORAGE | GPUBufferUsage.COPY_DST | GPUBufferUsage.COPY_SRC,
mappedAtCreation: false,
});
console.log(`[WebGPU Memory] 成功预分配 ${this.poolSizeBytes / 1024 / 1024}MB 统一共享显存池。`);
}

// 2. 申请模型运行期显存租约（Lease）
async acquireModelLease(modelType: ModelType): Promise<GPUBuffer> {
while (this.isLocked) {
// 互斥等待，确保同一时间只有一个模型管线在刷显存
await new Promise((resolve) => setTimeout(resolve, 20));
}

this.isLocked = true;

if (this.currentActiveModel === modelType) {
this.isLocked = false;
return this.sharedBuffer;
}

console.log(`[WebGPU Switch] 触发模型显存分时切换: ${this.currentActiveModel} ➔ ${modelType}`);

// 快速清理上一个模型的瞬时状态
this.device.queue.writeBuffer(
this.sharedBuffer,
0,
new Uint8Array(1024), // 清空前置元数据区
0,
1024
);

this.currentActiveModel = modelType;
this.isLocked = false;
return this.sharedBuffer;
}

// 3. 释放租约，允许下一个流水线节点接管
releaseModelLease(modelType: ModelType) {
if (this.currentActiveModel === modelType) {
console.log(`[WebGPU Release] 模型 ${modelType} 已释放显存租约。`);
}
}

// 4. 获取共享缓冲区的切片偏移量
getBufferSlice(offsetBytes: number, sizeBytes: number): { buffer: GPUBuffer; offset: number; size: number } {
if (offsetBytes + sizeBytes > this.poolSizeBytes) {
throw new Error(`[WebGPU OOM] 请求切片超出统一显存池边界！`);
}
return {
buffer: this.sharedBuffer,
offset: offsetBytes,
size: sizeBytes,
};
}
}

实测基准数据：静态独占 vs 分时复用

我们在配有 8GB 统一内存的轻薄本设备（Chrome 128 环境）上，对图文多模态端到端处理链路进行了 30 轮对比基准测试：

架构师防坑指南