上一篇我们从Qwen2开始，聊到模型的模型规模和参数，其中提到Qwen2的所有模型均稳定支持32K长度上下文，Qwen2-7B-Instruct与Qwen2-72B-Instruct可支持128K上下文（需额外配置），在模型推理的部分提到"如果您的输入token（包含您设定的历史对话）较长，可能需要更大显存的机器进行支持。"另外，Qwen2模型的推理速度(tokens/s)和显存占用与不同上下文长度也似乎有着千丝万缕的联系。那这个32K长度上下文和128K上下文到底是什么意思呢？区别在哪里呢？原理是如何呢？我们接着往下看。

大模型的上下文长度

在大语言模型中，上下文长度（Context Length）通常指的是模型在一次处理过程中能够理解和生成的文本的最大长度。这包括输入的提示（prompt）和模型生成的响应，如果超过这个长度的字符会被大模型丢弃。

上下文长度的重要性在于：

• 文本理解能力：上下文长度越大，模型能够理解和保持更多的背景信息，从而在生成响应时更有针对性和连贯性。例如，处理复杂的对话时，较长的上下文长度有助于模型记住前面的交流内容。
• 应用场景：不同的应用场景对上下文长度有不同的需求。例如，简短的问答对话可能只需要较短的上下文长度，而长篇文章生成或多轮对话系统则需要更长的上下文长度。

通常，大模型的上下文长度由模型的架构和训练过程决定。部分最新的模型会在设计和训练时特别优化上下文长度，以满足更复杂和多样化的应用需求。然而，由于计算资源和效率的限制，现实中的上下文长度仍然有一定的限制。为了提升模型的性能，开发者可能会通过技术手段（如记忆机制、分块处理等）对长文本进行处理，以在实际应用中尽可能弥补上下文长度的不足。

超长上下文的大模型部署推理的时候，往往会面临如下性能挑战：

• 推理时间变长
• 推理显存空间变大

主流开源大模型支持的上下文长度：

	参数（Params）	上下文长度（Context length）	训练数据量
Llama 3	8B	8k	15T
Llama 3	70B	8k	15T
Gemma 2	9B	8k	8T
Gemma 2	27B	8k	13T
Qwen 2	7B	32k	7T
Qwen 2	72B	32k	7T
Qwen 2	7B-Instruct	128k	7T
Qwen 2	72B-Instruct	128k	7T
GLM 4	9B	8k	10T
GLM 4	9B-Chat	128k	10T
GLM 4	9B-Chat-1M	1M	10T
DeepSeek-V2	236B-A21B	128k	8.1T
DeepSeek-V2	236B-A21B-Chat	128k	8.1T
Mixtral	8x7B	32k	15T
Mixtral	8x22B	64k	15T

主流商业闭源大模型支持的上下文长度：

上下文长度（Context length）
moonshot-v1	8k、32k、128k
OpenAI GPT-4	8k、32k、128k
OpenAI GPT-3.5	4k、16k
GLM-4	128k
通义千问	8k、32k、10000k
文心一言	8k、128k
minimax	8k、32k、245k
Baichuan	32k、128k
Doubao	4k、32k、128k
deepseek	32k、128k
Claude 3	200k
Mistral	32k、64k
零一万物	16k、32k、200k
混元	8k、32k、256k

(部分支持长度可能有变化，基于商业考虑各家厂商对参数和训练数据量很少公开)

上下文长度太短，就无法开启很多领域的应用，比如医疗GPT。想象一下，医患20轮对话之后，对话内容超过了上下文长度限制，模型会自动丢弃掉之前的对话内容，那医疗GPT扮演的医生就不记得病人的基本情况了，也就是我们使用过程中经常出现的模型"失忆"现象。

究其根本原因还是大模型的 Transformer 网络结构的自注意力机制导致的，自注意力机制的计算量会随着上下文长度的增加呈平方级增长，比如：上下文增加32倍时，计算量实际会增长1000倍。另外在大模型实际部署时，企业端根本无法提供很大的算力支持，这也就倒逼厂商无论是扩大模型参数还是文本长度，都要紧守算力一关。因此，较长的上下文会显著增加所需计算量，从而导致推理速度变慢。

