CAPEX ÷ CLOUD
显隐
● SEC-VERIFIED CAPITAL-CYCLE MONITOR 全季度 2022Q1 – 2026Q2 / UPDATED — 本地复刻 · 增强交互

超大规模云厂商 · 资本周期监测器

HYPERSCALER AI / CLOUD INFRASTRUCTURE CAPITAL-CYCLE MONITOR

四家超大规模云厂商的「资本支出 ÷ 云收入」。分子取现金流量表 purchases of property & equipment（data.sec.gov XBRL 逐季差分），分母取各自云口径。比率越高＝相对当期云收入，资本投入越重。
口径提醒：分子是合并现金 Capex（非 AI-only、非云分部专属），分母是各家云收入代理——严格说是"公司资本强度 ÷ 云变现"，跨公司看相对趋势可靠，绝对值须按 ¹²³ 注脚校正（见下方口径修正）。

SOURCE · SEC 8-K / 10-Q / 10-K + data.sec.gov XBRL RECONCILED · Amazon 分部 additions · Microsoft 经济 capex CONFIDENCE · capex+rev HIGH · Oracle 22–24 云收入 MED (rounded $B) · MSFT IC pre-23Q3 弃用(重述)
泡沫判断仪表盘 · BUBBLE SIGNAL DASHBOARD
六个高信息密度指标——比继续堆 Capex÷Revenue 变体更接近真正的泡沫判断。每卡标注数据性质（实测 / 代理 / 模型 / 概念），点标签跳转对应详解层。
削减病因分诊 · CAPEX-CUT TRIAGE（本地新增 · 自动判定）
同一句"削减 capex"，病因不同、含义相反：效率驱动＝利好（少花钱多办事），需求驱动＝利空（订单先见顶，领先 capex 决策 2–3 季）。本模块对每家公司监测四个先行指标，自动给出病因判定，随 data.json 更新自动重算。
判定规则：① capex 绝对额环比下滑＝削减已发生 → 云增速 ≥40% 且 RPO 未恶化＝效率驱动 · 利好，否则＝需求驱动 · 利空；② RPO 增速连续 2 季放缓 + 云增速连续 2 季放缓＝需求预警（领先信号，尚未削减）；③ V1 比率回落 + 云增速 ≥40% + 利润率扩张＝效率红利显现；④ 其余＝无信号。注：capex QoQ 受季节/结算节奏扰动，单季环比下滑需两季确认。
当前资本强度 · V1 SNAPSHOT
V1 · 同期 CONTEMPORANEOUS

当期资本强度

ratio(T) = Capex(T) ÷ CloudRev(T)
¹ Amazon 分子含全公司 Capex（零售/物流），非 AWS 专属 → 高估 ² Microsoft 分母含本地 Server + 现金 capex 排除融资租赁 → 双重低估 ³ Google 含 Search/YouTube 基建 → 偏差方向不定
会翻转结论的对比 · THE FLIP

V1 里 Oracle 当期最重（1.66，2026Q1 峰值 2.09）——现金 Capex 相对当期云收入最大。切到 LRI（现金 Capex 比 6 季后披露收入），Oracle 在当前 reported-scope LRI 代理指标中最低（≈0.40）：因为它 2024 年前 capex 的后续云收入增长倍数最大。

关键：LRI 下降几乎全来自"后续披露收入的增长倍数 G"，不是新发现的资本回报。Google 2024Q4 的单季现金 Capex，其 6 季后的单季披露收入是它的 1.73×（不代表利润或回本）——即 LRI ＝ V1ₜ ÷ G。

死穴 · THE BLIND SPOT

LRI 必然砍掉 2025Q1 之后的 capex（AI 最猛那段）。它只描述"后来披露收入规模相对于历史现金 Capex 扩大了多少"，不是 ROI、不是利润、不是回本——现在这波要等 2027 才能填进来。

V1 → 当期强度有多重
LRI → 历史 capex 相对后续收入
DECOMP → LRI ＝ V1 ÷ 收入增长 G
FAN → lag 敏感性（4–8Q 区间）
V3 → 整轮周期累计账（存量）
V2.5 → 利润追上了吗（经营利润率）
V2.6 → 吸收质量四象限（强度×利润）
V4 → 撑不撑得起（现金流/融资，公司口径）
V5 → 订单还在不在（RPO 前瞻需求）
V6 → 订单覆盖建设承诺吗（T1 近端流量 / T2 整本存量·模型）
V7 → 钱被谁赚走（全栈价值捕获）
V7.5 → 每 $100 capex 该落到谁头上（成本分摊情景·E 级）
RECONCILE → 真·分部/经济口径
LRI-6Q · LAGGED REVENUE INTENSITY

