这次做的是一组开源 3D 实时数字人测试。主组有 TalkingHead、Meuxe 和 Utsuwa，分别代表浏览器 3D 控制层、VRM 控制层和完整 VRM 应用。DH_live/MatesX 是额外加入的 2D 参考，用来观察轻量方案能把接入成本压到什么程度。
四条路线都在同一台 Apple M5、32GB 内存的 Mac 上运行。输入使用冻结的中文音频；需要完整语音能力的方案，接入本机开源 ASR、LLM 和 TTS。我主要测了六件事：源码和角色资产能否用于后续开发、M5 能否真正渲染角色、中文输入能否驱动嘴部、动作与停止是否有效、长时间运行是否稳定，以及接成可用产品还要补多少工作。
我最后选的 Utsuwa，偏偏在 30 分钟长测里失败了。TalkingHead 的角色控制更细，Meuxe 接现成语音服务更直接；Utsuwa 已经把角色、对话入口、页面和设置放进同一个应用，离“可继续开发的完整 3D 数字人”最近。它最值得继续做，稳定性也是接手后必须先修的问题。
四个方案先简单认识一下
三个 3D 项目承担的工作不同，所以这次没有强行计算百分制总分。我比较的是许可边界、M5 实载、中文驱动、动作与中断、稳定性和接入工作量；结果按通过、部分通过、失败、不支持和未测试五档记录。
- TalkingHead 是浏览器 3D 控制层，适合想自己掌控 GLB、口型和动作的团队，完整中文语音链需要另接。
- Meuxe 是 VRM 控制层，适合已经有 ASR、LLM、TTS 服务，只缺角色前端的团队。
- Utsuwa 是完整度最高的开源 VRM 应用，20 轮固定中文输入全部完成；30 分钟长测暴露出缺段和取消，仍是我最愿意继续投入的方案。
- DH_live/MatesX 是 2D 参考，接入最轻，适合快速验证半身口播原型，不参与 3D 能力比较。
我的选择标准很直接：我更看重谁已经把角色、对话和应用装进同一套可继续修改的代码里。按这个标准，Utsuwa 排在最前面。长测失败也保留在结论里，因为它正好指出了接手后的第一项工作。
TalkingHead：把 3D 角色控制权留在浏览器里
TalkingHead 是 MIT 许可的浏览器 3D 控制库。它负责加载 GLB 角色，控制骨骼、面部形变、口型和动作，但不自带语音识别、大模型或语音合成。
动图截取自本轮真实 Canvas 连续录屏：TalkingHead 在 Apple M5/Metal 上加载 CC0 MPFB 角色。该片段展示角色持续渲染，不单独证明中文口型质量。
- 优点：GLB、骨骼、形变和动作都能直接控制；支持外部口型时间线；角色资产可以继续走 Blender、MPFB 和 GLB 工作流。
- 缺点：完整中文语音链要自己接；默认中文 WAV 只会播放，不会自动生成口型；内置挥手只有抬手，没有连续摆动，也没有明确的倾听姿势。
本轮制作的 TH-CHR01 在 M5 上加载成功，模型包含 76 根骨骼、8 个网格和 15 个口型形变。接入 MFA 生成的音素时间线后，双唇音 PP 的形变峰值达到 0.8998，静音区间能回到零。
动作测试里，点头、向左侧指示和微笑通过。内置挥手动作不完整，倾听姿势不支持。另一套官方 CC0 mpfb.glb 技术控制资产完成了 30 分钟运行，但 7 个点头锚点中有 1 次没有回到基线，所以长测整体判为失败。首个 10 分钟的 CPU 中位数为 11.9%，RSS 约 1.34GiB；最后 10 分钟分别为 11.3% 和 1.37GiB。这组资源数据不属于 TH-CHR01。
TalkingHead 适合希望自己掌控角色资产和 Web 交互的团队。它给的是一套细致的角色控制能力，角色的“耳朵、脑和声音”仍要自行接入。
Meuxe：已有语音服务时，接 VRM 比较直接
Meuxe 是 MIT 许可的 VRM 控制层。外部服务把音频交给浏览器后，它根据音频能量驱动嘴部，并切换 idle、talking 和表情状态。
动图截取自本轮 15.76 秒真实连续录屏：固定中文输入经本地语音链生成响应音频，Meuxe 在 Apple M5/Metal 上持续驱动 VRM 的身体和嘴部。片段证明页面与角色连续变化，不单独证明中文口型准确度。
- 优点：与现有 ASR、LLM、TTS 服务的职责衔接清楚；MIT 代码和本轮使用的 VRM/VRMA 许可明确；音频接入后可以很快看到角色开口。
- 缺点：嘴部主要跟随音量，不能证明中文音素准确；统一点头、挥手、真实 VAD 和抢话没有完成；30 分钟长测只覆盖预生成音频回放。
我用 Faster-Whisper small、Qwythos 和 eSpeak NG 组成许可证明确的本地语音服务，跑了三段中文输入。三轮口型峰值都是 1.00，播放结束后角色回到 idle。随后执行 20 个固定回合，20/20 都拿到了识别文本、回复、语音和嘴部响应。
30 分钟测试循环播放预先生成的 response WAV，共完成 1,014 轮、记录 7,740 个样本。最大采样间隔为 394.2 毫秒，没有超过 500 毫秒的空档。这证明 VRM 音频驱动能持续工作，不代表 ASR→LLM→TTS 整条语音服务连续运行了 30 分钟。
Meuxe 对应的场景很具体：团队已经有语音服务，现在只缺一个 VRM 前端。精细口型、业务动作和真实打断仍要继续开发。
Utsuwa：这轮我最推荐，但要先修稳定性
Utsuwa 是 AGPL-3.0-or-later 许可的开源 VRM 应用。它已经有角色页面、文字和语音入口、会话状态与设置界面，团队可以在这个应用骨架上继续开发。
动图截取自本轮 99.16 秒真实连续录屏：同一个页面内完成 Voice input、固定中文音频、本地识别、Qwythos 回复、语音合成和 VRM 动作。它展示单次完整回合的连续画面；浏览器中的语音输入仍是固定 WAV，不是物理麦克风。
- 优点：应用结构已经成形；固定 v0.13.1 在 M5 上通过 435 项上游测试、生产构建和浏览器实载；本地语音服务可以串进现有 Voice input。
- 缺点：默认 embedding 初始化仍访问 Hugging Face；30 分钟运行出现响应缺段、采样空档和转录取消；统一身体动作没有测试。
固定中文音频经过 Utsuwa 的 Voice input，进入 Faster-Whisper、Qwythos 和 eSpeak NG，再返回 VRM 页面。20 个固定回合全部完成，说明本地语音对话能够接入这套应用。
长测暴露了稳定性风险。30 分钟虽然达到目标时长，独立检查只通过 21/24：13 轮没有走完整个识别、回复和语音流程，85 个采样间隔超过 500 毫秒，还有 7 个本地转录请求被取消。
这也是我把 Utsuwa 放在第一位的原因：它已经跨过“把各个组件拼成应用”这道门槛，后续工作主要集中在稳定性和外部依赖治理上。产品立项前应先处理本地 embedding 和长时请求稳定性，否则页面能跑起来，持续在线仍会出问题。
DH_live/MatesX：2D 参考把原型门槛压得更低
DH_live/MatesX 是 MIT 许可的 Web/WASM 2D 头像前端。它不属于 3D 主组，我把它放进来，是为了给只需要半身口播头像的项目一个成本参照。
动图截取自本轮 59.28 秒真实连续录屏：固定中文输入经过本地识别、Qwythos、官方 VITS 和 WASM 头像页面。8 秒内可见嘴部与页面状态连续变化；图中是项目样例资产，正式产品需另行核对或替换。
- 优点：浏览器直接运行，接入轻；27 条固定中文输入都有音频缓冲和 BlendShape 更新；
user_abort()可以清理旧队列。 - 缺点：它是 2D，不提供 3D 骨骼、视角和身体动作；模拟语音设备不等于真实麦克风；样例头像的再分发和商用权利没有锁定，也没有 10 分钟耐久结果。
模拟语音设备进入官方 getUserMedia 入口后，页面记录到 350 次形变更新。候选自己的 user_abort() 可以执行旧队列回收，但响应结束后没有观察到新增清理动作，后续音频是否真正恢复播放也没有在无头浏览器中确认。
如果产品只需要轻量 2D 口播原型，DH_live/MatesX 可以快速验证前端形态。正式使用前，先换成自有或许可清楚的头像，再补真实语音和稳定性测试。
如果只选一个，我选 Utsuwa
Utsuwa 给出的起点最完整：VRM 角色、文字和语音入口、会话状态、设置页面都在同一套开源应用里。本轮 20 个固定中文回合全部跑通，也证明本地语音链能够接进去。它的 30 分钟长测失败，因此我的推荐带着一个明确前提：先修请求稳定性，再谈持续在线。
如果团队只缺某一层，另外两条路线仍然更合适。需要精细控制 GLB、骨骼和动作，选 TalkingHead；已有成熟语音服务，只缺 VRM 前端，选 Meuxe；只做轻量 2D 口播原型，可以看 DH_live/MatesX。
对多数想做完整开源 3D 数字人的团队，我会从 Utsuwa 开始。它不是单项能力最强的方案，但它最接近一个可以继续打磨的产品。
以上就是这次的侦察。
如果对你有用，顺手点个赞 +「♥️」。
想第一时间收到前线情报，关注「硅基斥候S01」。我们，下次侦察见。