自 2022 年 11 月 OpenAI 发布 ChatGPT 以来，AI 加速融入实际应用的进程日益加快。伴随着 AI 需求的增多，加快日常迭代对于 AI 厂商来说越来越重要，而云原生刚好能在资源效率和开发交付效率上为 AI 应用赋能。

2024 年 3 月，CNCF 发布了首份关于云原生人工智能 CloudNative AI 的白皮书，详尽地探讨了将云原生技术与人工智能融合的当前状态、面临的挑战以及未来的发展方向：https://www.cncf.io/reports/cloud-native-artificial-intelligence-whitepaper。

结合业界的诸多讨论和火山引擎云原生团队的一些实践，如果需要从从分层架构层面理解云原生 AI，我们认为云原生 AI 将需要重点围绕资源管理、应用管理提供能力，如下图所示：

平台层面，围绕计算加速/访问加速/配置与权限管理提供服务：

• 支持 gang/numa-aware 等面向 AI workload 场景的调度能力，提供 queue 等能力管理 AI workload 的资源配额；

• 基于 AI 镜像超大、数据量超大的特点，提供镜像缓存/镜像预热/懒加载等镜像启动加速能力，并通过统一数据访问/数据缓存，将数据访问加速标准化；

• 配额与权限管理方面，提供基于 RBAC/IAM 的标准化权限管理，以及灵活的资源 quota 管理。

ML Lifecycle 层面，围绕 AI 模型训练/推理的生命周期提供服务：

• 通用能力上，提供 Debug/Workflow/Cost 能力，通过性能分析/故障检测自愈等增强 Debug 异常定位能力，通过 workflow/构建/部署策略等提供自动能力，通过资源弹性/应用弹性/虚拟化共享 GPU/任务分离等功能增强 Cost 管理能力；

• 模型训练场景，面向数据准备->预训练->微调等训练生命周期提供相应的功能，并通过加速库/AutoML 等提升训练效率；

• 模型推理场景，重点围绕 serving 提供竞争力，提升模型的推理性能和吞吐。

随着业界对于人工智能应用场景的不断拓展，企业在 AI 上的投资正在持续加大，但在工程层面，AI 应用涉及的服务模块和服务配置项繁多，比如推理引擎、模型配置等，配置复杂度高，会给用户带来较高的使用门槛，影响业务迭代效率。

如前文所述，企业在平台层面可以围绕计算加速/访问加速/配置与权限管理做一些建设，比如：

• 应用开发前：提供 AI 应用相关的基础镜像，如 Triton Inference Server/PyTorch/TensorFlow 等，这样工程师无需写 Dockerfile，即可由平台根据用户的配置自动构建镜像，提高开发效率；

• 应用开发中：将 AI 应用的描述封装为模板，用户只需填写少量必要的配置，无需写 Kubernetes YAML，即可自动生成 Kubernetes workload，轻松实现一键部署；

• 应用部署中：对于 AI 应用，出于稳定性保障的诉求，应支持渐进式的发布策略，允许工程师采用分批或灰度发布的策略降低发布风险；

• 应用部署后：提供将新实例注册到网关、下线旧实例的自动化能力；

• 应用运行中：面向 AI 应用提供弹性扩缩容能力，以更好应对弹性需求，降低资源成本。

火山引擎云原生团队针对上述问题做了一些探索，下面是我们基于落地实践总结的一些在平台层面可提供的通用解决方案。

在工程环境中，AI 模型所使用的基础镜像相对收敛，机器学习框架、依赖软件等相对比较统一，这为我们向企业用户提供可靠且高度一致的 AI 开发环境提供了可能。

我们在火山引擎云原生 AI 套件中提供了一系列预置镜像，预装常见的 AI 框架、工具和相关依赖。这些镜像是在火山引擎的云环境中验证过，每个地域都有提供，可以满足开发机、AI 应用构建、开发环境 commit 等多种使用场景。

AI 应用通常很大（十几 GiB 或更大），导致应用冷启动缓慢，会影响用户对服务的整体印象和满意度。同时，大镜像又会导致传输和部署时间长，增加运维成本。针对这个问题，我们提供了三种不同的镜像加速方案，满足 AI 训练、推理、精调等场景下的加速需求。

方案一：镜像懒加载

• 方案原理：利用容器启动时只需部分镜像数据，通过按需加载所需镜像数据而非全部数据，提升容器启动效率；

• 适用场景：适合容器镜像大、数据局部热点明显、镜像更新频繁的场景；

• 受限因素：对镜像自身有要求，需要数据局部热点明显，同时也会对镜像仓库带来比较大的请求压力。

方案二：P2P 加速

• 方案原理：利用节点的内网带宽资源，在节点之间分发镜像，减少对镜像仓库的压力；

