Broadcom FY2026 Q3：增长来自芯片，需求来自可被固化的巨量工作负载¶

分析日期：16 Sep 2026

财报发布日期：2 Sep 2026；报告期：截至 2 Aug 2026 的季度。

金额默认单位为十亿美元（b）。FCF 为经营现金流减购置固定资产。财务数据来自 Broadcom 财报与 SEC 文件；客户案例来自客户和 Broadcom 的公开资料。公开资料没有披露单个项目的芯片价格、开发费、完整成本和内部回报率，本文会把已披露事实、计算结果与分析推断分开。

结论¶

如果只问本轮 Broadcom 增长由什么推动，答案不是 VMware，也不是手机、宽带或存储，而是 AI 半导体，尤其是定制 AI 加速器及其配套网络芯片。

FY2026 Q3 总收入同比增加 13.639b，其中 AI 半导体收入增量约为 11.5b，贡献约 84%；非 AI 半导体只增加约 0.173b。基础设施软件增加 1.966b，对利润和现金流仍然重要，但不是当前增长斜率的来源。（FY2026 Q3 财报；FY2025 Q3 财报）

所以，本文沿着以下业务链条展开：

客户先拥有规模巨大且反复运行的工作负载
→ 通用加速器在成本、功耗、延迟、供给或路线控制上出现约束
→ 客户把工作负载抽象成可长期复用的硬件需求
→ Broadcom 将客户架构与自己的 SerDes、HBM、I/O、封装和网络能力组合
→ 芯片流片、验证、量产并进入机架
→ 客户用更低的单位总成本或更大的可用算力回收前期投入
→ Broadcom 从开发服务、批量芯片和配套网络中取得收入

“定制芯片更便宜”只是结果，不是需求来源。真正的需求来自四个条件同时成立：任务足够大、任务结构足够稳定、通用方案的约束足够昂贵、客户有能力维护自己的软件栈。 少一个条件，购买通用 GPU 往往更合理。

更准确地说，NVIDIA 与 Broadcom 路线不是“软件对硬件”，而是把专用化放在哪一层。NVIDIA 保留一颗可运行广泛工作负载的可编程 GPU，再用 CUDA、加速库和编译器把不同模型映射到同一硬件；Broadcom 的客户则把已经稳定的计算、内存和通信特征进一步下沉到自有 XPU，同时建设自己的编译器和运行时。两条路线解决的是同一个问题，区别在灵活性、效率和前期投入怎样分配。

Broadcom 的盈利模式也不是普通芯片代工。客户需要的不只是一张由晶圆厂制造的裸片：在流片之前，需要把计算模块与 HBM PHY、SerDes、die-to-die 等接口 IP 集成，完成时序、功耗、面积和可测试性验证；流片之后，还要解决封装、良率、测试和量产导入。Broadcom 从这些开发工作、可复用 IP、量产芯片及另行赢得的网络产品中取得收入，先进制造则主要外包。前期研发具有固定成本，量产具有可变成本，一旦同一平台进入几十万颗芯片和多代产品，固定工程投入会被大量出货摊薄。FY2026 Q3 半导体分部收入 20.839b、分部营业利润 12.770b，分部营业利润率约 61%；但这个口径没有分摊集团股权激励、收购无形资产摊销等费用。（FY2026 Q3 10-Q）

可以把 Broadcom 的作用概括为“用专用硬件优化现有计算需求”，但必须拆开看，否则仍然含糊：

1. 客户先定义要优化什么。 客户从生产负载中确定高频算子、允许的数据精度、张量形状、内存容量、通信模式、延迟和功耗目标，并决定矩阵、向量、标量单元及片上缓存的大致架构；客户还要维护把模型映射到这套架构的编译器和运行时。
2. Broadcom 负责让这套架构满足芯片工程约束。 它把客户的计算模块与自己的 HBM、SerDes、die-to-die 和网络 I/O 等 IP 集成，在目标制程下处理时序收敛、功耗、面积、测试与封装问题，完成流片和量产导入。具体项目中双方承担多少逻辑设计并未统一披露，但 Broadcom 公开的 3.5D 模式明确把处理单元架构归于客户，把设计流程、性能优化、接口和封装实现归于 Broadcom。（Broadcom 3.5D XPU 平台）
3. 晶圆厂和封测厂按完成的设计制造。 台积电等供应商提供先进制程和产能，但不替客户决定哪些 AI 算子应该固化，也不自动完成整颗 XPU 的接口、验证和系统集成。

因此，Broadcom 的竞争优势不是抽象的“懂 AI”，而是有大量已经验证的高速接口 IP、物理实现与验证流程，以及把计算 die、HBM 和 I/O die 组合后导入量产的经验。这些能力直接影响一颗客户自研 XPU 能否达到目标频率和功耗、能否一次流片成功、封装后能否稳定工作，以及能否按数据中心部署窗口交货。

最大的风险也在同一条主线上：客户集中、先进制造供应集中、项目延迟，以及部分前沿 AI 客户尚未用自身现金流覆盖基础设施投资。Broadcom 已经通过融资平台帮助客户取得算力，并对五年租赁承担最高约 29b 的潜在 backstop。此时芯片需求不再只是技术问题，也包含客户信用和设备残值风险。（FY2026 Q3 10-Q）

先把增长来源拉直¶

AI 芯片贡献了约 84% 的同比收入增量¶

注：AI 半导体是公司披露的管理口径，不是独立报告分部；非 AI 半导体为半导体分部减去 AI 半导体的近似值，受四舍五入影响。来源：FY2026 Q3 财报、FY2025 Q3 财报及本文计算。

本季度 AI 半导体已经占集团收入约 56%、占半导体分部约 80%。它既包括定制 AI 加速器，也包括 AI 网络产品。公司没有在财报表格中完整拆出二者各自收入，因此不能把 16.7b 全部当作 XPU，也不能把网络芯片视为无关配件。

