1. 引言：LLM推理的“算力焦虑”与ASIC崛起

1.1. 背景与市场驱动力

1.1.1. AI 计算范式的根本切换：从“训练为王”到“推理为王”

2025–2026 年正在成为“推理规模化元年”。这一转变不是修辞，而是真金白银的数据支撑：推理市场正在超越训练市场，并成为 AI 基础设施支出的绝对主体。 据 MarketsandMarkets 数据，全球 AI 推理市场规模在 2025 年已达约 1,061 亿美元，预计以 19.2% 的 CAGR 增长至 2030 年的 2,550 亿美元 [1]。而 AI 推理芯片市场增速更为凶狠——Verified Market Research 预测该细分市场将以 28.25% 的 CAGR 从 2026 年增长至 2032 年，达到 1,673 亿美元 [2]。更为关键的是，作为“推理工作负载”核心载体的 AI 服务器 ASIC，其出货量在 2026 年预计增长约 45%，远超数据中心 GPU 出货量 16% 的增幅 [3]。

工作负载内部的此消彼长同样剧烈。McKinsey 估计 2026 年训练与推理的数据中心电力需求将形成 50:50 的均势 [4]；而到 2026 年，推理已占全部 AI 算力消耗的约三分之二 [5]。Gartner 更预测，到 2025 年，80% 的 AI 基础设施支出将投向推理而非训练 [6]。背后的逻辑异常朴素：模型只训练一次，但推理请求以百万次计。

AI 算力支出结构正在发生根本性变化。训练是 CAPEX（资本支出），推理是 OPEX（运营支出）——而 OPEX 会随着用户增长线性甚至超线性放大。当 OpenAI 的 GPT-4 级别模型每百万 token 的推理成本从 2022 年末的约 $20 骤降至 2025 年末的约$0.40 时 [7]，竞争便从“谁能训出更好的模型”切换为 “谁能以更低成本服务更多 token”。

---

1.1.2. 推理成本：为什么它成了核心矛盾

1.1.2.1. Token 经济学：成本下降，但总量爆炸

LLM 推理成本正以每年约 10 倍的速度下降。a16z 的测算显示，同等性能水平的模型，推理成本从 2021 年的 $60/百万 token 降至 2025 年的$0.06/百万 token [8]。但这种下降被更快的用量增长所抵消——Gartner 指出，企业在规模化 AI 时面临 500%–1000% 的成本估算误差，单 token 成本虽在下降，但总推理支出因 AI 工作负载量增长 31 倍而持续攀升 [9]。

这意味着：推理成本优化不是一次性的效率提升，而是持续性的生存竞争。每降低 1% 的单 token 成本，在数十亿 token 级别的服务规模下，就是数百万美元的利润差。用一位行业分析师的话来说：“训练是军备竞赛，推理是消耗战。”

1.1.2.2. 推理 vs. 训练：完全不同的硬件需求

从业者容易陷入一个思维陷阱：认为“GPU 既能训练又能推理，所以是最好的 AI 芯片”。但深入分析会发现，训练和推理对硬件的需求几乎正交：

维度	训练	推理
计算模式	大规模并行矩阵乘法	Prefill: 大矩阵乘法；Decode: 逐 token 串行
算术强度	高（计算密集）	Prefill: 高；Decode: 极低（访存密集）
Batch 特征	大 batch，高吞吐	Decode 阶段 batch 受限
内存需求	权重+优化器状态+梯度+激活	权重+KV Cache（随上下文长度线性增长）
延迟敏感度	不敏感（小时/天级）	极度敏感（毫秒级 TTFT，数十毫秒级 TPOT）
硬件利用率	通常 60–90%	Decode 阶段 GPU 计算利用率常低于 30%
通信模式	All-reduce 密集	张量并行 all-reduce + KV Cache 传输

推理不是单一 workload，而是两个截然不同的阶段——Prefill 和 Decode——它们对硬件有完全相反的需求 [10]。

---

1.1.3. GPU 的架构短板：为什么“通用”反而成了“将就”

1.1.3.1. Roofline 模型揭示的真相

用 Roofline 模型分析 LLM 推理，结论清晰且残酷 [11]：

• Prefill 阶段：处理整个输入 prompt，本质上是并行的大矩阵乘法，算术强度高，落在 Roofline 的 compute-bound 区域。此时 GPU 的大量 Tensor Core 得到充分利用。
• Decode 阶段：逐 token 自回归生成，每次生成需要加载全部模型权重和 KV Cache 进行矩阵-向量乘法（GEMV），算术强度极低，远远落在 Roofline 的 memory-bound 区域。此时 GPU 90% 以上的计算单元处于空闲等待状态，瓶颈完全在 HBM 带宽上 [633]。

这就是为什么 NVIDIA H200 相比 H100，在计算能力完全不变的情况下，仅靠 HBM 容量从 80GB 提升到 141GB、带宽从 3.35 TB/s 提升到 4.8 TB/s，就能在 Llama 2 70B 推理上获得 1.9 倍的性能提升 [12]。这不是计算问题，这是内存带宽问题。

1.1.3.2. Memory Wall：AI 计算的真正瓶颈

过去十年，AI 芯片的算力增长了约 80 倍，而内存带宽仅增长了约 17 倍 [13]。这个不断扩大的“剪刀差”就是著名的 Memory Wall。

在 LLM 推理的 Decode 阶段，这个矛盾被放大到极致：

• 以 H100 为例：2,000 TFLOPS 的 FP8 算力 vs. 3.35 TB/s 的 HBM 带宽
• 每生成一个 token，需要从 HBM 读取全部模型权重（例如 Llama 2 70B 约 140GB FP16）
• 1,000 TFLOPS 的计算能力中，实际用于 Decode 的可能不到 5%
• GPUs 的 HBM 带宽利用率在 Decode 阶段通常也只有 40–70%，因为访问模式是随机的小粒度读取

IEEE CLOUD 2025 的一篇论文更直接指出：即使在大 batch 的 Decode 场景下，LLM 推理仍然 memory-bound，DRAM 带宽饱和是主要瓶颈，大量计算资源被闲置 [14]。

1.1.3.3. GPU 架构的“原罪”：为训练而生，为推理将就

GPU 的架构设计哲学根植于图形渲染和 HPC 训练的并行计算范式：

1. SIMT 执行模型：warp 调度、分支预测、寄存器文件——这些为通用并行计算设计的机制在 Decode 阶段不但无用，反而增加了调度开销和功耗。
2. 多级缓存层级：L1/L2 cache 在 LLM 推理中命中率极低（模型权重远大于 cache 容量），每次访问都穿透到 HBM，缓存反而成为延迟的来源。
3. HBM 的物理限制：HBM 虽然带宽高，但延迟并不低（约 100–300ns），且容量受限于 3D 堆叠层数和封装面积。HBM3e 单 stack 目前最高 36GB，8-stack 配置 288GB——对于万亿参数模型或超长上下文推理，远远不够。
4. 非确定性执行：GPU 的动态调度导致 token 生成延迟的不确定性（jitter），在实时语音对话、Agent 等场景中，这种不可预测性直接影响用户体验。

一个讽刺的事实是：花了 3 万美元买一张 H100，在 Decode 阶段可能只用了不到 500 美元的算力，其余都在等内存。 这就是 ASIC 兴起的原动力。

---

1.1.4. ASIC 的崛起逻辑：从“通用”到“专用”的必然

1.1.4.1. 为什么是现在？

ASIC 在 AI 领域并非新概念。Google TPU v1 早在 2015 年就已部署。但 LLM 推理专用 ASIC 在 2024–2026 年集中爆发，背后有四个结构性因素：

第一，推理工作负载的收敛。 当 90% 的 LLM 推理请求都落在 Transformer 架构（确切说是 Decoder-only Transformer）上时，硬件优化的目标空间变得足够窄，ASIC 的“专用”不再意味着“狭隘”。

第二，推理规模的临界点。 当单模型推理需要数百乃至数千张 GPU、年化推理成本达到数十亿美元时，即使 ASIC 的 NRE（一次性工程费用）高达 5–10 亿美元，也能在 12–18 个月内通过 TCO 节省收回。

第三，HBM 供应链的卡脖子。 HBM 被 SK 海力士、三星、美光三家垄断，产能严重不足。2025 年 HBM 供应缺口约 28%，HBM 价格较标准 DRAM 高出 10–20 倍 [15]。这迫使芯片设计者思考：有没有可能用 SRAM 甚至其他存储介质绕过 HBM 瓶颈？

第四，CUDA 锁定开始松动。 PyTorch 2.x 的 torch.compile、MLIR、Triton、OpenAI 的 Triton 语言、vLLM 等推理框架的兴起，使得模型从 CUDA 迁移到其他后端的成本大幅降低。虽然 CUDA 仍是 NVIDIA 最大的护城河，但护城河正在被填平。

1.1.4.2. ASIC 的架构自由度：不再被 GPU 范式束缚

当不受“GPU 必须兼容图形渲染”这一历史包袱约束时，AI ASIC 可以在多个维度上做激进创新：

架构维度	GPU 范式	ASIC 可探索方向
计算单元	SIMT + Tensor Core	纯 systolic array、dataflow、spatial architecture、in-memory compute
存储层级	HBM 为主，SRAM 为 cache	SRAM-centric（Groq）、晶圆级 SRAM（Cerebras）、数字存内计算（d-Matrix）
执行模型	动态调度、非确定性	编译时静态调度、确定性执行
互联	NVLink + InfiniBand	自研片间 fabric、晶圆级片上互联、光学互联
精度	FP32/FP16/BF16/FP8/FP4	针对特定模型蒸馏的混合精度、甚至 INT4/INT8 专用通路
软件栈	CUDA 全家桶	直接对接 PyTorch/MLIR，跳过 CUDA 层

1.1.4.3. 核心矛盾的重定义：FLOPS 不再是第一指标

LLM 推理 ASIC 的兴起本质上是行业对“什么才是推理芯片最重要的指标”这一问题的重新思考：

• 传统 GPU 思维：越多 FLOPS 越好 → 堆 Tensor Core → 算力利用率低
• ASIC 新思维：越高 token/秒/瓦越好 → 消除数据移动瓶颈 → 带宽利用率最大化

在 Decode 阶段，性能方程是：

Token/s ≈ Memory Bandwidth (TB/s) / Model Weight per Token (GB)

而不是：

Token/s ≈ FLOPS / FLOPs per Token

因为 Decode 阶段的算术强度太低，远低于任何现代加速器的“Roofline ridge point”（计算吞吐/带宽的比值） [16]。这意味着增加 FLOPS 对 Decode 性能的提升几乎为零——除非同时增加内存带宽。

这就是为什么 Groq LPU 的 80 TB/s 片上 SRAM 带宽远胜于 H100 的 3.35 TB/s HBM 带宽 [17]，为什么 Cerebras WSE-3 的 21 PB/s 片上带宽可以让其推理速度达到 GPU 方案的 10–70 倍 [18]。这不是“谁家的芯片更快”的竞赛，而是“谁更接近零数据移动成本”的竞赛。

---

1.1.5. 市场结构：三类玩家，三种逻辑

当前 LLM 推理芯片市场已经形成三类参与者，各自的战略逻辑和生存法则截然不同：

1.1.5.1. 独立 ASIC 创业公司（Groq、Cerebras、d-Matrix、Etched、Taalas、SambaNova）

核心逻辑：用架构创新换取对 GPU 的 10 倍性能/效率优势，在特定推理场景中建立“最优解”地位。

竞争优势：不受 legacy 架构约束，可以针对 Transformer/LLM 推理做端到端优化。SRAM-centric、wafer-scale、in-memory compute 等激进路线皆出自此类公司。

核心风险：软件生态从零建设、客户导入周期长、模型架构变化可能使专用硬件过时、资金链压力大。NVIDIA 在 2025 年 12 月以 $200 亿收购 Groq 的技术资产和团队，某种程度上正是对这种“创新但难以独立生存”困境的注解 [19]。

1.1.5.2. 云厂商自研 ASIC（Google TPU、Microsoft Maia、Meta MTIA、AWS Trainium/Inferentia、OpenAI/Broadcom Titan）

核心逻辑：不是为了卖芯片，而是为了降低内部推理成本、保障算力供应、实现硬件-模型协同优化。

竞争优势：有真实负载、真实数据、真实部署环境，不需要说服“客户”迁移——自己就是最大的客户。Google TPU 从 v6e（Trillium）到 v7（Ironwood）再到 v8t/v8i（训练/推理分叉），代际演进速度和规模都是独立 ASIC 公司难以企及的 [20]。OpenAI 与 Broadcom 合作开发 Titan 芯片，目标 2026 年下半年量产，首期部署 10GW 推理算力 [21]。

核心风险：自研芯片的技术成果不一定能变成开放市场产品；对单一工作负载的过度优化可能导致灵活性不足；如果内部推理需求不及预期，投入可能沉没。

1.1.5.3. NVIDIA：既要守城，又要攻城

NVIDIA 的策略最为复杂：它既是 GPU 的既得利益者（推理市场份额约 74% [1208]），又通过收购 Groq 获得了 LPU 技术，计划在 Vera Rubin 平台中整合 GPU + LPU 形成 hybrid inference architecture [22]。

核心逻辑：用 GPU（HBM-centric）覆盖 Prefill 和训练，用 LPU（SRAM-centric）覆盖 Decode——不必在不同架构之间二选一，而是全部拥有。

核心风险：反垄断审查、整合难度、ASIC 客户（云厂商）的“去 NVIDIA 化”趋势不可逆转。

---

1.1.6. 关键趋势：Prefill/Decode 分治与存储层级的重构

1.1.6.1. Disaggregated Inference：推理架构的“拆分”趋势

越来越多的研究和工程实践表明，将 Prefill 和 Decode 部署在同一 GPU 上是一种资源浪费 [23]：

• Prefill 吃计算、吃大 batch、吃高并行度
• Decode 吃内存带宽、吃低延迟、吃 KV Cache 容量

两者的资源需求几乎不重叠，却在传统架构中共享同一硬件。Disaggregated inference 将 Prefill 和 Decode 分离到不同的硬件池：

• Prefill pool：GPU 或高算力 ASIC，处理大矩阵乘法，生成 KV Cache
• Decode pool：SRAM-centric ASIC（如 LPU），高速生成 token
• KV Cache 传输：通过高速互联（如 NVLink、PCIe 6.0、RDMA 网络）在两者之间传递

这一架构趋势直接催生了“专用 Prefill 芯片”和“专用 Decode 芯片”的分化，也是 NVIDIA 收购 Groq 的战略逻辑——Rubin GPU 做 Prefill，Groq LPU 做 Decode，各司其职 [607]。

1.1.6.2. SRAM 与 HBM 的长期竞争：不是替代，而是分层

当前行业内存在一种“SRAM vs HBM 二选一”的叙事，但实际情况更可能是分层共存：

• SRAM：存放热权重层、KV Cache 的热数据、频繁访问的 attention 参数——延迟敏感、带宽需求高的数据
• HBM：存放完整模型权重、KV Cache 冷数据——容量需求大、访问频率相对低的数据
• PCIe 扩展 DDR / 远端内存：存放超长上下文的 KV Cache、MoE 的冷 Expert 参数——极致容量、低成本的冷存储

Google TPU v8 的分叉策略（v8t 训练 + v8i 推理）和 NVIDIA LPX 的 GPU+LPU 混合架构，本质上都是在探索这种存储层级的最优配置 [24]。SRAM 的密度仅为 DRAM 的 1/10 左右，成本高出一个数量级 [749]，因此不可能完全替代 HBM；但 HBM 的延迟和带宽劣势又无法满足 Decode 阶段的极致需求。未来的芯片更可能走向“SRAM + HBM + PCIe/DDR 扩展层”的混合层级，以在带宽、容量、成本之间取得最优平衡。

1.1.6.3. “矿机化”的推理 Appliance：标准化 vs. 定制化

随着推理成为 AI 基础设施的最大支出项，行业正在出现类似比特币矿机一样的“标准化推理 appliance”趋势：

• 机柜级预集成（如 NVIDIA LPX、Cerebras CS-3、Google TPU Pod）
• 液冷/浸没式冷却
• 标准化 API 接口
• 按 token 计费而非按硬件销售

这可能导致未来 AI 推理的竞争从“芯片 vs. 芯片”升级为“推理工厂 vs. 推理工厂”——最终赢家可能不是卖芯片的，而是以最低成本产出高质量 token 的垂直一体化服务商。

---

1.1.7. 小结

LLM 推理专用 ASIC 的兴起不是偶然的技术猎奇，而是 AI 产业从“模型能力竞赛”转向“推理成本竞赛”的必然结果。GPU 的通用性在训练阶段是优势，在推理的 Decode 阶段却成为效率的枷锁。Memory Wall 是最根本的物理约束，而 ASIC 通过 SRAM-centric、wafer-scale、in-memory compute 等架构路线，试图从不同角度绕过这堵墙。接下来的章节将逐一深入剖析每一家 ASIC 厂商的技术路线、商业策略和生存前景，并在此基础上构建完整的横向对比框架。

2. 独立商用芯片类深度分析

2.1. Groq LPU / NVIDIA LPX：SRAM-Centric 的确定性推理引擎

Groq 的 Language Processing Unit（LPU）是当前 LLM 推理领域最激进、也最具争议的架构创新。它并非在 GPU 基础上修修补补，而是从第一性原理出发，完全倒置了硬件与软件的关系——先设计编译器，再根据编译器生成的确定性执行图来定义芯片微架构 [79]。这种“软件定义硬件”的哲学，使得 LPU 能够在 Decode 阶段实现 GPU 难以企及的低延迟、高能效和零抖动，但也因此被锁定在 SRAM 容量、业务范畴和生态灵活性上。随着 NVIDIA 以 200 亿美元获得其技术许可并将其深度整合至 Vera Rubin 平台，LPU 已经从一家独立公司的差异化武器，蜕变为 GPU 巨头异构推理战略中的关键组件。

2.1.1. TSP 微架构与 SRAM-Centric 设计

LPU 的底层硅架构是 Tensor Streaming Processor（TSP），一种功能切片（Functional Slicing）的流式处理器 [1359]。TSP 将传统多核架构“由内向外翻转”：片上功能单元不再封装为独立核心，而是按类型排列为横跨芯片的水平切片——矩阵执行模块（MXM）、向量执行模块（VXM）、数据重排模块（SXM）、片上存储模块（MEM）和指令控制单元（ICU）——数据以 320 字节向量为单位，按编译器预定的时钟周期在这些切片间顺序流动，形成一条物理流水线 [1493]。每个切片由 20 个 tile 垂直堆叠，每个 tile 以 SIMD 方式处理 16 个元素，整个芯片相当于一个 320 字节 SIMD 单元、20 周期流水线的单一大核心 [1356]。这种设计使得芯片内没有多核同步、没有缓存一致性协议、也没有动态调度器，一切数据移动和计算时机都在编译期确定。

存储器是 LPU 最根本的差异化所在。LPU 完全放弃 HBM 和外部 DRAM，转而使用单层、全局共享的 scratchpad SRAM 作为权重的唯一驻留地 [1484]。第一代 TSP 片上 SRAM 为 230 MB，第二代 Groq 3 LPU 增至 500 MB [1289]。这种做法并非对容量的无视，而是对 LLM 推理 Decode 阶段物理瓶颈的精确回应：Decode 本质是 memory-bound 的矩阵-向量乘法（GEMV），每生成一个 token 都需从内存读取全部权重，而 GPU 的 HBM 带宽（H100 为 3.35 TB/s）严重不足，导致 90% 以上的计算单元空转。Groq 用 SRAM 将片上带宽推至 80 TB/s（第一代）乃至 150 TB/s（LPX 单 chip），是 HBM 的 20–45 倍，同时访问延迟从 HBM 的 300–500 ns 降至约 1 ns [79]。这种“带宽换容量”的取舍，使得 LPU 在 batch-size-1 的 Decode 场景下，能使计算单元几乎 100% 被喂饱，而 GPU 则需要大 batch 来摊销 HBM 延迟。

但代价是残酷的：单 chip 仅 230–500 MB 的 SRAM 无法容纳任何现代 LLM 的全部权重。以 Llama 2 70B 为例，FP8 精度权重约 70 GB，需要约 576 颗 LPU 通过片间互联拼成一个逻辑上的“大核心” [77]。这种规模化的拼装正是 LPU 片间扩展技术的核心挑战与成就。

2.1.2. 确定性执行：消除一切运行时变数

LPU 的确定性执行是其最根本的架构特征，也是与 GPU 最本质的区别。它从硬件层面移除了所有非确定性来源：没有缓存（因此无缓存未命中）、没有分支预测器、没有乱序执行、没有动态调度器、没有中断和上下文切换 [148]。GroqFlow 编译器在编译时预计算整个执行图——包括每一条指令、每一个内存访问、每一次芯片间数据包传输——精确到具体时钟周期 [75]。这样，同一个模型、同一个输入，在 LPU 上运行 1000 次，每次执行时间完全相同，纳秒级一致。

这种确定性直接转化为用户体验的质变。在生产 A/B 测试中，将客户支持聊天机器人从 H100 切换到 Groq，用户满意度提升了 34% [881]，关键原因并非平均延迟更低，而是延迟零抖动——每次对话都“感觉流畅”，没有 GPU 动态调度带来的尾延迟毛刺。这种可预测性也使得 Groq 成为 2025 年 Gartner Cool Vendor in AI Infrastructure 报告中特别强调的“所见即所得”性能 [90]。

2.1.3. 低延迟 Token Generation：Decode 阶段的“暴力美学”

LPU 在 Decode 阶段的速度优势源于三个层面的叠加：（1）SRAM 带宽比 HBM 高 10–20 倍，权重读取不再成为瓶颈；（2）确定性流水线消除了调度开销，每个时钟周期均为有效工作；（3）编译器启用的张量并行（Tensor Parallelism）将单层矩阵乘法拆分到多颗芯片，权重分片驻留，实时汇总结果，无运行时同步开销 [75]。

独立评测数据充分验证了这种优势。在 Artificial Analysis 的基准测试中，Groq LPU 在 Llama 2 70B 上跑出 241–300 tok/s，是 H100（30–40 tok/s）的约 7–10 倍 [1365]；Llama 3 70B 达到 280–300 tok/s，较 H100 的 60–100 tok/s 领先 3–5 倍 [1366]。在应用了投机解码（speculative decoding）后，Llama 3.3 70B 的生成速度飙升至 1,660–1,665 tok/s，因为 LPU 可以将 draft model 生成的候选序列在 SRAM 分布式权重中几乎即时验证，而 GPU 的 verification 步骤受限于 HBM 带宽 [1375]。MoE 模型（如 Mixtral 8x7B）在 Groq 上达到 430–727 tok/s，是 GPU 的 6–9 倍，因为 expert 切换所需的频繁权重加载在 SRAM 上几乎无延迟 [1477]。对于小模型，Groq 的 Gemma 7B 甚至跑出 2,800 tok/s 的公开记录 [1294]。

但必须指出，这些速度是在单请求、低 batch 条件下取得的，且以数百颗芯片的庞大系统为代价。LPU 并非为高吞吐批量处理而生——那正是 GPU 的领地。

2.1.4. 片间扩展：RealScale 与 Dragonfly 拓扑

要将数百颗 LPU 整合成一个逻辑上的“单核”，必须依靠同样确定性的片间互联。Groq 的 RealScale™ 技术是一种专有的点对点、软件定义互联 fabric [1292]。它与片上架构一脉相承：编译器将网络链路的发送和接收视为一等功能单元，预先调度每个数据包的路由和到达时刻，硬件不做任何自适应路由或仲裁 [1292]。RealScale 采用 plesiosynchronous 协议，能够消除芯片间的自然时钟漂移，使数百颗 LPU 对齐为单一同步核心，从而支持跨芯片张量并行 [74]。

网络拓扑采用 Dragonfly（或 Dragonfly-plus） 直接 mesh，无外部交换机，每颗芯片既是计算节点也是网络交换机，消除了传统交换机的额外跳数和排队延迟 [76]。一个 8 芯片的 GroqNode 内全互联，单跳可达；264 芯片系统内任意芯片对最多 3 跳，端到端延迟约 1.8 µs [1292]；576 芯片系统全局延迟 <3 µs，可访问约 2 TB 的聚合 SRAM 空间 [1302]。在 Groq 3 LPX 中，单芯片配备 96 条 112 Gbps 的 C2C 链路，双向总带宽约 2.5 TB/s，机架级互联带宽达 640 TB/s [623]。这种高带宽、低跳数、确定性的互联，使得编译器能够将大模型权重分片静态映射到所有芯片，并在运行时实现零同步开销的张量并行和流水线并行 [92]。

2.1.5. Batch Size 与用户并发：为“即时响应”而生

LPU 的架构站位非常清晰：batch-1 性能最优，小 batch 效率极高，而大 batch 聚合吞吐让步于 GPU。在 batch=1 的图像推理中，Groq 曾报告比 NVIDIA V100 快 17.6 倍，且性能不随 batch 减小而退化 [184]。对于 LLM 的单用户实时交互，LPU 能在 80 ms 左右的 TTFT 和 250+ tok/s 的生成速度下，保持无抖动，这正是语音助手、代码补全、Agent 循环等场景的刚需 [881]。

然而，当需要服务成百上千个并发用户时，LPU 的吞吐量优势便不再明显。NVIDIA B200 单 GPU 可在 Llama 3.3 70B 上实现 60,000 tok/s 的聚合吞吐，或同时服务 200 个用户、每用户 50 tok/s [1455]。LPU 则通过 GroqCloud 的速率限制和排队机制来管理并发，其免费层和付费层的 RPM/TPM 上限较严格，更适合总并发量可控的场景 [1465]。因此，LPU 与 GPU 并非替代关系，而是互补：LPU 负责延迟敏感的实时交互，GPU 负责高吞吐的批量任务。Spheron 的分析建议，对于 7B–70B 密集 LLM 推理，可将约 25% 的算力预算分配给 LPU，75% 分配给 GPU [91]。

2.1.6. NVIDIA LPX：从独立芯片到异构推理加速组件

2025 年 12 月，NVIDIA 与 Groq 达成一项价值约 200 亿美元的非排他性技术许可协议，Groq 创始人 Jonathan Ross 及核心工程团队加入 NVIDIA，而 Groq 作为独立公司继续运营 GroqCloud [1312]。这一交易被业界普遍视为事实上的“acqui-hire”，结构上规避了全面并购的监管审查 [1324]。2026 年 GTC 上，NVIDIA 正式发布 Groq 3 LPX，作为 Vera Rubin 平台的推理加速组件 [98]。

LPX 的核心创新在于注意力-前馈网络分离（Attention-Feedforward Network Disaggregation, AFD）：将 Decode 阶段进一步拆解，GPU 负责 attention（需要大容量 HBM 存储 KV Cache），LPU 负责 FFN/MoE 的带宽密集型计算 [97]。NVIDIA Dynamo 推理编排框架协调这一异构流水线：prefill 全部由 GPU 处理，decode 时 GPU 计算 attention，然后将中间激活通过 Spectrum‑X Ethernet 传给 LPU 执行 FFN/MoE，结果返回 GPU 继续生成 token，形成“乒乓”流水线 [87]。

一个 LPX 机架包含 256 颗 Groq 3 LPU，总 SRAM 128 GB，聚合带宽 40 PB/s，机架级互联带宽 640 TB/s，采用全液冷，功耗可达 160 kW [1289]。NVIDIA 宣称，LPX 与 Vera Rubin NVL72 搭配，在万亿参数模型上可实现比 Blackwell NVL72 高 35 倍的吞吐量/兆瓦，目标定价为 $45/百万 token [1289]。这种异构架构标志着 NVIDIA 正式将 SRAM 加速器纳入其推理基础设施，以解耦 HBM 的带宽瓶颈，同时保持 GPU 在 prefill 和 attention 中的主导地位。

2.1.7. 局限性与架构边界

尽管 LPU 在 Decode 延迟上建立了统治性优势，其架构边界同样清晰：

• SRAM 容量天花板：单 chip 500 MB，单机架 128 GB，而 400B+ 参数模型或万亿参数模型无法在单个 LPX 机架内驻留，必须依赖多机架或退回 GPU+HBM 方案 [91]。
• 推理半程依赖 GPU：LPU 无法独立完成 prefill，其计算模式不适合大规模并行矩阵乘法，因此在 NVIDIA 的异构架构中，prefill 完全由 GPU 处理，LPU 仅加速 decode 的 FFN 部分 [87]。这意味着 LPU 本身不是一个完整的推理平台。
• 多模态与训练缺位：LPU 基本没有图像/视频处理能力，视觉编码仍需 GPU；它也不支持训练、微调，甚至不能高效运行 prefill-heavy 的 RAG 流水线 [91]。
• 编译器锁定与生态封闭：GroqFlow 编译器虽然支持 PyTorch/TensorFlow/ONNX 导入，但实际部署高度依赖 Groq 编译器团队的手工适配，新模型架构（如 MoE 变体）的快速支持存在延迟风险 [184]。与 CUDA 的开放生态相比，这种封闭性制约了开发者自主优化和模型探索的灵活性。
• 物理扩展成本：运行 70B 模型需要数百颗芯片，占地面积、功耗和系统复杂度远超等效 GPU 方案，更适合云厂商的大规模统一部署，而不太适合企业私有化轻量部署 [76]。

2.1.8. 小结：Decode 加速的极致武器

Groq LPU / NVIDIA LPX 是 LLM 推理 Decode 阶段 memory-bound 瓶颈的极致解法。它以 SRAM 的带宽和确定性执行，将单请求 token 生成的延迟和抖动压至 GPU 无法企及的水平，但为此付出了容量、独立性和通用性的代价。NVIDIA 的 200 亿美元许可和 AFD 异构架构，实质上是将 LPU 定位为 GPU 推理系统的“涡轮增压器”——它不替代 GPU，而是接管 GPU 最不擅长的带宽密集型 Decode FFN 环节，与 GPU 的 prefill 和 attention 形成互补。对于实时交互式 AI 应用，LPU 已成为不可或缺的加速组件；而对于完整推理栈或高吞吐批量场景，GPU 仍然是最经济的基石。未来，随着长上下文、MoE 和多模态需求的增长，这种 SRAM + HBM 的异构混合架构很可能成为数据中心推理的标准范式。

2.2. Cerebras WSE-3：晶圆级芯片的极限工程与推理霸权

WSE-3 是 Cerebras Systems 的第三代晶圆级引擎，也是迄今为止商业化的最极端 AI 芯片。它不只是在芯片上做文章，而是把整张 300mm 硅晶圆当作一颗芯片来用。这种”暴力美学”的背后，是一整套从物理极限倒推回来的系统工程：片上存储、互联、供电散热、缺陷容忍、系统扩展，每一项都必须重新发明，才能让晶圆级芯片从实验室的”不可能”变成量产的”可能”。

2.2.1. 片上存储：44GB SRAM 与 21 PB/s 带宽的”暴力美学”

WSE-3 的存储架构是其一切性能表现的物理基础。它采用全分布式 SRAM：900,000 个 AI 优化核心，每个核心配备 48 KB 本地 SRAM，合计 44 GB 片上总容量 [115]。每个核心的 SRAM 与计算单元物理紧邻，单周期即可完成数据读取——这意味着没有 off-chip 访存延迟，没有 HBM 的 PHY 开销，没有 DRAM 的 row buffer miss [1]。

关键数字对比：

参数	Cerebras WSE-3	NVIDIA H100	NVIDIA B200	优势倍数
片上 SRAM	44 GB	~60 MB (L2)	~72 MB (L2)	~700×
总内存带宽	21 PB/s	3.35 TB/s (HBM3)	8 TB/s (HBM3e)	~6,000–7,000×
互联带宽	214 Pb/s	0.0576 Pb/s	—	~3,715×

21 PB/s 这个数字不是营销噱头——它是将所有 900,000 个核心本地 SRAM 的单周期带宽相加得出的物理结果。正如 Sean Lie 在 Hot Chips 2024 上所展示的，这个带宽是 H100 的约 7,000 倍 [12]。

44GB 的容量天花板与 Weight Streaming 的应对：

44 GB SRAM 对于现代 LLM 来说太小了。Llama 3.1 70B 需要约 140 GB FP16 权重，DeepSeek-V3 需要约 1,300 GB。Cerebras 的解决方案是将架构反转：激活驻留在 WSE 的片上 SRAM 中，权重从外部 MemoryX 设备逐层”流”入芯片 [143]。

MemoryX 是一种使用 DRAM + Flash 混合设计的外部存储设备，最高容量 1.2 PB，可支持 24 万亿参数模型 [1069]。在推理的 Decode 阶段，权重从 MemoryX 逐层流式传输到 WSE-3，激活保留在片上 SRAM 中 [106]。这种架构使得单个 CS-3 系统 + 1.2 PB MemoryX 的存储容量相当于一个 10,000 节点的 GPU 集群 [1069]。

但必须指出一个关键的物理限制：片上带宽是 21 PB/s，但 off-chip I/O 带宽仅约 150–200 GB/s——差距高达 133,000 倍 [105]。这意味着 Weight Streaming 的实际效果高度依赖于 compute-to-IO ratio：每个流入的权重必须被用于足够多的浮点运算，才能”隐藏”流式加载的延迟。对于模型能完全驻留在 44 GB SRAM 中的场景，WSE-3 的性能优势最显著；一旦需要 Weight Streaming，性能优势会显著缩水 [105]。

---

2.2.2. 片上互联：214 Pb/s 的 2D Mesh Fabric

WSE-3 的 900,000 个核心通过一个二维 Mesh 拓扑实现全芯片互联 [102]。每个核心内嵌一个 5 端口 fabric router，支持与东南西北四个邻居的 32-bit 并行数据传输（每周期 32 bit），第五端口连接核心自身的计算逻辑 [1606]。整个 fabric 提供 214 Pb/s（petabits per second）的聚合互联带宽，约为 H100 的 3,715 倍 [115]。

数据流驱动执行：

WSE-3 采用的是数据流架构（dataflow architecture），而非 GPU 的程序计数器驱动执行模型。在 WSE-3 上，数据到达触发计算——一个 32-bit 的数据包（称为 wavelet）带有 5-bit 的 “color” 标签，这个标签决定了它的路由路径和到达目标核心后触发的任务 [105]。正如一位架构师所言：“on a GPU, the program counter drives execution. on the WSE, data arrival triggers computation. a wavelet arrives on a color, the bound task fires. no wavelet, nothing happens” [105]。

这种架构的关键优势在于无边界通信：传统 GPU 集群中，跨芯片通信需要经过 NVLink/NVSwitch → 网络 → 对端 GPU 的层层协议栈，每一层都引入延迟和功耗开销。而在 WSE-3 上，数据从芯片一端到另一端只需要在 mesh 上跳转若干步——没有 off-chip 环节，没有协议转换，没有 SerDes 功耗 [20]。

跨光罩的”无缝”互联：

WSE-3 最硬核的工程挑战之一是跨 reticle 互联。TSMC 的光刻机一次只能曝光约 26mm × 33mm 的区域（一个 reticle），而 WSE-3 需要覆盖近乎整张 300mm 晶圆。Cerebras 的做法是：TSMC 打印 84 个完全相同的 die pattern，然后在原本用于切割芯片的 scribe line 上沉积金属连线，将 84 个 reticle pattern 无缝拼接成一个连续的 2D mesh——在 scribe line 上跑信号，而不是切掉它 [105]。这是与 TSMC 近十年合作开发的专有工艺，竞争对手极难复制 [1062]。

---

2.2.3. 能效与供电散热：23kW 的极致工程

WSE-3 的能效优势来自架构层面的”做减法” [1058]：

• 无 HBM PHY 功耗：HBM 的 PHY 接口是功耗大户，WSE-3 完全不需要
• 无芯片间 SerDes 功耗：所有通信都在片上 mesh 完成，没有跨芯片 SerDes 开销
• 无协议栈开销：数据移动不需要经过 PCIe、NVLink、InfiniBand 等协议层

CS-3 系统整体功耗约 23 kW [3]。这一数字是等效于约 62 块 H100 GPU 的算力（125 PFLOPS FP16）对应的功耗，但远低于等效 GPU 集群。Cerebras 声称其推理工作负载的功耗约为等效 GPU 云方案的 1/6 [1645]。对比 DGX B200，CS-3 在同等推理任务上功耗约为 1/3 [134]。

供电与散热工程：

驱动 WSE-3 需要约 20,000–30,000 安培的电流 [1590]。Cerebras 开发了名为 “engine block” 的专利封装方案：供电模块直接面对晶圆正面，通过 3D 配电网络将电流均匀输送至整个芯片；水冷冷板紧贴晶圆背面，通过分区水冷设计实现均匀散热 [1070]。这种垂直供电+水冷的一体化设计，是传统芯片封装无法实现的技术突破 [1070]。

---

2.2.4. 良率与制造成本：晶圆级芯片的经济账

缺陷容忍：从”避免缺陷”到”拥抱缺陷”

晶圆级芯片最核心的商业化障碍是良率。在 300mm 晶圆上，制造缺陷不可避免。Cerebras 的解决方案不是”避免缺陷”，而是通过三个层次的设计”容忍缺陷” [4]：

1. 超小核心（0.05 mm²）：每个 AI 核心仅约 NVIDIA H100 SM 核心（~6 mm²）的 1/120。当一个制造缺陷命中时，WSE-3 只损失 0.05 mm² 硅面积，而 GPU 损失 6 mm²——约 100–164 倍的缺陷容忍度差异 [105]。

2. 冗余核心：物理制造约 970,000 个核心，但出货规格为 900,000 个。约 7–8% 的冗余容量用于替换缺陷核心，即约 70,000 个核心在出货时已永久禁用 [2]。

3. 故障容忍路由：fabric router 自动绕过缺陷区域，将数据流重新路由到正常核心。对软件而言，这个过程完全透明——编译器看到的始终是一个”完美”的逻辑 mesh [1575]。

成本结构：

经济账大致如下 [268]：

• 一张 TSMC N5 300mm 晶圆成本约 $18,500 [899]
• 一个 CS-3 系统（含 WSE-3、engine block、散热、供电）售价约 $300 万
• Cerebras 2024 年毛利率约 41% [896]

$300 万一个节点的价格不便宜，但对比的是等效可能需要 60+ 块 H100 组成的 GPU 集群。关键在于，WSE-3 的 TCO 优势来自消除集群互联的复杂性和功耗——而不是来自更便宜的硅。Cerebras 声称 CS-3 在 Llama 3 70B 推理上相比 DGX B200 有 32% 的 TCO 优势 [108]。

为什么停留在 5nm：

WSE-3 使用了 TSMC 5nm 而非 3nm。Cerebras 创始人 Andrew Feldman 明确表示，这是”价格和良率差异”的考量——对于晶圆级芯片，成熟节点的良率比前沿节点的晶体管密度更重要 [119]。这是晶圆级芯片与 GPU 在工艺路线选择上的根本差异。

---

2.2.5. 推理性能：数字不会说谎

实测 Benchmark：

模型	Cerebras WSE-3 (CS-3)	最快 GPU 方案	优势倍数
Llama 3.1 8B	1,800 tok/s	~90 tok/s (云 GPU)	20×
Llama 3.1 70B (v2)	2,100 tok/s	~131 tok/s (最快 GPU)	16× vs GPU, 68× vs 云
Llama 3.1 405B (1K prompt)	969 tok/s	~81 tok/s (最快 GPU 云)	12×
Llama 4 Scout	2,600+ tok/s	—	19× vs 最快 GPU
Llama 4 Maverick (400B)	2,500+ tok/s/user	~1,000 tok/s (DGX B200)	>2.5×
GPT-OSS-120B	2,700+ tok/s	580–900 tok/s (B200)	3×–4.7×

数据来源：[5]

端到端延迟：

在 Llama 3 70B 推理场景（1,024 input tokens, 4,096 output tokens），CS-3 系统对比 NVIDIA DGX B200 [134]：

• 21× 端到端延迟优势
• 32% 更低的总拥有成本（TCO）
• 约 1/3 的功耗

TTFT（Time to First Token）方面，CS-3 在 Llama 3.1 70B 上约 50ms，在 Llama 3.1 405B（1K prompt）上约 240ms——“大约是大多数 GPU API 的几分之一” [122]。

Batch Size 独立性：

WSE-3 的一个关键特征是batch size 不敏感：在 batch 1 到 batch 64 范围内，输出速度保持 ~2,100 tok/s 不变。这是因为片上 SRAM 带宽足以在 batch 1 时就让计算单元满负荷运转——不需要像 GPU 那样靠增大 batch 来摊销 HBM 访存延迟 [1]。对于需要低延迟、低并发的实时交互场景（如语音助手、代码补全），这是巨大的架构优势。

---

2.2.6. 推理中的优势与限制

优势：

1. Decode 阶段的绝对低延迟：21 PB/s 片上带宽 + 无 off-chip 访存 = 对 memory-bound 的 Decode 阶段的终极优化。这是 WSE-3 最核心的不可替代优势 [7]。

2. 架构简洁性：一个 CS-3 系统替代了数十个 GPU + 交换机 + 线缆的集群。用 Cerebras 的话说：“一个设备，一个模型，一行代码” [105]。对于企业私有化部署，这种简洁性直接转化为更低的运维复杂度和更高的可靠性。

3. MoE 友好：Cerebras 声称其平台对 MoE 模型天然友好——因为片上 SRAM 带宽足够高，即使专家路由导致不规则访存模式，也不会出现 GPU 上常见的”expert parallelism 通信瓶颈” [7]。Cerebras 的 BTA（Batch Token Allocation）技术在 MoE 推理中可维持与密集模型相当的高吞吐 [1650]。

4. 能效：推理功耗约为等效 GPU 云方案的 1/6 [1645]。

限制：

1. 模型容量天花板：44 GB SRAM 对于现代 LLM 太小。Weight Streaming 虽然技术上可行，但 off-chip I/O 的 133,000× 带宽差距意味着性能会显著下降 [105]。

2. 多芯片扩展的瓶颈：当模型需要跨多个 CS-3 系统时（如 Llama 70B 需要 4 个 CS-3），片间通信带宽成为新的瓶颈，单芯片的带宽优势被削弱 [1546]。一位分析师指出：“the current cap for WSE-3 is the 44GB of SRAM and a lack of a fast enough communication layer between chips to maintain their performance advantage once you start stringing chips together” [1547]。

3. 并发能力受限：WSE-3 的 batch-1 性能无敌，但高并发场景（数千用户同时请求）中，GPU 集群可以通过增大 batch size 来摊销 HBM 访存延迟，实现更高的系统级吞吐。WSE-3 的 SRAM 带宽虽然高，但 44 GB 容量限制了它能同时服务的请求数量。

4. 长上下文推理的挑战：KV Cache 随上下文长度线性增长。对于 100K+ token 的长上下文，KV Cache 可能达到数十 GB——远超 44 GB 的 SRAM 容量 [1646]。

5. 软件生态远不如 CUDA：虽然 Cerebras 提供了 PyTorch 集成和 CSoft 编译器（支持 PyTorch 2.0、XLA lazy tensor 后端），但模型移植仍需适配，且不支持 vLLM、TensorRT-LLM、SGLang 等主流推理框架 [1676]。对于需要自定义算子的前沿模型，开发者需要学习 Cerebras 专有的 CSL 语言 [114]。一位分析师直言：“because this hardware fundamentally guarantees the compiler complexity, Cerebras can never achieve the software optimization of NVIDIA” [1061]。

6. 客户集中度风险：Cerebras 2025 年 86% 的收入来自两个 UAE 关联实体（MBZUAI 62%，G42 24%），加上 OpenAI 的 $10–20B 协议，客户集中度极高 [1079]。这不仅是商业风险，也意味着 WSE-3 尚未在广泛的市场中被验证。

---

2.2.7. 小结

WSE-3 是 LLM 推理 ASIC 竞赛中最极端、最纯粹的技术路线。它的核心逻辑可以浓缩为一句话：用一整张晶圆的硅面积，换取无 off-chip 访存的极致带宽和延迟。

这个策略在推理 Decode 阶段取得了无可争议的领先——2,100 tok/s 的 Llama 70B 生成速度、21× 的端到端延迟优势、1/3 的功耗，这些数字不是渐进式改进，而是数量级的代差 [136]。

但代价同样巨大：44 GB 的容量天花板、多芯片扩展后的带宽衰减、极高的客户集中度、以及一个永远无法与 CUDA 比肩的软件生态。WSE-3 不是”GPU 杀手”，它是一把为特定场景淬炼的利刃——在它擅长的领域（低延迟、单用户、中等规模模型的 Decode 推理），它没有对手；在它不擅长的领域（大规模训练、高并发推理、超大模型、长上下文），GPU 仍然是更务实的选择。

2.3. Taalas HC1：当“模型即芯片”走到极致——机遇、风险与“刻硅舟”困局

在 Groq 用 SRAM 征服访存延迟、Cerebras 用一整片晶圆“暴力美学”吞下整块模型之后，Taalas 选择了一条更极端的路径：让 Llama 3.1 8B 的权重直接成为硅原子的排列方式。 如果说 Groq 是“为推理而生”，Cerebras 是“为规模而生”，那么 Taalas 就是“为这一个模型而生”。

它的 HC1（Hardcore 1）芯片不是 GPU，甚至不是传统意义上的可编程 ASIC，而是一件“硅铸模型”——将 Meta Llama 3.1 8B 的计算图（computational graph）和训练好的权重直接硬连线（hardwire）到 TSMC N6 工艺的 815mm²、530 亿晶体管的裸片上 [21]。结果是骇人的：单用户 17,000 tokens/s、低于 100ms 响应延迟、成本仅 B200 的 1/20、功耗仅 1/10 [27]。

但在这组令人眩晕的数字背后，一个根本性问题横亘在 Taalas 面前：当你的芯片就是模型本身时，模型进化的速度会不会让你的芯片还没流片回来就已过时？ 这不仅是 Taalas 的达摩克利斯之剑，也是整个“模型专用硬件”（model-specific silicon）路线的最大存在主义拷问。

---

2.3.1. 架构思想：Hardcore 逻辑与“不灵活”的哲学

2.3.1.1. 什么是“模型专用硬件生成”？

Taalas 的核心技术理念不是设计一款芯片，而是构建一套从模型计算图到物理版图的自动编译流水线 [28]。传统 ASIC 设计中的 RTL 编写、综合、布局布线，在 Taalas 这里被部分替换为一种“模型→硅片直出”的自动化流程。

这个流水线的输入是一个已训练好的模型（权重固定、架构固定），输出是一版可直接流片的 GDSII 文件。整个过程不需要重新发明微架构——计算的并行化模式、数据流路径、存储层次，都直接从模型的 DAG（有向无环图）中推导并映射为硬件结构。

这一路线与 Google TPU 的多代演进存在本质区别：TPU 的 systolic array 是可编程的——你可以今天跑 ResNet，明天跑 Llama，后天跑 Gemini，只要编译器能映射。而 Taalas 的 HC1，其数据路径就是 Llama 3.1 8B 的 attention head 和 MLP 层的物理实例化。它不“运行”模型，它就是模型 [36]。

2.3.1.2. 计算与存储的“零距离”融合

当前 AI 推理硬件的最大功耗和延迟来源不是计算，而是数据搬运——把权重从 HBM 搬到计算单元。H100 每搬运一个 bit 的能耗是执行一次 FP8 乘加运算的约 200 倍 [22]。

HC1 把搬运成本压至理论下限：权重不是存储在 SRAM 或 HBM 里等待被读取，而是被“烧录”成晶体管的连接模式，直接参与计算。 这本质上是一种超高密度的存内计算（compute-in-memory），但不是用新兴存储介质（ReRAM/PCM），而是用最成熟的 CMOS 数字逻辑——“用逻辑门来记住权重，用连线来定义算子并行度” [1690]。

这种“存储逻辑一体化”带来三重优势：

• 消除片下带宽瓶颈：不需要 HBM，因为不存在“从存储器调用权重”的步骤。HC1 采用 DRAM-like 密度的一体化设计，没有 HBM 堆叠、没有 3D 封装、甚至不需要液冷 [26]。
• 超低延迟确定性执行：计算路径完全固定，没有 cache miss、没有分支预测失败、没有数据流水线 stall。每次前向推理的周期数精确可预测，这是实时 AI 交互（如语音对话、自动驾驶推理）的圣杯。
• 能效极致化：17,000 tokens/s 的性能在 B200 级别被视为“暴力堆料”，但 HC1 只用 10% 的功耗就做到了，原因就是 90% 的 GPU 功耗浪费在数据搬运上，而 HC1 几乎不存在搬运 [70]。

2.3.1.3. 有限的可编程性：那条“两金属层”的生命线

HC1 并非完全僵死。它保留了一小片 SRAM，用于存储 微调后的权重偏移量 和 KV Cache——这意味着在不改变底层基座模型架构的前提下，可通过刷写 SRAM 中的增量参数来进行轻量适配 [23]。

更关键的是 Taalas 宣称的 “两金属层掩模”快速重流片方案 [27]。现代芯片制造中，底层晶体管层（FEOL）的变更需要重做全套光罩（成本数千万美元、周期数月），但顶层金属互连层（BEOL）的变更只需要替换少数几张掩模。如果模型更新主要涉及权重值变化（而不是架构层的 attention 头数、隐藏维度等结构性参数），理论上可通过只修改金属布线层，将流片周期从 12–18 个月压缩到约 2 个月。

这是 Taalas 商业模式的核心支点——如果 2 月转身真的可行，那么模型迭代（通常 6–12 个月发布新版本）就赶不上专用芯片过快的“死去”，专用芯片的经济账就可能在变旧的权重值过时之前算得过来。

---

2.3.2. 架构适应性风险：当“刻入硅”遇到“变化是唯一常数”

2.3.2.1. 模型架构“变异”的速度远超 ASIC 流片周期

Llama 3.1 8B 发布于 2024 年 7 月，HC1 的芯片接近 2026 年 Q1 亮相——间隔约 20 个月。这期间 Llama 3.2（多模态）、Llama 4 Scout/Maverick 以及各类 MoE 变体已经铺开，8B 稠密模型在 2026 年的竞争中已明显处于“入门级”定位。HC1 上市之刻，它硬化的模型已不是最领先的一批 [1689]。

问题在于：如果下一代模型的架构发生质变——例如从 Dense 改为 MoE、增加 Multi-Head Latent Attention（MLA）、引入状态空间模型（Mamba/SSM）甚至完全脱离 Transformer —— 那不是什么“两金属层”能拯救的。 这意味着需要新的数据路径结构、新的 attention 机制硬件映射、新的路由器和 gating 逻辑。这需要重设 FEOL，周期回升到传统 ASIC 的 12 个月以上 [29]。

2.3.2.2. “为 Llama 3.1 8B 量身定制”的隐性限制

HC1 的 17,000 tokens/s 指标有一组关键的限定条件：输入 1k / 输出 1k tokens，Llama 3.1 8B 的特定变体版本 [70]。这暴露出几个隐含问题：

隐性限制	影响
上下文长度固定（2k tokens）	长上下文推理需重新设计 KV Cache 存储结构，超出了“两金属层修补”范围
Batch size = 1 优化	高并发多用户场景下，芯片间如何切分/复制模型？片间互联系统未充分披露
4-bit KV Cache 量化	模型准确率退化风险，在需要高精度 KV 检索的场景中可能不适用 [31]
仅支持单一模型族	客户如果需要切换至 CodeLlama、Qwen、Gemma 等不同架构，需全新芯片

“天下武功唯快不破”的前提是你的“快”是在解决通用问题。如果 HC1 的“快”只在一条赛道上成立，那它就天然不适用于客户的多模型部署需求。

2.3.2.3. 对 MoE、多模态、非 Transformer 架构的适配：基本是零

Taalas 当前路线的“强硬化”特性决定了：每支持一个新架构，就需要新一次流片。

• MoE 模型：专家路由涉及动态 gating 网络和稀疏激活，这些逻辑如果“硬连线”将极其复杂，若用 SRAM 做可编程逻辑又会破坏“零搬运”假设。
• 多模态模型：图像/音频编码器与语言模型的异构计算图大大增加了硬连线复杂度，绝非“两金属层”能覆盖。
• Mamba/SSM/线性 attention：这些架构的硬件映射与 Transformer 的 QKV attention 完全不同，需全新的数据路径设计。

结论：Taalas HC1 更适合那些架构收敛、模型部署后长期不变（1-2年以上）的场景。但今天的 LLM 生态恰恰是架构进化最剧烈的领域。

---

2.3.3. 商业化挑战：“唯有那个唯一的客户”

2.3.3.1. 客户锁定悖论

购买 HC1 的客户获得的不是“AI 推理能力”，而是“Llama 3.1 8B 的极致推理性能”。这意味着 Taalas 卖的不是通用算力，而是一种绑定了特定模型版本的服务载体。

客户面临一个残酷的算账题：

• 购买 10,000 颗 HC1，1 年后 Llama 3.1 8B 已落后 2 代。这些芯片无法运行更新、更好的开源模型。
• 若继续采购基于新模型的 HC2，旧芯片沉没成本成为资产负债表上的伤疤。
• 对比 GPU 集群：硬件可复用 5 年以上，只要新模型没超出显存/算力上限。

GPU 的“通用性溢价”在此刻变为“灵活性贴现”——三年的复用生命周期相对于 1 年即过时的专用芯片，前者的 TCO 可能在长期更低。 Taalas 需要在芯片单价上压低到足以补偿这种“提前淘汰风险”的水平，这才是 1/20 B200 成本的核心商业逻辑，而不只是芯片制造成本低 [27]。

2.3.3.2. “快速重流片”的商业可行性尚未验证

两金属层掩模的快速流片方案在纸面上优美，但面临几个实际层面问题：

• 实际周期：即使掩模修改只需 2 个月，加上 wafer fab 周期（N6 的 typical cycle time ~60 天）、封装测试、板卡适配、软件栈验证，整体 end-to-end 耗时更可能在 4-6 个月。这个周期仍大于很多开源模型的迭代速度。
• 成本：一套金属层掩模虽比全光罩便宜，但对初创公司而言仍是一笔数百万美元量级的费用。频繁流片的经济压力会在模型版本碎片化时急剧放大。
• 良率和验证：只改金属层不能完全避免时序收敛和信号完整性问题——尤其是对于 815mm²、530 亿晶体管的大芯片 [26]。

2.3.3.3. 软件生态：极简化是双刃剑

HC1 的软件栈极简——模型已在硅中，不需要复杂的图编译、算子调度、内存分配。这降低了开发成本，但也意味着 HC1 无法接入现有的推理服务生态（vLLM、SGLang、TRT-LLM）。客户需要专门为 HC1 开发服务侧软件，这堆高了使用门槛。

“极简软件栈”的代价是“软件生态为 0”——这在 GPU 主导的世界里，就是把迁移成本全部转嫁给客户。

---

2.3.4. 流片与模型迭代的矛盾：根本性的时间尺度错配

这是 Taalas 路线最大的结构性问题，值得单独剖析。

维度	LLM 迭代节奏	ASIC 流片节奏	矛盾
模型架构更新周期	6-12 个月发布新架构	12-18 个月（全流片）/ 4-6 月（金属层修改估算）	芯片永远比模型“慢半拍”
模型权重迭代周期	数周～数月（post-training/fine-tuning）	不可追（除非仅限 SRAM 内权重偏移）	芯片只能固化 base model，无法跟踪社区微调
开源模型生态碎片化速度	快（Llama、Qwen、Gemma、Mistral 等频繁发布）	每款新架构需新芯片	客户无法在一个硬件上覆盖多个模型族
算法突破不确定	Transformer 可能被替代，MoE 比例/结构在变化	架构无法预设	“押注”风险极高

类比：这像是软硬件联合优化的“双子星”问题——你必须在模型尚在快速变异的阶段，就决定把哪个版本永远“定型”为硬件。而上一次有人这样做并成功的是比特币 ASIC 矿机——但 SHA-256 哈希算法 15 年没变。LLM 连 15 个月不变都不敢保证。

2.3.5. 推演与判断

Taalas HC1 代表了一种极端情境下的经济推演：如果未来 1-2 年内出现一个“足够好、不再大变”的基础模型架构（类似于 CPU 领域的 x86 或移动端的 ARM 在指令集层面的稳定），且这个模型的推理需求足够大（数十亿 token/天量级），那么“model-specific ASIC”就可能成为比 GPU 更经济的方案——10 倍速度、1/20 成本、1/10 功耗的组合会直接撕裂现有市场。

但目前看，这个“如果”尚未成立。Taalas 的路径更适合以下特定场景：

• 企业内部已锁定某一模型版本，且该模型在未来 2年以上不做架构级升级的批量推理（如特定客服机器人、特定代码补全模型）
• 模型架构已被“国家级标准”锁定、变更为零的政务/国防部署
• 极致低延迟单用户场景（如实时语音对话），对通用性无要求

Taalas 真正“鲨”的不是 NVIDIA，而是那些同样走 SRAM-centric 路线的同行（如 Groq、d-Matrix）。它把“专用化”推到了极致，测试的不只是芯片设计的边界，更是 AI 产业“模型标准化”的耐心。 在这场测试结束之前，HC1 是一把锋利的单刃剑——切得快，但只能朝一个方向。

这一路线若想走得更远，Taalas 必须回答：当 AI 产业终于找到“够用且稳定”的模型时，你的自动设计流水线是否已准备好批量“印刷”这些硅铸模型？如果答案是肯定的，你就在等风来。如果答案是否定的，那你等来的可能只是一堆昂贵的硅片墓碑，上面镌刻着过时模型的名字。

2.4. Etched Sohu：将 Transformer “烧入硅片” 的终极赌注

在所有挑战 NVIDIA 推理垄断的路线中，Etched 选择了最极端、也最纯粹的一条：将 Transformer 架构直接烧入硅片，制成一枚除了 Transformer 什么都不会跑的 ASIC。Sohu 没有 CUDA core、没有 Tensor Core、没有可编程的 shader——它只有一套硬连线的注意力电路和一组前馈网络 systolic array，专门为 Llama、GPT 这类 decoder-only Transformer 的推理而生 [50]。这枚芯片在 2024 年 6 月一经公布，便以”8 芯片服务器取代 160 张 H100”的极致性能宣言震惊业界，但截至 2026 年中，它仍未向任何客户交付生产级硅片，也从未接受过独立第三方的基准测试 [44]。Sohu 的处境因此成为整个 LLM ASIC 赛道的缩影：架构赌注越大，性能上限越高，但商业化的容错空间也越窄。

2.4.1. 架构哲学：当”通用”成为负担

Etched 的核心论断朴素而尖锐：NVIDIA H100 的 800 亿晶体管中，只有约 3.3% 真正用于矩阵乘法——其余 96.7% 都是在为”通用可编程性”买单 [155]。这个数字虽然引发争议（H100 的 L2 cache 本身就占约 17B 晶体管，SM 内部也有大量寄存器文件和 warp scheduler），但它指向了一个真实的问题：GPU 在 LLM 推理 Decode 阶段的实际 FLOPS 利用率通常只有 30–40%，大量硅面积在”等待内存”中空转 [155]。

Sohu 的答案是：既然 Transformer 的操作集如此稳定——attention（QKV 投影 + softmax + 加权求和）、MLP（两个线性层 + 激活函数）、layer norm、residual add——为什么不把这些操作直接做成硬件电路？ [46]

Sohu 的芯片架构包含两个关键组件 [155]：

1. 专用 Self-Attention 电路：一套独立于 systolic array 的硬件单元，专门处理 attention 内部的 matmul-softmax-matmul 交织模式。在 GPU 上，attention 需要将 QKV 投影、softmax、加权求和拆分为多个 kernel，反复读写 HBM；Sohu 将这些操作融合为单一硬件流水线，中间数据全部驻留在片上 SRAM 或寄存器中，无需往返 HBM [155]。

2. 大容量 Systolic Array：负责 MLP/FFN 层的大规模矩阵乘法。由于不需要兼顾卷积、pooling、非 Transformer 激活函数等通用操作，systolic array 的尺寸可以做到极致——去除所有”灵活性”硅面积，全部替换为 FMA 单元 [45]。

此外，Etched 还申请了多项专利，包括激活函数近似（用更少硅面积实现常见激活函数）和编译器层面的”融合 kernel 替换”技术 [48]。

在工艺和存储方面，Sohu 基于 TSMC 4nm 工艺制造，采用 reticle-limit die（即单光罩极限尺寸，约 800+ mm²），每芯片配备 144 GB HBM3E，带宽约为 H100 SXM5（3.35 TB/s）的 1.8 倍 [41]。与 Groq LPU 的纯 SRAM 路线不同，Sohu 选择了 HBM 作为权重和 KV cache 的驻留地——这意味着它并非”SRAM-centric”，而是”HBM + 固定功能逻辑”的混合路线 [41]。Etched 声称，凭借去除通用性开销，Sohu 的 FLOPS 利用率超过 90%，而 GPU 在典型推理负载下仅 30–40% [44]。

2.4.2. 架构绑定：到底有多”硬”？

这是 Sohu 最核心的取舍，也是所有潜在客户在评估时必须回答的第一个问题：Sohu 到底能跑什么，不能跑什么？

能跑的：所有标准 dense Transformer 架构——Llama 系列、GPT 系列、Gemma、Mistral（dense variant）、Stable Diffusion 3（基于 Diffusion Transformer/DiT）等 [45]。只要是 attention + MLP 的堆叠，Sohu 理论上都能支持。

不能跑的 [41]：

• CNN（ResNet、EfficientNet）：没有卷积硬件单元
• RNN/LSTM：没有循环状态机
• SSM/Mamba（State Space Model）：Mamba 的核心是选择性状态空间扫描，计算模式与 attention 完全不同，无法映射到 Sohu 的固定功能电路 [41]
• 多模态模型的视觉编码器：LLaVA、Qwen-VL、Llama 3.2 Vision 等模型的视觉 backbone（通常是 ViT 或卷积编码器）包含 Sohu 不支持的算子 [41]
• 扩散模型的 U-Net：传统 Stable Diffusion 的 U-Net 去噪器不在支持范围内（但 DiT 架构的 SD3 可以）
• MoE 的动态 expert routing：DeepSeek V4、Mixtral、Qwen3-235B-A22B 等使用稀疏 expert 选择的模型，需要不规则的 memory access pattern，固定功能电路无法适应 [41]——不过 Etched 已披露存在单独的 MoE 变体芯片 [60]
• 训练/微调：Sohu 没有反向传播的硬件实现，是纯推理芯片 [41]

这意味着一个残酷的现实：截至 2026 年 4 月，开源社区中部署最广泛的模型之一 DeepSeek V4（MoE 架构）和 Qwen3-235B-A22B（MoE 架构），都无法在当前的 Sohu 上运行 [41]。要支持它们，需要等待 Etched 的 MoE 变体芯片。

更深远的问题是：如果 AI 架构在 Sohu 的生命周期内发生范式转移，会发生什么？ Etched 自己的估计是：从架构确定到新芯片流片，大约需要 3 年 [60]。在一个模型架构以月为单位迭代的行业里，3 年的硬件响应时间是一笔巨大的风险敞口。假设 2026 年出现某种 Hybrid SSM-Attention 架构（如 Mamba-3 的某些探索方向），或者某种全新的序列建模范式，Sohu 将在一夜之间从”最快的 Transformer 芯片”变成”最快的电子废料”。

当然，Etched 的赌注并非毫无依据：Transformer 自 2017 年诞生以来，已经统治了 AI 领域近 9 年，并且至今没有出现明确的替代者。SSM/Mamba 虽然在长序列效率上表现出色，但在实际模型质量和生态成熟度上仍远不及 Transformer。“Transformer 不会消失”这个命题，在 2026 年看仍然成立——但”Transformer 不会演化”这个命题，已经岌岌可危。MoE 的普及、multimodal encoder-decoder 的混合架构、以及各种 attention 变体（FlashAttention、ring attention、linear attention）的涌现，都在不断挑战”纯 dense Transformer”的边界。

2.4.3. 低延迟与高吞吐：纸面指标与工程现实的裂隙

Sohu 的性能声明是 AI 芯片行业近年来最引人注目的：8 芯片服务器在 Llama 70B 上跑出 500,000+ tokens/s，是 8×H100 的约 20 倍，是 8×B200 的约 10 倍 [41]。这个数字足以让任何推理服务商心跳加速。

但仔细审视 benchmark 条件，会发现几个关键限定 [1765]：

• 精度：FP8，无 sparsity
• 输入/输出长度：2048 input tokens / 128 output tokens
• 并行策略：8-way model parallelism（即 8 芯片各持一部分权重，做张量并行）
• Batch size：接近 batch-1（Etched 未明确公布，但多方分析均指向低 batch 条件）

这意味着这个数字描述的场景是：短上下文、单请求、低并发。这与 Groq LPU 的”甜蜜点”非常相似——都是将 Decode 阶段的 memory-bound 瓶颈通过硬件加速来解决。但 Sohu 的具体做法不同：Groq 用 SRAM 的高带宽（80 TB/s）来喂饱计算单元，而 Sohu 用固定功能电路来最大化每单位 HBM 带宽的利用率 [155]。

这里有一个关键的数字需要审视：Sohu 的 HBM 带宽约为 H100 的 1.4–1.8 倍，但声称吞吐量是 H100 的 20 倍 [155]。如果 LLM 推理真的是 memory-bandwidth-bound（正如业界共识），那么仅靠 1.4–1.8 倍的带宽提升，如何获得 20 倍的吞吐量提升？Etched 的答案在于”利用率”：H100 在 batch-1 Decode 时，大量 HBM 带宽被浪费在非计算相关的数据搬运上（如 kernel launch overhead、中间激活的反复读写），而 Sohu 的固定功能流水线将几乎 100% 的 HBM 带宽都用于权重读取——不存在”浪费的带宽” [59]。这个逻辑在理论上是自洽的，但由于缺乏独立验证，我们无法判断 20 倍的”利用率红利”中，有多少是真实的架构优势，有多少是 marketing 的”基准测试艺术”。

在 Prefill 阶段，Sohu 的大容量 systolic array 理论上可以高效处理大矩阵乘法。2048 token 的 prefill 在计算量上远小于 Decode 阶段的 memory 瓶颈，所以 Sohu 的优势更多体现在 Decode 侧。对于长上下文（8K+）的高并发 prefill，Sohu 的 HBM 容量和带宽是否会成为瓶颈，目前没有公开数据 [155]。

在长上下文推理方面，Etched 没有公布 Sohu 可支持的最大 context length。考虑到每芯片 144 GB HBM3E，8 芯片服务器合计约 1.1 TB [1762]，理论上可以容纳相当规模的 KV cache。但固定功能 attention 电路是否支持 FlashAttention 式的分块计算、是否支持 KV cache 量化（如 FP8 KV cache），目前均未公开 [41]。

2.4.4. 软件生态：最简单的编译器，最难的迁移

从纯编译器工程的角度，Sohu 的软件栈可能是所有 AI 芯片中最简单的——因为它只需要支持 Transformer 的有限操作集。Etched 的第三项专利（US20250138820A1，“Model-Specific ASIC Compilation Using Fused Kernel Replacement”）描述了其编译器的工作原理：识别 PyTorch/TensorFlow 代码中的”专用函数”（如 layer norm + linear 的融合模式），将其翻译为 ASIC 的中间表示。同一份模型代码可以编译到 GPU（用于训练）或 Sohu（用于推理）[155]。

这与 CUDA 的软件栈形成了鲜明对比：CUDA 需要支持任意计算图、任意 kernel 组合、任意精度格式，其编译器（NVCC + PTX → SASS）的复杂度呈指数级增长。Sohu 的编译器只需要处理几十种融合操作，编译时间、调试难度和优化空间都大幅简化 [155]。

但”简单”不等于”易用”。Sohu 面临的核心软件挑战不是编译器本身，而是生态接入 [41]：

• 没有 CUDA：无法利用任何现有的 CUDA kernel library（cuBLAS、cuDNN、FlashAttention kernel 等）
• 没有 vLLM：无法接入最流行的开源 LLM serving 框架
• 没有 TensorRT-LLM：NVIDIA 的推理优化栈完全不可用
• 没有 ROCm：AMD 的生态路线也不通
• 需要 Etched 的专有 compiler：用户必须将模型通过 Etched 的工具链编译，任何不在操作集内的自定义算子都会导致编译失败

对于开发者而言，这意味着：如果你用了 Sohu，你就完全进入了 Etched 的封闭生态。没有 fallback 到 GPU 的选项，没有社区支持的开源 serving stack，没有现成的模型 zoo。在模型还处于快速迭代期的今天，开发者无法在 Sohu 上快速实验新架构变体——任何模型改动都需要等待 Etched 编译器更新，或者干脆无法运行 [44]。

Etched 声称其软件栈是”开源”的 [1814]，但具体的开源范围、license 和社区治理模式尚未公开。截至 2026 年中，Sohu Developer Cloud 仍处于预告阶段，尚未对公众开放 [160]。

2.4.5. 客户接受度：谁在买，为什么买？

Sohu 的商业化进展是评估其前景的最关键变量。截至 2026 年 6 月，事实如下：

已确认的事实：

• Etched 已融资约 $6.2 亿（$120M Series A + $500M 新一轮），估值$50 亿，投资方包括 Peter Thiel、Stripes、Primary Venture Partners、Positive Sum 等 [64]
• 与 TSMC 新兴业务集团合作，采用 4nm 工艺流片 [1774]
• 团队核心包括前 Cypress Semiconductor CTO Mark Ross（曾带领团队交付 13 款系统级产品）、前 Broadcom/Intel 设计高管 Ajat Hukkoo 等资深人士 [1839]
• CEO 声称已有”数千万美元”的硬件预订 [160]

未确认/需验证的信息：

• 芯片是否已 tape-out 并产出可用硅片：2024 年 6 月宣布时仅展示了渲染图，预测市场 Manifold 上关于”Sohu 是否在一年内出货”的赌约已 resolving NO [159]
• 500,000 tok/s 的性能声明：无独立第三方验证 [44]
• 预订客户身份：均为”未具名”客户 [160]
• Sohu Developer Cloud 的实际上线时间：未公开 [160]

谁可能是 Sohu 的目标客户？

从 Etched 的定位来看，最可能的客户画像包括 [1775]：

1. 推理即服务（Inference-as-a-Service）提供商：如 CoreWeave、Lambda Labs、Together AI 等——它们需要极致的 token 生成成本来与超大规模云厂商竞争，且技术能力足以消化专有硬件的集成成本
2. 自有模型的大型 AI 公司：如 OpenAI、Anthropic 等——如果它们的主力模型是纯 dense Transformer 架构，Sohu 可以显著降低 token 成本
3. 垂直领域的推理部署：如代码补全（Copilot 类）、实时语音助手、Agent 循环——这些场景对低延迟、高吞吐的单请求性能有极致要求

但以下客户可能不会选择 Sohu：

• 需要运行 MoE 模型的公司（除非等 MoE 变体）
• 需要多模态推理的公司（视觉编码器不兼容）
• 模型架构频繁迭代的 AI 研究机构
• 需要混合负载（训练 + 推理 + HPC）的企业

最关键的商业化风险：如果 Sohu 在 2027 年才能大规模出货，届时 NVIDIA 的 Rubin 平台（Vera Rubin + LPX）已经量产，B300 也已经成熟，Sohu 的”20 倍 H100”优势将被大幅稀释——因为对比基准已经不是 H100 了 [1812]。而如果 AI 架构在 2026–2027 年间发生重大演化（如 MoE 成为主流、SSM 混合架构兴起），Sohu 的市场窗口可能尚未打开就已经关闭。

2.4.6. 小结：赔率最高的赌注

Etched Sohu 代表了 AI 芯片设计中”专业化”路线的极端形态。它在以下维度上做出了明确的取舍：

维度	Sohu 的选择	优势	风险
架构灵活性	仅支持 dense Transformer	极致硅面积效率，90%+ FLOPS 利用率	架构演化 → 芯片报废
存储路线	HBM3E（非 SRAM）	大容量（144 GB/chip），生态成熟	带宽提升有限（1.4–1.8× H100）
计算单元	专用 attention 电路 + systolic array	零调度开销，融合操作	无法适应新算子
软件生态	专有编译器 + 有限 PyTorch 兼容	编译器简单，优化空间大	无 CUDA/vLLM 生态，迁移成本高
商业化	直接卖芯片/服务器	单 token 成本极低（理论）	无出货记录，客户信任未建立

Sohu 的最终命运取决于三个变量的博弈：

1. Transformer 架构的稳定期有多长？ 如果 dense Transformer 在未来 3–5 年内仍是 LLM 的主流架构，Sohu 的”架构绑定”就从风险变成了壁垒——它用不可逆的硬件锁定换来了竞争对手无法企及的效率。

2. Etched 能否在 2027 年前实现大规模出货？ 芯片创业最残酷的规律是：从 tape-out 到量产，往往比 founders 预期的时间长 2–3 倍。而每延迟一个季度，NVIDIA 的下一代 GPU 就逼近一步。

3. 软件生态能否从”专有”走向”开放”？ 如果 Etched 能够将 Sohu 的 compiler 与 PyTorch 2.x 的 torch.compile、MLIR 生态打通，甚至吸引社区开发者在 Sohu 上适配 vLLM 等 serving 框架，那么迁移成本将大幅降低 [155]。

用投资术语来说：Sohu 是一笔高赔率、低确定性的赌注。如果一切顺利——Transformer 持续统治、芯片按时出货、性能兑现——Sohu 可能成为 AI 推理成本曲线的拐点。如果任何一个环节出错——架构演化、流片延迟、生态失守——Sohu 将沦为又一个”技术惊艳但商业失败”的 AI 芯片案例。考虑到 Etched 团队中 Mark Ross 和 Ajat Hukkoo 等人拥有 Cypress、Broadcom 级别的量产经验，以及 TSMC 新兴业务集团的直接支持，Sohu 的芯片本身大概率能跑通——真正的问题不在于”芯片能不能做出来”，而在于”做出来的时候，世界还需不需要它” [1839]。

2.5. d-Matrix Corsair：数字存内计算如何击穿 LLM 解码的内存墙

在讨论过 Groq LPU 的纯 SRAM 算力梭和 Cerebras 的整晶圆暴力流之后，d-Matrix 给出的方案更像一把精心打磨的“解剖刀”，只切向 LLM 推理中最痛的环节——decode 阶段。Corsair 不是想当万金油加速器，它的定位极其清晰：做一块专为生成式解码设计的 ASIC，与 GPU 的 prefill 能力组成异构计算集群 [1924]。背后的核心 insights 只有两个：一、decode 是纯粹的内存带宽瓶颈，算力堆再多也没用；二、破局的钥匙不是更贵的 HBM，而是把计算搬进存储器内部。

---

2.5.1. DIMC 架构本质：计算跑向数据，而非数据被反复搬运

d-Matrix 把其核心技术称为 Digital In-Memory Compute（DIMC）。它既不是把 SRAM 当大容量缓存用（像 Groq），也不是靠堆极致带宽的 HBM（像 GPU），而是在 SRAM 存储单元的物理阵列中直接嵌入数字乘法累加逻辑 [228]。每个 DIMC 核心实质上是一块经过改造的 SRAM macro，读出的权重值不需要跨越总线、不需经过复杂的 cache hierarchy，就在字线/位线旁边完成乘加运算。这给 decode 带来的好处是立竿见影的：

• 矩阵-向量操作的数据搬运量骤降。 传统 GPU 跑 decode 时，一个 token 的权重矩阵需要被从 HBM 读到 SM 的寄存器，实际计算只消耗极小一部分搬运的数据，绝大多数带宽被浪费在重复读取权重上。DIMC 让权重停留在宏内部，输出只有部分和或最终的激活值，数据的“动态功耗距离”从厘米级缩短到微米级。
• 数字计算保持精度，免去模拟存内计算的噪声和校准问题。 Corsair 采用 Block Floating Point（BFP）格式，在一个块内共享指数，在保证推理精度（4‑bit/8‑bit）的同时大幅降低计算与存储开销 [209]。这比许多早期模拟存内方案更具量产亲和力。

这种设计从 Roofline 模型上看，相当于把内存墙的“屋顶”直接抬高了数十倍——不是靠增加带宽，而是靠让绝大部分操作不再触及外存带宽限制。Corsair 的片上“性能内存”（即嵌入了算力的 SRAM 阵列）总容量只有 2 GB，却能提供 ~150 TB/s 的内部聚合带宽 [212]。这不是传统意义上的 cache，而是“计算介质”，容量大小不等于可利用的存储大小，它本身就是吞吐引擎。

---

2.5.2. 存储层级：SRAM 做算力，LPDDR5X 做容量

Corsair 的存储由两层构成，职责分明：

层级	单卡容量	带宽	用途
性能内存（DIMC SRAM）	2 GB [1925]	~150 TB/s (片上交互)	矩阵乘法的驻留计算阵列
容量内存（off-chip LPDDR5X）	256 GB (128 GB/封装 × 2) [238]	400 GB/s (200 GB/s/封装)	模型权重驻留、KV cache、激活暂存

这种分工与 GPU/HBM 路线截然相反。GPU 拼命往 HBM 塞带宽（H100 约 3.35 TB/s），但 decode 时绝大部分权重读取无法隐藏延迟，导致有效利用率低于 30%。Corsair 则允许权重长期“冷”放在低速但便宜的 LPDDR5X 中，只在需要时流进 SRAM 计算宏，一次流入即可完成大量乘加，从而用区区 400 GB/s 的外部带宽撑起了数百用户的并发解码吞吐 [213]。

但必须指出一个关键限制：KV cache 的访问模式无法利用 DIMC 的复用优势。 对每个新 token，需要从 KV cache 中读取所有历史 key/value 向量，这些向量并不像权重那样有大量重用——因此 KV cache 的带宽消耗会直接落在 LPDDR5X 的 400 GB/s 上。对于长上下文或大 batch 场景，这个带宽可能成为新的瓶颈。d-Matrix 官方材料并未详细披露 KV cache 的组织方式（比如是否利用组批、压缩、远端 offload），推测其目标部署模式是搭配 GPU 做 prefill，而 Corsair 只负责相对较短的 decode burst，从而将 KV cache 的访问压力限制在合理范围。

---

2.5.3. Chiplet 与互联：用标准封装实现“乐高式”线性扩展

Corsair 的 chiplet 方案堪称实用主义的典范。它使用 TSMC 6nm 这一非最前沿但成本极佳、良率友好的工艺，每片 ASIC 由 4 个 chiplet 通过 DMX Link™（基于 BoW 的低功耗 die‑to‑die 互联）拼装而成，单张 PCIe 卡集成两个这种 4‑chiplet 封装，总共 8 个 chiplet [1925]。两卡之间再通过 DMX Bridge™ 高速连接，形成一个双卡逻辑单元，可容纳近百 GB 的模型权重而不必跨机箱通信 [210]。

这种从芯片到机柜的互联体系的妙处在于：

• Tensor parallelism 在 chiplet 间天然友好。 每个 chiplet 配备 RISC‑V 分发引擎，可直接对不同 chunk 的张量切片做矩阵运算，而 chip‑to‑chip 延迟极低、功耗可控 [209]。这绕开了 GPU 跨卡 NVLink 的昂贵开销，让细粒度的模型切分变得可行。
• 卡间 DMX Bridge 和以太网级 JetStream 架构形成侵略性扩展。 d-Matrix 展示的 SquadRack 概念将多节点 Corsair 与专用网络整合，对外呈现为一个统一的 decode 池 [1926]。换句话说，它既能塞进一个 2U 服务器做小规模部署，也能像“内存计算矿机”一样堆满整个机柜。

与 Cerebras WSE-3 的单晶圆不同，Corsair 的 chiplet 策略没有“全有或全无”的良率风险，成本可控，且迭代速度快——把下一代数模混合宏直接放进新一代 chiplet 即可，而不必推倒整张晶圆。但与 Groq LPU 相比，Corsair 的一个软肋是单卡 SRAM 总容量（2 GB）太小，无法让模型权重以“驻留”状态存在，必须承受流式加载的开销。只不过 Groq 的代价是模型必须整个塞进片内，Corsair 则是牺牲一部分延迟确定性换取了支持大几十 B 参数模型的能力。

---

2.5.4. 性能与能效：纸面数字耀眼，实测场景突出

d-Matrix 官方给出的峰值算力为 2,400 TFLOPS（INT8） 或 9,600 TFLOPS（INT4），能效 38 TOPS/W，单卡功耗约 600 W [209]。这些数字如果单纯对比 GPU 的 FP16 理论值并不公平，因为 decode 任务中 GPU 的实际利用率极低。

更具参考价值的是第三方机构的实测：在 Llama‑70B、4K 上下文的推理场景下，将 Corsair 作为 GPU 的 decode 协处理器，端到端响应时间从 24 秒大幅降至 2 秒以内 [1926]。这与 d-Matrix 声称的“最高 20 倍吞吐提升、延迟降至 1/20”相吻合 [233]。其背后的系统逻辑是：GPU 仍负责 prefill（高计算量、大矩阵乘法），Corsair 接管 decode（大量小 batch 矩阵-向量乘），从而解耦两种截然不同的负载，大幅提升整体系统的 token 生成效率和硬件利用率。

能效方面，38 TOPS/W 意味着用标准 PCIe 风冷卡就能实现高 token 吞吐，不过这个数字显然是在 DIMC 宏密集执行且外存访问占比低的理想情况下得到的。当长上下文推理导致 LPDDR5X 带宽吃紧时，实际的能效比会有所退化，这必须结合具体工作负载来评估。

---

2.5.5. 软件与生态：巧妙卡位，而非重新造轮子

d-Matrix 的商业策略很聪明：它不试图让用户扔掉 GPU、全部换成 Corsair，而是以 Aviator 软件栈 提供一种“插入式”的 decode 卸载方案。硬件侧每个 chiplet 的调度由 RISC‑V 小核负责，软件侧则提供分布式推理的原生支持，包含 pipeline parallelism、tensor parallelism，并可对接标准的 PyTorch 等上游框架 [218]。其思路是让 Corsair 在现有 GPU serving 集群中充当一块透明的“decode 加速卡”，而不需要重写整个服务堆栈。

当然，这并不意味着所有开发者都能无痛迁移。与成熟的 CUDA 生态、TensorRT‑LLM、vLLM 等相比，Aviator 的生态广度极其有限，模型移植时仍需针对 DIMC 的块浮点特性做量化适配，KV cache 管理、按 batch 调度等也需要与 GPU 侧的 prefill 引擎精细对齐。不过，比起那些要求全部 workload 都跑在自家硬件上的全栈方案，Corsair 的互补定位未来说服力更强——尤其在大型云厂商已经拥有海量 GPU 集群时，添购 decode 专用 ASIC 远比重建整个推理基建更符合经济逻辑。

---

2.5.6. 对比总结：与 Groq、Cerebras、GPU 的差异化竞争力

维度	d-Matrix Corsair	Groq LPU	Cerebras WSE-3	NVIDIA H100/H200
核心思路	数字存内计算（DIMC）突破 decode 内存墙	纯 SRAM 确定性执行，低延迟 decode	晶圆级整片 SRAM + weight streaming	HBM 大容量 + CUDA 通用计算
SRAM 角色	计算阵列（2 GB）	模型权重/KV cache 驻留（230 MB）	激活与 KV 驻留（44 GB）	L2 cache（~60 MB），地位次要
模型规模支持	通过 LPDDR5X 支持 70B+，多卡 scale	受限于 SRAM 容量，超大模型需大量芯片拼接	通过 MemoryX 支持 24T 参数	通过 HBM 容量支持 70B~数百 B
Decode 延迟	极低（异构解放 GPU），批量吞吐优秀	单流延迟极低，高通量下确定性	低（推理全在片内），但需流式权重	依赖 batch 隐藏延迟，单用户较高
长上下文/KV cache	受 LPDDR5X 带宽约束，适配中等长度	受限于 SRAM 容量，长度受限	44 GB SRAM 可容纳较长 KV	HBM 容量高，可支持长上下文
与 GPU 关系	解码协处理器，与 GPU prefill 分工	可独立端到端，但 batch 受限	独立系统，可同时 prefill+decode	全能但解码效率不够
生态与成熟度	Aviator 初具形态，需要 GPU 协同，仍小众	自研编译器+SDK，确定性强	Cerebras SDK，开源整合中	CUDA 生态绝对成熟

Corsair 的位置恰好处在“太专用”和“太通用”之间：它比 Groq 更适应大模型和大 batch，比 Cerebras 小巧灵活、成本低了两个数量级，比 GPU 在 decode 上提升了决定性的单位成本 token 产出。其核心风险依旧来自 KV‑cache 带宽可能成为新墙角，以及团队能否在主攻算力巨头和云厂商自研 ASIC 的夹缝中迅速占据足够大的部署份额。但无论如何，在 prefill/decode 离散部署成为共识的 2025 年，Corsair 这种“decode the killer, leave prefill to GPU”的架构理念，已经被众多实际测试证明不是纸上谈兵，而是 LLM 推理芯片里最接近商业可行性的专用解法之一。

2.6. SambaNova SN50：可重构数据流的“编译器定义芯片”与企业全栈交付

SambaNova 的第五代 Reconfigurable Dataflow Unit（RDU）——SN50，是当前 AI 推理 ASIC 赛道中最激进地将“编译器即硬件定义者”理念产品化的产物。它并非在 GPU 的骨架上雕花，而是从根上抛弃了冯·诺依曼的指令取指-执行循环，转而用编译器将整个模型的计算图直接映射为芯片上数据流的物理拓扑。TSMC 3 nm 工艺、双 chiplet 合封、3.2 PFLOPS FP8 算力、三层存储与最高 32K 芯片的 scale-out 能力，全部围绕一个目标：让 agentic 推理的每一跳延迟与每一 token 成本都成为可精确计算的工程指标，而非撞大运的统计值[272]。

2.6.1. 架构核心：PCU、PMU、AGC 与 RDN——数据流“乐高”的拼装逻辑

SN50 的 RDU 继承并放大了 SambaNova 一贯的“平铺式可重构”哲学。芯片由大量Pattern Compute Unit (PCU)、Pattern Memory Unit (PMU) 与 Address Generation and Coalescing Unit (AGCU) 组成，三者通过 Reconfigurable Dataflow Network (RDN)——一个二维 mesh 兼三维交换 fabric——紧密耦合[514]。SN50 双 chiplet 总计约 2080 个 PCU，每个 PCU 是一组可重构的 SIMD 流水线，能执行矩阵乘加、softmax、layer norm 等多种算子；PMU 则提供分布式 SRAM 片，既缓存权重又保存 KV Cache；AGCU 负责不规则访存与跨芯片数据路由[281]。

这套架构的“魔法”在于：SambaFlow 编译器并不生成指令，而是生成一份硬件配置位流（bitstream），直接决定每个 PCU 在此时刻执行何种计算、每个 PMU 分配多大空间、数据沿 RDN 的哪条物理路径流动。这意味着，一旦位流加载完成，芯片就进入“无指令、无取指、无 cache miss”的确定性流式执行——数据从一片 PMU 经 PCU 运算后直接流向下一片，中间无需反复穿越 HBM 或片外内存[2090]。与 GPU 的“kernel-by-kernel”模式相比，这种空间映射数据流可将数百个算子融合为一次连续的数据流管道，彻底消除了中间结果的片外搬运，从而在访存密集的 decode 阶段获得惊人的效率提升[514]。

2.6.2. 三层存储：SRAM + HBM + DDR5 的“热-温-冷”发动机

SN50 的存储层级设计是它区别于 Groq（纯 SRAM）和 Cerebras（晶圆级 SRAM）的关键差异化武器。片上分布式 SRAM（容量未公开，但前代 SN40L 为 520 MB，SN50 预计数倍于此）提供几十 TB/s 的极致带宽，用于存放当前 decode 步骤的 KV Cache 和热点权重；封装内 HBM（预计 192 GB 级别）以 ~8 TB/s 的带宽容纳完整模型和近期上下文；而片外 DDR5 则作为数百 GB 乃至 TB 级的大容量冷存储，用于驻留多模型副本与长尾 KV Cache[273]。

这一设计的直接收益是多模型秒级热切换。根据 SN40L 的实测数据，从 DDR 向 HBM 切换一个 7B 模型 checkpoint 仅需 60–90 ms，而同等条件下 GPU 服务栈需要约 800 ms[2301]。在 Composition of Experts（CoE）场景中，8 槽 SN40L 节点较 DGX H100 实现了 3.7× 的整体加速，模型切换速度提升 15–31×，机器占地减少 19×[2112]。SN50 更将这一能力推至 10 万亿参数模型与 1000 万 token 上下文长度，使其成为面向 agentic、多模型持久化状态的推理底座，而非仅跑单一大模型的加速器[306]。

2.6.3. 编译器：SambaFlow 是“灵魂”，不是“软件栈”

SambaNova 的软件护城河正是 SambaFlow，它并非简单的驱动或 runtime，而是一个完整的图编译器 + 硬件配置器。用户以标准 PyTorch/TensorFlow 编写模型，SambaFlow 捕获计算图，应用 o0（安全逐算子）或 o1（自动融合）模式进行算子融合，再通过空间映射将图“平铺”到 RDU 的物理单元上，最终生成 PEF（可执行位流文件）[308]。对于不支持的标准算子，开发者可通过高维张量索引 API 描述新算子，由 Template Compiler 生成优化的空间模板[308]。

这种“编译器决定硬件行为”的范式意味着：性能的天花板取决于编译器的优化质量，而非手工编写 kernel 的功力。SambaNova 提供了融合规则配置文件，允许对特定模型族（如 LLM）进行深度定制[2127]。但这也暴露了脆弱性：每当新模型架构（如 Mamba、原生多模态）出现，编译器团队必须投入巨大精力适配，否则性能会跌入“未优化”的低谷。目前 SambaFlow 已支持 PyTorch 2.x 生态，并提供 OpenAI 兼容 API 端点，但 vLLM、SGLang 等推理框架的深度适配仍需大量工程工作[2281]。

2.6.4. 企业部署：从芯片到全栈“数据主权”交付

SambaNova 的商业定位早已不是“卖芯片的”，而是以全栈 AI 系统公司的身份切入企业级推理市场。其产品矩阵包括：

• DataScale 硬件系统：集成 SN50 的整机柜 SambaRack，16 颗 RDU 高密部署，支持 256 加速器通过 multi-TB/s 互连[269]。
• SambaStack 软件平台：提供 on-premise 部署、Kubernetes 原生管理、模型热切换与多租户隔离，强调“45 分钟开箱即用”[2140]。
• SambaCloud 云服务：通过 API 提供 open-source 模型（如 Llama 4、DeepSeek）的推理服务，并支持 OpenAI 兼容接口，开发者可零成本迁移[2149]。
• SambaManaged 托管服务：为数据中心提供全托管推理节点，满足数据主权与合规要求[2235]。

这种“硬件+软件+云+托管”的全栈垂直整合，使 SambaNova 在政务、金融、国防等对数据隐私有严苛要求的领域占据优势。2026 年，SoftBank 成为 SN50 的首个部署客户，将在其日本 AI 数据中心利用 SN50 构建主权 AI 推理服务，并计划于 2026 年 10 月商用[275]。

更耐人寻味的是与 Intel 的深度合作。双方推出的异构推理蓝图将 LLM 推理拆分为三个阶段：GPU 负责 compute-bound 的 prefill，SN50 RDU 专攻 memory-bound 的 decode，Intel Xeon 6 则作为 host CPU 执行 agentic 工具调用与编排[312]。这种“分而治之”的架构凸显了 SambaNova 的自我定位：RDU 是 decode 的终极引擎，而非整个推理的万能药。同时，Intel 的全球渠道与 Xeon 生态为 SN50 触及更多企业客户提供了跳板[2161]。

2.6.5. 公司属性：芯片公司，还是 AI 系统公司？

SambaNova 的自我描述是“full-stack AI solutions provider”，其营收模型包括硬件销售、专业服务与订阅制云服务[2237]。从财务角度看，它必须在多条战线上同时作战：芯片设计、编译器开发、系统集成、云平台运营。这种“全栈”模式固然能最大化单客户价值，但研发资源的分散与对多代芯片持续迭代的依赖也是巨大风险。

2021 年 SambaNova 估值曾达 50 亿美元，但后续因市场调整与竞争加剧，二级市场估值一度缩水至约 16 亿美元[2181]。2026 年 Vista Equity 领投的 3.5 亿美元 Series E 则为其注入新血，估值回升至约 48 亿美元[2177]。公司 2025 年从训练业务转向聚焦推理云服务，并大幅简化产品线，集中火力攻打 agentic 推理[274]。这一战略转向是否成功，最终取决于 SN50 的落地速度与生态建设能否跑赢 Groq、Cerebras 以及 NVIDIA Rubin 的迭代。

结论：SambaNova 本质上是一家以 RDU 芯片为锚点的 AI 系统公司，而非单纯的芯片供应商。 它卖的不是裸片，而是“数据主权级低延迟推理”的整合承诺。在企业私有化部署这个对 TCO、时延和数据可控性极为敏感的战场上，SN50 的“编译器定义芯片”与三层存储直击 GPU 的软肋。但它的命运也系于 SambaFlow 的编译能力能否跟上模型架构的演化——可重构的“乐高”虽然灵活，但每次改变拼法都需要一位技艺高超的编译大师。

3. 互联网与云厂商自研类

3.1. Google TPU (v6–v8)：从”训练-推理一体”到”训练-推理分治”的三代进化

在所有云厂商自研 AI 芯片中，Google TPU 拥有最长的迭代历史、最深厚的技术积累，以及最独特的一条演进路径。从 2015 年 TPU v1 的纯推理 INT8 脉动阵列，到 2026 年 TPU v8 的”训练芯片（8t）与推理芯片（8i）彻底分道扬镳”，Google 用 11 年时间走完了一条从”辅助 GPU”到”主力训练+推理平台”再到”按工作负载专用化”的完整弧线。理解 v6→v8 三代 TPU 的演进逻辑，本质上就是理解 Google 如何用芯片-互联-编译器-网络四位一体的系统级协同设计，挑战 NVIDIA 在 AI 基础设施领域的统治地位。

3.1.1. TPU v6e “Trillium”：在 N5 工艺上榨出”架构红利”

Trillium 是 Google 第六代 TPU，也是迄今为止最”接地气”的一代——它并非追求极致性能，而是追求极致的性价比与部署密度。这枚芯片于 2024 年 5 月 Google I/O 发布 [2496]，2024 年 12 月正式 GA [383]，至今仍是 Google Cloud TPU 对外服务的主力机型。

3.1.1.1. 脉动阵列的”四倍扩容”

Trillium 最核心的架构变更只有一个：MXU（Matrix Multiply Unit）从之前四代（v2–v5p）的 128×128 扩展至 256×256 [329]。这意味着每个 MXU 每个周期可以完成 65,536 次 MAC 运算，是上一代的 4 倍。两个 MXU 组成一个 TensorCore，每芯片一个 TensorCore——总计 131,072 MAC/cycle [537]。

为什么是 256×256 而不是更大？这里有物理约束：脉动阵列的硅面积与边长的平方成正比，而数据进出的带宽需求与边长成正比。256×256 在 N5 工艺、约 800 mm² die size 的约束下，恰好是 Google 在面积、功耗、时钟频率三者之间找到的最优解。更重要的是，LLM 推理中矩阵乘法的典型维度（hidden dimension 如 4096、8192）是 256 的整数倍，这使得 MXU 利用率在大多数场景下接近峰值 [2428]。

值得注意的是，Trillium 的 MXU 仍然不原生支持 FP8——FP8 是通过软件模拟实现的 [331]。真正的原生 FP8 支持要等到 v7 Ironwood。这也说明了 Trillium 的定位：它是一枚”成熟工艺 + 成熟精度”的性价比芯片，而非”前沿精度”的激进探索。

3.1.1.2. HBM 与 SparseCore：推理的”左右手”

Trillium 每芯片配备 32 GB HBM（v5e 的 2 倍），带宽约 1,600 GB/s [533]。这个数字放到 2024–2025 年的 GPU 市场并不惊人——H100 有 80 GB / 3.35 TB/s，H200 有 141 GB / 4.8 TB/s。但 Google 的策略不是单芯片对决，而是Pod 级聚合：8 芯片构成 256 GB HBM 的推理节点，256 芯片构成 8 TB HBM 的 Pod，再通过 Jupiter 数据中心网络将多个 Pod 级联为 10 万+ 芯片的超级计算机 [335]。

Trillium 还引入了 第三代 SparseCore——这是 Google TPU 独有的、专为 embedding lookup 设计的加速器 [470]。在推荐系统和 MoE 模型的 expert routing 中，embedding 访问是典型的”随机、稀疏、memory-bound”操作，GPU 的 Tensor Core 对此效率极低（因为 warp divergence 和内存合并访问的限制）。SparseCore 通过可变 SIMD 宽度（FP32 时 8 元素，BF16 时 16 元素）和优化的内存访问模式，将 embedding 密集型模型的性能提升了 2 倍，DLRM DCNv2 基准测试更是提升了 5 倍 [331]。这是 Google 将自身广告/搜索业务需求直接硬件化的典型案例。

3.1.1.3. ICI：2D Torus 的成本优化逻辑

Trillium 的 ICI（Inter-Chip Interconnect）采用 2D 环形拓扑，每芯片 4 条 ICI 链路，总带宽 3,200 Gbps（400 GB/s），最大 Pod 为 256 芯片 [341]。与 v5p 的 3D Torus + OCS（光学电路交换机）方案相比，v6e 的 2D Torus 是”无 OCS 的静态网格”，省去了昂贵的光学交换层，大幅降低了 Pod 部署成本 [540]。

这恰恰反映了 Google 的 SKU 分化策略：“e”后缀（efficiency）用低成本 2D 互联，面向推理和中小规模训练；“p”后缀（performance）用 3D Torus + OCS，面向大规模预训练。Trillium 是 Google 最后一枚”e”后缀的 TPU [379]，之后这种二分法会被 v8 的更激进的分治策略取代。

3.1.2. TPU v7 “Ironwood”：推理时代的宣言

Ironwood 是 Google 第七代 TPU，于 2025 年 4 月 Google Cloud Next 发布，2025 年 11 月 GA [2316]。它是 Google 历史上第一枚明确以推理为第一设计目标的 TPU——Google 官方称之为”为推理时代打造的第一枚 TPU” [2397]。这枚芯片标志着 Google 的战略重心正式从”训练为王”转向”推理决胜”。

3.1.2.1. Chiplet 架构与原生 FP8

Ironwood 采用 双计算 chiplet 设计，每 chiplet 包含 1 个 TensorCore + 2 个 SparseCore，通过硅中介层（interposer）互联 [381]。单芯片总计 4,614 TFLOPS FP8 密集算力，BF16 约 2,300 TFLOPS [451]。这是 Google TPU 首次原生支持 FP8 精度——MXU 的数据路径可以同时处理两个 FP8 操作数，使 256×256 阵列的行为等同于 512×512 的有效脉动阵列 [331]。

HBM 方面，Ironwood 每芯片配备 192 GB HBM3e（8 个 stack），带宽 7.37–7.4 TB/s [2397]。这比 Trillium 的 32 GB / 1.6 TB/s 提升了整整 6 倍容量和 4.6 倍带宽。192 GB 意味着 Ironwood 可以单芯片驻留完整的 70B 参数模型（FP8 精度约需 70 GB + KV cache），而不需要张量并行切分——这对 Decode 阶段的低延迟推理至关重要。

3.1.2.2. ICI 的”光学飞跃”

Ironwood 的 ICI 是 Google 迄今为止最雄心勃勃的互联设计：

• 每芯片 4 条 ICI 链路，总带宽 9.6 Tbps（1.2 TB/s）双向 [451]
• Cube 内：64 芯片组成 4×4×4 的 3D Torus，通过铜缆直连 [381]
• Cube 间：通过 OCS（光学电路交换机） 将 144 个 Cube 连接为 9,216 芯片的 Superpod [449]

这个 Superpod 的聚合算力是 42.5 ExaFLOPS (FP8)，聚合 HBM 容量 1.77 PB，超过了当时全球最快超级计算机 El Capitan（1.7 ExaFLOPS）的 24 倍 [331]。而且 OCS 是动态可重构的——Google 可以在不改变物理布线的情况下，重新配置 Cube 之间的拓扑连接，以适应不同的并行策略。

但这里有一个关键观察：Ironwood 的 ICI 带宽（1.2 TB/s）仍然低于同期 NVIDIA Blackwell 的 NVLink 5（1.8 TB/s） [330]。Google 的补偿策略是：用更大规模的 Pod（9,216 vs 72 GPU）和更高效的拓扑（3D Torus + OCS）来弥补单链路带宽的差距。这本质上是”用系统架构弥补微架构劣势”的思路。

3.1.2.3. 推理优化：从”能推理”到”为推理而生”

Ironwood 在推理方面做了几项针对性的硬件优化：

• 增强的 SparseCore：专门优化了 MoE 模型中 expert 选择的稀疏访问模式 [2397]。在 MoE 推理中，每个 token 仅激活 2–8 个 expert，这意味着大量不规则的内存访问——SparseCore 可以将这些操作从 TensorCore 卸载，避免脉动阵列在”等待 embedding 数据”时空转。

• Pathways 运行时集成：Ironwood 的编译器 XLA 与 Pathways 分布式运行时深度协同，实现了跨数千芯片的 RDMA（远程直接内存访问），芯片间可以直接交换数据而无需经过 host CPU [449]。这大大降低了 Decode 阶段 all-reduce 的延迟。

• 与 Gemini 3 的协同设计：Google DeepMind 的 Gemini 3 模型在 2025 年底至 2026 年初的推理部署完全运行在 Ironwood 上 [335]。这是 Google 内部”模型-芯片协同设计”闭环的巅峰案例——芯片架构师与模型研究员直接对话，硬件特性为模型需求定制。

3.1.3. TPU v8：训练与推理的”终极分治”

2026 年 4 月 Google Cloud Next，Google 宣布了第八代 TPU 的根本性架构分裂：TPU 8t（训练）和 TPU 8i（推理）——两枚在架构、设计团队、互联拓扑、甚至制造工艺上都截然不同的芯片 [387]。这标志着 Google 正式承认了一个业界争论已久的事实：训练和推理的硬件需求已经分化到无法用同一枚芯片同时优化的程度。

3.1.3.1. TPU 8t “Sunfish”：训练专用

参数	规格
设计伙伴	Broadcom [394]
峰值算力	12.6 FP4 PFLOPs [332]
HBM	216 GB HBM3e，6,528 GB/s [332]
片上 SRAM (Vmem)	128 MB
ICI	19.2 Tb/s 双向，3D Torus [341]
Superpod	9,600 芯片，121 FP4 ExaFLOPS [461]
扩展网络	Virgo Network：47 Pb/s 非阻塞 bisectional 带宽，可扩展至 134,000+ 芯片，甚至 100 万+ 芯片线性扩展 [388]

8t 的互联拓扑延续了 3D Torus 的传统——这是训练工作负载（以大规模 all-reduce 为主）最成熟的拓扑。但真正的突破在于 Virgo Network：一个高 radix、多平面、光学交换的数据中心级网络，配合 JAX 的 GSPMD/Shardy 自动分片和 Pathways 分布式运行时，实现了接近线性的超大规模扩展。这基本上是 Google 在说：“我们不需要 InfiniBand，我们自己造了一个更好的。“

3.1.3.2. TPU 8i “Zebrafish”：推理专用

参数	规格
设计伙伴	MediaTek（首次！）[394]
峰值算力	10.1 FP4 PFLOPs [341]
HBM	288 GB HBM3e，8,601 GB/s [394]
片上 SRAM	384 MB（Ironwood 的 3 倍）[392]
ICI	19.2 Tb/s 双向 [332]
Pod	1,152 芯片，11.6 FP8 ExaFLOPS [399]
关键特性	CAE（Collectives Acceleration Engine）、Boardfly 拓扑 [387]

8i 的架构设计体现了一个清晰的核心理念：推理芯片不需要训练芯片那么强的计算密度，但需要更大的内存、更低的通信延迟、以及针对 Decode 阶段特殊通信模式的硬件加速。

384 MB 片上 SRAM 是 8i 最引人注目的数字。这个容量足以容纳推理中 KV cache 的”热”部分——对于典型的 70B 参数模型，单请求的 KV cache 在 128K 上下文下可达数百 MB，但大部分请求的 KV cache 是随时间衰减的。384 MB 的 SRAM 可以充当 KV cache 的 L1 缓存，大幅减少对 HBM 的随机访问。Google 官方明确表示，这个 SRAM 容量是”为推理模型在生产规模下的 KV cache 足迹量身定制的” [392]。

CAE（Collectives Acceleration Engine） 是 8i 独有的硬件单元，取代了 Ironwood 上的 4 个 SparseCore [387]。它的作用是什么？在 Decode 阶段，每个 token 生成后需要进行一次 all-reduce 来同步各芯片上的输出——这个操作虽然计算量不大，但延迟直接影响端到端 token 生成时间。CAE 将 on-chip 的 collective 操作延迟降低了 最多 5 倍 [2334]，这对 chain-of-thought 推理（需要数百步串行 decode）的影响是巨大的。

Boardfly 拓扑是 8i 的另一个杀手锏。它放弃了训练系统惯用的 3D Torus，转而采用受 Dragonfly 拓扑启发的三级分层互联 [2337]：

• Level 1：4 芯片全连接的基础块
• Level 2：8 个基础块全连接为一组
• Level 3：36 组全连接为 1,152 芯片 Pod

这不仅将网络直径从 3D Torus 的 16 跳降至 7 跳（减少 56%） [388]，更重要的是——它专门优化了 MoE 推理中的 all-to-all 通信模式。在 MoE 模型中，每个 token 需要被路由到不同的 expert，这要求 chip-to-chip 通信具有极低的尾延迟。Boardfly 的扁平化拓扑确保任意两芯片之间的跳数不超过 7，从而将尾延迟控制在一个可预测的范围内——这对 agentic AI 场景（多步推理、多工具调用）至关重要 [388]。

3.1.3.3. 工艺节点、供应链与 MediaTek 的加入

TPU v8 最有意思的变化不在芯片本身，而在供应链。Google 首次将推理芯片（8i）的设计外包给了 MediaTek，而训练芯片（8t）仍由长期合作伙伴 Broadcom 负责 [394]。这是一个”分而治之”的供应链策略：

• Broadcom 拥有大规模 ASIC 设计、CoWoS 封装和高速 SerDes 的深厚经验，适合训练芯片的高复杂度
• MediaTek 在移动 SoC 的能效优化、成本控制和量产管理方面经验丰富，适合推理芯片的相对简化设计

关于工艺节点，存在两种不同说法：Tom’s Hardware 报道称使用 TSMC N3 家族（3nm FinFET）[392]，而 The Next Web、Tech-Insider 等多家半导体媒体指向 TSMC N2（2nm GAA nanosheet），目标 2027 年底外部客户可用 [395]。考虑到 TSMC N2 在 2026 年中仍处于风险试产阶段，两种说法可能并不矛盾：也许首批内部部署的 v8 使用 N3，而外销版本（2027 年底）使用 N2。无论哪种情况，TPU v8 都代表着 Google TPU 首次进入 3nm 以下节点——这将带来显著的能效提升（官方宣称 2× perf/watt vs Ironwood [387]）。

3.1.4. 软件生态：JAX → XLA → Pathways 的”三位一体”

Google TPU 的软件生态是一把双刃剑。一方面，JAX + XLA + Pathways 的组合是 AI 硬件领域最精密的软硬件协同设计体系；另一方面，它长期以来是 Google 内部工具链的”外溢”，对 PyTorch 生态的兼容性一直落后于 NVIDIA CUDA。

3.1.4.1. XLA 编译器：所有道路的终点

所有 TPU 上的框架——无论是 JAX、PyTorch/XLA 还是 TensorFlow——最终都通过 XLA（Accelerated Linear Algebra）编译器 生成 HLO（High-Level Optimizer）图，再由 XLA 进行全程序分析、算子融合、内存布局优化，最终编译为 TPU 可执行代码 [2385]。XLA 的”全程序视图”优势在于：它可以跨算子边界进行优化（如将 attention 的多个 matmul + softmax 融合为单个 kernel），这是 GPU 上逐 kernel 编译的 CUDA 难以做到的。

从 Ironwood 开始，XLA 编译器与硬件协同设计，实现了 FP8 的原生支持——编译器自动识别可以使用 FP8 精度的算子，并插入适当的量化/反量化节点 [2390]。在 v8 时代，XLA 的 GSPMD 自动分片系统被更先进的 Shardy 取代，后者支持更好的约束传播和动态形状处理 [331]。

3.1.4.2. PyTorch 的”第二通道”：从 PTXLA 到 TorchTPU

长期以来，在 TPU 上运行 PyTorch 的唯一方式是 PyTorch/XLA（PTXLA）——它的核心问题是”懒惰张量”（lazy tensor）：PyTorch 代码被记录为计算图，而非即时执行，这导致调试困难、与 PyTorch 原生 API（如 torch.distributed、FSDP2）不兼容 [379]。

2025 年 10 月，Google 提出了 RFC #9684，启动了一个根本性的方向转变 [2407]。2026 年 4 月，TorchTPU 正式开源 [2406]：

• 使用 PyTorch 的 PrivateUse1 接口实现原生 eager 执行，无需静态图编译 [1817]
• 原生支持 torch.compile、DTensor、FSDP2、DDP 等 PyTorch 分布式 API [2411]
• 底层仍对接 XLA 编译器，但桥接层从”图捕获”变为”算子级转换” [2412]
• 一旦成熟，将完全取代 PyTorch/XLA [2382]

这意味着到 2026–2027 年，开发者可以在 TPU 上获得与 GPU 几乎一致的 PyTorch 体验——这是 Google 打破 CUDA 生态锁定最重要的一步棋。

3.1.4.3. 推理服务栈：JetStream 与 vLLM-TPU

Google 的推理服务栈分为两条路径 [2384]：

• JetStream：Google 自研的吞吐量/内存优化推理引擎，基于 Pathways 运行时，直接服务于 Gemini 等内部模型。支持 continuous batching、KV cache 优化、int8 量化、prefix caching、speculative decoding [2359]。2025 年 4 月集成 Pathways 后，JetStream 实现了 disaggregated serving（prefill 和 decode 分离部署）[344]。

• vLLM-TPU：面向开源模型生态的推理引擎。2025 年经历了重大重构，采用 SPMD 编程模型（替代了之前的 GPU 风格多 worker 模式），实现了通信与计算重叠，吞吐量比 2025 年 2 月的原型提升了近 5 倍 [2017]。2025 年 Q3 成为 Google AI Hypercomputer 的标准推理组件 [2368]。

在 Trillium 上，JetStream + vLLM 的联合部署已经实现了 70B 级别模型长序列推理的 3,500+ tokens/s 每节点（8 芯片） [344]。在 Ironwood 上，推理性能是 Trillium 的约 4 倍 [333]。

3.1.5. TPU vs GPU：推理场景的系统性对比

将 Google TPU 与 NVIDIA GPU 放在一起比较，需要先理解一个根本性差异：TPU 是”云原生”芯片，GPU 是”通用加速器”。这决定了它们在推理场景中的不同定位。

3.1.5.1. 关键指标对比

维度	TPU v6e Trillium	TPU v7 Ironwood	NVIDIA H100	NVIDIA B200
峰值算力 (BF16/FP8)	918 TFLOPS (BF16)	4,614 TFLOPS (FP8)	989 TFLOPS (FP8)	4,500 TFLOPS (FP8)
HBM 容量	32 GB	192 GB	80 GB	192 GB
HBM 带宽	~1,600 GB/s	~7,400 GB/s	3,350 GB/s	8,000 GB/s
片间互联带宽	3,200 Gbps (ICI)	9,600 Gbps (ICI)	900 GB/s (NVLink 4)	1,800 GB/s (NVLink 5)
最大原生域	256 芯片 (Pod)	9,216 芯片 (Superpod)	8 GPU (NVSwitch)	72 GPU (NVSwitch)
工艺	TSMC N5	TSMC 5nm	TSMC 4N	TSMC 4NP
TDP（估算）	~380W	~600W	700W	1,000W
软件生态	JAX + XLA + TorchTPU	JAX + XLA + TorchTPU	CUDA (成熟)	CUDA (成熟)

3.1.5.2. Prefill 阶段：GPU 仍占优，TPU 在追赶

Prefill 是大批量、大矩阵乘法的计算密集型阶段。GPU 的优势在于：高时钟频率、大 batch 下的高利用率、成熟的 CUDA kernel（如 FlashAttention-3）。在 batch-1 的短上下文场景，H100 在 LLaMA 70B 上的单 token 延迟（约 150 tokens/s）优于 Trillium（约 120 tokens/s）[1244]。

但 TPU 的脉动阵列在大 batch场景下有独特优势：XLA 的确定性执行和静态编译使得 batch 扩展时的利用率衰减远小于 GPU [342]。在 batch 64+ 时，Trillium 的吞吐量可达到 800–1,000 tokens/s/chip（7B 模型）[342]。此外，Ironwood 的 192 GB HBM 意味着 70B 模型可以单芯片驻留，无需张量并行切分——这避免了 Prefill 阶段的跨芯片通信开销。

3.1.5.3. Decode 阶段：TPU 的系统级优势开始显现

Decode 是 memory-bound、低 batch、低延迟的阶段。这里 TPU 有三个关键优势：

1. 确定性执行：脉动阵列 + XLA 静态编译意味着每个 token 的生成延迟是可预测的，没有 GPU 上 warp scheduler 的动态调度不确定性。这对 SLA 敏感的推理服务至关重要。

2. ICI 的 Pod 级扩展：NVLink 只能连接 8–72 个 GPU，而 Ironwood 的 ICI 直接连接 9,216 个 TPU。这意味着在 MoE 模型中，expert 可以分布在数百个芯片上，而 all-to-all 通信无需经过 InfiniBand 或以太网——ICI 的延迟和带宽远优于前者。

3. CAE（v8 引入）：将 Decode 中最频繁的 collective 操作延迟降低 5 倍，直接转化为端到端 token 延迟的降低 [2334]。

但 GPU 也有其不可忽视的优势：H200/B200 的 HBM 带宽（4.8–8.0 TB/s）仍然高于 Ironwood（7.4 TB/s），且 CUDA 生态中 vLLM、SGLang、TensorRT-LLM 等推理框架的优化成熟度远超 JetStream/vLLM-TPU。2025 年 Artificial Analysis 的独立基准测试显示，NVIDIA H100/B200 在 tokens-per-dollar 指标上比 TPU v6e 有约 5 倍的领先优势 [2443]——但这个数字可能低估了 TPU 在 Google 内部优化后的表现（Google 自身使用 JetStream + Pathways，而非第三方基准测试中使用的 vLLM-TPU）。

3.1.5.4. 成本：TPU 的”隐性优势”

TPU 最大的优势在于总拥有成本（TCO）。作为云厂商自研芯片，Google 不需要为 TPU 支付 NVIDIA 的毛利率（约 70–75%），也不需要支付 HBM 的中间商加价。SemiAnalysis 估算，Ironwood 在全 3D Torus 配置下的每芯片 TCO 比 NVIDIA GB200 低约 44% [379]。Google Cloud 的 TPU 实例定价也反映了这一点：v6e 按需价格约 $0.39–$1.375/芯片-小时 [334]，而同等算力的 H100 实例通常为 $2.00–$5.50/GPU-小时 [2529]。

更关键的是，Google 的 AI Hypercomputer 理念允许训练和推理使用同一套 TPU 基础设施——Gemini 模型在 v5e/v6e 上训练，直接在 v6e/v7 上推理，无需模型转换 [335]。这种”训推一体”的流程简化对 Google 内部 AI 产品的迭代速度有巨大价值，但对 Google Cloud 的外部客户来说，它的吸引力取决于客户是否愿意绑定 Google 的 TPU 生态。

3.1.6. 从 v6 到 v8 的演进逻辑总结

回顾 Trillium → Ironwood → TPU 8t/8i 三代演进，可以清晰看到 Google 的三条设计主线和一条隐含的战略转变：

主线一：MXU 的”大数组”策略。从 v5 的 128×128 到 v6 的 256×256，Google 选择了一条”大脉动阵列 + 高利用率”的路线，而非 NVIDIA 的”小 Tensor Core + 高频率”路线。大阵列的优势在于确定性执行和能效（67% 能效提升 [384]），代价是灵活性降低。

主线二：从”e/p 二分”到”t/i 分治”。v5/v6 时代，Google 用”e”（efficiency）和”p”（performance）后缀区分推理和训练优化。v8 时代，训练和推理芯片彻底分道扬镳——不同的设计团队、不同的互联拓扑、不同的 SRAM 容量、不同的加速单元。这是对”推理和训练是不同 workload”这一事实的最终承认。

主线三：系统 > 芯片。TPU 的竞争力从来不是单芯片的 FLOPS 或 HBM 带宽，而是 ICI + Jupiter DCN + XLA 编译器 + Pathways 运行时 构成的系统级能力。Ironwood 的 9,216 芯片 Superpod 和 v8 的 100 万+ 芯片 Virgo Network，都是”系统架构定义芯片架构”的典型案例。

隐含的战略转变：从内部工具到云服务基础设施。v6e 是 Google 首次将 TPU 作为通用云服务大规模推向市场——Anthropic 签署了数十万 Trillium 芯片的租赁协议，Meta 也在洽谈大规模 TPU 部署 [2313]。v8 引入 MediaTek 作为设计伙伴，也是为外销和量产做准备。Google TPU 正在从”Google 的 TPU”变成”云端的 TPU”——这或许是最大的变化。

3.2. Microsoft Maia 200：以推理为锚、以 Azure 为基的自研硅战略

在分析 Maia 200 之前，有一个关键认知需要先厘清：微软做自研芯片不是为了卖芯片，而是为了卖 token。 这与独立 ASIC 公司（如 Groq、d-Matrix）的商业逻辑有本质区别——Maia 系列的每一项技术决策，都根植于 Azure 内部工作负载的真实需求、成本结构和数据中心物理约束。它的对手不是 NVIDIA 的 GPU 产品线本身，而是”租用 NVIDIA GPU 跑推理的单 token 成本”。

---

3.2.1. 战略动机：推理成本正在吃掉云服务的利润

微软的 AI 芯片自研之路，可以用三个关键词概括：省钱、控货、协同优化。

省钱是最直接的驱动力。微软是 NVIDIA 全球最大的客户之一，每年在 GPU 采购上花费数十亿美元 [2598]。当 AI 工作负载从”训练军备竞赛”转向”推理规模化部署”，token 生成成本成为 Azure OpenAI、Microsoft 365 Copilot、Foundry 等核心业务的主要运营支出。Scott Guthrie（微软云与 AI 执行副总裁）在 Maia 200 发布会上直言：该芯片比 Azure 机队中最新一代硬件性能/美元高出 30% [302]。对于每天生成数以万亿计 token 的微软来说，30% 的 TCO 改善意味着每年节省数十亿美元。

控货是战略层面的考量。GPU 供应长期受制于台积电 CoWoS 产能、HBM 供应链和 NVIDIA 的分配策略。2024-2025 年的 GPU 短缺已经充分证明：完全依赖第三方供应商意味着将核心业务的命脉交到他人手中。Maia 系列让微软获得了对自身推理基础设施的”供应主权”——即便 Maia 不会完全替代 GPU，它也提供了谈判筹码和供应弹性 [2564]。

协同优化是云厂商自研芯片最深层的优势。微软拥有真实的工作负载（GPT-5.2、Copilot、Foundry）、真实的数据中心、真实的功耗/散热/网络约束。Maia 团队可以在芯片设计阶段就精确模拟 LLM 推理工作负载的行为，将硅、网络、散热、软件栈作为一个整体系统进行优化 [2539]。这种”从硅到服务”的垂直整合深度，是独立芯片公司无法企及的。

一个被低估的细节：微软在 Maia 200 上实现了一个惊人的工程速度纪录——从 first silicon 到数据中心机架部署的时间不到同类 AI 基础设施项目的一半，AI 模型在首批封装芯片到达后数天内即开始运行 [286]。这种速度背后，是芯片团队、数据中心团队、软件团队和 OpenAI 工作负载团队之间高度耦合的协同能力。

---

3.2.2. 从 Maia 100 到 Maia 200：两代产品间的代际飞跃

理解 Maia 200 需要先回顾 Maia 100。2023 年 11 月，微软在 Ignite 大会上首次公布了 Maia 100——其第一代自研 AI 加速器。Maia 100 基于 TSMC 5nm 工艺，1050 亿晶体管，配备 64GB HBM2E（1.8 TB/s 带宽），TDP 500-700W，采用 CoWoS-S 封装 [414]。其计算架构包含一个 16×16 的 tensor unit 和一个可编程向量处理器，支持 FP32 和 BF16 [438]。

Maia 100 的定位是试水——验证自研芯片能否在 Azure 内部跑通 LLM 推理。微软将其部署在定制机架”Ares”中，配合第一代闭环液冷”sidekick”散热单元，主要用于运行 GPT-3.5-Turbo 等 Azure OpenAI 工作负载，以释放 GPU 容量给更重要的训练任务 [2540]。

但 Maia 100 有明显的保守痕迹：使用 HBM2E 而非 HBM3/HBM3e（避免与 NVIDIA 争抢最新 HBM 产能）[414]，FP8 支持不够原生，芯片规模偏小。第二代 Maia 200 则是一次全面激进的代际跃迁：

维度	Maia 100	Maia 200	提升幅度
工艺节点	TSMC 5nm (N5)	TSMC 3nm (N3)	全节点跨越
晶体管数	~1050 亿	~1400 亿	+33%
HBM	64GB HBM2E	216GB HBM3e	3.4× 容量
HBM 带宽	1.8 TB/s	7 TB/s	3.9× 带宽
片上 SRAM	未公布（推测~100MB级）	272 MB	大幅提升
峰值算力 (FP4)	不支持	>10 PFLOPS	从无到有
峰值算力 (FP8)	未明确	>5 PFLOPS	—
片间互联带宽	未公布	2.8 TB/s 双向	—
最大集群规模	~2,304 加速器	6,144 加速器	2.7×
SoC TDP	500-700W	750W	小幅提升
液冷	第一代 sidekick	第二代闭环液冷	成熟度提升

Maia 200 内部代号为 “Braga”，原本计划 2025 年量产，但经历了至少六个月的延迟 [413]。据 The Information 和 Reuters 报道，延迟原因包括：OpenAI 提出的新功能需求导致设计变更、芯片在仿真中不稳定、以及芯片设计团队的高员工流失率 [2612]。这是一个值得深思的细节——它既反映了深度绑定大模型客户可能带来的设计迭代压力，也揭示了硅谷 AI 芯片人才争夺战的激烈程度。

---

3.2.3. 芯片架构：推理优先、窄精度原生的 Tile 化设计

Maia 200 的架构体现了微软对”推理究竟需要什么”的深刻理解：推理不是训练的低配版，而是一个完全不同的计算问题。 训练需要高精度（FP16/BF16/FP32）、大 batch、高算力密度；推理（尤其是 decode）需要低精度（FP4/FP8）、低延迟、高内存带宽。

Maia 200 的计算架构以 Tile 为最小自治单元，每个 Tile 包含四个核心组件 [2586]：

• Tile Tensor Unit (TTU)：矩阵乘法/卷积加速器，原生仅支持 FP8、FP6、FP4 精度，支持混合精度模式（如 FP8 激活 × FP4 权重）[287]。BF16 和 FP32 精度不在 TTU 硬件支持范围内，必须卸载到向量处理器执行，且性能大幅下降 [302]。
• Tile Vector Processor (TVP)：可编程 SIMD 引擎，支持 FP8 以及 BF16/FP16/FP32 等更广泛的数据类型 [2586]。TVP 负责 TTU 无法覆盖的算子——如 attention 中的 softmax、layer norm、激活函数、以及 MoE routing 等非矩阵乘操作。
• Tile SRAM (TSRAM)：多 bank 本地 SRAM，为 Tile 内的计算引擎提供低延迟数据供给 [2586]。
• Tile DMA：Tile 级 DMA 引擎，支持 1D/2D/3D strided movement，在 TSRAM、HBM 和外部接口之间高效搬运张量数据，避免计算流水线停顿 [2531]。

多个 Tile 组成 Cluster（第二级局部性层级），再通过一个层次化 Network-on-Chip (NoC) 互连。NoC 在逻辑上分为两个平面：数据平面（承载 bulk tensor traffic）和控制平面（承载低延迟的同步和控制信号）[2586]。这种分离设计确保了大批量数据搬运不会阻塞关键的同步操作。

一个关键架构选择：TTU 不原生支持 BF16/FP16。 这意味着 Maia 200 是一块纯粹的推理芯片，而非训练+推理通用芯片。如果用户试图在 Maia 200 上跑训练或高精度推理，只能使用 TVP 以极低的效率执行。这是微软与 Google TPU（兼顾训练和推理）在哲学上的根本分歧——微软赌的是推理市场将比训练市场更大、更持久、对成本更敏感。

整个数据移动架构围绕一个多级 DMA 子系统构建，与层次化 NoC 紧密耦合 [287]。DMA 引擎支持多通道高带宽传输，能高效搬运常见的 ML 张量布局——这是 Maia 200 区别于 GPU cache hierarchy 的核心设计特征：在 GPU 中，数据移动大量依赖硬件 cache 的自动预取和替换策略，而 Maia 200 选择了更接近 deterministic dataflow 的显式 DMA 方案，让软件/编译器对数据移动有更精确的控制。

---

3.2.4. 存储层级：272MB SRAM + 216GB HBM3e 的混合策略

Maia 200 的存储设计是理解其推理定位的关键。它没有像 Groq 那样走纯 SRAM 路线，也没有像 Cerebras 那样用晶圆级 SRAM 替代 HBM，而是构建了一个务实的两层混合存储体系：

• 片上 SRAM：总计 272 MB（含 CSRAM 集中式 SRAM + TSRAM 分布式 Tile SRAM）[286]。带宽未公开，但结合层次化 NoC 和 DMA 的设计，内部聚合带宽应在数十 TB/s 量级。SRAM 的核心用途是驻留 tile 间频繁复用的数据——如 attention 计算中的中间张量、部分权重缓存、以及 DMA 流水线中的 staging buffer。
• HBM3e：216 GB 容量，7 TB/s 带宽 [286]。这是 Maia 200 对 NVIDIA H200（141GB HBM3e @ 4.8 TB/s）和 B200（192GB HBM3e @ 8 TB/s）的直接对标。216GB 的容量意味着可以在一颗芯片上以 FP4 精度驻留超过 400B 参数的模型权重，或以 FP8 精度驻留约 200B 参数模型。

这个存储配置反映了一个务实判断：对于生产级 LLM 推理，纯 SRAM 路线（Groq）的容量限制在经济上不可行，而单纯依赖 HBM 带宽（GPU）无法充分隐藏 decode 阶段的内存延迟。 Maia 200 的策略是：用大规模 HBM 保证模型容量，用大容量 SRAM + 专用 DMA + NoC 保证数据供给效率，用窄精度（FP4/FP8）压缩有效带宽需求。

值得注意的是，Maia 200 的 7 TB/s HBM 带宽相对于 H200 的 4.8 TB/s 有显著提升，但略低于 B200 的 8 TB/s。然而在 decode 场景中，实际有效带宽利用率比峰值带宽更重要——这正是 Maia 200 的 DMA + NoC 架构试图优化的方向。

KV cache 的存储位置是一个微软未详细披露的关键问题。216GB HBM 中，模型权重（以 FP4 约 200GB 可容纳 400B 参数）和 KV cache 需要共享空间。对于长上下文推理（如 128K tokens），KV cache 可能消耗数十 GB 容量，显著压缩可用于权重的 HBM 空间。微软的解决方案可能包括：跨多芯片 tensor parallelism 切分 KV cache、利用 272MB SRAM 缓存热点 KV 向量、或通过 Ethernet 互联将 KV cache 卸载到池化内存节点。

---

3.2.5. 互联架构：标准以太网取代专有 Fabric 的胆识

Maia 200 最引人注目的设计决策之一，是其片间互联完全基于标准以太网，而非 NVIDIA NVLink/NVSwitch 这样的专有 fabric [322]。这对一个 hyperscaler 自研芯片来说，既是技术选择，也是战略宣言。

架构拓扑：

• Tray 内互联：每台 blade server 搭载 4 颗 Maia 200 加速器 + 1 颗 Cobalt 200 Arm CPU。4 颗加速器之间通过**直接非交换链路（Fully Connected Quads, FCQ）**全互联，保持高带宽通信本地化 [286]。
• Tray 间/Rack 间互联：采用两层 scale-up 网络拓扑，基于标准以太网配合微软自研的 AI Transport Layer (ATL) 协议 [2531]。每颗芯片集成的 on-die NIC 提供 2.8 TB/s 双向专用 scale-up 带宽（推测为 56 条 400 Gb/s SerDes 通道）[325]。
• 最大集群规模：单一 scale-up domain 可扩展至 6,144 颗加速器（约 1,536 个节点），相比之下 Maia 100 仅支持 2,304 颗 [2579]。

ATL 协议是这套互联体系的核心创新。它提供packet spraying、multipath routing、congestion-resistant flow control 等传输层特性 [2531]。传统以太网在 AI 集群中的痛点是 tail latency 和 congestion collapse——ATL 通过自定义传输层直接解决这些问题，使得标准以太网交换机的成本优势得以发挥，同时逼近专有 fabric 的性能可预测性。

为什么选择以太网而非自研专有 fabric？ 这个决策背后有几个考量：

1. 成本：以太网交换机是地球上最成熟的网络设备，单位带宽成本远低于 NVLink Switch 或 Google ICI 的专有方案。
2. 供应链：不依赖 NVIDIA 的 NVSwitch 生态，也不需自建专有交换机产线。
3. 部署速度：Azure 数据中心已有成熟的以太网基础设施，Maia 200 可以更快地融入现有 topology。
4. 生态系统：使用标准以太网意味着 Maia 集群可以更容易地与 Azure 的通用计算、存储网络互通。

但以太网路线也有代价：相比 NVLink 的 GPU-to-GPU 直接内存访问（具有极低延迟和 cache coherence），ATL over Ethernet 的延迟更高、协议开销更大。对于 tensor parallelism 中频繁的 all-reduce 操作，这可能成为性能瓶颈。微软的应对策略是：将 TP 通信限制在 tray 内的 FCQ 直连链路中（低延迟），而 tray 间/rack 间使用 pipeline parallelism 或 expert parallelism（通信频次低、数据量大）[286]。

---

3.2.6. 液冷与机柜级设计：从”sidekick”到原生液冷

Maia 200 的散热设计是理解微软数据中心战略的重要窗口。750W TDP 的芯片已经无法用传统风冷散热——每一颗 Maia 200 的功耗密度已经接近甚至超过 NVIDIA H100（700W）和 B200（1000W）[2549]。

微软的液冷方案经历了两次迭代：

• Maia 100 时代：由于现有 Azure 数据中心并非为大规模液冷而建，微软开发了”sidekick”外部散热单元——一个放置在机架旁边的闭环液冷 heat exchanger，通过冷板（cold plate）将芯片热量传导至外部循环流体 [2550]。
• Maia 200 时代：升级为第二代闭环液冷 Heat Exchanger Unit，支持更密集的机架部署 [287]。同时，微软在新建的 AI 专用数据中心（如 Fairwater 园区）中直接将液冷基础设施整合到建筑设计中，实现了更高的机架功率密度 [2557]。

Maia 200 的硬件系统采用定制机架（非标准 19” OCP 机架），每机架容纳 8 台 blade server、共 32 颗 Maia 200 加速器，总功率约 65 kW/rack [2549]。每台 blade server 搭载 4 颗 Maia 200 + 1 颗 Cobalt 200 CPU（微软自研 Arm 服务器 CPU），形成紧密的计算-网络-散热一体化单元 [325]。

这套系统设计的精妙之处在于：它不是一个”芯片”产品，而是一个”基础设施单元”。 微软控制从芯片、网络、散热到 Azure 控制平面（security, telemetry, diagnostics, management）的整个堆栈 [286]。这种垂直整合度使得 Maia 200 的部署效率远超在 Azure 中部署 NVIDIA GPU——后者需要适配 NVIDIA 的 NVLink topology、DGX 参考设计、以及 Mellanox 网络栈，这些都不是微软能完全控制的。

---

3.2.7. 与 OpenAI 工作负载的深度耦合

Maia 200 从设计阶段就与 OpenAI 的工作负载深度绑定。微软明确表示，Maia 200 当前已在 Azure 美国中部区域（Des Moines, Iowa）和西部 3 区域（Phoenix, Arizona） 部署，直接服务于 OpenAI 的 GPT-5.2 模型推理，同时支撑 Microsoft Foundry 和 Microsoft 365 Copilot [286]。

这种绑定关系有几个层面的含义：

第一，工作负载驱动的芯片设计。 Maia 200 的 FP4/FP8 原生精度选择、HBM 容量/带宽配比、DMA 架构、甚至延迟期间的设计变更，都直接反映了 OpenAI 对 GPT 系列模型推理特征的需求 [2613]。据报道，OpenAI 在 Braga（Maia 200 代号）开发期间提出的新功能需求导致了芯片仿真不稳定和项目延期 [2612]。这既是深度合作的体现，也是”客户需求驱动芯片设计”模式的风险注脚。

第二，推理+合成数据生成+强化学习的混合负载。 微软的 Superintelligence 团队（由 Mustafa Suleyman 领导）将使用 Maia 200 进行合成数据生成和强化学习，以训练下一代内部模型 [286]。这暗示 Maia 200 虽然定位为”推理芯片”，但其实际工作负载范围已扩展到 RL 中的 reward evaluation、采样和排序等推理-like 任务 [2588]。

第三，微软 vs OpenAI 的微妙关系。 微软在 2026 年初同时宣布了自研 MAI 模型（减少对 OpenAI 的依赖），以及 Maia 200 服务于 GPT-5.2 的部署 [2532]。这种”既合作又竞争”的关系，使得 Maia 系列成为微软在 AI 基础设施上的战略筹码——无论未来与 OpenAI 的关系如何演变，微软都拥有自主可控的推理底座。

第四，Anthropic 作为首个外部客户的可能性。 2026 年 5 月，CNBC 和 The Information 报道 Anthropic 正在与微软洽谈，成为 Maia 200 的首个外部客户 [2605]。截至 2026 年 6 月，Maia 200 尚未对 Azure 普通客户开放，Anthropic 的交易仍处于早期谈判阶段，尚未达成正式协议 [2605]。如果这笔交易落地，Claude 将成为首个在 Maia 200 上运行的前沿模型——这将是 Maia 从”内部工具”走向”对外云服务”的关键一步。

---

3.2.8. 软件生态：以 Triton 为桥梁、以 PyTorch 为入口

Maia 200 的软件栈是微软最具野心的布局之一。微软没有试图自创一个全新的 AI 框架生态（如 Google 的 JAX/XLA 之于 TPU），而是选择了嵌入现有开源生态的策略：

Maia SDK 的核心组件 [288]：

• PyTorch 集成：作为一级入口，开发者首先在 PyTorch 中编写模型代码。
• Triton 编译器：Maia 的 Triton compiler 是 Triton 语言的一个后端实现。Triton 最初由 OpenAI 开发，已经成为 PyTorch 2.x 中 TorchInductor 的默认 GPU kernel 生成器 [2572]。微软选择 Triton 而非自研编译器 DSL，意味着大量现有的 Triton kernel 可以相对容易地移植到 Maia 上。
• 优化 kernel 库：针对 Maia 的 Tile 和 Cluster 架构手工调优的高性能 kernel 集合，覆盖 LLM 推理中的常见算子。
• NPL (Nested Parallel Language)：Maia 的低级编程语言，允许开发者显式控制数据移动、SRAM 放置和并行执行，以达到接近峰值的硬件利用率 [287]。NPL 之于 Maia，类似于 CUDA 之于 NVIDIA GPU，或 PTA 之于 Groq LPU。
• Maia 模拟器与成本计算器：允许开发者在没有物理硬件的情况下进行早期性能评估和成本建模 [2583]。

这是一种”三明治”策略： 上层用 PyTorch 抓住最广泛的开发者群体；中层用 Triton 提供跨硬件的 kernel 可移植性；底层用 NPL 给极致性能优化留出后门。相比 Google TPU 的 XLA 编译器和 JAX 框架（需要较强的生态锁定），微软的策略更开放、更易于吸引已经在 PyTorch/NVIDIA 生态中的开发者。

但必须指出，软件生态的完整性不等于开发者体验的流畅性。 Maia SDK 在 2026 年 1 月仍处于 preview 阶段 [286]。对于已经深度依赖 CUDA、TensorRT-LLM、vLLM、SGLang 等成熟推理框架的用户来说，迁移到 Maia 意味着需要重新适配 serving stack、重新调试性能、重新建立运维流程。这不是”支不支持 PyTorch”的问题，而是 “PyTorch 下面的整个推理引擎是否无缝工作”的问题。

---

3.2.9. 对 NVIDIA 依赖度的影响：互补而非替代

Maia 200 对微软与 NVIDIA 关系的影响，需要放在一个更长的历史维度中理解。Maia 不是为了取代 NVIDIA GPU，而是为了在推理这一特定领域建立”第二供应源”。

微软的立场很明确：异构 AI 基础设施。 Maia 200 与 NVIDIA GPU 在 Azure 中并行部署，各司其职 [286]：

• NVIDIA GPU（H200/B200/GB200）：承担训练、高精度推理、需要超大显存的工作负载、以及面向外部客户的 GPU 云实例。
• Maia 200：承担大规模生产级推理——Copilot 的 token 生成、GPT-5.2 的 API 服务、Foundry 的模型推理流水线。这些工作负载具有高度可预测性、海量规模、对成本极度敏感的特征。

微软在 2026 年 3 月的 NVIDIA GTC 上仍然高调宣布与 NVIDIA 的深度合作，包括将下一代 NVIDIA 系统引入 Azure 数据中心 [2566]。这并非虚伪——微软每年数十亿美元的 GPU 采购不会因为 Maia 200 而停止，尤其是在推理需求以指数级增长、而 Maia 产能爬坡仍需要时间的背景下 [305]。

但 Maia 200 确实改变了博弈的格局。它让微软从”价格的接受者”变成”价格的制定者”——即便 Maia 只为微软节省了 30% 的推理成本，这笔节省在每年数百亿美元的 AI 基础设施支出中也意味着数十亿美元的真金白银。更重要的是，Maia 给了微软在与 NVIDIA 的采购谈判中更多的筹码：如果 GPU 价格太高，微软可以将更多推理负载迁移到 Maia 上。

一个值得关注的信号： 微软在 2026 年 Q3 的资本支出计划高达 1900 亿美元（含数据中心、服务器、网络等）[321]。分析机构指出，Maia 200 的产能爬坡将最终决定微软能否在 2026-2028 年间结构性降低对商用 GPU 的依赖 [321]。这不是一个技术问题，而是一个产能经济学问题。

---

3.2.10. 小结：Maia 200 的定位与局限

Maia 200 代表了 hyperscaler 自研 AI 芯片的最高水准之一。它不追求绝对性能的领先，而是追求在特定工作负载（LLM 推理）上的最优 TCO。其核心优势包括：

• 与 Azure 和 OpenAI 工作负载的深度垂直整合
• 原生 FP4/FP8 精度带来的推理效率优势
• 基于标准以太网的互联方案降低了集群部署成本
• 从芯片到机柜到液冷的一体化系统设计
• Triton + PyTorch 的开放软件策略降低了生态迁移门槛

其核心局限同样清晰：

• 纯推理芯片，无法兼顾训练，限制了其在 Azure 内部的适用场景
• 对非 Transformer 架构、非 LLM 工作负载的适配性未知
• 软件生态仍处于 early preview 阶段，与 CUDA 生态的成熟度差距巨大
• 未对 Azure 普通客户开放，外部生态建设几乎为零
• 对 OpenAI 单一客户的工作负载依赖度较高

Maia 200 的故事本质上是一个关于”自制还是外购”的经典战略命题。在 AI 推理这个特定领域，微软的答案是：当规模足够大、工作负载足够确定时，自制永远比外购便宜。 而 Maia 200 就是这个答案的物理载体。

3.3. Meta MTIA：从广告印钞机到生成式推理的”成本最优解”

在云厂商自研 ASIC 的版图中，Meta 的 MTIA 是一条最特立独行的路径：它不卖芯片，不租芯片，甚至不对外提供服务。MTIA 存在的唯一理由，就是让 Meta 自家每天数万亿次的推理请求——从信息流排序、广告匹配到 Llama 系列生成式模型——跑得比 GPU 更便宜。这是一种极度务实的工程哲学：既然我有全球最明确的推理负载画像，为什么要用一块为通用训练而设计的 GPU 来做推理？

3.3.1. 演进路线：从推荐推理到 GenAI 的”三级跳”

MTIA 的演进史是一部”按需进化”的教科书。2020 年，Meta 启动 MTIA 项目，第一代芯片（后更名为 MTIA100）直指核心痛点：GPU 跑深度推荐模型推理既不经济也不高效[352]。MTIA v1 采用 TSMC 7nm 工艺，800MHz 频率，提供 102.4 TOPS INT8 / 51.2 TFLOPS FP16 算力，TDP 仅 25W，搭配 128GB LPDDR5——这些参数放在今天看似平淡，却标志着 Meta 开始认真审视”为什么我的推理负载要绑在别人的架构上”[2767]。

第二代 MTIA200（原名 MTIA2i）是一次质的飞跃。TSMC 5nm 工艺，主频提升 68.8% 至 1.35GHz，芯片面积扩大至 421mm²[367]。核心架构是一个 8×8 共 64 个 Processing Element（PE）组成的网格，每个 PE 内含两个 RISC-V 核心（一个标量、一个带向量扩展）、Dot Product Engine（DPE）、Special Function Unit（SFU）、Reduction Engine 和 DMA 引擎[364]。片上 SRAM 翻倍至 256MB，带宽 2.7 TB/s；本地 PE 存储增至 384KB；128GB LPDDR5 提供 205 GB/s 带宽[364]。整卡 TDP 仅 90W——对比同时期 350-700W 的 GPU 加速卡，能效比优势一目了然[2796]。在 ISCA 2025 论文中，Meta 披露 MTIA200 在已部署的生产模型上实现了平均 44% 的 TCO 降低（对比 GPU）[375]。

真正的转折发生在 2026 年 3 月。Meta 一口气公布四代 MTIA 芯片路线图——MTIA300、400、450、500——以约 6 个月一代的节奏推进，全部面向推理优化[348]。

MTIA300：首个 chiplet 设计，一片 compute chiplet + 两片 network chiplet + 若干 HBM 栈，标志着 MTIA 从 LPDDR5 向 HBM 的历史性跨越。已部署用于排名与推荐（R&R）训练[373]。

MTIA400：首次正式支持 GenAI 推理，同时保持 R&R 能力。单芯片算力较 MTIA300 提升 5 倍以上，scale-up 域从 16 节点跃升至 72 节点[358]。MX4 精度下达到 12 PFLOPs，HBM 带宽 9.2 TB/s[2679]。

MTIA450：HBM 带宽翻倍至 18.4 TB/s，Meta 明确宣称”远超现有领先商用产品”（暗指 NVIDIA H100/H200）[373]。引入低精度数据类型（包括 Meta 自研定制格式），专为 GenAI 推理优化。计划 2027 年初大规模部署[348]。

MTIA500：HBM 带宽再增 50% 至 27.6 TB/s，HBM 容量最高达 512GB/加速器。采用 2×2 compute chiplet 配置，周围环绕多组 HBM 栈和 network chiplet，外加 SoC chiplet 提供 PCIe 连接。30 PFLOPs MX4 和 5 PFLOPs BF16 性能[348]。

值得注意的是，MTIA 的命名体系在 2026 年经历了重新梳理：MTIA v1 → MTIA100，MTIA v2/MTIA2i → MTIA200，后续依次为 300/400/450/500。这一变化本身就是一个信号——MTIA 已从探索性项目蜕变为按代际规划的正式产品线[348]。

3.3.2. 架构特征：RISC-V 网格 + 大 SRAM + 渐进式 HBM

3.3.2.1. 计算单元：PE 网格的”联邦制”设计

MTIA 的核心计算范式是PE 网格（Grid of Processing Elements）。每个 PE 是一个相对自洽的计算单元，内含：两个 RISC-V 处理器核心（一个带向量扩展），负责控制流与非规则计算；Dot Product Engine（DPE），专用于矩阵乘法的固定功能加速器；Special Function Unit（SFU），处理激活函数与逐元素操作；Reduction Engine，负责累加与跨 PE 通信；DMA Engine，管理本地数据搬运；以及本地 SRAM（MTIA200 规格为 384KB）[2672]。

这种设计在哲学上接近”分布式计算单元联邦”——每个 PE 都有自己的控制核心和本地存储，PE 之间通过片上 NoC（Network-on-Chip）通信。MTIA200 的 NoC 带宽较 MTIA100 提升 3.3 倍，确保 64 个 PE 间的数据流动不会饿死计算单元[350]。它不是 GPU 的 SIMT 模型（一个指令流驱动数千线程），也不是 TPU 的集中式脉动阵列，而更像是一个可编程的、带有专用加速器附件的 RISC-V 多核集群[357]。

这种架构特别适合推荐模型的稀疏特征查找和 Embedding 操作——PE 的 RISC-V 核心可以直接处理不规则访存，DPE 加速矩阵运算，两者之间的切换由硬件调度而非软件 kernel 切换完成。Meta 特别强调了 Table Branch Embedding（TBE） 硬件加速，可将 runtime 提升 2-3 倍[368]（笔者注：此数据来自 ISCA 论文摘要，正式版本可能有微调）。

3.3.2.2. 存储层级：从”SRAM+LPDDR”到”HBM 激进扩展”的范式迁移

MTIA 的存储设计有一条贯穿始终的逻辑：大 SRAM 是必须的，SRAM-only 是不现实的。

MTIA100/200 坚持使用 LPDDR5 而非 HBM，理由非常明确：推荐推理模型对延迟敏感，但对绝对带宽的需求不如 LLM 高，LPDDR5 在成本和功耗上具有压倒性优势[2665]。MTIA200 的 256MB 片上 SRAM（2.7 TB/s 带宽）在同等功耗芯片中堪称”奢侈”——Embedding 表、MLP 权重、激活值全部驻留在 SRAM 中，避免片外 DRAM 的不可预测延迟[2665]。

但 GenAI 推理的出现彻底改变了这一逻辑。LLM decode 阶段是典型的 memory-bound 负载——HBM 带宽直接决定 token 生成速率。Meta 毫不犹豫地转向了 HBM，而且是以远超商用 GPU 的带宽作为目标。MTIA 副总裁 Yee Jiun Song 公开表示：“我们看到推理需求正在爆炸式增长，这是我们当前的关注焦点”[2742]。

从 MTIA400 到 MTIA500，HBM 带宽在约 18 个月内从 9.2 TB/s 飙升至 27.6 TB/s——增长了 3 倍[363]。这一增速比 JEDEC HBM 标准的代际提升节奏更快。Meta 如何实现？答案藏在 chiplet 架构中：MTIA500 的 2×2 compute chiplet 配置允许同时连接更多 HBM 栈，从而在不依赖单栈带宽提升的前提下实现总带宽线性扩展。

对于 LLM 推理中的 KV Cache 问题，MTIA 的应对策略仍不明朗。Meta 尚未公开 MTIA 如何处理长上下文 KV Cache——是全部留在 HBM 中、部分缓存到 SRAM、还是通过 PCIe 扩展或远端 RDMA 内存做容量外溢？考虑到 MTIA 的部署场景（Meta 内部自有负载），这很可能是一个”按需裁剪”的问题：Meta 精确知道自己的模型上下文长度，可以据此配置每芯片的 KV Cache 容量，无需像商用芯片那样为”理论上可能的 100 万 token 上下文”做过度的工程预留。

3.3.2.3. 互联架构：HCCL + Ethernet 的”去 NVLink 化”

MTIA 的通信栈围绕 Hoot Collective Communications Library（HCCL） 构建，功能上对标 NVIDIA 的 NCCL，但做了几项关键差异化[348]：

• 硬件卸载：利用 MTIA 芯片内置的 network chiplet 实现集合通信的硬件加速，减少 compute PE 的通信开销[2798]
• 近存计算归约：在内存控制器附近执行 reduction 操作，避免数据反复穿越计算单元[2672]
• 计算-通信融合：HCCL 可以将集合通信操作与相邻计算 kernel 融合，以计算掩盖通信延迟[350]
• 用户态传输层：Rust 实现的用户态驱动，避免内核态 syscall 开销，实现亚微秒级 job launch 延迟[350]

在系统级互联上，MTIA 选择的是 Ethernet 路线而非 NVLink 式的专有 fabric。2026 年 4 月 Meta 与 Broadcom 签署的扩展合作协议中，Broadcom 提供的正是”高基数 Ethernet 交换机、光互联产品、PCIe 交换机”——一个完全基于标准 Ethernet 的 rack-scale 互联方案[2717]。这种选择符合 Meta 作为 OCP 发起者的基因：宁可牺牲一点极致性能，也要确保供应链多样性和成本可控。

MTIA400 的 72 芯片 scale-up 域（对比 MTIA300 的 16 芯片）是一个值得关注的数字[358]。72 芯片的 all-reduce 通信效率直接决定了 tensor parallelism 的可行性和效率。Meta 在这一点上展示了”内部客户”的独特优势：他们不需要保证任意 72 芯片拓扑都能高效通信，只需要保证 Meta 数据中心内部的标准机柜配置能跑通即可。

3.3.3. 软件栈：PyTorch 原生的”零迁移”叙事

MTIA 在软件生态上的策略可以用一句话概括：不做 CUDA 的敌人，做 PyTorch 的朋友。

Meta 从一开始就将 MTIA 软件栈构建在 PyTorch 2.x 生态之上，而非另起炉灶。具体而言：

• PyTorch 原生：支持 torch.compile 和 torch.export，模型代码无需 MTIA 专用修改即可在 GPU 和 MTIA 之间切换[373]
• Triton 编译器：使用 Triton 作为 kernel 生成基础设施，通过 MLIR 和 LLVM 将算子编译到 MTIA 硬件[348]
• vLLM 集成：提供 vLLM 插件，支持 FlashAttention 优化 kernel、LayerNorm 加速和 prefill-decode 分离，与 NVIDIA 硬件上的 vLLM 0.17.0 性能特性对齐[2687]
• Eager Mode 硬件加速：MTIA 硬件支持 PyTorch eager mode 的亚微秒级 job launch，这对交互式推理和实时模型更新至关重要[2665]
• HCCL 通信库：对标 NCCL，支持 all-reduce、all-gather、reduce-scatter 等集合通信[350]

此外，Meta 还开发了 KNYFE——一种 DSL（领域特定语言），让开发者用高层描述定义 ML 算子，自动生成优化后的低级 C++ kernel 代码[352]。对于需要极致性能的算子，仍可使用 C/C++ 手工编写。

这种”融入而非替代”的软件策略，精准地利用了 Meta 作为 PyTorch 维护者的独特地位。当 PyTorch 2.x 的 torch.compile 和 Triton 后端逐渐成为行业标准时，MTIA 可以天然享受生态红利——开发者不需要为 MTIA 学习新框架，只需要确保模型在 PyTorch 生态内即可。这与 Groq、Cerebras、SambaNova 等需要开发者适配专用编译器的路线形成了鲜明对比[356]。

但”零迁移”叙事也有其边界。MTIA 的算力、内存带宽、互联拓扑与 GPU 仍有本质差异，torch.compile 的自动优化在 MTIA 上能达到 GPU 同等”效率占比”的程度仍需时间验证。更关键的是，MTIA 不需要证明它对所有模型都高效——它只需要对自己跑的模型高效即可。这是一个独立 ASIC 厂商永远无法享有的奢侈。

3.3.4. 内部工作负载适配性：推荐 > 广告 > GenAI 的优先级排序

MTIA 的负载适配策略遵循一个清晰的优先级：推荐系统（R&R）→ 广告系统 → 生成式 AI。这不是技术偏好，而是财务逻辑的必然结果。

Meta 每年超过 1500 亿美元广告收入的核心引擎，就是推荐模型推理[354]。Facebook 从 2011 年引入算法信息流开始，ML 驱动的内容排序和广告匹配就一直是业务的命脉。当你的核心变现系统每天运行数万亿次推理，每次推理的延迟和成本微小优化，乘以这个基数就是数十亿美元的利润差异。

MTIA 的架构设计处处体现这种”推荐优先”的基因：

• 大 SRAM：推荐模型的 Embedding 表查找对延迟极度敏感，SRAM 提供了 GPU HBM 无法比拟的确定性延迟
• RISC-V 控制核心：推荐模型包含大量不规则操作（如特征哈希、Embedding Bag、稀疏查找），通用控制核心比固定功能加速器更灵活
• LPDDR5 优先（早期）：推荐推理的 batch size 通常较小，不需要 HBM 级别的带宽，LPDDR5 在成本/功耗上远优于 HBM[2665]
• TBE 硬件加速：Table Branch Embedding 是推荐模型的核心算子，专用硬件加速直接降低延迟

当 MTIA 从推荐转向 GenAI 推理时，架构面临一次”范式转换”：LLM 推理的 decode 阶段是 memory-bound 的，HBM 带宽成为绝对瓶颈；prefill 阶段是 compute-bound 的，需要大量矩阵乘法算力。这就是为什么 MTIA400→450→500 的演进中，HBM 带宽成为最核心的升级维度——从 9.2 TB/s 到 18.4 TB/s 再到 27.6 TB/s[348]。

不过，Meta 对 GenAI 推理的支持仍处于”追赶”阶段。MTIA450 和 500 被明确描述为”优先针对 GenAI 推理优化，再支持其他负载”[354]。MTIA 副总裁 Song 的原话是：“主流 GPU 通常为最苛刻的负载——大规模 GenAI 预训练——构建，然后被低效地应用于推理等工作负载。我们采取相反的路线：MTIA450 和 500 优先为 GenAI 推理优化，然后可以按需支持排名和推荐训练与推理，以及 GenAI 训练”[356]。

但推荐系统的根基地位从未动摇。MTIA300 已部署用于 R&R 训练，MTIA400 虽然支持 GenAI 推理，但同样”保持 R&R 能力”[373]。Meta 的整个 MTIA 路线图都显示：推荐是印钞机，GenAI 是未来的增长引擎，二者都不能丢。

3.3.5. 外销可能性：几乎为零，但影响深远

MTIA 的商业化路径问题，答案异常简单：不卖，不租，不开放。

Meta 是四大美国超大规模云厂商中唯一没有公有云业务的[2790]。MTIA 芯片仅部署在 Meta 自有数据中心，服务于 Facebook、Instagram、WhatsApp、Threads 等平台的内部推理负载[2658]。正如分析师所指出的：“Meta 只在内部使用它们；没有云业务”[354]。

但这并不意味着 MTIA 对产业没有影响。恰恰相反，MTIA 的”纯内部”模式可能是最具破坏力的：

• GPU 需求置换：每一瓦 MTIA 部署容量，都是对 NVIDIA GPU 采购的直接替代。据估算，每一 GW 的 MTIA 容量都是对 NVIDIA 支出的直接削减[2791]。到 2027 年 MTIA 的部署规模可能达到 multi-GW 级别，对应的 GPU 采购金额可达数百亿美元。
• 供应链信号：当 Meta 公开宣称 HBM 带宽是”影响 GenAI 推理性能的最重要因素”时，这向 HBM 供应商（SK Hynix、Samsung）传递了强烈的需求信号，间接影响整个产业的 HBM 定价和产能分配[348]。Song 在 CNBC 采访中坦承”绝对担心 HBM 供应”，但相信已锁定足够产能支持部署计划[2756]。
• 开源生态红利：MTIA 对 PyTorch、Triton、vLLM 的深度集成，推动了这些开源项目对非 NVIDIA 硬件的支持成熟度。当 vLLM 可以通过 Triton backend 在 NVIDIA/AMD/Intel GPU 上运行同一套代码时，MTIA 的兼容性积累也在降低其他 ASIC 厂商的软件迁移成本[2686]。
• 验证”推理优先”路线：MTIA 证明了一个关键命题——为推理优化的芯片，在推理负载上可以比”训练优先”的 GPU 实现显著的 TCO 优势。这一验证为整个 ASIC 推理赛道提供了商业逻辑背书。

此外，MTIA 的 chiplet 架构和 6 个月迭代节奏本身就是一种产业示范。通过将 compute chiplet、network chiplet、HBM 栈分离设计，Meta 可以在不影响整体架构的前提下独立升级每个组件——这比传统 monolithic SoC 的 18-24 个月迭代周期快了 3-4 倍[356]。

3.3.6. 团队与生态位：Rivos 收购与 Broadcom 同盟

MTIA 的团队建设路径揭示了 Meta 在芯片领域的战略深度：

内部团队：由 VP of Engineering Yee Jiun Song 领导，他拥有 Cornell University 计算机科学博士学位，此前曾在 Instabase 担任 SVP of Engineering[2745]。Song 于 2023 年 9 月接管 MTIA 项目，接替离职的 Alexis Black Bjorlin，负责 Meta 的基础设施架构组织，涵盖 AI、计算、存储硬件平台、定制芯片、供应链运营和全球数据中心管理[2755]。

Rivos 收购：2025 年 9 月，Meta 以约 20 亿美元收购了 RISC-V AI 芯片初创公司 Rivos[2697]+Expands+AI+Chip+Ambitions+With+$2+Billion+Rivos+Acquisition)。Rivos 此前已在协助 Meta 设计 MTIA 芯片，收购后团队直接融入 MTIA 项目，带来”全栈 AI 系统”的深厚经验[354]。Song 表示：“鉴于我们前两代 AI 加速器的成功，我们渴望加速和扩展 MTIA 路线图。Rivos 拥有设计和开发全栈 AI 系统的深厚技术专长和经验”[2693]。

据报道，Meta CEO Mark Zuckerberg 对内部芯片开发进度不太满意，因此推动了这次收购以”带来增援”[2692]。Rivos 还正在开发自己的 GPU，这使其成为 Meta 的特别战略性收购——Meta 一方面通过 MTIA 建立自研能力，另一方面每年仍花费数十亿美元购买外部 GPU[2704]。

Broadcom 合作：2026 年 4 月，Meta 与 Broadcom 签署扩展合作协议，共同开发多代 MTIA 芯片直至 2029 年。合作范围涵盖芯片设计、先进封装和 Ethernet 网络。初始部署规模超过 1GW，远期目标为 multi-GW 级别[2718]。Zuckerberg 亲自表态：“Meta 正在与 Broadcom 在芯片设计、封装和网络方面合作，以构建我们为数十亿人提供个人超级智能所需的庞大计算基础”[2719]。

Broadcom 为 MTIA 提供的不仅是设计服务，还包括其 XPU 平台——一个定制 AI 加速器框架——以及高基数 Ethernet 交换机、光互联产品、PCIe 交换机和高速 SerDes[2724]。这一”内部团队 + 收购人才 + 半导体巨头同盟”的三角架构，使 MTIA 在工程执行力和供应链安全上都获得了强有力的支撑。

但 Broadcom 同时为 Google（TPU）、Meta（MTIA）和可能的 OpenAI 提供定制 ASIC 服务，这形成了”竞争者共享供应商”的微妙格局。Broadcom 的 XPU 平台在不同客户之间可能存在技术复用，但具体细节受保密协议约束。

3.3.7. MTIA 的独特定位：云厂商自研 ASIC 的”第三条道路”

将 MTIA 放在云厂商自研 ASIC 的坐标系中，其定位格外清晰。以下是与其他云厂商自研芯片的简要对比：

维度	Google TPU	Amazon Trainium/Inferentia	Microsoft Maia	Meta MTIA
对外销售	云租赁（TPU Pod）	云租赁	云租赁（Azure）	不对外
主要负载	训练+推理	训练+推理	推理	推理优先
软件生态	JAX/TF/XLA	PyTorch/Neuron	PyTorch/Maia SDK	PyTorch/Triton/vLLM
公开程度	中等	中等	较低	较高（ISCA 论文）

MTIA 的”不对外”模式看似封闭，实则赋予了它其他云厂商 ASIC 无法企及的工程自由度。没有客户兼容性包袱，没有 SLA 承诺，没有”用户可能跑什么奇怪模型”的焦虑——MTIA 团队可以基于 Meta 内部确切的模型架构、batch size 分布、延迟 SLO 和功耗预算，做最极致的 co-design。这种”为已知负载精雕细琢”的能力，恰恰是通用 ASIC 厂商最大的软肋。

Meta 能够实现 6 个月一代的迭代速度，正是因为采用了模块化、可复用的 chiplet 设计，而且只有一个客户（自己），省去了商业芯片公司需要耗费数年的兼容性测试和生态支持工作[358]。

但硬币的另一面是：MTIA 的技术成果几乎不会直接转化为可销售的产品。当 Groq、Cerebras、SambaNova 在市场上争夺”GPU 替代”叙事时，MTIA 的工程经验只能沉淀在 Meta 内部——它降低的是 Meta 的推理成本，而非整个行业的推理成本。从这个意义上说，MTIA 是 Meta 的”成本武器”而非”行业解决方案”[356]。

这也解释了为什么 Meta 愿意在 ISCA 等顶级学术会议上公开 MTIA 的架构细节：学术影响力有助于吸引顶尖芯片人才加入 Meta，而公开的架构信息对竞争对手而言只是”参考”而非”威胁”——毕竟，没有 Meta 的推荐模型和数据，你复制不了 MTIA 的 co-design 效果。

3.3.8. 小结：MTIA 到底改变了什么？

MTIA 的价值主张可以浓缩为三点：

第一，证明了”推理专用芯片”的经济学。 当一块为训练优化的 GPU 有大量晶体管和功耗花在你推理时用不到的功能上（FP64、MIG 分区等），专门为推理负载定制芯片的 TCO 优势几乎是必然的。MTIA 的 44% TCO 降低数据只是起点，随着 MTIA450/500 的 HBM 带宽大幅超越商用 GPU，这一优势可能进一步扩大[375]。

第二，展示了”内部客户”模式的工程优势。 6 个月一代的迭代速度在商用芯片领域是不可想象的——没有客户验证周期、没有兼容性矩阵测试、没有市场营销窗口。Meta 需要的只是芯片能跑自己的模型，这种”闭环开发”的效率是独立 ASIC 公司永远无法企及的。

第三，揭示了 LLM 推理的”成本中心”迁移。 从 MTIA100 到 MTIA500，HBM 带宽从 205 GB/s（LPDDR5）跃升至 27.6 TB/s——增长了 135 倍。这一轨迹清晰地表明：在 LLM 推理中，存储带宽比计算密度更重要。Meta 工程副总裁 Song 的表态——“HBM 带宽是影响 GenAI 推理性能的最重要因素”——为这一产业共识提供了最权威的注脚[348]。

但 MTIA 也有其根本性的局限。它不适用于非 Meta 的负载，不适用于模型架构的快速实验，不适用于需要极致灵活性的研究场景。它是一个”为已知世界优化”的工具，而非”探索未知世界”的平台。当 LLM 架构从 Dense Transformer 走向 MoE、Mamba、原生多模态甚至更不可预测的新范式时，MTIA 的”定制化优势”可能变成”定制化锁定”——这是所有 workload-specific ASIC 都需要面对的终极拷问。

不过，对 Meta 而言，只要推荐系统还是印钞机，只要 Llama 系列还在持续扩大用户基数，MTIA 就永远有它不可替代的 TCO 价值。正如一位分析师精辟总结的：“MTIA 路线图的驱动力是负载，从最清晰 ROI 的推荐系统开始，逐步扩展到 GenAI”[354]。Meta 的算力需求是刚性的，而 MTIA 是满足这一需求最具成本效益的答案——这就足够了。

3.4. OpenAI / Broadcom “Titan”：自研推理 ASIC 的系统级豪赌

在所有互联网与云厂商自研 ASIC 的叙事中，OpenAI 的“Titan”项目是最特殊、也最值得深究的一个。它既不是 Google 那样长达十年的“芯片-编译器-网络”三位一体演进，也不是 Meta 将自研芯片深埋推荐系统管线的低调务实，而是一个模型公司直接跳进芯片深水区，试图用 10 GW 的算力规模在一夜之间改写推理基础设施的竞争规则。这个项目的信息密度极高，谣言与事实交织，需要我们以“手术刀”级的精度进行事实核验、动机剖析与架构推演。

3.4.1. 事实核验：合作已经板上钉钉，但“芯片”仅是冰山一角

2025 年 10 月 13 日，OpenAI 与 Broadcom 联合发布官方声明，宣布一项“战略合作”，核心内容如下 [492]：

• 合作范围：OpenAI 负责加速器与系统设计，Broadcom 负责开发与部署，双方共同交付包含 AI 加速器与 Broadcom 以太网方案的完整机架系统。
• 规模：10 吉瓦（GW）的定制 AI 加速器，从 2026 年下半年开始部署，2029 年底前完成全部部署 [482]。
• 工艺节点：将采用 3 nm 和 2 nm 设计，首款芯片目标 2026 年下半年量产，大概率基于 TSMC N3 工艺 [482]。
• 商业性质：这是 Broadcom 历史上最大的一笔定制 ASIC 系统订单，多家分析师估算合同价值约 100 亿美元，Broadcom 将其定义为“完整系统”而非仅芯片 [474]。

需要特别澄清的是，“Titan”这一名称并非出自 OpenAI 官方公告，而是多家媒体在报道中使用的代号 [472]。OpenAI 官方材料中仅使用“OpenAI-designed AI accelerators”或“XPU”的描述。因此，“Titan”是一个合理且已被广泛接受的行业代称，但并非官方正式产品名。

另外，有报道提及 OpenAI 与三星就 HBM4 供应的接触 [472]，这暗示 Titan 极有可能采用 HBM4 作为存储方案，但截至目前尚未有正式签约消息。三星 HBM4 的量产时间与 Titan 的 2026 年下半年部署窗口存在时间对齐的可能性，但也可能选择 SK hynix 或美光，需持续观察。

3.4.2. 战略动机：不是“降本”这么简单，而是一场生存博弈

OpenAI 自研 ASIC 的动机，远不止“降低推理成本”或“摆脱对 NVIDIA 的依赖”这种表面叙事。从系统层面看，这是一场由物理极限、经济模型与战略控制权三重压力共同驱动的豪赌。

1. 推理 token 经济学的根本性倒逼

OpenAI 的 GPT-o 系列模型（以及未来的 GPT-5/6）推理成本惊人。在 2024–2025 年，OpenAI 的 API 价格经历了多轮下降，但每一次降价都是靠更高效的推理硬件和软件优化实现的。然而，NVIDIA GPU 的硬件成本下降速度（摩尔定律 + 工艺进步）已经跟不上 token 生成量指数级增长的曲线。当你的模型每轮对话生成数千 token，用户数却以亿计，且推理成本占整体算力成本的 60%–70% 时，任何 20% 的硬件效率提升都无法通过购买通用 GPU 来实现——你必须去从芯片 architecture 层面榨取 token 生成效率的阶梯式跃升。自研 ASIC 是唯一能让 token 边际成本跌破“通用 GPU 地板”的路径。

2. 摆脱“算力乞丐”角色，掌握硬件-模型协同优化的垂直控制权

OpenAI 长期依赖 NVIDIA GPU 供应，在 H100/B200 的抢购潮中处于被动地位。即便与微软 Azure 有深度绑定，Azure 的 GPU 供应同样受制于 NVIDIA 的产能分配。更关键的是，NVIDIA 的 GPU 架构更新节奏（约 2 年一代）与 OpenAI 的模型迭代节奏（GPT-4→GPT-4o→o1→o3 快速演进）并不完全同步。自研 ASIC 意味着 OpenAI 可以在芯片定义阶段就嵌入对自家模型推理特性的深度优化——比如 MoE 的 sparse expert activation、特定 attention 模式的硬件加速、KV cache 的定制化存储层级等。这是“硬件-模型协同优化”的最高形态，类似于苹果的 A 系列芯片与 iOS 的垂直整合，但用于 AI 推理。

3. 数据中心基础设施的“主权化”

10 GW 是什么概念？这大约相当于 10 个大型核电站的发电功率，或者 2024 年全球数据中心总耗电量的约 2%–3%。OpenAI 不仅要芯片，还要机架、网络、液冷、电力供应——这本质上是一个 “AI 算力主权”的宣告。OpenAI 正在从“模型公司”转变为“AI 基础设施公司”，自研芯片是这一转型的核心支点。与 Broadcom 的合作，让 OpenAI 可以绕开部分云厂商的中间环节，直接部署自己的定制化推理集群，这对保障下一代超大模型的服务质量至关重要。

4. 与 Azure 的关系：互补与博弈并存

OpenAI 的推理服务仍大量运行在 Azure 上，而 Azure 也在推进自家的 Maia 200 推理芯片。OpenAI 自研 Titan 并非要取代 Azure，而是为了构建一个异构算力池：NVIDIA GPU 提供最灵活的通用推理、AMD GPU 提供性价比选项、Maia 200 提供 Azure 原生推理、Titan 提供 OpenAI 专用超大规模推理。这种“不把所有鸡蛋放在一个篮子里”的策略，既是对 NVIDIA 依赖的削弱，也是对 Azure 依赖的某种平衡——OpenAI 需要确保自己有独立于任何单一云厂商的底层算力自主权。

3.4.3. 架构方向推演：推理专用、高带宽存储、Chiplet 与 Ethernet 系统级协同

基于公开信息与合理推演，Titan 的架构方向可以从以下几个维度勾勒：

1. 推理为主，训练为辅，首代大概率是纯推理芯片

OpenAI 当前最紧迫的痛点是推理成本与 token 生成吞吐，而非训练（训练可以通过与微软、Oracle 等合作使用 NVIDIA/AMD 集群解决）。因此，Titan 的首代产品几乎可以断定是推理专用 ASIC。它可能会在 Decode 阶段做极致的 memory-bound 优化，比如超大容量 HBM、定制化的 KV cache 管理器、针对 MoE 的 sparse expert 激活硬件等。至于训练，可能要等到第二代或第三代 Titan 才会覆盖，届时或出现类似 Google TPU “训练-推理分治”的路线。

2. HBM4 是必然选择，容量与带宽将远超同期 GPU

三星 HBM4 的报道并非空穴来风。HBM4 的理论带宽可达 1.5–2 TB/s/stack，如果 Titan 搭载 8–12 个 HBM4 stack，总带宽将逼近 20 TB/s，容量可达 256–384 GB。这对推理至关重要：一个 1T 参数的 MoE 模型，每个 expert 的权重约 100 GB，若能在单芯片或多芯片近距离互联中驻留全部 expert 权重，Decode 阶段的 token 生成延迟将大幅降低。此外，HBM4 的功耗效率比 HBM3e 更高，有助于在 10 GW 的总功耗约束下提升算力密度。

3. Chiplet 设计是 Broadcom 的拿手好戏

Broadcom 的定制 ASIC 业务（已为 Google TPU、Meta MTIA、Microsoft Maia 服务）高度依赖 Chiplet 技术。Titan 极有可能采用 “计算 die + 网络 die + 存储 interposer”的 Chiplet 方案，通过 CoWoS 或类似封装将多个计算 tile 与 HBM 集成。计算 die 可能包含高度优化的矩阵乘法引擎（类似脉动阵列或数据流架构），以及专用的 attention 加速单元；网络 die 则集成 Broadcom 的彼时最新以太网 PHY 或自研的 scale-up 互联。这种架构有利于灵活调整算力配置，并降低单 die 的良率风险。

4. 网络：Broadcom 以太网方案是系统级的关键支柱

官方声明中明确提到“包括 Broadcom 的以太网解决方案” [492]。这意味着 Titan 的 scale-up 和 scale-out 互联将基于以太网，而非 NVIDIA 的 NVLink 或 Google 的 ICI 私有协议。Broadcom 的 Tomahawk/Trident 系列交换机芯片在超大规模数据中心中拥有统治地位，Titan 的 system-level 设计很可能是每个机架内置一个 Broadcom 自制或合作伙伴的以太网交换机，通过 RoCEv2 或更贴合的协议实现芯片间的高带宽通信。对于推理的 Decode 阶段，scale-up 的带宽需求（all-reduce 在 Tensor Parallelism 中）是刚性的，以太网能否在延迟和带宽上媲美 NVLink 还需要观察，但 Broadcom 的 800G/1.6T 以太网技术在 2026 年时已相当成熟，配合适当的拥塞控制和拓扑设计，可以支撑 64–128 芯片的推理集群。

5. 与 Azure 数据中心的协同：可能是一个“逻辑一体化”的异构集群

OpenAI 的 Titan 集群大概率会部署在微软新建的、专为 OpenAI 设计的 Azure 数据中心（或 Stargate 超级计算机项目的一部分）。这些数据中心将原生支持液冷、高密度机架供电，并配备 Azure 的软件定义网络。Titan 的推理任务可能会通过 Azure 的统一调度器与 Maia 200、NVIDIA GPU 进行协同，形成 disaggregated inference 池：Titan 负责 OpenAI 自有模型的规模化 Decode，Maia 200 服务通用 Azure 客户，NVIDIA GPU 则处理 Prefill 或复杂的长上下文任务。这种“异构 disaggregated”架构是未来超大规模推理的必然方向，而 OpenAI 与微软的深度绑定恰好为此提供了土壤。

3.4.4. 事实与推测的明确边界

在分析 Titan 时，我们必须严格区分已确认的事实、合理推测与未经证实的传闻。下表提供了一个清晰的对照：

类别	内容	可信度	来源/依据
事实	OpenAI 与 Broadcom 合作，2026 年下半年开始部署 10 GW 定制 AI 加速器系统	高	官方联合声明 [492]
事实	OpenAI 负责芯片和系统设计，Broadcom 负责开发与部署，系统包含以太网方案	高	官方声明 [492]
事实	芯片将采用 3 nm 和 2 nm 工艺，首批 2026 年下半年量产	高	Broadcom 财报电话会及 Tom’s Hardware 报道 [482]
事实	合同价值约 100 亿美元，Broadcom 定义为完整系统而非仅芯片	高	分析师报告及 Broadcom 高管表述 [474]
合理推测	首代芯片为推理专用，面向 Decode 阶段优化	中	OpenAI 的推理成本压力与行业惯例，无官方确认
合理推测	采用 HBM4（可能来自三星），单芯片带宽超 15 TB/s	中	三星 HBM4 接触报道 + 推理带宽需求推导 [472]
合理推测	Chiplet 设计，基于 CoWoS 封装，多 die 集成	中	Broadcom 定制 ASIC 的常规技术路线，OpenAI 在招聘中提及 Chiplet
合理推测	软件栈可能基于 OpenAI Triton 或自研编译器，与 PyTorch 生态兼容	低	尚无公开信息，仅基于 OpenAI 技术积累推断
传闻	芯片代号“Titan”或“Nexus”	未确认	媒体报道 [485]，非官方命名
传闻	与三星 HBM4 供应协议已签署	未确认	单一来源报道，无后续跟进 [472]

3.4.5. 挑战与风险：软件生态、团队能力与供应链三角

OpenAI 自研芯片最大的挑战并非硬件设计——Broadcom 在这方面拥有全球最顶尖的 ASIC 工程能力——而是软件生态与开发者体验。NVIDIA 的 CUDA 护城河不是一天挖成的，即便 OpenAI 可以开发自己的编译器、kernel library 和 serving stack，要让外部开发者（如果有朝一日开放）无缝迁移，或者让内部团队在芯片流片前就完成完整的模型移植，仍存在巨大风险。不过，OpenAI 拥有一个其他芯片初创公司难以企及的优势：它不需要对外销售芯片，只需为自己的模型优化。这大大降低了软件生态的复杂度——只要编译器能跑通自家模型，serving 性能达标，便算成功。

另一个风险是团队能力。OpenAI 此前并无芯片设计经验，尽管它从 NVIDIA、Google TPU、AMD 等公司招募了大量硬件人才，但要从零组建一支能定义复杂推理 ASIC 的架构团队，并在 2026 年实现量产，整个时间线极度紧迫。Broadcom 的深度参与部分缓解了这个问题，但 OpenAI 仍需在架构定义、性能验证、软件协同等方面拥有足够的话语权，否则可能沦为“贴牌”产品。

最后，供应链三角——TSMC 的先进封装产能、HBM4 的供应稳定性、10 GW 规模的电力与散热基础设施——任何一环卡住，都可能让 Titan 的部署节奏滞后。尤其是在 2026–2027 年，全球 AI 芯片需求仍在爆发期，OpenAI 将与 NVIDIA、AMD、Google、Meta 等巨头争夺同一批资源，这是一场“金钱与关系”的终极考验。

3.4.6. 结语

OpenAI 的 Titan 项目，是独立模型公司自研推理 ASIC 的极限试验。它可能成功，让 OpenAI 成为继 Google 之后第二个拥有自研推理芯片的 AI 巨头，也可能因为工程复杂度、软件生态或供应链问题而延迟，迫使 OpenAI 继续依赖 NVIDIA。但无论如何，这个项目已经向整个行业发出了一个明确信号：当推理成为 AI 的核心成本时，谁掌握了芯片，谁就掌握了 AI 服务的定价权与战略主动权。

4. 核心分析维度深度拆解

4.1. Prefill与Decode分治趋势：从两阶段分治到专用芯片分化

有一种广为流传的误解：LLM 推理是一种”单一 workload”。事实恰恰相反。LLM 推理包含两个在计算特征上几乎正交的阶段——Prefill 和 Decode。它们对硬件的需求差异之大，堪比”训练和推理”的差异。理解这一分歧，是理解所有 LLM 推理 ASIC 设计逻辑的起点。

---

4.1.1. 两个阶段，两种物理瓶颈

4.1.1.1. 算术强度：从 200+ 到 ~1 的断崖式下跌

用 Roofline 模型的语言来说，Prefill 和 Decode 分别位于图的两端。

Prefill 阶段处理整个输入 prompt，一次性对所有 token 进行并行编码。在 attention 层中，每个 head 需要计算一个完整的 S×S 注意力矩阵（S 为 prompt 长度）。以 S=4,096 为例，仅一个 head 的一个 attention 层就要执行约 1,670 万次乘加运算 [638]。此时算术强度（arithmetic intensity）可达 200-400 FLOPs/byte，几乎所有现代 GPU 的张量核心都能被充分喂饱 [767]。GPU 利用率可达 90-95% [975]。Prefill 是典型的 compute-bound 工作负载。

Decode 阶段则完全不同。每生成一个 token，模型只需要计算一个 1×(S+t) 的向量点积（每个 head），但必须从 HBM 中读取全部模型权重和整个 KV cache。在单 batch decode 场景下，线性层的算术强度约为 1 FLOP/byte——即每从 HBM 读入一个字节的权重，只执行约一次乘加运算 [3051]。对比 H100 的 HBM3 带宽约 3.35 TB/s 与 989 TFLOPS（FP16）的峰值算力，这意味着 decode 时 GPU 的计算单元利用率通常只有 20-40% [975]，大部分时间在等待数据从 HBM 搬运到片上。

一个直观的类比：Prefill 像工厂流水线全速运转，原材料（数据）供应充足，瓶颈在机器（计算单元）的加工速度；Decode 像点外卖，每次只下一个单（一个 token），但每次都要从仓库（HBM）完整清点一遍库存（权重+KV cache），瓶颈在搬运工的效率而非厨师的做菜速度。

4.1.1.2. 为什么这个问题不能通过 batching 解决

理论上，增大 batch size 可以提高算术强度，将 decode 推向 compute-bound。但这里有三重约束：

第一，延迟 SLO 约束。 交互式 LLM 应用（聊天、代码补全、Agent）的 TPOT（Time Per Output Token）SLO 通常要求在 50-200ms 以内。大 batch 意味着每个 decode step 需要处理更多请求，单步延迟随之上升。你不能为了吞吐而牺牲延迟——用户不会等。

第二，KV cache 容量限制。 每个并发请求都需要独立的 KV cache 空间。在 HBM 容量有限的 GPU 上，KV cache 的膨胀直接限制了最大并发数。以 70B 模型、FP8 精度、8K 上下文为例，单个请求的 KV cache 约 1.6GB，H100 的 80GB HBM 扣除权重约 35GB 后，理论上只能容纳 20-30 个并发请求。

第三，长上下文的放大效应。 随着 Claude、Gemini、GPT 等模型支持 100K+ token 上下文窗口，KV cache 的容量压力进一步加剧 [646]。更长的上下文意味着 decode 时需要读取的 KV cache 更大，但算术强度不变——memory wall 问题被等比放大。多步推理带来的超长上下文更是加剧了 Prefill 和 Decode 之间的资源需求差异 [754]。

---

4.1.2. 系统层的觉醒：从”合”到”分”

4.1.2.1. 学术界的理论奠基

2024 年是 Prefill-Decode 分离思想的”理论元年”。两篇关键论文在同一年独立提出了相同的核心洞察：

Splitwise（ISCA 2024） 从硬件效率和功耗角度出发，指出 Prefill 和 Decode 具有截然不同的延迟、吞吐、内存和功耗特征，将两者放在同一 GPU 上运行会导致”双重妥协”——两阶段都无法获得最优硬件配置 [592]。Splitwise 展示了一个令人震惊的数据：在 BLOOM-176B 上，处理一个 1,500-token 的 prompt（Prefill）所需的时间，相当于生成仅 6 个输出 token（Decode）[3062]。

DistServe（OSDI 2024） 从 serving 系统角度出发，将 Prefill-Decode 分离形式化为一种系统架构。DistServe 的核心贡献是证明了：分离部署可以实现 4.48× 的 goodput 提升（在满足相同 SLO 的前提下），或 12.6× 更严格的 SLO，同时将两阶段之间的延迟方差降低 20 倍 [975]。DistServe 还提出了一个关键观察：在分离后，Prefill 和 Decode 可以独立选择最优的并行策略——Prefill 选择更大规模的 TP（Tensor Parallelism），Decode 选择更小的 TP 以降低通信开销 [601]。

更重要的是，Splitwise 通过功耗分析揭示了一个被忽视的维度：TPOT 在 400W-600W 之间持续改善，但在 600W 之后趋于平缓；TTFT 在 700W 之后开始趋于平缓 [3060]。这意味着在分离架构中，可以给 Prefill 和 Decode 节点分配不同的功耗预算，实现全系统能效最优。

4.1.2.2. 工业界的快速落地

从学术论文到生产部署，间隔不到一年。以下是一些里程碑：

时间	事件	意义
2024.07	Mooncake 发布（Moonshot AI/Kimi）	首个大规模生产级 P/D 分离系统，KV cache-centric 架构，分离 Prefill 集群和 Decode 集群 [932]
2025.02	Mooncake 论文发表在 FAST ‘25	展示了在 Kimi 服务中 24 小时 Prefill/Decode 负载追踪和动态副本调度 [943]
2025.03	NVIDIA Dynamo 发布（GTC 2025）	NVIDIA 官方将 P/D 分离作为第一等公民支持，整合 vLLM/SGLang/TensorRT-LLM [912]
2025.05	DeepSeek-V3 生产部署	3 个 Prefill 节点 + 9 个 Decode 节点（每节点 8×H100），52.3K input tok/s + 22.3K output tok/s 每节点 [590]
2025-2026	Meta、LinkedIn、Mistral、HuggingFace 在 vLLM 上运行分离式 serving	P/D 分离成为主流 serving 框架的标配功能 [3026]
2026.03	AWS + Cerebras 合作	Trainium 负责 Prefill + Cerebras CS-3 负责 Decode 的异构分离架构，部署于 Amazon Bedrock [3072]

到 2026 年中，几乎每个生产级 LLM serving 框架——NVIDIA Dynamo、vLLM、SGLang、LMDeploy——都原生支持 P/D 分离 [590]。这已经不是一个”是否应该分离”的问题，而是”如何分离得更好”的问题。

---

4.1.3. 芯片层的分化：Prefill 芯片与 Decode 芯片的硬件蓝图

如果说系统层的分离是软件架构的演进，那么芯片层的分化则是硬件设计的范式转移。当 Prefill 和 Decode 可以在不同芯片上运行时，一个自然的问题浮现：我们是否应该为每个阶段设计专用的芯片？

4.1.3.1. 学术界的先行探索：SPAD

2025 年 10 月，普林斯顿大学和华盛顿大学的联合团队发表了 SPAD（Specialized Prefill and Decode Hardware） 论文 [1049]，这是学术界首次系统性地探索为 Prefill 和 Decode 分别设计专用硬件的可行性。

SPAD 的核心发现：

• Prefill Chip：大 systolic array + GDDR7 内存（而非 HBM）。因为 Prefill 是 compute-bound，不需要 HBM 级别的带宽，GDDR7 的带宽足以满足需求，成本却大幅降低。Prefill 延迟对内存带宽的敏感度远低于对计算容量的敏感度 [1050]。
• Decode Chip：大容量片上 SRAM + 优化的内存子系统。Decode 是 memory-bound，需要最大化有效带宽，而非峰值算力 [606]。
• 成本效益：在相同制造成本下，专用芯片组合相比 GPU 实现了 1.6× 的性能提升 [594]。

SPAD 的结论与工业界的实践方向高度一致。它本质上验证了一个假设：Prefill 和 Decode 不仅是软件层面的不同 workload，而且值得在硅层面进行差异化设计。

4.1.3.2. 工业界的实际分化

当我们审视当前市场上的各类芯片，一个清晰的模式已经浮现：

4.1.3.2.1. Prefill 侧：谁在做”计算重活”？

芯片	设计特征	定位
NVIDIA H100/H200/B200 GPU	HBM3/HBM3e 高带宽、高 FP16/BF16 算力	在分离架构中承担 Prefill 角色 [3027]
AWS Trainium	高吞吐 systolic array	AWS+Cerebras 合作中承担 Prefill [3072]
Google TPU	大规模 systolic array + HBM + ICI 互联	天然适合 Prefill 高 batch 场景

4.1.3.2.2. Decode 侧：谁在解决”搬运问题”？

芯片	设计特征	定位
Groq LPU / NVIDIA Groq3 LPU	数百 MB SRAM、40 PB/s 片上带宽、确定性执行	纯 Decode 加速器，NVIDIA 官方定位为”decode-phase co-processor” [1289]
d-Matrix Corsair	2GB SRAM、150 TB/s 带宽、DIMC 存内计算	Decode 专用，在异构部署中与 GPU 配合 [215]
Cerebras WSE-3	44GB SRAM、21 PB/s 带宽、900K 核心	极致 Decode 性能，AWS 合作中承担 Decode [5]
SambaNova SN50	可重构数据流 + 大容量片上 SRAM	Decode 优先，低延迟 token 生成

这些芯片有一个共同特征：SRAM-centric，而非 HBM-centric。 它们的设计哲学是：与其花大钱买 HBM 然后在 decode 时浪费 60-80% 的计算能力，不如把 HBM 的预算转化为更多的片上 SRAM，从根本上消除 memory wall。

4.1.3.3. 一个被低估的细节：NVIDIA 的异构推理蓝图

NVIDIA 在 2025-2026 年的产品布局中，实际上已经清晰地展示了 Prefill/Decode 分治的硬件蓝图：

芯片	内存	角色
Rubin GPU (HBM4)	288GB HBM4	通用 GPU，兼顾 Prefill 和训练
Groq3 LPU	~500MB SRAM	Decode 专用加速器

在当前仍可成立的公开叙事里，Rubin GPU 继续承担通用的 Prefill 与 attention 计算，Groq3 LPU 则被定位为 Decode 阶段的专用加速器。这种组合依然说明：即使不引入额外的 Prefill 专用芯片，NVIDIA 也在推动 GPU 与 SRAM-centric 加速器的异构分工，而不是依赖单一芯片覆盖全部推理路径。

---

4.1.4. KV Cache 传输：分离架构的阿喀琉斯之踵

Prefill 和 Decode 分离后，一个关键的工程挑战浮现：Prefill 节点生成的 KV cache 必须传输到 Decode 节点。 如果传输开销过大，分离带来的收益可能被完全抵消。

4.1.4.1. 传输方案的演进

方案	代表系统	特点
RDMA over InfiniBand/RoCE	DistServe, Mooncake	跨节点传输，延迟 ~μs 级，适合大规模分离 [594]
NVLink/NVSwitch	NVIDIA Dynamo (NIXL)	节点内 GPU 间传输，延迟 ~ns 级，适合 NVLink 域内分离 [917]
PCIe / RDMA 外挂内存	FPGA/专用加速器方案	通过 PCIe 挂载内存或 RDMA 远端访问扩容，适合容量优先场景 [594]
NIXL (NVIDIA)	Dynamo + vLLM/SGLang	NVIDIA 官方 KV 传输库，支持 NVLink 和 InfiniBand 双路径 [3046]

Mooncake 的实践表明，在 RDMA 网络上，KV cache 传输时间通常仅占总推理时间的 0.1% 以下 [1053]——前提是网络带宽足够且传输与计算能有效重叠。P/D-Serve 进一步将 D2D（Die-to-Die）KV 传输时间减少了 46% [1053]。

4.1.4.2. 传输策略的关键权衡

一个关键的性能折衷是 KV cache 的传输时机：

• 同步传输：Prefill 完成后立即传输全部 KV cache，Decode 节点等待传输完成后才开始生成。优点是简单可靠，缺点是引入了”第二 token 延迟”（即 TTFT 和第二个 token 之间的延迟）。
• 流水线传输：Prefill 产生一批 KV cache 即传输一批，Decode 可以提前开始。这是 Mooncake 和 Dynamo 的默认模式，能有效隐藏传输延迟 [949]。
• 统一地址视图：通过 RDMA 注册内存、用户态通信栈或远端页缓存机制，尽量减少 Prefill 和 Decode 节点之间的显式复制。semi-PD 方案展示了这类方法可将端到端延迟降低 1.27-2.58× [1053]。

---

4.1.5. 未来的分治形态：从静态分离到弹性分离

4.1.5.1. 分离的粒度在细化

当前的主流分离是”请求级”——每个请求的 Prefill 和 Decode 在不同节点上执行。但更细粒度的分离正在出现：

• Intra-GPU 分离（Nexus）：在同一 GPU 内部通过 SM 分区动态分配 Prefill 和 Decode [611]
• Attention-FFN 分离（Glinthawk）：将 Decode 中 memory-bound 的 attention 计算与 compute-bound 的 FFN 计算分离到不同硬件 [3022]
• Encode-Prefill-Decode 三级分离：对于多模态模型，将图像/音频编码（Encode）、文本 Prefill 和 Decode 分别部署到专用硬件池 [596]

4.1.5.2. 分离是否会”合回去”？

一种可能的反驳是：如果未来内存技术取得突破（如 HBM4 带宽达到 10+ TB/s，或 PCIe/RDMA 远端内存扩展的时延进一步下降），分离是否还有必要？

答案可能是：分离不会消失，但会动态化。 TaiChi 等工作已经展示了”混合模式”——允许 P-heavy 和 D-heavy 实例各自处理混合的 Prefill/Decode 请求，在负载波动时动态调整 [613]。未来的分离架构可能不是静态的”Prefill 池 + Decode 池”，而是 “弹性分离”——根据实时负载在聚合和分离模式之间自适应切换。

AWS 与 Cerebras 的合作也印证了这一点：他们明确表示将同时支持聚合和分离两种配置——分离模式适合大规模稳定工作负载，而传统聚合模式适合 Prefill/Decode 比例多变的混合负载 [3059]。

4.1.5.3. 分离架构的能效维度

一个被长期忽视但在 2025-2026 年逐渐受到重视的维度是能耗归因。Decode 阶段由于执行时间远长于 Prefill，占据了 LLM 推理总能耗的绝大部分 [628]。TokenPowerBench 等新工具的出现，使得系统可以精细地将能耗归因到 Prefill 和 Decode 阶段，从而为分离架构的资源分配决策提供数据支撑 [3100]。

实验表明，在不同的 P:D 比例（从 50:1 到 1:50）下，功耗和能耗随请求长度增加而显著变化 [3096]。这意味着分离架构的能效优势不仅体现在吞吐上，也体现在每 joule 可生成的 token 数量上——而这恰恰是超大规模推理部署中最重要的成本指标。

---

4.1.6. 小结：一个分裂的硬件世界

Prefill 和 Decode 的分治趋势，正在重塑 AI 推理芯片的竞争格局。核心结论如下：

1. Prefill 和 Decode 是两种根本不同的物理问题：一个是 compute-bound（200-400 FLOPs/byte），一个是 memory-bound（~1 FLOP/byte）。试图用同一种芯片同时优化两者，必然导致至少一个阶段的效率低下。

2. 系统层已经完成了分离：从 DistServe、Splitwise 到 Mooncake、NVIDIA Dynamo，P/D 分离已成为生产级 LLM serving 的标配架构。分离架构带来的收益是结构性的——2-7× 的吞吐提升在传统架构中无法实现 [589]。

3. 芯片层正在跟进：NVIDIA 的”Rubin GPU + LPU”异构组合、AWS 的”Trainium + Cerebras”合作、d-Matrix 的”GPU + Corsair”异构部署，都指向同一个方向——Prefill 芯片和 Decode 芯片将走向不同的设计极值。

4. 两类芯片的”理想形态”已经清晰：

   • Prefill 芯片：大 systolic array、高 FP8/FP4 算力、GDDR7 或低成本 HBM、侧重吞吐
   • Decode 芯片：大容量 SRAM、高片上带宽、确定性数据流、低精度原生支持、侧重延迟

5. KV cache 传输是分离架构的关键路径：RDMA、NVLink、PCIe 等高速互联技术是实现高效分离的基础设施前提。传输开销在优化良好的系统中可以控制在 0.1% 以下 [1053]。

6. 分离不会消失，但会更加动态和细粒度：从请求级分离到算子级分离，从静态分离到弹性分离，这一趋势仍在深化。HBM 是 Decode 容量的绑定性约束 [767]——将 Decode 迁移到 SRAM-centric 芯片，释放 HBM 给训练和 Prefill，是全局最优的资源配置策略。

一句话总结：LLM 推理不是一个 workload，而是两个。 认识到这一点，并围绕这一点设计芯片和系统架构，是 2024-2026 年 AI 推理硬件领域最重要的范式转变。那些仍然试图用”一块芯片打天下”的设计，正在被时代抛弃。

4.2. SRAM 与 HBM 的长期竞争：一场没有终点的”速度 vs 容量”军备竞赛

在 LLM 推理 ASIC 的架构讨论中，很少有话题比”SRAM 还是 HBM”更具分裂性。一边是 Groq LPU 和 Cerebras WSE 的 SRAM-only 激进路线，一边是 NVIDIA GPU 和 Google TPU 的 HBM-centric 成熟方案，中间还有 SambaNova 和 d-Matrix 的混合层级探索。这场争论的本质不是一个”孰优孰劣”的技术选择题，而是一个物理约束下的帕累托最优求解——速度、容量、成本、功耗，你永远无法同时最大化所有维度。

4.2.1. 物理底牌：为什么 SRAM 和 HBM 是”天生不对等”的对手

在讨论架构取舍之前，必须先理解两种存储介质在物理层面的根本差异。这不是一个可以通过”工程优化”绕过的鸿沟，而是晶体管物理和制造工艺决定的硬约束。

4.2.1.1. 存储单元结构：6T vs 1T1C

SRAM 的每个 bit 由 6 个晶体管（6T）构成一个双稳态触发器——本质上是用逻辑门”锁住”状态 [749]。这带来两个核心优势：读取无需刷新、访问延迟极低（单周期级别）。但代价也显而易见：6 个晶体管占用的硅面积远大于 DRAM 的 1 个晶体管 + 1 个电容（1T1C）。

HBM 本质上是垂直堆叠的 DRAM 芯片，通过硅通孔（TSV）和硅中介层（Interposer）与计算芯片连接。每个存储单元只需 1 个晶体管 + 1 个电容，密度天然高出 5-6 倍 [749]。但 DRAM 的读取需要行激活（row activation）、预充电（precharge）等操作，延迟比 SRAM 高出两个数量级。

表 1：SRAM vs HBM 物理特性对比

维度	SRAM	HBM（DRAM）	倍数差距
存储单元结构	6T 触发器	1T1C 电容	—
位元面积（TSMC N3E）	~0.021 μm²	~0.002 μm²（等效）	~10×
密度（TSMC N3E）	~38 Mb/mm²	~200 Mb/mm²	~5-6×
典型访问延迟	1-10 ns	375-500 ns	~50-200×
每 bit 读取能耗	0.1-0.3 pJ	3.5-7 pJ	~20-70×
每 GB 成本	~$5,000	~$60-100	~50-80×
是否需要刷新	否	是（周期刷新）	—
片上集成方式	原生（同一芯片）	2.5D/3D 封装	—

数据来源：[82]

4.2.1.2. SRAM 缩放停滞：一个被低估的产业级危机

过去十年，摩尔定律对 SRAM 的”眷顾”远不如对逻辑晶体管。TSMC 从 N5 到 N3E，SRAM 位元面积完全停滞在 0.021 μm² [3181]。直到 N2 节点，TSMC 才通过 DTCO（Design-Technology Co-Optimization）而非纯微缩实现了约 11% 的密度提升——38.1 Mb/mm² [3177]。这意味着：在未来几代工艺节点中，SRAM 的每 bit 成本将越来越高，而密度提升越来越慢。

这对 SRAM-centric 架构是一个根本性的利空。SRAM 的容量天花板不是设计问题，而是物理和工艺经济学的双重约束。Groq 选择在 Samsung 4nm 上制造 725 mm² 的巨大芯片，仅集成 230 MB SRAM [76]——不是它不想放更多，而是再多放，芯片面积和成本将呈指数级膨胀。

这里有一个粗略但直观的核算：如果在 TSMC N3 上制造 80 GB 的 SRAM（等效于 H100 的 HBM 容量），仅 SRAM 裸片成本就约 $13,000，而一块 H100 整卡售价约$30,000 [1247]。这还没算上计算单元、互联、封装等——纯 SRAM 路线在容量上的经济性劣势是结构性而非暂时性的。

4.2.2. LLM 推理中的”存储需求三兄弟”：权重、激活、KV Cache

要理解 SRAM 和 HBM 在 LLM 推理中的角色，必须先搞清楚到底需要存储什么。

4.2.2.1. 权重（Weights）：最大的”静态居民”

以 Llama-3-70B 为例，BF16 精度下约 140 GB。在 decode 阶段，每个 token 的生成都需要完整读取一遍全部权重——这是 decode 阶段 memory-bound 的根本原因 [3153]。权重是”静态”的：加载后不变，只读不写，对延迟敏感但对写入速度无要求。

权重适合放在哪里？ HBM 是天然选择——容量够大（141 GB 的 H200 正好装下 70B 模型），带宽够高（4.8 TB/s）。SRAM 当然更好（80 TB/s 的 Groq LPU），但容量严重不足——230 MB 的单芯片 SRAM 需要 576 个芯片才能拼出 70B 模型的容量。

4.2.2.2. KV Cache：动态增长的”内存黑洞”

KV Cache 是 LLM 推理中最棘手的内存问题。它的尺寸随上下文长度线性增长：对 70B 模型，每 1K token 约消耗 0.5 GB KV Cache [3153]。在 128K 上下文、batch size 32 的情况下，KV Cache 可能超过 150 GB——单独比权重大。

KV Cache 的特殊性在于：每次 decode 步骤都需要读取完整的 KV Cache 来计算注意力，而且它不断增长。这意味着它不仅需要容量，还需要带宽——长上下文下，KV Cache 的读取带宽可能超过权重读取带宽 [3151]。

KV Cache 适合放在哪里？ 理想的方案是分层：热 KV Cache 放在 SRAM/HBM 中，温/冷 KV Cache 通过 PCIe 挂载 DDR、CPU DRAM 或 RDMA 远端内存扩展。SambaNova 的 DDR5 层实际上就是为 KV Cache 和多模型驻留预留的”廉价容量池” [316]。

4.2.2.3. 激活值（Activations）：最小的”临时过客”

激活值是每层计算产生的中间结果，尺寸相对较小（通常几十 MB 到几百 MB），生命周期极短（用完即弃）。它们天然适合 SRAM——需要高速读写，但不需要大容量。这也是为什么 GPU 的 L1/L2 Cache 和共享内存（本质都是 SRAM）已经被充分用于激活值管理。

表 2：LLM 推理中三类数据的最佳存储层级

数据类型	尺寸特征	带宽需求	容量需求	最佳存储层级	次优但可行的方案
模型权重	固定，大（70B≈140GB）	极高（每 token 全读）	高	HBM	多芯片 SRAM 拼合
KV Cache	动态增长，O(n)	高（随上下文增长）	极高（长上下文）	HBM（热）+ PCIe/DDR（温）	纯 HBM（容量受限）
激活值	临时，小	极高	低	片上 SRAM	—

4.2.3. SRAM 的优势：确定性、低延迟与能效，但”贵得离谱”

4.2.3.1. 延迟：200-500 倍的王者优势

SRAM 的访问延迟在 1-10 ns 量级，而 HBM 需要 375-500 ns [82]。这意味着对于 latency-critical 的 decode 阶段，SRAM 可以做到几乎零等待——计算单元永远不需要停等数据。Groq 的”确定性执行”正是建立在这一物理特性之上：编译器可以精确预知每条指令的数据到达时间，因为 SRAM 没有 cache miss、没有 DRAM 行冲突、没有刷新周期的干扰 [81]。

相比之下，HBM 虽然带宽很高（TB/s 级），但每次访问都要经过行激活、列寻址、预充电等 DRAM 标准流程，延迟不可消除。NVIDIA 通过大 L2 Cache（H100: 50 MB，B200: 126 MB）缓解这一问题，但 cache hit rate 的不确定性使延迟不可预测 [1033]。

4.2.3.2. 能效：20-70 倍的每 bit 能耗优势

SRAM 的数据传输能耗约为 0.1-0.3 pJ/bit，而 HBM 约为 3.5-7 pJ/bit [3142]。差距来自物理距离：SRAM 与计算单元同处一个芯片，数据移动距离以微米计；HBM 要通过 TSV、中介层、PHY 接口，数据移动距离以毫米计。

在 LLM 推理这个”数据搬运占比远超实际计算”的场景中，这一差距被极度放大。Groq 声称其 LPU 每 token 能效比 GPU 高约 10 倍 [1330]，NVIDIA 在收购 Groq 后宣称 Groq 3 LPU 实现”每兆瓦 35 倍推理吞吐量提升” [91]。虽然这些数字是厂商的最优情况宣称，但 SRAM 在 decode 阶段的能效优势是物理上确定的。

4.2.3.3. 确定性与可预测性

SRAM 的另一个被低估的优势是确定性。没有 cache miss、没有 DRAM 刷新冲突、没有 HBM 温度 throttling——这意味着 SRAM 系统可以提供稳定的尾延迟（tail latency），这对实时性要求高的 Agentic AI 场景至关重要。GPU 的 HBM 路径在重负载下经常出现”延迟抖动”，这是 Groq 和 Cerebras 在营销中反复强调的差异化卖点。

4.2.3.4. SRAM 的致命缺陷：容量、成本与扩展性

SRAM 的优势在 decode 场景下非常耀眼，但它的劣势同样致命：

• 容量天花板：Groq 单芯片 230 MB，Cerebras WSE-3 整片晶圆也仅 44 GB [105]。运行 Llama-70B 需要 Groq 576 个芯片 [147]，运行 405B 模型需要数千个——这不仅是硬件成本的问题，更是系统复杂度和故障率的噩梦。
• 成本呈指数级：SRAM 每 GB 约 $5,000，HBM 约$60-100，差了 50-80 倍 [1249]。在推理总拥有成本（TCO）计算中，SRAM 芯片的硅面积成本可能会抵消其能效优势。
• 扩展靠”堆芯片”：多芯片切分模型虽然可行，但引入了片间互联的延迟和功耗开销。Groq 的 16 个 chip-to-chip 互联端口 [96] 本身就是对 SRAM 容量不足的”被动补偿”。
• SRAM 缩放停滞：如前所述，SRAM 未来几代的密度提升有限，与 HBM 的容量差距只会越来越大。

4.2.4. HBM 的优势：容量、生态与可扩展性，但”又贵又慢又受限”

4.2.4.1. 容量：600 倍的碾压性优势

H200 的 141 GB HBM3e 对比 Groq 的 230 MB SRAM——容量差距是 600 倍 [3203]。这意味着单张 GPU 可以完整驻留 70B 模型，而在 SRAM-only 方案中需要数百个芯片。对于 prefill 阶段（高吞吐、大 batch）和大模型部署，HBM 的容量优势不可替代。

4.2.4.2. 带宽：够用，且在快速追赶

H200 的 4.8 TB/s HBM 带宽虽然远低于 Groq 的 80 TB/s SRAM 带宽，但它已经足够满足大多数 decode 场景的需求。关键数据：Llama-70B 在 decode 阶段每生成一个 token 需要读取约 140 GB 权重，在 4.8 TB/s 带宽下理论耗时约 29 ms，实际约 15-20 ms（得益于 batch 和 L2 cache）。HBM4 将带宽推至 2 TB/s 每栈，8 栈配置可达 16 TB/s [3254]；HBM4E 进一步到 2.5-3.6 TB/s 每栈 [3255]——HBM 的带宽增长并未停滞。

4.2.4.3. 生态成熟度：CUDA 的”隐形护城河”

HBM 路线最大的优势可能不是技术本身，而是整个软件栈已经围绕 HBM 内存模型构建。PyTorch、TensorRT-LLM、vLLM、SGLang 等框架的 GPU kernel 都假设模型权重在 HBM 中、通过多级 cache 逐层加载到 SRAM 进行计算。切换到 SRAM-only 需要重写整个内存管理逻辑——这是比硬件更深的锁定。

4.2.4.4. HBM 的结构性困境

HBM 的问题同样不可忽视：

• 供应链高度集中：SK Hynix、Samsung、Micron 三家垄断全球 95% 以上的 HBM 产能 [1225]。SK Hynix 的 2026 年产能已全部售罄 [3242]，HBM3E 价格在 2026 年上涨近 20% [3240]。
• 制造成本高：1 GB HBM 消耗 4 倍于标准 DRAM 的晶圆产能 [1246]。HBM 模块售价约 $60-100，相比之下同容量 DDR5 仅$5-10 [3208]。
• 封装复杂度：HBM 需要 CoWoS 等先进封装，而 TSMC 的 CoWoS 产能同样是瓶颈——这是 NVIDIA 自己也头疼的问题。
• 能耗较高：每 bit 传输能耗约 3.5-7 pJ，8 栈 HBM 的总功耗可达数十瓦，且随带宽提升而增加。HBM4E 的单栈功耗上限已推至 80W [3257]。
• 延迟不可消除：DRAM 的物理特性决定了 ~100 ns 级别的延迟是硬地板，无法通过工艺改进消除。

4.2.5. 混合层级：SRAM + HBM + PCIe/DDR 的”三级火箭”

纯 SRAM 和纯 HBM 都有明显的天花板，行业正在向一个更复杂的答案收敛：混合层级。

4.2.5.1. 已经出现的混合架构

SambaNova SN50 是目前最清晰的混合层级实践者：432 MB 片上 SRAM（数百 TB/s）+ 64 GB HBM2E（1.8 TB/s）+ 最高 2 TB DDR5——三级存储各自承担不同的角色 [272]。SRAM 处理最热的本地计算，HBM 承载当前运行的模型权重，DDR5 存放多模型副本和 KV Cache 缓存 [316]。SambaNova 称之为”agentic caching”——允许在不到一秒内热切换模型 [276]。

d-Matrix Corsair 走的是另一条混合路径：2 GB 片上 SRAM（~150 TB/s 聚合带宽）作为”性能内存”，256 GB LPDDR5X 作为”容量内存” [231]。这种 SRAM + LPDDR 的组合比 SRAM + HBM 成本更低，但带宽落差更大（LPDDR5 约 205 GB/s vs HBM 的 TB/s 级）。

NVIDIA GPU 本身的演进也在暗示混合趋势：H100 的 50 MB L2 → B200 的 126 MB L2 [3200]，SRAM 占比在增大。即将推出的 Vera Rubin 平台整合 Groq 3 LPU 作为专门的 decode 加速器，本质上是将 SRAM-centric 推理作为 HBM-centric GPU 的异构补充 [87]。

4.2.5.2. 未来的理想层级：SRAM → HBM → PCIe/RDMA → SSD

一个合理的推测是：未来 3-5 年的 AI 推理芯片将普遍采用四级存储层级：

层级	介质	典型容量	典型带宽	用途
L0	寄存器/本地 SRAM	数 MB	数十 TB/s	矩阵乘法中间结果
L1	共享 SRAM	数百 MB - 数 GB	数 TB/s - 数十 TB/s	激活值、注意力计算
L2	HBM	100 GB - 1 TB	数 TB/s - 数十 TB/s	模型权重、热 KV Cache
L3	PCIe 挂载 DDR / RDMA 远端内存	数百 GB - 数 TB	数十 GB/s - 数百 GB/s	温 KV Cache、多模型驻留
L4	SSD/远端存储	数 TB	数十 GB/s	冷 KV Cache、模型库

这个层级的每一层都在约 10 倍的带宽和 10 倍的成本（每 GB）上递减，形成一条平滑的帕累托曲线。问题已经不再是”选 SRAM 还是 HBM”，而是”如何分配数据到不同层级以最小化每 token 成本”。

4.2.6. 长上下文与 MoE：存储层级设计的”放大器”

4.2.6.1. 长上下文如何放大存储矛盾

上下文窗口从 4K 扩展到 128K、1M 甚至 10M token，KV Cache 的尺寸从数百 MB 膨胀到数百 GB。在 1M token 上下文下，仅 KV Cache 就可能超过 500 GB（70B 模型，BF16）——远超任何单芯片 HBM 容量 [3151]。

这产生了两个后果：

• 纯 SRAM 方案在长上下文下几乎不可行：即使 576 个 Groq 芯片能拼出足够容量，KV Cache 的跨芯片访问延迟将吞噬 SRAM 的延迟优势。
• HBM 的容量也不够用：141 GB 的 H200 连权重 + KV Cache 都装不下，必须依赖 PCIe 扩展、CPU 内存分层或 offloading 策略。

长上下文是推动混合层级的最强动力——它同时要求大容量（超出任何单一介质）和低延迟（无法接受 SSD 的 ms 级延迟），因此工程上更现实的折中通常是 PCIe 挂载 DDR、CPU 内存分层或 RDMA 远端内存：延迟虽然明显高于 HBM，但仍远低于块存储，且容量扩展更直接。

4.2.6.2. MoE 如何改变存储需求

MoE 模型（如 Mixtral 8×7B、DeepSeek V3 671B）对存储层级的影响是双重的：

• 权重驻留的新挑战：虽然每个 token 只激活 2-4 个 Expert，但在高并发下，所有 Expert 最终都会被激活——这意味着全部参数必须可访问 [3234]。传统的”热权重驻留 SRAM、冷权重驻留 HBM”策略在 MoE 下面临更复杂的调度问题。
• KV Cache 不受 Expert 路由影响：不管你激活了哪个 Expert，KV Cache 都要存储完整的注意力状态 [3235]。这意味着 MoE 的 KV Cache 压力与同等参数量的 Dense 模型相同——但 MoE 的总参数量通常更大，KV Cache 压力反而更重。

MoE 放大了存储层级的需求：你需要比 Dense 模型更大的 HBM 容量来存放全部 Expert 权重，同时 KV Cache 的压力并未因 Expert 稀疏性而降低。这让 SRAM + HBM + PCIe/DDR 分层设计更有价值——SRAM 处理当前活跃 Expert 的快速访问，HBM 存放全部权重，外部内存层扩展 KV Cache。

4.2.7. 结论：没有赢家，只有更聪明的妥协

SRAM 与 HBM 的长期竞争不会有一个”谁取代谁”的结局。更可能的结果是：

1. SRAM 的角色从”存储介质”变为”计算加速器”：SRAM 将越来越多地用于近存计算、in-memory compute、注意力加速等延迟敏感场景，而不是作为权重主存储。d-Matrix 的数字 in-memory compute 和 SambaNova 的 SRAM scratchpad 已经指向了这个方向。

2. HBM 将继续作为 AI 芯片的”主内存”：容量优势太明显，生态惯性太强。HBM4/HBM4E 的带宽提升也会持续缩小与 SRAM 的差距——虽然永远追不上，但”够用”才是商业化的关键。

3. PCIe 直连 DDR 与 RDMA 远端内存将成为常见的第三级存储方案：它们可以在机柜或集群尺度提供数百 GB 到数 TB 的”温内存”，填补 HBM 和 SSD 之间的鸿沟。尤其在长上下文和 MoE 推理中，这类分层与 offloading 方案会越来越常见。

4. 异构计算将取代单一架构：未来一个推理机柜中，可能同时存在 SRAM-centric 的 decode 加速器（Groq LPU 类）、HBM-centric 的 prefill 处理器（GPU/TPU 类）、以及基于 PCIe/RDMA 的共享 KV Cache 存储层——这正是 disaggregated inference 架构的硬件基础。

最终，存储层级的设计不应该由”SRAM vs HBM”的意识形态决定，而应该由负载特征驱动：prefill 阶段的 compute-bound 大矩阵乘法需要 HBM 的高容量和高带宽；decode 阶段的 memory-bound 逐 token 生成需要 SRAM 的低延迟和确定性；长上下文需要外部内存分层与 offloading；MoE 需要更智能的 Expert 权重调度。最好的架构不是”只用一种存储”，而是让每种存储都在自己最擅长的场景中发挥最大价值。

4.3. 软件生态：护城河还是瓶颈？

如果说芯片架构决定了推理性能的理论上限，那么软件生态就是决定这个上限能否被触达、被多少开发者触达的“钥匙”。在 LLM 推理 ASIC 的竞赛中，一个反复被提及的命题是：NVIDIA 的真正护城河不是 Tensor Core，不是 HBM 带宽，而是 CUDA 生态所构建的开发者锁定效应。对于所有试图挑战 GPU 的 ASIC 厂商而言，无论其硬件指标多么亮眼，最终都必须回答一个灵魂拷问：“你的芯片，能跑 PyTorch 吗？”

4.3.1. CUDA 锁定效应：二十年积累的“隐形帝国”

CUDA 的锁定效应，本质上是一种技术生态的网络效应。它并非靠单一技术壁垒实现，而是由以下几个层次层层叠加，形成了一套几乎无法绕过的“惯性引力场”：

1. 开发者基数与行为惯性

CUDA 拥有超过 400 万注册开发者，覆盖全球 40,000 余个组织 [866]。这一数字构成了迁移成本的“实践地板”——任何试图替代 CUDA 的平台，不仅要提供同等的性能，更要在开发者心智、培训资源、社区支持等维度上进行一场不对称战争。正如一位分析师所言：“NVIDIA 维持 80% 市场份额直至 2030 年；19 年的 CUDA 生态投资创造了超过任何竞争对手性能优势的转换成本”[692]。绝大多数 AI 研究者和工程师的职业生涯始于 CUDA，cuDNN、cuBLAS、NCCL 等库是他们日常工作的“空气和水”。即便有性能更强的硬件出现，让数百万开发者放弃熟悉的工具链、调试器（如 Nsight）、profiling 工具和优化经验，重新学习一套全新的编程模型，其迁移成本不是硬件价格的差异，而是组织性的人力资本重置。

2. 库与框架的深度绑定

PyTorch 虽然名义上是一个“硬件无关”的框架，但其最核心的算子后端（ATen/cuDNN）对 CUDA 的依赖如同操作系统对内核的依赖。今天几乎所有的 AI 模型，从研究原型到生产部署，其第一条代码路径都是 CUDA。TensorRT-LLM 对 LLM 推理的极致优化、vLLM 的 PagedAttention 实现、FlashAttention 的早期版本，均以 CUDA kernel 为第一公民。这种“框架→库→kernel”的纵向整合，形成了乘法效应而非加法效应的转换成本——一个在纸面上拥有 20% 性能优势的替代方案，在实际落地时可能因为需要重建整个软件栈而变成 20% 的劣势 [692]。

3. 研究-生产的一致性

学术界和产业界的顶尖 AI 研究，几乎全部在 CUDA 环境下完成。当一篇论文发布时，代码仓库默认是 CUDA。这意味着，任何企业在尝试复现、改进或部署该模型时，从 CUDA 迁移到其他平台的风险是——不仅需要工程适配，还可能引入结果的差异。这种“可复现性焦虑”是 CUDA 锁定中最隐蔽却最坚固的一环 [3274]。正如一位观察者所指出的：“AI 软件和模型的前沿——这才是真正驱动 AI 革命的东西，而不是硬件/算力——仍然在 CUDA 生态系统中”[3280]。

4. NVIDIA 的战略投入：从数十亿到数百亿

NVIDIA 对 CUDA 生态的投入堪称寸土不让。从 2006 年 CUDA 问世以来的近 20 年间，NVIDIA 累计研发投入已超过 767 亿美元，其中相当比例用于软件生态建设 [3444]。仅在 2025 年，NVIDIA 就宣布投资 260 亿美元用于开放权重 AI 模型和软件生态 [698]。其 CUDA-X 系列库的更新频率令人窒息——在最近一次更新中，NVIDIA 一次性发布了超过 60 项 CUDA-X 库、工具和技术的更新 [3504]。这种“饱和式投入”使得任何试图追赶的竞争对手都面临一个残酷现实：NVIDIA 一年在软件生态上的投入，可能超过大多数 ASIC 创业公司的总估值。

4.3.2. ASIC 厂商降低迁移成本的手段：从“移植”到“原生”

面对 CUDA 的铜墙铁壁，ASIC 厂商并非坐以待毙。他们在过去五年中逐渐摸索出了一套多层次的“去 CUDA 化”策略，核心思路是：利用现代编译器基础设施和框架抽象层，将硬件差异隐藏在人们看不见的地方。

1. PyTorch 2.x 的“特洛伊木马”效应

PyTorch 2.x 引入的 torch.compile 和 Dynamo/Inductor 体系，从根本上改变了游戏规则。Inductor 默认将计算图 lowering 到 Triton 或 C++/OpenMP，而 ASIC 厂商只需提供自己的 Triton 后端或直接对接 Inductor 的 backend interface，就能让 PyTorch 程序“无感”运行在非 NVIDIA 硬件上。

以 Google 的 TorchTPU 项目为例，这是目前最值得关注的“破壁”行动。TorchTPU 旨在让 PyTorch 代码无缝且原生地运行在 TPU 上，直接削弱 CUDA 的框架锁定 [694]。根据报道，Google 正与 Meta 密切合作改进 PyTorch-on-TPU 性能，并考虑开源部分 TorchTPU 以加速采用 [2410]。一位内部人士直白地指出，TorchTPU 是“旨在结束这种锁定的‘反恐精英’，将从 NVIDIA 到 Google 芯片的迁移从数月的工程项目变成几行代码的事情”[3381]。一旦 TorchTPU 公开发布，它将取代现有的 PyTorch/XLA [2382]。

AMD 的策略同样激进。通过优化 Triton 后端适配 AMD GCN ISA，AMD 理论上允许任何 torch.compile 模型在 MI300X 上以高性能运行，无需代码修改 [782]。ROCm 7.0 中，torch.compile 配合 Triton 后端已对许多工作负载功能可用，尽管在自动调优成熟度上仍不及 CUDA [782]。

2. Triton：编写一次，到处运行的“圣杯”之争

OpenAI 推出的 Triton 开源编程语言和编译器，目标是让没有 CUDA 经验的研究者也能编写高效的 GPU 代码——大多数情况下能达到专家级水平 [722]。Triton 的架构设计使其天然具备跨硬件特性：通过 MLIR 多层中间表示，Triton 内核可以 lowering 到不同的硬件后端，包括 NVIDIA CUDA、AMD ROCm、Intel XPU，甚至 Qualcomm Hexagon NPU [720]。

然而，“写一次，到处运行”的理想与现实之间仍存在显著差距。以下是关键现状：

硬件平台	Triton 支持状态	成熟度
NVIDIA CUDA	一流支持，自动调优成熟	生产级
AMD ROCm	torch.compile + Triton 功能可用，但自动调优不及 CUDA	接近生产级
Intel XPU	需手动设置 TRITON_CODEGEN_INTEL_XPU_BACKEND=1	实验性
Qualcomm NPU	通过 Hexagon-MLIR 栈支持	开发中
Meta MTIA	引入 MTIA-aware MLIR 方言和 Triton DSL 扩展	内部生产

Meta 为 MTIA 引入的 Triton 扩展尤其值得关注：它改进了 TorchInductor 的 Triton 代码生成和内核融合，并通过自动调优能力自动优化工作负载 [348]。这表明，大型云厂商正在将 Triton 作为连接 PyTorch 生态与自研硬件的标准桥梁。

3. MLIR：编译器基础设施的“基础设施”

MLIR（Multi-Level Intermediate Representation）已成为 AI 编译器领域的事实标准。它不仅被 Triton 采用，还构成了 OpenXLA、TensorFlow、PyTorch 的 Glow 编译器、以及众多 ASIC 厂商编译栈的基础 [3331]。Google 将 MLIR 贡献给 LLVM 基金会，使其成为真正的行业公共品 [804]。MLIR 的关键价值在于：芯片厂商可以定义自己的硬件 dialect，通过逐级 lowering 将高层算子映射到自家后端，而不必重新发明完整的编译器前端。

d-Matrix 的 Aviator 软件栈明确建立在 MLIR、PyTorch 和 Triton DSL 等开源组件之上 [231]。Cerebras 的编译器将 PyTorch/TensorFlow 图自动映射到 WSE 核心 [141]。SambaNova 的 SambaFlow 将标准框架模型编译为 RDU 可执行的数据流图 [184]。这些案例证明，MLIR 已经成为 ASIC 厂商降低软件迁移成本的“共同语言”。

4. vLLM 的多后端生态：推理框架的“去 CUDA 化”

vLLM 在 2025-2026 年间已发展为多后端推理的事实标准，覆盖 NVIDIA、AMD、Intel、Trainium、TPU，拥有 17k+ GitHub star [3374]。vLLM TPU 后端的推出尤其具有象征意义：一个由 Googlers 和 vLLM 核心贡献者组成的“小而强大”团队，在 2025 年 2 月着手开发，目标是在 Cloud Next 2025 前推出可用的 TPU 后端 [2367]。如今，vLLM 已在 NVIDIA GPU、AMD GPU、Google TPU、AWS Trainium/Inferentia、Intel Gaudi 等硬件上提供一流支持 [3458]。

这一趋势意味着：对于新进入的 ASIC 厂商，只要能在 vLLM 中提供合格的后端，就能获得与主流推理生态的“即插即用”兼容性。这大幅降低了迁移成本——从“重建整个 serving stack”变成“实现一个 vLLM 后端”。

4.3.3. 抽象层能否真正削弱 CUDA 锁定？——理想与现实的鸿沟

尽管 MLIR、Triton、PyTorch 2.x、vLLM 等抽象层在理论上极大地降低了硬件迁移门槛，但我们必须清醒地认识到：写下“能跑”和“跑得好”之间，隔着至少一个数量级的工程投入。

1. 性能的“最后一公里”问题

AMD MI300X 的案例是最好的例证。尽管 MI300X 提供比 H100 高 1.5 倍的理论算力，但在 LLM 推理中仅达到 H100/H200 的 37-66% 性能 [827]。这不是硬件的问题，而是软件成熟度的问题。Triton 虽然能生成可运行的 kernel，但要在特定硬件上榨取极致性能，仍需手写硬件特定的 kernel 或进行大量 auto-tuning。NVIDIA 的 cuDNN 库中，每个算子针对不同代际 GPU 的微架构进行了手写汇编级的优化，这种“人肉优化”积累是 ASIC 厂商短期无法复制的。

2. 调试、Profiling 与运维工具链的缺失

CUDA 生态的价值不仅在于写出 kernel，更在于 Nsight Systems、Nsight Compute 等强大的 profiling 和调试工具，以及 cuda-gdb、cuda-memcheck 等开发辅助。ASIC 厂商通常只能提供基础的性能计数器，缺乏成熟的性能分析可视化工具。当模型出现精度问题或性能瓶颈时，开发者往往束手无策，这种“黑盒感”会大幅抬高运维成本，甚至导致项目失败。

3. 极端案例：Taalas 和 Etched 的“零软件”策略

在软件生态的讨论中，Taalas 和 Etched 代表了两种极端的“去软件化”路径：

• Taalas HC1：直接将 Llama 3.1 8B 模型的权重和计算图硬连逻辑到硅片中，完全消除了“加载模型-编译-执行”这一软件栈 [37]。用户不需要编写任何 kernel，不需要配置编译器，不需要管理 KV cache——模型就是芯片，芯片就是模型。这种“模型硬连逻辑”的方式，将软件迁移成本从“数周”降到“零”，但代价是芯片只能运行一个模型 [39]。

• Etched Sohu：将 Transformer 架构直接烧录到硅片中，仅支持 Transformer 类模型，不支持 CNN、RNN、SSM 或 DLRM [42]。Etched 需要开发者使用其专有的编译器，没有从 vLLM 或 TensorRT-LLM 的迁移路径 [41]。但与此同时，Sohu 的软件栈相对简单，因为它只需要支持 Transformer 架构 [163]。

这两种策略的共同逻辑是：通过极限的架构绑定，换取软件栈的“消失”。这种策略在特定场景下有效（如大规模部署单一模型族），但一旦模型架构发生变化（如 SSM、Mamba、RWKV 等新架构崛起），这些芯片将立即失去全部价值 [44]。

4.3.4. 推理框架生态：从 CUDA 原生到多后端均衡

LLM 推理框架的格局正在经历一场静默但深刻的变革，其核心趋势是从 CUDA 单一依赖向多后端均衡演进。

vLLM vs SGLang vs TensorRT-LLM 的“三国演义”

2025-2026 年的推理框架竞争呈现出清晰的三角格局：

框架	核心优势	硬件绑定	适用场景
TensorRT-LLM	NVIDIA 硬件上最高原始吞吐，FP8 量化下可达 vLLM 的 2.3 倍	深度绑定 NVIDIA	纯 NVIDIA 环境，追求极致性能
vLLM	最广泛的硬件和模型覆盖，OpenAI 兼容 API，社区生态最大	多后端支持	多硬件环境，需要灵活性
SGLang	RadixAttention 和 prefix caching 优势，高并发 MoE 工作负载领先	多后端支持	共享上下文场景，高并发推理

TensorRT-LLM 的编译引擎路径可提供最高原始吞吐，但代价是巨大的操作复杂性——冷启动时间约 28 分钟，而 vLLM 和 SGLang 仅需数秒 [3345]。SGLang 在 prefix-heavy 工作负载上比 vLLM 高出 28% 的吞吐 [3333]。vLLM 是唯一不会因更换硬件而需要重写的引擎 [3334]。

值得注意的是，Hugging Face 的 TGI 在 2025 年 12 月进入维护模式，Hugging Face 决定将资源贡献给 vLLM 和 SGLang 而非维护独立推理引擎 [3346]。这一信号表明，推理框架的收敛正在加速，多后端支持成为生存必需，CUDA 独占不再是默认选项。

4.3.5. 团队与资金：软件生态建设的“军备竞赛”

对于初创 ASIC 公司，一个尖锐的观点是：软件团队的重要性已经超过硬件团队。这并非否认硬件架构的价值，而是因为：

• 硬件设计是一次性的巨额投入，而软件生态建设是持续性的、指数级增长的投入。
• 一个优秀的硬件架构如果缺乏软件支持，最快可能在 18 个月内被市场遗忘；而一个平庸的硬件如果拥有出色的软件兼容性和易用性，却可能找到生存空间。
• NVIDIA 在 2025 财年的研发支出达 129 亿美元，同比增长 48.86% [3440]。其累计研发投入已超过 767 亿美元 [3444]。软件年度收入（包括 CUDA 相关服务）已超过 20 亿美元 [3447]。这种体量的投入，是任何 ASIC 初创公司无法匹敌的。

Ian Baird 的判断一针见血：“每个定制加速器面临的主要障碍不是硬件性能，而是软件兼容性”[3430]。NVIDIA 的成功不仅在于其强大的芯片，还在于其用户友好的软件生态——竞争对手可能缺乏同等的用户基础 [3500]。

4.3.6. 结论：软件生态是“护城河”，也是 ASIC 必须跨越的“瓶颈”

NVIDIA 的 CUDA 护城河是真实存在的，并且在未来 3-5 年内仍将是 AI 芯片竞争中最坚固的壁垒。然而，护城河并非不可逾越的城墙——PyTorch 2.x、Triton、MLIR、vLLM 等抽象层正在将这道城墙的高度逐渐降低，但还远未到“填平”的程度。

关键判断如下：

1. CUDA 的锁定效应正在从“绝对锁定”转向“相对锁定”。多后端框架（vLLM、SGLang）和硬件抽象层（Triton、MLIR）的成熟，使得迁移成本从“不可行”变为“可承受”，但远未达到“无感”的程度。

2. “能跑”与“跑得好”之间的鸿沟是竞争的关键。抽象层可以解决“能跑”的问题，但“跑得好”仍需持续的库优化、kernel 调优和工具链建设。这正是 NVIDIA 的护城河所在——近 20 年积累的优化不是任何抽象层能在短期内替代的。

3. 云厂商自研 ASIC 的软件生态建设路径与独立 ASIC 公司截然不同。前者（Google TPU、Meta MTIA、Microsoft Maia）可以将软件投入分摊到内部海量工作负载上，且不需要对外销售；后者必须面对客户导入、软件迁移、社区建设等全方位挑战。

4. TorchTPU 是 CUDA 统治面临的最严峻挑战。Google 与 Meta 的联手，加上 PyTorch 生态的向心力，可能首次构建出一个足以与 CUDA 抗衡的“反 CUDA 联盟”。但 TorchTPU 的迁移预计需要 18-24 个月才能渗透到中小型应用公司 [3374]。

5. 极端策略（Taalas 的“模型硬连逻辑”、Etched 的“架构烧录”）在特定场景有效，但抗风险能力极弱。一旦模型架构演进，这些芯片将迅速失去价值。软件生态的“消失”是以牺牲灵活性为代价的。

最终，软件生态的竞争将演变为生态共同体的竞争。NVIDIA 拥有一个封闭但高度优化的共同体，而它的挑战者们正在通过拥抱开源抽象层，试图构建一个“反 CUDA 联盟”。这个联盟能否成功，取决于它能否在“开放性”和“极致性能”之间找到平衡点——而这正是 LLM 推理 ASIC 产业中最值得持续观察的深层博弈。

4.4. 云厂商自研ASIC与独立ASIC公司的不同命运：两条路径，两种生存逻辑

如果把AI芯片的商业化赌局比作牌桌，云厂商和独立ASIC公司坐在同一张桌上，筹码却截然不同。云厂商押注“自用降本”，独立ASIC公司押注“对外销售”——这两种逻辑决定了它们在技术路线、客户关系、资金耐力、甚至终极命运上的根本性分歧。

---

4.4.1. 商业模式基因的源头分歧

4.4.1.1. 云厂商：芯片是成本中心，不是利润中心

Google TPU的故事从一开始就不是为了“卖芯片”。2013年，Google意识到如果要用AI全面改造搜索，数据中心数量需要翻倍[379]。TPU v1的诞生是为了让搜索推理的算力账单不爆炸——本质上是一个成本规避工具，而非营收创造工具。

这种“成本中心”基因决定了云厂商自研ASIC的五个关键特征：

特征	具体表现	战略含义
不需要“卖”芯片	芯片直接部署于自有数据中心，跳过市场营销、销售渠道、客户支持	省去整个商业化部门，组织效率极高
真实负载驱动设计	芯片规格直接来源于内部工作负载的profiling数据	架构决策有数据支撑，不会“闭门造车”
容忍不完美	首代芯片性能不达预期没关系，内部吃下、迭代改进	试错成本由内部业务消化，无需面对客户投诉
软件生态“够用就行”	不需要兼容所有框架，只需支持内部使用的技术栈	避免了CUDA兼容性这一“无底洞”
部署规模决定ROI	芯片设计成本（1-5亿美元/代）由百万级芯片出货摊薄	年推理支出超过5亿美元才有经济意义[3563]

这四个云厂商加在一起，2025年在AI基础设施上的资本支出超过3800亿美元[825]。自研芯片在这笔账上的角色很清楚：每将一个workload从NVIDIA GPU迁移到自研ASIC，就省下NVIDIA 70%毛利率那一层“GPU税”[3865]。

各家的成果验证了这个逻辑：

• Google TPU：成熟度最高，TPU v7 Ironwood的TCO较NVIDIA GB200低约44%[3864]。2025年TPU相关收入预计达113亿美元，基于250万颗出货量[1243]。Google已与Broadcom签订至2031年的长期供应协议[3692]。
• AWS Trainium：Trainium2实例比GPU实例价格性能优30-40%[3611]，Trainium3宣称比H100便宜50%[4002]。截至2025年底已部署超50万颗Trainium2芯片[688]，Anthropic的Project Rainier集群已激活近50万颗[3727]。
• Meta MTIA：MTIA200实现平均44%的TCO降低[351]。MTIA系列已从推荐系统推理扩展到GenAI推理，路线图涵盖MTIA 300/400/450/500四代产品[2659]。分析师估计MTIA每年可为Meta节省30-40亿美元[358]。
• Microsoft Maia：Maia 100起步较晚，2024年才在Hot Chips上公布规格[300]，但Maia 200已转向TSMC 3nm工艺，聚焦推理，宣称性能/美元提升30%以上[2533]。

4.4.1.2. 独立ASIC公司：芯片必须是利润中心

独立ASIC公司的基因完全不同。它们没有内部搜索、广告、推荐业务来消化芯片成本，每一颗芯片都必须找到外部买家，且售价必须覆盖研发、流片、软件支持、销售团队的全部成本，还要给投资人留下利润。

这就产生了一个根本性的不对称：

云厂商自研芯片的“盈亏平衡点”是“比买GPU便宜”，而独立ASIC公司的盈亏平衡点是“客户愿意付的价钱 > 我们造芯片的成本 + 软件迁移成本 + 风险溢价”。

后者远比前者苛刻。因为客户在比较的不是“ASIC vs GPU的硬件成本”，而是“把整个serving栈从CUDA迁移到你的平台的总成本 vs 多买几块H100继续用”。

---

4.4.2. 导入难度：从“内部通知”到“说服客户”

4.4.2.1. 云厂商：唯一的“客户”是内部AI团队

Google的TPU团队和Gemini团队在同一栋楼里开会。当TPU v6e的编译器对某个attention算子支持不好时，解决方案不是发一篇白皮书说服外部客户，而是直接让两个团队的工程师坐下来一起debug。这种“物理距离为零”的协同效率，是独立ASIC公司永远无法复制的。

Meta的MTIA路线图更直白——从推荐系统推理出发，逐步扩展到GenAI推理[354]。推荐系统是Meta的核心收入引擎（广告排序），MTIA在这上面每提升1%的效率，直接转化为数亿美元的营收增量。芯片不需要被“卖”给任何外部客户，它的ROI在内部P&L上清清楚楚。

Amazon则将自研芯片的导入路径制度化：Trainium通过Bedrock、SageMaker等上层服务交付，客户甚至不需要知道底层跑的是Trainium还是NVIDIA GPU[3785]。AWS CEO Andy Jassy预测Trainium推理业务“将发展成与EC2同等规模的业务”[3785]——这意味着一款没有外部“销售”的芯片，反而可能成为AWS史上最大的增长引擎。

但值得注意的是，Google正在将TPU从纯内部工具转型为对外商业化产品。Anthropic在2025年10月宣布获取最多100万颗TPU的协议[389]，Meta也签署了价值超100亿美元的六年期云协议[3015]。Google甚至开始向外部客户直接提供TPU硬件，而非仅通过云租赁[3864]。这一转变标志着TPU从“成本中心”走向“利润中心”的尝试——但这条路仍需验证。正如分析师指出的，TPU的商业化可能会让内部AI研究团队面临算力资源竞争[3672]。

4.4.2.2. 独立ASIC公司：一个客户一个客户地“啃”

独立ASIC公司的客户导入则是一个漫长而痛苦的信任建立过程。这一点在Cerebras的IPO文件中有最赤裸的体现：

• 2024年：G42一家客户占Cerebras营收的85%[3626]
• 2025年：两个阿联酋关联实体（MBZUAI + G42）合计占86%[1079]
• 本质上，2025年的“客户多元化”只是两个关联实体之间的账面调整

这种极端客户集中度不是Cerebras独有的问题，而是独立ASIC商业模式的系统性困境：早期只有少数“超级客户”（主权基金、国家实验室、顶级AI实验室）有足够的动力和预算去尝试非GPU方案。 Groq在2025年7月将全年营收预期从20亿美元下调至5亿美元，降幅75%，核心原因就是沙特15亿美元供应协议的延迟[3873]。当一个公司的命运系于单一客户的支付节奏时，“商业模式”三个字要打上引号。

SambaNova的情况更说明问题。2025年全年ARR仅约1亿美元[2243]，同年10月融资失败、探索出售，BlackRock将持股减记17%[2186]。Intel的收购谈判（约16亿美元）最终破裂[2176]，2026年2月以实质性down-round完成Series E 3.5亿美元融资[2141]。从2021年估值超50亿美元到2025年估值缩水57%[3628]，SambaNova的轨迹是一个教科书级的警示：在没有云厂商那样的内部负载支撑的情况下，即使技术路线独特（可重构数据流架构），独立ASIC公司也可能在商业化上陷入“死亡螺旋”。

---

4.4.3. 软件生态：CUDA是护城河，也是一堵墙

4.4.3.1. 云厂商可以“绕墙走”

Google TPU的软件栈曾长期只支持TensorFlow，外界批评其“厂商锁定”[3531]。但Google的回应很简单：Gemini和搜索团队只用TensorFlow/JAX，所以不需要支持PyTorch。直到2024年Anthropic作为外部客户提出了PyTorch兼容性需求，Google才开始与Meta合作优化PyTorch/XLA栈[3373]。

AWS Trainium则从一开始就选择了“兼容性优先”的策略——Neuron SDK原生支持PyTorch、TensorFlow和JAX，通过torch-neuronx实现与PyTorch/XLA的兼容[3656]。这不是因为AWS比Google更“开放”，而是因为AWS作为云平台，其芯片天然需要服务外部客户的工作负载多样性。

Meta的MTIA在软件生态上最为“封闭”——它只需要支持Meta内部的推荐模型和LLaMA系列模型。MTIA的编译器甚至不需要支持通用的PyTorch算子全集，只需支持Meta实际使用的算子子集。这种“不需要兼容一切”的自由度，是独立ASIC公司做梦都不敢想的。

4.4.3.2. 独立ASIC公司必须“正面硬刚”

CUDA的规模效应是压倒性的：400万+开发者、3,000+ GPU加速应用、15年持续优化[1159]。对于独立ASIC公司，软件迁移成本是最大的单一竞争壁垒，其影响远超硬件性能差距。

各公司的应对策略各不相同，但都付出了巨大代价：

公司	软件策略	代价
Groq	API兼容OpenAI格式 + 自有编译器	API层兼容降低了门槛，但底层LPU架构需要模型重构才能获得最佳性能[139]
Cerebras	专有CSL语言 + SDK	需要学习全新编程语言编写kernel，与CUDA完全不兼容[4039]
d-Matrix	开源标准兼容 + 全栈软件	强调兼容性，但商业化初期尚无大规模开发者验证[218]
SambaNova	PyTorch → 数据流图编译（SambaFlow）	全栈锁定，企业需同时采用硬件+软件+模型[3766]

AMD的ROCm经过多年投资仍未能实质性地侵蚀CUDA份额[3812]，这一事实本身就说明：“够用”的软件替代方案不足以驱动大规模迁移。独立ASIC公司需要的是“更好用”——而这在CUDA 15年的先发优势面前，几乎是一个不可能完成的任务。

---

4.4.4. 供应链：谁在台积电面前有话语权？

4.4.4.1. 云厂商：大客户身份就是通行证

Google每年向台积电下的晶圆订单，规模仅次于Apple。当Google需要为TPU v7 Ironwood锁定CoWoS产能时，它不需要“排队”——它是台积电最优先服务的客户之一。Google甚至自建数据中心，PUE低至1.1（行业平均1.58），进一步放大自研芯片的能源成本优势[345]。

Amazon通过Annapurna Labs（2015年以3.5亿美元收购）建立了完整的内部芯片设计能力[3551]，Trainium 3转向了3nm工艺[3553]。AWS的采购体量（不仅仅是AI芯片，还包括Graviton CPU、Nitro卡）使其在台积电面前拥有极强的议价权。Trainium芯片业务年营收运转率已突破200亿美元，同比增长三位数百分比[3574]。

Meta与Broadcom合作设计了MTIA系列，借助Broadcom的供应链管理能力确保产能[354]。Microsoft的Maia系列虽然起步最晚，但Microsoft作为台积电的大客户群体之一，同样享有产能分配优先级。

4.4.4.2. 独立ASIC公司：小客户，大风险

独立ASIC公司在供应链上的脆弱性，在Groq身上体现得最为戏剧化。

Groq的LPU选择了三星4nm SF4X工艺[3794]。三星4nm良率在2025年长期徘徊在60-70%，直到2026年4月才突破80%[4094]。良率不足直接导致可售芯片数量不足[4093]，而三星在2025年削减代工投资超50%，承认“继续向缺乏客户牵引力的业务投入资本代表糟糕的资本配置”[3889]。Groq的营收预期下调15亿美元，对三星代工业务造成了直接打击[3873]——这是一个“双向脆弱”的关系：初创公司依赖代工厂，代工厂也在评估初创公司是否值得长期投入。

Cerebras的晶圆级引擎（WSE）面临独有的供应链挑战。单个芯片面积46,225mm²（整个300mm晶圆），在台积电5nm缺陷密度（~0.001/mm²）下，每个晶圆约有40-50个缺陷[1091]。所有晶圆采购均为逐单订购，无长期产能承诺[3770]。NVIDIA已锁定台积电大部分CoWoS产能，Cerebras在产能紧张时必然排在Apple、NVIDIA、AMD之后[3773]。

d-Matrix采用台积电6nm工艺，相对成熟[231]，但作为年收入尚未规模化的初创公司，在产能分配优先级上同样处于劣势。SambaNova与Apple、NVIDIA竞争台积电5nm/3nm产能[3766]，年营收仅1亿美元的公司与年营收数千亿美元的公司站在同一队列里——这不是一个公平的竞争。

---

4.4.5. 结论：分层共赢，而非零和博弈

层次	主导者	商业模式	利润特征	长期确定性
AI应用/服务层	Google、Amazon、Microsoft、Meta	Token/API/广告变现	持续性、高增长、网络效应	⭐⭐⭐⭐
芯片设计服务层	Broadcom（60%）、Marvell（25%）	设计费+芯片出货提成	长期合同、跨客户摊薄	⭐⭐⭐⭐⭐
制造层	台积电	晶圆代工+CoWoS封装	不可替代、供不应求	⭐⭐⭐⭐⭐
独立ASIC芯片层	Groq、Cerebras、d-Matrix、SambaNova	芯片销售/Token服务	高波动、客户集中、资本密集	⭐⭐

五个核心判断：

1. 云厂商自研ASIC的“降本”逻辑已获验证。 Google TPU的TCO优势约40-44%，Meta MTIA约44%，Amazon Trainium约30-50%[482]。这些数据来自真实的规模化部署，而非PPT推演。

2. 独立ASIC公司的“对外销售”逻辑面临结构性困境。 客户集中度（Cerebras 86%来自两个关联实体）、软件迁移成本（CUDA 15年生态壁垒）、供应链弱势（台积电产能分配优先级）三重压力相互强化，形成恶性循环。

3. “卖芯片”正在让位于“卖Token”。 Groq和Cerebras的转型表明，独立ASIC公司意识到：持续性的Token收入 > 一次性的芯片收入。但这一转型使它们与云厂商从“供应商-客户”关系变为“直接竞争对手”。

4. 最终赢家可能不是芯片公司，而是垂直整合的AI基础设施运营商。 Google同时拥有TPU + Gemini + Google Cloud，Amazon同时拥有Trainium + Bedrock + AWS，Meta同时拥有MTIA + LLaMA + 社交网络。芯片只是它们价值拼图的一角，而非全部。

5. NVIDIA不会被替代，但垄断地位将被削弱。 预计NVIDIA在超大规模数据中心的AI训练份额将从当前的80%降至55-60%，ASIC将填补空白[475]。市场格局将从“一家独大”变为“GPU + ASIC双轨并行”，而这对整个行业来说，是比单一供应商垄断更健康的状态。

一句话总结：云厂商自研ASIC的终极目标不是打败NVIDIA，而是“不再给NVIDIA交税”。独立ASIC公司的终极目标不是取代GPU，而是找到一个足够大的细分市场，在云厂商和NVIDIA的夹缝中生存下来。两者的命运轨迹看似平行，实则指向同一个终点——AI推理的算力不再是一种稀缺商品，而是一种像电力一样的基础设施。而在这个终点到来之前，谁能活下来，取决于谁手里有“内部负载”这张最硬的底牌。

5. 横向对比表

5.1. 表1：各ASIC/芯片基本信息

说明：本表汇总截至2026年6月各芯片的关键参数。信息可信度分三级——高（芯片已量产/部署，有第三方验证或官方详细规格）、中（芯片已正式发布/流片但未量产，或关键参数来自厂商单方面宣称）、低（仅有路线图/传闻，缺乏官方确认）。

公司/芯片	芯片类型	主要目标场景	工艺节点	存储架构	片间互联	软件生态	商业化状态	主要客户/部署场景	已公开性能指标	信息可信度
Groq LPU v1 (TSP)	确定性 VLIW SIMD，SRAM-centric	LLM 推理（decode 为主）	GlobalFoundries 14nm（725 mm²）[179]	230 MB 片上 SRAM，~80 TB/s 带宽 [81]	16 链路 plesiosynchronous 协议，Dragonfly 拓扑 [75]	自研编译器（确定性静态调度），无标准框架原生支持 [79]	已部署（GroqCloud），约 108K LPU 部署 [1155]	GroqCloud 开发者、企业 API 客户	188 TFLOPS FP16；750 TOPS INT8；Llama 3 70B ~800 tok/s [88]	高
NVIDIA Groq 3 LP30 (LPU v2)	SRAM-centric 确定性推理加速器（LPU）	LLM decode 协处理器，与 Vera Rubin 平台配对	Samsung 4nm（SF4X）[4323]	500–512 MB 片上 SRAM，150 TB/s 带宽 [98]	96 链路 @112 Gbps，2.5 TB/s 双向 I/O；LPX 机柜 256 LPU 全互联 [84]	NVIDIA CUDA 生态集成，Triton 推断支持 [4334]	2026 Q3 出货（LPX 机柜）[1289]	NVIDIA AI Factory 客户，预集成于 Vera Rubin 平台 [4338]	1.23 PFLOPS FP8；LPX 机柜 315 PFLOPS FP8，40 PB/s 聚合 SRAM 带宽 [87]	中（已发布未量产）
Cerebras WSE-3	晶圆级引擎（Wafer-Scale Engine）	训练 + 推理	TSMC 5nm（46,225 mm²，4T 晶体管）[7]	44 GB 片上 SRAM，21 PB/s 带宽 [115]	2D Mesh 片上 fabric（214 Pbit/s）；SwarmX 外部互联；MemoryX 外置权重存储 [3]	CSoft 编译栈，Cerebras Graph Compiler [105]	已量产（CS-3 系统），OpenAI 签 $20B 采购协议 [102]	OpenAI（750 MW 容量）、政府/科研 HPC	125 PFLOPS FP16；Llama 4 Maverick ~2,500 tok/s/user [3]	高
Taalas HC1	模型专用集成电路（MSIC），Mask ROM + SRAM	单模型推理（Llama 3.1 8B）	TSMC 6nm（815 mm²，53B 晶体管）[38]	Mask ROM 硬编码权重 + SRAM（KV Cache / LoRA）；无 HBM [23]	标准 PCIe 插卡 [39]	无通用软件栈；模型直接”烧录”于硅中 [21]	技术演示器（2026.2 发布），API 可试用；HC2 规划中 [4169]	开发者 API 试用	17,000 tok/s/user（Llama 3.1 8B）；200W/卡；2.5 kW 双路服务器 [27]	中（芯片存在但仅限演示）
Etched Sohu	Transformer 专用 ASIC	Transformer 推理（仅推理，不支持训练）	TSMC 4nm（~800 mm² 估计）[156]	144 GB HBM3E，~4,800 GB/s；片上 SRAM 未公开 [156]	未公开细节	自研编译器；仅支持 Transformer [41]	未出货（截至 2026.6）；$625M+ 融资，$5B+ 估值 [155]	无公开客户	宣称 500K+ tok/s（Llama 70B，8 芯片服务器）；无独立 benchmark [44]	低（未流片确认，无第三方验证）
d-Matrix Corsair	数字存内计算（DIMC）ASIC，Chiplet	低延迟 LLM 推理（decode）	TSMC 6nm（每 Chiplet ~400 mm²）[209]	2 GB SRAM（每卡）+ 256 GB LPDDR5；150 TB/s SRAM 带宽 [209]	DMX Link（自研 D2D，~1 TB/s，115 ns）；DMX Bridge 卡间桥接；PCIe Gen5 [232]	Aviator 软件栈，原生分布式推理 [218]	2026.6 全面量产；SquadRack 通过 Supermicro 出货 [215]	优先 hyperscaler 客户	2.4 PFLOPS MXINT8；Llama 3 8B 60K tok/s；70B 30K tok/s（单机架）[212]	高（已量产）
SambaNova SN50	可重构数据流架构（RDU），双 Chiplet	企业级 Agentic AI 推理	TSMC 5nm [4234]	432 MB SRAM + 64 GB HBM2E + 256 GB–2 TB DDR5（三层混合）[272]	自研 Ethernet-based fabric，多 TB/s 级，最大 256 芯片 [270]	SambaFlow 数据流编译器，PyTorch/TensorFlow 前端	2026 H2 出货；$350M Series E 融资 [3198]	SoftBank（日本数据中心首发）；Intel 战略合作 [280]	3.2 PFLOPS FP8；Llama 3.3 70B 895 tok/s/user [272]	中（已发布未量产）
Google TPU v6e Trillium	脉动阵列（Systolic Array）	训练 + 推理	TSMC 5nm（与 v5p 同节点，~700 mm² 估计）[379]	32 GB HBM3，~1.6 TB/s [532]	ICI 3.2 Tbps，2D Torus，256 芯片 Pod [341]	XLA/JAX/TensorFlow [380]	2024 GA；Google Cloud 对外提供 [335]	Google Cloud TPU 实例客户	~918 BF16 TFLOPS（估计）；4.7× v5e [377]	高（已部署）
Google TPU v7 Ironwood	脉动阵列，双计算 Die + 8 HBM 堆栈	大规模推理	TSMC 3nm（N3P，~700 mm² 计算 Die）[4312]	192 GB HBM3e，7.4 TB/s [396]	ICI 9.6 Tb/s，3D Torus + OCS，9,216 芯片 Superpod [333]	XLA/JAX/TensorFlow [331]	2025.11 GA；Google Cloud [395]	Google Cloud、Google 内部模型	4,614 TFLOPS FP8；42.5 EF Superpod [333]	高（已部署）
Google TPU v8i Zebrafish	推理专用脉动阵列（与训练分叉）	推理（分叉架构首款推理芯片）	TSMC 2nm（N2, GAAFET）[395]	288 GB HBM3e，8.6 TB/s；384 MB 片上 SRAM [392]	ICI 19.2 Tb/s，Boardfly 拓扑，1,152 芯片 Pod；CAE 加速引擎 [4319]	XLA/JAX/TensorFlow [388]	目标 2027 年末 [395]	Google Cloud（规划中）	10.1 PFLOPS FP4 [392]	低（路线图阶段）
Microsoft Maia 200	瓦片化推理加速器（Tile-based）	LLM 推理（token 生成）	TSMC 3nm（N3P，~140B 晶体管）[2576]	216 GB HBM3e，7 TB/s；272 MB 片上 SRAM（CSRAM + TSRAM 分区）[286]	Ethernet-based ATL，2.8 TB/s，FCQ 拓扑，最大 6,144 芯片 [302]	Maia SDK，Triton 支持，Azure 集成 [293]	2026.1 已部署（Azure US Central）；内部使用，未对外租售 [286]	Microsoft 内部（GPT-5.2 推理、Copilot、Foundry）[325]	>10 PFLOPS FP4，>5 PFLOPS FP8；750W TDP [2627]	高（已部署，但未公开租售）
Meta MTIA v2 (200)	8×8 PE 网格，RISC-V + 固定功能单元	推荐系统推理	TSMC 5nm（421 mm²）[2670]	256 MB SRAM（2.7 TB/s）+ 128 GB LPDDR5（204.8 GB/s）[350]	PCIe Gen5 ×8 [2714]	PyTorch 2.0，Triton，vLLM [361]	已大规模部署（数十万片）[351]	Meta 内部（Facebook/Instagram 推荐）	354 TOPS INT8，177 TFLOPS FP16 [2714]	高（已部署）
Meta MTIA 300	Chiplet（1 计算 Die + 2 网络 Chiplet + HBM）	推荐训练 + GenAI	未披露（推测先进节点）[2679]	216 GB HBM，6.1 TB/s [348]	集成 NIC（2 Chiplet × 6 × 800 Gbps），16 芯片 Scale-up [2679]	PyTorch，vLLM，Triton [350]	已量产（2025–2026）[3738]	Meta 内部	1.2 PFLOPS FP16，0.6 PFLOPS FP8 [348]	高（已量产）
Meta MTIA 400	双计算 Die Chiplet + HBM	GenAI 推理	未披露	288 GB HBM，9.2 TB/s [348]	72 芯片 Scale-up 域 [348]	PyTorch，vLLM，Triton [350]	实验室测试完成，2026 部署中 [358]	Meta 内部	12 PFLOPS FP8，6 PFLOPS FP16 [348]	中（已流片测试）
OpenAI / Broadcom “Titan”	推理 ASIC（脉动阵列）	OpenAI 模型推理	TSMC 3nm（N3）；Gen 2 规划 A16（1.6nm）[479]	HBM3E（Gen 1）；HBM4（Gen 2）；容量未公开 [502]	Broadcom Ethernet 栈 + PCIe；3.5D XDSiP 封装 [2886]	内部专用，不对外 [492]	2026 H2 量产；10 GW 部署目标 2029 年完成 [2827]	OpenAI 内部（~$10B 初始订单）[472]	宣称推理成本降低 ~90% [489]	低-中（正式合作确认，但规格大多未公开）

数据来源：本表数据综合自各厂商官方公告、技术文档、第三方分析报告及行业媒体报道，具体引用编号见各单元格标注。由于表1源自此前完成的独立分析，部分引用编号可能与报告其他章节不连续，但均可在本报告末尾的完整参考文献列表中找到对应来源。

5.2. 表2：不同架构路线对LLM推理阶段的适配性

下表从八个核心维度，对当前市场主流 ASIC 路线进行系统性比较。

5.2.1. 表2：不同架构路线对 LLM 推理阶段的适配性

架构路线	Prefill 适配性	Decode 适配性	长上下文能力	MoE 支持	多模态支持	高并发能力	低延迟能力	大模型参数扩展
Groq LPU (SRAM-centric)	❌ 弱。NVIDIA Groq3 LPX 明确将 Prefill 卸载至 Rubin GPU；“无法以有竞争力的速度运行 prefill” [87]	★★★★★ 核心优势。150 TB/s SRAM 带宽，确定性执行，~10ms TTFT，300–1,300 tok/s [1294]	⚠️ 有限。长系统提示词会降低实际性能；Groq3 LPX 中长上下文 Prefill 由 GPU 处理 [1294]	✅ 在 Groq3 LPX 中 LPU 专门执行 MoE FFN/expert 部分 [143]	❌ 不支持。“无法用于计算机视觉或视频生成” [91]	⚠️ 中等。确定性延迟保证稳定性，但 API 速率限制（免费层 30 RPM）约束实际并发 [87]	★★★★★ 极致。P99 延迟在 median 的 15% 以内，确定性执行消除抖动 [1164]	⚠️ 需线性芯片扩展。70B 模型需 ~576 LPU，1T 参数需 4–8 个 LPX 机柜 [1286]
Cerebras WSE-3 (Wafer-scale)	❌ 弱。计算密集阶段不享受 SRAM 带宽优势；AWS 合作伙伴方案中将 Prefill 卸载至 Trainium [7]	★★★★★ 世界领先。2,000–3,000 tok/s 单用户，21 PB/s 聚合带宽 [12]	★★★★ 强。付费层支持 131K 上下文；近 50% 请求超 128K tokens [110]	★★★★★ 强。Llama 4 Maverick/Scout、DeepSeek R1、Qwen 3 MoE 均以创纪录速度服务 [253]	⚠️ 硬件支持但 API 受限。Llama 4 原生多模态，但公开 API 截至 2026 年中主要为纯文本 [124]	⚠️ 有限。Above ~8 并发用户，GPU continuous batching 可超越 WSE-3 [124]	★★★★★ 极致。Llama 405B 仅 240ms 延迟 [123]	★★★★★ 强。支持 24T 参数模型，可扩展至 2,048 CS-3 系统 [3]
Taalas HC1 (Model-specific ASIC)	⚠️ 仅支持固定 2K 上下文窗口内的 Prefill [31]	★★★★★ 极致速度。17,000 tok/s 单用户，但仅限 Llama 3.1 8B 单一模型 [70]	❌ 严重受限。6,144 token 硬上限，无法扩展 [31]	❌ 不支持。仅 Llama 3.1 8B 密集模型 [21]	❌ 不支持。单一模型硬编码 [21]	❌ 无。“不需要批处理查询”，单用户架构 [31]	★★★★★ 极致。复杂响应约 64ms 完成 [1691]	❌ 严重受限。815 mm² 逼近 reticle limit；70B+ 需 ~50 芯片且未经验证 [1696]
Etched Sohu (Transformer-specific ASIC)	★★★★ 强。吞吐机器，>90% FLOPS 利用率，固定功能 attention 电路 [45]	★★★ 中等。~1.4× H100 带宽优势，主要优势来自利用率而非带宽 [155]	⚠️ 未明确。144 GB HBM3E 理论上可支持，但无独立验证 [303]	❌ 基础版不支持。动态 expert routing 需单独 Sohu 变体芯片 [41]	❌ 不支持。无法运行视觉编码器、扩散模型、CNN/RNN/SSM [41]	★★★★ 强。8 芯片服务器 500K tok/s（自报），吞吐导向 [44]	⚠️ 非设计目标。可能存在 ~10s 级请求延迟，非低延迟产品 [44]	★★★ 中等。144 GB HBM3E 可容纳 Llama 70B FP8，但更大模型需多芯片 [303]
d-Matrix Corsair (DIMC/SRAM-centric)	❌ 不优化。GPU 处理 Prefill，Corsair 专注 Decode [214]	★★★★★ 核心优势。150 TB/s SRAM 带宽，2ms/token（Llama 70B），10× 快于 GPU 同场景 [210]	⚠️ 中等。256 GB LPDDR5 容量内存支持长上下文，但非主要设计目标 [238]	⚠️ 间接支持。DIMC 架构可处理 MoE FFN，但非主要卖点	⚠️ 未重点强调	★★★★ 强。面向交互式批量推理优化，“batched throughput” [1925]	★★★★★ 极致。1K prompt + 200 TPS 低于 10ms [218]	★★★ 中等。Capacity Mode 下支持 1T+ 参数模型，但延迟需权衡 [233]
SambaNova SN50 (Reconfigurable Dataflow)	❌ 卸载至 GPU。Intel 异构蓝图：B200/B300 处理 Prefill [2199]	★★★★★ 核心优势。数据流架构，500–600 tok/s/用户，3× B200 吞吐 [517]	★★★★★ 极致。最多 1000 万 token 上下文，三级存储体系（SRAM+HBM+DDR）[269]	★★★★★ 强。DeepSeek-R1 671B 在 16 SN40L 芯片上以 ~195 tok/s 运行，已验证 [4705]	★★★★ 支持。文本、图像、视频、音频多模态推理 [4699]	★★★★ 强。256 RDU/worker，32,768 横向扩展 [270]	★★★★★ 极低。数据流架构消除冗余数据移动，空冷高效 [278]	★★★★★ 强。支持 10T 参数模型 [269]
Google TPU v8i (Cloud in-house ASIC)	★★★★ 强。v6e 已支持 disaggregated prefill/decode（7× TTFT 改进）；v8i 专为推理优化 [344]	★★★★★ 强。CAE 引擎近零延迟聚合，384 MB 片上 SRAM 驻留 KV Cache，5× 集合通信延迟降低 [388]	★★★★★ 强。288 GB HBM3e + 384 MB SRAM，专为长上下文推理 KV Cache 设计 [389]	★★★★★ 强。Boardfly 拓扑减少 56% 网络直径专攻 MoE；CAE 替代 SparseCores 加速 expert 通信 [389]	★★★★ 支持。通过 JAX/PyTorch + vLLM 软件栈支持多模态模型	★★★★★ 极强。1,152 芯片 Pod，11.6 FP8 ExaFLOPS；vLLM continuous batching [341]	★★★★ 强。CAE 降低 on-chip collective latency 5×；Boardfly 减少 hops [392]	★★★★★ 极强。Pod 级共享内存模型，288 GB HBM3e/芯片 [341]
Microsoft Maia 200 (Cloud in-house ASIC)	★★★★ 强。10 PFLOPS FP4，216 GB HBM3e @ 7 TB/s，原生 FP8/FP4 tensor core [286]	★★★★ 强。272 MB 片上 SRAM + 数据移动引擎，7 TB/s HBM 带宽兼顾访存密集阶段 [287]	★★★★ 强。216 GB HBM3e 提供充足 KV Cache 空间；2.8 TB/s 双向 scale-up 带宽 [286]	★★★★ 支持。微软 MAI 模型采用 MoE 架构（35B active），硬件原生支持 [4602]	★★★★ 支持。通过 Azure AI 基础设施栈支持多模态 [4602]	★★★★★ 极强。6,144 加速器集群， intra-tray 全互联无交换机 [286]	★★★★ 强。可预测的高性能集合通信，专用 AI 传输协议 [286]	★★★★★ 强。“可轻松运行当前最大模型，并为未来更大模型预留充足空间” [286]
Meta MTIA 450/500 (Cloud in-house ASIC)	★★★★ 强。Disaggregated prefill/decode 架构，Prefill 独立硬件池 [348]	★★★★★ 核心优势。“推理优先”设计哲学，MTIA450 18.4 TB/s HBM 带宽，硬件 FlashAttention [348]	★★★★ 强。MTIA500 最多 512 GB HBM，硬件 FlashAttention 加速长上下文 attention [4562]	★★★★ 支持。硬件 MoE FFN 加速 [2679]	⚠️ 有限。聚焦推荐系统与 GenAI 文本推理，多模态非主要目标	★★★★★ 极强。72 加速器 scale-up domain，vLLM continuous batching + chunked prefill [4569]	★★★★ 强。Disaggregated 架构独立控制 TTFT 与 ITL [4571]	★★★★★ 强。HSTU GR 模型已达 1.5T 参数规模；MTIA500 30 PFLOPS MX4 [4561]

5.2.2. 维度解读与关键洞察

5.2.2.1. Prefill 与 Decode：一场正在制度化的”分工”

从上表可以清晰看出，没有任何一种架构路线能同时在 Prefill 和 Decode 两个阶段都取得五星评价。这并非偶然——而是由两个阶段的物理特性决定的：

• Prefill 本质是大矩阵乘法，计算密集、高度并行、对 batch size 友好。GPU/HBM 架构（NVIDIA H100/B200、Google TPU v8i、Microsoft Maia 200）天然适配。
• Decode 本质是逐 token 的权重流式读取，访存密集、对 batch size 不敏感、延迟敏感。SRAM-centric 架构（Groq LPU、d-Matrix Corsair、Cerebras WSE-3）天然适配。

这一分化正在被行业以 disaggregated inference 的形式制度化。截至 2026 年中期，已有至少四种明确的 disaggregated 部署方案进入生产或公测阶段：

方案	Prefill 硬件	Decode 硬件	状态
NVIDIA Groq3 LPX	Rubin GPU	Groq3 LPU (FFN/MoE)	2026 年下半年发布 [87]
AWS + Cerebras	Trainium	CS-3 (WSE-3)	2026 年 3 月 Amazon Bedrock 上线 [4371]
Intel + SambaNova	B200/B300 GPU	SN50 RDU	2026 年 COMPUTEX 演示，H2 2026 发货 [2193]
Meta MTIA 内部分离	计算优化池	带宽优化池	已生产部署 [348]

这意味着，未来 LLM 推理的硬件选型将不再是”选一颗芯片”，而是”选一对芯片组合”。对于表2而言，五星星级评价代表的是在 disaggregated 架构中该芯片在对应阶段的”分工适配度”，而非单芯片全面性。

5.2.2.2. 长上下文：SRAM 容量与 HBM 容量的博弈

长上下文推理的核心瓶颈是 KV Cache 存储。每 1K token 上下文在 70B 模型上约需 0.5–1 GB KV Cache 空间。不同架构路线的应对策略截然不同：

• SRAM-centric 路线（Groq LPU、d-Matrix Corsair）：片上 SRAM 带宽极高但容量极小（230 MB–2 GB），长上下文必须依赖 disaggregated 架构中 GPU 侧的 KV Cache 管理，或通过多芯片切分扩展。Groq3 LPX 中 LPU 不负责 attention/KV Cache，仅执行 FFN/MoE [87]。
• Wafer-scale 路线（Cerebras WSE-3）：44 GB 片上 SRAM 可容纳中等规模 KV Cache，已支持 131K 上下文 [110]。
• HBM 路线（GPU、TPU v8i、Maia 200、MTIA 500）：288–512 GB HBM 为 KV Cache 提供充足空间，是当前长上下文推理的最成熟方案。TPU v8i 特别将 384 MB 片上 SRAM 专门设计为 KV Cache 热数据驻留层 [389]。
• 激进路线（SambaNova SN50）：三级存储（SRAM + HBM + DDR）实现 1000 万 token 上下文，是目前公开宣称的极限 [269]。

值得关注的是，长上下文趋势正在同时放大 Prefill 和 Decode 的硬件需求：长 prompt 的 Prefill 计算量随序列长度二次增长（attention 部分），长输出的 Decode 则要求 KV Cache 容量线性增长。这意味着 disaggregated 架构中，Prefill 池和 Decode 池都需要为长上下文做针对性强化。

5.2.2.3. MoE（Mixture of Experts）：从”可选”到”必备”

截至 2026 年中，MoE 已成为前沿 LLM 的主流架构选择——Llama 4（Scout/Maverick/Behemoth）、DeepSeek R1/V3、Qwen 3-235B、GPT-OSS-120B、Gemini 3 均为 MoE 架构。不支持 MoE 的 ASIC 将直接被排除在下一代模型部署之外。

这一趋势对 ASIC 格局产生了深远影响：

• Etched Sohu 是最极端的反面案例：基础版 Sohu 完全无法运行 MoE 模型，需要单独设计一款 MoE 变体芯片——这恰恰暴露了固定功能 ASIC 在模型架构快速演变面前的脆弱性 [41]。
• Taalas HC1 同样被锁定：仅支持 Llama 3.1 8B 密集模型，在 MoE 浪潮中几乎无实际部署价值 [21]。
• Google TPU v8i 的 CAE 引擎是 MoE 推理硬件加速的标杆：专门为 expert dispatch/combine 和 all-to-all 通信设计了硬件加速单元，Boardfly 拓扑将 MoE 通信的网络直径减少 56% [389]。
• Groq3 LPU 在 MoE 中找到了最佳定位：LPU 不处理 attention（GPU 负责），专门执行 MoE 的 FFN/expert 计算——这正是 MoE 推理中访存最密集、受益于高 SRAM 带宽最多的部分 [143]。

5.2.2.4. 多模态：被忽视的”隐形杀手”

多模态（视觉-语言、视频-语言、音频-语言）正在成为 LLM 的标配能力，而非可选附加项。但这对 ASIC 架构提出了非平凡的挑战：

• 视觉编码器（ViT、CLIP 等）的计算模式与文本 Transformer 存在差异，且通常需要不同的精度和内存布局。
• 跨模态 attention 引入了额外的 KV Cache 维度和通信模式。
• 扩散模型（Stable Diffusion、Sora 等）的计算图与自回归 LLM 完全不同。

当前 ASIC 的多模态支持呈现明显分化：SambaNova SN50 和云厂商自研 ASIC（TPU v8i、Maia 200）通过软件栈实现多模态支持；Groq LPU、Etched Sohu、Taalas HC1 则明确不支持；Cerebras WSE-3 硬件支持但 API 尚未完全开放 [124]。对于企业级部署而言，如果推理平台不支持多模态，等于主动放弃了 AI 应用的下一个增长曲线。

5.2.2.5. 高并发 vs. 低延迟：一个”不可能三角”的体现

LLM 推理服务中存在一个根本性的权衡：高并发吞吐、低单请求延迟、低成本——三者难以同时最优。不同架构路线在这个三角中选择了不同的优化目标：

架构路线	优化目标	代价
Groq LPU / d-Matrix Corsair	极低单请求延迟 + 确定性	高并发吞吐受限（SRAM 容量约束）
Cerebras WSE-3	极低单请求延迟 + 极高单用户吞吐	高并发（>8 用户）被 GPU batching 反超 [124]
Etched Sohu	极高批量吞吐 + 低成本	单请求延迟可能较高（~10s）[44]
GPU (H100/B200)	高并发吞吐 + 灵活 batching	单请求延迟较高（200–500ms TTFT）[1294]
TPU v8i / Maia 200 / MTIA 500	平衡：中低延迟 + 高并发 + 可接受成本	自研芯片的生态锁定和供应链风险

对于实际部署而言，选择取决于业务场景：面向消费者的聊天机器人需要低延迟（Groq/d-Matrix/Cerebras），企业内部批量文档处理需要高吞吐（GPU/Etched Sohu），云服务商多租户平台需要平衡能力（TPU/Maia/MTIA）。

5.2.2.6. 大模型参数扩展：SRAM 路线的”阿克琉斯之踵”

SRAM-centric 架构（Groq LPU、d-Matrix Corsair）面临一个根本性的扩展悖论：片上 SRAM 容量与模型参数规模成正比扩展。一颗 Groq3 LPU 仅 500 MB SRAM，部署 70B 模型需要 576 颗芯片协同工作 [179]；部署 1T 参数模型则需要 4–8 个 LPX 机柜 [1286]。相比之下，HBM 方案（GPU、TPU、Maia）可以通过增加 HBM 堆栈来扩展单芯片模型容量，成本曲线更平缓。

Cerebras WSE-3 的 wafer-scale 方案在单芯片上拥有 44 GB SRAM，是 SRAM-centric 路线中容量最大的——但仍不足以容纳 70B 模型的完整权重（FP8 约 70 GB），需要跨 CS-3 系统流水线分布 [1647]。

SambaNova SN50 的三级存储（SRAM + HBM + DDR）提供了最灵活的扩展方案，通过将冷权重存放于 DDR、热权重加载至 HBM、KV Cache 驻留 SRAM，实现了 10T 参数模型的支持 [269]。这一混合层级设计可能是未来 LLM 推理 ASIC 的主流方向。

5.2.3. 小结

表2 揭示了一个核心结论：LLM 推理硬件市场正在从”通用芯片适配所有阶段”向”专用芯片分工协作”演进。在这一演进中：

• SRAM-centric 和 Wafer-scale 架构在 Decode 阶段建立了难以撼动的低延迟优势，但 Prefill 和模型扩展性是其短板。
• HBM-based 架构（GPU 和云厂商自研 ASIC）在 Prefill、长上下文、高并发、模型扩展性上保持综合领先，但单请求延迟难以与 SRAM 方案竞争。
• 固定功能 ASIC（Etched Sohu、Taalas HC1）在特定场景下可达到极致效率，但模型架构锁定风险在 MoE 和多模态浪潮中被急剧放大。
• Disaggregated inference 正在成为行业共识，这意味着未来的竞争不再是”谁的单芯片最强”，而是”谁的芯片组合和互联方案最优”。

5.3. 小结：不同路线的“最佳战场”与核心结论

路线	最优战场	不擅长的事
NVIDIA GPU/HBM	训练、高吞吐batch推理、多模型混合部署、需要频繁迭代的研发场景	极致低延迟单用户decode（不如SRAM ASIC）
SRAM-centric ASIC	低延迟decode、实时交互、agentic workflow、语音助手	训练、prefill、高并发batch推理、大模型单芯片部署
Wafer-scale ASIC	超低延迟大模型推理、单用户高吞吐、实时coding assistant	高并发多租户、训练、MoE/多模态
Transformer-specific ASIC	大规模单一模型（如8B）的超低成本推理	模型架构变化、MoE、多模型部署、训练
Cloud in-house ASIC	云厂商自有大规模推理负载、成本敏感型内部workload	对外销售、通用AI加速、非自有生态的多样化负载

核心结论：不存在“唯一正确的路线”。 LLM推理的workload本身正在分化——prefill和decode、batch推理和实时交互、短文本和长上下文——这些场景对硬件的需求截然不同。NVIDIA已经率先拥抱异构计算：通过收购Groq，将LPU整合进Rubin平台，打造”GPU做prefill + LPU做decode”的disaggregated architecture [97]。这不再是”谁取代谁”的问题，而是”谁在哪个位置不可替代”的问题。未来的数据中心很可能是一个异构计算池：GPU做prefill和训练，SRAM ASIC做实时decode，wafer-scale做超大模型低延迟推理，云厂商ASIC做内部标准化负载。赢家不是某一种芯片，而是能整合多种芯片的系统级方案。

6. 推演与结论

6.1. 各家核心优势与短板总评

经过前述对独立商用芯片与云厂商自研芯片共十家参与者的逐项深度剖析，本小节将汇总各家在 LLM 推理场景中的核心竞争力与关键短板，以多维对比表格配合定性判断，形成整体图景。

---

6.1.1. 总览：多维雷达对比表

评分说明：★ = 严重不足 / 不适用；★★ = 有明显短板；★★★ = 行业平均；★★★★ = 较强；★★★★★ = 行业领先。为避免横向表格过宽，下表拆为“技术与生态”与“工程与商业化”两部分；未量产产品按公开信息折现评估，标注「^」表示不确定性较高。

6.1.1.1. 技术与生态

维度	NVIDIA GPU/HBM 路线	SRAM-centric ASIC	Wafer-scale ASIC	Transformer-specific ASIC	Cloud in-house ASIC
代表玩家	H200 / B200 / GB200 / Rubin	NVIDIA Groq3 LPU、d-Matrix Corsair	Cerebras WSE-3	Etched Sohu、Taalas HC1	Google TPU、Maia、MTIA
灵活性	★★★★★ 最高：通用可编程，兼容训练、推理、微调与新架构演进	★★☆☆☆ 较低：以 decode 优化为主，模型与编译器约束明显	★★☆☆☆ 较低：推理专用，支持模型族有限，MoE/多模态弹性不足 [124]	★☆☆☆☆ 极低：架构强绑定 Transformer 或单一模型，最怕模型范式切换 [1649]	★★★☆☆ 中高：TPU 通用性最好，Maia/MTIA 更偏内部负载优化
性能上限	★★★★★ 最高且持续上行：B200、GB200 已建立吞吐优势，Rubin 仍在抬升上限 [4755][4778][4861]	★★★☆☆ 中高：decode 极强，但系统级性能依赖大规模组网；d-Matrix 仍需与 GPU 配合 [167][3901]	★★★★☆ 高：单用户 tok/s 与低延迟突出，但大模型常需多 CS-3 堆叠 [253][121]	★★★☆☆ 潜力高但未证实：Sohu 与 HC1 的亮眼数字仍主要来自厂商口径 [55][21]	★★★★☆ 高且追赶快：TPU、Maia、MTIA 在内部场景已逼近一线水平 [397][2660][2539]
软件生态	★★★★★ 绝对壁垒：CUDA、TensorRT-LLM、vLLM、SGLang 全栈最成熟 [4995]	★★☆☆☆ 薄弱：Groq 与 d-Matrix 均依赖自有编译器 / SDK，迁移与调优成本偏高	★★☆☆☆ 薄弱：自有编译栈较封闭，Hugging Face 兼容度有限	★☆☆☆☆ 近乎空白：Etched 缺少公开 SDK，Taalas 更接近“模型即芯片”交付 [159]	★★★☆☆ 分化明显：TPU 生态最成熟，Maia/MTIA 仍以自有栈为主
单 token 成本	★★★★☆ 快速下探：单位 token 成本持续下降，但硬件采购与部署成本仍高 [1449][4900]	★★★★☆ 有竞争力：Groq API 与 d-Matrix 的 decode 成本具吸引力，但适用场景较窄 [4792][1982]	★★★☆☆ 中等：服务成本不差，但整机价格高，大模型往往需要多系统	★☆☆☆☆ 难判断：缺少真实出货与定价，成本优势基本停留在宣称层面 [41][29]	★★★★★ 最优于内部场景：核心优势是省去 GPU 溢价，在自有负载上兑现 perf/$ [1244][358][298]
能耗	★★★☆☆ 绝对功耗高，但 tokens/watt 仍在快速改善 [4755]	★★★★★ decode 能效最佳：SRAM 路线在 memory-bound 场景有物理优势 [1330][81]	★★★★☆ 优秀：系统级效率强，但单节点功耗与散热要求并不低 [1667][18]	★★★★☆ 理论值亮眼，但缺少独立第三方功耗验证	★★★★☆ 良好：云厂商 ASIC 通常在 perf/watt 上优于通用 GPU [795][2539][4562]
适应模型变化能力	★★★★★ 最强：从 CNN、Transformer 到 SSM 与未来新架构均可承接	★★☆☆☆ 偏弱：围绕 decode 做硬件 / 编译器定制，遇到新范式需要重做适配	★★☆☆☆ 偏弱：模型族支持面仍窄，新架构兼容性一般	★☆☆☆☆ 最弱：最容易被 MoE、多模态和新算子打穿 [1649]	★★★☆☆ 中等：能随内部负载快速迭代，但对外泛化能力有限

6.1.1.2. 工程与商业化

维度	NVIDIA GPU/HBM 路线	SRAM-centric ASIC	Wafer-scale ASIC	Transformer-specific ASIC	Cloud in-house ASIC
供应链韧性	★★☆☆☆ 风险高：高度依赖 TSMC CoWoS 与 HBM，先进封装仍是关键瓶颈 [872][4974]	★★★★☆ 较强：Groq 与 d-Matrix 都在主动规避 HBM / CoWoS 约束 [81][215]	★★★★☆ 较强：不依赖 HBM，但晶圆级制造本身是另一种高门槛风险 [111]	★★★☆☆ 中等：Sohu 仍受 HBM / CoWoS 影响，Taalas 供应链透明度不足 [47]	★★★☆☆ 中等：同样吃先进节点与 HBM，但可凭云厂商体量锁定供给 [3692]
量产/部署	★★★★★ 最成熟：量产、渠道、云供给与工程经验都已成体系	★★★★☆ 已进入落地期：Groq 依赖平台化交付，d-Matrix 已量产出货 [3899]	★★★★★ 已部署：CS-3 与云服务都已有真实生产落地	★☆☆☆☆ 很弱：Sohu 未量产，HC1 仍偏 demo / 概念验证 [44]	★★★★★ 内部落地最强：TPU、Maia、MTIA 都基于自有云或自有负载部署
部署难度	★★★★☆ 最低：OEM / ODM 与云租用链路成熟，但高功耗机型往往要求液冷	★★★☆☆ 中等：Groq 需大规模组网，d-Matrix 形态更友好但仍需异构协同 [87][215]	★★★☆☆ 中等：系统级交付降低了门槛，但大模型常需多机扩展	★★☆☆☆ 高：Sohu 未量产，Taalas 需围绕客户与模型定制部署 [44]	★★★★☆ 低：内部部署最顺畅，但外部客户几乎无直接导入空间
商业化可行性	★★★★★ 已验证：市场、渠道、软件、服务体系最完整	★★★★☆ 明显抬升：Groq 获得 NVIDIA 平台入口，d-Matrix 已量产，但独立商业化深度仍待继续验证 [76][3899]	★★★☆☆ 谨慎乐观：已有重量级合同，但客户集中度仍是核心风险 [1079]	★☆☆☆☆ 很低：Sohu 长期未出货，HC1 仍在概念验证阶段 [44][64]	★★★★★ 已证明：关键不在对外卖卡，而在内部 ROI 与规模化复用 [1243][358][2533]
客户多样性	★★★★★ 最高：云、企业、研究机构、初创公司全覆盖	★★☆☆☆ 有限：目前仍集中在少数场景与少数早期采用者	★★☆☆☆ 有限：订单质量高，但客户基数不大	★☆☆☆☆ 极低：尚未形成真实客户面	★★★★★ 很高但以内部为主：客户多样性体现在云厂商自有业务线，而非外部市场

---

6.1.2. 各家核心优势与短板逐项评述

6.1.2.1. Groq LPU / NVIDIA Groq 3 LP30

核心优势：在 LLM decode 阶段的延迟与确定性上，LPU 至今仍是无可争议的王者。SRAM-centric 架构带来的 ~150 TB/s 片上带宽（Groq 3）、确定性 VLIW 静态调度，使其在单用户 token generation 速度上碾压 GPU——Llama 3.3 70B 达到 241 tok/s，远超任何 GPU 服务商 [1]。2025 年 12 月被 NVIDIA 以 $20B 非排他授权协议收入麾下后，LPU 作为 Vera Rubin 平台的 decode 协处理器重新定位，填补了 NVIDIA 自身 GPU 在 decode 低延迟场景的天然短板，形成 disaggregated inference（Rubin 做 prefill + LPU 做 decode）的完整闭环 [2]。

关键短板：SRAM 容量是根本性制约。即使 Groq 3 的 500 MB SRAM 也远不足以驻留任何现代 LLM，运行 Llama 2 70B 需要 ~576 个 LPU 级联，使得”芯片”本质上是”整机柜”——硬件 CapEx 据测算约 40× 等效 GPU [4]。被 NVIDIA 整合后，LPU 丧失了独立路线图的话语权，长期演进方向取决于 NVIDIA 的平台战略而非独立优化。此外，LPU 不支持训练，不支持非 Transformer 架构的快速适配，模型目录仅限于开源模型 [5]。

一句评：decode 延迟的终极武器，但 SRAM 容量天花板决定了它只能是 GPU 的”僚机”而非”主机”。

---

6.1.2.2. Cerebras WSE-3

核心优势：晶圆级引擎的物理极致——44 GB 片上 SRAM 配合 21 PB/s 带宽，约 7,000× H100 的 HBM 带宽，是当前所有 AI 芯片中片上数据搬运能力最强的架构 [6]。这在 LLM 推理中直接转化为业界最快的单用户 token 生成速度：Llama 4 Maverick（400B）达到 ~2,500 tok/s/user，是 NVIDIA DGX B200 的 2× 以上 [7]。OpenAI 签下 $20B+ 的三年采购协议、AWS Bedrock 集成 Cerebras 做 decode——这两个信号证明其商业化路径已获得顶级客户的生产级验证，而非停留在 benchmark 层面 [8]。

关键短板：44 GB SRAM 的”甜蜜区”一旦溢出到外部 MemoryX，21 PB/s 的带宽优势就瞬间崩塌为 ~150 GB/s 的外部 I/O 瓶颈 [10]。每节点 ~$3M 的价格、23–25 kW 的功耗、需要定制液冷——这些使 WSE-3 只能服务金字塔尖的 hyperscaler 客户 [11]。晶圆级制造的良率风险是结构性的：一个缺陷可毁掉整张晶圆，冗余设计增加成本和复杂度 [12]。此外，2025 年 86% 的收入来自阿联酋两个实体（MBZUAI 和 G42），OpenAI 大单虽然分散了集中度，但本质上是”从一个巨鲸换成另一个巨鲸” [13]。

一句评：片上带宽的绝对王者，但 44 GB 的”玻璃天花板”和 $3M/节点的门票，让它注定是少数人的武器。

---

6.1.2.3. Taalas HC1

核心优势：将模型权重直接”烧录”进硅片的 Mask ROM 路线，在特定模型上实现了令人瞠目的效率——Llama 3.1 8B 单卡 17,000 tok/s、200W 功耗，能效比在当前所有已公开芯片中名列前茅 [14]。这种”模型即芯片”的哲学，在模型固定、部署规模极大、对延迟极度敏感的场景（如大规模客服机器人、特定企业内部模型）中，理论上具有无可匹敌的单位 token 成本优势。$219M 的融资（含 Fidelity 参与）和 TSMC 6nm 工艺的选用，说明资本市场愿意为这个极端路线下注 [15]。

关键短板：模型专用性是一把致命双刃剑。HC1 只能运行 Llama 3.1 8B——不能跑 GPT-4、Claude，甚至不能跑 Llama 3.2。一旦模型更新，需要重新流片，而流片周期（即使 Taalas 宣称可缩短至数月）与模型迭代速度（前沿模型每 3–6 个月一更）之间存在根本性矛盾 [16]。24 人团队 vs. 万亿晶体管芯片设计之间的张力、商业化路径的模糊（是卖卡还是卖 API？）、客户对”模型-硬件锁定”的本能抗拒——都让 HC1 更像一个令人尊敬的技术探索，而非可持续的商业产品。Taalas 自己也将其定位为”技术演示器” [17]。

一句评：极致的专用化带来极致效率，但也意味着极致的脆弱——当模型更新速度超过芯片流片速度，商业模式就岌岌可危。

---

6.1.2.4. Etched Sohu

核心优势：如果 Sohu 能兑现其宣称的性能——500K+ tok/s 的 Llama 70B 推理、8 芯片服务器替代 160 个 H100——那么它将是 Transformer 推理领域最具颠覆性的产品。$1B 级别的融资（含 Peter Thiel、Stripes 等顶级投资者）和$5B 估值，说明资本对其”All-in Transformer”赌注的认可 [18]。TSMC 4nm + HBM3E 的工艺选择在技术上是合理的，可以规避 SRAM 容量不足的问题。

关键短板：截至 2026 年 6 月，Sohu 没有公开确认的流片、没有硅片、没有任何第三方 benchmark。 所有性能数据均来自 Etched 对投资者的受控演示 [19]。原定 2024–2025 年的出货窗口已错过，最早交付时间已滑至 2027 年 [20]。与此同时，NVIDIA Blackwell 已大规模出货、Cerebras WSE-3 已服务 OpenAI 生产负载、Groq LPU 已被 NVIDIA 整合——Sohu 的窗口期正在迅速关闭。Transformer-only 的架构锁定意味着：一旦 AI 架构出现重大范式转移（如 SSM、混合注意力、或者 Transformer 本身的重大变体），Sohu 可能成为一块昂贵的硅镇纸。$5B 估值在零收入、零硅片的前提下，隐含了极高的执行风险溢价。

一句评：最激进的架构赌注，配上最漫长的交付延迟——在 AI 硬件这个”快鱼吃慢鱼”的市场，Sohu 正在从先驱变成旁观者。

---

6.1.2.5. d-Matrix Corsair

核心优势：Corsair 是当前独立 ASIC 创业公司中量产进度最扎实的之一——2026 年 6 月全面量产，通过 Supermicro 渠道出货 SquadRack 整机柜方案 [21]。其数字存内计算（DIMC）+ SRAM 架构在 decode 阶段的低延迟表现已经被 Gimlet Labs 独立验证：将基线 24 秒的响应时间压缩至不到 2 秒 [22]。供应链策略尤其聪明：TSMC N6（成熟节点，不抢先进产能）、有机基板（不用 CoWoS）、LPDDR5（不用 HBM）——三个关键选择使其在 2025–2026 年的全球芯片短缺中保持了供应链韧性 [23]。与 GPU 的”异构配合”定位（GPU 做 prefill，Corsair 做 decode）降低了客户导入的心理门槛——不是”替换 GPU”，而是”增强 GPU 舰队”。

关键短板：SRAM 容量再次成为限制——Corsair 无法服务超大参数量的推理模型，斯坦福 Rick Bahr 教授也明确指出这一点 [24]。客户名称至今未公开，实际部署规模和收入质量无法验证。$2B 的估值在 Cerebras（~$23B IPO）和 Groq（$20B 被收购）的映衬下显得”小而美”，但这也意味着资源有限，难以支撑多代芯片的快速迭代。NVIDIA 收购 Groq 后，在 SRAM-based decode 加速器领域形成了”免费 + 平台绑定”的竞争格局，对 d-Matrix 的独立商业化构成直接挤压。

一句评：最务实的 SRAM 推理芯片——量产了、验证了、供应链稳了，但”小池塘里的大鱼”能否在 NVIDIA 鲸吞 Groq 后继续游下去，是个开放问题。

---

6.1.2.6. SambaNova SN50

核心优势：在所有独立 ASIC 中，SambaNova 的三层混合存储架构（432 MB SRAM + 64 GB HBM2E + 256 GB–2 TB DDR5） 是最接近”通用推理平台”理想的方案，同时兼顾了 SRAM 的低延迟、HBM 的大带宽和 DDR 的大容量 [25]。这使得 SN50 可以支持 10T+ 参数模型和 10M+ token 上下文——这正是 Cerebras 和 Groq 的 SRAM-only 路线无法触及的领地 [26]。Intel 的战略合作（$35M 投资 + 联合异构推理架构）和 SoftBank 的首发部署，为其提供了可观的生态背书和初始订单 [27]。可重构数据流架构对模型变化的适应性，远优于 Taalas 的”烧录”路线和 Etched 的 Transformer 锁定。

关键短板：SN50 要到 2026 H2 才开始出货，意味着截至目前所有性能数据都是厂商宣称，未经第三方大规模验证。Intel 收购谈判在 2025 年底破裂（$1.6B 估值），反映了市场对其独立生存能力的疑虑 [29]。SambaNova 的软件栈（SambaFlow 数据流编译器）虽然功能强大，但学习曲线陡峭，与 CUDA 生态的兼容性远不如 NVIDIA 路线。此外，SN50 的”瑞士军刀”定位在成本上可能不如专用芯片极致——既要做大模型、又要长上下文、又要低延迟，每一个维度都面临更专注对手的竞争。

一句评：最接近”通用推理 ASIC”的产品——能跑大模型、能扛长上下文、能换模型，但”全能”也意味着在每个单项上都不是最极致的。

---

6.1.2.7. Google TPU（v7 Ironwood / v8i Zebrafish）

核心优势：Google TPU 是当前唯一在系统级规模上能与 NVIDIA GPU 正面对抗的 AI 加速器平台。Ironwood 的 9,216 芯片 Superpod（42.5 EFLOPS FP8）、v8i 的 9,600+ 芯片 Virgo 织物、光学电路交换（OCS）实现近线性扩展——这些是 NVIDIA 目前 NVL72 之后落入 InfiniBand 瓶颈时无法匹敌的能力 [30]。v8i Zebrafish 专门引入的 Collectives Acceleration Engine（CAE），将片上集合通信延迟降低 5×，直接针对 agentic AI 时代数千次小工具调用的采样瓶颈，这是目前所有 ASIC 中最具前瞻性的推理专用硬件创新 [32]。Anthropic 承诺最高 100 万 Ironwood TPU，Midjourney 迁移后推理成本降低 65%——这些都是经过生产验证的 TCO 优势 [33]。

关键短板：CUDA 生态的鸿沟仍然是 TPU 最大的外部采用障碍。虽然 PyTorch/XLA 和 vLLM-on-TPU 已取得长足进步，但与 NVIDIA 15 年积累的 CUDA 生态（cuDNN、TensorRT-LLM、数千个预优化 kernel）相比，TPU 的开发者体验、社区支持和第三方库覆盖仍然有显著差距 [34]。GCP 独占意味着无法满足多 cloud 或 on-prem 部署需求，对许多企业客户形成不可接受的 vendor lock-in。v8i 的外部客户可用要等到 2027 年底，而 Vera Rubin 的 HBM4 + NVLink 6 可能在 2026 H2 就重新夺回性能优势 [35]。

一句评：唯一能在系统级挑战 NVIDIA 的完整平台，但”Google-only”的围墙花园既是其垂直整合的优势，也是其市场渗透的天花板。

---

6.1.2.8. Microsoft Maia 200

核心优势：Maia 200 是云厂商自研 ASIC 中最”暴力”的推理芯片——TSMC 3nm、140B 晶体管、10 PFLOPS FP4、216 GB HBM3e @ 7 TB/s、272 MB 片上 SRAM [36]。在纸面规格上，它在 FP4 性能上超过 Amazon Trainium 3 的 3×、在 FP8 性能上超过 Google TPU v7 [37]。更重要的是，Maia 200 已经在 Azure 上实际服务 GPT-5.2 的推理工作负载，并提供了 30% 的性能/美元提升 [38]。Maia 200 的 SDK 原生支持 PyTorch 和 Triton，这极大降低了从 CUDA 生态迁移的门槛——微软显然吸取了第一代 Maia 100 软件生态不成熟的教训 [40]。6,144 芯片的 Ethernet-based scale-up 集群，使其在推理扩展性上具备与 TPU Pod 对标的潜力 [41]。

关键短板：Maia 200 是微软的第二代产品，但在推理芯片领域仍是”新兵”——与 Google TPU 历经 8 代迭代的成熟度无法相提并论。Azure 独占意味着与 TPU 一样面临 vendor lock-in 问题，虽然 Azure 的市场份额比 GCP 更大，但多 cloud 趋势下这仍然是一个限制。Maia 200 目前聚焦推理，微软在训练侧仍然重度依赖 NVIDIA，这意味着 Maia 无法形成类似 TPU 的”训推一体”闭环。此外，Maia 200 的硬件细节（如计算单元微架构、片间互联协议）公开程度远低于 Google TPU 和 NVIDIA GPU，独立评估其性能声明的难度较大。

一句评：规格最”凶残”的推理 ASIC，已经服务 GPT-5.2 生产流量——但”第二代”的成熟度 vs.”第八代”的 TPU，差距不仅在硬件上。

---

6.1.2.9. Meta MTIA

核心优势：Meta 的 MTIA 路线图展示了全行业最激进的迭代速度——24 个月内推出 4 代芯片（MTIA 300/400/450/500），从推荐系统推理扩展到 GenAI 推理和推荐系统训练 [42]。这种”小步快跑”的策略源于 Meta 的独特优势：拥有全球最大的推荐系统推理负载（Facebook、Instagram 的广告和内容排序），可以在自研芯片上做真正 workload-driven 的优化，而非像独立 ASIC 公司那样猜测市场需求 [43]。MTIA 已经在大规模生产环境中证明了其价值——Meta 的广告系统推理成本显著降低，这是任何 benchmark 无法替代的真实验证 [44]。与 Broadcom 的合作关系使 MTIA 获得了成熟的 ASIC 设计能力，同时保持了 Meta 对架构方向的控制权。

关键短板：MTIA 的DNA 是推荐系统，不是 LLM。在通用 LLM 推理上，MTIA 落后 TPU v6 约 30–40% [45]。MTIA 不对外销售，这意味着它永远无法像 NVIDIA GPU 或 Google TPU（通过 GCP）那样形成外部生态和规模效应。Meta 的芯片团队规模和技术积累与 Google TPU 团队（10+ 年历史）相比仍有差距。MTIA 的快速迭代策略虽然灵活，但也意味着每一代芯片的生命周期很短，可能无法形成足够深厚的技术积累来支撑未来的训练芯片。

一句评：“自家的刀，削自家的苹果”——MTIA 在 Meta 的推荐系统推理上无可替代，但离通用 LLM 推理芯片还有不小的距离。

---

6.1.2.10. OpenAI / Broadcom “Titan”

核心优势：OpenAI 自研 ASIC 的战略动机是当前所有芯片项目中最清晰的：降低 token 成本、保障算力供应、实现硬件-模型协同优化、摆脱对 NVIDIA 的单一供应商依赖。与 Broadcom 的合作（ASIC 设计 + IP 库）、TSMC N3 工艺、Samsung HBM4 独家供应协议——这一组合在技术选型上高度合理 [46]。OpenAI 计划部署 10 GW 的 Titan 推理算力，与现有的 NVIDIA（10 GW）和 AMD（6 GW）形成三足鼎立，这一规模足以支撑自研芯片的 NRE 摊销 [48]。

关键短板：Titan 至今没有公开的架构细节、性能数据或硅片验证。 所有信息均来自供应链泄露和 Broadcom 财报电话会议中的间接提及。最早部署时间为 2027 年，这意味着 OpenAI 在 2026–2027 年仍将重度依赖 NVIDIA 和 Cerebras [49]。第一代 ASIC 的”踩坑”成本是不可避免的——Google TPU v1 用了近 3 年才达到生产级成熟度，Amazon Trainium 第一代也经历了漫长的爬坡。OpenAI 并非芯片公司，其核心竞争力是模型而非硅设计——这决定了 Titan 本质上是一个”外包设计 + 内部定义规格”的项目，与 Google TPU（内部全栈团队）的深度不可同日而语。此外，TSMC N3 的产能竞争极度激烈（Apple、NVIDIA、MediaTek 都是更大的客户），Titan 的产能保障存在不确定性 [50]。

一句评：逻辑上最合理的自研 ASIC 故事——但”2027 年才能见分晓”意味着，在 AI 推理硬件的窗口期争夺战中，Titan 的入场时间可能是最晚的。

---

6.1.3. 综合判断：三类玩家，三种命运

将十家参与者按商业模式和战略逻辑分类，可以归纳出三种截然不同的命运轨迹：

类型	代表	核心逻辑	最大优势	最大风险	5年生存概率判断
云厂商自研 ASIC	Google TPU、Microsoft Maia、Meta MTIA、OpenAI Titan	降低内部 token 成本，不依赖对外销售	真实负载驱动优化、垂直整合、无销售压力	外部生态缺失、技术路线受制于内部决策	极高（有母体养着）
已被整合的独立 ASIC	Groq LPU（归入 NVIDIA）	技术被平台巨头吸收，成为其产品矩阵的一部分	获得平台级生态和分销能力	丧失独立路线图、可能被边缘化	中高（取决于整合效果）
独立生存的 ASIC 创业公司	Cerebras、d-Matrix、SambaNova、Taalas、Etched	以差异化架构切入推理市场，独立商业化	架构创新自由度、潜在的高回报	客户导入、软件生态、多代芯片迭代的资金压力	分化严重（Cerebras 较高，Etched/Taalas 存疑）

核心判断：

1. 云厂商自研 ASIC（Google TPU、Microsoft Maia、Meta MTIA）将是最大的赢家群体。他们不需要在公开市场上击败 NVIDIA，只需要在内部负载上实现比采购 GPU 更低的单位 token 成本。Google TPU 已经走通了这条路，Maia 200 正在快速跟进，Meta MTIA 在推荐系统推理上同样证明了 ROI。OpenAI Titan 虽然来得最晚，但其推理需求规模（全球最大 LLM 推理客户之一）本身就足以支撑自研芯片的商业合理性。

2. 独立 ASIC 创业公司的生存窗口正在收窄。NVIDIA 收购 Groq 是一个标志性事件——它表明即使是最成功的独立推理 ASIC，最终也可能被平台巨头吸收。Cerebras 凭借 OpenAI 大单和 AWS 集成获得了独特的”准平台”地位，但 d-Matrix、SambaNova 仍需在 NVIDIA 的阴影下证明独立商业化的可行性。而 Taalas 和 Etched 的极端路线，在当前阶段更像是”技术期权”而非确定的商业产品。

3. 最终赢家可能不是卖芯片的，而是卖 token 服务的。Cerebras 通过 Cerebras Cloud 卖 token、Groq 通过 GroqCloud 卖 token、SambaNova 通过 SambaCloud 卖 token——这个模式的内在逻辑是：客户买的不是芯片，而是”更便宜、更快的 token”。如果能绕开芯片销售中的客户导入、软件迁移、供应链管理等环节，直接提供 API 级别的推理服务，独立 ASIC 公司可能找到一条更轻的变现路径。

4. 异构计算是共识，disaggregated prefill/decode 是方向。NVIDIA（Rubin + LPU）、Intel + SambaNova（GPU + RDU）、d-Matrix + Gimlet Labs（GPU + Corsair）、AWS（Trainium + Cerebras）——几乎所有的行业参与者都在走向”GPU 做 prefill、ASIC 做 decode”的异构架构。这不是偶然，而是 LLM 推理两个阶段截然不同的计算特征所决定的必然结果。未来不会有一个芯片”通吃”所有推理场景，而是不同芯片在 disaggregated pipeline 中各司其职。

---

6.2. 未来 LLM 推理专用 ASIC 技术演进方向

物理约束不会消失，它们只会改头换面，从一处瓶颈迁移到另一处瓶颈。理解这些约束的迁移路径，是预判下一代架构走向的关键。

基于前文对各家芯片的深度剖析，我们在此推演未来 3–5 年 LLM 推理专用 ASIC 的五大核心技术演进方向。这些方向并非孤立的技术选择，而是由内存墙、光罩极限、SRAM 微缩停滞、热密度、HBM 供应链等物理约束共同驱动的必然趋势。

---

6.2.1. SRAM 与 HBM 的长期竞争：从替代到混合

6.2.1.1. SRAM 的困境：工艺微缩之墙

SRAM 长期以来是片上存储的黄金标准，但它在先进制程上的微缩几乎撞上了物理极限。TSMC N3 节点的 SRAM 位单元面积（0.021 µm²）与 N5 完全相同，N3B 仅实现了约 5% 的微缩 [3181]。这让 SRAM 在芯片面积中的占比越来越大，成本飙升。

好消息是 TSMC N2 节点（纳米片晶体管 GAA）终于打破了这一僵局：HD SRAM 位单元面积缩小至约 0.0175 µm²，密度达到 38 Mb/mm²，较 N3 提升约 18% [3177]。但即便如此，SRAM 的微缩速度仍远落后于逻辑晶体管（N5→N3 逻辑密度提升约 1.6×），SRAM 的绝对成本仍居高不下——约 $1/MB，是 HBM 的约 100 倍，是普通 DRAM 的约 1000 倍 [5406]。

6.2.1.2. HBM 的狂飙：容量与带宽的军备竞赛

HBM 代际演进速度惊人：HBM3E 12Hi 已量产并成为 2025 年主流，单栈带宽达 6.0 TB/s，容量 192 GB；HBM4 16Hi 将于 2026 年量产，单栈带宽 2.0 TB/s，容量 48–64 GB [892]。但 HBM 的代价同样惊人：每 GB HBM 消耗约 4 倍标准 DRAM 的晶圆产能，2026 年 HBM 产能已被 100% 预订 [1225]。DRAM 价格自 2025 年初已翻倍 [1225]。

6.2.1.3. 为什么”纯 SRAM”和”纯 HBM”都不是最优解

纯 SRAM 方案（Groq LPU、Cerebras WSE）的致命伤是容量——230 MB SRAM 只能装下约 1/100 的模型参数，需要数百颗芯片拼出大模型，芯片间通信开销成为新瓶颈 [147]。黄仁勋在 CES 2026 直截了当地指出：“如果一切都能装进 SRAM，那确实不需要 HBM，但问题是这会使模型尺寸缩小约 100 倍” [5406]。

纯 HBM 方案（NVIDIA GPU、Google TPU）的瓶颈是带宽效率——Decode 阶段每 token 需从 HBM 读取全部权重，但实际能利用的带宽仅约 70%（MBU），大量算力闲置 [5407]。H100 的 3.35 TB/s HBM 带宽在 Decode 场景下，理论最大吞吐量仅约 50 tok/s（Llama 70B FP16），而实际通常更低。

6.2.1.4. 混合内存层级：正在成为主流范式

行业正在收敛到 SRAM + HBM + 大容量 DDR/PCIe 扩展 的三级存储体系：

• L1：SRAM 缓存/暂存区——存放当前 token 的 KV Cache 热点、attention 中间结果。Google TPU v7 Ironwood 片上 SRAM 达 384 MB（较上代 3 倍）[634]，明确为 KV Cache 驻留设计。
• L2：HBM——存放模型权重和活跃 KV Cache 页。仍是当前数据中心推理芯片的标配。
• L3：DDR/LPDDR/PCIe 扩展内存——存放冷 KV Cache 页、历史对话上下文；在跨节点场景下，也可以通过 RDMA 访问远端容量池。

d-Matrix Corsair 的 SRAM (2GB) + LPDDR5 (256GB) 混合架构在此方向上走得更激进：SRAM 提供 150 TB/s 带宽用于频繁访问的权重和 KV Cache，LPDDR5 提供 400 GB/s 容量层用于冷数据，避免了对昂贵 HBM 封装的依赖 [4653]。其下一代产品 Pavehawk/Raptor 更进一步，采用 3D 堆叠 DRAM 直接置于逻辑芯片下方，号称 10 倍于 HBM4 的带宽和能效 [484]。

SambaNova SN50 则采用了 64GB HBM + 432MB SRAM + 256GB~2TB DDR5 的三级架构，支持 10 万亿参数模型和 1000 万 token 上下文 [284]。

6.2.1.5. 趋势判断：SRAM/HBM 配比将按 workload 分化

我们预判，未来 3–5 年不会出现”SRAM 取代 HBM”或反之的单一结局，而是出现一个按 workload 特征分化的配比谱系：

场景	推荐配比	代表方案
训练	大 HBM（>80 GB）+ 中等 SRAM 缓存	NVIDIA B200/Rubin、Google TPU
通用推理（高并发）	大 HBM + 大 SRAM Cache	NVIDIA Rubin、Google TPU v8i
极致低延迟 Decode	超大 SRAM + 无/小 HBM	Groq LPU、Cerebras WSE
成本优先推理	中 SRAM + LPDDR5/DDR5 + 无 HBM	d-Matrix Corsair、SambaNova SN50
模型专用极致推理	权重硬编码入硅片 + 无 HBM	Taalas HC1

---

6.2.2. 近存计算与存内计算：从实验室到量产的关键转折

6.2.2.1. 为什么需要近存计算

LLM 推理的数据搬运能耗远超计算能耗。以 Decode 阶段为例，每生成一个 token 需要从内存读取全部模型权重（70B 模型约 140 GB FP16），而实际计算量仅约 140 GFLOPS——算术强度仅约 1 FLOPS/byte，远低于现代 GPU 的 ~100 FLOPS/byte 的计算能力上限 [884]。这意味着绝大部分能耗和延迟都消耗在数据搬运上，而非计算本身。

近存计算（Near-Memory Computing）和存内计算（In-Memory Compute）的核心思想是：把计算搬到数据旁边，而不是把数据搬到计算单元旁边。

6.2.2.2. 数字存内计算（DIMC）：d-Matrix 的实践

d-Matrix 的 DIMC 技术在 SRAM 阵列中直接嵌入乘法累加单元，实现 150 TB/s 的等效带宽——远高于 HBM 方案的 4–8 TB/s [223]。其核心优势在于：

• 消除权重搬运：权重存储在 SRAM 中，计算直接在存储单元旁完成，无需通过外部总线搬运。
• 能效比极高：SRAM 访问能耗约 0.3 pJ/bit，而 HBM 访问约 6 pJ/bit，差距约 20 倍。
• 无需 HBM 封装：使用标准 LPDDR5 或 3D 堆叠 DRAM，避免 HBM 的 CoWoS 封装成本和供应链风险。

2025 年 Q2 量产的 Corsair（TSMC 6nm）是该路线的首个量产产品，下一代的 3DIMC 技术（4nm，2026 年商用）将 3D 堆叠 DRAM 直接置于逻辑芯片下方，承诺 10 倍于 HBM4 的带宽和能效 [219]。

6.2.2.3. HBM-PIM：三星与 SK 海力士的推进

三星在 HBM 堆栈内部集成可编程计算单元（1.2 TFLOPS），与 Xilinx Alveo 加速器集成验证显示系统性能提升 2.5 倍，能耗降低 60% [5963]。2025 年底，三星与 SK 海力士联合推动 LP-DDR6-PIM 的 JEDEC 标准化 [5969]。但商业化仍处于客户验证阶段，距离大规模量产尚有距离 [5975]。

6.2.2.4. 国内进展

中国在存算一体领域布局积极：微纳核芯的 3D-CIM 架构实现 4 倍算力密度提升和 10 倍功耗降低 [5387]；后摩智能鸿途 H30（256 TOPS）已送测 [5395]；亿铸科技在长上下文、高并发推理场景中实现吞吐突破 [5386]。行业预期 2025–2026 年大算力存算一体芯片将逐步商用 [5393]。

6.2.2.5. 趋势判断：存内计算将在推理侧率先大规模商用

存内计算的核心挑战在于热管理（3D 堆叠后散热面积减小）和工艺成熟度。但推理场景的”低算术强度 + 高带宽需求”特性恰好放大了存内计算的优势。我们预判，存内计算将在 Decode 推理场景率先规模商用，训练场景由于数据流复杂度和精度要求更高，短期内仍以 HBM 为主。

---

6.2.3. MoE 专用互联：All-to-All 通信的硬件化

6.2.3.1. 为什么 MoE 需要专用互联

MoE 架构的每一层在推理中需要两次 All-to-All 通信（dispatch + combine），通信时间可占到 MoE 层前向延迟的 47–59%，即使在高带宽 NVLink 上也如此 [6162]。DeepSeek-V2 的测试显示，在 8 GPU 上运行 EP 时，通信占 MoE 层延迟的 59.2% [6164]。

MoE 通信的特征——动态路由（token 级别）、稀疏性（每 token 仅激活少数 expert）、细粒度——使得传统 AllReduce 无法高效支持，需要专用的通信原语和硬件加速 [5433]。

6.2.3.2. 从软件到硬件：通信栈的深度优化

2025 年最具影响力的 MoE 通信创新来自 DeepSeek 开源的 DeepEP：

• 提供高吞吐（HT）和低延迟（LL）两种模式，分别针对 Prefill 和 Decode [5561]
• 基于 NVSHMEM + IBGDA 实现 GPU-initiated RDMA——GPU 直接向 NIC 发起网络传输，零 CPU 参与 [5550]
• 在 DeepSeek-V3 训练中，配合 8×400Gbps InfiniBand NIC，实现 All-to-All 通信速度超过 40 GB/s [1761]

NVIDIA 随后在 2026 年初推出 NCCL EP，将 MoE 通信原生集成到 NCCL 中，提供统一的 ncclEpDispatch / ncclEpCombine 原语，并利用 TMA（Tensor Memory Accelerator）加速 NVLink 传输 [5576]。这标志着 MoE 通信从”用户手写 CUDA kernel”迈入”标准化通信库”阶段。

在更底层，NVIDIA 的 GIN（GPU-Initiated Networking） 技术允许 GPU 直接发起网络 RDMA 传输，无需 CPU 参与，与 NVSHMEM 性能差异在 1–2% 以内 [5894]。

6.2.3.3. 单 Kernel 融合：FlashMoE 的突破

FlashMoE（NeurIPS 2025）将分布式 MoE 的 dispatch、expert 计算、combine 全部融合到单个持久 GPU kernel 中，消除 CPU 协调和多次 kernel launch 开销（每次 ~10–50 μs），在 8×H100 上实现：GPU 利用率提升 9×，延迟降低 6×，吞吐量提升 5.7× [5826]。这代表了 MoE 推理优化的终极方向——通信与计算在单 kernel 内完全融合，消除所有 host-device 往返。

6.2.3.4. 互联带宽的硬件升级

NVLink 的带宽演进直接服务于 MoE 的 All-to-All 通信需求：

• NVLink 5（Blackwell）：1,800 GB/s/GPU，NVL72 域内聚合 130 TB/s [5421]
• NVLink 6（Rubin）：3,600 GB/s/GPU，NVL72 聚合 260 TB/s，MoE 训练所需 GPU 数减少 4 倍 [5938]
• 576 GPU 非阻塞 fabric 总带宽达 1 PB/s [5437]

Google TPU v8i 的 Boardfly 拓扑减少了 56% 的网络直径，专门优化 MoE 的 expert 通信；**CAE（Collective Acceleration Engine）**替代了 SparseCores，加速 expert 通信中的集合操作，将 on-chip collective 延迟降低 5× [389]。

6.2.3.5. 光电混合互联：MixNet 的启示

MIT 等机构提出的 MixNet（SIGCOMM 2025）引入运行时重配置的光电混合 fabric，利用光电路交换（OCS）在毫秒级实现拓扑重配置，针对 MoE 的 All-to-All 通信模式动态优化网络拓扑 [5296]。在 400 Gbps 链路下，网络成本效率提升 1.9–2.3×，支持超过 30,000 GPU 规模 [5296]。

6.2.3.6. 趋势判断：MoE 互联将从”通信优化”走向”通信-计算融合”

我们预判，未来 3 年 MoE 专用互联将沿以下路径演进：

1. Short-term（2026–2027）：NCCL EP 标准化 + DeepEP 持续优化，通信与计算 overlap 成为标配。
2. Mid-term（2027–2028）：FlashMoE 风格的单 kernel 融合成为主流，MoE 通信在 kernel 内部完成，消除 host 参与。
3. Long-term（2028+）：光电混合 fabric 实现拓扑级动态优化，MoE All-to-All 通信不再依赖静态网络拓扑，而是由 OCS 实时重配置。

---

6.2.4. 光互联：从交换机到芯片封装，从 Scale-Out 到 Scale-Up

6.2.4.1. CPO 商用的转折点：2025–2026

2024–2025 年是共封装光学（CPO）从实验室验证走向商业部署的关键转折点 [5306]。三大里程碑事件：

• 博通 Bailly（2024 年 3 月）：业界首款 51.2 Tbps CPO 以太网交换机，光互联功耗降低 70% [5630]。
• NVIDIA Spectrum-X/Quantum-X Photonics（2025 年 GTC）：144 个 800Gb/s 端口，总吞吐 115.2 Tb/s，功耗降低 3.5 倍，延迟从微秒级降至纳秒级 [5467]。
• 台积电 COUPE 平台：3D 堆叠硅光子引擎（EIC-on-PIC，SoIC-X 键合），200Gbps 光调制，>99% 的 3D 堆叠良率已在工程样品上实现 [5592]。

CPO 的核心价值在于：将光引擎与交换/计算芯片通过先进封装集成，缩短电气走线，功耗降低 40–70%，带宽提升 3 倍，延迟缩短 50% [5337]。

6.2.4.2. 从 Scale-Out 到 Scale-Up：光互联向 GPU/加速器封装渗透

Scale-Out 光互联（交换机侧 CPO）只是第一步。更深远的影响在于 Scale-Up 光互联（OIO，In-Package Optical I/O）——将光收发器直接集成到 GPU/加速器封装内部，替代铜缆 NVLink [5356]。

这一方向的关键进展：

• Ayar Labs TeraPHY（2025 年 3 月）：全球首款 UCIe 光学 I/O Chiplet，8 Tbps 带宽，16 波长 SuperNova 光源，单跳延迟 100–200 纳秒 [5464]。已向客户出货约 15,000 台 [5458]。2026 年 3 月完成 5 亿美元 E 轮融资，估值 37.5 亿美元 [5720]。
• Celestial AI Photonic Fabric（2025 年 Hot Chips）：单 Chiplet 16 Tbps 带宽，直接在 2.5D 中介层上集成硅光子 [5613]。2025 年 12 月被 Marvell 以约 55 亿美元收购 [5612]。
• Lightmatter Passage M1000（2025 年 3 月）：4,000mm² 3D 光子中介层，支持 34 个 Chiplet 集成，总光带宽 114 Tbps [5699]。
• NVIDIA 路线图：2028 年 Feynman 架构将推出 NVLink 8 CPO 交换机，实现 Scale-Up 光互联 [5950]。

2025 年底，AMD、Broadcom、NVIDIA 联合微软、Meta、OpenAI 等成立了 OCI（Optical Compute Interconnect）MSA，定义开放的 Scale-Up 光互联物理层规范，统一支持 UALink 和 NVLink 等上层协议 [2993]。

6.2.4.3. 物理约束与成本考量

光互联并非万能。当前硅光子调制器（MRM 或 MZM）的每比特能耗约为 3–5 pJ/bit，虽然优于长距离电互联（~15 pJ/bit），但短距离片上铜互联仍具有成本优势。CPO 的光源（激光器）成本、封装良率、热管理（激光器对温度敏感）仍是工程挑战 [5328]。

6.2.4.4. 趋势判断：2028 年前后 Scale-Up 光互联将进入主流

我们预判：Scale-Out 光互联（CPO 交换机）在 2026–2027 年将成为新建 AI 数据中心的标配；Scale-Up 光互联（OIO）将在 2028 年随 NVIDIA Feynman 平台进入主流，首先取代长距离 NVLink 铜缆，中长期可能实现跨机架的光互联统一 fabric。

---

6.2.5. 稀疏化硬件加速：2:4 之后是什么？

6.2.5.1. 2:4 结构化稀疏：NVIDIA 的硬件赌注

NVIDIA 自 Ampere 架构起引入 Sparse Tensor Core，支持 2:4 结构化稀疏模式——每 4 个连续值中正好 2 个为零，理论上可实现 2× 矩阵乘法加速 [5362]。这一硬件特性延续到 Hopper 和 Blackwell 架构，Blackwell 在 FP8 稀疏模式下可达 9,000 TFLOPS [5672]。

6.2.5.2. 实际效果：理想与现实的差距

然而实际加速效果远低于理论值。学术界和工业界的共识是：2:4 稀疏在推理中的实际加速比通常仅 ≤1.3×，而非理论上的 2× [6132]。原因包括：

• 稀疏模式难以在训练中维持精度：结构化剪枝后需重新训练恢复精度，而这一过程对 LLM 而言成本极高。
• 访存瓶颈掩盖了计算加速：Decode 阶段的根本瓶颈是内存带宽，即使计算加速 2×，总吞吐量提升仍受限于带宽。
• 稀疏张量核心的利用率受限：并非所有层的权重都能达到 2:4 稀疏，激活稀疏更难预测。

SemiAnalysis 的评论一针见血：“NVIDIA 应该停止在主题演讲中使用 Jensen Math 的结构化稀疏 FLOPS，除非他们能持续展示 SOTA 开源模型在结构化剪枝下保持零精度损失” [5520]。

6.2.5.3. 激活稀疏：新的前沿

2025 年的重要进展是将 2:4 稀疏从权重扩展到激活值。论文《Accelerating Transformer Inference and Training with 2:4 Activation Sparsity》展示了激活稀疏的可行性，但这一方向需要模型架构层面的配合（如 Squared-ReLU 激活函数），限制了通用性 [5781]。

6.2.5.4. 超越 2:4：V:N:M 稀疏与未来方向

学术界正在探索更灵活的稀疏模式。V:N:M 稀疏（Beyond 2:4）允许不同比例和块大小的稀疏模式，如 4:8、8:16 或超过 50% 的稀疏率 [6132]。但当前 GPU 硬件仅支持 2:4 模式，通用稀疏加速器仍处于研究阶段。

在 ASIC 侧，Taalas HC1 的”模型权重物理编码”路线可以视为极致的稀疏化——不需要的权重根本不占用硅面积，而非通过稀疏模式压缩。这代表了稀疏化的终极形态：模型结构本身就是硬件结构。

6.2.5.5. 趋势判断：稀疏化将从”通用加速器特性”走向”模型-硬件协同设计”

我们预判：通用 2:4 稀疏在 LLM 推理中的实际价值有限，真正的稀疏化收益将来自模型-硬件协同设计——MoE 的 expert 稀疏激活、KV Cache 稀疏注意力、以及模型专用 ASIC 的物理权重编码。稀疏化将不再是”通用 GPU 特性”，而是”专用 ASIC 的核心竞争力”。

---

6.2.6. 物理约束全景：不可逾越的边界条件

上述所有技术演进方向，最终都受制于以下物理约束。理解这些约束，比追捧任何单一技术路线都更重要。

6.2.6.1. 内存墙（Memory Wall）

这是最根本的约束。处理器性能每 2 年翻倍，内存带宽每 3–4 年翻倍，两者之间的差距持续扩大 [752]。LLM 推理的 Decode 阶段算术强度仅约 0.5–10 FLOPS/byte，远低于现代 GPU 的计算能力，使得内存带宽成为绝对瓶颈 [884]。

应对方向：存内计算（d-Matrix）、SRAM 替代 HBM（Groq/Cerebras）、权重物理编码（Taalas）。

6.2.6.2. 光罩极限（Reticle Limit）

单个 reticle 约 858 mm²（26mm×33mm），现代 GPU 如 B200 已逼近此极限（~814 mm²），TDP 达 1000–1200W [6064]。突破方式包括：Chiplet 分解（AMD MI300X）、晶圆级集成（Cerebras WSE）、3D 堆叠（Broadcom 3.5D XDSiP 支持 6000mm² 以上封装，最多 12 个 HBM 堆栈）[2894]。

6.2.6.3. SRAM 微缩停滞

N3 节点 SRAM 微缩约 5%，N2 恢复至 18% 但逻辑晶体管微缩 1.6×，SRAM 在芯片面积中的占比持续上升，推高成本 [6114]。这直接推动了”少 SRAM、多 HBM”和”纯 SRAM 无 HBM”两种极端路线以及混合路线的出现。

6.2.6.4. 热密度与散热

3D 堆叠芯片散热面积减小，热密度急剧上升，需通过降频降压来限制功耗 [634]。SambaNova SN50 采用空气冷却（15–30kW/rack），Groq LPU 同样风冷设计 [74]——这成为衡量部署可行性的关键指标。液冷（DLC）虽然可以解决散热问题，但增加了基础设施复杂度和成本。

6.2.6.5. HBM 供应链约束

HBM 是推理系统最稀缺的资源。2025 年 HBM 产能已售罄至 2026 年，DRAM 价格自 2025 年初已翻倍 [1225]。NVIDIA 收购 Groq 的战略动机之一正是 LPU 不需要 HBM [1330]。供应链约束正在加速”去 HBM”方向的探索。

---

6.2.7. 综合推演：2026–2030 年 LLM 推理硬件演进路线图

基于以上分析，我们给出未来 3–5 年的技术演进推演：

6.2.7.1. 2026–2027：异构推理架构的元年

• NVIDIA 双轨路线确立：Vera Rubin GPU 处理 Prefill + Groq3 LPX 处理 Decode，成为行业参照系。
• 分离式推理成为云服务标配：vLLM/NVIDIA Dynamo 原生支持，NIXL 成为 KV Cache 传输标准。
• 存内计算首批量产：d-Matrix Corsair（2026 Q2）、Raptor（2026–2027），三星 HBM-PIM 进入客户验证。
• CPO 交换机规模部署：NVIDIA Spectrum-X/Quantum-X Photonics 量产，新建数据中心标配。

6.2.7.2. 2027–2028：专用化与光互联的加速

• MoE 专用互联成熟：FlashMoE 风格单 kernel 融合成为主流，NCCL EP 标准化，All-to-All 通信不再成为瓶颈。
• Scale-Up 光互联进入主流：NVIDIA Feynman NVLink 8 CPO 发布，OIO Chiplet（Ayar Labs、Celestial AI）在 GPU 封装中商用。
• 模型专用 ASIC 的”快速迭代”模式验证：Taalas 的 2 个月流片周期承诺能否兑现，将决定该路线的生死。
• 大规模外部内存分层部署：KV Cache 和冷权重卸载到 PCIe 挂载内存或 RDMA 远端容量池成为标准操作。

6.2.7.3. 2028–2030：光子互联与训练-推理完全解耦

• 光电混合 fabric 统一 Scale-Up 和 Scale-Out：OCS 实现毫秒级拓扑重配置，MoE 的 All-to-All 通信与网络拓扑动态协同。
• 训练和推理硬件完全解耦：训练继续使用 GPU/HBM 路线，推理根据场景使用 SRAM-centric / 存内计算 / 模型专用 ASIC 等多样化方案。
• 3D 堆叠 DRAM + 逻辑成为主流：d-Matrix 3DIMC 路线被验证，HBM 不再是唯一的大容量高带宽存储方案。
• “Token 即服务”取代”芯片即产品”：云厂商自研 ASIC（Google TPU、Microsoft Maia、Meta MTIA）与独立 ASIC（Etched、d-Matrix、SambaNova）的竞争，最终取决于谁能以更低的 token 成本提供更好的服务质量。

---

6.2.8. 核心结论

1. 不存在”银弹”架构。LLM 推理的 Prefill 和 Decode 阶段对硬件的需求是正交的，最佳方案是异构硬件池 + 分离式推理调度。

2. SRAM 与 HBM 不是替代关系，而是协同关系。混合内存层级（SRAM + HBM + PCIe/DDR）正在成为主流范式，具体配比取决于 workload 特征。

3. 存内计算将在推理侧率先规模商用。d-Matrix 的量产和三星 HBM-PIM 的推进标志着存内计算从实验室走向量产，Decode 场景的低算术强度放大了其优势。

4. MoE 的 All-to-All 通信正在从软件优化走向硬件加速。DeepEP → NCCL EP → FlashMoE → 光电混合 fabric 的演进路径清晰可辨。

5. 光互联正在从交换机侧向芯片封装内部渗透。2025–2026 年是 CPO 商用转折点，2028 年 Scale-Up 光互联（OIO）将进入主流。

6. 通用稀疏化对 LLM 推理的实际价值有限。真正的稀疏化收益来自模型-硬件协同设计（MoE、模型专用 ASIC），而非通用 GPU 的 2:4 稀疏。

7. 物理约束——内存墙、光罩极限、SRAM 微缩停滞、热密度、HBM 供应链——是架构创新的根本驱动力。理解这些约束的迁移路径，是预判下一代架构方向的关键。

8. 最终赢家可能不是卖芯片的公司，而是以最低 token 成本提供最佳推理服务的公司。云厂商自研 ASIC 和独立 ASIC 公司的竞争，最终将体现在 token 价格上——这一指标将比任何技术参数都更能决定市场格局。