• 适用场景：适合镜像大、频繁变更且集群中节点数量多的场景；

• 受限因素：会对节点上的云盘带来较大压力，造成读放大。

方案三：自定义节点镜像

• 方案原理：对容器镜像进行拆分，将变动频率低的数据下沉到节点的操作系统镜像，减少容器启动时现场拉数据的量；

• 适用场景：适合底层镜像变动频率低、对启动速度有极致要求的场景；

• 受限因素：对于变更频繁，尤其是变更较多层的场景，会使得预先缓存的镜像层失效。

我们也提供模型仓库服务，由模型仓库提供模型的版本管理、安全扫描、制品同步、回收清理等功能，同时支持对接外部模型仓库，如 HuggingFace 等。

AI 模型部署时，为了保障推理效果能让用户满意，企业可以选择进行灰度发布，逐步调大新模型的流量。通常情况下，模型会存储在模型仓库中，我们可以借助模型仓库的版本管理能力管理模型的不同版本。部署模型时，运行环境通常不会有变化，差异点在于通过 PVC 挂载的模型不同。同时由于模型的体积通常都很大，部署新模型时可借助上述模型加载加速能力来降低冷启动的耗时。

网关层面上，借助灰度标签，工程师可以控制存量模型和新模型的流量比例，以实现灰度发布的能力。在灰度发布过程中，网关提供了丰富的技术和业务观测数据，进一步确保灰度过程的稳定性。

从模型发布的端到端角度来看，模型发布涉及到模型的测试、模型存储管理、模型部署、灰度发布等过程，这个过程涉及到较多的环节和组件。

为了提升整体的发布效率，减少人工介入带来的发布风险，我们提供了模型发布流水线，通过流水线将端到端的发布过程自动化，如下所示：

首先我们先通过两张图快速回顾下 Transformer 和 StableDiffusion 模型的架构：

左图是经典的 Transformer 架构，它在大规模数据集上的训练效率高，同时 self-attention 机制使得模型在处理复杂语言任务时表现出色，但 Transformer 架构的一些因素又极大影响了其推理性能：

• 计算复杂度：Transformer 的 self-attention 机制对输入序列长度具有平方复杂度，这意味着随着序列长度的增加，计算成本呈平方增长；

• 内存使用：Transformer 模型需要大量内存来存储模型参数和推理过程中产生的中间状态，从而导致内存需求显著增加；

• 并行化能力：在序列生成过程中，Transformer 通常以自回归的方式进行推理。这意味着每个 token 必须按顺序串行生成，限制了并行化的能力，从而增加了推理时间。

右图是经典的 Stable Diffusion 架构，具有高效的图像生成能力，还可以用于视频和动画的生成、图像编辑等。Stable Diffusion 将随机噪声转化为图像是个迭代的过程，导致计算复杂度较高，同时在推理过程中需要大量显存。

在生产环境中部署 AI 模型时，工程师通常会使用专门的推理引擎管理请求和模型，比如业界常用 Triton Inference Server/vLLM/TGI 部署 LLM 模型，使用 ComfyUI/Stable-Diffusion WebUI 部署 StableDiffusion 模型。

虽然推理引擎各种各样，但它们的核心能力基本类似，主要包括两方面：

• 请求管理：将外部请求转发到对应的模型；

• 模型管理：模型的 load/unload 等，有些推理引擎额外还有多模型、多 lora 管理等。

这里以 Triton Inference Server 为例端到端分析影响 AI 推理请求的因素，Triton Server 主体分为两部分：

• Server：智能调度传入的推理请求，支持多个模型或同一模型的多个实例在同一系统上并行执行，提供批量处理能力，以提高吞吐量和减少延迟。并支持丰富的观测能力，提供关于模型性能、资源使用和请求延迟的详细指标；

• Backend：专门负责实际推理计算的组件，支持多种后端，如 TensorRT/ONNX Runtime/vLLM/PyTorch 等；

• Triton Server 启动时，会根据配置进行模型的 load/warmup 等操作，减少首个请求的处理延时，并提供请求结果的缓存能力，提升相同请求的处理性能等。

基于生产环境中推理引擎架构和工作流程的理解，我们可以总结出端到端的推理性能优化方案：

• Batching：通过批处理请求，提升推理引擎的吞吐，降低请求的响应延时；

• TensorRT/TensorRT-LLM：使用 Layer Fusion/量化/Kernel Auto-Tuning/Dynamic Tensor Memory Management 等技术，面向特定的运行环境优化模型格式；

• Model Instances：增加模型实例的数量，充分利用硬件资源来提升吞吐；

• Response Caching：对于重复请求的结果进行缓存，降低重复请求的响应延迟；

