面向智算服务构建下一代可观测 Pipeline

烨陌

2025-03-18

云原生智算服务关键技术

AI 发展趋势

在过去的十多年中，以深度学习为核心算法，在 GPU 提供的强大算力支持下，并得益于海量数据的积累，AI 技术取得了革新性的飞跃。这一进程涵盖了有监督学习、无监督学习和强化学习等多种学习范式，促进了机器视觉、语音识别与自然语言处理等多个子领域的显著突破。深度学习驱使 AI 在商业智能、个性化医疗、智慧教育、智能制造、网络安全及智能交通管理等领域被广泛应用。

总结深度学习任务的特性，我们可以看到：

首先，它是一种端到端的工作流水线，旨在从大规模原始数据中提取特征，进而构建可执行模型，其间会涉及数据准备、模型构建、模型训练、模型推理四个步骤。

其次，此类任务往往伴随着计算密集型的特点，训练过程可能耗时极长，周期从数小时到数月不等。在训练过程中，需反复迭代优化，不断调整参数，以使模型能够更好地接近真实数据特征分布，这会导致算力资源和数据的巨大消耗。

近年来，随着大型语言模型（LLM）和人工智能生成内容（AIGC）等新领域阶跃式发展，模型参数规模呈现出每年十倍的指数级增长趋势，AI 对基础设施服务能力提出了前所未有的挑战。主要体现在规模、性能和效率三个方面。

规模方面：在训练具备广泛知识和专业领域理解及推理能力的大语言模型时，通常需要万卡级别的 GPU 集群、PB 级的数据存储以及 TB 级的数据吞吐。此外，高性能网络需支持单机 800Gbps 甚至 3.2Tbps 的 RDMA 互联，以确保高效的计算和数据传输。
性能方面：
- 在训练阶段，随着模型规模参数的显著增加，单个 GPU 已无法满足计算需求。因此，分布式训练成为必要选择，通过利用多GPU架构并结合多种混合并行策略来加速训练过程。这些策略涵盖了数据并行（Data Parallelism）、模型并行（Model Parallelism）、流水线并行（Pipeline Parallelism）以及专为序列处理设计的序列并行技术（Sequence Parallelism）。
- 进入推理阶段后，目标转向提供既高效又可靠的推理服务。为此，必须持续地对模型进行性能调优，并采取有效措施确保服务质量（QoS, Quality of Service）达到预期标准，从而满足用户对于响应时间、吞吐量及稳定性的高要求。
工程效率方面：伴随 AI 技术的突飞猛进和广泛应用，我们越来越发现想要保证“算法+算力+数据”的飞轮高效运转，规模化生产出有商业落地价值的 AI 能力，其实并不容易。规模的扩大与性能的要求，带来了昂贵的算力投入与工程复杂度的提升。效率的提升迫在眉睫，主要表现在：资源利用效率提升，通过弹性扩展资源规模，以应对突发的计算需求；工程效率提升，优化算法人员的工作效率，提高模型迭代速度和质量。

容器服务是 AI 场景的基础设施

经过 10 年发展，Kubernetes 技术已经成为容器领域编排业务应用和微服务实际意义上的基础技术底座。在 AI 时代，Kubernetes 继续快速演进，基于 Kubernetes 的容器技术逐渐成为 AI 场景的理想选择。

Kubernetes 原生的资源调度与弹性伸缩、设备插件灵活扩展、命名空间与资源配额、持续集成与持续部署、容器化应用管理等能力，天然解决了 AI 工程当中普遍面临的分布式计算、异构硬件、资源隔离、迭代效率、环境一致性的痛点。

然而普通的 Kubernetes 还满足不了完全 AI 训练、推理的一些要求，需要从“计算、存储、网络”三个维度进行增强。

计算：

Kubernetes 是一个用于大规模节点上管理容器的系统，其核心功能在于根据资源需求将容器调度至合适的节点。默认情况下，Kubernetes 主要考虑的资源类型是 CPU 和内存。然而，当容器需要特殊硬件资源（如 GPU）时，Kubernetes 的原生机制就显得不足了。这是因为 Kubernetes 本身并不直接支持异构资源的管理和调度，仅统计节点上的剩余 CPU 和内存资源。

为了解决这一问题，Kubernetes 引入了设备插件框架（Device Plugin Framework），允许第三方开发者扩展 Kubernetes 对各种异构资源的支持。通过这一框架，可以实现对 GPU、RoCE 网卡、NPU 卡、FPGA、加密狗等多种硬件的管理。例如，GPU Device Plugin 可以实时监控和报告节点上的 GPU 使用情况，从而帮助 Kubernetes 按需分配 GPU 资源。这种灵活的插件机制使得 Kubernetes 成为了一个通用且强大的资源调度平台，能够应对多样化的计算需求。

