模型推理并发优化

增强模型推理并发性：优化性能的策略和技术

1.简介：高模型推理并发的必要性

模型推理并发是指系统同时处理多个模型推理请求的能力。对于在高流量的现实应用程序（例如在线服务、推荐引擎和实时分析平台）中部署机器学习模型来说，这是一个至关重要的属性。同时处理大量请求的能力可确保用户的低延迟，优化计算资源的利用率，并最终降低运营成本 。如果没有高效的并发，人工智能驱动的服务可能会成为瓶颈，导致用户体验不佳或由于需要过多的资源配置而导致基础设施费用不可持续 。

实现高推理并发性会带来一些技术挑战。现代机器学习模型（尤其是深度学习模型）的大小和计算复杂性通常会导致各个硬件单元的内存和处理能力紧张 。硬件限制（包括 CPU 和 GPU 的内存容量以及处理能力）可能会限制模型实例的数量或可容纳的批量大小 。分布式系统中的网络延迟和输入/输出 (I/O) 瓶颈可能会进一步阻碍请求的并发处理 。此外，有效管理和扩展底层基础设施以支持高并发性又给部署过程增加了一层复杂性 。因此，需要采取多方面的方法来应对这些挑战并释放高模型推理并发的潜力。

2. 增强并发的模型优化技术

更小、更快的模型本质上支持更高的并发性，因为它们每次推理消耗的计算资源更少，允许在相同的硬件限制内并行处理更多的请求 。可以采用多种模型优化技术来减少资源消耗并提高推理速度。

2.1 模型剪枝

模型剪枝涉及删除经过训练的神经网络中不必要的部分，例如对模型整体准确性贡献较小的特定神经元、层，甚至整个子模型 。此过程减少了模型的大小和计算复杂性，从而可能缩短推理时间。基于幅度的剪枝（删除最小幅度的权重）和基于灵敏度的剪枝（根据权重对模型性能的影响来删除权重）等技术是有效的策略 。神经元剪枝根据低激活值等标准消除整个神经元，而通道剪枝则减少卷积层中的通道数量 。 TensorFlow 和 PyTorch 等库提供了工具和 API 来促进这些剪枝技术的实施，通常需要在剪枝后重新训练模型以恢复任何潜在的准确性损失 。通过使模型更加轻量级，剪枝不仅可以减少其内存占用，还可以提高硬件利用率。密度较低的模型可能更有效地适合 GPU 缓存，或者具有更少的互操作依赖性，从而使硬件能够同时执行更多数量的推理 。

2.2 量化

量化是降低用于表示模型权重和激活的数值精度的过程 。模型的参数不使用浮点数（如 FP32），而是转换为较低精度的数据类型，例如 16 位浮点数 (FP16) 或 8 位整数 (INT8) 。精度的降低带来了多种好处，包括更低的内存使用量和更快的计算速度，特别是在针对这些低精度数据类型进行优化的硬件上 。存在各种量化技术，包括训练后量化 (PTQ)（在模型完全训练后应用）和量化感知训练 (QAT)（在训练模型时了解推理过程中将应用的量化） 。动态量化和静态量化也是选项，混合量化也是如此，它结合了不同的方法 。 TensorFlow 和 PyTorch 等框架以及 Intel Neural Compressor 等专用库提供了执行模型量化的工具 。量化可以显着加速推理，特别是在配备专为 FP16 运算而设计的张量核心的新型 GPU 上，或者在 INT8 运算通常比 FP32 更快的 CPU 上。这种加速直接有助于增加在给定时间范围内可以同时执行的推理数量 。

2.3 模型蒸馏

模型蒸馏是一种技术，其中较小、更轻量级的模型（称为“学生”）经过训练来模仿更大、更复杂的模型（称为“教师”）的行为 。目标是将教师模型学到的知识转移到学生模型中，使学生能够以显着减小的尺寸和计算成本实现可比的精度 。学生模型的训练过程涉及使用教师的预测（通常包括软目标（概率分布））作为训练信号 。这种方法对于在资源有限的边缘设备上或在快速推理至关重要的场景中部署模型特别有效 。通过部署这些精炼的轻量级模型，系统可以更快地处理推理请求，从而提高并发请求的容量，尤其是在资源受限的环境中 。由此产生的高效推理引擎可以更轻松地跨可用硬件进行复制，以管理更高的并发负载。

