出品/星动无极
10月30日，北京太空算力创新中心在"天算纪元·太空算力主题日"活动上发布天地一体化太空算力云平台。按发布方的说法，这是全球首个把在轨算力与地面算力统一纳管的平台：已完成核心功能建设，覆盖40余颗卫星的算力资源，与CPU、GPU、NPU等地面算力实现统一纳管和池化调度，支持大模型推理业务的天地一体化协同调度。
平台打通的是四段流程：星地算力资源汇聚、模型上传与发布、在轨推理、结果回传。这四段听起来像常规的云计算描述，放到天上就变了一件事——在轨算力不是随时可用的。卫星要过境才能与地面站建立链路，一次过境的窗口通常只有几分钟到十几分钟，模型上传、任务下发、结果回传都要挤在这个窗口里完成。平台要做的，是把"什么时候有算力可用"变成可以提前编排的资源表。
技术上的难点集中在三处。第一是异构纳管，在轨算力来自不同厂商、不同代际的星载计算单元，指令集、功耗预算、散热能力都不一样，要抽象成统一接口才能被调度。第二是任务编排，地面云可以假设网络常连，天上不行，任务必须在卫星可见窗口内切分、排队、重试。第三是结果一致性，同一模型在星上跑出来的结果与地面跑出来的结果如果有偏差，业务方就无法把在轨推理当成可信计算。
40余颗卫星是一个起点规模。按国内目前在轨的算力卫星数量，这个数字基本覆盖了已有的试验星和首批业务星。北京太空算力创新中心此前已吸纳首批入驻企业，其中包含完成13颗卫星在轨交付的研制方。把在轨资源集中到一个平台调度，实际效果是把分散在各家企业手里的算力变成可计量的公共资源，也让后续接入的卫星不必各自建一套地面调度系统。
这件事的商业含义要看谁付费。目前能想到的付费方有三类：需要低时延响应的遥感应用方，希望在数据下传前就拿到识别结果；需要广域覆盖的物联网与应急通信方，用星上处理减少回传量；以及做在轨技术验证的载荷研制方，按算力时长租用。三类需求的共同点是单笔金额不大，但调用频次高，这正好是云平台适合承接的业务形态。三类里最先跑出规模的，大概率是遥感初筛——它的数据量最大，回传成本最高，星上处理省下的带宽可以直接折算成钱。
与地面算力相比，太空算力的成本结构完全不同。地面数据中心的电费和散热是主要支出，太空里太阳能供电不受昼夜和天气影响，低温环境也省掉了大量制冷设备；代价是发射成本、辐射防护和器件等级。平台把在轨算力池化，等于把这个成本结构摊到多个用户身上，单个用户不必自己发一颗算力星。
时延特征也不一样。地面云到用户的往返时延通常在几十毫秒量级，在轨算力要等卫星过境才能把结果传下来，单次等待可能长达数十分钟。这意味着在轨算力更适合那些不需要即时响应的任务：大范围遥感影像的初筛、海洋目标的持续跟踪、偏远地区的数据预处理。对需要秒级响应的业务，在轨算力替代不了地面。
平台要解决的一个现实问题是计量。地面云的算力按核时、卡时计费，在轨算力的"可用时长"取决于轨道、过境窗口和太阳照射角，同一颗星在不同时间的可调度时长不同。要把在轨算力做成可售卖的资源，必须先建一套按窗口、按功耗、按任务类型折算的计量规则，这套规则目前还没有行业标准。
同一时间轴上还有两个参照。马斯克10月31日在社交平台发文，预言2029年部署到近地轨道的AI与云计算处理能力将远超地面算力，2028年轨道算力的每月新增部署量就会超过地面。谷歌10月30日宣布Project Suncatcher原型卫星在轨跑通首个AI回复。一个在讲规模，一个在做单点验证，北京这个平台选择的是第三条路：先把存量在轨算力组织起来，做成可调度的服务。
三条路都有各自的难点。讲规模的受制于发射运力和星上功耗，单点验证离商业化还有距离，做平台调度的难点在于没有足够多的在轨算力可调。40余颗卫星对应的算力总量，与地面一个中型智算中心相比仍小几个数量级，平台当前的价值更多在于把流程跑通、把接口定下来。
判断这类平台进展的指标不在发布会的表述里，而在两个数字上：一是在轨算力资源的实际调用时长，二是接入平台的第三方模型数量。调用时长说明有没有人真在用，模型数量说明接口是不是足够通用。这两项数据目前都未披露。对做载荷研制的单位，平台还有一层价值：它把在轨算力的接口和计量规则提前定义出来，后续型号设计时可以按这套接口预留算力模块，减少入轨后的适配成本。
平台方在发布材料中没有给出调用计费的具体标准，这部分规则要等首批用户接入后才会明确。对卫星运营商，把算力挂上平台意味着多一条变现渠道，也意味着要接受统一的接口约束，两边怎么平衡，看首批接入的运营商怎么谈。