本地版 Qwen 不是更差的 Opus，而是另一种工具

我们都听人说过，本地版 Qwen 27B 或 35-A3B“接近 Opus 水平”，但我掌握着一家软件企业和开源项目的实际凭据，现在想坦诚地告诉你们。

这篇文章之所以写得很长，是有原因的。它不是走马观花式的浅尝辄止，不是有人在 X 上毫无依据地宣称要取消 Claude Max，也不是一篇关于模型以每秒个位数 Token 运行、上下文窗口仅有 32K 的业余玩家体验报告。它也不是出自某位知名 CEO 之手，在飞机上发推大谈编程。

这是我作为一家小型软件企业创始人的亲身历程：本地模型已经带来了真实但附带前提的价值。我切身投入其中，但没有动机去为云端模型或本地模型中的任何一方站台；同时，我也强烈希望本地模型能够变得更强大、更可靠。

我会讲讲这块显卡如何在前两三个月内就回本，它如何持续服务于我们特定的业务场景，为什么我至今仍无法在无人监督的情况下信任它，以及 Qwen 最糟糕的特点：陷入无限循环和产生幻觉的风险。尤其是在为了适配消费级 GPU 而对其进行量化压缩时，这些问题最为明显。

摸清 RTX 6000 Pro 的供电接口

谈谈我使用 AI 的场景

我作为维护者和创始人的历程始于 OpenFaaS——完全靠手工构建，正如 2016 年直到最近的大多数软件一样。这意味着我需要独自打下项目的核心基础，然后再通过社区邀请他人参与——并不是因为我一个人做不到，而是因为我的目标是打造一个成功的开源项目。大约在 2017 年，我尝试通过加入 VMware 为自己的时间投入获得资金支持；到了 2019 年，随着市场变化，我需要找到一种能够自行资助这项工作的方式，于是转向开放核心模式，并创办了一家自筹资金的公司。如今，我们这个小团队维护着 OpenFaaS、SlicerVM——AI 沙箱和“Linux 缺失的 API”、Actuated.com——面向 GitHub/GitLab 的自托管 CI 运行器，以及 Inlets.com——自托管的 HTTP/TCP 隧道。

这些产品使用了诸如容器、Kubernetes、Firecracker microVM 以及网络协议等非常底层的 Linux 原语。往宽了看，它们本质上都是带有明确设计取向的基础设施产品，聚焦于：效率、用户体验、控制力和自主性。它们用 Go 编写，其中一些还配有基于 React 的 UI 组件、落地页、文档、代理技能和 CLI。除代码之外，我们还提供一流的支持服务，因为我们的团队精干，也愿意去做那些无法规模化、但能帮助顾客的事情。

自从 AI 工具问世以来，我就一直在使用它们——从早期 VS Code 里的 Tab 自动补全，到让 ChatGPT 生成成段代码、查找漏洞，再到每天有 12 个小时都泡在 tmux 里。我发现自己大部分时间都待在 tmux 中，以至于我写了一个免费的工具 Superterm.dev，用来跟踪我的会话、笔记，并获取来自编码代理的可视化反馈。在这段时间里，我见证了这些工具的能力从“减少样板代码”发展到“完成端到端的设计、架构与测试”。承担我大部分工作的是 Claude 或 Codex；虽然我坚持自己写文章，但我已经很少亲手写代码了——尽管这么说让我有些不是滋味。

前沿智能的转折点

我想，大约是在 2025 年 11 月至 2026 年 1 月之间，我们看到了一个转折点。X 上的许多开发者开始推崇 Claude Opus，认为它已经发生了变化，如今能够完成他们全部的工作。手动编程迅速变得像离开冰箱的牛奶一样，很快就馊了。顶级编程方案的费用稳定在个人每月约 200 美元。这个数字确实不小，但考虑到它们创造的价值，仍在可接受范围内。即便是今天，只要避免过多无人值守的工作，你仍然可以让它撑过 5 小时限制；如果足够谨慎，连每周限额也能应付过去。

是什么让本地模型变得有趣

