前阵子接了个需求，要在浏览器里实现实时车辆和行人检测，场景是固定的路口摄像头视角。我一开始走的是常规路线：后端部署YOLOv8s，前端传帧、后端返回结果。延迟倒是能压到几十毫秒，但带宽、并发、服务器成本的问题全冒出来了。后来干脆换了个思路——把模型塞进浏览器里跑，用YOLOv8n作为基座，再做算法融合和一系列轻量化优化。折腾两周之后，在普通笔记本上做到了20帧上下的实时检测，手机端也能跑起来。这篇文章就把这套改进方案的完整链路、核心取舍和踩坑记录整理出来，给同样在做Web端目标检测的朋友做个参考。

整个方案的定位很明确：不追求服务器端大模型的极致精度，而是在隐私不出设备、零服务器成本、低延迟的前提下，做到“能用、够用”。如果你正准备在Web端做类似的事情，这篇内容应该能帮你少走不少弯路。

1. 为什么Web端实时检测绕不开YOLOv8n这条路线

很多人的第一反应是：Web端检测，直接用现成的JavaScript库调一个预训练模型不就行了？真上手会发现，事情没那么简单。车辆与行人检测这个场景对实时性、精度和部署环境都有特殊要求，模型选型一旦错了，后面怎么优化都补不回来。

1.1 车辆行人检测场景的特殊约束

车辆和行人检测和通用目标检测最大的区别在于目标尺度跨度极大。一个路口画面里，近处的卡车可能占几百个像素，远处的行人可能只有十几个像素。YOLOv8预训练模型在COCO数据集上对car、truck、bus、person这些类别的识别能力是可以直接复用的，这省了大量标注成本。但COCO场景和真实路口场景之间的分布差距也存在：真实摄像头视角通常是俯视、光照复杂、有遮挡，模型需要针对本地数据做微调。

这个场景对实时性的要求比通用检测高得多。车辆和行人都在持续运动，每多一秒延迟，结果的可信度就下降一截。后端方案之所以体验不好，就是因为在网络传输和队列等待上消耗了太多时间。而Web端方案把推理链路压缩到了浏览器内部，延迟直接降一个数量级。虽然模型精度天花板低于服务器端大模型，但对路口监控、园区安防这类偏“感知”而非“精确测量”的场景，这个性价比是值得的。

1.2 YOLOv8n在轻量模型里的位置

把模型放到浏览器跑，先得面对算力天花板。浏览器端没有GPU的大规模并行能力，除非走WebGPU路线，否则CPU推理是常态。在CPU上，模型参数量和计算量直接决定帧率。我在选型时对比过几个常见轻量模型：

结论很清楚：YOLOv8n是能在Web端勉强跑起来且精度还算可靠的上限。YOLOv5n虽然更快，但在遮挡和远距离行人上漏检率太高；YOLOv8s又太重，初始推理延迟就过不了关。所谓“绕不开”，不是说YOLOv8n完美，而是它卡在了一个算力和精度的甜点上，后面所有的优化才有发挥空间。

1.3 把检测放到浏览器里，究竟图什么

这个方案真正的价值不是技术炫技，而是解决了三个实际问题。第一是隐私，摄像头画面完全在用户本地处理，不需要把原始视频传到服务器，这在很多场景里是硬性要求。第二是延迟，推理结果直接在浏览器生成，省去了网络往返时间，交互响应更跟手。第三是成本，浏览器端推理不占服务器算力，尤其适合摄像头数量多但并发访问量不高的场景。

当然代价也很明确：无法跑大模型，精度天花板低，低端设备上体验勉强。这也是为什么我在整套方案里把“算法融合+动态策略”放在很重的位置——既然模型不能变大，就用工程手段把每一帧的算力花在刀刃上。

2. Web端部署链路搭建：从PyTorch权重到前端推理

把YOLOv8n从PyTorch搬到浏览器，不是简单地把权重文件丢进前端就行。中间涉及模型导出、推理引擎选择、前后处理重写，每一步都有坑。这节记录的是我实际跑通的链路。

2.1 模型导出：哪些开关该关，哪些坑别踩

第一步是把.pt权重导出成ONNX格式。这里最关键的一个决定是：导出时不要带NMS后处理。YOLOv8官方导出工具默认会附加端到端NMS模块，看起来很方便，但在Web端这会把输出变成动态shape，不同帧的检测框数量不一样，很多推理引擎对动态shape的支持不稳定，稍不留神就报错。我最终导出的是去掉NMS的裸网络，输出固定张量1×84×8400，后处理全部放到JS里自己实现。