另外随着上下文长度的增加显存占用也会增加，自注意力机制不仅计算复杂度较高，其显存占用也呈O(N^2)增长。随着输入序列长度增加，存储自注意力矩阵和中间结果所需的显存显著增加。模型在每一层都会生成中间激活值。这些值需要在前向传播过程中存储在显存中，以便在反向传播过程中使用。较长的上下文意味着更多的中间激活值需要存储，从而增加显存的总体占用。目前有几种发展趋势可以关注：

• GPU算力逐渐充裕且逐渐廉价。
• Transformer不断优化或者出现更好的算法。
• 更多工程上的技术进步和优化手段。

更多技术细节会更新到后续推出的论文和工程技术解读篇章里面，敬请期待。

Tokens计算规则

文本生成模型以 Token 为基本单位来处理文本。Token 代表常见的字符序列。例如，单个汉字"夔"可能会被分解为若干 Token 的组合，而像"中国"这样短且常见的短语则可能会使用单个 Token。大致来说，对于一段通常的中文文本，1 个 Token 大约相当于 1.5-2 个汉字。一个 token 可以是一个单词、一个词的一部分（如词干、词缀），或者是一个字符，具体取决于所用的分词算法和模型的设计。模型将输入文本分解成的一个个独立的片段，模型以这些片段为基础进行处理和生成。

需要注意的是，对于文本模型，Input 和 Output 的总和长度不能超过模型的最大上下文长度。另外，各家大模型厂商对Tokens的定义和计算规则都有细微的差别：

	Token定义、计算规则
Claude	Tokens 是语言模型的最小单个单位，可以对应单词、子词、字符，甚至字节（在 Unicode 的情况下）。对于 Claude，一个 token 大约代表 3.5 个英文字符，但具体数量可能因使用的语言而异。
智谱GLM	Token 是模型用来表示自然语言文本的基本单位，可以直观的理解为“字”或“词”；通常 1 个中文词语、1 个英文单词、1 个数字或 1 个符号计为 1 个token。 一般情况下 ChatGLM 系列模型中 token 和字数的换算比例约为 1:1.6 。
Deepseek	token 是模型用来表示自然语言文本的基本单位，也是我们的计费单元，可以直观的理解为“字”或“词”；通常 1 个中文词语、1 个英文单词、1 个数字或 1 个符号计为 1 个 token。 一般情况下模型中 token 和字数的换算比例大致如下： 1 个英文字符 ≈ 0.3 个 token。 1 个中文字符 ≈ 0.6 个 token。
通义千问	Token是模型用来表示自然语言文本的基本单位，可以直观地理解为“字”或“词”。对于中文文本来说，千问模型的1个token平均对应1.5-1.8个汉字；对于英文文本来说，1个token通常对应一个单词或词根。但在语言模型使用中，字符数目和token数目并不一定是一一对应的，例如在通义千问开源7B模型中： "苹果"对应1个token； "my friends"对应3个token； " 周"对应3个token。
文心一言	1个字母=1个字符，举例，hello=5字符 1个汉字=1个字符，举例，你好=2字符 大模型中，token是指语言模型中用来表示中文汉字、英文单词、或中英文短语的符号。token可以是单个字符，也可以是多个字符组成的序列。
minimax	Token 是自然语言文本中的最小粒度单位，即一个最小的单词或符号，可以直观理解为1 个中文词语、1 个英文单词、1 个数字或 1 个符号。通常自然语言文本是由一个一个Token组成的，每个Token都具备自己的词性、词义等属性。一般情况下，abab系列模型中 Token 和字数的换算比例约为 1:1.33，每一次实际处理 token 数量以模型返回为准。
OpenAI	Language models read and write text in chunks called tokens. In English, a token can be as short as one character or as long as one word (e.g., a or apple), and in some languages tokens can be even shorter than one character or even longer than one word. For example, the string "ChatGPT is great!" is encoded into six tokens: ["Chat", "G", "PT", " is", " great", "!"].
Doubao	通常1个中文词语、英文单词、数字、符号计为 1 个token，当文字未收录在 Token 词库时，可能会有一个字/词对应多个 Token 的情况
Baichuan	Token在这里指的是文本中的一个最小单位，可以是一个词、一个数字或一个标点符号等。一般情况下Baichuan2大模型1个token约等于1.5个中文汉字。
moonshot	1 个 Token 大约相当于 1.5-2 个汉字
Yi	一般而言，在中文文本中，1 个 token 大约对应 1 个汉字；在英文文本中，1 个 token 大约对应 3 至 4 个字母。因此，yi-medium-200k 可以处理约 20w ~ 30w 汉字。
hunyuan	token 为服务输入+服务输出的总额，1token 约等于1.8个中文汉字或3个英文字母

