E001 分析：本地可打断语音

阅读日：2026-11-12（UTC）。数字只来自当天打开的 GitHub API、Hugging Face API 和下列原文。没有在 64GB 机器上跑过这些模型。凡是「估计」都单独标出。

agent24 对照提交仍是 阅读快照 的 bc923205。这次没有因为语音材料去改基线。

1. 问题怎么拆

用户要的是学校里、本机、中英、可打断的语音 Agent，并且后台能调用同一台机器上的 API。内存档是 Mac 统一内存 64 / 128 / 256GB，以及同级 Windows，外加服务器对照。

这里把两件事分开：

• 原生全双工：一个模型在自己说话时继续听，由模型决定让不让。Moshi、MiniCPM-o 4.5 的 duplex 模式、MOSS-Live 的自述属于这一类。
• 级联可打断：ASR、LLM、TTS 分开。用户一开始说话，网关停掉播放和生成。对话双方不会同时往下说。Pipecat、LiveKit、TEN 的 barge-in 属于这一类。SGLang 把 Qwen3-Omni 标成 turn-based，也是这一类。

学校第一版要的「可以被打断」用第二类就能满足。「边听边说」才需要第一类。

2. 调查范围和当天的公开热度

GitHub stargazers_count、pushed_at、license.spdx_id 取自 2026-11-12 的 REST API。Hugging Face downloads 与 lastModified 取自同一天的 https://huggingface.co/api/models/<repo>。OpenMOSS 的模型 API 返回 401，下载量记为未知，不估计。

Hugging Face downloads（API 字段，不另分时间窗）：

下载量高不等于适合教室。Kokoro 最高，但仓库最后 push 停在 2025-08-06，中文要额外装 misaki[zh]，本次没有找到官方中文音质表。

3. 必须单列的 VoxCPM 和 MOSS

VoxCPM2

官方 README（2026-11-12 读取）写明：2B，30 种语言，含中文和英文，以及一批汉语方言。48 kHz。流式 API 是 generate_streaming。Apache-2.0。RTX 4090 上 RTF 约 0.30，Nano-vLLM 或 vLLM-Omni 约 0.13。这里 RTF 小于 1 表示快于实时，是 TTS 论文里的常见定义。见 https://github.com/OpenBMB/VoxCPM

MLX 社区卡 mlx-community/VoxCPM2-bf16 写权重体积：bf16 4.96 GB、8-bit 3.23 GB、4-bit 2.30 GB。同一张卡把 RTF 定义成大于 1 才快于实时，并给出 0.48 / 0.85 / 0.90。机型没有写。因此不能把这三行当成 M 系列 Max 64GB 的实测。第三方 VoxWeft（stars 16，push 2026-09-22）报告他们自己的流式解码器首包：M5 约 169 ms，M2 16GB 约 303 ms，M3 Ultra 约 124 到 168 ms。这是移植作者的数字，不是 OpenBMB 的承诺。

结论：VoxCPM2 是学校中英音质的优先候选，CUDA 上有官方实时系数。Apple 上能装，但是否快于实时要在目标 Mac 上重测。它是 TTS，不是全双工对话模型。

MOSS-TTS、MOSS-TTSD、MOSS-TTS-Realtime

MOSS-TTS README 把家族分成长期合成、对话合成、声音设计和实时 TTS。Apache-2.0。

• MOSS-TTS / v1.5：8B。llama.cpp 路径写过 8B 可放进 8GB GPU（2026-03-10 的新闻行）。这是权重装入，不是整条语音链路的端到端延迟。
• MOSS-TTSD v1.0：8B，长对话、多说话人。适合播客，不适合学生打断后 200 ms 级停嘴。旧版 streamer.py 的块大约 20 秒，见仓库 legacy 文档。
• MOSS-TTS-Realtime：1.7B。模型卡写在单张 L20 上、预热后 TTFB 180 ms，RTF 0.51。他们用 vLLM 上的 Qwen3.5-9B 生成 12 个 token 花了 197 ms，两者相加 377 ms。vLLM-Omni 配方写 A10G 24GB 上 talker 约 6 GB，codec 约 8 GB。语言表含中文和英文，共 20 种。见 https://github.com/OpenMOSS/MOSS-TTS/blob/main/docs/moss_tts_realtime_model_card.md 与 https://github.com/vllm-project/vllm-omni/blob/main/recipes/OpenMOSS/MOSS-TTS.md
• MOSS-TTS-Nano：约 0.1B，README 写 4 个 CPU 核可以流式。质量是否够教室，本次没有独立听测。
• mlx-audio 的模型表列出了 MOSS-TTS、Local-Transformer 和 Nano。表里没有把 MOSS-TTS-Realtime 单列。Apple 上的 Realtime 路径本次未证实。

MOSS-Speech 和 MOSS-Live

MOSS-Speech 的 README 写它不先出文本、直接出语音，骨干是 Qwen3-8B。Next Steps 仍勾着两件未完成的事：开放 base 模型，以及 Gradio 流式输出。不能当作今天可部署的全双工。

