企业官网建设流程全解析

一次在 Hacker News 上的讨论帖，把问题问到了点子上：现在大家都在卷 benchmark 分数，但很少有人认真质疑一件事——同样的模型，换一套评估管线，分数还能不能复现？

这个帖子讨论的不是“再做一个新数据集”，也不是“再刷一个 SOTA”，而是想做一个harness-only benchmark：固定模型不变，专门对比不同评估管线（harness）对结果的影响。这个方向对做模型评测、写技术博客、做模型选型的人都有价值，而且动手门槛不高。这篇就顺着这个思路，聊聊为什么要做、怎么做、跑起来要关注什么。

1. 核心能力速览

先给一个整体判断：harness-only benchmark 不是一个传统意义上的“模型跑分工具”，而是一套用来评估评估管线的工程方案。它要回答的不是“哪个模型强”，而是“同一模型在不同评估管线里，分数稳不稳、偏差大不大、成本差多少”。

简单说，这个方向不是给你一个“跑完就出分”的工具，而是给你一套“检查跑分工具靠不靠谱”的方法论。做完之后，你能得到一组可量化的结论：哪套 harness 更适合当前模型、哪些指标在不同管线里波动很大、哪些 prompt 模板对分数影响明显。

2. 为什么需要 harness-only benchmark

先理清概念。这里说的 harness，指的是模型评估的完整执行管线，包括：

• 数据集加载与预处理
• 提示词模板拼接
• 采样参数设置（temperature、top_p、max_tokens）
• 模型推理调用（本地模型或 API）
• 输出后处理与答案解析
• 指标计算与结果聚合

当前主流 benchmark 评测，比如 MMLU、GSM8K、HumanEval、C-Eval，表面上是测模型能力，实际上测试的是“模型 + 数据集 + harness”三者组合后的结果。模型权重一样，但换一套 harness，分数可能明显浮动。

几个常见干扰源：

1. 提示词模板差异。同一道数学题，有的 harness 会加“Let's think step by step”，有的不加，最后准确率差出好几个点。
2. 答案解析逻辑差异。模型输出“答案是 42”，有的解析器能提取 42，有的解析器判断为格式错误。
3. 采样参数差异。有的评估默认 temperature=0，有的默认 temperature=0.7，生成分布完全不同。
4. 并发与批处理差异。批量大小不同，部分模型在 batch 解码时行为会有细微变化。
5. 指标聚合方式差异。有的按样本平均，有的按数据集加权，有的按 stratified 处理。

如果这些 harness 层面的差异没有被控制，两个团队报告同一个模型的 MMLU 分数差了 3 个点，就很难判断是模型作弊、数据泄漏，还是 harness 不一致。

harness-only benchmark 的思路就是：把所有模型变量固定下来，只改变 harness，量化 harness 对分数的影响。

3. 适用场景与使用边界

这个方向适合以下几类人：

• 做模型评测的工程师，需要一个稳定的内部评测基线。
• 技术选型人员，需要判断不同评测报告里的分数有多大参考价值。
• 开源项目维护者，想对比自家评测管线和其他主流工具的差异。
• 写模型测评文章的作者，想给读者展示“分数可能因评测管线而变化”。

不适合的场景也很明确：

• 不适合拿来“证明某个模型更强”。它的目标不是模型排名，而是评估评估工具本身。
• 不适合在资源极度紧张的环境里做全量跑分。要对比多套 harness，意味着同一批数据要重复跑多遍。
• 不适合零工程基础直接上手。至少需要能处理 Python 环境、命令行参数和 JSON 配置。

合规与安全边界要注意：评测数据如果来自第三方数据集，确认数据集的使用条款；如果模型输出涉及用户隐私或版权内容，不能随便公开；如果评测过程中调用线上 API，注意数据脱敏和调用频率控制。

4. 评测体系设计：要衡量什么

做 harness-only benchmark 之前，先定义清楚衡量标准和目标结果。建议从四个维度设计指标体系：

4.1 可复现性

同一套 harness、同一模型、同一数据集，跑两次，分数误差应该在什么范围内。理想情况是误差在极小范围内，或者完全相同。

衡量方法：重复运行 2 到 3 次，计算标准差。

4.2 稳定性

不同 harness 之间分数波动有多大。通过对比多套 harness 的均值、中位数、极差（最大值减最小值）来判断。

衡量方法：计算同模型在 N 套 harness 下的分数范围和变异系数。

4.3 敏感性

harness 对关键参数变化的敏感程度。比如 temperature 从 0 调到 0.3，分数变化大不大；prompt 模板少一行解释性文字，分数变化大不大。

衡量方法：控制变量，每次只改一个参数，记录分数变化。

4.4 成本效率

完成同一评估任务，不同 harness 的 token 消耗、推理时间、显存占用、失败任务数量。

