尧图网页设计 
VoiceMem对接gpt-realtime与qwen-omni语音模型记忆注入、打断与回声消除的工程细节【免费下载链接】VoiceMemInfrastructure for the next generation of voice agents, designed to provide universal memory. It is divided into a left brain and a right brain, storing information and emotions respectively, while a fully streaming architecture eliminates latency at the fundamental level.项目地址: https://gitcode.com/gh_mirrors/vo/VoiceMemVoiceMem 是一个面向实时语音智能体的开源流式双脑记忆系统本文基于官方示例 examples/05_realtime_gpt_qwen.py详解如何把 gpt-realtime 与 qwen-omni-realtime 两大语音模型接入 VoiceMem并拆解记忆注入、打断barge-in与回声消除AEC三处最容易踩坑的工程细节——让记忆检索在你说完话之前就已就绪回复延迟几乎归零。先认识 VoiceMem给语音模型装上「左脑 右脑」很多语音助手「一问一答」却从不积累你上周说过的过敏、养过的猫下周它就全忘了。VoiceMem 的定位就是补上这个缺失的组件——长期记忆。它把记忆拆成两个互相配合的部分左脑Information Graph用 Schema 和 Entity 组织事实记忆负责「你说过什么」右脑Affect Graph用独立节点和交叉节点管理人设、情绪、关系负责「你是谁、你什么感受」。更重要的是它的流式特性用户还在说话时转写、实体抽取、记忆检索就在后台并行进行。官方在 LoCoMo 基准上达到 91.2%Mem0 为 61.68%检索响应约 134ms单轮只注入约 430 个记忆 token——这些数字都来自 README.md 与 evaluation/README.md。对接总览一份音频走两条路接 Realtime 语音模型的整体思路可以概括为一句话麦克风音频平行地走两条路。麦克风 ──┬──→ uplink 协程 ──→ realtime 服务input_audio_buffer.append──→ 原生语音回复 │ └──→ 主循环 ──→ vm.stream(feed) ──→ VoiceMem 边听边投机预取记忆 │ VAD 判「说完了」(turn_over) │ input_audio_buffer.commit │ response.create携带已检索好的记忆对应 examples/05_realtime_gpt_qwen.py#L114-L119 中的split()每一块麦克风音频同时put进两个队列——to_ws上行走 realtime和to_vm给记忆预取。两条路各有各的消费者协程绝不排队原因见文末「延迟三细节」。VoiceMem 侧的入口就是流式接口vm.stream()每喂一块音频返回一个StreamState当本地 VAD 判定这一轮说完时state变为turn_over此时st.memory_context里装着早已检索好的记忆文本拿来即用见 voicemem/stream.py#L4-L16。记忆注入投机预取 一个「必须知道」的坑0–500ms 投机预取说完话那一刻记忆已经现成VoiceMem 的检索不等你说完才开始。转写攒够几个字、后台就开始向量检索等 VAD 确认「说完了」记忆基本是现成的主循环里对应就三步examples/05_realtime_gpt_qwen.py#L164-L178等到turn_over发input_audio_buffer.commit提交音频发response.create把PERSONA人设 st.memory_context记忆拼进本次响应的instructions。关键坑记忆必须走 per-response 的 instructions这是官方 README 里用实测验证过的教训examples/README.md记忆必须走 per-response 的instructions不能用session.update—— 后者是会话级设置实测这一轮模型读不到问「我的猫叫什么」库里明明检索到「叫墨墨」它还答「你刚提过但我没听清」。session.update是会话级配置而记忆是逐轮变化的只有塞进本轮response.create的instructions里模型才保证读到。另外服务端 VAD 只被借用做打断create_responseFalseinterrupt_responseTrue——什么时候回复由本地决定否则服务端抢先生成的那个 response 里没有我们注入的记忆。两家 API 的差异只需替换一个 dictgpt-realtime 与 qwen-omni-realtime 的事件名完全一致session.update/input_audio_buffer.append/response.create/response.*audio.delta差别只在 session 配置段和采样率。示例代码用两个 dict 把差异全部封装examples/05_realtime_gpt_qwen.py#L34-L61配置项gpt-realtimeqwen3-omni-realtime鉴权OPENAI_API_KEYDASHSCOPE_API_KEY输入采样率24000 Hz16000 Hzturn_detection位置必须放在session.audio.input下写顶层会被静默拒绝扁平结构直接在 session 下音色audio.output.voice如 marinvoice如 Chelsie事实抽取 LLMOpenAI 侧 gpt-4o-miniDashScope 兼容模式 qwen-plus两点值得细看gpt 的turn_detection层级是隐藏雷写成顶层不报错、但不生效排查起来很费时间采样率不同麦克风统一按 16k 采集AEC 的原生档发往 gpt 前在 examples/05_realtime_gpt_qwen.py#L70-L76 的to_wire()里重采样成 24k 再 base64 编码。打断barge-in双路备份 宽限期好的语音助手用户一开口就得闭嘴。这套实现里有两条互为备份的打断路径服务端 VAD 路径interrupt_responseTrue服务端听到人声直接掐掉正在生成的回复本地 AEC 路径回声消除模块持续计算speech_probability助手播放期间人声概率连续 0.5s 过阈值就立即清播放缓冲并回调on_barge_in→ 发response.cancelexamples/05_realtime_gpt_qwen.py#L104-L112。谁先到算谁的慢的那条会撞上response_cancel_not_active错误属于预期行为示例里连同input_audio_buffer_commit_empty一起列入白名单静默处理examples/05_realtime_gpt_qwen.py#L63-L67。两个容易忽略的细节本地播放缓冲必须清interrupt_response只让服务端停止生成本地已收到的那几秒音频照样播完听感就是「打断没用」宽限期grace_s 0.6s助手刚开口那半秒麦克风里几乎只有它自己的声音、AEC 尚未收敛若此时判打断它会「一出声就把自己掐了」。所以打断判定要求「已说话 ≥ 0.6s 且人声连续 ≥ 0.5s」参数在 examples/_audio.py#L40-L41 可调。回声消除AEC别让助手的话被存成「你的话」外放场景下麦克风录到的是「你的声音 喇叭里助手的声音」。若不消除回声会坏两件事examples/_audio.py#L1-L16转写把助手的话当成你说的存进记忆库——污染记忆VAD 一直以为有人在说话助手一开口就触发自己的打断逻辑。实现上用了 WebRTC APMpywebrtc_audio拿喇叭正在放的那份信号far-end作参考从麦克风信号里减掉它。核心约束是——播放和录音必须走同一个sd.Stream只有在同一个音频回调里才拿得到与这一帧麦克风严格对齐的参考信号examples/_audio.py#L69-L90。整条设备链路统一跑 16kWebRTC APM 只吃 8/16/32/48kTTS/realtime 吐出的 24k 音频在play()里降到 16k 进缓冲——这份缓冲正是 AEC 的参考信号一举两得。另外麦克风队列「满了就丢」助手说话那几秒没人取数据攒着只会让下一轮的 ASR 落后一大截。顺带一提浏览器场景不用手写这些getUserMedia自带 AEC仓库里的 web demopython web/run.py就靠它。延迟三细节不是随手写的是「必须这么写」examples/README.md 里专门点了三处「延迟上必须这么写」的代码都是生产环境的血泪经验播放要过一层缓冲。realtime 推音频的速度比实时播放快得多若在事件泵里直接写声卡会阻塞——而事件泵是 websocket 的唯一消费者一卡就不再收事件TCP 反压上去speech_started/response.done全被推迟打断要清本地缓冲上文已述上行音频与本地 ASR 各走一条协程。stream.feed()里的 ASR 跑在事件循环上若与上行音频串在同一条协程它一抖发给 realtime 的上行音频也跟着抖。还有第四个常被漏掉的存记忆vm.ingest是秒级的同步调用必须丢线程asyncio.to_thread示例中async_factsTrue异步抽事实。把它摆在事件泵或主循环上等于整条会话被卡住examples/05_realtime_gpt_qwen.py#L151-L153。最后为什么 embedding 和 slot 分类都要选provider: local本地 E5因为投机预取的 0–500ms 预算里不能走网络——你说话时检索已在后台跑说完时记忆必须是现成的embedding 若每轮发 HTTP光网络往返就吃掉整个预算。三步跑起来# 1. 克隆并安装含 ASR / 声纹 / 情绪 / 本地 embedding 全套组件 git clone https://gitcode.com/gh_mirrors/vo/VoiceMem cd VoiceMem pip install voicemem # 2. 下载本地模型 hf download zhifeixie/VoiceMem_Default_Models_Env --local-dir ./models # 3. 设置 Key 后二选一运行 OPENAI_API_KEYsk-... python examples/05_realtime_gpt_qwen.py gpt DASHSCOPE_API_KEYsk-... python examples/05_realtime_gpt_qwen.py qwen运行后听到[ready] … 说话吧就可以开口了说「我对花生过敏」隔几轮再问「我不能吃什么」——它答得出来且开口几乎没有迟疑。小结把 VoiceMem 接到 gpt-realtime 或 qwen-omni-realtime本质上是三件事的组合拳记忆注入投机预取 per-responseinstructions检索零占回复时间打断服务端 VAD 与本地 AEC 双路备份外加宽限期与本地缓冲清理回声消除同一sd.Stream里做 AEC保住「记忆不被助手自己的话污染」。两条路解耦、事件泵不阻塞、写入丢线程——这些细节单看都不起眼合起来才是一个「记得住、打断得住、听得干净」的低延迟语音智能体。想继续深入可以从 examples/README.md 的六个官方示例和 voicemem/stream.py 的流式接口入手。【免费下载链接】VoiceMemInfrastructure for the next generation of voice agents, designed to provide universal memory. It is divided into a left brain and a right brain, storing information and emotions respectively, while a fully streaming architecture eliminates latency at the fundamental level.项目地址: https://gitcode.com/gh_mirrors/vo/VoiceMem创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 VoiceMem对接gpt-realtime与qwen-omni语音模型：记忆注入、打断与回声消除的工程细节
VoiceMem对接gpt-realtime与qwen-omni语音模型记忆注入、打断与回声消除的工程细节【免费下载链接】VoiceMemInfrastructure for the next generation of voice agents, designed to provide universal memory. It is divided into a left brain and a right brain, storing information and emotions respectively, while a fully streaming architecture eliminates latency at the fundamental level.项目地址: https://gitcode.com/gh_mirrors/vo/VoiceMemVoiceMem 是一个面向实时语音智能体的开源流式双脑记忆系统本文基于官方示例 examples/05_realtime_gpt_qwen.py详解如何把 gpt-realtime 与 qwen-omni-realtime 两大语音模型接入 VoiceMem并拆解记忆注入、打断barge-in与回声消除AEC三处最容易踩坑的工程细节——让记忆检索在你说完话之前就已就绪回复延迟几乎归零。先认识 VoiceMem给语音模型装上「左脑 右脑」很多语音助手「一问一答」却从不积累你上周说过的过敏、养过的猫下周它就全忘了。VoiceMem 的定位就是补上这个缺失的组件——长期记忆。它把记忆拆成两个互相配合的部分左脑Information Graph用 Schema 和 Entity 组织事实记忆负责「你说过什么」右脑Affect Graph用独立节点和交叉节点管理人设、情绪、关系负责「你是谁、你什么感受」。更重要的是它的流式特性用户还在说话时转写、实体抽取、记忆检索就在后台并行进行。官方在 LoCoMo 基准上达到 91.2%Mem0 为 61.68%检索响应约 134ms单轮只注入约 430 个记忆 token——这些数字都来自 README.md 与 evaluation/README.md。对接总览一份音频走两条路接 Realtime 语音模型的整体思路可以概括为一句话麦克风音频平行地走两条路。麦克风 ──┬──→ uplink 协程 ──→ realtime 服务input_audio_buffer.append──→ 原生语音回复 │ └──→ 主循环 ──→ vm.stream(feed) ──→ VoiceMem 边听边投机预取记忆 │ VAD 判「说完了」(turn_over) │ input_audio_buffer.commit │ response.create携带已检索好的记忆对应 examples/05_realtime_gpt_qwen.py#L114-L119 中的split()每一块麦克风音频同时put进两个队列——to_ws上行走 realtime和to_vm给记忆预取。两条路各有各的消费者协程绝不排队原因见文末「延迟三细节」。VoiceMem 侧的入口就是流式接口vm.stream()每喂一块音频返回一个StreamState当本地 VAD 判定这一轮说完时state变为turn_over此时st.memory_context里装着早已检索好的记忆文本拿来即用见 voicemem/stream.py#L4-L16。记忆注入投机预取 一个「必须知道」的坑0–500ms 投机预取说完话那一刻记忆已经现成VoiceMem 的检索不等你说完才开始。转写攒够几个字、后台就开始向量检索等 VAD 确认「说完了」记忆基本是现成的主循环里对应就三步examples/05_realtime_gpt_qwen.py#L164-L178等到turn_over发input_audio_buffer.commit提交音频发response.create把PERSONA人设 st.memory_context记忆拼进本次响应的instructions。关键坑记忆必须走 per-response 的 instructions这是官方 README 里用实测验证过的教训examples/README.md记忆必须走 per-response 的instructions不能用session.update—— 后者是会话级设置实测这一轮模型读不到问「我的猫叫什么」库里明明检索到「叫墨墨」它还答「你刚提过但我没听清」。session.update是会话级配置而记忆是逐轮变化的只有塞进本轮response.create的instructions里模型才保证读到。另外服务端 VAD 只被借用做打断create_responseFalseinterrupt_responseTrue——什么时候回复由本地决定否则服务端抢先生成的那个 response 里没有我们注入的记忆。两家 API 的差异只需替换一个 dictgpt-realtime 与 qwen-omni-realtime 的事件名完全一致session.update/input_audio_buffer.append/response.create/response.*audio.delta差别只在 session 配置段和采样率。示例代码用两个 dict 把差异全部封装examples/05_realtime_gpt_qwen.py#L34-L61配置项gpt-realtimeqwen3-omni-realtime鉴权OPENAI_API_KEYDASHSCOPE_API_KEY输入采样率24000 Hz16000 Hzturn_detection位置必须放在session.audio.input下写顶层会被静默拒绝扁平结构直接在 session 下音色audio.output.voice如 marinvoice如 Chelsie事实抽取 LLMOpenAI 侧 gpt-4o-miniDashScope 兼容模式 qwen-plus两点值得细看gpt 的turn_detection层级是隐藏雷写成顶层不报错、但不生效排查起来很费时间采样率不同麦克风统一按 16k 采集AEC 的原生档发往 gpt 前在 examples/05_realtime_gpt_qwen.py#L70-L76 的to_wire()里重采样成 24k 再 base64 编码。打断barge-in双路备份 宽限期好的语音助手用户一开口就得闭嘴。这套实现里有两条互为备份的打断路径服务端 VAD 路径interrupt_responseTrue服务端听到人声直接掐掉正在生成的回复本地 AEC 路径回声消除模块持续计算speech_probability助手播放期间人声概率连续 0.5s 过阈值就立即清播放缓冲并回调on_barge_in→ 发response.cancelexamples/05_realtime_gpt_qwen.py#L104-L112。谁先到算谁的慢的那条会撞上response_cancel_not_active错误属于预期行为示例里连同input_audio_buffer_commit_empty一起列入白名单静默处理examples/05_realtime_gpt_qwen.py#L63-L67。两个容易忽略的细节本地播放缓冲必须清interrupt_response只让服务端停止生成本地已收到的那几秒音频照样播完听感就是「打断没用」宽限期grace_s 0.6s助手刚开口那半秒麦克风里几乎只有它自己的声音、AEC 尚未收敛若此时判打断它会「一出声就把自己掐了」。所以打断判定要求「已说话 ≥ 0.6s 且人声连续 ≥ 0.5s」参数在 examples/_audio.py#L40-L41 可调。回声消除AEC别让助手的话被存成「你的话」外放场景下麦克风录到的是「你的声音 喇叭里助手的声音」。若不消除回声会坏两件事examples/_audio.py#L1-L16转写把助手的话当成你说的存进记忆库——污染记忆VAD 一直以为有人在说话助手一开口就触发自己的打断逻辑。实现上用了 WebRTC APMpywebrtc_audio拿喇叭正在放的那份信号far-end作参考从麦克风信号里减掉它。核心约束是——播放和录音必须走同一个sd.Stream只有在同一个音频回调里才拿得到与这一帧麦克风严格对齐的参考信号examples/_audio.py#L69-L90。整条设备链路统一跑 16kWebRTC APM 只吃 8/16/32/48kTTS/realtime 吐出的 24k 音频在play()里降到 16k 进缓冲——这份缓冲正是 AEC 的参考信号一举两得。另外麦克风队列「满了就丢」助手说话那几秒没人取数据攒着只会让下一轮的 ASR 落后一大截。顺带一提浏览器场景不用手写这些getUserMedia自带 AEC仓库里的 web demopython web/run.py就靠它。延迟三细节不是随手写的是「必须这么写」examples/README.md 里专门点了三处「延迟上必须这么写」的代码都是生产环境的血泪经验播放要过一层缓冲。realtime 推音频的速度比实时播放快得多若在事件泵里直接写声卡会阻塞——而事件泵是 websocket 的唯一消费者一卡就不再收事件TCP 反压上去speech_started/response.done全被推迟打断要清本地缓冲上文已述上行音频与本地 ASR 各走一条协程。stream.feed()里的 ASR 跑在事件循环上若与上行音频串在同一条协程它一抖发给 realtime 的上行音频也跟着抖。还有第四个常被漏掉的存记忆vm.ingest是秒级的同步调用必须丢线程asyncio.to_thread示例中async_factsTrue异步抽事实。把它摆在事件泵或主循环上等于整条会话被卡住examples/05_realtime_gpt_qwen.py#L151-L153。最后为什么 embedding 和 slot 分类都要选provider: local本地 E5因为投机预取的 0–500ms 预算里不能走网络——你说话时检索已在后台跑说完时记忆必须是现成的embedding 若每轮发 HTTP光网络往返就吃掉整个预算。三步跑起来# 1. 克隆并安装含 ASR / 声纹 / 情绪 / 本地 embedding 全套组件 git clone https://gitcode.com/gh_mirrors/vo/VoiceMem cd VoiceMem pip install voicemem # 2. 下载本地模型 hf download zhifeixie/VoiceMem_Default_Models_Env --local-dir ./models # 3. 设置 Key 后二选一运行 OPENAI_API_KEYsk-... python examples/05_realtime_gpt_qwen.py gpt DASHSCOPE_API_KEYsk-... python examples/05_realtime_gpt_qwen.py qwen运行后听到[ready] … 说话吧就可以开口了说「我对花生过敏」隔几轮再问「我不能吃什么」——它答得出来且开口几乎没有迟疑。小结把 VoiceMem 接到 gpt-realtime 或 qwen-omni-realtime本质上是三件事的组合拳记忆注入投机预取 per-responseinstructions检索零占回复时间打断服务端 VAD 与本地 AEC 双路备份外加宽限期与本地缓冲清理回声消除同一sd.Stream里做 AEC保住「记忆不被助手自己的话污染」。两条路解耦、事件泵不阻塞、写入丢线程——这些细节单看都不起眼合起来才是一个「记得住、打断得住、听得干净」的低延迟语音智能体。想继续深入可以从 examples/README.md 的六个官方示例和 voicemem/stream.py 的流式接口入手。【免费下载链接】VoiceMemInfrastructure for the next generation of voice agents, designed to provide universal memory. It is divided into a left brain and a right brain, storing information and emotions respectively, while a fully streaming architecture eliminates latency at the fundamental level.项目地址: https://gitcode.com/gh_mirrors/vo/VoiceMem创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考