WASM推理性能为何跑不快？——内存、线程与指令集的深层拆解

上周有个朋友在群里晒出一段测速对比：同一个模型，原生C++推理只要几十毫秒，他费了一整天把代码编到WASM放进浏览器一跑，直接翻了几倍。群友陆续支招，从编译参数到内存对齐试了一圈，始终回不到原生水平，最后他抛出一句灵魂拷问：“是不是WASM这东西成心跟推理过不去？”

这个场景我太熟了。WASM刚火那会儿，大家普遍觉得“能接近原生性能”，于是把模型推理这种计算密集任务往浏览器里搬是理所当然的选择。可真跑起来之后，数据吞吐、调用边界、内存布局、线程模型这些平时根本不在意的细节，像连环坑一样往外冒。这篇文章我把这几年做浏览器端推理踩过的坑、看过的坑、以及最后沉淀下来的判断逻辑，系统地拆一遍，聊聊WASM推理“跑不快”的真正原因。

先立个结论：绝大多数项目卡住，不是因为WASM引擎太弱，而是我们默认“接近原生”这个前提自动成立，却忽略了好性能的根都在数据搬运、内存访问模式、指令级利用这几件小事上。把这几个层次搞明白了，你才知道该往哪个方向拧。

1. “接近原生”的承诺，到底在什么条件下成立？

1.1 先分清WASM的本质：虚拟机里的目标代码

WASM不是一种可以直接落在CPU上的机器码，它是浏览器虚拟机里运行的一套字节码。浏览器引擎拿到WASM模块之后，依然要经过“解析—编译—优化—生成机器码”的过程，最后才变成当前CPU真正执行的指令。

“接近原生”这句话本身没错，但它默认的是：同一段代码，去掉平台差异之后，编译器能生成同等质量的机器码。对于纯数值计算、内存访问连续、没有系统调用、没有动态派发的场景，WASM确实能逼近原生水平。可一旦代码里出现条件分支复杂、函数调用频繁、内存分布零散的情况，引擎和编译器的处理逻辑跟原生环境根本不是一回事。

推理恰恰是个混合体：底层的矩阵乘、卷积是完美适配WASM的纯计算任务，但上面的张量搬运、维度转换、算子调度，又是一堆分支和函数调用。期望“整体都快”，等于默认WASM对每一种代码形态都有原生的优化能力，这不现实。

1.2 推理场景为什么先天吃亏

我常说一句话：推理的速度瓶颈，通常不在“算”上，而在“挪”上。数据从内存取到寄存器、从一层算子的输出搬到下一层算子的输入、从布局A转换成布局B，这些动作在原生环境里都有高度优化的库和指令兜底，而在WASM沙箱里就是裸写的数据移动加循环。

更关键的是，原生推理库动辄用手工汇编、SIMD intrinsic、平台专属的调度器去榨干硬件。这些东西本质上依赖CPU指令集细节。WASM为了跨平台，只能在指令层级取所有平台的公约数，等于你手里有一套万能工具，但每个功能都比平台原装工具钝一点。

1.3 一张表看懂原生和WASM的“性能装备”差异

这张表不是想说明WASM不行，而是想说明：原生C++推理有完整的“性能工具箱”，WASM只有其中很小一部分。你用工具箱齐全的思路去衡量只有几件工具的场景，当然处处不满意。

2. 线性内存和边界检查：被低估的基础成本

2.1 每次访存都要过一道“检查门”

WASM的内存模型是一个巨大的线性内存区域，可以理解成一块连续的大buffer，所有指针本质上都是这块buffer里的偏移量。引擎为了保证沙箱安全，每次load和store都要确认偏移量没有越界，触发越界就要抛异常并终止模块执行。

现代引擎做了很多优化来降低边界检查的开销，比如利用掩码、合并检查、懒检查。但请注意，这只是在“编译器优化得很好”的前提下。一旦你的循环结构复杂、索引计算不是简单递推、数据访问随机跳跃，引擎就没办法消除检查。你每取一个数、每写一个数，中间都夹着一道隐形的判断，循环一跑几十万次，这个成本就变成了一笔不小的开销。

我实测过一个很典型的场景：同样的卷积算子，数据换成“每次循环里做两个if判断索引越界”的版本，性能直接掉了百分之十几。边界检查在C++里是写代码时不需要想的事情，在WASM里却悄悄变成了每个热点循环都会发生的事。

2.2 动态分配是推理循环里的定时炸弹

原生C++推理框架里，各种临时张量、中间缓存通常会在初始化阶段一次性分配好，推理循环里几乎不碰malloc。但直接拿一套通用代码编译到WASM，事情就会失控。