有一种观点认为：“既然负担得起，为什么不用你能买得起的最好产品？”

2026 年无疑是一个全新的前沿时代：我们发现自己正身处这样一个环境——任何想法，都可能在一夜之间被某个你从未听说过、只是在某个发展中国家买了个订阅的人复制出来。我亲眼见过这种事发生在我们的 SlicerVM 产品上（最初于 2022 年手写完成），也发生在 Superterm 上（2026 年的新产品，100%由编码代理编写）。这并不是说，一个“氛围编码”克隆品就能 100%等同于一个经过精良工程设计与架构、并由经验丰富团队提供支持的解决方案；但在一个软件成本趋近于零的市场里，免费且“足够好”也许就是唯一重要的事。

那么，在这样一个竞争激烈的格局中，为什么还要把自己限制在一个更差的选择上？这难道不是机会成本吗？这难道不是在拿自己的生计冒险吗？

有估计认为，领先模型的参数规模介于 0.5 万亿至 2 万亿之间。这可不只是比本地硬件上同类最佳模型“略多一些”或“多出几倍”——而是完全不同的量级。参数数量大致可以作为模型容量、知识储备和推理能力的代理指标。然而，不知为何，即便是像 Qwen 3.6 27B 这样的小型稠密模型，也能在 SWE-Bench Verified 这一权威基准测试中拿到 77.2 分，而 Claude Opus 4.8 的成绩为 88.6%。

因此，如果你跑到 X 上高声宣称“本地模型只比 SOTA 落后 12%”，别人也未必会苛责你；很多人确实就是这么做的，还会拿《太空侵略者》这类一击即中的演示来助阵。你甚至可能进一步声称，一块已有 6 年历史的单张 GPU，就能替代你每月 200 美元的 ChatGPT Pro 订阅，而事实上，很多人也的确提出过这样的说法。

基准刷分

基准测试是一个不断变化的目标，而且由于它们被广泛获取，完全有可能通过针对这些测试对模型进行训练和调优，使其在这类测验中拿到比原本更高的分数。经典的 SWE-Bench Verified 基准测试，基于多个开源项目中的一组 Python 问题。Python 有线程，也有异步机制，但你实际遇到的大多数代码仍是单线程、同步执行的。相比之下，我们用 Go 编写分布式系统，其中 channel、context 和 struct 横跨很大的执行域。

成本

有一种非常流行的观点认为，“本地模型无关成本”，但这其实是站在一种特权位置上说的话。个人用户可以使用这类编程套餐，以每月 200 美元的价格换取足以支撑整个工作日的大量使用额度。就这一点而言，你获得的是 SOTA 级别的智能、某项功能真正可用且质量过关的最佳机会，更有希望找到那个 bug，或者生成那个落地页。

编程套餐显然是有补贴的，看看 GitHub Copilot 套餐后来发生了什么就知道了。它们最初以每月 39 美元提供 1500 次请求，而这点额度花不了多少钱却能用很久。GitHub/Microsoft/Azure 内部有些未曾披露的事情发生了，随后他们把所有人都转到了基于代币的定价模式，引发了巨大反弹。真实成本被隐藏了太久，我们早已对此习以为常。

如今，如果你是按 API 费率为 token 付费，达到临界点的时间会比我们许多人意识到的更早。最近，Uber 将每位开发者、每种工具的月度支出上限设定为 1500 美元。Uber 的年薪中位数为 33 万美元，因此如果一名开发者把两种工具都用到上限，这大致相当于其全年薪酬的 12%。

因此，对于高强度使用、循环任务、智能体分析，以及通过 SaaS 系统部署到产品中的能力而言，开放权重模型或本地模型都能提供真正可观的价值。不考虑成本并不公平，但对很多人来说，重点并不在这里。

主权与隐私

