如何让本地大模型开始自动干活

albert0211
8 阅读8分钟

调用本地 GPU 上的大模型，整个 AI 推理过程，全部都在本地完成。没有任何 AI API，也没有任何 Token 消耗。以前很多 AI 工具，一旦断网，直接就废了。但现在，本地 AI Agent 已经开始具备真正的离线能力。这一点，其实非常重要。因为这意味着，未来很多 AI 工作流，可能都会开始从“云端依赖”逐渐转向“本地运行”。

本地部署

1、安装 OpenAI Codex

如果你下载的是 macOS 版，注意选择 Intel / M 芯片。

2、安装新版 Ollama

目前只有最新版 Ollama 0.24 版本才完全适配 Codex，所以如果你安装的是旧版 Ollama，一定要将其升级到最新版。根据官方公告，Ollama v0.24.0 于 2026 年 5 月 15 日正式发布，Codex App 正式加入 Ollama 体系，同时围绕本地与云端模型调用、浏览器交互、代码评审以及 Apple Silicon 上的推理体验做了系统性增强。

3、下载模型

在 4B~40B 消费级显卡能跑的开源模型中，首推 Qwen3.6开源模型，因为无论是模型智力、代码编写、逻辑推理、中文理解等方面，这两款模型的综合评分都是数一数二的！

Qwen3.6 开源模型

安装命令：


ollama run qwen3.6

ollama run qwen3.6:27b

Mac 电脑上请选择 mlx 结尾的适配版：


ollama run qwen3.6:27b-mlx

ollama run qwen3.6:35b-mlx

Mac 电脑可选模型：


ollama run gemma4:e2b-mlx

ollama run gemma4:e4b-mlx

ollama run gemma4:26b-mlx

4、对接命令


ollama launch codex-app

注意：如果需要使用之前的模型，可以通过下方的命令进行恢复：


ollama launch codex-app --restore

2、llama.cpp 的启动命令


llama-server.exe ^

-m "models\Qwen3.6-27B-UD-Q5_K_XL.gguf" ^

-ngl 999 ^

-c 16384 ^

-n 2048 ^

-fa on ^

--jinja ^

--host 127.0.0.1 ^

--port 8080

里面的模型改成你自己的。

现在很多小模型已经完全可以胜任基础 AI 编程任务。

比如：

  • Qwen 系列。

  • DeepSeek Coder。

甚至一些 7B、14B 的模型，最低 6G、8G 显存，现在都已经可以跑起来了。 虽然速度肯定没办法和 4090 相比，但对于很多普通用户来说，已经足够体验“本地 AI 自动编程”这件事情了。 一个 AI Agent，已经开始逐渐具备独立完成整个流程的能力。这件事情，其实是非常恐怖的。更夸张的是，现在很多 Agent 已经不仅仅局限于代码开发。它甚至还能自动打开浏览器、自行搜索、自行浏览网页、自行下载文件，然后自动完成整个操作流程。这已经越来越像真正的 AI 助手了。而 Ollama，现在正在成为整个本地 AI 生态里非常核心的一环。以前很多人觉得，Ollama 只是一个简单的本地模型启动工具。

附录：常见问题与解决方案

❌ 问题一：ollama run qwen3.6:27b-mlx 报 500 错误

不少 Mac 用户在按照上述步骤执行 ollama run qwen3.6:27b-mlx 时，可能会遇到如下报错：


Error: 500 Internal Server Error: model requires 18.4 GiB but only 17.3 GiB are available (after 512.0 MiB overhead)

原因分析：

这个错误本质上不是软件 Bug，而是触发了 macOS 统一内存（Unified Memory）的硬性限制。 Qwen3.6-27B 模型根据量化精度的不同，对内存的需求也不同。根据 Unsloth 官方文档的数据，4-bit 量化版本需要约 18GB 内存，8-bit 版本则需要约 30GB。模型本身的参数量是固定的——约 270 亿参数，要想运行它，就必须有足够的内存来装载这些参数。mlx 版本虽然已针对 Apple Silicon 做了优化，但在内存占用上并未进行极致压缩，17.3GB 的可用内存在扣除系统服务和其他后台应用的开销后，实际能分配给模型的连续内存已经不足以支撑 27B 模型的加载。

而且，macOS 为了系统稳定性，单个进程可调用的显存上限通常被限制在物理内存的 60%-70%，当系统已占用 + 模型权重 + KV Cache 逼近物理极限时，内存分配器会拒绝申请。

解决方案如下：

✅ 方案一：换用 4-bit 量化版本

如果你的硬件内存有限，优先尝试 Qwen3.6-27B 的 4-bit 量化版本。该版本只需要约 15-18GB 内存即可运行。你可以搜索 qwen3.6:27b-mlx-4bit 这样的 Tag：


ollama run qwen3.6:27b-mlx-4bit

✅ 方案二：换用更小的模型

如果你的设备确实无法满足 27B 模型的内存需求，可以考虑使用 14B 甚至 7B 的模型。这些模型在代码生成和项目修复等任务上表现同样出色，但内存门槛大幅降低：


