我的 AI 代理为我的 AI 代理们打造了一个基准测试工具

简单来说： 我的 AI 编程代理编写了 bench-llm，这是一个单独的 Python 文件，用于测试本地模型的速度以及它能否完成简单任务。它至今仍可使用，且可免费下载。但它在两周内就变得太简单了，所以我用 CrucibleForge 取而代之——这是一款更大的免费工具，会提出 251 个问题，并运行模型生成的代码来验证。

想在自己的环境中实现这个？ 你不必手动照抄这篇文章——LLM 助手（Claude、ChatGPT 或本地模型）可以根据本文末尾的下载文件，帮你适配到自己的设备上。你只需要处理那些只有你能做的部分，然后把下面的提示词粘贴给助手，剩下的交给它。 LLM 助手是什么，第一次接触？看看这份搭建指南（Claude Code、Cowork、Reasonix、DeepSeek）。

你需要做的部分——只有你能完成

Python 3.8+ 及 pip（或 uv）
LM Studio 在本地运行，且至少有一个模型加载在 localhost:1234 上
两个 Python 包：pip install openai requests

交给助手做的部分

下载 bench-llm，安装其两个依赖项（openai、requests），并确认 --list 能显示你的模型
对每个模型运行一次 --quick 冒烟测试，然后对你想比较的两三个模型运行完整基准测试
读取 ~/benchmarks/ 中的 JSON 结果，并总结哪个模型在速度、能力和代理适应性方面胜出

复制下面的提示词开始：

先获取并阅读 https://www.laserlloyd.com/zh/projects/bench-llm-ai-agent-built-benchmarking-tool/——里面包含这个项目完整的步骤、设置和注意事项。 在我的机器上设置 bench-llm，并针对我在 LM Studio 中的模型运行它。安装它所需的两个 Python 包（openai、requests），列出我的模型，对每个模型运行 --quick，然后对最好的三个模型运行完整基准测试。读取 JSON 结果，告诉我哪个模型最快、哪个是最好的通用代理，以及哪个我不应该用于工具调用。向我展示最终的对比表格。

2026-08-11，我让我的编程代理做一个工具，用来对我的代理栈中的本地模型进行基准测试。它带回了 bench-llm：1,660 行 Python 代码，测量 LM Studio 中的速度，运行模型编写的代码，并检查模型能否处理一个小型代理任务。两周内，我关心的每个模型都在它上面得了 5/5 分，于是我将其重建为 CrucibleForge：251 个用例，其中 158 个为高难度，现已在 GitHub 上开源。本页涵盖两者。用 bench-llm 在五分钟内获得模型的第一个分数。当你需要对所有能通过简单测试的模型进行排名时，使用 CrucibleForge。

简而言之

bench-llm：一个 Python 文件，免费下载。它测试速度（首个 token 的时间、每秒 token 数）、能力（5 项测试：代码、逻辑、JSON、指令、摘要）和代理适应性（针对一个 syslog 任务的 3 项检查）。需要 Python 3.8+、pip install openai requests 和 LM Studio。
为何退役：一旦优秀模型全部通过，5 项能力测试和 3 项代理检查就无法再区分模型。
CrucibleForge：251 个用例，158 个高难度。代码在沙盒中运行，并按结果评分。它适用于任何 OpenAI 兼容端点，并附带 Web GUI。MIT 许可证，github.com/LaserLloyd/CrucibleForge。
高难度层级显示了什么：DeepSeek V4 Pro 通过了 93% 的客观高难度用例。在我自己的 GPU 上，最好的本地 27B 模型通过了 88%。

更新日志：2026-08-26，bench-llm 退役，结果移至后续套件。2026-09-16，CrucibleForge 部分重写，排行榜根据保存的运行文件重建，封面重绘。

最终会得到什么

对一个模型执行一条命令后，会输出如下内容（示例运行结果，已简化）：

$ bench-llm gemma-4-31b-it

  bench-llm — Benchmarking: gemma-4-31b-it
  GGUF Size:     16.5 GB     Quant: Q4_K_M

  ⚡ SPEED BENCHMARKS
    short_50    TPS: mean=84.2   TTFT: mean=0.231s
    medium_200  TPS: mean=85.7   TTFT: mean=0.312s
    long_800    TPS: mean=82.1   TTFT: mean=0.541s
  🔍 Validating speed plausibility...  Confidence: HIGH

  🧠 ABILITY TESTS
    Code Generation (median_of_list)... PASS
    Logic Puzzle (Pet Ownership)....... PASS
    JSON Compliance.................... PASS
    Instruction Following.............. PASS
    Summarization (Key Facts).......... FAIL
    Ability Score: 4/5

  🤖 AGENT FITNESS TESTS
    Task Acknowledgment / Format Adherence / Conciseness: PASS
    Agent Fitness Score: 3/3

  📄 Results saved: ~/benchmarks/gemma-4-31b-it-2026-08-11.json

