回顾

把本地 LLM 跑在 Mac Studio 上后，我发现个人和小团队更适合把它当成慢但强的工作机

AAnonymous
10分钟阅读
#Mac Studio
#LM Studio
#本地 LLM
#AI 工作流

前言

谈到在本地运行 LLM，通常都是从安装方法讲起。先讲用什么运行时、下载什么模型、要开放哪个端口。

但用久一点就会发现，真正更重要的问题另有其事，那就是 如何把大型 LLM 在本地真正用出价值。能跑起来，和能持续用下去，完全是两回事。

起初我也是从 Ubuntu + vLLM + 2x 3090 Ti 开始的。现在则换到了 Mac Studio M3 Ultra(512GB) 和 LM Studio，在本地运行 deepseek、qwen、glm 系列的大模型。

这篇文章不是安装指南。我想轻松聊聊，为什么我在双 3090 上感受到了上限、为什么换到 Mac Studio，以及我现在如何把慢速的本地 LLM 真正用于实际工作。

一开始我是从两张 3090 Ti 起步的

最初的配置很简单。我花大约 220 万韩元买了两张二手 3090 Ti GPU，装在 Ubuntu 上，运行时选的是 vLLM。

当时，gemma 3 是我在本地体验里感觉不错的模型之一。如果只是处理非常简单指令的助手，或者搭一些小型工作流，它已经足够让人印象深刻。多语言能力不差，按当时的标准看，生成速度也相当让人满意。

实际上，我也确实用这套环境做过并测试过不少助手。

  • 聊天 Agent
  • 塔罗牌解读助手
  • 具有翻译人格的助手
  • 简单的工作流型工具

在这个阶段，我得到的结论很明确。本地 LLM 已经不是 玩具 级别了。但如果说它已经足以立刻做出 真正有意义的 Agent，那也还差得很远。

问题不在软件，而在更现实的硬件条件

一开始我选择 vLLM 的理由也很简单。它的配置不算太难，而且比 sglang 更广为人知。

但随着时间推移，我意识到，在家里跑 3090 多 GPU 时，真正的瓶颈远比运行时选型更现实。

  • 电费压力很大。
  • 发热太严重了。
  • 很难在家里长期常开。
  • 更重要的是，我真正想跑的大模型依然吃力。

当时我真正想要的，是在本地用足够长的上下文去处理 deepseek v3 级别的模型。但双 3090 在这里的上限很明确。能把小模型跑顺，和能把大模型稳定地作为工作资产长期使用，完全不是一回事。

最终我把 GPU 出掉，买了 Mac Studio M3 Ultra(512GB)。这次转换不只是换了设备，更改变了我理解本地 LLM 的方式。

换到 Mac Studio 之后，哪些事开始变得可行

切换到 macOS + LM Studio 之后，最大的变化是，那些以前连想都很难想的大模型，开始成为现实可选项。

当我终于能亲自加载 deepseek、glm、Qwen3-235B-A22B 这类大模型并直接看结果时，我对它们本身的能力相当惊讶。推理质量比我预期的还要好。哪怕只是给出稍微复杂一点的指令，得到的结果往往也比以前精细、稳定得多。

不过与此同时，限制也变得非常清晰。pp 性能比我想象中更慢，很明显不适合那种像实时聊天一样需要即时响应的用法。调研时我就知道它慢，但真正每天用起来，这个上限会体感得更加明显。

到这里，我改变了判断标准。我不再先问 这个模型够不够快？，而是先问 这个模型应该用在哪些场景？

虽然很慢，但让我满意度很高的工作

有意思的是，一旦放弃实时响应的期待，本地 LLM 反而变得更有用了。

让我最满意的场景，大多有一些共同点。

  • 需要高精度结果的数据分析类工作
  • 像游戏故事编写这样可以容忍长耗时的工作
  • 像复杂分析工作流这样步骤很多的工作
  • 像 OpenHands 一类可让它代替人整夜运行的自动化开发任务

例如，生成一个故事可能要花 40 到 60 分钟，甚至更久。按实时聊天的标准看，这速度简直糟糕透顶。但如果把这类工作改成 睡前先排上 3 到 5 个队列任务，第二天早上再收结果，整个故事就完全不同了。

它虽然慢，但产出的结果更大、更细致。人不必整晚守着，只要第二天检查结果，再把下一批任务排进去就行。

