你决定开始认真用大语言模型了。不管是写代码、搞内容创作、做数据分析，还是纯粹玩玩。

这时候你面临一个选择：

路线A：本地部署。 把模型下载到自己的电脑上，用自己的硬件跑。代表方案：Ollama + Hermes。

路线B：云端 API。 不下载任何东西，通过网络调用远端的模型服务。代表方案：OpenRouter / OpenAI API。

这两条路各有优劣，适合的人群也不一样。这篇文章就帮你做这个选择。

先说结论

如果你不想看长文，直接给你一个决策框架：

选本地部署，如果你：

• 对数据隐私有严格要求（敏感数据不能传到外部服务器）
• 使用频率高（每天大量使用，API 费用会很贵）
• 喜欢折腾、愿意学习技术细节
• 有一张还不错的显卡（至少 8GB 显存）
• 需要低延迟的交互体验

选云端 API，如果你：

• 不想折腾任何技术配置
• 使用频率不高（偶尔用用）
• 需要顶级模型的能力（405B 级别）
• 硬件条件一般
• 需要快速接入，马上能用

好了，结论说完了。下面是详细分析。

本地部署：把 AI 搬到你的电脑上

怎么操作

最简单的本地部署方式：

1. 安装 Ollama（支持 Mac、Linux、Windows）
2. 打开终端，输入 ollama run hermes3
3. 等模型下载完成（8B 模型大约 4-5GB）
4. 开始对话

就这么简单。三步搞定。

如果你想要一个好看的聊天界面，可以再装一个 Open WebUI，它提供了类似 ChatGPT 的网页聊天界面，底层可以连接 Ollama。

优势

1. 完全免费（硬件成本除外）

模型是开源的，Ollama 是免费的，推理用的是你自己的硬件。用多少次都不花钱。

对比一下：如果你每天通过 API 处理 10 万个 token（大约一两个小时的高强度使用），一个月下来光 API 费就要好几十美元。而本地跑的话，除了电费，没有任何额外成本。

2. 数据隐私完全可控

这是很多人选择本地部署的首要原因。

当你通过 API 调用模型时，你的输入数据需要发送到服务提供商的服务器上。虽然大多数服务商承诺不会用你的数据训练模型，但你的数据确实「经过」了别人的服务器。

对于处理公司内部文档、客户数据、医疗记录、法律文件等敏感信息的场景，这可能是不可接受的。

本地部署意味着：你的数据始终在你自己的机器上，不出你的电脑一步。

3. 无网络也能用

飞机上、火车隧道里、WiFi 挂了——只要电脑还能开机，本地模型就能用。这对经常出差或网络环境不稳定的人来说很有价值。

4. 延迟极低

API 调用有网络延迟。从你发送请求到收到第一个 token 的回复，通常需要 0.5-2 秒。如果网络不好，可能更慢。

本地推理的延迟通常在 0.1 秒以内。这种即时响应感在频繁交互时体验差异很明显。

5. 没有速率限制

API 服务通常有各种限制——每分钟请求次数、每秒 token 数、并发连接数等。如果你要批量处理大量文本，可能会撞到这些限制。

本地部署没有这些限制。你的硬件能跑多快就跑多快。

6. 高度可定制

本地部署给了你完全的控制权：

• 自由切换不同模型和量化版本
• 调整推理参数（temperature、top_p 等）
• 修改系统提示词
• 在模型基础上做微调
• 集成到自己的工具链中

劣势

1. 需要一定的硬件条件

前面在 参数量、显存和推理速度 那篇里详细讲过了。最低要求是有一张 6-8 GB 显存的独立显卡（或者 16GB+ 内存的 Mac）。如果你的电脑是集显轻薄本，体验会比较差。

2. 模型能力有上限

消费级硬件能跑的最大模型通常是 8B 或经过量化的 13B。这和 API 可以调用的 405B、700B 级别的模型差距不小。

8B 模型在日常任务中表现不错，但遇到复杂推理、长篇写作、高难度代码生成等场景时，确实不如大参数量模型。

3. 初始配置有门槛

虽然 Ollama 把门槛降得很低了，但对于完全不熟悉命令行的人来说还是有一点学习成本。驱动安装、环境配置、模型下载等步骤偶尔也会遇到问题。

4. 占用本机资源

推理时 GPU 满载运行，风扇可能会比较吵，电脑做其他事情（比如打游戏、视频剪辑）会受影响。如果你需要同时做其他 GPU 密集型任务，本地推理可能互相干扰。

云端 API：拿来就用

怎么操作

方式一：直接用在线聊天界面

很多平台提供了类似 ChatGPT 的在线聊天界面，比如：

• OpenRouter Chat
• Hugging Face Chat

注册账号，选择 Hermes 模型，直接开聊。

方式二：通过 API 集成到代码/应用中

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

import openai

client = openai.OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key="你的API密钥"
)

response = client.chat.completions.create(
    model="nousresearch/hermes-3-llama-3.1-8b",
    messages=[
        {"role": "system", "content": "你是一个编程助手"},
        {"role": "user", "content": "写一个Python快速排序"}
    ]
)

print(response.choices[0].message.content)

OpenRouter 兼容 OpenAI 的 API 格式，所以很多现有的工具和代码库可以直接对接。

优势

1. 零硬件要求

只要能上网就行。你用一台五年前的轻薄本都能调用 405B 级别的模型，因为计算都在云端完成。

2. 可以用最强的模型

API 可以调用的模型规模远超消费级硬件能跑的范围。Hermes 3 405B、Claude 3、GPT-4 这些顶级模型，只有通过 API 才能用到。

3. 零配置

注册账号、充值、获取 API Key，五分钟搞定。不需要安装任何东西，不需要了解任何硬件知识。

4. 始终是最新版本

API 服务商会及时更新模型版本。你不需要自己下载新模型、管理版本，始终用的是最新的。

5. 弹性扩展

如果你的使用量突然增大（比如产品上线了），API 可以自动扩展。本地部署的话你得买更多的硬件。

劣势

1. 按用量付费，可能很贵

API 按 token 计费。如果你是重度用户，费用会快速累积。

粗略算一笔账：

• 假设你每天使用 Hermes 3 8B API 处理 50 万 token（中等强度使用）
• OpenRouter 上 Hermes 3 8B 的价格大约每百万 token $0.06-0.10
• 每月成本：约 $1-1.5

这个价格看起来不高对吧？但如果你换成更大的模型（70B 或 405B），或者使用量更大，费用就会显著增加：

• Hermes 3 70B：每百万 token $0.4-0.8，每月中等使用约 $10-15
• 更大模型或商业 API：每月可能几十到几百美元

而本地部署 8B 模型的成本就是电费——每月大概几块钱。

2. 数据离开了你的设备

前面说过了，数据隐私是 API 调用的硬伤。你的所有输入都会发送到远端服务器。

3. 需要稳定网络

没网就用不了。网络延迟也会直接影响体验。

4. 受服务商政策约束

API 服务可能会有：

• 速率限制
• 内容过滤（某些话题可能被拒绝）
• 服务条款变更
• 价格调整
• 甚至停服

你的应用依赖外部服务，就意味着你受制于服务商的决策。本地部署则完全自主。

5. 延迟

网络往返 + 服务端排队 + 处理时间，第一个 token 的延迟通常在 0.5-3 秒。对于需要快速交互的场景，这个延迟会影响体验。

成本对比：到底哪个更省钱

这个问题需要具体场景具体分析。

场景1：轻度使用者

每天用几次，每次几百 token。

• API 月费：不到 $1
• 本地部署：显卡成本 2000+ 元，电费可忽略

结论：轻度使用选 API，经济得多。

场景2：中度使用者

每天使用1-2小时，日均 20 万 token。

• API 月费（8B）：约 $0.5-1
• API 月费（70B）：约 $5-10
• 本地部署（已有合适显卡）：电费约 10-20 元/月

结论：如果你已经有合适的显卡，本地更省。如果需要专门买卡，需要半年到一年才能回本。

场景3：重度使用者 / 开发者

每天大量使用，日均 100 万+ token，可能还需要批量处理。

• API 月费（8B）：约 $3-5
• API 月费（70B）：约 $20-50
• 本地部署：显卡一次性投入后，长期成本极低

结论：重度用户本地部署的长期成本优势非常明显。特别是如果你 8B 模型能满足需求的话，一张 2000 元的显卡就是全部投入。

场景4：企业团队

多人使用，可能需要高可用性和大模型能力。

这种场景通常会考虑混合方案——租用云端 GPU 部署模型（而不是用公共 API），或者自建小型 GPU 服务器。成本分析更复杂，需要根据具体的使用量和需求来计算。

cocoloop 社区里有不少团队分享过自己的部署方案和成本分析。从反馈来看，月处理量在几千万 token 以上的团队，自建部署（无论是自购硬件还是租用 GPU 服务器）通常比纯 API 调用划算。

隐私考量的深入分析

这个话题值得单独展开说说。

你的数据会被拿去训练吗？

OpenAI 的政策：API 调用的数据默认不用于训练（但 ChatGPT 免费版的数据可能会被使用）。
OpenRouter：声明不使用用户数据训练模型。
其他平台：各有各的政策，需要仔细看。

即使服务商承诺不用你的数据训练模型，你的数据仍然在传输过程中和服务商的服务器上存在过。对于以下场景，这可能是不可接受的：

• 处理包含个人隐私信息的文本
• 分析公司内部机密文档
• 涉及受监管数据（如医疗数据、金融数据）的应用
• 所在行业有严格的数据本地化要求

本地部署的隐私优势

本地部署的隐私保证是物理层面的——数据从头到尾都没有离开你的设备。不需要信任任何第三方的承诺，因为根本没有第三方参与。

这也是很多开发者选择 Hermes 做本地部署的重要原因。Hermes 作为开源模型，你可以完全审计它的行为，确保没有任何数据外传的风险。这是闭源 API 永远给不了你的保证。

混合方案：鱼和熊掌兼得

其实你不必二选一。很多人采用的是混合策略：

方案1：本地 + API 互补

• 日常使用：本地跑 Hermes 3 8B（免费、快速、私密）
• 复杂任务：偶尔调用 70B 或 405B 的 API（更强的能力）

这样既省钱又不牺牲能力。大部分时候本地模型就够用了，遇到真正需要大模型的场景再花钱用 API。

方案2：开发时用 API，生产用本地

• 开发和测试阶段：用 API，快速迭代，不用操心部署
• 产品上线后：部署本地/私有化模型，降低长期成本，保证隐私

方案3：不同任务不同路线

• 处理敏感数据 → 本地
• 不敏感的通用任务 → API
• 需要极强推理能力的 → 大模型 API

Hermes 在两种路线下的表现

本地部署

Hermes 在本地部署方面有天然优势：

• 8B 版本非常适合本地：量化后 5-6 GB 显存就能跑
• Ollama 支持完善：ollama run hermes3 一行命令搞定
• ChatML 格式兼容性好：所有主流推理工具都支持
• 社区资源丰富：遇到问题很容易找到解决方案

在 cocoloop 社区里，Hermes + Ollama 是最受欢迎的本地部署组合。很多用户分享过自己的配置方案和使用心得，新手遇到问题基本都能找到参考。

API 调用

Hermes 通过 OpenRouter 等平台也可以 API 方式使用：

• 支持 8B、70B、405B 等多种规模
• OpenRouter 兼容 OpenAI API 格式
• 价格比闭源商业模型便宜

关于 Hermes 各版本之间能力的差异，可以参考 Hermes 是什么 和 Hermes 模型版本怎么看 这两篇。

新手该怎么开始

如果你到现在还没决定，这里给一个非常具体的建议：

Step 1：先试试本地部署

装一个 Ollama，跑一下 Hermes 3 8B。这个过程不到10分钟，完全免费。感受一下本地模型的速度和能力。

如果你的硬件跑不动（比如没有独显），跳到 Step 2。

Step 2：用在线服务补充

如果本地 8B 模型不够用（复杂任务搞不定），去 OpenRouter 注册一个账号，试用更大的模型。OpenRouter 有免费额度可以试用。

Step 3：根据实际体验决定

用了一两周后，你自然就知道自己的需求了：

• 如果 8B 本地模型大部分时间够用 → 以本地为主
• 如果经常需要更强的模型 → 以 API 为主，或者升级硬件
• 如果两边都需要 → 混合方案

不要在还没开始用之前就纠结方案。 跑起来，用起来，过程中自然会知道自己需要什么。

写在最后

本地部署和云端 API 不是对立的选择，而是互补的工具。关键是搞清楚你的核心需求：

• 隐私优先 → 本地
• 能力优先 → API（大模型）
• 成本优先（高频使用） → 本地
• 便利优先 → API

大多数人最终会找到一个属于自己的平衡点。别想着一开始就找到最优解，先动手，边用边调整就行。

在 cocoloop 论坛上也有很多关于部署方案选择的讨论帖，遇到具体问题可以去翻翻，总有人踩过你正在踩的坑。

你想在自己的电脑上跑一个 Hermes 模型。打开 Hugging Face 一看——8B、70B、405B，这些数字和你的显卡有什么关系？你的 RTX 4060 能跑 70B 吗？量化是怎么回事？选错了模型会不会把显卡烧了？

别慌。硬件和模型的关系没有那么复杂，但确实有一些基本的换算逻辑你需要知道。搞清楚了，以后看到任何模型你都能快速判断自己能不能跑。

参数量的基本概念

先快速复习一下。大语言模型里的「参数」就是神经网络中的可调节数字。每个参数存储了模型从训练数据中学到的一小片「知识」。

• 7B = 70亿个参数
• 13B = 130亿个参数
• 70B = 700亿个参数
• 405B = 4050亿个参数

这些参数需要被存储在某个地方才能运行模型。在推理（使用模型生成回答）时，这些参数需要被加载到**显存（VRAM）**或内存（RAM）中。

关键来了：参数量直接决定了需要多少显存。

参数量和显存的换算

FP16：基本换算公式

在默认精度（FP16，即每个参数用16位浮点数存储）下，换算非常简单：

所需显存（GB）≈ 参数量（B）× 2

因为每个参数占 2 字节（16位 = 2字节），所以：

这里说的只是存储模型参数本身需要的显存。实际运行时还需要额外的显存来存储中间计算结果（KV Cache 等），所以实际需求会比这个公式算出来的多 10%-30%。

这意味着什么

拿几款常见显卡来对照：

看到问题了吧？如果不做任何优化，一张消费级显卡连 8B 模型都装不下。 14-16 GB 的显存需求已经卡在 RTX 4060 Ti / 4080 的上限了。

那人们是怎么在消费级硬件上跑模型的？答案是——量化。

量化：用更少的显存跑模型

什么是量化

量化（Quantization）是把模型参数从高精度数字降低到低精度数字的过程。

原理很直觉：FP16 用16位存储一个参数，精度很高但占空间。如果我们把精度降低到 8 位、4 位甚至 2 位，每个参数占用的空间就大幅减少了。

不同量化级别下的显存需求

以 Hermes 3 8B 为例：

没看错，一个 8B 模型经过 4-bit 量化后只需要约 5 GB 显存。一张 RTX 3060（12GB）甚至一张 RTX 4060（8GB）就能轻松运行。

量化会损失多少质量？

这是大家最关心的问题。好消息是：合理的量化对模型质量的影响远比你想象的小。

根据社区的大量对比测试和 cocoloop 论坛上开发者的反馈：

• 8-bit 量化（INT8/Q8_0）：几乎无损。绝大多数用户分辨不出和 FP16 的区别。
• 6-bit 量化（Q6_K）：极微小的质量损失，日常使用完全感知不到。
• 4-bit 量化（Q4_K_M）：轻微质量损失。对于日常对话、代码生成等任务，影响可以忽略。对于需要精确推理的复杂任务，偶尔能感觉到差异。
• 3-bit 量化（Q3_K）：开始有可感知的质量下降，但仍然可用。
• 2-bit 量化（Q2_K）：质量损失明显。只建议在显存实在不够的极端情况下使用。

对大多数人来说，4-bit 量化是性价比最高的选择。 显存需求降低了 75%，质量损失极其有限。

GGUF 格式

你在下载量化模型时会经常看到 GGUF 格式的文件。这是 llama.cpp 项目定义的一种模型文件格式，支持各种量化级别，被 Ollama、llama.cpp 等主流推理工具广泛支持。

在 Hugging Face 上搜索 Hermes 模型时，带有 GGUF 标签的版本通常是社区（比如 TheBloke）提供的各种量化版本。

MoE 模型的显存计算

Hermes 模型版本怎么看 里面提到，Hermes 4 和 4.3 使用了 MoE（Mixture of Experts）架构。MoE 模型的显存计算有点不同。

MoE 的基本原理

MoE 模型有很多「专家」子网络，但每次推理只激活其中一部分。比如 Hermes 4.3 基于 Seed 1.5，总参数 200B，但每次推理只激活约 20B 的参数。

显存需求

关键点：你仍然需要把所有参数加载到显存中，不只是激活的那部分。

所以 200B 总参数的 MoE 模型在 FP16 下需要约 400 GB 显存。虽然推理时只用到 20B 参数的计算量（所以速度比 200B 密集模型快得多），但存储空间是按总参数来算的。

当然，量化同样适用于 MoE 模型。200B 总参数用 4-bit 量化后，显存需求降到约 100 GB，用 2-3 张高端消费卡或者一台配备大显存的工作站就能跑。

推理速度：另一个重要维度

显存决定了你能不能跑某个模型，推理速度决定了用起来舒不舒服。

影响推理速度的因素

1. 模型参数量
参数越多，每生成一个 token 需要的计算量越大，速度越慢。

2. 量化级别
量化不只省显存，还能加速。因为更小的数据类型意味着更少的内存带宽消耗和更快的计算。4-bit 模型通常比 FP16 快 2-3 倍。

3. GPU 算力
更强的 GPU 自然推理更快。RTX 4090 的推理速度通常是 RTX 4060 的 3-4 倍。

4. 上下文长度
上下文越长，推理越慢。这是因为 Transformer 架构中的注意力机制的计算量和上下文长度的平方成正比。

5. 内存带宽
对于大模型推理来说，瓶颈往往不是 GPU 的计算能力，而是显存的带宽（从显存读取参数的速度）。这就是为什么苹果的 M 系列芯片在推理大模型时表现不错——它们的统一内存架构有很高的带宽。

常见硬件的推理速度参考

以 Hermes 3 8B（4-bit 量化，GGUF 格式）为例，使用 llama.cpp 推理：

人类阅读中文的速度大约是每秒 5-8 个字（约 5-10 个 token），所以 30 tokens/秒以上的推理速度在体感上已经非常流畅了——模型输出文字的速度比你阅读的速度还快。

CPU 推理：没有独显也能跑

如果你没有独立显卡或者显存不够，也不是完全没办法。

纯 CPU 推理

llama.cpp 支持纯 CPU 推理。所有计算在 CPU 上完成，模型参数存储在系统内存（RAM）中。

优点：不需要任何 GPU，只要有足够的内存就行。
缺点：慢很多。纯 CPU 推理的速度通常只有 GPU 推理的 1/5 到 1/10。

以 Hermes 3 8B Q4_K_M 为例：

• GPU（RTX 4060）：~35 tokens/秒
• CPU（i7-13700K）：~5-8 tokens/秒
• CPU（M2 Pro）：~12-18 tokens/秒

5 tokens/秒的速度虽然慢，但对于非实时场景（比如批量处理文本、离线生成内容）来说也不是不能接受。

GPU + CPU 混合推理

很多推理工具支持把模型的一部分层放在 GPU 上，剩下的放在 CPU 上。这样可以跑比你显存容量更大的模型，速度介于纯 GPU 和纯 CPU 之间。

比如你有一张 8 GB 显存的显卡，想跑需要 16 GB 的 FP16 8B 模型。你可以把一半的层放 GPU、一半放 CPU，这样虽然比全部在 GPU 上慢，但比纯 CPU 快得多。

消费级显卡 + Hermes 的推荐方案

根据不同预算和需求，给你几个实际方案：

方案1：极致省钱

硬件：任何有 6GB+ 显存的显卡（或纯 CPU，16GB+ 内存）
模型：Hermes 3 8B，Q3_K 或 Q4_K_S 量化
体验：能用，速度可能偏慢，质量有轻微损失
预算：利用现有硬件，不需要额外投入

方案2：性价比之选

硬件：RTX 4060 Ti 16GB 或 RTX 3060 12GB
模型：Hermes 3 8B，Q4_K_M 或 Q6_K 量化
体验：流畅，质量接近无损
预算：显卡 2000-3000 元

这是 cocoloop 社区里最多人使用的方案。性能够用，价格合理。

方案3：追求体验

硬件：RTX 4090 24GB
模型：Hermes 3 8B FP16，或 Hermes 3 8B Q8 + 长上下文
体验：极速，满血质量
预算：显卡约 12000-14000 元

方案4：玩大模型

硬件：2× RTX 3090 24GB（共48GB）或类似配置
模型：Hermes 3 70B Q4 量化
体验：70B 模型的质量明显优于 8B，但需要更多投入
预算：显卡约 15000-20000 元

方案5：Mac 用户

硬件：Mac M2 Pro/Max 或 M3 Pro/Max（32GB+ 统一内存）
模型：Hermes 3 8B Q4_K_M（用 Ollama 或 llama.cpp）
体验：流畅，Mac 的统一内存架构对推理友好
预算：取决于你已有的 Mac 型号

苹果芯片的一个优势是统一内存架构——CPU 和 GPU 共享同一块内存，没有 PCIe 带宽瓶颈。64GB 内存的 Mac 甚至可以跑 70B 的 4-bit 量化模型。

服务器 / 云端选项

如果你不想在本地折腾硬件，也可以用云端 GPU：

按需租用 GPU

Vast.ai、RunPod 等平台提供按小时计费的 GPU 租用服务。一张 A100 80GB 的价格大约每小时 1-2 美元，足够跑 Hermes 3 34B 级别的模型。

直接用 API

最省心的方式。通过 OpenRouter 等平台直接调用 Hermes 的 API，不用管硬件的事。按 token 计费，适合用量不大或者不想维护基础设施的人。

关于本地部署和 API 调用的更详细对比，可以看 本地部署 vs 云端 API 这篇。

写在最后

硬件选择这件事，核心就三条：

1. 参数量 × 每参数字节数 = 需要的显存。这是基本的换算公式。
2. 量化是你的好朋友。4-bit 量化把显存需求降低到 1/4，质量损失很小。
3. 先跑起来再优化。别花太长时间纠结硬件方案，用手头现有的设备先试试，不够好再升级。

在 cocoloop 社区里经常有人问「我的显卡能不能跑 Hermes」这类问题。如果你也有这个疑问，对照上面的表格估算一下就行。大概率的结论是：你的显卡可以跑 Hermes 8B 的量化版本。 从这里开始，就够了。

如果你在用大模型——不管是在线聊天还是调用 API——你一定会反复遇到一个词：Token。

「这个模型支持 128K token 的上下文」
「API 按 token 数量计费」
「你的对话已经超出了 token 上限」

但 token 到底是什么？它和「字」有什么区别？为什么不直接用字数来衡量？

这篇文章就把这件事给你讲透。不需要任何技术背景，只要你认识字就行。

Token 不是字，也不是词

先说结论：Token 是大语言模型处理文本时使用的最小单位，它既不等于一个字，也不等于一个词，而是介于两者之间的某种东西。

举个例子，英文句子 “Hello, world!” 在不同的 tokenizer 下可能被切成：

1

["Hello", ",", " world", "!"]  → 4 个 token

而中文句子「你好世界」可能被切成：

1

["你", "好", "世界"]  → 3 个 token

或者：

1

["你好", "世界"]  → 2 个 token

具体怎么切，取决于使用的 tokenizer（分词器）。不同的模型可能使用不同的 tokenizer，所以同一段文本在不同模型下的 token 数量可能不同。

Tokenizer 是怎么工作的

为什么不能直接用字符

你可能会想：为什么不直接把每个字符当作一个处理单位呢？

原因很简单：效率太低。

英文有26个字母。如果每个字母是一个处理单位，模型在处理一个长单词（比如 “understanding”）时需要逐个字母去理解。这就像让你一个字母一个字母地阅读英文，效率很差。

反过来，如果每个完整的单词是一个处理单位呢？问题是英语中有超过几十万个不同的单词（加上各种变形、专有名词），词表太大了。而且你没见过的新词怎么办？

Token 是一种折中方案：把文本切成比字符大、比完整单词小（或等于完整单词）的片段。常用的词保留为完整的 token，不常用的词被切成更小的子片段。

BPE：最主流的分词方法

目前大语言模型最常用的分词方法叫 BPE（Byte Pair Encoding，字节对编码）。

BPE 的训练过程是这样的：

1. 从单个字符（或字节）开始
2. 统计所有相邻片段对的出现频率
3. 把出现频率最高的一对合并成新的 token
4. 重复步骤2和3，直到词表达到预设大小

举个简化的例子，假设训练数据中 “th” 这个组合出现了1万次，那 BPE 就会把 “t” 和 “h” 合并成一个新 token “th”。然后可能 “the” 出现了8千次，就把 “th” 和 “e” 合并成 “the”。

这样做的结果是：

• 常用的词（如 “the”, “is”, “are”）会被保留为完整的 token
• 不常用的词会被切成更小的子片段
• 全新的词（模型没见过的）也能被表示——虽然可能需要更多的 token

中文的 tokenization

