最近在做大模型推理部署方案调研时连续看了几篇 Cerebras CEO Andrew Feldman 的公开访谈。他屡次提到一个非常有冲击力的数字晶圆级架构Wafer-Scale Engine在特定推理任务上比传统 GPU 快 2500 倍。这个数字乍看很像营销话术但当我把大模型推理的访存模型、硬件体系结构和实际部署链路拆开看之后发现它背后并不是单纯碰瓷而是一套和 GPU 完全不同的设计哲学。这篇文章我会沿着一条比较清晰的逻辑线展开先解释大模型推理为什么受限于访存带宽再拆解 Cerebras 晶圆级架构到底“大”在哪里接着逐步还原 2500 倍这个数字在什么条件下成立、哪些加成来自片内存储、哪些来自互联拓扑。最后给出我在实际推理部署中总结的选型建议和常见误区希望对你评估推理硬件有所帮助。1. 从“2500倍”这个数字说起1.1 什么是晶圆级架构晶圆级架构英文叫 Wafer-Scale Engine简称 WSE是 Cerebras 公司推出的芯片设计路线。传统芯片是把一颗晶圆切割成几十上百块裸片die每块裸片封成一颗独立处理器。而 Cerebras 的做法很极端不做切割把整片 12 英寸晶圆直接变成一颗完整芯片再用专门设计的供电、散热和封装系统让它工作起来。Cerebras 目前公开的第三代产品是 WSE-3。根据官方资料WSE-3 采用 5nm 工艺制造内部集成了大约 90 万个计算核心晶体管数量达到数万亿级别片内 SRAM 容量为 44GB。这些数字和主流 GPU 相比完全是另一个量级英伟达 H100 大约有 1800 亿晶体管内部 CUDA 核心数量约 1.6 万到 1.7 万。即便算上 Tensor CoreWSE-3 的核心规模也要比 H100 大一个数量级。1.2 为什么这个数字会引发热议2500 倍是一个让人本能怀疑的数字。实际业务场景里GPU 之间的性能差异通常只有几倍就算用最新硬件对比老硬件也很少能有百倍以上的提升。所以当 Cerebras CEO 反复使用这个话题时技术圈第一反应是质疑。但如果我们看一下大模型推理的实际瓶颈就会发现问题没有想象中简单。大模型推理尤其是自回归生成阶段决定速度的往往不是浮点算力而是内存带宽。GPU 的算力一直比它的显存带宽增长快很多 Transformer 模型在 GPU 上的实际利用率只有 10% 到 30%。这意味着 Cerebras 如果把内存带宽做得特别高和 GPU 拉开几十倍差距完全是可能的2500 倍在特定对比条件下也可以被解释清楚。这篇文章不会单纯把“2500倍”当结论直接接受而是会把背后的推理机制、硬件结构、软件栈限制逐层拆开帮助你建立自己的判断。2. 大模型推理的真实瓶颈访存带宽2.1 一次推理到底做了什么以 GPT 这类自回归模型为例。用户输入一段文本后模型并不是一次性生成完整回答而是一个 token 一个 token 地预测。每生成一个 token都需要把模型参数和当前上下文对应的 KV Cache 全部读取一遍做矩阵乘法和注意力计算然后输出下一个 token 的概率分布。这个过程当中权重数据和 KV Cache 的读取量非常大。比如一个 7B 参数量的模型用 FP16 存储权重那么单次推理至少需要读取 14GB 数据。在 batch size 为 1 的在线请求场景下每次只生成一个 token也要把这 14GB 数据从内存里搬一遍。这个访存开销和计算本身相比反而是主导因素。我经常用一个公式来估算推理时长单 token 延迟 ≈ 模型权重体积字节 / 内存系统有效带宽这个公式忽略了计算时间和部分并行优化但对理解推理瓶颈非常直观你的权重体积是固定的当内存带宽越大单 token 延迟就越低。2.2 为什么 GPU 算力强仍然被“饿死”GPU 的峰值算力在现代架构中已经非常惊人。但算力和带宽之间存在明显失衡。以主流数据中心的 H100 为例它的 HBM3 显存带宽大约是 3.35 TB/s而 FP16 稠密算力接近 1000 TFLOPS。假设一个 7B 模型每生成一个 token 需要约 28G 次浮点运算那么纯计算时间只有不到 0.03 毫秒。但读取 14GB 权重数据需要约 4.2 毫秒。可以看出访存时间比计算时间高出两个数量级。这个现象说明在自回归推理场景中GPU 的计算核心大量处于空转等待状态。硬件算力再强如果权重数据不能及时送到计算单元里面一切都是空谈。这也是为什么很多团队发现在 batch size 较小的情况下A100 和 H100 的推理速度差距远没有算力差距大。2.3 影响推理速度的主要硬件指标既然访存是瓶颈那评估推理硬件时应该优先关注哪些指标我自己的排序如下内存带宽决定权重和 KV Cache 读取速度。内存容量决定能否放下整个模型。放不下就需要多卡拆分或外部内存这会引入更多通信开销。片上缓存与互连决定多个计算核心之间交换中间结果是否高效。批处理扩展能力带宽高的硬件可以在 batch size 变大时仍然保持合理延迟。很多人只看 TFLOPS这是典型的误区。在推理场景里TFLOPS 是必要但不充分的条件带宽和显存容量往往更重要。理解这一点后Cerebras 的优势逻辑就很好理解了。3. 什么是晶圆级架构3.1 把整块晶圆变成一颗芯片晶圆级架构的核心思路一句话概括就是“把芯片做得极大”。常规的制造流程中光刻机把芯片电路曝光在晶圆表面随后晶圆被切割成许多小块每一块是一个 die。die 的尺寸受限于制造良率、光罩尺寸和封装能力。Cerebras 的设计是整片晶圆上的电路完全保留形成一颗面积超过 4 万平方毫米的巨型芯片。这个面积大约是英伟达 H100 芯片面积的 50 倍以上。你可能会问这么大的芯片有一点缺陷怎么办Cerebras 的做法是在芯片内部设计冗余逻辑通过架构层的容错机制绕过坏点这也就是它能够量产的原因之一。3.2 WSE-3 核心参数解读下面用表格对比一下 WSE-3 与主流数据中心 GPU 的公开参数。需要注意具体数据可能随不同批次和型号有差异这里主要是为了让你感受体型差异。对比项Cerebras WSE-3公开资料英伟达 H100 SXM公开资料芯片制造工艺5nm4N 定制增强工艺晶体管规模数万亿约 800 亿计算核心约 90 万约 1.7 万 CUDA 核心 大量 Tensor Core片内存储44GB SRAM50MB L2 80GB HBM3片内带宽官方宣称 PB/s 级片内互联带宽约几十 TB/s对外存储带宽依赖于 CS-3 系统与外部存储接口3.35 TB/s HBM 带宽可以看到WSE-3 的核心数量是 H100 的几十倍片内 SRAM 容量虽然远小于 H100 的外部显存但它的关键优势是不需要把数据搬到片外所有数据都可以在片上完成读写。3.3 为什么其他厂商不效仿既然晶圆级架构看起来优势明显为什么英伟达、AMD 不做首先是难度。整片晶圆供电、散热、良率都是巨大挑战。Cerebras 为此专门设计了供电系统、液冷模组和容错网络这不是普通芯片公司能轻易复制的。其次是生态。GPU 已经发展了几十年CUDA 生态、PyTorch 适配、TensorRT 优化链路都非常成熟。晶圆级架构要进入市场必须重写编译器、运行时调度器和推理框架适配层工程成本极高。第三是市场定位。数据中心的大部分负载仍然是多样化的从训练到小模型推理、从图计算到传统数据库加速。GPU 这种通用方案能覆盖更多场景。Cerebras 选择先打推理和特定训练场景其实是一种务实的生存策略。4. Cerebras 推理快 2500 倍的原因拆解4.1 片上 SRAM 取代外部 DRAMCerebras 推理性能提升最核心的来源是它用 44GB 的片内 SRAM 替代了传统 GPU 的外部 HBM 显存。SRAM 和 DRAM 的读写速度差异非常大。GPU 通过 HBM 访问外部显存路径较长每次读取要经过内存控制器和互连总线。而 Cerebras 的每个计算核心都紧挨着 SRAM 存储单元数据访问距离极短。官方公布的片内互连带宽达到 PB/s 级别而 H100 的外部显存带宽只有 3.35 TB/s。算下来片内带宽和片外带宽相差数百倍到上千倍。大模型推理是典型的“权重反复读取”场景。只要模型能完全放进 44GB SRAM 里每次推理都不需要跨片访问内存延迟自然大大降低。2500 倍这个数字很大程度上就是从这个带宽差距推导出来的而并非说它的整数倍算力是 GPU 的 2500 倍。4.2 极致的核间互联CPU 和 GPU 的架构中核心之间交换数据要走多级互连L2 Cache、跨 die 的 NoC、甚至 PCIe 总线。核心数量越多数据一致性开销越大。Cerebras 把 90 万个核心放在同一片硅片上直接用一个 2D 网格互联把它们连起来。每个核心可以和上下左右邻居通信整体拓扑非常扁平。这种架构特别适合 Transformer 模型中逐层传递的前向计算模型某一层的输出可以非常快地传递到下一层中间不需要跨芯片传输。4.3 数据流执行方式Cerebras 架构还有一个重要特点是“数据流执行”。传统 GPU 执行方式是 SIMT很多线程同时执行同一条指令每一步操作都遵循取指-译码-执行模式。而 Cerebras 的每个核心基于数据流模型工作当某个计算所需要的数据全部到达后计算单元立即开始执行执行完直接通过片上网络把结果送到下一个需要它的核心。这样省掉了大量指令调度开销也不再需要把中间结果写回全局内存再读出来。对大模型推理这种计算图相对固定、数据依赖清晰的负载来说数据流执行方式非常友好。4.4 在 batch size 较小场景下的压倒性优势最后要强调2500 倍不是所有场景下的绝对倍数。在 batch size 很大、大量请求同时处理的场景中GPU 可以利用各种矩阵并行和内存复用技巧效率会明显提升。而在在线交互场景比如聊天机器人、代码补全、Agent 工具调用多数请求是 batch size 1 或很小批量这时推理速度几乎完全取决于单次权重读入的时间。Cerebras 的晶圆级架构在 batch size 较小的场景下可以把权重全部放在片上 SRAM 中每个 token 只需在片上完成一次完整遍历。这个场景下它与 GPU 的差距非常夸张2500 倍这个数字如果加了“特定模型、特定 batch size、特定量化精度”的前缀合理度就大大提升。5. 实测视角推理吞吐与延迟还受哪些因素影响5.1 精度和批处理配置宣传中的性能数字往往采用较高的精度和特定 batch size。实际部署中推理端为了降本通常使用 FP8、INT8 或 INT4 量化。量化之后模型体积减小推理需要的带宽也减少。对 GPU 来说量化能带来数倍提升对 Cerebras 来说模型变小也意味着 44GB SRAM 可以容纳更大尺寸的模型。这里有一个很实际的结论不管用什么硬件推理速度不仅取决于硬件峰值能力还取决于部署时的精度选择、是否使用 PagedAttention 这类 KV Cache 管理技术、是否开启了 Continuous Batching以及是否合理设置 max_tokens。5.2 软件栈与模型支持程度Cerebras 虽然推出了自己的 SDK 和编译工具但和 PyTorch 生态的兼容性还在快速演进中。如果你在部署时发现某个算子不支持或者某类自定义模型无法编译那再高的硬件带宽也发挥不出来。我通常建议团队在选型前做一轮“真实模型可运行性测试”。不要只跑官方标准的 ResNet 或 GPT 示例而是把自己业务里真实模型的代码、分词器、预处理逻辑都跑一遍确认能否编译、能否正确导出、能否和现有的服务框架集成。6. 一个衡量带宽瓶颈的简单实验6.1 计算单次推理的理论访存开销为了更直观地理解带宽对大模型推理的影响我写了一个简单的 Python 脚本用来估算不同模型在 FP16 精度下的单 token 访存开销。# 文件路径estimate_bandwidth.py def estimate_bandwidth_bytes(model_params_billion, precision_bytes2): 估算单次生成一个 token 需要读取的模型权重字节数。 model_params_billion: 模型参数量单位是十亿例如 7 表示 7B precision_bytes: 每个参数占用的字节数FP16 为 2FP8 为 1INT4 为 0.5 return model_params_billion * 1_000_000_000 * precision_bytes def estimate_token_latency_ms(bandwidth_bytes, models): bandwidth_bytes: 内存带宽单位是字节/秒 models: 模型名称到参数量的字典 for name, params in models.items(): weight_bytes estimate_bandwidth_bytes(params) latency_ms weight_bytes / bandwidth_bytes * 1000 print(f{name}: 单 token 理论访存延迟约 {latency_ms:.2f} ms) # 以 H100 的 3.35 TB/s 为例 h100_bw 3.35 * 1024 * 1024 * 1024 * 1024 estimate_token_latency_ms(h100_bw, { 7B 模型: 7, 13B 模型: 13, 70B 模型: 70, })运行后大致能看到7B 模型在 H100 上单 token 理论访存延迟约 4 毫秒左右70B 模型会接近 40 毫秒。这个数字和真实在线服务的首 token 延迟与 token 生成速率对照可以帮我们判断当前瓶颈到底在计算还是访存。6.2 用 PyTorch 模拟不同 batch size 的吞吐变化下面这个小实验可以用来观察 batch size 变大后访存开销如何被摊薄。我们构造一个大矩阵乘法模拟模型权重读取。# 文件路径memory_bound_simulation.py import time import torch def run_matmul_repeated(weight, inputs, repeat100): start time.time() for _ in range(repeat): output torch.matmul(inputs, weight) elapsed time.time() - start return elapsed / repeat for batch in [1, 8, 32, 128]: weight torch.randn(4096, 4096, devicecuda) inputs torch.randn(batch, 4096, devicecuda) avg_ms run_matmul_repeated(weight, inputs) * 1000 print(fbatch{batch}, 每次迭代耗时约 {avg_ms:.3f} ms)注意权重矩阵固定在显存中每次迭代都需要从显存读取一遍。当 batch 变大时计算量线性增长但权重读取次数不变因此吞吐会不断提高。如果某一时刻吞吐增长放缓往往就是显存带宽碰到了上限。6.3 命令行观察实际硬件状态在日常推理服务排查时观察硬件利用率是第一步。NVIDIA GPU 可以用下面的命令查看显存和功耗状态nvidia-smi --query-gpuindex,name,memory.total,memory.used,power.draw,utilization.gpu --formatcsv如果看到 GPU 利用率很低但显存读取已经接近上限说明你的瓶颈在显存带宽而不是算力。这个时候换一张算力更高但带宽没提升的卡收益会非常有限。7. 常见问题与误区7.1 2500 倍是真的吗严格说2500 倍是“在限定条件下可以复现”的倍数。限定条件至少包括特定模型结构、特定精度、特定 batch size、特定对比 GPU 型号和软件优化程度。脱离这些前缀谈 2500 倍和把它当成所有场景的绝对性能都是不严谨的。但从架构原理看片内带宽和片外带宽之间的数量级差距是真实存在的所以推理性能差距确实可能非常大。我倾向把它理解成“带宽优势的倍数”而不是“算力优势的倍数”。7.2 常见误区表格误区实际情况推理快 算力高算力高有帮助但访存带宽往往才是主要瓶颈显存越大越好大显存解决容量问题但不能弥补带宽不足所有模型都能直接跑需要看模型算子是否能编译到目标架构上芯片强 系统强软件栈、框架适配、运维工具共同决定整体体验LPU 和晶圆级架构是一回事不完全等价。LPU 是另外一家公司对专用处理器路线的一种描述晶圆级架构强调的是把整块晶圆做成单芯片的设计路线两者不能混用7.3 与推理框架相关的常见问题在调研推理部署时很多同事也会问Ollama、Dify、YOLOv11 这些工具会不会受硬件架构影响答案是有很大影响。Ollama 搭在 llama.cpp 之上底层优化高度依赖 AVX、CUDA 或 Metal 指令集如果换成 Cerebras 这类专用硬件需要官方提供对应的后端支持。Dify Chatflow 做多轮对话时上下文一旦变长KV Cache 会快速膨胀系统对内存带宽和显存容量的需求都会上升。YOLOv11 这类 CV 模型推理则是相对轻量的 CNN 计算特点和要求与Transformer生成模型完全不同。选型时不能只看模型跑不跑得动还要看框架层的适配成本。8. 工程选型与落地建议8.1 推理硬件选型关注点我总结了一张选型前需要确认的清单模型是否完全放入设备内存如果放不下需要切分这会影响整体性能。业务请求是高并发在线还是离线批量在线小 batch 场景更看重带宽离线大 batch 更看重算力与吞吐。推理框架是否提供目标硬件的后端如果没有需要评估自研算子与编译成本。团队是否具备新硬件长期维护能力专用硬件往往意味着调试工具和社区资源较少。单位成本下的真实吞吐和延迟是多少不要只看总吞吐也要看服务可用性和响应延迟 P99。8.2 Cerebras 适合什么业务从架构特点看Cerebras 最适合几类业务第一类是固定模型、固定结构的超大模型推理例如部署后不太经常改网络层的生成模型。模型结构稳定编译器优化的收益可以长期复利。第二类是交互式低延迟场景例如语音助手、代码助手等对单 token 延迟非常敏感batch size 不大。第三类是需要超高吞吐的离线批量推理比如用大模型批量改写文章、批量生成测试用例。只要模型能放进片内 SRAM吞吐收益比 GPU 集群更明显。反过来如果你需要经常换模型或者要快速适配最新发布的权重结构传统 GPU 生态的灵活度仍然是优势。8.3 成本与生态的平衡任何新硬件进入技术选型最终都绕不开成本与生态。Cerebras 的采购和托管成本并不低而且学习、适配、踩坑都需要时间。很多团队更适合的方式是先在云上或合作机房做小规模 PoC拿自己的真实流量回放测试再决定是否大规模引入。从整个行业趋势看专用推理芯片确实越来越有价值。传统 GPU 在训练上的统治地位短期不会动摇但推理市场正在分化出大量专用需求。晶圆级架构、类脑芯片、可重构数据流架构等路线都在抢占“大模型推理”这块蛋糕。9. 理性看待推理芯片的“军备竞赛”动手评估过这些专用架构之后我最大的感受是推理芯片的性能差距真实存在但它必须放在“模型—框架—硬件—请求特征”组成的完整系统里去理解。2500 倍这个数字提醒我们传统 GPU 并非在所有推理场景都是最优解但它也提醒我们任何单一指标都不应该被当作神话来膜拜。如果你正在做推理部署选型建议把注意力从“谁快多少倍”转移到“我的模型和我的流量是否适配这条路线上来”。先用一个简单的带宽模型估算瓶颈再用真实模型跑一轮端到端基准测试最后结合成本、运维和生态做决定。这样即使最终选择更换硬件数据也能告诉你真正的收益边界在哪里。