Kimi 上下文扩展到 200 万汉字

背景

Kimi 于 2023 年 10 月上线，当时一次最多能处理 20 万个汉字。^[2][3] 这个数字说的是模型的上下文窗口（context window）：它在生成一次回答时能同时「看到」多少文字。窗口的大小决定了一个助手能一口气做完什么样的活。问几页纸之内的问题，窗口绰绰有余；但一整份合同、一本小说、一部很长的技术手册就放不进去，通常的变通办法是把文档切成若干段分别喂进去，结果模型很难把开头的一句话和后文几百页处的条款联系起来。

发生了什么

2024 年 3 月，月之暗面表示 Kimi 现在可以在单次提示（prompt）中处理最多 200 万个汉字。^[3] 与上线时的数字相比，这大约是十倍的提升，实际可处理的单位也从一篇文章推到接近一本书的体量，用户不必事先判断哪一章才是重点。

分批开放

更大的窗口并不是第一天就人人可用。2024 年 3 月它以封闭测试的形式运行，仅限受邀用户，之后才扩大开放。^[1][3] 对于负载和成本难以预估的功能，分批放量是常见做法：一小批测试者能暴露出人们真的把很长的材料贴进来时系统会怎样，以及在放开之前还需要修好什么。

同一季度的融资

2024 年 2 月，也就是这轮测试开始的同一个季度，月之暗面完成了一轮 10 亿美元的融资，由阿里巴巴领投。^[2][4] 资金和上下文长度是连在一起的。处理超长输入很吃算力，提示里每多一个字，每次请求模型就要多做一份计算；一个鼓励用户贴进整本书的助手，成本结构与只回答短问题的助手并不相同。

缓存与用户规模

2024 年 7 月，上下文缓存（context caching）进入公测。^[1] 它的思路是把一大段文字先处理一次并保留结果，这样针对同一份文档的后续提问就不必每次从头再来。它与大窗口天然配套：用户贴进来的材料越长，避免重复处理的收益就越大。

到 2024 年 8 月，Kimi 按月活用户数排在聊天助手第三位。^[2]

为什么重要

上下文长度是语言模型使用方式中不太显眼的一项约束。窗口短的模型，等于把摘录和筛选的工作先推给用户，而被省掉的部分对模型来说根本不存在。窗口变长之后，原始材料可以直接放进去，整份文档层面的工作才成为可能：通读一份完整报告、拿一长串要点逐条核对协议，或者让一封拖了很久的往来信件前后保持一致。

也要把局限说清楚。更大的窗口只是「能放进去多少」的上限，并不保证某一段具体内容会被用好；而处理长输入本身开销很大，缓存这类技术因此成为让功能可用的组成部分。2024 年 3 月的这次测试是朝这个方向迈出的一步，而不是终点。