在为要求严格、注重吞吐量的模型训练任务选择实例之后,重心转向服务。为推理选择合适的实例是一种不同的优化问题。训练通常是临时的、高成本的批处理作业,而推理则通常是全天候服务,其中低延迟和每次预测的成本是主要衡量标准。在此处的任何错误计算不仅会浪费单个作业的预算;还会持续增加运营成本。推理服务的主要目标是尽可能快且便宜地返回预测。这带来了不同的硬件考量。一个擅长训练的强大多GPU实例,在处理单个实时请求时可能既浪费又慢。CPU实例:经济实惠的常规选择对于许多模型,尤其是大型语言模型(LLM)或生成式图像领域之外的模型,CPU实例是用于服务的最实用且经济高效的选择。这包括来自Scikit-learn和XGBoost等库的传统机器学习模型,以及较小的深度学习模型。CPU擅长处理独立的低延迟请求。由于每个推理请求通常是独立处理的,GPU的庞大并行能力可能未被充分利用,使其成为一种昂贵且闲置的资源。在以下情况选择CPU实例:延迟要求非常高且无法进行批处理: 如果您的应用程序需要对每个传入请求立即响应,CPU可以直接处理,无需将数据传输到GPU的额外开销。流量为低到中等: 如果您每秒预期只有少量请求,单个CPU核心通常可以应付。通过添加更多CPU实例进行横向扩展是简单且经济的。模型计算量不大: 决策树、线性模型和较小的神经网络没有足够的并行操作来充分利用GPU,这使得CPU成为更具效率的选择。云服务提供商提供多种基于CPU的虚拟机。通用实例(如AWS的m5系列或GCP的e2系列)提供CPU和内存的均衡组合,是一个不错的起始选择。如果分析显示您的模型受CPU限制,计算优化型实例(如AWS的c5系列或GCP的c2系列)能在相同内存量下提供更强大的核心。GPU实例:适用于高吞吐量和大型模型当您的应用程序服务大型复杂的深度学习模型或处理大量并发请求时,GPU变得很有必要。有效使用GPU进行推理的核心在于最大化其利用率。一次只处理一个请求的GPU效率不高。目标是将多个传入请求批量处理,同时进行,以发挥GPU的并行架构优势。这种策略将问题从延迟限制型转变为吞吐量限制型。虽然单个请求的延迟可能会因等待批次填充而略微增加,但每秒的总推理次数(以及每次推理的成本)将显著提升。云服务提供商现在提供专门为推理设计的GPU,这些GPU比顶级训练GPU更经济:NVIDIA T4: 一种流行且多功能的推理加速器,为深度学习模型提供了性能与成本的良好平衡。它被广泛提供(例如,AWS g4dn实例,带T4的GCP n1-standard)。NVIDIA L4: T4的新一代继任者,为更广泛的AI工作负载(包括视频和生成式AI)提供更高的性能。NVIDIA A10G: 比T4更强大的选择,适用于更大的模型或更高的吞吐量需求(例如,AWS g5实例)。是否使用GPU取决于您实施批处理策略的能力。这可以在您的应用程序逻辑中完成,或者使用像NVIDIA Triton Inference Server这样的专用模型服务框架,它能自动处理请求批处理。digraph G { rankdir=TB; splines=ortho; node [shape=box, style="rounded,filled", fontname="Arial", fillcolor="#e9ecef"]; edge [fontname="Arial"]; "start" [label="开始:定义\n推理要求", shape=ellipse, fillcolor="#74c0fc"]; "check_traffic" [label="流量大小?"]; "check_latency" [label="严格的延迟要求\n(例如,< 100毫秒)?"]; "check_model_size" [label="模型大小\n(例如,> 1GB)?"]; "cpu_instance" [label="使用CPU实例\n(通用型)", fillcolor="#b2f2bb"]; "gpu_instance" [label="使用GPU实例\n(例如,T4, L4)", fillcolor="#ffc9c9"]; "asic_instance" [label="考虑专用ASIC\n(例如,Inferentia, TPU)", fillcolor="#ffd8a8"]; "optimize" [label="优化:量化、\n批量请求、\n和自动扩缩", shape=diamond, fillcolor="#d0bfff"]; "start" -> "check_model_size"; "check_model_size" -> "check_traffic" [label="小型"]; "check_model_size" -> "gpu_instance" [label="大型"]; "check_traffic" -> "check_latency" [label="低到中等"]; "check_traffic" -> "gpu_instance" [label="高"]; "check_latency" -> "cpu_instance" [label="是"]; "check_latency" -> "gpu_instance" [label="否 (可批处理)"]; "cpu_instance" -> "optimize"; "gpu_instance" -> "optimize"; "asic_instance" -> "optimize"; "gpu_instance" -> "asic_instance" [style=dashed, label="为实现最高成本效益"]; }选择推理实例的决策流程。此过程需要评估模型大小、流量和延迟要求,以确定最合适的硬件。专用推理加速器 (ASICs)对于运营规模非常大的组织,云服务提供商提供定制设计的专用集成电路(ASICs),其唯一目的是:高效、低成本的模型推理。AWS Inferentia: 这些芯片由亚马逊设计,旨在提供高吞吐量和每次推理的低成本。使用它们需要使用AWS Neuron SDK编译您的模型,该SDK会对其进行优化以在Inferentia硬件上运行。像inf1和inf2这样的实例在大规模推理方面通常比同等GPU实例显著便宜。Google Cloud TPUs: 尽管以训练闻名,谷歌也提供TPU(例如v4和v5e),这些TPU对于推理非常高效,特别是对于大型模型。与Inferentia类似,这条路径需要模型转换步骤才能在硬件上运行。使用这些ASIC的权衡是灵活性。它们支持特定的模型架构和操作集,并且所需的编译步骤会增加工程开销。然而,对于稳定、高容量的工作负载,成本节约可能非常可观。适当规模、自动扩缩和无服务器选项选择实例类型只是第一步。为了有效管理成本,您必须使您的预置容量与实际需求相匹配。自动扩缩: 推理流量很少是恒定的。它可能在业务高峰期达到峰值,并在夜间下降。配置自动扩缩组以根据CPU利用率或未完成请求的数量等指标自动添加或删除实例。这确保您只为您所需的容量付费。模型优化: 降低服务成本最有效的方法是使模型本身更高效。模型量化(使用INT8而不是FP32精度)和剪枝等技术(在第五章中介绍)可以显著减小模型大小并加速推理速度,使您能够使用更小、更便宜的实例。无服务器推理: 对于不频繁或流量高度不可预测的工作负载,考虑使用AWS Lambda、Google Cloud Run或Azure Functions等无服务器平台。这些服务可以运行容器镜像,让您无需管理任何底层服务器即可部署模型。您只需为每次调用消耗的计算时间付费,这对于低流量应用程序而言可以非常经济高效。最终的决定是性能、成本和工程投入之间的平衡。一个简单的基于CPU的部署易于管理,而高度优化的基于ASIC的解决方案需要更专业的工作,但在规模化时能提供最低的成本。实例类别最适合主要考量云服务示例CPU (通用型)低到中等流量、对延迟敏感的应用程序、传统机器学习模型。简单性及低闲置成本。AWS m 系列, GCP e2/n2, Azure DSv4GPU (推理优化型)高吞吐量、大型深度学习模型、可批处理请求。吞吐量和性能。AWS g4dn/g5 (T4/A10G), GCP n1 带 T4/L4专用ASIC超高容量、稳定工作负载,以实现最高成本效益。规模化时每次推理成本最低。AWS inf 系列 (Inferentia), GCP TPU 实例无服务器计算不频繁或高度不可预测的流量。按用量付费,无闲置成本。AWS Lambda, Google Cloud Run, Azure Functions