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

我的 AI 编码代理 Hermes 写了一个基准测试工具。它测试的是我的本地模型——也就是别的 AI 代理实际运行的那些模型——的速度、智能和代理适应性，输出是 JSON 加终端表格。这个工具是 1,660 行的 Python，名叫 bench-llm——一个 AI 代理为 AI 代理们造了一个基准测试工具。

你最后得到什么

对一个模型跑一条命令，终端里就会得到这种形状的输出（示例运行）：

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

============================================================
  bench-llm — Benchmarking: gemma-4-31b-it
  GGUF Status:   READY
  GGUF Path:     ~/.lmstudio/models/google/gemma-4-31b-it-Q4_K_M.gguf
  GGUF Size:     16.5 GB
  Arch:          gemma4
  Quant:         Q4_K_M
============================================================

  🔥 Warming up model... OK (0.23s TTFT)

  ⚡ SPEED BENCHMARKS
  ----------------------------------------
    short_50 (131 chars, 3 runs)...
      TPS:  mean=84.2 median=83.8
      TTFT: mean=0.231s median=0.228s
    medium_200 (323 chars, 3 runs)...
      TPS:  mean=85.7 median=85.2
      TTFT: mean=0.312s median=0.308s
    long_800 (769 chars, 3 runs)...
      TPS:  mean=82.1 median=81.5
      TTFT: mean=0.541s median=0.537s

  🔍 Validating speed plausibility...
    Confidence: HIGH

  🧠 ABILITY TESTS
  ----------------------------------------
    Running: Code Generation (median_of_list)... PASS
    Running: Logic Puzzle (Pet Ownership)... PASS
    Running: JSON Compliance... PASS
    Running: Instruction Following... PASS
    Running: Summarization (Key Facts)... FAIL

    Ability Score: 4/5

  🤖 AGENT FITNESS TESTS
  ----------------------------------------
    Running: Task Acknowledgment... PASS
    Running: Format Adherence... PASS
    Running: Conciseness (Output/Input Ratio)... PASS

    Agent Fitness Score: 3/3

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

================================================================================
  BENCHMARK RESULTS: gemma-4-31b-it
================================================================================

  📊 SUMMARY TABLE
  ──────────────────────────────────────────────────────────────────────
  Model ID                         gemma-4-31b-it
  GGUF Size                        16.5 GB
  Architecture                     gemma4
  Quantization                     Q4_K_M
  T/s (short, mean)                84.2
  TTFT (short, mean)               0.231s
  Ability Score                    4/5 (80.0%)
  Agent Fitness Score              3/3 (100.0%)
  Confidence                       🟢 HIGH
  ──────────────────────────────────────────────────────────────────────

它还会把完整的 JSON 载荷写进 ~/benchmarks/——包含每一项原始测量、每一次测试响应和一份结构化总结——所以你可以把结果喂回给你的代理，然后问它「我的哪些模型应该承担批量 JSON 工作？」

它测试什么

三个维度，每一个都是因为对常驻代理栈很重要才选的。

⚡ 速度

三种提示长度——短（约 50 字符，"解释一下变量是什么"）、中（约 200 字符，"解释一下递归"）、长（约 800 字符，"比较三种编程范式"）——先跑三次预热，再做真实测量。

测量的指标：

• TTFT（Time To First Token，首个 token 的时间）——模型开始输出之前要多久。对聊天体验至关重要；超过 500ms 就会觉得卡顿。
• 吞吐量（token/秒）——一旦开始生成，它有多快。对长代码块和报告很重要。
• 预填充 T/s——生成前处理输入提示的速度。看不见但真实存在的成本。

它还会对照已知的硬件上限做一次合理性检查。如果你的 30GB 模型在 7900 XTX 上声称 200 T/s，bench-llm 会标记出来——那个数字很可能被投机解码或预热过的缓存污染了。

🧠 能力

五个测试，对合格的模型来说小菜一碟，对挣扎的模型来说一抓一个准：

• 代码生成——写出带边界情况（空列表、偶数长度、奇数长度、不要修改输入）的 median_of_list(numbers)。这个函数会在 bench-llm 内部对六个测试用例真正执行——不是拿响应文本做模式匹配，而是真的把代码跑起来。
• 逻辑谜题——一个四宠物归属谜题（Alice/鱼、Bob/鸟、Carol/猫、Dan/狗）。用正则从响应里提取答案分配，然后全部四项核对。
• JSON 合规——"返回一个带这些确切键的 JSON 对象"。测试模型能否按需生成有效、符合 schema 的 JSON——这是工具调用的最低要求。
• 指令遵循——写出数字 1–10，给偶数标 *，然后求和。测试精确的格式遵循：答案本身无关紧要，格式才是重点。
• 摘要——一段关于氦基量子计算的密集段落。检查六个关键技术事实有没有在压缩中幸存。大多数模型至少会丢掉一个。