因为不同模型的分词方法不同，所以换算比例也存在差异，每一次实际处理 token 数量以模型返回为准。各大厂商大部分也都提供了token计算器页面，可以在线计算token计算结果，详情见各模型厂商文档。理论上开源大模型与同一家公司的闭源商业大模型的token计算规则是一样的。

tokens价格和速率限制

在大语言模型处理任务的过程中，输入的文本会被转译为Token输入到模型中，而输出则是从Token转译到文本。输入与输出Token的长度直接影响了大语言模型所消耗的算力，所以业界通常采用基于Token数量的计费模式。

鉴于目前各大模型厂商（商业闭源模型）在价格方面频繁变动（降价），且模型API类型又有很多厂商拆分成了：文本大模型、Embeddings（向量化）、Retrieval（知识库）、Finetune（微调）、Assistants（助手）、语音大模型、文生图大模型、模型精调、模型评估等等不同种类，每种的计费方式都不尽相同，这里只整理了各大厂商的产品定价文档链速率限制文档链接及单个模型举例说明，有需要详细了解的请自行查看对应文档。另外基本上主流厂家都对每个模型设置了RPM（Requests Per Minute，每分钟请求数）及TPM（Tokens Per Minute，每分钟tokens数量）的调用限制。模型推理为什么要做速率限制呢？

• 有效防止请求过载：帮助管理总负载情况，避免请求激增导致的服务器性能问题，提高服务可靠性。
• 保障资源的公平性及合理利用：避免某一方过多的请求，影响其他方使用。保障更多方的请求调用和用户的使用体验。
• 安全防护：防止恶意性的攻击，提高整体网络安全。

这是一些限制名词解释：

• QPS: 同一时间内最多处理的请求数
• RPM: request per minute 指一分钟内最多发起的请求数
• TPM: token per minute 指一分钟内最多和模型交互的token数
• TPD: token per day 指一天内最多和模型交互的token数

也有很多厂商根据客户的级别和充值金额来进行限流配额管理，还有部分厂商提供模型提额申请入口。

	计费/定价文档链接	限制/速率文档链接	举例说明
