在配备24GB内存的M4芯片MacBook上运行本地模型

在配备 24GB 内存的 M4 上运行本地模型 | jola.dev

jola.dev

首页关于博客项目演讲

[](https://github.com/joladev)[](https://twitter.com/joladev)[](https://bsky.app/profile/jola.dev)[](https://linkedin.com/in/joladev)[](https://jola.dev/rss.xml)

首页关于博客项目演讲

[](https://github.com/joladev)[](https://twitter.com/joladev)[](https://bsky.app/profile/jola.dev)[](https://linkedin.com/in/joladev)[](https://jola.dev/rss.xml)

在配备 24GB 内存的 M4 上运行本地模型

2026 年 5 月 10 日

阅读时间：13 分钟

elixir llm qwen llmstudio

我断断续续地尝试在本地运行模型已经有一段时间了，终于找到了一个看起来还算靠谱的配置。虽然它的输出远不如顶级模型（SOTA），但能用本地模型完成基本任务、研究和规划所带来的兴奋感，足以弥补这一点！而且完全不需要联网！顺便说一句，这也是减少对美国科技巨头依赖的一种方式，哪怕只是微不足道的一点。

不过说实话，把这套东西搭建起来并不容易。首先你得决定如何运行模型：Ollama、llama.cpp 还是 LM Studio。每种工具都有自己的特点和限制，并不是所有模型都支持。然后当然还要选择你的模型——你要找的是能在内存中运行且留有足够空间运行常规 Electron 应用的最好模型，同时至少要有 64K 的上下文窗口，理想情况下是 128K 或更高。

最近我试过 Qwen 3.6 Q3、GPT-OSS 20B 和 Devstral Small 24B，它们理论上都能装进内存，但实际上根本没法用；还有 Gemma 4B，虽然可以正常运行，但在使用工具方面表现得很吃力。

接着就是一堆可调参数。从常见的如 temperature（温度），到更冷门的如 K Cache Quantization Type（K 缓存量化类型）。很多工具自带一组推荐设置，但合适的参数可能取决于是否启用了“思考模式”！

Qwen 3.5-9B（4b 量化）

qwen3.5-9b@q4_k_s (HuggingFace 链接) 是我目前找到的最合适的模型，大约每秒 40 tokens，开启思考模式，成功调用工具，并拥有 128K 上下文窗口，运行在 LM Studio 上。相比 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

为了启用思考模式，我还必须选择该模型，进入配置页面，在推理标签页底部添加 {%- 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": "Qwen 3.5 9B Q4_K_S",
          "tools": true,
          "context_length": 131072,
          "max_tokens": 32768
        }
      }
    }
  },
  "model": "lmstudio/qwen3.5-9b@q4_k_s"
}

与 SOTA 模型的对比

像 Qwen 3.5 9B（Q4）这样的模型远远无法像 SOTA 模型那样长时间独立解决复杂问题。你不能指望它一次性构建整个应用程序，否则只会徒劳无功。

真正有效的方式是一种更互动的工作流：你需要清晰地一步步与模型沟通，并给予大量指导。我知道这对很多人来说听起来毫无意义——为什么要用一个需要你全程盯着的模型？但我发现这反而让我更加投入。使用 SOTA 模型的问题在于，它们让你太容易把全部认知负担都甩出去，即使你本意是要主动控制这种倾向。

使用本地模型时，我需要承担更多的思考和规划工作，必须更加具体明确，但它仍然可以作为研究助理、调试伙伴，以及一个拥有大量编程语言细节和命令行用法即时记忆能力的天才。它不会带来大型 AI 公司宣传的那种 10 倍生产力提升，但至少是个有用的工具，而且很有趣。

为了让你了解哪些事情能成功、哪些不能，这里有一些非常基础的例子。

示例 1：

我想将 Elixir 的 linter 工具 credo 升级到最新版本，结果代码中出现了警告。作为一个实验，我让 Qwen 来看一下。

我：
  运行 mix credo --strict 并建议如何解决，不要直接编辑

Qwen：
    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 中更符合习惯，并且避免了计算列表长度的开销。

我让 Qwen 执行这些修改，它一次性完成了 4 处并行编辑，非常干净。总体来说这是一个非常简单的任务，我自己也可以通过在终端和编辑器之间来回切换获取行号来完成。努力程度差别不大，但确实方便很多。

示例 2：

在一些依赖项升级之后，我有一个 Dependabot PR 出现了 Git 冲突，而 Dependabot 因某种原因拒绝重新变基（rebase）。我拉下来后手动进行了 rebase，然后让 Qwen 来看看。这其实是一个非常简单的冲突，只需要保留每项的最新版本即可，模型也识别出了这一点。

我能看到冲突。情况如下：
HEAD（你当前分支）：
- sentry: 13.0.1
- tailwind: 0.3.1
另一侧（正在被 rebase 的提交）：
- 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
你想采用哪种方式？

然而，当我要求它执行更改时，它忘了真正做编辑，而是试图添加变更并继续 rebase，冲突标记依然存在。

> 思考：用户希望同时保留两个更新——sentry 13.0.1 和 tailwind 0.4.1。我需要通过保留 HEAD 版本的 sentry 和另一侧版本的 tailwind 来解决冲突。我会使用 git add 来暂存已解决的文件。
----
# 暂存已解决的 mix.lock 并继续 rebase
$ git add mix.lock && git rebase --continue
Vim: Warning: Output is not to a terminal
Vim: Warning: Input is not from a terminal
"~/workspace/mixtli/.git/COMMIT_EDITMSG" 32L, 1047Bump tailwind from 0.3.1 to 0.4.1
Bumps [tailwind](https://github.com/phoenixframework/tailwind) from 0.3.1 to 0.44.1.
- [Changelog](https://github.com/phoenixframework/tailwind/blob/main/CHANGELOG.mmd)
- [Commits](https://github.com/phoenixframework/tailwind/compare/v0.3.1...v0.4.11)

此外，它未能识别出 git rebase --continue 会打开编辑器，导致 OpenCode 卡住（不过这可能只是偶发问题）。

结论

总之，LLM 非常灵活，即使是本地模型也能做很多事情。你的想象力才是限制因素。本地模型虽然有明显的权衡，但也带来了不少吸引人的优势：

• 不需要互联网连接，你可以在飞机上工作！
• 成本仅限于你使用的电力，假设你本来就要买电脑，就不需要订阅服务。
• 训练这些模型仍会产生显著的环境成本，但开源模型公司在这方面的影响远低于头部企业，而且使用自己的硬件意味着减少数据中心需求。
• 玩弄它们很有趣。

LLM 对我们的世界产生了巨大影响，其中许多并非积极正面，但显然它们已经扎根于此。尝试本地模型的感觉更像是以一种更可持续、更积极的方式与这项技术互动。老实说，即使它偶尔犯错，也很有意思！

用心构建软件

© 2026 Johanna Larsson。保留所有权利。