配套网络尤其重要。加速器数量增加以后，芯片之间需要更快交换模型参数、激活值和中间结果；如果网络让昂贵的计算芯片等待，客户购买的理论算力就不能转化为有效算力。Broadcom 因而可以在同一 AI 集群中同时获得 XPU、交换 ASIC、网卡、PCIe、SerDes、DSP 和光连接等机会，但每一项仍需分别赢得设计，不能假设全部由 Broadcom 供应。（Broadcom AI 基础设施产品）

软件是利润底座，不是当前增长主线¶

本季度基础设施软件收入同比增长 29%，并不弱；其分部营业利润率约 84%，高于半导体分部。VMware 等软件资产提供了高利润和现金流，使公司有能力承担研发、供应链承诺和资本回报。

但投资判断必须区分“利润底座”和“边际增长”：

利润底座：基础设施软件 + 成熟半导体产品
增长斜率：定制 AI 加速器 + AI 网络

若 AI 项目放缓，软件可以缓冲利润，却不能自动补回当前由 AI 半导体贡献的 11.5b 同比收入增量。因此，下文不再逐项展开手机、宽带、存储和企业软件，而只在分析成本或风险时把它们作为集团背景。

同一个 AI 问题，NVIDIA 与 Broadcom 分别怎样解决¶

模型最终会变成计算、数据搬运和芯片间通信¶

用户写下的是 PyTorch、JAX 或 TensorFlow 模型，但芯片不会直接理解“Transformer”或“推荐系统”。模型首先被表示成计算图，再拆成较低层的运算：矩阵乘法、向量运算、归一化、激活、数据重排、内存读写，以及多芯片之间的聚合与交换。

以一次 Transformer 推理为例，它并不是从头到尾只做一种矩阵乘法：

输入 token
→ embedding 和 Q/K/V 投影：大量矩阵乘法
→ attention：矩阵乘法、softmax、mask、KV cache 读写
→ MLP：矩阵乘法和激活函数
→ normalization、采样和其他向量运算
→ 多芯片部署时执行 all-reduce、all-gather 或 all-to-all
→ 生成下一个 token，再重复执行

所以，峰值 FLOPS 不是完整性能。一个简化的执行时间可以写成：

执行时间
≈ max(
    计算量 / 有效计算吞吐，
    数据搬运量 / 有效内存带宽，
    芯片间通信量 / 有效网络带宽
  )
  + kernel 启动、同步和排队延迟

这是分析框架，不是精确性能公式。NVIDIA 的性能文档同样把算子区分为 compute-bound、memory-bound 和 latency-bound：如果一个算子受内存搬运限制，只增加矩阵计算单元并不会等比例提速。（NVIDIA GPU Performance Background）

真正要解决的问题是：怎样让计算单元持续获得数据，尽量少把中间结果写回 HBM，并让成千上万颗芯片高效协作。 NVIDIA 和定制 XPU 的分歧，主要在于由软件适应硬件，还是让硬件也适应已经确定的负载。

NVIDIA：用 CUDA 把不断变化的模型映射到同一类 GPU¶

NVIDIA 的完整执行链可以简化为：

PyTorch / JAX / TensorFlow 模型
            ↓
框架编译器、cuDNN、cuBLAS、TensorRT 等
            ↓ 选择、融合并生成 CUDA kernel
CUDA runtime 与 driver
            ↓ 启动 thread blocks / warps
GPU 的 SM、Tensor Cores、寄存器、cache 和 HBM
            ↓
NVLink / NVSwitch / InfiniBand 或 Ethernet
            ↑
NCCL 负责多 GPU collective communication

CUDA 首先是一套并行编程模型和平台。GPU 由许多 Streaming Multiprocessors（SM）组成；程序把工作写成 kernel，再拆成大量 thread blocks 和 warps，由硬件调度到不同 SM 上执行。SM 内既有可编程计算单元，也有寄存器、shared memory、cache 和针对矩阵运算的专用单元。（NVIDIA CUDA Programming Guide）

CUDA 的价值不止是让代码“能运行”。上层软件还持续寻找同一颗 GPU 的更优执行方式：

• cuBLAS、cuDNN 等库提供经过优化的矩阵和深度学习 kernel；
• TensorRT 把训练好的模型编译成面向具体 GPU 的 inference engine，为各层选择 kernel、精度和数据布局；
• kernel fusion 把多个操作合在一起，减少 kernel 启动和中间张量写回 DRAM 的开销；
• NCCL 根据 GPU 和网络拓扑执行 all-reduce、all-gather、reduce-scatter 等多卡通信；
• runtime 在运行时管理 stream、内存、同步和 kernel launch。

TensorRT 官方文档明确描述：builder 会为模型各层选择可用的最快 GPU kernel，生成硬件相关的 engine；其融合优化可以消除中间张量的 DRAM 往返和多次 kernel 启动。（NVIDIA TensorRT；TensorRT kernel fusion）

因此，NVIDIA 的解法是：GPU 的主要硬件结构已经确定，再由软件把每个新模型编译、切块、融合和调度到这套硬件上。 模型从 CNN 变到 Transformer，或者算子和张量形状变化，客户通常先升级框架、库或 kernel，而不是重新设计芯片。

GPU 也不是“完全通用”的 CPU。Tensor Cores 本身就是为矩阵乘法和低精度计算优化的专用硬件；GPU 的优势是，在这些专用单元之外仍保留足够的可编程 SM、内存层次和成熟软件生态，可以处理模型中不断变化的长尾算子。

Broadcom 路线：让客户把稳定负载继续下沉到芯片¶

Broadcom 不向所有开发者提供一套统一的“AVGO CUDA”。它服务的客户通常已经控制模型、框架、编译器、数据中心和部署规模。客户可以统计生产负载，再决定一颗 XPU 应该把多少面积和功耗分配给矩阵单元、向量单元、片上内存、HBM 接口、chip-to-chip I/O 和网络。