Claude	docs.anthropic.com/zh-CN/docs/…	docs.anthropic.com/zh-CN/api/r…	Claude 3 Sonnet： 成本（每百万标记的输入/输出）3.00/3.00 / 3.00/15.00。 使用等级Build Tier 1 $5，RPM 50，TPM 40,000，TPD 1,000,000。
OpenAI	openai.com/api/pricing…	platform.openai.com/docs/guides…	GPT-4o: US5.00/1Minputtokens，US5.00 / 1M input tokens，US5.00/1Minputtokens，US15.00 / 1M output tokens。 Tier 1，$5 paid，RPM 500，TPM 30,000。
智谱GLM	open.bigmodel.cn/pricing	open.bigmodel.cn/dev/howuse/…	GLM-4： 单价(1K tokens)0.1元。 用量级别1，api调用消耗50元-500元/每月（不含），QPS 10。
Deepseek	platform.deepseek.com/api-docs/zh…	platform.deepseek.com/api-docs/zh…调用模型时的并发限制是多少是否可以提高账号的并发上限	DeepSeek-V2： 输入价格1 元 / 百万 tokens，输出价格2 元 / 百万 tokens。 动态限流。
通义千问	help.aliyun.com/zh/dashscop…	help.aliyun.com/zh/dashscop…	通义千问qwen-max： 输入（input）价格0.04元/1,000 tokens，输出（output）价格0.12元/1,000 tokens。 60 QPM 60，TPM 100,000。
文心一言	cloud.baidu.com/doc/WENXINW…	cloud.baidu.com/doc/WENXINW…	ERNIE 4.0系列： 推理服务-输入0.04元/千tokens，输出0.12元/千tokens。 Tokens量1000万，服务速率限制TPM = 120K，RPM = 120，QPS = 2
minimax	platform.minimaxi.com/document/pr…	platform.minimaxi.com/document/ra…	abab6.5： 0.03元/千tokens。 充值用户RPM 120，TPM 360000。
Doubao	www.volcengine.com/docs/82379/…产品价格	www.volcengine.com/docs/82379/…模型推理限制	Doubao-pro-128k： 推理(输入)定价0.0050 元/千tokens，推理(输出)定价0.0090 元/千tokens，LoRA精调定价0.0500 元/千tokens。 1000 RPM 400000 TPM
Baichuan	platform.baichuan-ai.com/price	platform.baichuan-ai.com/docs/api#3	Baichuan4： 0.1元/千tokens（包含输入和输出）。 当前已认证账号限制 120 rpm，未认证账号限制 12 rpm 且每日请求不超过 300 次。
moonshot	platform.moonshot.cn/docs/price/…产品定价	platform.moonshot.cn/docs/price/…充值与限速	moonshot-v1-128k： 1M tokens 价格¥60.00。 用户等级Tier1，累计充值金额¥ 50，QPS 50，RPM 200，TPM 128,000，TPD 10,000,000。

那在这样的模型使用速率限制下，作为开发者和使用者应该尽量有效控制API调用频率，防止触发速率限制，并优化应用性能，确保用户体验不受影响。下面是一些常见的处理方法：

• 请求排队和节流： 实现一个队列系统，对于超出速率限制的请求进行排队处理。在单位时间内控制请求发送的频率。
• 使用缓存： 对频繁请求的数据进行缓存，设置适当的缓存过期时间。
• 分片请求： 使用分页或者按某种规则分片处理，减少单次请求的数据量和频率。
• 超限反馈和用户提示： 当用户请求超出速率限制时，返回友好的提示信息，告知用户当前操作需等待，并给出预计等待时间
• 使用批处理： 部分模型提供批量请求API，对于可以批量处理的请求，合并成一个请求，以减少调用频率。
• 监控和报警： 监控API调用情况和用户的请求频率，当系统接近速率限制时，预警并主动限制用户请求。

大模型上下文缓存机制

着重提一下上下文缓存，在总结上文内容的过程中发现月之暗面moonshotAI的文档里7月更新了一个上下文缓存的内容：Moonshot AI - 开放平台

Context Caching （上下文缓存）是一种高效的数据管理技术，它允许系统预先存储那些可能会被频繁请求的大量数据或信息。这样，当您再次请求相同信息时，系统可以直接从缓存中快速提供，而无需重新计算或从原始数据源中检索，从而节省时间和资源。使用 Context Caching 时，您首先需要通过 API 创建缓存，指定要存储的数据类型和内容，然后设置一个合适的过期时间以保持数据的时效性。一旦缓存创建完成，任何对该数据的请求都会首先检查缓存，如果缓存有效，就直接使用，否则需要重新生成并更新缓存。这种方法特别适用于需要处理大量重复请求的应用程序，可以显著提高响应速度和系统性能。Context Caching 特别适合于用频繁请求，重复引用大量初始上下文的情况，通过重用已缓存的内容，可以显著提高效率并降低费用。因为这个功能具有强烈的业务属性，我们下面简单列举一些合适的业务场景：