网络。

在Kubernetes标准框架中，容器通常仅配置单一网络接口（eth0），无论是通过 overlay 网络实现隧道通信还是利用 underlay 网络实现直接通信，其核心目标均在于确保网络连通性。然而，在大规模 AI 集群中，特别是涉及百亿乃至千亿参数的大模型分布式训练时，普通以太网传输效率低下，无法满足高速数据交换需求。为此，采用 RDMA 技术成为必要的选择，因其能够绕过 TCP/IP 协议栈并直接在硬件层面进行数据传输，显著提升网络性能，从而大幅加速参数梯度等信息节点间的交换。

存储。

AI 场景下，数据摄取、模型加载、批量读取和 Checkpointing 模型内部状态等往往涉及大量 IO 密集型的任务，可能会造成瓶颈，限制整体性能和 GPU 利用率。以 Checkpoint 为例，为了确保训练过程中的容错性和恢复能力，定期执行 Checkpoint 是至关重要的环节。然而，在 Checkpoint 运行期间，所有相关的计算活动均需暂停，导致原本应处于高效运算状态下的 GPU 资源被迫进入闲置等待模式，直至 Checkpoint 完成其数据持久化至磁盘的操作为止。因此，加速 Checkpoint 流程成为了提升整体性能的关键所在。

然而，随着深度学习模型规模日益扩大，单个Checkpoint 文件大小往往达到数 TB 级别，这给传统的存储解决方案带来了前所未有的挑战——尤其是在写入吞吐量方面形成了显著障碍。为了解决这一问题，采用具备高带宽、低延迟特性和高 IOPS 能力的分布式并行文件系统成为了业界普遍认可的最佳实践之一。

AI 工程平台：从小作坊到云原生架构

在计算、存储、网络增强后，Kubernetes 满足了作为 AI 的基础设施条件。工程师借助 Kubernetes 和 Kubeflow 等便可以快速构建 GPU 集群，实现 AI 任务的调度与 GPU 资源分配，并通过标准化接口访问存储服务。训练完成的模型可直接部署于该集群内，从而初步完成了从 AI 开发到生产的流程闭环。然而，随着对生产效率要求的提升，一系列挑战也随之浮现：GPU 利用率低、分布式训练扩展性差、作业无法弹性伸缩、训练数据访问慢、缺少有效的数据集及模型管理工具、难以获取实时的日志监控与可视化支持、模型发布缺乏质量和性能验证、上线后缺少服务化运维和治理手段、Kubernetes 和容器使用门槛高、用户体验不符合数据科学家的使用习惯、团队协作和共享困难、资源争抢等问题。

为了从根本上解决这些问题，AI 生产环境必然要从“单打独斗的小作坊”模式，向“资源池化 + AI 工程平台化 + 多角色协作”的云原生架构模式升级。云原生架构的 AI 工程平台通过资源池化，实现计算资源的高效共享和动态调度，提升资源利用率；平台化提供统一的开发、训练和部署环境，简化工作流程，缩短开发周期；多角色协作支持数据科学家、工程师的无缝合作，增强团队效率和创新能力。从而有效地把数据科学家和算法工程师从繁杂低效的环境管理、资源分配和任务调度工作中解放出来，将更多的精力留给更核心的算法领域。三方研究机构预测到2025年，接近50%的企业内部的数据密集型或性能密集型计算工作负载都将迁移到基于云原生的架构上。

云原生 AI 核心场景

云原生 AI 能够充分利用云计算的弹性资源、异构算力以及容器、自动化、微服务等云原生技术，提升AI/ML的工程效率，降低整体成本，提高可扩展性，并实现端到端的解决方案。其中最核心的两大应用场景：

统一管理异构资源，提升资源利用率。

对各种异构的计算（如CPU，GPU，NPU，VPU，FPGA，ASIC）、存储（OSS，NAS， CPFS，HDFS）、网络（TCP， RDMA）资源进行抽象，统一管理、运维和分配，通过弹性和软硬协同优化，持续提升资源利用率。

原生 Kubernetes 仅支持 GPU 整卡调度，导致任务容器独占GPU资源。对于计算量和显存需求较小的任务模型，这将造成 GPU 资源的浪费。为解决此问题，引入了 GPU 共享调度机制，该机制允许根据模型的实际算力和显存需求，在同一块 GPU 上并行运行多个任务容器，从而提高GPU 利用率。GPU 共享调度还支持多种分配策略，包括用于模型推理场景的单容器单 GPU 卡共享、用于分布式模型训练的单容器多 GPU卡共享。

