在配备 24GB 内存的 M4 上运行本地模型
2026 年 5 月 10 日，阅读时长 13 分钟。涉及 Elixir、大语言模型（LLM）、通义千问（Qwen）、LLM Studio。断断续续尝试在本地运行模型一段时间后，终于找到可行方案。虽输出效果不及最先进（SOTA）模型，但能让本地模型完成基本任务、用于研究和规划，这种兴奋感足以弥补差距！而且运行本地模型无需联网，还能减少对美国大型科技公司的依赖。
搭建环境不易
搭建运行本地模型的环境并不轻松。首先要选择运行模型的方式，像 [Ollama]、[llama.cpp] 或者 [LM Studio]，每种方式都有特点和局限性，并非所有模型都能在这些工具中使用。接着要挑选合适的模型，需选既能在内存中运行，又能为日常使用的 Electron 应用留出足够空间的最佳模型，且模型最好有至少 64K 的上下文窗口，理想情况是达到 128K 或更大。最近尝试了 Qwen 3.6 Q3、GPT - OSS 20B、Devstral Small 24B，理论上能在内存中运行，但实际无法正常工作；Gemma 4B 运行没问题，但工具使用表现不佳。
此外，还有大量配置选项需调整。从常见参数（如温度）到晦涩选项（如 K 缓存量化类型），很多工具提供基本推荐选项，但合适配置会因是否启用思考模式等因素而异。
通义千问 3.5 - 9B（4b 量化）表现出色
`qwen3.5 - 9b@q4_k_s` 是目前运行效果最好的模型。在 LM Studio 上运行，启用思考模式时每秒约能输出 40 个 token，能成功使用工具，有 128K 的上下文窗口。与 SOTA 模型相比，它易分心、会陷入循环、可能误解问题等。但对于配备 24GB 内存的 Macbook Pro 来说，运行时还能为其他程序留空间，表现相当不错！
以下是思考模式和编码工作的推荐设置：
精确编码任务（如 Web 开发）的思考模式：
温度（temperature）= 0.6，核采样概率（top_p）= 0.95，采样数量（top_k）= 20，最小概率（min_p）= 0.0，存在惩罚（presence_penalty）= 0.0，重复惩罚（repetition_penalty）= 1.0
要启用思考模式，需选择模型，进入配置页面，滚动到推理（Inference）选项卡底部，在提示模板（Prompt Template）中添加 `{% - set enable_thinking = true %}`。
通过 [pi] 和 [OpenCode] 使用这个模型，但还没决定更喜欢哪个。Pi 响应速度更快，虽欣赏其自动构建工具和丰富自定义功能，但希望它提供合理默认设置，感觉调整 Pi 配置花费的时间可能比实际项目开发时间还多！
Pi 设置
以下是 `~/.pi/agent/models.json` 的内容：
{
"providers": {
"lmstudio": {
"baseUrl": "http://localhost:1234/v1",
"api": "openai - completions",
"apiKey": "lm - studio",
"models": [
{
"id": "qwen3.5 - 9b@q4_k_s",
"reasoning": true,
"compat": { "thinkingFormat": "qwen - chat - template" }
}
]
}
}
}
若要隐藏干扰性的思考内容，可在 `~/.pi/agent/settings.json` 中添加 "hideThinkingBlock": true。
OpenCode 设置
`~/.config/opencode/opencode.json` 的内容如下：
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"lmstudio": {
"npm": "@ai - sdk/openai - compatible",
"name": "LM Studio (本地)",
"options": {
"baseURL": "http://127.0.0.1:1234/v1"
},
"models": {
"qwen3.5 - 9b@q4_k_s": {
"name": "通义千问 3.5 9B Q4_K_S",
"tools": true,
"context_length": 131072,
"max_tokens": 32768
}
}
}
},
"model": "lmstudio/qwen3.5 - 9b@q4_k_s"
}
与 SOTA 模型的比较
像通义千问 3.5 9B（Q4）这样的模型，远不能像 SOTA 模型那样长时间独立解决复杂问题。让它一次性构建完整应用程序不现实，只会浪费时间没结果。
不过，采用更交互式工作流程更有效，即逐步与模型清晰沟通并给予大量指导。很多人可能觉得这样做没意义，但实际上这能让人更投入。使用 SOTA 模型的弊端是，容易让人把所有认知工作交给它们，即便试图避免也难。
使用本地模型时，需承担更多思考和规划工作，更具体地提问题，但它仍可充当研究助手、“橡皮鸭调试法”对象，以及能瞬间回忆大量编程语言细节和命令行调用的专家。虽无法带来 10 倍生产力提升，但有一定作用且有趣。
示例展示
示例 1
想将 Elixir 代码检查工具 `credo` 更新到最新版本，代码出现警告。让通义千问帮忙查看，它给出了详细解决方案：
我：
运行 mix credo --strict 并提出解决方案，不要直接编辑代码
通义千问：
Credo 警告
测试文件中有 4 个警告。问题在于使用 length/1 来检查列表是否非空。Credo 建议将列表与空列表进行比较。
警告信息如下：
1. test/jola_dev_web/controllers/blog_controller_test.exs:11
- assert length(conn.assigns.posts) > 0
2. test/jola_dev_web/controllers/blog_controller_test.exs:22
- assert length(conn.assigns.posts) > 0
3. test/jola_dev/blog_test.exs:10
- assert length(posts) > 0
4. test/jola_dev/blog_test.exs:23
- assert length(tags) > 0
解决方案
将每个 length(list) > 0 替换为 list != []：
blog_controller_test.exs:
# 第 11 行
assert conn.assigns.posts != []
# 第 22 行
assert conn.assigns.posts != []
blog_test.exs:
# 第 10 行
assert posts != []
# 第 23 行
assert tags != []
这样在 Elixir 中更符合习惯，并且避免了计算列表长度的开销。
让通义千问进行编辑，它同时进行了 4 处编辑，很干净利落。总体来说，这是简单任务，自己也可在终端和编辑器间切换获取行号编辑，使用模型更方便。
示例 2
更新一些依赖项后，Dependabot 的拉取请求（PR）出现 Git 冲突，Dependabot 拒绝变基。将代码拉下来变基后让通义千问帮忙查看。这是简单冲突，只需选每个依赖项较新版本，模型也识别出这点。
它给出了几种选择：
我能看到冲突。情况如下：
HEAD（当前分支）：
- sentry: 13.0.1
- tailwind: 0.3.1
另一方（正在变基的提交）：
- sentry: 12.0.3
- tailwind: 0.4.1
依赖项更新存在分歧。你有以下几种选择：
选项 1：同时接受两个更新（推荐）
- 保留 HEAD 中的 sentry 13.0.1
- 保留另一方的 tailwind 0.4.1
- 这样可以获得两个依赖项的最新版本
选项 2：仅接受 sentry 更新
- 保留 sentry 13.0.1
- 保留 tailwind 0.3.1
选项 3：仅接受 tailwind 更新
- 保留 sentry 12.0.3
- 保留 tailwind 0.4.1
你想采用哪种方法？
然而，要求它进行更改时，它忘记编辑，只试图添加更改并继续变基操作，冲突标记仍存在。
它还没意识到 `git rebase --continue` 会打开编辑器，导致 OpenCode 卡住，不过这可能是个例。
总结
大语言模型（LLM）非常灵活，本地模型也能完成很多任务，想象力就是边界。本地模型虽有明显权衡之处，但也有吸引人的优点：无需联网，可在飞机上工作；成本仅限于使用的电量，无需订阅费用；开源模型公司在环境影响方面远不及大型公司，使用自己的硬件减少了数据中心的使用；摆弄这些模型很有趣。
大语言模型对世界产生巨大影响，虽有很多不积极的影响，但显然会一直存在。尝试使用本地模型是更可持续、更积极的与这项技术互动的方式。即便它偶尔出错，也很有趣！那你是否也想尝试一下本地模型呢？