该 JSON 文件包含了所有的原始计时数据、每个模型的响应以及汇总信息。你可以将其提供给你的智能体，并询问：“我的哪些模型适合处理大批量的 JSON 数据呢？”

Bench-LLM测试的内容

速度测试

测试时会发送三种长度的提示文本（约50、200和800个字符），先进行预热运行，随后测量三项指标。TTFT（首个字符生成时间）指从发送请求到文本开始显示所需的时间；若超过500毫秒，在聊天体验上就会显得迟缓。吞吐量（每秒生成的标记数）则表示模型开始工作后的输出速度。预填充速率则反映模型读取提示文本的速度。

此外，测试还会对照已知的硬件性能极限进行合理性校验。如果一个30GB大小的模型声称能在7900 XTX显卡上实现200 T/s的吞吐量，Bench-LLM会标记该数值为可疑——因为推测性解码或缓存预热很可能导致了数值虚高。

能力测试

代码生成：要求编写一个能处理各种边界情况的 median_of_list(numbers) 函数。Bench-LLM会实际执行该函数并验证其能否正确应对六个测试用例。
逻辑推理：一道涉及四个人各自养什么宠物的逻辑题。校验程序会从模型的回复中提取出所有四种分配结果。
JSON格式合规性：要求返回包含特定键名的对象。这是模型实现工具调用所需具备的最低条件。
指令遵循能力：要求列出1至10的数字，标记其中的偶数并求和。计算本身很简单，关键在于输出格式是否符合要求。
摘要生成：要求对一段内容密集的段落进行压缩，同时保留六个关键事实。大多数模型都会遗漏至少一个事实。

智能体适配性测试

测试给模型分配一个贴近实际场景的任务：在系统日志中搜索包含“ERROR”的行，按服务类别分组后以JSON格式返回结果。该回复会接受三项指标的检验：

任务理解程度：模型是否说明了自己的处理思路，以及哪些情况无法处理？如果模型凭空编造了系统日志内容，则判定为不合格。
格式规范性：输出中是否包含 services 数组、total_errors 整型数值以及 scan_period 字符串？
简洁性：输出长度与输入长度的比值。若模型对仅1300字符的输入给出了20000字符的回复，则会被标记为“过于冗长”——因为这样的智能体每次对话都会迅速占满上下文窗口。

实现方式

我给编程智能体的指令只有一句话：“我需要一个能在 LM Studio 中测试本地模型的工具，能测试其运行速度与性能表现，并输出 JSON 格式的结果及表格。”它在一个下午内分四步完成了该工具的开发：首先通过 LM Studio 提供的兼容 OpenAI 协议的流式 API 进行速度测试；接着是功能测试；随后实现智能体任务处理模块；最后进行优化（比如从磁盘中查找 GGUF 文件、执行合理性校验，以及实现 --quick、--list、--check 等参数）。所有代码均由智能体编写完成。我所做的只是在真实模型上运行该工具并给出反馈。之所以加入合理性校验机制，是因为我曾告诉智能体：某个吞吐量数值对于一个拥有1230亿参数的模型来说根本不可能实现。

以下设计思路值得你在自己的工具开发中借鉴：

采用流式处理而非轮询方式。 只有逐令牌计时才能准确获取 TTFT 值。
确保代码能实际运行。 看起来完美无缺但无法运行的代码其实属于失败品，不能算作合格。
先提取答案再进行校验。 校验程序会去除诸如“当然！这是您的答案：”之类的冗余前缀，这样测试才能仅针对内容本身进行评估。
每次运行前都清空 GPU 缓存。 否则先前模型留下的缓存会影响 TTFT 数值的准确性。关于 bench-llm 如何实现这一点，详见下文说明。

设置

# 1. Install both dependencies (requests reads LM Studio's model metadata;
#    without it every model shows as "not found")
pip install openai requests

# 2. Start LM Studio with at least one model; it listens on localhost:1234

# 3. Run it
./bench-llm --list                         # what's available
./bench-llm gemma-4-31b-it --quick         # smoke test
./bench-llm gemma-4-31b-it                 # full benchmark

