人工智能的尽头是算力，算力的尽头是电力。

2026年，“算电协同”首次写入政府工作报告，并被纳入“十五五”规划的重点部署。国家发改委、国家能源局、工信部、国家数据局四部门随后联合发文，推动人工智能与能源体系双向融合。算电协同，正式从行业探索升级为国家战略。伴随多部门政策持续落地，算电协同从产业讨论中的热词，真正变成了国家层面的基础工程。

同年5月，在宁夏中卫的戈壁滩上，全国首个大规模算电协同绿电直供项目正式投运。50万千瓦光伏电站发出的电，不再经由复杂的公共网络迂回输送，而是通过4条专用线路，直接送进云基地数据中心。这里消耗的每一度电，都可以追溯其绿色来源。待150万千瓦风电项目建成后，中卫将进一步打通从发电侧到机柜侧的全链路绿电直连，成为全国具有标志意义的算力枢纽样板。

算力和电力，这两张长期平行运行的网络，终于开始交织。

但交织不等于协同，物理上的连通解决不了数据层面的割裂。发电侧的出力数据、电网侧的负荷状态、储能侧的充放电曲线，以及算力侧的功耗与任务队列，分属不同系统，格式不同、协议不同、采集频率也从毫秒级到分钟级不等。算电协同之所以长期难以落地，问题往往不在于电力或算力本身不足，而在于这四端数据之间缺少一套可以实时连接、统一计算的底座。

数据连不上，协同就无从谈起。而打通电力侧与算力侧之间这条实时、统一、可计算的数据链路，正是 DolphinDB 作为工业数据底座的核心价值所在。本文将从数据接入、实时计算、存储、事件处理、预测建模和边云协同六个维度，拆解算电协同的关键堵点，以及 DolphinDB 的应对路径。

数据接入：打通两侧的第一步

电力侧和算力侧的数据，长期生长在两条平行线上。

电力侧的数据主要来自 SCADA 系统、智能电表、PMU（同步相量测量单元）、气象预报系统，以及分布在发电厂和变电站中的各类现场设备。这类数据通常运行在工业自动化体系内，使用 IEC 规约、OPC UA 等工业通信协议，采集频率高、测点数量大，在大型场景中点位规模可达到百万级。

算力侧的数据则来自服务器功耗监控、GPU 利用率、任务队列深度、机房总功耗及 PUE 相关指标等运行数据，通常由 Prometheus 等监控系统采集，并通过 Kafka 等消息系统进行分发。这一侧更偏 IT 系统，数据结构、通信方式和更新节奏都与电力侧显著不同。

要把两套数据汇聚到一起做联合分析，首先要解决的不是算法，而是接入层的统一。只有把原本分散在工业现场和数据中心里的异构数据接进同一平台，后续的实时计算、联动分析和协同调度才有可能成立。

DolphinDB 在这一层提供了较为全面的数据接入能力：在消息系统层面，可对接 Kafka、MQTT、RabbitMQ、RocketMQ、Pulsar 等主流组件；在工业协议层面，支持 OPC UA、OPC 等现场设备数据接入；在应用接口层面，则提供 Python、Java、C++ 以及 REST 等主流开发接口，便于算力侧监控系统和业务平台写入数据。

接入层的覆盖面，决定了协同的边界。数据进不来，后面的分析、建模和调度就无从谈起。

实时计算：从感知走向响应

数据汇聚进来之后，面临的第二个问题是速度，也就是实时性的需求。

算电协同的调度决策有严格的时效要求。电价信号变化了，算力负载要不要响应？某个节点功耗异常拉升，是触发告警，还是动态迁移任务？这类判断的窗口往往是秒级，部分高实时性场景甚至要求更低延迟。如果仍然依赖传统批处理链路，等数据汇总、计算完成后再做决策，往往已经错过最佳响应时机。

DolphinDB 提供完整的流批一体计算框架，内置多种流计算引擎，覆盖时序聚合、状态计算、会话窗口、异常检测、实时关联等各类场景。流数据进入系统后，可以在实时链路中直接完成接收、计算与结果输出，减少中间落盘和重复读取带来的额外延迟。

在可靠性方面，DolphinDB 为流计算提供了故障恢复与高可用能力，支持在节点故障或异常情况下自动恢复，保障计算任务的连续性。这意味着在电价波动、负荷变化、设备异常等需要实时响应的场景下，系统即使出现短时故障，也能尽快恢复处理，降低对调度决策和运行响应的影响。

实时计算能力，是算电协同从“感知”走向“响应”的关键一步。

多模存储：承接异构数据

算电协同的数据形态，远比“时序数据”这四个字更复杂。

