太空上跑推理，第一道约束不是算力而是窗口｜洹拓科技
一、四个约束分别压在哪一层
据公开报道，一家云厂商与卫星公司联合研制的原型星已经入轨，星上搭载四颗数据中心级加速芯片与约一千瓦的供电能力；受系统供电限制，一次只能启动其中一颗，单次运行约二十分钟；模型权重预先部署在星上，地面通过地面站发出提示词，返回结果要等卫星飞经某处高纬度地面站上空时才被收到。团队把这一步称为该计划的第一次可运行验证，后续实验逐步转向更实际的系统测试，观察加速芯片在轨道热应力与辐射环境下的表现。同一批消息里也给出了动机：太空光伏的发电潜力与接近持续的日照，用来缓解地面数据中心的能源与散热约束。这些数字是报道给出的口径，不是本篇的判断依据；本篇关心的是另一件事，四个约束各自压在执行链的哪一层。
四个约束不在同一层，混在一起读就会得出算力不够的错误结论：供电配额压住可并发度，单次运行时长压住任务粒度，可见窗口压住结果可得时刻与端到端延迟，热应力与辐射尚未验证则压住错误率与寿命。最后一层最容易漏，因为它让前三条的结论都没有基线可对照。
| 约束 | 它压住的是哪一项 | 地面机房里对应的默认假设 | 窗口型算力下要改成的做法 |
|---|---|---|---|
| 一次只允许启动一颗加速芯片 | 可并发度 | 一个任务可拆成多副本同时跑 | 编排按一颗芯片一个作业排队，多副本只用于验证不用于提速 |
| 单次运行约二十分钟 | 任务粒度 | 作业可一直跑到自然结束 | 作业必须自包含，且能在配额内完成收尾 |
| 结果只在飞经地面站上空时回传 | 结果可得时刻与端到端延迟 | 请求返回就等于结果可得 | 提交与可得分列两个事件，中间按可用窗口排程 |
| 热应力与辐射表现待验证 | 错误率与寿命未知 | 硬件故障率有历史基线可用 | 按未知错误率设计验收，不引用历史基线 |
把这四行合起来看，地面机房抽象的四条默认假设，即可分配、可持续、随时可达、可现场处置，在这里一条都不成立，四条分别被供电配额、单次时长上限、可见窗口与不可到场处置否掉。结论不是把机房搬远了一点，而是任务编排的基本单位要换掉，从实例换成窗口。实例回答的是我拿到多少算力，窗口回答的是我在哪一段时间里能做事、做完的什么时候能被看见。
二、任务粒度按窗口重算
单位换掉以后，第一件事是重算一次执行的内容。窗口型算力上的一次执行必须自包含，也就是在这一段可运行时长里把该做的收尾全部做完，因为一旦超出配额，剩下的不只是没算完的部分，还有没落盘、没压缩、没排进下行的部分。据此把一次执行的时长预算拆成三段。
- 可运行时长：由供电配额给出的上限，是外部约束，不参与讨价还价。
- 可用于计算时长：从可运行时长里减掉加载权重与自检、结果落盘与压缩、排队等待下行这三段之后剩下的部分，这才是真正能推进任务量的额度。
- 需要预留的收尾时长：落盘、压缩、校验写入完整性以及把结果推到待发区所需的时长，这一段要按上限而不是按平均预留，因为它恰好在供电耗尽的那一刻发生。
三段预算定下来，超窗未完的处置才有依据。可选的只有两种，而且必须在提交前选定。第一种是截断续跑，把作业切成可在窗口内完成的段，每段结束时落一份可续跑的中间状态，下一段从该状态接着算；代价是引入分段之间的状态一致性检查，中间状态本身也要占用落盘与下行的额度。第二种是整批作废重排，一个窗口做不完就整个作业退回待排窗，等下一个更长或者更空的窗口重跑；代价是重复消耗算力，但结论干净，不会留下无法解释的半成品。判定用哪一种，看的是作业能否分段：有确定中间状态、重跑不产生副作用的，用截断续跑；输出是一次性整体、中间状态不可信或者重跑会改变外部世界的，用整批作废重排。在错误率未知的执行环境里，宁可多作废几次，也不要把来历不明的中间状态当结论。
三、端到端延迟的主语是轨道几何
在地面，端到端延迟的主语是网络往返，所以一个超时值就能概括。窗口型算力上不是。这里有三个时刻，各自由不同的东西决定：提交时刻由地面站的注入安排与链路可用性决定，提示词要能被送上星；开始执行时刻由排窗结果与供电配额决定，前面的作业没让出配额就轮不到；结果可得时刻由卫星飞经地面站的可见窗口决定，与前面两个时刻之间没有稳定的间隔可言。三段各自有独立的等待源，用一个请求超时来概括它们，得到的数字既不能用于重试也不能用于告警，因为超时的语义本来假设对端一直在听。
按窗口组织之后，作业的状态机也要重写。五个状态与各自的可观测证据如下。
| 状态 | 含义 | 可观测证据 |
|---|---|---|
| 待排窗 | 已提交，尚未分配到某段可运行时长 | 排程记录里有该作业，且没有注入确认 |
| 已注入 | 指令与参数已上星，等待轮到配额 | 地面站注入回执，星侧作业队列可见该标识 |
| 执行中 | 占用配额正在运行 | 星侧自检记录持续追加，逐次落盘有条目 |
| 待下行 | 已算完并落盘，等待可见窗口 | 结果文件校验通过，处于待发区 |
| 已收 | 结果已在地面可读 | 地面站收到记录与内容哈希一致 |
状态机的价值在于每一步等待都能被归因。等待发生在待排窗是供给问题，在待下行是几何问题，在执行中超时才是任务粒度问题。把这三种等待混成一个延迟指标，就再也分不出该找谁。重试的判定同样要按状态来：注入未确认可重发，执行中中断按第二节的两种处置处理，已收之后不能因为读得慢而重复提交。
四、错误率未知时的验收
据公开报道，后续实验要观察的正是加速芯片在轨道热应力与辐射环境下的表现，也就是说错误率与寿命这两件事还没有结论。没有结论不等于只能等，它改变的是验收设计：不得把跑通一次当作可用性证明。一次成功的运行只能证明这条链路在某个窗口里成立，不能证明第二次也成立，更不能说明失败模式是什么。
替代做法是三件事。其一是固定一个最小可复现集，选取一组输入与期望输出，长度、结构与计算量都要可控，让每次运行都落在同一把尺子上比对；这套集合本身也要预先部署在星上，而不是每次由地面重发。其二是逐次落盘的自检记录，每次执行都写入运行标识、占用配额的时长、加载与计算与收尾各段耗时、中间状态摘要与输出的校验值，并且这些记录按待下行的优先级排在业务结果之前：业务结果没了可以重跑，自检记录没了这一轮就无从解释。其三是把两条判据分开写清楚，不要合成一个通过率。
- 内容正确性判据：同一输入的输出与期望或历史基线的比对结果，回答这次算得对不对。
- 环境退化判据：自检记录里各段耗时、加载时长与校验值的漂移趋势，回答执行环境是不是在变坏。
两条判据分开，才有办法处理这种局面：内容依旧正确，但加载时长持续变长，或者收尾阶段的校验失败率上升。这属于环境退化的信号，不该被内容正确掩盖；反过来只看环境指标，又会把一次真实的推理错误解释成偶发。分开之后，退化速率与错误速率各自成为可汇报的量。
五、统一纳管与池化调度要降级成三个问题
同一批消息里还有几类供给侧的说法，本篇把它们当作客户提问来处理。一是路线差异：一家厂商在多星之间配置高速链路，让一组卫星协同处理同一任务，另一类方案是单颗卫星独立运行；二是此前已有其他公司把一类图形加速卡送上轨道，完成大语言模型运行与小规模训练实验；三是国内团队发布天地一体化算力平台，据公开报道宣称覆盖四十余颗卫星的算力资源，与地面处理器统一纳管、池化调度，这个数量是报道口径，不是本篇的判断依据。
这类词在方案汇报里出现得很多，落到工程上必须降级成三个可问出来的问题。纳管的对象是什么，是可调度的算力与配额，还是只能收到数据回传与心跳；只能收到回传的叫可见，不叫纳管。调度能否指定窗口，即能否把一个作业明确排进某段可运行时长，并按窗口给出预计可得时刻；只能决定有空就安排的是队列，不是调度。计量按什么单位，按芯片时长、按窗口、按作业还是按下行字节；计量单位决定了账单与容量规划能不能对齐，也决定了第二节的三段预算是否有第三方可核对的数据。这三件事问不出来，它在交付意义上仍是一个项目而不是能力，因为我们对它做任何承诺都缺少可验证的接口。
洹拓在评审这类供给方案时把三个问题写成必答项，答案要落在书面材料里而不是口头解释里。顺带一条：多星协同处理同一任务要追问协同的粒度，即一个窗口内跨星交换的是中间状态还是结果摘要，否则它与第二节的自包含要求相互冲突。
六、这套编排方法在我们交付里的复用
把窗口当成编排单位，不只是为轨道算力准备的。我们的客户里有相当一部分本来就跑在窗口型链路上：矿山井上的作业面按班次联通，远洋船舶按卫星过顶才有带宽，应急现场按保障车辆到位时间取用链路，边远站点每天只有有限时段能稳定回传。这些场景和上面是同一个问题形状：能算、能存，但什么时候能提交、什么时候能拿到结果不由请求决定。
适用与否按三档判断，逐档给出可核对的条件。
- 第一档，能容忍分钟级到小时级的结果延迟：业务侧接受提交不等于可得，结果带时间戳与可得时刻的解释即可；做不到这一条，任何窗口编排都是负担。
- 第二档，能容忍单次算力上限：任务可以在有限时长内切段自包含，且允许一次做不完时作废重排；业务只有不可中断的大任务时，先解决任务形状再谈交付。
- 第三档，能接受本地自检代替集中监控：现场节点逐次落盘自检记录、按窗口回传，接受回传缺口是常态而不是故障；要求实时看板与集中告警的，不适合按窗口组织。
三档都满足的，把状态机、三段预算与两条判据直接搬过去，只是把可见窗口的来源从星地几何换成班次安排或者过顶计划；有一档不满足的，我们把它写成明确的限制条件放进方案，而不是用重试与超时去掩盖。执行形态的差别从来不在离得远近，而在约束是常驻的还是成段的。这一层想清楚，采购、能源与投资都不必扯进来看法里。