2.4 权重共享（聚类）

权重共享，也称为聚类，是一种优化技术，通过减少不同权重值的数量来帮助提高模型的内存效率 。在此过程中，神经网络中每一层的权重被分组为簇，然后簇内的所有权重由单个共享值（通常是簇的质心）表示 。这减少了模型在推理过程中需要存储和计算的唯一参数的总数 。与其他模型压缩技术类似，权重共享可以减少模型的内存占用 。当部署模型的多个实例来处理并发推理请求时，内存使用量的减少特别有益。如果每个模型实例需要更少的内存，就可以在同一硬件上容纳更多的实例，这直接提高了系统的整体并发性 。

选择最合适的模型优化技术通常涉及模型大小、推理速度和特定应用可接受的准确度之间的仔细平衡 。进行彻底的评估和基准测试以了解与每种技术相关的权衡并确保优化的模型满足所需的性能和准确性指标至关重要 。

3. 利用批处理提高吞吐量

批处理或批量推理是一种技术，涉及将多个独立的推理请求分组在一起，并通过机器学习模型在一次前向传递中处理它们 。这种方法可以通过更有效地利用现代硬件加速器（例如 GPU 和 TPU）的并行处理能力，显着提高推理系统的整体吞吐量。通过一次处理一批请求，与每个单独请求相关的开销（例如数据加载和模型执行设置）将在整个批次中分摊，从而减少每个请求的平均处理时间 。

3.1 TensorFlow Serving 中的批处理

TensorFlow Serving 提供了一个强大的库，用于批处理推理请求以提高性能。批处理行为的配置可以通过多个参数进行控制，包括 max_batch_size，它设置可以分组到单个批处理中的最大请求数，以及batch_timeout_micros，它定义调度程序在处理批处理之前等待的最长时间，即使它尚未达到最大大小。 num_batch_threads 参数确定用于并发处理批次的线程数，而 max_enqueued_batches 限制待处理批次的数量以限制排队延迟 。（可选） allowed_batch_sizes 可以将批量大小限制为一组特定的值 。 TensorFlow Serving 提供用于批处理的同步和异步 API。 BatchingSession 为标准 TensorFlow Session 添加了批处理功能，非常适合能够适应其同步特性的应用程序 。为了更灵活的异步操作，BasicBatchScheduler 允许将任务排队并使用回调机制批量处理它们 。当服务多个模型或同一模型的不同版本时，重要的是要考虑批处理调度程序如何与共享的底层计算资源交互以避免争用 。 TensorFlow Serving 的批处理还可以与 Amazon SageMaker Batch Transform 等服务集成，以实现离线或面向批量的推理任务 。在 TensorFlow Serving 中配置各种批处理参数的能力允许根据应用程序的特定需求微调吞吐量和延迟之间的平衡。例如，限制允许的批量大小对于管理 GPU 内存限制或优化特定硬件配置的性能非常有用 。

3.2 TorchServe 中的批处理

TorchServe 设计原生支持批处理传入的推理请求。可以通过 POST /models 管理 API 或通过在 config.properties 文件中设置参数来配置批处理。 TorchServe 中批处理的关键配置属性是batch_size（定义聚合到批处理中的最大请求数）和 max_batch_delay（指定等待收集所需的batch_size 的最长时间（以毫秒为单位））。如果在 max_batch_delay 内未达到batch_size，TorchServe 会将累积的请求发送到模型处理程序 。大多数 TorchServe 的默认处理程序都支持开箱即用的批量推理，但 text_classifier 处理程序除外。对于支持批量推理的自定义模型处理程序，需要设计处理程序代码来处理批量输入。 TorchServe 还提供动态批处理功能，使其能够根据传入请求负载和配置的延迟调整批处理大小，从而优化资源利用率和吞吐量。 TorchServe 中的 max_batch_delay 参数在通过较大批量实现高吞吐量和维持单个请求可接受的延迟之间找到适当的平衡方面发挥着关键作用。较短的延迟将导致较小的批次和较低的延迟，但可能会降低吞吐量，而较长的延迟可能会导致更大、更高效的批次，但代价是延迟增加。

3.3 动态批处理