实时观测和分析 GPU 资源利用率和 GPU 任务的性能表现，及时识别瓶颈进行优化。

统一任务调度，实现AI、大数据等复杂任务的高效管理。

标准 K8s 集群的容器调度是针对单个容器独立调度的。但是分布式AI训练容器不一样，它们是一组容器，必须同时运行，即所谓的 All_or_Nothing，这个是分布式 AI 场景的强诉求。否则会因为多个分布式作业在资源调度层面出现争抢，导致出现资源维度的死锁，结果是谁都没法正常训练。

为了提升资源利用率，就需要扩展 Kubernetes 原生调度框架，常见的有 Gang Scheduling、Binpack Scheduling、Capacity Scheduling 等。

智算服务可观测需求与挑战

前面我们知道云原生架构的容器服务逐渐成为了支撑 AI 智算的基础底座。随着 AI 任务规模快速发展，特别是大模型的参数量从十亿量级跃升至万亿级别，训练规模的急剧扩张不仅引发了集群成本的显著上涨，还对系统稳定性构成了挑战。

GPU价格昂贵，且坏卡率高，如何自动进行坏卡检测，从而任务、环境自愈，是保证 AI 生产任务不间断的基本保障需求。
模型如何调参，任务为什么跑得慢，都需要暴露更多透明化的观测能力帮助进行模型性能优化，帮助调参。
在生产环境如进行推理任务时，如何保障集群、AI 业务任务的环境稳定性。

为了有效应对上述挑战，迫切需要构建可观测数据驱动的云原生智算服务架构。对应于智算服务系统分层架构，可观测体系也针对性地分为 IaaS 层云资源可观测、CaaS 层容器可观测、PaaS 模型训练/推理可观测等三个层次。

在构建面向智能计算服务的可观测性体系时，一个关键需求是如何能够适应云原生 AI 基础设施的特点，进行有效的可观测数据采集及预处理。这一过程中面临的主要挑战包括但不限于：

异构属性
- 资源异构：计算、存储、网络等资源异构，数据丰富度与时效性要求高。例如，GPU、CPU、RDMA、CPFS等。
- 数据异构：从集群组件到模型所应用产生的观测指标、日志各不相同且种类繁多。
集群规模大
- 分布式训练多个节点协同工作，可观测数据一致性。
- 多集群/跨地域训练时稳定性，能够应对网络不稳定的风险。
- 大规模多集群下采集任务的可管控性。
弹性：工作负载增删频繁、生命周期不确定、流量突发大。
- 分布式训练模型复杂、训练参数/数据大，扩容速度10K Pod/min。
- 分布式训练过程中节点失效容错/资源变动等，需要弹性保证训练连续性。
- 分布式推理（潮汐业务）随流量变化进行扩缩容。
多租
- 可观测数据采集的隔离性。
- 采集任务的优先级调度。

因此，迫切需要一款强大的适应于云原生智算服务的可观测 Pipeline，它需要集可观测采集与预处理于一身，具备全面的数据采集能力、灵活的数据处理；强大的弹性能力；性能好、资源开销低、稳定可靠；支持多租；管控能力强，易用等特点。

下一代可观测 Pipeline 架构

LoongCollector 是一款集卓越性能、超强稳定性和灵活可编程性于一身的数据采集器，专为构建下一代可观测 Pipeline 设计。愿景是：打造业界领先的“统一可观测 Agent（Unified Observability Agent）”与“端到端可观测 Pipeline（End-to-End Observability Pipeline）”。

LoongCollector 源自阿里云可观测性团队所开源的 iLogtail 项目，在继承了 iLogtail 强大的日志采集与处理能力的基础上，进行了全面的功能升级与扩展。从原来单一日志场景，逐步扩展为可观测数据采集、本地计算、服务发现的统一体。凭借着广泛的数据接入、高性能、高可靠、可编程性、可管控性、云原生支持、多租隔离等特点，LoongCollector 可以很好的适应智算服务可观测采集与预处理的需求场景。

遥测数据，无限边界

LoongCollector 秉承 All-in-One 的设计理念，致力于所有的采集工作用一个 Agent 实现 Logs、Metric、Traces、Events、Profiles 的采集、处理、路由、发送等功能。LoongCollector 着重强化了 Prometheus 指标抓取能力，深度融入 eBPF（Extended Berkeley Packet Filter）技术以实现无侵入式采集，提供原生的指标采集功能，做到真正的 OneAgent。

