# 补偿有价值，不等于有流动性

## 为什么服务抵扣可能补偿 AI 客户，却未必能为恢复业务提供资金

AI Infra Credit · 2026年9月24日 · 公开配套研究扩展

服务失败至少带来两个问题：客户失去有用的工作成果，以及有人必须为恢复业务先付钱。未来折扣可能缓解第一种经济损失，却未必能满足第二种现金需要。

本研究不是说服务抵扣没有价值，而是要区分：**补偿面值、可用价值与兑现时点，是三个变量。** 相同名义补偿，可以得到相同的最终现金余额，却需要不同规模的过桥资金。

## 一、公开文件究竟覆盖什么

| 公开来源 | 选定机制 | 边界 |
| --- | --- | --- |
| [CoreWeave 通用条款](https://docs.coreweave.com/policies/terms-of-service) | 未来受覆盖服务账单抵扣，受通知、证据与排除条件限制 | 页面标注2022年6月日期，尚未证明适用于某份具体Flex订单 |
| [CoreWeave 对象存储SLA](https://docs.coreweave.com/policies/terms-of-service/coreweave-ai-object-storage-policy) | 特定端点的抵扣，无现金退款或跨账户转移；最高列示档为受影响可用区月账单的100% | 是存储补救，不是GPU付款保证 |
| [CoreWeave Spot条款](https://docs.coreweave.com/policies/spot-tos) | 通用条款的SLO不适用 | 不代表所有法律救济都被排除 |
| [Lambda云服务条款](https://lambda.ai/legal/terms-of-service#cloud-terms-of-service) | 指定服务的非现金、不可转让抵扣，含默认到期规则；冲突时以双方认可的订单为准 | 另有条件的终止条款不等于停机即退款 |
| [Lambda计费文档](https://docs.lambda.ai/public-cloud/billing/) | 将退款描述为未来云服务额度 | 属于运营说明，不是对全部合同退款权利的判定 |
| [Lambda 1CC支持文档](https://docs.lambda.ai/public-cloud/1-click-clusters/support/) | 一级事件初次响应为4小时 | 初次响应不等于保证4小时完成修复 |

配套出处表保留不同的申请与抵扣时钟。以取得资格为起点的期限，不会被悄悄改成从事故发生时计算。本轮没有取得签署的客户订单、真实故障索赔、已批准赔付或银行到账记录；公开条款说明可能的权利和流程，不证明实际回收。

还要区分同一网页中的不同合同：Lambda法律页同时包含网站、硬件与云服务条款，本研究使用的是云服务部分。其中有条件的终止规则保留当时已经欠付的金额，并不直接量化所有未来承诺。具体权利及可执行性取决于适用协议和法律。

## 二、三份等额补偿，两种资金需求

下面使用假设现金单位，不是公司实际账单。客户有20的增量流动性缓冲，需要在第0期为恢复业务支付40。正常经营预算已经为各期普通发票提供现金安排，但这些发票**并没有提前向供应商付款**。我们单独考察事故及补救带来的增量变化。

共五个月度期间，第0—4期，每期普通账单为20。假设第0期已批准面值30的抵扣；它可以在第1、2、3期分别抵扣10原本需要现金支付的合格费用，第4期开始前失效。批准、金额、时点和到期日都是假设，不是CoreWeave或Lambda条款。

| 假设补救 | 最终实际获益 | 期末增量流动性 | 峰值额外融资缺口 |
| --- | ---: | ---: | ---: |
| 第1、2、3期各抵扣10 | 30 | 10 | 20 |
| 第0期收到30现金，但晚于恢复业务付款 | 30 | 10 | 20 |
| 第0期先收到30现金，再支付恢复业务款 | 30 | 10 | 0 |

服务抵扣在第0期获批，并没有增加现金：20的缓冲仍须面对40的付款。未来节约最终改善余额，却不能倒过来为已经到期的恢复支出付款。

即使现金退款发生在同一会计期间，也可能太晚。先付款，余额会先降至负20，随后退款才使它回升到10；先退款，最低余额则是10。只看期末净额，会漏掉这项差别。

负余额表示尚未落实的资金需要，不是已经获批的透支或默认存在的授信。融资利息与费用还会增加需求。这里也没有声称任何一家厂商实际负有即时现金退款义务。

## 三、能否用掉抵扣，本身就是金融变量

把假设到期日提前一期，只能抵扣20，另有10失效，期末增量流动性降至零。保持未来仍有账单，但把费用改为不符合抵扣条件，全部30都会失效，现金获益为零。面值再高，也无法自动修复抵扣范围与客户真实需求之间的不匹配。

退出供应商的算例则假设未来不再有该供应商账单，同样使抵扣无法使用。这个假设不会创造终止权，也不会抹去真实欠款；那些条件必须来自另外有效的协议或结算安排。

按12%的有效年折现率计算，三笔未来抵扣的条件现值约为**29.43955**，第0期现金退款则为30。这是给定情景的折现收益，不是权利公允价值或可交易价格。虽然折现后保留了绝大多数面值，20的初始资金缺口仍然存在。

如果观察期在失效前结束，尚未使用与已经失效必须分开。短观察期算例中，已经用掉10、仍剩20；不能只因为表格到这里结束，就认定剩余部分价值为零。

## 四、从同一笔转移同时看交易双方

对服务商，批准抵扣不一定立即付出现金。假设发票按时足额结算：

    服务商净现金转移
      = 原本应以现金支付的总账单
      − 实际用于抵扣这些账单的额度
      − 实际付出的现金退款

五期总账单为100。全部用掉的30抵扣与30现金退款，都使供应商净收款降至70，但发生日期不同。不能在批准时扣掉30，再在使用时重复扣30。

这是现金恒等式，不是收入确认结论。对已经由预付钱包支付的费用，也不能把每次未来抵扣都当作新现金；那种情形需要另外衔接使用权消耗、钱包余额和资金结算。

因此，一家AI运营商可以用合同保护自身即时流动性，而客户仍需要今天就购买替代算力。反过来，立即现金赔付可能缩小客户缺口，却把筹资义务放到运营商身上。金融负担发生了转移，并没有消失。

## 五、设计恢复业务的现金路径，而不只比较赔付比例

建设性的问题，是哪种补救能够以双方可以接受的成本支持业务连续性。

- 更快、更清晰的索赔流程，可以缩短不确定性；但接受索赔仍不等于现金结算。
- 有效的下一张应付账单抵扣权，可能比很晚才能使用的大额额度更有流动性价值。合同限制单方抵销时，不能默认客户可以自行少付款。
- 现金结算、可转移性或替代服务可以提高灵活性，但这些权利必须真实存在，提供它们的一方也需要获得补偿。
- 约定好的营运资金储备或授信可以连接恢复支出与补偿兑现；提款条件、期限与成本要匹配补救时点。
- 可抵扣的未来服务应该是客户真正需要的，不能为了用掉额度而增加经济上不合理的采购。

最高抵扣比例不能替代上述设计。融资分析要识别受覆盖产品、故障定义、程序门槛、合格费用基础、使用规则与现金日期。对服务商的权利，也不自动成为可以自由转让的抵押品。

这与加速AI发展的关系很具体：能够继续取得有用算力的恢复方案，可能比形式或时点不合适的更大名义补偿更有价值。

## 复算

配套文件为service-remedy-evidence.json、service-remedy-model.mjs、verify-service-remedy.mjs及service-remedy-results.json。运行：

    node verify-service-remedy.mjs

九个情景、23组检查，覆盖额度守恒、客户与服务商转移一致性、期内资金缺口、失效、不合格费用、未获赔情景及未知输入拒绝。不需要额外软件包、账户或联网。

程序接受一个假设已批准的补救金额，不会把可用率直接翻译成法律赔付权，不会填平公开阈值文字中的模糊边界，也不估计违约风险或执行供应商合同。原期限、技术现金流与计费模型基准保持不变。本扩展已纳入公开算力融资研究包。