WASM默认的内存分配器并不是为推理场景调的。它的自由链表管理、块合并、对齐策略，都是为了通用性，而不是为了“每次推理线程里几千次小分配”这种压力模式。我在一个项目里见过，把推理循环里的线程局部临时buffer改为预分配之后，耗时直接降到三分之一。这不是玄学，是分配器在WASM里频繁扩容、收缩线性内存的代价太高了。

这里还有个隐性问题：如果每个算子都做一次动态分配，分配出来的内存地址还大概率不连续。跨层传递时缓存命中率掉得厉害，而缓存不命中恰恰是“你以为在算，其实在等内存”的最大来源。

2.3 数据来了又走了：“过桥”成本

原生推理里，输入数据直接放在进程地址空间，算完了输出也放在原地，一切都在一个内存视图里完成。WASM推理面临一个额外的结构性问题：数据必须从JS侧搬进WASM线性内存，推理结束再搬出来。

日常做法是后端拿到输入之后，用一个set方法把TypedArray整个拷贝进WASM堆，推理结束后再把结果拷回JS那边。这段拷贝看起来只是内存复制，但涉及两个运行时边界、一次数据跨区域移动，一旦输入是视频帧、点云这些大块数据，它消耗的时间可能会超过你本来想优化的卷积计算。

最气人的是，很多人优化了半天指令级，回头一测才发现数据搬运占了三成以上的时间。这一步不是WASM本身慢，而是把数据构建在JS侧，本质上是让数据白白跨了一次边界。后面我会细说SharedArrayBuffer和直接在WASM内存里构建数据的方法。

3. 线程和SIMD：WASM推理速度的两块天花板

3.1 默认单线程，多线程是“攒出来”的

WASM规范里没有“线程”这个概念。浏览器里的WASM模块默认在主线程上跑，你指望它像原生推理那样自动起一个线程池做算子并行，完全是做梦。

如果想让多个WASM实例并行计算，你得自己在JS侧开Web Worker，用SharedArrayBuffer共享输入输出内存，再写一套线程池调度逻辑。且不说SharedArrayBuffer要求页面开启跨源隔离头，单是数据同步、任务分发、结果回收这一层，就比原生线程多出大量开销。

更麻烦的是，WASM的线程池和原生线程池在调度上根本不是一回事。原生调度器知道线程跑在哪个核上，可以尽量维持缓存亲和性；Web Worker里面，浏览器对线程迁移动态控制，你的计算可能这次在这个核、下次就蹦到另一个核，缓存全被冲掉。单看这一点，多线程的收益就要打折扣。

3.2 SIMD能用，但离“全开”还有距离

WASM SIMD是基于128位寄存器的通用向量指令，理论上对标原生平台的SSE和NEON。但原生推理库在x86平台上普遍用AVX-512做深度优化，在ARM上用手工NEON内联做极致调优。WASM这边你没有AVX-512，也没有办法针对某款具体CPU生成specialize的指令序列。

更微妙的是自动向量化。编译器能不能把你写的循环自动变成SIMD版本，取决于内存访问是否连续、依赖关系是否清晰、循环结构是否简单。在原生环境里，经过多年打磨的编译器已经能自动向量化大部分算子循环，而WASM这条链路相对年轻，加上跨平台语义要考虑的边界情况，生成出的SIMD代码往往没有那么激进。

我自己有一个直观感受：某些算子在WASM SIMD能跑到原生六成到八成，但一旦算子依赖复杂或分支多，退化成标量执行的概率就很高。相比之下，原生库里有大量针对具体CPU微架构手工调过的汇编片段，你能跑得赢纯属意外。

4. 引擎与工具链的“隐藏税”：JIT、代码生成、框架适配

4.1 引擎编译策略远没有原生直译

原生编译是一条非常清晰的链路：源代码经过编译器和链接器变成平台机器码，运行前指令已经躺在内存里等CPU取用。WASM不一样，浏览器引擎拿到模块之后，还需要经历自己的编译和优化阶段才能生成机器码。

引擎的JIT编译策略跟前端代码形态高度相关。如果WASM模块里的函数过大、循环嵌套过深，引擎的贯彻落实没那么深，甚至放弃某些激进优化，退回解释器或较低优化的路径。这种回落不是显式的报错，而是“什么都没发生，但速度就是上不去”的幽灵瓶颈。

这里我觉得可以打个比方：原生程序是出门前就把地图整条路线背好，WASM是边开车边看导航，还得随时根据路况换路。正常情况下差别不大，可一旦导航的“路况逻辑”跟你的驾驶习惯不匹配，降速就没商量。

4.2 把原生推理库“整个搬上WASM”的坑