一方面，电力侧天然会产生大量高频时序数据。一个省级电网的测点数量可以达到亿级，振动监测的采样频率可达 50KHz 甚至更高，数据一旦积累起来，保存周期往往还是按年计算。另一方面，算力侧虽然不一定都是高频采样数据，但数据维度更多，也更强调聚合分析、多维查询，以及和业务状态、资源调度之间的关联。

这就带来一个很现实的问题：不同类型的数据，写入方式不一样，查询方式不一样，适合的存储组织方式也不一样。想靠单一引擎把所有问题都解决，往往并不现实。

DolphinDB 的思路是，用多模存储架构来应对这种复杂性：不同数据形态，使用更适合它的存储引擎。

比如，在电力物联网场景下，IOTDB 引擎更适合承载亿级测点和高频采样数据；TSDB 引擎可作为通用时序数据的存储与分析底座，支持明细查询、历史曲线分析和时间范围统计；OLAP 引擎则更适合面向汇总后的分析型数据开展多维统计和专题分析。除此之外，DolphinDB 还提供向量、文本、特征、内存 OLTP 和 PKEY 等引擎，用来支持 RAG、AI 特征存储、低延迟事务处理，以及外部主键表同步适配和增量更新等需求。

换句话说，无论是电力侧的高频振动波形、智能电表的秒级采集数据，还是算力侧的指标结果、业务状态和 AI 特征，都可以在同一个系统里，按更合适的方式存储下来。

而当这些不同形态的数据被统一放进同一个系统后，价值不只体现在“省掉几套系统”。更重要的是，数据流转链路更短了，跨类型分析更自然了，电力侧和算力侧的数据也更容易做时间对齐、关联分析和联合计算。

复杂事件处理：让联动在实时流上发生

算电协同，难的不是调度，而是“什么时候触发调度”。

表面看，算电协同似乎就是“电便宜的时候多算一点，电贵的时候少算一点”。但真正落地时会发现，调度动作很少由单一条件决定，更多时候要看多个条件是否同时成立。

例如，只有当实时电价已经处在高位、当前算力利用率还有余量、同时未来两小时风电预测出力又比较充裕时，系统才适合把一部分可迁移的计算任务调整到更低成本的时段执行。

这件事听起来像“配个规则”就行，做起来却没那么简单。因为这些条件通常来自不同系统：电价在交易侧，算力负载在资源调度侧，新能源预测又在气象或电力系统侧。更麻烦的是，它们往往还带有时间关系——有的看实时值，有的看未来预测，有的要求连续满足一段时间。如果把这些逻辑都写在下游应用里，往往意味着不断拉数据、拼条件、改接口、发版本。规则一多，系统就容易变得又长又重。

这类问题，本质上是复杂事件的实时识别问题。DolphinDB 的 CEP（复杂事件处理）能力，可以把电价、算力负载、风电预测等多路数据放到同一个实时处理平面上，直接定义“什么条件组合成立、成立后触发什么动作”。这样一来，系统不需要等数据绕一圈到了下游再判断，而是可以在数据流动的过程中就完成识别和触发。

复杂事件处理引擎（CEP）架构图

在电力行业里，这类能力已经被用于振动异常录波、设备故障预警等实时场景。放到算电协同里，它解决的也是同一个问题：不是等结果出来再响应，而是在事件发生的当下就做出决策。说到底，算电协同要想真正做到实时响应，关键不是规则写得多复杂，而是要让规则能够直接跑在实时数据流上。

预测建模：让调度从被动走向主动

实时响应解决的是“事情已经发生了，系统怎么尽快动作”；但算电协同真正的价值，往往在于“事情还没发生，系统就已经开始准备”。不管是负荷预测、新能源出力预测，还是电价预测，本质上都在回答同一个问题：未来一段时间里，电和算该怎么提前排布，才能把成本压低、把资源用好。这也是很多中游调度系统最核心的能力之一。

但预测这件事，难的往往不是“有没有模型”，而是数据链路太长。传统做法通常是把数据从业务库导出去，在外部平台做特征处理、模型训练和预测，再把结果导回调度系统使用。数据来回搬运，不仅延迟高，还很容易在加工过程中出现口径不一致，最后影响模型效果和调度可信度。

DolphinDB 的优势在于，它把数据处理、建模和推理尽可能放在同一套环境里完成。内置机器学习函数可覆盖常见时序分析和回归建模需求，支持分布式训练；对于更复杂的场景，也可以通过 LibTorch、XGBoost、LightGBM 等插件接入主流模型能力。对于需要对接外部 AI 训练框架的场景，也可以通过 AI DataLoader 等方式，将 DolphinDB 中的数据转换为训练流程可直接使用的 Tensor 形式，接入 Torch、TensorFlow 等框架。

