企业官网建设流程全解析

语音识别圈子里，wenet已经是很多团队做端到端ASR时的首选开源工具包；芯片这一侧，昆仑芯这两年也随着AI推理需求增长频繁出现在各类部署场景中。这次昆仑芯与vivo围绕语音识别做的合作，把「语音识别、wenet、开源生态」这三个关键词串在了同一条链路上：vivo需要可靠、低成本、自可控的自建ASR服务，昆仑芯需要证明芯片在真实业务里的效果和性能，wenet则恰好承担了“模型训练、解码流程标准化”的公共底座角色。作为一个常年和ASR部署打交道的人，这个组合很值得拆开研究。

这篇内容不从内部消息出发，而是从一个部署工程师的视角，把方案背后的技术链路完整拆一遍：为什么是wenet、昆仑芯适配的难点在哪、vivo这类业务方真正在解决什么问题，以及开源生态在中间起了什么作用。适合正在做语音识别落地的算法工程师、推理部署同学，还有关心AI芯片选型的人。读完之后，你会对一个开源ASR模型怎么跑上一块新芯片这件事有完整认知，也能避开一些常见的坑。

1. 为什么组合选了wenet和昆仑芯

1.1 wenet在工业级ASR里的位置

做语音识别的人很少不知道wenet。这个开源项目提供了一整套工业级端到端ASR方案：特征提取、数据准备、模型训练、流式/非流式解码，全部在同一个框架里串起来。模型结构上，wenet默认走的是U2/U2++加Conformer路线，这意味着它同时具备CTC分支和Attention分支，训练时联合优化，解码时先走CTC快速出结果，再用Attention decoder做重打分，把准确率往上拉。

很多团队选wenet不单是因为它开源，而是因为它的“生产可用”属性。数据格式怎么处理、模型怎么训练、怎么做流式识别，社区里都有成熟脚本，踩坑经验也足够多。尤其中文场景，WenetSpeech数据集就是wenet社区放出来的大规模中文语音数据，很多工业模型直接基于它训练或微调。可以说，在中文端到端ASR里，wenet已经成了一个事实标准。

与RNN-T或者纯CTC方案相比，wenet的U2++结构在实际落地时更灵活。同一个模型既能做流式识别，也能做离线整句识别，只是解码模式不同。对于vivo这种既要做实时对话、又要做离线转写的业务场景，这种“一套模型、两种用法”的特性非常关键。

1.2 昆仑芯能带来什么

昆仑芯是百度自研的AI芯片，核心是XPU架构。与通用GPU不同，它针对深度学习推理场景做了大量指令级优化，在FP32、FP16、INT8这几种精度上都有专门的计算路径设计。对于语音识别这类“模型不大但并发很高”的业务负载，昆仑芯这类专用推理卡比通用CPU合适得多。

我习惯用一个类比：CPU像家用车，什么都能拉一点但满载爬坡费劲；AI推理芯片像卡车，结构固定、流水线作业，在特定模型形状下能持续跑出高吞吐。ASR的模型结构一旦定了，比如Conformer、流式Transformer，计算模式就相对固定，这正是专用芯片擅长的场景。

昆仑芯比较务实的一点是兼容性。它和PaddlePaddle生态贴合得很深，模型从Paddle导出后转换很顺，同时也能吃ONNX格式的模型，这意味PyTorch训练的wenet模型，可以通过ONNX中转导入到昆仑芯工具链。另外昆仑芯也提供量化工具和图优化能力，这是做大规模部署时最需要的东西。

1.3 vivo的真实需求：可靠可控的自建ASR

vivo的需求要从语音助手Jovi说起。语音识别是整个助手链路的第一环，用户说一句话，先变成文字，后面才能做意图识别、语义理解、指令执行。如果识别错了，后面全错。所以准确率是刚需。同时手机端语音交互讲究低延迟，用户说完一句话，系统应该在几百毫秒内给出反馈，这对推理时延的约束非常严格。