• 提供大量预设内容的 QA Bot，例如 Kimi API 小助手。
• 针对固定的文档集合的频繁查询，例如上市公司信息披露问答工具。
• 对静态代码库或知识库的周期性分析，例如各类 Copilot Agent。
• 瞬时流量巨大的爆款 AI 应用，例如哄哄模拟器，LLM Riddles。
• 交互规则复杂的 Agent 类应用，例如什么值得买 Kimi+ 等。

这个功能目前还处在公测阶段，且是收费项目，但理论上确实面对一些特定场景缓存非常有效，能节约很大成本。后续所有大模型厂商可能都会跟进这个功能，期待后续有更多优化手段出现。

多语言支持

我们以Qwen2为例，Qwen2投入了大量精力研究如何扩展多语言预训练和指令微调数据的规模并提升其质量，从而提升模型的多语言能力。尽管大语言模型本身具有一定的泛化性，Qwen2还是针对性地对除中英文以外的27种语言进行了增强：

地区	语言
西欧	德语、法语、西班牙语、葡萄牙语、 意大利语、荷兰语
东欧及中欧	俄语、捷克语、波兰语
中东	阿拉伯语、波斯语、希伯来语、土耳其语
东亚	日语、韩语
东南亚	越南语、泰语、印尼语、马来语、老挝语、缅甸语、宿务语、高棉语、菲律宾语
南亚	印地语、孟加拉语、乌尔都语

此外，Qwen2针对性地优化了多语言场景中常见的语言转换（code switch）问题，模型当前发生语言转换的概率大幅度降低。使用容易触发语言转换现象的提示词进行测试，观察到Qwen2系列模型在此方面能力的显著提升。我们这里也做了一个总结，不同开源模型对多语言支持的程度对比：

	多语言支持
Llama 3	超过5%的Llama 3预训练数据集由高质量的非英语组成，涵盖30多种语言的数据。然而，我们并不期望在这些语言中有与英语相同的表现水平。 这样也催生了基于llama3全参数微调的shenzhi-wang/Llama3-8B-Chinese-Chat、shenzhi-wang/Llama3-70B-Chinese-Chat等类似的微调模型，Chinese-Chat是国内首批专门针对中英文用户进行微调的LLM之一，基于Meta-Llama-3-70B-Instruct模型，使用的微调算法是ORPO，大大减少了“中文问英文”和中英文混杂的问题。
Gemma 2	与 Meta 的 Llama3相比，Gemma2的一个显着优势是它对印度语言的处理。Gemma2因其分词器而出类拔萃，该分词器专为这些语言设计，并包含大量256k 个令牌以捕捉语言的细微差别。另一方面，尽管 Llama3支持多种语言，但由于词汇量和训练数据有限，在印度语脚本的标记化方面遇到了困难。这使得 Gemma2在涉及印度语的任务中具有优势，使其成为在这些领域工作的开发人员和研究人员的更好选择。 同样针对中文有shenzhi-wang/Gemma-2-9B-Chinese-Chat、shenzhi-wang/Gemma-2-27B-Chinese-Chat等针对中文和英文用户的指令调整语言模型（instruction-tuned language model）。
Qwen 2	除中英文以外的27种语言进行了增强，针对性地优化了多语言场景中常见的语言转换（code switch）问题。
GLM 4	本代模型增加了多语言支持，支持包括日语，韩语，德语在内的 26 种语言
DeepSeek-V2	在中文能力方面，DeepSeek-V2 在 AlignBench 排名中全球领先
Mixtral	支持英语、法语、意大利语、德语和西班牙语
Yi 1.5	中文能力强
Baichuan2	翻译能力强
Phi-3	尽管phi-3-small通过增加多语言数据进行了优化，但Phi-3系列模型的主要语言能力仍然主要集中在英语上

这里有一篇博客《Gemma 2 (9B & 27B) Evaluation — vs. Open/Closed-Source LLMs》可以简单对比一下各大开源模型多语言的能力。

总结一下本篇主要还是一些知识扫盲和总结归纳内容，为了照顾普通读者，没有深入技术细节进行讲解，下一篇我们将着重探讨"大海捞针"的技术细节和重要性以及开闭源各方对"Scaling Law"的一些不同观点，咱们下期见。