这样一来，模型可以尽量贴近数据运行，而不必让数据在不同系统之间反复流转。对于算电协同来说，这一点很重要：电力时序数据规模大、更新快，如果每次训练和推理都要先“导数据”，预测链路就会被拉长，系统也更难兼顾速度、稳定性和可维护性。对算电协同而言，预测能力比拼的，不只是模型本身，更取决于数据准备、计算执行与结果落地能否形成一条更短、更顺畅的闭环链路。

边云协同：让数据在更合适的位置计算

算电协同有一个物理上的现实：设备是分散的，数据也是分散的。

发电设备在西部，算力中心可能在东部，配电设备遍布全国，储能站星罗棋布。如果把所有数据都传到云端再处理，带宽是第一道墙，延迟是第二道墙。一个采样频率 50KHz 的振动传感器，全量上传一秒钟的数据量就足以打满普通工控机的网络带宽。

DolphinDB 的边云协同架构，正是针对这种物理分布式场景设计的。它可以轻量化地部署在 ARM 工控机等资源受限的边缘设备上，让传感器数据在边端直接进入流数据表，完成实时降采样、异常录波和指标计算，再将关键结果定时通过 RPC 机制同步到云端。这样一来，原始数据尽量在本地处理，云端更多接收摘要和结果，带宽压力更小，响应链路也更短。

DolphinDB 云边协调架构

这套架构在电力行业已经有真实落地。某电力监测设备生产商将 DolphinDB 内置于主变振动监测设备，在边端 ARM 工控机上直接处理 8KHz 至 50KHz 的高频振动数据，通过流计算引擎实时完成波形录制和故障预警，实现毫秒级异常响应；处理后的关键数据再同步到云端，用于历史分析和全局监控。边端负责实时处理，云端负责统一分析。对于算电协同这类强物理分布、强实时约束的场景来说，这往往是更符合现实的一种架构方式。

总结：算电协同需要一套统一底座

算电协同的关键，不在于电力侧和算力侧各自是否拥有成熟系统，而在于两者之间能否建立起连续、低延迟、可联动的数据协同能力。

如果只是各自监控、各自分析，两套系统当然都可以运转；但一旦要做协同，问题就会集中暴露出来。电力侧的数据是高频时序，算力侧的数据更多是资源、负载和运行状态指标，二者只有放到同一时间框架下，联合分析才有意义。若数据分散在不同系统中，跨系统查询首先要面对的就是时间对齐问题；而一旦涉及告警联动、组合条件触发和联合建模，还会引入额外的数据搬运、链路延迟和系统复杂度。

这正是一套统一底座的价值所在。DolphinDB 作为统一的数据汇聚与分析层，并不是要替换算力侧已有的监控系统，而是通过 Kafka、API 等方式，把电力侧和算力侧的数据接入同一个时序计算环境。在这套环境里，两类数据可以按照统一的时间口径处理，CEP 引擎可以直接基于跨域数据做事件触发，预测模型也可以同时消费电力历史数据和算力负载数据，协同所需的数据基础才能真正建立起来。

说到底，算电协同最大的成本，很多时候不在“算”本身，而在电和算之间那道看不见的数据接缝。一套底座的意义，不是让所有系统变成一个系统，而是尽量让这道接缝变短、变平，让协同真正发生在同一条数据链路上。

展望：从数据底座到 AI 底座

如果说前面讨论的重点，是如何把电力侧和算力侧的数据接进来、算起来、联动起来；那么再往前看，算电协同对底座的要求，已经不会停留在“存得下、算得快”这一层。随着“源网荷储算”逐步走向更紧密的联动，底座能力也必须继续往上走：不仅要支撑实时感知和高效分析，还要进一步承接知识组织、模型迭代和智能决策。

DolphinDB 也在沿着这一路径延伸能力边界。在数据层面，多模存储已经覆盖向量数据库和文本数据库，为知识检索与 RAG 应用提供基础；在模型层面，特征引擎与模型推理能力可以支撑预测模型的持续训练和迭代；在应用层面，DolphinX 平台支持 MCP 和 Agent 的开发与管理，为算电协同场景中的智能调度 Agent 提供开发底座，面向电力与工业物联网的专用 Agent 也在持续规划中。

DolphinDB AI 产品线全景图

回到文章开头那句话——"人工智能的尽头是算力，算力的尽头是电力。"这描述的是一个能源问题。但让算力和电力真正协同起来的，是数据——数据流动的速度决定协同响应的速度，数据理解的深度决定调度决策的质量。从打通数据链路，到支撑智能决策，算电协同真正的竞争力，最终都会沉淀在数据底座的深度上。

这也是 DolphinDB 一直在做的事——让数据流动得更快、计算得更准、决策得更智能，让算力和电力的协同，不止于物理连通，更发生在每一条实时数据链路上。