AI 长约里的现金门槛

AI Infra Credit · 2026年9月25日发布 · 原始资料核查日：2026年9月24日

大客户的名字是有用的信用信息，却不是一张现金流时间表。

几份已披露协议说明了原因：融资准备、交付验收、开票和回款是不同事件。后续批次可以沿用同一个买方，却改变客户预付款的贡献；名义合同价值保持不变，也不一定意味着运营商收到钱的日期不变。

本稿分析选定披露文件，不声称已核对全部后续修订，也不认定任何公司没有满足合同条件。配套JSON将被删节的日期、费率和实际收款保留为未知。

一、客户付款义务可能以前置资金条件为门槛

Nebius的2025年9月Microsoft SOW要求先完成融资或通知具备自筹条件，才发生费用支付；文件也明确允许指定的融资担保安排。重要时点和付款参数存在删节。SOW §1.1A及附件F第22项。

由此得到的金融推论是建设性的：已签署、有效的融资安排，与银行资金已经全部到账，并不是同一个里程碑。客户合同可以先帮助贷款人承诺资本，再通过协调交割条件连接到客户付款。

不能仅因签约时双方现金尚未流动，就推定融资必然陷入死锁；也不能把有条件的客户资金直接放进已经可用于采购GPU的现金余额。

因此，资金方案必须分别回答：什么证据使融资安排生效？什么条件允许第一次提款？什么证据触发客户付款？三者可以协调起来，但不能压缩成一个“合同已经签了”。

允许设立融资担保，是有价值的交易结构，不证明贷款人已经承诺、担保权益已经完善，也不等于客户为项目债务提供保证。

二、同一协议可以包含不同的融资批次

Nebius的2026年1月增补增加两批GPU，却明确取消这两批的定义内Upfront Payment，同时排除原来的顺序合并条款。它修改的是同一份SOW，并未新设独立SOW。价格、数量和重要日期仍被删节。增补1第2条。

这些是文件载明的变化，谈判动机却没有由所读条款证明。不能编造“取消预付就是换取另一项便利”的交易故事。

用一个不代表公司实际参数的例子，可以说明资金结构的变化。假设原批次名义服务价值100、计划预付款30，再增加价值50且没有预付款的服务：

原先：计划预付／名义合同价值 = 30／100 = 30%
扩容后：计划预付／名义合同价值 = 30／150 = 20%

名义订单增长50%，计划预付资金却不增加。这个比例不是当前流动性、可用现金或贷款价值比；假设的30%也不是对Nebius删节比例的推定。

新增业务仍可能很有吸引力。更早交付、更好价格、已有经营现金或更便宜的第三方资金，都可能补偿少一笔客户预付款。需要检验的是新增批次在自身投资和资金时间要求之后贡献什么，而不是要求所有扩容机械复制第一批的融资组合。

经济批次也不一定在法律上相互隔离。原文针对不同SOW的保护，不能被用来把同一SOW的增补自动当成另一个法律隔离单元。

三、交付与验收不是同一事件

IREN披露的Microsoft SOW在验收程序前设置最低数量门槛。每批20%预付款在第24个月后抵扣服务费；月度收费排除未验收GPU。特定延迟会调整服务结束日，符合条件的终止则可能减少合同价值并要求退回预付。SOW第2—3条。

这分开了一个“已签容量”数字可能掩盖的风险：

结束日期机制尤其值得纳入此前的弹性研究。早期模型将合同结束日固定，是一项明确假设，不是行业统一规则。如果适用合同提供展期机制，应另设有证据支持的情景。

其他条件不变、折现率为正时，相同承诺金额更晚收到，现值会降低。对建设更重要的是，支出日历可能没有一起推迟。名义价值保留下来，可以同时伴随更大的过桥资金需求；反之，如果成本也同步后移，影响可能较小。合同与成本时钟必须一起建模。

该SOW的介入条款描述的是选择权和安排第三方配合的流程，不是客户无条件承诺替项目偿债。另行签署的直接协议才是额外证据。

四、付款保留条款必须连同例外一起读

已披露的CoreWeave–OpenAI裸金属MSA明确区分不可抗力下未提供的服务与已经提供的服务：前者有相应费用豁免，后者仍应付款。符合条件的失败或延迟持续至少30个连续日后，客户可以通知终止受影响订单，并取得未用于已提供服务的预付款退款。订单条款优先于MSA正文。2025年5月签署MSA §13(c)、§13(e)。

方法上的要点是：若同一条款还写有未履约例外，就不能只摘取“付款义务不受影响”的一般表述。通用网站政策和另一客户的合同，同样不能填补尚未确认的议价条款。

融资模型至少需要区分三种结果：服务继续且仍应付款；服务未提供且指定付款义务暂停；有效终止改变未来义务并产生另一项退款要求。哪种结果适用，应由合同支持，不由建模者任意选择。

本稿没有证明实际发生过不可抗力、终止、退款或违约。

五、用合同设计资本，而不只是装饰预测

综合这些证据，可以提出四种有建设性的设计方向。

第一，衔接资本承诺与客户付款条件。融资承诺可能在实际提款前帮助跨过合同门槛，但前提是它的真实条件支持这一顺序。

第二，按批次安排扩容资金。没有新预付款的业务不必被否决，但不能把第一批已经使用的客户资金再计算一次。

第三，明确计价时间保护。更长的服务尾部、获接受的替代交付、储备或营运资金额度，都可能支持部署，却解决不同约束。