为什么不自研芯片，也不直接用第三方云ASR服务？答案在于可控性。手机厂商的用户数据极其敏感，语音数据更是如此，把音频送到外部云服务过一遍，在合规和信任层面都有问题。自建ASR服务，模型、数据、部署全部掌握在自己手里，是更稳妥的路线。但自建也不意味着什么都要自己造，尤其模型层面，直接用开源方案是明智选择。

用开源模型加专用芯片的组合，对vivo来说性价比很突出。训练侧基于wenet，不重复造轮子；推理侧用昆仑芯，比通用GPU成本低而且供应更可控。这就是vivo、昆仑芯、wenet三方能够走到一起的根本原因：各取所需，而且技术栈是兼容的。

2. 整体方案设计：从训练框架到推理芯片的完整链路

2.1 标准链路长什么样

把wenet模型实际跑上昆仑芯，链路可以拆成四段。第一段是训练侧，用PyTorch在GPU上完成Conformer模型训练，导出模型权重；第二段是格式转换，把权重转成ONNX这类统一中间表示；第三段是在昆仑芯工具链里做模型转换、图优化、INT8量化，生成适合XPU加载的推理模型；第四段是部署，把推理模型封装成服务，接上音频输入和解码输出。

链路本身不复杂，复杂的是每一步都可能埋雷。我见过最耗时的坑不在模型训练，而在特征处理不一致。比如训练时用了80维fbank加CMVN全局归一化，部署时特征提取脚本版本不一样，CMVN统计量没加载进去，结果模型的识别率直接掉到没法看。这类问题不会在模型转换阶段暴露，只有做端到端一致性测试时才会发现。

所以我对这套链路的第一步建议是：先别管性能和量化，先把FP32推理在昆仑芯上完整跑通，用同一段音频对比PyTorch输出和XPU输出的最大误差。确认误差在合理范围内，再继续往下做优化。这个习惯帮我避免过无数次“调了半天发现是前置流程坏了”的尴尬。

2.2 算子兼容性才是第一道坎

Conformer模型的计算图并不复杂，但细节相当多。Conv2D子采样、多头自注意力、FFN、SiLU激活、LayerNorm、相对位置编码、attention mask，这些都是常规深度学习算子，在PyTorch里跑一点问题没有。但转到ONNX再进昆仑芯工具链后，会遇到两种情况：一是某些算子对新版本模型支持还不完整，二是某些算子虽然在ONNX里有标准定义，但当前芯片的kernel实现性能不理想。

典型的例子是相对位置编码。Conformer里使用的相对位置编码，PyTorch实现时通常是一段自定义逻辑，导成ONNX后可能变成一串比较复杂的切片和广播操作，计算效率很差。更麻烦的是流式模型里的cache更新操作，这些在训练代码里是普通张量操作，导出后会在图中引入跨step的状态依赖，普通推理引擎优化起来很费劲。

应对这种问题，通常有两种思路。一是把复杂算子改写成标准算子组合，用更细粒度但语义等价的张量操作替代；二是利用芯片厂商提供的plugin机制，写一个自定义kernel，把整段逻辑合并成一个高性能算子。前者通用性好，后者性能上限高。我的建议是先用标准算子跑通，确认正确性，再针对热点算子做plugin优化，不要一拍脑袋直接写插件。

2.3 流式与非流式：两套模型的差异化处理

语音助手场景对实时性容忍度很低。用户说完“今天天气怎么样”，系统不能等他完全停顿才开始识别，否则体感就是迟钝。所以线上服务一定要有流式识别能力，边说边出结果。wenet对流式的支持方式是chunk-based自注意力，每次只看一小段音频，同时缓存历史信息用于后续计算。这种机制在芯片侧会放大一个问题：推理不能简单按整段音频一次跑完，而要按照时间步反复调用模型，并且每次都要带上历史状态。

非流式模型就好处理得多。整段音频一次性送进去，Attention可以看到全局上下文，准确率更高，但时延也更高。实际产品里，很多团队选择同时部署两套模型：流式模型负责实时展示中间结果，等用户说完之后，再用非流式模型对整句话做一次精识别，用精识别结果作为最终输出。vivo的语音助手大概率也会走类似路线。