LRI · 滞后收入强度

LRI(t,L) = Capex(t) ÷ CloudRev(t+6Q) = V1(t) ÷ 收入增长倍数 G
描述性指标 · 非 ROI / 非利润 / 非回本：LRI 越低＝历史 capex 相对其 6 季后披露收入越小 默认 TTM 4Q（滚动）以压平单季设备付款 / 融资租赁 / 结算时点噪音；单季为 drill-down
分解 · DECOMPOSITION（最新可算 vintage · 单季）
LRI ＝ V1ₜ（当初强度）÷ G（收入增长倍数）。LRI 的"改善"几乎全来自 G——后续收入长大了，不是发现了新的资本回报。这一层把 V2 从"伪 ROI"还原成"V1 + 收入增长"的再表达。
敏感性 · COHORT HEATMAP / LAG-FAN

别只信一个 18 个月 lag

行＝capex vintage · 列＝lag 0–8Q · 灰＝未成熟（未来收入尚未披露）
LRI 色阶 低 ≤0.5 · 1.0 · ≥1.75 高 未成熟 / censored
LAG-FAN · 4–8Q 稳健区间（最新成熟 vintage · 单季 LRI）
与其挑一个 lag，不如报区间：lag 4–8Q 的 LRI 中位 + min–max。区间越宽＝对 lag 假设越敏感，越不该 cherry-pick 单一数字。
V3 · 累计 CYCLE-TO-DATE

整轮周期的累计账

ratio(T) = Σ Capex(2022Q1…T) ÷ Σ CloudRev(2022Q1…T)

单季比率噪声大（capex 有交付节奏、收入有季节性）。累计口径回答一个更接近估值的问题：这一整轮 AI 周期里，每 1 美元云收入背后压了多少美元资产？曲线上行＝强度在结构性抬升。

存量视角：把 capex 当已投产能存量而非单季流量 → 消除设备付款 / 融资租赁 / 结算时点的季节噪音 起点＝各家云收入序列起点（Microsoft 自 2023Q3）；分子仍为合并现金 Capex（同 ¹²³ 口径失真）
V2.5 · 利润口径 PROFIT CATCH-UP

利润追上了吗

云分部经营利润率 = 分部 Operating Income ÷ 云收入（TTM 滚动）

V1–V3 都在问"投了多少"。V2.5 问"赚回来没有"：capex 建起来的云业务，经营利润率在往哪走？这是从"资本强度"迈向"资本回报"的第一步。

Google Cloud 从 2022 经营亏损翻到 2026 约 +31%（TTM）/ +36%（单季）——教科书式"capex 养成利润" AWS 成熟 ~35%；MSFT IC ~41%（含本地 Server，高估纯 Azure）；Oracle 云 op income 不披露 → 缺席
利润 ÷ 累计 CAPEX · 收益率（IGPY 精神 · 水平口径）
公司经营利润率 TTM年化利润 ÷ 累计capex口径
AWS35.2%≈24%干净（AWS 分部 capex $202B / 年化利润 $48B）
Google Cloud31.3%—分部 capex 不披露，÷capex 无法干净算
MSFT IC41.4%—分部 capex 不披露 · 含本地 Server
OracleN/AN/A云 op income 不披露
红线警告：op income ≠ gross profit；未拆维护性 capex；反向因果（公司多是先见到需求才提前 capex）。只有 AWS 能干净算 ÷capex 收益率（唯一披露分部 capex）。完整增量 IGPY（baseline 反事实 + 保守/基准/乐观情景带）属 D 档建模——此处不编造情景，只给可核的水平收益率。
V2.6 · 资本吸收质量 ABSORPTION QUALITY

需求吸收有没有利润

横 Δ(Capex/Rev · TTM · YoY) · 纵 Δ云经营利润率(TTM · YoY, pp) · 轨迹=近 6 季，大点=最新