导出命令大致是：

pip install ultralytics onnx onnxsim # 导出固定尺寸、不带NMS的ONNX模型 yolo export model=yolov8n.pt format=onnx opset=12 simplify=True dynamic=False

对于Web端，输入尺寸建议固定，不要开动态轴。我测试过640和480两种分辨率，固定尺寸可以避免推理引擎在运行时做shape推断，稳定性和速度都有提升。opset用12或13都行，太高反而可能导致浏览器端算子不支持。导出后用Netron看一眼计算图，重点确认输出节点是否真的是原始检测头。

2.2 推理引擎选型：WASM与WebGPU的组合方案

目前Web端推理引擎主要有两条路线：一是WebAssembly加SIMD的CPU推理，二是WebGPU的GPU推理。我的项目实际是两条腿走路，以WASM为主链路，检测到WebGPU可用时自动切换。

WASM路线的兼容性最好，主流的浏览器都能跑，缺点是CPU推理速度有限。在普通笔记本上，640输入大概100到200毫秒一帧。WebGPU路线依赖浏览器原生支持，速度能提升到40到60毫秒一帧，但移动端浏览器支持还不完全，只能作为渐进增强。在代码里做一个能力检测，优先用WebGPU，降级到WASM，是当前最稳妥的组合方案。

模型加载方式也值得注意。不要每次打开页面都从服务器拉权重文件，最好配合Service Worker做预缓存。YOLOv8n的ONNX模型大约6MB，量化后能压到3MB左右，对移动网络仍然是个负担。

2.3 前端预处理与后处理：真正耗时的地方

很多人以为模型推理是全部耗时，实测下来前后处理占用的时间经常被低估。预处理的letterbox、归一化、CHW转换，以及后处理的置信度筛选和NMS，每一步在JS里都可能成为瓶颈。

预处理我建议直接用Canvas完成传统resize，避免手写像素插值。先把视频帧画到一个离线Canvas上，按letterbox规则缩放，再通过getImageData拿到RGBA像素数据，转成Float32Array并做归一化。注意这里有几个细节：一是Canvas宽度高度必须是整数，否则边缘像素会对不齐；二是转CHW时，循环顺序要按“先通道再行再列”来写，避免额外做一次转置。

后处理的核心是按置信度阈值先行过滤，再对剩下的框做NMS。代码骨架大致是：

// 输出张量 shape 为 [1, 84, 8400] const data = output.data; // Float32Array const numClasses = 80; const numAnchors = 8400; const candidates = []; for (let i = 0; i < numAnchors; i++) { let maxScore = 0; let classId = -1; for (let c = 0; c < numClasses; c++) { const score = data[i * 84 + 4 + c]; if (score > maxScore) { maxScore = score; classId = c; } } if (maxScore >= confThresh) { const cx = data[i * 84]; const cy = data[i * 84 + 1]; const w = data[i * 84 + 2]; const h = data[i * 84 + 3]; candidates.push({ x: cx - w / 2, y: cy - h / 2, w, h, score: maxScore, classId }); } } // 对 candidates 按 score 排序后执行 NMS

置信度阈值建议设在0.25到0.35之间。阈值太低，密集路口会出现大量重叠框，NMS压力剧增；阈值太高，遮挡行人和远距离车辆容易被漏掉。这个值需要根据实际视频的清晰度和模型微调效果来定。

3. 算法融合的核心：让检测、跟踪和动态策略协同起来

“算法融合”在这套方案里不是简单地把好几个模型凑在一起，而是让检测模型、跟踪算法和动态调度策略协同工作。纯粹逐帧推理，在Web端的算力限制下是走不通的，必须让每一帧都花在关键位置上。

3.1 隔帧检测与IOU跟踪的接力方案

实测下来，YOLOv8n在WASM上的推理速度不足以支撑每帧检测。一个很自然的思路是：不是每一帧都跑完整检测，而是每隔3到5帧跑一次检测，中间帧用跟踪算法补位。

跟踪算法选了轻量的IOU跟踪思路，本质上就是SORT的简化版。核心逻辑很简单：新检测框和已有跟踪轨迹做IOU匹配，IOU大于0.5就认为是同一个目标，用当前检测框更新轨迹位置；没匹配上的检测框新建轨迹；连续多帧没有匹配的轨迹直接删除。