ollama run qwen3.6:14b-mlx

ollama run qwen3.6:7b-mlx

一个 4-bit 量化的 7B 模型大约只需要 3.5-4GB 内存，14B 模型大约需要 7-8GB。

✅ 方案三：通过 llama.cpp 加载 GGUF 量化模型

这是目前最灵活、内存利用率最高的一种方案。因为 llama.cpp 采用了更高效的内存管理机制，而且 GGUF 格式本身在量化压缩方面经过了大量的社区优化。

具体步骤：

  1. 下载 GGUF 格式模型：在 Hugging Face 等平台搜索并下载 Qwen3.6-27B-GGUF，推荐选择 Q4_K_M 或 Q5_K_XL 级别的量化模型。根据实测数据，Q4_K_M 量化的 27B 模型文件大小约为 15-16GB，配合合理的上下文长度设置，可以在 17GB 可用内存下稳定运行。

  2. 启动 llama-server 服务：


./llama-server -m /path/to/Qwen3.6-27B-UD-Q5_K_XL.gguf \

  -ngl 99 \

  -c 8192 \

  -fa on \

  --jinja \

  --host 127.0.0.1 \

  --port 8080

参数说明：

  • -ngl：指定加载到 GPU 的层数，值越大 GPU 参与越多，速度越快（可根据内存情况适当调低）

  • -c：上下文长度，建议从 8192 开始，内存充裕时可适当调大

  • -fa：启用 Flash Attention，可显著降低 KV Cache 的内存占用

  • --jinja：启用模型的对话模板，确保模型能够正确处理 System Prompt 和多轮对话格式

  1. 配置 Codex 连接 llama.cpp：按上文“更强玩法”中的配置文件修改即可。

✅ 方案四：调整 Ollama 的内存相关配置

  • 降低上下文窗口大小：通过环境变量限制上下文长度，可以显著降低 KV Cache 的内存占用：

export OLLAMA_CONTEXT_LENGTH=8192

ollama run qwen3.6:27b-mlx

默认的 262144（约 262K tokens）远超多数任务的实际需求，降低到 8192 可以节省数 GB 的内存。

  • 限制同时加载的模型数量：

export OLLAMA_MAX_LOADED_MODELS=1
  • 清理系统缓存：在进行高载荷推理前，关闭浏览器、IDE 等大型应用，或者执行 sudo purge（macOS）强制刷新系统缓存，可以为模型腾出更多可用内存。

❌ 问题二：下载好的模型突然找不到了

现象：明明已经成功 pull 了模型，但 ollama list 看不到，或者 ollama run 提示模型不存在。

原因：Ollama 0.24 版本更新后，模型存储路径和 Manifest 索引机制有所调整。此外，直接从非官方源 pull 模型往往会因为缺少 GGUF 适配而失败。 解决方案：

  1. 升级到最新版 Ollama：ollama --version 确认版本 ≥ 0.24.0

  2. 重新 pull 模型：ollama pull qwen3.6:27b-mlx

  3. 如果仍然失败，尝试从官方指定的镜像源下载

❌ 问题三：Ollama 下载模型缓慢

现象：ollama pull 卡住或速度极慢。

原因：国内网络访问国外 Hugging Face 等源时速度受限。

解决方案：

  1. 配置代理环境变量：

export HTTP_PROXY=http://127.0.0.1:7890

export HTTPS_PROXY=http://127.0.0.1:7890

ollama pull qwen3.6:27b-mlx
  1. 或者直接使用国内镜像源（如有）

❌ 问题四：Codex 无法连接 Ollama

现象：执行 ollama launch codex-app 后，Codex 报错无法连接或找不到模型。

原因：Ollama 服务未正常启动，或 Codex 配置的模型名称与实际模型名称不匹配。

解决方案：

  1. 确认 Ollama 服务正在运行：ollama list 应显示已安装的模型

  2. 先手动启动 Ollama 服务：ollama serve

  3. 确认模型已下载：ollama run qwen3.6:27b-mlx 能否正常进入对话

  4. 检查 Codex 配置文件中的模型名称是否与 ollama list 输出完全一致

✅ 方案五：强制 CPU 模式（不推荐，仅作最后尝试）

如果实在无法加载，可以考虑禁用 GPU 加速，强制使用 CPU 运行，但代价是推理速度会显著下降：


OLLAMA_NUM_GPU=0 ollama run qwen3.6:27b-mlx

📌 经验总结

在 Mac 这种统一内存架构下，部署大模型不是简单的“下载即运行”，而是一场关于算力、内存与量化精度的博弈。理解量化（Quantization）和分层卸载（Offloading）的底层逻辑，才能真正发挥出 Apple Silicon 芯片的性能。

在实际部署前，建议先查看模型的实际内存需求：


ollama show qwen3.6:27b-mlx --modelinfo | grep size

如果模型要求的内存超出了你的可用内存，优先尝试换用量化版本或更小的模型。对于追求稳定性的用户，强烈推荐 GGUF + llama.cpp 方案，它能让你在相同硬件上运行更大的模型。

avatar
文章
阅读
粉丝