● SEC-VERIFIED CAPITAL-CYCLE MONITOR 全季度 2023Q1 – 2026Q2 / UPDATED 2026-07-26

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

HYPERSCALER AI / CLOUD INFRASTRUCTURE CAPITAL-CYCLE MONITOR

四家超大规模云厂商的资本周期，按 投了多少 → 换回什么 → 撑得住吗 → 钱归谁 四幕组织。骨架指标 「资本支出 ÷ 云收入」——比率越高＝相对当期云收入，资本投入越重。四家口径不统一，跨公司只比趋势，不比绝对值。

先读这个 · 口径提醒
  • 分子默认取各家已披露的最干净口径：Amazon 用 AWS 分部 additions、Microsoft 加回融资租赁；Google / Oracle 无分部披露，只能用合并现金 capex，含非云基建。图上可切回全部合并现金口径对比
  • 分母是各家云收入代理——严格说，这测的是"公司资本强度 ÷ 云变现"
  • 比绝对值须按 ¹²³ 注脚校正，见第一幕末「口径修正」
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
每卡标注数据性质（实测 / 代理 / 模型 / 概念），点标签跳到对应幕。
01
投了多少
HOW MUCH WAS SPENT
当前资本强度 · V1 SNAPSHOT
V1 · 同期 CONTEMPORANEOUS

当期资本强度

ratio(T) = 修正后 Capex(T) ÷ CloudRev(T)　·　Amazon 用分部 additions · Microsoft 加回融资租赁
¹ Amazon 分子含全公司 Capex（零售/物流），非 AWS 专属 → 高估 ² Microsoft 分母含本地 Server（修不了：只披露 Azure 增速、无绝对额）+ 分子排除融资租赁（已修：见口径修正，FY25 加回 $20.5B） ³ Google 含 Search/YouTube 基建 → 偏差方向不定。外部不可修：不披露分部 capex；卖方仅有用途拆分（约 60% 服务器），无分部维度
V3 · 累计 CYCLE-TO-DATE（新增）

整轮周期的累计账

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

累计口径回答一个更接近估值的问题：这一整轮 AI 周期里，每 1 美元云收入背后压了多少美元资产？曲线上行＝强度在结构性抬升。

存量视角：把 capex 当已投产能存量而非单季流量 → 消除设备付款 / 融资租赁 / 结算时点的季节噪音 起点＝2023Q1——ChatGPT 于 2022-11-30 发布，2023Q1 是首个完整受其影响的季度（微软 1 月投资 OpenAI、Google 拉响 code red 均在此季）。全页序列均自此起，2022 年的 pre-AI 常规 capex 已整体排除。Microsoft 例外：云收入序列自 2023Q3 起（规避两次 re-segmentation 断点），其累计实际从 2023Q3 计。分子仍为合并现金 Capex（同 ¹²³ 口径失真）
口径修正 · 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%，其余是零售/物流）。
⚠ 但"克制"这个判断到 2026Q1 已不成立：AWS 分部 net additions $41.5B ÷ AWS 分部收入 $37.6B ＝ 1.10，同比 2025Q1 的 0.70（$20.5B ÷ $29.3B）抬了 57%——AWS 自己的分部口径已经破 1，不再是低强度那一档。占全公司 additions 由 FY25 的 68% 升到 Q1-26 的 76%，但 Q1-25 已是 75%——占比这条季节性强，不承重；承重的是分部强度破 1。单季比率有季节性误差，看方向不看点。 来源：AMZN 10-Q 2026Q1 分部附注
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，无法修正。
02
换回了什么
WHAT CAME BACK
V2.5 · 利润口径 PROFIT CATCH-UP（新增）

利润追上了吗

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

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

Google Cloud 2023 年起转正，到 2026 约 +31%（TTM）/ +36%（单季）——教科书式"capex 养成利润"（2022 的亏损期已不在本页区间内） AWS 成熟 ~35%；MSFT IC ~41%（含本地 Server，高估纯 Azure） Oracle 是全公司口径——它不披露云分部经营利润，此处用 SEC 披露的全公司经营利润 ÷ 全公司收入（GAAP，逐季差分）
Oracle 那条线怎么读 · CAVEATS
  • 层级相同、范围不同：与其余三条同为经营利润率，只是分子分母都是全公司而非云分部。云占 Oracle 收入 50.5%（四家最高，Google 仅 13.9%），故全公司代理云业务的误差在四家中最小
  • 残余偏差方向：Oracle 传统 license support 毛利极高，会抬高全公司利润率 → 这条线相对"纯云"仍偏高
  • 券商估 OCI（IaaS）毛利率 FY25 ~42% → FY26E 36%（降 600bp，卖方研报估算）。与本线方向相反——云基建毛利在被爬坡成本压，但公司整体靠裁员 13% 与高毛利传统业务撑住了经营利润率
V2.6 · 资本吸收质量 ABSORPTION QUALITY（新增）

需求吸收有没有利润

横 Δ(Capex/Rev · TTM · YoY) · 纵 Δ云经营利润率(TTM · YoY, pp) · 轨迹=近 6 季 · 点由小到大、由淡到浓 ＝ 时间由早到近

资本强度在变、利润率也在变——两者一起看才分得清"前置扩张"和"降价填产能"。左上＝强度降+利润升(高质量吸收)；右下＝强度升+利润降(Capex trap 风险)。增量利润率 ΔOI/ΔRev 量的是"每多 1 美元收入带回多少经营利润"。Oracle 两轴口径不一致：横轴分母是云收入，纵轴是全公司利润率（它不披露云分部利润）——位置可读趋势，不可与其余三条精确比距离。