• Model Warmup：预热模型，降低首个请求的处理延迟；

• Quantization：模型量化，适当降低模型精度，减少显存占用，提升推理性能；

• Torch compile：基于 PyTorch 的能力优化 cuda graph，降低请求处理延时；

• Distributed KV Cache: 分布式推理场景下，共享模型处理过程中的缓存数据，提升系统整体的吞吐，降低请求处理延时；

• Storage Access Acceleration：存储访问加速，优化模型加载性能。

AI 模型通常很大，一般会被放在 TOS/NAS 等远端存储，在有请求时远程拉取和加载。此时模型的访问性能会极大影响模型请求的端到端性能，这也是 AI 推理中影响端到端性能极为关键的环节。接下来我们将结合生产实践，重点分析如何使用云原生技术解决存储访问加速问题。

AIGC 场景下，很多企业会选择通过 Stable Diffusion 模型生成图片。在这个场景下，模型启动前就需要先读取基础模型，再响应外部的请求。我们将这个过程做下拆分，可以分成四个阶段：

• 第一阶段是业务流量来临，指标升高，触发 HPA 扩容。这里略有一些延迟，主要是指标采集、计算，反映到 HPA 上的延迟一般是秒级别，我们暂时可以先忽略；

• 第二阶段在 HPA 触发了 Pod 扩容后调度到节点上完成 Pod 创建的过程，涉及调度、sandbox 创建、拉取镜像等多个步骤，其中拉镜像是一个耗时点；

• 第三阶段是 Pod 创建完成后启动起来，业务开始自身的初始化，即 Stable Diffusion 从远端存储上读取模型、启动，这之中读取模型也是一个耗时点；

• 最后是对外提供服务。

整个流程中有两个比较显著的耗时点，一个是拉镜像，另一个是拉模型。

• 拉镜像慢，是因为 AI 场景下的容器镜像普遍都非常大，镜像中包含了 CUDA、各种推理框架、Python 库，这种场景可通过相对成熟的 P2P、镜像懒加载、镜像预热等方案来解决。如前文所述，目前火山引擎的云原生 AI 套件已可提供这三种加速能力；

• 拉模型慢，是因为存储产品的带宽是固定的，当同时读取模型的 Pod 数量很多时，每个 Pod 平摊到的带宽很小，对单个 Pod 来说，下载模型的速度就慢。虽然可以通过使用更高性能的存储来暂时缓解这个问题，但会带来成本的增加，同时存储产品的带宽是固定的，Pod 的数量增长后，平摊到每个 Pod 上的下载带宽就会减少，因此需要一个更加灵活、弹性、低成本的解决方案。

在火山引擎云原生团队服务企业用户的落地实践中，我们采取的方式是引入 Fluid，它能很好地解决这些问题。

Fluid 是一个 CNCF 开源项目，它定义了一套 API，抽象出的数据集（DataSet）、存储运行时（Runtime）等概念，既对接了 Alluxio、JuiceFS 这些优秀的存储系统，也对接了各大云厂商的存储产品，因此能将数据的使用和数据的存储解耦开，支持在不同环境中使用不同的存储运行时。

同时在管理存储运行时的过程中，Fluid 也能提供弹性伸缩的能力，贴合业务的流量峰谷以降低缓存成本。在业务高峰时，可以将存储运行时的 Pod 调度到性能更好的节点、增大副本数，来提升性能抗住压力；在业务低峰时，也能减小副本数来减少成本。

在数据集和存储运行时都正常运行后，Fluid 会创建一个新的 PVC，在最简单的场景下，使用数据的业务方，只要使用这个新的 PVC，修改下应用中使用的 PVC 名字和挂载路径，就能享受到数据加速的效果：

另外我们还能利用 Fluid 提供的预热（DataLoad）功能，让 Runtime 将我们指定的文件，提前从远端存储拉取到 Runtime 的缓存集群中，在应用读取时，避免去远端存储拉取。

我们基于客户的业务场景做了一些规模测试，证实 Fluid+Runtime 确实可以大幅减少 Stable Diffusion Pod 的首次文生图耗时。如下表所示，Worker 数量的不同、是否预热，提供的性能是不同的，这样用户在成本和性能之间的选择也更加灵活。

之后我们也会基于这个方案，去自研更快、更稳定的存储运行时，在模型文件的读取上，也会考虑和 veTurboIO 结合，然后在产品上去提升易用性、在稳定性上做更大规模的测试。

前面介绍了推理加速的理论方法，也介绍了通过 Fluid 和 Alluxio 去加速推理服务，还有一个问题：如何衡量推理服务的性能。

在我们的场景下，会衍生出这些问题：

• 相同的模型在不同的 GPU 卡（机型）上的性能表现如何；

