旗下微信矩阵:

Kimi首发“上下文缓存”技术,助推长文本大模型降本90%

2024-07-02 16:17 · 互联网

近日,月之暗面宣布 Kimi 开放平台正式公测新技术——上下文缓存(Context Caching),该技术在 API 价格不变的前提下,可为开发者降低最 高 90% 的长文本大模型使用成本,并且显著提升模型的响应速度。

据了解,月之暗面是国内首 家面向开发者推出上下文缓存(Context Caching)技术的大模型公司。

上下文缓存(Context Caching)技术的基本原理是,系统预先存储那些可能会被频繁请求的大量数据或信息。这样,当用户再次请求相同信息时,系统可以直接从缓存中快速提供,而无需重新计算或从原始数据源中检索,从而节省时间和资源。

上下文缓存(Context Caching)技术可以带来降本和提速两大价值。首先,通过缓存重复性输入的大量数据,对于公共上下文仅收取一次费用,上下文缓存(Context Caching)技术大大降低了开发者使用长文本旗舰大模型的成本,最 高可降本达 90%。其次,上下文缓存(Context Caching)技术还有助于提升大模型API的响应速度,实测可将 128K 长文本大模型的首 token 延迟降低 83% 左右,从平均 30 秒左右降低到平均 5 秒内。

在长上下文和高负载的业务场景上,上下文缓存带来的降本和提速效果尤为显著。常见场景包括提供大量预设内容的问答机器人,例如 Kimi API 小助手;针对固定的文档集合的频繁查询,例如上市公司信息披露问答工具;对静态代码库或知识库的周期性分析,例如各类 Copilot Agent;瞬时流量巨大的爆款 AI 应用,例如哄哄模拟器;交互规则复杂的 Agent 类应用,例如什么值得买的 Kimi+ 等

以常见的固定文档大量提问场景为例。某硬件产品说明书大概 9万字,换算 Tokens 长度大概 64K,该产品售前支持人员需要在 10 分钟内,密集对产品的功能/使用方式进行 40 次问答,每次的问题大概 100 个字,要求模型的输出需要基于产品说明书来回答,回答问题在 120 字以内。

按照大模型问答的 Tokens 计算逻辑,售前支持人员需要每次向模型输入的 Tokens =文档 Tokens +问题 Tokens,10 分钟内 40 次的问答共计需要消耗 Tokens 2.56 M,128k 模型价格为 60元/M,预计原始花费需要 153.84 元。若该场景接入上下文缓存(Context Caching)技术:9万字的文档只收取一次创建 Cache 和存储 10 分钟 Cache 的费用,10分钟内的40次提问,将只收取问题的 100 字+ 回答的 120 字的费用,预计花费 11.88 元。节省了 141.95 元,相当于费用降低 90% 左右。

响应速度方面,以128k模型的一次4万字(约30k tokens)的推理请求为例。通常向模型提问,平均要 30 秒返回首 Token。接入上下文缓存技术后,最快可 1 秒内完成首 Token 返回。经过大量测试,接入上下文缓存功能后,128k 模型的首 Token 延迟平均可降至 5 秒内,降低了 83%左右。

需要注意的是,上述测试效果基于 1 token = 1~1.5个文字和字符,使用 128k 模型进行测算。具体的效果根据业务情况/模型选择不同,会有略微差别。

上下文缓存(Context Caching)技术在公测期间将首先提供给 Kimi 开放平台的 Tier5 等级开发者,后续陆续增大开发者公开测试范围。

Kimi 大模型目前已接入了钉钉、扣子等平台,用户或开发者可以在这些平台选用 Kimi 大模型,借助出色的长文本和指令遵循能力搭建个性化的智能体应用。Kimi 开放平台的开发者注册量自从今年 2 月份以来复合增长率超过 175%,在投研服务、法律尽调、企业知识库问答、辅助软件开发等场景获得广泛应用。近期,Kimi 开放平台陆续上线了工具调用(Tool Use)、Partial Mode、上下文缓存(Context Caching)等能力,持续帮助开发者高效打造更有想象力的AI 应用。

(免责声明:本文转载自其它媒体,转载目的在于传递更多信息,并不代表本站赞同其观点和对其真实性负责。请读者仅做参考,并请自行承担全部责任。)