企业官网建设流程全解析

最近团队在推进一个很典型的端侧 AI 项目：把基于 wenet 的流式语音识别模型迁移到昆仑芯平台，用来支撑 vivo 设备上的语音助手、实时转写和录音纪要功能。一边是开源社区里最活跃的 ASR 训练推理框架之一，一边是国产 AI 芯片阵营的重要玩家，很多人以为这只是换一块硬件的事，但真正做下来才会发现，从模型导出、算子适配、量化调优到开源回馈，每一步都藏着一堆讲究。

这篇文章会把整个项目从头到尾拆开来讲，包括我们为什么选昆仑芯而不是继续堆 GPU、wenet 这套开源工具链到底好在哪、模型迁移到 NPU 上的具体优化过程，以及最后怎么把一家手机厂商的技术积累反哺回开源社区。不管你是做语音识别算法、端侧推理，还是关心国产 AI 芯片实际落地效果，都可以从里面找到能直接抄作业的部分。

1. 项目全景：从一颗芯到一条完整的语音链路

1.1 为什么是昆仑芯：不是拍脑袋的选型

语音识别端的部署场景和纯训练场景对芯片的需求完全不同。训练时可以接受高功耗、大显存、强散热，但到了手机或边缘设备上，每一毫瓦功耗都要精打细算。GPU 在云端训练领域依然是霸主，可放到端侧做实时识别，功耗和体积都很难接受。vivo 的语音功能不是一个跑在实验室里的 demo，而是要跑在千万级量产设备上的常驻服务，对功耗、时延、稳定性都有硬指标。我们当时评估了几类方案，最终把目光落在昆仑芯上，核心原因是它在算力、功耗和工具链之间找到一个相对务实的平衡点。

昆仑芯基于自研的 XPU 架构，不是简单地堆通用计算核心，而是围绕神经网络算子的访存和计算模式做了大量硬件设计。像 Conformer 里最耗时的 Attention、FeedForward、LayerNorm、GELU 这类算子，在昆仑芯上都有对应的硬件加速路径。也就是说，wenet 模型的骨干结构不用做伤筋动骨的改动，就有机会跑出不错的性能。这一点比那些只支持 CNN 类算子的 NPU 要省心得多。

另一个决定性因素是端云同栈。vivo 的语音场景不只是本地识别，还有云端增强。如果端侧用昆仑芯，云端继续用 GPU，那就得维护两套模型导出和推理逻辑。昆仑芯在服务器端和终端侧都有产品覆盖，我们可以在同一套算子上做好优化，再同时部署到两端，维护成本能压缩一大截。这个选型背后，既有对算力指标的硬性要求，也有对工程长期维护成本的考量。

1.2 vivo 语音识别场景的真实痛点

在讨论“性能提升”之前，先得说清楚我们到底在解决什么问题。vivo 设备上的语音识别不是一个单一任务，它涵盖了语音助手指令词识别、拨号与发消息时的口语输入法、录音转写、实时通话字幕等多个场景。每个场景对延迟和精度的要求都不同：指令词必须极速响应，最好在说话人说完 300 毫秒内就给出结果；录音转写则可以放宽到几百毫秒的显示延迟，但对专有名词和人名的要求很高。

最折磨人的其实是长尾词的识别。用户的联系人姓名、常用 App 名、方言词汇、中英混说的句子，经常不在通用训练数据里。wenet 支持上下文偏置（Contextual Biasing），可以在推理时动态注入一份热词列表，这正好打在 vivo 场景的痛点上。我们可以在不改动模型参数的情况下，让“小 V”这类指令词和用户通讯录里的名字识别率大幅提升。

另外隐私合规也在推动架构变化。越来越多的语音数据只能在本地处理，不能上传云端。这意味着端侧模型必须自己扛住大部分识别任务，准确率不能比云端差太多。综合这些条件，我们需要的不是一块“性能看起来很猛”的芯片，而是一个能同时满足低延迟、低功耗、支持动态热词、可量化部署的完整方案。昆仑芯和 wenet 的组合，恰好沿着这条路线往前走。

2. wenet 生态：开源框架如何撑起商业化落地

2.1 wenet 的设计哲学：流式非流式一把抓