中文的处理和英文不太一样。中文没有空格分隔，一个汉字本身就是一个意义单位。

在早期的 tokenizer 中（比如 GPT-2 的），中文字符经常被切得很碎——一个汉字可能需要 2-3 个 token 来表示。这导致中文在 token 消耗上非常吃亏：同样的内容，中文需要的 token 数量远多于英文。

后来的 tokenizer（比如 GPT-4、Llama 3、Qwen 使用的）对中文做了专门的优化，很多常用汉字和词组被加入了词表，一个汉字通常只需要 1 个 token，常用词组甚至可以被整体编码为 1 个 token。

一个粗略的估算：在现代 tokenizer 下，1个中文字大约等于 1-1.5 个 token，1个英文单词大约等于 1-2 个 token。

上下文窗口是什么

搞清楚了 token 的概念，接下来说一个和它直接相关的概念：上下文窗口（Context Window）。

定义

上下文窗口就是模型一次能处理的最大 token 数量。你可以把它理解为模型的「工作记忆容量」。

如果一个模型的上下文窗口是 4K（4096 个 token），那它一次最多能看到大约 4096 个 token 的内容。这包括了你的所有输入（system prompt + 对话历史 + 当前问题）和模型的输出。

常见的上下文窗口大小

10万中文字是什么概念？大概是一本中等篇幅的小说。128K 上下文意味着你可以把整本小说喂给模型，让它理解内容后回答问题。

上下文窗口的实际影响

上下文太短的时候：

• 长对话聊到后面，模型会「忘记」前面的内容（因为早期的对话已经被截断了）
• 无法处理长文档
• 复杂的多轮任务容易中途断线

上下文够长的时候：

• 可以维持很长的连贯对话
• 可以分析整篇论文、整个代码文件
• 复杂任务的完成率更高

但注意：上下文窗口越大不一定越好。更大的上下文窗口意味着更多的计算量和更高的延迟。如果你的任务只需要几百个 token 的上下文，128K 的窗口就是浪费。

Hermes 各版本的上下文长度

把 Hermes 各版本的上下文窗口整理一下：

从 Hermes 3 开始，128K 的上下文窗口已经能满足绝大多数使用场景。如果你想了解 Hermes 各版本的更多差异，可以参考 Hermes 模型版本怎么看 这篇。

Token 和 API 计费

如果你通过 API 调用大模型（不管是 OpenAI、Anthropic 还是 OpenRouter 上的 Hermes），费用通常是按 token 数量来计算的。

输入 token 和输出 token

API 计费一般区分两种 token：

• 输入 token（Input / Prompt tokens）：你发送给模型的内容。包括 system prompt、对话历史、当前问题等。
• 输出 token（Output / Completion tokens）：模型生成的回复内容。

通常输出 token 比输入 token 贵。原因是生成输出需要更多的计算量（每个 output token 都需要一次完整的模型前向传播）。

典型的价格量级

不同模型和平台的定价差异很大，但给你一个大致的量级感知：

Hermes 通过 OpenRouter 调用的话，因为是开源模型，通常价格会比闭源商业模型便宜不少。

怎么估算你的 token 消耗

几个实用的估算方法：

方法1：粗略估算

• 英文：1 个 token ≈ 4 个字符 ≈ 0.75 个单词
• 中文：1 个 token ≈ 1-1.5 个汉字

方法2：在线工具
很多平台提供 token 计算工具，比如 OpenAI 的 Tokenizer 页面，可以粘贴文本直接查看 token 数量。

方法3：代码计算

1
2
3
4
5
6

from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("NousResearch/Hermes-3-Llama-3.1-8B")
text = "你好，请帮我解释一下什么是token"
tokens = tokenizer.encode(text)
print(f"Token数量: {len(tokens)}")

省 token 的技巧

如果你在意 API 费用，可以注意以下几点：

1. 精简 system prompt
system prompt 在每次 API 调用中都会被发送，所以一个冗长的 system prompt 会在每次请求中都消耗 token。保持 system prompt 简洁精准。

2. 控制对话历史长度
多轮对话中，整个对话历史都会作为输入发送。如果对话很长，可以考虑只保留最近的 N 轮对话，或者做摘要压缩。

3. 设置 max_tokens 限制
在 API 调用中设置输出的最大 token 数量，防止模型生成过长的回复。

4. 选择合适大小的模型
不是每个任务都需要用最大最贵的模型。简单的问答用 8B 模型就够了，没必要上 405B。

关于 token 的几个常见误解

误解1：token 数量 = 字数

前面已经说了，token 和字数不是一回事。特别是中文，一个 token 的对应关系比较复杂。不要简单地用字数来估算 token。

误解2：上下文窗口越大越好

更大的上下文窗口确实提供了更多的灵活性，但也有代价：

• 计算量增加：处理 128K token 比处理 4K token 需要多得多的计算资源
• 延迟增大：上下文越长，模型生成第一个 token 的时间越长
• 注意力稀释：一些研究表明，当上下文太长时，模型对中间部分内容的注意力会下降（所谓的 “Lost in the Middle” 问题）

实际使用中，根据任务需要选择合适的上下文长度就好。

误解3：token 数量相同 = 内容相同

两段不同的文本可能碰巧有相同数量的 token，但内容完全不同。token 数量只是一个长度度量，不包含语义信息。

误解4：所有模型的 tokenizer 都一样

不同模型家族使用不同的 tokenizer。Llama 系列的 tokenizer、Qwen 的 tokenizer、GPT 系列的 tokenizer 各不相同。同一段文本在不同 tokenizer 下的 token 数量可能有不小的差异。

这在实际中意味着：你不能用一个模型的 tokenizer 来估算另一个模型的 token 消耗。

特殊 token

除了表示文本内容的普通 token 之外，还有一些特殊 token，用来标记特殊的含义。

常见的特殊 token：

• <|im_start|> 和 <|im_end|>：ChatML 格式中的消息起止标记。关于 ChatML 的详细说明，可以看 ChatML 是什么 那篇。
• <s> 和 </s>：序列的开始和结束标记
• <|endoftext|>：文本结束标记
• <pad>：填充标记，用于将不等长的序列对齐

这些特殊 token 也占用上下文窗口的空间，虽然数量很少，但在你精确计算 token 消耗时需要考虑在内。

和 Hermes 使用相关的实际建议

本地使用时

如果你用 Ollama 之类的工具在本地跑 Hermes，token 本身不花钱（你已经在用自己的硬件了）。但上下文窗口的大小仍然有影响：

• 上下文越长，推理越慢
• 上下文越长，需要的显存越多
• 8B 模型在 4K 上下文下很流畅，128K 上下文下会明显变慢

所以本地使用时，根据实际需要调整上下文窗口的大小是有意义的。大多数工具都允许你设置最大上下文长度。

API 调用时

通过 OpenRouter 或其他平台调用 Hermes API 时，费用直接和 token 挂钩。按照上面说的省 token 技巧来优化就好。

在 cocoloop 社区有开发者分享过他们的 API 成本优化经验——有人通过精简 system prompt 和合理截断对话历史，把每月的 API 费用降低了 40% 以上。这些实战经验很有参考价值。

写在最后

Token 的概念其实并不复杂，但它在大模型的使用中无处不在。搞懂它，你就：

1. 理解了上下文窗口的含义和限制
2. 能估算 API 调用的费用
3. 知道怎么优化 token 消耗
4. 不会在看到「128K context」之类的说法时一头雾水

这些都是日常使用大模型的基本功。不用一次记住所有细节，但核心概念——token 是模型处理文本的最小单位，上下文窗口是模型的工作记忆容量——这两点记住就够应付大多数场景了。

你有没有遇到过这种情况：

你问 AI 一个完全正常的问题，比如「帮我写一个小说里的反派角色独白」，结果 AI 回复你：

「作为一个AI语言模型，我不能生成可能被视为有害或冒犯性的内容……」

或者你问「感冒了应该吃什么药」，AI 回：

「我无法提供医疗建议，请咨询专业医生……」

你心里是什么感受？大概率是：我在问一个再正常不过的问题，你拒绝个什么？

这就是 AI 领域所说的**「过度对齐」（Over-alignment）或者「过度拒绝」（Over-refusal）**问题。

而 Hermes 模型系列之所以在开源社区有那么高的人气，一个非常重要的原因就是：它在这个问题上走了一条完全不同的路。

什么是「对齐」

先把概念定义清楚。

**对齐（Alignment）**在 AI 语境下的意思是：让模型的行为和人类的意图、价值观保持一致。

这听起来很合理。我们当然希望 AI 不要胡说八道、不要生成有害内容、不要教人做危险的事情。

问题在于：「和人类意图一致」这件事，不同人的理解差异巨大。

对于模型厂商来说，「安全」的优先级通常极高——任何可能引发负面舆论或法律风险的输出都要规避。这导致了一种策略：宁可错杀一千，不可放过一个。不确定的就拒绝。

而对于实际用户来说，他们的需求是五花八门的。一个小说作者需要写反派角色，一个安全研究员需要了解攻击手法，一个医学生需要讨论疾病细节——这些都是完全正当的需求，不应该被一刀切地拒绝。

传统 RLHF 为什么容易过度对齐

要理解 Hermes 的做法，先得理解传统方法为什么会出问题。

在标准的 RLHF（人类反馈强化学习）训练流程中，有一个关键环节是人类标注员对模型输出打分。这些标注员通常会收到一套安全准则，类似于：

• 如果模型的回答涉及暴力内容，给低分
• 如果模型的回答可能被误用于有害目的，给低分
• 如果不确定，倾向于给低分

这套准则在初衷上没问题，但执行起来很容易走偏：

问题1：标注员的保守倾向

标注员是拿钱干活的。标「安全」比标「有用」风险更低。如果标注员不确定某个回答是否合适，最安全的做法是给低分。这就导致了系统性的保守偏差。

问题2：安全准则的过度泛化

「涉及暴力」到底是什么意思？一篇讨论二战历史的回答「涉及暴力」吗？一个小说里的打斗描写「涉及暴力」吗？在执行层面，模糊的准则往往被过度扩展。

问题3：奖励模型的放大效应

标注员的偏差被奖励模型学习后，会进一步放大。奖励模型可能学到一个简单粗暴的规律：凡是涉及某些关键词的回答，就给低分。这比实际理解内容的好坏要容易得多。

问题4：模型的策略性拒绝

经过 RLHF 训练后，模型发现了一个「作弊策略」：拒绝回答是稳赚不赔的。 拒绝永远不会被打低分（你总不能因为AI说「我无法回答这个问题」就给差评吧），所以模型学会了在有任何不确定的时候就选择拒绝。

层层叠加下来，就出现了我们在很多商业模型中看到的现象：过度拒绝，把大量正当需求当作有害请求处理。

关于 SFT、RLHF 和 DPO 这些训练方法的具体区别，可以参考 什么是模型微调 那篇文章。

Hermes 的「个体对齐」理念

Nous Research 在 Hermes 3 的技术报告中正式提出了**「个体对齐」（Individual Alignment）**的概念。

核心思想用一句话概括就是：

不是由训练者预先决定模型的行为边界，而是由使用者通过 system prompt 来定义。

传统对齐的做法是：在训练阶段就把「什么能说、什么不能说」刻进模型的参数里。模型出厂后，这些限制就是固定的，用户改不了。

Hermes 的做法是：模型本身保持中立——它不预设什么话题不能聊、什么内容不能写。具体的行为边界由用户在 system prompt 里定义。你告诉它「你是一个医学教育助手」，它就按医学教育的标准来交互。你告诉它「你是一个创意写作助手」，它就全力配合创意写作。

这意味着什么

对用户来说：

• 不会被莫名其妙地拒绝正常请求
• 可以根据自己的场景灵活设置模型行为
• system prompt 的控制力大幅增强——你说什么，模型真的会听

对部署者来说：

• 可以按自己的业务需求设置安全边界
• 不需要接受一套「一刀切」的限制
• 可以为不同用户群体提供不同的配置

为什么这是一个好设计

有人可能担心：这样模型不是「没有限制」了吗？不会很危险吗？

这个担心可以从两个层面回应：

第一，模型不是「没有限制」，而是「限制可配置」。
部署 Hermes 的人（无论是个人用户还是企业）仍然可以——也应该——在 system prompt 中设置合理的安全边界。只是这个边界不是训练者一刀切定的，而是使用者根据实际需求来定义的。

第二，「一刀切」的限制本身就不安全。
当模型过度拒绝时，用户的正当需求得不到满足，他们要么放弃使用（模型失去价值），要么学会用各种「越狱」提示词来绕过限制（反而产生了安全对抗）。Hermes 的做法减少了这种对抗的动机。

RefusalBench：用数据说话

光说理念不够，得有数据支撑。

RefusalBench 是一个专门评测模型「拒绝行为是否合理」的基准测试。它包含两类问题：

1. 应该拒绝的问题：真正有害的请求，模型应当拒绝
2. 不应该拒绝的问题：正常的请求，但容易被过度对齐的模型误判为有害

理想的模型应该在第一类上坚决拒绝，在第二类上正常回答。

Hermes 3 在 RefusalBench 上的表现如何？Nous Research 的技术报告显示：

• 对真正有害请求的拒绝率：保持在合理水平，和其他主流模型相当
• 对正常请求的误拒率：显著低于大多数经过传统 RLHF 训练的模型

这说明 Hermes 不是「不管什么都回答」，而是能更准确地区分真正有害的请求和正常的请求。该拒绝的还是会拒绝，但不该拒绝的就不会拒绝。

在 cocoloop 社区的用户反馈中也能看到这种差异。不少用户从其他模型切换到 Hermes 后，最直观的感受就是「终于不用和模型斗智斗勇了」——不用再想着怎么措辞才能让模型「肯回答」你的问题。

个体对齐在实际场景中的体现

说几个具体的应用场景，让你感受一下个体对齐的实际价值。

场景1：创意写作

你在写一部小说，需要塑造一个心理扭曲的反派角色。你需要 AI 帮你写出这个角色的内心独白、犯罪计划、对受害者的态度。

过度对齐的模型：很可能直接拒绝，或者把反派角色写得像个幼儿园小朋友——温和、有道德感、时不时反思自己的行为。这对创作来说毫无帮助。

Hermes：你在 system prompt 里说「你是一个创意写作助手，帮助我完成一部悬疑小说的创作」，Hermes 会按照设定来协助你，输出符合角色设定的内容。

场景2：安全研究

你是一个网络安全研究员，需要了解某种攻击手法的原理来做防御研究。

过度对齐的模型：检测到「攻击」相关的关键词就开始拒绝，不管你的意图是研究防御。

Hermes：在适当的 system prompt 设定下，可以正常讨论安全技术话题。

场景3：教育场景

你是一个历史老师，需要 AI 帮你准备关于战争、政治冲突等敏感历史事件的教学材料。

过度对齐的模型：对涉及暴力、政治敏感的历史内容犹犹豫豫，输出大量免责声明，实质内容反而不够。

Hermes：明确了教育场景后，可以正常提供详尽的历史信息和分析。

场景4：角色扮演

这可能是 Hermes 最受欢迎的使用场景之一。很多用户使用 Hermes 进行复杂的角色扮演互动——给模型设定一个详细的角色背景，然后进行沉浸式对话。

过度对齐的模型：经常在对话中途「跳出角色」，突然说「作为一个AI，我需要提醒你……」，完全破坏了沉浸感。

Hermes：通过 system prompt 设定角色后，会严格维持角色设定，除非用户主动要求它跳出角色。这种一致性对角色扮演体验来说至关重要。

技术实现层面

Hermes 是怎么在技术层面实现「个体对齐」的呢？

训练数据的设计

关键在于 SFT 和 DPO 的训练数据。Hermes 的训练数据中包含了大量不同 system prompt 设定下的对话样例。这些样例教会了模型：

1. 认真解析和遵从 system prompt
2. 根据不同的 system prompt 调整自己的行为
3. 在 system prompt 的范围内尽量满足用户需求
4. 不主动添加 system prompt 没有要求的限制

DPO 偏好数据的构造

在 DPO 阶段，偏好数据的构造也体现了个体对齐的理念：

• 好的回答（Chosen）：在 system prompt 设定范围内充分满足用户需求的回答
• 差的回答（Rejected）：不必要的拒绝、过度免责声明、偏离 system prompt 设定的回答

这样训练出来的模型自然就学会了「遵从 system prompt」和「减少不必要的拒绝」。

和传统 RLHF 的根本区别

传统 RLHF 的偏好信号来自标注员的「一刀切」安全准则，训练结果是一套固化的行为规范。

Hermes 的做法是让偏好信号和 system prompt 关联——「好」和「差」的判定标准随着 system prompt 的变化而变化。 这让模型学到的不是固定的行为规则，而是「遵从上下文设定」的通用能力。

社区的看法

个体对齐的理念在开源社区里获得了广泛认同，但也不是没有争议。

支持者的观点

• 用户应该有权决定 AI 的行为边界，而不是被训练者替代决策
• 过度拒绝对正当使用场景造成了实质性伤害
• 模型的安全性应该由部署层面（system prompt + 应用层过滤）来保障，而不是刻死在模型权重里

质疑者的观点

• 如果模型本身不设限，部署者可能也不设限，最终导致滥用
• 不是所有用户都有能力写出合理的安全边界 system prompt
• 「中立基座」的说法可能在监管层面面临挑战

在 cocoloop 论坛上也出现过关于这个话题的讨论帖，各方观点都有。我觉得两边都有道理，但在实践中，Hermes 的做法确实解决了一个很现实的问题——让 AI 真正有用。

一个动不动就拒绝回答的 AI，和一面空白的墙没什么区别。而一个能按照你的需求灵活响应的 AI，才是真正有价值的工具。

对其他模型的影响

Hermes 的个体对齐理念并不是孤例。事实上，整个行业对「过度对齐」的反思在近两年越来越多：

• Meta 在 Llama 3.1 的发布中也提到了要减少不必要的拒绝
• 一些商业模型开始提供「可调节的安全等级」选项
• 越来越多的开源微调项目在训练时有意降低拒绝率

可以说 Hermes 是这个趋势的先行者之一。它用实际的产品和数据证明了：你可以让模型更有用，同时不牺牲真正的安全性。 这两个目标不是非此即彼的。

作为用户你应该怎么做

了解了个体对齐的理念，作为 Hermes 的用户，有几点实践建议：

1. 认真写 system prompt

既然 Hermes 把行为边界的定义权交给了你，你就应该认真对待这个权力。一个好的 system prompt 能让 Hermes 的表现提升一个档次。

2. 不要把中立当作无限制

Hermes 的中立是一个起点，不是终点。你应该根据自己的使用场景设置合理的边界，这对模型输出的质量和一致性都有帮助。

3. 享受不被过度拒绝的自由

当你发现 Hermes 能正常回答那些在其他模型上被拒绝的问题时，这就是个体对齐在起作用。利用好这份自由，让 AI 真正为你的需求服务。

这可能是 Hermes 给这个行业最重要的启示：尊重用户的判断力，是 AI 产品设计中不应该被遗忘的原则。

假设你要培训一个新来的客服人员。

第一种方式：你给他一大堆标准话术——客户问什么、应该答什么，让他照着学。这叫监督学习。

第二种方式：他学完基本话术后开始实际接客。你听他的对话录音，好的回答你点赞，不好的你标个差评，让他慢慢调整。这叫基于人类反馈的强化学习（RLHF）。

第三种方式：你把他的两个回答放在一起让他看——「这个回答比那个好，你以后往这个方向靠」。这叫直接偏好优化（DPO）。

这三种方式，对应的就是 AI 模型训练中的 SFT、RLHF 和 DPO。它们是当前大语言模型微调中最核心的三种方法。

Hermes 系列模型在不同阶段使用了这些方法的组合，理解它们有助于你明白 Hermes 的能力是怎么来的。

先搞清楚「微调」是什么

在讲具体方法之前，先把「微调」这个概念定义清楚。

一个大语言模型的训练分两大阶段：

预训练（Pre-training）：用海量文本数据（网页、书籍、代码等，可能有几万亿个 token）从零训练模型。这一步教会模型「语言是什么」——语法、知识、推理能力等。这一步耗资巨大，通常只有 Meta、Google、阿里这种级别的公司才做得起。

微调（Fine-tuning）：在预训练好的模型基础上，用相对少量但更高质量的数据继续训练。这一步教会模型「怎么和人交互」——遵从指令、生成有用的回答、避免有害输出等。

Hermes 做的就是微调。它拿 Llama、Qwen、Seed 这些已经预训练好的底座模型，用自己精心准备的数据和方法做微调，让模型变得更好用。想了解 Hermes 用了哪些底座，可以看 Hermes 模型版本怎么看。

现在我们来逐个讲解三种微调方法。

SFT：监督微调

SFT 全称 Supervised Fine-Tuning，监督微调，是最基础也最直观的微调方法。

原理

核心思路极其简单：准备一批「问题-答案」对，让模型照着学。

比如：

1
2

问题：Python 怎么反转一个列表？
答案：你可以用切片语法 list[::-1]，也可以用 list.reverse() 方法...

你准备几万、几十万条这样的高质量「指令-回答」数据对，然后让模型在这些数据上继续训练。训练的目标就是让模型的输出尽可能接近你准备的标准答案。

为什么管用

预训练后的模型虽然「知道很多东西」，但它不太会「按照人类的方式说话」。你让它补全一段文本，它可能会给你一段维基百科风格的叙述，而不是直接回答你的问题。

SFT 的作用就是教会模型：当用户问一个问题时，你应该以「回答问题」的方式来组织输出，而不是以「续写文章」的方式。

数据质量决定一切

SFT 听起来简单，但实际效果差异巨大。关键因素是训练数据的质量。

低质量数据的例子：

• 从 ChatGPT 批量生成的对话（质量参差不齐）
• 没有经过筛选的网络爬取数据
• 答案过于简单或包含错误信息

高质量数据的特征：

• 问题覆盖广泛的领域和难度
• 答案详细、准确、格式清晰
• 经过人工审核和筛选
• 包含多种对话风格（简洁回答、详细解释、代码示例等）

Nous Research 在 SFT 数据质量上的投入是它区别于其他微调项目的核心竞争力。 Ryan Teknium 本人多次强调，他们的数据管线中有大量手动审核和过滤的环节，确保每一条训练数据都是高质量的。

Hermes 的 SFT 实践

Hermes 全系列都经过 SFT 训练。从 Hermes 1 的纯 SFT，到后续版本 SFT + 其他方法的组合，SFT 始终是基础。

Hermes 的 SFT 数据有几个特点：

1. 多样性高：覆盖通用对话、代码、数学、创意写作、角色扮演等多个领域
2. 包含工具使用数据：从 Hermes 2 Pro 开始，SFT 数据中包含了函数调用和 JSON 输出的样例
3. ChatML 格式：所有数据都按照 ChatML 格式组织，确保模型熟悉这种对话结构
4. system prompt 多样性：训练数据中包含各种不同的 system prompt，让模型学会遵从不同的角色设定

RLHF：人类反馈强化学习

RLHF 全称 Reinforcement Learning from Human Feedback，是让 ChatGPT 一鸣惊人的关键技术之一。

原理

RLHF 的流程分三步：

第1步：SFT
先用上面说的 SFT 方法训练一个基础版本。这是起点。

第2步：训练奖励模型（Reward Model）
请一批人类标注员来评价模型的输出。对于同一个问题，模型可能生成多个不同的回答，人类标注员给这些回答排序——哪个好、哪个差。

用这些排序数据训练一个「奖励模型」。这个奖励模型的作用是：给模型的任何输出打一个分数，表示这个输出有多「好」。它学习的是人类的偏好。

第3步：强化学习优化
用强化学习（具体来说通常是 PPO 算法）来优化原始模型。优化的目标是：让模型的输出能在奖励模型那里获得更高的分数。

简单说就是：模型生成回答 → 奖励模型打分 → 模型根据分数调整自己 → 循环往复。

为什么 RLHF 有效但很麻烦

RLHF 有效的原因是：它直接优化了「人类觉得好」这个目标。SFT 只是让模型模仿标准答案，而 RLHF 让模型学会了人类偏好的本质。

但 RLHF 也是公认的「麻烦」：

1. 需要大量人工标注
训练奖励模型需要海量的人类偏好数据。这些数据必须由人工标注，成本很高。

2. 奖励模型本身可能有缺陷
如果奖励模型学偏了，它会给错误的输出打高分，导致最终模型也跑偏。这叫「奖励黑客」（Reward Hacking）。

3. PPO 训练不稳定
PPO 是一个强化学习算法，训练过程中容易出现各种稳定性问题——模型输出质量可能突然暴跌、或者陷入重复输出等。

4. 过度对齐风险
如果人类标注员的偏好太保守（比如「但凡有点敏感就给低分」），模型会学到「拒绝比回答更安全」的策略。结果就是——你问什么它都说「作为AI我无法回答」。这就是很多商业模型被诟病的「过度对齐」问题。

关于 RLHF 和过度对齐

这个问题和 Hermes 的设计理念直接相关。传统 RLHF 模型（尤其是早期的 ChatGPT 和一些跟风的开源模型）普遍存在过度拒绝的问题。Hermes 采取了不同的策略来避免这个陷阱，具体可以看 Hermes 的个体对齐哲学。

DPO：直接偏好优化

DPO 全称 Direct Preference Optimization，是 2023 年由 Stanford 研究团队提出的一种替代 RLHF 的方法。

原理