增量经营利润率 · INCREMENTAL MARGIN（最新季 · 同比 YoY）
红线 · CAVEATS
  • op income ≠ gross profit
  • YoY 对齐消季节性但受基数扰动
  • MSFT IC 含本地 Server → 非纯 Azure 增量
  • 单季增量利润率波动大，看方向不看点。象限位置＝TTM 口径，更稳
值不值 · RETURN vs COST OF CAPITAL
这笔钱赚回来了吗
≈24%vs WACC ~8–9%
AWS 年化分部经营利润 $48B ÷ 累计分部 capex $202B。 全页唯一能干净算的一笔——另三家不披露分部 capex，分母拿不到，这个问题对它们无解。 利润率再高也回答不了「值不值」，因为没有资本成本做对照；这里是唯一有对照的地方。
红线 · CAVEATS
  • op income ≠ gross profit；未拆维护性 capex
  • 反向因果：公司多是先见到需求才提前 capex，不能读成"投了就有回报"
  • 按现行会计折旧年限计；真实经济寿命若短于账面，分子分母双向恶化（本页未做敏感性）
  • 完整增量 IGPY（baseline 反事实 + 情景带）属 D 档建模，此处不编造情景，只给可核的水平收益率
03
撑得住吗
CAN THEY HOLD
V4 · 现金流 / 融资压力 CASH-FLOW & FINANCING（新增 · 公司合并口径）

撑得起这轮 capex 吗

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

前面全是云分部口径问"投多少、赚多少"。这段切到公司合并口径问最后一个问题：capex 是不是已经吃光经营现金流、要靠外部融资才撑得下去？

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

订单还在不在

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

当期收入是滞后的；RPO（remaining performance obligations，已签约未消耗的合同额）是前瞻的。

总公司 RPO（Oracle=云+license · MSFT=全商业含 O365 · Google≈以云为主）；含多年期合约，非全近端 Amazon 已补：$364B（2026-03-31）· 文字披露非 XBRL（2020Q2 后停用该标签）· 仅含原始期限 >1 年合约 · 与另三家口径不同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 合约通常前低后高，直线摊可能高估近端，即 0.17× 反而偏乐观那侧
  • MSFT 用 IC 分部 OI 率（含本地 Server，偏高）· ORCL 无云分部 OI，用全公司 OI 率 · 分子分母口径见每行末列
04
钱归谁
WHO CAPTURES IT
V7 · 全栈价值捕获 VALUE CAPTURE ACROSS THE STACK（新增 · 先验二）

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

前面六层都在问 hyperscaler 自己。但需求真不代表基础设施所有者赚到钱——价值可能被上游芯片/HBM/电力、模型公司、应用层，乃至客户(生产率)和消费者(降价)截获。

经营利润池分布 · OPERATING PROFIT POOL（apples-to-apples，$B）
💡 利润池在上游，不在云厂
  • NVIDIA 一家经营利润 $130B（FY Jan26）＞ 三家 hyperscaler 云经营利润合计 $120B
  • 上游硬件（美股 NVDA/AVGO/MU/AMD）利润池 ~$169B ＞ hyperscaler 云 ~$120B
  • 且这还未计入不在美股的 SK 海力士 / 三星 / 台积电
价值正被上游不成比例地截获。
价值捕获层级 · 谁赚 & 可测性
泡沫签名：AWS 累计-capex 收益率 ~24%（见第二幕「值不值」）当前仍＞资本成本 ~8-9%，基础设施所有者尚未跌破成本线；但最肥的利润池在上游（NVDA 毛利率 ~71%），不在 hyperscaler。真正要盯的拐点：hyperscaler 云 ROIC 若在 capex 超支（见第三幕现金流）中压到资本成本以下，而上游仍守高毛利 —— 那才是"需求真、所有者不赚钱"的泡沫落地。
红线 · CAVEATS
  • 上游为最新年度 10-K（各家财年末不同，已标注）
  • hyperscaler 为 TTM 口径至 2026Q1、上游为年度（NVDA 截至 2026-01）——窗口不对齐，云在高增长期会被 TTM 抬高
  • 按同一日历年 2025 三家云合计约 $110B，差距更大。分部毛利不披露
  • 模型层私有、客户/消费者红利属经济剩余，均不可作利润池数——此处不编造，只标状态
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,060 亿 ＝ +17.8%；Meta 2026 全年指引 $1,250–1,450 亿 ÷ 同一分母 ＝ +31%~+36%，但那是未来年度指引对 TTM 实际，窗口不对齐。两个数都列在这里，别只引后一个
  • 时点错位。左侧是现金 capex（付款时点），右侧收款方确认收入是出货时点，中间隔着数据中心建设周期（≤2 年，Epoch）。不要做同期减法
  • 左侧四家之间也不同口径：Amazon 用 AWS 分部 additions、Microsoft 加回融资租赁、Google / Oracle 只能用合并现金 capex（含非云基建）。总额 $4,060 亿是四个口径的和，不是一个统一口径的量
方法论与数据表 · METHODOLOGY

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

DATA · ALPHABET · AMAZON · ORACLE · MICROSOFT · SEC 8-K/10-Q/10-K + XBRL
NOT INVESTMENT ADVICE · DATA VISUALIZATION ONLY · GENERATED 2026-07-26