动态批处理是一种复杂的批处理方法，实时收集和处理传入的推理请求以形成批处理 。与批量大小固定的静态批处理不同，动态批处理根据当前请求负载和配置的最大等待时间调整批量大小 。当推理请求到达时，系统会暂时将它们保留为一个批次，该批次的大小可能会根据并发请求量而变化 。该技术对于处理波动的工作负载特别有益，因为它允许系统通过在高峰时段形成较大的批次和在低流量期间形成较小的批次来最大化资源利用率，同时还确保单个请求不会过度延迟。 TensorFlow Serving 和 TorchServe 都提供对动态批处理的支持。在TensorFlow Serving中，可以通过模型配置中的dynamic_batching设置来启用和配置。 TorchServe 还提供动态批处理，可通过 batch_size 和 max_batch_delay 设置进行配置，可以通过 SageMaker 中的环境变量或通过 config.properties 文件。动态批处理在批处理计算的效率和在线服务所需的响应能力之间取得了平衡，使其成为在请求到达模式可变的场景中优化吞吐量的宝贵工具。

表 1：TensorFlow Serving 和 TorchServe 中的批处理参数比较

 

参数名称	TensorFlow 服务	火炬服务	描述
最大批量大小	任何批次的最大尺寸	批量大小	单个批次中包含的最大推理请求数。
批处理超时微秒	执行批处理之前等待的最长时间（微秒）	最大批量延迟（毫秒）	即使未达到最大大小，在处理之前等待收集批次的最长时间。
批处理线程数	并发处理的最大批次数	（通过worker配置隐式）	处理批次的并行度。
最大入队批次	可以排队的任务的批次数量	（隐式通过请求队列大小限制）	限制待处理批次的数量以控制排队延迟。
允许的批次大小	将批量大小限制为一组固定值	（不是直接等价物，但batch_size是一个限制）	用于限制可能的批量大小的可选参数。

4. 通过异步模型推理增强响应能力

异步模型推理是一种允许发送推理请求的客户端立即接收响应（例如请求标识符）的技术，而实际的模型推理则在后台处理。这种方法对于长时间运行的推理任务特别有用，因为等待结果同步返回会导致糟糕的用户体验或不必要地占用资源。通过解耦请求和响应，异步推理可以显着提高系统的整体吞吐量和响应能力。

4.1 Python 中的异步推理

FastAPI 等 Python 框架为构建异步 API 提供了出色的支持，可以有效地处理并发推理请求。 Python 中的 async 和await 关键字允许开发人员定义异步函数（协程），这些函数可以在等待 I/O 密集型操作（如推理任务）完成时暂停执行，而不会阻塞主事件循环。这使得服务器能够在等待期间处理其他传入请求，从而提高整体吞吐量和响应能力。例如，在FastAPI中，可以使用async def定义路径操作函数，以指示它可以使用await调用其他异步函数，例如向后端服务器提交推理作业的函数。 FastAPI还提供了BackgroundTasks类，它允许开发人员添加在处理主请求并将响应发送到客户端后在后台执行的函数。这对于记录推理结果或触发后处理步骤等任务非常有用，而不会延迟对用户的初始响应。 FastAPI 对异步操作的原生支持简化了能够处理大量并发请求的高性能推理 API 的开发。

4.2 使用服务框架进行异步推理

TensorFlow Serving、TorchServe 和 Triton Inference Server 等主要模型服务框架提供了用于异步处理推理请求的内置机制。在 TensorFlow Serving 中，BasicBatchScheduler 提供异步 API，允许非阻塞调度和推理任务处理。 TorchServe 还支持异步请求处理，使其能够有效管理大量传入的预测请求，而不会阻塞每个客户端。虽然 TorchServe 中异步处理的具体文档可能有限，但其架构（涉及管理多个工作进程）本质上支持并发处理，从而支持异步处理。 Triton Inference Server 旨在同时处理多个请求，并且可以配置为异步操作，允许客户端稍后提交请求并检索结果。这些框架抽象了管理异步操作的复杂性，使得为生产环境构建可扩展且响应灵敏的推理服务变得更加容易。

4.3 使用加速库进行异步推理