如果在三年前问一个团队，做语音识别选哪个开源框架，答案多半是 Kaldi 或者 ESPnet。Kaldi 很强，但它的主要产出是传统混合系统的组件，和现在主流的端到端模型之间隔了一层；ESPnet 做研究很方便，可真正要部署到手机和服务器上，还有不少额外工作。wenet 从诞生起就瞄准了一个更加务实的点：一套代码，既出训练模型，又出可部署的推理脚本，并且把流式和非流式统一到一个模型结构里。

wenet 用的 U2/U2++ 结构是一个非常有代表性的设计。它把流式识别所需的 CTC 分支、基于 Attention 的非流式解码分支，以及一个共享的 Encoder 主干绑在一起训练。训练时，Encoder 可以借鉴未来的上下文来学习更好的表征；部署时，通过动态 chunk 机制，让模型的 Attention 只能看到当前时刻之前的一小段上下文，从而实现低延迟流式识别。换句话说，wenet 让同一个模型既能做到离线的高精度识别，也能做到实时的流式输出，这在产品落地时是巨大的便利。

另一个让我很欣赏的点是 wenet 对解码流程的简化。它用 CTC 前缀解码加 Attention Rescoring 的组合方式，既保证了流式场景下可以快速出中间结果，又在最终结果上借助 Attention 做精修。这种工程上的平衡，比单纯追求极致精度或者极致速度都更贴合真实产品需求。

2.2 从训练到部署的完整工具链

wenet 能快速落地，绝不只是因为模型结构选得对，更重要的是它把工程链路做得很完整。从最早的 Kaldi-style 数据准备脚本，到基于 PyTorch 的训练代码，再到导出 ONNX/TorchScript 的流程，以及一个可以直接编译运行的 C++ runtime，wenet 把“研究代码”和“产品代码”之间的距离拉得非常近。我们在做昆仑芯适配时，最明显的感受是：大部分精力不用花在“如何写推理代码”上，而是可以集中在“如何让 NPU 更好地执行这些算子”上。

这里要横向对比一下。Kaldi 虽然也有 nnet3 和 chain 模型，但它的端到端支持相对零散，新的 Conformer 结构往往需要第三方实现；ESPnet 在实验灵活性上很好，可它的 Python 推理链路重，部署到端侧要费不少功夫。wenet 的 C++ runtime 从一开始就考虑了流式解码状态管理、上下文偏置和低资源环境，这让它在手机、嵌入式设备上落地时更加顺理成章。我们之前在 GPU 上用 TensorRT 部署过 wenet 模型，这次迁移到昆仑芯之后发现，模型结构层面的代码基本不用动，替换的只是底层的算子执行引擎。

3. 昆仑芯上跑 wenet：迁移、量化与性能优化实战

3.1 模型转换与算子适配：比想象中复杂

把 wenet 模型从 PyTorch 迁到昆仑芯上，第一步是把模型导出成 ONNX。wenet 官方的导出脚本做得比较完善，支持动态时间维度和动态 batch，但在实际使用中还是有不少细节需要调整。我们踩到的第一个坑是：ONNX 导出时如果不把序列长度相关的维度明确标记为动态维度，昆仑芯的模型转换工具会把它当作静态图来处理，一旦输入音频长度比训练时短，模型就直接跑挂。

所以我的建议是，不要直接拿官方导出脚本的默认参数就跑，先花十分钟打开 Netron 看一眼导出的 ONNX 图。重点检查三个地方：一是 chunk 相关的 loop 是否被正确展开；二是 attention 里的 reshape/transpose 是否保持了可追踪的维度；三是 softmax 算子的 axis 是否和昆仑芯后端期望的一致。很多问题在模型可视化阶段就能提前暴露。

算子适配层面，最耗时间的往往是 LayerNorm 和 GELU。LayerNorm 在训练时很容易实现，但部署到 NPU 上，有的芯片只提供逐元素的乘加指令，不提供规约和求平方根的硬件算子。昆仑芯的 SDK 里其实已经封装了不少融合算子，但如果你用的 wenet 版本比较新，模型结构里有新的子模块，就得自己写算子映射规则。我们的做法是优先把 LayerNorm 和残差连接融合成一个算子，再把 GELU 也合并到前面的 Linear 输出里，这样能明显减少 NPU 和 CPU 之间的往返次数。

