最近随着AI+陪伴硬件受到更多的关注，看到了各种相关的方案发现基本都还是用的小智的这套架构来做，确实也能理解，因为最方便直接出demo，而且默认自带的的“台湾妹”语音更容易吸引眼球。我自己最近也用Seeed的一款硬件来玩了一下小智语音聊天机器人，确实融合了硬件后还是挺好玩的。同时顺手读了一下小智的技术文档，下面简单整理了小智的模型使用情况及其服务端代码分析供想玩的朋友们参考：
小智的模型使用情况1. ASR 相关
VAD（语音活动检测）：speech_fsmn_vad_zh-cn-16k-common-pytorch 用于检测语音的起始和结束，过滤掉静默和噪音；
核心 ASR：SenseVoiceSmall 用于将语音转换为文本，是小智语音识别的核心模型；
声纹识别模型：speech_eres2netv2w24s4ep4_sv_zh-cn_16k-common 用于识别说话人的身份，可以用于区分不同的用户；
2. LLM
官方FAQ页面说是基于 QWen 72B 进行“训练”和自部署，以及小智管理后台配置看是写的默认使用“Qwen 实时”；
QWen 是阿里开源的通义千问大语言模型，小智团队在其基础上进行了定制化的“训练”和部署，但具体细节尚未公开；
3. TTS 相关
火山引擎（Volcengine）
火山引擎的智能语音服务，提供多种音色的语音合成功能，默认的“湾湾小何”语音就是来自火山；
阿里云（Dashscope）
阿里云的智能语音服务；
“小智”项目服务端代码分析“小智”项目服务端代码主要由两个核心部分组成：ASR（语音识别）服务和 TTS（语音合成）服务。这两个服务分别负责将用户的语音转换为文字，以及将文字合成为语音。整体而言，该项目采用前后端分离的架构，后端主要使用 Node.js 和 Python 语言，通过 WebSocket 实现前后端以及内部服务之间的通信。
技术实现分析
ASR 服务
前端实现：前端 ASR 服务（asr-server）主要使用 Node.js 和 WebSocket 实现。它负责接收来自前端的音频数据，并通过manager.js将音频数据发送给后端的推理节点（asr-worker）。此外，前端还负责管理 ASR worker 的连接和会话，以及处理 ASR worker 返回的识别结果。
后端实现：后端 ASR 服务（asr-worker）主要使用 Python 实现。它负责接收来自前端的音频数据，并使用 FunASR 和 ModelScope 等模型进行语音识别和声纹识别。识别完成后，将识别结果（包括文本、音频向量和音频下载地址）发送回前端。
核心技术点：
使用 WebSocket 实现前后端实时通信。
使用`@discordjs/opus`进行音频数据的编解码。
使用 FunASR 和 ModelScope 等模型进行语音识别和声纹识别。
使用 OSS（阿里云对象存储服务）存储音频文件。
TTS 服务
前端实现：前端 TTS 服务（tts-server）主要使用 Node.js 和 WebSocket 实现。它负责接收来自前端的文本数据，并选择合适的 TTS worker（如 BytedanceTTS 或 DashscopeTTS）进行语音合成。合成完成后，将合成的语音数据发送回前端。
后端实现：后端 TTS 服务（bytedance_tts.js和dashscope_tts.js）主要实现了与第三方 TTS 服务（如火山引擎和阿里云灵积）的交互。它们负责将文本数据发送给第三方服务，并接收第三方服务返回的语音数据。
核心技术点：
使用 WebSocket 实现前后端实时通信。
支持多种第三方 TTS 服务，如火山引擎和阿里云灵积。
使用`@discordjs/opus`进行音频数据的编码。
实现音频数据的流式传输和速率控制。
其他技术点
环境变量管理：使用dotenv库管理环境变量，方便配置和部署。
日志管理：使用logging库记录日志，方便调试和问题排查。
依赖管理：使用package.json和requirements.txt管理项目依赖。
项目特点
前后端分离：项目采用前后端分离的架构，后端服务化，方便独立部署和扩展；
实时通信：使用 WebSocket 实现前后端以及内部服务之间的实时通信；
支持多种 ASR 和 TTS 模型：项目支持多种 ASR 和 TTS 模型，方便用户根据需求进行选择；
流式处理：ASR 和 TTS 服务都支持流式处理，可以实时返回识别和合成结果；
易于部署和扩展：项目使用 Docker 进行容器化部署，方便快捷；