如何在不访问专用实例的情况下提高GPT-4的吞吐量

在AI和大模型技术领域，吞吐量是一个关键的性能指标。最近，cursor_ai通过逆向工程的方法，成功地在不访问OpenAI的专用实例的情况下，将GPT-4的吞吐量提高了2-3倍。本文将详细介绍他们是如何做到的。

专用实例的优势

首先，只有在使用OpenAI的专用容量时，这种提升才是可能的。对于大型组织和高使用量的场景，出于成本考虑，选择专用容量是明智的选择。专用容量允许用户承诺在一段时间内使用一定量的服务以换取降低的价格。

更重要的是，它提供了一个不同的抽象层次：模型现在运行在“实例”上。每个实例可以被视为运行着某个大型变压器模型的机器（或机器组）。

在cursor_ai的慢速池中，所有请求都进入一个队列，并且只有在“有足够容量”的情况下才会被处理。最初，他们通过每个实例每分钟的令牌数（TPM）来衡量容量，这是一个合理的初步尝试，但远非完美。

他们的工作负载主要由长提示（>4000提示令牌）的生成任务所主导。在高使用量期间，他们必须受到KV缓存的内存带宽限制（假设不使用MQA风格的注意力机制）。因此，他们只关心实例上的内存负载（而不是计算负载）。

由于几乎所有的内存带宽都被用于读取KV缓存，且KV缓存的大小与活跃令牌的数量成正比，这意味着内存使用量约等于某个常数c_1乘以活跃令牌的数量。

活跃令牌是指对于一个活跃的流式请求，计算提示令牌和到目前为止生成的令牌数量。随着流的继续，这个数字会增加。当请求结束时，他们会减去最终的计数，然后将这个总数跨所有请求求和。

为了测试这个假设，cursor_ai构建了一个分布式令牌记账系统，使用Redis和lua脚本来跟踪活跃令牌。记住，在流式传输期间对令牌进行记账是必须的，因为这需要精确到秒。

最后，他们更新了请求队列逻辑：只有当预计的延迟低于目标时，才会从队列中弹出传入的请求。在他们的慢速池中，对于相同的延迟目标，他们看到了吞吐量的2倍提升！而且实际的内存使用现在是一条平坦的线。

通过这种方法，@cursor_ai不仅提高了GPT-4的吞吐量，还为我们提供了一个关于如何更有效地管理大型AI模型的宝贵案例。这种技术的应用，无疑将推动AI技术的进一步发展和优化。