这条执行链更接近：

客户的 PyTorch / JAX / 自有框架模型
                 ↓
StableHLO 或客户自有中间表示
                 ↓
客户主导的 compiler backend、算子库与 runtime
                 ↓ 进行融合、切块、内存规划和指令生成
客户定义的 XPU 指令集或数据流
                 ↓
定制矩阵 / 向量 / 标量单元、片上内存和 HBM
                 ↓
Broadcom SerDes、die-to-die、封装和网络技术

OpenXLA 展示了这种软件结构如何成立：PyTorch、TensorFlow 或 JAX 可以先转换为 StableHLO，再由面向目标硬件的 backend 做特定优化并生成机器指令。为新加速器增加 backend 的目的，就是让大量模型不必逐个重写，却仍能针对不同硬件生成不同执行程序。（OpenXLA 架构）

这并不表示所有 Broadcom 客户都使用同一套 XLA 流程，也不表示 Broadcom 负责客户的完整编译器。具体分工没有公开。重要的是：客户必须拥有一个能把模型图编译到自有 XPU 的软件后端；否则芯片即使流片成功，也无法高效运行生产模型。

Broadcom 官方对 3.5D XPU 分工的描述很直接：处理单元架构由客户拥有；Broadcom 拥有设计流程与性能优化，并提供 HBM PHY、网络 I/O、chiplet 和封装实现。这说明 Broadcom 更像客户自有计算平台的 silicon implementation partner，而不是另一个面向所有开发者的软件平台。（Broadcom 3.5D XPU 平台）

ASIC 的效率究竟从哪里来¶

定制 XPU 不是因为贴上 ASIC 标签就自动更快。它的潜在效率来自客户可以根据已知负载，改变整颗芯片和系统的资源比例。

1. 减少不需要的通用性¶

GPU 要支持不同模型、张量形状、数据类型、控制流和长尾算子，必须保留较广泛的指令、调度和内存能力。定制 XPU 可以把晶体管和功耗集中到客户最常见的运算与精度，并减少长期不用的能力。

但这不是把控制逻辑全部删除。实际 XPU 通常仍需要矩阵、向量和标量单元，以处理 softmax、激活、地址计算和控制流。Google TPU 的公开架构就是这种组合：MXU 执行主要矩阵乘法，vector unit 处理激活和 softmax，scalar unit 处理控制与地址计算。（Google Cloud TPU 架构）

2. 围绕固定数据流减少内存往返¶

模型性能经常受数据搬运而非乘法数量限制。通用 GPU 通过 cache、shared memory、kernel fusion 和软件调度增加数据复用；定制 XPU 还可以按照高频算子的实际张量形状，调整片上 SRAM、HBM 通道、数据布局和计算流水线。

例如 systolic array 会让数据在相邻 multiply-accumulate 单元之间连续流动，矩阵乘法过程中不必让每一步都重新访问外部内存。Google 的 TPU MXU 是公开可见的例子，但它只用于解释原理，不能据此假设所有 Broadcom XPU 都采用相同微架构。（Google Cloud TPU 架构）

3. 把原本由软件反复完成的融合固定成常用快路径¶

NVIDIA 可以在 TensorRT 中把多个层融合成一个 kernel；客户如果确定某种算子组合会长期大量出现，可以让 XPU 的指令、片上网络和内存路径从设计阶段就适合这类融合。这样能进一步减少调度和中间数据落地，但也把对未来工作负载的预测写进了硅片。

4. 让芯片、HBM 和网络按同一负载共同设计¶

单颗芯片更快，不代表整个集群更快。训练需要频繁同步梯度，推理可能需要在 tensor、pipeline 或 expert parallel 之间交换数据。NVIDIA 用 NCCL 配合 NVLink、NVSwitch、InfiniBand 或 Ethernet 屏蔽不同拓扑；定制客户则可以让 compiler、XPU I/O、机架拓扑和网络协议围绕自己的并行方式共同优化。（NVIDIA NCCL）

这正是 Broadcom 的 SerDes、交换 ASIC、DSP、光连接和封装能力与 XPU 同时有价值的原因。它赚取的并非只有计算 die，而可能是把数据从 HBM 移到计算单元、从一颗 XPU 移到另一颗 XPU 的整条数据路径。

用同一个 Transformer 看两条路线¶

这个表格也解释了为什么不能只比较“某颗 XPU 和某颗 GPU 的峰值算力”。真正应比较的是同一个模型、同一种服务等级下的端到端结果：每 token 或每次推荐的成本、P99 延迟、有效吞吐、每瓦吞吐、机架密度、软件迁移成本和集群利用率。

Broadcom 需求产生于“软件优化已经不够”之后¶

NVIDIA 软件栈本身已经能做低精度、kernel 选择、算子融合、内存规划和拓扑感知通信。客户不会因为发现这些优化存在，就自然转向 ASIC。定制项目成立，需要客户进一步证明：

在 CUDA / TensorRT 已充分优化之后
仍然存在长期、规模化的成本或系统约束

且

把这些负载特征写进自有硬件所节省的成本
>
芯片研发 + compiler/runtime + 迁移 + 延期和过时风险

所以 Broadcom 的潜在市场不是“所有正在使用 NVIDIA 的算力”，而是其中已经形成稳定生产负载、并且规模大到值得拥有自有硬件后端的部分。也正因为客户必须同时控制软件和硬件路线，这个市场天然集中在少数 hyperscaler、消费互联网平台和前沿模型公司。

定制芯片的需求到底从哪里来¶

客户不是先决定“我要一颗 ASIC”，而是先发现系统约束¶

一家大型互联网平台通常已经运行着数十万台服务器。它不会因为某颗 ASIC 的峰值算力看起来更高就立项，而是先从生产系统中发现约束：

