AI 编程工具的规模效率反思

小模型在代码任务上足以媲美巨型模型

我们打开 IDE，让某个运行在云端的模型读取整个代码库，只为添加一个 null 检查——顺便还一路追踪我们的行为。我们打开 Google Docs，请 Gemini 修正一个拼写错误。我们启动 GPT 级别的模型来润色一条 Slack 消息、调整一段评论的结构、生成一张缩略图。凡是有数据可供训练的地方，我们都打算把 AI 硬塞进去。

我并不是说我们不应该这样做——这是技术进步的必然趋势，我们在这件事上也没有太多选择。但不知从何时起，我们不再追问：模型的规模是否与任务的规模相匹配？而答案往往是：不匹配，只是我们不太愿意承认罢了。

这并不是什么末日论调。我们不会被取代。只是我们仍处在采用 AI 的早期阶段，大多数人还没有完全理解 AI 不是什么、它的边界又在哪里，对它抱有太多一厢情愿的幻想。这意味着我们仍然可以塑造它——就像我们曾经塑造广播、互联网，后来又塑造开源一样。我们只需要为这项技术找到一条更自然的道路，赶在当前的默认模式固化为唯一选项之前。

数据并不支持当前的默认选择

以 Qwen3-Coder-Next 为例：它总共有 80B 参数，但实际激活的只有 3B，却能达到那些活跃计算量高出 10～20 倍的模型的水平；而且它可以运行在高端消费级硬件上，例如配备 64GB 以上内存的 Apple Silicon Mac，或搭载高性能工作站显卡的设备，而不需要占用一整排数据中心机架。再往小了看，事情会变得更有意思。一个针对特定任务进行 fine-tuning 的 Qwen3-4B，在该任务上的表现可以媲美 120B 以上的模型，同时还能部署在消费级硬件上。再看看 Chandra——这是一个专为 PDF 和图像转换打造的 5B OCR 模型，在多语言文档 benchmark 上同时击败了 Gemini 2.5 Flash 和 GPT-5 Mini。不是因为它更聪明，而是因为它足够专注。

每次主流模型发布，声势都像是发生了一场足以撼动世界的大事件：它注定会让此前的一切黯然失色，并把所有事情的效率提升十倍。可等我们真正开始使用它时，通常只会发现一些有限的提升——大多集中在特定方面，也大多源于模型接受过什么样的训练。以 Anthropic 神秘公布的 Mythos 为例，据说它“危险到不能发布”——但我们甚至还不知道它是否配得上如此声势浩大的宣传。与此同时，Aisle 的这篇实验性文章已经表明，小模型在漏洞扫描中可能达到甚至超过它的表现——这只是一次早期实验，但已经很能说明问题。

而且，这并不是什么新发现。早在 2022 年，Chinchilla 就已经对“越大越好”的正统观念发起挑战。此后，相关证据只增不减：针对特定任务、使用高质量数据训练的小模型，可以达到甚至超过那些体量大得多的同类模型。可我们依然习惯性地选择当时能用的最大模型，一部分是出于惯性，另一部分则是因为所有希望把我们留在云端的人，都在不遗余力地推动云端范式。标题里的宣传总是跑在现实前面，而现实是：对于大多数任务来说，通过扩大模型规模来获得有效回报，早已过了收益明显的阶段。

还有另一条路，而且它并不像《Cyberpunk 2037》。你不需要庞大的 H200 集群，只为把简历美化得更漂亮一些。这条路会带来更加平等的 AI 分布，也不试图取代任何人。

这条道路由小型专用模型构成，它们最多只接受训练来完成一种或少数几种特定任务。这些模型足够聪明，能够实现自己的用途；同时又足够小，不会给人造成它们正在取代谁的错觉。这才是未来的大众 AI——真正的共生。或者更准确地说，这才是正确使用工具的方式。

因为 AI 并不是一个生命体。它只是对生命体的模拟：一个经过巧妙工程设计的统计模型，擅长以一种看起来像适应能力的方式进行近似。把它当成一个生命体，会让我们每次都伸手去拿规模最大的模型，就好像是在请某个人帮忙一样。把它当成工具，才能让我们根据任务选择匹配的模型——就像你不会拿链锯来切面包。

落实到实践中，这意味着软件从一开始就应该以 AI-native 的方式构建，而不是事后通过 MCP 和对远程巨型模型的 API 调用，把 AI 生硬地拼装上去。比如，一个内置或可插拔小模型的文档编辑器，可以完成语法检查、结构调整和摘要，而且全部在本地运行。一个只专注于 OCR、并且把 OCR 做好的处理流水线，再配上一个小型 RAG 模型，让你真正能够在本地搜索和查询一整架扫描论文或 PDF。一个配有小模型的视频编辑器，可以直接在你的机器上剪辑视频片段并添加标签。一个运行在玩家硬件上的游戏内 AI。这些场景都不需要什么技术突破——相关模型已经存在；只要有足够的数据，即使没有价值十亿美元的集群，也可以把它们训练出来。

目前缺少的是一种能够妥善承载这些模型的软件范式，以及一个可以将它们串联起来的 orchestration 层。如果说通用 AI 的普及仍处于早期阶段，那么小模型 orchestration 甚至还在襁褓之中：工具、约定和生态系统都尚未成型。ComfyUI 已经可以让人们把专用的图像和视频模型串联成本地流水线——这是目前最接近可行蓝图的方案，尽管它仍然很脆弱，而且严重依赖 Python venv。LM Studio 和 Ollama 让本地运行模型变得简单而稳定，但它们更像 runtime，而不是 orchestrator。这些方案都还只是胚胎——但它们证明了这种范式是可行的。而这正是值得我们继续投入建设的部分。

大模型仍然适用的地方

大模型并不是一条死路。对于真正困难、开放式的问题，它们才是合适的工具——例如跨越陌生代码库的复杂编程、深入分析，以及任何确实需要在广泛上下文中进行推理的任务。这里的观点并不是“所有事情都应该用小模型”，而是“不要用一个万亿参数的模型来修正拼写错误”。

更诚实的 AI 未来会是混合形态：在真正需要大模型能力的地方使用大模型，而对于数量庞大的聚焦型长尾任务，则使用小型专用模型——后者其实占据了绝大多数。真正造成浪费的，是用同一种方式对待这两类场景，而不是技术本身。

凡事都使用大模型，才是一条死路。不是因为它行不通，而是因为它的成本，以及它最终会把我们带向何处。每一条被发送给 frontier model 的“修正这个拼写错误”，都是投给计算集中化、数据集中化，以及“由谁决定 AI 下一步该做什么”这一权力集中化的一张小票。把它乘以每天十亿条 prompt，就得到了我们正在吹大的泡沫——在这个泡沫中，唯一可行的 AI，是那种必须由 hyperscaler 才能运行的 AI。

小模型路线并不只是效率更高。它也更加诚实地面对了一个事实：大多数 AI 任务真正需要的究竟是什么。同时，它也为 AI 留出了成为其他形态的空间，而不只是我们从少数 hyperscaler 手中租用的一项服务。

我们仍然可以走上这条道路。许多模型已经准备就绪，另一些模型还有待探索和训练。硬件也已经具备。现在缺少的，是停止认定“越大越好”的意愿，以及让“小”成为新默认选择的软件。

部分评论可能仅对已登录的访客可见。登录后可查看全部评论。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。