从芯片选型角度看，流式模型的推理模式对运行时提出了额外要求。一是状态管理，每路并发请求都要维护自己的历史cache；二是动态shape，每个时间步输入的chunk长度相对固定，但历史信息和batch大小会动态变化。部署时如果推理引擎对动态shape支持不好，性能会大打折扣。这块在选型阶段就应该重点考察，而不是等模型转换完再发现。

3. 核心实操：wenet模型在昆仑芯上的部署全流程

3.1 环境准备与版本匹配

在昆仑芯上跑wenet，第一步是环境准备。建议直接用官方提供的容器镜像，里面通常已经装好了芯片驱动、推理运行时和配套的模型转换工具。基于镜像再单独装PyTorch和wenet代码库，这样训练、转换、推理三块环境都隔离清楚，不容易互相污染。

版本匹配是这阶段最容易被忽略的问题。PyTorch导出ONNX时用的opset版本，必须和昆仑芯工具链支持的版本对应。opset太新，工具链不认；opset太旧，导出回来的图可能用了老算子，性能不好。另外Python版本也会影响SDK的安装兼容性，建议先看官方文档的版本矩阵，别一上来就装最新版。

准备work space时，我习惯新建一个项目目录，分成train、export、quant、deploy四个子目录。train放wenet训练脚本和checkpoint；export放导出的ONNX和转换脚本；quant放校准集和量化配置；deploy放服务代码和Dockerfile。这套目录结构很土，但多人协作时能省掉大量“你这个文件在哪”的沟通成本。

3.2 模型导出与自定义算子处理

wenet本身有导出相关脚本，但不同版本差异较大，别指望开箱即用。导出时最关键的是配置动态维度，输入特征的shape通常是batch、time、feature_dim，其中time维度一定要设为动态，否则模型只能处理固定长度音频，实际业务根本没法用。

很多同学导出ONNX时报错，基本都出在自定义算子上。比如Conformer的相对位置编码，导出的过程中可能涉及多个切片、拼接操作，有些引擎解析不了。我的处理方法是先打印完整计算图，找出所有不是标准ONNX算子的节点，逐个判断能不能用标准算子重写。可以重写的尽量重写，不能重写的记录接口和输入输出形状，后续在推理引擎里用自定义算子补上。

导出之后千万别急着转量化，先做一致性验证。取一段3到5秒的真实音频，提取好fbank特征，分别在PyTorch和昆仑芯的FP32推理环境里跑一遍，比较logits或者CTC输出的最大绝对误差。一般误差在1e-3量级以内算正常。如果误差很大，先怀疑预处理差异，再怀疑算子实现偏差，这个排查顺序能省很多时间。

3.3 INT8量化校准与精度保护

ASR业务请求量很大，纯FP32推理虽然准确率最高，但吞吐和成本都不理想。量化到INT8通常能让推理吞吐提升一到两倍，代价是精度可能掉点。语音识别这类序列输出任务对量化其实比较敏感，尤其Attention结构里的softmax和LayerNorm，稍不注意就掉两个百分点CER。

INT8量化的核心不是调参数，而是校准集选得对不对。很多人图省事，从开源数据集里抽几百条干净语音做校准，结果模型上线后遇到打电话、车内噪声、方言口音就崩。校准集必须覆盖真实业务场景，要有不同信噪比、不同说话人、不同手机录音风格，数量上建议至少500到1000条。

校准算法上，经验值是优先用百分位法，比如把激活值分布放到99.99%的百分位再截断，比简单min/max效果更稳。LayerNorm和最后的输出层建议保留FP16甚至FP32，这两个位置对数值精度极其敏感，全量INT8往往会掉点。量化之后一定要跑一遍开发集对比CER，如果掉点在可接受范围内再上线，掉点明显就考虑混合精度或者做量化感知训练。这块没有捷径，只能一遍遍试。

3.4 推理服务化与性能评估

模型转换好之后，要封装成推理服务。接口层面常见的是gRPC或者HTTP，音频上传后按流式或非流式模式处理，返回识别文本。服务内部核心逻辑类似下边的伪代码，具体接口名称以你们SDK版本为准：

