SWE-bench：2026 年开源 LLM 编程能力排名

在本地评估 SWE-bench LLM，可以衡量开放权重模型解决真实 GitHub 缺陷的实际能力，所反映的内容远不止 HumanEval 得分。SWE-bench LLM 的独特之处在于，它要求模型浏览完整的代码仓库、理解 issue 工单、修改多个文件并通过整套测试。本文详细介绍该基准测试的机制、SWE-bench Verified 变体、硬件要求、模型目录中的候选模型以及本地执行流程，随后回答自托管实践者的常见问题。

理解 SWE-bench 的工作机制

SWE-bench 是 2023 年由普林斯顿大学发布的基准测试，收集了来自 12 个流行 Python 项目（如 Django、scikit-learn、sympy、matplotlib 等）的 2,294 个真实 GitHub 问题。每个任务为模型提供一个特定提交的仓库和一个问题描述。大语言模型需生成一个补丁（diff) 应用后可使此前失败的测试通过，且不破坏现有测试。关于数据集构建的详细信息，请参见原始SWE-bench论文以及官方GitHub仓库.

HumanEval 评估的是孤立的短函数，而 SWE-bench 衡量的是：

上下文理解 : 阅读包含数万行代码的仓库
Bug 定位 ：在没有明确指导的情况下，识别出需要修改的正确文件
多文件编辑 ：生成逻辑一致且不破坏现有功能的补丁
长链推理 : 在探索、假设、验证之间切换

SWE-bench 上 20% 的原始得分，往往对应 HumanEval 上超过 80% 的得分。这解释了为什么许多模型在 HumanEval 上表现出色，却在 SWE-bench 上表现大幅下滑。

SWE-bench Verified：经过筛选的版本

SWE-bench Verified 是由 OpenAI 与普林斯顿大学作者合作手动标注的 500 个实例的子集。目标是剔除题干模糊、隐藏测试过于具体，或参考补丁依赖未提供上下文的任务。有关详情，请参见 OpenAI 关于 Verified 的博客文章.

本地测试时, SWE-bench Verified是合适的选择 :

500个实例而非2294个：可在一台工作站上几天内完成执行
更可靠地评估模型的真实推理能力
与厂商公布的评分进行直接对比

使用最广泛的基准智能体是 SWE-agent，一个为 LLM 提供交互式终端的运行框架，使其能够编辑文件、执行命令和运行测试。一种常见的替代方案是 OpenHands, 原生支持 OpenAI 兼容后端（vLLM, llama.cpp server, SGLang）。

目录中适配基准测试的模型

用于编程智能体的LLM必须兼顾较大的上下文窗口（运行框架会注入堆栈跟踪、源代码和操作历史）与良好的推理性能。以下是模型目录中的候选模型，按硬件配置分类。

显存容量非常大的工作站（≥ 400 GB）

DeepSeek V3.2 （685B，MIT）— Q4 量化所需显存约 410 GB，上下文长度 128k。根据独立评估，它是目前 SWE-bench Verified 上的开放权重标杆模型。
DeepSeek R1 671B (671B, MIT) — VRAM Q4 ~400 GB，上下文长度 128k。长链推理模型，特别适用于Bug定位。
Mistral Large 3 675B (675B, Apache 2.0) — VRAM Q4 ~405 GB，上下文长度 256k。许可宽松，适合商业使用。
Kimi K2.6 （1000B，Modified MIT）—— Q4 量化下所需显存约为 600 GB，上下文长度为 256k。据 Moonshot 称，已针对智能体工作流进行优化。

多 GPU 集群（140-250GB）

Qwen 3 235B-A22B （235B，Apache 2.0）— Q4 显存约 142 GB，上下文 131k。MoE 激活参数为 220 亿，成本与质量之比较好。
Llama 4 Maverick 400B （400B，Llama 4 Community）——Q4 显存需求约为 240 GB，上下文长度为 1M。超长上下文，非常适合大型代码仓库。
GLM-5.1 (744B，MIT) — 显存Q4约445GB，上下文长度200k。

单台工作站（≤ 80 GB）

Qwen3-Coder-Next 80B-A3B (80B, Apache 2.0) — VRAM Q4 约 48 GB，上下文长度 262k。专用于代码，可在 A100 80GB 或两块 3090 上运行。
gpt-oss 120B (117B, Apache 2.0) — VRAM Q4 ~70 GB，上下文长度 128k。OpenAI 发布的开源权重模型。
Mistral Small 4 (119B, Apache 2.0) — VRAM Q4 ~72 GB，上下文长度 256k

关于代码层面的详细对比，请参见 Qwen3-Coder vs DeepSeek V3.2 和该页面最适合编程的 LLM.

每秒 token 数及对运行时长的影响

完整运行 SWE-bench Verified 的消耗量在 5 亿至 20 亿 tokens 之间，具体取决于运行框架和允许的尝试次数。因此，tokens/秒的吞吐量直接决定了基准测试的时长。

估算值（需根据您的设备配置确认） :

DeepSeek V3.2 采用 Q4 量化，在 8 张 H100 80GB 上运行：生成速度约为 25 tokens/秒，Verified 测试运行预计耗时 5 至 8 天
Qwen 3 235B-A22B 在 4×H100 上：Q4 下约 40 tokens/秒（MoE 仅激活 22B 参数有助于提升速度），预计运行需 3 至 5 天
Qwen3-Coder-Next 80B-A3B 在2×A100 80GB上：Q4模式下约60 tokens/秒，运行时长约2至3天
gpt-oss 120B 在 1×H200 141GB、Q4 模式下：约 35 tokens/秒，运行预估需 3 到 4 天