1. 某类任务每天被重复执行数十亿次，通用性带来的额外电路和数据搬运变成持续成本。
2. 数据中心的电力、机架、散热或网络先达到上限，新增芯片不再等比例增加可用算力。
3. 用户请求有延迟要求，平均吞吐量合格但尾延迟过高，仍会伤害产品体验或广告收入。
4. 商用加速器的供给、价格和产品节奏受外部厂商控制，客户自己的模型路线无法决定硬件路线。
5. 某些运算、数据精度、内存访问和通信模式已经相对稳定，可以被固化成硬件，而不需要保留通用处理器的全部灵活性。

这一步的核心不是“发现 GPU 贵”，而是把成本拆成 总拥有成本（TCO）：芯片采购、服务器、网络、电力、散热、机房、软件工程、设备利用率和资金成本都要计算。采购价更低但利用率更差的芯片，可能反而更贵。

工作负载怎样被抽象成芯片¶

客户需要把业务语言逐层翻译成工程约束：

因此，ASIC 不是“把一个模型焊死在芯片里”。更常见的做法，是把长期稳定的矩阵运算、数据格式、内存访问和通信模式做成高效率硬件，同时保留足够的可编程空间，让同一代芯片运行一组模型。

通用性更差，为什么客户仍愿意承担过时风险¶

因为客户购买定制 XPU 时，本来就没有假设它永不过时。决策成立的条件是：芯片在预计淘汰时间之前创造的价值已经覆盖全部投入。 如果项目必须使用十年才能回本，而客户只能确信工作负载未来两年相对稳定，这个项目就不应该立项。

这里首先要区分“领域专用”和“只能运行一个模型”。定制 XPU 固定的是一部分资源比例和数据通路，但仍然通过编译器、指令和片上调度运行不同计算图：

所以客户不需要准确预测三年后仍然使用今天的具体模型。它需要判断的是更底层的规律是否稳定：未来一段时间，主要负载是否仍由矩阵乘法、低精度计算、特定内存访问和通信模式构成。只要新模型仍落在这组硬件能力的覆盖范围内，就可以通过更新 compiler、runtime 和算子库适配，不必立即换芯片。只有当新模型需要硬件不支持的精度、内存容量、算子或通信结构时，专用化才会真正变成包袱。

回本计算已经把有限寿命算进去¶

客户比较的不是“XPU 能否永久使用”，而是它在有限寿命内是否比购买 GPU 更有价值：

定制 XPU 相对 GPU 的净价值
= Σ 在第 t 年节省的芯片、网络、电力、散热和机房 TCO
 + Σ 因释放电力、机架或供给而新增的业务价值
 - 芯片 NRE、compiler/runtime 和系统迁移投入
 - 提前淘汰、低残值和项目延期造成的损失

立项条件：保守情景下的回本周期
        < 可预测的负载稳定期
        < 芯片可能仍可运行的物理寿命

GPU 同样会因新一代产品而经济性过时；定制 XPU 的额外风险，是它能转去运行的其他任务更少、二手残值更低，而且软件投入无法转移到其他硬件。因此，客户必须用更短的回本要求、更保守的负载预测和更低的残值假设来补偿这种风险。

规模会显著缩短回本时间。下面只是敏感性示例，不是 Meta 或 Google 的实际数据，也不假设 XPU 与 GPU 可以一比一替换：如果部署 100,000 颗 XPU，每颗按整个替代方案分摊后的净节省为每天 1 美元，一年就是约 36.5m；每天节省 10 美元，就是约 365m。如果每颗 XPU 相对承担同等负载的替代系统平均少消耗 100W，100,000 颗就会持续释放约 10MW 电力。对于电力和机架已经成为扩容瓶颈的客户，这部分价值可能比芯片采购差价更重要。

新一代出现，不等于旧一代价值立即归零¶

“技术落后”至少有三种不同含义：

1. 仍能运行原负载，但单位成本不如新芯片。 旧 XPU 只要产生的业务价值仍高于电力、维护和占用机架的机会成本，就可以继续使用；它只是从最稀缺的负载退出，而非物理报废。
2. 无法高效运行新模型，但仍能运行旧模型。 客户可以把新模型放在 GPU 或新一代 XPU，把排名、推荐和成熟推理留在旧芯片上。能否这样调度，取决于旧负载是否继续存在。
3. 原工作负载本身消失或软件不再维护。 这才是最接近“全部报废”的情形，也是定制芯片相对 GPU 最大的尾部风险。

大型客户降低风险的典型方法，是不把全部算力一次性押在同一颗 XPU 上：把数量大、变化慢的基础负载逐步迁到定制芯片，把前沿训练、长尾算子和尚未稳定的模型留在 GPU；按代际分批增加容量，而不是预先假设新一代发布时替换全部存量。这样牺牲的是一部分灵活性，而不是整个数据中心的选择权。

Meta 的公开路线正好说明这种组合。它已经部署数十万颗 MTIA，却仍同时采购多家供应商的芯片；未来两年计划推出四代 MTIA，并明确表示依靠模块化、可复用设计以及与既有机架兼容来降低每代开发和部署成本。（Meta：Expanding Meta's Custom Silicon）Meta 没有披露每代 MTIA 的退役速度，因此不能断言旧芯片会使用多久；但从组合采购、分代部署和模块复用可以推断，其经济模型依赖多代并存与增量扩容，而不是每六个月报废全部存量。

Meta 将大多数服务器和网络资产的估计使用寿命设为 5.5 年。这个会计口径并不等于 MTIA 的实际寿命，但至少说明大型平台本来就是按有限年限回收数据中心硬件，而不是依赖永久使用或很高的终值。（Meta FY2025 10-K）

对 Broadcom 而言，换代既是机会也是风险¶

客户的旧 XPU 会过时，并不自动伤害 Broadcom；如果客户已经在使用期内回本，下一代反而带来新的设计和量产收入。Broadcom 还可以在下一代复用 SerDes、HBM PHY、封装模块、验证工具和供应链流程，客户也可以复用 compiler、runtime 和机架接口，因而后续代际不必重复第一代的全部成本。