3.2 量化策略：既要提速又不能掉点

模型迁移的另一个重头戏是量化。语音识别模型对精度极其敏感，尤其是流式场景下的一句完整句子，中间出一个错别字都会影响用户体验。我们直接在浮点模型上做后训练量化，效果并不理想，词错误率上升了约 0.5 个百分点，在噪杂环境中甚至会到 1 个百分点以上。后来换成混合精度量化方案，才在性能和精度之间找到平衡点。

具体做法是：先对模型做算子级 profiling，找出哪些算子占了超过 80% 的执行时间，然后把它们标记为 INT8量化候选；对于 LayerNorm、Softmax、GELU 这类对激活值动态范围非常敏感或者存在指数运算的算子，强制保留 FP16。这样做下来，MatMul 和部分 Linear 层用 INT8，其余关键路径用 FP16，最终的结果是 RTF 下降明显，词错误率几乎和 FP32 持平。

校准集的选择也是被很多人忽略的地方。单纯用几十条干净录音做量化校准，看起来精度没问题，一上真实场景就露馅。我们准备了大约 2000 条覆盖多个 SNR 区间、不同口音和不同背景噪声的音频，再附上对应的热词列表样本。这样量化模型时，激活值分布会更接近真实部署环境，INT8 的鲁棒性会好很多。可以说，量化不是简单的工具调用，而是在收集“代表真实世界的输入分布”。

3.3 流式推理的调度优化

模型落到 NPU 上之后，性能瓶颈往往不在峰值算力，而在数据搬运和调度策略。语音信号是时间序列，流式解码天然是串行的：每来一个 chunk，就要做一次 Encoder 前向。如果每个 chunk 都让 NPU 等待 CPU 完成特征提取，那即便 NPU 的算子再快，整体时延也不会理想。

我们在实际工程里采用了三级流水线：第一级 CPU 负责音频采集和 fbank 特征提取，第二级把特征拷贝到 NPU 的输入缓存，第三级由 NPU 执行 Encoder 计算并将输出直接传递到 CTC 解码。通过把这三个阶段重叠起来，一个 chunk 的计算延迟可以隐藏在下一个 chunk 的特征提取时间里。实测数据是：在 8 核 ARM 处理器上，纯 CPU 跑 FP32 wenet 模型的实时率大概在 0.3 左右，而昆仑芯混合精度方案的实时率可以压到 0.06 附近，首字延迟也从原来的 230 毫秒左右降到了 190 毫秒上下。

要注意的是，流式解码的“首字延迟”容易被人为优化得很漂亮，但如果后续每帧的延迟抖动过大，体验依然是灾难。所以我们又做了一个小改进：把 Encoder 的中间层输出缓存到一块专门的内存池里，避免每次推理都重新申请和释放内存。这个改动对内存分配的减少非常明显，也让延迟曲线变得平滑得多。

参数上，我们选过 chunk size 16 和 chunk size 24 两套配置。chunk size 16 的延迟更低，但准确率略有下降；chunk size 24 在延迟和精度之间更均衡。最后在面向量产时选择了 24，同时通过左侧上下文扩展到 8 帧来弥补流式信息不足的问题。这种参数调优没有绝对正确的答案，完全依赖具体产品对延迟和精度的容忍度。

4. 端云协同：让准确率和时延同时在线

4.1 端侧与云侧的任务分工

单靠端侧模型，不可能在所有场景都做到完美。手机上有时候要处理的内容很复杂，比如一段混乱的多人会议录音，端侧模型受算力和内存限制，很难支撑超高词表和大上下文建模。我们的方案是让端侧和云侧各管一段：唤醒词、短指令、涉及个人隐私的内容、没有网络时的离线输入法，全部由端侧模型完成；长录音转写、需要理解语义的复杂指令、多说话人场景，则走云端大模型。

这里有一个特别重要的细节：两个环节用的是同一个 wenet 模型家族。端侧是流式版 U2++，云侧是更大的非流式 Conformer。它们在结构上同源，在输出接口上也保持对齐，所以端侧在结果置信度比较低时，可以把中间特征或者部分文本直接抛给云端做二次精修，而不需要重新拉取一整段音频。这种设计比传统的“端侧小模型 + 云侧大模型”做法更高效，因为端侧已经在本地消费了音频，云侧只需要处理候选片段。