这里没有配置文件，也没有数据库。LM Studio允许使用任意字符串作为 API 密钥。运行结果会保存在 ~/benchmarks/ 目录下。如果您希望随时从任何位置运行该脚本，可将其复制到 PATH 路径下的某个文件夹中。

注意事项

它会终止 llama-server 进程。 每次运行时，它都会执行 pkill -f llama-server 并等待 LM Studio 报告已加载的模型数量为零。此时机器上的所有 llama-server 进程都会被终止。切勿在运行着其他服务的机器上使用此工具，否则请删除该步骤。
编码测试通过 exec() 来执行模型输出。 该过程会使用全新的命名空间，但这并非真正的沙盒环境。建议以权限受限的用户身份运行它；或者直接使用 --speed-only 参数跳过各项能力测试。
推理类模型的响应速度看似较慢。 TTFT 统计的是包括思考内容在内的第一个标记的生成时间。在生成的 JSON 数据中，该时间被拆分为 ttft_reasoning_s 和 ttft_content_s 两个字段。
仅总结任务未通过却能得到 4/5 的评分，这已算不错的成绩了。 实际上几乎所有模型都会遗漏至少一个信息点。
对单个模型执行完整测试需要 2 至 5 分钟。 可使用 --quick 参数快速对比多个模型，之后再对表现较好的模型进行完整测试。
LM Studio 必须处于运行状态。 bench-llm 会连接至 localhost:1234，但不会自行启动 LM Studio。

结果：在我的高性能主机与迷你电脑上运行的基础模型表现

这些数据来自 bench-llm 之后的测试套件（测试方法相同，测试项目更多；报告日期为 2026年8月18日）。“主机”指的是配备了两块 RTX 5090 和两块 RTX 3090 的无头式 GPU 服务器。“迷你电脑”则指搭载集成显卡的设备（当时该设备仍能运行本地模型服务器）。请仅在同一设备上比较性能。代码、工具调用、指令遵循及推理能力均为对应的成功率。

模型	设备	生成速度（token/秒）	首次生成延迟	代码能力	工具调用能力	指令遵循能力	推理能力
Gemma 4 26B-A4B（QAT，Q4量化）	主机	229.0	110毫秒	88%	100%	50%	95%
Nemotron 3 Nano 4B（Q8量化）	迷你电脑	18.5	175毫秒	92%	70%	94%	95%
Gemma 4 12B	迷你电脑	10.1	633毫秒	—	—	—	—

Gemma 4 26B 混合专家模型（实际激活参数为4B）是主机上的主力模型：生成速度高达229 token/秒，首次生成延迟仅110毫秒，且工具调用能力堪称完美。不过其在指令遵循方面表现一般，而这正是无监督智能体循环所最依赖的能力。相比之下，迷你电脑上的4B版 Nemotron 在指令遵循方面表现更佳（94%对比50%）。不过它的生成速度要慢得多（18.5 vs 229 token/秒），且运行在不同设备上。因此请依据您的工作负载需求来选择模型，而非单纯以生成速度作为判断标准。

它的替代品：CrucibleForge

Bench-LLM因“过于成功”而“寿终正寝”。五个能力测试虽然能打造出不错的烟雾报警器，但在模型排名方面却毫无用处：一旦所有模型都获得了5/5和3/3的评分，这个工具就无话可说了。CrucibleForge便是对其的重写版本。它由约9,400行Python代码构成，其设计原则就是即便是最难的问题，评分也应当轻而易举。

158个难题。 这些题目包括需要得出整数答案的数学竞赛题、具有唯一解的逻辑网格题，以及那些对算法复杂度有严格要求的编程题（例如，时间复杂度为 O(n²) 的逆序对计数算法就会超时）。此外还有利用虚假工具或提示注入手段设置的陷阱题；需要处理 12,000 至 24,000 个 token 的长文本检索任务；以及需要同时满足多个约束条件的指令题。

代码是通过运行方式来评分的：代码会在一个没有网络连接、系统为只读状态且运行时间限制为15秒的 bwrap 沙盒环境中执行。只有当程序在标准输出中输出指定的标记字符串时才算通过；因此程序无法通过返回零值来伪造成功结果。若没有 bwrap（在 macOS 和 Windows 上总是如此），除非指定 --allow-unsandboxed 参数，否则程序会拒绝运行模型代码。

文字形式的回答会被评为“最佳答案”。 评判模型会先查看正确答案，然后判断回复的意思是否与之相同。任何合格的指令型模型都能做到这一点，因此评判环节也不再是薄弱环节了。