但每一代都必须重新证明经济性，也必须重新赢得 design win。若新模型超出旧架构覆盖范围、客户迁回 GPU、改用其他 ASIC 伙伴或把实现能力内化，上一代合作不会保证 Broadcom 获得下一代。多代协议和模块复用降低了转换成本，却没有消除技术过时风险。

归根结底，需求能否成立取决于规模、稳定性和回本速度。单个项目的开发费、单位节省和退役计划没有公开，因而不能诚实地写出“Broadcom 客户一年回本”之类的精确结论；但是否进入生产、部署量、多代续约、是否沿用编译器与机架架构，可以帮助判断客户是否认为项目已经越过经济门槛。

案例一：Meta MTIA——从广告与推荐推理中产生的需求¶

真实问题：通用训练芯片并不天然适合所有推理¶

Meta 的核心产品每天都要做内容推荐、广告排序和模型推理。这类任务直接影响用户停留时间、广告展示和广告转化，同时又具有请求量大、延迟敏感、长期反复运行的特点。

Meta 公开解释其 MTIA 路线时指出，主流 AI 芯片通常先为最困难的大规模预训练设计，再被用于推理；对于 Meta 自己的推理和推荐任务，这种配置未必具有最佳成本效率。到 2026 年，Meta 已经在生产环境部署数十万颗 MTIA，并计划在两年内开发和部署四代新芯片。（Meta：Expanding Meta's Custom Silicon）

这正是定制需求的来源：不是 Meta 预测未来也许会有 AI，而是它已经拥有可以测量的巨大生产负载。每天的请求日志能够告诉它哪些算子使用最多、需要什么精度、数据怎样移动、芯片在等计算还是等内存、多少延迟会影响业务。

怎样把问题抽象成一条芯片路线¶

根据 Meta 的公开说明，可以重建其决策逻辑：

排名、推荐、广告和生成式 AI 推理持续增长
→ 先把高频且稳定的推理负载交给定制芯片
→ 围绕计算、内存带宽和效率连续迭代
→ 用模块化设计复用上一代成果
→ 保持与现有机架和行业标准兼容
→ 再把适用范围扩展到训练和更多生成式 AI 工作负载

Meta 将这条路线称为 inference-first。MTIA 300 用于排名和推荐训练，后续 MTIA 400、450 和 500 的适用范围更广，但近期仍主要面向生成式 AI 推理。模块化设计使新芯片可以进入既有机架，减少每一代都重做服务器、供电和网络的成本。（Meta：Expanding Meta's Custom Silicon）

这也说明客户不会在“全部买 GPU”和“全部用 ASIC”之间二选一。Meta 明确采用多供应商组合：通用加速器承担变化快、生态要求高或最前沿的任务；MTIA 承担规模大、可被充分理解和优化的任务。定制芯片获得的不是整个数据中心，而是它最适合的负载池。

Broadcom 为什么在这里有价值¶

Meta 用生产负载决定 MTIA 要支持哪些算子、精度、内存访问和软件接口；Broadcom 则提供芯片实现所需的设计流程、接口 IP、封装与量产能力。换句话说，Meta 决定芯片应该怎样执行自己的工作负载，Broadcom 解决这套设计怎样在目标制程、功耗和交付周期内成为实体产品。双方在 2026 年宣布共同开发多代 MTIA，合作范围覆盖芯片及系统部署。（Meta 与 Broadcom 合作公告）

Broadcom 可以复用的不是 Meta 的业务数据，而是底层工程资产：

• 高速 SerDes 和网络 I/O；
• HBM PHY、die-to-die 连接和内存集成；
• 逻辑实现、时序收敛和验证流程；
• 2.5D/3D 封装设计；
• 与晶圆厂、封装测试厂和系统供应链协同量产的经验。

客户如果完全自建这些能力，理论上可以保留更多控制权，但需要长期维护庞大的后端设计、验证、封装和供应链团队。Broadcom 让客户集中在架构与软件差异化上，同时缩短把设计变成量产产品的路径。

MTIA 怎样回本，需求又怎样延续¶

公开资料没有披露 MTIA 的开发费、单颗成本或节省金额，因此无法计算精确回本期。但它已经给出三项强证据：数十万颗生产部署、连续四代路线、与 Broadcom 的多代合作。试验芯片不会自然导向这些承诺；只有当单位 TCO、供给或战略控制权具有足够价值时，客户才会继续扩展。

对 Meta 而言，回报不只表现为“少付芯片钱”：

1. 相同电力和机架可以处理更多推荐、广告或推理请求；
2. 更低延迟可能改善用户体验和广告效果；
3. 自有路线降低对单一商用加速器供应的依赖；
4. 既有机架和模块化设计减少换代成本；
5. 每一代软硬件经验可以进入下一代，缩短后续回本周期。

对 AVGO 而言，长期需求并不直接等于 Meta 的资本开支总额，而取决于：MTIA 在 Meta 工作负载中的渗透率、每代芯片的 Broadcom 内容价值、部署规模，以及 Broadcom 能否继续赢得下一代设计。

案例二：Google TPU——从内部成本中心变成云产品¶

真实问题：机器学习已经进入大量产品，功耗和延迟开始约束部署¶

Google 在 2016 年首次公开 TPU 时表示，当时已有超过 100 个内部团队使用机器学习，覆盖搜索、语音、图片和邮件等产品。TPU 项目在公开前已经秘密开发数年，并已在数据中心运行一年以上。Google 当时披露，第一代 TPU 针对 TensorFlow 和机器学习中的矩阵运算设计，并利用较低数值精度减少每次运算所需晶体管；相较当时的通用产品，其内部测试取得数量级的每瓦性能改善。（Google 2016 TPU 公告）

这个案例比“GPU 太贵”完整得多。Google 先在真实产品中看到机器学习需求扩散，再发现现有硬件的功耗、吞吐和响应时间会限制继续扩张，最后才把共同运算抽象为矩阵处理器。

