我为什么开始在自己的 Mac 上搭一套本地 AI 基础设施

最近两天，我开始在自己的 Mac mini 上运行 oMLX 和本地模型。与此同时，我仍然用云端的强模型做开发，也让 Codex 帮我处理完整项目。这两个选择放在一起，并不矛盾。我想增加的是一个能由自己观察和安排的实验位置，而不是证明小模型已经可以替代 GPT 或 Codex。

真正读到这台机器的运行记录后，这件事才有了具体形状：模型配置已经存在，服务进程正在运行，文本请求留下了输入和输出统计，还有一份本地 TTS 测试音频。但从“已经能运行”到“值得长期承担某类工作”，我还需要继续验证。

云端模型已经很强，本地还补什么

我现在愿意把较难的理解、工程判断和复杂开发继续交给云端强模型。本地模型的吸引力在另一个方向：如果一个任务可以在自己的机器上完成，我能不能更直接地控制材料放在哪里、什么时候运行、怎样重复实验？这些问题不需要先证明本地模型比云端更聪明。

对个人项目来说，很多实验的目的只是了解某个小环节，而不是完成一个复杂产品。我想试一段文本处理、一种模型配置，或者一段语音输出时，可以先观察本地执行的过程，再决定它适不适合进入日常工具。当前这仍然是用途判断，不能写成这些任务已经全部稳定跑通。

我也不想把所有请求一开始都绑到同一种能力上。需要较强推理和上下文判断时，云端模型仍然有位置；如果未来某些范围清楚、质量要求能够核对的工作适合本地，再把那一部分留下。互补首先意味着允许不同任务有不同去处，而不是为了使用本地模型，强行把原本顺手的工作迁过来。

这次已经做到哪里

Mac mini 上已经有 Qwen 系语言模型的量化配置，也有 Qwen3-TTS 的本地模型配置。oMLX 保存了请求统计和按小时的使用记录，两份记录中的请求数可以对应，文本模型有非零的输出 token 统计。这比只看到模型下载目录更进一步：这台机器确实留下了处理请求的历史。

不过，这些统计没有告诉我每次回答是否正确。我没有从请求数推导任务成功率，也没有拿日志里的生成速度当统一性能结论。模型、输入长度、缓存和当时的运行状态都会影响一次观察；目前没有固定任务集和一致条件下的比较。

语音部分也要单独说清。已有一条 TTS 相关请求记录，桌面上留着可以解析的 WAV，长度约 7.7 秒。它支持“已经留下一个本地语音测试产物”这个结论；我还没有用这份材料证明中文听感、长文本稳定性或批量合成能力，更不能把它算成已经接入视频生产。

这尤其容易混淆，因为同一阶段我刚做完一条使用云端 TTS 的视频。那条片的成片、字幕和完整播放有自己的记录；Mac mini 上的语音实验是另一件事。两边都存在，不等于两边已经连接起来。本地配音能否进入下一条视频，要等实际替换、渲染和看片后再判断。

隐私是动机，不是装完模型后的保证

我希望给不方便发送到外部的个人材料留一个选择。但“本地模型”只能说明其中的模型执行位置，不能自动说明整条任务都不出网。资料从哪里取得，是否调用外部工具，日志保存什么，客户端又向哪里发送请求，都需要沿实际使用路径检查。

所以我目前不会把这套环境称为已经完成隐私审计的离线系统。先让任务和数据范围明确，再逐步确认调用路径，比贴上“本地所以安全”的标签更有用。访问自己的服务也仍然需要认证，能在自己机器上运行并不意味着可以随意开放给网络里的所有设备。

成本和 Agent 的价值，都还不能先算出来

我关心本地计算是否能减少一部分云端调用，但还没有做成本对照。机器、存储、电耗和维护时间并不会消失。我还没有把这些投入与真实使用量放到一起比较，因此不能说已经省钱。若大部分时间只是下载模型和处理环境问题，本地运行也可能增加负担。

Agent 是我想继续实验的方向之一：把本地模型作为一个可以调用的能力，让它处理合适的局部任务。但模型服务能运行、开发工具已安装、远程访问已打通，是几件不同的事实。现在没有足够记录证明一个本地 Agent 已经持续替我完成工作，也没有与现有 Codex 使用方式的效率对照。

我目前更愿意保留的安排

短期内，我会继续用云端能力推进复杂项目，把 Mac mini 留作本地推理与语音实验的位置。先找一类会重复发生、结果又能实际检查的任务，记录它的质量、等待时间和维护负担，再决定是否值得留下。模型数量和已处理请求数，都不该成为扩张用途的理由。

这套本地 AI 基础设施对我已经从讨论变成了有运行记录的实验环境。它还没有成为强模型的替代品，也没有因为能输出内容就自动获得长期价值。我想验证的是：它能否在自己的边界里承担一部分真实工作，让云端能力与本地计算各有合适的位置。