Qwen 3.6 27B 在 SWE-Bench Verified 上是 77.2，Claude Opus 4.8 是 88.6。

这个差距看起来不大，很容易被说成“本地模型快追上 Opus 了”。OpenFaaS 创始人 Alex Ellis 不太买账。他的说法更冷：本地 Qwen 不是差一点的 Opus，而是不同工具。

这个判断不是来自一次演示。Ellis 的小团队维护 OpenFaaS、SlicerVM、Actuated、Inlets 等基础设施产品，主要代码是 Go，还涉及 Kubernetes、Firecracker microVM、容器和网络协议。

所以问题不是“榜单差几分”。问题是：本地大模型能不能进入真实软件业务，替代 Claude、Codex 这类前沿闭源模型。

他的答案是：能进场，但不能接管。

跑分接近，不等于能接复杂工程活

争议从那个分数开始。

Qwen 3.6 27B 的 SWE-Bench Verified 分数是 77.2，Claude Opus 4.8 是 88.6。把它粗暴换算成“只差 12 个点”，听起来很诱人，也很危险。

SWE-Bench Verified 主要来自开源项目里的 Python 问题。Python 当然不简单，也有线程、异步和复杂依赖。但很多测试任务仍更像局部修复：读 issue、改代码、跑测试。

Ellis 面对的是另一类工作。

Go 分布式系统里，channel、context、结构体、网络状态、进程边界经常缠在一起。模型能在榜单上修 bug，不等于能稳定理解一个基础设施产品的执行路径。

对比项本地 Qwen 27B/35-A3BClaude Opus / Codex更现实的判断
基准测试SWE-Bench Verified 表现亮眼Opus 4.8 分数更高分数不能直接折成工程能力
典型任务日志解释、小范围修改、受控分析长周期编码、测试、迭代 PR任务半径不同
风险点长上下文、量化、工具调用更容易出错更适合无人值守跑一段流程稳定性差距比跑分更关键
决策含义可纳入内部辅助流程关键路径仍更可靠不是平替关系

我更在意的是这个差别：跑分衡量的是“能不能做成一类题”，生产环境考的是“能不能少添乱”。

对重度使用 AI 编程工具的小团队，动作应该很具体：不要因为一个榜单分数就迁移主力编码流程。可以拿本地 Qwen 做日志摘要、配置解释、简单补丁，但长 PR、跨模块重构、自动跑测试和提交，仍要留给 Claude、Codex 或人工复核。

本地模型买的是控制权，不是取消订阅

Ellis 不是只在笔记本上试了试。他先用 RTX 3090 做实验，后来转向一张约 12000 美元的 RTX 6000 Pro Blackwell，96GB VRAM。

这已经不是“装个本地模型玩玩”的投入。

但他没有把这笔钱解释成“从此不用 Claude”。相反，他明确说这张卡回本了，但不能替代 Claude 订阅。

这里的账，要分开算。

一张专业显卡带来的主要收益，不是每个 token 都比云端便宜。更重要的是三件事：固定成本、客户数据不外泄、降低对 Anthropic、OpenAI 等供应商的依赖。

对 OpenFaaS、Actuated 这类基础设施产品，这些收益很真实。它们面对企业支持、日志、配置、故障线索，也服务一批关心自托管和控制权的客户。

但这套账不自动适用于所有人。

如果一个个人开发者主要写网页组件、脚本、内部小工具，每月 AI 费用不高，直接买 12000 美元级别显卡未必划算。原文也没有给出完整吞吐、并发服务成本和运维折旧数据，不能把“对 Ellis 回本”推成“对所有团队都回本”。

更稳妥的动作是先做三件事：

  • 统计每月真实 AI 使用成本，而不是凭感觉说贵。
  • 把涉及客户数据的任务单独挑出来，看哪些适合本地跑。
  • 用一小段内部流程试点，不要一上来替换主力模型。

对企业技术负责人，本地 Qwen 更适合先进入内网支持、代码检索、日志分析和知识库问答。采购可以推进，但承诺要保守：它降低外部依赖，不等于消灭外部依赖。

使用边界：能当副驾驶，别急着无人驾驶

Ellis 对 Qwen 的主要不满不是“笨”，而是不稳定。

量化之后塞进消费级显卡，再叠加长上下文，问题会放大。循环、幻觉、工具调用错误，都会更容易出现。

他提到一个例子：让 Qwen 检查一台机器并生成取证报告。模型开始逐个读取文件，填满上下文，后来编造文件名，甚至把工具路径也弄错。

这类错误对演示影响不大，对生产流程很致命。

同样任务交给 Claude，Ellis 的描述是更能放心让它理解问题、修改代码、跑端到端测试，再生成 PR。对小团队来说，无人值守 5 到 15 分钟还能往前推进，这个能力很值钱。

Qwen 目前更适合被关在较小的笼子里：

  • 看一段日志，给出可能原因。
  • 解释一份配置，指出明显风险。
  • 草拟客户支持回复，再由人确认。
  • 做小范围代码修改，不让它跨太多文件。

不适合的场景也要说清楚：长上下文、多工具调用、自动修改代码、自动测试、自动提交 PR。这些任务一旦出错，排查成本可能吃掉本地推理省下的钱。

所以接下来最该看的不是榜单再涨几分，而是三个更硬的指标。

观察项为什么重要没看清前的动作
长上下文下工具调用是否稳定决定能不能做长周期代理任务不要放进无人值守流程
量化后推理质量是否保住决定消费级或本地硬件能否可靠使用只用于低风险任务
本地推理并发成本是否可控决定团队部署是不是划算先小规模试点，再谈采购

这才是 Ellis 那篇文章真正有价值的地方。

它不是给本地模型泼冷水，也不是给闭源模型站台。它提醒软件团队把两个问题分开：本地模型有没有价值，和它能不能替代 Opus，是两件事。

答案也分开。

本地 Qwen 有价值。尤其在隐私、主权、固定成本和供应商风险上。

但它目前更像一把放在工位旁边的工具刀。能省时间，也能处理脏活。真要让它独自开挖整条隧道，还不到时候。