OpenHands 类任务也一样。与其把它当成立即响应的 Copilot，不如把任务堆进队列，让它自动跑起来，这种方式更契合。用这个视角看，本地 LLM 更像 安静地长时间工作的工作机，而不是 慢速聊天机器人。

不必像兔子一样快，也可以像乌龟一样赢

我在看待本地 LLM 时，经常会想到龟兔赛跑的故事。

云端 LLM 往往更像兔子。它快，响应直接，拿来即用。相反，本地大模型更像乌龟。它慢，按即时性来衡量会让人着急，比较方法一旦错了，很快就会失望。

但只要换一个评价标准，结论也会跟着改变。

如果拿它去拼实时聊天，本地 LLM 往往会输。但如果把使用方式改成让 持续性 获胜的结构，比如队列、重复任务、批处理、夜间执行，情况就完全不同了。实际中，我正是在这种方式里获得了很高的满意度。更重要的是，功耗也比多 GPU 方案稳定得多。以体感来说，和 GPU 配置相比，用不到七分之一的电力就能驱动更大的模型，这点也非常关键。

到头来，重要的不是模型速度，而是 你如何为自己的工作设计节奏。

我的代码最终也变成了以队列为中心

这不只是感想，它也被原封不动地体现在实际实现里。

如果去看我的 ai-service 模块，会很清楚地看到，我是把本地 LLM 当成 后台工作机，而不是 实时聊天 工具。

先说模型接入本身，它比想象中简单。在 RunnableAiModel 里，我把 vllm 和 lm studio 当成 OpenAI 兼容 Provider 来处理，只需要替换 baseUrl 就能接上。也就是说，从上层应用的视角看，只要接口形式符合 OpenAI 兼容端点，本地后端就可以比较自然地被替换进去。

针对 LM Studio 也有单独的使用示例。LMStudioVisionClient 实际上就是按 LM Studio 的 /v1 端点来接入视觉模型。换句话说，本地 VLM 也能顺着这条链路接进来，把能力扩展到图像分析。

更重要的是执行方式。

AiAgentExecutor 不会立刻执行工作流，而是先把它登记成 DTE Job 放进队列。LoopJobService 和 LoopWorkflowExecutor 被设计成在后台处理那些会反复运行的长任务，同时也具备检查点和恢复流程。WritingToolExecutor、多 Agent 工作流、营销内容生成流水线，整体上也都更接近异步执行，而不是即时应答。

这不是偶然。与其强行把慢模型塞进实时界面，不如把那些允许慢一点的任务送进队列里，这才更现实。

简单说，我后来是这样理解本地 LLM 的。

  • 它比起聊天应答器，更适合任务队列。
  • 它更适合那些速度不如难度与精细度重要的工作。
  • 它和「整夜运行、早上审阅」的模式很合拍。
  • 只要对上 OpenAI 兼容 API，把它接进现有服务结构也不难。

所以，本地 LLM 适合谁

如果你读到了这里，大概也在想类似的问题：本地 LLM 到底值不值得用，以及为它花一笔不小的钱，是否真的划算。

我的标准很明确。

本地 LLM 很适合下面这类人。

  • 比起实时聊天，更常做批处理的人
  • 希望把复杂生成与分析任务整夜跑起来的人
  • 想用更低运营成本持续利用大模型的人
  • 能把自己的工作流重新设计成队列中心的人

反过来，如果你最看重的是即时对话体验，那么它一开始一定会让人憋闷。在这种情况下，选择本地 LLM 很可能就是建立在错误预期之上的决定。

结语

在本地运行大型 LLM 这件事，往往会比想象中更快地从「安装成功」滑向「使用失败」。因为模型能启动，不代表它立刻就有用。

我是从 2x 3090 Ti + Ubuntu + vLLM 起步的，现在则换到了 Mac Studio M3 Ultra(512GB) 和 LM Studio。在这个过程中，我得到的结论很简单。

对个人和小团队来说，本地 LLM 与其说是用来替代快速聊天的工具，不如说更适合被做成慢、但很强的工作机。

如果你已经有 Mac，尤其是拥有 Mac Studio 级别的设备，我会建议你至少试一次这样的本地 LLM 用法。开始时不必搞得很宏大。别从实时聊天开始，而是先挑一件今晚可以塞进队列里的难任务。

比你想象中更多的可能性，往往就是从那里开始的。