【免费下载链接】voxtral.cPure C inference of Mistral Voxtral Realtime 4B speech to text model项目地址https://gitcode.com/gh_mirrors/vo/voxtral.c点击查看免费下载voxtral.c 是一个纯 C 语言实现的 Mistral Voxtral Realtime 4B语音识别语音转文字推理引擎。本文解析它的滚动 KV 缓存Rolling KV Cache设计——正是这一机制让长音频、无限时长的实时流式语音识别不会撑爆内存也不需要 Python、CUDA 或 vLLM 等任何运行时依赖。一、长音频语音识别的内存难题KV 缓存为什么会无限膨胀做流式语音识别的开发者都绕不开一个经典问题Transformer 每处理一个新 token都会往KV 缓存里追加注意力向量。音频越长缓存越大——一段 10 分钟录音缓存就是 10 分钟的量麦克风直播转写几个小时缓存将直接吃光物理内存。普通实现只能选择截断或拒绝长音频。voxtral.c 给出的答案是不删关键信息、也不无限增长而是让缓存滚动。它的整体管线为WAV → 16kHz → Mel 谱图 → Conv Stem → 音频编码器32 层→ 4 倍下采样 → Adapter → LLM 解码器26 层→ 文本 token每个 token 对应 80ms 音频。KV 缓存同时存在于编码器和解码器两侧且两侧都采用了滚动策略常量定义见 voxtral.h组件滑动窗口滚动策略音频编码器750 个位置VOX_ENC_WINDOW增量编码 满窗压缩LLM 解码器8192 个位置VOX_DEC_WINDOW满窗压缩compact二、滚动 KV 缓存的工作原理滑窗压缩三步法以解码器为例压缩逻辑集中在kv_cache_compact函数voxtral_decoder.c思路可以概括为三步保留最近窗口只保留最后 8192 个位置的 K/V 向量丢弃更早的历史整体前移用memmove把保留的数据移到缓存第 0 位腾出头部空间修正逻辑偏移把丢弃的数量累加进kv_pos_offset作为后续位置编码的逻辑偏移量。关键洞察RoPE旋转位置编码在写入时已经烘焙进缓存的 K 向量里所以压缩不需要任何重编码只需修正后续新 token 的逻辑位置即可详见下文。当新的 token 到来、缓存写满时解码器先尝试压缩而不是盲目扩容voxtral_decoder.c/* Rolling KV cache: compact instead of growing when possible */ if (pos ctx-kv_cache_max) { if (ctx-kv_cache_len VOX_DEC_WINDOW) { kv_cache_compact(ctx); /* 丢弃最老的部分保留最近 8192 */ pos ctx-kv_cache_len; } ... }这样无论音频多长解码器 KV 缓存的物理大小被硬性封顶在滑动窗口——内存占用 O(窗口)而不是 O(音频长度)。RoPE 逻辑位置修正压缩后位置编码为何依然正确有人会问把老数据丢掉、新数据从位置 0 重新排队位置编码不就错乱了吗voxtral.c 用物理位置 逻辑偏移双轨制解决voxtral_decoder.c/* RoPE uses logical position (physical offset from compactions) */ int logical_pos ctx-kv_pos_offset pos;postoken 在缓存中的物理下标压缩后从 0 开始kv_pos_offset历史上累计被压缩丢弃的位置数voxtral.h。两者相加才是 RoPE 使用的逻辑位置保证位置编码与 token 在完整序列中的真实时间顺序完全一致。编码器侧同理使用enc_kv_pos_offsetvoxtral.h。三、编码器侧750 窗口下的增量编码音频编码器32 层因果 Transformer的滚动实现在 voxtral_encoder.c 的enc_kv_cache_compact逻辑与解码器完全对称只是窗口更小750 个位置约 12.5Hz 帧率下的 60 秒音频if (ctx-enc_kv_cache_len new_len VOX_ENC_WINDOW) { enc_kv_cache_compact(ctx); /* 压缩到 750 位置 */ }配合增量编码vox_encoder_forward_incrementalvoxtral.hTransformer 每次只对新位置做前向计算、对缓存的 K/V 做注意力因此编码成本与音频总长无关。连最底层的 Mel 谱图缓冲区也在滚动mel_compact_samplesvoxtral_audio.c会丢弃已经不可能再贡献任何未来 Mel 帧的旧音频样本让整条流水线的每一层内存都有界。四、直播转写实战连续模式下 KV 溢出的自动重启对于离线文件滚动压缩已经足够但对于麦克风直播转写voxtral.c 还叠加了第二道保险——连续模式vox_stream_set_continuousvoxtral.h。在 voxtral.c 中运行时会监测四种情况并自动重启解码器EOS模型认为当前话语片段结束KV 溢出解码缓存长度超过STREAM_MAX_DECODE_KV2000重启以限制注意力计算成本、维持实时速度非文本 token 连发捕获解码器陷入控制 token 死循环⌚解码停滞看门狗音频在推进但解码器毫无产出。这里的重启是硬重置不携带解码上下文但编码器缓存与流式管线继续运行对用户而言转写文本依然连续输出。这一滑动窗口 自动重启的组合意味着即使录上一整天内存占用也始终被压在解码器 KV 缓存约 1.8 GB 的上限README.md。五、内存与性能无限量长音频的实测代价项目数值说明模型权重8.9 GB磁盘 mmapBF16 按需映射加载几乎瞬时解码器 KV 缓存≤ 1.8 GB封顶滚动压缩与音频长度无关工作缓冲区~200 MB编码器/解码器共享最长音频无限制官方规格明确标注README.md性能方面长音频耗时呈线性增长编码器因滑动窗口注意力是 O(n)解码器每 80ms 音频恒定产出一个 tokenREADME.md。也就是说1 小时和 10 分钟录音的每单位时间开销基本相同内存则完全一样。六、快速上手3 步验证滚动 KV 缓存# 1. 克隆仓库 git clone https://gitcode.com/gh_mirrors/vo/voxtral.c # 2. 编译Apple Silicon 走 Metal GPU最快速度 make mps # 或 make blas 走 CPU BLAS # 3. 下载模型约 8.9 GB并跑一个 3 分钟的长音频 ./download_model.sh ffmpeg -i samples/I_have_a_dream.ogg -f s16le -ar 16000 -ac 1 - 2/dev/null \ | ./voxtral -d voxtral-model --stdin --monitor--monitor会在 stderr 输出符号化状态其中⟳表示KV 溢出触发的解码器重启voxtral.c让你直观看到滚动机制在长音频上持续工作。想深入阅读可对照 Python 参考实现 python_simple_implementation.py 中的 KV 缓存逻辑。七、核心文件速查表文件作用voxtral.hKV 缓存字段定义与滚动注释voxtral_decoder.c解码器滚动压缩kv_cache_compactvoxtral_encoder.c编码器滚动压缩enc_kv_cache_compactvoxtral.c连续模式下的 KV 溢出自动重启voxtral_audio.cMel 缓冲区的样本级滚动SPEED.md性能剖析与 fp16 KV 缓存细节MODEL.md完整模型架构参考一句话总结voxtral.c 的滚动 KV 缓存 滑动窗口保留 内存前移 RoPE 逻辑偏移修正 直播模式自动重启四板斧让纯 C 语音识别引擎在恒定内存下从容转写任意时长的音频。赞分享【免费下载链接】voxtral.cPure C inference of Mistral Voxtral Realtime 4B speech to text model项目地址https://gitcode.com/gh_mirrors/vo/voxtral.c点击查看免费下载相关推荐终极人体姿态估计方案Lite-HRNet如何实现轻量级高分辨率网络革命终极人体姿态估计方案Lite HRNet如何实现轻量级高分辨率网络革命 在计算机视觉领域人体姿态估计一直是备受关注的核心技术之一。Lite HRNet作为一LEDE语音识别语音处理库支持LEDE语音识别语音处理库支持 语音处理基础库支持现状 LEDE项目当前未集成专门的语音识别引擎但通过底层音频处理库可构建语音应用基础。核心依赖库集中在 p嵌入式固件操作系统网络物联网7款语音转文字工具横评AsrTools如何做到无GPU也能高效批量转写7款语音转文字工具横评AsrTools如何做到无GPU也能高效批量转写 在数字化办公与内容创作领域语音转文字技术正成为提升效率的关键工具。无论是会议记录、采语音音频桌面应用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考