我们与各类企业顾客合作，这些顾客对数据控制极为重视。如果你从整体上看我们的产品线，就会发现我们的核心就是隐私与主权。OpenFaaS 在你的基础设施上运行函数，遵循你的限制、你偏好的语言以及事件体系。SlicerVM 运行的是微型虚拟机，不是在某种抽象化的云端裸金属上，而是在你自己的设备上，甚至包括你的 MacBook。Inlets 运行隧道，而你可以在 100% 隐私条件下控制隧道客户端和服务器。Actuated 则把 GitHub Actions 中那些繁琐艰难的部分拿走，并且告诉你：“在你的机器上安装一个代理，然后就不用再操心了。”

因此，我们自然而然会被本地模型所吸引——这既源于我们的核心价值观，以及我们对互联网应有样貌的信念，也源于现实责任。

你或许并不持有这些看法，也可能并不处理任何顾客数据，但如果你身处美国之外，那么 Anthropic 的 Fable 5 模型一夜之间被下架，可能会让你感到震惊。换句话说，供应商风险确实存在，而我们中的许多人已经对这一来源形成了依赖。

本地模型正是用来回答“如果前沿实验室做出 X 这样的举动怎么办？”这一问题的解决方案。

为刀片回火

我说过，本地模型与 SOTA 并不是同一种工具。我这话是什么意思？

我用手工具制作家具，也偶尔会像为了满足某种需求而发布一个开源项目那样，做一些刃具，比如凿子、开槽刨刀片、划针、用于雕刻的 Sloyd 小刀。

将一把日式划线刀放在加热的锉刀背上回火，直到刀身呈现稻草色。

根据你能投入的资金多少，钢材加工有两种方式。锻造是把一块原钢加热后，用锤子反复敲打成所需的形状。它被视为最纯粹、最有荣誉感的加工方式——“真正的做法”。而对于较小的物件，“去料成形”则更容易上手。它是以钢板为材料，切出形状，再磨出斜面或尖端。

但这还只是定型。接下来还得把钢加热，再放入油或水中淬火。这样会让钢变得极其坚硬，硬到掉在地上都会碎成几块。所以我们必须擦掉表面的黑色氧化层，再次加热，盯着那一抹彩虹般的颜色变化。只要比所需的色阶多过一档，就得把整个热处理过程从头再来。

我们团队使用本地模型的体验，恰如在回火时错过了钢材的颜色变化。模型“温度”高得离谱，以至于越过目标后开始原地打转。对此几乎无计可施，除了关闭整个程序，然后寄希望于清空上下文后能得到不同的结果。

我绝不会让正在回火的刀刃处于无人看管状态，就像我绝不会让 Qwen 3.6 27B 独自处理一个长期任务一样。对于钢材来说，变通办法是使用窑炉，或带温控的烤箱，以消除波动。

我们锻造出来的那把 Sloyd 刀也可以拿来钉钉子，但你很可能会一边割伤自己的手，一边把刀刃也毁了。让我们回到起点：如果它是一种不同的工具，那它到底擅长什么？

我在寻找什么

我所寻找的，是我们在上一节讨论过的所有东西：隐私、固定成本，以及对供应商风险的防范。真正让我失望、而且至今仍让我失望的是，当我把 opencode 里的本地模型，和对待 Claude 或 Codex 一样来使用时。它们在几乎完全无人看管的情况下，竟然能长时间持续工作，同时朝着目标取得实质性进展，这几乎让人感到诡异。

我可以直接贴上这样一句话：“Eoin 告诉我，他一直在循环运行 Slicer 虚拟机，结果文件描述符耗尽了。他怀疑是 VSock 的问题。” 几分钟后，Claude 就会回复：“现在我看清全貌了：你们在做 X，你们需要做 Y。” 我会说：“去做吧，并在我的迷你 PC 上做端到端测试。” 再过上一段时间——5 分钟或 15 分钟——我就可以发起一个 PR，让它自动完成代码审查，然后再让 Claude 读一遍，继续迭代。

对于我们这样一个管理多款产品、并与企业客户和社区用户保持紧密协作的小团队来说，这是一个效率极高的闭环。

一张3090带来的深刻教训

