人工智能的尽头是算力算力的尽头是电力。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 一直在做的事——让数据流动得更快、计算得更准、决策得更智能让算力和电力的协同不止于物理连通更发生在每一条实时数据链路上。