Yi模型上下文窗口与许可证条款深度解读

Yi 的上下文窗口要么是 4,096 个 token，要么是 200,000，具体取决于你从哪个仓库下载。01.AI 将长上下文模型作为独立检查点发布，名称中带有 -200K，而不是作为基础模型的配置来发布，几乎所有用一个单一数字回答这个问题的人都是在引用两者之一而没有说明是哪一个。

发布历程

Yi-6B 和 Yi-34B（2023 年 11 月）。01.AI 的初始发布， decoder-only transformer，采用与 Llama 兼容的架构——这也是它们能够直接插入现有工具的原因，基于英汉双语语料库训练。

Yi-6B-200K 和 Yi-34B-200K。长上下文变体随同发布，作为独立的仓库。

Yi-9B（2024 年）。中间规模，从 6B 模型深度扩展而来。

Yi-1.5（2024 年 5 月）。在 6B、9B 和 34B 上重新训练的版本，发布时带有 4K、16K 和 32K 上下文变体以及指令微调对应版本。

Yi-Coder 和 Yi-VL。代码和多模态视觉语言产品线，拥有各自的技术文档卡片和定位。

Yi-Large。仅提供 API 的模型。没有权重，因此下面的开源权重许可证讨论不适用于它；其条款由平台服务条款规定。

值得停下来谈一下 Llama 兼容架构，因为它解释了 Yi 为何如此快速地出现在众多工具中，也因为它在发布时引发了一场公开争论：初始检查点使用了 Llama 的架构，只是重命名了两个 tensor，这引来了关于归属问题的批评。01.AI 随后恢复了原始名称并记录了这段关系。权重本身没有争议——它们是从零开始在 01.AI 自己的语料库上训练的——但这段历史解释了为什么某些较旧的加载器带有 Yi 特定的名称映射，而现在已不再需要。如果你遇到加载早期检查点时的密钥不匹配错误，那就是原因。

上下文长度，包括 200K 变体

Yi-6B / Yi-34B                    4,096 tokens
Yi-6B-200K / Yi-34B-200K        200,000 tokens (approx. 262,144 configured)
Yi-9B                             4,096 tokens
Yi-1.5 (base variants)      4,096 / 16,384 / 32,768 tokens

营销数字 200K 与仓库中配置的 max_position_embeddings 之间存在差距，值得注意而非将其视为错误：这些模型被定位为支持 200K，并配置到了其上方的一个 2 的幂次天花板。如果你是在计算缓冲区大小，请阅读配置文件；如果你是在阅读对比表格，预期会看到取整后的数字。

配置为 200K 的检查点并不是承诺检索质量在 200K 个 token 范围内保持一致。它承诺的是位置编码和运行时都会接受它们。这是两个不同的声明，只有第二个是架构层面的。在你实际打算使用的深度上测试召回率。

许可证已变更为 Apache 2.0

2023 年 11 月的初始发布使用的是 Yi Series Models Community License，该许可证允许免费用于研究用途，但商业使用需要先向 01.AI 注册。这一门槛立即招致批评——一个需要你获得许可的许可证是下游项目无法依赖的——01.AI 随后将其移除：Yi 模型重新授权为 Apache 2.0，Yi-1.5 从一开始就是以 Apache 2.0 发布。

两个实际后果。首先，如果你正在阅读 2023 年底或 2024 年初的文档或第三方对比，其中关于 Yi 的许可证声明已经过时，描述的是不再适用的条款。其次，对于任何有合规流程的项目更为重要：这里的 Apache 2.0 就是 Apache 2.0，没有附加任何可接受使用政策。这使 Yi 处于与 Falcon 和 DBRX 所用的 Apache 衍生许可证真正不同的类别，与 Mistral 的 Apache 2.0 发布和 Qwen 处于同一类别。

每个 Hugging Face 仓库中的许可证文件是权威来源，由于变更通过更新仓库的方式应用，因此在变更之前获取的权重副本会带有旧文本。如果你的组织在 2023 年归档了一个镜像，档案中的许可证文件才是你接受的版本。

同样值得精确说明重新授权涵盖和不涵盖的内容。模型权重移至 Apache 2.0。训练数据并未公开，也没有发布任何语料库——Yi 是狭义上的开源权重模型，而非 OLMo 描述的那种开放式模型。这两个维度是独立的，将它们混为一谈很常见：一个模型可以采用世界上最宽松的许可证，但仍不附带任何可供审查的内容。

200K 变体在实践中的成本

200K 检查点是带有重新缩放旋转位置编码的普通 transformer。没有混合架构提供的那种架构层面的缓解——每一层仍然保留完整的 KV 缓存，随序列长度线性增长。因此成本就是你能够预测的那些：

重新缩放值得精确命名，因为它是标准操作，你会在每一个长上下文 transformer 上遇到它。旋转嵌入通过由位置和基础频率决定的角度旋转 query 和 key 向量，通常以 rope_theta 暴露。将这个基础频率提高会扩展同一组频率覆盖的位置范围，这就是让一个在某长度上训练的模型能够在更长得多的长度上继续训练而不会出现角度模式无法识别的原因。这是一个训练时的变更，有着配置时的指纹：两个具有相同架构但不同 rope_theta 值的检查点是不同的模型，而这个字段是区分真正的长上下文检查点与在某人在配置上编辑过的检查点的可靠方式。

每次请求的内存随窗口大小无界增长。在 200K token 时，34B 模型的缓存是典型请求所用大小的数倍，而且是每个并发请求一份。相应地，批处理大小会大幅下降。

预填充主导延迟。首个 token 的时间由处理 prompt 决定，而对 200K prompt 的注意力在序列长度上是二次方的。这不是流式输出能够隐藏的；流还没有开始。

基础模型和 200K 检查点是独立下载的。它们是分开训练的，不是配置出来的。你无法通过在基础模型上提高配置值来获得长窗口。将 max_position_embeddings 提高到模型训练长度之外会产生看似流畅但质量下降的输出，而不是报错，这是最糟糕的失败模式。唯一一个有记录表明超出训练长度是设计目标的架构是 ALiBi——参见 MPT 如何在不进行位置微调的情况下进行外推。

实际上，这意味着 200K 变体是一种专业工具，而非基础模型的严格升级版。如果你的 prompt 只有几千个 token，基础检查点是同一模型，具有相同的质量，但服务成本低得多。只有当你的文档确实没有其他方式能够容纳时，才使用 200K 版本，并且预期要单独为其配置资源，而不是将两者放在同一个池中运行。

实用建议

确认仓库名称是否以 -200K 结尾。那个后缀，而非系列名称，才是决定窗口大小的关键。

阅读 config.json 中的 max_position_embeddings 和 rope_theta，并记录两者。社区重新量化可能已更改了其中任一值。

阅读你实际拉取的仓库中的 LICENSE，并记录 commit hash。不要依赖对比文章中的许可证栏。

如果你继承了一个 2024 年之前的镜像，请单独检查其许可证文件——它可能早于 Apache 2.0 变更。

延伸阅读

Falcon's Context Window and License Terms Across Versions

StableLM's Context Window and Stability AI's Licensing Terms