Intel OpenVINO 和 NVIDIA TensorRT 等硬件加速库还提供异步 API，以进一步优化推理性能。 OpenVINO 提供了 async_predict 方法和 AsyncInferQueue 类，允许非阻塞推理执行。使用这些功能，应用程序可以启动推理任务，然后继续其他操作，例如数据预处理或处理其他请求，同时推理正在后台处理。可以设置回调函数，在推理完成后执行。同样，NVIDIA TensorRT 通过使用多个执行上下文和 CUDA 流支持异步执行推理。通过使用单独的流，可以并行排队和处理多个推理请求，允许重叠计算和数据传输，这可以显着提高推理管道的整体吞吐量。这些加速库中异步 API 的可用性使开发人员能够将计算与其他任务重叠，从而更有效地利用硬件资源并提高并发性。

5. 使用模型并行性和分布式计算扩展推理

对于超出单个设备内存容量或需要巨大计算能力进行推理的超大型模型，模型并行性和分布式计算技术对于扩展推理能力至关重要。这些方法涉及将模型和/或推理工作负载分布在多个处理单元（例如 GPU 甚至多台机器）上，以实现高效处理。

5.1 数据并行性

数据并行是一种技术，其中整个机器学习模型在多个处理设备（例如 GPU）上复制，并且每个设备并行处理输入数据的不同子集。在每个处理步骤之后，来自不同设备的结果通常会被聚合以产生最终输出。这种方法在处理大型数据集时特别有用，因为它允许并行处理不同的数据块，从而显着加快整体推理时间。数据并行性与批量大小很好地扩展；随着批量大小的增加，可以在设备上分发更多数据，从而提高吞吐量。使用 PyTorch 和 TensorFlow 等流行的深度学习框架来实现该技术相对简单，这些框架提供了跨多个设备分发数据和同步模型更新的实用程序。当模型适合单个设备并且主要瓶颈是要处理的数据量时，数据并行性可以通过添加更多处理单元来提供近线性的加速。

5.2 张量并行性

张量并行是模型并行的一种更复杂的形式，涉及将模型的各个张量（权重和激活）拆分到多个处理设备上。这种方法对于处理非常大的模型至关重要，因为即使模型的参数也无法放入单个 GPU 的内存中。通过将模型的张量划分为较小的块并将这些块分布在多个设备上，每个设备上的内存需求显着减少。在前向和后向传递期间，每个设备计算其张量运算部分，然后使用设备间通信在设备之间组合结果。像 DeepSpeed 这样的库提供了自动张量并行的功能，这简化了大型模型（例如 Hugging Face 的 Transformers 库中的模型）的分区过程，以及管理必要的 GPU 间通信的过程。这使得用户能够使用原本无法加载到单个 GPU 上的模型，从而能够对最先进的大型语言模型进行推理。

5.3 管道并行性

管道并行是另一种扩展大型模型推理的技术，尤其是那些具有深层架构的模型。在这种方法中，模型的层或部分被分为连续的阶段，每个阶段都分配给不同的处理设备。当一批输入数据正在一台设备上由模型的第一阶段处理时，下一批数据可以同时由另一台设备上的第二阶段处理，依此类推，形成处理管道。这允许对不同输入样本的模型的不同部分进行并行处理，这可以显着提高深度神经网络的整体吞吐量。然而，由于管道的顺序性质，管道并行性可能会引入延迟；请求必须经过所有阶段才能得到结果。平衡不同阶段的计算负载并最小化设备之间的通信开销是有效实现管道并行性的关键考虑因素。

5.4 专家并行（专家混合 - MoE）

专家并行通常通过专家混合 (MoE) 架构实现，是一种能够在推理过程中高效使用大型模型的技术。在这种方法中，模型被划分为多个专家子网络，其中每个专家通常是一个神经网络，经过训练可以处理更广泛的问题域中的特定类型的输入或子任务。门控网络或路由器用于确定针对给定输入应激活哪个专家或专家组合。对于任何特定输入，仅激活一部分专家，这意味着不同的专家可以分布在不同的处理设备上，并且只有相关专家为每个请求消耗计算资源。这大大减少了每个请求必须交互的参数数量，因为有效地跳过了不活动的专家，从而可能加快推理时间并能够处理具有大量总参数的模型。专家并行性特别适合需要具有广泛功能的模型，因为不同的专家可以专注于任务的不同方面。

