上下文窗口（Context Window）可能是普通用户最容易感知到的一个模型参数。你往对话框里粘贴一篇长文章，模型说”太长了处理不了”——这就是上下文窗口的限制。
Hermes 系列从最初的 2K 一路扩展到 512K，每次扩展背后都涉及不少技术挑战和取舍。这篇文章把这段进化史捋一遍，顺便说说长上下文到底有什么实际用途。
先理解上下文窗口
在聊进化史之前，先把概念搞清楚。
上下文窗口指的是模型在一次推理中能处理的最大 token 数量。Token 不完全等于字或词——在英文中大约每个单词对应 1-2 个 token，在中文中每个字大约对应 1-2 个 token。
4K tokens 大约是 3000 个英文单词或 2000 个中文字，也就是一篇普通的文章长度。512K tokens 大约对应 40-50 万中文字，相当于一本厚书的篇幅。
上下文窗口是一个”硬限制”——超过这个长度的输入，模型直接无法处理。不是处理得不好，是完全不能接收。
各版本的上下文长度
| 版本 | 上下文窗口 | 约等于中文字数 |
|---|---|---|
| Hermes (初代, LLaMA 13B) | 2K | ~1,500 字 |
| OpenHermes 2.5 | 4K | ~3,000 字 |
| Hermes 2 Pro (Mistral 7B) | 8K | ~6,000 字 |
| Hermes 3 (Llama 3.1) | 128K | ~100,000 字 |
| Hermes 4 (Llama 3.1) | 128K | ~100,000 字 |
| Hermes 4.3 (Seed-OSS-36B) | 512K | ~400,000 字 |
可以看到，增长是非线性的——从 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 倍。下一步是什么？百万级？千万级？让我们拭目以待。