24GB 内存 M4 运行本地模型：虽有局限但乐趣与优势并存！

在配备 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 - 9B4b 量化表现出色qwen3.5 - 9bq4_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 - 9bq4_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 - 9bq4_k_s: {name: 通义千问 3.5 9B Q4_K_S,tools: true,context_length: 131072,max_tokens: 32768}}}},model: lmstudio/qwen3.5 - 9bq4_k_s}与 SOTA 模型的比较像通义千问 3.5 9BQ4这样的模型远不能像 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) 02. test/jola_dev_web/controllers/blog_controller_test.exs:22- assert length(conn.assigns.posts) 03. test/jola_dev/blog_test.exs:10- assert length(posts) 04. 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非常灵活本地模型也能完成很多任务想象力就是边界。本地模型虽有明显权衡之处但也有吸引人的优点无需联网可在飞机上工作成本仅限于使用的电量无需订阅费用开源模型公司在环境影响方面远不及大型公司使用自己的硬件减少了数据中心的使用摆弄这些模型很有趣。大语言模型对世界产生巨大影响虽有很多不积极的影响但显然会一直存在。尝试使用本地模型是更可持续、更积极的与这项技术互动的方式。即便它偶尔出错也很有趣那你是否也想尝试一下本地模型呢