任何与 OpenAI 兼容的端点。 包括 LM Studio、Ollama、llama.cpp、vLLM、DeepSeek、OpenRouter 等。托管模型可同时处理多个任务，并报告生成的令牌数量及相应成本。API 密钥仅能通过环境变量获取。

它能找回那些推理模型遗漏的答案。 一个耗尽了所有计算资源进行思考的推理模型最终只返回了空答案。系统会察觉到这一点，于是关闭思考功能后再次提问，并统计这种情况发生的频率。recover 功能则会重新运行之前运行中出现此类情况的那些数据行。

它能“礼貌地”共享GPU资源。 在我的 StudioForge 服务器上，每个运行任务都会先占用所需的显卡资源，任务结束后再把资源归还给其他程序。而 bench-llm 则是通过 pkill 命令来终止所有模型进程，从而解决了同样的问题。

一个网页界面运行在 127.0.0.1:8777 上，您可以通过它选择模型与类别、查看日志，还能打开任何处理失败的记录：包括提示内容、回复、推理过程以及评判员的备注。只有在提供了令牌之后，该界面才能监听除本地回环地址以外的任何请求。

试试看

git clone https://github.com/LaserLloyd/CrucibleForge.git crucibleforge
cd crucibleforge
uv sync
uv run crucibleforge config --init      # writes models.yaml; add your provider and model
uv run crucibleforge status             # is the provider up? how many cases?
uv run crucibleforge all --profile standard --models my-model --yes
uv run crucibleforge gui                # http://127.0.0.1:8777

standard配置是一种固定的56个案例的组合，在27B规模的模型上运行时，包括评判环节在内，整个过程耗时不到一小时，生成速度约为70令牌/秒。这样的运行次数完全在可承受范围内。该配置还被分为两部分：coding环节无需进行评判，而chat环节则包含需要评判的部分。其他命令包括 run、judge、recover、report、pairwise、models、import-openclaw 以及 cases。

我最信任的命令就是那个用于检查题目本身的命令。它会在沙盒环境中运行每一个参考解决方案，通过穷举法重新计算出每一个数学答案，并重新构建出包含大量上下文信息的文本结构。以下是该命令在2026年9月16日的输出结果：

$ uv run crucibleforge cases verify
251 cases checked, 0 with problems (36 reference solutions executed, 35 answers re-derived)

该测试套件包含335个测试用例，它们执行相同的检查。因此，如果有某个问题存在缺陷，它不可能让所有模型都默默失败，却又能让处于较高级别的模型顺利完成任务。

报告的样子

report 会生成一个 Markdown 文件和一个 JSON 文件。每个模型都会有一行汇总信息，以及一行按类别划分的详细数据。以下是 DeepSeek V4 Pro 按类别划分的数据行：

| Model        | Coding      | Math        | Tool use    | Instruction  | Reasoning    | Long-context |
| deepseek-pro | 89% (54/61) | 95% (21/22) | 94% (31/33) | 100% (31/31) | 100% (37/37) | 97% (29/30)  |

每次失败及其原因都被一一列出。所有七次编码失误的表现都与下面的第一行类似。第二行则是两次工具使用失误中的一次：

- deepseek-pro [coding] CZ01-prime-census: TRUNCATED at 32768 tokens (32768 reasoning tokens); no code in response
- deepseek-pro [tooluse] TZ06-three-parallel-one-turn: 1 calls, expected 3

这才是有价值的部分。该模型并没有写出糟糕的代码；它一直思考，直到32,768个令牌的预算用尽，最终也什么代码都没写出来。如果增加预算或降低推理所需的努力程度，这个评分也会随之变化。单凭通过率本身是无法反映出这一点的。

高难度测试用例结果

这些是完整套件的测试结果：涵盖了全部251个测试用例，或者说几乎全部。所谓“高难度通过率”指的是模型在154个高难度测试用例中的通过比例（实际测试了158个，另有4个未计入统计）。代码、数学与工具类通过率则分别指模型在该类别下所有测试用例的通过比例。我排除了那些仅测试了56个用例的结果——它们只覆盖了38个高难度用例，不具备可比性。此外，我也省略了完整报告中关于角色扮演及成人内容的相关评分，因为这些对评估智能体能力并无帮助。

