简介这是一套基于语音交互的智能对话系统开源实现聚焦实时语音输入与大型语言模型响应面向希望摆脱云端依赖、在个人电脑或低算力硬件上离线部署语音助手的开发者和AI研究者解决低延迟自然对话与本地私有化运行两大痛点。压缩包共37个文件仅113KB包体紧凑内容以Rust核心源码为主辅以TypeScript/JavaScript前端脚本、Cargo与package配置文件并带有Dockerfile、跨平台启停脚本、架构图PNG、说明文档与许可证文件类型与模块划分一目了然。已有136人学习下载。资源内含完整sage-main代码库覆盖语音识别、模型调用、前端交互等关键链路附赠资源.docx可作使用指南或API参考说明文件.txt提供快速启动与排障步骤README则梳理了整体设计方便开发者直接复现、二次开发或移植到自己的硬件环境。1. 基于语音交互的智能对话系统一条在个人硬件上跑通语音 LLM 的务实路径语音交互的智能对话系统老实说是这些年我在个人硬件上见到过最典型的「看着容易、做起来全是细节」的项目。标题里真正有分量的约束不是「能用语音和大型语言模型聊天」而是离线自托管部署和模块化设计——这意味着你面对的不是一个黑匣子聊天机器人而是一整套由语音识别、推理引擎、语音合成与消息编排组成的本地管线还要让它跑在消费级硬件上。这套方案能解决什么不依赖云端 API 的隐私对话、断网可用的语音助手、以及每个组件都能单独替换的可持续维护架构。适合谁想把开源工具落地到自己电脑或家用服务器上的工程师也适合想拆解语音 LLM 各个环节做二次开发的人。下面这篇我从架构选型一路写到部署步骤、模块接口再落到我踩过的四个具体坑。2. 语音交互系统的四段式架构ASR、LLM、TTS 与消息总线的选型逻辑一套实时的语音对话系统拆开看永远跑不出四条链路语音识别ASR→ 意图理解与生成LLM→ 语音合成TTS→ 模块间消息编排。很多人的第一版翻车就是因为把这四件事揉进了同一个进程、同一个线程最后延迟、崩溃、资源占用互相打架。先把架构拆对后面所有事都顺。2.1 ASR 选型流式识别是实时对话的及格线语音交互的「实时感」主要来自 ASR 这一段。非流式方案要等用户说完、录音结束才开始识别一段 5 秒的话往往要再等 23 秒才出文字对话节奏直接垮掉流式方案在用户说话的同时就吐 partial 结果停顿 500 毫秒左右基本能看到完整句子。对实时对话来说流式不是加分项是及格线。常见开源工具里我按自己的使用经验排个序方案流式中文支持资源占用适用场景faster-whisper否需自行切片好显存 2GB 起有 GPU、能接受整句识别whisper.cpp否好CPU 为主纯 CPU 小机器sherpa-onnx是好CPU 可跑内存 1GB 内离线实时对话首选Vosk是中上极低树莓派级设备我一般会给这类项目配 sherpa-onnx 的流式 Zipformer 模型16kHz 采样率、CPU 实时率在 0.3 以下意思是你讲 1 秒它用 0.3 秒处理完给 LLM 和 TTS 留出大量余量。如果你手头只有整段识别的模型也不要急着换——在 VAD 层把音频切成长度 38 秒的片段把「切完之后立刻识别并送回结果」当伪流式用体验也比干等全句结束好得多。2.2 LLM 推理引擎选型量化等级与消费级显存预算LLM 这一段的核心矛盾是显存。个人消费级硬件最常见的两块分水岭6GB 显存GTX 1660 / RTX 3050 / RTX 4060和 16GB 内存的 CPU-only 机器。在这两个区间7B 模型的 Q4 量化是最稳的选择——模型权重约 4.5GB加上 KV cache 和运行时开销6GB 显存能塞下但余量不大CPU-only 的话内存占用能控制在 6GB 以内速度在 58 token/s 左右能用但不算流畅。选推理后端时我踩过一次「拿着服务器思维套个人硬件」的坑。vLLM 吞吐确实强但它为了并发做了大量显存预留和调度单用户场景反而浪费严重。llama.cpp 的量化格式和内存映射做得更贴近消费级场景Ollama 则是基于它封装出的更友好的开源工具。我的结论是能接受命令行就用 llama.cpp想要 API 和管理界面就用 Ollama两者底层是同一套量化路线模型文件可以互通。解码参数里有两个必须调。第一个是max_tokens实时对话场景每条回复 200400 token 足够默认的 2048 会让 TTS 等太久第二个是temperature语音对话的情绪链路比文本对话更怕胡言乱语我一般压在 0.60.8。这两个参数不改延迟和稳定性都会出问题。2.3 TTS 选型首包延迟比音色更影响对话体验很多人选 TTS 先听音色但实时对话场景里首包延迟才是决定生死的那一项。用户说完话到听到回复中间经过 ASR、LLM 两段已经花掉一两秒留给 TTS 的心理余量很小。如果 TTS 先等整句合成完再播放用户会觉得「卡了一下」如果它能边合成边播放哪怕音色平一点体感都会流畅很多。开源工具里我推荐 Piper它输出 ONNX 格式的神经 TTS 模型CPU 上实时率能做到 0.5 左右中文音色够用而且天然支持按句子切分流式合成。极端低配场景可以用 espeak-ng体积只几兆但机械感极重适合做调试占位不适合最终交付。需要避开的坑是 edge-tts 这类在线接口——它虽然音色自然但要求联网跟这个项目的「离线自托管部署」目标直接冲突只适合开发期临时验证链路。如果你想省事有个常见做法是给 TTS 单独起一个常驻进程对外暴露一个本地 HTTP 端口。这样无论后面怎么换 TTS主进程都不用重新编译只改配置文件里的地址。模块化思维从这个进程边界就开始了。2.4 模块间通信统一事件格式串起整个语音对话流程ASR、LLM、TTS 各自跑在自己的进程里怎么把它们串起来答案是一层统一的事件消息。我见过有人用共享文件夹、用 Redis 队列、用数据库轮询都能跑但都不优雅。最务实的是本地用 WebSocket 或 ZMQ跨设备用 MQTT消息体统一 JSON事件类型定死不上浮。{ event: asr_final, session_id: 9f2c, text: 今天天气怎么样, audio_meta: { sample_rate: 16000, duration_ms: 1800 }, ts_ms: 1716300000123 }这段事件的event字段是管线里最关键的约定。我一般会定这几类wakeup唤醒词触发、asr_partial识别中间结果、asr_final一句话识别完成、llm_start/llm_stream/llm_final大模型开始/增量/完成、tts_chunk/tts_final语音合成音频分片/完成。每个模块只消费自己关注的事件再把结果包装成新事件发出去。这样做的好处是换任何模块都只动它自己的输入输出适配其他模块完全不用感知。3. 离线自托管部署实操从零到一在个人电脑上跑通语音对话架构定完接下来就是动手。这一章我按自己实际部署的顺序写硬件基线、环境依赖、主循环编排、启动预热。跟着做一台普通的 x86 电脑就能在半天内跑起一个能对话的本地语音助手。3.1 硬件基线CPU-only 与入门 GPU 两种可复现的配置先说我能接受的底线。CPU-only 方案4 核 8GB 内存是能跑的下限但 ASR、LLM、TTS 三链路同时常驻会吃紧建议至少 8GB 内存如果追求「对话不卡顿」推荐 8 核 16GBLLM 用 7B Q4 量化能有 812 token/s。带 GPU 的方案6GB 显存是甜点实测 7B Q4 能跑到 1525 token/s配合流式 ASR 和分片 TTS端到端延迟可以压进 2 秒以内这个水平日常对话完全够用。操作系统我建议 Ubuntu 22.04 或 Debian 12原因是这套工具链的预编译包和依赖在这两个系统上最齐全。Windows 上也能跑但 CUDA 环境配置和进程管理要费更多功夫。存储方面给模型留 10GB 左右空间足够ASR 模型 200MB、LLM 量化模型 4.5GB、TTS 模型 150MB都算进去了。3.2 环境初始化安装开源语音与 LLM 推理链路的依赖下面这段脚本是 Python 虚拟环境加核心依赖的安装顺序我在新机器上基本都这么来一遍mkdir -p ~/voice-llm/{models,logs,venv} cd ~/voice-llm python3 -m venv venv source venv/bin/activate pip install --upgrade pip # 语音识别后端提供流式 ASR 的 Python 绑定 pip install sherpa-onnx sounddevice numpy # 音频处理与 VAD pip install webrtcvad pyaudio # LLM 推理后端使用 llama-cpp-python 的 CPU/GPU 统一版本 pip install llama-cpp-python # TTS 直接下载预编译二进制放 models/ 目录python 侧只调 HTTP 接口 curl -L -o models/piper.tar.gz piper下载地址 tar xzf models/piper.tar.gz -C models/代码逻辑不复杂但顺序有讲究先建好虚拟环境和目录结构再装 ASR 依赖最后处理 TTS。我把 TTS 的安装方式写成「下载预编译二进制」而不是 pip 装因为它带独立的可执行文件和模型目录做成独立进程比塞进 Python 环境更容易替换。sounddevice负责录音和播放webrtcvad做人声检测——VAD 在后面避坑章节会反复出现它决定了断句质量。参数说明sherpa-onnx需要配套下载对应语言模型文件中文推荐sherpa-onnx-streaming-zipformer-zh系列下载后把model.onnx路径存到配置文件llama-cpp-python默认编 CPU 版如果你的机器有 CUDA安装前先设CMAKE_ARGS-DGGML_CUDAon这一点最容易忽略装错了只能重编。3.3 编排主循环用 asyncio 串起「听到说话→LLM 回复→语音播报」核心编排代码不复杂但一定要用异步队列把三段链路解耦。下面是我维护过的一个最小骨架把 ASR 的识别结果通过队列送给 LLMLLM 增量输出再经 TTS 播放import asyncio import queue from dataclasses import dataclass dataclass class VoiceEvent: event: str text: str audio_chunk: bytes b class VoicePipeline: def __init__(self, asr, llm, tts): self.asr asr self.llm llm self.tts tts self.asr_queue asyncio.Queue() self.llm_queue asyncio.Queue() self.tts_queue asyncio.Queue() self.speaking False # 半双工标志TTS 播报时暂停 ASR async def run(self): # 三个消费循环彼此独立互不阻塞 await asyncio.gather( self._asr_loop(), self._llm_loop(), self._tts_loop(), ) async def _asr_loop(self): while True: audio await self.asr_queue.get() resp self.asr.recognize(audio) if resp[is_final] and not self.speaking: await self.llm_queue.put(VoiceEvent(asr_final, textresp[text])) async def _llm_loop(self): while True: evt await self.llm_queue.get() prompt f你是本地语音助手用简短口语回答{evt.text} async for chunk in self.llm.stream_chat(prompt): await self.tts_queue.put(VoiceEvent(llm_stream, textchunk)) async def _tts_loop(self): while True: evt await self.tts_queue.get() self.speaking True await self.tts.play_text(evt.text) # 流式合成并播放 self.speaking False代码的关键点在三个asyncio.Queue和三个_loop。ASR、LLM、TTS 分别有自己的消费循环谁慢都不会阻塞谁——ASR 卡了不影响 TTS 把上一句话播完。self.speaking是半双工开关TTS 播放期间 ASR 不再往里送结果防止播报内容被自己识别一遍这个标志位在回声问题上会反复用到。参数说明stream_chat是流式接口LLM 每生成几个 token 就 yield 一次TTS 拿到片段立刻合成不必等整句。实际使用时把max_tokens控制在 256 内LLM 首 token 延迟能低不少。play_text内部如果用 Piper会对长文本按标点自动切分每切出一句就合成立即播放。3.4 服务启动顺序与自托管脚本先预热再对外提供语音交互进程的启动顺序我吃过亏之后总结了一个固定套路先起 TTS再起 LLM最后起 ASR 和主进程。理由很直接TTS 模型小加载快、但播放设备初始化可能要探测声卡LLM 模型大加载和预热最慢ASR 常驻后就开始占麦克风如果前面没准备好用户一说话结果没人接体验很差。#!/usr/bin/env bash # 自托管语音对话系统启动脚本 cd ~/voice-llm echo [1/3] 启动 TTS 服务... nohup models/piper/piper --http_server 0.0.0.0:5000 \ --model models/piper/zh_CN-huayan-medium.onnx logs/tts.log 21 echo [2/3] 启动 LLM 推理服务... nohup venv/bin/python -m llama_cpp.server \ --model models/llm/qwen-7b-q4.gguf \ --n_gpu_layers 99 --port 8080 logs/llm.log 21 echo 等待 LLM 模型加载完成... until curl -s localhost:8080/health | grep -q ok; do sleep 2; done echo [3/3] 启动主编排进程... nohup venv/bin/python main.py logs/pipeline.log 21 脚本里那个until curl的循环值得单独说。llama.cpp 的 HTTP 服务启动后模型 mmap 加载需要几十秒如果不做健康检查就启动主进程主进程第一轮请求会直接连接失败或超时。加了这层等待之后整个系统的启动从「大概率翻车」变成「每次都成功」。参数说明--n_gpu_layers 99表示尽可能把 Transformer 层都塞进 GPUCPU-only 机器改成0TTS 的 HTTP 端口 5000 和 LLM 的 8080 在后续模块化改造时都要写进配置文件不建议硬编码。启动脚本可以配合 systemd Units实现开机自启和崩溃拉起这个我放在最后一章聊验证方法时一并展开。4. 模块化设计落地可替换组件的最小接口约定标题里「模块化设计」四个字放在这个项目里的真实含义是LLM 模型三个月换一代ASR 和 TTS 也在快速演进你的架构必须让更换任意一个组件都不动其他代码。这一章给出我落地时使用的接口约定以及一次真实的替换过程。4.1 为什么语音对话系统必须模块化模型换代速度远超你的预期大语言模型的迭代速度用「月」计算。你今年基于某个 7B 模型调好了一版下个月就有新模型推理速度更快、中文更好语音合成同理——开源社区每月都有音色更自然的模型放出来。如果这些组件全粘连在一个进程里每次升级都要重新测试全链路那是自己给自己造维护地狱。模块化的第二个收益在硬件升级路径上。我最初在 CPU-only 机器上跑通后来加了一块显卡改造只发生在 LLM 推理这一层——把 llama.cpp 的--n_gpu_layers调大、模型路径不变、其他模块无感。反过来如果某天你觉得 ASR 的唤醒词误报太多想换成 Vosk同样只需要改 ASR 适配器。这种「想换哪块换哪块」的能力就是模块化设计对个人维护者最大的回报。但这里也要划条边界不要过度设计。个人项目里模块化的目标是把「替换成本」降下来而不是做出微服务治理。三个独立进程加一个统一事件格式已经足够SPI、依赖注入、注册中心那套东西是这个体量不需要的。4.2 组件接口定义统一事件结构让 ASR、LLM、TTS 解耦我落地过的一套最小接口用 Python 的Protocol定义核心就三个方法占位from typing import AsyncIterator from dataclasses import dataclass from typing import Protocol dataclass class AudioChunk: data: bytes sample_rate: int 16000 class ASRModule(Protocol): def recognize_stream(self) - AsyncIterator[dict]: 从麦克风读取音频流持续产出识别事件 ... yield {event: asr_partial, text: 你好} yield {event: asr_final, text: 你好今天天气怎么样} class LLMModule(Protocol): async def stream_chat(self, prompt: str) - AsyncIterator[str]: 输入完整 prompt产出增量文本 ... yield 今天 class TTSModule(Protocol): async def play_text(self, text: str) - None: 把文本合成语音并阻塞播放至结束 ...这套定义刻意压到最薄ASR 只需产出asr_partial/asr_finalLLM 只需把增量文本逐段抛出来TTS 只需能把一句话播完。每个模块的消费者只依赖这个Protocol不感知具体实现。你在自己的项目里可以把Protocol换成抽象基类但要点相同方法与事件的语义定死方法内部怎么做不管。接口定为 16kHz 采样率也有讲究。ASR 模型、VAD 和人声采集全部统一到 16kHz避免了重采样带来的额外延迟TTS 输出虽然可以是 22.05kHz 或 44.1kHz但播放环节会自动处理不需要外层感知。4.3 替换一个模块的最小改动以换 TTS 为例的两小时改造光说接口没用拿一次真实替换来说明改动边界。假设你嫌 Piper 音色不够自然想换成另一个神经网络 TTS。替换步骤拆开看新 TTS 如果输出 WAV 文件写成独立进程监听 5000 端口把文本 POST 过去返回 WAV 字节——这是一次性的适配层代码新 TTS 如果支持流式分句就按标点切好逐句返回不支持就把整段返回播放端缓冲即可主进程的tts_queue消费逻辑不动因为play_text的语义还是「把这段话播完」。这个过程中 llm_queue、asr_queue、半双工开关、事件格式全部不需要改。真正要动的只有两处配置文件的 TTS 地址如果新服务换端口以及tts_loop里处理返回音频格式的几行代码比如把 44.1kHz、16bit 的 WAV 重采样到播放设备支持的格式。如果新 TTS 输出格式和旧的一致那这次替换连代码都不用改只换进程和模型目录。反过来看如果系统一开始没有这层进程边界替换 TTS 意味着改主进程引用、处理初始化顺序、重新测试 VAD 和播放的并发逻辑——半天起步。这多出来的三小时就是模块化的价值。4.4 模块化带来的扩展可能拾音端与推理端分离的一种常见做法模块化的另一个顺带红利是你可以把不同的模块放到不同的设备上。一个典型场景一台老笔记本或树莓派做拾音端插着麦克风放在客厅主力 PC 做推理跑 LLM 和 TTS。两端通过 MQTT 通信事件格式就是 2.4 节那套 JSON。拾音端的工作很简单采集音频、跑 VAD 和 ASR把asr_final事件发布到voice/asr主题推理端订阅该主题跑完 LLM 和 TTS把tts_chunk音频帧发布到voice/tts主题拾音端再订阅voice/tts播放。真正改动的地方只有通信层模块接口都不用动。这种扩展能力在单体架构里想都不敢想——这也是我在任何语音 LLM 项目里坚持模块化设计的根本原因。5. 实时语音对话的常见问题与排查断句、冷启动、回声与中文识别离线语音对话项目踩坑太正常了我自己就是从「每轮对话都用不了」调到「亲戚朋友愿意多说几句话」的。这一章把我认为最有代表性的四类问题按「现象→原因→解决」写清楚。5.1 现象说话中间停顿一下就被当成一句话处理了用户说「我想查一下呃明天的天气」在「查一下」后面停顿了 1 秒系统直接判定这句话说完了把「我想查一下」送给 LLM返回一句莫名其妙的回答。这是语音对话里最常见的翻车点。原因是 VAD 的静音判定太灵敏。webrtcvad 默认的静音超时 500ms 是给短命令设计的对长句和自然口语来说太短。解决思路是调长静音超时到 8001200ms同时在 LLM 的 prompt 里加一句「如果用户指令不完整可以反问确认」。前者治标后者治本import webrtcvad vad webrtcvad.Vad() vad.set_mode(1) # 0 最宽松3 最严格口语对话建议 1 SILENCE_TIMEOUT_MS 1000 # 原来是 500口语对话调到 1000参数说明set_mode(1)比默认的2更宽容对背景噪音和轻声说话更友好SILENCE_TIMEOUT_MS调大后代价是用户说完话到 ASR 出结果的时间变长。我试过 1500ms识别率高但延迟太明显1000ms 是口语对话里体感较好的折中值。另外可以给 ASR 加一个「最大语音长度」上限比如 15 秒防止用户一直不停地说导致后续链路饿死。5.2 现象第一轮对话等很久之后恢复正常系统刚启动时用户说的第一句话要等 10 多秒才听到回复但从第二轮开始就快很多。很多人以为代码有问题其实不是。原因是 LLM 模型首次推理前要做多项初始化从磁盘 mmap 加载 4GB 权重、建立 CUDA context、分配 KV cacheTTS 也要在首次合成时加载 ONNX 会话和线程池。这些一次性开销全部摊在了第一轮请求里。解决思路是启动时做一次预热的假请求import time def warmup_llm(llm, prompt: str 你好): start time.time() for _ in llm.stream_chat(prompt): pass # 丢弃预热输出只触发完整推理链路 print(f[warmup] LLM 预热耗时 {time.time() - start:.1f}s)代码的作用是在主进程对外接受语音输入前用一句「你好」把 LLM 的首次推理代价先付掉。预热请求最好放在启动脚本的「等待 LLM 健康检查通过」之后确保--n_gpu_layers的权重加载已完成。TTS 也可以预热一次让它加载好语音模型并完成一次合成这样真实对话的 TTS 首包延迟从 500ms 降到 100ms 级别。5.3 现象TTS 播报过程中麦克风把播报内容又识别进去典型场景你问「现在几点」系统回答「现在是下午三点十五分」结果这句话说了一半ASR 又识别出「现在是下午」并触发下一轮 LLM 调用形成自我对话的循环。这种现象在环境安静的房间里尤其严重。原因是麦克风采集到了扬声器播出的声音系统没有做回声消除AECASR 也不会分辨声音来源是人还是音箱。解决有三条路按优先级排使用耳机或带硬件 AEC 的麦克风阵列——最省事音质和体验都更好半双工控制TTS 播放期间暂停 ASR 送入 LLM就是第 3 章代码里self.speaking的用途。虽然会损失「边听边说」的能力但对话逻辑最稳双工场景引入软件 AEC用sounddevice把播放参考信号同步给 AEC 算法这是专业语音助手的做法复杂度明显上台阶。个人项目我强烈建议先做半双工原因是它的改动量只有几行但效果立竿见影。等对话流程稳定以后再考虑软 AEC追求「TTS 说话时可以插话打断」的体验那是另一套复杂度。5.4 现象中文识别标点乱、数字错同一个模型英文却很好同样是本地 ASR识别「今天 temperature 是二十度」这种中英混合句子时英文单词被拆得七零八落中文标点也经常丢。很多人在模型上反复换版本其实问题不在模型在推理参数。原因是流式模型默认的解码策略偏向速度对数字、混合语言的上下文利用不足。我用的解法有两个一是给识别热词表注入常见语料二是调低解码的 beam search 温度。以 sherpa-onnx 为例import sherpa_onnx config sherpa_onnx.OnlineRecognizerConfig( modelzh-zipformer-streaming.onnx, decoding_methodgreedy_search, # 调试期先用贪心稳定后换 beam_search max_active_paths30, enable_endpoint_detectionTrue, rule_fstshotwords.fst, # 注入领域热词如天气明天温度 ) recognizer sherpa_onnx.OnlineRecognizer(config)参数说明max_active_paths从 10 调到 30 能让 beam 保留更多候选路径中文识别字准率明显上升代价是 CPU 占用小幅增加rule_fsts是热词加权文件把「天气」「温度」这类对话高频词放进去后识别「明天天气怎么样」的成功率高非常多。纯英文效果好中文差的问题多半是模型没带中文语料适配或热词缺失先从这两个参数排查比换模型快得多。6. 把端到端延迟从 3 秒压到 1 秒分段测量与三处关键调优延迟是语音交互体验的最终裁决者。3 秒的延迟会让用户觉得「系统迟钝」1 秒内则基本接近真人对话的节奏。这里我给出一套能落地的分段测量方法和三个实际有效的调优方向。测延迟的第一步是让它可见。我在主进程里埋过一段统计代码事件每次流转都打时间戳class LatencyTracker: def __init__(self): self.timestamps {} def mark(self, stage: str): self.timestamps[stage] time.time() * 1000 def report(self) - dict: t self.timestamps return { asr_ms: t.get(asr_final, 0) - t.get(audio_end, 0), llm_first_ms: t.get(llm_first, 0) - t.get(asr_final, 0), tts_first_ms: t.get(tts_first, 0) - t.get(llm_final, 0), }这段代码的用法是在录音结束、ASR 出最终结果、LLM 吐出第一个 token、TTS 播放第一帧这四个时间点各调一次mark跑几轮后看哪段耗时占比最高。通常你会发现瓶颈集中在 llm_first_ms——LLM 的首 token 延迟是大头。接下来三个调优方向我按收益排序。第一个方向ASR 出 partial 结果时就送 LLM 预生成。用户还没说完ASR 已经给出「明天天气怎么样」的前半段此时让 LLM 先行开始推理等asr_final来了再修正。这能砍掉一半以上的首 token 延迟但要注意修正逻辑不能产生冲突回答。第二个方向给 LLM 减负。max_tokens降到 200、prompt 精简到一句系统提示、关闭思考链这些改动能让首 token 快 20% 以上。第三个方向TTS 流式合成。不要等 LLM 整句结束才合成按标点切句LLM 吐出的第一个分句立刻合成并播放用户听到回复的时间能从 2 秒降到 1.2 秒左右。这套方法我验证过多次端到端延迟从 3 秒降到 1.5 秒是稳定的再往下受限于单机推理速度需要换更强的硬件。我现在的习惯是每次改任何模块参数先跑一遍 LatencyTracker记录三段耗时再决定下一步——没有数据支撑的调优全是玄学。希望帮到你也期待你的离线语音助手跑起来之后比我这个版本更流畅。本文还有配套的精品资源点击获取