资本强度在变、利润率也在变——两者一起看才分得清"前置扩张"和"降价填产能"。左上＝强度降+利润升(高质量吸收)；右下＝强度升+利润降(Capex trap 风险)。增量利润率 ΔOI/ΔRev 量的是"每多 1 美元云收入带回多少经营利润"。Oracle 不披露云经营利润，缺席。

增量经营利润率 · INCREMENTAL MARGIN（最新季 · 同比 YoY）
红线：op income ≠ gross profit；YoY 对齐消季节性但受基数扰动；MSFT IC 含本地 Server → 非纯 Azure 增量；单季增量利润率波动大，看方向不看点。象限位置＝TTM 口径，更稳。
V4 · 现金流 / 融资压力 CASH-FLOW & FINANCING（公司合并口径）

撑得起这轮 capex 吗

Capex/OCF · FCF ＝ OCF − Capex · FCF margin ＝ FCF ÷ 总收入 · 均 TTM 滚动

前面全是云分部口径问"投多少、赚多少"。这段切到公司合并口径问最后一个问题：capex 是不是已经吃光经营现金流、要靠外部融资才撑得下去？Capex/OCF 越过 100% ＝ 当期资本开支超过经营活动现金流，自由现金流转负。OCF / 总收入 全 SEC XBRL 逐季差分，capex 与主看板同源、已逐季对齐。

100% 线＝capex 吃光 OCF；越线＝FCF 转负、需外部融资 TTM 滚动消季节性（Oracle 财 Q4 现金收缴集中）；分子分母均全公司合并，非云分部
融资压力排名 · 最新 TTM（Capex/OCF 降序）
读法：Capex/OCF > 100% 且 FCF < 0 ＝ 当期扩张已超自身造血，依赖债务 / 融资租赁 / 客户预付。Oracle、Amazon 已越线，Google / MSFT 仍自给。红线：OCF / capex / 收入均全公司合并数（含非云业务）；净债务、融资租赁、客户预付明细属脚注级，未纳入本轮（下一步）。
V5 · RPO / BACKLOG 前瞻需求（领先指标）

订单还在不在

RPO ＝ 已签约未确认收入（前瞻订单簿）· RPO增速 vs Capex增速 背离 ＝ 需求见顶探测

当期收入是滞后的；RPO（remaining performance obligations，已签约未消耗的合同额）是前瞻的。逻辑：capex 狂飙但 RPO 增速掉头 ＝ 新客户不再提前锁算力 ＝ 需求见顶直接信号。反之 RPO 增速持续跑赢 capex 增速 ＝ 订单簿仍在扩张。

总公司 RPO（Oracle=云+license · MSFT=全商业含 O365 · Google≈以云为主）；含多年期合约，非全近端 Amazon 口径不同：自愿文字披露（2020Q2 后停用 XBRL 标签），仅含原始期限 >1 年合约；2026Q2 的 $496B 为电话会管理层口径（backlog，YoY 三位数），新闻稿未更新正式 RPO（上次正式披露 $364B，2026-03-31） Google 有口径断点：2026Q1 起把 ≤1 年合约纳入 backlog，$242.8B→$467.6B 的增幅含定义变更，公司未量化
背离探测 · RPO 增速 vs Capex 增速（最新 · 同比 YoY，背离降序）
见顶信号：背离(Capex增速 − RPO增速) 转正且走阔 ＝ 资本开支跑赢订单，需求侧见顶。当前四家背离全为负（RPO 增速远超 capex）＝ 订单簿仍在扩张，capex 反而落后于签约。但这个"负"是单季台阶造成的，不是平滑流量——见下方失效判据。
红线 · CAVEATS
  • RPO 为总公司口径、含多年期合约
  • 增速受大单一次性签约扰动，看趋势拐点不看单点
  • 四家不是同一种合约（详见下节「签下的订单，覆盖得了多少建设承诺」）：AMZN 非 ASC 606 口径；GOOGL 2026Q1 起把 ≤1 年合约纳入 backlog → 增速含定义变更，公司未量化，该家 YoY 不可当纯需求读
  • 当前增速来自单季台阶：MSFT $398B→$631B（2025Q3→Q4）· ORCL $137.8B→$455.3B（FY25末→FY26Q1）· GOOGL $242.8B→$467.6B（2025Q4→2026Q1）。归因只到公司自陈程度：ORCL 原文是 "certain significant cloud contracts"（复数）、MSFT 未归因 → "单一交易对手驱动"无证据支持，不采用
  • 失效判据（预先写死，不是事后感觉）：某家连续两个季度 RPO 环比增幅 < 同期 capex 环比增幅 → 判该家订单侧领先信号失效、背离转正。台阶不再出现即触发，无需等"突然翻转"的直觉