有效上下文长度与原始速度同样重要：SWE-agent 会定期向提示中注入 30k 至 60k 个 token，以重建代码仓库的状态。上下文长度仅为 32k 的模型不太适合；应以至少 128k 为目标。另请参阅按量化方式划分的 VRAM 使用指南以调整您的内存预算

本地运行流程

以下是严格自托管配置的简化流程。

准备Docker环境 ：SWE-bench Verified 需要每个项目（Django、sympy 等）的 Docker 镜像以隔离测试执行。请为维护者发布的官方镜像预留 80 GB 磁盘空间。
启动兼容 OpenAI 的推理服务器 ：使用 vLLM 或使用 llama.cpp 的服务器模式，在以下地址提供模型服务： localhost:8000/v1。对于在 2×A100 上运行的 Qwen3-Coder-Next Q4 量化模型，典型的 vLLM 命令会设置 --tensor-parallel-size 2 --max-model-len 131072 --quantization awq.
克隆SWE-agent 并配置测试框架，使其指向本地端点。配置文件支持 api_base: http://localhost:8000/v1 et model_name: <votre-modèle>.
执行一次校准测试 在 10–20 个实例上，以检查动作格式是否符合要求。许多开放权重模型在这一步失败，因为它们会编造测试框架无法识别的 XML 标签。
完整运行 : 500 实例，数天运行，系统性记录生成的补丁以供事后分析。
可选提交 au 官方排行榜用于公开对比。

实用技巧：限制每个实例的操作数量（50-75）以避免模型陷入无限循环并消耗您的 token 预算。

结果解读

SWE-bench Verified 的原始分数应从相对角度解读，而不能作绝对判断。

< 10 % ：模型未能掌握智能体的动作格式，或其上下文长度过短
10-25 % ：对于通用开放权重模型而言，属于不错的水平
25-50 % : 专用推理模型的预期水平(DeepSeek R1 671B, Kimi K2.6)
> 50 % ：前沿水平，最优秀的专有模型已达到这一水平

除了评分，还需关注 失败情况分布 ：测试超时、补丁无法应用、修改了范围之外的文件。这种分析往往表明，限制模型的并非其推理能力，而是运行框架（窗口大小、动作解析）。要进一步了解如何选择用于智能体的模型，请参阅面向 AI 智能体的 LLM 指南.

FAQ

Q：首次测试使用SWE-bench还是SWE-bench Verified？

选 Verified，毫不犹豫。500 个实例均经过人工标注，有歧义的实例已被剔除，在单台工作站上的运行时间也保持在合理范围内。完整的 SWE-bench（2,294 个实例）包含描述不充分的任务，会使模型受到不公平的扣分。Verified 还支持与专有模型供应商公布的分数进行直接比较。

Q：为了保持编程基准测试得分，应选择哪种量化方式？

Q4_K_M (GGUF) 或 AWQ 4 位量化通常会使 SWE-bench 得分降低 1 到 3 分，相比 FP16 仍可接受。在推理模型上避免使用 Q3 和 Q2，因为性能损失会变得显著。如果 VRAM 允许，Q5_K_M 或 Q8 量化能提供更好的性能表现。参见 GGUF 与 AWQ 量化方式的对比.

Q：应该选择专门的“编程”模型，还是通用模型？

这两类模型都适用。专门用于编程的模型，例如 Qwen3-Coder-Next 80B-A3B 在补丁生成方面表现优异，但通用推理模型如 DeepSeek R1 671B 在缺陷定位和多步骤规划方面通常表现更出色，而这两项工作占据了 SWE-bench 任务成本的大部分。

Q：能否在单块RTX 4090上运行SWE-bench Verified？

很难。24 GB 显存将可运行的模型限制在 Q4 量化、规模 ≤ 30B 的范围内，而这些模型由于推理能力不足，在 Verified 上的得分通常达不到 10%。您可以用它来验证自己的处理流程，例如使用 Qwen3-Coder-Next 这样的轻量模型，并将部分计算卸载到 CPU；但若要获得可用的结果，建议以 2×3090 或 1×A100 80GB 为目标配置。

Q：一次完整运行消耗多少token？

根据测试框架（SWE-agent, OpenHands, 自定义）和每个实例允许的最大操作次数，估计在 5 亿到 20 亿个 token 之间。如果每个实例预算为 50 次操作，平均上下文为 30k token，那么 500 个实例大约需要 10 亿个 token。模型以链式方式“思考”得越多（R1 风格），token 账单就越高。

Q：本地运行的结果是否与排行榜分数相当？

是的，前提是使用官方评测框架、相同的数据集版本，并遵守提交规程（每个实例仅提交一个补丁，不借助标准答案或评测反馈进行重试）。对评测框架或系统提示的任何修改都必须记录。 SWE-bench 排行榜支持自托管提交并验证可复现性

结论

在本地对LLM运行SWE-bench，仍是区分开放权重编程模型与仅在HumanEval上表现出色的模型最有说服力的测试。借助SWE-bench Verified、一台配备2×A100或4×H100的工作站以及合适的模型（Qwen3-Coder-Next, DeepSeek V3.2 或 gpt-oss 120B），一次贴近实际场景的测试运行可在几天内完成。在启动基准测试前，请使用以下工具校准您的配置： quelllm.fr 配置工具或浏览完整目录.