晶圆级芯片近年重新进入大众视野核心原因只有一个传统芯片封装之间的 I/O 带宽已经卡住了大模型训练和科学计算的天花板。与其在 PCB 上拼命塞 HBM、铺高速 SerDes不如直接做一整片晶圆那么大的芯片把原本需要跨芯片传输的数据流全部收敛到片内。这个思路最典型的代表就是 Cerebras 的 Wafer-Scale EngineWSE系列。这篇文章不聊概念只拆三个问题晶圆级芯片的 I/O 带宽到底卡在哪里、怎么算清楚这些带宽数据、用什么方法验证和量化瓶颈。最后给一套可以复用的带宽估算公式和测试路径适合做 AI 基础设施、高性能计算选型或者单纯想搞明白“为什么 2.6 万亿晶体管的芯片反而最缺带宽”的人。1. 晶圆级芯片核心能力速览能力项说明芯片类型晶圆级集成芯片单芯片覆盖整片晶圆典型代表Cerebras WSE-2 / WSE-3核心目标解决多芯片互连导致的片间 I/O 带宽瓶颈片上互连带宽公开资料显示 WSE 系列片内互连带宽达到 PB/s 量级存储架构大量片上 SRAM避免频繁访问片外 HBM功耗规模单系统功耗达到 kW 级需要专门散热方案主要场景AI 大模型训练、科学计算、高带宽数据处理分析工具Roofline Model、带宽计算脚本、链路测试工具适配能力需要专用编译器和编程框架无法直接运行通用 CUDA 代码从这张表能看出晶圆级芯片的本质不是“更大的 GPU”而是用工艺和封装手段把互连带宽密度提到一个传统多芯片系统无法达到的级别。下面逐步展开。2. I/O 带宽瓶颈从哪来传统封装的短板先明确一个定义I/O 带宽不是单一指标至少包含三个层面片内互连带宽芯片内部计算单元之间、计算单元与缓存之间的数据传输速率。片外存储带宽芯片访问 HBM、DDR、SRAM 等外部存储的速率。片间通信带宽多个芯片通过 PCB 走线、SerDes、CXL、NVLink 等互连的速率。传统做法是拆成多个小 die再用先进封装或者 PCB 拼起来。这个路线的上限非常明确引脚数受限BGA 封装能提供的引脚数量有限信号速率又不能无限提升片间带宽被引脚密度卡死。功耗受限高速 SerDes 每传输 1 bit 数据的能量开销远高于片内 wire高带宽意味着高功耗。面积受限2.5D interposer 可以放 HBM但 interposer 本身也有面积和良率限制。所以当算力增长远远超过芯片间带宽增长时瓶颈就从“算得不够快”转移到“数据送不进去”。晶圆级芯片的做法是放弃切分直接做一整片。这让绝大多数通信从“片间”变成“片内”I/O 压力瞬间转移到了片上互联和片外存储两个局部。3. 晶圆级芯片的片上 I/O 带宽特征晶圆级芯片最重要的带宽优势来自片上网格mesh互连。以 Cerebras WSE 为例公开资料显示其核心之间由高密度、低时延的二维网格网络连接带宽可以达到 PB/s 量级。这个数字怎么理解对比几个常见传输链路链路典型总带宽量级单 bit 传输能效片内 wire数十 TB/s 到 PB/s极低0.1 pJ/bit 附近HBM2E 单颗约 460 GB/s 到 1.2 TB/s中等约 2-4 pJ/bitPCIe Gen5 x16约 64 GB/s较高约 10-15 pJ/bit400G 光模块约 50 GB/s很高加上电光转换更高这里的关键不是绝对数字而是“带宽密度”。片内 wire 可以在很紧凑的空间里并行放置成千上万条单位面积带宽密度远高于引脚和 PCB 走线。晶圆级芯片正是放大了这个优势。但瓶颈也随之转移片内网格虽然带宽高但全局同步困难数据从芯片一端到另一端存在可感知的跨 Die 时延。片上 SRAM 容量仍然有限不可能全部塞进片内。最终还是要通过片外接口读入训练数据、写出权重和中间结果此时片外 I/O 成为新的窄口。所以晶圆级芯片的 I/O 瓶颈不是“带宽总量不够”而是“总带宽分布不均”片内极高、片外相对有限”。4. 片外 I/O 瓶颈SerDes、HBM 与光互连晶圆级芯片的片外 I/O 主要面临三类约束。4.1 SerDes 引脚密度限制晶圆边缘的面积有限能布下的 Pad 和 SerDes 通道数量受限。等 2.6 万亿晶体管规模的芯片需要高频访问外部网络和存储时每增加一个高速通道都要占用晶圆边缘面积和功耗预算。这个限制和传统封装类似但晶圆级芯片的功耗更高留给 I/O 的功耗余量更加敏感。4.2 HBM 接口功耗较高HBM 是当前 AI 芯片最常用的外部存储方案单颗 HBM3E 带宽可以做到 1 TB/s 量级。但问题在于HBM 需要借助 2.5D interposer或 CoWoS 封装连接到芯片晶圆级芯片面积巨大和 interposer 的匹配难度很高。HBM 访问能耗远高于片上 SRAM大量随机小尺寸访问会让能效更差。如果只靠 HBM 做片外存储带宽还是会被接口数量限制住难以和片内 PB/s 级带宽匹配。4.3 光 I/O 是方向但不是现成的万能解光互连在长距离传输上优势明显但片上集成光引擎要解决激光器、调制器、光电探测器的工艺兼容性和封装良率问题。目前还没有量产晶圆级芯片直接标配可插拔光 I/O。结论片外 I/O 的瓶颈是工程约束和物理约束共同作用的结果不是简单提升一种协议速率就能解决。5. 带宽计算口径从 HBM、LPDDR 到背板带宽分析晶圆级芯片 I/O 瓶颈前先把带宽计算的口径统一。热搜词里出现了 LPDDR5 9600 带宽计算、HBM2/HBM2E/HBM3/HBM3E 显存带宽大小、设备背板带宽为什么是两个数据等高频问题这里一次性说明白。5.1 显存带宽计算公式带宽Byte/s 数据速率MT/s x 位宽bit / 8以 LPDDR5-9600 为例# LPDDR5-9600 单通道64-bit 位宽 rate_mts 9600 # MT/s bus_width 64 # bit channels 4 # 假设 4 通道 bandwidth_gbps rate_mts * bus_width * channels / 1000 # Gbit/s bandwidth_gbs bandwidth_gbps / 8 # GB/s print(fLPDDR5-9600 4通道带宽: {bandwidth_gbs:.1f} GB/s)输出约 307.2 GB/s。如果换成 HBM3E单颗位宽通常 1024 bit数据速率约 9.6 Gbps单颗带宽约 1.2 TB/s。HBM2、HBM2E、HBM3、HBM3E 的演进本质是提高数据速率和堆叠密度类型单颗典型带宽位宽主要提升点HBM2256 GB/s 左右1024 bit基础堆叠HBM2E460 GB/s 左右1024 bit堆叠层数增加HBM3800 GB/s 左右1024 bit速率提升HBM3E1 TB/s 以上1024 bit更高速率、更大容量5.2 设备背板带宽为什么是两个数据背板带宽标称两个数据通常是指“总带宽”和“交换容量/吞吐量”两套口径。总带宽一般按照“端口数量 x 端口速率 x 双向”计算交换容量可能只算单向或去掉冗余链路。这个差异同样会出现在晶圆级芯片的网络接口宣传中所以看规格时一定要确认标称值是单向还是双向是否含链路冗余。# 以 64 个 100G 端口为例计算背板带宽 # 双向往返总带宽 echo 64 * 100G * 2 $(python3 -c print(64 * 100 * 2)) Gbps # 单方向交换容量 echo 64 * 100G $(python3 -c print(64 * 100)) Gbps同一个设备用不同口径能差出一倍。这也是晶圆级网络和传统设备对标时最容易踩的坑。6. 晶圆级芯片 I/O 瓶颈分析环境准备不管是做理论分析还是有机会拿到真实硬件做基准测试都需要一套可复用的分析环境。这里给出一个基础环境清单按需取用。6.1 硬件建议CPUx86_64建议 8 核以上用于跑带宽计算脚本和仿真。内存32 GB 以上仿真片上网络时内存占用比较明显。GPU可选如果同时跑 AI 模型对比测试建议 NVIDIA 显卡显存越大越好。磁盘SSD 512 GB 以上保存数据集、日志和模型权重。6.2 软件依赖# Python 环境用于带宽计算和数据分析 python3 -m venv wafer_io_env source wafer_io_env/bin/activate pip install numpy pandas matplotlib如果是实际跑网络接口测试还要准备 iperf3、ib_write_bw 这类工具# Ubuntu/Debian 安装网络带宽测试工具 sudo apt update sudo apt install -y iperf36.3 分析流程明确对象是分析片内 NoC 还是片外 SerDes还是整机存储带宽。构建带宽模型用公式和脚本量化理论峰值。收集流量特征跑代表性负载记录实际吞吐和时延。对比 Roofline把算力峰值和带宽峰值画在同一张图里找到瓶颈区。7. I/O 带宽瓶颈测试与效果验证方法这一节给出一套可操作验证流程。即使没有晶圆级芯片实物也可以在传统多卡集群上做对照测试验证“片间带宽不足”是否真实存在。7.1 全连接通信测试多卡场景下如果节点间通信占比高总吞吐会被片间 I/O 卡住。可以用 iperf3 或 NCCL 的 all_reduce 测试验证。# 服务端 iperf3 -s -p 5201 # 客户端跑 60 秒测单线程 TCP 吞吐 iperf3 -c 192.168.1.100 -p 5201 -t 60判断标准吞吐接近链路理论值说明片间带宽余量充足。吞吐明显低于理论值且 CPU 占用不饱和说明协议栈或驱动层受限。多流并行时总带宽提升但单流不行则可能是单核处理瓶颈。7.2 矩阵乘法带宽压力测试用 GEMM 测试可以判断“算力 vs 带宽”的实际配比。import numpy as np import time n 8192 a np.random.rand(n, n).astype(np.float32) b np.random.rand(n, n).astype(np.float32) start time.time() c a b elapsed time.time() - start # 估算所需最小带宽2 * n^3 次浮点操作假设峰值算力为 P flops 2 * n ** 3 print(f计算量: {flops / 1e12:.2f} TFLOPS) print(f耗时: {elapsed:.3f} s)如果耗时远超理论算力对应的预期时间就说明访存带宽或 I/O 数据搬运成为瓶颈。7.3 HBM 带宽验证实际服务器上可以通过nvidia-smi或rocm-smi查看显存带宽占用状态用带访存密集 Kernel 的向量加法和矩阵乘法脚本做验证。判断是否命中带宽瓶颈的方法把矩阵规模翻倍如果耗时近似线性增长而算力利用率没有明显变化大概率是带宽受限。7.4 批量任务与长时稳定性晶圆级芯片往往面向长时间训练任务I/O 瓶颈会在长跑中暴露网络重连次数是否增加。检查点保存是否阻塞计算。多租户并发任务是否互相挤占带宽。建议跑 24 小时稳定性测试记录每分钟吞吐均值、P99 时延、错误重传数。8. I/O 瓶颈的可视化与 Roofline 分析量化瓶颈最有效的方式是 Roofline Model。它把硬件能力画成两条线屋顶线是算力峰值斜线是带宽上限。一个负载如果落在斜线区域就说明其性能受限于 I/O 带宽。8.1 Roofline 计算脚本import matplotlib.pyplot as plt import numpy as np # 假设峰值算力 10 TFLOPS带宽 2 TB/s peak_flops 10e12 peak_bw 2e12 # 算术强度范围 x np.logspace(-2, 3, 200) ridge peak_flops / peak_bw # 转折点 y_bandwidth x * peak_bw y_compute np.full_like(x, peak_flops) y_roofline np.minimum(y_bandwidth, y_compute) plt.figure(figsize(8, 5)) plt.loglog(x, y_roofline, linewidth2, labelRoofline) plt.axvline(ridge, linestyle--, colorgray, labelfRidge Point {ridge:.1f} FLOP/Byte) plt.xlabel(Arithmetic Intensity (FLOP/Byte)) plt.ylabel(Achievable Performance (FLOPS)) plt.legend() plt.grid(True, whichboth, alpha0.3) plt.tight_layout() plt.savefig(roofline.png, dpi120)8.2 判断方法算术强度小于 Ridge Point属于带宽受限型负载。算术强度大于 Ridge Point属于计算受限型负载。晶圆级芯片一般会把 Ridge Point 推得很高因为片内带宽大但片外接入数据仍然会有明显拐点。对这个脚本稍加改造把 WSE 公开的算力和带宽参数填进去就能画出该芯片的理论 Roofline直观看出哪些负载类型适合晶圆级架构。9. 晶圆级 I/O 瓶颈缓解方向9.1 存储上移把数据尽量放在片上 SRAM 或靠近计算的存储层级减少对片外带宽的依赖。WSE 采用大量片上 SRAM 就是这种思路。9.2 光互连与硅光集成当电互连的面积和功耗无法继续扩展引入片间光互连可以显著提高带宽密度。虽然工艺还不完全成熟但方向明确。9.3 近内存计算把部分计算任务下推到存储周边减少数据搬运。对于稀疏模型和图计算这类低算术强度任务效果更明显。9.4 异构片间协议用定制扇出封装、2.5D 互连替代标准 PCIe/CXL虽然成本高但能显著提升单位功耗下的带宽效率。10. 常见问题与排查方法问题现象可能原因排查方式解决方案带宽测试远低于理论值驱动或协议栈未调优查看网卡中断、CPU 占用开启多队列、调大 MTU显存带宽跑不满访存模式随机化严重用 roofline 看算术强度改成连续访存或分块多用户并发时吞吐下降带宽被争抢无 QoS观察队列深度和延迟配置流控或任务调度HBM 带宽型号看错规格表口径不一致重新计算位宽 x 速率统一用 Byte/s 对比训练中 I/O 等待过高数据集读取太慢观察数据加载线程预取、缓存、压缩11. 最佳实践与使用建议11.1 先算规格再选硬件看任何芯片或系统的 I/O 能力先确认三组数带宽总数、单向还是双向、可同时使用的通道数。宁可多算一遍也不要被宣传数字误导。11.2 用 Roofline 指导模型选型低算术强度的模型如推荐系统、图神经网络在晶圆级芯片上的收益更明显。高算术强度模型反而受限于算力峰值的提升幅度。11.3 批量任务要留带宽余量批量训练或推理场景下数据预取、检查点保存、日志采集都会抢占 I/O。建议预留 20% 到 30% 的带宽余量避免长稳运行时抖动。11.4 注意功耗和散热约束晶圆级芯片功耗极高I/O 功耗占比可能超过 30%。如果做系统集成液冷和电源设计必须在选型早期介入否则带宽拉得高也稳不住。12. 总结与下一步晶圆级芯片的 I/O 瓶颈已经从传统“引脚不够、链路不够”转变为“片内带宽资源不均、功耗墙限制提升空间”。分析这类系统关键是先建立统一的带宽计算口径再用 Roofline 判断负载是在带宽受限区还是在计算受限区最后通过多流测试和长稳观察验证真实表现。如果手里有真实硬件或者较大的多卡集群建议第一个实验就做一个全链路带宽矩阵测试把节点内、节点间、存储访问三条路径的峰值带宽全部打一遍记录 P99 时延。这套数据比任何理论峰值都有说服力。下一步可以继续做编译器和调度策略的带宽适配但先把手头的 I/O 基线数据跑满比盲目追新架构更重要。