我在 2023 年开始时只有一张 3090 显卡，很快就意识到，要想加载模型并拥有足够的上下文窗口，还需要再加一张。至于 2023 年的本地模型，这里没什么值得展开讲的，唯一可以说的是，它们太难用了，以至于我最终放弃了。直到 Qwen 3.5，我才第一次真正看到代理开始干活。

我可以把模型以 Q4 量化方式加载到任意一张显卡上，并配上 20 万上下文（同样经过量化），在加以引导的情况下完成一些小任务。我至今还记得情况是如何迅速失控的。我告诉模型：“从各个角度探索这台机器，完成一份关于这台机器及其使用方式的取证报告”——Claude 对这种任务大概会轻松应对。Qwen 却开始逐个读取我机器上的每一个文件，填满了自己的上下文，随后开始幻觉式地编造文件名，甚至连工具调用都出错，~/faas-netes 变成了 ~/faaned。退一步看，当我把任务范围收窄为“快速看一下这台机器周边情况，告诉我是谁在使用它、用途是什么”时，我就能得到一份思路非常清晰的报告，而且生成速度大约能达到每秒 40 到 50 个 token。

27B 模型根本无法以完整精度装进单张 3090 显卡，因此可调的“旋钮”包括：模型权重的压缩级别（量化）、上下文长度，以及上下文中键和值的压缩级别。

有一条广为人知的经验法则是：一旦 KV 缓存中的 keys 部分降到 Q4_0，就开始出问题了。我做过最激进的设置，也只是把 keys 设为 Q8_0，把 values 设为 Q4_0。

那些 3090 一直是头疼的来源——我不得不把量化压到远低于我能接受的程度。其中一张卡甚至只有在开机时“祈祷一下”才会被识别。连重启都治不好——我每次都得切断交流电源、拔掉电源线，再等 30 秒。

我最新的实验是搭建 vLLM（生产部署和并发服务的黄金标准），即便加上了 NVLink（175 英镑）并开启张量并行，在同等配置下，它在生成阶段仍比 llama.cpp 慢 3 个 token/秒。

我花在让它们跑起来上的时间，比花在结果本身上的时间还多。

挥金如土

我们向使用我们产品的企业客户提供支持合同，一旦工单进来，我们就有动力在合理范围内尽快解决。我原以为，买一块能让这些小毛病统统消失的显卡，就能解决本地模型的问题，而顾客支持值得冒这个险。

我们花了大约 1.2 万美元购入一块配备 96GB 显存的 RTX 6000 Pro Blackwell 版。即便只是过了几个月，价格也已涨至约 1.54 万美元，因此再添置第二块就更难证明其合理性了。你不能在消费级机器里随便“再插一张卡”了事。从 PCI 通道、带宽，到显卡间距以及电源负载，都有许多问题需要考虑。

这是一次经过审慎计算的押注，而且事实证明它奏效了，但并不是因为它取代了我们的 Claude 订阅——它做不到这一点。

无痛顾客支持，无需泄露顾客数据

许多企业公司的运维人员能力很强、技术娴熟，但他们往往受制于手动流程和操作习惯。有时候运气好，对方会把故障排查指南中的每一步都走一遍，并告诉你他们哪里做错了。另一些时候，你们已经在一串电子邮件往来中回复了 150 封，对方却仍然没有运行那一条本可说明一切的命令。

因此，我们编写了“diag”这一款易于运维人员运行的 CLI 工具，用于捕获 Kubernetes 上 OpenFaaS 安装环境的完整快照。随后，他们可以通过电子邮件将这份转储发送给我们，我们再在由 Slicer 创建的临时虚拟机中，通过一套隔离网络的本地模型对其进行分析。关于我们发现的问题，你可以在 OpenFaaS 博客上的 《介绍：无痛支持与免介入架构审查》 中了解更多。

营收挽回

最近有一笔续约到期，而正是因为我把遥测数据库输入本地模型，我们才发现，他们在过去12个多月里一直少报许可证数量、少付款约4到5倍。仅这一项收入追回，就已经收回了这张显卡的成本。