5.5 分布式推理框架

一些专门的框架旨在促进跨多个设备和节点的分布式推理。 DeepSpeed是一个深度学习优化库，支持各种并行技术，包括张量、管道、专家和ZeRO并行，还提供高性能的自定义推理内核和通信优化。 vLLM 是另一个专门致力于通过连续批处理传入请求以及有效管理注意力键和值内存等技术为大型语言模型实现最先进的服务吞吐量的框架。 LocalAI 通过允许推理请求分布在多个工作节点（可以通过对等通信进行连接）来实现分布式推理。 Hugging Face 的 Accelerate 库通过提供统一的接口来抽象化底层分布式环境的复杂性，从而简化了跨分布式设置运行训练和推理的过程。这些框架提供高级抽象和优化，使扩展模型服务变得更容易，以满足大型复杂人工智能应用程序的需求。

表 2：模型并行技术比较

 

技术	并行化单元	可扩展性	内存效率	通信开销	负载平衡适用性	典型模型用例
数据并行性	批量投入	可以很好地适应批量大小	低（每台设备上的完整模型）	低的	如果数据均匀分布，则总体平衡	具有小计算图的模型
张量并行性	单独的张量/层	对于非常大的模型来说可以很好地扩展	高（仅每个设备上每层的一部分）	中到高	运营内部平衡	具有大层尺寸的宽模型
管道并行性	模型阶段	可以很好地适应深度模型	高（每个设备上仅部分模型）	低（阶段之间）	需要仔细平衡	大而深的模型
专家并行性	专家（子网络）	适合宽模型的良好扩展	中到高（专家分布）	中型（路由器）	取决于路由器逻辑	集成模型，专家组合

6. 加速库：优化特定硬件的推理

硬件加速库在进一步优化特定类型计算硬件的模型推理方面发挥着关键作用，导致速度和效率的显着提升，从而直接增强更高并发的潜力。

6.1 NVIDIA TensorRT

NVIDIA TensorRT 是一款高性能深度学习推理 SDK，旨在优化和加速 NVIDIA GPU 上深度神经网络的推理。 TensorRT 的工作原理是从 TensorFlow、PyTorch 或 ONNX 等流行的深度学习框架中获取经过训练的模型，并应用一系列优化，例如层融合（将多个层组合为单个操作）、精度校准（将权重和激活的精度降低到 INT8 或 FP16）、动态张量内存管理和自动内核调整（为每层选择最高效的 GPU 内核）。这些优化产生了高效的推理引擎，与直接运行原始模型相比，可以实现更高的吞吐量和更低的延迟。对于并发推理，TensorRT 允许从单个优化引擎创建多个执行上下文。然后，每个上下文都可以用于并行处理独立的推理请求，而无需同步，从而最大限度地利用 GPU 的并行处理能力。 TensorRT与NVIDIA硬件的深度集成及其执行低级优化的能力使其成为在NVIDIA平台上实现高推理并发的强大工具。

6.2 英特尔OpenVINO

英特尔 OpenVINO 是一个综合工具包，用于在各种英特尔硬件（包括 CPU、集成 GPU 和专用 GPU）上部署和优化 AI 模型。与 TensorRT 类似，OpenVINO 提供各种优化技术来提高推理性能，例如图剪枝、知识蒸馏、层融合和量化（包括 INT8 和 FP16）。这些优化有助于减少模型的计算要求和内存占用，从而提高推理速度。 OpenVINO 通过其 async_predict 方法和推理流的使用为异步推理提供强大的支持。流允许在底层硬件上并行执行多个推理请求，有效提高推理过程的吞吐量和并发性。 OpenVINO 支持来自各种框架的模型，包括 TensorFlow、PyTorch 和 ONNX，使其成为优化基于 Intel 的系统上的推理的多功能解决方案。通过利用英特尔硬件特定功能并提供同步和异步推理选项，OpenVINO使开发人员能够在英特尔平台上实现高并发和高效的资源利用。

6.3 比较