# 以昆仑芯runtime常见接口为例，具体API以随SDK发布的文档为准 engine = kunlun_runtime.Engine() model = engine.load("conformer_int8.onnx", precision="int8") # 创建session时指定time维度动态范围，比如最长支持20秒音频 session = model.create_session(dynamic={"time": [1, 5120]}) # feat为提取好的fbank特征，shape为[batch, time, 80] result = session.run({"fbank": feat}) # 取CTC输出和attention输出做后续解码 ctc_logits = result["ctc_logits"]

性能评估先看RTF，也就是推理耗时除以音频时长。1秒音频如果推理耗时小于0.1秒，RTF就是0.1，说明可以做到实时识别且CPU占用有富余。语音助手场景通常要求RTF低于0.1，最好能到0.05以下。还要看P99延迟和并发吞吐，单条平均延迟好看没用，高峰期并发一上来就露馅。

性能调优按照这个顺序来：先把单实例单请求调通，记录FP32和INT8的RTF差异；然后开动态batching，把同一时刻到达的多个短请求合并成一次推理；再考虑CPU和芯片的流水线重叠，特征提取放CPU，模型推理放XPU，两边异步执行。最后才是多实例多卡扩展，应对更大并发。

提示：性能压测和单条测试是完全不同的两件事。很多人拿单条循环测试当并发压测，报告写得很漂亮，上线就被流量打爆。正确做法是用压测工具同时发送多路请求，统计P99延迟和吞吐上限，而不是只看平均RTF。

4. 问题排查实录：我踩过的坑和排查思路

4.1 常见问题速查表

做ASR部署最怕问题没头绪。按我自己的经验，把高频问题整理成一张速查表，排查时先对照表格缩小范围。

4.2 三个实战复盘

第一个实战是INT8量化掉点。第一次用wenet跑业务模型时，量化出来比FP32掉了两个多百分点CER，几乎等于白做。后来排查发现校准集用的是开源开源集里的安静环境录音，但业务音频里有大量地铁、马路和音乐场景。之后我把校准集换成2000条来自真实业务的音频，包含不同噪声和录音设备，量化掉点才缩回到可接受范围。这个教训让我后面每次做量化，第一件事就是先问“校准集能不能反应线上分布”。

第二个实战是流式模型状态错乱。当时用的是流式Conformer，单独测每一帧都没问题，但连续识别时发现从第二句开始结果错得离谱。排查到最后是cache更新逻辑问题：服务里为了省显存，多路请求共用了一份状态缓存，导致A用户的音频特征被B用户的历史状态污染。改成每路请求独立状态隔离后，问题立刻消失。这个案例说明流式ASR服务里，状态管理是一个容易被忽视但极其关键的设计点。

第三个实战是性能瓶颈不在芯片。有一阵子RTF始终在0.15左右徘徊，怎么调都降不动。后来用profiling工具一看，发现一半时间花在CPU上的fbank特征提取，而且特征数据拷贝到XPU是同步的，模型等着特征数据。把特征提取放到独立线程池，预处理和推理做成异步流水线，RTF直接降到0.08以下。所以说性能优化要整个系统一起看，有些瓶颈根本不在你想的那个位置。

4.3 性能调优心得

按照投入产出比排序，我最推荐先做计算图优化。模型转换时打开图优化选项，让工具链自动做算子融合和冗余消除，这条零成本收益往往相当可观。第二是搞动态batching，语音请求普遍很短，一条一条跑的话芯片利用率很低，把短请求合并成一个batch推理，吞吐能成倍提升。第三才是手写自定义kernel或调整底层算子实现。

过程里一定要记录基线。我在每个项目开始前，都会先把原始PyTorch模型在CPU上用固定测试集跑一遍，记下CER和RTF，这个基线后面所有优化都要跟它对比。如果哪天芯片侧模型输出突然变差，拿基线一比就能快速锁定是模型转换问题还是前后处理改动，真的省下无数排查时间。

5. 开源生态共建：芯片、模型、场景三方共赢

