新文章：我最近如何使用本地模型进行开发。现在的工具已经足以支持智能体工作流，大家都应该试一试！

https://t.co/3Tx3CMsNG3

现在运行本地模型体验良好

来源：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，配备 64GB 内存和 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/) 系列，我终于能够在本地进行智能体编码，并且工作流的准确率/速度达到了前沿模型的大约 75%，这已经非常惊人了。

到目前为止，我主要使用 LM Studio 实现 (https://lmstudio.ai/models/google/gemma-4-26b-a4b) 的 gemma-4-26b-a4b 作为默认本地模型。我已经用这个本地设置完成了：将一个笔记本形式的 Python 脚本重构为包含 5-6 个模块的仓库，并检查该模块 (https://peps.python.org/pep-0585/) 以使用正确的泛型类型提示（大多数前沿模型现在已经自动完成这点，但并非总是如此）。

我还用它校对了一些博客文章，编写了单元测试，并引导了一个仓库来搭建双塔推荐模型，只是想看看智能体在空白状态下会做什么。以下是它生成的内容，虽然相当基础，但已超出去年我认为可能达到的范围：

注意环境是受限的，因为我所有智能体工作流都在一个 Docker 容器中运行，执行权限有限。

我还在构建一个从 Arxiv 论文中提取热门话题的应用。出于好奇，我让 Pi 浏览我过去的 LM Studio 会话日志，看看我都在用 LM Studio 做什么：

毫不意外，因为我一直在研究 Rijksearch (https://vickiboykis.com/2026/04/20/build-yourself-flowers/)：

这些都不是开创性的任务（很多还是个性化的 Google/文档查询），而且处理它们确实让我的 GPU 和内存活动起来，K-V 缓存增长到了 64GB 内存。

但对我来说，更重要的是，这些任务即使是简单的，在 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 淘金热中还没有被真正问过。

今天如何本地运行智能体模型

但以上这些你们不要只听我说，自己试试看！你需要一个本地模型推理引擎、一个智能体框架以及本地模型工件，如果你想尝试运行本地智能体流程。你需要设置框架以指向你的本地推理端点，以及通过推理引擎提供的已下载模型工件 (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. 安全： 我在 Docker 容器中运行每个 Pi 会话，仅赋予其 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

# 根据工作空间目录的基本名称派生容器名称。
# 清理为 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 上的处理方式。你可以更改系统提示、量化方式。你可以让模型相互对抗。你还可以更改和自省框架方面。

可能性是无限的，而且工具只会越来越好。