虽然 NVIDIA TensorRT 和 Intel OpenVINO 的目标都是加速深度学习推理，但它们的主要目标硬件不同。 TensorRT 专为 NVIDIA GPU 设计和优化，充分利用其架构和 CUDA 功能。另一方面，OpenVINO 支持更广泛的 Intel 硬件，包括 CPU、集成显卡和独立 GPU，为混合硬件或偏爱 Intel 产品的环境提供更通用的解决方案。这两个库都通过各种模型优化技术实现了显着的性能改进，尽管具体方法及其有效性可能因模型和硬件而异。对于主要使用 NVIDIA GPU 的用户来说，TensorRT 通常是首选，因为它针对该平台进行了深度优化。相反，OpenVINO 为在以 Intel 为中心的基础设施上的部署提供了更大的灵活性。两者之间的选择通常取决于部署环境中可用的特定硬件以及应用程序所需的性能特征。

7. 模型服务框架中的并发请求管理

模型服务框架在管理并发推理请求的执行方面发挥着至关重要的作用，提供了控制并行处理的请求数量并优化资源利用率的机制。

7.1 TensorFlow 服务

TensorFlow Serving 主要通过其批处理库来管理并发性，其中批处理配置中的 num_batch_threads 参数控制专用于同时处理批处理的 CPU 线程数。对于除了 GPU 推理之外还涉及大量基于 CPU 的操作（例如预处理或后处理）的工作负载，TensorFlow Serving 提供了 tensorflow_intra_op_parallelism 和 tensorflow_inter_op_parallelism 等参数来控制 CPU 上 TensorFlow 操作的并行度。 TensorFlow Serving 还设计用于同时服务多个模型和同一模型的不同版本，允许并发执行针对不同模型或版本的请求。通过调整批处理线程数和调整CPU并行度设置，用户可以影响服务器可以有效处理的并发请求数。为多个模型提供服务本质上涉及管理每个模型的并发执行上下文。

7.2 Torch服务

TorchServe 采用的架构依赖于管理多个工作进程来处理并发推理请求。当模型加载到 TorchServe 时，可以使用模型配置文件中的 minWorkers 和 maxWorkers 等参数或通过管理 API 来配置分配给该模型的工作进程数量 。 TorchServe 的前端负责接收请求并将其分发到可用的工作进程中。每个工作进程通常负责运行模型并执行实际推理。通过增加给定模型的工作进程数量，TorchServe 可以并行处理更多数量的并发请求，直至底层硬件资源的限制。 TorchServe 前端中的 WorkLoadManager 组件在管理这些工作进程的生命周期和数量方面发挥着关键作用。

7.3 Triton 推理服务器

Triton Inference Server 经过明确设计，允许在单个系统上并发执行多个模型和同一模型的多个实例，该系统可以具有零个或多个 GPU。对于同一模型，Triton 默认情况下会在单个 GPU 上序列化传入请求的执行。但是，用户可以使用模型配置文件中的instance_group设置来配置每个模型的并行执行实例的数量。通过增加instance_group中的计数，用户可以指定同一模型的多个实例应在可用GPU上并行加载和运行，从而允许真正并发处理该模型的多个请求 。

Triton 还支持动态批处理，可以通过将单个请求组合成更大的批次来进一步提高吞吐量，从而更有效地执行。此外，对于 RNN 等有状态模型，Triton 提供序列批处理，以确保属于同一序列的请求被路由到同一模型实例，以正确维护状态。 Triton 能够管理多个模型实例并利用动态批处理，提供对并发和资源利用率的细粒度控制。

8. 负载均衡以实现高可用性和可扩展性

当部署模型服务框架的多个实例以实现高并发并确保容错时，负载均衡成为关键组件。负载均衡器在可用服务器实例之间分配传入的推理请求，防止任何单个实例被淹没，并提高服务的整体响应能力和可靠性。

8.1 负载均衡策略

可以采用多种负载平衡策略来分发推理请求。循环法是一种简单的策略，它按顺序将请求分发到服务器。最少连接将流量引导至活动连接数最少的服务器，旨在平衡当前负载。最小负载策略，专为模型推理服务器量身定制，将请求分发到具有最少数量的正在进行的请求的副本。 IP 哈希根据 IP 地址将服务器分配给客户端，这可以提高某些应用程序中的缓存命中率。对于使用前缀缓存的大型语言模型 (LLM)，前缀哈希策略利用一致哈希将具有公共前缀的请求路由到同一副本，从而增加 KV 缓存命中的可能性。策略的选择取决于应用程序的具体特征和期望的优化目标。对于简单的无状态模型，循环或最少连接可能就足够了，而有状态应用程序或严重依赖缓存的应用程序可能会从 IP 哈希或前缀哈希中受益更多。

