Mac本地听写与LLM改写实战：Whisper+本地大模型离线方案-北京尧图网络

1. 为什么我要在 Mac 上折腾本地听写和 LLM 改写我每天在 Mac 上敲的字少说也有大几千写稿、回邮件、记会议纪要手指在键盘上飞久了是真的累。语音输入这件事我试过不少方案系统自带的听写功能能用但延迟高、标点全靠猜说一段话出来经常是一坨没有断句的文本还得手动改半天。后来我把目光转向了本地跑的 Whisper 模型配合本地 LLM 做二次改写整套流程全部在 Apple Silicon 上离线完成这就是 TalkScribe 这个项目要解决的核心问题。简单说TalkScribe 是一个跑在 macOS 上的本地听写加 LLM 改写工具。你对着麦克风说话它用 Whisper 把语音转成文字再调用本地部署的大语言模型对这段文字做润色、纠错、格式化最后把干净的结果直接送到你当前光标所在的位置。整个过程不联网、不上传、不依赖任何云端服务隐私性拉满延迟也控制得相当不错。这套东西适合谁一是像我这样每天大量码字的内容工作者二是对隐私敏感、不愿意把语音数据传到云端的开发者三是手里有 M 系列芯片 Mac、想物尽其用跑点本地模型折腾一下的技术爱好者。哪怕你之前没接触过 Whisper 和本地 LLM只要跟着思路走也能把整套流程搭起来。我下面会从整体设计思路讲起把每个环节的技术选型理由、参数配置、实操步骤、踩过的坑全部摊开说尽量让你看完就能自己复现一套。2. 整体架构设计与技术选型思路2.1 为什么坚持全本地离线方案云端语音转写服务用起来确实省事但有几个绕不开的问题。第一是隐私你说的话要传到别人的服务器上处理会议内容、私人笔记这些东西我是不太放心往外发的。第二是延迟网络往返加上排队说一句话等两三秒才出结果思路都被打断了。第三是成本按分钟计费的服务用多了也是笔开销。本地方案把这三点全解决了。Apple Silicon 芯片的神经网络引擎加上统一内存架构跑 Whisper 这种模型其实相当轻松。我用的是 M2 Pro 16G 的机器Whisper 的 medium 模型转写一段十秒的语音大概只要几百毫秒完全感觉不到等待。LLM 改写环节用 7B 到 8B 量级的量化模型生成一段百来字的润色结果也就一两秒。整套流程下来从你说完话到文字出现在屏幕上基本在三秒以内。提示本地方案的前提是你的 Mac 内存要够。8G 内存的机器跑 Whisper medium 加 7B 量化模型会比较吃力建议至少 16G24G 以上体验更从容。2.2 Whisper 模型选型的取舍Whisper 有 tiny、base、small、medium、large 几个规格参数量从 3900 万到 15 亿不等。选哪个不是越大越好得看你的实际场景。我做过一轮对比测试用同一段包含中英文混说的三分钟录音在不同模型上跑转写结果大致是这样的模型规格参数量转写耗时M2 Pro中文准确率感受内存占用tiny39M约 1.5 秒勉强能用错字多约 400MBbase74M约 2.5 秒日常够用专业词易错约 600MBsmall244M约 5 秒准确率明显提升约 1GBmedium769M约 12 秒接近可用偶有偏差约 2.5GBlarge1.5B约 30 秒最准但慢约 5GB注意这个耗时是整段三分钟录音的处理时间不是实时延迟。实际使用中我们是流式分片处理的每片几秒钟所以体感延迟远低于表格里的数字。我的建议是如果你主要说中文small 是性价比最高的选择准确率和速度平衡得很好。如果经常中英混说或者有大量专业术语上 medium。tiny 和 base 只适合对准确率要求不高的场景比如快速记个待办。2.3 本地 LLM 的选择逻辑改写环节的 LLM 我试过好几个最后落在 7B 到 8B 这个量级。原因很简单再小的模型改写质量不行经常把原意改跑偏再大的模型推理速度掉得厉害而且内存吃紧。具体到模型我推荐几个方向。一是通用指令微调模型这类模型对“润色”“纠错”“格式化”这类指令响应好输出稳定。二是专门做过中文优化的模型中文标点和语序处理更自然。量化方面用 4-bit 或 5-bit 量化能在几乎不损失质量的前提下把内存占用压到 4G 到 6G。这里有个关键点改写用的提示词设计比模型本身还重要。我后面会专门讲提示词怎么写。2.4 整体数据流设计整套流程的数据流是这样的麦克风采集音频按静音检测切分成语音片段每个片段送进 Whisper 转写成原始文本原始文本加上上下文和提示词送进 LLM 改写改写结果通过辅助功能接口注入到当前光标位置。这里有个设计决策值得说是每句话单独改写还是攒一段一起改写。单独改写延迟低但 LLM 看不到上下文容易把代词改错。攒一段改写质量高但等待时间长。我的做法是折中按自然停顿切分一般三到五句话一组既保证上下文连贯又不至于等太久。3. 核心环节的实操配置与参数细节3.1 音频采集与静音检测的关键参数音频采集这块采样率用 16kHz 就够了因为 Whisper 本身就是按 16kHz 训练的采高了也是浪费。位深 16-bit单声道这些是 Whisper 的标准输入格式。静音检测是决定体验流畅度的关键。参数调不好要么你说完半天它不触发要么你稍微停顿一下它就把句子切断了。我用的参数是这样的静音阈值设在 -40dB 左右连续静音超过 700 毫秒判定为一句结束。这个 700 毫秒是我反复试出来的太短了正常说话的换气停顿会被误判太长了等待感明显。注意不同麦克风的底噪水平不一样-40dB 这个阈值不是万能的。建议你先录一段环境音看看底噪在什么水平然后把阈值设在底噪之上 10dB 左右。还有一个细节是预缓冲。就是在检测到语音开始之前往前多保留 300 毫秒的音频。因为静音检测有延迟如果不做预缓冲你说的第一个字经常被吃掉。这个坑我踩过一开始总觉得转写结果少字查了半天才发现是切分点的问题。3.2 Whisper 推理的加速技巧Whisper 在 Apple Silicon 上跑有几个加速手段。首先是框架选择用针对 Apple 芯片优化的推理框架比原版 PyTorch 快不少。其次是模型格式转成 Core ML 格式能调用神经网络引擎功耗和速度都有改善。批处理也是个技巧。如果你攒了几段音频一起处理可以拼成一个 batch 送进去比逐段处理效率高。但 batch 太大会增加延迟我一般控制在 4 到 8 段。还有个容易被忽略的点是语言检测。Whisper 每次推理都会先检测语言如果你明确知道自己说的是中文直接指定语言能省掉这一步速度有可见提升。中英混说的场景就没办法了只能让它自己检测。3.3 LLM 改写的提示词工程提示词这块我要多花点篇幅因为这是决定最终输出质量的核心。我试过的提示词版本少说也有几十个最后稳定下来的结构是这样的你是一个文字润色助手。请对下面的语音转写文本进行处理 1. 修正明显的同音字错误和识别错误 2. 补全标点符号合理断句 3. 去掉口头禅和重复的词 4. 保持原意不变不要添加原文没有的信息 5. 如果原文是问句保持问句形式原始文本 {transcript} 处理后的文本这个提示词有几个设计要点。第一明确列出任务清单模型不容易漏项。第二强调“保持原意”防止模型自由发挥。第三给出输出格式的引导让它直接输出结果不要废话。我试过让模型同时做翻译或者总结效果都不好任务一多它就顾此失彼。所以我的建议是提示词只做一件事要翻译就单独走一个流程。温度参数我设在 0.2 到 0.3太低了输出死板太高了容易乱改。top_p 用 0.9重复惩罚 1.1这几个值在我这儿比较稳。3.4 文本注入的实现方式改写完的文字怎么送到光标位置这个环节看起来简单其实有讲究。最直接的方式是模拟键盘输入把文字一个字一个字打进去。但这种方式慢长文本要打好几秒而且有些应用对模拟输入不友好。更好的方式是用 macOS 的辅助功能接口直接设置文本框的值或者插入文本。这需要应用支持辅助功能大部分原生应用和主流编辑器都没问题。遇到不支持的就退回模拟输入。还有个细节是剪贴板方案。先把文字写进剪贴板然后模拟粘贴。这个方式兼容性最好但会覆盖用户剪贴板里的内容。我的做法是粘贴完把原剪贴板内容恢复回去用户体验就好很多。4. 完整搭建流程与实操记录4.1 环境准备与依赖安装先说环境。你需要一台 Apple Silicon 的 Mac系统版本建议 macOS 13 以上因为一些推理框架的新特性需要较新的系统。Xcode 命令行工具要装很多依赖编译需要它。Python 环境我建议用 3.10 或 3.11太新的版本有些库还没适配。用虚拟环境隔离别污染系统 Python。包管理用 pip 或者 conda 都行我习惯 conda因为能顺便管理一些非 Python 的依赖。核心依赖大概这几类音频处理库负责采集和重采样Whisper 推理库负责转写LLM 推理库负责改写还有辅助功能相关的库负责文本注入。具体装哪些包取决于你选的推理框架我下面会给出一个参考组合。提示安装过程中如果遇到编译错误八成是缺少系统级的开发库。用 Homebrew 装一下对应的依赖通常能解决。4.2 Whisper 模型的下载与转换模型下载有几种途径。官方仓库能下原版权重社区也有转好的优化格式。我建议先用原版跑通流程确认没问题再考虑转换优化。下载完之后要做格式转换。如果直接用原版加载会慢一些。转成优化格式后首次加载快很多后续推理也更快。转换过程需要一点时间但一次性的值得做。模型文件放哪儿也有讲究。默认位置在用户目录下的缓存文件夹但如果你有多个项目共用建议统一放一个地方通过环境变量指定路径避免重复下载占空间。4.3 LLM 的本地部署LLM 部署我用的是专门的本地推理工具这类工具对 Apple Silicon 的优化做得不错支持量化模型内存管理也省心。模型文件从社区下载量化版本4-bit 的量化的 7B 模型大概 4G 左右。启动推理服务的时候要注意几个参数。上下文长度设 2048 够用了因为我们每次处理的文本不长。并发数设 1本地用不需要并发。GPU 层数拉满让模型尽量跑在 GPU 上。服务起来之后先用简单的请求测一下确认能正常返回结果再接入主流程。我见过有人模型下载不完整加载的时候报错排查半天。4.4 主流程串联与调试前面几个环节单独跑通之后把它们串起来。我的做法是先写一个简单的命令行版本按顺序调用各个模块确认数据流转正确。这个阶段不要追求体验先把功能跑通。串联的时候最容易出问题的是数据格式。音频采集出来是浮点数组Whisper 要的是特定格式LLM 要的是字符串中间转换环节多容易出错。我的经验是每个环节之间都打印一下数据形状和类型出问题好定位。跑通命令行版本之后再做常驻后台的服务版本。服务版本要考虑资源管理模型加载一次常驻内存音频采集用回调文本注入用事件驱动。这个架构比命令行复杂但体验好太多。4.5 快捷键与交互设计交互这块我设计得比较简单。按住一个快捷键开始录音松开结束并触发处理。处理过程中有个小的状态指示处理完文字自动注入。快捷键的选择有讲究要避开系统和其他应用的常用组合。我用的是 Control 加空格这类组合冲突少。状态指示我一开始想做得花哨后来发现越简单越好一个小圆点变色就够了不打扰注意力。还有个体验细节是错误提示。如果转写失败或者 LLM 没响应要给用户反馈但不能弹窗打断。我的做法是在状态指示上闪一下红色用户知道出问题了具体日志去后台看。5. 常见问题排查与避坑经验5.1 转写准确率不达预期怎么办准确率问题分几种情况。如果是普遍性的错字多先检查模型规格是不是太小了换个更大的模型试试。如果是特定词汇老是错那是模型对这个领域的词汇不熟悉可以考虑用带提示的转写把专业词汇提前告诉模型。环境噪音也是大头。麦克风离嘴太远、房间回声大、背景有持续噪音都会影响准确率。我建议用指向性麦克风离嘴 15 到 20 厘米这个距离信噪比最好。还有个隐蔽的问题是采样率不匹配。如果采集用的采样率和模型期望的不一致转写质量会明显下降。一定要确认采集端输出的是 16kHz。5.2 LLM 改写把原意改跑偏了这个问题我遇到过好几次原因通常是提示词约束不够。模型天生有“帮忙”的倾向看到语句不通顺就想大改。解决办法是在提示词里反复强调“保持原意”“不要添加信息”并且给几个正反例。温度参数也有影响。温度高了模型发挥空间大容易改跑偏。把温度降到 0.2 以下输出会保守很多。如果还是不行可以考虑换一个指令遵循能力更强的模型。还有一种情况是原始转写文本本身就有歧义模型只能猜。这种没办法根治只能靠提升转写准确率来减少。5.3 延迟忽高忽低不稳定延迟不稳定一般是资源竞争导致的。检查一下后台有没有其他吃 CPU 或 GPU 的程序。浏览器开着一堆标签页、视频会议软件在后台跑都会抢资源。内存压力也是常见原因。如果模型加载后系统开始频繁换页延迟会飙升。用活动监视器看一下内存压力如果长期是黄色或红色说明内存不够得换更小的模型或者加内存。首次推理总是比后续慢因为要加载模型和预热。如果你对首次延迟敏感可以在启动服务的时候就跑一次空推理预热。5.4 文本注入到某些应用失效不同应用对文本注入的支持程度不一样。原生应用一般没问题一些跨平台框架做的应用可能不响应辅助功能接口。遇到这种情况退回模拟键盘输入通常能解决只是慢一点。还有一种情况是应用有输入法保护模拟输入会被拦截。这种比较麻烦可能需要在应用设置里关掉相关保护或者干脆手动复制粘贴。权限问题也别忽略。macOS 对辅助功能权限管得严第一次用要手动授权授权之后如果系统更新了可能还要重新授权。这个坑我踩过明明代码没问题就是不生效查了半天是权限掉了。5.5 常见问题速查表现象可能原因排查方向转写错字多模型太小/噪音大/采样率不对换大模型、改善录音环境、检查采样率改写跑偏提示词约束弱/温度高强化提示词、降低温度延迟高资源竞争/内存不足关后台程序、换小模型注入失效应用不支持/权限丢失退回模拟输入、重新授权首字丢失静音检测无预缓冲增加预缓冲时长句子被截断静音阈值太敏感调长静音判定时间6. 性能调优与进阶玩法6.1 内存与速度的平衡策略本地跑模型内存和速度永远是一对矛盾。我的策略是分级配置日常轻量使用用 small 模型加 4-bit 量化的 7B内存占用控制在 6G 以内需要高质量输出的时候切到 medium 加 5-bit 量化内存占用到 10G 左右。切换模型不用重启服务但首次切换会有加载延迟。我的做法是常用的模型常驻不常用的按需加载用完释放。这样既保证常用场景的响应速度又不至于把内存占满。还有个技巧是模型分片加载。有些推理框架支持把模型分成几部分用哪部分加载哪部分。对于超大模型这个技巧很有用但配置起来复杂一般场景用不上。6.2 自定义词库与领域适配通用模型对专业术语的处理总是不尽如人意。解决办法是建一个自定义词库转写的时候把词库作为提示传给 Whisper改写的时候把词库作为术语表传给 LLM。词库的维护是个长期活儿。我的做法是每次发现转写错误就记下来定期整理进词库。词库不用太大几百个高频术语就能覆盖大部分场景。词库格式用简单的文本文件就行一行一个词方便维护。提示词库里的词不要太多太多了反而会干扰模型。只放那些确实高频且容易错的词一般控制在 500 个以内。6.3 多语言混说的处理中英混说是很多人的实际场景处理起来确实麻烦。Whisper 对混说的支持还行但偶尔会把中文识别成英文或者反过来。LLM 改写的时候如果提示词没处理好可能把英文词翻译成中文那就闹笑话了。我的处理方式是在提示词里明确说明“保留原文中的英文词汇不要翻译”。同时给几个中英混说的例子让模型明白这种模式。实测下来这样处理之后混说场景的准确率提升明显。如果混说特别频繁可以考虑用支持多语言的模型或者干脆分开处理中文段落走中文流程英文段落走英文流程。但这样实现复杂一般没必要。6.4 与其他工具的联动这套东西搭好之后可以和其他工具联动玩出更多花样。比如接上自动化工具说一句话触发一个工作流实现语音控制。或者把转写结果自动存进笔记软件做语音日记。我自己的用法是接了一个简单的命令识别说“记一下”开头的内容自动存进待办清单说“查一下”开头的内容自动触发搜索。这个用简单的规则匹配就能实现不用上复杂的意图识别。联动的时候要注意权限和稳定性。自动化工具调用其他应用需要授权而且如果被调用的应用没启动调用会失败。做好错误处理别让一个环节失败导致整个流程卡死。7. 我在实际使用中的几点体会这套本地听写加 LLM 改写的方案我用了大半年从最初的命令行原型到现在常驻后台的服务中间迭代了不知道多少版。最大的感受是本地方案的上限比云端高但需要你自己调的东西也多。云端服务开箱即用但你就只能用它给的那套本地方案什么都能改但每个参数都得自己试。模型选择上我的建议是别一步到位上最大的。先用 small 跑通流程感受一下整套东西的工作方式然后再根据实际需求调整。我见过不少人一上来就下 large 模型结果内存不够跑不起来或者速度慢到没法用直接放弃了。提示词这块值得多花时间。同样的模型提示词写好写坏输出质量能差出一大截。我的提示词改了十几版才稳定下来每次遇到新问题就加一条约束。这个过程急不得得在实际使用中慢慢磨。最后说个心态问题。本地模型再优化也不可能做到百分之百准确总会有错字或者改错的地方。把它当成一个帮你省力的助手而不是完全替代你思考的工具。该检查的地方还是要检查尤其是重要的内容。接受它的不完美用好它的长处这套东西才能真正提升你的效率。

Mac本地听写与LLM改写实战：Whisper+本地大模型离线方案

相关推荐

程序员转型大模型工程师：技能迁移与职业发展指南

Mac本地离线听写与LLM改写实战：Whisper+llama.cpp全流程指南

Go Context模式：从超时控制到goroutine泄漏排查

更多资讯

08:字符替换

【前后端】沙箱机制

07:配对碱基链

04:石头剪子布

05:输出亲朋字符串

ESP32模组料号解析：N/R/H/U后缀含义与选型指南

今日更新

猫狗目标检测数据集：VOC/COCO/YOLO三格式一体化实战包

HDU2017多校标程复现：算法竞赛工程化真题沙盒

Codex Sandbox 隔离环境拆解：AI Agent 的临时实验室如何运作

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？