这里有两个关键条件：

• Google 同时控制模型框架、数据中心和芯片使用方式，能够为新硬件修改软件；
• 大量内部产品共享类似运算，使芯片的固定开发成本可以跨团队摊薄。

普通企业即使面对相同芯片价格，也没有这两个条件，因此不会得出相同决策。

交付速度为什么不能只看“流片到量产”¶

Google 表示，第一批可用芯片完成测试后，仅 22 天就开始以生产速度运行应用。这个数字说明：如果软件、机架和应用适配提前完成，成功硅片到生产部署可以很快；但它不代表整个 TPU 项目只用了 22 天。项目前面还有数年的负载研究、架构设计、验证和制造。

这是理解 AVGO 项目周期的关键：

首次项目：需求发现和软硬件共设计可能持续多年
成功流片后：已有软件与机架可使部署缩短到数周或数月
衍生代际：复用 IP、模块和工具后，节奏可以继续加快

把全部过程笼统写成“芯片交付需要 18 个月”会掩盖真正风险。第一次架构定义、一次重新流片、封装良率爬坡和成熟平台的衍生产品，时间完全不同。Broadcom 没有披露每个客户项目的统一周期；设计、流片、验证、production release 和 volume ramp 所代表的收入确定性也不相同。

TPU 的回报有三层¶

Google 的回报结构也比单纯节省成本更丰富：

1. 内部成本节省：搜索、广告、语音和模型服务不必全部购买外部加速器。
2. 产品能力：在既定电力和延迟条件下运行更大的模型或更多请求。
3. 外部收入：TPU 通过 Google Cloud 对外提供，原本的内部资本开支变成可以出租的云资源。（Google Cloud TPU 架构）

因此，只要 Google Cloud 客户愿意使用 TPU，项目规模就不再受 Google 内部负载限制。反过来，外部客户是否愿意迁移模型、工具链是否成熟、集群利用率是否足够，会决定这部分资本的回收速度。

Broadcom 获得的是多代量产与系统内容，不是 Google 的模型¶

2026 年 Broadcom 披露，它与 Google 签订长期协议，为后续多代 TPU 提供开发和供应，并为下一代 AI 机架提供网络及其他组件，期限最长到 2031 年。同一文件还披露，Anthropic 自 2027 年起将通过 Broadcom 获得约 3.5GW 的下一代 TPU 算力，但明确指出使用量取决于 Anthropic 持续的商业成功。（Broadcom 8-K：Google TPU 长期协议）

这份协议揭示了 Broadcom 长期收入的三个来源：

• 每一代 TPU 的工程实现和量产；
• TPU 机架里的网络与其他 Broadcom 组件；
• 当 Google 把 TPU 算力卖给外部模型公司时，新增部署带来的芯片需求。

同时，它也揭示了需求边界：模型公司的收入和融资如果不能跟上算力承诺，合同中写下的 GW 不一定全部转化为高质量现金收入。

案例三：AI XPV——有技术需求，但客户现金流暂时不够¶

前两个案例主要是现金充足的大型平台。FY2026 的新变化是，部分前沿模型公司虽然需要大量算力，却没有足够当前现金流一次性购买基础设施。

Broadcom 在 Q3 10-Q 中披露，公司建立 AI XPV 平台，计划通过金融合作方支持到 2028 年超过 20GW 的 XPU 和网络算力。2026 年 6 月启动的第一批融资规模为 35b，用于超过 1GW 的基础设施：金融合作方购买 AI 机架，再由客户通过五年租赁取得算力；Broadcom 提供技术，并为租赁义务提供 backstop。（FY2026 Q3 10-Q）

这解决的是另一种真实问题：

客户认为未来模型收入足以支持大规模算力
但当前现金流 < 当前需要支付的基础设施投资
→ 引入金融资本购买设备
→ 客户用未来五年现金流支付租金
→ Broadcom 提前扩大可交付的芯片和网络规模

五年是租赁期限，不是已经证明的客户回本期。客户是否真正回本，仍取决于模型收入、设备利用率、电力成本和硬件淘汰速度。

Broadcom 的最大潜在 backstop 在全部机架部署后约为 29b。客户违约时，公司承担的责任与未付租赁余额及设备出售价值有关；截至 Q3 尚未发生付款，相关担保公允价值不重大。不能把 29b 当成已经发生的损失，也不能因为没有当期付款就忽略它。

这个案例改变了 AVGO 需求分析：

• 现金充足的 hyperscaler 订单，主要是技术和项目执行风险；
• 依靠项目融资的前沿模型客户，还增加信用、融资成本和设备残值风险；
• 在 AI 景气下降时，客户收入和专用设备残值可能同时下降。

因此，协议中的 GW 表示计划提供的算力规模，并不等于已经回款的芯片需求。付款主体、租赁期限、客户现金流和 Broadcom 的担保责任共同决定这类收入附带的融资风险。

从立项到收入：Broadcom 的生产与交付周期¶

一颗定制 XPU 需要经过哪些阶段¶

Broadcom 的公开材料强调，它的 ASIC 平台可以组合客户 IP、Broadcom IP 和第三方 IP，并提供先进制程和封装选择。这能缩短客户从架构到量产的路径，但不会消除流片失败、良率、HBM、封装产能或软件迁移风险。（Broadcom ASIC 平台）

为什么第一代慢，后续代际可能更快¶

第一代最难，因为硬件、编译器、模型和机架同时变化。一旦形成稳定接口，后续产品可以复用：

• 已验证的 SerDes、HBM PHY 和 die-to-die IP；
• 编译器、运行时和模型迁移工具；
• 机架尺寸、电力、散热和网络接口；
• 验证环境、测试向量和供应链流程。