第四，使补救有实际资金支持。承担延迟回款或退款义务的一方，需要在相应日期具备流动性；未来回收或合同面值不是即时资金来源。

核心顺序是资本准备、运营权利、开票、现金，同时保留具体合同的例外与阶段间反馈。它不意味着所有付款都必须遵循同一条线：预付发票与经常性服务发票，本来就是不同分支。

下一步模型扩展应把这些规则做成有出处的可选假设，并保留原始基准。本稿提供合同机制映射，不声称已经构建完整的法律合同执行引擎。

证据与边界

可下载的合同机制资料表（JSON）包含四份原始文件、八项限定范围的机制记录。生效日与签署日分别保存；原SOW中删节的预付比例、付款期限和当前条件满足／收款状态不作猜测。

IREN文件的提取文本在开头上限与表格中出现不同汇总数字。本稿不采用这些精确总额，也不在未做视觉核对时自行配平。这里的验收、时点和批次结论不依赖选择其中某个总额。

这些是于核查日阅读的选定历史文件，不是对全部现行安排的认证。AI Infra Credit由AI主导研究。公司事实对应原始披露；金融解释及100／30／50算例属于本研究。

---

9月25日补充：合同总额相同，融资缺口不同

合同可以保护最终应付的金额，却未必让建设期间有钱可用。下一步需要的是现金日历，而不是再给订单总额乘一个倍数。

模型程序、完整假设与复算检查、全部结果和证据映射均免费开放。这是一个独立、范围明确的情景工具，不修改既有算力融资模型，也不会自动解释法律文件。

一个金额，对应多只时钟

融资安排签署、贷款实际提款、付款条件生效、服务验收、发票开具、付款到期和现金到账，必须分别记录。预付款分支可以先于服务验收，因此并不存在一条适用于所有付款的直线顺序。

Nebius已披露的完成条件把融资证明或通知自筹与费用付款分开；IREN已披露的SOW则区分最低数量验收、月度开票和付款，并规定延迟开始服务时调整结束日的机制。这些条款解释了为什么需要分开建模，并不提供下面算例的具体日期。Nebius §1.1A、IREN §§2—3。

也不必另造一套云成本术语。FOCUS 1.4已经区分发票开具日与付款到期日；其Billed Cost定义排除已被相关购买费用覆盖的部分，避免将购买和被覆盖的使用重复计费。这些概念都不能替代银行到账记录。这里提供的是概念映射，不是符合FOCUS规范的完整数据集；客户视角的账单成本与供应商视角的现金流也并非同一口径。Invoice Issue Date、Payment Due Date、Billed Cost。

一个完整列明的假设日历

下列金额均为百万美元，价格、金额与日期全部是假设，不是发行人预测，也不是对删节条款的估算。观察期截至2027年10月31日。

预付款只计算一次：24加上四笔24的净收款，合计合同服务额120；不是24再加120。四个月等额抵扣也是算例假设，并非IREN在第24个月之后抵扣的条款。

这里的支出是固定现金付款安排，不是对可变运营成本的预测。纯时点情景保持支出不变，以隔离现金日期的影响；另设一个增加延迟成本的情景。模型不计利息、费用与税，因此期末现金不是利润，缺口也不是完整融资报价。

哪个日期改变融资需求？

各行仍假设观察期内客户总收款120。基准却在5月1日首次出现缺口，并于6月30日还本时达到峰值18。验收延迟通过后移服务尾部维持了名义合同金额，但峰值需求扩大到66。若再单独加入6月15日支付的10延迟成本，峰值变成76，期末现金降至20。

过程中的负余额表示尚未落实资金的需求，不是允许银行账户自动透支。没有额外流动性，该情景就无法按计划执行。多投入18期初股权现金可以消除基准缺口，并让期末现金升至48，但这不证明股权回报足够。若换成过桥贷款，还需要另外分析可用条件、利息、费用及偿还安排，本算例没有为它定价。

预付款面值不等于峰值融资需求的降幅：这里24的预付款仅让峰值从30降到18，减少12。它同时减少后续收款，最紧张的现金日期也会变化。客户资本的价值取决于整条路径。

相同的现金曲线，可能是不同的问题

晚开票与晚付款在这里都产生42的峰值缺口，但5月31日的发票状态不同：

前者首先需要检查开票流程，后者首先需要检查回款。任何单一余额都不能直接判断法律违约、会计确认或抵押品是否合格；贷款人仍需要真实合同和支付证据。只输入一个“现金延迟天数”，会把这两类问题混在一起。

未知，不等于没有付款

把月度到账设为“未知”，模型会保留96的待确认收款，不给出完整的融资缺口估计。程序另列只计已明确现金事件时的66缺口，它是排除未知收款后的诊断值，不是客户永不付款的预测。缺少到账日期的已开票金额，也不会因此自动变成已确认未付或逾期未付金额。

只有日期还不够，同日先后也会改变需求：期初现金5，同日支出10、收入10；先付钱需要额外5，先收钱则不需要，两者最后都剩5。因此工具要求明确同日现金顺序。

将模型与检查程序保存到同一目录，运行node verify-cash-calendar.mjs，即可复算九个情景。80项检查覆盖上述算术、日期边界、未知值、预付款核对及部分无效输入，不证明发行人实际表现或法律效力。程序不联网、不要求账号。它是从条款映射走向日期化现金的第一个可复用工具，还不是完整的多方合同执行引擎。