• 不同的模型在相同的 GPU 卡（机型）上的性能表现如何；

• 在确定推理模型的 SLO，如何获得推理模型部署的配置推荐。

这就需要一个性能测试工具来回答上述问题。衡量推理服务的性能要从指标入手，这里我们可以把性能指标简单分为两类：系统指标和服务指标。

系统指标是指我们可以采集到的 CPU、内存、GPU 的使用率（node exporter、NVIDIA 的 dcgm exporter）；服务指标可以来自测试工具自身的报告、推理框架，也可以通过计算获得（如成本）。

值得注意的是，服务的性能和模型的表现之间可能会有冲突，有些优化手段是有损的，使用这些方法后模型的效果会降低，但性能会提升。所以用户也可以不断尝试优化方法，在满足模型效果的前提下，去寻找适合的部署配置。

针对 LLM 场景，我们比较关注延迟和吞吐，比如 TTFT 首 token 延迟和 TPOT 输出的每个 token 的耗时，还有 input  和 output 的吞吐量。

下图展示了我们内部当前正在开发的测试工具，通过 Kubernetes CRD 或者火山引擎云原生产品的 OpenAPI，让用户来做一些配置，比如测试目标、用来部署模型的 backend 框架、要部署的模型和一些部署参数，再设定一些测试场景，比如总的测试请求量、发送速率等，设置完之后，测试工具能自动的在 Kubernetes 集群里，在不同的 GPU 节点上部署 model server，然后执行测试、获得测试数据。经过多种参数、多轮测试后，我们就能知道应该在哪种规格的节点上、使用哪些参数、什么框架来部署模型，能获得一个最大的吞吐。

后面我们会将这些工作都开源出来，支持云原生 AI 领域的发展。

下面展示了我们测评工具的输出，一类是文本类的，偏向程序视角的使用，一方面是易于解析，另一方面也方便后面和其他工具配合使用，形成工作流。另一类是图表，偏向用户视角，能直观看到测试的关键指标，和不同部署配置之间的性能差异。

Llama3 的发布是 AI 开源领域的里程碑，但其报告显示硬件故障率高达 78%，GPU 故障占 58.7%，严重影响训练效率和模型性能，这要求我们在硬件稳定性和故障管理上投入更多关注。

下图是火山引擎云基础团队总结的 GPU 异常检测和处理方案，展示了在 AI 算力基础设施中，GPU 故障的多样性、检测场景的广泛性以及处理流程的复杂性。

• 首先，GPU 故障类型繁多，包括但不限于卡故障、显存故障、链路故障等。这些故障可能由电源不稳定、过热、硬件老化或软件配置错误引起；

• 其次，不同类型故障检测方法也相对复杂，需要丰富的领域知识和较多的实践，才能对 GPU 的性能和健康状态进行综合评估；

• 最后，处理 GPU 故障的过程相对复杂。一旦检测到异常，需要进行一系列预定义的故障处理流程，如故障隔离、资源重新调度、自动修复等。这些流程需要精确协调，以最小化对 AI 训练和推理任务的影响。

面对 GPU 故障检测自愈的复杂度，我们形成了这样的解决方案：

通过定期检查和监听 IaaS 异常事件，我们可以及时准确对集群中 GPU 健康状态进行检查，并在出现异常时，执行预定义的故障处理流程：

• 首先对异常节点进行封锁，防止新任务分配；

• 其次排干节点上运行的任务，以减少对业务的影响；

• 然后重启节点，尝试恢复服务；

• 最后进行自愈结果的检查，确保 GPU 恢复正常运行。

值得注意的是，这些自愈动作是高度可配置的。用户可以根据自身业务需求和资源策略，灵活选择执行全部或部分自愈动作。这种灵活性不仅提升了故障处理的效率，也最大化了资源的利用率和业务的连续性。

检测自愈效果的好坏，很大程度上取决于故障检测的准确度。我们提出了一种精细化的异常检测与自愈策略，这张表格展示了我们的检测项与自愈动作的对应关系：

我们列出了多种 GPU 异常情况，包括但不限于过热、硬件故障、驱动问题等，并对每一种异常都设计了相应的自愈动作，如自动重启、资源重新分配、故障隔离等。这种一一对应的策略，确保了一旦检测到异常，系统能够立即采取正确的自愈措施，从而最大限度地减少系统停机时间，保障 AI 服务的连续性和稳定性。

GPU 检测自愈通过一个内部后端系统实现：

• 左侧，用户配置检测和自愈规则；

• 中间，定时检测和监听 IaaS 事件，触发检测动作；

• 右侧，通过检测结果和用户配置，判断是否执行自愈动作，以及需要进行哪些自愈动作。