Cerebras 这个名字很多不玩 AI Infra 的人可能有点陌生。它不是做 GPU 的也不是做常规 AI 加速卡的而是把整块 300mm 晶圆做成一个连续计算芯片的公司。最近 Cerebras CEO Andrew Feldman 在公开场合又聊到了晶圆级架构在推理上的优势甚至给出了“快 2500 倍”这种给人印象很深的数字。很多人的第一反应是具体快在哪是频率更高还是核心更多其实都不是。真正的核心是内存带宽和权重的搬运方式。如果你正在做大模型推理部署、选型、或者被显卡显存带宽卡得难受这篇文章可以帮你理清楚这个“2500 倍”是营销话术还是物理优势。接下来我会先讲清楚 Cerebras 晶圆级引擎是什么再拆开来说推理为什么会卡在内存带宽上然后解释“快 2500 倍”这句话的成立条件最后给出一套通用的推理性能验证思路方便你拿到任何推理服务时都能自己算账。1. Cerebras 与晶圆级架构核心能力速览先给一个整体的能力速览。下面的信息主要来自公开技术资料和厂商发布具体型号、参数和接口能力还是要以官方资料为准。能力项说明公司Cerebras Systems专注大模型训练与推理加速核心产品晶圆级引擎Wafer-Scale EngineWSE设计思路整片晶圆不切割当作单一芯片连续使用机器学习场景大模型预训练、微调、推理服务推理核心优势减少外部内存搬运提高单 token 生成吞吐典型部署形态数据中心设备、云端推理 API不面向个人 PC接口能力提供云端推理 API业界常采用 OpenAI 兼容风格批量任务面向高并发、高吞吐推理场景可支撑批量请求硬件门槛普通用户无法自行部署需通过云 API 或整机方案接入适合人群推理服务架构师、大模型应用开发者、AI Infra 研究Cerebras 在 2024 年发布了最新一代晶圆级引擎公开信息显示其采用先进制程单颗芯片包含约 90 万个 AI 核心拥有数十 GB 的片上 SRAM片上内存带宽达到 PB/s 级别。这个数量级和常规 GPU 的 HBM 带宽完全不在一个层面。注意这里的核心不是“核心多”而是“数据离计算单元足够近”。晶圆级架构最核心的特点不是把晶体管做多而是把内存和计算放在同一个连续晶圆上尽量消除片外数据搬运。传统 GPU 是显卡上放一个或几个 die外面配 HBM 显存中间通过封装基板和 I/O 走线通信。Cerebras 的思路则是整片晶圆直接作为计算连续体使用大量 SRAM 和计算核之间的距离被压缩到了极致。2. 为什么大模型推理会慢在内存上很多人以为推理慢是因为算力不够但实际情况更复杂。LLM 推理分为两个阶段prefill预填充和 decode逐 token 生成。prefill 阶段要并行处理输入文本计算量大但通常只做一次。decode 阶段才是真正拖时间的地方因为每个 token 都是串行生成的。decode 阶段有一个非常明显的特征每次生成一个 token都需要把模型权重重新访问一遍。模型权重不会因为上一次推理就被“记住”在计算单元里每次都要重新从内存读取。举个例子一个 70B 参数的模型如果用 FP16 精度保存权重那么权重文件大约 140GB。在 decode 阶段每次生成一个 token理论上至少要读取这 140GB 的权重数据。如果算力足够瓶颈就完全被内存搬运时间锁死了。传统 GPU 的高端型号 HBM 带宽大约在 3TB/s 左右。即使按照 3.35TB/s 计算纯理论状态下降 140GB 权重搬到计算单元也需要时间 140GB / 3.35TB/s ≈ 41.8 毫秒也就是单个请求顺序生成时光是权重读取这一项理论上限也只有每秒 24 个 token 左右。实际还会受到注意力计算、KV Cache、调度开销、显存访问冲突等影响最终吞吐只会更低。这就是为什么很多人在本地跑大模型时明明 GPU 算力很强但 token 生成速度依然不理想。所以 LLM 推理的性能瓶颈很大程度不在 GPU 的浮点算力而在内存带宽。这也是“以内存换算力”的架构改动能够改变推理体验的根本原因。3. 晶圆级架构到底改了什么Cerebras 的晶圆级引擎把内存带宽提升了一个数量级关键是它改变了“权重放哪里”和“权重怎么访问”这两个问题。传统 GPU 的架构里HBM 显存通过较长的物理走线连接到 GPU die 上。虽然 HBM 的带宽已经比普通 DDR 内存高很多但物理距离、IO 接口数量、封装功耗的限制都存在。每次读取权重数据要走完“计算单元 → 片内缓存 → 存储控制器 → HBM 颗粒”整条路。数据量一大延迟和功耗都会急剧上升。Cerebras 的做法是把大量 SRAM 直接和计算核心放在同一片晶圆上。SRAM 的优点是速率快、延迟低、能与算力单元紧密耦合缺点是单位容量成本高、密度低。在传统 GPU 上SRAM 一般只用来做 cache无法存放完整的大模型权重。但晶圆级架构通过整片晶圆的大面积把 SRAM 容量做到了几十 GB 级别让更多的权重可以长期驻留在片上。这样的直接结果是 decode 阶段每次读取权重时不再需要跨越完整的 HBM 走线和存储控制器而是从片内 SRAM 获取。再加上片内互连的带宽优势每次权重读取的耗时被大幅压缩。晶圆级架构还解决了多卡并行的问题。很多大模型在 GPU 集群上推理时需要做张量并行或流水线并行模型会被切到多张卡上每生成一个 token多张卡之间还要同步一层输出。这样跨卡通信的延迟会叠加在每 token 延迟上。Cerebras 单片晶圆面积够大一个“逻辑芯片”上集成了极高数量的核心和互连很多模型可以在单芯片内完成切分不需要频繁通过外部网络传递中间结果。这等于同时减少了“内存搬运”和“卡间同步”两笔开销。所以晶圆级架构并不是简单地把 GPU 做大而是把推理中最影响体感的两部分瓶颈也就是内存带宽和卡间通信分别在物理层面做了优化。4. “快 2500 倍”这个数字是怎么来的Cerebras CEO 多次提到的“2500 倍”并不是所有场景下的通用结论。它应该被理解为一个特定项目、特定基线、特定测试条件下的比较结果。这个数字能成立主要来自几个维度的叠加。第一不同硬件方案的“每 token 生成速度”差异极大。如果拿晶圆级架构和 CPU 推理比或者和内存带宽受限明显的低功耗 GPU 平台比由于基线本身很低倍率自然会被拉得非常大。用户在本地用 CPU 跑 70B 模型时每秒可能只有几个 token而 Cerebras 的数据中心级方案可以达到每秒上千 token倍率成百上千并不奇怪。第二Cerebras 在架构层面把权重的“重复读取”代价降下来了。GPU 上每个 token 都要从 HBM 拉权重一旦请求并发或者服务长文本带宽会被迅速占满。而在晶圆级架构中权重可能常驻芯片 SRAM单 token 的生成延迟大幅缩短。也就是说“2500 倍”这个数字本质是“内存搬运”“卡间通信”“串行 decode”这三项开销同时被压缩之后的体现而不是单靠某一项改出来的。第三厂商在宣传时往往会选择对自己最有利的对比基线。比如选择的模型大小、精度、batch size、并发数、输出长度、参考 GPU 型号等都会影响倍率。以不同 baseline 做基准测试可能得到几十倍、几百倍、甚至几千倍的不同结论。从技术人的角度看这个“2500 倍”的价值不在于精确的倍数而在于它揭示了一个趋势推理的下一阶段优化重点将从“增加算力”转为“减少数据搬运”。谁能把权重的物理距离拉得越近谁就能在 token 生成场景中获得越明显的体验优势。5. 适用场景与使用边界晶圆级架构的特点是高吞吐、低延迟权重访问、大芯片一体化调度。因此它最适合以下场景。一是高并发推理服务。很多 AI 应用需要同时处理大量独立的生成请求晶圆级架构的大面积核心和片上网络可以更高效地处理并行任务降低排队时间。二是长文本生成。输出 token 越多decode 阶段占总时间的比例越高内存带宽瓶颈越明显。晶圆级架构在长输出场景下的相对优势更大。三是对延迟敏感的生产环境。比如实时聊天、Agent 工具调用、程序生成等用户希望首 token 快、后续 token 稳定。晶圆级架构的确定性调度比传统 GPU 更容易做到低抖动。但它的边界也非常明显。首先这不是普通人能在自己电脑上部署的硬件。晶圆级引擎需要专门的主板、机柜、散热和供电方案个人开发者只能通过云 API 接触。其次片上 SRAM 虽然容量不小但和显存相比仍然有限。超大模型无法完整放入单颗晶圆级芯片时依然要做模型切分、外部存储配合或者多芯片并行这会降低一部分优势。不同官方资料给出的方案不同实际性能需要按具体模型和环境测试。再次软件生态相对年轻。GPU 拥有 CUDA、PyTorch 高度适配的成熟生态而晶圆级架构要发挥完整能力需要编译器、推理框架、模型工具链的深度适配。新模型是否能快速上线存在一定滞后风险。最后成本和采购门槛不低。晶圆级引擎的设备价格属于数据中心级投入并不适合所有团队。对于大多数中小规模业务继续使用 GPU 云服务可能是更经济的方案。6. 性能验证思路与 token/s 实测脚本不管选择什么推理服务最终还是要用数据验证。如果你正好拿到了某个推理服务的 API 访问权限无论它是 Cerebras 还是任何 GPU 推理平台都可以用一个通用脚本测试端到端的生成性能。测试时至少需要关注三个指标首 token 延迟、平均每秒 token 数、整体请求耗时。其中每秒 token 数是最直观的对比指标。下面给出一段简单的测速脚本使用 Python requests 直接请求兼容 OpenAI 风格的 chat completions 接口。注意这只是一种通用测试模板实际 API 路径、鉴权方式、参数名需要根据服务提供方的官方文档调整。import time import requests # 请替换为你的推理服务端点、密钥和模型名 endpoint https://your-inference-service/v1/chat/completions api_key YOUR_API_KEY model your-model-name payload { model: model, messages: [ {role: system, content: 你是一个输出稳定的助手。}, {role: user, content: 请写一段 200 字左右的技术说明。} ], max_tokens: 512, temperature: 0.7, stream: False } headers { Authorization: fBearer {api_key}, Content-Type: application/json, } start time.perf_counter() resp requests.post(endpoint, jsonpayload, headersheaders, timeout180) latency time.perf_counter() - start data resp.json() if resp.status_code ! 200: print(请求失败, data) exit(1) content data[choices][0][message][content] usage data.get(usage, {}) completion_tokens usage.get(completion_tokens, 0) total_tokens usage.get(total_tokens, 0) print(f输出内容长度{len(content)} 字符) print(f总耗时{latency:.2f} 秒) print(f生成 token 数{completion_tokens}) if completion_tokens 0: print(f平均生成速度{completion_tokens / max(latency, 0.001):.2f} tokens/s) print(f总 token 数含输入{total_tokens})测试时要注意几个坑。第一如果 max_tokens 设置得过小输出可能提前结束测出来的 token 数会失真。第二如果是流式接口总耗时和 token 生成速度的统计方式不同。流式接口需要自己处理增量内容并记录首 token 时间。第三同一服务的性能会随着并发数、输入长度、服务端负载而波动。要得到稳定对比建议每个配置测多轮取中位数或平均值不要只跑一次。如果你希望观察更细的指标还可以使用time.perf_counter()分别记录首个 token 到达时间和剩余 token 的累计时间这样能同时看到首 token 延迟和稳定生成阶段的速率。7. 关于这个话题的常见问题与排查思路很多人一看到“快 2500 倍”就开始争论其实问题往往出在指标定义不一致。下面整理了几个常见的疑问和排查建议。问题现象可能原因排查方式解决方案为什么不同文章的倍数差异巨大对比基线、模型、精度、batch 都不同查看原文是否给出完整测试条件自己拿同一脚本跑目标服务再做对比CPU、GPU、晶圆级芯片测出不同 token 速度内存带宽和权重驻留位置不同分别记录 TTFT 和 decode 阶段耗时重点看 decode 阶段的平均 token 生成耗时API 返回结果比本地推理慢网络延迟、服务端排队、限流用 curl 查看 HTTP 响应耗时和状态码增加超时重试并避开服务高峰输出 token 数统计异常API 的 usage 字段可能不返回检查返回字段结构改为按输出字符数和采样算法估算或用服务端日志统计并发请求时性能大幅下降服务端资源被占满或限流观察每秒成功请求数控制并发加入退避重试调整 batch某些模型新推出但无法在特定推理平台上使用推理平台还没来得及适配模型查看官方模型支持列表改用已适配的模型或切换到其他平台这里的最重要建议是不要只看厂商宣传的倍率要自己在具体业务场景里做回归测试。因为你的输入、输出、并发模型和厂商测试环境很可能完全不同。8. 做推理选型时应该看哪些底层指标看完 Cerebras 的晶圆级架构回到普通开发者视角我们依然可以从中学到一套选择推理硬件的逻辑。第一看内存带宽。如果你的业务以长文本输出为主比如文档生成、Agent 对话、代码补全内存带宽比峰值算力更关键。带宽越高每 token 生成延迟越稳定。第二看内存容量。模型权重能放得下是第一步。如果单卡放不下就要评估多卡并行时的通信开销。这也是为什么很多推理服务追求“单卡装下模型不做张量并行”的原因省掉跨卡同步的时间。第三看批量处理能力。推理服务一般会通过 batch 动态合并提升吞吐这时候要关注服务端是否能高效处理多个并发请求。Cerebras 在大批量场景的片上调度优势对应到 GPU 平台就是 CUDA 的 batch manager、vLLM 的 continuous batching 等软件能力。第四看软件栈。硬件只是底座真正影响生产的是后端框架、量化工具、OpenAI 兼容 API、监控日志是否好用。如果每次上新模型都要烧一轮适配架构优势都会被运维成本抵消。9. 总结Cerebras 的晶圆级架构从物理层面改变了权重搬运方式这是它能在推理场景上跑出夸张倍率的根本原因。对于做应用层和推理服务的人这个案例最大的参考价值不是“买不买 Cerebras”而是让你重新审视自己项目的性能瓶颈到底在哪里。如果你现在跑大模型推理建议先做一个最简单的小测试用脚本记录 prefill 和 decode 两个阶段的耗时算一下每 token 平均生成速度。如果 decode 时间占比很高那就说明问题很可能出在内存带宽和权重访问上。这时候再调整模型精度、batch 策略、并行方式会比盲目升级显卡更有效。