现在运行本地模型已经很不错了

# 现在运行本地模型体验不错了 来源：https://vickiboykis.com/2026/06/15/running-local-models-is-good-now/ 自本地模型问世以来，我一直都在捣鼓它们（https://vickiboykis.com/2024/02/28/gguf-the-long-way-around/），如今，它们终于出乎意料地好用了。 我有一台 2022 年的 M2 Mac，64 GB 内存，1TB 存储，我用过的模型包括： - Mistral 7B（https://mistral.ai/news/announcing-mistral-7B/） - Gemma 3（https://deepmind.google/models/gemma/gemma-3/） - OpenAI OSS-20B（https://huggingface.co/openai/gpt-oss-20b） - Qwen 3 MOE（https://huggingface.co/Qwen/Qwen3-30B-A3B），以及大量其他 Qwen 变体，比如 Qwen 2.5 Coder（https://ollama.com/library/qwen2.5-coder） 这些模型跑在各种不同的系统配置上（https://vickiboykis.com/2026/05/18/tagging-my-blog-posts-with-bertopic-and-llms/），例如： - 原生 llama.cpp + Open WebUI（https://github.com/open-webui/open-webui） - llama-cpp-python - Ollama - llamafiles - LM Studio ## 现在本地模型发展到什么程度了？ 早期的时候，模型又慢又难用，而且对大部分编程任务来说准确度不高。本地模型严重落后的说法基本成立，直到——对我来说——GPT-OSS 发布才有所改观。我没有具体的科学证据——我自己衡量“模型够不够用”的直觉标准是“我是否需要再用 API 模型复核一遍”，而 GPT-OSS 是第一个让我开始不怎么做复核的模型。 也因此，我多数时候把本地模型当作快速、个性化的 Google 来用，解决那些不需要时效性的开发问题。 不过，随着 Google 在 Gemma 4（https://deepmind.google/models/gemma/gemma-4/）系列中的最新发布，我终于能在本地进行代理式编码（agentic coding）了，而且循环的准确度/速度大约能达到前沿模型的 75%，这已经非常了不起了。 到目前为止，我一直把 `gemma-4-26b-a4b` 的 LM Studio 实现（https://lmstudio.ai/models/google/gemma-4-26b-a4b）作为默认本地模型。我已经用这套本地环境做了这些事：将一个曾是 Notebook 的 Python 脚本重构为一个包含 5-6 个模块的仓库，并对该模块进行 lint（https://peps.python.org/pep-0585/），加入正确的泛型类型提示（大多数前沿模型现在会自动完成这个，但并非总是如此）。 我还用它校对了几篇博客文章、写了单元测试，以及引导生成了一个用于推荐的双塔模型仓库——就想看看代理在空白的条件下会做些什么。下面就是它生成的内容，虽然很基础，但已经超出了我去年能想象的范围： 注意：由于我把所有代理工作流都放在一个对执行权限有限的 Docker 容器中运行，所以环境是受限的。 另外，我正在做一个 App，用来展示 arXiv 论文的热门主题。出于好奇，我让 Pi 翻看了我过去的 LM Studio 会话日志，整理出我平时用 LM Studio 做什么： 毫不意外，因为我一直在做 Rijksearch（https://vickiboykis.com/2026/04/20/build-yourself-flowers/）项目。 这些都不是什么突破性的任务（主要还是大量个性化的 Google/文档查询），而且运行它们确实让我的 GPU 和内存忙碌起来，K-V 缓存会增长到 64 GB。 但对我来说，更大的意义在于：就在 6 个月前，这类任务对本地模型来说还不可能完成，即便它们现在看起来如此简单。 `Gemma-4-12b-qat`（https://blog.google/innovation-and-ai/technology/developers-tools/quantization-aware-training-gemma-4/）刚刚发布，但以它的尺寸而言，其性能已经令我印象深刻。模型架构本身非常有趣（https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-gemma-4-12b），并提出了很多有意思的问题，比如：“如果受限于性能和价格，我们在架构上需要做出哪些权衡？”这个问题在当前疯狂的 token 淘金热中是很少被问及的。 ## 今天如何在本地运行代理式模型 不过，别光听我说，自己试试吧！如果你想尝试本地的代理流程，你需要一个本地模型推理引擎、一个代理工具框架（agentic harness），以及本地模型制品。你需要把工具框架配置指向你的本地推理端点，而下载好的模型制品（https://vickiboykis.com/2024/02/28/gguf-the-long-way-around/）则通过推理引擎对外服务。 我目前的本地配置是：用 Pi（https://pi.dev/）作为代理工具框架，用 LM Studio（https://lmstudio.ai/）作为推理服务器——虽然如果直接用 llama.cpp 可能会更快，这也是未来实验的一个潜在方向。 按照这篇文章（https://patloeber.com/gemma-4-pi-agent/）的说明设置 Pi + LM Studio 的代理编码非常顺利，不过我做了一些小的调整： 1. **模型：** 文章推荐的是 `Gemma 26B A4B`，但 `gemma-4-12b-qat` 更新、更小、更快，而且精度损失不大。 2. **安全：** 我把每个 Pi 会话都放在 Docker 容器中运行，只给它 bash 的权限，这样它就不能执行 Python 代码或浏览网页，不过后续我打算在另一个镜像里允许 curl，以便做一些研究工作。 3. **代理工具框架配置：** 因为所有东西都跑在 Docker 里，我修改了 Pi 的 `models.json`，让 Pi 能与模型通信。 `` "lmstudio": { "baseUrl": "http://host.docker.internal:1234/v1", "api": "openai-completions", "apiKey": "not-needed", "models": [ { "id": "google/gemma-4-12b-qat", "input": [ "text", "image" ] } ] } `` 这是我的 Docker Compose 配置： `` services: pi: build: context: . dockerfile: Dockerfile image: pi-agent:0.74.0 init: true stdin_open: true tty: true extra_hosts: - "host.docker.internal:host-gateway" environment: ANTHROPIC_API_KEY: ${ANTHROPIC_API_KEY:-} OPENAI_API_KEY: ${OPENAI_API_KEY:-not-needed} GEMINI_API_KEY: ${GEMINI_API_KEY:-} OPENAI_API_BASE: ${OPENAI_API_BASE:-http://host.docker.internal:1234/v1} # 注意：如果你也用 OpenAI 访问实际完成端点，需要指定一个 base WHATEVER_API_KEY: ${WHATEVER_API_KEY:-} volumes: - ${HOME}/.pi/agent/models.json:/config/models.json - ${WORKSPACE:-.}:/workspace - pi-config:/config - pi-sessions:/sessions working_dir: /workspace volumes: pi-config: pi-sessions: `` 下面是运行 `pi` 的 bash 脚本： `` #!/usr/bin/env bash # Pi — 启动容器化的 Pi 代理。 # 包含此脚本及 compose 文件的目录。 SCRIPT_DIR="$(cd -- "$(dirname "${BASH_SOURCE[0]}")" && pwd)" # 挂载到容器中的工作空间目录。 WORKSPACE_DIR="${WORKSPACE:-$(pwd)}" case "$WORKSPACE_DIR" in /*) ;; *) WORKSPACE_DIR="$(cd -- "$WORKSPACE_DIR" && pwd)" ;; esac export WORKSPACE="$WORKSPACE_DIR" sandbox="${PI_SANDBOX:-0}" pi_args=() while (($#)); do case "$1" in --sandbox) sandbox=1 ;; --no-sandbox) sandbox=0 ;; *) pi_args+=("$1") ;; esac shift done compose_files=( -f "$SCRIPT_DIR/docker-compose.yml" ) if [[ "$sandbox" == "1" ]]; then # 更安全的沙箱 compose_files+=( -f "$SCRIPT_DIR/docker-compose.sandbox.yml" ) fi # 从工作空间目录的 basename 派生容器名称。 # 清理为 Docker 接受的字符：[a-zA-Z0-9][a-zA-Z0-9_.-]* repo_slug="$(basename -- "$WORKSPACE_DIR" | tr -c 'a-zA-Z0-9_.-' '-' | sed 's/^-*//')" [[ -z "$repo_slug" ]] && repo_slug="workspace" container_name="pi-${repo_slug}-$$" api_key_args=( -e OPENAI_API_KEY -e DEEPSEEK_API_KEY -e ANTHROPIC_API_KEY -e GEMINI_API_KEY ) cmd=( docker compose --project-directory "$SCRIPT_DIR" "${compose_files[@]}" run --rm --name "$container_name" "${api_key_args[@]}" pi ) if ((${#pi_args[@]})); then cmd+=("${pi_args[@]}") fi exec "${cmd[@]}" `` 我构建 Docker 容器，并在其自身的仓库中对文件进行修改。然后，我在当前工作仓库中运行 Pi，这会启动 Docker，从而让 Pi 无法在我的物理硬盘上执行操作（例如擦除文件或目录）。这还允许容器中的 Pi 通过将自定义的模型 `json` 配置传入容器来看到它。所有这些对于我的实验来说都运行得相当不错。 本地模型仍然存在一些问题：推理可能很慢，上下文窗口受限于你的硬件，而且生态系统虽然通过 LM Studio 和 HuggingFace 的“使用此模型”按钮（https://huggingface.co/blog/yagilb/lms-hf）等工具变得容易得多，但早期版本仍会遭受提示模板不匹配（https://docs.langchain.com/langsmith/prompt-template-format）的困扰。不过，这些问题通常很快就能得到修复。不用多说，我不确定它现在是否已经准备好用于生产级软件开发。 但好处是很多的，而且这个生态系统值得投入，尤其是在当下。本地模型非常酷的一点是，你几乎可以内省一切，比如实时观察 token 推理过程， 以及查看 token 的流入和流出。 你可以做这些事情：改变本地上下文窗口并观察性能的提升或下降，深入了解你的 token 在 GPU 上是如何被处理的。你可以修改系统提示、量化方式。你可以让模型相互较量。你还可以修改和内省工具框架这一侧。 可能性是无限的，而工具只会越来越好。