AI API 的并发控制应该怎样设计，Token 数量为什么比请求数量更值得关注

AI API的并发控制应该怎样设计 Token数量为什么比请求数量更值得关注

很多开发者第一次搭建AI API服务时，最容易想到的是限制同时处理多少个请求。例如规定服务器最多同时处理10个、50个或者100个请求，以此避免服务器过载。这种方法对于普通Web服务比较直观，但对于大语言模型推理系统来说，仅仅统计请求数量往往不够，因为两个请求虽然在数量上都是一个，但它们消耗的计算资源可能存在巨大差异。

一个只包含几十个Token的简单问题，与一个包含数万Token上下文的长文档分析请求，对GPU计算、显存以及KV Cache的压力完全不同。如果系统只按照请求数量控制并发，那么几个超长请求就可能迅速占满GPU资源，而大量短请求却可能同时进入队列。因此，设计AI API的并发控制时，除了关注请求数量，还需要关注输入Token数量、输出Token数量、上下文长度以及不同阶段的计算资源消耗。

在大语言模型推理过程中，可以把请求大致理解为两个重要阶段。第一个阶段是Prefill，也就是模型读取并处理用户提交的上下文；第二个阶段是Decode，也就是模型逐步生成回答。Prefill通常需要一次性处理大量输入Token，而Decode则按照生成过程逐步产生新的Token。两者的计算特征并不完全相同，因此单纯使用请求数作为系统负载指标，很难准确反映GPU当前究竟有多忙。

KV Cache是长上下文推理中非常重要的一项资源。模型在生成文本时，会保存此前已经处理过的一部分注意力计算结果，从而避免每生成一个新Token都重新计算整个上下文。随着上下文长度增加，KV Cache通常也会随之增加，因此长上下文请求可能占用大量GPU显存。如果同时运行多个长上下文请求，显存压力可能迅速超过系统能够承受的范围。

这也是为什么AI API的并发控制不能简单理解成传统意义上的连接数限制。对于普通HTTP服务来说，一个请求可能只占用少量内存和CPU资源，但对于大语言模型来说，一个请求可能携带数千甚至数万Token，并且还可能要求生成大量输出内容。服务器真正需要控制的不是有多少个用户按下了发送按钮，而是这些请求合计需要消耗多少推理资源。

不过，这并不意味着Token数量可以直接转换成一个固定的GPU资源数字。不同模型的参数规模、注意力结构、KV heads数量、数据类型以及推理框架都会影响实际资源消耗。同样数量的Token，在不同模型和不同硬件上产生的计算和显存压力可能完全不同。因此，工程系统不应该简单规定一个所谓每个Token固定占用多少MB显存，而应该通过实际压测建立自己的资源模型。

比较实用的方法是同时监控几个指标。请求并发数可以反映系统当前有多少任务正在执行，输入Token数量可以反映Prefill压力，输出Token数量可以帮助估算Decode阶段的工作量，而KV Cache使用率则可以直接反映长上下文请求对显存的压力。此外，还应该观察GPU利用率、显存使用量、队列等待时间以及每秒生成Token数量等指标。

在API网关层面，可以首先设置基本的请求并发上限。例如一个服务最多允许一定数量的请求进入推理队列。这个限制主要用于防止大量请求瞬间涌入服务器，但它不应该成为唯一的控制机制。对于Token消耗特别大的请求，还应该设置输入上下文长度和最大输出Token数，避免单个请求无限制地占用计算资源。

进一步的设计可以采用Token预算的思路。系统收到请求以后，先估算输入Token数量，再结合用户允许生成的最大Token数量计算一个资源预算。资源预算并不需要精确预测最终会生成多少Token，而是可以作为调度系统判断请求成本的一个指标。例如，短问题可以快速进入处理队列，而超长文档则可能受到更严格的并发限制。

对于多用户SaaS平台，这种控制尤其重要。如果所有用户共享同一组GPU，而系统只限制总体请求数，那么一个客户提交大量长文档以后，就可能影响其他客户的正常使用。因此，可以进一步建立租户级别的并发和Token配额，让不同用户或者不同套餐拥有不同的资源上限。

队列系统也是AI API并发控制的重要组成部分。当GPU暂时无法继续接受新的推理任务时，并不应该让所有请求同时进入计算环节，而应该进入等待队列。调度器可以根据请求长度、优先级、等待时间以及当前GPU资源状态决定下一个任务。对于商业AI服务来说，公平性同样重要，否则单纯让长请求优先可能导致大量短请求长期等待。

现代推理框架还会利用连续批处理等技术提高GPU利用率。传统批处理往往需要等待一批请求准备完成后再一起处理，而连续批处理能够让不同请求在生成过程中的不同时间点加入或退出批次，从而更加充分地利用GPU资源。这种机制也是为什么现代大模型服务不能简单套用传统Web服务器的并发模型。

Prefix Cache或者KV Cache复用也可以降低重复上下文带来的计算成本。例如一个企业内部AI系统可能有大量请求都使用相同的系统提示词、知识库前缀或者固定文档。如果推理框架能够复用已经计算过的前缀，就可以减少重复Prefill工作。不过，这类缓存同样需要占用内存，因此缓存策略必须和显存容量以及请求规模一起考虑。

硬件环境也会直接影响并发控制策略。GPU的显存容量决定了系统能够同时容纳多少模型参数、KV Cache以及其他运行数据，而GPU计算能力则影响Token生成速度。多GPU系统还需要考虑GPU之间的数据传输和模型并行方式。因此，同一个模型部署在不同GPU服务器上，即使API接口完全一样，也不能简单使用相同的并发参数。

在实际部署中，与其一开始就人为规定一个很高的并发数，不如通过压力测试逐渐找到系统的合理范围。可以分别测试短输入、长输入、短输出和长输出，然后观察不同负载下的首Token延迟、Token生成速度、平均响应时间、P95或P99延迟以及GPU显存使用情况。通过这些数据，可以建立更加接近真实业务的容量模型。

还需要注意限流和并发控制并不是同一件事情。限流主要解决单位时间内允许进入多少请求的问题，而并发控制主要解决同一时间有多少任务正在执行的问题。Token配额则进一步限制用户在一定时间内能够消耗多少模型资源。一个成熟的AI API通常需要把这几个机制组合起来，而不是依赖单一的请求数量限制。

因此，AI API的并发控制应该从单纯的请求数量管理，逐渐升级为面向实际推理资源的管理体系。请求数仍然重要，但它只是其中一个指标；输入Token、输出Token、上下文长度、KV Cache使用率、GPU利用率以及队列等待时间，往往能够更加准确地反映系统压力。对于一个真正面向大量用户运行的AI服务来说，最终目标并不是让服务器接受尽可能多的请求，而是在可接受的延迟范围内，让有限的GPU资源产生尽可能高的有效Token吞吐量。

如果把整个系统进一步简化，可以形成一条比较清晰的控制链条：请求进入API网关后进行身份验证和基础限流，然后计算Token预算并检查上下文长度，再进入调度队列，最后由推理引擎根据GPU显存、KV Cache和当前批处理状态决定实际执行方式。这样的设计比单纯设置一个同时处理多少个请求的数字更加可靠，也更适合真正运行在生产环境中的AI API服务。