LLM 服务和优化实践 (Chinese Edition)

第9章. LLM 优化实践

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

优化是一个动态目标：在不同的 环境中，“最佳”策略会发生变化。 由于资源有限，您无法对每种选项进行穷举测试。为了帮助您针对自身领域高效优化，我们精心挑选了一些真实案例，展示关键因素——硬件配置、模型选择、内存和键值缓存行为、分布式服务以及流量模式——如何影响服务性能，以及如何衡量和解读这些差异。这种理解将赋予您直觉，助您在约束条件下找到最佳服务配置。

在本章的实践环节中，我们将把前几章所学内容付诸实践。以开源的 Qwen3-14B 模型配合 vLLM 作为示例，我们将带您逐步完成一个实用的 LLM 服务优化流程，并展示如何实现服务架构的横向和纵向扩展。

我们将从一份简明的优化计划开始，并按部就班地执行——包括环境搭建、评估工作负载准备、实验运行、在单GPU和多GPU配置上部署模型、结果分析，以及应用前文介绍的技术。最后，我们将总结一套基于自身实战经验的经验教训和权衡建议，这些内容可作为您未来优化工作的指导原则。

读完本章后，您将清晰了解 LLM 服务优化的实际操作流程，并有信心根据自身用例和流量模式对 LLM 进行优化。

实验代码

您可以在 ch09 文件夹中。由于本实验需要高性能 GPU（如 NVIDIA L40S），某些情况下还需多 GPU 硬件，因此许多读者可能无法获取必要的计算资源。

为了让本章内容更易于理解，我们准备了一个Jupyter 笔记本，其中不仅包含完整的实验代码，还包含每个优化步骤的输出结果——即使您不亲自运行实验，也能跟随流程并查看结果。

LLM 服务优化方案

在本练习中，我们将重点放在在线模型服务环境中优化Qwen/Qwen3-14B 模型的令牌吞吐量 （ ）上。具体而言，我们的目标是最大化单个模型实例的服务吞吐量——在给定时间范围内处理尽可能多的令牌。 更高的令牌吞吐量直接意味着更低的服务成本，因为处理的令牌数量是大多数 LLM 定价模型的基础。这一优化目标与现实世界中 LLM 服务场景的常见目标相一致：即在单位时间内实现尽可能高的令牌处理效率。

吞吐量与延迟之间的权衡

在许多情况下，优化技术 能够同时提升吞吐量和降低延迟——例如，通过减少冗余计算或提高批处理效率。然而，对于某些流量模式而言，峰值吞吐量和最小延迟是本质上相互冲突的目标。

原因在于，更高的吞吐量通常依赖于对请求进行批处理或排队以更好地利用硬件资源，这会引入等待时间，从而增加单次请求的延迟。相反，纯粹为了最低延迟而进行优化，通常意味着在并行度降低的情况下立即处理请求，这会导致资源利用率不足和整体吞吐量降低。

在实际应用中，我们通常优先提升吞吐量，同时将延迟控制在可接受范围内，以确保在不牺牲用户体验的前提下提高效率。在本章中，尽管我们的重点是吞吐量优化，但当响应速度比效率更关键时，我们也会讨论一些更侧重低延迟的技术（例如分布式服务）。

以下是我们在下一节中将执行的高级优化计划。无论您是与我们同步执行这些步骤，还是在 Jupyter 笔记本中跟随操作，本练习都将为您提供基准测试的实践经验，并帮助您通过比较不同的优化技术和配置，理解它们对服务性能的影响：

1. 评估硬件

首先，我们将回顾硬件配置，并确定对服务性能影响最大的关键 GPU 规格——例如 GPU 内存大小、带宽、计算能力以及 NVLink 互连。了解这些因素将有助于您在后续阶段更准确地解读基准测试结果。

2. 生成基准测试流量

接下来，我们将设计具有代表性的基准测试流量，以模拟实际的请求模式。我们将探讨通常用于缓存评估的输入数据类型、请求长度分布以及重复设置。 ...