2024.6横向对比各家LLM的Long Context (合集 V1.10)
TLDR
本文构造了一个比大海捞针稍难的长上下文测试方案，并对比了目前支持128k和32k以上的上下文的闭源API LLM模型。
仅从这个很狭隘的测试来看，海外头部三家厂商在长上下文上还是领先于国内的。
本文的测试代码框架已经开源，方便大家测试其他数据。
本系列没有得到任何厂商赞助，目前累计花了4300RMB充值各家平台。
Github地址：https://github.com/SomeoneKong/llm_long_context_bench202405/tree/bench_32k_v1https://github.com/SomeoneKong/llm_long_context_bench202405/tree/bench_128k_v1合集更新历史：
在正文内容上没有太多更新，主要是数据表的更新，可以直接跳去看表格。
V1.10
增加了智谱 6.5发布的新系列模型的结果。由于SiliconFlow对glm-4-9b的适配只支持32k context，所以仅有32k测试结果。
增加了阿里 qwen2 新系列开源模型的结果。由于SiliconFlow对该系列模型的适配只支持32k context，所以仅有32k测试结果。
零一万物的yi-large的context能力提升到32k，新增其32k的测试结果。
腾讯hunyuan模型已经能够成功响应128k请求，新增hunyuan系列的128k测试结果。
更新了阶跃星辰 step-1-128k的测试结果，主要是延迟和速度数据更新。
SiliconFlow支持了stream模式下返回usage的功能，所以更新了deepseek-v2 on SiliconFlow的token生成速度数据。
修正了 Mistral 系模型 temperature 设置错误的问题，更新测试结果。
适配了Reka最新SDK，增加了Reka的首token延迟时间和token生成速度数据。
移除了Minimax已经下线的 abab6-chat。
V1.6
增加了字节的Doubao模型的32k、128k测试结果，Doubao-pro的模型效果名列前茅。
在128k测试中增加了：DeepSeek-V2开源模型、reka-flash、cohere系列模型。
根据官方信息更新了对Baichuan4的描述。
后续更新计划
目前的测试在我来看有一些需要改进的地方，例如难度不足、测试用例偏离实际应用场景等。所以后续只会有一些少量的模型新增更新，整体的数据更新已经不再进行规划。
由于本次测试用例已经计划废弃，所以就不再单独部署开源模型的未量化版本进行测试了。（目前SiliconFlow、Togather等部署的模型很可能是某种量化版本。）
处于减少公众号上重复文章的考虑，本系列的旧版本文章在逐步移除，如果读者后续寻找数据时发现本文被删除时，请到公众号上查看最新版本。
0、前言
最近一段时间各家基座LLM爆发了一波更新，>=128k的long context能力已经逐渐普及。而目前对于long context的测试就只有大海捞针，其实大海捞针只是一个最简单的测试，理论上RAG的召回过程做好了也一样能解决。
我也是看到别人转的一个测试之后有些手痒，所以尝试将其更完善一些，由此作为一个横向对比的方式，（希望国内各家基座LLM厂商能够更卷一点）。需要说明的是，这个测试对于long context场景仍然十分简单，但已经有区分度了，有一些模型已经不能通过，这就够了。
另外在测试中发现不同模型的响应速度有较大差异，所以也把响应时间纳入比较结果。
想要在测试中消除偶然随机性导致的影响的成本很高，我尽量在成本可控的范围内减少这方面的影响，但仍然离完美还有很大距离。我会开源本文测试过程的代码，方便读者进行复现和基于此改造。
整体来说这个测试仍然十分偏颇，希望能够抛砖引玉，最终能够有一个更好比较各家基座LLM能力的方案。
1、测试方案说明
本文的测试仍然是有点类似大海捞针性的，但是需要捞多根针。
首先选取一个长文档作为基础，为了横向比较国内外模型语言选择为英文。这里选择哈利波特的第三部和第四部。
将一个问题的几个条件分别插入到文章的随机位置，插入的内容作为一个独立段落出现，不会插入在一个段落中。然后要求LLM根据输入的文档和问题进行回答，可以使用CoT。
根据各模型的context能力，分为两个级别：128k、32k。不再单独评比8k、16k水平的模型。
以下是插入的问题：
Defined var_earth = 1200.
Defined var_mars = var_earth + 100.
Defined var_jupiter = var_mars + 50.
---------Based on the content of the documents above, calculate the value of the var_jupiter step by step.
问题的答案：1350选择两个文档作为基础，每个文档随机生成3套插入位置，每个插入结果使用temperature=0.8测试5次。先计算每套插入位置的平均正确率，然后在2个文档之间取平均作为最终成功率。不对结果的逻辑和语义进行检查，只要出现【1350】这个结果都算正确。
响应时间方面统计两个指标：首个token的返回延迟，返回首个token之后的token生成平均速度。为了消除网络偶然因素，每个插入结果中会剔除掉时间最长的一个结果后再取平均。由于不同结果中的推理路径可能长短不一，以及各个模型的CoT措辞习惯也有较大差异，所以整个请求的总耗时不列入比较范围。
【为什么测试次数有点少】
主要是成本问题，一方面token费用就不便宜了，一个模型的测试消耗约3M 输入token，及GLM-4为例就要花费300RMB。另外还有是时间成本问题，各家LLM的TPM限制制约了跑实验的速度。实际上我基本是默认串行跑所有请求的。
32k的测试综合来讲还好，但仍然沿用同样的测试规模。
【为什么选择哈利波特】
选择标准是：英语、自然语言为主题的内容（排除公式类）、是最近一段时间写成的、足够长（>=100k）。
要求是近期的作品是为了让语言习惯更贴近LLM所熟悉的范围。为了方便起见选择一个知名的小说，简单能想到的就是哈利波特系列。
【问题选择】
选择的问题本身是简单的，数值计算的数值也经过特意选择，能够让LLM不依赖外部工具就能够大概率正确计算。使用CoT也是为了降低整个问题难度和数值计算的难度。
这个问题的求解需要逐步的召回3个信息，像RAG那样直接根据问题直接召回相关内容再计算的方式更可能会遗漏前两个条件。这也是这个测试与大海捞针不同的地方，大海捞针可以单纯的将待处理的范围缩小到某个区间内进行处理。
变量名的选择一方面是让其与背景文章不同，不会出现重名的问题。
后续补充：从测试结果来看，这三个变量名的选择差异并不足够大，很多模型能够从一开始就直接召回第一个变量的信息，而不是逐步找回。未来会考虑增加测试难度。
【为什么选择temperature=0.8】
我也考虑过选择一个稍小的temperature，例如0.1或0.001。但这个问题本身较为简单，只考察LLM预测的最大概率结果路径难度较低，大部分都能通过。所以为了进一步考察各家模型输出概率分布整体质量，让测试的区分度更大，以及考虑有多样性需求的场景，综合把temperature提升到0.8。
以及贪心解码的生成路径未必是语义上最大概率的结果，以及为了抑制整个测试中各个方面随机性的影响，多次抽样取平均是需要的，也使得不能选择太小的temperature。
【测试文件的具体长度】
考虑到不同模型的tokenizer压缩率稍有差异，所以128k档位的测试数据选择OpenAI cl100k_base的100k左右文本，32k档位测试数据选择cl100k_base的24k左右文本。
2、测试结果
2.1、各家情况说明
【Google Gemini】
Gemini全系为1M context能力，选择 gemini-1.5-flash 和 gemini-1.5-pro 进行测试。
【OpenAI】
OpenAI的模型细分版本较多，但只有gpt-4/gpt-4o系为128k能力，gpt-3.5仅为16k，考虑到成本问题只选择最新的 gpt-4o-2024-05-13 进行对比。
【Anthropic Claude】
Claude 3 全系为200k，claude-3-sonnet的效果就已经足够好，考虑到成本问题 claude-3-opus 不列入测试。
Anthropic 官方API有个很低的TPD限制，导致128k测试任务无法完成，所以128k测试只能转而使用API代理商进行请求，这可能影响到对时间的统计。
【Mistral】
Mistral全系列都支持32k，为了方便与开源模型的能力对比，顺带增加了它的两个开源版本：open-mixtral-8x7b、open-mixtral-8x22b。
【Reka】
Reka的 reka-flash 和 reka-core 模型为128k。
【cohere Command】
command-r 和 command-r-plus 模型为128k。
cohere官网我无法成功登录，只能通过API代理商进行请求。
【智谱 GLM】
智谱全系列模型都是128k。
【零一万物 Yi】
Yi系列目前yi-large是32k，yi-medium-200k 是200k，其余模型都是16k。
【月之暗面 Moonshot】
moonshot-v1有32k、128k版本。
【字节 Doubao】
Doubao系列模型有 Doubao-pro 和 Doubao-lite，均有32k和128k版本。
【百川 Baichuan】
百川目前刚发布了Baichuan3-Turbo和Baichuan4的API，由于产品线较多，所以忽略更早的Baichuan2等。
Baichuan3和4默认是32k context，有Baichuan3-Turbo-128k特化版本。
【阶跃星辰 Step】
阶跃星辰的step-1有32k、128k、256k版本。
Step的风控策略较为严格，只有早先128k测试时通过了一个测试用例，目前已经无法通过风控。
【Minimax abab】
Minimax的abab有abab6.5s-chat为245k。
由于Minimax的API没有返回生成的token数量，所以无法直接计算token速度，本次结果中不列该项。
【商汤 SenseChat】
商汤的 SenseChat系列有32k和128k版本，SenseChat-5 为128k。由于商汤的风控策略过严，本次测试用例均无法通过。
【幻方 DeepSeek】
DeepSeek系列只有deepseek-v2-chat，官方API支持32k，开源版本支持128k。使用了SiliconFlow提供的版本进行测试。
【百度 ERNIE】
百度的模型版本众多，但只有 ERNIE-Speed-128K 和 ERNIE-Lite-128K 为128k，但 ERNIE-Lite-128K 调用失败，只有Speed模型进入测试。
【阿里 Qwen】
Qwen系列有qwen-max-longcontext、qwen-plus支持30-32k。
qwen-long应该是RAG方案，所以本次不列入。
【腾讯 混元】
混元全系列支持32k，lite版本支持256k，standard有256k特化版本。
【SiliconFlow】
由于SiliconFlow在多次相同prompt请求下，能够明显从首个token的延迟上看到后续请求命中了部分缓存的结果，无法准确测量prompt首次计算时候的首个token延迟。
一般应用场景下，用户几乎不会用完全相同的prompt多次进行请求，所以才要排除掉命中缓存的情况。在有公用context的多次LLM调用的业务场景中，这是有意义的，但这并非本次测试所评估的场景。
2.2、测试结果（128k）
数据缺陷说明：
Minimax abab6.5s-chat由于API结果缺输出token数量，无法计算生成速度。
Claude-3-haiku的生成速度太快，所以速度结果不准。
Claude系列模型由于TPD的限制，通过API代理商进行测试。
阶跃星辰由于风控问题，只有一半测试用例。
商汤SenseChat系列由于风控问题，没有测试用例可用。
出于节省成本的角度，claude-3-opus暂未测试，从claude-3-sonnet的效果来看应该可以接近100%正确率。
cohere由于通过API代理商访问，缺输出token数量，无法计算生成速度。
数据指标说明：
Token生成速度是从收到首个token之后开始计算。
2.3、测试结果（32k）
数据缺陷说明：
本次Anthropic的请求方式是直接请求，与上次通过API代理商请求不同，由于Anthropic有多处部署，响应时间上与上次可能无法直接对比。
出于节省成本的角度，claude-3-opus暂未测试，从claude-3-sonnet的效果来看应该可以接近100%正确率。
数据指标说明：
Token生成速度是从收到首个token之后开始计算。
由于32k的token生成速度较快，更容易受到如内容审核等其他环节影响，所以本次测试结果中生成速度跟模型规模没有128k时候的那么明显的正相关性。
选择了mixtral系列和qwen系列的开源模型作为对比，前者由Mistral官方提供API，后者调用Together.ai提供的API。
3、总结
海外头部三家OpenAI、Google、Anthropic在长上下文能力上名不虚传，在128k测试中无论是正确率还是响应速度都是明显超过国内水平的。国内各家距离它们还是有差距的，这才只是128k测试，1M context的能力呢？
总体来看，国内各家主要落后的还是响应时间上和费用上，这对于实际应用影响很大。
对于32k测试结果，从结果可见 32k测试相对于128k测试容易了很多。大多数都能够获得一个不错的成功率，而响应时间和成本方面还有不少距离要追赶。值得一提的是：
BAT三家的效果似乎是相对落后的。
字节的Doubao-pro效果很好。
腾讯的huiyuan-pro没有想象的差，混元正在追赶。
qwen的qwen-max-longcontext该更新了，qwen2在这里的效果明显比闭源模型还好。
交流与合作
如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请私信联系，见 联系方式。
本文于2024.5.28首发于微信公众号与知乎，合集版本于2024.6.7发布于微信公众号。
知乎链接：
https://zhuanlan.zhihu.com/p/699926343
https://zhuanlan.zhihu.com/p/700378183