衡量方法：记录每次运行的总耗时、推理 token 数、失败样本数、平均单样本耗时。

设计完指标后，需要一张结果表来记录：

5. 环境准备与前置条件

做这组对比实验，不需要顶级显卡，但需要一块能跑目标模型的 GPU。以 7B 到 14B 参数的开源模型为例：

• 显存建议 16GB 以上，24GB 更充裕。
• 磁盘预留 50GB 以上，用于存放多个模型版本和评测结果。
• 操作系统推荐 Linux，Windows 也可以，但最好用 WSL2。
• Python 3.10 以上版本。
• CUDA 环境已配置，PyTorch 可用。

如果模型是 70B 级别，那就需要多卡并行或量化方案，评估成本会明显上升。建议第一轮先选一个小模型把整套流程跑通。

需要安装的工具包括：

• lm-evaluation-harness
• OpenCompass（可选）
• vLLM 或 Transformers 作为推理后端
• Python 包管理工具（pip 或 conda）

如果只想做最小验证，只需要 lm-evaluation-harness 加上 Transformers 就够了。

6. 部署与启动方式：最小可运行流程

下面给出一套通用流程。实际操作时，需要将路径和模型名替换为本机实际环境。

6.1 安装 lm-evaluation-harness

git clone https://github.com/EleutherAI/lm-evaluation-harness.git cd lm-evaluation-harness pip install -e .

安装完成后，通过lm_eval --help检查是否成功。

6.2 验证推理后端

如果使用 HuggingFace Transformers 作为后端：

lm_eval \ --model hf \ --model_args pretrained=Qwen/Qwen2.5-7B-Instruct,dtype=bfloat16 \ --tasks mmlu \ --device cuda:0 \ --batch_size 4 \ --output_path ./results/qwen7b_mmlu

参数说明：

• --model hf：使用 HuggingFace Transformers 模型。
• --model_args pretrained=...：指定模型名称和加载参数。
• --tasks mmlu：指定评测任务，这里以 MMLU 为例。
• --device cuda:0：指定 GPU 设备。
• --output_path：结果输出目录。

第一次运行会自动下载模型文件，耗时取决于网络条件和模型大小。

6.3 记录基线结果

第一次运行得到的结果，就是后续所有对比实验的基线。把输出目录完整保存，记录：

• results.json：核心指标结果。
• 日志文件：模型加载时间、推理时间、失败样本信息。
• 命令行参数：完整保留，方便复现。

这里建议把完整的命令行参数也写入一个文本文件，随结果一起保存。

7. 功能测试与效果验证：横向对比实验设计

安装部署之后，进入核心的评测对比环节。下面是具体实验设计。

7.1 实验一：不同 harness 的分数对比

准备两套以上 harness，例如：

• lm-evaluation-harness
• OpenCompass 或自研简单 pipeline

固定模型和数据集，分别运行，记录分数和耗时。

命令示例（lm-evaluation-harness）：

lm_eval \ --model hf \ --model_args pretrained=Qwen/Qwen2.5-7B-Instruct,dtype=bfloat16 \ --tasks gsm8k \ --num_fewshot 5 \ --device cuda:0 \ --batch_size 4 \ --output_path ./results/harness_a_gsm8k

另一套 harness 按各自文档运行，例如 OpenCompass：

python run.py \ --models hf_qwen2.5_7b_instruct \ --datasets gsm8k \ --work-dir ./results/harness_b_gsm8k \ --reuse latest

对比两份结果中的acc或exact_match指标。

判断标准：

• 两套 harness 的分数差在 0.5% 以内：说明该指标对 harness 不敏感。
• 分数差超过 2%：说明 harness 实现差异显著影响结果，需要定位 diff 来自提示词模板还是解析逻辑。

7.2 实验二：提示词模板敏感性

固定 harness 和模型，只修改提示词模板，对比结果。

在 lm-evaluation-harness 中，可以通过修改注册的任务或使用自定义 YAML 配置来实现。简单验证可以这样：同一道 GSM8K 题目，一组不加额外提示词，一组加“Please explain your reasoning step by step”，对比输出结果。

预期结果可能有两种：

• 模型是强指令跟随模型，额外提示词不会带来显著分数提升。
• 模型对提示词敏感，额外说明影响大。

记录差异后，可以判断是否需要在该模型上统一 prompt 模板，避免后续评测结果失真。

7.3 实验三：采样参数敏感性

固定 harness、模型、数据集，分别设置 temperature=0、temperature=0.3、top_p=0.9，对比分数。

