回复
从分布式追踪到任务级能耗治理 - DeepFlow 在算电协同中应用的思考 原创
树欲静而风不止
发布于 2025-10-16 14:38
浏览
0收藏
本文内容来自南京邮电大学的王梓炫，在 南京邮电大学 和 DeepFlow 社区联合举办的《电力业务全栈可观测性与算力电力协同发展》Meetup 上的主题分享。
作者：王梓炫，南京邮电大学 博士
大家好，我是南京邮电大学的博士后王梓炫。我的研究方向是信息网络，也是从去年开始关注到算电协同领域。今年开始和电网公司有一些项目合作，于是开始考虑怎么在数据中心中实现分布式任务的能耗追踪。我们注意到 DeepFlow 开源社区，并基于开源代码进行了一些实践。今天分享的内容就是 DeepFlow 在数据中心算电协同中的应用的一些思考。
我的介绍将从背景、挑战、到方案设计 逐步展开。
01｜背景与意义
先从算电协同的背景讲起，就是为什么我们希望做“算电协同”系统这件事。
首先，为什么现在 “算电协同” 会成为行业关注的焦点？
近两年 AI 技术的爆发，正推动算力需求与电力消耗形成 “双激增” 态势，两者的协同矛盾越发突出。
从算力侧看，需求呈加速扩张趋势：全球层面，AI 算力需求年均增长率达43%，远超传统IT负载（8%）；国内层面，2024 年智能算力规模占比已达 25.4%，2025 年将进一步提升至 35%，算力负荷正快速成为电力系统的重要组成部分。
从电力侧看，能耗压力同步凸显：全球数据中心总耗电量预计 2022-2026 年实现 “4 年翻番”，增量相当于瑞典或德国全国年用电量；国内数据中心年耗电量已达 1500 亿 kWh，占全社会用电 1.6%。更关键的是，由于计算任务的高功耗密度特点，突发的密集计算任务甚至可能引发电网崩溃，这导致算力增长与电力系统支撑能力的不匹配问题愈发突出。
算力需求快速扩张与电力供给稳定安全的矛盾，使得算电协同逐步成为行业关注的核心焦点。
既然能耗矛盾这么突出，算电协同的必要性就很明确了。
- 简单说，算电协同就是让 “算力网络” 和 “电力网络” 联动起来：
- 对数据中心而言，可调节负荷能参与电网调度，获得收益、降低运营成本；
- 对电网而言，能提升需求侧灵活性，缓解新能源消纳压力。比如数据中心的算力负荷本身具有 “时空灵活性”
- 时间上，离线任务可推迟处理；
- 空间上，部分任务可异地迁移；
- 设备层面，还能通过 CPU 频率调整、制冷系统控温等优化效率。
这种灵活性，正是新型电力系统建设的重要助力，也是实现算力与电力共赢的关键路径。
02｜算电协同的应用场景和挑战
那么当前算电协同有哪些应用场景和挑战呢？
当前算电协同的应用方向主要有3大类：
第一个方向是数据中心内部节能优化，通过观测计算任务能耗规律，依托能耗建模（如加性模型）识别高耗环节，用设备节能、任务调度等手段降低能耗成本，聚焦 “内部降耗”。
第二个方向是基于空间电价差异的任务迁移，利用区域电价差异，将非实时任务转移到低价区域降本，通过 “算力跟着电价走” 降低用电成本。
第三个方向是电网协同下的算电友好互动，在电网的统一调控下针对性转移负荷 。 比如电网高峰时，将部分可延迟任务转移到负荷较低的集群；新能源出力充足时，集中运行高耗能任务，助力绿电消纳。这种模式的核心是 “与电网友好互动”，让数据中心成为电网的灵活调节资源。
然而，无论是那种场景，其关键的问题均在于如何对算力任务的时空负荷进行建模，然后再进行多约束条件下的联合优化调度。
说了那么多宏观的例子，现在我举一个例子让大家感受一下算电协同的过程，也是我们目前正在合作的一个项目。
该数据中心由电网公司自建，并且地处山区，泥石流山火等灾害风险较高，会影响到数据中心的供电进而影响导数据中心的业务。因此，想通过算电协同来提升数据中心的容灾能力。
通过将数据中心的管理系统对接极端天气的预警系统。可以在极端天气发生前，实现极端天气的预测风险的评估。这里可以通过算法预测到极端天气对数据中心供电的影响程度。通过算力任务感知（包括任务类型、时延要求、时间 / 空间可转移性）等以及算力任务未来的能耗预测，可以实现对算力任务迁移能力的量化评估。 当极端天气发生时，算电系统会根据算力任务的运行状态，基于算力任务的重要性和耗能情况，制定算力任务的迁移策略。最后，将高耗能、重要程度或实时性要求高的任务暂时迁移到电力供应稳定的区域，以提升数据中心的容灾能力。
在整个过程中，最重要的就是需要对数据中心当前运行的任务和每个任务未来的能耗做到精准的感知。
然而，在实际实施时，数据中心往往涉及到多个主体。这使得在数据中心进行任务追踪和能耗感知变得十分困难，主要表现在以下几个方面：
- 算力运营商通常只关注整体 PUE、总功耗等宏观指标，缺乏对单个算力任务细粒度运行状态感知的动机。
- 多算力用户、运营商、基础设施提供商等多方主体并存，权责和数据边界复杂。算力感知、能耗采集、电力调度等系统相互独立，数据不通、调度分离，很难从全局把控和谋划。
- 即使是自建数据中心，传统任务追踪手段也难实施。传统的感知方式（比如硬件插桩、业务埋点）需要深入用户业务或基础设施层，会面临权限、安全的限制，很难推进。
因此，如何在电网的数据中心中能够实现分布式算力任务的追踪和能耗感知呢？ 于是我们就发现了 DeepFlow。
03｜基于 DeepFlow 的任务追踪与能耗分析
DeepFlow 是云杉网络开发的一款可观测性产品，旨在为复杂的云基础设施及云原生应用提供深度可观测性。DeepFlow 基于 eBPF 实现了应用性能指标、分布式追踪、持续性能剖析等观测信号的零侵扰采集，并结合智能标签技术实现了所有观测信号的全栈关联和高效存取。使用 DeepFlow 作为底座可以方便的实现对计算任务运行状态的追踪。其优势在于3个任意。
第一个是任意 Service 的全景图。不管是 K8s Pod、KVM Host，还是 Kong 网关、CoreDNS，DeepFlow 能穿透从用户到底层硬件的所有层级，自动绘制服务间的调用关系和时延分布 —— 比如图中能清晰看到每个 Service 的响应时间（1ms、5ms、50ms），不用手动埋点，就能快速掌握整个集群的服务架构。
第二个是任意 Request 的分布式追踪。从用户发起的 nginx 请求，到 Spring Gateway、Envoy、后端 Java/Go 服务，再到 Redis、MySQL，每一次请求的全链路耗时、调用路径，甚至网卡层面的数据包流转，DeepFlow 都能通过 eBPF 技术零侵入捕获 —— 这对定位算力任务的性能瓶颈至关重要。
第三个是任意 Function 的持续性能剖析。小到 CPU、GPU 的计算过程，大到 Java/Python 的 Runtime 函数、CUDA 函数，DeepFlow 能深入到代码和硬件指令层面，分析每个函数的资源占用情况 —— 比如 GPU Memory 的使用、TCP 网络的耗时，这为后续关联 “算力消耗” 和 “能耗” 打下了基础。
此外，DeepFlow 还能无缝集成 Prometheus、Grafana 等主流可观测性技术栈，不用重构现有系统，就能快速接入，降低了改造门槛。
图中展示的是基于 DeepFlow 的算电协同感知框架。 一个算力服务可以抽象为 Gateway，调度服务，计算服务，数据服务几个部分。
当创建任务的请求连接到Gateway后，Gateway会负载到后端的调度服务进行处理。 选取合适的计算节点，并告诉计算节点数据服务的地址。之后协调各个计算节点进行数据访问，并在调度服务的领导下实现模型的分布式训练。
所以我们只需要在每个服务的pod中部署普罗米修斯，和 DeepFlow agent 就可以实现对整个业务各个组件的分布式追踪。
那么如何能够让 DeepFlow 采集算电数据并做能耗预测？核心分二步：第一步是算电数据采集。第二步是能耗预测模型嵌入。
基于 DeepFlow 丰富的扩展能力，我们通过改造 Promethes 实现计算任务运行状态和能耗的感知。
针对不同层级的数据需求，我们在两个层面部署 Exporter—— 在每个模型训练 Pod 里，部署 “自定义 Exporter”，它会对外暴露 /metrics 接口，专门输出任务级指标，比如模型训练的 Epoch 进度、实时能耗、任务处理时延；同时在每个 Node 节点上，用常规的 node-exporter 采集节点级硬指标，像 CPU 利用率、内存占用、这些系统数据。
通过配置 ServiceMonitor，让 Prometheus 能自动识别所有 Exporter，定期拉取指标，把任务运行数据和能耗数据统一归集到 Prometheus。
Prometheus 里配置 remote_write 规则，指定 DeepFlow Agent 的接收地址，这样归并后的所有数据会实时推给 Agent 并最终发送至 sercer 端进行关联分析。
具体而言，第一步是配置自定义 Exporter，让 Prometheus 能找到它：先给自定义 Exporter 创建配套的 Service 和 ServiceMonitor——Service 要打上明确标签（比如 “app:carbon-exporter”），方便后续匹配；ServiceMonitor 则通过 selector 精准对接这个标签，同时指定抓取的端口（比如 8000）、路径（/metrics）和间隔（30 秒），这样 Prometheus 就能精准拉取 Pod 内的任务指标。
第二步是配置 remote_write，把数据推给 DeepFlow Agent：在 Prometheus 配置文件里，明确 remote_write 的地址（比如
http://172.31.15.216:38086/api/v1/prometheus），设置资源参数（比如请求 400Mi 内存），并开启 “自动选择所有 ServiceMonitor” 的功能，确保所有采集到的指标（任务 + 节点）都能稳定推给 Agent。
数据到 Agent 后，它会用 eBPF 技术自动给数据补全上下文标签 —— 比如 Pod 名称、节点 IP、命名空间，让数据带上 “身份信息”；之后再把增强后的数据传给 DeepFlow Server 存储，最终我们在 Grafana 里就能查询这些带完整标签的数据，做任务能耗和节点资源的多维度关联分析。
有了前面采集到的任务运行与能耗数据后，我们接下来嵌入能耗预测模型，核心思路是 “用简单线性模型实现高效预测，靠实时迭代保证精度”。
首先，确定模型与核心变量：我们选择线性回归模型，因为它轻量、计算高效，很适合实时预测。模型的核心输入有两个 —— 一是计算任务已产生的能耗（作为系数基础），二是任务训练轮数（作为变量），通过 “已用能耗 + 轮数” 的线性关系，就能推算未来能耗。
然后，通过实时迭代更新模型系数：模型不是固定不变的 —— 在计算任务运行过程中，会不断用新产生的能耗数据（比如每完成 2轮 训练就更新 1 次）调整系数，避免因任务负载波动（如 GPU 利用率变化）导致预测偏差，始终保持模型准确性。
这个模型最大的优势是 “不用等大量实测数据”—— 哪怕只完成 5 轮训练，有了前 5 轮的能耗数据，就能启动模型预测未来长周期的能耗，不用等到任务跑一半甚至结束，大大提前了调度决策的时间窗口。
从实际实验结果来看，这个线性回归模型的预测精度完全能满足算电协同调度的需求。我们尝试了两种场景；
第一个是短周期预测精度：如果用前 5 轮的实测能耗数据做训练，去预测未来 50 轮的能耗，误差能控制在 0.6% 以内。
第二个是长周期预测精度：如果用前 5 轮的数据预测未来 100 轮的能耗，误差也能稳定在 6% 以内 。
04｜总结与展望
目前，团队正致力于基于 DeepFlow 构建一套 “零侵入的算力——能耗一体化可观测体系”，当前已经完成了初步的原型系统。
未来我们计划从2个方向深化探索：
- 扩展至多云 / 异构算力中心：目前我们主要在单一集群验证，接下来会将方案推广到公有云、私有云混合部署的场景，同时适配 x86、ARM、GPU/TPU 等异构算力，覆盖更广泛的应用场景；
- 结合 LLM 进行智能调度与根因分析：后续会引入大语言模型，一方面让调度系统能自动理解电网信号、算力需求，生成最优调度策略；另一方面，当出现能耗异常时，能基于 DeepFlow 的全链路数据，自动定位根因（比如是 GPU 频率过高，还是制冷系统低效）。
PPT下载地址
©著作权归作者所有，如需转载，请注明出处，否则将追究法律责任
赞
收藏
回复
相关推荐