路由策略上，我们不是简单地设定一个置信度阈值就决定上云。因为不同用户说话习惯差异太大，固定阈值会误判。后来改成结合 CTC 平均概率、语言模型打分和热词命中率做综合判断。只有三者都不满意时，才触发云端兜底。这项改造让云端请求量下降了接近四成，用户不会因为网络波动频繁看到转写停滞。

4.2 服务端基于昆仑芯的弹性收益

云侧推理过去是 GPU 的天下，但 GPU 在 ASR 这种高并发、短序列、低延迟的场景里，其实浪费很严重。语音识别单个请求的模型计算量不大，但请求数量多、时延要求高，GPU 的并行优势并不能完全发挥出来，反而带来了高昂的设备和功耗成本。我们把云侧 wenet 模型迁到基于昆仑芯的服务器之后，做了一组对比测试：在相同并发下，昆仑芯方案的单路 RTF 比原来用 GPU 的方案下降了约 25%，单台机器的功耗则降低了约 35%。

这个收益来自几个层面积累。一是昆仑芯的 NPU 调度更适合我们这种高频短任务，没有 GPU 那套庞大的上下文切换开销；二是 C++ runtime 层面的动态 batch 优化，把多个并发请求的 encoder 推理合并到同一次 NPU 调用里，大幅提升了芯片利用率；三是精确的缓存复用，因为很多请求的模型权重是一样的，权重不再重复从内存搬运。

在实际运营中，弹性扩容也比以前舒服很多。之前 GPU 服务器的采购周期长、功耗预算高，扩容一次要协调很多部门。昆仑芯方案在同样的机架空间里塞进了更多处理单元，扩容的摩擦小了很多。如果团队里有人要做服务器选型，建议不要看纸面峰值算力，直接拿自家真实流量场景跑一轮压测，重点看 P95 延迟下的吞吐量，这个数据最真实。

5. 共建开源生态：从使用者到贡献者

5.1 vivo 在 wenet 社区的落地贡献

一家公司用开源项目，最开始一定是索取为主：下载代码、训练模型、部署上线。但如果仅仅是索取，很多适配工作就只能停留在公司内部，换一个硬件平台、换一个模型版本，又得重做一遍。vivo 在昆仑芯和 wenet 的适配过程中，选择把一部分成果反哺回社区，这也是项目名里“携手共建 wenet 开源生态”的实际含义。

我们贡献的内容包括三类：第一类是昆仑芯后端的算子适配层，让 wenet 的 C++ runtime 可以直接调用昆仑芯的推理引擎；第二类是量化工具链的辅助脚本，覆盖了从 FP32 导出到混合精度量化、再到精度对比的完整流程；第三类是真实场景的测试集样例，脱敏之后包含指令词、联系人名单、中英混说和部分带噪语音片段，方便社区做端侧模型的评测。三个贡献里有不少代码改动非常琐碎，但它在社区的带动作用很大，会让更多同行看到“国产芯片 + wenet”是可以跑通的。

在做开源贡献时，还要考虑维护成本。代码提上去只是开始，后续的 issue 回复、新版本适配、回归测试都是长期工作。vivo 的做法是内部先成立一个小型虚拟团队，成员包括 ASR 算法工程师、嵌入式优化工程师和 DevOps，每个版本都要做上游跟踪。针对 wenet 的新 release，我们会在发布后两周内跑完内部回归，并把发现的问题反馈给社区，形成一个良性的“使用—反馈—改进”循环。

5.2 开源共建的现实收益与组织方式

开源不是做慈善，企业投入人力去共建生态，最终要让业务受益。对 vivo 来说，最直接的收益是上游优先。我们如果只维护一个内部 fork，每次 wenet 官方更新都要做一遍复杂的代码合并；而把适配层贡献到上游以后，官方版本的演进会自动带上昆仑芯相关的兼容逻辑，我们内部的维护成本反而降了下去。

