最近有个需求一直绕不开在一台没有外网的环境里做一套私有语音助手声音数据一个字都不准出本机。我把FunASR、DeepSeek、离线TTS串起来端到端跑通之后发现这套组合其实没有想象中那么高门槛真正花时间的反而是装环境、模块对接和交互细节。这篇教程我把每一步怎么装、每一段代码怎么写的思路全部摊开讲适合手里有一台Linux机器、想自己折腾离线语音助手的开发者也适合做智能家居网关、终端语音交互这类项目的朋友。先说结论这套链路本质就是“听懂、思考、说话”三个环节FunASR负责听DeepSeek负责想TTS负责说。最难的不是任何一个模型的效果而是把三者的接口、依赖、延迟和异常处理理顺。下面从整体架构开始一步步来。1. 整条语音链路先拆开看谁在听、谁在想、谁在说1.1 三个模块的边界FunASR是阿里达摩院开源的一套语音识别工具包不能简单理解成一个模型它内部包含了多个组件。我用的组合是paraformer-zh作为主识别模型fsmn-vad做语音活动检测另外挂了一个ct-punc标点恢复模型。这样做的好处是VAD先把长音频里的说话片段找出来去掉大量静音标点模型再把识别出来的裸文本加上逗号句号后面给大模型的时候语义边界会清楚很多。DeepSeek负责的是“思考”这一层。它接收FunASR输出的文本理解用户意图生成回复文本。这里有个容易混淆的概念DeepSeek不是单一模型名而是一系列模型和API服务的总称。你可以本地拉它的开源权重也可以直接调用官方API两者在工程上差别很大我后面会单独讲。TTS负责把DeepSeek回复的文本变成音频。离线场景下我主要用MeloTTS中文发音自然度比较满意CPU也能跑得动。工程上我把TTS封装成一个输入文本、输出wav文件的函数不关心内部是哪个模型。1.2 为什么接口全部用文本整个流水线在接口层只传递两种东西文本和音频文件路径。麦克风音频 → [FunASR] → 文本 → [DeepSeek] → 回复文本 → [TTS] → wav文件 → 播放器我刻意让三个模块之间不共享任何内部状态。FunASR只负责把音频变文本DeepSeek只负责把问题变答案TTS只负责把答案变声音。这种设计的最大好处是调试方便任何一段输出出了问题你都可以把中间文本打印出来单独测某一个模块。比如发现回复不自然那就拿同一个prompt直接测LLM和ASR、TTS完全无关。1.3 这套组合适合放在哪些场景我实际把这套方案部署在办公室的Linux主机上用途是离线的知识问答和定时提醒。更典型的场景还包括无外网环境的工位助手、数据敏感区的语音录入终端、以及智能家居的本地语音网关。它的核心价值就两条隐私可控、免费无限调用。和云服务比少了很多“调用次数”的心理负担想怎么问就怎么问。2. 装环境之前的三个决策硬件、TTS引擎、DeepSeek部署方式2.1 先确认手里的机器能干什么很多人一上来就装大模型结果显卡扛不住整个流程直接劝退。我建议先给机器分个档机器条件可行的方案预期体验纯CPU无GPUFunASR小模型 TTS DeepSeek 1.5B/7B量化版能跑通但一句对话等待5~15秒6~8GB显存本地7B量化模型 全链路GPU加速流畅3秒内能听到回复16GB以上显存本地14B甚至更大模型体验接近云API没有本地算力但有网FunASR/TTS本地 DeepSeek官方API速度快、回复质量高但非纯离线我自己的主力机器是i5 RTX 3060 12GB跑7B量化模型比较舒服。如果你只是验证流程CPU方案也能跑通不要因为显卡不行就放弃后面我会给出对应的参数调整建议。2.2 TTS引擎选型对比TTS是整个链路里最容易“听出来廉价感”的环节。我对比过几款主流离线方案引擎是否离线中文自然度部署难度适合场景MeloTTS是好低通用助手推荐首选ChatTTS是很好带语气词中闲聊对话但稳定性一般Piper TTS是一般极低嵌入式、树莓派GPT-SoVITS是非常好可克隆音色高需要特定音色的场景Edge-TTS否好低能联网但不想折腾时用这里注意Edge-TTS虽然效果不错但本质是云服务不满足本教程的离线前提。我最终选MeloTTS原因很简单中文效果好、CPU能推理、几行代码就能跑起来。ChatTTS我也测过对话语气很丰富甚至能模拟口头禅和笑叹词但参数多、生成稳定性差一些放在后面对比。2.3 DeepSeek的三种接入方式怎么选DeepSeek接入我把它分成三条路线接入方式适合人群离线成本说明Ollama本地部署想自己掌控一切是免费一行命令拉模型适合新手vLLM本地部署生产环境、高并发是免费吞吐高但配置复杂官方API快速验证、有网否按token计费模型能力最强接入最简单我的建议很实际如果你是第一次搭这套链路先用Ollama本地部署跑通后面即便切换到API你的代码改动也只是一行base_url的问题。不要把某个具体接入方式焊死在你的架构里。3. FunASR离线识别把麦克风声音变成文字3.1 Linux上装FunASR及可能缺的系统依赖FunASR本身是个Python包但Linux上装它经常栽在系统依赖上。我建议按顺序执行避免装完才发现缺东西# 创建干净的Python环境推荐3.10 conda create -n voice python3.10 conda activate voice # 安装必要的系统级工具Ubuntu/Debian系 sudo apt update sudo apt install -y ffmpeg portaudio19-dev # 安装Python依赖 pip install funasr modelscope torchaudio soundfile librosaffmpeg和portaudio19-dev是我踩坑后补上的。FunASR底层处理音频时要调librosa而librosa解码各种格式音频依赖ffmpeg如果你后面要接实时麦克风sounddevice又依赖portaudio。这里一次性装好后面能省很多事。验证是否装好直接进Python执行python -c import funasr; print(funasr.__version__)正常输出版本号就说明安装成功。如果用Apple Silicon Macportaudio19-dev这条不适用需要自行通过Homebrew装portaudio其余一致。3.2 加载识别模型并跑通第一个音频文件环境没问题之后写一个最简识别脚本from funasr import AutoModel # 第一次运行会自动下载模型耐心等一会儿 model AutoModel( modelparaformer-zh, vad_modelfsmn-vad, vad_kwargs{max_single_segment_time: 30000}, punc_modelct-punc, devicecuda:0, # 没有GPU就改成 cpu hubmodelscope, ) res model.generate( inputtest.wav, batch_size_s300, hotword小助手, ) print(res[0][text])解释几个参数的意义。paraformer-zh是主识别模型中文识别效果好模型会从ModelScope自动下载首次运行需要等下载完成。vad_model是语音活动检测它的作用是先把一个长音频切分成若干“有人说话”的片段避免在静音段浪费算力。punc_model是标点恢复让输出带标点符号这在后续给LLM使用时特别重要。batch_size_s控制一次批量处理的音频时长设成300秒足够覆盖大多数录音。hotword是热词表比如你的助手叫“小助手”可以把这个词强化识别率会明显提升。注意model.generate返回的是一个列表每个元素是一个字典文本存在[text]字段里。我第一次用的时候直接打印整个返回值给调试造成了一点困惑先提醒一下。3.3 长音频和实时麦克风的处理思路上面的脚本适合处理已经存在的wav文件。但语音助手场景通常是“录一段、识别一段、再录一段”这里涉及两个问题一是录音转存二是静音过滤。对于实时麦克风我推荐一个既简单又稳定的做法用sounddevice录音并直接保存成wav然后把wav路径交给FunASR。示例代码import sounddevice as sd import soundfile as sf import numpy as np fs 16000 duration 3.0 # 录音时长可调 recording sd.rec(int(fs * duration), sampleratefs, channels1, dtypefloat32) sd.wait() sf.write(input.wav, recording, fs)这里采样率设成16000是FunASR模型比较友好的范围。录完之后再调用model.generate识别即可。如果你想要“检测到人说话才开始识别”的效果可以用VAD模型对音频片段做静音过滤或者更简单地在录音过程里实时计算音量音量低于阈值就不保存。先把基础流程跑通再优化交互体验。3.4 FunASR实测表现和两个高频坑实测下来paraformer-zh对普通话的识别准确率很能打即使有一些环境噪声也没问题。但在两个坑让我花了不少时间第一个坑是首次运行下载模型太慢。解决方案是提前手动下载模型文件放到缓存目录或者配置MODELSCOPE_CACHE环境变量来指定模型缓存位置避免每次都在同一个目录反复下载。第二个坑是缺少音频后端导致读取wav报错。解决方法是装soundfile和ffmpeg。别小看这个问题代码层面不会直接告诉你缺ffmpeg而是报一个“librosa无法解析音频”的异常排查方向容易被带偏。4. DeepSeek大脑本地模型和官方API怎么选、怎么搭4.1 本地部署路线Ollama拉取DeepSeek模型Ollama是目前本地部署大模型最省心的方案它把模型下载、服务启动、API接口都封装好了。安装和启动非常简单# Linux一键脚本按官方文档执行 curl -fsSL https://ollama.com/install.sh | sh # 启动服务 ollama serve拉取模型时去Ollama仓库搜索deepseek-r1等模型名按你显存大小选择量化版本。以7B为例ollama pull deepseek-r1:7b拉取完成后Ollama默认监听localhost:11434提供OpenAI兼容的HTTP接口。Python调用示例import requests def ask_local_llm(prompt, modeldeepseek-r1:7b): resp requests.post( http://localhost:11434/api/chat, json{ model: model, messages: [ {role: system, content: 你是一个简洁的语音助手用中文口语化回答控制在两句话以内。}, {role: user, content: prompt}, ], stream: False, options: {temperature: 0.7, top_p: 0.9}, }, timeout60, ) return resp.json()[message][content]这里temperature和top_p是LLM的采样参数。温度越高回复越发散语音助手场景我建议适中偏低0.7左右比较好既能保证稳定又不会显得死板。timeout一定要设置否则模型推理慢的时候请求会一直挂着导致整个语音助手“假死”。4.2 官方API路线十几行代码接入如果不想折腾显卡或者对回复质量有更高要求直接用官方API是最快的方式。DeepSeek API的兼容性做得比较好直接用OpenAI SDK就能调from openai import OpenAI client OpenAI( api_keysk-你的key, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个简洁的语音助手。}, {role: user, content: 现在几点}, ], streamFalse, ) print(resp.choices[0].message.content)API路线的好处是模型大、推理快、不用维护本地服务缺点也很明显它要求有稳定的网络环境且不是离线方案。我把它作为“快速原型”的首选等把整个语音助手逻辑调通之后再切换到本地模型做最终部署。4.3 路由选择建议用对话模型而非推理模型作为助手大脑这点是我在真实使用中体会最深的语音助手的“大脑”应该选对话模型而不是推理模型。DeepSeek的推理模型比如R1系列在数学、逻辑题上很强但它们的输出经常带着一大段思考过程对语音播报来说完全是灾难——用户问一句话模型先“内心复盘”半天回复速度慢输出也冗长。语音交互对延迟极其敏感用户说完话之后超过3秒还没有回应就会明显觉得“卡”。所以我建议主力使用对话模型回复质量足够速度更快输出更符合播报习惯。如果你只有推理模型可用也可以通过system prompt让它不要输出思考过程但效果不如直接用对话模型来得干净。4.4 为语音交互定制system prompt给LLM的system prompt是这一整套方案里性价比最高的优化点。语音和文字聊天的最大区别是文字用户可以慢慢看长回答语音用户听不了啰嗦内容。所以我把prompt明确写成你是运行在离线设备上的语音助手。 - 全部用中文回答 - 口语化、自然像真人说话 - 回答控制在两句话以内一般不超过40字 - 不要使用markdown、列表、括号备注 - 不要输出解释性内容实测下来这样一套约束能把回复长度从平均100多字压到30字左右TTS播报时长明显缩短整个对话节奏舒服很多。说到底语音助手的核心体验不是“聪明”而是“快、短、准”。5. 离线TTS让声音不“机械”的选型与接入5.1 用MeloTTS把文字合成中文语音MeloTTS是我目前在离线TTS里的首选方案。它的安装和使用都很轻量pip install melotts使用代码from melo.api import TTS # 加载中文模型cpu或cuda均可 model TTS(languageZH, deviceauto) speaker_ids model.hps.data.spk2id output_path reply.wav # speed1.0为正常语速我建议设成1.1~1.2听起来更自然 model.tts_to_file( 你好我是你的离线语音助手请问有什么需要帮助的, speaker_ids[ZH], output_path, speed1.1, )第一次运行时MeloTTS会自动下载权重文件等一会就好。deviceauto会自动检测CUDA如果没有GPU就回退CPU。我实测CPU模式下合成一句10字以内的回复大约1秒多完全可接受。关于speed参数我想多说一句TTS默认1.0语速在中文里听着偏慢调到1.1或者1.2之后声音节奏更接近真人说话也显得更“聪明”。这是我调了好几个音色参数之后得出来的结论你可以直接抄作业。5.2 ChatTTS和Piper在何时替换如果MeloTTS的音色不能满足你的需求两个备选方案值得了解。ChatTTS的优势是对话感极强生成的语音带有停顿、笑叹和语气变化很接近真人聊天。但它也有明显问题需要较长的生成时间GPU占了也不低而且有时候会生成奇怪的语气词打断语义。我的建议是做“陪伴闲聊”类产品时试ChatTTS做“任务问答”类助手时老老实实用MeloTTS。Piper则是极轻量路线模型极小、CPU上运行飞快适合树莓派这种低算力终端。中文发音自然度一般有点机械感但在“能说话”和“说得好听”之间Piper明显倾斜于前者。如果碰巧你的设备功耗极低Piper是个实用的选择。5.3 播放端把生成的音频真正放出来TTS生成的是wav文件最后一步是把它播放出来。Linux命令行最简单aplay reply.wav在Python里我习惯这样写import subprocess def play_audio(file_path): subprocess.run([aplay, file_path], checkTrue)这样最稳不依赖额外的Python库。如果你在Windows上可以把命令换成powershell -c (New-Object Media.SoundPlayer reply.wav).PlaySync()。核心思想一样把播放逻辑和TTS逻辑解耦替换成本很低。6. 把三块拼成完整助手工程细节和延迟优化6.1 封装三个引擎接口前面的环境搭建和单模块验证都跑通之后就到了工程落地阶段。我强烈建议先把三个引擎封装成独立模块每个模块只暴露一个稳定接口# asr_engine.py from funasr import AutoModel class ASREngine: def __init__(self, devicecuda:0): self.model AutoModel( modelparaformer-zh, vad_modelfsmn-vad, punc_modelct-punc, devicedevice, hubmodelscope, ) def recognize(self, wav_path): res self.model.generate(inputwav_path) return res[0][text]# llm_engine.py import requests class LLMEngine: def __init__(self, modeldeepseek-r1:7b, base_urlhttp://localhost:11434): self.model model self.base_url base_url self.system_prompt ( 你是运行在离线设备上的语音助手。 全部用中文回答口语化自然 回答控制在两句话以内一般不超过40字。 不要使用markdown、列表、括号不要输出解释。 ) def chat(self, user_text): resp requests.post( f{self.base_url}/api/chat, json{ model: self.model, messages: [ {role: system, content: self.system_prompt}, {role: user, content: user_text}, ], stream: False, options: {temperature: 0.7}, }, timeout60, ) return resp.json()[message][content]# tts_engine.py from melo.api import TTS class TTSEngine: def __init__(self): self.model TTS(languageZH, deviceauto) self.speaker_id self.model.hps.data.spk2id[ZH] def synthesize(self, text, output_pathreply.wav, speed1.1): self.model.tts_to_file(text, self.speaker_id, output_path, speedspeed) return output_path这样封装之后三个模块之间完全解耦。想换DeepSeek的API只改LLMEngine内部的chat方法就行。想换TTS换TTSEngine一个文件即可。这个设计在后续迭代中的作用远比你想象的大。6.2 主循环录音、识别、生成、合成、播放主循环代码核心逻辑就是循环录音识别判断内容请求LLM合成语音播放。import sounddevice as sd import soundfile as sf import subprocess from asr_engine import ASREngine from llm_engine import LLMEngine from tts_engine import TTSEngine asr ASREngine(devicecuda:0) llm LLMEngine(modeldeepseek-r1:7b) tts TTSEngine() WAKE_WORD 小助手 def record(duration3.0, fs16000): audio sd.rec(int(fs * duration), sampleratefs, channels1, dtypefloat32) sd.wait() wav_path input.wav sf.write(wav_path, audio, fs) return wav_path def play(wav_path): subprocess.run([aplay, wav_path], checkTrue) def main(): print(语音助手已启动录音完成后自动识别...) while True: wav_path record() text asr.recognize(wav_path).strip() if not text: continue print(f[用户] {text}) # 只有包含唤醒词才响应避免把环境噪音当成命令 if WAKE_WORD not in text: continue # 去掉唤醒词本身把剩余内容交给LLM clean_text text.replace(WAKE_WORD, , 1).strip() if not clean_text: continue reply llm.chat(clean_text) print(f[助手] {reply}) audio_path tts.synthesize(reply) play(audio_path) if __name__ __main__: main()这里面有一个工程细节值得注意record()函数每次都从头开始录固定时长实际使用中会出现录到一半才开始说话、尾部被截断的问题。想要更稳可以改成“检测到音量超过阈值才开始保存安静后再停”本质上需要VAD判断。简单起见先跑通这个版本再把录音段换成动态截取。6.3 加入唤醒词避免每句话都被响应唤醒词在离线语音助手里不只是“魔法咒语”更是一种噪声过滤机制。如果系统对每一句识别文本都去请求LLM那邻居说话、电视声、敲键盘声全都会被当成指令体验极差。我用的是文本级唤醒把唤醒词写进FunASR的hotword参数强化识别然后在主循环里判断if WAKE_WORD not in text不包含就跳过。这套方案简单可靠缺点是需要说完唤醒词才能继续不像“小爱同学”那样支持边听边唤醒。如果你追求更自然的全双工体验就得引入单独的唤醒词检测模型那属于另一个更复杂的工程不建议第一次就上。6.4 延迟实测与优化手段以我的机器i5-12400 RTX 3060 12GB为例跑完整的“录音3秒 FunASR识别 DeepSeek 7B生成 MeloTTS合成 播放”链路延迟分布大致如下环节耗时录音3秒ASR识别0.2~0.5秒LLM生成1~4秒TTS合成0.3~1秒播放语音时长这里录音3秒是硬性的用户不说话也在录。真正可以优化的是录音阶段接上VAD之后用户一开口再开始录音能省掉大量等待。LLM生成是最大瓶颈解决方式是换更小模型、加max_tokens限制、或者用API。TTS方面MeloTTS已经够快如果还不够可以考虑把生成和播放切成异步流水线TTS合成第一句的同时开始播放形成“边合成边播”的效果。7. 我在真实场景跑了两个月的几点体会整套系统放在办公室用了一段时间最大的感受是技术层面的瓶颈远不如交互设计来得重要。最初我以为最麻烦的是ASR识别不准或者TTS声音难听实际用了才发现最难的是让用户知道什么时候该说话。按键触发和唤醒词都试过之后我最终保留了“先录音、再判断是否包含唤醒词”的简单模式虽然不够酷但足够稳定家里人也能轻松上手。第二个体会是CPU方案完全能跑但体验是“能用”和“好用”的差距。如果你的主机器有NVIDIA显卡全链路GPU加速带来的流畅度提升比换任何模型都明显。反过来如果你只有一台旧笔记本也不要气馁把DeepSeek模型换成1.5B的量化版然后接受10秒级别的响应做定时提醒、百科问答这类场景依旧绰绰有余。最后分享一个我一直在用的小技巧把TTS语速调到1.1把LLM的回复长度压缩到30字以内整个助手的听感会一下子“聪明”起来。语音交互的体验核心不是模型多强而是每一轮对话有多快、多短、多自然。你先把这条链路跑通再根据实际反馈慢慢迭代很快就能找到属于自己的最佳参数组合。