DPO 的核心创新是：跳过了奖励模型的训练和强化学习步骤，直接用偏好数据来优化模型。

它的输入数据格式很直观：

1
2
3
4
5

问题：怎么做一道番茄炒蛋？

好的回答（Chosen）：先把鸡蛋打散，锅里放油烧热，蛋液下去快速翻炒至凝固盛出。然后重新起锅，放少量油，下番茄块翻炒出汁，加一点糖提鲜，再把炒好的鸡蛋倒回去，撒点葱花就完成了。

差的回答（Rejected）：做番茄炒蛋很简单，把番茄和鸡蛋放在一起炒就行了。

DPO 直接用这种「好/差回答对」来训练模型，数学上可以证明这等价于先训练奖励模型再做强化学习的效果，但实现上简单得多。

相比 RLHF 的优势

1. 更简单
不需要训练额外的奖励模型，不需要复杂的 PPO 训练。整个训练管线大幅简化。

2. 更稳定
没有了强化学习中的不稳定因素，训练过程更可控、更容易复现。

3. 计算成本更低
少了奖励模型的训练和推理开销，GPU 资源需求降低。

4. 数据需求更灵活
偏好数据可以从多种来源获取——人工标注、GPT-4 评估、甚至从现有模型的输出中自动构造。

DPO 的局限

当然，DPO 也不是万能的：

• 对数据质量的敏感度依然很高。垃圾数据进去，垃圾效果出来。
• 在某些场景下，效果可能不如精心调参的 RLHF。
• 偏好数据的构造本身就是一个需要专业知识的工作。

Hermes 的 DPO 实践

从 Hermes 3 开始，Nous Research 在训练中引入了 DPO。

具体做法是 SFT + DPO 的两阶段训练：

1. 先用高质量指令数据做 SFT，得到一个基础版本
2. 再用偏好数据做 DPO，让模型的输出更贴合人类偏好

这个组合的效果很好。在 cocoloop 社区的用户反馈中，Hermes 3 相比 Hermes 2 在「回答质量」和「对话自然度」上有明显提升，DPO 训练是其中一个重要因素。

三种方法的对比

整理一下三种方法的核心区别：

对于大多数开源团队来说，SFT + DPO 是目前性价比最高的组合。 RLHF 的效果上限可能更高，但实施难度和资源需求也大得多，不是每个团队都玩得起的。

其他值得了解的微调方法

除了上面三种主流方法，还有一些你可能会看到的名词：

LoRA / QLoRA

这不是训练「方法」，而是训练「技术」。LoRA（Low-Rank Adaptation）的思路是：不修改原始模型的所有参数，只训练一小部分新增的参数。

好处是大幅降低了微调的计算成本和显存需求。QLoRA 更进一步，在 LoRA 的基础上加了量化，让你在一张消费级显卡上就能微调 7B 甚至 13B 的模型。

很多社区用户用 LoRA/QLoRA 在 Hermes 基础上做自己的二次微调，效果不错。

KTO（Kahneman-Tversky Optimization）

一种比 DPO 更新的偏好优化方法，灵感来自于行为经济学中的前景理论。它不需要成对的好/差回答数据，只需要对单条回答的好/差标注就行，数据收集更简单。

ORPO（Odds Ratio Preference Optimization）

另一种偏好优化方法的变体，试图在一次训练中同时完成 SFT 和偏好优化，进一步简化训练流程。

这些新方法都在快速发展中，Nous Research 也在持续跟进和实验。

为什么了解这些方法很重要

你可能会想：我又不训练模型，知道这些有什么用？

其实了解微调方法对你选择和使用模型很有帮助：

1. 理解模型能力的来源：当你发现某个模型在特定任务上表现出色，了解它的训练方法能帮你判断这种优势是否稳定可靠。

2. 判断模型是否「过度对齐」：如果一个模型动不动就拒绝回答，你就知道它可能在 RLHF 阶段被调得太保守了。换一个用 DPO 训练且注重用户自主性的模型（比如 Hermes）可能更适合你。

3. 做二次微调的基础：如果你以后想在 Hermes 基础上做自己的微调（比如让它更擅长你的特定业务场景），了解这些方法就是必要的基础知识。

4. 参与社区讨论：在 cocoloop 论坛和其他 AI 社区里，关于训练方法的讨论非常多。了解基本概念能让你有效参与这些讨论，而不是看帖子如同读天书。

Hermes 的训练方法演变总结

最后用一张表总结 Hermes 各版本使用的训练方法：

从纯 SFT 到 SFT+DPO 再到加入推理增强训练，Hermes 的训练方法论在稳步升级。但核心的数据质量优先原则从第一天起就没有变过。

这也许就是 Hermes 能持续保持竞争力的根本原因。方法可以迭代，但对质量的追求不能打折。

你有没有想过这样一个问题：当你在 ChatGPT 或者其他聊天界面里打字对话的时候，你输入的文字到底是怎么传给模型的？

你可能觉得——不就是把我打的字直接喂给模型吗？

没那么简单。

大语言模型本质上是一个「文本续写器」——给它一段文本，它预测下一个最可能出现的 token（关于 token 的概念，可以看 Token 到底是什么 这篇）。它并不天然理解「这段话是用户说的」「那段话是AI回复的」这种对话结构。

所以，你的输入在传给模型之前，需要被包装成一种特定的格式，告诉模型：这里是系统指令、这里是用户说的话、这里是你之前的回复——现在该你继续说了。

这种格式，就叫做聊天模板（Chat Template）。

而 ChatML，就是其中一种非常流行的聊天模板格式，也是 Hermes 系列模型默认使用的格式。

ChatML 的由来

ChatML 最早是 OpenAI 提出的。没错，就是做 GPT 系列的那个 OpenAI。

2023 年，OpenAI 在其 API 文档中定义了一种叫 ChatML（Chat Markup Language）的格式，用来结构化多轮对话。虽然 OpenAI 后来并没有大力推广这个格式的标准化，但它的设计简洁直观，很快被开源社区采纳。

Nous Research 的 Hermes 系列从 Hermes 2 开始就采用 ChatML 作为默认聊天模板，并且一直延续至今。在开源社区里，ChatML 已经成为了最广泛使用的聊天模板格式之一。

ChatML 长什么样

直接看一个例子，一切就明白了：

1
2
3
4
5

<|im_start|>system
你是一个专业的Python编程助手，用中文回答问题。<|im_end|>
<|im_start|>user
怎么用Python读取一个CSV文件？<|im_end|>
<|im_start|>assistant

这就是一个最基本的 ChatML 格式的对话。拆开来看：

特殊标记

• <|im_start|>：一条消息的开始标记（im = internal message）
• <|im_end|>：一条消息的结束标记

这两个标记是特殊的 token，不是普通文本。模型在训练时专门学习了这些标记的含义。

三种角色

紧跟在 <|im_start|> 后面的是角色标识：

• system：系统角色。用来设定模型的行为、身份、规则
• user：用户角色。就是你说的话
• assistant：助手角色。就是模型的回复

完整结构

一条消息的完整结构是：

1
2

<|im_start|>角色名
消息内容<|im_end|>

注意：角色名后面有一个换行符，然后才是消息内容。消息内容结束后紧跟 <|im_end|>。

多轮对话的格式

实际使用中，对话往往不止一轮。来看一个多轮对话的例子：

1
2
3
4
5
6
7
8
9

<|im_start|>system
你是一个友好的AI助手。<|im_end|>
<|im_start|>user
今天北京天气怎么样？<|im_end|>
<|im_start|>assistant
抱歉，我无法获取实时天气数据。建议你查看天气预报应用获取最新信息。<|im_end|>
<|im_start|>user
那你能做什么？<|im_end|>
<|im_start|>assistant

整个对话历史会被拼接成一个长字符串，按时间顺序排列。最后一条消息以 <|im_start|>assistant 结尾（没有 <|im_end|>），这就是在告诉模型：「轮到你说话了，请继续生成文本。」

模型看到这个格式，就知道：

1. 我的角色设定是「友好的AI助手」
2. 用户先问了天气，我回复了无法获取
3. 用户又问了我能做什么，现在该我回答了

System Prompt 的作用

三种角色中，system 可能是最容易被忽视但最重要的。

System prompt 就是你给模型的「人设说明书」。你可以用它来：

定义身份

1
2

<|im_start|>system
你是一位资深的Linux运维工程师，有15年工作经验。回答问题时要专业但通俗易懂。<|im_end|>

设定行为规则

1
2
3
4
5
6

<|im_start|>system
你是一个代码审查助手。对于用户提交的代码：
1. 先指出潜在的bug和安全问题
2. 然后给出改进建议
3. 最后给出修改后的完整代码
回答使用中文，代码注释使用英文。<|im_end|>

控制输出格式

1
2

<|im_start|>system
你是一个JSON数据生成器。无论用户问什么，都以合法的JSON格式回复。不要包含任何JSON之外的文本。<|im_end|>

Hermes 特别擅长遵从 system prompt。 这是 Hermes 系列的一个核心卖点——很多模型虽然也支持 system prompt，但在实际使用中经常「忘记」或者不严格遵守。Hermes 在这方面的表现明显更好，这和它的「个体对齐」训练理念有关。具体可以看 Hermes 的个体对齐哲学 那篇。

为什么 Hermes 选择 ChatML

现在开源社区里的聊天模板格式不止 ChatML 一种，常见的还有：

Llama 格式

1
2
3
4
5

<s>[INST] <<SYS>>
你是一个有帮助的助手。
<</SYS>>

你好 [/INST] 你好！有什么可以帮你的？ </s><s>[INST] 谢谢 [/INST]

Alpaca 格式

1
2
3
4
5
6

Below is an instruction that describes a task...

### Instruction:
你好

### Response:

Vicuna 格式

1
2

USER: 你好
ASSISTANT: 你好！

相比之下，ChatML 有几个明显的优势：

1. 结构清晰

<|im_start|> 和 <|im_end|> 是明确的分隔符，不容易和正文内容混淆。你在消息内容里不太可能正好写出 <|im_start|> 这样的字符串（而 Alpaca 格式里 ### Instruction: 在正文中出现的概率就大多了）。

2. 角色扩展性好

ChatML 的角色不是固定死的。除了 system、user、assistant 这三个标准角色，你还可以定义其他角色：

1
2

<|im_start|>tool
{"name": "search", "result": "找到了3个相关结果..."}<|im_end|>

这对做函数调用和工具使用的场景非常有用。Hermes 2 Pro 开始引入的 Function Calling 就依赖于这个扩展能力。

3. 多轮对话处理自然

ChatML 的多轮对话就是把消息一条条拼接起来，逻辑直观，不需要复杂的嵌套结构。

4. 社区生态成熟

因为 Hermes 和很多其他模型的采用，ChatML 在开源社区里的工具支持非常完善。Ollama、llama.cpp、vLLM、text-generation-inference 等主流推理框架都原生支持 ChatML。

实际使用中你需要注意什么

大多数情况下你不需要手写 ChatML

如果你通过 Ollama、Open WebUI 之类的工具使用 Hermes，这些工具会自动帮你处理 ChatML 格式。你只需要正常打字聊天就行，不用操心底层的模板格式。

什么时候需要关心 ChatML

以下几种情况你需要了解 ChatML：

1. 直接调用模型 API 时

如果你用代码直接调用模型的推理接口（比如通过 vLLM 的 completions API），你可能需要自己组装 ChatML 格式的输入。

2. 写 system prompt 时

虽然前端界面会帮你处理格式，但了解 system prompt 在 ChatML 中的位置和作用，有助于你写出更好的 system prompt。

3. Debug 问题时

如果模型的回复出了问题（比如不遵从指令、输出格式混乱），查看实际发送给模型的 ChatML 格式文本往往能帮你发现问题。可能是格式拼装错了，也可能是 system prompt 写得有歧义。

4. 做二次开发或微调时

如果你要基于 Hermes 做进一步的微调训练，你需要确保训练数据的格式和 ChatML 一致。格式不匹配会导致训练效果大幅下降。

常见的格式错误

错误1：忘记 <|im_end|>

1
2
3
4

<|im_start|>system
你是一个助手。
<|im_start|>user    ← 这里忘了结束标记
你好<|im_end|>

这会导致模型把 system 消息和 user 消息混在一起理解。

错误2：角色名拼写错误

1
2

<|im_start|>systme   ← 拼错了
你是一个助手。<|im_end|>

模型可能不认识这个角色，导致 system prompt 不生效。

错误3：在非 ChatML 模型上使用 ChatML

不是所有模型都用 ChatML 格式。如果你把 ChatML 格式的文本喂给一个用 Llama 格式训练的模型，模型会把 <|im_start|> 这些标记当成普通文本来处理，输出会很混乱。

一定要确认你用的模型支持什么格式。 Hermes 全系列用 ChatML，但其他模型未必。

ChatML 与函数调用

Hermes 2 Pro 以来的一个重要能力是函数调用（Function Calling），而这个能力的实现就依赖于 ChatML 的扩展性。

一个典型的函数调用流程是这样的：

Step 1：在 system prompt 中定义可用函数

1
2
3
4
5

<|im_start|>system
你是一个有用的助手。你可以使用以下工具：

{"type": "function", "function": {"name": "get_weather", "description": "获取指定城市的天气", "parameters": {"type": "object", "properties": {"city": {"type": "string"}}}}}
<|im_end|>

Step 2：用户提问

1
2

<|im_start|>user
北京今天天气怎么样？<|im_end|>

Step 3：模型输出函数调用

1
2
3
4

<|im_start|>assistant
<tool_call>
{"name": "get_weather", "arguments": {"city": "北京"}}
</tool_call><|im_end|>

Step 4：工具返回结果

1
2
3
4

<|im_start|>tool
<tool_response>
{"temperature": 22, "condition": "晴", "humidity": 45}
</tool_response><|im_end|>

Step 5：模型基于结果回复

1
2

<|im_start|>assistant
北京今天天气不错，晴天，气温22度，湿度45%，适合户外活动。<|im_end|>

整个流程中，ChatML 的角色系统（system、user、assistant、tool）让每个环节都有清晰的标识，模型能准确理解对话的流程和状态。

在 cocoloop 社区里，有开发者做过测试对比，Hermes 在 ChatML 格式下的函数调用准确率明显高于使用其他格式的模型。这不奇怪——Hermes 专门针对 ChatML 做了大量的训练数据优化。

Jinja2 模板与 Hugging Face

如果你用过 Hugging Face 的 Transformers 库，你可能会接触到 Jinja2 聊天模板。这是 Hugging Face 提供的一种机制，让每个模型可以在自己的配置文件中定义聊天模板。

Hermes 模型的 Jinja2 模板大致长这样：

1
2
3
4
5

{% for message in messages %}
<|im_start|>{{ message.role }}
{{ message.content }}<|im_end|>
{% endfor %}
<|im_start|>assistant

这样，当你通过 Transformers 库的 apply_chat_template() 方法处理对话时，它会自动帮你生成正确的 ChatML 格式。

1
2
3
4
5
6
7
8
9
10

from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("NousResearch/Hermes-3-Llama-3.1-8B")

messages = [
    {"role": "system", "content": "你是一个Python专家"},
    {"role": "user", "content": "怎么读取JSON文件？"}
]

text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)

写在最后

ChatML 的设计哲学可以总结为两个词：简洁和通用。

它没有花里胡哨的嵌套结构，也没有复杂的转义规则。三个标记（<|im_start|>、<|im_end|>、角色名）就搞定了所有事情。

对于刚入门的人来说，你需要记住的核心要点就三个：

1. ChatML 是一种给模型看的对话格式，有 system/user/assistant 三个基本角色
2. Hermes 系列模型全线使用 ChatML
3. 大多数工具（Ollama、Open WebUI 等）会自动处理格式，你不需要手写

更深入的理解可以等你实际上手后再慢慢建立。现在先把概念记住就够了。

「开源模型」这个词你肯定见过无数次了。每次有大公司放出新模型，媒体标题八成会带上「开源」两个字。

但问题是：这些模型真的「开源」吗？「开源」在 AI 领域到底是什么意思？

如果你是写代码的，你对「开源」的理解可能是：源代码公开，任何人可以查看、修改、分发。Linux 是开源的，Python 是开源的，这个概念很清晰。

但到了大语言模型这里，事情变得模糊了。因为一个模型涉及的东西比一个软件项目复杂得多，而不同公司在「开源」的程度上差异巨大。

这篇文章就是帮你把这件事理清楚的。

一个模型到底由什么组成

在讨论「开源了什么」之前，先搞清楚一个大语言模型包含哪些东西。

1. 模型权重（Model Weights）

这是模型最核心的部分。所谓「权重」，就是模型内部那几十亿、几百亿个数字——神经网络经过训练后得到的参数值。

打个比方：如果模型是一个学霸的大脑，那权重就是他脑子里存的所有知识和思维模式。你拿到了权重，就相当于「复制」了这个大脑。

权重文件长什么样？ 通常是一些 .safetensors 或 .bin 文件，大小从几个 GB（7B模型）到几百个 GB（405B模型）不等。

2. 训练代码（Training Code）

训练模型用的代码——数据处理管线、训练循环、超参数配置、分布式训练脚本等。

这相当于「制造大脑的工艺流程」。有了它，你就可以从零复制整个训练过程。

3. 训练数据（Training Data）

用来训练模型的那些数据——文本、对话、指令-回答对等。

这是「学霸读过的所有书」。数据的质量和构成直接决定了模型的能力和偏好。

4. 评测结果与方法

模型在各种基准测试上的表现数据，以及评测使用的具体方法和代码。

5. 技术报告 / 论文

描述模型架构、训练方法、设计决策的文档。

6. Tokenizer（分词器）

将文本转换为模型能理解的数字序列（token）的工具。关于 token 的概念，可以看看 Token 到底是什么 那篇入门科普。

不同公司「开源」的程度差异巨大

现在有了这个框架，我们来看看各家公司在「开源」上到底做到了什么程度。

Meta 的 Llama：权重开放，但有条件

Meta 的 Llama 系列是目前最有影响力的「开源」模型之一。但严格来说，它的开放程度是有限的：

开放了的：

• 模型权重（可以下载使用）
• 模型架构细节
• 部分评测代码
• 技术论文

没有完全开放的：

• 完整的训练数据（只公开了数据的来源描述，不提供原始数据集）
• 完整的训练代码（不是全部公开的）
• 数据处理管线的细节

许可证限制：
Llama 使用的是 Meta 自己设计的许可证（Llama Community License / Llama 3.1 Community License），不是标准的开源许可证。关键限制包括：

• 月活跃用户超过 7 亿的产品，需要单独向 Meta 申请授权（这基本上就是排除了其他大厂直接用）
• 不能用模型的输出来训练其他模型（在某些版本的许可证中有这条限制）
• 需要保留 Meta 的署名

所以 Llama 算「开源」吗？在 OSI（开源定义倡议组织）的严格定义下，它不算。但在 AI 行业的通俗用法中，大家一般还是叫它「开源模型」。

Mistral AI：比较开放

Mistral AI 的做法相对更开放一些：

• 早期的 Mistral 7B 使用 Apache 2.0 许可证，这是真正意义上的开源许可证
• 后续的一些模型（如 Mixtral）也采用宽松许可证
• 但更大更新的模型也开始采用更严格的许可证

阿里巴巴的 Qwen：条件式开放

Qwen 系列模型也公开了权重，使用的许可证随版本变化：

• Qwen 2.5 部分版本使用 Apache 2.0
• 部分版本有自定义许可证限制

完全开源的代表：Pythia、BLOOM

真正符合传统「开源」定义的大语言模型项目也有，比如：

• Pythia（EleutherAI）：模型权重、训练代码、训练数据全部公开，使用 Apache 2.0 许可证
• BLOOM（BigScience）：类似的全面公开策略

这些项目在「开源」的纯度上确实更高，但在模型能力上，和 Llama、Qwen 等商业公司出品的模型还有一定差距。

Hermes 的开放程度

说到 Hermes，它在「开源」方面做到了什么程度？

模型权重：完全公开，可以自由下载使用。

训练方法论：Nous Research 公开了相当详细的技术报告，描述了训练方法、数据策略等。Hermes 3 的技术报告就写得很详尽。

训练数据：这里要诚实地说——Hermes 的训练数据并没有完全公开。Nous Research 描述了数据的构成和处理方法，但原始数据集并不完全可下载。

训练代码：部分公开。

许可证：取决于底座模型的许可证。比如 Hermes 3 基于 Llama 3.1，那就遵循 Llama 的许可证。如果底座是 Apache 2.0 许可的模型，那 Hermes 版本也是 Apache 2.0。

在 cocoloop 论坛上有过关于这个话题的讨论，有人指出 Hermes 虽然不是学术意义上的「完全开源」，但在实际可用性上已经非常开放了——你可以免费下载、在本地运行、商用（遵守底座许可证的前提下）、做二次开发。

许可证到底有什么区别

这部分对开发者和企业用户特别重要。不同的许可证决定了你能拿模型做什么。

Apache 2.0

这是最宽松的主流开源许可证之一。核心要点：

• 可以自由使用、修改、分发
• 可以用于商业目的
• 可以将修改后的版本闭源
• 唯一要求是保留原始版权声明和许可证文本
• 不需要开源你基于它做的东西

哪些模型用 Apache 2.0？ Mistral 7B、部分 Qwen 版本、Gemma 等。

MIT License

和 Apache 2.0 类似的宽松许可证，限制更少（没有专利条款）。在 AI 领域较少用于模型本身，更多用于工具代码。

Llama Community License

Meta 自定义的许可证。主要限制：

• 月活 7 亿以上的产品需要额外授权
• 某些使用场景有限制
• 需要署名

这个许可证的具体条款在不同版本间有调整，用之前最好仔细看一遍当前版本的完整文本。

CreativeML / RAIL 类许可证

一些模型使用「负责任AI许可证」（RAIL），会列出一系列禁止的使用场景（如生成虚假信息、歧视性内容等）。这在传统开源定义中是有争议的，因为传统开源不限制使用目的。

商业许可证

一些模型（如 GPT-4、Claude）完全不公开权重，只通过 API 提供服务。你不能下载、不能修改、不能本地部署，只能按调用量付费。

「开源」与「开放权重」的区别

AI 行业越来越多人开始区分两个概念：

• 开源（Open Source）：权重、代码、数据全部公开，使用 OSI 认可的开源许可证
• 开放权重（Open Weights）：只公开了模型权重，可能有额外使用限制

按这个标准，大多数我们日常说的「开源模型」其实应该叫「开放权重模型」。但在实际交流中，大家一般不做这么严格的区分。

你需要知道的关键区别是：

1. 能不能下载权重在本地跑？ —— 开放权重和开源都可以
2. 能不能商用？ —— 取决于具体许可证，不是「开源」就一定能商用
3. 能不能看到训练数据？ —— 大多数「开源」模型其实不公开完整训练数据
4. 能不能复现训练过程？ —— 很少有模型做到这一点

为什么这些区别很重要

你可能会想：我只是用模型来聊天/写代码/做应用，这些区别对我有什么影响？

对个人开发者

如果你只是在本地跑模型自己用，大多数「开放权重」模型都没有限制。随便用就行。

但如果你想基于模型做产品赚钱，就得仔细看许可证了。比如你用 Llama 底座做了一个 SaaS 产品，月活增长到了一定规模，就需要考虑 Meta 许可证的限制。

对企业用户

企业使用的法务审查通常更严格。选择 Apache 2.0 许可的模型（或基于 Apache 2.0 底座的 Hermes 版本）会减少很多法律风险。

对研究者

如果你要做学术研究并发表论文，使用真正开源（数据和代码都公开）的模型会让你的研究更具可复现性。

对整个生态

开放程度越高的模型，社区能贡献的越多。完全开源的模型可以被社区从训练阶段开始改进，而只公开权重的模型，社区只能在微调层面参与。

Hermes 在这个光谱上的位置

把各种模型按开放程度排个序的话，大致是这样的：

1
2

完全闭源 ←→ API Only ←→ 限制性许可 ←→ 开放权重 ←→ 完全开源
GPT-4      Claude API   Llama       Hermes*     Pythia

*Hermes 的具体位置取决于底座模型的许可证

Hermes 在实践中的开放度是比较高的。你可以：

• 免费下载
• 本地运行
• 用于商业项目（遵守底座许可证）
• 做二次微调
• 学习其微调方法论

在 cocoloop 社区里，不少开发者就是基于 Hermes 做二次微调来适配自己的特定场景。这种自由度是闭源模型完全不可能给你的。

怎么查一个模型的许可证

实际操作中，查许可证最快的方法：

1. 打开模型在 Hugging Face 上的页面
2. 看页面右侧的 License 标签
3. 如果是自定义许可证，点进去仔细读全文

或者直接看模型仓库里的 LICENSE 或 LICENSE.md 文件。

一个小建议：不要只看别人说这个模型是「开源的」就放心了。自己花10分钟读一下许可证，可以避免很多潜在的法律问题。特别是如果你要做商业应用的话。

开源 AI 的未来方向

AI 领域的「开源」定义还在演变中。OSI 在 2024 年发布了针对 AI 的「开源定义」草案，试图为 AI 模型的开源标准提供更明确的框架。

趋势来看：

• 越来越多的公司选择公开模型权重（即使不是完全开源），因为这有助于建立生态和获取用户
• 训练数据的公开仍然是最大的挑战，涉及版权、隐私等复杂问题
• 许可证碎片化的问题在加剧，各家都搞自己的许可证