我见过不少团队的第一反应，是把某个开源C++推理框架用WASM工具链直接编一遍，期望得到一个浏览器里能用的推理引擎。这种做法理论上可行，但结果往往一言难尽。

原因是这些框架在原生环境里大量依赖平台特色，比如CPU指令集检测、运行时特化内核、多线程调度加上线程池的负载均衡。编译到WASM之后，这些能力全部退化或消失了。框架还是那个框架，但内里最锋利的部分全被“过筛”挡在外面。

更尴尬的是，直接搬运还会把抽象层的代价原样保留下来。框架为了可扩展性在算子和内存管理上做了一层又一层包装，这些包装在原生环境里靠编译器内联和寄存器分配能吃掉，在WASM里却成为实实在在的函数调用和对象操作开销。看起来你在跑一个“已经编好的推理框架”，实际上是在跑一个把优化内核全丢了、还背着抽象层包装的解释版。

4.3 为WASM专门写算子，才是正路

后来我自己做性能整改时发现，真正能跑出水平的浏览器推理实现，核心算子往往不是直接从原生框架搬运，而是针对WASM指令集和线性内存重新手写的。简化分支、连续访存、显式使用SIMD内建函数，这些代码在WASM下能稳定生成高效机器码。

手写算子听上去工程量很大，实际上你只需要优先处理少数几个热点算子，比如矩阵乘、卷积、逐元素运算、归一化。推理框架里的时间分布极度不均，头部几个算子占掉大半时间，把它们作为重点特化对象就够了。

关键是你要把思路从“把一个原生大框架搬进来”切换成“用WASM适合的方式重写计算核心”。这就像同样是做菜，不能指望微波炉复刻炭火烤炉的全部效果，但完全可以针对几道拿手菜摸索一套稳定的做法。

5. 实测之后才能定位：别把所有锅都扣在WASM头上

5.1 一个典型的性能拆解流程

遇到“WASM推理慢”，我的第一反应是拉起测量，把时间分成几段：JS侧数据处理、数据进入WASM、WASM内算子计算、结果拷出、JS侧后处理。然后分别统计这些阶段的耗时占比。

有个很简单的办法：写一个只拷贝但不跑算子的空推理，拿来跟完整推理对比，差值基本就是计算本身的耗时。再用几个不同大小、不同形状的输入跑一遍，观察耗时是否随数据量线性增长。如果数据量变大数据搬运时间涨得比计算还快，说明瓶颈在搬运而非计算。

下面是一个我实际见过的耗时拆解情况（数据纯虚拟，但比例很有代表性）：

按这个表看，即便把全部计算都优化到零，整体也只能快不到一半。你真正该动手的是数据拷贝和内存布局，而不是抠算子指令。

5.2 最容易忽略的JS侧瓶颈

排查之后经常发现的一个真相是：WASM本身并不慢，慢的是JS侧动不动做类型转换、对象解包、异步等待。比如每层算子在JS里返回一个Promise，上层再await下一次调用，计算流水线就被切成一块块等待，根本没有原生那种连续计算的状态。

还有一类问题是最容易被忽视的，就是数据没落在WASM内存里。你把输入攥在JS的Uint8Array里，WASM那边计算前必须先做一轮导入，输出再做一轮导出。这跟你把文件从一个目录拷到另一个目录再处理是一个道理，中间那次“移动”没有产生任何计算价值，但时间和带宽实打实消耗。

我建议所有输入输出相关的结构都直接定义在SharedArrayBuffer或者WASM内存里，JS侧只保留视图，不要反复做数组复制。

5.3 模型和算子层面的影响远大于引擎本身

模型本身的结构往往比运行时更能决定快慢。一个模型里如果有大量小算子串在一条链上，每次调用都要经过完整的调度、参数校验、内存申请流程，这种模式在原生环境靠函数内联和预分配消化掉一部分，在WASM里则会原样暴露。你要做的第一件事永远是简化计算图，合并相邻逐元素算子，减少“看起来轻实则昂贵”的调用。

量化也是绕不开的话题。原生环境下INT8推理能靠AVX-512的VNNI指令把吞吐拉得很高，而WASM的SIMD没有同等效力的原生INT8乘加指令支持，即使引擎和工具链逐步跟上，落地速度依然落后一个身位。你如果拿一个float模型直接上WASM跑，和原生预量化、预编译过的模型对比，差距会非常大。

我在优化某个模拟项目的时候就吃过这个亏：模型端没做任何精简和量化，却指望WASM端用几十毫秒出结果，结果跑了四百多毫秒，仔细一分析，光算图上那几十次维度重排就吃掉了一大半时间。模型本身的算子设计，比运行时还要重要。

