轨道计算需要一把衡量“按时交付工作”的尺子

2026年10月30日，Google公布Suncatcher在轨原型首次返回AI响应。卫星于10月1日发射；响应发生在公告当周，未披露具体日期。Google公告

跟着一项任务，直到结果回来

Open Market Notes分析。 轨道计算接下来值得讨论的问题，是如何定义一项工作已经完成。以下提出评估框架，不是对Google实际系统的描述，也不代表其商业性能已经得到证明。

用户经历的是一条完整链路：提交输入、等待接收、执行计算、传回输出，再判断输出是否合格。只给处理器计时，会把这条链路的相当一部分排除在测量之外。技术上正确的结果，也可能在相关决策结束之后才到达。反过来，一项明天才需要完成的归档任务，可能完全能够接受较长等待。什么算有用容量，取决于服务承诺了什么。

因此，较实用的比较单位，是在明确截止时间内交付、并达到约定质量门槛的合格结果。分母应包含所有已经接收的独立任务，包括过期、失败或需要重试的任务；执行尝试次数另行统计。否则，只展示成功返回的案例，就能让表面成功率变得好看。被拒绝的请求也应单独披露：控制接入量可以保护可靠性，却同时减少真正得到服务的需求。

这样的定义并非要求研究实验立即达到生产服务标准，而是让前后实验能够比较。一条成功路径回答一个较窄的问题；重复执行、并公开等待时间的任务，可以回答更宽的问题。两种观察都不应被悄悄升级为持续可用的证据。

把等待写进任务设计

NASA对延迟容忍网络的解释是：链路中断时先保存数据，待具备条件后再转发。这是一般通信背景，并不能证明Suncatcher选用了该协议。NASA说明

我们的推论是，应用的截止时间应与计算任务一起设计。设想两类客户：一类希望在夜间完成一批固定资料的分类；另一类必须在立即采取行动之前获得答案。即使模型执行时间相同，两者得到的服务也不等价。前者可能接受排队和约定时间取回结果，后者则可能需要在轨道结果返回之前启用地面备选方案。这个假设例子不包含任何性能或时延预测。

数据来自哪里、有多大，也会改变比较方式。如果输入首先需要上传，传输就是用户购买的服务的一部分。如果数据已经位于处理器附近，问题就可能变成：返回筛选后的发现，还是把底层数据传回地面处理。这里讨论的是有条件的设计选择，并未断言哪条路径更便宜，也不声称某个任务已经采用它。

减少传输字节还可能带来验证负担。简短答案只有在接收者能够判断其是否适合任务时才有价值。因此，试验可以保留输入样本，记录模型及软件版本，并将部分输出与事先约定的参照结果比较。这些是我们建议的控制措施，不应被写成该项目已经展示的功能。

恢复过程需要记账，同一任务不要算两遍

重试应有单独的记录。输出迟迟未到，客户可能再次提交，也可能把工作转移到其他地方。两次执行都消耗资源，但客户仍然只是在解决同一个问题。有用的报告应区分独立的合格结果与执行尝试次数，并说明何时丢弃了迟到的重复结果。

备选路径也有两面性。它能改善客户体验，同时可能遮住轨道路径本身的限制。这并不意味着不该使用备选方案，而是应分别报告组合服务表现和轨道部分的贡献。否则，地面系统可能承担了可靠性承诺，太空系统却获得了全部性能功劳。

公平的地面对照，应使用相同输入、质量要求、截止时间和统计边界，两侧都计入等待与恢复。把轨道加速器的执行时段与完整的地面流程比较，或反过来选择边界，都会制造醒目却难以使用的数字。成本及能源比较还需要公开系统边界；本文不进行这两项计算。

下一份结果怎样才更有信息量

一个规模不大、说明清楚的工作负载，可能比规模更大却不公开分母的演示更能帮助判断。报告接收了多少任务、多少按时到达、最老的未完成任务等待了多久，以及中断以后怎样处理；同时披露完成时间的分布，而不是只给出有利的平均值。读者才有机会判断，这种等待对于某个具体应用是否足够可预测。

不同解释都需要保留空间。有些任务可能容忍很长等待；另一些任务需要的连续性，可能无法由这种架构经济地提供。早期实验无法一次解决这些差异。没有公开服务等级记录，也不能反过来被当作失败证据。更有建设性的标准是：每次新测试，都让人更容易辨认哪些工作能可靠地交付有用结果，并把剩余的不确定性摆在明处。