# 方案一：temperature=0 lm_eval \ --model hf \ --model_args pretrained=Qwen/Qwen2.5-7B-Instruct,dtype=bfloat16 \ --tasks mmlu \ --temperature 0.0 \ --device cuda:0 \ --batch_size 4 \ --output_path ./results/qwen7b_mmlu_temp0 # 方案二：temperature=0.3 lm_eval \ --model hf \ --model_args pretrained=Qwen/Qwen2.5-7B-Instruct,dtype=bfloat16 \ --tasks mmlu \ --temperature 0.3 \ --device cuda:0 \ --batch_size 4 \ --output_path ./results/qwen7b_mmlu_temp03

判断标准：

• 分数差很小：评测对随机采样不敏感，可以参考单次结果。
• 分数差明显：后续评测必须固定采样参数，否则没有可比性。

这里需要注意，lm-evaluation-harness 默认评估生成类任务时 temperature 通常设为 0，如果你的版本支持通过 CLI 参数修改，可以按上述方式测试；否则需要修改任务配置或加载参数，以实际支持情况为准。

7.4 实验四：并发批量大小对比

同模型同数据集，batch_size 分别为 1、4、16，对比分数和耗时。

lm_eval \ --model hf \ --model_args pretrained=Qwen/Qwen2.5-7B-Instruct,dtype=bfloat16 \ --tasks mmlu \ --device cuda:0 \ --batch_size 1 \ --output_path ./results/qwen7b_mmlu_bs1

lm_eval \ --model hf \ --model_args pretrained=Qwen/Qwen2.5-7B-Instruct,dtype=bfloat16 \ --tasks mmlu \ --device cuda:0 \ --batch_size 16 \ --output_path ./results/qwen7b_mmlu_bs16

观察内容：

• GPU 显存占用变化。
• 单条样本平均耗时。
• 分数是否出现波动。

根据常见情况，批处理通常不会显著影响 greedy decoding 的结果，但会影响显存占用和推理速度。具体数据以本机实测为准。

7.5 失败任务统计

每次运行结束后，查看results.json中的样本数量与成功数量。

python -c "import json; data=json.load(open('./results/qwen7b_mmlu_gsm8k/results.json')); print(data.get('results', {}).get('gsm8k'))"

如果出现大量任务因格式问题被判错，需要检查解析逻辑，或单独查看失败样本的原始输出。

8. 接口 API 与批量任务

如果目标是自动化批量评测，而不是手动一条条命令，建议把评测流程封装成脚本或服务。

8.1 批量任务脚本

使用 Python 编写批量任务脚本：

import subprocess import yaml configs = [ { "name": "qwen7b_gsm8k_harness_a", "model": "Qwen/Qwen2.5-7B-Instruct", "task": "gsm8k", "harness": "lm-evaluation-harness" }, { "name": "qwen7b_mmlu_harness_a", "model": "Qwen/Qwen2.5-7B-Instruct", "task": "mmlu", "harness": "lm-evaluation-harness" } ] for cfg in configs: cmd = [ "lm_eval", "--model", "hf", "--model_args", f"pretrained={cfg['model']},dtype=bfloat16", "--tasks", cfg["task"], "--device", "cuda:0", "--batch_size", "4", "--output_path", f"./results/{cfg['name']}" ] print(f"Running: {cfg['name']}") subprocess.run(cmd, check=True)

8.2 通过 API 模式评估

一些 harness 或推理框架支持“先起模型服务，再通过 API 调用评估”的方式。这种模式的好处是模型只加载一次，多个任务共享同一次加载，节省大量时间。

以 vLLM 为例，先起一个 OpenAI 兼容的服务：

python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --port 8000

然后在评估配置中指向该 API：

lm_eval \ --model local-completions \ --model_args model=Qwen/Qwen2.5-7B-Instruct,base_url=http://127.0.0.1:8000/v1 \ --tasks mmlu \ --output_path ./results/qwen7b_mmlu_vllm

使用接口模式时注意：

• 确认 base_url 和模型名与你的服务端一致。
• 控制并发请求数，避免打满服务导致超时。
• 记录请求失败率，单独统计重试次数。
• 不向外部服务发送未脱敏的私有数据。

8.3 结果汇总

批量任务跑完后，建议统一汇总到一个 CSV：

import json import csv import glob rows = [] for result_file in glob.glob("./results/*/results.json"): data = json.load(open(result_file)) for task_name, task_data in data.get("results", {}).items(): rows.append({ "run": result_file.split("/")[-2], "task": task_name, "acc": task_data.get("acc,none"), "exact_match": task_data.get("exact_match,none") }) with open("./summary.csv", "w", newline="") as f: writer = csv.DictWriter(f, fieldnames=["run", "task", "acc", "exact_match"]) writer.writeheader() writer.writerows(rows) print("Summary written to ./summary.csv")

9. 资源占用与性能观察

