LLM Stateful API前瞻【2023.10】

0、前言

最近网上开始传OpenAI可能会在11月的开发者大会上发布LLM的Stateful API，并可能明显降低多轮对话场景的成本。

目前该消息来源不确定，是否能达到传闻所称的大幅降低成本也很值得怀疑。

但目前确实是一个适合讨论Stateful API方案的时点，所以才有了本文，讨论一下这个方案会有哪些潜在的优势。

1、Stateless API

以早期OpenAI的LLM API为代表，大部分LLM供应商的API都是无状态的（即Stateless）。很明显，这个方式必然有一些优势，具体来说有：

• 无状态的服务在工程实现上更容易，无论是session状态管理、流量平衡等等方面。

• 虽然服务器建立一个session，仅仅保存对话历史的成本也并不算高，但单纯保存文本也并没有太多的好处。

• 让client端每次提交完整的对话历史还可以方便client端定制和修改历史对话、每轮的LLM参数，甚至在同一个对话历史中交错使用多种模型等等。

Stateless API是一个更接近于底层推理过程的抽象层，优先提供这个抽象层面几乎是最佳实践。

但这种方式也有一些缺点：在多轮对话场景下，序列的请求中包含了很多重复的部分，这些内容会对应重复的计算。虽然在Stateless API下也可以针对性的进行缓存设计，但由于这套API暴露了太多内部状态，使得一些更加复杂的多轮对话优化方案变得难以实现，例如：

OpenAI存在某种自己的超长对话历史压缩方式，但在stateless API下，client端可能会自己对历史进行滑窗截断，导致很难无感知的命中这种缓存优化。

同时这些针对于多轮对话的优化策略的计算量也很难直接的反映到单次stateless API的计费方式中。自然的方式还是提供针对多轮对话session的stateful API，并针对性的设计对于session的计费方式。

2、基于对话Session的Stateful API

在基于session的API中，就可以更加容易和自然地使用如下优化方案：

【1】多轮对话的KV-Cache（与 状态存储方案讨论）

KV-Cache在单轮对话中就可以使用，在多轮对话下也同样有效。但问题就是如何保存一次请求的KV-Cache，并在下次如何调取。以及管理这些缓存数据。

先估算单次query请求需要的Cache大小。KV-Cache占用数据量为：

2 x 浮点数据类型字节数 x 模型层数 x 模型内部维数 x 序列长度

对于30B左右模型、1k token长度的请求，大概需要小几GB的数据量需要存储，数据量属于不大不小。

数据写入存储到下一次调用的时间参考人类交互，可能至少要等待数秒。

能够接受的缓存数据读取延迟较高，可达1秒级别，因为LLM生成过程本身就较慢。

考虑到上述场景，并考虑工程实现复杂度，一个比较平衡的方式是：使用分布式对象存储服务。例如类似AWS S3；query完成时，保存KV-Cache和其他需要缓存的数据到S3；下一个query到达时，处理的节点机器重新拉取缓存数据，送入显存。这个方式还可以附加一个可选的本机SSD磁盘缓存和内存缓存策略。分布式对象存储系统可以随意的划分多个Region，优化远程通讯量并减少系统单点风险，但需要把后续请求也路由到同样的Region。

除此之外，也可以只使用单机磁盘存储状态，或者说把Region设置为机器级别，不过这会制约负载平衡策略的决策空间和效果。

【2】私有的长对话历史的压缩/检索策略

目前长对话历史的压缩策略都是调用API的应用层进行处理，但实际上在基座模型供应商的层面也能做很多方案。

从简单的滑窗策略到session级别向量召回、甚至更重的检索策略等等都可以做，甚至可以提供参数由用户指定方案，来平衡效果和成本。

当然，这会是一个闭源的策略，从请求的结果并不容易推测内部的实现策略，特别是他的策略较为复杂的时候。

【3】多模态API 与 文档输入

在一次对话中，可以缓存的内容并不只KV-Cache和对话历史的压缩/检索结果，当支持多模态输入的时候，输入的图片、文档的预处理结果、内部索引也都是可以被记录到session存储的。

Stateful API才是多模态的多轮对话下最自然的API风格。

3、超越短期Session

在前面的思路下，其实不止单文档输入，就算是知识库的构建，可以使用Stateful的API，只不过作为对话session级别可能并不合适。会需要生存时间更长的workspace级别的概念，用来存储知识库的信息，并提供更新方式。需要对话查询时，从具体的某个workspace来创建对话session。

类似的，也可以构建长时间存在的长期对话session，提供极长的等效context window能力，满足持续的无遗忘对话场景需求。

甚至说大部分的2C产品的功能都可以通过这种Workspace、长期session、短期session的方式来提供。说基座LLM公司可以吃下很多上层应用，诚不欺我。

能够限制基座LLM公司的就只有它自己的战略路线和它的研发能力了。

交流与合作

如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请私信联系，见 联系方式。

希望留言可以到知乎对应文章下留言。

本文于2023.10.17首发于微信公众号与知乎。

知乎链接 https://zhuanlan.zhihu.com/p/661799327