秉承开源、开放的原则，积极拥抱 OpenTelemetry、Prometheus 在内的开源标准；同时，支持 OpenTelemetry Flusher、ClickHouse Flusher、Kafka Flusher 等众多开源生态对接能力。作为可观测基础设施，LoongCollector 不断完善在异构环境下的兼容能力，并积极致力于实现对主流操作系统环境的全面且深度的支持。

K8s 采集场景的能力一直都是 LoongCollector 的核心能力所在。众所周知在可观测领域，K8s 元数据（例如 Namespace、Pod、Container、Labels 等）对于可观测数据分析往往起着至关重要的作用。LoongCollector 基于标准 CRI API 与 Pod 的底层定义进行交互，实现 K8s 下各类元数据信息获取，从而无侵入地实现采集时的 K8s 元信息 AutoTagging 能力。

性能可靠，无懈可击

LoongCollector 始终将追求极致的采集性能和超强可靠性放在首位，坚信这是实践长期主义理念的根基。主要表现为性能、资源开销、稳定性上的精益求精。

持续的性能突破：采用了单线程事件驱动，并且结合时间片调度、无锁化、数据流处理免拷贝等技术，使其在具备高性能的同时资源占用也极低。
内存管理精益求精：使用 Memory Arena 技术减少内存的分配次数，核心数据流使用 Zero Copy 技术减少内存无效拷贝。
高低水位反馈队列：流量反压控制机制，At-Least-Once 语义保证。
Pipeline 多租户隔离：不同数据流之间相互隔离，提供优先级调度机制；多目标发送，网络异常流控机制。
可持久化缓存：容忍短时间环境异常，保证数据不丢。

编程管道，无与伦比

LoongCollector 通过 SPL 与多语言 Plugin 双引擎加持，构建完善的可编程体系，提供了强大的数据预处理能力。不同引擎都可以相互打通，通过灵活的组合实现预期的计算能力。

开发者可以根据自身需求灵活选择可编程引擎。如果看重执行效率，可以选择原生插件；如果看重算子全面性，需要处理复杂数据，可以选择 SPL 引擎；如果强调低门槛的自身定制化，可以选择扩展插件，采用 Golang 进行编程。

配置管理，无忧无虑

在分布式智算服务复杂的生产环境中，管理成千上万节点的配置接入是一项严峻挑战，这尤其凸显了在行业内缺乏一套统一且高效的管控规范的问题。针对这一痛点，LoongCollector 社区设计并推行了一套详尽的 Agent 管控协议。此协议旨在为不同来源与架构的 Agent 提供一个标准化、可互操作的框架，从而促进配置管理的自动化。

基于该管控协议实现的 ConfigServer 服务，可以管控任意符合该协议的 Agent，显著提升了大规模分布式系统中配置策略的统一性、实时性和可追溯性。ConfigServer 作为一款可观测 Agent 的管控服务，支持以下功能：

以 Agent 组的形式对采集 Agent 进行统一管理。
远程批量配置采集 Agent 的采集配置。
监控采集 Agent 运行状态，汇总告警信息。

行业对比

在可观测领域，Fluent Bit、OpenTelemetry Collector 及 Vector 都是备受推崇的可观测数据采集器。其中，FluentBit 小巧精悍，以性能著称；OpenTelemetry Collector 背靠 CNCF，借助 Opentelemetry 概念构建了丰富的生态体系；而 Vector 在 Datadog 加持下，则通过 Observability Pipelines 与 VRL 的组合，为数据处理提供了新的选择。而 LoongCollector 则立足日志场景，通过持续完善指标、跟踪等场景实现更全面的 OneAgent 采集能力；依托性能、稳定性、Pipeline灵活性、可编程性优势，打造核心能力的差异化；同时，借助强大的管控能力，提供了大规模采集配置管理能力。更多详见下表，绿色部分为优势项。

智算服务可观测 Pipeline 技术实践

作为一款高性能的可观测数据采集与预处理 Pipeline，LoongCollector 在智算集群中具备如下几种工作模式：

Agent 模式：As An Agent
- LoongCollector 作为 Agent 运行在智算集群的节点上，每个 LoongCollector 实例专注于采集所在节点的多维度可观测性数据。
- 充分利用本地计算资源，实现在数据源头的即时处理，降低了数据传输带来的延迟和网络流量，提升了数据处理的时效性。
- 具备随节点动态扩展的自适应能力，确保在集群规模演变时，可观测数据的采集与处理能力无缝弹性伸缩。
集群模式：As A Service
- LoongCollector 部署于一个或多个核心数据处理节点，以多副本部署及支持扩缩容，用于接收来自系统内 Agent 或开源协议的数据，并进行转换、汇集等操作。
- 作为中心化服务，便于掌握整个系统的上下文，强化了集群元数据的关联分析能力，为深入理解系统状态与数据流向奠定了基础。
- 作为集中式服务枢纽，提供 Prometheus 指标抓取等集群数据抓取和处理能力。