做这类对比实验，资源观察本身就很有价值。建议统一记录以下几个指标：显存占用、GPU 利用率、平均单样本耗时、总耗时、峰值内存。

观察方式：

• 使用nvidia-smi查看实时显存占用。

nvidia-smi --query-gpu=name,memory.used,memory.total,utilization.gpu --format=csv -l 2

• 在 Python 代码中记录耗时。

import time start = time.time() # 评测逻辑 elapsed = time.time() - start print(f"Elapsed: {elapsed:.2f}s")

影响资源占用的因素：

• 模型参数：7B 模型加载后约占用 14GB 显存（bfloat16），13B 模型约 26GB，具体以模型量化精度为准。
• batch_size：批量越大，显存占用越高，但单位样本耗时通常越低。
• 上下文长度：长上下文评测会显著增加显存占用。
• 并发请求数：使用 API 模式时，并发越高，CPU 和网络占用越高。

如果显存不足，可以考虑：

1. 使用 4-bit 或 8-bit 量化加载模型。
2. 降低 batch_size。
3. 使用 CPU offload，但推理速度会明显下降。
4. 分数据集逐项运行，不要一次性加载全部任务。

需要注意，不同硬件配置下的显存占用和耗时会差异很大。给出结论时，务必注明模型、量化方式、batch_size、GPU 型号，否则结果没有可比性。

10. 常见问题与排查方法

11. 最佳实践与使用建议

结合做评测工具链的工程经验，给出几条实用建议。

11.1 固定评测环境

评测环境尽可能锁定版本：

1. 记录 Python 包版本。
2. 记录数据集版本或 commit hash。
3. 记录模型文件 sha256。
4. 记录 GPU 驱动和 CUDA 版本。

可以整理成一个environment.yaml文件：

python: "3.10" cuda: "12.1" packages: - torch: "2.3.0" - transformers: "4.41.0" - lm-evaluation-harness: "0.4.3"

这样任何一次复现出现问题，都容易定位是软件版本还是数据版本变化导致的差异。

11.2 每次运行前检查磁盘空间

评测结果 JSON 较小，但日志和缓存可能占用空间。模型下载默认在 HuggingFace 缓存目录，可能出现缓存占用几十 GB 的情况：

du -sh ~/.cache/huggingface

空间不足时清理不再使用的模型文件。

11.3 先小规模验证，再全量跑分

不要一上来就跑完整 MMLU。先选一个几百样本的子集或一个小型任务，验证 harness 能正常输出结果，再跑全量。

11.4 评测结果按目录分类保存

推荐目录结构：

results/ qwen7b/ harness_a/ mmlu/ gsm8k/ harness_b/ mmlu/ gsm8k/

每个任务目录内保存results.json、运行日志、命令行参数记录。

11.5 接口服务限制访问范围

如果你把评测封装成 API 服务，绑定地址优先使用127.0.0.1，不要直接暴露到公网。必须暴露到公网时，加鉴权和限流。

11.6 不轻易下“模型更强”的结论

harness-only benchmark 的核心价值是让人对跑分保持谨慎。不同评测报告中的模型分数，如果 harness 不一致，就不具备直接可比性。写文章或做技术方案时，建议同时标注模型版本、harness 版本、数据集版本和关键采样参数。

12. 一个值得关注的场景：DeepSeek harness

回到开头提到的网络热词——deepseek harness。搜索热度高，说明很多人确实在实际使用 DeepSeek 模型做评测时遇到了 harness 相关的问题。比如：

• 官方报告里 DeepSeek 模型表现优秀，但用第三方 harness 复现时分数有差异。
• 不同工具加载 DeepSeek 模型时，对对话模板的处理方式不一致，导致指令跟随效果不同。
• DeepSeek 模型在特定任务上的输出格式差异，导致解析器兼容性问题。

这些场景正好是 harness-only benchmark 能发挥价值的地方。如果你正在给 DeepSeek 或其他开源模型做内部评测基线，建议单独跑一组 harness 对比实验，确认你的评测结论不受管线实现影响。

网上也有一些围绕deepseek harness的部署和安装教程，涉及pnpm dsh web卡住等问题。这类问题通常和前端构建、依赖版本、网络源有关，建议在部署时锁定 Node 版本并检查 pnpm 镜像源，具体以官方文档为准。

13. 总结

harness-only benchmark 的价值不在排名，而在校准。校准之后，你就知道哪些分数值得信，哪些分数只是管线产物。建议先做两件事：固定一套模型和数据集，跑通两套 harness 的基线对比；把每次运行的环境信息完整记录下来。这两步做完，再谈扩大评测规模。最容易踩的坑是一上来就跑全量数据和多个模型，最后结果差异很大却定位不了原因。控制变量，保持环境一致，先小规模测试，再逐步扩展，才是这个方向最值得推广的做法。