这个方案对车辆和行人这类运动速度不是特别快的目标足够用。行人走路、车辆过路口，帧间位移通常不会太大，IOU匹配的稳定性完全够。如果换成高速运动目标，比如体育比赛里的画面，这个方案就不行了，得考虑带特征提取的跟踪算法。

这里可以补充一个细节：检测和跟踪结果的融合规则不要只做覆盖，可以做加权。如果某条轨迹最近3帧内都有高置信度检测框，说明目标状态可靠；如果连续两帧只有跟踪框没有检测框，说明模型暂时丢了目标，此时应该降低展示框的置信度，而不是直接消失。这样在视觉上更平滑，也不容易误导后续的业务逻辑。

3.2 动态分辨率与目标区域的策略设计

固定输入尺寸是最省事的做法，但不是最优做法。路口这类固定监控场景有一个明显特点：大部分时间画面里只有零散车辆和行人，真正拥挤的时刻占少数。如果模型一直以最高分辨率运行，大部分算力都浪费在“没什么可看”的帧上。

我实现了一个简单的动态分辨率策略。根据上一帧检测出的目标数量决定下一帧的输入尺寸：目标少于阈值时降到320×320，中等数量用480×480，目标密集时再上到640×640。这个策略的收益很大，实测在车辆稀疏的路段，帧率能直接翻倍。

还可以配合ROI区域设定。固定摄像头视角下，画面边缘通常是固定的建筑、树木，根本不可能是检测区域。前端可以把这些区域标出来，在预处理阶段就置为纯色，相当于变相缩小了有效检测范围。这个做法的精度损失几乎为零，但能减少模型被骗的概率，比如树影晃动时不会误检成人。

3.3 Worker架构与帧率自适应的实现细节

Web端实时检测一个很容易被忽视的问题是线程阻塞。如果把推理放在主线程，哪怕一帧只花100毫秒，期间用户去点页面按钮都会卡顿。正确做法是用Web Worker把推理逻辑和主线程完全隔离。

我的架构分三层：主线程负责视频采集和结果渲染，一个Worker负责模型推理，另一个Worker负责跟踪与后处理计算。视频帧通过OffscreenCanvas转交给Worker，推理结果再通过消息传递回主线程。要注意的坑是：Worker之间传递大量像素数据时，如果用结构化克隆会非常慢，最好用transferable对象把ArrayBuffer转移过去，转移之后原线程就不能再访问这块内存了。

帧率自适应方面，视频源通常是30帧每秒，但检测速度可能只有12帧每秒。不能简单用“每3帧检测一次”的固定逻辑，因为设备性能会动态变化。我的做法是维护一个平滑的时间戳队列，统计最近20帧的实际推理耗时，动态计算检测间隔，保证输出结果的流畅度，而不是强行追帧率。

4. 模型优化的实测收益：从量化到后处理裁剪

模型本身的优化是方案的核心之一。YOLOv8n再轻，直接搬到浏览器也有性能压力。这里的优化分成三块：模型量化、结构裁剪思路、后处理改造。

4.1 量化到哪种程度Web端才扛得住

模型量化是Web端部署最容易立竿见影的手段。我对比过三种方案：

车辆和行人检测属于安全相关场景，我对精度损失很敏感。实际测试中，INT8量化后车辆检测的mAP损失大约1到2个点，但远距离小行人的漏检率上升得比较明显，尤其低光照下更明显。最终我的选择是先量化到FP16打底，再针对关键场景验证INT8能否接受。如果业务更偏向车辆计数，INT8完全可用；如果行人安全告警是核心功能，还是保留FP16更稳。

量化流程上用静态量化，校准集不必太大。准备两三百张覆盖白天、夜晚、晴雨天的截图就够了。需要注意的是校准集分布要贴近真实场景，如果全用白天数据校准，夜晚场景的量化误差会明显放大。

4.2 结构裁剪的边界与正确做法

有的教程会教人直接删掉模型里的某些模块，比如把C2f的层数从3改到2，或者在深层把普通卷积换成深度可分离卷积。从工程角度讲，这些做法的代价容易被低估。任何结构改动都意味着模型不再和预训练权重匹配，需要自己重新训练和调参，这在Web端部署的现实周期里往往不划算。

