本地赛博女友链路：speech-to-speech、Duix Avatar与DeepSeek API

作者：@AIwood爱屋研究室

本地赛博女友链路：speech-to-speech、Duix Avatar与DeepSeek API

一句话导读：作者用一整天搭建本地“赛博女友”原型，以 Hugging Face speech-to-speech 项目承载语音对话底座，调用 DeepSeek API 生成回复，再接入 Duix Avatar 数字人形象；视频重点复盘这条链路的延迟、显存和工程衔接问题，而不是提供可直接照抄的一键安装教程。

核心内容：
1. 基础链路先完成语音输入、识别、语言模型回复和语音输出。作者认为默认语音识别容易误判语种或过早截断说话，因此建议中文场景改用更适合中文的识别模型；视频没有稳定给出该模型的准确名称，本文不作额外推断。
2. 大语言模型既可通过 Ollama 一类本地运行方式部署，也可调用线上 API。作者最终使用 DeepSeek API，以减少本地显存占用；若同时本地加载语言模型，数字人部分可用的显存会进一步收紧。
3. 只做语音聊天时，前半段链路已经能够工作；真正困难的是把回复接入数字人形象。作者尝试过多种方案：轻量版本速度较快但画质不足，质量更高的版本又出现较长生成等待，说明“能生成”与“接近实时”之间仍有明显工程差距。
4. 当前原型最终接入简介所列的 Duix Avatar。作者口述其数字人部分约占 13G 显存，16G 显存设备在不加载本地大语言模型时可以尝试；其本机一次回复仍需约 15—20 秒生成数字人片段，因此不应理解为真正零延迟的实时对话。
5. 除模型本身外，链路编排也决定体验：需要明确先生成语音还是数字人、何时取回素材并回填界面；背景视频要循环播放，数字人生成和播放阶段应暂停麦克风收音，播放结束后再恢复，避免系统把自己的声音当成新任务。
6. 作者还为缓存和临时素材设置滚动清理逻辑，例如只保留最近若干生成结果，防止长时间运行持续堆积文件；重复运行时复用部分缓存，也能减少后续等待。
7. 作者自述调试过程消耗约 8 亿 token，主要来自不断排错和调整连接逻辑。这个数字是视频中的个人开发记录，不代表搭建同类项目的固定成本；硬件、模型、代码基础和自动化工具不同，实际消耗会有很大差异。
8. 默认首屏评论也认为真实时数字人仍是难题，并有人建议尝试 LiveAct。评论观点和硬件反馈仅作为补充线索，本文不把它们当作已经验证的替代方案。

相关项目：
Hugging Face speech-to-speech：https://github.com/huggingface/speech-to-speech
Duix Avatar：https://github.com/duixcom/Duix-Avatar

适合人群：想把语音识别、TTS、LLM API 与本地数字人形象串成对话原型，并需要评估显存、延迟、麦克风状态和素材生命周期管理的开发者。

补充说明：本文根据授权视频约 340 秒完整音频转写、视频简介和默认首屏评论整理；首屏未发现夸克网盘链接。转写中个别模型名称不够稳定，正文只保留能由简介项目链接和连续语义交叉确认的名称。作者明确表示不同环境遇到的问题差异很大，实际部署请以两个项目的官方说明和原视频画面为准。