本文构造了一个比大海捞针稍难的长上下文测试方案，并对比了目前支持128k以上的上下文的闭源API LLM模型。
仅从这个很狭隘的测试来看，海外头部三家厂商在长上下文上还是领先于国内的。
本文的测试代码框架已经开源，方便大家测试其他数据。
本文没有得到任何厂商赞助，累计花了2700RMB充值各家平台。我也是有点测不起了。
Github地址：
https://github.com/SomeoneKong/llm_long_context_bench202405/tree/bench_128k_v1
0、前言最近一段时间各家基座LLM爆发了一波更新，>=128k的long context能力已经逐渐普及。而目前对于long context的测试就只有大海捞针，其实大海捞针只是一个最简单的测试，理论上RAG的召回过程做好了也一样能解决。
我也是看到别人转的一个测试之后有些手痒，所以尝试将其更完善一些，由此作为一个横向对比的方式，（希望国内各家基座LLM厂商能够更卷一点）。需要说明的是，这个测试对于long context场景仍然十分简单，但已经有区分度了，有一些模型已经不能通过，这就够了。
另外在测试中发现不同模型的响应速度有较大差异，所以也把响应时间纳入比较结果。
想要在测试中消除偶然随机性导致的影响的成本很高，我尽量在成本可控的范围内减少这方面的影响，但仍然离完美还有很大距离。我会开源本文测试过程的代码，方便读者进行复现和基于此改造。
整体来说这个测试仍然十分偏颇，希望能够抛砖引玉，最终能够有一个更好比较各家基座LLM能力的方案。
1、测试方案说明本文的测试仍然是有点类似大海捞针性的，但是需要捞多根针。
首先选取一个长文档作为基础，为了横向比较国内外模型语言选择为英文。这里选择哈利波特的第三部和第四部。
将一个问题的几个条件分别插入到文章的随机位置，插入的内容作为一个独立段落出现，不会插入在一个段落中。然后要求LLM根据输入的文档和问题进行回答，可以使用CoT。
根据各模型的context能力，分为两个级别：128k、32k。不再单独评比8k水平的模型。由于时间所限，本次文只完成了128k的测试。
以下是插入的问题：
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限制制约了跑实验的速度。实际上我基本是默认串行跑所有请求的。
【为什么选择哈利波特】
选择标准是：英语、自然语言为主题的内容（排除公式类）、是最近一段时间写成的、足够长（>=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全系模型都满足128k（1M），选择 gemini-1.5-flash 和 gemini-1.5-pro 进行测试。
【OpenAI】
OpenAI的模型细分版本较多，但只有GPT4系支持128k，考虑到成本问题只选择最新的 gpt-4o-2024-05-13 进行对比。
【Anthropic Claude】
Claude 3 全系满足128k（1M），claude-3-sonnet的效果就已经足够好，考虑到成本问题 claude-3-opus 不列入测试。
Anthropic 官方API有个很低的TPD限制，本次测试任务无法完成，所以只能转而使用API代理商进行请求，这可能影响到对时间的统计。
需要说明的是：Claude-3-haiku的生成速度太快，所以token生成速度结果不准。
【Reka】
Reka的 reka-flash 和 reka-core 支持128k，但测试发现服务端失败率太高，所以整体放弃测试。
Reka目前还不支持流式返回。
【智谱 GLM】
智谱的 glm-3-turbo 和 glm-4 都支持128k，都入选。
智谱官方并没有说有TPM限制，不确定是否有被限流。
【零一万物 Yi】
Yi系列目前只有 yi-medium-200k 满足 128k。
【月之暗面 Moonshot】
moonshot-v1有128k版本。
【字节 Doubao】
Doubao系列模型有 Doubao-pro-128k 和 Doubao-lite-128k 支持128k，但截至发文我卡在它SDK的鉴权方式上还没有搞定，所以本次不列入。欢迎有兴趣的同学在项目中对这块贡献代码。
【百川 Baichuan】
百川目前刚发布了Baichuan3-Turbo和Baichuan4的API，由于产品线较多，所以忽略更早的Baichuan2等。
Baichuan3-Turbo选择Baichuan3-Turbo-128k版本。
Baichuan4官方未说明context能力，但测试发现测试用例也能跑，通过返回的usage发现输入的各家一般被编码为100k token的输入被当成30k左右。不知道是否是Baichuan4使用了超大的token词表。
Baichuan4的结果是非常糟糕的，全部成功率都是0%，以及考虑到如果是30k token的话，那么速度和时间方面的数据跟其他模型也没有可比性，所以本次不列入。
【阶跃星辰 Step】
阶跃星辰的step-1有128k版本，使用此版本进行测试。
Step的风控策略也较为严格，本次有一个测试用例无法通过。
在本文发布前，阶跃星辰的同学反馈我测试step-1-128k时候它们模型正好放在低配置集群上，所以又再补充了step-1-256k的结果。后续阶跃星辰还会再调整不同模型的硬件配置安排。
【Minimax abab】
Minimax的abab只有abab6.5s-chat满足128k（240k）。
由于Minimax的API没有返回生成的token数量，所以无法直接计算token速度，本次结果中不列该项。
【商汤 SenseChat】
商汤的 SenseChat-128K 和 SenseChat-5 都支持128k，但由于商汤的风控策略过严，本次使用的两个测试都无法通过，只能放弃。
【百度 ERNIE】
百度的模型版本众多，但只有 ERNIE-Speed-128K 版本支持128k。
ERNIE-Speed-128K的模型效果也十分糟糕，全部正确率都是0%，这并非数据录入错误。
【阿里 Qwen】
Qwen系列官方没有支持128k的模型，只有一个实现方案语焉不详的qwen-long。测试来看它不支持通过prompt输入 128k，结合其他测试来看应该是RAG方案。所以本次不列入。
2.2、测试结果
数据缺陷说明：
Doubao-pro-128k 和 Doubao-lite-128k的接入没有搞定，缺数据
Minimax abab6.5s-chat由于API结果缺token生成速度数据
Claude-3-haiku的生成速度太快，所以速度结果不准。
Claude系列模型由于TPD的限制，通过API代理商进行测试。
阶跃星辰由于风控问题，只有一半测试用例。
阶跃星辰后续会调整硬件配置，未来结果还会有变化。（其他家大概也会由此开始优化性能吧）
商汤SenseChat系列由于风控问题，没有测试用例可用。
出于节省成本的角度，claude-3-opus暂未测试，从claude-3-sonnet的效果来看应该可以接近100%正确率。
数据指标说明：
Token生成速度是从收到首个token之后开始计算。
海外头部三家OpenAI、Google、Anthropic在长上下文能力上名不虚传，无论是正确率还是响应速度都是明显超过国内水平的。国内各家距离它们还是有差距的，这才只是128k测试，1M context的能力呢？
总体来看，国内各家主要落后的还是响应时间上，无论是首token的延迟时间还有token生成速度都是落后的，这对于实际应用影响很大。
百度的LLM其实并不擅长long context，只是由于ERNIE-Speed-128K因素挤入本次榜单，导致被吊打。但这并不是说只有百度是最烂的，其他没有上榜的模型之所以把context写的较小也是有原因的。虽然我还尚未做完整的32k测试，但初步来看，qwen的long context能力也让人皱眉，其他未上榜的就不一一列举，有兴趣的读者可以自行使用我的代码进行测试。
本来是想做完32k测试一起发的，但目前来看本周末时间不够了。测试也比想象的还要耗时和费钱，32k的测试何时能发我还不确定。欢迎对此有兴趣的同行来给这个项目贡献其他厂商的API适配代码，或者基于此构建新的测试。