8.2 使用 Kubernetes 进行负载均衡

Kubernetes 是一种广泛采用的容器编排平台，为负载均衡模型推理服务提供了强大的机制。当模型服务器部署为 Kubernetes 集群中的 Pod 时，Kubernetes 服务可用于抽象底层 Pod 并在它们之间分配流量。 Kubernetes 支持各种类型的服务，包括 LoadBalancer，它可以配置外部负载均衡器（例如，来自 AWS 或 Google Cloud 等云提供商）以将流量从集群外部分配到 Pod。此外，Kubernetes 还提供 Horizo​​ntal Pod Autoscaler (HPA)，它可以根据观察到的指标（如 CPU 利用率或自定义指标）自动调整 pod 副本的数量，从而允许推理服务动态扩展以响应不断变化的负载 。与云提供商负载均衡器（例如 AWS Application Load Balancer (ALB) 或 Google Cloud Load Balancer）集成，可以提供高级负载均衡功能并提高性能。 Kubernetes 简化了多个模型服务器实例的管理，并确保流量有效分配，从而增强性能和可用性。

8.3 使用 HAProxy 进行负载均衡

HAProxy 是一种流行的开源负载均衡器，可用于在 Triton 或 TorchServe 等模型服务框架的多个实例之间分配推理流量。要使用 HAProxy，它通常安装在充当反向代理的单独虚拟机上。 HAProxy 的配置涉及定义一个侦听传入请求的前端和一个列出模型服务器实例的 IP 地址和端口的后端。 HAProxy支持多种负载均衡算法，包括轮询、最少连接等，允许用户选择最适合自己需求的方法。还可以配置运行状况检查以确保流量仅路由到运行状况良好且响应迅速的服务器实例 。通过将客户端应用程序指向 HAProxy 负载均衡器的 IP 地址，推理请求将分布在后端模型服务器上，提供负载均衡并提高推理服务的整体可扩展性和弹性 。

8.4 使用 Nginx 进行负载平衡

Nginx 主要被称为高性能 Web 服务器和反向代理，还提供强大的负载平衡功能，可有效用于分发模型推理请求。与 HAProxy 类似，Nginx 可以配置为充当位于多个后端模型服务器实例前面的反向代理。 Nginx 中的负载平衡配置通常涉及定义一个上游块，其中列出后端服务器的地址（IP 和端口）。在服务器块内，可以定义一个位置来处理特定的路由，并且 proxy_pass 指令用于将请求转发到上游模型服务器组。 Nginx 支持多种负载均衡方法，包括循环（默认）、最少连接和 IP 哈希。它还允许配置超时和保持连接以优化性能。 Nginx 是一个轻量级且高效的负载平衡选项，特别是对于由 TorchServe 或自定义 FastAPI 应用程序等框架提供的基于 HTTP/REST 的推理 API。

9. 通过推理结果缓存提高效率

缓存模型推理的结果可以是减少冗余计算并提高系统感知并发性的有效策略，特别是在处理重复或相似的输入查询时。通过存储先前推理请求的输出，系统可以直接为后续相同或相似的输入提供这些结果，从而避免重新运行计算成本高昂的模型推理过程。这可以显着降低频繁发生的查询的延迟，并减少推理基础设施上的总体计算负载。

9.1 精确缓存

精确缓存涉及存储完全相同的输入查询的推理结果。当收到新的推理请求时，系统首先检查之前是否处理过完全相同的输入以及结果是否在缓存中可用。如果找到匹配项（缓存命中），则立即返回缓存结果，绕过模型推理步骤。此策略在频繁出现相同查询的应用程序中最为有效，例如在具有常见用户话语的聊天机器人中或在处理重复传感器数据的系统中。可以使用内存数据存储（例如字典或哈希映射）来实现精确缓存，以实现快速检索，也可以使用外部缓存系统（例如 Redis 或 Memcached）来实现更大的数据集或分布式环境。精确缓存的关键考虑因素包括缓存失效（确定缓存结果何时可能变得过时）、内存管理（以防止缓存无限增长）以及确保缓存键的唯一性，该键通常应从输入查询的所有相关部分派生。