6. 如果想提速，我建议按这个顺序动手

6.1 先做profiling，别拍脑袋

我的建议永远是：不要凭直觉优化，先拿性能分析工具看数据。浏览器自带的Performance面板能记录WASM函数级别的调用耗时，配合performance.now在关键节点打点，基本能画出整条数据流的耗时热力图。

具体做法是把推理过程拆成“预处理、输入进WASM、算子计算、输出出WASM、后处理”五个阶段，每个阶段前后各打一个点。跑几轮取中位数，你马上就知道该往哪里使劲了。很多时候这个步骤一完成，团队里“WASM太慢”的抱怨就消停了一半——因为慢的根本不在你想的那个地方。

6.2 内存和布局优化，收益最大

在所有优化手段里，内存相关改动带来的收益最稳定。核心思路是让推理循环里尽量不存在动态分配和随机访存。

• 初始化阶段一次性分配好所有中间缓存，推理过程只复用这些缓存；
• 张量布局尽量采用连续布局，比如把NCHW改成NHWC这样按像素连续排列的格式；
• 对热点循环做小的手工改动：把多重嵌套循环改成平铺循环，减少索引计算的次数。

我之前在一个图像处理的WASM模块里做过一次类似整改，只做了“消除推理循环里所有临时动态分配”和“把输入数据结构直接落在WASM内存”这两件事，整体耗时降了大约四成。相比之下，后来花大精力优化的几段SIMD代码，带来的收益还不如这两项明显。

6.3 SIMD、线程、JS边界三件事一起上

在前两步做完的基础上，再去碰SIMD和线程。编译时务必开启高级优化和SIMD支持，开启bulk memory和尾调用等现代特性，同时打开跨模块内联优化。很多人在这一步漏了关键参数，编出来的WASM压根没有向量指令，只有自己写SIMD内建函数的部分在跑快路径。

多线程方面，可以先用Web Worker加上SharedArrayBuffer做一个实验性的算子并行，观察是否稳定、是否带来明显提升。有一个很实用的判断标准：如果单线程下某个算子已经占到总耗时一半以上，而且算子本身访存连续、无依赖，那多线程并行大概率有收益。反之，如果瓶颈在数据搬运、分支逻辑、小算子调度，多线程只会把数据竞争和同步问题搅进来。

分享一个最小可用的骨架思路：

// 主线程：创建共享内存，交给 worker const sab = new SharedArrayBuffer(bufferSize); const worker = new Worker('./inference-worker.js'); // 输入输出都直接定义在共享内存上 const inputView = new Float32Array(sab, 0, inputLength); // 填充输入后通知 worker 开始推理，避免 postMessage 拷贝大数组 worker.postMessage({ type: 'run', totalBuffers: 1 });

// inference-worker.js 内 self.onmessage = (e) => { if (e.data.type === 'run') { // 从共享内存里直接读取输入，调用 WASM 模块计算 // 结果直接写回共享内存，再发一个轻量消息通知主线程 self.postMessage({ type: 'done' }); } };

这套方案的关键优势，是数据根本不需要在JS和WASM之间来回拷贝，所有计算都围绕共享内存进行。代价是你要把推理流程的异步协调自己想清楚，多线程就是“自己动手丰衣足食”。

6.4 考虑混合架构，别走极端

如果项目场景真的非常吃性能，我建议别把所有计算都锁死在WASM单条路上。浏览器环境其实还提供了一些“更接近硬件”的路径，比如在某些支持场景下可以把重计算交给GPU，或者用原生服务处理一部分最重的计算，WASM只负责核心关键、不适合外移的部分。

混合架构听上去复杂，但实际落地往往没那么困难。一次典型的做法是：把预处理和后处理留在WASM里，保证数据流简洁和可移植；把最重的矩阵运算交给更合适的计算后端；把调度逻辑放在JS侧。

在做决策前，先想清楚一个基本问题：你的性能瓶颈到底在“算不过来”还是“倒腾不过来”。前者可以尝试并行和指令优化，后者则需要重新设计数据流，把数据尽量“就地”处理掉。WASM推理本可以是一条很顺畅的路，只是路况复杂时，你得知道哪里该减速、哪里该换道、哪里干脆绕行。

我自己这几年测下来，最有用的经验来自一次意外：把模型输入直接从JS端改成在WASM内存里构造数据之后，没有改算子实现，整体时间反而下降了。那次让我彻底明白，“WASM推理跑不快”这个问题，大多数时候不是写在指令里，而是藏在数据怎么进来、内存怎么分配、调度怎么编排这些你看不见的地方。先把这些地方理清楚，快不快就不那么玄学了。