MOSS-Live 和 Hugging Face 博客（2026-11-07）描述的是全双工、可打断、能区分「嗯」和抢话，后台工具和前台说话并行。开始方式是线上 playground 和 realtime API。README 没有本地权重和显存表。他们自己的表里，用户打断后的响应延迟是 1.38 秒，Candor 接话延迟 1.14 秒。这些是他们的评测，不是本校网络。学校要求音频留在本机，所以 MOSS-Live 只作能力对照，不进部署排序。

4. 其他一线组件，按角色

听

• Qwen3-ASR 0.6B / 1.7B：官方写 30 种语言加 22 种汉语方言，单模型同时支持离线和流式，流式目前走 vLLM。见 https://github.com/QwenLM/Qwen3-ASR 。mlx-audio 提供 8-bit MLX 和 stream_transcribe。MLX 文档列出的语言比官方短，以运行库 get_supported_languages() 为准。
• SenseVoice-Small：论文写 234M，中、英、粤、日、韩，A800 上 10 秒音频延迟 70 ms，RTF 0.007。见 https://arxiv.org/html/2407.04051v2 。这是整段识别。FunASR 是否还有流式 Paraformer，本次没有把未打开的文档写成事实。
• Parakeet TDT 0.6B：HF 许可 CC-BY-4.0。mlx-audio 写 v2 是英语，v3 是 25 种欧洲语言。不作为中文教室的默认识别。
• Whisper / whisper.cpp / mlx-whisper：mlx-audio 仍列出 Whisper。中文可用，但是 Qwen3-ASR 已经同时覆盖中英流式和 MLX，第一版不必并行维护两套识别。

说

• Qwen3-TTS：官方写首包可以低到 97 ms，10 种语言含中英，0.6B 与 1.7B，流式。技术报告写 12 Hz 的 0.6B 与 1.7B 在并发 1 时首包 97 ms 和 101 ms，测量平台是他们的 vLLM，加了 torch.compile 和 CUDA Graph。见 https://github.com/QwenLM/Qwen3-TTS 与 https://arxiv.org/html/2601.15621 。mlx-audio 有 8-bit 和 --stream。Apple 上的毫秒数本次没有官方数字。
• CosyVoice 2：官网写首包可到 150 ms。论文训练数据以中文 13 万小时、英文 3 万小时为主。见 https://fun-audio-llm.github.io/cosyvoice2/ 与 https://arxiv.org/html/2412.10117v3 。适合中文，本次没有找到与 VoxCPM2 同机的对照，所以不把它写成音质第一。
• Kokoro：小，Apache-2.0，MLX 有。中文依赖额外前端。作故障时的轻量退路，不作教室主语音。
• Fish Speech、IndexTTS：stars 很高。GitHub 许可字段是 NOASSERTION。学校默认不用，除非另做许可审阅。

原生或接近原生的对话模型

• Moshi：官方写理论延迟 160 ms（Mimi 帧 80 ms 加声学延迟 80 ms），L4 上实践约 200 ms。PyTorch 未量化，要约 24GB 显存。MLX 在 MacBook Pro M3 上测过，提供 4-bit 和 8-bit。CLI 写明不做回声消除，也不丢帧追赶延迟。见 https://github.com/kyutai-labs/moshi 。模型卡语言重心是英文对话。没有找到官方中文教室指标。
• MiniCPM-o 4.5 duplex：文档写每秒一块音频，模型自己决定听或说，GPU worker 在整个会话期间独占。默认 chunk_ms 是 1000。打断靠客户端继续送音频，或调用 set_break()。见 https://openbmb.github.io/MiniCPM-o-Demo/site/en/api/duplex.html 。SGLang-Omni 指南写 MiniCPM-o 需要一张至少 80GB 的 GPU，并把它标成 native_full_duplex。见 https://sgl-project.github.io/sglang-omni/developer_reference/full_duplex_guide.html 。64GB 与 128GB 统一内存都低于这个门槛。256GB Mac 在容量上有机会，但是本次没有找到该 duplex 模式的 MLX 实现。
• MiniCPM-o 2.6：HF 权重存在，Apache-2.0。DeepWiki 对它的服务描述是 VAD 等到说完再生成，/stop 可以打断。那是可打断，不是 4.5 的 duplex 循环。本次不把它升为全双工。
• Qwen3-Omni-30B-A3B：官方表写 BF16、带 thinker 和 talker 的 Instruct，15 秒视频的理论最小显存 78.85 GB，随视频变长升到 144.81 GB。见 https://github.com/QwenLM/Qwen3-Omni 。SGLang 明确写它不在说话时听，用户插话或 response.cancel 会停掉回答。两张 H100 或一张 H200。H100 配置的短对话 max_sessions 是 4，一张 H200 的 KV 池按 32768 去除得到 16。这是服务槽位，不是实测学生数。
• 一篇 2026 年的论文 D2 把 Qwen3-Omni 和 LLaMA-Omni 2 称作半双工骨干，再改成更密的全双工。见 https://arxiv.org/html/2610.17124 。它报告的延迟是论文系统，不是现成的学校安装包。

编排