V6 · 合同需求质量 CONTRACTED DEMAND QUALITY（模型 · 口径审计后 v2）

签下的订单，覆盖得了多少建设承诺

T1 近端 ＝ 近12m合同收入(各家披露排期) × 分部经营利润率 ÷ 年化Capex　·　T2 整本 ＝ RPO × 毛利率 × 确认概率(分公司) × 折现 ÷ 承诺Capex(A/B/C)
⚠ 四家披露的不是同一种合约SEC 原文核过
  • Amazon — 不是 ASC 606 RPO 口径。2020Q2 起停用该 XBRL 标签，改为自愿文字披露；仅含原始期限 >1 年的合约，无确认排期
  • Google — 明确剔除可取消合同；2026Q1 改过定义，≤1 年合约由排除改为纳入
  • Oracle — 选用 optional exemption，排除可变对价
  • Microsoft — 反向，把估计的客户用量计入可变对价
  • 近端可转化率 12%（ORCL）~25%（MSFT）· 加权久期 2.5 年（MSFT）~5.5 年（AMZN）
横向数字须先标准化才能比；单家时间序列也有断点（GOOGL 改口径、AMZN 停标签）。本层因此不再给"谁最厚"的排名。
⚠ 模型 · 非测量
  • SEC 实数 — RPO · Capex · 承诺义务 · 确认排期 · 分部利润率
  • 假设（随情景可调、非披露）— 毛利率 · 确认概率 · 折现因子
  • 上一版的错在存量÷流量 — 多年期 RPO 存量 ÷ 一年 capex 流量，>1 不等于"够本"，只等于"整本合同相当于 N 年当期 capex"
  • T1 明年的合同利润够付明年的建设吗（流量÷流量）
  • T2 整本合同利润够付已签的建设承诺吗（存量÷存量）
T1 · 近端流量 ÷ 流量（久期匹配 · 全部按各家自己披露的确认排期）
读法：倍数 ＝ 未来 12 个月已签约合同带来的经营利润，占同期年化 capex 的几成。四家全部 < 1×——明年的合同利润填不满明年的建设，缺口靠"未签约的按需消费"补，而那部分正是本轮争议的标的物、不是已锁定的量。
红线 · CAVEATS
  • 用经营利润率、不是毛利率（OI 已扣研发/销售/折旧）→ 比 T2 与旧版严得多，两者数值不可对照。这是压力下限，不是"真实覆盖率"
  • AMZN 的近12m 用 1/5.5 直线摊 ＝ 假设，非披露（Amazon 只给 5.5 年加权剩余期限）。AWS 合约通常前低后高，直线摊可能高估近端
  • MSFT 用 IC 分部 OI 率（含本地 Server，偏高）· ORCL 无云分部 OI，用全公司 OI 率 · 分子分母口径见每行末列
V7 · 全栈价值捕获 VALUE CAPTURE ACROSS THE STACK（先验二）

需求是真的，钱被谁赚走了

AI 需求真 ≠ 基础设施所有者高回报 · 价值可被上游 / 模型 / 应用 / 客户 / 消费者截获

前面六层都在问 hyperscaler 自己。但需求真不代表基础设施所有者赚到钱——价值可能被上游芯片/HBM/电力、模型公司、应用层，乃至客户(生产率)和消费者(降价)截获。泡沫的签名不是"没需求"，而是"用量与社会价值高增，但基础设施所有者 ROIC 长期低于资本成本"。