所以我更推荐用训练框架提供的缩放因子直接生成更小的变体，而不是手工改结构。YOLOv8n本身已经是nano级别，再往下缩的收益有限，而精度损失会快速放大。我的经验是：结构层的优化是最后一条路，前面把分辨率策略、量化、后处理做好，往往已经能满足需求，不必动结构。

4.3 EfficientNMS与输出解析的优化

后处理优化经常被忽略，但它的收益非常直观。模型输出的8400个候选框如果全部参与NMS，循环次数是恐怖的。优化思路是先按置信度阈值过滤掉绝大多数框，再参与NMS。

具体实现有两个关键点。一是排序问题，不要在过滤前对全部8400个框排序，而是先过滤出几十个候选框，再对这几十个排序，时间差非常大。二是按类别分组做NMS，车辆和行人不会互相抑制，如果混在一起算，有些紧挨着路边的行人会被车的框抑制掉。实测下来，优化后NMS耗时从10毫秒以上降到2毫秒以内，这个节省完全白拿。

把整个优化阶梯的效果整理一下：

5. 实测数据与那些容易翻车的边界条件

方案做完之后，我在不同设备上做了多轮验证。很多问题只有在真机密集场景里才会暴露，这节记录的就是实测数据和最容易翻车的边界条件。

5.1 不同设备上的性能参考

设备性能差异在Web端被浏览器版本、是否开启硬件加速等因素进一步放大。以下是我用同一段路口视频做离线测试的参考数据：

这里要强调的是，帧率数字在不同浏览器、不同版本里波动很大，不能只看一次测试结果就下结论。建议在自己的目标浏览器环境里跑一个压测脚本，统计P50和P95延迟，P95比P50更能反映卡顿体验。

5.2 密集场景、小目标与夜晚

密集路口是这套方案的最大考验。车辆和行人交错时，检测框互相重叠，NMS的抑制阈值需要单独调。我遇到过的问题是：两辆并排车辆被一个框框住，或者行人被旁边车辆的框大面积抑制。解决方法是把NMS的IOU阈值从默认0.45适当调高到0.5，同时给不同类别设置独立的置信度阈值，行人可以稍微低一点。

小目标方面，YOLOv8n在800像素以下输入尺寸下，对十几像素的行人基本无力。坦白说，这个方案应对远距离小目标的能力有限，需要通过动态ROI把近处区域切出来跑高分辨率，或者接受漏检。千万不要指望一个3M参数量的模型解决所有尺度的问题，这不现实。

夜晚和逆光场景也值得单独说。预训练模型在夜间路口的表现明显下滑，主要是因为训练集的夜间样本不足。我的做法是收集一段本地的夜间视频做增量微调，不用太多，几百帧就够了，效果立竿见影。这里强调的是，安全类检测场景绝不能只依赖预训练权重，本地数据微调是必经步骤。

5.3 内存、加载时间和浏览器权限的坑

Web端部署有两个容易被低估的工程问题：内存和首帧时间。

WASM推理时，模型权重和中间张量都会占用线性内存。低端安卓手机在画面较大时可能直接内存溢出，页面白屏。对策是尽量用低分辨率输入、量化模型，以及用完及时释放Worker。还有多标签页问题，同一个浏览器开多个检测页面，每个页面都加载一份WASM，内存翻倍，非常容易卡死，最好在业务上做单标签限制。

浏览器权限方面，getUserMedia只有在HTTPS安全上下文下才能调用，本地调试要用localhost或者配置本地证书。权限拒绝状态要单独处理，不能简单当作“摄像头不可用”，否则页面会反复请求权限。另外浏览器对视频流的处理本身也有性能损耗，实测某些浏览器上Canvas每帧绘制的耗时甚至接近模型推理耗时，这个环节也要做性能监控，不能光盯模型。

最后分享一点个人体会。这套方案不适合和服务器端大模型比拼绝对精度，它的价值在于把“检测”这件事搬到了用户本地，用低成本、低延迟的方式覆盖真实需求。实际落地时，代码层面的优化只是起点，真正决定体验的是你对场景的理解——哪些区域值得跑高分辨率、哪些时段可以闲置、哪些类别的漏检不可接受。这些业务判断，比任何模型技巧都重要。如果后续时间充裕，我准备把后处理的NMS也用WASM模块重写一遍，再试试WebGPU下并行处理候选框，应该还能挤出一些性能空间。这个方向值得继续挖，也希望有同行一起交流各自踩过的坑。