无论他们对数据保留持何种立场，我都不可能凭良心把遥测转储或顾客的诊断输出放到任何云端方案里处理。这里也正好谈谈近东和远东的编码方案——买者自慎——到目前为止，我还没发现哪一家不会对你的知识产权占据优先地位——无论是对输入和输出的训练使用权，还是所有权。ChatGPT Pro 和 Claude Max 可以配置为 30 天保留期，但即便是这种程度，也很可能会使你与顾客签订的合同失效。

有时我会把遥测数据表的模式提供给 GPT 或 Opus，让它写一份本地模型最有可能遵循的 AGENTS.md。我们的数据每天会从多个高可用副本上报数次，因此不能简单地按 24 小时周期汇总。模型早期版本在算术方面会出错——27.3K 会被算成 273,000。也正因为我当时在彻底核查它的工作，才发现了这个问题。

还有一次，模型推断某位顾客很可能会流失，因为他们使用的功能数量较少。它完全忽略了这样一个事实：这位顾客每天会多次运行这较少数量的功能。所以，很多时候最好让它们专注于分析，而不是解释。

我们当前的配置

我非常支持像 Jack Rong 和 Kyle Hessling 这样的人，他们一直在为 Qwen 这类开放权重模型开发微调版本。Qwopus 试图在 Qwen 之上叠加思维链轨迹，以提升其推理和编程能力。他们这样做是为了帮助社区，也是出于对本地 AI 的坚定信念。

在我们团队中，我们在 RTX 6000 这套设备上同时运行最新一代的 Qwopus，以及基础版 27B Qwen 3.6 模型。随着时间推移，这会不断变化——新的微调版本会推出，Qwen 的新补丁版本会发布，我们也会不断遇到新的边缘案例和局限。直到不久前，我们一直完全关闭了 thinking，而最近才重新启用它，这也恰好与我们观察到更多循环输出的情况同时出现。

这些模型由两个相互独立的 llama.cpp 实例提供服务，这意味着它们能够保留完整的上下文长度。对“并发”的默认做法是运行 --parallel 2，但这会将可用上下文减半。

$ nvidia-smi
Wed Jun 17 11:56:03 2026       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 590.48.01              Driver Version: 590.48.01      CUDA Version: 13.1     |
+-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA RTX PRO 6000 Blac...    Off |   00000000:01:00.0 Off |                  Off |
| 30%   32C    P8             15W /  600W |   85937MiB /  97887MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A            2265      C   ...ma.cpp/build/bin/llama-server      31198MiB |
|    0   N/A  N/A            2544      C   ...ma.cpp/build/bin/llama-server      54718MiB |
+-----------------------------------------------------------------------------------------+

llama.cpp 通过源代码构建，并每周更新一次，或根据需要更新。之所以必须从源代码构建，是为了加入对 NVIDIA GPU 的支持。

这是我们为单个 Qwen 实例配置的命令，可提供完整上下文长度和最高质量的上下文。

#!/bin/bash
~/llama.cpp/build/bin/llama-server \
 -hf unsloth/Qwen3.6-27B-MTP-GGUF:UD-Q8_K_XL \
 --alias Qwen3.6-27B-Base \
 --host 0.0.0.0 \
 --port 8085 \
 -ngl 99 \
 -c 262144 \
 --cache-type-k f16 \
 --cache-type-v f16 \
 --flash-attn on \
 --parallel 1 \
 --threads 16 \
 -b 4096 \
 -ub 2048 \
 --jinja \
 --reasoning-budget 2048 \
 --temperature 0.6 \
 --top-p 0.95 \
 --top-k 20 \
 --min-p 0.0 \
 --presence-penalty 1.1 \
 --reasoning on \
 --spec-type draft-mtp \
 --spec-draft-n-max 6 \
 --chat-template-kwargs '{"preserve_thinking": true}' \
 --chat-template-file chat_template.jinja \
 --reasoning-budget-message "reasoning budget consumed, time to answer now"

我们通过 MTP 实现的推测解码接受率约为 93%，速度也从稳定的 67 tok/s 提升至长期持续的 130 至 200 tok/s。体感上，这比使用云端模型还要更快。