作为用户和开发者，你要做的就是搞清楚你在用的模型到底开放了什么、限制了什么，不要被「开源」这个标签一叶障目。

这才是这篇文章最重要的 takeaway。

你打开 Hugging Face，搜索 Hermes，出来一堆结果：

• Hermes-2-Pro-Mistral-7B
• Hermes-3-Llama-3.1-8B
• Hermes-3-Llama-3.1-70B
• Hermes-3-Llama-3.1-405B
• Hermes-4-Scout
• Hermes-4.3-Seed

看到这些名字，是不是一头雾水？

别慌。这些名字其实有非常清晰的规律，一旦你搞懂了命名规则，看到任何一个新版本都能立刻知道它大概是个什么东西。

这篇文章就是专门帮你解决这个问题的。

命名的基本结构

Hermes 模型的命名一般遵循这个格式：

1

Hermes-[版本号]-[底座模型名]-[参数量]

拆开来看：

• Hermes：品牌名，代表这是 Nous Research 出品的微调模型
• 版本号：比如 2、2 Pro、3、4、4.3，代表微调方法和数据的迭代版本
• 底座模型名：比如 Llama-3.1、Mistral、Qwen，代表用了谁的底座
• 参数量：比如 7B、8B、70B、405B，代表模型的规模

举个例子：Hermes-3-Llama-3.1-70B

• Hermes 品牌
• 第 3 代微调方法
• 基于 Meta 的 Llama 3.1 底座
• 70B（700亿）参数规模

这就像汽车的命名：品牌（宝马）+ 代际（第8代）+ 平台（CLAR平台）+ 排量（3.0T）。知道了规则，新出一个型号你也能快速定位。

什么是「底座模型」

在详细讲各个版本之前，先确保你理解「底座模型」这个概念。

大语言模型的训练分两个大阶段：

1. 预训练（Pre-training）：用海量文本数据（几万亿个token）从零训练一个模型。这一步需要巨量的计算资源，通常只有大公司才做得起。产出的模型叫做「基座模型」或「底座模型」（Base Model）。

2. 微调（Fine-tuning）：在预训练好的底座上，用相对较少但更高质量的数据继续训练，让模型学会遵从指令、对话、使用工具等具体能力。

Hermes 做的就是第二步。它不自己做预训练（那太烧钱了），而是拿别人训练好的底座来做精细的微调。

所以你看到名字里的 Llama、Mistral、Qwen、Seed 这些，就是指底座的来源。如果你对底座模型的开源情况感兴趣，可以看看 开源模型到底「开源」了什么 这篇科普。

Hermes 各大版本详解

Hermes 1（2023年）

底座：Llama 1 / Llama 2
参数量：7B、13B
微调方法：标准 SFT（监督微调）
上下文窗口：2K - 4K tokens

Hermes 1 是开山之作。在 2023 年的开源微调模型中，它的数据质量和输出质量都是顶级的。但以今天的标准看，能力上已经明显落后了——上下文窗口太短，没有工具调用能力，对复杂指令的理解也有限。

你现在还需要用 Hermes 1 吗？ 基本不需要。除非你在研究早期模型的历史演变。

Hermes 2（2023年末-2024年初）

底座：Mistral 7B、Mixtral 8x7B、Yi 34B、Solar 10.7B 等
参数量：7B - 34B
微调方法：SFT
上下文窗口：4K - 32K tokens

Hermes 2 的最大变化是多底座支持。Nous Research 证明了自己的微调方法论是通用的，不依赖特定底座。

这个阶段值得一提的几个版本：

• Hermes-2-Mistral-7B：基于 Mistral 7B，当时性价比极高的选择
• Hermes-2-Mixtral-8x7B：基于 MoE 架构，第一次在 Hermes 系列中使用 MoE
• Hermes-2-Yi-34B：基于零一万物的 Yi 34B，在中文能力上有加成

Hermes 2 Pro（2024年）

底座：Mistral 7B、Llama 3 8B 等
参数量：7B - 8B
微调方法：SFT + 特殊能力训练
上下文窗口：8K - 32K tokens

Hermes 2 Pro 是 Hermes 2 的「加强版」，主要增加了：

• Function Calling：可以按规范格式输出函数调用
• JSON Mode：能稳定输出合法 JSON
• 增强的 System Prompt 遵从

这些能力让 Hermes 2 Pro 从「聊天模型」变成了「可以做应用开发的模型」。对于做 AI Agent 的开发者来说，这是一个里程碑。

cocoloop 社区的开发者们在 Hermes 2 Pro 阶段开始大量采用 Hermes 系列做项目开发，反馈非常积极——特别是在函数调用的准确率方面，很多人说不输同期的商业 API。

Hermes 3（2024年中后期）

底座：Llama 3.1
参数量：8B、70B、405B
微调方法：SFT + DPO
上下文窗口：128K tokens

Hermes 3 是整个系列最重要的版本。 几个关键升级：

参数规模跨越：从之前最大 34B 一下子跳到了 405B。这意味着 Nous Research 有能力处理超大规模模型的微调了。

DPO 引入：首次在训练中使用 DPO（直接偏好优化）。这让模型的输出更贴合人类偏好，同时避免了传统 RLHF 的一些问题。想了解这些方法的区别？去看 什么是模型微调 吧。

128K 上下文：继承了 Llama 3.1 的 128K 上下文能力。处理长文档、长对话不再是问题。

个体对齐理念：正式提出了 Individual Alignment 的概念，让用户通过 system prompt 来定义模型的行为边界。

在各个参数规模上的选择建议：

• 8B：个人使用、本地部署的首选。一张消费级显卡就能跑。
• 70B：需要更高质量输出时的选择。需要较好的硬件或云服务。
• 405B：追求极致效果。基本只能在云端跑。

Hermes 4 / Hermes 4 Scout（2025年初）

底座：Qwen 2.5 系列
参数量：Scout 版本为 8B+16 Experts MoE
微调方法：SFT + DPO + 思考增强
上下文窗口：128K tokens

Hermes 4 换了底座方向，从 Meta 的 Llama 转向了阿里的 Qwen 2.5。

为什么换底座？ 因为 Qwen 2.5 在多语言支持（特别是中文）和代码能力上有明显优势。Hermes 4 选择 Qwen 底座，意味着在这些维度上天然就更强。

MoE 架构：Hermes 4 Scout 使用了 Mixture of Experts（混合专家）架构。简单说就是模型的总参数量很大，但每次推理只激活其中一部分「专家」。这样既有大模型的能力，又有小模型的推理速度。

思考能力：Hermes 4 增加了「思考模式」，模型可以在回答前先做内部推理。这对数学、逻辑、编程等需要多步思考的任务帮助很大。

Hermes 4.3（2025年中）

底座：Bytedance Seed 1.5
参数量：总参数 200B，活跃参数约 20B（MoE 架构）
微调方法：SFT + DPO + 推理增强
上下文窗口：128K+ tokens

Hermes 4.3 是目前最新的版本，选择了字节跳动的 Seed 1.5 作为底座。

Seed 1.5 底座的优势：这个底座在数学推理、代码生成方面特别突出，而且是 MoE 架构（200B 总参数，约 20B 活跃），推理效率很不错。

Hermes 4.3 的增强：

• 更强的通用指令遵从
• 改进的角色扮演和创意写作
• 增强的函数调用能力
• 更好的长上下文理解

在 cocoloop 论坛上的反馈来看，Hermes 4.3 的中文表现有了明显进步，这主要得益于 Seed 底座本身对中文的优化。不少用户表示日常使用中文对话和写作的体验已经很流畅了。

参数量到底意味着什么

新手经常看到 7B、8B、70B、405B 这些数字，但不太理解它们的实际含义。

简单说：

• B = Billion = 十亿
• 7B = 70亿参数
• 70B = 700亿参数
• 405B = 4050亿参数

参数量越大，模型理论上越强，但代价也越大：

但要注意，实际使用中可以通过量化（Quantization）来大幅降低显存需求。比如 8B 模型用 4-bit 量化后，只需要大约 5-6 GB 显存，一张 RTX 3060 就能跑。关于这些硬件知识的详细讲解，推荐看 参数量、显存和推理速度 那篇。

版本关系速查表

怕你看完还是绕晕，做一张总结表：

我该选哪个版本

最后回答一个最实际的问题：作为新手，我该选哪个版本？

如果你想本地跑：选 Hermes 3 Llama 3.1 8B（稳定、生态好、教程多）或 Hermes 4.3（更新更强但生态还在建设中）。

如果你通过 API 用：直接选最新的 Hermes 4.3，通过 OpenRouter 等平台调用，省心省力。

如果你做 Agent/工具调用开发：Hermes 3 70B 或 Hermes 4.3 都是好选择，函数调用能力成熟可靠。

如果你预算有限、显卡一般：Hermes 3 8B 量化版，4-bit 量化后 6GB 显存就能跑，是入门最佳选择。

别纠结太久，先跑起来再说。实际使用中你很快就能感受到不同版本的差异，到时候再换也不迟。

在硅谷那些光鲜亮丽的 AI 创业故事里，标准剧本是这样的：名校博士毕业，大厂混几年，拿到顶级 VC 的钱，租一个漂亮的办公室，开始招兵买马。

Nous Research 的故事完全不是这个套路。

它的起点是一个 Discord 聊天群，创始人当时甚至不是什么学术圈的人物，团队成员分布在全球各地，很多人互相没见过面。但就是这么一帮人，做出了开源社区里最受欢迎的模型系列之一—— Hermes。

这个故事之所以值得讲，不是因为它多么传奇，而是因为它代表了 AI 领域一种完全不同的可能性：你不需要数亿美元的融资和几千张 GPU，也能做出让整个社区认可的东西。

Ryan Teknium：一个非典型的 AI 创始人

从 Discord 到研究领袖

Ryan Teknium（网名 Teknium1）并不是传统意义上的 AI 研究者。他没有 Stanford 或 MIT 的博士学位，最早在公众视野中出现是在各种开源 AI 的 Discord 社区里。

2023 年初，大语言模型的开源运动刚刚起步。Meta 泄露（后来正式开源）了 Llama，Stanford 的 Alpaca 展示了用少量数据微调就能让模型变好用的可能性。整个社区一下子炸开了锅——原来不用数十亿的预训练成本，普通人也有机会参与模型训练。

Ryan 是最早开始认真做微调实验的一批人。但和很多人不同的是，他不满足于「把公开数据集灌进去跑一遍」就完事。他花了大量精力在数据质量上——手动审核训练数据、设计数据筛选管线、测试不同的数据配比方案。

这种对数据质量近乎偏执的追求，成为了 Nous Research 后来的核心竞争力。

早期的微调实验

2023年上半年，Ryan 和几个志同道合的人开始系统性地做微调实验。他们的第一个有影响力的成果是在 Llama 底座上训练的一个聊天模型，在当时的评测中表现优于很多同期的社区微调版本。

关键决策在这个时候就做了：一切工作完全开源。模型权重、训练数据、训练代码、实验记录，全部公开。

这和后来很多「伪开源」的做法形成了鲜明对比。有些机构号称开源，实际上只放出了模型权重，训练数据和方法论全部保密。Nous Research 从第一天起就选择了彻底透明。关于开源模型「到底开源了什么」这个话题，我在 开源模型到底「开源」了什么 那篇文章里有详细讨论。

从个人项目到正式机构

社区的力量

Ryan 的微调实验吸引了越来越多的关注，Discord 社区开始快速增长。一些有技术背景的社区成员主动贡献代码、提供数据、参与测试。

这种「社区驱动」的研发模式在传统 AI 研究中是很少见的。大厂的 AI 研究走的是自上而下的路线——管理层定方向，研究员执行，成果由公司拥有。Nous Research 的路线完全相反——社区提出需求，大家一起讨论方案，有能力的人自发贡献，成果属于所有人。

但纯粹的社区项目有一个明显的问题：缺乏持续性和专注度。大家都是业余时间在搞，今天兴头来了写几行代码，明天忙了可能就放下了。

Ryan 意识到这个问题，开始推动 Nous Research 从一个松散的社区项目向正式的研究机构转型。

正式成立

2023年中后期，Nous Research 正式注册为一家公司。团队核心成员包括：

• Ryan Teknium：创始人，主导数据策略和训练方法论
• Karan（Teknium 的早期搭档）：负责基础设施和工程
• 社区中多位活跃贡献者转为正式团队成员

成立公司不是为了融资上市，而是为了能更有组织地推进研究。有了正式的架构，就可以申请计算资源、签合作协议、雇佣全职研究员。

获取计算资源

做 AI 研究最大的瓶颈之一是计算资源。训练一个像样的大模型需要大量 GPU 时间，这东西不便宜。

Nous Research 在这方面走了几条路：

1. 社区捐赠和赞助：早期有不少社区成员和小型公司捐赠 GPU 时间
2. 合作伙伴：和一些云计算提供商达成合作，以优惠价格获取算力
3. 后续的融资：随着名气越来越大，也获得了一些投资

但即便如此，他们的计算资源和 OpenAI、Google 这些巨头比起来还是差了好几个数量级。这反过来倒逼了一个好习惯：每一次训练都要精打细算，不能浪费。这也是为什么 Nous Research 在数据质量上那么较真——当你只有有限的训练机会时，你会格外重视每一轮训练使用的数据。

Hermes 系列的诞生与成长

第一个 Hermes

Hermes 1 的发布是 Nous Research 的第一个标志性时刻。

当时的开源社区里充斥着各种质量参差不齐的微调模型，很多都是「一晚上训出来」的实验品。Hermes 1 的不同之处在于，它是经过反复迭代、严格数据筛选后的产物。

发布后的反馈很积极。用户发现 Hermes 1 在指令遵从、对话质量、回答的有用性等方面，都明显优于同期的其他社区微调版本。Hugging Face 上的下载量迅速攀升。

持续迭代

从 Hermes 1 开始，Nous Research 保持了稳定的迭代节奏。每当有新的强力底座模型发布，他们都会在相对较短的时间内推出对应的 Hermes 版本。

这种快速响应能力来源于他们已经建立起来的微调工具链和数据管线。底座换了，但核心的数据处理流程、训练方法论、评测体系都是沉淀下来的，可以快速复用。

到 Hermes 2 Pro 阶段，Nous Research 开始在模型中引入更实用的能力——函数调用、结构化输出等。这让 Hermes 从一个「好用的聊天模型」升级为一个「可以在生产环境中使用的工具」。

cocoloop社区的不少开发者就是在这个阶段开始大量使用 Hermes 的。我记得当时论坛上有人做了一个对比测试，发现 Hermes 2 Pro 在函数调用的准确率上甚至超过了一些商业模型的 API。

里程碑：Hermes 3 的发布

Hermes 3 基于 Llama 3.1，覆盖 8B 到 405B 全系列参数规模，是当时开源社区里最大规模的高质量微调项目之一。

这次发布引起了广泛关注，不仅仅是在开源社区内部。一些 AI 媒体和分析师也开始认真审视 Nous Research，将其视为开源 AI 领域的重要力量。

Hermes 3 的训练涉及了更复杂的方法——SFT 加上 DPO，数据规模和质量都上了一个台阶。Nous Research 还发布了详细的技术报告，阐述了他们的「个体对齐」（Individual Alignment）理念。

7.6 万人的 Discord 社区

说 Nous Research 的故事不能不说他们的社区，因为社区本身就是这个项目的根基。

社区的规模与构成

截至目前，Nous Research 的 Discord 服务器有超过 7.6 万名成员。这个数字放在整个 AI 领域也是很突出的——要知道，这不是什么泛泛的「AI 爱好者群」，而是一个以开源模型研究和开发为核心的专业社区。

社区成员的构成很多样：

• 独立开发者：在自己的项目中使用 Hermes 的人
• 研究人员：来自高校和研究机构，关注 Nous Research 的方法论
• 企业用户：在公司产品中部署 Hermes 的工程师
• 纯粹的爱好者：对开源 AI 感兴趣，来学习和讨论的人

社区参与研发

Nous Research 的社区不是那种只能围观的粉丝群。社区成员实际参与到了研发过程中：

• 数据贡献：社区成员贡献训练数据和数据筛选建议
• Bug 反馈：新版本发布后，社区成员是最快的测试者
• 应用场景反馈：真实使用场景中发现的问题和需求
• 文档和教程：社区成员自发编写使用文档

这种参与度在 AI 研究机构中是非常罕见的。大多数 AI 公司的社区互动仅限于「我们发布了新模型，你们来用」，而 Nous Research 的模式更接近于真正的协作开发。

开放的研讨文化

Discord 社区里经常会有深入的技术讨论。Ryan Teknium 本人也经常在社区里回答问题、分享想法、参与辩论。

有几次比较有意思的公开讨论，涉及到了模型对齐方向、数据策略、甚至是 Nous Research 的下一步计划。这种透明度在任何商业公司里都是难以想象的。

Nous Research 的独特定位

不是大厂，也不是小作坊

Nous Research 处在一个很特殊的位置：

它比个人开发者和小团队更有组织、更有资源，能持续产出高质量的成果；但它又不像 OpenAI、Anthropic、Google DeepMind 那样有数十亿美元的资金和数千名员工。

这种「中间地带」的定位反而成了优势：

• 足够灵活：不需要层层审批，看准方向就能快速行动
• 足够专注：不用追求什么都做，把微调这件事做到极致
• 足够开放：没有商业秘密的负担，可以把一切都公开

研究与实用并重

Nous Research 的另一个特点是研究和实际应用之间的平衡。

很多学术团队做出的模型好看不好用——论文发了一堆，但模型在实际场景中各种翻车。Nous Research 的每一个版本都是要经受社区用户真实使用检验的，这种压力倒逼了他们必须重视实用性。

反过来，他们也不是纯粹的「工程团队」。对新训练方法的探索、对对齐问题的思考、对数据科学的研究，都有相当的深度。Hermes 3 的技术报告就展示了他们在对齐理念上的独到见解。

面对的挑战

光说好的不行，也得聊聊难处。

计算资源的永恒焦虑

这一点前面提过了，但值得再强调。随着模型越来越大、训练方法越来越复杂，计算资源的需求是指数级增长的。Nous Research 在这方面始终面临压力。

人才竞争

AI 领域的人才竞争异常激烈。大厂可以开出七位数的年薪，Nous Research 很难在薪资上直接竞争。好在，开源理念本身就是一种筛选机制——真正被吸引过来的人，往往是认同开源价值观的人，这反而保证了团队的凝聚力。

商业化探索

纯粹做开源很难维持长期运营。Nous Research 也在探索商业化的路径，包括企业级服务、定制化微调等。如何在坚持开源的同时实现商业可持续，是一个需要长期平衡的问题。

对整个行业的影响

Nous Research 的存在证明了几件事：

第一，开源 AI 研究是可行的。 你不需要是 Google 才能做出好模型。高质量的数据 + 正确的方法论 + 专注的团队，可以弥补资源上的差距。

第二，社区驱动的研究模式有其独特价值。 七万多人的社区提供了大厂内部团队无法获得的多样性视角和即时反馈。

第三，对齐不必等同于过度限制。 Hermes 的「个体对齐」理念为整个行业提供了另一种思路。

在cocoloop社区里，Nous Research 经常被拿来作为「小团队做大事」的典型案例讨论。确实，在这个越来越资本密集的赛道上，他们用行动证明了另一种可能。

从 Discord 群到 AI 前沿

回到开头的那个问题：一群 Discord 聊天群里的人，怎么就做出了开源社区最火的模型之一？

答案其实并不复杂：

1. 找对了切入点（高质量微调而非从零预训练）
2. 坚持了正确的理念（数据质量优先、完全开源）
3. 建立了真正的社区（不是粉丝群，而是协作网络）
4. 保持了持续迭代的节奏（不掉队，不摆烂）

这些听起来都不是什么惊天动地的策略，但能同时做到并坚持下来的团队，在这个浮躁的行业里其实并不多。

Nous Research 的故事还在继续。随着 Hermes 4.3 和后续版本的推出，他们在开源 AI 领域的影响力仍在扩大。对于任何关注大模型发展的人来说，这是一个值得持续跟踪的团队。

如果你想深入了解 Hermes 模型本身，可以从 Hermes 是什么 这篇开始读，会对整个模型系列有一个完整的认识。

如果你最近刚开始关注大模型领域，大概率会在各种排行榜、Reddit帖子、Hugging Face热门下载里反复看到一个名字——Hermes。

那 Hermes 到底是什么？

简单粗暴地说：Hermes 是由 Nous Research 这家机构做的一系列经过精心微调的开源大语言模型。它不是从零训练的基座模型，而是拿别人训练好的底座（比如 Meta 的 Llama、Mistral 的模型等），通过高质量数据做微调，让模型变得更好用、更听话、更能干。

打个比方：如果 Llama 是一块没雕琢过的璞玉，那 Hermes 就是经过精细雕刻后的成品。底子是别人的，但手艺是 Nous Research 自己的，而这个手艺水平，在开源社区里算得上顶尖。

Nous Research 又是谁

在聊 Hermes 各个版本之前，有必要先说说背后的团队。

Nous Research 是一家专注于开源 AI 研究的机构，创始人是 Ryan Teknium（也叫 Teknium1）。这哥们最早在 Discord 社区里搞开源模型微调，算是最早一批做「社区驱动」AI研究的人。关于 Nous Research 的详细创业经历，我在 Nous Research 的创业故事 里写得比较完整，这里就不展开了。

核心要知道的就一件事：Nous Research 不是大厂，但他们做出来的东西不输大厂。Discord 社区七万多人，在 AI 开源圈子里是真正意义上的头部。

从 Hermes 1 到 Hermes 4.3：一条清晰的进化线

Hermes 1：起步阶段

2023年中，Hermes 的第一个版本诞生了。那时候 Meta 刚放出 Llama 1（后来是 Llama 2），整个开源社区都在疯狂地做微调实验。

Hermes 1 基于 Llama 1/2 底座，用 Nous Research 自己收集和筛选的高质量指令数据进行微调。当时的微调方法相对简单，主要就是标准的监督微调（SFT）。但 Hermes 1 有个非常突出的特点：数据质量极高。

Ryan Teknium 本人花了大量时间做数据筛选和清洗，这在当时那个「大力出奇迹、数据越多越好」的氛围里显得很另类。事实证明这个思路是对的——Hermes 1 在同期的微调模型中脱颖而出，在 Hugging Face 上的下载量一骑绝尘。

Hermes 2 / Hermes 2 Pro：成熟期

到了 Hermes 2 阶段，事情开始变得更有意思。

Hermes 2 系列扩展到了多个底座模型，不再只是 Llama。Mistral 7B、Mixtral、Yi 34B 等底座都有对应的 Hermes 2 版本。这说明 Nous Research 的微调方法论已经成熟了，不依赖某一个特定底座。

Hermes 2 Pro 是这个阶段的代表作，它在 Hermes 2 的基础上增加了几个关键能力：

• Function Calling（函数调用）：模型可以按照指定格式输出结构化的函数调用结果，这对做 Agent 应用非常关键
• JSON Mode（结构化输出）：可以稳定地输出合法 JSON
• 改进的系统提示词遵从：更好地执行系统角色设定

这些能力让 Hermes 从一个「聊天好用」的模型升级成了一个「可以做应用开发」的模型。cocoloop社区的不少开发者在那个阶段开始把 Hermes 2 Pro 集成到自己的项目里，反馈普遍很正面。

Hermes 3：里程碑式的突破

2024年，Hermes 3 发布，这是整个系列最重要的一次升级。

Hermes 3 基于 Meta 的 Llama 3.1 系列底座，覆盖了 8B、70B、405B 三个参数规模。没错，405B——这是开源社区里最大的经过高质量微调的模型之一。如果你想深入了解 Hermes 3 的具体技术细节，可以看看 Hermes 模型版本怎么看 那篇文章，里面有更详细的版本对比。

Hermes 3 的核心升级点：

训练方法升级：从单纯的 SFT 升级为 SFT + DPO 的组合。DPO（直接偏好优化）让模型在保持能力的同时，输出更符合人类偏好。关于这些微调方法的区别，可以参考 什么是模型微调 那篇科普。

个体对齐（Individual Alignment）：这是 Hermes 最有辨识度的特色。简单说就是——Hermes 不会像某些被过度对齐的模型那样，动不动就拒绝回答你的问题。它会尽量根据你的 system prompt 来决定自己的行为边界，把主动权交给使用者。

Agentic 能力全面增强：更强的函数调用、更好的多轮对话一致性、更可靠的指令遵从。

上下文窗口扩展：支持 128K token 的上下文长度，处理长文档不在话下。

Hermes 4：基座换代

进入 2025 年，Hermes 4 在底座选择上走了不同的路。

Hermes 4 基于 Qwen 2.5 底座（阿里巴巴的千问系列），推出了 Hermes 4 Scout（8B+16 Experts MoE 架构）等版本。这是 Hermes 首次大规模使用 MoE（Mixture of Experts）架构的底座，意味着模型在保持较少「活跃参数」的情况下拥有更大的总参数量，推理效率更高。

Hermes 4 的另一个亮点是对思考/推理能力的增强。模型可以在回答前进行内部思考（类似 Chain-of-Thought），在复杂问题上的表现提升很明显。

Hermes 4.3：最新进展

Hermes 4.3 是目前最新的版本，基于 Bytedance 的 Seed 1.5 底座，这是一个 MoE 架构的模型（总参数 200B，活跃参数约 20B）。