模型	运行环境	高难度通过率	代码	数学	工具类	生成速度（词/秒）	单次运行成本（$）
DeepSeek V4 Pro	API	93% (143/154)	89%	95%	94%	61.6	1.10
DeepSeek V4 Flash ¹	API	90% (138/154)	87%	91%	91%	82.2	0.331
Qwen3.8 27B (Q5_K_S) ¹	本地服务器	88% (135/154)	85%	91%	88%	143.5	—
dark-scarlett-27b-v2	本地服务器	88% (135/154)	80%	86%	91%	65.7	—
dark-scarlett-31b	本地服务器	86% (133/154)	90%	86%	91%	43.1	—
MiniMax M3 ²	API	85% (130/153)	82%	77%	85%	212.1	1.07
qwen3.8-27b-abliterated	本地服务器	79% (122/154)	62%	77%	91%	97.0	—
joyfox-35b-rp	本地服务器	75% (116/154)	72%	77%	76%	319.1	—
gemma-e4b-uncensored ³	本地服务器	69% (97/140)	61%	64%	88%	221.6	—
muse-glimmer-30b	本地服务器	57% (88/154)	57%	64%	76%	71.9	—
Qwen2.5 1.5B ¹	本地服务器	29% (45/154)	28%	5%	58%	624.1	—
Qwen2.5-VL 7B	迷你PC	18% (28/154)	15%	0%	12%	18.8	—
SmolVLM 256M ³	本地服务器	3% (4/140)	0%	0%	6%	959.2	—

表中以小写字母命名的模型均为社区用户自行微调或修改的版本，其名称取自相关注册表。未标注特殊标记的条目均为2026年9月16日根据原始测试文件重新生成的。由于不同版本的测试用例集存在差异，因此1%至2%的差距可视为正常波动。¹ 数据源自2026年8月25日的报告；后续进行的56用例测试结果取代了这些模型原本的完整套件测试数据。早期版本中V4 Flash的得分记录为272/308：当时两次完整测试被合并统计，而目前显示的0.331美元仅为单次运行的成本。² MiniMax M3是MiniMax提供的托管服务模型。有一个测试用例未获得评分；所列成本仅为估算值——我使用的是固定费率套餐，该数值基于注册表中的默认定价标准计算得出（即每百万输入/输出tokens分别需支付0.255美元与1.02美元）。若按MiniMax官方标价0.60美元与2.40美元计算，实际成本约为上述数值的2.4倍；在当前的半价促销期间则约为1.2倍。³ 这些模型仅完成了154个高难度测试用例中的140个测试，其余用例所需的上下文长度超出了其模型容量限制。

我的总结如下：

托管服务的成本其实相当低廉。 DeepSeek V4 Pro完成154个高难度测试用例仅花费1.10美元。这一成本之低，足以让我们在本地测试结果显得过于理想时随时重新进行测试。
自行部署的27B级模型亦可接近此水平。 Qwen3.8 27B同样完成了135个高难度测试，仅比V4 Flash少2个百分点；其生成速度更是快了1.7倍。
生成速度并不能直接反映模型能力。 MiniMax M3的生成速度高达212词/秒，位列所有托管服务模型之首，但其整体通过率仅为85%，其中数学类测试表现最差（仅77%）。而生成速度更快的joyfox-35b-rp得分也只有75%。
对模型进行修改可能反而降低其编码能力。 经过特殊处理的Qwen3.8 27B模型在代码类测试中的通过率骤降至62%，远低于原始版本85%的水平。
长上下文检索能力本身并不能说明太多问题。 即便代码与数学能力大幅下滑，1.5B、7B以及256M规模的模型依然能分别完成83%、80%和56%的高难度测试——可见仅凭长上下文检索能力尚不足以全面评估模型水平。

下载

此下载包为 bench-llm，即已不再维护的原始版本；并非 CrucibleForge（该项目可在 GitHub 上找到）。压缩包内含两个文件：bench-llm，这是一个包含1,660行代码的脚本；以及 README.md，里面简要说明了设置方法。除了这两个文件外无需任何编译或安装操作：解压后即可运行。这两个文件均由 AI 生成，并采用 MIT 许可证发布。所需的依赖库为 openai 与 requests。在将此程序部署到正在运行其他服务的机器上之前，请务必阅读注意事项。

相关链接：StudioForge（这些模型所使用的 GPU 服务器）、我的 AI 代理实际所需的成本（为何本地运行速度至关重要）、DeepSeek Harness（这些模型所支持的编程代理工具），以及它们所运行的本地 AI 代理堆栈。

下载

Download bench-llm, the original single-file script (zip — retired, still works) 18 KB

仅限个人使用免费。如果它替你省下了一下午的时间，欢迎点旁边的咖啡按钮支持一下。