本地模型现在真的很好用了

自从本地模型问世以来，我一直在使用它们1。如今，这些模型的表现竟然出人意料地出色。

我有一台2022款的Mac M2，配备64GB内存和1TB存储空间。我曾多次使用

• Mistral 7B

• Gemma 3

• OpenAI OSS-20B

• Qwen 3 MOE,以及许多其他Qwen变体，比如Qwen 2.5 Coder

在各种不同的系统配置中进行测试，例如

• 原始的Llama CPP，搭配Open WebUI

• Llama-CPP-Python

• Ollama

• LLAMAFILES

• LM Studio

本地模型如今何去何从？

早期，本地模型运行缓慢、使用不便，而且在大多数编程任务上也谈不上多么精准。 直到我接触到GPT-OSS，人们普遍认为本地模型落后严重的想法才逐渐被打破。 不过，我并没有确凿的科学证据来佐证这一点——我个人对“一个模型是否足够好”的判断标准是： “我是否需要再用API模型来验证一遍？ ”而GPT-OSS正是我开始少用这种验证方式的第一个模型。

因此，目前我更多地将本地模型用于快速、个性化的开发需求，尤其是那些不需要实时更新的项目。对于这类任务，我更倾向于使用本地模型，而不是依赖云端的大型预训练模型。

然而，随着谷歌最新发布的Gemma 4系列模型，我终于得以在本地实现代理式编程，并且让循环的运行精度和速度达到了前沿模型的约75%水平——这简直令人惊叹！

截至目前，我主要使用gemma-4-26b-a4b作为默认的本地模型，该模型由LM Studio团队提供。在本地环境中，我已用它完成了以下工作：将一个原本以笔记本形式存在的Python脚本重构为包含5到6个模块的代码库； 对这个模块进行了代码检查,以确保其泛型类型注解的正确性（如今大多数前沿模型都能自动完成这一操作， 但并非总是如此）。

此外，我还用它来校对一些博客文章、编写单元测试，甚至用来搭建一个基础环境， 通过构建一个双塔架构的推荐系统，只为一睹代理在面对空白草稿时会做出怎样的反应。 以下是它生成的内容——虽然内容相当基础，但远超了我去年所想象的范围：

请注意，由于我将所有的代理式工作流程都运行在Docker容器中，且容器对执行权限的限制较为严格，因此环境受到一定限制。

我还在开发一款应用，能够从Arxiv论文中提取热门话题。 出于好奇，我让Pi浏览了我过去在LM Studio中的会话记录，从而了解自己究竟在用LM Studio做些什么：

毫不意外的是，由于我一直在研究Rijksearch。

这些任务其实并不算什么突破性的创新——毕竟，很多个人化的需求往往只需要在Google或Docs中进行简单的查询。 不过，当这些任务真正落到我的GPU和RAM上时，它们确实让我大汗淋漓，而且K-V缓存的容量也增长到了64GB内存。

不过，对我来说，更大的意义在于：就在短短六个月前，像这样的任务，即便再简单，对本地模型来说也几乎是不可能实现的。

Gemma-4-12b-qat刚刚发布， 但我已经对它的性能与模型规模之间的对比感到非常惊艳。 其模型架构本身2就十分有趣，提出了许多引人深思的问题，比如：“如果我们在性能和成本之间面临抉择， 又该做出哪些架构上的权衡？”而这个问题，在这场疯狂的代币热潮中，至今仍未得到充分的探讨。

如今在本地运行代理式模型

不过，别只听我的说法，不妨亲自试一试！ 如果你想尝试运行本地的代理式流程，你需要一台本地模型推理引擎、一套代理式框架， 以及本地模型的运行文件。3你还需要将代理式框架配置为指向你的本地推理端点——也就是通过推理引擎提供的下载的模型运行文件。

在本地环境下，我目前使用Pi作为代理框架，LM Studio作为推理服务器。不过，如果我能直接使用Llama CPP，或许会更快——这也是未来实验的一个潜在方向。

这篇帖子非常容易上手——通过Pi和LM Studio就能轻松实现代理式编程，尽管我在帖子的设置上做了一些小调整。

1. 模型：帖子推荐使用Gemma 26B A4B,但gemma-4-12b-qat的版本更新更早、体积更小、速度更快，同时在精度上几乎没有牺牲。

2. 安全性：我将每次Pi会话都运行在Docker容器中，并仅赋予其bash权限， 这样它就无法运行Python代码或进行网页浏览。 不过，我计划在未来的研究工作中，允许在另一个镜像中使用curl。

3. 代理框架配置：由于我所有的操作都在Docker中进行，所以我修改了Pi的models.json文件，使Pi能够与模型进行通信。

这是我的Docker Compose配置：

接下来，我们来看运行pi的Bash脚本。