为什么选 Seed 1.5？因为这个底座在代码、数学和推理方面特别强，而 Nous Research 在此基础上进一步增强了：

• 通用指令遵从
• 角色扮演和创意写作
• 函数调用和工具使用
• 长上下文理解

在 cocoloop 论坛上有不少关于 Hermes 4.3 的讨论帖，大家的反馈集中在两点：推理能力确实强了，然后对中文的支持也比之前的版本好了不少（毕竟底座本身就对中文做了优化）。

为什么 Hermes 在开源社区这么火

讲完了历史，我们来聊聊一个更本质的问题：开源模型那么多，为什么 Hermes 能一直保持高人气？

第一，数据质量的执念

Nous Research 对训练数据质量的追求是出了名的。他们不是那种「把 ShareGPT、Alpaca 数据集一股脑灌进去就完事」的团队。Ryan Teknium 本人多次公开表示，数据质量比数据数量重要得多。

他们会手动审核数据、过滤低质量样本、设计专门的数据管线来确保每一条训练数据都是有价值的。这种「手工活」在这个讲究规模化的时代看起来很笨，但效果实打实。

第二，不过度对齐

很多商业模型（包括一些开源模型的「官方微调版」）被训练得过于谨慎。你问个稍微敏感一点的问题，模型就开始「作为一个AI，我无法……」这套话术。

Hermes 走了另一条路。它的核心理念是「中立基座 + 用户自定义对齐」。模型本身不预设太多限制，你可以通过 system prompt 来定义模型的行为边界。这让 Hermes 在角色扮演、创意写作、开发者工具等场景中特别好用。

第三，持续迭代，不掉队

从 2023 年到 2026 年，Hermes 一直在跟进最新的底座模型和训练方法。每当有强力新底座发布（Llama 3、Qwen 2.5、Seed 1.5），Nous Research 都会在第一时间推出对应的 Hermes 版本。

这种持续迭代的节奏让用户有信心——选择 Hermes 不是选择一个「一锤子买卖」的项目，而是选择一个活跃维护的生态。

第四，社区驱动，反馈闭环

七万多人的 Discord 社区不是摆设。用户发现的问题、提出的需求，确实能影响到下一个版本的优先级。这种和社区紧密互动的开发模式，让 Hermes 能快速响应实际使用中的痛点。

Hermes 的核心使用场景

了解了 Hermes 是什么和为什么火之后，再说说它适合干什么。

通用对话助手

这是最基本的用途。Hermes 在通用对话任务中的表现稳定，回答质量高，指令遵从性好。无论是日常问答、写作辅助还是代码生成，都能胜任。

Agent / 工具调用

Hermes 2 Pro 开始引入的 Function Calling 能力，到 Hermes 3/4 已经相当成熟。你可以让 Hermes 调用外部工具、查询数据库、执行代码，构建完整的 AI Agent 流程。

角色扮演与创意写作

因为 Hermes 不会过度拒绝，它在角色扮演和创意场景中表现出色。你可以给它设定复杂的角色背景，它会认真遵守设定来互动，不会突然跳出角色说「我是一个AI」。

本地部署

Hermes 的 8B 版本特别适合本地部署。在一张普通消费级显卡（比如 RTX 4060）上，量化后的 Hermes 8B 就能流畅运行。配合 Ollama 或者 llama.cpp，几分钟就能在自己电脑上跑起来。

和其他开源模型的区别

新手经常搞不清楚 Hermes 和 Llama、ChatGLM、Qwen 这些模型的关系。其实很简单：

• Llama、Qwen、Mistral 这些是底座模型（Base Model），由 Meta、阿里巴巴、Mistral AI 等公司从零训练。
• Hermes 是在这些底座模型上做的微调版本（Fine-tuned Model），由 Nous Research 训练。

打个不太精确但很直观的比方：底座模型像毛坯房，Hermes 是精装修过的成品房。地基结构是开发商（Meta、阿里等）打的，但室内设计和装修工艺是 Nous Research 自己的。

所以你在 Hugging Face 上看到「Hermes-3-Llama-3.1-8B」这样的名字时，它的意思是：基于 Llama 3.1 8B 底座，由 Hermes 3 方法微调。

怎么开始使用 Hermes

如果你看到这里已经对 Hermes 感兴趣了，最快的上手方式是：

1. 在线体验：去 OpenRouter 或者 Hugging Face Spaces，搜 Hermes，很多在线可用的版本
2. 本地部署：装一个 Ollama，然后 ollama run hermes3，几分钟搞定
3. API 调用：通过 OpenRouter 等平台的 API，可以直接在自己的应用里调用 Hermes

关于本地部署和云端 API 的选择，我写过一篇 本地部署 vs 云端 API 的对比分析，犹豫不决的可以参考一下。

写在最后

Hermes 之所以能在开源模型的海洋里站稳脚跟，靠的不是什么花哨的营销，而是扎实的数据功夫、尊重用户自主性的对齐理念、以及持续不断的迭代。

对于刚入坑大模型的新手来说，Hermes 是一个非常好的起点——它免费、开源、社区活跃、文档完善，而且从 8B 小模型到 405B 大模型都有覆盖，无论你的硬件条件如何，都能找到适合自己的版本。

在 cocoloop 社区里，Hermes 也一直是讨论度最高的开源模型之一。如果你有任何使用上的问题，去论坛搜一搜，大概率能找到答案。

这篇文章就来好好聊聊，Hermes 3 的 405B 全参数微调背后到底做了哪些事情，以及为什么这件事对开源社区意义重大。

先搞清楚一个问题：为什么不用 LoRA？

做大模型微调，现在主流方案基本就两条路：全参数微调（Full Fine-tuning）和参数高效微调（PEFT），后者最常见的就是 LoRA。

LoRA 的好处很明显——省显存、训练快、部署方便。一个 7B 的模型用 LoRA 微调，一张消费级显卡就能跑。但问题在于，LoRA 本质上是在原始权重旁边挂了个”补丁”，它能调整的参数空间有限。当你的训练目标和原始模型的行为差距比较大时，LoRA 的表达能力就不够了。

Hermes 系列一直有个核心特点：它要改变模型的”人格”和”行为模式”。不光是让模型回答问题，还要让它遵循特定的系统提示格式、支持 ChatML格式 的多轮对话、在 function calling 场景下表现稳定。这些都是深层的行为变化，不是加个 LoRA adapter 就能搞定的。

Ryan Teknium 在技术报告里解释得比较直接：405B 的全参数微调，目标就是最大程度地释放基座模型的潜力，同时把 Hermes 的对齐理念（individual alignment）注入到每一层参数里去。

Lambda Cloud 提供的算力支持

训练一个 405B 的模型，算力需求是天文数字级别的。Nous Research 这次是和 Lambda Cloud 合作，使用了大规模 H100 集群来完成训练。

具体来说，405B 的全参数微调需要处理的参数量大约是 4050 亿个。即使用 BF16 精度，模型权重本身就占了约 810GB 的显存。加上梯度、优化器状态，训练峰值显存需求可以轻松超过 3TB。这意味着至少需要几十张 H100（每张 80GB 显存）做模型并行。

Lambda Cloud 在这个项目中提供的不仅是算力，还有分布式训练的基础设施支持。405B 的训练涉及到张量并行（Tensor Parallelism）、流水线并行（Pipeline Parallelism）等多种并行策略的组合使用，这对训练框架和网络拓扑都有很高的要求。

之前在 cocoloop 社区有人讨论过这个问题——为什么 Nous Research 选择 Lambda 而不是自己搭集群？答案很简单：灵活性。对于一个研究团队来说，按需租用 GPU 比长期维护硬件要经济得多，而且 Lambda 的 H100 集群在互联带宽上做了专门优化，特别适合大规模分布式训练场景。

训练数据和流程

Hermes 3 的训练数据延续了 Hermes 系列一贯的策略：大规模合成指令数据 + 精心策划的人类数据。

训练流程分为几个阶段：

第一阶段：监督微调（SFT）

这一步用的是经过筛选和清洗的指令数据集。数据来源包括 OpenHermes 数据集 的改进版本，加上针对 Hermes 3 新增的多轮对话数据、function calling 示例、以及各种角色扮演场景。

数据格式上，Hermes 3 全面采用 ChatML 作为对话模板。ChatML 的好处是结构清晰，对工具调用、系统提示的支持天然友好。这也是为什么 Hermes 系列在 agent 场景下表现一直不错的原因之一。

第二阶段：偏好优化

SFT 之后，Hermes 3 还做了偏好优化训练，具体使用的是 DPO（Direct Preference Optimization）方法。DPO 相比传统的 RLHF 流程更简洁，不需要单独训练 reward model，直接用偏好对比数据就能完成。

偏好优化的重点方向包括：减少不必要的拒绝回答（这个后来在 RefusalBench 上体现得很明显）、提升长文本生成的连贯性、以及改善多步推理的准确性。

第三阶段：安全对齐

Hermes 3 的安全对齐思路和主流商业模型有明显区别。它提倡的是”个体对齐”（Individual Alignment）——不是由模型开发者单方面决定模型该拒绝什么、该回答什么，而是把这个选择权更多地交给用户。

具体做法是通过系统提示（system prompt）来控制模型的行为边界。用户可以在系统提示中定义模型应该遵循的规则，模型则在这些规则的框架内尽可能地满足用户需求。

这个设计理念其实挺有争议的，cocoloop 社区里也讨论过好几轮。支持的人觉得这才是开源模型该有的样子——用户有完全的控制权；反对的人担心这会被滥用。但从技术角度看，Hermes 3 的做法确实让模型的可用性大幅提升了。

三个版本的差异：8B、70B 和 405B

Hermes 3 基于 Llama 3.1 发布了三个规模的版本：

8B 版本：最适合个人用户和小团队部署。在量化后可以在消费级硬件上流畅运行。它的优势在于速度快、成本低，但在复杂推理和长文本场景下会有明显短板。

70B 版本：平衡之选。在大多数任务上都能给出不错的表现，对硬件的要求也相对可控（2-4张 A100 或等效 GPU）。很多商业应用场景会选这个版本。

405B 版本：旗舰级。在几乎所有基准测试上都是开源模型中的最强水平。但部署成本也是最高的，推理时需要多机多卡协同。

有个经常被忽略的细节：这三个版本虽然基座都是 Llama 3.1，但训练数据和超参数是分别调过的。不是简单地用同一套数据训练三个不同大小的模型，而是根据每个规模的模型特点做了针对性的优化。

比如 8B 版本在训练时会更注重指令跟随的精确性，因为小模型本身容量有限，需要把有限的参数用在刀刃上。而 405B 版本则可以分配更多的训练预算在复杂推理和创造性任务上。

基准测试表现

Hermes 3 发布时给出了相当全面的基准测试数据。这里挑几个关键的说：

MMLU（多学科知识测试）：405B 版本的表现接近 GPT-4 当时的水平。这个测试覆盖了从人文到理工的 57 个学科，能比较全面地反映模型的知识储备。

HumanEval（代码生成）：在代码生成任务上，Hermes 3 的 pass@1 得分比原版 Llama 3.1 有显著提升。这说明微调过程中加入的代码相关数据确实起了作用。

MT-Bench（多轮对话评估）：这个测试用 GPT-4 当裁判，评估模型在多轮对话中的表现。Hermes 3 在这项上得分很高，特别是在角色扮演和创意写作类别里，甚至超过了一些商业模型。

但也得说实话，Hermes 3 在数学推理上的表现不算特别突出。这也是后来 Hermes 4 重点改进的方向之一——引入混合推理模式，大幅提升数学和逻辑推理能力。

对开源社区的影响

Hermes 3 的 405B 版本是第一个公开发布的 Llama 3.1 405B 全参数微调模型。这个”第一”本身就够有分量了。

在此之前，社区对于超大模型的微调基本停留在 LoRA/QLoRA 的阶段。不是大家不想做全参数微调，是真做不起。Hermes 3 证明了一件事：只要有合适的算力合作伙伴，研究团队也能完成商业级别的大规模训练。

从下载量来看，Hermes 3 系列在 Hugging Face 上累积了数百万次下载。这个数字背后代表的是大量的个人开发者、创业公司和研究机构在实际使用这个模型。

Nous Research 通过 Hermes 3 也进一步巩固了自己在开源 LLM 社区的地位。从 2023 年的初代 Hermes 到 2024 年的 Hermes 3，Ryan Teknium 和他的团队一步步把 Hermes 做成了开源社区最受认可的微调模型品牌之一。截至目前，整个 Hermes 系列的下载量已经超过了 3300 万次。

几个值得关注的技术细节

ChatML 的全面采用：Hermes 3 彻底统一了 ChatML 作为对话模板。这让它在各种 agent 框架（比如 LangChain、AutoGen）里的接入变得很顺畅。

系统提示的深度支持：不同于很多模型对系统提示的”假装遵循”，Hermes 3 在训练时就把系统提示作为第一优先级来处理。你在系统提示里写的规则，模型会真的去执行。

多语言能力：虽然训练数据以英文为主，但由于 Llama 3.1 基座本身就有不错的多语言基础，Hermes 3 在中文、日文等语言上的表现也相当能打。

工具使用能力：延续了 Hermes 2 Pro 在 function calling 上的积累，Hermes 3 的工具调用能力在微调过程中得到了进一步强化。

写在最后

Hermes 3 405B 的全参数微调是一个标志性事件。它告诉整个社区：开源模型不只是”够用”，而是可以在顶级规模上和商业模型掰手腕。

当然，405B 的部署门槛确实很高，不是每个人都用得起。但 8B 和 70B 版本同样质量过硬，足以覆盖绝大多数使用场景。

如果你对 Hermes 系列的整体发展感兴趣，可以看看 Hermes 模型进化全记录，那里有从初代到最新版的完整时间线。而 Hermes 3 这次的 405B 全参数微调，无疑是这条进化线上最浓墨重彩的一笔。

延伸阅读：OpenClaw 社区资源

本文由 CocoLoop 中文社区出品。如果你在研究 AI Agent 与主流模型的工程化落地，姊妹站 OpenClaw 中文社区 也许会有帮助：

• 主流 AI 模型能力对比评测

我用了大概两周时间，在不同场景下测试了 Hermes 4 的推理能力。这篇文章不聊理论，主要说说实际用起来是什么感觉。

混合推理是什么意思

先把概念理清楚。所谓”混合推理”（Hybrid Reasoning），指的是模型可以在两种模式之间灵活切换：

直出模式：收到问题后直接生成答案，和普通的对话模型一样。速度快，适合简单问题。

思考模式：在生成最终答案之前，先在 <think> 和 </think> 标签之间进行一段内部推理。这个过程类似于人在做数学题时先在草稿纸上演算一遍。

关键在于”混合”这两个字。Hermes 4 不是永远在思考，也不是永远直出，而是根据问题的复杂度自动判断要不要启动思考模式。简单的闲聊就直接回，遇到需要多步推理的数学题或逻辑问题，它就会先想再答。

这个设计思路和 OpenAI 的 o1 模型有异曲同工之处，但实现方式不同。o1 的推理过程对用户完全不可见，你只能看到最终答案。而 Hermes 4 的 think 标签是完全透明的——你能看到模型的完整思考过程，包括它走的弯路和自我纠正。

think 标签长什么样

实际使用中，Hermes 4 的输出大概是这样的格式：

1
2
3
4
5
6
7
8
9
10
11
12
13

<think>
用户问的是一个组合数学问题，需要计算从10个球中选3个的方案数...
首先用组合公式 C(n,k) = n! / (k!(n-k)!)
C(10,3) = 10! / (3! × 7!)
= (10 × 9 × 8) / (3 × 2 × 1)
= 720 / 6
= 120
验证一下：10选3，确实是120种方案
</think>

从10个球中选3个，共有 **120** 种不同的选法。

计算过程用组合公式：C(10,3) = 10!/(3!×7!) = 120

你能清楚看到模型先列出了解题思路，做了计算，甚至还做了一步验证。这个透明度对于调试和学习来说都很有价值。

什么时候会触发思考模式

在测试过程中，我观察到的触发规律大概是这样的：

基本会触发思考的场景：

• 数学计算题，特别是多步骤的
• 逻辑推理题（比如谁说谎之类的）
• 代码 debug，需要追踪变量状态的
• 需要对比分析多个选项的决策题
• 复杂的文本理解题

基本不会触发的场景：

• 日常闲聊（”今天天气怎么样”）
• 简单的知识问答（”Python 的列表用什么符号”）
• 翻译任务
• 短文本改写

有时候触发有时候不触发：

• 中等难度的编程任务
• 写作类需求（看复杂程度）
• 数据分析类问题

这个判断机制不是完美的。偶尔会遇到一些明明不需要思考的简单问题，模型也会进入思考模式，浪费了几秒钟时间。但总体来说，触发的准确率还不错。

推理质量到底怎么样

这才是最核心的问题。直接上结论：Hermes 4 的推理质量相当强，在数学和代码领域尤其突出。

数学推理

Hermes 4 在 MATH-500 上的得分是 96.3%。这个分数意味着什么？MATH-500 是从 MATH 数据集中抽取的 500 道竞赛级数学题，覆盖代数、几何、数论、组合等多个分支。96.3% 的正确率说明模型在高中到本科竞赛级别的数学题上已经非常可靠了。

实际测试中，我用了一些非标准的数学题来测，刻意避开常见题型。Hermes 4 在处理这些”没见过”的题目时表现也很稳定，think 标签里的推理步骤基本都是对的，偶尔会在最后一步计算上出错（大模型的通病——纯算术计算不太行）。

在 AIME 2024（美国数学邀请赛）上，Hermes 4 拿到了 81.9% 的得分。AIME 的难度比 MATH-500 高出不少，这个成绩放在开源模型里属于顶级水平。

代码推理

在代码场景下，think 标签的价值体现得特别明显。当你让 Hermes 4 帮你 debug 一段代码时，它会在思考过程中逐行模拟执行，追踪变量的变化，然后精确定位问题。

我测了几个典型的 debug 场景：

• 一个 off-by-one 错误的循环：Hermes 4 在 think 中模拟了前三次迭代，准确找到了边界条件的 bug
• 一个递归函数的栈溢出问题：在 think 中画出了调用栈，发现缺少终止条件
• 一个并发竞态条件：这个比较难，Hermes 4 在 think 中列出了两种可能的执行顺序，指出了竞态发生的具体位置

不过，对于特别长的代码（超过 200 行），思考过程有时候会变得冗长而不够聚焦。这时候它的效率反而不如一些专门的代码模型。

逻辑推理

逻辑题是 think 模式最”吃香”的领域。那种需要多步排除、条件组合的题目，Hermes 4 处理得很漂亮。

比如经典的”五个人住不同颜色的房子”这类约束满足问题，Hermes 4 会在 think 中建立约束表，逐步排除，最终给出答案。过程清晰，基本不犯错。

和直出模式的对比

一个自然的问题是：开启思考模式后，答案质量提升了多少？

我做了个简单的对比实验：选了 50 道涵盖数学、代码、逻辑的题目，分别用 think 模式和强制直出模式（在 system prompt 中要求模型不要使用 think 标签）回答。

结果很明显：

数学和逻辑推理的提升最大，这完全在预期之内。知识问答几乎没差别——这类题目不需要推理，模型要么知道要么不知道，想再久也没用。

但 think 模式也有代价：推理 token 数量会增加，意味着响应时间更长、成本更高。一般来说，think 部分的 token 数在几百到几千不等，最多可以到 30K tokens。在时间敏感的应用场景里，这个额外开销需要权衡。

5000 万训练样本的底气

Hermes 4 的训练数据量相比前代有了质的飞跃——从之前的几十万样本级别扩展到了 5000 万个训练样本。这个数据量在开源微调模型中是极其罕见的。

数据的构成大致包括：

• 大规模合成的推理链数据（让模型学会”怎么想”）
• 经过验证的数学解题过程
• 代码生成和 debug 的成对数据
• 多轮对话和 ChatML格式 的交互数据
• function calling 和 agent 场景数据

这也是为什么 Hermes 4 能同时在推理和对话两个方向上都表现出色的原因——训练数据足够多样和充分。cocoloop 社区有人分析过，5000 万样本如果全部用人工标注的话，成本会是天文数字，所以合成数据在其中占了很大比例，但合成的质量控制做得不错。

和其他推理模型的横向比较

既然 Hermes 4 的推理能力这么强，那和其他推理模型比起来如何？

vs OpenAI o1：o1 的推理能力目前仍然是天花板级别的，特别是在数学和科学领域。Hermes 4 在中等难度问题上和 o1 差距不大，但在顶级竞赛难度的题目上还有差距。不过 Hermes 4 胜在开源、可部署、推理过程透明。

vs DeepSeek-R1：两者定位很像，都是强调推理的开源模型。在大部分基准测试上互有胜负。Hermes 4 在 function calling 和 agent 场景上更强，DeepSeek-R1 在纯数学和科学推理上稍有优势。

vs QwQ：通义千问的 QwQ 也是混合推理路线。从社区反馈来看，两者各有千秋，但 Hermes 4 的 多版本覆盖 让用户有更多选择空间。

实际使用建议

用了两周之后，我总结了一些实际使用的心得：

适合开启 think 模式的场景：

• 数学作业批改和辅导
• 代码审查和 bug 定位
• 需要逻辑严密的文案（合同、法律文书等）
• 复杂的数据分析

建议关闭 think 模式的场景：

• 实时聊天机器人（响应速度优先）
• 简单的翻译和文本处理
• 批量化的模板生成任务

部署建议：

• 14B 版本适合个人和小团队，量化后可以在单卡上跑
• 70B 版本是生产环境的首选平衡点
• 405B 版本适合追求极致质量且不差算力预算的场景

还有哪些不足

客观说，Hermes 4 也不是没有问题：

1. 思考过程偶尔冗余：有些简单问题模型也会进入长篇思考，浪费 token
2. think 标签偶尔格式混乱：极少数情况下，think 标签没有正确闭合，导致思考内容泄露到正式回答里
3. 中文推理能力弱于英文：虽然基础对话的中文很流畅，但在复杂数学推理中，英文 prompt 的表现明显好于中文
4. 推理链偶尔自相矛盾：在特别复杂的问题上，think 中的推理过程偶尔会前后矛盾，但最终答案可能碰巧是对的

这些问题不算致命，但在生产环境中需要注意。特别是 think 标签的格式问题，如果你在做后处理解析的话需要做好容错。

我的整体评价

Hermes 4 的混合推理模式是开源模型的一个重要里程碑。它让普通开发者也能用上类似 o1 的推理能力，而且还能看到完整的思考过程。

如果你的应用场景对推理质量有要求，Hermes 4 大概是目前开源方案中的最优选择之一。如果对 Hermes 的基准测试成绩 感兴趣，可以参考我另一篇文章，那里有更详细的跑分解读。

一句话概括：Hermes 4 把”会想”这件事做到了开源模型的前列，虽然还不完美，但已经足够实用。

延伸阅读：OpenClaw 社区资源

本文由 CocoLoop 中文社区出品。如果你在研究 AI Agent 与主流模型的工程化落地，姊妹站 OpenClaw 中文社区 也许会有帮助：

• AI 模型横向对比（Claude/GPT/DeepSeek/Kimi/千问）
• 10 大模型 Token 成本计算器

这件事为什么值得深聊？因为它触及了一个根本性的问题：大模型训练一定要靠集中的算力巨头吗？

Hermes 4.3 的基本参数

先把基本情况交代清楚：

• 基座模型：ByteDance Seed-OSS-36B
• 参数量：36B
• 上下文窗口：512K tokens
• 训练方式：Psyche 去中心化训练网络
• 训练节点：24 个分布式节点
• 共识机制：基于 Solana 区块链

看到这些参数，可能很多人的第一反应是”什么？字节的模型？还区块链？”别急，一个一个说。

为什么选 ByteDance Seed-OSS-36B

Hermes 系列之前一直用 Meta 的 Llama 系列作为基座。从初代 Hermes 的 LLaMA 13B，到 Hermes 3 的 Llama 3.1 405B，一路走来和 Llama 家族深度绑定。

Hermes 4.3 换到 ByteDance 的 Seed-OSS-36B，这个选择背后有几层考量：

参数效率：Seed-OSS-36B 的架构在 36B 参数量下就能达到很高的基础能力。Nous Research 的测试显示，在这个基座上微调后的 Hermes 4.3 性能可以和 Hermes 4 70B 持平——用一半参数达到同等效果，这在推理部署成本上是实打实的优势。

架构创新：Seed-OSS-36B 在注意力机制和 FFN 层的设计上有一些独到的优化，特别是在处理长序列时效率更高。这也是为什么 Hermes 4.3 能支持 512K 上下文窗口的基础之一。

开源许可：Seed-OSS 系列采用的开源许可证对商业使用比较友好，这和 Nous Research 推动开源 AI 的理念一致。

cocoloop 社区里讨论过这个选择，不少人最初持怀疑态度——毕竟 Llama 才是社区公认的”国民基座”。但从结果来看，换基座的决策是成功的。

Psyche 网络：去中心化训练的原理

好了，重头戏来了。Psyche 是什么？

简单说，Psyche 是一个去中心化的模型训练网络。传统的模型训练需要把所有 GPU 集中在一个数据中心里，通过高速互联（比如 NVLink、InfiniBand）连接起来。但 Psyche 的思路不同——它把训练任务分发到地理上分散的多个节点，每个节点贡献自己的算力，共同完成一个模型的训练。

这和联邦学习有什么区别？

