上周五面了一家做端侧AI的公司，B轮，团队80人，产品方向是浏览器内置AI助手。 终面，技术VP面。 一上来没问项目经历，直接抛了个问题： "WebGPU 1.0刚成为W3C正式标准。假设我们的产品经理要求你在浏览器里跑一个7B参数的语言模型，不依赖后端API，纯端侧推理。你怎么设计这个系统？" 我心里一紧——这不是八股文，是实打实的系统设计。 但我刚好在做这件事。

先拆解问题

我没有急着写代码。先跟VP确认了3个约束条件：

1. 目标设备：中高端笔记本，16GB内存，集成显卡支持WebGPU
2. 模型规模：7B参数，量化后约4GB
3. 延迟要求：首Token生成时间<3秒，后续Token生成速度>15 TPS VP点点头："对，这就是我们的产品目标。"

系统架构设计 我在白板上画了5层架构： 第1层：模型加载层 "7B模型量化到4-bit后约4GB。WebGPU的GPU内存限制通常在总内存的50-70%，所以16GB笔记本大约有8-10GB可用GPU内存。4GB模型可以完整加载。" "关键问题是怎么加载。WebGPU没有原生的大文件读取API，需要：

1. 用Fetch API从CDN拉取模型文件（分块传输，每块64MB）
2. 在CPU内存中解压GGUF格式
3. 通过writeBuffer将权重数据写入GPU Buffer" VP追问："分块传输的时候，如果网络断了怎么办？" "用Service Worker做离线缓存。模型文件下载完成后缓存到CacheStorage。第二次打开直接走缓存，不需要重新下载。如果下载中断，从断点续传。"

第2层：计算层 "Transformer的核心计算是矩阵乘法。WebGPU提供了compute shader，可以在GPU上执行GPGPU计算。" "关键优化点： • 分块矩阵乘法（Tiling）：把大矩阵切成16x16的小块，利用GPU的shared memory做局部计算，减少global memory访问 • KV Cache：生成每个Token时，之前的Key/Value不需要重新计算，缓存到GPU内存中 • 算子融合：把LayerNorm + Linear + RoPE合成一个compute pass，减少GPU内存读写次数" VP："你实际跑过吗？P50延迟多少？" "我测过。7B-4bit模型，在M2 MacBook Air上，首Token延迟2.1秒，后续生成速度约22 TPS。在Windows集显本上差一些，大概14-16 TPS。"

对了。顺嘴提一句，技术大厂，前后端-测试机会，全国一线及双线城市均有坑位，待遇和稳定性还不错，感兴趣看看。

第3层：调度层 "浏览器是单线程的。如果推理计算一直占用GPU主线程，UI会卡死。" "方案是用Web Worker + WebGPU的组合： • 主线程：负责UI渲染、用户输入 • Worker线程：负责模型推理 • 通过Transferable Objects在两个线程间传递数据，零拷贝" VP追问："如果用户同时在浏览网页，GPU资源怎么分配？" "WebGPU提供了队列优先级机制。可以给推理任务设置low priority queue，浏览器渲染任务走high priority queue。当用户滚动页面时，推理自动让出GPU资源。"

第4层：交互层 "最后是用户体验设计。端侧推理有两个痛点：

1. 首次加载慢（4GB模型下载+解压约需30秒）
2. 生成过程中用户不知道进度" "方案： • 启动时展示骨架屏+进度条，显示下载百分比 • 生成Token时用流式渲染，模拟打字机效果 • 提供'模型管理'页面，支持下载/删除/更新模型"

追问环节

追问1："WebGPU和WebAssembly+CPU推理相比，优势在哪？" "速度。同样7B-4bit模型，纯CPU用WebAssembly跑，速度约5-8 TPS。WebGPU可以跑到14-22 TPS。核心原因是GPU的并行计算能力——矩阵乘法天然适合GPU的SIMD架构。而且GPU推理不占用CPU，不会影响页面其他逻辑。"

追问2："如果模型超过GPU内存怎么办？比如13B模型？" "两种方案。第一，CPU-GPU混合推理：把模型切成两部分，前几层放GPU，后几层放CPU。第二，模型offload：参考llama.cpp的做法，把不常用的层offload到内存，只保留当前计算需要的层在GPU上。但性能会下降50%以上。"

追问3："WebGPU的浏览器兼容性怎么样？" "2026年Q1，W3C已经发布了1.0稳定版规范。Chrome、Firefox、Safari、Edge四大浏览器100%兼容。Safari是最后一个支持的，从去年底开始跟进。现在全球WebGPU覆盖率已经超过92%。"

面试后第3天收到offer。薪资涨了40%。