在调校 llama.cpp 时，遵循模型卡中的说明很重要。实验室之所以选择某个特定温度，往往是有原因的。比如，在 Qwopus 这个微调模型上，关闭思考模式并把温度调得很高，设在 0.85 到 1.0 之间，效果最好。

说到这种循环

最近我一直在调校它，试图避免它陷入循环，这又回到了那个“火候”类比。你不能把这个模型单独扔在那里去处理长周期任务。

我问 Qwen，我们应该给 faas-cli 添加哪些命令，它给出了一些还算合理的建议，但随后卡住了，开始一遍又一遍地重复这些建议，白白烧掉了我足足半个小时、600 瓦的电力。

58. faas-cli function import - Import functions from a YAML file or URL.
59. faas-cli function export - Export deployed functions back to a stack.yaml file.
60. faas-cli function scale - Manually scale function replicas without redeploying.
61. faas-cli function rename - Rename a function in-place.
62. faas-cli function diff - Compare local stack.yaml with what's deployed - show differences.

63. faas-cli function import - Import functions from a YAML file or URL.
64. faas-cli function export - Export deployed functions back to a stack.yaml file.
65. faas-cli function scale - Manually scale function replicas without redeploying.
66. faas-cli function rename - Rename a function in-place.
67. faas-cli function diff - Compare local stack.yaml with what's deployed - show differences.

68. faas-cli function import - Import functions from a YAML file or URL.
69. faas-cli function export - Export deployed functions back to a stack.yaml file.
70. faas-cli function scale - Manually scale function replicas without redeploying.
71. faas-cli function rename - Rename a function in-place.
72. faas-cli function diff - Compare local stack.yaml with what's deployed - show differences.

Build · Qwen3.6-27B-Base toilgate

当我要求它“为所有 get 和 list 命令添加 –json”时，也发生了同样的情况——前一两个看起来很有说服力，甚至还写了测试。

随后，由于 --json 是机器可读的，faas-cli 在使用 http:// 远程端点时，必须停止输出有关不安全 TLS 的警告。Qwen 想不出该怎么处理，于是我让它用 Python 写一个反向代理，改为调用那个。第一版看起来像那么回事，但缩进有问题。等它意识到这个问题后，它把文件弄坏了，还不断抱怨自己不知道该怎么修复，并陷入了另一种循环。它就是不肯放弃，却越来越偏离正轨。

我团队里的 Han 报告过非常类似的循环问题——多数属于第二种。模型或代理会卡住，停留在自身能力边缘，却又不会主动寻求帮助。对我来说，我主要遇到的是前一种，这可以说更糟，也意味着除了用于顾客支持/续约中的遥测和诊断工作外，我很少会完全信任它。

衡量并分配访问权限

起初，我搭建了一条单独的 inlets 隧道，并希望各个代理不会相互冲突。两个代理在无关上下文下同时访问同一个 llama.cpp 实例，意味着每一个请求都会使对方缓存的前缀失效——因此每次都得从头重新处理完整提示词，这种来回抖动带来的延迟，并不是你愿意经常承受的。那时我们的工作仍主要集中在编码方案上，所以这还不算真正的问题。

分发这套配置其实很简单：编辑 opencode.json，加入 URL 和 token，然后把这个文件复制到你的各台机器或 Slicer 虚拟机上。

但只要有第二个人开始使用这个模型，它就不再是原型了。谁在用哪个 llama.cpp 实例？他们用了多少？用的是哪个模型？这在电力上花了我们多少成本？如果那个人离开团队会发生什么？我们又该如何给团队加入另一个模型？

Toilgate 完全是凭感觉写出来的，而且要把它开源出来工作量太大了。如果你喜欢这个思路，完全可以自己做一个。

我没有选择手动编辑我的 opencode.json 文件，再把它发给各位团队成员，而是决定为 opencode 写一个 provider。它负责管理可用模型，从稳定的基础版本，到更偏实验性的量化版 Qwopus 变体。你只需要运行 opencode，进入模型选择器，选中 toilgate，然后再挑你想用的模型即可。