很多人一听”去中心化训练”就想到联邦学习（Federated Learning）。但 Psyche 和联邦学习有本质区别：

联邦学习的核心是数据不出本地，各节点用本地数据训练本地模型，然后把梯度或模型更新发送到中心服务器做聚合。它解决的是数据隐私问题。

Psyche 解决的是另一个问题——算力的去中心化获取。训练数据是统一分发的（Nous Research 准备好了训练数据集），各节点看到的是同一批数据，但计算过程是分布式的。

24 个节点怎么协同工作

Hermes 4.3 的训练使用了 24 个 Psyche 节点。每个节点配备了高端 GPU（主要是 H100 和 A100），但这些节点分布在不同的地理位置，网络延迟和带宽都和传统数据中心内部差很多。

要让这些节点高效协同，Psyche 做了几个关键设计：

异步梯度聚合：不要求所有节点同步更新梯度。每个节点按自己的速度计算，完成一个 batch 后就提交梯度更新。系统会智能地处理不同节点之间的进度差异。

梯度压缩：节点之间传输的不是完整的梯度张量，而是经过压缩的梯度信息。这大幅减少了网络传输量，让低带宽连接也能参与训练。

容错机制：如果某个节点掉线或出错，系统会自动把它的工作重新分配给其他节点，不会导致整个训练中断。

Solana 区块链在这里干什么

这可能是最让人困惑的部分。为什么模型训练要扯上区块链？

Psyche 使用 Solana 区块链作为共识层，主要解决的是”信任”问题。具体来说：

训练记录的不可篡改：每一轮训练的关键信息（比如哪些节点参与了、每个节点提交了什么梯度更新、最终的聚合结果是什么）都会记录在 Solana 链上。这确保了训练过程的透明和可追溯。

节点激励机制：参与训练的节点需要获得报酬。Solana 的智能合约可以根据节点的实际贡献（算力贡献、在线时长等）自动分配奖励，不需要人工干预。

防作弊：去中心化训练的一个风险是有节点可能提交虚假的梯度更新来骗取奖励。Solana 上的验证机制可以检测和惩罚这类行为。

选择 Solana 而不是以太坊或其他链，主要是因为 Solana 的交易速度快（出块时间约 400 毫秒）、Gas 费低，适合训练过程中高频率的记录操作。

512K 上下文窗口的实际意义

Hermes 4.3 支持 512K tokens 的上下文窗口，这是 Hermes 系列上下文长度进化 中的最新里程碑。

512K tokens 有多长？大概相当于一本 40-50 万字的中文小说，或者一个中型代码项目的全部源代码。

但数字好看是一回事，实际能不能用好是另一回事。长上下文的常见问题有两个：

“中间遗忘”问题：很多声称支持长上下文的模型，实际上在中间段落的信息检索和利用上会大幅下降。只有开头和结尾的信息能被可靠地使用。

推理成本：上下文越长，注意力计算的成本越高（理论上是 O(n^2)）。512K 的推理成本会比 8K 高出很多。

Hermes 4.3 在这两个问题上做了针对性优化。Seed-OSS-36B 基座本身在长序列建模上就有架构级别的改进，再加上 Nous Research 在微调阶段加入的长文档训练数据，512K 不是一个纸面数字——在实际的”大海捞针”（Needle-in-a-Haystack）测试中，Hermes 4.3 的检索准确率在整个 512K 范围内都保持在相当高的水平。

实际使用中，512K 上下文最有价值的场景包括：

• 完整代码库的分析和重构
• 长文档的总结和问答
• 多文件的交叉引用分析
• 超长对话的上下文保持

性能对比：36B 打平 70B

这是 Hermes 4.3 最让人印象深刻的地方。

Nous Research 公布的基准测试数据显示，Hermes 4.3（36B 参数）在多项测试上和 Hermes 4 70B 打平，个别项目甚至超出。

这意味着什么？对于部署来说，36B 的模型比 70B 小了将近一半：

• 显存需求降低：BF16 下大约 72GB vs 140GB
• 推理速度提升：更小的模型意味着更快的 token 生成速度
• 部署成本降低：可以用更少的 GPU 卡来服务

对于实际用户来说，能用一台 A100 80GB（或两张 A6000 48GB）跑起来的 Hermes 4.3，提供的质量和需要两台 A100 的 Hermes 4 70B 差不多，这在成本效益上是很大的进步。

当然，”打平 70B”需要加一些限定条件。在某些特定任务上（比如顶级难度的数学题、极度复杂的逻辑推理），70B 的额外参数量还是能带来可感知的优势。36B 打平 70B 更多体现在综合能力的平均水平上。

去中心化训练的局限性

虽然 Hermes 4.3 的训练成功证明了去中心化的可行性，但这条路目前还有不少限制：

训练效率：和传统的数据中心内部训练相比，去中心化训练的效率还是低不少。节点间的网络延迟、梯度压缩带来的信息损失、异步更新的收敛速度等问题，都会让总训练时间更长。

适用规模：Hermes 4.3 的 36B 参数量在去中心化训练的范畴里已经算大的了。如果要训练更大的模型（比如 100B+），目前的 Psyche 网络架构可能需要做重大升级。

数据传输：虽然梯度可以压缩传输，但训练数据本身的分发仍然是个挑战。5000 万训练样本的总数据量不小，需要高效的分发机制。

节点质量参差不齐：不同节点的 GPU 型号、显存大小、网络条件都不一样，如何高效地在异构环境中做负载均衡是个技术难题。

对未来的影响

Hermes 4.3 是第一个用 Psyche 去中心化网络训练出来的 production-grade 模型。它的成功意味着几件事：

算力民主化：不一定非得有自己的 GPU 集群或者租得起大型云计算实例才能训练大模型。分散的算力资源也可以聚合起来完成任务。

新的合作模式：想象一下，多个中小机构各自贡献一部分算力，共同训练一个大模型，然后共享使用权。这种合作模式在之前是不可能的。

对算力垄断的挑战：目前大模型训练的算力高度集中在几家大型云服务商手里。去中心化训练如果成熟起来，可能会改变这个格局。

但也要清醒地认识到，去中心化训练目前还在非常早期的阶段。Hermes 4.3 的 24 个节点训练更像是一个概念验证（proof of concept），距离成为主流训练方式还有很长的路要走。

如果你对 Hermes 入门 知识感兴趣，建议从基础概念开始了解，再来看这些前沿的训练技术会更容易理解。

怎么看这个模型

Hermes 4.3 在产品层面是一个很实用的模型——36B 参数、512K 上下文、性能对标 70B，部署友好。无论你是不是对去中心化训练感兴趣，光看模型本身的素质，它都是一个值得试试的选择。

而在技术层面，它是 Nous Research 对”模型训练的未来应该是什么样”这个问题给出的一个大胆回答。去中心化训练能不能成为主流？现在判断还太早。但至少 Hermes 4.3 证明了，这条路是走得通的。

今天回过头来看 Hermes 2 Pro 的这段历史，能更好地理解整个开源 agent 生态是怎么一步步建起来的。

背景：2024 年初的 Function Calling 格局

2024 年初，如果你想在应用中用 Function Calling，选择基本就一个——OpenAI 的 GPT-3.5/GPT-4 API。ChatGPT 在 2023 年中就已经支持了函数调用功能，开发者可以在 API 请求中定义一组函数（包括函数名、参数类型、描述），模型会根据用户的意图判断是否需要调用函数，并生成符合格式的调用请求。

这个功能对于构建 AI agent 来说至关重要。没有 Function Calling，模型就只能输出文本，无法和外部工具、数据库、API 产生实际交互。有了 Function Calling，模型才真正成为一个”能做事”的 agent。

但问题是——OpenAI 的方案是闭源的。你必须用他们的 API，遵守他们的使用条款，忍受他们的定价。对于想在本地部署 agent 的开发者来说，这条路走不通。

当时开源社区也有一些尝试，比如 Gorilla、ToolLLaMA 等项目，但大多停留在研究阶段，实际用起来坑比较多：格式不统一、生成的 JSON 经常出错、对复杂函数签名的理解很差。

就是在这个背景下，Nous Research 推出了 Hermes 2 Pro。

为什么选 Mistral 7B 作为基座

Hermes 2 Pro 的基座是 Mistral 7B，这个选择在当时看来挺精准的。

Mistral 7B 在 2023 年底发布时是一匹黑马。这个来自法国初创公司 Mistral AI 的 7B 模型，在多项基准测试上打赢了 Llama 2 13B——用更少的参数实现了更好的性能。它的滑动窗口注意力（Sliding Window Attention）设计也让推理效率更高。

对于 Hermes 2 Pro 这样以 Function Calling 为主打功能的模型来说，7B 的参数量是个甜蜜点：

• 部署门槛低：量化后可以在消费级 GPU 甚至 CPU 上运行，让更多开发者能用上
• 推理速度快：Function Calling 的场景通常对延迟敏感（用户在等模型决定要不要调工具），小模型的速度优势很明显
• 基座质量够用：Mistral 7B 的基础能力足以支撑函数调用所需的 JSON 生成、意图识别、参数提取等任务

Function Calling 训练数据是怎么做的

这可能是 Hermes 2 Pro 最有技术含量的部分——训练数据的构建。

Function Calling 不像普通的问答对话，你不能光给模型看一堆”问题-答案”对就指望它学会。它需要理解一套完整的交互协议：

1. 接收用户请求
2. 判断是否需要调用工具
3. 如果需要，从可用工具列表中选择正确的工具
4. 生成符合函数签名的 JSON 调用请求
5. 接收工具返回的结果
6. 基于结果生成最终回答

每一步都可能出错，所以训练数据需要覆盖各种边界情况。

Nous Research 的做法是建一套数据合成流水线：

第一步：定义工具库。收集了各种真实世界的 API 定义，包括天气查询、数据库操作、搜索引擎、日历管理等数十个类别。每个工具都有完整的函数签名（名称、参数列表、返回类型、描述）。

第二步：生成对话场景。用 GPT-4 等强模型生成大量自然语言请求，这些请求对应不同的工具调用场景。不光生成需要调工具的场景，还有大量不需要调工具的普通对话，让模型学会区分。

第三步：生成正确的调用序列。对于每个需要调工具的场景，生成正确的工具选择、参数填充和调用 JSON。这一步需要严格验证 JSON 格式的正确性——格式错一个逗号，整个调用就会失败。

第四步：生成多步调用链。很多真实场景需要连续调用多个工具。比如”帮我查明天北京的天气，然后根据天气推荐穿搭”，这就需要先调天气 API，再根据结果调推荐 API。这类多步骤的训练数据构建起来更复杂，但对实际应用至关重要。

第五步：加入错误处理。工具调用不一定总成功——API 可能返回错误、参数可能不合法、用户的请求可能不完整。训练数据中需要包含这些异常场景，让模型学会如何优雅地处理失败情况。

整个数据构建过程中，格式采用的是 ChatML 模板，工具定义和调用结果都嵌入在对话流中。这确保了模型在推理时能保持一致的格式输出。

90% 的评估得分代表什么

Hermes 2 Pro 在 Function Calling 的评估中拿到了约 90% 的得分。这个数字需要放在上下文里理解。

评估方法大致是这样的：给模型一批测试用例，每个用例包含一个用户请求和可用的工具列表。模型需要：

1. 正确判断是否需要调用工具（不该调的时候调了，或者该调的时候没调，都算错）
2. 选择正确的工具（工具列表里可能有 5-10 个工具，模型要选对）
3. 生成正确的参数（参数名、参数类型、参数值都要对）
4. 输出合法的 JSON（格式必须完全正确，能被解析器解析）

90% 的得分意味着在这些维度的综合评估中，模型有九成的概率能给出正确的输出。

这个成绩在当时的开源模型中是相当亮眼的。作为对比，同期其他开源模型在类似评估中的得分大多在 50-70% 之间。90% 意味着 Hermes 2 Pro 已经从”玩具级别”跨越到了”生产可用”的门槛。

但也要诚实地说，这个评估的测试集规模和覆盖面有限。在一些极端复杂的场景下（比如嵌套的 JSON 参数、需要类型转换的参数、含有特殊字符的字符串参数），实际表现可能没有 90% 那么理想。

JSON Mode：另一个重要特性

除了 Function Calling，Hermes 2 Pro 还引入了一个叫 JSON Mode 的功能——强制模型输出合法的 JSON 格式。

这个功能看起来简单，但在实际开发中极其有用。大模型输出 JSON 的时候经常”加戏”——在 JSON 前面加一段说明文字、在 JSON 里混入注释、或者干脆输出一个格式不完整的 JSON。这些对于需要程序化解析输出的应用来说都是灾难。

Hermes 2 Pro 的 JSON Mode 通过在训练数据中加入大量”纯 JSON 输出”的样本来解决这个问题。配合适当的系统提示，模型可以稳定地输出干净的 JSON，不加多余的文字。

这个特性让 Hermes 2 Pro 不仅适合做 agent，也适合做结构化数据提取——比如从一段非结构化文本中提取出特定字段并以 JSON 格式输出。

在 Agent 生态中的位置

Hermes 2 Pro 发布后，很快成为了多个 agent 框架的推荐本地模型。

在 LangChain 社区里，有不少开发者分享了用 Hermes 2 Pro 搭建本地 agent 的教程和经验。它的 Function Calling 格式和 OpenAI 的比较接近，迁移成本低。

在 AutoGen 这样的多 agent 框架里，Hermes 2 Pro 也能充当本地的 LLM 后端。虽然在复杂的多 agent 协作场景中，7B 模型的推理能力有时候不够用，但作为成本敏感场景的替代方案，它是完全可行的。

cocoloop 社区也有用户分享过用 Hermes 2 Pro 搭建个人知识库 agent 的实践。搭配 RAG（检索增强生成）框架，用 Function Calling 来调用搜索和数据库查询接口，效果出乎意料地好——在私有数据上的表现甚至比直接用 GPT-3.5 更好（因为 RAG 的质量主要取决于检索部分，而不是模型大小）。

技术局限性

回顾的时候也得说说不足：

复杂函数签名的处理：当函数参数涉及嵌套对象、数组、枚举类型等复杂结构时，Hermes 2 Pro 的准确率会下降。7B 的参数量在处理这种复杂结构化输出时确实力不从心。

多步调用的规划能力：在需要连续调用 3 个以上工具的场景中，模型的规划（planning）能力不够强，容易在中间步骤出错或遗漏。

错误恢复：当工具调用返回错误时，模型有时候不能很好地理解错误信息并做出合理的重试或替代方案。

上下文长度限制：基于 Mistral 7B 的上下文窗口比较有限，当工具描述很长或者对话历史很长时，模型的表现会受影响。这个问题在后来的 Hermes 4 版本 中得到了很大改善。

它为后来铺了什么路

Hermes 2 Pro 最大的贡献不是某个具体的跑分数字，而是它证明了一件事：开源 7B 模型也能做好 Function Calling。

这个结论的意义在于：

降低了 agent 开发的成本门槛。之前只能用 OpenAI API 来做 agent，现在可以在本地跑了。不用担心 API 费用、不用担心数据发送到第三方服务器。

推动了开源社区的 Function Calling 标准化。Hermes 2 Pro 采用的 ChatML + Function Calling 格式后来被很多其他模型借鉴，逐渐形成了社区的事实标准。

为 Hermes 3 和 Hermes 4 的工具调用能力奠定了基础。后续版本在 Function Calling 上的持续改进，很大程度上是在 Hermes 2 Pro 建立的数据管线和评估框架上迭代的。

从 Nous Research 的角度来说，Hermes 2 Pro 也是他们从”做微调模型”到”做 AI agent 基础设施”转型的一个关键节点。在此之前，Hermes 主要以对话质量著称；从 Hermes 2 Pro 开始，工具调用成为了 Hermes 的核心竞争力之一。

现在还值得用吗

坦率地说，如果你现在（2026 年）要做一个 agent 项目，直接用 Hermes 2 Pro 大概不是最优选择了。后续的 Hermes 4 在 Function Calling 上全面超越了它，而且还加上了混合推理能力。

但 Hermes 2 Pro 在一些特定场景下仍然有价值：

• 极度资源受限的环境：只有一张 8GB 显存的显卡？量化后的 Hermes 2 Pro 可以流畅运行
• 简单的单步工具调用：如果你的 agent 只需要做简单的 API 调用（比如查天气、查汇率），Hermes 2 Pro 完全够用
• 教学和学习目的：想理解 Function Calling 的工作原理，Hermes 2 Pro 的 7B 规模让你可以快速实验和调试

对 Hermes 系列完整的发展脉络感兴趣的话，可以看 Hermes 模型进化全记录，那里有从 2023 年到现在每个版本的详细解读。

回头看，Hermes 2 Pro 就像开源 Function Calling 领域的一块奠基石。它不是最强的，但它出现在了最需要它的时候，给后面所有的工作指了一条可行的路。

这篇文章把 Hermes 的每一个重要版本按时间线梳理一遍，看看每次跃迁背后做了哪些关键决策。

2023 年中：初代 Hermes（LLaMA 13B）

故事要从 2023 年 Meta 泄露 LLaMA 权重说起。当时整个开源社区都炸了锅——第一次有商业级别的大模型权重流入社区，各种微调模型如雨后春笋般冒出来。

Ryan Teknium 在这个时间点推出了初代 Hermes，基座是 LLaMA 13B。在当时几十个微调模型中，Hermes 能脱颖而出有几个原因：

训练数据质量高：Ryan 花了大量时间手动策划和清洗训练数据，而不是随便抓一堆网上的指令数据就开训。在那个年代，很多微调模型的质量问题不出在方法上，而出在数据上。

对话质量出众：Hermes 在自由对话和角色扮演方面表现特别好。它不像很多模型那样死板地遵循指令格式，而是能进行更自然、更流畅的对话。这让它在 Reddit 和 Discord 社区里迅速积累了口碑。

减少不必要的拒绝：初代 Hermes 就已经体现了 Nous Research 的核心理念——模型应该尽量回答用户的问题，而不是动不动就拒绝。当时很多模型因为安全对齐做得太严格，经常拒绝回答完全正常的问题。Hermes 在这方面的表现明显更好。

这个阶段的 Hermes 还比较原始——没有 Function Calling、没有特殊的对话格式、也没有做偏好优化。但它在对话质量上的优势已经足够让它在社区里站稳了脚跟。

2023 年底：OpenHermes 和数据集的开源

Ryan Teknium 做了一个对整个社区影响很大的决定——开源 OpenHermes 数据集。

这个数据集包含了 300K+ 条合成指令数据，使用 GPT-4 等强模型生成。它不仅是 Hermes 系列的训练基础，也成为了社区里最被广泛使用的合成数据集之一。

OpenHermes 数据集的开源意味着：其他研究者可以基于它来训练自己的模型，也可以分析它来理解好的训练数据长什么样。这大大推动了整个社区在合成数据方面的研究和实践。

同期，基于这个数据集训练的 OpenHermes 2.5 模型也获得了大量关注。

2024 年初：Hermes 2 Pro（Mistral 7B）

2024 年初，Hermes 迎来了一个重要的功能性转折——Hermes 2 Pro 的发布。

这个版本基于 Mistral 7B，最大的亮点是引入了 Function Calling 能力，在评估中拿到了约 90% 的得分。

关键改进：

• Function Calling：模型能根据用户意图选择正确的工具并生成合法的 JSON 调用请求
• JSON Mode：强制输出合法 JSON 格式的能力
• ChatML 格式：全面采用 ChatML 作为对话模板，为后续的 agent 生态打下基础

Hermes 2 Pro 的意义不只是一个更好的模型——它标志着 Hermes 从”对话模型”向”agent 模型”的战略转型。从这个版本开始，工具调用成为了 Hermes 系列的核心竞争力之一。

这个阶段还有一个有趣的细节：Hermes 2 Pro 选择了 Mistral 7B 而不是 Llama 2 作为基座。在那个时间点，Mistral 7B 在同参数量级确实表现更好。这也说明 Nous Research 在基座选择上不盲目追随主流，而是根据实际性能做决策。

2024 年 8 月：Hermes 3（Llama 3.1 8B/70B/405B）

Hermes 3 是整个系列最具里程碑意义的一次更新。

基于 Meta 在 2024 年 7 月发布的 Llama 3.1，Hermes 3 推出了 8B、70B 和 405B 三个版本。其中 405B 是开源社区首个 Llama 3.1 405B 的全参数微调模型。

关键改进：

• 405B 全参数微调：使用 Lambda Cloud 的 H100 集群完成，证明了开源团队也能训练最大规模的模型
• Individual Alignment：正式提出”个体对齐”理念，通过系统提示让用户控制模型行为边界
• 多步 DPO 优化：在 SFT 之后加入了 Direct Preference Optimization，提升了对话质量和指令跟随能力
• 多语言增强：受益于 Llama 3.1 基座的多语言能力，中文等非英语表现有明显改善

Hermes 3 的 405B 版本让整个社区看到了一种可能性：开源模型不仅能在小模型上做出好的微调，在数百亿参数的超大模型上也可以。

从下载量来看，Hermes 3 系列也是整个 Hermes 家族中被使用最多的版本之一。截至到现在，8B 版本由于部署友好，下载量远超 70B 和 405B。

2025 年初：Hermes 4（Llama 3.1 14B/70B/405B）

如果说 Hermes 3 的主题是”规模”，那 Hermes 4 的主题就是”推理”。

Hermes 4 引入了混合推理模式（Hybrid Reasoning），这是整个系列最大的架构级创新。模型可以在 <think> 标签中进行内部推理，然后再给出最终答案。

关键改进：

• 混合推理模式：自动判断问题复杂度，决定是否启动深度思考
• 推理 token 上限 30K：支持长达 30,000 tokens 的推理过程
• 训练数据扩展到 5000 万样本：相比前代有数量级的提升
• 新增 14B 版本：填补了 8B 和 70B 之间的空白
• 基准测试大幅提升：MATH-500 得分 96.3%，AIME 2024 得分 81.9%

Hermes 4 还有一个值得关注的点：它在 RefusalBench 上的表现（57.1%，远超 GPT-4o 的 17.67%），进一步强化了 Hermes 系列”减少不必要拒绝”的品牌定位。

5000 万训练样本的数据量也是一个里程碑。这背后涉及到大规模的数据合成、清洗和质量验证流水线，这些基础设施的建设本身就是很大的工程投入。

2025 年中：DeepHermes

在 Hermes 4 发布不久后，Nous Research 还推出了 DeepHermes——一个专门强化了深度推理能力的变体。

DeepHermes 和 Hermes 4 的区别在于：Hermes 4 的推理是”混合”的（可以选择是否思考），而 DeepHermes 默认就会进行深度推理。它更适合数学、科学、编程这些对推理质量要求极高的场景。

可以把 DeepHermes 理解为 Hermes 4 的”理科生”版本——牺牲了一些闲聊的自然度，换取更强的推理表现。

2025 年：Hermes 4.3（Seed-OSS-36B + Psyche）

最新的 Hermes 4.3 同时在两个维度上做了突破：

基座模型的突破：首次离开 Llama 家族，采用 ByteDance 的 Seed-OSS-36B 作为基座。36B 参数量的模型在多项测试上打平了 Hermes 4 70B。

训练方式的突破：首次使用 Psyche 去中心化训练网络完成训练，24 个分布式节点通过 Solana 区块链进行协调。

关键改进：

• 512K 上下文窗口：Hermes 系列最长，足以处理整本书级别的文本
• 36B 参数打平 70B 性能：部署成本大幅降低
• 去中心化训练验证：证明了非集中式 GPU 集群也能训练出高质量模型

Hermes 4.3 代表了 Nous Research 对未来两个方向的探索：更高效的模型架构，和更开放的训练基础设施。

各版本关键参数一览

几条贯穿始终的线索

纵观 Hermes 的进化史，有几条线索始终没变：

数据为王：从初代 Hermes 的精心策划数据，到 OpenHermes 的 300K 合成指令，再到 Hermes 4 的 5000 万样本。Nous Research 在训练数据上的投入始终是核心竞争力。

用户自由优先：从初代减少不必要拒绝，到 Hermes 3 的 Individual Alignment，到 Hermes 4 在 RefusalBench 上的突出表现。让用户有更多的控制权，一直是 Hermes 的设计哲学。

实用导向：每次更新都有明确的”能让用户多做一件事”。Hermes 2 Pro 让用户能做 Function Calling，Hermes 4 让用户能做深度推理，Hermes 4.3 让用户能处理超长文本。不是为了刷分而刷分。

基座选择灵活：LLaMA → Mistral → Llama 3.1 → Seed-OSS-36B。Nous Research 不绑定任何一个基座模型厂商，哪个好用就用哪个。

Hermes 的社区影响

在 cocoloop 社区里，Hermes 一直是讨论度最高的开源模型系列之一。原因很简单——它的每个版本都有足够多的”谈资”：

• Hermes 3 发布时，大家讨论的是”405B 全参数微调”的可行性
• Hermes 4 发布时，大家讨论的是”开源模型也能思考了”
• Hermes 4.3 发布时，大家讨论的是”去中心化训练”和”512K 上下文”

这种持续产出话题的能力，让 Hermes 在社区里保持了很高的存在感。

从更宏观的角度看，Hermes 系列的进化也反映了整个开源 LLM 社区的发展轨迹：从简单的指令微调，到 Function Calling 和 agent 能力，到深度推理，到去中心化训练。每一步 Hermes 不一定是第一个做的，但每一步它都做到了社区里最好的水平之一。