经营利润池分布 · OPERATING PROFIT POOL（apples-to-apples，$B）
💡 利润池的重心仍在上游：上游硬件（美股 NVDA/AVGO/MU/AMD）经营利润池 ~$169B ＞ 三家 hyperscaler 云经营利润合计 ~$136B（TTM→2026Q2）——且这还未计入不在美股的 SK 海力士 / 三星 / 台积电。NVIDIA 一家 $130B（FY Jan26）≈ 三家云合计——云侧靠 Q2 利润放量（AWS +64% YoY）刚追到平手，但 NVDA 的窗口止于 2026-01、缺最近两季 AI 爆发，同窗口比较上游优势更大。价值正被上游不成比例地截获。
价值捕获层级 · 谁赚 & 可测性
泡沫签名：AWS 累计-capex 收益率 ~24%（见 V2.5）当前仍＞资本成本 ~8-9%，基础设施所有者尚未跌破成本线；但最肥的利润池在上游（NVDA 毛利率 ~71%），不在 hyperscaler。真正要盯的拐点：hyperscaler 云 ROIC 若在 capex 超支（见 V4）中压到资本成本以下，而上游仍守高毛利 —— 那才是"需求真、所有者不赚钱"的泡沫落地。红线：上游为最新年度 10-K（各家财年末不同，已标注）；hyperscaler 为 TTM 经营口径（分部毛利不披露）；模型层私有、客户/消费者红利属经济剩余，均不可作利润池数——此处不编造，只标状态。
V7.5 · 成本分摊情景 COST ALLOCATION SCENARIO（E 级）

每 $100 资本支出，模型说它该落到谁头上

A 级总量（SEC capex）× E 级份额（第三方成本模型）＝ E 级情景
这张图的身份，先说死
  • 它是成本分摊情景，不是资金流证据
  • 左侧总额可回溯到 SEC，但只要乘上模型份额、画成 ribbon，整张图就必须整体按 E 级读
  • 本页别处立的「两层不做任何混算」，在这一段是明标的例外——这里就是拿 A 级总量当锚、套 E 级份额
  • ribbon 不代表任何一笔可追踪的付款：没有任何一家 hyperscaler 披露过 capex 的供应商构成
只能读方向和量级，不能读小数点。

上面那张利润池图回答的是"谁最后赚到了"（A 级，各家已披露的经营利润）。这张图换一个问题："按业内的成本模型，这笔钱该被谁截一道"——两张图不同层级，别串着读。

窄屏可左右滑动 →
穿透 · GPU 那一格里面又分给谁
GPU/加速器拿走整笔 capex 的 39%，但这 39 块钱不全归 NVIDIA——它自己也要付 HBM、晶圆、封装。Bernstein 的口径下（四项都是「占总 capex」的份额，不是 GPU 内部的独立测量）：
红线
  • 这是分摊份额，不是穿透到 NVDA 实际确认收入的金额。"模型隐含毛利份额"和"NVDA 真的收到并确认了多少"之间隔着客户边界、时点、口径三道，本页不跨
  • Bernstein 的"NVDA 毛利 = 全部 AI 数据中心成本的 29%"很可能已含它的网络业务（FY27Q1 网络单季 $148 亿）。若剔除，GPU 格内的毛利占比要下调，上游占比上调
  • 半导体设备（ASML/AMAT/LRCX，Bernstein 估 3–4%）不在这张图里——那是芯片厂的 capex，不是数据中心的 capex，画进来就是双计
  • 自研 ASIC（TPU→Broadcom、Trainium→Marvell/Alchip、Maia）也在这一格，这部分完全不流向 NVIDIA
对账 · 模型隐含 vs 实际披露（A 级）
这张对账表只杀一条推理链，别多读：NVDA 数据中心收入里只有 约 55% 来自 Hyperscale，另 $104B 来自 ACIE。所以"云厂减 capex ⇒ NVDA 收入同比例塌"这条链是断的。
它不能推出"NVDA 对云厂 capex 不敏感"，也不能推出"风险主要不在云厂"。而且 NVDA 口径的 Hyperscale ＝ "public clouds + 全球最大消费互联网公司"，并不等于本页左侧这四家（Meta 一类在里面），两边不能直接相减。
ACIE 那一半的信用 · 降级后的说法
已知的只有一个样本：同一发行人 CoreWeave 两笔贷款，承购方 META（投资级）约 5.9%/A3，承购方无评级 >8%/Ba2，利差 214bp（卖方信用研究）。
它能证明的是：ACIE 里存在一类"融资型 AI cloud"，其付款方信用显著弱于 hyperscaler。它不能证明"ACIE 那一半整体信用弱"——ACIE 还含工业、企业、主权国家等多类付款方，本页没有覆盖它们的证据。这一条按风险提示读，不是结论。
为什么两个 labs 不在左边那一列
  • 按 Epoch AI 的口径，它们的支出科目是「云算力采购」不是 capex —— Anthropic 2026Q1 单季 $136 亿（R&D + 推理合计）、OpenAI 2025 全年 $160 亿
  • 那是买方付给算力供应商的经常性开支，落在供应商的收入端；和 capex 并列画会双计
  • 但不能说"全部经由 hyperscaler" —— 也会流向 CoreWeave 一类 neocloud、Stargate 这类 JV / 表外结构
  • 准确的说法是「有双计风险，且流向本身不可核」，不是"这笔钱一定被数了两遍"
  • labs 自建 capex 没有可核披露 —— Epoch 明确说其公司库只记经常性算力开支，不记数据中心建设的资本开支。这一格是真空，本页不填、也不估
