参数与最佳实践#

既然我们已经回顾了用于测量 LLM 推理延迟和吞吐量的基准测试指标,现在让我们讨论一些重要的测试参数及其扫描范围,这些参数和范围确保有意义的基准测试和质量保证。

用例#

应用程序的特定用例会影响序列长度(即 ISL 和 OSL),而序列长度又会影响系统消化输入以形成 KV 缓存和生成输出令牌的速度。较长的 ISL 会增加预填充阶段的内存需求,从而增加 TTFT,而较长的 OSL 会增加生成阶段的内存需求(带宽和容量),从而增加 ITL。您必须了解 LLM 部署中输入和输出的分布,才能最好地优化硬件利用率。常见的用例和可能的 ISL/OSL 对包括以下内容。

  • 翻译:这包括语言和代码之间的翻译,其特点是 ISL 和 OSL 相似,每个约为 500~2000 个令牌。

  • 生成:这包括通过搜索生成代码、故事、电子邮件和通用内容。其特点是 OSL 为 O(1000) 个令牌,远长于 ISL 的 O(100) 个令牌。

  • 摘要:这包括检索、思维链提示和多轮对话。其特点是 ISL 为 O(1000) 个令牌,远长于 OSL 的 O(100) 个令牌。

如果您有真实数据,也可以将其作为输入提供。GenAI-perf 支持 HuggingFace OpenOrcaCNN Dailymail 数据集。

负载控制#

  • 并发 N 是并发用户的数量,每个用户都有一个活动请求,或者等效地说是 LLM 服务同时处理的请求数量。一旦每个用户的请求收到完整响应,就会发送另一个请求,以确保在任何时候,系统都恰好有 N 个请求。

    关于 LLMperf 的注意事项:它以 N 个请求的批次发送请求,但有一个排空期,它会等待所有请求完成,然后再发送下一批。因此,在批次结束时,并发请求的数量逐渐减少到 0。这与 GenAI-perf 不同,后者始终确保在整个基准测试期间都有 N 个活动请求。

    并发最常用于描述和控制推理系统上引起的负载。

  • 最大批处理大小:批处理是推理引擎正在处理的同步请求组。这可能是并发请求的子集。最大批处理大小参数定义了推理引擎可以同时处理的最大请求数。

    如果并发超过最大批处理大小乘以活动副本数,则某些请求将不得不排队等待稍后处理。在这种情况下,您可能会看到由于等待插槽打开的排队效应,导致 Time-to-first-Token 值增加。

  • 请求速率是另一个可用于通过确定发送新请求的速率来控制负载的参数。使用恒定(或静态)请求速率 r 意味着每 1/r 秒发送 1 个请求,而使用泊松(或指数)请求速率则确定平均到达间隔时间。

    GenAI-perf 同时支持并发和请求速率,但是我们建议使用并发(与请求速率一样,如果每秒请求数超过系统吞吐量,则未完成请求的数量可能会无限增长)。

    在指定要测试的并发数时,最好扫描一系列值,从最小值为 1 到最大值不大于最大批处理大小。这是因为当并发大于引擎的最大批处理大小时,某些请求将不得不排队。因此,系统的吞吐量通常在最大批处理大小附近饱和,而延迟稳步增加。

其他参数#

  • “ignore_eos”:大多数 LLM 都有一个特殊的序列结束 (EOS) 令牌,它表示生成的结束。它表明 LLM 已生成完整响应,应停止。在一般使用情况下,LLM 推理应尊重此信号并停止生成更多令牌。ignore_eos 参数通常指示 LLM 推理框架是否应忽略 EOS 令牌并继续生成令牌,直到达到 max_tokens 限制。出于基准测试目的,此参数应设置为 True,以便达到预期的输出长度并获得一致的测量结果。

  • 采样与贪婪:不同的采样策略可能会对 LLM 生成速度产生影响。例如,贪婪可以通过简单地选择具有最高 logits 的令牌来实现(无需标准化和排序令牌上的概率分布,从而节省计算)。有关不同采样方法的详细说明,请参阅此 博客。无论选择哪种采样方法,在同一基准测试设置中保持一致都是一个好习惯。