9.2 语义缓存

语义缓存是一种更高级的缓存形式，旨在存储和重用语义相似的查询的推理结果，即使它们不完全相同。这种方法通常涉及使用嵌入模型来生成输入查询的向量表示。然后将这些嵌入及其相应的推理结果存储在向量数据库中。当新查询到达时，会计算其嵌入，并在向量数据库中执行相似性搜索以查找最接近的缓存嵌入。如果新查询的嵌入和缓存的嵌入之间的相似度分数超过预定义的阈值，则返回与相似查询关联的缓存结果。语义缓存在用户可能以略有不同的方式表达相同请求的应用程序中特别有用 。然而，实现语义缓存会带来复杂性，例如选择合适的嵌入模型、选择合适的相似性度量和阈值以及管理向量数据库。如果相似性评估有缺陷，还存在返回错误结果的风险。

9.3 大型语言模型（LLM）的提示缓存

对于大型语言模型 (LLM)，一种称为提示缓存的特殊形式的缓存可以显着提高推理效率，特别是对于输出逐个令牌生成的自回归模型。提示缓存，特别是键值（KV）缓存的使用，涉及缓存为输入提示计算的注意力状态和先前生成的令牌。在朴素自回归生成中，这些注意力状态在令牌生成的每一步都被完全重新计算。通过缓存这些状态，模型可以在后续步骤中重用它们来计算新令牌的注意力，从而显着降低计算成本和延迟，特别是对于较长的序列或在上下文（提示历史记录）随着每次回合增长的对话设置中 。专为服务 LLM 而设计的框架和服务（例如 Amazon Bedrock）通常包含可通过 API 配置的提示缓存机制 。这些机制可能涉及为提示前缀创建缓存检查点，并根据令牌计数和生存时间等因素管理缓存生命周期 。

表 3：缓存策略比较

 

战略	缓存键的基础	使用案例	实施复杂性	内存使用情况	减少延迟	法学硕士的适合性
精确缓存	精确输入查询	频繁的相同查询	低的	可以高	高的	是的
语义缓存	嵌入相似度	语义相似的查询	中等的	高的	中到高	是的
提示缓存	提示前缀（注意状态）	自回归生成，重复上下文	中等的	高的	高的	是（具体）

10. 结论：制定最佳推理并发策略

实现高模型推理并发性是一项多方面的工作，需要对各种技术进行战略组合。正如本报告所详述的，这些技术跨越整个推理管道，从优化模型本身到有效管理请求和扩展部署基础设施。剪枝、量化和蒸馏等模型优化技术旨在减少每次推理的计算负担，从而增加可以并发处理的请求数量。批处理（包括静态和动态批处理）通过利用现代硬件的并行处理功能来提高吞吐量 。异步推理允许客户端在后台进行推理时接收立即确认，从而增强响应能力 。对于非常大的模型，模型并行性和分布式计算框架对于扩展超越单个设备的限制至关重要 。 TensorRT 和 OpenVINO 等硬件加速库通过优化特定硬件架构的推理来显着提升性能 。模型服务框架提供用于管理并发请求的内置功能，负载平衡可确保跨多个服务器实例的高可用性和可扩展性 。最后，缓存策略可以减少冗余计算并改善重复或类似查询的延迟 。

增强推理并发性的最佳策略高度依赖于多个因素，包括机器学习模型的特征（其大小、复杂性和类型）、可用的硬件资源（CPU、GPU、内存）、应用程序的具体性能要求（吞吐量和延迟目标）以及部署环境（云、边缘或本地） 。建议采用系统的优化方法。这首先涉及通过分析和监控来识别当前推理管道中的关键瓶颈 。基于此分析，应根据其潜在影响和实施的复杂性来优先考虑适当的优化技术 。应迭代地实施变更并进行基准测试，并在类似生产的环境中仔细监控性能指标 。生产环境中的持续监控对于检测任何性能下降或需要进一步改进的领域至关重要，并且应根据需要调整配置以适应不断变化的应用程序需求和流量模式 。最终，实现高模型推理并发性是一个持续的过程，需要持续关注、实验和适应，以确保人工智能应用程序大规模高效地执行。