收款方明细 · 谁在这一格里收钱
红线 · 这张图不能读出什么
  • 两个模型的分歧不是误差带。Epoch 的 IT ＝ 服务器＋网络（68.9%），Bernstein 的 IT ＝ GPU＋网络＋CPU＋存储（56.3%）——— 的差里含分类口径不等价，不是同一指标的两次测量。可以展示，不能承重
  • 电费几乎看不见，不是因为电便宜。每 GW 电费是 $6 亿/年（Epoch，8.34¢/kWh）到 $13 亿/年（Bernstein，15¢/kWh）的 opex；capex 里的"电"是配电/UPS/开关/发电设备，占 33%。把电力公司画成主要收款方是错的——赚钱的是机电设备商，不是卖电的
  • 左侧不含 Meta，但"大多少"取决于拿哪个窗口比：Meta 2025 全年 capex $722 亿 ÷ 四家 TTM $4,770 亿（→2026Q2）＝ +15.1%；Meta 2026 全年指引 $1,250–1,450 亿 ÷ 同一分母 ＝ +26%~+30%，但那是未来年度指引对 TTM 实际，窗口不对齐。两个数都列在这里，别只引后一个
  • 时点错位。左侧是现金 capex（付款时点），右侧收款方确认收入是出货时点，中间隔着数据中心建设周期（≤2 年，Epoch）。不要做同期减法
  • 左侧四家之间也不同口径：Amazon 用 AWS 分部 additions、Microsoft 加回融资租赁、Google / Oracle 只能用合并现金 capex（含非云基建）。总额是四个口径的和，不是一个统一口径的量
V8 · 折旧与融资 DEPRECIATION & FCF WAVE（本地新增 · SEC 实测 + 队列模型）

被推迟的账单什么时候到期

D&A(t) = Σ cohorts[ SV·Capex/24Q + (1−SV)·Capex/80Q ] · 转固滞后 2Q · 2024 起服务器占比 70%

现金的痛已经在付（Q2'26 FCF −58.6 亿，史上首负），利润表的账才刚到：Q2 折旧 $71 亿（+42%）仅为当期 capex 的 16%，而常态 D&A/Capex 约 70%+——这个剪刀差只有一种收敛方式。用队列模型（60/40 服务器/基建拆分、直线法、转固滞后）按 SEC 实测折旧标定（拟合误差 —），推演 2027 capex 三种裁决下的折旧浪潮。占比挤压图看演化：D&A÷云收入 — → —（2030E 基准），Capex÷云收入 — → —；金色阴影＝两线差值＝被推迟账单的厚度。被挤的那块海绵就是云利润率。

占比挤压演化：金色阴影＝两线差值＝当季收入中「已付 capex 、尚未折旧」的份额（被推迟账单的厚度）；斜率＝挤压速度——紫线上翘＝折旧增速跑赢收入增速（利润率被压缩），蓝线下行＝收入追上投入（效率红利） 虚线段＝推演（云收入 YoY +55%→+20% 渐降假设，非指引）· 终点直接标注 2030E 值 · 蓝线领先紫线约 2–3 年（转固滞后＋折旧年限） legacy 修正 ≈ 两次年限延长（2021 3→4、2023 4→6）对存量资产的摊薄 · 2023 为口径切换年、拟合偏差最大
2026 全年 FCF 网格 · 本模型测算（$B）
H1'26 FCF 仍为正（+$4.3B，Q1 +$10.1B 抵消 Q2 −$5.9B）。若 H2 OCF 延续 +15~30% 增速（Q2 实测 +41%），全年 FCF 可守住盈亏平衡；只有 OCF 增长停摆，才落入 −50~−150 亿的悲观区间。2027 年：capex 2,570–3,500 亿 vs OCF ~2,000–2,200 亿 → 负 FCF 常态化几乎不可避免。
监测清单 · WATCH LIST
时点事件触发含义
7/29–30MSFT / AMZN 财报同步上调 capex → 板块二次催化；共同季推进 2026Q2
8 月Q2 10-Q 在建工程蓄水池续涨 or 放水；季折旧增速 >+50% ＝ 主浪提前
10-K年限变更段落再延长＝红旗；跟 Amazon 缩到 5 年＝EPS 一次性 −8%
2027.022027 capex 指引2,570 亿共识 vs 3,500 亿上限的裁决 → 定折旧终值
双向争论：Burry（3 年寿命，五大厂低估折旧 $1,760亿）vs Bernstein/英伟达（6 年 A100 满负荷）；二手市场 H100 前 24 个月保值率 75–85% 指向真实寿命 4–5 年 → 账面利润温和高估（低个位数 %），6 年年限激进但不构成舞弊。
口径修正 · RECONCILED BASIS