Meta 能把新一代发布时间压缩到六个月以内，依赖的正是模块化和复用；这不是说每六个月从零设计一颗全新芯片。Google 第一批可用 TPU 能在 22 天内进入生产，也依赖前置的软件和系统准备。

所以，Broadcom 的商业价值很大一部分来自“第一次做对”以及“下一代不必重新开始”。先进芯片如果需要重新流片，损失的不只是制造费，还包括一整个产品窗口和客户数据中心部署计划。

收入为什么会跳跃，而不是平滑增长¶

设计阶段投入工程人员，量产阶段才集中出货。一个大型客户从样片转入量产，季度收入可以突然增加；客户推迟机架、电力或软件部署，同样会让订单集中后移。

Q3 前五大终端客户占集团收入约 55%，一年前约 40%；一个半导体分销客户占集团收入 50%。公司也明确提示，AI 与无线客户的大订单或延期会放大季度波动。（FY2026 Q3 10-Q）

因此，多年协议提高可见度，却不等于每季平均确认收入。真正有用的项目状态是：

engagement < design win < tape-out < sample < production release < volume deployment

越靠左，技术选择权越多、收入确定性越低；越靠右，收入越确定，但市场通常也越早计价。

Broadcom 的成本结构与盈利模式¶

芯片业务的成本不是只有晶圆¶

Broadcom 将大多数先进芯片制造外包。FY2025 10-K 说明，其大部分前端晶圆由外部晶圆厂完成，组装与测试也主要由合同制造商承担；FY2026 前三季度，合同制造商生产的晶圆约 95% 来自台积电。（FY2025 10-K；FY2026 Q3 10-Q）

成本可以分成四层：

公司披露，产品销售成本主要包括晶圆、其他材料、组装与测试，以及制造人员、设备、质量、保修和库存减值。研发费用则包括工程人员、项目材料、顾问、原型和设计工具计算成本。（FY2025 10-K）

这是一种“轻晶圆厂、重研发和供应链承诺”的模式。Broadcom 不需要自己建设最先进逻辑晶圆厂，所以财务报表上的 CapEx 相对低；但它仍然依赖先进制程、HBM 和封装产能，也可能提前签订大量采购义务。低 CapEx 不等于没有资本风险。

本季度半导体分部怎样赚钱¶

来源：FY2026 Q3 10-Q，分部披露及本文计算。分部利润不含集团未分摊的股权激励、收购无形资产摊销、重组等费用，不能等同于 GAAP 集团营业利润。

半导体分部能够取得高利润率，主要有四个原因：

1. 客户购买高价值 IP 和执行能力，而不只是晶圆。 芯片价格包含架构实现、验证、接口和量产风险的价值。
2. 前期研发可以被大规模出货摊薄。 设计完成后，多卖一颗芯片仍有晶圆、HBM、封装和测试成本，但不需要等比例增加全部研发团队。
3. 同一底层 IP 可以跨项目和代际复用。 SerDes、HBM PHY、封装和验证工具不是每个客户从零开发。
4. 客户数量少、订单大，销售费用低。 本季度分部销售及管理费用不到收入的 1%，但集中度风险也因此很高。

需要避免一个误解：67% 的分部毛利率不代表定制 XPU 本身也恰好是 67%。公司没有披露定制加速器、网络、无线和其他半导体各自利润率。集团 69% 的 GAAP 毛利率还受高毛利软件影响；公司明确表示，半导体收入占比提高会对集团毛利率形成组合压力。（FY2026 Q3 10-Q）

盈利来自三次，而不是一次设计费¶

Broadcom 的公开会计政策把 NRE（一次性工程开发）安排归入 subscriptions and services，但没有单独披露 AI 项目的 NRE 收入。芯片和半导体系统出货则计入产品收入。（FY2025 10-K）

从经济实质看，一项成功项目可以产生三层利润：

1. 开发阶段：客户通过 NRE、里程碑付款或其他合同安排分担部分开发成本。具体结构未披露，不能假设 Broadcom 已完全转移研发风险。
2. 量产阶段：每颗 XPU、交换芯片、网卡或连接器件产生产品毛利。对规模项目，这通常比一次性设计费更重要。
3. 多代扩展：客户下一代继续采用 Broadcom，既产生新工程收入，也让既有 IP、工具和供应链再次变现。

可以把长期利润写成：

项目累计利润
≈ 开发与 IP 收入
 + Σ（每代出货量 × 每单位毛利）
 + 配套网络与连接毛利
 - 前期研发与失败项目成本
 - 供应、信用和残值损失

项目累计利润并不只由单代芯片售价决定，还取决于客户工作负载、软件迁移、量产规模和多代续约。一次 design win 本身尚未产生完整的量产经济价值。

现金流与采购、担保承诺并存¶

Q3 经营现金流为 14.197b，FCF 为 13.665b，FCF 利润率约 46%。资产轻和高利润软件让大量会计利润转化为现金。（FY2026 Q3 财报）

但未来义务在扩大。Q3 末公司披露的不可取消采购承诺合计 126.821b，主要在 FY2027 和 FY2028 到期；这类承诺主要用于购买库存等商品或服务，财报没有说全部属于 AI。再加上 AI XPV 的潜在 backstop，Broadcom 正从单纯的芯片设计供应商，部分转向为供应链和客户融资承担风险。（FY2026 Q3 10-Q）

Broadcom 的竞争优势到底是什么¶

1. 它承担的是架构定义与晶圆制造之间的芯片实现¶

大型云客户可以从自己的模型和生产日志中设计一套专用计算架构，但“已经决定需要多少矩阵单元和片上内存”不等于“已经有一颗能制造的芯片”。两者之间至少还有以下工作：

计算模块和接口 IP 集成
→ 逻辑验证与可测试性设计
→ 综合、布局布线、时钟和供电网络设计
→ 在目标频率下完成时序、功耗和面积收敛
→ HBM、SerDes、die-to-die 等高速接口验证
→ 计算 die、I/O die 和 HBM 的封装设计
→ tape-out、样片测试、良率爬坡和量产导入

