WeKws C++ 运行时源码解析：ONNX Runtime 流式推理的 cache 机制揭秘
WeKws C 运行时源码解析ONNX Runtime 流式推理的 cache 机制揭秘【免费下载链接】wekwsProduction First and Production Ready End-to-End Keyword Spotting Toolkit项目地址: https://gitcode.com/gh_mirrors/we/wekwsWeKws 是一个生产级、端到端的关键词唤醒Keyword Spotting工具包它的 C 运行时基于 ONNX Runtime 实现了真正的流式推理。本文将从源码层面揭秘 WeKws 中最核心也最精妙的设计——cache 机制它如何让时序模型记住过去、避免整段重复计算从而在手机、树莓派等边缘设备上实现毫秒级唤醒响应。为什么流式推理离不开 cache 机制关键词唤醒是一个典型的边听边认场景麦克风源源不断送来音频系统必须边接收、边出结果而不是等录音结束再统一识别。WeKws 的骨干网络TCN、FSMN底层是因果卷积——卷积核只能看到当前及之前的帧看不到未来。这带来一个难题卷积核有一定宽度感受野计算当前帧的输出时需要用到它前面若干帧的数据。如果每来一帧都从头重算整段音频计算量会随时间线性膨胀在手机、树莓派上根本无法实时运行。cache 机制正是为此而生把历史上下文打包成一小块缓存随每一帧输入送入模型模型算完后把新的缓存再交还给你。这样每次推理只处理增量数据计算量恒定完美适配流式场景。方案计算量延迟内存整段重算随音频长度增长高高cache 增量推理恒定极低极低KB 级cache 机制全景图训练、导出、运行时的完整链路要理解运行时代码先看懂 cache 从哪来。它是一条贯穿训练 → 导出 → 部署的完整链路训练侧TCN 的每个卷积块都会计算自己的历史宽度padding (kernel_size - 1) * dilation所有层累加得到模型总的 cache 长度代码在 tcn.py 中可见导出侧export_onnx.py导出模型时把cache_dim隐藏维度和cache_len总 padding 长度作为自定义元数据写入 ONNX 文件导出逻辑见 export_onnx.py运行时侧C 程序加载模型后直接从元数据中读出这两个数值动态分配 cache 缓冲区。也就是说运行时不需要硬编码任何缓存尺寸模型自己告诉运行时该开多大的缓存换模型也无需改代码非常优雅。源码解析KeywordSpotting 类如何管理 cache核心实现位于 keyword_spotting.ccAndroid、ONNX Runtime、树莓派各目录下的版本完全一致对应的头文件是 keyword_spotting.h。整个类的状态只有两块Ort::Value cache_ort_; // 交给 ONNX Runtime 的缓存张量 std::vectorfloat cache_; // 缓存背后的原始内存构造时从元数据读取 cache 尺寸构造函数加载模型后立即通过GetModelMetadata()读取cache_dim和cache_len打印出来并调用Reset()完成初始化。Reset()一键清空缓存void KeywordSpotting::Reset() { cache_.resize(cache_dim_ * cache_len_, 0.0); // 全零填充 const int64_t cache_shape[] {1, cache_dim_, cache_len_}; cache_ort_ Ort::Value::CreateTensorfloat(...); }每次检测到关键词后必须调用Reset()把历史上下文清零相当于告诉模型上一轮会话结束了重新开始听。注意缓存形状是(1, D, C)与模型训练时的 cache 张量完全对应。Forward()流式推理的四步舞曲Forward()是每次推理的入口接收一小段帧特征输出各时间步的唤醒概率。整个流程只有四步准备输入把本次的帧特征feats拼成一维向量封装成 ONNX 张量shape 为(1, num_frames, feature_dim)带上缓存一起推理把特征张量和当前的cache_ort_一起作为输入调用session_-Run()得到两个输出——output概率和r_cache新缓存更新缓存核心一步直接cache_ort_ std::move(ort_outputs[1])把模型吐出的新缓存据为己有供下一轮使用取概率从output张量中按帧拷贝出概率值返回给调用方。值得一提的是第 2 步中模型的输入输出名in_names_ {input, cache}; out_names_ {output, r_cache};喂 cache、收 r_cache一进一出周而复始——这就是流式推理的核心循环。完整推理流水线从音频到唤醒概率运行时侧的数据流可以概括为音频 → 特征 → 增量推理 → 概率 → 唤醒。音频采集线程把波形喂给FeaturePipeline见 feature_pipeline.h内部用线程安全的阻塞队列缓存特征帧推理侧每凑满 80 帧就调用一次Forward()见 Android 端 wekws.cc80 帧约等于 0.8 秒音频每轮推理都携带上一轮的 cache因此第 N 轮的输出严格等价于从头算到第 N 轮的结果——流式结果与离线结果完全一致取所有帧概率的最大值作为本轮结果一旦超过阈值即触发唤醒。整个推理过程不重算历史ONNX Runtime 只处理新增的 80 帧加上 cache 张量极小通常只有几十 KB因此单次推理耗时极短实时性有充分保障。一套 C 代码多端部署WeKws 运行时的设计非常务实核心推理代码与平台无关直接复用到各个端上。在 runtime 目录下可以看到四个平台core纯 Linux 版本可交叉编译部署到嵌入式设备onnxruntime标准 ONNX Runtime 部署版androidJNI 封装运行在 Android 手机上模型需先转为.ort格式raspberrypi树莓派专用构建附有交叉编译工具链配置。它们共享同一份KeywordSpotting实现只是外围的音频采集与特征接口略有差异。这也意味着你只要把 cache 机制理解透四个平台的源码就都读懂了。总结WeKws 的 cache 机制是生产可用设计哲学的缩影训练侧为因果卷积预留上下文导出侧把尺寸写进模型元数据运行时侧零硬编码地动态管理缓存并通过一进一出的循环实现严格等价的流式推理。理解这条链路你就掌握了 WeKws C 运行时的灵魂也能轻松读懂它背后的 TCN/FSMN 流式部署原理。【免费下载链接】wekwsProduction First and Production Ready End-to-End Keyword Spotting Toolkit项目地址: https://gitcode.com/gh_mirrors/we/wekws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