• Pipecat：VAD 与轮次策略分开。用户开始说话可以触发 interruption。BSD-2-Clause。见 https://docs.pipecat.ai/pipecat/learn/speech-input 。适合把本地 ASR、LLM、TTS 串成进程内管道，第一版不必上 WebRTC。
• LiveKit Agents：文档把级联、轮次式实时模型、全双工实时模型分成三类，并写级联是多数生产代理的默认。打断可以按 VAD，也有自适应模式，但自适应默认条件包含 LiveKit Cloud 或带云凭证的开发模式。学校离线部署不能依赖那条。见 https://docs.livekit.io/agents/models/pipelines/ 与 https://docs.livekit.io/agents/logic/turns/adaptive-interruption-handling/ 。教室若要浏览器直连媒体，LiveKit 自建 SFU 是第二阶段的传输，不是第一阶段的模型。
• TEN：VAD 与 Turn Detection 支持中英（Agora 博客，https://www.agora.io/en/blog/making-voice-ai-agents-more-human-with-ten-vad-and-turn-detection/ ）。级联示例在部分识别时调用 _interrupt() 冲掉 LLM 和 TTS。见 https://theten.ai/docs/ten_agent_examples/customize_agent/modify-main/main_python_cascade 。框架许可带附加限制，学校法务未看过之前，不作为第一名框架。VAD 模型本身可以以后再替换进 Pipecat。

5. 八个完整方案，按学校可部署性排序

每个方案都是「模型组合 + 编排」，不是单颗模型。排序看的是：中英、可打断、本机、许可清楚、目标内存放得下、能调用本机 agent24。不按 stars 排序。

不进入这八名的：

• MOSS-Live：行为最接近用户说的全双工，但是没有本地权重。
• MOSS-Speech：流式和基座权重都还在待办。
• MOSS-TTSD：长对话配音，块太大。
• Fish Speech、IndexTTS：许可字段不是清楚的 Apache/MIT。
• Kokoro：可作 S1 的应急 TTS，不单独成方案。

6. 各档第一名

并发一栏没有本校测量。估计只写设计目标。

64GB 能不能用：能。指的是一路中英、可打断、模型和 API 都在本机的级联对话。不能指原生全双工，也不能指未经测量的多学生同时说话。

更大的显存会更好的部分，只在官方材料里出现过的范围：4090 上 VoxCPM2 有 RTF，H200 / 双 H100 才能按 SGLang 的配置跑 Omni 或原生 duplex。它不自动让 64GB 上的中文对话变得不可用。

7. 和 agent24 的缝

基线见 agent24 架构基线。和语音直接相关的代码是：

• RunManager::start_run 先把 run 写成 Queued 再在后台 execute。run_loop 最多 10 轮。最终回答在工具调用为空时，先写记忆，再把整段文本放进一次 ModelDelta。字段注释写的是 streaming increment，这个调用点送出的是完整答案。见 rust/crates/agent24-agent/src/lib.rs 第 62、1459、2923、3017-3026 行。
• cancel_run 对非终态发取消令牌，终态则原样返回。见第 1684-1703 行。模型调用和记忆写入都和取消赛跑。所以「停掉这一轮文字生成」已经有入口。
• 浏览器不能作为 /api/v1/events 的客户端。Origin 头存在就 403。见 rust/apps/agent24d/src/events.rs 第 72-79 行。
• daemon 只绑 127.0.0.1。见 rust/apps/agent24d/src/serve_steps.rs 第 974-982 行。教室里的浏览器必须打到网关，不能打到 daemon。
• 工具默认要过 ApprovalBroker。语音里等人点卡片，打断体验不成立。
• agent24-worker 有转写契约，Cargo 注释写没有产品调用方。不能把「内核已经会听」当成现状。
• 桌面语音面板展示的是附着模块的转写。真正的听和说在 AgentEar 进程里，不在 run_loop 里。见 AgentEar 基线。

因此语音时钟应留在 AgentEar。agent24d 继续通过已有的 _a24/model/complete 回答，而不是再为语音开一条 /api/v1/runs。闲聊如果要边出边合成，仍走 AgentEar 本机边车的流式。附着路径今天是整句。

9. AgentEar 已经覆盖什么

阅读提交 17e911b。对照表：

结论：Mac 上的语音网关应做在 AgentEar 里面，不从 Pipecat 重写采集、识别和 VoxCPM2。Windows 档 AgentEar 跑不了，仍用原来的 S2 到 S5，那是另一条以后的移植，不是第一刀。

8. 事实、推断、未验证

事实是第 2 到第 4 节里带链接的句子。推断是：64GB 同时装下 ASR 0.6B 8-bit、TTS 0.6B 8-bit 和一个中小 LLM 后仍有余量。权重体积支持这个方向，进程开销和 KV 缓存没有测。

未验证：任何一档的端到端毫秒、同时学生数、VoxCPM2 在 M 系列 Max 上的 RTF、MOSS-TTS-Realtime 的中文主观音质、教室扬声器下的误打断率、MiniCPM-o 4.5 在 Apple 上能否跑。AgentEar README 里的 2.80 秒中位数是他们自己的句子级流水线，这次没有重测，也不能当成语音打断之后的数字。