🤖 代理适应性

这是 bench-llm 做了我在其他基准测试工具里没见过的事情。它给模型发一个真正的代理任务——在 syslog 里搜索 ERROR 行，按服务分组，生成一份 JSON 报告——然后像代理主管那样评估响应：

• 任务确认——模型理解被要求做什么了吗？它能概述方法并识别障碍吗？（一上来就开始编造 syslog 条目的模型在这里就会失败。）
• 格式遵循——输出符合要求的 JSON schema 吗？检查 services 数组、total_errors 整数和 scan_period 字符串。
• 简洁性——输出对输入的比率是多少？用一个 1,300 字符的提示换来 20,000 字符长篇大论的模型会被标记为 VERBOSE。做不到简洁的代理，每一轮都在烧你的上下文窗口。

三个代理适应性测试共用同一个提示——它们评估的是同一次响应的不同侧面。这样既让基准测试保持快速，又能量到模型在无人监督运行时真正重要的那些品质。

它是怎么造出来的

Hermes——我机器上的编码代理——写了全部内容。我给了它一个粗略的规格："我需要一个工具，能对 LM Studio 里的本地模型做基准测试，测速度和聪明程度，输出 JSON 和一张表。"它走开，带回一个能跑的脚本，然后我们一起迭代。

过程是这样的：

1. 第一版：只有速度测试——连接 LM Studio 的 OpenAI 兼容 API，流式接收 token，测量 TTFT 和 T/s。
2. 第二版：能力测试——编码（真正执行）、逻辑谜题、JSON schema 合规、指令遵循、摘要。
3. 第三版：代理适应性——syslog 任务，把模型当作我栈里的代理来评估响应。
4. 打磨版：GGUF 文件解析（在磁盘上找到真实模型文件，报告大小和量化）、速度合理性校验、汇总表、--quick 模式、用于模型发现的 --list、预检用的 --check 命令。

四轮迭代都在一个下午内完成。最终脚本 1,660 行。每一行都是 Hermes 写的——我负责审阅、在真实模型上测试、挑毛病（"这个吞吐量数字对 123B 模型来说不可能是对的"），然后它修掉。合理性校验器正是从这种反馈循环里诞生的。

沉淀下来的设计决策

• 用流式，不用轮询。bench-llm 用 OpenAI 兼容的流式接口获取逐 token 的计时。轮询方式会模糊 TTFT 的测量，丢掉 token 级别的粒度。
• 编码测试真正执行代码。它不问"这看起来像中位数函数吗？"——它在新的命名空间里 exec() 这段代码，跑六个测试用例；看起来很自信但跑不起来的输出就是失败。
• 逻辑/JSON 测试用正则提取答案。要求模型输出精确格式的基准测试，会严厉惩罚那些在真正输出前加一句"当然！这是你的答案："的模型。bench-llm 的检查器会从模型外面套的任何包装里抽出载荷——测的是模型的内容，不是它的废话程度。
• 基准测试之间清理 VRAM。它会在每次运行前执行 pkill -f llama-server，并等待 LM Studio 显示零个已加载模型。不这样做，前一个模型的 KV 缓存就会污染下一次基准测试的 TTFT 测量。
• GGUF 文件解析。它用发布者名称和架构的模糊匹配，把 LM Studio 的模型 ID 映射回磁盘上真实的 GGUF 文件。这样你能拿到模型大小、量化程度、以及文件到底存不存在——在浪费一次运行之前就回答"这个模型真的准备好跑基准了吗？"。

设置

三步：

# 1. Install the two dependencies (requests talks to LM Studio's model-metadata
#    endpoint — without it every model shows as "not found")
pip install openai requests

# 2. Make sure LM Studio is running with at least one model loaded
# (it should be listening on localhost:1234 — that's the default)

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

没有配置文件，没有 API 密钥（LM Studio 接受任何字符串），没有数据库。结果会落到 ~/benchmarks/。

可选但有用：把 bench-llm 复制进你的 PATH，这样就能从任何地方运行它。

cp bench-llm ~/bin/
chmod +x ~/bin/bench-llm