Broadcom 主要竞争的就是这一段。它不是用 AI 模型替客户决定芯片架构，也不是像台积电一样出售晶圆制造产能；它提供的是经过验证的接口 IP、设计与验证流程、封装方案和量产工程。其 ASIC 平台可以组合客户 IP、Broadcom IP 和第三方 IP，并支持先进制程与封装。（Broadcom ASIC 平台）

这段工作的结果可以直接测量：芯片是否达到频率、功耗和面积目标，是否需要重新流片，HBM 与 I/O 是否稳定，封装良率是否合格，以及能否在客户的数据中心建设窗口前进入量产。Broadcom 的优势如果存在，最终应表现为更高的一次流片成功率、更短的量产导入时间，或同一功耗和封装约束下更高的有效性能；公司没有逐项披露这些指标，因此不能只凭“工程能力强”判断优势大小。

2. SerDes、内存、封装和网络可以复用¶

Broadcom 不只做计算逻辑。它在自定义 XPU 中拥有 HBM PHY、网络 I/O、die-to-die 和封装能力，在机架外又销售以太网交换、DSP、光连接、PCIe 和网卡。

其 3.5D XDSiP 平台把 2.5D 与 3D 堆叠结合，公开方案可集成多块计算 die、I/O die 和最多 12 组 HBM。Broadcom 宣称其设计流程已验证关键 SerDes、HBM 和 die-to-die IP，并在 2026 年开始生产出货。（Broadcom 3.5D XDSiP）

这形成两个优势：

• 客户不必分别协调所有底层接口，项目风险和上市时间下降；
• Broadcom 每赢得一个 XPU 项目，就有机会在网络和连接环节增加单个集群的内容价值。

第二点只是交叉销售机会，不是自动捆绑。客户仍可使用其他供应商的交换芯片、光模块或网卡。

3. 多代合作形成高转换成本¶

定制芯片的转换成本不只来自合同。客户的软件、模型、机架、测试和供应链已经围绕某套接口建立；更换设计伙伴意味着重新验证 IP、工具、封装和量产流程。

Meta 的多代 MTIA 合作和 Google 最长到 2031 年的 TPU 协议，说明客户购买的是路线图，而非一次性芯片。Broadcom 还披露 Q3 末剩余履约义务约 179.2b，其中包含长期定制 AI 加速器合同；但该数字同时包含半导体和软件合同，不能全部视为 AI backlog。（FY2026 Q3 10-Q）

多代关系提高留存，却不是不可打破。客户可能把更多后端能力内化、采用 customer-owned tooling、转向 Marvell 等定制芯片供应商，或回到 NVIDIA、AMD 等通用平台。Broadcom 自己也在风险因素中把客户自研和自有工具列为需求风险。

4. 资产轻让工程价值更容易转化为现金¶

Broadcom 把先进逻辑制造和大部分封装测试外包，不需要为每一代制程建设晶圆厂。需求上升时，公司的资本主要投向研发、预付款、库存和供应承诺，而不是厂房设备；这解释了其高 FCF 转化。

但资产轻同时制造了单点依赖。FY2026 前三季度，外部合同制造晶圆约 95% 来自台积电，超过四分之三制造材料采购来自五家供应商。Broadcom 的规模可能帮助争取产能，却不能消除台积电、HBM 和先进封装的约束。（FY2026 Q3 10-Q）

5. Broadcom 的壁垒不是 CUDA，而是专用芯片实现¶

NVIDIA 自己定义 GPU，并拥有从 CUDA 到加速库、通信库和推理引擎的公共软件平台；它把一次平台投资分摊给大量客户和开发者。Broadcom 没有对应的通用软件生态，也通常不拥有客户的模型编译器。客户要自行证明某类工作负载值得固化，并定义 XPU 的计算架构；Broadcom 的工作是完成接口集成、物理设计、验证、封装和量产导入，使这套架构在给定功耗、面积、频率和交付时间内成为可采购的芯片。

这意味着 Broadcom 的壁垒和限制来自同一个事实：每个项目都深度嵌入客户路线。项目进入量产和多代迭代后，工程转换成本很高；但客户工作负载改变、compiler 落后或决定自研后端时，Broadcom 不能用一个公共 CUDA 生态自动留住客户。

NVIDIA 的核心优势仍是通用硬件、CUDA 软件生态和快速部署：客户不知道三年后模型会怎样变化时，通用平台的选择权很有价值。Broadcom 的优势则出现在另一端：客户已经非常了解负载，并愿意用较低灵活性换取特定任务的 TCO、功耗和供应控制。

因此，两者并非简单零和关系：

定制 XPU 并不适用于所有 AI 计算，而更适合表格右侧的工作负载。推理和推荐通常比前沿训练更容易满足这些条件，但大规模训练在架构稳定、客户规模足够时同样可以采用定制 XPU。

总结¶

FY2026 Q3 的收入结构显示，Broadcom 当前的增长增量高度集中于 AI 半导体。少数大型客户正在把已经存在的巨量 AI 工作负载固化为定制芯片，并同时扩建网络；Broadcom 提供这些 XPU 所需的接口 IP、物理实现、验证、封装和量产导入，并争取配套网络芯片订单。

公开可验证的需求来源包括 Meta 推荐和广告、Google 搜索与云 TPU 这类已经运行、可测量、可重复的负载。它们解释了客户为什么愿意为单位成本、电力、延迟或供应控制牺牲部分通用性，以及大规模部署和多代路线怎样摊薄开发成本。

XPU 不需要永不过时，但必须在过时之前回本。公开资料证明了 Broadcom 的芯片收入、量产协议和现金流正在快速增长，也披露了采购承诺与融资担保；它没有披露单个客户项目的完整成本、节省额、利用率和实际回本期。本文到此只解释需求形成和利润产生的机制，不据此推演未来订单或投资结论。

Comments