分布式指标采集

鉴于智算服务系统架构的复杂性和多样性，需要对多种关键性能指标进行监控。这些指标涵盖了从基础设施层面到应用层面的范围，并且以 Prometheus Exporter 的形式对外提供数据接口。例如针对计算节点资源的 Node Exporter，针对 GPU 设备的 NVIDIA DCGM Exporter，针对集群的 kube-state-metrics，针对训练框架的 TensorFlow Exporter、PyTorch Exporter等。

LoongCollector 具备原生支持直接抓取 Prometheus Exporter 所暴露的各项指标的能力，采用 Master-Slave 多副本采集模式。

Master 功能由 LoongCollector Operator 承载，根据服务发现结果提供 Target Allocator 能力，实现 Woker 负载均衡、水平扩缩容能力、平滑升级等能力。
Worker 节点则由 LoongCollector 承载，采用 Pipleline 架构，根据 Target Allocator 结果进行指标抓取与处理。

基于智算服务采集的指标结果，可以通过可视化仪表盘进行 GPU 使用量监控及坏卡状态检测。同时对于高吞吐量的场景，可以快速发现多集群多卡 AI 训练的瓶颈点，以便更好的提升 GPU 等资源利用率。

分布式日志采集

在智算集群日志采集场景下，LoongCollector 根据业务要求提供了灵活的部署方式。

DaemonSet方式：在集群的每个节点上部署一个 LoongCollector，负责采集该节点上所有容器的日志；特点：运维简单、资源占用少、配置方式灵活；但是隔离性较弱。
Sidecar方式：每个 Pod 中伴随业务容器运行一个 LoongCollector 容器，用于采集该 Pod 中业务容器产生的日志；特点：多租户隔离性好、性能好；但资源占用较多。

不管是分布式训练还是推理服务部署，都有较强的弹性特点。LoongCollector 很好的适应了弹性与多租的要求：

容器自动发现：通过访问位于宿主机上容器运行时（Docker Engine/ContainerD）的 sock 获取容器的上下文信息。
- 容器层级信息：容器名、ID、挂载点、环境变量、Label
- K8s层级信息：Pod、命名空间、Labels。
容器过滤及隔离性：基于容器上下文信息，提供采集容器过滤能力，既可以保证采集的隔离性，也可以减少不必要的资源浪费。
元信息关联：基于容器上下文信息和容器环境变量，提供在日志中富化 K8s 元信息的能力。
采集路径发现
- 标准输出：可以根据容器元信息自动识别不同运行时的标准输出格式和日志路径，不需要额外手动配置。
- 容器内文件：对于 overlay、overlay2 的存储驱动，根据日志类型及容器运行时自动拼接出采集路径。

数据处理方案：容器上下文关联与数据处理

智算服务场景下，为了最大化地挖掘数据价值，通常需要将集群日志、分布式训练日志以及推理服务日志高效采集并传输至后端日志分析平台，并在此基础上实施一系列的数据增强策略。对于分布式训练日志而言，需要关联容器上下文需包含容器 ID、Pod 名称、命名空间和节点信息，确保追踪和优化跨容器的 AI 训练任务；推理服务为了针对访问流量等进行更高效的分析，需要对日志进行字段标准化处理，同时也需要关联容器上下文。

LoongCollector 凭借强大的计算能力，可以针对接入的数据，关联 K8s 元信息；同时，利用 SPL、多语言插件计算引擎，提供灵活的数据处理编排能力，便于处理各类负责格式。

如下是一些典型的日志处理场景：

分布式训练多行日志切分：训练异常往往涉及调用栈信息，通常以多行形式呈现。
分布式训练、推理服务容器上下文关联：便于追踪异常训练任务与线上服务。
日志上下文顺序查看：采集到日志分析系统不会导致日志乱序。

eBPF 采集

在分布式训练框架下，多个计算节点协同工作以加速模型训练过程。然而，在实际操作中，整体系统性能可能受到多种因素的影响而变得不稳定，如网络延迟、带宽限制及计算资源瓶颈等，这些都可能导致训练效率的波动甚至下降。LoongCollector 通过 eBPF 技术，在智算服务中实现无侵入网络监控，通过实时捕获和分析流量，识别集群网络拓扑，达到快速捕获异常点的作用，进而提升整个模型训练的效率。