真实结果：我工作站和笔记本上的基础模型

下面的数字来自后续套件（同样的速度方法、更宽的测试集），只覆盖基础模型——没有社区微调版本。"工作站"是一台无头 GPU 机器，2× RTX 5090 + 2× RTX 3090；"APU"是这台笔记本的集成 GPU。速度只能在同一种设备内比较。套件自己的注意事项同样适用：记录横跨几个修订版本，所以把小的差距当噪声看。

速度 + 代理适应性（bench 套件，2026-08-18 报告——Code / Tools / Instruct / Reason 是通过率）：

硬档位（Gauntlet，2026-08-19——仅硬档用例的通过率；"—" = 该模型未运行这个类别）：

我的解读：MoE 的 Gemma 4 26B（4B 激活）是工作站上日常的主力——229 T/s、110ms TTFT、完美的工具调用——而它最弱的一列是指令遵循，这恰恰是无监督代理循环最依赖的能力。4B 的 Nemotron 是个惊喜：在笔记本 APU 上，它遵循指令比 26B 在工作站上还好，只是慢了五倍（APU 18.5 T/s 对工作站 229）。硬档位上，基础 Qwen3.8 27B 编码拿到 74%，1.5B 和 256M 那两行展示了"做代理工作太小了"长什么样，云端的 V4-Flash 那行则是本地模型追赶的天花板——整轮硬档跑下来只要 $0.088。

它有什么不同

LLM 基准测试多的是。大多数是学术谜题集（MMLU）或者冲着排行榜优化的 trivia。bench-llm 做了三件对真正运行本地模型的人有意义的事：

1. 它测的是代理品质，不是聊天品质。格式遵循、任务确认和简洁性，决定了一个模型在无监督代理循环里是成是败。一个聊天很棒但跟不了一个 JSON schema 的模型，在工具调用工作流里毫无用处。
2. 它自己校验自己的测量。合理性检查器能抓住不可能是对的数字——投机解码污染、预热过的缓存、测量 bug。如果一个基准测试工具连自己的输出是不是垃圾都说不清，那它什么都不可信。
3. 它就是一个脚本。没有 Docker，没有数据库，没有 GPU 驱动依赖，没有 50GB 数据集下载。一个 Python 文件、一次 pip install，就能对你此刻加载在 LM Studio 里的任何东西生效。

坑

• 必须先启动 LM Studio。bench-llm 不会替你启动 LM Studio——它只连 localhost:1234。如果没有东西在监听，它会带着明确的报错失败。
• VRAM 清理很激进。它会在基准测试之间运行 pkill llama-server 来清掉 KV 缓存。如果你有其他想保活的 llama-server 进程，别跑 bench-llm——或者改掉清理那一步。
• 摘要是最难的测试。我测过的几乎每个模型都会至少丢掉一个关键事实。如果某模型 4/5、唯一失败项是摘要，那是很强的结果——别把它读成缺陷。
• 推理模型的 TTFT 更慢。思考模型在产出输出前会花时间在推理阶段。bench-llm 从任何种类的第一个 token 开始测 TTFT——包括推理 token。这让推理模型看起来比实际感受慢，因为思考 token 是在原本是静默时间的时段里流式输出的。JSON 输出把 TTFT 拆成 ttft_reasoning_s 和 ttft_content_s，你可以看到拆分。
• 编码测试会 exec() 模型的输出。它在全新的命名空间里和纯测试函数一起运行——不是真正的沙箱，所以请用一个丢了也不心疼的用户跑它——但如果你对运行 LLM 生成的代码这件事感到不安，可以用 --speed-only 跳过能力测试。
• 很多模型很花时间。一个模型的完整基准测试按速度要 2–5 分钟；几十个就是一整晚。比较用 --quick，把完整套件留给你的头号候选。

下载

bench-llm 是一个 Python 脚本加一个 README。没有构建步骤，没有安装向导——解压即跑。

zip 里包括：

• bench-llm——1,660 行的基准测试脚本
• README.md——精简的设置和使用说明

两个文件都是我的编码代理 Hermes 写的。MIT 许可——随便用、随便改、塞进你自己的工具链。依赖：openai 和 requests。

相关：我的 AI 代理们到底花了多少钱（为什么本地速度重要）、Reasonix 和 DeepSeek Harness（这些模型支撑的编码代理），以及它们运行所在的本地代理栈。

下载

• 下载 bench-llm（zip） 18 KB

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