组织方式上，我建议不要一上来就直接改 wenet 主分支，而是先做成插件或者独立 backend 集成。wenet 的 runtime 本来就是模块化的，扩一个昆仑芯 inference backend 并不难。稳重推进的顺序应该是先在内部打一个可复现的基线，再把适配代码抽成补丁提交给社区，经过 review 合入后，再更新内部基线。这样既不会破坏社区既有用户的稳定性，也不会让内部代码偏离主线太远。

另一个容易被忽略的点是文档。开源社区最稀缺的不是代码，而是“别人踩坑后写下的经验”。我们为 wenet 新增了昆仑芯部署指南和混合精度量化教程之后，GitHub 上的相关 issue 明显少了，不少用户在讨论区直接说照着文档做一次就通了。这就是共建的正向循环：文档节省了后来者的时间，也让维护者从重复答疑中解脱出来。

6. 踩坑实录与排查手册

6.1 模型转换期的高频问题

这段内容也许是整篇文章里最值得直接保存的部分。我们再做 ONNX 导出时，第一版模型存在很多动态维度相关的警告，当时没在意，结果跑到昆仑芯转换工具时直接报错。细查才发现，是 wenet 导出的三个输入节点（chunk、offset、attention mask）没有统一设置动态轴。解决办法是把 batch 和 time 两个维度都标记为 symbolic，并且保证和 runtime 调用时传入的 shape 严格一致。

LayerNorm 量化不稳定的问题也出现过很多次。量化校准工具默认把 LayerNorm 归到量化层里，结果模型一上真实数据，特定说话人的声音变大一点，识别率就掉得厉害。后来我们在量化配置里显式指定敏感算子的精度为 FP16，问题立刻缓解。这类问题的排查思路是：先跑固定测试集看哪条句子出错，再用分模块输出对比，逐层逼近到底哪个算子在浮点和量化版本之间差异最大。

6.2 性能优化中的隐蔽瓶颈

在 3.3 节讲过数据搬运的问题，这里展开说一个非常隐蔽的瓶颈。我们最初做性能 profiling 时发现，NPU 的峰值利用率只有 30% 左右，RTF 已经压得很低，但总延迟就是降不下去。后来在算子上加时间戳，发现绝大多数时间花在 CPU 端把 fbank 特征从 Mat 容器拷贝到 NPU 输入 Tensor，再从 NPU 输出 Tensor 拷回 CTC 解码器。两个拷贝操作占了整体延迟的一半。

解决方案是用内存池加双缓冲。预先分配两块 NPU 可访问的内存，一块用于当前 chunk 的计算，另一块用于下一 chunk 的数据填充。等当前 chunk 算完，两块内存角色互换。这有点像一个简单的生产者—消费者模型，把拷贝延迟从关键路径上彻底移除。这类优化在 GPU 上不太明显，因为 PCIe 带宽大、拷贝延迟低；但在端侧 NPU 上，总线带宽有限，内存池和双缓冲就是救命稻草。

6.3 典型问题速查表

把这段时间遇到的典型问题整理成一张表，方便后来人按图索骥。

这张表里的每一条都是我们在实际项目中撞到南墙之后才总结出来的。尤其是内存复用这一条，如果你的部署环境资源紧张，建议尽早把这个机制设计进去，不要等到上线前再优化。

7. 最后分享一点实际项目体会

这个项目做下来，我最深的一个感受是：端侧 AI 落地成功与否，关键往往不在芯片的峰值算力，也不在模型的论文指标，而在工具链完整度和优化者的耐心。昆仑芯的硬件底子并不差，但真正让它跑出效果的是我们花了大量时间做算子适配、量化校准和流水线调度。开源生态也一样，wenet 本来就是一个好框架，但只有越来越多的企业用户愿意把适配经验反哺回社区，它才会在一代代版本演进中变得更通用、更强大。

如果现在有人想复制这条路线，我建议一开始就建立一套自动化的精度回归脚本，每次调整量化配置或驱动版本后，能快速回答“性能提升多少、精度掉没掉”这两个问题。另外要提前想好端云协同的接口，不要只盯着端侧，毕竟语音助手类产品的完整体验往往是两端一起撑起来的。最后，多给开源社区写清晰的文档，你帮助过的那些人，未来很可能会成为帮你提 issue 和 fix bug 的伙伴。