换成真·分部 / 经济口径

仅 Amazon 披露分部 capex · Microsoft 加回融资租赁 = 经济 capex · 年度
AMAZON · 分部 additions 口径
FY全公司÷AWSAWS分部÷AWS高估
20220.760.352.19×
20230.530.271.95×
20240.800.501.61×
20251.110.751.47×
用 AWS 分部 additions 做分子，AWS 真实资本强度 FY25＝0.75，主图全公司口径 1.11 高估 1.47×。AWS 在 FY25 是三家里投得最"克制"的（占全公司 additions 68%，其余是零售/物流）。
⚠ 最新 2026Q2 release 没有单列 AWS additions：因此主图 Q2 先沿用 FY25 修正系数；最后一笔可核的分部拆分仍是 2026Q1——AWS 分部 net additions $41.5B ÷ AWS 分部收入 $37.6B ＝ 1.10，同比 2025Q1 的 0.70（$20.5B ÷ $29.3B）抬了 57%。占全公司 additions FY25 的 68%，Q1-26 的 76%（Q1-25 已是 75%）——占比季节性强，不承重；承重的是最后一笔已审计分部强度破 1。单季比率有季节性误差，看方向不看点。 来源：AMZN 2026Q1 10-Q；Q2 2026-07-30 release 未披露分部 additions
MICROSOFT · 经济 capex（含融资租赁）
FY现金÷IC经济÷IC低估
20240.510.64+0.13
20250.610.80+0.19
加回融资租赁数据中心（FY25＝$20.5B），经济 capex 强度 FY25＝0.80，现金口径 0.61 低估 +0.19。微软大量算力走融资租赁，现金 capex 系统性偏低。
基准说明：Amazon 两列同为 "net additions"（含融资租赁）口径，仅换分子范围以隔离失真；主图 Amazon 线用现金 capex（≈全公司 additions）。Google/Oracle 不披露分部 capex，无法修正。
方法论与数据表 · METHODOLOGY（附 CSV 导出）

分子＝季度 Capex（cash-flow "purchases of property & equipment"，XBRL 累计 YTD 逐季差分）。云收入分母：Google＝Google Cloud 分部；Amazon＝AWS 分部；Oracle＝Total Cloud (SaaS+IaaS)，2022–2024 为财报四舍五入十亿值；Microsoft＝Intelligent Cloud 分部，已统一到最新分部口径、自 2023Q3 起（规避两次 re-segmentation 断点）。Oracle/Microsoft 财年非日历年，按财季末对齐日历季度。分部 capex 仅 Amazon 披露；Oracle "capex≈全 OCI" 为假设、未证。全部数字经年度重构对账（季度和＝财报直报年度值）。

实时更新：顶栏「⟳ 检查更新」会重新拉取 data.json 并重渲染全部图表；勾选「自动 60s」可定时轮询。运行 python update_data.py 可从 SEC XBRL 自动补齐最新季度的 Capex / OCF / 总收入（云分部收入、分部利润、RPO 无标准 XBRL 概念，仍需按 8-K 手工录入）。

DATA · ALPHABET · AMAZON · ORACLE · MICROSOFT · SEC 8-K/10-Q/10-K + XBRL
NOT INVESTMENT ADVICE · DATA VISUALIZATION ONLY · GENERATED — · 本地复刻版