5.1 昆仑芯参与wenet建设的具体形式

芯片厂商做开源生态，最忌讳空喊口号。昆仑芯在wenet上的共建，从公开信息能看到的动作集中在几个方面。一是提供适配层代码，比如wenet模型导出到ONNX的示例脚本、转昆仑芯推理模型的教程、Docker镜像，这类东西让用户照着操作就能跑通；二是算子补齐，把Conformer、流式Attention等ASR场景常用结构里的热点算子用XPU原语实现并合入参考代码；三是发布benchmark验证脚本，告诉大家什么样的模型在什么配置下能达到什么性能水平。

这些动作本质上都是在降低用户的使用门槛。对ASR开发者来说，不需要了解XPU的底层指令细节，也不需要从头写算子，只需要把官方示例替换成自己的数据和模型权重，就能完成部署。这才是“共建开源生态”落到实处：让每个后来者都能站在已有成果上继续往前做，而不是每次都从零开始。

5.2 vivo、昆仑芯、wenet社区的协作闭环

这个合作里，vivo的角色不是简单的芯片采购方。语音助手是真实业务，Jovi每天要处理大量用户的真实语音，这本身就构成了一个高价值的验证场。vivo在合规前提下把业务中遇到的口音、噪声、长尾表达反馈到模型中，帮助wenet社区完善数据覆盖；昆仑芯也借助vivo的业务负载，反过来优化芯片在ASR场景的算子实现和性能策略。

这个闭环的三方收益很清晰。vivo拿到的是可靠、可用而且成本可控的ASR服务，模型迭代和数据处理都掌握在自己手里；昆仑芯拿到的是真实场景的验证机会，芯片在产业界的口碑就是这样一点点积累起来的；wenet社区收获的是模型在更多业务场景的落地数据和反馈，持续增强开源项目的生命力。

需要说明的是，芯片和模型不像应用代码，文档再多也会有各种版本细节问题。这类合作的顺利推进，很大程度上依赖wenet社区开放的Issue和PR机制。使用者遇到算子缺失或者性能瓶颈，可以直接提问题、发PR，社区维护者和芯片厂商的开发团队同步跟进，这种透明度是真金白银换不来的。

5.3 给同行的建议

如果你的公司也想自建ASR，我的建议是先从开源方案起步。用wenet加开源数据集跑通一个小模型，部署到目标硬件上验证效果，再根据业务数据去做微调和定制。千万不要一开始就投入大量资源自研模型结构，绝大多数场景用成熟方案加针对性优化，效果反而更好，成本低得多。

如果你是做芯片或者推理引擎的同学，多关注模型结构层面的演进。Conformer之后，新一代流式模型、LLM接入的语音助手，都会不断引入新算子。芯片的软件栈如果不能紧跟社区变化，硬件再强也发挥不出来。把更多精力放在动态shape、状态缓存、量化兼容这些真问题上，比单纯堆算力更有价值。

如果你是算法工程师，我的劝告是别只会训练模型。抽点时间了解推理引擎、算子调度、校准数据，这些知识不是让你一个人干所有活，而是让你和部署团队沟通时能说出准确的需求，而不是只说“模型很准，跑不动就是你们的问题”。

说点我的个人体会

语音识别的效果和性能，从来不是某一个单点的功劳。模型结构定好了，需要芯片把算子跑快；芯片再快，也需要特征前端不拖后腿；所有这些做对了，还需要真实业务的数据来验证。这次昆仑芯与vivo在wenet上的合作，本质上就是把算法、硬件、场景三者拧成一股绳，这种系统性优化的思路，比任何单点突破都有参考价值。

最后分享一个我自己用了很久的小技巧：拿到任何新芯片，先不要急着把整套业务迁移过去。先跑通一个最小模型，比如wenet里的小Conformer，用同一份测试集做基线，把FP32、INT8、混合精度的效果和性能全部记录清楚。这个基线就是之后所有优化的对照线，有了它，任何一个环节出了问题，都能快速定位。这条习惯帮我在多个项目里少加了无数个班，也建议你把它用起来。