在Mac本地跑语音听写与LLM改写：Whisper+Ollama实战

1. 为什么要在本地跑听写和改写把语音转文字和文本润色这两件事都放在本地完成是 TalkScribe 这个项目最核心的出发点。我最早接触这类需求是在做访谈整理的时候一段一小时的录音丢进在线服务等转写、等排队、还要担心内容被上传到别人的服务器。后来换成在 Mac 上本地跑整个流程从提交-等待-下载变成了按下快捷键-说完-文字已经在光标处体验完全是两个量级。TalkScribe 做的事情可以拆成两段第一段是听写dictation把你说的话实时转成文字第二段是本地大模型改写local LLM rewrite把转出来的口语化文字用本地运行的语言模型重新组织成更书面、更通顺的表达。两段都在设备上完成不依赖网络不上传任何音频或文本。这套方案适合几类人经常需要口述记录的产品经理、记者、律师、医生对隐私敏感、不能把会议内容外传的从业者以及像我这样单纯觉得在线服务延迟高、按量计费不划算、还想自己掌控整条链路的技术爱好者。它解决的核心问题就三个字——隐私、延迟、成本。音频不出本机隐私问题直接消失本地推理没有网络往返延迟取决于芯片性能而不是带宽一次配置好之后边际成本几乎为零。关键词里出现的 macOS、LLM、Apple Silicon、On-Device、Whisper基本勾勒出了技术栈的全貌在 Apple Silicon 芯片的 Mac 上用 Whisper 系列模型做语音识别用本地 LLM 做文本改写全程 on-device。下面我会把这条链路拆开讲清楚每个环节为什么这么选、怎么落地、以及我踩过的那些坑。2. 技术栈选型Whisper 与本地 LLM 的搭配逻辑2.1 语音识别为什么绕不开 Whisper语音转文字这个领域开源方案里 Whisper 几乎是默认答案。它是 OpenAI 放出来的语音识别模型家族从 tiny 到 large 有好几个尺寸覆盖多种语言中文识别质量在开源模型里属于第一梯队。TalkScribe 这类工具选它理由很实在模型权重公开、社区工具链成熟、在 Apple Silicon 上有专门的加速路径。Whisper 的模型尺寸和资源占用大致是这样的关系模型尺寸参数量磁盘占用内存占用相对速度适用场景tiny39M约 75MB约 400MB最快快速草稿、低配设备base74M约 142MB约 500MB很快日常口述small244M约 466MB约 1GB快质量与速度平衡medium769M约 1.5GB约 2.5GB中等高质量转写large1550M约 3GB约 5GB慢最高质量热词里出现了potplayer whisper small 模型说明不少人在关注 small 这个档位。我的实测结论是中文日常口述small 是性价比拐点。tiny 和 base 在中文上错字明显偏多尤其是同音字和专有名词medium 和 large 质量确实更好但实时听写场景下延迟会让人等得难受。small 在 M 系列芯片上基本能做到接近实时的转写速度错字率也在可接受范围。2.2 本地 LLM 在改写环节扮演什么角色语音转出来的文字有个通病口语化、有重复、有嗯那个就是说这类填充词句子结构也松散。直接拿去用读起来很别扭。这时候就需要一个语言模型做后处理——把口语转成书面语去掉冗余理顺逻辑。为什么用本地 LLM 而不是调在线接口还是那三个字隐私、延迟、成本。改写这一步要处理的是完整的文本内容如果走在线接口等于把转写结果又上传了一遍前面本地转写的隐私优势就白费了。本地 LLM 用 7B 到 14B 这个量级的模型在 Apple Silicon 上通过量化后跑推理速度完全够用改写一段几百字的文本通常一两秒内完成。选模型的时候有几个考量点。指令跟随能力要强因为改写本质是一个指令任务你得让模型听懂把这段话改成书面语保留原意不要添加新信息。中文能力要过关很多英文强的小模型中文改写会翻车。量化后的体积要能塞进内存7B 模型 4-bit 量化后大约 4GB 左右16GB 内存的 Mac 跑起来比较从容。2.3 Apple Silicon 带来的 on-device 可行性这套方案能在 Mac 上跑得动Apple Silicon 的统一内存架构是关键。传统 PC 上CPU 和 GPU 各有各的内存模型要在两者之间搬数据带宽是瓶颈。Apple Silicon 把 CPU、GPU、神经引擎放在同一块芯片上共享内存模型加载一次各个计算单元都能直接访问省掉了大量数据搬运。再加上 Metal 这套图形和计算框架以及专门为它优化的推理后端本地跑 Whisper 和 LLM 的效率比同价位的 x86 笔记本高出一截。这也是为什么热词里Apple Silicon和On-Device会同时出现——硬件特性直接决定了本地推理这件事在 Mac 上从能跑变成了好用。提示内存是硬门槛。8GB 内存的 Mac 跑 small 模型加 7B 量化 LLM 会比较吃力建议 16GB 起步24GB 以上更从容。统一内存虽然高效但容量不够时系统会疯狂换页体验断崖式下跌。3. 从零搭起本地听写链路3.1 环境准备里最容易忽略的几件事动手之前先把环境理清楚。很多人一上来就装模型结果卡在依赖或者权限上白白浪费时间。我建议按这个顺序来确认芯片和系统版本。Apple SiliconM1 及以后和 Intel Mac 的路径不一样前者能用 Metal 加速后者只能靠 CPU速度差很多。系统版本建议 macOS 13 以上新版本对本地推理框架的支持更完整。装好包管理工具。Homebrew 是 Mac 上装命令行工具的标准入口后面装 Python、ffmpeg 之类的都靠它。准备 Python 环境。强烈建议用虚拟环境别把依赖装到系统 Python 里否则后面版本冲突会让你怀疑人生。装 ffmpeg。音频解码、重采样、格式转换都靠它Whisper 处理音频文件时底层会调用。# 安装 Homebrew如果还没装 /bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh) # 装 ffmpeg brew install ffmpeg # 建一个独立的 Python 虚拟环境 python3 -m venv talkscribe-env source talkscribe-env/bin/activate这里有个坑要提前说麦克风权限。macOS 对隐私管得很严任何要访问麦克风的应用第一次运行时系统会弹窗要权限。如果你是在终端里跑脚本弹窗可能出现在系统设置里而不是前台容易错过。跑之前先去系统设置 - 隐私与安全性 - 麦克风里把你用的终端或应用勾上。3.2 音频采集与实时转写的衔接听写的难点不在转写本身而在音频流的切分和衔接。Whisper 处理的是定长音频片段而人说话是连续的怎么把连续语音切成合适的片段直接决定转写质量。常见的做法是维护一个滑动窗口持续采集麦克风音频累积到一定长度比如 5 到 10 秒就送一次转写同时保留一小段重叠区域避免把词切在两段中间。重叠区域的处理是个细节——如果两段转写结果在重叠处有重复文字需要做去重合并。# 音频采集与分段的简化逻辑示意 import sounddevice as sd import numpy as np SAMPLE_RATE 16000 # Whisper 期望的采样率 CHUNK_SECONDS 8 # 每次送转写的音频长度 OVERLAP_SECONDS 1 # 相邻片段的重叠长度 def capture_stream(): chunk_frames CHUNK_SECONDS * SAMPLE_RATE overlap_frames OVERLAP_SECONDS * SAMPLE_RATE buffer np.zeros(0, dtypenp.float32) with sd.InputStream(samplerateSAMPLE_RATE, channels1, dtypefloat32) as stream: while True: data, _ stream.read(SAMPLE_RATE) # 每次读 1 秒 buffer np.concatenate([buffer, data[:, 0]]) if len(buffer) chunk_frames: yield buffer[:chunk_frames] # 保留重叠部分丢弃已处理的主体 buffer buffer[chunk_frames - overlap_frames:]采样率必须是 16000Hz这是 Whisper 的硬性要求。如果你从其他设备拿到的是 44100Hz 或 48000Hz 的音频得先重采样否则识别结果会乱套。这个坑我踩过——用 48kHz 直接喂进去转出来的文字全是乱码排查了半天才发现是采样率问题。3.3 模型加载与推理参数调优Whisper 推理有几个参数会明显影响结果值得单独调language明确指定语言比如zh比让模型自动检测更稳尤其是中英混杂的场景自动检测容易来回跳。tasktranscribe是转写translate是翻译成英文听写场景用前者。temperature控制输出的随机性。听写要的是稳定复现建议设成 0 或者一个很小的值。beam_size束搜索宽度越大质量越好但越慢。实时听写用 1 到 5 之间离线批量处理可以开到 5 以上。initial_prompt可以塞一段领域词汇进去引导模型往正确的方向识别。比如你经常说专业术语把术语表放进去错字率会下降。import whisper model whisper.load_model(small) # 加载 small 模型 result model.transcribe( audio_array, languagezh, tasktranscribe, temperature0.0, beam_size5, initial_prompt以下是普通话内容涉及产品、技术、会议记录等词汇。, condition_on_previous_textFalse, # 避免前文错误累积影响后文 ) print(result[text])condition_on_previous_text这个参数容易被忽略。它默认是 True意思是让模型参考前面的转写结果来理解当前片段。好处是上下文连贯坏处是一旦前面转错错误会一路传染下去。实时听写场景我建议关掉它让每段独立转写稳定性更好。4. 本地 LLM 改写环节的落地细节4.1 改写提示词怎么写才不跑偏改写这件事成败八成在提示词。语音转出来的文字你要的是保留原意、去掉口语、理顺结构而不是让模型自由发挥。提示词写得太松模型会自己加内容写得太死又改不动。我反复调整后比较稳的一个模板是这样的你是一个文本润色助手。请把下面这段语音转写的文字改写成通顺的书面语。 要求 1. 保留原意不要添加原文没有的信息。 2. 去掉嗯那个就是说等口语填充词。 3. 修正明显的语病和重复。 4. 保持原段落结构不要合并或拆分段落。 5. 只输出改写后的文字不要任何解释。 原文 {transcribed_text}关键在最后一句只输出改写后的文字。不加这句模型经常会先来一段好的我来帮你改写然后才是正文你还得再写代码把这段前缀剥掉。另外不要添加原文没有的信息这条也很重要否则模型会自作主张补充细节改出来的东西跟原意对不上。4.2 用 Ollama 跑本地模型的实操本地跑 LLM目前最省心的方式是 Ollama。它把模型下载、量化、推理服务都封装好了一条命令就能拉起一个本地模型服务然后通过 HTTP 接口调用。# 安装 Ollama brew install ollama # 拉取一个中文能力不错的 7B 模型 ollama pull qwen2.5:7b # 启动服务默认监听 11434 端口 ollama serve模型选型上中文改写我推荐 Qwen 系列指令跟随和中文表达都比较稳。7B 版本 4-bit 量化后大约 4.5GB16GB 内存的 Mac 跑起来没问题。如果你内存充裕14B 版本质量会更好但速度会慢一些。调用的时候把提示词和转写文本拼好发过去import requests def rewrite_text(text): prompt f你是一个文本润色助手。请把下面这段语音转写的文字改写成通顺的书面语。 要求 1. 保留原意不要添加原文没有的信息。 2. 去掉口语填充词。 3. 修正语病和重复。 4. 只输出改写后的文字。 原文 {text} resp requests.post( http://localhost:11434/api/generate, json{ model: qwen2.5:7b, prompt: prompt, stream: False, options: { temperature: 0.3, # 改写要稳温度调低 num_predict: 1024, # 最大输出长度 }, }, ) return resp.json()[response].strip()temperature设 0.3 左右比较合适。太高了改写结果每次都不一样太低了又显得死板。num_predict是输出长度上限设太小会截断长文本设太大又浪费显存按你实际处理的文本长度来定。4.3 流式输出让改写不卡顿改写一段几百字的文本7B 模型通常一两秒出结果但如果文本很长等全部生成完再显示用户会感觉卡住。Ollama 支持流式输出可以边生成边显示体验好很多。def rewrite_stream(text): prompt build_prompt(text) resp requests.post( http://localhost:11434/api/generate, json{model: qwen2.5:7b, prompt: prompt, stream: True}, streamTrue, ) for line in resp.iter_lines(): if line: import json chunk json.loads(line) yield chunk.get(response, )流式输出还有个好处如果发现模型改偏了可以中途打断不用等它把整段废话生成完。这在交互式场景里很实用。5. 踩坑实录那些让我折腾半天的细节5.1 中文标点和分段的处理Whisper 转中文有个特点它倾向于输出不带标点或者标点很稀疏的长句。英文转写标点相对完整中文就经常是一大串没有断句的文字。这直接影响后续 LLM 改写的效果——模型拿到一坨没有标点的文字断句都断不明白改写质量自然差。我的处理办法是在转写后加一步轻量后处理用规则或者小模型给长句补标点。简单场景下可以按语气词和停顿位置插入逗号句号要求高的话可以再跑一个小模型专门做标点恢复。这一步不做后面改写环节会一直别扭。分段也是类似问题。Whisper 按音频片段输出片段边界和语义边界往往对不上可能一句话被切成两段也可能两句话挤在一段里。我的做法是转写完成后按标点和长度重新分段让每段语义相对完整再送去改写。5.2 内存和显存的实际占用前面表格里给的内存占用是模型本身的实际运行时还要算上系统、应用、音频缓冲的开销。我实测下来small 模型加 7B 量化 LLM在 16GB 的 Mac 上跑系统内存压力会到黄色区间偶尔卡顿。如果同时开着浏览器一堆标签页就容易触发换页转写延迟明显上升。几个缓解办法一是听写和改写不要同时加载转写完再加载 LLM二是用更小的模型比如 base 加 3B LLM三是关掉不用的应用。内存这件事宁可留余量别卡在临界点上。注意模型加载后不会自动释放内存。如果你在脚本里反复加载不同模型记得显式释放否则内存会越占越多最后系统卡死。5.3 麦克风权限和音频设备的坑macOS 的麦克风权限是个高频坑。终端应用第一次访问麦克风时系统弹窗可能不出现或者出现了你没注意结果就是录不到声音程序也不报错你以为是代码问题其实是权限没给。排查方法去系统设置 - 隐私与安全性 - 麦克风看你的终端或应用有没有被勾选。没有的话手动加上然后重启终端权限才会生效。这个重启步骤很多人会漏改完权限不重启还是录不到。音频设备切换也是坑。Mac 上可能有内置麦克风、外接麦克风、耳机麦克风好几个输入源程序默认选的不一定是你想要的。用 sounddevice 这类库的时候最好先列出所有设备明确指定用哪个import sounddevice as sd print(sd.query_devices()) # 列出所有音频设备 # 找到目标设备的索引在 InputStream 里用 device索引 指定5.4 模型下载慢和缓存位置Whisper 和 Ollama 的模型文件都不小下载慢是常态。Whisper 的模型默认缓存在~/.cache/whisperOllama 的模型在~/.ollama/models。知道这两个位置有好处一是可以手动把模型文件放进去避免重复下载二是磁盘紧张的时候知道去哪清理。下载慢的话可以错峰下载或者找国内的镜像源。Ollama 支持配置镜像地址具体方式看它的文档。Whisper 的模型文件是公开的也可以手动下载后放到缓存目录程序会直接读取。6. 把听写和改写串成完整工作流6.1 快捷键触发与光标处插入工具好不好用很大程度看交互。理想状态是按一个快捷键开始录音再按一下结束文字自动出现在当前光标位置。这需要把音频采集、转写、改写、文本插入串成一条流水线。文本插入这一步macOS 上可以用 AppleScript 或者辅助功能接口模拟键盘输入。简单做法是把结果写进剪贴板然后模拟 CmdV 粘贴# 把文本写入剪贴板 echo -n 改写后的文字 | pbcopy # 用 AppleScript 模拟粘贴 osascript -e tell application System Events to keystroke v using command down这个方案简单可靠缺点是会覆盖你剪贴板里原有的内容。讲究一点的话可以先备份剪贴板粘贴完再恢复。6.2 批量处理已有录音文件除了实时听写这套链路也能处理已有的录音文件。访谈录音、会议录音、课程录音丢进来批量转写加改写效率比手动整理高太多。批量处理的流程是遍历音频文件逐个转写转写结果送去改写最后按文件名输出成文本。这里要注意的是长音频的分段。Whisper 对长音频会内部切分但切分点可能不理想。我的做法是先用 ffmpeg 按静音检测切分成语义段落再逐段转写质量比整段丢进去好。# 用 ffmpeg 按静音切分音频 ffmpeg -i input.wav -af silencedetectnoise-30dB:d0.5 -f null - 21 | grep silence这条命令会输出静音段的位置据此可以算出语音段的起止时间再用 ffmpeg 切分。参数noise-30dB是静音判定阈值d0.5是静音最短持续时间这两个值要根据实际录音环境调。6.3 效果验证与迭代方向搭好之后怎么判断效果好不好我的验证方法是拿一段自己熟悉的录音人工转写一遍作为基准然后对比工具的输出。重点看三类错误同音字错误、专有名词错误、断句错误。同音字错误多说明模型尺寸不够或者 initial_prompt 没给好专有名词错误多往 initial_prompt 里加术语断句错误多检查标点后处理环节。改写环节的验证看的是改完之后读起来顺不顺原意有没有丢。我一般会挑几段改得最狠的逐句对照原文看有没有添加或遗漏信息。如果模型经常自作主张加内容把提示词里的约束再收紧。迭代方向上有几个值得投入的点一是领域词表把你常用的专业术语整理成 initial_prompt识别准确率提升明显二是改写模板针对不同场景会议纪要、邮件、文章准备不同的提示词三是快捷键和交互把常用操作做成一键触发减少打断思路的操作。7. 关于隐私、性能与日常使用的几点体会用下来最大的感受是本地方案的价值不只是隐私更是一种掌控感。在线服务你不知道它什么时候改接口、什么时候涨价、什么时候把你的数据拿去训练本地方案这些东西都在你自己手里。模型想换就换参数想调就调出了问题能自己排查。性能上Apple Silicon 确实让本地推理从能跑变成了好用。我手上这台 M 系列芯片的 Mac跑 small 模型加 7B 量化 LLM日常听写加改写基本感觉不到等待。当然前提是内存够8GB 的机器会明显吃力这点在买机器或者选模型的时候要提前想清楚。日常使用中我建议把听写和改写做成两个独立的快捷键。有时候你只想快速记一笔不需要改写直接转写就行有时候你要输出正式文本再触发改写。分开控制比绑在一起灵活。最后分享一个我常用的小技巧把 initial_prompt 做成可切换的。开会的时候用会议术语表写代码注释的时候用技术词汇表切换一下提示词识别准确率能差出一大截。这个改动很小但效果立竿见影。