我用两个 Shelly Plus Plug 监测墙上插座端的耗电情况，以便更准确地了解实际成本。RTX 6000 Pro 在推理时功耗可达 600 瓦，而且相对安静；两张 3090 的合计功耗则接近 750 瓦，噪音非常大。

错误的比较方式

一旦可以进行计量，最容易掉进去的陷阱，就是把每百万 token 的输入/输出成本拿去和 OpenAI 的 GPT-5.5 API 定价比较。以当前能力来看，这种比较方式并不对。更重要的是理解持续性的成本——而这些成本目前由我个人承担，因为机器就放在我家里——用于那些并不适合交给云端模型处理的工作。

这正是“本地 AI”演变成运维问题的地方。你需要身份认证、访问控制、计量、配额、模型路由以及功耗监控。我们反复遇到的更难问题，是代理与模型组合的可靠性、如何跟上 MTP 等创新，以及如何为那些已经开始依赖模型可用性的人确保足够的在线时间。

总结

尽管本地 Qwen 还达不到“接近 Opus 水平”，我想我在文中已经充分说明了这一点，但它在某些任务和工作流程中仍然有其价值。而且现在还处于非常早期的阶段，未来只会越来越好。Qwen 3.5 很可能是第一个能给我们带来可用结果的模型。有传言称 3.7 很快就会发布，我预计那将是一次渐进式改进，而非革命性的飞跃。

一些确有帮助的做法：

• 将本地模型及其工具链与专门任务相匹配——顾客支持、边界明确的维护工作，以及端到端测试
• AGENTS.md——当我向 alexellis/arkade 添加详细说明时，我发现本地模型添加新的 CLI 的速度和效率都超过了人工贡献者，而且还会对其工作进行测试
• 请注意模型卡上的调优说明——温度、上下文设置和量化都会产生影响。要警惕过低的量化水平。
• 本地模型即使不会编写代码，也能快速阅读并解释代码库——这是一种“超能力”
• 像 Qwopus 这样的微调模型已经出现——要勇于尝试，找到合适的模型
• 智能体技能帮助极大——我们曾让一个本地智能体在一台新的迷你 PC 上从零开始完成 Slicer 的安装配置 。它甚至还对 slicer CLI 的可用性提出了反馈，而我们已将这些反馈整合进去
• 要习惯用本地模型和云端模型执行同一任务 ——有时你会失望，另一些时候你会觉得自己走了大运
• 不要把需要长周期、无人监督的智能体工作交给它——这正是它会陷入循环的地方，连我们那张将近 1.5 万美元的显卡也无能为力

你会注意到，我没有提到 70B 模型——其中大多数如今确实已经老了，落后了好几代。Qwen 的 35-A3B 变体之所以常受欢迎，是因为它在 MacBook 上看起来更快——原因在于生成时只有 3B 个活跃参数，而我更愿意用速度来换取我能获得的最佳质量。还有更大的模型，如 GLM 5.2、Kimi 2.7、Minimax M3 和 Deepseek V4 Flash。它们可以在一些本地机器上运行，但通常即便只是加载模型的量化版本，也往往需要 4 到 6 张 RTX 6000 Pro 显卡，这使得它们对我们来说不在考虑范围内。

作为消费者，我不知道下一步升级会是什么——是转向企业级硬件，还是说 27B 稠密模型也有其一席之地；但就目前而言，它们并不适合整天用来写 Go。它们在知识储备和注意力上的局限，在代码审查中会立刻显现出来。虽然它们可以写出 Go 代码，甚至可能连并发都能跑通，但当我们发现 Qwen 不会遵循“简洁作答”的指令，反而会在自动化代码审查中展开大量无谓细节，还会凭空捏造并发问题和竞态条件时， 我们的实验很快就被叫停了 。相较之下，没那么吸睛的 Grok Coder Fast 1 更便宜、速度更快，而且在被弃用前的几个月里一直很好地满足了我们的需求。

你可以在这里了解我们的代码审查机器人 ，也可以在这里了解 OpenFaaS 的无痛客户支持和架构评审 。