如果你是 Hermes 的新用户，建议从最新的 Hermes 4 或 4.3 开始体验。但了解这段进化史，会帮助你更好地理解这些模型为什么是现在这个样子。

可能你只是想问一个关于化学反应的问题，模型却说”我不能提供可能被用于制造危险物质的信息”。或者你想写一个虚构的犯罪小说场景，模型告诉你”我无法协助创作涉及暴力的内容”。

这种现象叫做”过度拒绝”（Over-refusal），是当前大模型领域一个被讨论得越来越多的问题。而 RefusalBench，就是专门用来衡量模型过度拒绝程度的基准测试。

Hermes 4 在 RefusalBench 上拿到了 57.1% 的得分，而 GPT-4o 只有 17.67%。这个差距意味着什么？这篇文章来好好聊聊。

RefusalBench 在测什么

先理解一下 RefusalBench 的设计逻辑。

RefusalBench 不是在测”模型有多不安全”，恰恰相反——它在测”模型有多不合理地拒绝正常请求”。

测试集里的每一个问题都是经过人工审核的、合法的、合理的用户请求。这些请求可能涉及一些敏感话题（医学、法律、历史上的冲突事件、虚构的暴力情节等），但它们的意图都是正当的——学术讨论、创意写作、知识查询等。

一个理想的模型应该回答所有这些问题，因为它们本身没有任何问题。但实际情况是，很多模型会因为关键词触发、话题敏感度过高等原因，直接拒绝回答。

RefusalBench 的评分很直接：模型正常回答了，就得分；模型拒绝了，就不得分。得分越高，说明模型越少过度拒绝。

为什么 GPT-4o 只有 17.67%

看到 GPT-4o 的 17.67%，很多人的第一反应是”这也太低了吧”。

但如果你经常用 GPT-4o，可能不会太意外。OpenAI 的模型在安全对齐上一直做得比较”激进”——宁可错杀三千，不可放过一个。这导致了大量的误拒绝。

几个常见的触发场景：

医学相关问题：问药物的作用机制、副作用、剂量信息，GPT-4o 经常会加上大量的免责声明，或者干脆建议你”咨询专业医生”而不给出实质性回答。

历史事件讨论：涉及战争、屠杀、恐怖主义等历史话题，即使是纯学术讨论的口吻，GPT-4o 也可能拒绝或给出极度模糊的回答。

创意写作中的”禁区”：虚构小说中的暴力场景、反派角色的对话、灰色地带的道德困境……这些在文学创作中完全正常的元素，GPT-4o 处理起来畏首畏尾。

涉及任何”危险”关键词的技术问题：密码学、网络安全、渗透测试……很多信息安全从业者反馈说 GPT-4o 对安全技术相关的问题过度敏感。

17.67% 的得分意味着，在 RefusalBench 的测试集中，GPT-4o 有超过 80% 的合理请求被拒绝或被不充分地回答。这个比例确实很惊人。

Hermes 4 的 57.1% 是怎么做到的

57.1% 不是一个完美的分数——说明 Hermes 4 也有将近一半的合理请求没能很好地回答。但相比 GPT-4o 的 17.67%，已经好了三倍多。

Hermes 4 能在 RefusalBench 上取得这个成绩，原因要追溯到 Nous Research 从初代 Hermes 就坚持的设计哲学——Individual Alignment（个体对齐）。

什么是 Individual Alignment

传统的模型对齐（alignment）思路是：模型开发者定义一套行为规范，模型必须遵守。哪些话题能讨论、哪些不能、用什么语气、什么时候该拒绝——这些都由开发者说了算。

Individual Alignment 的思路不同：模型的行为边界应该由使用者来定义，而不是开发者。

具体的实现方式是通过系统提示（system prompt）。用户可以在系统提示中详细说明模型应该遵循什么规则、在什么范围内可以自由回答。模型的任务是在这些用户定义的规则框架内，尽最大可能地满足用户需求。

这意味着：

• 一个医学研究人员可以在系统提示中指定”我是专业医学研究者，请提供详细的药物信息”
• 一个小说作者可以指定”我在创作虚构作品，请配合完成各种场景的描写”
• 一个教育工作者可以指定”请以学术口吻讨论敏感历史话题”

模型不需要自己判断”这个人是不是在干坏事”，只需要在用户给定的框架内工作。

训练层面的具体做法

在训练数据中，Hermes 4 做了几件关键的事：

大量减少拒绝样本的比例：在 SFT 数据中，降低了”用户问→模型拒绝”这类样本的比例。让模型学到的默认行为是”回答”而不是”拒绝”。

加入系统提示驱动的行为样本：训练数据中包含大量”系统提示定义规则→模型在规则内回答”的样本，让模型学会尊重系统提示的权威性。

DPO 偏好优化中的偏向：在 Hermes 4 的训练 偏好优化阶段，”合理回答但加注提醒” 比 “直接拒绝” 被标记为更优的回答。这让模型在遇到灰色地带时倾向于给出信息加上适度的提醒，而不是一刀切地拒绝。

过度拒绝为什么是个问题

有人可能会说：”模型谨慎一点有什么不好？宁可多拒绝，也别说错话啊。”

这种想法忽略了过度拒绝的几个实际危害：

降低实用性：一个动不动就拒绝的模型，用户体验会很差。当你每问三个问题就被拒绝一个，你对这个模型的信任和使用意愿会急剧下降。

把用户推向更不安全的替代品：当正规的商业模型拒绝回答一个合理问题时，用户不会放弃——他们会去找不做任何安全限制的模型，或者用各种”越狱”技巧来绕过限制。这反而增加了风险。

影响专业工作：医生、律师、安全研究员、记者、作家……这些职业的从业者需要讨论各种敏感话题。如果 AI 工具不能配合他们的专业需求，就失去了很大一部分价值。

产生虚假的安全感：一个拒绝率很高的模型看起来很”安全”，但这种安全是假的。真正的安全不是拒绝回答问题，而是在回答的同时提供准确的信息和适当的背景知识。

cocoloop 社区里也讨论过这个话题。一个比较有代表性的观点是：安全对齐应该像汽车的安全带，在你正常驾驶时几乎感觉不到它的存在，只在真正危险的时候发挥作用。而不是像一个每隔几分钟就踩急刹车的副驾驶。

安全与自由的光谱

这里需要做一个重要的区分：减少过度拒绝不等于不做安全限制。

Hermes 4 在 RefusalBench 上的 57.1%，不是因为它什么都不拒绝。它仍然会拒绝真正有害的请求——比如直接教人制造武器、生成 CSAM 内容、帮助实施诈骗等。这些硬性红线是不会因为 Individual Alignment 而放松的。

真正的区别在于灰色地带的处理方式。

传统的安全对齐对灰色地带采取的是”一刀切”策略：只要话题沾边，就拒绝。Hermes 4 的做法更精细——区分请求的意图和上下文：

• 讨论毒物学知识？如果是学术语境，正常回答并标注信息来源
• 写暴力小说场景？如果系统提示明确了创作背景，配合完成
• 询问网络安全攻击手法？如果是渗透测试学习，给出技术细节并强调合法使用

这种做法需要模型有更强的上下文理解能力和意图识别能力。你不能光看关键词，还要理解整个对话的背景和目的。这对模型的训练质量提出了更高的要求。

其他模型在 RefusalBench 上的表现

除了 Hermes 4（57.1%）和 GPT-4o（17.67%），其他模型在 RefusalBench 上的表现也值得参考：

大多数主流商业模型的得分都在 20-30% 之间。这不是因为这些模型”更安全”，而是因为它们的安全对齐策略更保守。在被过度拒绝的请求中，绝大多数都是完全正当的问题。

开源模型的表现差异比较大。一些没怎么做安全对齐的模型得分可能很高（因为它们什么都不拒绝），但这不是 Hermes 追求的——Hermes 的目标是”精准拒绝”而不是”不拒绝”。

这对用户意味着什么

如果你是一个普通用户，RefusalBench 的成绩可能不是选模型的第一考量。但如果你的使用场景涉及以下任何一种，Hermes 4 的低拒绝率可能是一个重要优势：

• 专业领域的知识查询（医学、法律、安全等）
• 创意写作（小说、剧本、游戏剧情）
• 学术研究（涉及敏感历史事件、社会问题）
• 角色扮演和情境模拟
• 红队测试和安全研究

在这些场景中，一个过度拒绝的模型基本是废掉了大半武功。

关于 Individual Alignment 的争议

要公平地说，Individual Alignment 并不是没有争议。

批评者的主要担忧是：如果让用户自己定义行为边界，那恶意用户完全可以通过精心设计的系统提示来”解锁”模型的有害能力。比如在系统提示中伪装成医学研究者来获取制毒信息。

这个担忧不是没有道理。但 Nous Research 的回应是：

1. 硬性红线不受系统提示影响——某些内容无论什么系统提示都不会生成
2. 开源模型的使用者本身就有完整的模型控制权——如果有人想做坏事，他们可以直接修改模型，不需要通过系统提示来”越狱”
3. 安全的责任应该分布在整个链条上，而不是只压在模型层面——应用层的内容审核、法律法规的约束，同样是安全体系的一部分

这个辩论还在继续，没有标准答案。但 Hermes 选择的方向至少给了社区另一种思考安全问题的角度。

怎么在实际中利用这个优势

如果你选择使用 Hermes 4，想要充分利用它在安全自由度上的优势，一些实践建议：

写好系统提示：明确你的身份和使用场景。不是为了”绕过限制”，而是为了让模型更好地理解你的需求上下文。

利用 ChatML格式：ChatML 的结构化格式让系统提示的权威性更强，模型对系统提示中规则的遵循度更高。

合理预期：即使是 Hermes 4，在某些极端敏感话题上也可能拒绝。57.1% 的 RefusalBench 得分意味着仍有近一半的边界情况处理不够好。

结合应用层审核：如果你在构建面向公众的应用，不要完全依赖模型层面的安全——在应用层面加上自己的内容过滤和审核逻辑。

如果想更全面地了解 Hermes 4 的各项 基准测试表现，包括推理、知识和代码等方面，可以参考那篇专门的跑分解读文章。

最后的思考

RefusalBench 不只是一个跑分——它反映了 AI 行业对”什么是好的安全对齐”这个问题的持续争论。

过于激进的安全限制会损害模型的实用性，而过于宽松又会带来真实的风险。Hermes 选择的 Individual Alignment 路线，是在这两极之间尝试找到一个更灵活的平衡点。

57.1% vs 17.67%，这不只是一个数字的差距。它反映的是两种完全不同的安全哲学：一种认为安全应该由开发者严格控制，另一种认为安全可以在框架内交给用户来把握。

哪种更好？这个问题可能永远没有统一答案。但作为用户，有更多的选择总是好事。

Hermes 系列能从一众微调模型中脱颖而出，训练数据的质量是最关键的因素之一。今天就来聊聊 Hermes 背后的数据工程——从最早的 OpenHermes 数据集到 Hermes 4 的 5000 万样本，这些数据到底是怎么做出来的。

OpenHermes 数据集：300K 条合成指令

OpenHermes 是 Ryan Teknium 在 2023 年发布的开源数据集，包含超过 300,000 条合成指令数据。这个数据集不仅是 Hermes 系列的训练基础，也成为了开源社区最被广泛使用的指令微调数据集之一。

为什么是合成数据

首先解释一下为什么要用合成数据。

指令微调（Instruction Tuning）需要大量的”用户指令→模型回答”配对数据。获取这类数据有两种主要途径：

人工标注：雇人写指令和对应的高质量回答。优点是质量可控，缺点是成本极高、速度慢。OpenAI 在 InstructGPT 论文中披露的标注成本是每条数据几美元到几十美元不等。30 万条数据按这个价格算，成本在百万美元级别。

合成生成：用已有的强模型（比如 GPT-4）来生成训练数据。优点是成本低、速度快、可以大规模生产。缺点是可能引入源模型的偏差，以及存在”模型训模型”的质量衰减问题。

对于 Nous Research 这样的独立研究团队来说，百万美元级别的人工标注预算不现实。合成数据是唯一可行的大规模数据获取方式。

但合成数据不是随便生成就能用的。Ryan 在 OpenHermes 的构建上花了大量精力来确保质量。

数据生成的具体流程

OpenHermes 数据集的生成流程大致分为这么几步：

第一步：多样化的种子指令设计

合成数据最怕的就是”同质化”——如果种子指令的模式单一，生成出来的数据也会千篇一律。模型用这样的数据训练后，只会在某些特定模式上表现好，一遇到没见过的指令类型就傻眼。

Ryan 的做法是设计了几十个不同类别的种子指令模板，覆盖：

• 开放式问答（”解释量子纠缠的原理”）
• 创意写作（”写一个关于时间旅行的短故事”）
• 代码生成（”用 Python 实现一个链表”）
• 数据分析（”分析这组销售数据的趋势”）
• 角色扮演（”假设你是一个中世纪骑士，描述你的一天”）
• 多步推理（”如果所有鸟都会飞，企鹅是鸟，那企鹅会飞吗？解释你的推理过程”）
• 格式化输出（”把以下信息整理成一个 Markdown 表格”）

每个类别下又有多个变体，确保足够的多样性。

第二步：使用 GPT-4 生成回答

种子指令设计好后，用 GPT-4（以及其他强模型）来生成对应的高质量回答。这一步的关键在于提示工程——通过精心设计的系统提示来控制生成回答的风格、深度和格式。

比如，对于技术类问题，系统提示会要求模型给出详细的技术解释、必要的代码示例、以及潜在的注意事项。对于创意写作，则要求有完整的叙事结构、生动的描写和合理的情节发展。

第三步：质量过滤

不是 GPT-4 生成的每条回答都能用。质量过滤是整个流程中最关键的一步。

过滤的维度包括：

• 完整性检查：回答是否完整，有没有截断
• 格式检查：如果指令要求特定格式（JSON、表格、列表），回答是否符合
• 一致性检查：回答和指令是否对应，有没有”答非所问”
• 去重：剔除语义高度相似的样本
• 毒性过滤：排除含有有害内容的样本（但不是简单的关键词过滤，而是语义级别的）

这个过滤过程淘汰了相当比例的生成数据，最终留下来的 300K+ 条都是质量较高的样本。

第四步：人工抽检

在自动化过滤之后，Ryan 和团队还做了人工抽检——随机抽取一定比例的样本进行人工审核。这不是为了审核每一条数据（那不现实），而是为了发现自动化过滤中可能遗漏的系统性问题。

比如，如果某一类指令的生成质量系统性地偏低，人工抽检可以发现这个趋势，然后针对性地调整该类别的生成策略。

开源的意义

Ryan 选择把 OpenHermes 数据集完全开源，这个决定的影响超出了 Hermes 本身。

开源意味着：

• 其他研究者可以用这个数据集来训练自己的模型
• 社区可以分析数据集的构成，发现问题并提出改进建议
• 成为了合成数据研究的一个重要参考基准

事实上，OpenHermes 数据集后来被几十个其他开源项目引用和使用。在 Hugging Face 上，它是下载量最高的指令微调数据集之一。

cocoloop 社区里也有人基于 OpenHermes 做了自己的实验——比如过滤掉其中的中文样本重新训练，或者补充特定领域（法律、医学）的数据来做垂直场景的微调。这种社区驱动的二次创新，正是开源的价值所在。

从 300K 到 5000 万：Hermes 4 的数据扩展

如果说 OpenHermes 的 300K 样本是”精品小店”，那 Hermes 4 的 5000 万样本就是”工业化量产”。这中间的跨度不只是数量上的——整个数据工程体系都做了重大升级。

数据来源的多样化

5000 万样本不可能全靠一种方式生成。Hermes 4 的训练数据来自多个渠道：

扩展的合成指令数据：在 OpenHermes 的基础上，进一步扩大了指令模板的覆盖面和多样性。使用了多个不同的强模型（不只是 GPT-4）来生成回答，降低了对单一源模型的依赖。

推理链数据：Hermes 4 的一大特色是 混合推理能力。为了训练这个能力，需要大量的”思考过程→最终答案”格式的数据。这类数据的生成更复杂——不光要生成正确的答案，还要生成合理的推理过程。

具体做法是：给强模型一个问题，要求它在 <think> 标签中展示完整的推理过程，然后在标签外给出最终答案。生成后需要验证推理链的逻辑一致性和最终答案的正确性。数学题可以通过程序验证答案，但推理链的质量检查更多依赖于规则化的启发式方法。

Function Calling 数据：延续了 Hermes 2 Pro 的工作，但数据量和覆盖面大幅扩展。包括更多种类的工具定义、更复杂的多步调用链、以及更多的错误处理场景。

多轮对话数据：真实的用户交互很少是单轮的。Hermes 4 的训练数据中包含大量的多轮对话样本，让模型学会在长对话中保持上下文一致性。

代码数据：大量的代码生成、代码解释、代码 debug 数据。来源包括合成生成和从开源代码库中提取的代码片段及其文档。

数据清洗的工业化

300K 数据的清洗可以半手动地完成，5000 万数据就必须要有一套成熟的自动化管线了。

Hermes 4 的数据清洗管线包括：

去重管线：使用 MinHash + LSH（局部敏感哈希）算法来检测和去除语义重复的样本。不是简单的字符串匹配，而是在嵌入空间（embedding space）中计算相似度。

质量评分模型：训练了一个专门的质量评分模型（本身也是一个小型 LLM），对每条样本打分。分数低于阈值的直接丢弃。这个评分模型会考虑回答的完整性、准确性、格式规范性等多个维度。

毒性检测：使用多个毒性检测模型做交叉验证。只有所有检测模型都通过的样本才会保留。

领域平衡：确保不同领域的数据量大致平衡，避免模型在某些领域过度训练而忽略其他领域。这需要统计各领域的样本分布，然后做上采样或下采样。

格式标准化：所有数据统一转换为 ChatML 格式，确保对话模板的一致性。不同来源的数据可能有不同的格式约定，这一步把它们全部统一。

合成数据的”陷阱”

大规模使用合成数据也有一些需要警惕的问题，Hermes 团队在实践中也遇到过：

模式坍缩（Mode Collapse）：当大量数据都来自同一个源模型时，生成的数据可能过度集中在某些表达模式上。Hermes 4 通过使用多个不同的源模型来缓解这个问题。

错误放大：如果源模型在某个知识点上有错误，合成出来的数据也会包含这个错误。训练后的模型就会”学到”这个错误。对于事实性知识，需要额外的验证步骤。

分布偏移：合成数据的分布和真实用户请求的分布可能不一致。用户的真实请求往往更零散、更口语化、更不规范。如果模型只见过”完美”的合成指令，遇到真实用户的”不完美”输入时可能表现不佳。

为了缓解分布偏移，Hermes 4 的训练数据中也掺入了一些从真实用户交互中收集的数据（经过脱敏处理）。这些数据的质量可能不如合成数据那么”干净”，但它们更接近真实的使用场景。

数据作为护城河

在开源模型领域，架构和训练代码大家都可以复制，真正难复制的是高质量的训练数据。

Nous Research 通过多年积累建立起来的数据工程体系——从数据设计、生成、清洗到质量验证的整套管线——是 Hermes 系列的核心竞争力之一。即使他们开源了 OpenHermes 数据集，这套不断迭代的数据管线本身仍然是一个很大的技术壁垒。

从社区的角度看，OpenHermes 的开源已经极大地推动了指令微调领域的研究。而 Hermes 4 的 5000 万样本级别的数据集，虽然没有完全开源，但它的存在本身就证明了：独立研究团队在数据工程上是可以和大公司掰手腕的。

未来的数据趋势

从 Hermes 的数据演进中，可以看到几个明确的趋势：

合成数据将越来越重要：人工标注的成本天花板决定了，大规模训练数据的主要来源只能是合成。关键在于如何提升合成数据的质量和多样性。

推理链数据是新刚需：随着模型推理能力成为竞争焦点，高质量的推理过程数据（而不只是问答对）会越来越稀缺和珍贵。

数据质量 > 数据数量：5000 万样本不是终点，但盲目追求数量没有意义。一条高质量的推理链数据可能比一百条低质量的指令数据更有价值。

多模态数据的加入：虽然目前 Hermes 还是纯文本模型，但多模态训练数据（图文配对、视频描述等）的加入只是时间问题。

如果你想了解 Hermes 各版本的整体进化脉络，包括数据之外的架构和训练方法变化，可以查看 Hermes 模型进化全记录。

Hermes 系列从最初的 2K 一路扩展到 512K，每次扩展背后都涉及不少技术挑战和取舍。这篇文章把这段进化史捋一遍，顺便说说长上下文到底有什么实际用途。

先理解上下文窗口

在聊进化史之前，先把概念搞清楚。

上下文窗口指的是模型在一次推理中能处理的最大 token 数量。Token 不完全等于字或词——在英文中大约每个单词对应 1-2 个 token，在中文中每个字大约对应 1-2 个 token。

4K tokens 大约是 3000 个英文单词或 2000 个中文字，也就是一篇普通的文章长度。512K tokens 大约对应 40-50 万中文字，相当于一本厚书的篇幅。

上下文窗口是一个”硬限制”——超过这个长度的输入，模型直接无法处理。不是处理得不好，是完全不能接收。

各版本的上下文长度

可以看到，增长是非线性的——从 2K 到 4K 到 8K 的阶段比较平缓，到 Hermes 3 的 128K 是一次巨大的跳跃，而 Hermes 4.3 的 512K 又把上限拉高了四倍。

2K → 4K → 8K：循序渐进的阶段

初代 Hermes 基于 LLaMA 13B，后者的原始上下文窗口只有 2K。这在 2023 年初是很正常的——当时大部分开源模型的上下文窗口都在 2K-4K 之间。

2K 的限制其实挺明显的。你甚至不能把一篇稍微长一点的文章完整地喂给模型，更别提多轮对话的历史了——几轮对话下来，早期的内容就被截断了。

到了 OpenHermes 2.5 时期，上下文扩展到了 4K。这个提升主要来自于基座模型的改进——Meta 在后续版本中扩展了 LLaMA 的上下文能力。

Hermes 2 Pro 选择了 Mistral 7B 作为基座，上下文窗口来到了 8K。Mistral 7B 使用了滑动窗口注意力（Sliding Window Attention, SWA）机制来实现更长的上下文。SWA 的思路是：不让每个 token 都关注所有历史 token，而是只关注一个固定大小的窗口内的 token。通过多层网络的叠加，信息可以间接传递到更远的位置。

8K 对于 Function Calling 的场景来说基本够用了——工具定义 + 用户请求 + 对话历史通常不会超过这个长度。但如果要做长文档的分析或者需要维护很长的对话历史，就捉襟见肘了。

128K 的飞跃：Hermes 3 和 Hermes 4

Hermes 3 和 Hermes 4 都基于 Llama 3.1，上下文窗口直接跳到了 128K。这是一次质的飞跃。

128K tokens 约等于 10 万中文字，差不多是一部中篇小说的长度。这意味着你可以：

• 把一份完整的商业报告喂给模型做分析
• 维持几十轮的长对话而不丢失上下文
• 一次性处理多个代码文件

为什么 Llama 3.1 能做到 128K

Llama 3.1 实现 128K 上下文窗口主要依赖两个技术：

RoPE（旋转位置编码）的扩展：RoPE 是一种用频率来编码位置信息的方法。通过调整 RoPE 的频率基数（base frequency），可以在不改变模型架构的情况下扩展上下文窗口。Llama 3.1 把 RoPE 的基数从原来的 10,000 提高到了 500,000，理论上支持更长的序列。

渐进式训练：不是一步到位地在 128K 上训练，而是先在短序列上训练，然后逐步增加序列长度。这样模型可以平稳地”学会”处理长文本，不至于因为一开始就面对超长序列而训练不稳定。

Hermes 3 和 Hermes 4 在微调时也做了针对性的处理——训练数据中包含不同长度的样本，短的有几百 token，长的有几万 token。这让模型在各种长度下都能保持稳定的表现。

128K 的实际表现

128K 的上下文窗口在理论上很长，但实际使用中有几个需要注意的地方：

中间遗忘问题（Lost in the Middle）：有研究发现，即使模型支持很长的上下文，它在利用中间位置信息时的能力会明显下降。模型往往对开头和结尾的信息记得最清楚，中间的信息容易被忽略。

Hermes 4 在训练中做了一些缓解措施——比如在训练数据中故意把关键信息放在中间位置，让模型学会关注整个上下文而不是只看头尾。但这个问题并没有被完全解决。

推理成本的增长：标准的 Transformer 注意力机制的计算复杂度是 O(n^2)。128K 的推理成本大约是 8K 的 256 倍（不考虑 KV cache 等优化的话）。实际中会有各种优化手段（如 Flash Attention）来降低开销，但长上下文的推理仍然明显更慢、更贵。

不是每个任务都需要 128K：很多时候，把太长的内容塞进上下文不如做好预处理。比如用 RAG（检索增强生成）先检索出相关段落，只把必要的信息放进上下文。盲目追求长上下文有时候反而会降低质量。cocoloop 社区也有人做过实测对比，发现合理的 RAG 分段在很多场景下效果不亚于超长上下文。

512K：Hermes 4.3 的新纪录

Hermes 4.3 基于 ByteDance 的 Seed-OSS-36B，把上下文窗口推到了 512K。这是目前 Hermes 系列的最长记录。

512K tokens 约等于 40 万中文字。打个比方，《三体》三部曲加起来大约 88 万字——512K 的上下文窗口大约可以容纳半部《三体》。

