9 六流闭环

9.1 资产请求

推理项目经常在局部表现良好：机器已到，模型能跑，客户也感兴趣。但局部事实之间没有自动连接。只有资产、请求、token、数据、合同和资金六条流同时闭合，技术结果才会稳定转成回款；任何一条断开，其他五条的局部优化都可能失去商业价值。这六条流是全书的主流模型，第 31 章的跨境责任路径是它在海外场景下的局部视图。

资产流回答三个问题：谁拥有资产，谁有使用权，谁有运营控制。它从芯片、服务器和网络设备开始，经过购买、租赁、运输、托管、安装、验收、备件和退役。这条流的时间尺度最长：机房大型电力租约可达 5 到 10 年，而模型 API 请求以秒发生，上游长期固定承诺与下游短期波动之间的期限转换，是推理服务商必须吸收的核心风险。入口证据是采购或租赁文件、序列号、机房位置、起租日、拓扑和验收；出口证据是可被调度的健康容量。设备存在但运营方没有管理员权限，不能算已进入可控产能。

请求流回答：谁接收请求，在哪一跳决定模型和供应商，错误在哪里产生，重试由谁触发。它从客户端开始，经过解析、网关鉴权、限流、路由、排队、调度、GPU 执行和流式返回。聚合路由能在多个提供商之间选择与回退，提高可用性；代价是同一业务可能跨越不同区域、数据政策和模型版本，并产生重复计费。请求流需要端到端的请求 ID：没有统一标识，各组件都有日志，却无法把一次重试还原成同一业务动作。

9.2 计量数据

token 流回答：哪个分词器计数，输入输出分别多少，缓存怎样收费，中断和失败怎样处理。同一次请求可能产生三组数字：模型处理过的 token、客户实际收到的 token、账单记录的可计费 token。三者不一致不必然是错误，但必须有规则解释。token 流的出口不是一串文本，而是文本、完成原因、模型版本和可审计用量记录的组合。

数据流连接事实与动作：监控发现偏差，调度或运维修复，复盘更新阈值与容量计划。它包括请求元数据、模型日志、指标、追踪、计量明细、告警、客户反馈和审计记录。数据流也承载风险：提示词、响应、缓存、日志和账单可能由不同主体保留，路由回退又可能改变处理方和位置，应分别定义内容数据、运维遥测和商业账单的最小保留、访问、删除与导出，不把日志当成单一对象。数据还有一项常被忽略的商业功能是对账：FinOps 的 FOCUS 规范为云成本、用量、发票与合同承诺提供统一数据结构，可作内部字段设计参考，但只有双方在合同中采用一致字段，它才成为可执行计量。核

9.3 合同资金

合同流不是覆盖技术事实的法律包装，而是把事实映射为付款与补偿条件：从主协议、订单和数据条款开始，向下定义产品、区域、模型、容量、价格、验收、服务目标、维护、责任和退出。关键是把每一项承诺接到可观测数据：销售承诺 P99 延迟而监控只记录平均值，订单承诺特定区域而路由允许跨区回退，账单按缓存 token 计费而双方没有缓存命中字段，争议从签约那天就已经埋下。

资金流回答：谁先垫钱，谁开票，谁收款，谁承担坏账与汇率。资产和设施先产生固定付款，请求与 token 收入后发生。预付款改善现金时点，却对应未履行的服务义务；最低采购承诺（take-or-pay）锁定数量，却不消除供应商未交付、SLA 抵扣和客户信用风险。CoreWeave 的年报同时出现多年承诺容量、资产层融资、服务信用、租赁负债与客户集中，说明固定合同和风险可以同时存在。核资金流要同时看三张表：利润表说明会计结果，现金流量表说明钱何时进出，合同台账说明未来承诺；只看其中一张，会把预收款当利润，或把尚未履约的合同金额当现金。

9.4 故障会合

设想一组 GPU 节点失效。资产流记录故障设备、备件和返修；请求流把新请求迁到其他副本；token 流收口失败请求和重试；数据流产生告警、追踪与影响范围；合同流判断是否达到停机与信用门槛；资金流计算信用抵扣、额外资源和维修成本。第一步影响是容量下降，第二步反馈是队列变长、尾延迟上升、客户端重试增加、剩余副本过载，SLA 影响随之扩大。如果各流没有共同的事件 ID 和时间窗，运营方无法判断真实原因，财务也无法复核信用额。

9.5 审查用法

审查时，对每条流都问同样五件事：入口是什么、保存什么状态、谁能采取动作、怎样证明完成、失败怎样传播。六条都能回答，才有资格讨论规模化。

产品边界、交付条件和六条业务流已经对齐。下面往物理层走，从显存、互联和机房条件判断这批产能的硬上限。