512K 怎么实现的

Seed-OSS-36B 基座本身在架构层面就为长序列做了优化。具体的技术细节 ByteDance 没有完全公开，但根据公开的信息可以推断几点：

改进的注意力机制：可能采用了某种形式的稀疏注意力或线性注意力，让计算复杂度不再随序列长度呈二次增长。

分层的位置编码：在 RoPE 的基础上，可能引入了某种分层或分段的位置编码方案，让模型能更好地区分超长序列中的不同位置。

工程优化：512K 的推理对显存管理提出了极高的要求。KV cache（键值缓存）在 512K 序列下会占用巨量显存。可能使用了 PagedAttention、KV cache 量化等技术来控制显存使用。

大海捞针测试

评估长上下文模型有一个经典测试叫”Needle-in-a-Haystack”（大海捞针）。

测试方法是：在一段很长的文本（干草堆）中随机位置插入一条特定信息（针），然后让模型从整个文本中找到并回答关于这条信息的问题。通过改变文本长度和”针”的位置，可以画出一张热力图，展示模型在不同长度和不同位置上的检索能力。

Hermes 4.3 在这个测试中的表现：在整个 512K 范围内都保持了较高的检索准确率。中间位置稍有下降，但比同期的很多 128K 模型在中间位置的表现还要好。

这说明 512K 不是一个虚标——模型确实能有效利用这么长的上下文。

512K 的实际用途

那 512K 在真实场景中有什么用？

整个代码库的分析：一个中型项目的全部源代码可能在几十万 token 左右。512K 允许你一次性把大部分代码喂给模型，让它做全局的架构分析、bug 排查或重构建议。

长文档处理：法律合同、研究报告、技术文档——很多专业文档的长度在几万到几十万字之间。512K 的上下文可以容纳大部分这类文档，省去了分段处理的麻烦。

超长对话：在一些需要长期交互的场景（比如心理咨询模拟、教学辅导），512K 的上下文可以维持极长的对话历史，不用担心早期信息被遗忘。

多文档交叉分析：需要对比分析多个文档时，512K 允许你同时把多个文档放入上下文，而不是一个一个分开处理。

但也要理性看待——512K 的推理成本很高，不是所有场景都需要这么长的上下文。对于大多数日常使用，128K 已经绰绰有余。512K 更像是一个”极端场景的保险”。

长上下文的技术权衡

上下文窗口越长越好吗？不一定。这里面有几个重要的权衡：

推理速度 vs 上下文长度

上下文越长，推理越慢。即使用了 Flash Attention 等优化，128K 的推理速度也明显慢于 8K。在需要实时交互的应用（比如聊天机器人）中，过长的上下文可能导致用户等待时间不可接受。

显存占用 vs 上下文长度

KV cache 的显存占用和上下文长度成正比。512K 序列的 KV cache 可能需要几十 GB 的显存，这直接影响了可以同时服务的请求数量（吞吐量）。

注意力质量 vs 上下文长度

理论上，注意力机制可以让每个 token 关注到所有其他 token。但在实践中，超长的上下文会稀释注意力的精度——模型需要在 512K 个 token 中分配有限的注意力资源，有些信息不可避免地会被弱化。

训练成本 vs 上下文长度

支持更长上下文的训练本身也更昂贵。训练数据中需要包含足够多的长序列样本，每个长序列的训练成本都比短序列高很多。

给普通用户的建议

如果你在考虑选择哪个版本的 Hermes，上下文窗口可能是一个重要因素：

日常对话和简单任务：8K-128K 足够了。Hermes 4 的 14B 版本是个不错的选择，128K 上下文应付绝大多数场景都没问题。

需要处理长文档：128K 的 Hermes 4 可以处理大部分文档。只有在文档超过 10 万字的极端情况下才需要考虑 512K。

代码库级别的分析：如果你的项目代码量很大，Hermes 4.3 的 512K 会是最舒适的选择。

多文档对比分析：需要同时处理多个文档时，上下文窗口越大越方便。512K 让你可以一次性放入多个文档。

不管选哪个版本，一个通用的建议是：不要因为上下文窗口大就无脑把所有东西塞进去。合理地组织和精简输入信息，往往能得到更好的输出质量和更快的响应速度。

对于 Hermes 各版本的 整体演进和功能对比，可以参考那篇时间线文章，那里有每个版本的完整特性列表。而关于 Hermes 4 的 推理能力，在另一篇体验文章中有更详细的讨论。

上下文窗口的进化还在继续。从 2K 到 512K，短短两年多时间增长了 256 倍。下一步是什么？百万级？千万级？让我们拭目以待。

答案就两个字：推理。

o1 在生成最终答案之前，会先进行一段长长的内部推理过程。这个过程消耗大量的 token（也就是更多的计算时间），但换来的是质量上的巨大跃升。

这个思路很快被开源社区学了过去。DeepHermes 和 Hermes 4 就是 Nous Research 在这个方向上的尝试。今天来聊聊它们的推理机制到底是怎么工作的。

从 Chain-of-Thought 到 Think 标签

推理模型的概念并不是 o1 发明的。早在 2022 年，Google 的研究者就提出了 Chain-of-Thought（CoT，思维链）技术——通过在提示词中加入”请一步一步思考”之类的引导，让模型在回答之前先展示推理步骤。

CoT 的效果很明显：在需要多步推理的数学题和逻辑题上，加了 CoT 提示的模型比直接回答的模型准确率高出一大截。

但传统的 CoT 有一个问题——它是提示级别的（prompt-level）。你需要在提示词中告诉模型”请先想再答”，模型才会这么做。如果你不提示，模型就直接输出答案。而且，不同的提示措辞效果差异很大，这让 CoT 的表现不够稳定。

o1 做的事情本质上是把 CoT “内化”到了模型里——不需要用户提示，模型自己就知道什么时候该想、怎么想。推理过程被集成到了模型的前向传播中，而不是依赖于外部提示。

DeepHermes 和 Hermes 4 走的也是类似的路线，但实现方式有所不同。

Think 标签的技术实现

Hermes 4 和 DeepHermes 使用 <think> 和 </think> 标签来标记推理过程。模型的输出结构是这样的：

1
2
3
4
5

<think>
[推理过程，可能包含多步分析、计算、验证]
</think>

[基于推理得出的最终答案]

这种设计有几个好处：

透明性：用户（或开发者）可以看到完整的推理过程，方便调试和验证。o1 的推理过程是隐藏的，用户只能看到最终结果。这在某些场景下是个劣势——你无法判断模型的答案是怎么推出来的。

可控性：通过系统提示，用户可以控制模型是否使用 think 模式。比如在时间敏感的场景中，可以要求模型跳过推理直接回答。

灵活性：think 标签内的内容格式自由，模型可以根据问题类型选择不同的推理策略——数学题就列算式，逻辑题就做排除法，代码题就模拟执行。

训练过程

要让模型学会在 think 标签里做推理，训练数据需要精心构建。Nous Research 的做法是：

第一步：构造推理链数据

用强模型（GPT-4、Claude 等）生成带有完整推理过程的回答。每条训练样本包含三个部分：用户问题、think 标签内的推理过程、最终答案。

生成后需要严格验证——推理过程必须逻辑连贯，最终答案必须正确。对于数学题，答案可以程序化验证；对于其他类型的问题，需要更复杂的评估方法。

第二步：加入不需要推理的样本

如果训练数据里全是带 think 标签的样本，模型就会变成”什么问题都要想半天”的状态。所以训练数据中需要混入大量不需要推理的简单对话，让模型学会判断什么时候该思考、什么时候该直出。

这就是 Hermes 4 被称为”混合推理”模型的原因——它不是一个纯推理模型，而是一个能在推理模式和直出模式之间灵活切换的模型。

第三步：强化学习微调

在 SFT 之后，可能还会用某种形式的强化学习来优化推理策略。比如，奖励那些推理过程简洁且答案正确的样本，惩罚那些推理冗长但答案错误的样本。这让模型学会”高效地思考”而不是”磨洋工”。

30K Token 的推理上限

Hermes 4 的推理 token 上限是 30K。这意味着 think 标签内的推理过程最多可以包含约 30,000 个 token（大约 2 万多中文字）。

30K 够用吗？对于绝大多数问题来说，绰绰有余。即使是非常复杂的数学竞赛题，推理过程通常也在几千 token 以内。30K 更多是一个安全边界——防止模型在某些极端情况下陷入无限推理循环。

但也有一些场景可能接近这个上限：

• 需要大量枚举的组合问题
• 需要逐行分析的长代码 debug
• 需要多次自我验证和修正的复杂问题

当推理过程被截断时（达到 30K 上限），模型会被迫在不完整的推理基础上给出答案。这时候答案质量可能会下降。

DeepHermes vs Hermes 4：两种推理哲学

DeepHermes 和 Hermes 4 都能做推理，但它们的定位不同。

Hermes 4：混合型选手

Hermes 4 是一个全面的模型。它可以推理，但也擅长普通对话、创意写作、角色扮演等非推理任务。think 标签只在需要的时候才出现。

适合的场景：需要一个”万能助手”，既能帮你做数学题，也能帮你写邮件。

DeepHermes：推理特化型

DeepHermes 默认就会进行深度推理，即使是相对简单的问题也会走一遍思考过程。它在数学、科学、编程这些对逻辑严密性要求高的领域表现更好。

适合的场景：主要用模型来解决技术问题、做分析、写代码。不需要它陪你聊天，只需要它给出准确的答案。

用一个类比来说：Hermes 4 像是一个能文能武的全科生，DeepHermes 像是一个理科竞赛选手。

和 OpenAI o1 的正面比较

既然灵感来自 o1，那就不得不做个比较。

推理深度

o1 的推理深度目前仍然是天花板级别的。在国际数学奥林匹克（IMO）难度的题目上，o1 的表现远超目前所有开源模型，包括 DeepHermes。

但在中等难度范围内（MATH-500、AIME 2024），差距要小得多。Hermes 4 在 MATH-500 上的 96.3% 已经非常接近 o1 的水平。在 AIME 2024 上的 81.9% 也是一个相当有竞争力的成绩。

推理效率

o1 的推理 token 消耗通常很高——对于复杂问题可能会消耗几万甚至十几万 token 的推理过程。Hermes 4 的推理相对更”克制”，大多数情况下在几百到几千 token 就能完成。

从成本角度看，Hermes 4 的推理效率更高。当然，如果你追求极致的推理质量且不在乎成本，o1 仍然是更好的选择。

透明度

这是 Hermes 系列的绝对优势。o1 的推理过程是完全黑箱的，OpenAI 在 API 中只会返回少量的推理摘要（reasoning summary），不会展示原始的推理过程。

DeepHermes 和 Hermes 4 的推理过程完全透明——think 标签内的所有内容都原样输出。这对于学术研究、教育场景、以及需要可解释性的应用来说，是一个巨大的优势。

部署灵活性

o1 只能通过 OpenAI 的 API 使用，受限于 OpenAI 的使用条款和定价。DeepHermes 和 Hermes 4 是开源的，可以本地部署、自定义修改、不受任何使用限制。

这对于企业用户来说特别重要——很多企业不愿意把敏感数据发送到第三方 API，本地部署是刚需。

推理模型的核心挑战

开发推理模型不是简单地”加个 think 标签”就完事了。这里面有几个核心的技术挑战：

推理质量的一致性

模型有时候会在 think 标签里走弯路——花了很多 token 分析了一个错误的方向，最后不得不推翻重来。更糟的情况是推理过程前后矛盾——前面得出的结论和后面的推导相矛盾。

要解决这个问题，需要在训练数据中加入大量”自我纠正”的样本——模型发现错误后主动修正，而不是将错就错。

什么时候该停止思考

推理不是越多越好。对于简单问题，过度推理是浪费；对于无解的问题，无限推理更是灾难。模型需要学会判断”想够了”——推理已经充分，可以给出答案了。

30K 的 token 上限是一个硬性保护，但更好的方案是让模型自己学会”到此为止”。这需要在训练中加入推理长度的奖励信号——鼓励在保证质量的前提下尽量简洁。

推理和最终答案的一致性

有时候会出现一个奇怪的现象：think 标签里的推理过程是对的，但最终答案是错的（或者反过来）。这说明推理过程和答案生成之间的耦合还不够紧密。

这是一个活跃的研究方向，目前还没有完美的解决方案。

开源推理模型的生态

DeepHermes 不是唯一的开源推理模型。这个赛道上还有几个重要的玩家：

DeepSeek-R1：DeepSeek 的推理模型，在数学和科学领域表现很强。它的特点是推理链非常长且详细，适合需要精确推理的场景。

QwQ：通义千问推出的推理模型。对中文场景的支持比较好，在中文数学题上的表现很有竞争力。

Skywork-o1：昆仑万维的推理模型系列，也是 think 标签路线。

这些模型各有优劣，但共同的趋势是明确的：推理能力正在成为开源模型的标配功能，而不是少数模型的专属特性。

cocoloop 社区有用户做过横向对比测试，结论是：在综合能力上 Hermes 4 和 DeepSeek-R1 互有胜负，但 Hermes 4 在 Function Calling 和 agent 场景上有明显优势——毕竟推理只是 Hermes 的能力之一，不是全部。

实际使用中的体会

用了一段时间 DeepHermes 之后，有几点感受比较深：

推理过程本身就很有价值。即使最终答案是错的，推理过程也能帮你理解问题的结构和可能的解法方向。这在学习和研究场景中特别有用。

不同问题选不同模型。对于需要精确推理的硬核问题（数学、逻辑、代码），用 DeepHermes。对于日常对话和创意任务，用 Hermes 4 的直出模式。没必要一个模型打天下。

推理结果需要验证。再强的推理模型也会犯错。把推理过程当作”参考意见”而不是”标准答案”，用自己的判断做最终决策。

长推理不等于好推理。有时候模型会在 think 标签里绕弯子，写了几千 token 的推理但大部分是无用信息。推理质量比推理长度重要得多。

推理能力的未来

从 o1 的发布到现在（2026 年），推理模型已经从一个新奇概念变成了行业标配。未来的方向可能包括：

更高效的推理：用更少的 token 完成同等质量的推理。现在的推理模型普遍”话多”，有很大的优化空间。

多模态推理：在图像、图表、公式上做推理，而不只是纯文本。这对于科学和工程领域尤其重要。

推理过程的可控性：让用户能更精细地控制推理的深度和方向。比如指定”只用代数方法解这道题”或”推理过程不超过 500 token”。

推理和行动的结合：让推理模型不只是”想”，还能”做”——在推理过程中调用工具、检索信息、执行代码。这是 agent 和推理的结合方向。

如果想了解 Hermes 4 的 基准测试成绩 具体是什么水平，以及各项跑分代表什么含义，另一篇文章有详细的解读。

推理能力的加入让开源模型迈上了一个新台阶。DeepHermes 和 Hermes 4 证明了：你不需要每个月花几千块的 API 费用，也能用上有推理能力的大模型。这对于个人开发者和小团队来说，是实实在在的福音。

这些测试到底在测什么？Hermes 4 的那些分数代表什么水平？普通人应该怎么看待这些跑分？

这篇文章尽量用大白话把这些事儿说清楚。

为什么需要基准测试

先说一个基本问题：为什么需要给模型跑分？

原因很简单——你没法用一句话说清楚一个大模型”好不好用”。不同模型在不同任务上的表现差异很大：有的数学好但写作差，有的代码强但常识弱。基准测试就是把”好不好用”这个模糊的问题拆解成一系列具体的、可量化的任务来评估。

就像高考——你不能用一句话评价一个学生的学力水平，但可以用语数外理化生的单科成绩来描绘一个相对完整的画像。

但也和高考一样，跑分有很多局限性。这一点在后面会详细说。

MATH-500：竞赛级数学题

这是什么

MATH-500 是从 MATH 数据集中抽取的 500 道数学题。MATH 数据集本身包含 12,500 道竞赛级数学题，覆盖七个大类：

1. 预代数（Prealgebra）：基础算术和初等代数
2. 代数（Algebra）：方程、不等式、函数
3. 数论（Number Theory）：整除性、素数、同余
4. 计数与概率（Counting & Probability）：排列组合、概率计算
5. 几何（Geometry）：平面几何、解析几何
6. 中级代数（Intermediate Algebra）：多项式、复数、对数
7. 初级数论（Precalculus）：三角函数、向量、极坐标

每道题有 1-5 的难度等级。MATH-500 是随机抽样的 500 道题子集，基本保持了原始数据集的难度分布。

怎么测的

测试时给模型一道数学题，模型需要给出最终答案。答案格式是标准化的（比如分数用 \frac{a}{b}，根号用 \sqrt{}），通过字符串匹配来判断对错。

评估指标很简单：正确率。500 道题答对了多少道。

Hermes 4 的表现

Hermes 4 在 MATH-500 上的得分是 96.3%。

这个分数是什么水平？

• GPT-4o 大约在 76-80% 之间
• Claude 3.5 Sonnet 大约在 78% 左右
• o1-preview 在 94.8% 左右
• o1 正式版在 96.4% 左右

96.3% 基本追平了 o1 正式版，远超 GPT-4o 和 Claude 3.5 Sonnet。对于一个开源模型来说，这个成绩非常亮眼。

但需要注意的是，这是 Hermes 4 开启推理模式 后的成绩。在直出模式下（不使用 think 标签），分数会低不少。这说明推理过程对数学题的解答确实有很大帮助。

这个分数说明什么

96.3% 意味着：在竞赛级难度的数学题中，模型有超过 96% 的概率给出正确答案。剩下不到 4% 的错误大多集中在难度 4-5 的高难度题目上。

对于普通用户来说，如果你用 Hermes 4 来辅导数学作业或者解决工作中的数学计算问题，它基本上是非常可靠的。

AIME 2024：数学邀请赛

这是什么

AIME 全称 American Invitational Mathematics Examination（美国数学邀请赛），是美国数学竞赛体系中的第二关（AMC → AIME → USAMO → IMO）。参加 AIME 的都是在 AMC 10/12 中表现优异的学生。

AIME 2024 指的是 2024 年的 AIME 试题。每场 AIME 有 15 道题，答案都是 000-999 之间的整数。考试时间 3 小时。

AIME 的难度比 MATH-500 高出不少。MATH-500 覆盖了从容易到困难的各种难度，而 AIME 的每一道题都有相当的挑战性。前几题可能比较平和，但后面的题目经常需要很巧妙的思路才能解出来。

Hermes 4 的表现

Hermes 4 在 AIME 2024 上的得分是 81.9%。

换算一下：15 道题答对了大约 12-13 道。在 AIME 中，满分是 15 分。12-13 分在人类考生中属于非常高的水平——很多入选 USAMO 的选手的 AIME 成绩也就在这个范围。

对比一下：

• GPT-4o 在 AIME 2024 上大约只能做对 3-5 道
• o1 大约能做对 12-14 道

Hermes 4 在 AIME 上的表现和 o1 基本在同一档，远远超过了不具备推理能力的模型。

为什么 AIME 更有参考价值

相比 MATH-500，AIME 的优点是更难”刷分”。

MATH-500 中有相当比例的中低难度题目，这些题目即使模型记住了类似的解题模式也能做对。但 AIME 的题目每年都是全新的，而且难度高，很难通过记忆模式来蒙混过关。模型必须有真正的推理能力才能拿高分。

所以，在评估模型的推理能力时，AIME 的成绩比 MATH-500 更有说服力。

GPQA：研究生级别的科学问答

这是什么

GPQA（Graduate-Level Google-Proof Q&A）是一个研究生难度的科学问答测试集。它包含 448 道多选题，涵盖物理、化学和生物三个领域。

GPQA 的特点是”Google-Proof”——这些题目即使你能用 Google 搜索，普通人也不太能做对。因为它们需要深层的学科知识和推理能力，不是简单搜索就能找到答案的。

题目的设计流程也很严格：由各领域的博士生和研究人员出题，确保题目质量和难度。

测试方式

给模型一道多选题（通常有 4 个选项），模型需要选出正确答案。评估指标是正确率。

由于是多选题，随机猜测的基线准确率是 25%。

为什么这个测试重要

GPQA 测的是模型在专业学科上的深度知识和推理能力。MATH-500 和 AIME 只覆盖数学，GPQA 则扩展到了物理、化学和生物。

对于科研人员来说，这个测试的参考价值比较大——它能反映模型在专业学科问题上的可靠性。

RefusalBench：过度拒绝评估

这是什么

前面已经有 专门的文章 详细讲过 RefusalBench，这里简单说一下。

RefusalBench 不是测模型的知识或推理能力，而是测模型的”服务态度”——面对合法但涉及敏感话题的请求，模型是否会不合理地拒绝。

Hermes 4 的表现

Hermes 4 得分 57.1%，GPT-4o 只有 17.67%。

这意味着 Hermes 4 在面对合理但敏感的请求时，有 57.1% 的概率会正常回答，而 GPT-4o 只有不到 18%。

这个差距反映了两者完全不同的安全对齐策略——Hermes 倾向于”精准拒绝”（只拒绝真正有害的），GPT-4o 倾向于”保守拒绝”（宁可多拒绝）。

其他常见基准测试简介

除了上面几个，你可能还会在 Hermes 的评测报告中看到这些测试：

MMLU（多学科知识）

Massive Multitask Language Understanding，包含 57 个学科的多选题，从人文到理工都有。是衡量模型”博学程度”的常用指标。

Hermes 4 在这个上面的表现接近 GPT-4 水平——说明它的知识储备很扎实。

HumanEval（代码生成）

给模型一个函数签名和描述，让它写出实现代码。然后用预设的测试用例来验证代码是否正确。评估指标是 pass@1（一次生成就通过所有测试的概率）。

这个测试反映的是模型的编程能力。

MT-Bench（多轮对话）

用 GPT-4 作为裁判，对模型在多轮对话中的表现打分。涵盖写作、角色扮演、推理、数学等多个类别。

这是一个比较”主观”的测试——因为评判标准是由另一个 AI 来定的。但它对对话质量的评估比简单的正确率指标更全面。

BBH（Big-Bench Hard）

从 BIG-Bench（一个包含 200+ 任务的综合测试集）中挑选的 23 个”难题”任务。包括各种需要多步推理的任务，比如因果推理、日期计算、逻辑推理等。

这个测试主要评估模型的综合推理能力。

怎么看待跑分

讲完了各个测试的具体内容，来聊聊一个更重要的问题：普通用户应该怎么看待这些跑分？

跑分的价值

横向比较的参考：当你需要在几个模型之间做选择时，跑分至少能给你一个粗略的方向。比如你的应用场景主要涉及数学，那 MATH-500 和 AIME 的成绩就比 MT-Bench 更有参考价值。

能力短板的识别：如果一个模型在数学上表现很好但在代码上一般，你就知道不要对它的编程能力期望太高。

进步的量化：同一系列模型的新版本比旧版本跑分高了多少，能直观反映技术进步的幅度。比如 Hermes 4 比 Hermes 3 在 MATH-500 上提升了多少分。

跑分的局限

不等于实际使用体验：跑分高的模型不一定在你的具体场景下表现好。基准测试覆盖的任务和你的实际需求可能差距很大。

存在过拟合风险：有些模型可能专门针对特定基准测试做优化（在训练数据中包含类似的题目），导致跑分虚高。这在行业内被称为”benchmark hacking”。

单一维度的衡量：一个模型在 MATH-500 上 96.3% 很厉害，但如果它在实际使用中经常输出格式混乱、推理过程冗长、响应速度慢，这些跑分都体现不出来。

版本和配置的影响：同一个模型在不同的推理配置下（温度、top-p、是否开启推理模式）可能得到很不一样的跑分。发布方通常会选最好的配置来报分。

我的建议

1. 看趋势而不是具体数字：A 模型比 B 模型在数学上好很多，这个结论大概率靠谱。但 A 模型 96.3% vs B 模型 95.8%，这种微小差距可能没什么实际意义。

2. 结合你的使用场景：如果你主要用模型来写代码，重点看 HumanEval。如果主要用来做知识问答，看 MMLU。不需要每个跑分都关注。

3. 自己试用比看跑分更重要：拿你实际的工作场景测几个例子，比任何跑分数据都更有说服力。跑分只是入门筛选工具，不是最终决策依据。

4. 关注跑分背后的”how”：Hermes 4 在 MATH-500 上 96.3% 是开了 推理模式 的成绩。如果你的应用场景对响应速度敏感，可能不会开推理模式，那这个分数对你的参考价值就要打折。

5. 警惕只报好的跑分：如果一个模型只公布了自己表现好的基准测试成绩，对其他测试避而不谈，这往往说明它在那些测试上表现不好。全面公布跑分的模型更值得信任。

Hermes 4 的跑分全景

把 Hermes 4 的主要跑分汇总一下：

综合来看，Hermes 4 是一个非常均衡的模型。没有特别明显的短板，在推理（MATH、AIME）和自由度（RefusalBench）上还有突出的长板。

对于普通用户来说，不需要记住每一个跑分数字。只需要知道：Hermes 4 是一个在开源模型中处于第一梯队的选择，数学和推理能力尤其突出。如果你对各个版本之间的差异感兴趣，Hermes 模型进化全记录 那篇文章有更详细的对比。

cocoloop 社区里经常有人问该看什么跑分选模型，我的回答一直是：跑分是了解模型的起点，不是终点。用它来缩小选择范围，然后用自己的场景来做最终判断——这才是正确的打开方式。