前几天AI 芯片圈最热闹的一幕不是某家大厂又发布了千亿参数模型而是 NVIDIA LPX 性能信息公布后Cerebras 被 SemiAnalysis 公开批评为“疯狂 cope-tweeting”。Cerebras 的反应被定义为一种典型的“嘴硬式发推”舆论压力越大社交平台上的输出密度越高真正的技术论证却越来越模糊。围观者当然可以把这件事当成一场行业口水战。但如果只是看谁怼了谁就浪费了这次争论的真正价值。LPX 这个名字背后是 NVIDIA 对“AI 推理到底需要什么硬件”的重新定义Cerebras 的应激反应则暴露了以“晶圆级芯片”为核心叙事的新锐公司在巨头改变赛道规则时的真实压力。这篇文章不打算站队而是想把争论背后几个必须理解的技术问题讲清楚为什么 AI 推理正在遇到“带宽墙”LPX 的架构方向为什么会让 Cerebras 紧张WSE 的“单芯片巨无霸”路线和 LPX 的“专用线性处理器”路线本质差异在哪里作为普通开发者或技术决策者用什么框架去评估这类新芯片才不会被官方 PPT 和社交平台情绪带着走。1. 这场“Cope-tweeting”争论到底发生了什么先把事件中的三个主角说清楚。SemiAnalysis 是一家在半导体和 AI 基础设施领域很有影响力的独立研究机构由 Dylan Patel 创办。它长期追踪 GPU、ASIC、先进封装、数据中心功耗等话题在很多关键判断上准确率不低。它这次批评 Cerebras“疯狂 cope-tweeting”用词虽然带着网络嘲讽但在行业里不是普通自媒体式的互喷。Cerebras 是 AI 芯片创业公司里最特殊的存在之一。它没有走“小芯片并联”的路线而是把一整片晶圆做成一颗芯片也就是 WSEWafer Scale Engine。公开信息显示其 WSE-3 拥有约 90 万计算核心并配备大容量片上 SRAM。Cerebras 对外叙事一直是“大模型训练和推理不应继续被 NVIDIA GPU 垄断我们提供另一种选择。”NVIDIA LPX 则是这次争论的导火索。LPX 不是传统意义上“又一块更强 GPU”而是 NVIDIA 在推理方向上推出的“线性处理器”产品线。从公开宣传看它刻意脱离了“GPU 通用计算”的既有叙事把资源集中在 LLM 推理时真正密集的线性代数操作上强调推理吞吐、能效和每 Token 成本。事件本身并不复杂NVIDIA LPX 的性能信息公布后Cerebras 方面在社交平台上连续回应试图证明自己的方案仍然有优势。SemiAnalysis 则认为这种回应不是基于扎实的技术数据而是面对不利信息时的一种“情绪性补偿”因此用了 cope-tweeting 这个词来概括。对技术人来说真正值得关注的是这件事暴露出的矛盾点。Cerebras 过去挑战 NVIDIA 时最擅长的打法是用“单芯片性能数字”压制 GPU 服务器现在 NVIDIA 推出 LPX不是在 GPU 维度上继续堆核心而是承认“AI 推理需要专用架构”。于是 Cerebras 的差异化叙事被巨头用另一种方式接住了。2. LPX 冲击了 Cerebras 哪条叙事线2.1 “不用 GPU”的招牌被巨头接走Cerebras 过去面对客户时核心说服逻辑一直是“GPU 不适合 AI 推理至少不是最优解”。这个逻辑并非没有依据GPU 是通用并行计算架构早期设计是为了图形渲染和多用途计算。大模型训练阶段任务规模足够大可以把 GPU 的并行单元尽量填满但推理阶段尤其是单用户请求的低延迟场景GPU 的许多通用计算资源其实处于闲置状态。Cerebras 的晶圆级 WSE 芯片本质上是把“计算单元多”和“数据靠近计算”这两件事推到极致。它试图证明如果用一颗足够大的芯片把计算和存储塞在一起就不需要像 GPU 那样频繁地把权重从 HBM 搬到计算单元。这个方向确实有合理性Cerebras 也因此在一些公开测试中展示了不错的推理性能。但当 NVIDIA 推出 LPX 后Cerebras 面对的局势发生变化。过去市场上的选择是“通用 GPU”还是“非 GPU 专用芯片”Cerebras 站在后者阵营。现在 NVIDIA 自己跳出来说“推理场景下你们可以不用 GPU用我的 LPX。”这对 Cerebras 是釜底抽薪级别的冲击因为它面临的竞争不再是“不同技术路线之争”而是“同一路线里巨头也下场了”。2.2 从“单芯片最强”到“推理专用”的叙事落差Cerebras 还有一个长期使用的叙事优势单芯片规模最夸张。拿核心数量、片内存储、单芯片性能极限来对比确实很有视觉冲击力。但 LPX 的出现把话题从“谁的芯片更大”转向了“谁的方案在真实推理负载中更划算”。后一个话题恰恰是 NVIDIA 最擅长的战场。NVIDIA 有巨大的软件生态、成熟的数据中心供应链、丰富的部署经验以及客户已经习惯的开发流程。Cerebras 如果继续在社交平台上强调“我的核心数更多”反而容易被认为是在回避更关键的问题客户把你的芯片买回去迁移成本多少在标准模型上的持续推理吞吐是多少整柜功耗多少这也解释了为什么 SemiAnalysis 会用“cope”来形容 Cerebras。技术公司面对不利消息时正常的做法是给出可复现的对比数据或是指出对方对比方式中的具体问题。如果只是高强度发推重复“我们也很强”之类的观点在圈内人看来就属于情绪输出。3. 理解 LPX 必需的技术背景Transformer 推理的“带宽墙”3.1 为什么 decode 阶段不是算力瓶颈要理解 LPX 的架构思路先要理解 Transformer 推理的结构。一次完整的 LLM 推理通常分成两个阶段prefill 阶段处理用户输入的 prompt并行度较高decode 阶段逐个生成 token每个 token 生成都依赖上一 token 的输出。decode 阶段的问题在于计算任务串行化无法像训练阶段那样大规模并行。很多开发者以为推理速度取决于芯片的峰值算力也就是 TFLOPs。但 decode 阶段真正的瓶颈往往不是算力而是内存带宽。每生成一个 token模型都要把每一层权重从存储中取出来参与计算。当权重规模达到几十 GB而单次请求的 batch size 较小时权重搬运时间会远远超过实际计算时间。这里可以用一个极端类比帮助理解你有十个超级厉害的厨师但厨房只有一个很小的窗口可以递食材。每做一道菜厨师都要等食材从仓库一点点搬过来。这时候决定出餐速度的不是厨师人数而是那个窗口的搬运速度。对应到推理场景窗口就是芯片的内存带宽。3.2 用一段脚本理解权重读取量我们可以用一段简单的 Python 脚本估算运行不同规模模型时单个 token 生成所需的理论权重读取量。# decode_weight_estimate.py # 用途估算一次完整解码前向需要读取的模型权重总量 # 注意这是理论下限真实部署还会包含 KV Cache、激活值等开销 MODELS { Llama-3.1-8B: 8_000_000_000, Llama-3.1-70B: 70_000_000_000, Qwen2.5-72B: 72_000_000_000, } BYTES_PER_PARAM { FP16/BF16: 2, INT8: 1, FP8: 1, } def weight_bytes(param_count: int, bytes_per_param: int) - float: return param_count * bytes_per_param / (1024**3) # 转换为 GiB for model_name, params in MODELS.items(): for fmt, bpp in BYTES_PER_PARAM.items(): size_gib weight_bytes(params, bpp) print(f{model_name:18s} {fmt:10s} 约 {size_gib:10.2f} GiB)这段代码没有做任何复杂推演就是把一个容易被忽略的事实摆出来70B 量级模型即使用 INT8 量化单份权重也有约 65 GiB如果使用 BF16则接近 130 GiB。decode 阶段每生成一个 token理论上都要把这么大体量的权重从存储搬到计算单元一遍。实际场景中模型权重会有多级缓存并且当多个推理请求组成一个 batch 时权重读取会被分摊因此服务商可以通过增大 batch size 提高吞吐。但这不改变问题本质内存带宽和存储层级设计才是推理硬件能否高效工作的关键。3.3 从内存带宽推算推理吞吐上限假设一个硬件平台的内存带宽是 2 TB/s要运行一个 BF16 格式的 70B 模型权重体量约 130 GiB。那么单条请求的 decode 速度理论上限大约是2 TB/s ÷ 130 GiB ≈ 2,000 GiB/s ÷ 130 GiB ≈ 15.4 token/s这里还没有考虑 KV Cache、注意力计算、调度开销等额外成本。也就是说即使计算单元的 TFLOPs 高达天文数字如果内存带宽提不上去单流推理速度也会被死死压住。为了快速对比不同芯片的推理潜力可以继续用 Python 做一次粗略估算。注意这里的“带宽”需要替换成官方实测参数下面的代码只是演示评估方法。# decode_token_rate_estimate.py # 用途根据内存带宽和模型权重体量估算单流 decode 理论上限 # 免责声明真实系统受 batch、缓存、算子实现等因素影响本结果仅用于初步对比 def decode_token_rate(memory_bw_gibps: float, weight_gib: float) - float: return memory_bw_gibps / weight_gib NVIDIA_BW_SPEC_EXAMPLE 2000 # 单位 GiB/s仅为演示请按官方发布替换 CEREBRAS_SRAM_BW_EXAMPLE 8000 # 单位 GiB/s仅为演示请按官方发布替换 MODEL_WEIGHT_70B_BF16 130 # 单位 GiB约等于 70B * 2 Byte 后换算 for name, bw in [ (方案 A高算力低带宽, 2000), (方案 B更高内存带宽, 8000), ]: rate decode_token_rate(bw, MODEL_WEIGHT_70B_BF16) print(f{name}: 约 {rate:.1f} token/s)很多人看到“算力不如对手”时往往会担心但在 decode 场景下高带宽带来的收益可能比高算力更直观。LPX 这种专用推理处理器的价值恰恰在于它可以直接针对这个瓶颈做架构裁剪。4. 两条缓解“带宽墙”的路线WSE 的极端与 LPX 的“专门化”4.1 Cerebras WSE把存储和计算放得足够近Cerebras 应对带宽墙的思路很直接既然权重搬运慢那就把存储做得离计算足够近。WSE 通过晶圆级集成技术把巨大数量的计算核心和大容量片上 SRAM 放到同一颗芯片里。公开报道显示WSE-3 配备约 44 GB 的片上 SRAM这比绝大多数 GPU 的片上缓存大得多。SRAM 的速度远高于 HBM这确实有助于缓解权重搬运问题。但这条路线也有明显代价。晶圆级芯片的制造难度、良率、封装和散热问题都极其复杂最终产品往往需要定制服务器、特殊水冷方案部署形态和传统数据中心不兼容。另一个挑战是软件生态WSE 无法直接运行 CUDA 程序要发挥硬件性能需要投入大量工程力量做算子适配和工具链开发。从公开信息看Cerebras 的推理服务确实在一些模型上取得了让人印象深刻的成绩。但当 NVIDIA 这类公司下场做专用推理处理器时Cerebras 面对的将不只是“技术是否领先”的问题而是“客户是否愿意为一个新生态付出迁移成本”的问题。4.2 NVIDIA LPX用专用线性处理器重新定义推理单位关于 LPX 的详细硬件规格截至写作时公开信息仍然有限更完整的技术参数可能要等后续资料和实测数据。但从 NVIDIA 发布的架构理念和产品定位来看LPX 至少有两点值得关注。第一它不再把通用 GPU 当作 AI 推理的唯一答案。传统 GPU 的设计要兼顾图形、科学计算、通用并行等需求这些灵活性在 LLM 推理场景中会变成额外的芯片面积和功耗。LPX 如果只围绕“推理时最密集的矩阵和向量操作”来设计计算单元就可以把大量晶体管用在真正有价值的路径上。第二它的软件调度方式更像是面向大规模在线服务设计的而不是面向单一开发者的“显卡”。NVIDIA 生态中已经有很多推理优化工具LPX 大概率会延续这种体系通过标准的服务化接口对外提供能力底层可以调度多个线性处理器共同完成一个模型的推理请求。需要提醒的是LPX 目前还不能根据官方早期的性能数据直接判定为“已经超越谁”。新架构的成熟度、工具链完整性、真实负载下的表现都需要等更多资料甚至实物验证。4.3 竞争维度对比表为了让对比更直观下面用一张表格梳理两条路线的差异。由于 LPX 详细规格未完全公开表中更多描述的是“竞争逻辑”而不是精确参数。对比维度传统 NVIDIA GPU 路线Cerebras WSE 路线NVIDIA LPX 宣传方向设计哲学通用并行计算 Tensor Core晶圆级单芯片堆核心和片上存储面向推理的专用线性处理器核心卖点CUDA 生态成熟通用性好单芯片规模大存储距离近推理每瓦性能、每 Token 成本部署形态标准服务器即可使用需要定制机柜和水冷系统按 NVIDIA 数据中心体系规划软件生态CUDA支持广泛自有工具链与 CUDA 不兼容沿用 NVIDIA 软件体系迁移门槛较低典型适合场景训练 推理 科学计算超大模型训练/推理专用方案大规模 LLM 推理服务主要风险通用资源在低并发推理中闲置生态和部署门槛高新架构需要时间和实测验证这张表传递出的最重要信息是Cerebras 的 WSE 与 LPX 并不是同一个维度上的直接对手但它们都在争夺同一个客户心智——“如果你真的想把大模型推理成本降下来应该买什么设备”。5. LPX 的市场含义重新定义“买算力”的方式5.1 客户从“买卡”变成“买 Token 能力”过去采购 AI 算力惯例是先定型号、再按卡数下单。客户会说“我要 100 张 A100”或者“我要一个 8 卡 HGX 节点”。这种购买方式的支撑逻辑是GPU 是通用设备我买了它可以用来训练、做科学计算、跑各种负载未来需求变化还能复用。但当推理成为主要负载后客户真正需要购买的其实是“单位时间能处理多少 Token”以及“每百万 Token 的成本是多少”。算力指标退后内存带宽、实际服务吞吐、能效和运行稳定性成为更关键参数。LPX 如果真能把推理服务的单位成本降下来那客户就不需要再去关心它到底有多少个核心、主频多少。这种变化对 Cerebras 这种创业公司很残酷。它花了大量精力向市场解释“晶圆级芯片是多么先进”但当 NVIDIA 也拿出专用推理产品时客户会比价的方式不是看谁的芯片更具突破性而是看谁能在标准模型上跑出更低成本、更容易接入现有系统的结果。5.2 NVIDIA 的生态锁换产品线比换供应商更容易NVIDIA 最强的地方不只是硬件设计而是 CUDA 生态和整个数据中心软件栈。开发者写好的推理服务、调优好的算子、沉淀下来的监控告警体系都长在 NVIDIA 的软件体系上。如果 NVIDIA 推出 LPX老客户调整方案的成本远低于完全切换到一家新供应商的成本。恰恰因为这一点Cerebras 的回应才显得被动。它不是输在“芯片不够厉害”而是输在“客户切换供应商的成本极高”。社交平台上的发推无法解决这个结构性问题。6. Cerebras 更有效的应对方式不止是发推以下内容是基于公开竞争逻辑的技术策略推演不涉及任何内部消息只是给关注这场竞争的人提供一种分析视角。6.1 回到可控、可复现的第三方评测面对 LPX 的早期性能宣传Cerebras 最能建立信任的做法是发布一套可复现的第三方推理评测数据。测试模型要尽量贴近企业真实生产环境比如 Llama 3.1 70B、Qwen 2.5 72B 这类常见开源模型评测工具最好是行业公开使用的推理框架数据要包含不同并发下的吞吐、延迟曲线。这类评测比任何社交平台发言都更有说服力。客户并不需要一个“赢过 LPX”的结论他们需要的是能放进自己技术方案里评估的数据。6.2 把确定性延迟作为企业私有化卖点很多企业客户对公有云上的推理服务有顾虑核心原因就是性能不稳定GPU 共享、网络抖动、调度排队都会影响延迟。Cerebras 的一体化设备如果能提供更可预测、更稳定的延迟在金融、制造、企业私有化部署场景中是有差异化机会的。相比去和 NVIDIA 比拼全品类覆盖Cerebras 更适合聚焦“需要确定性延迟 愿意使用专用架构 对数据主权敏感”的客户。这类客户对“芯片革命”不一定感兴趣但很在意服务稳定性。6.3 不要把“方向差异”说成“技术碾压”在技术传播上Cerebras 需要避免一个陷阱把英伟达 LPX 的架构思路说成“抄袭”或“蹭热点”。因为 LPX 和大模型推理优化的整体方向本质上是行业共识。正确的表达方式是强调自己的方案在特定负载下的验证成绩而不是批评对方方向不对。一旦陷入方向之争讨论就会变成立场之争这对挑战者位置的公司没有好处。7. 开发者如何建立自己的芯片评估框架7.1 一句话识别营销话术新芯片发布时几乎所有官方宣传都带有选择性。普通开发者如果只看官方口径很容易把“特定条件下的最佳成绩”当成“所有场景下的平均表现”。下面是一张快速识别话术的对照表官方宣传口径你需要追问的问题“核心数是 XX 的 N 倍”单流解码时这些核心能被充分利用吗还是只能在极大 batch 下起作用“每瓦性能提升 X 倍”是否包含整机功耗、散热功耗对比的 batch size 是多少“训练速度是 A100 的 X 倍”是指单卡还是集群多卡扩展效率如何大模型下是否依然成立“推理吞吐提升 X 倍”用的什么模型什么精度什么并发是否包含前后处理时间“兼容 CUDA”是完全兼容还是需要大量迁移和适配这张表的核心不是否定厂商宣传而是提醒开发者任何脱离模型规模、batch size、内存带宽、功耗和数据精度来谈“性能翻倍”的说法都需要降低优先级。7.2 一个小型团队选型模板如果团队正在做推理基础设施选型可以先用一个 YAML 文件把硬性需求写清楚再分头收集候选平台的数据。这样讨论时不会只停留在“谁粉丝多”的层面。# hardware_eval_template.yaml # 用途团队推理硬件选型模板字段需要根据真实测试结果填写 workload: model_name: Llama-3.1-70B-Instruct precision: BF16 concurrency: 64 max_input_tokens: 4096 max_output_tokens: 2048 qps_target: 200 candidates: - name: candidate-a hardware_type: GPU mem_bw_gbps: 0 # 待填官方或实测内存带宽 decode_token_rate: 0 # 待填单流 decode 实测 sustained_qps: 0 # 待填目标并发下的真实 QPS power_per_node_w: 0 # 待填单节点整机功耗 software_migration_cost: low/medium/high notes: - name: candidate-b hardware_type: ASIC mem_bw_gbps:
前几天AI 芯片圈最热闹的一幕不是某家大厂又发布了千亿参数模型而是 NVIDIA LPX 性能信息公布后Cerebras 被 SemiAnalysis 公开批评为“疯狂 cope-tweeting”。Cerebras 的反应被定义为一种典型的“嘴硬式发推”舆论压力越大社交平台上的输出密度越高真正的技术论证却越来越模糊。围观者当然可以把这件事当成一场行业口水战。但如果只是看谁怼了谁就浪费了这次争论的真正价值。LPX 这个名字背后是 NVIDIA 对“AI 推理到底需要什么硬件”的重新定义Cerebras 的应激反应则暴露了以“晶圆级芯片”为核心叙事的新锐公司在巨头改变赛道规则时的真实压力。这篇文章不打算站队而是想把争论背后几个必须理解的技术问题讲清楚为什么 AI 推理正在遇到“带宽墙”LPX 的架构方向为什么会让 Cerebras 紧张WSE 的“单芯片巨无霸”路线和 LPX 的“专用线性处理器”路线本质差异在哪里作为普通开发者或技术决策者用什么框架去评估这类新芯片才不会被官方 PPT 和社交平台情绪带着走。1. 这场“Cope-tweeting”争论到底发生了什么先把事件中的三个主角说清楚。SemiAnalysis 是一家在半导体和 AI 基础设施领域很有影响力的独立研究机构由 Dylan Patel 创办。它长期追踪 GPU、ASIC、先进封装、数据中心功耗等话题在很多关键判断上准确率不低。它这次批评 Cerebras“疯狂 cope-tweeting”用词虽然带着网络嘲讽但在行业里不是普通自媒体式的互喷。Cerebras 是 AI 芯片创业公司里最特殊的存在之一。它没有走“小芯片并联”的路线而是把一整片晶圆做成一颗芯片也就是 WSEWafer Scale Engine。公开信息显示其 WSE-3 拥有约 90 万计算核心并配备大容量片上 SRAM。Cerebras 对外叙事一直是“大模型训练和推理不应继续被 NVIDIA GPU 垄断我们提供另一种选择。”NVIDIA LPX 则是这次争论的导火索。LPX 不是传统意义上“又一块更强 GPU”而是 NVIDIA 在推理方向上推出的“线性处理器”产品线。从公开宣传看它刻意脱离了“GPU 通用计算”的既有叙事把资源集中在 LLM 推理时真正密集的线性代数操作上强调推理吞吐、能效和每 Token 成本。事件本身并不复杂NVIDIA LPX 的性能信息公布后Cerebras 方面在社交平台上连续回应试图证明自己的方案仍然有优势。SemiAnalysis 则认为这种回应不是基于扎实的技术数据而是面对不利信息时的一种“情绪性补偿”因此用了 cope-tweeting 这个词来概括。对技术人来说真正值得关注的是这件事暴露出的矛盾点。Cerebras 过去挑战 NVIDIA 时最擅长的打法是用“单芯片性能数字”压制 GPU 服务器现在 NVIDIA 推出 LPX不是在 GPU 维度上继续堆核心而是承认“AI 推理需要专用架构”。于是 Cerebras 的差异化叙事被巨头用另一种方式接住了。2. LPX 冲击了 Cerebras 哪条叙事线2.1 “不用 GPU”的招牌被巨头接走Cerebras 过去面对客户时核心说服逻辑一直是“GPU 不适合 AI 推理至少不是最优解”。这个逻辑并非没有依据GPU 是通用并行计算架构早期设计是为了图形渲染和多用途计算。大模型训练阶段任务规模足够大可以把 GPU 的并行单元尽量填满但推理阶段尤其是单用户请求的低延迟场景GPU 的许多通用计算资源其实处于闲置状态。Cerebras 的晶圆级 WSE 芯片本质上是把“计算单元多”和“数据靠近计算”这两件事推到极致。它试图证明如果用一颗足够大的芯片把计算和存储塞在一起就不需要像 GPU 那样频繁地把权重从 HBM 搬到计算单元。这个方向确实有合理性Cerebras 也因此在一些公开测试中展示了不错的推理性能。但当 NVIDIA 推出 LPX 后Cerebras 面对的局势发生变化。过去市场上的选择是“通用 GPU”还是“非 GPU 专用芯片”Cerebras 站在后者阵营。现在 NVIDIA 自己跳出来说“推理场景下你们可以不用 GPU用我的 LPX。”这对 Cerebras 是釜底抽薪级别的冲击因为它面临的竞争不再是“不同技术路线之争”而是“同一路线里巨头也下场了”。2.2 从“单芯片最强”到“推理专用”的叙事落差Cerebras 还有一个长期使用的叙事优势单芯片规模最夸张。拿核心数量、片内存储、单芯片性能极限来对比确实很有视觉冲击力。但 LPX 的出现把话题从“谁的芯片更大”转向了“谁的方案在真实推理负载中更划算”。后一个话题恰恰是 NVIDIA 最擅长的战场。NVIDIA 有巨大的软件生态、成熟的数据中心供应链、丰富的部署经验以及客户已经习惯的开发流程。Cerebras 如果继续在社交平台上强调“我的核心数更多”反而容易被认为是在回避更关键的问题客户把你的芯片买回去迁移成本多少在标准模型上的持续推理吞吐是多少整柜功耗多少这也解释了为什么 SemiAnalysis 会用“cope”来形容 Cerebras。技术公司面对不利消息时正常的做法是给出可复现的对比数据或是指出对方对比方式中的具体问题。如果只是高强度发推重复“我们也很强”之类的观点在圈内人看来就属于情绪输出。3. 理解 LPX 必需的技术背景Transformer 推理的“带宽墙”3.1 为什么 decode 阶段不是算力瓶颈要理解 LPX 的架构思路先要理解 Transformer 推理的结构。一次完整的 LLM 推理通常分成两个阶段prefill 阶段处理用户输入的 prompt并行度较高decode 阶段逐个生成 token每个 token 生成都依赖上一 token 的输出。decode 阶段的问题在于计算任务串行化无法像训练阶段那样大规模并行。很多开发者以为推理速度取决于芯片的峰值算力也就是 TFLOPs。但 decode 阶段真正的瓶颈往往不是算力而是内存带宽。每生成一个 token模型都要把每一层权重从存储中取出来参与计算。当权重规模达到几十 GB而单次请求的 batch size 较小时权重搬运时间会远远超过实际计算时间。这里可以用一个极端类比帮助理解你有十个超级厉害的厨师但厨房只有一个很小的窗口可以递食材。每做一道菜厨师都要等食材从仓库一点点搬过来。这时候决定出餐速度的不是厨师人数而是那个窗口的搬运速度。对应到推理场景窗口就是芯片的内存带宽。3.2 用一段脚本理解权重读取量我们可以用一段简单的 Python 脚本估算运行不同规模模型时单个 token 生成所需的理论权重读取量。# decode_weight_estimate.py # 用途估算一次完整解码前向需要读取的模型权重总量 # 注意这是理论下限真实部署还会包含 KV Cache、激活值等开销 MODELS { Llama-3.1-8B: 8_000_000_000, Llama-3.1-70B: 70_000_000_000, Qwen2.5-72B: 72_000_000_000, } BYTES_PER_PARAM { FP16/BF16: 2, INT8: 1, FP8: 1, } def weight_bytes(param_count: int, bytes_per_param: int) - float: return param_count * bytes_per_param / (1024**3) # 转换为 GiB for model_name, params in MODELS.items(): for fmt, bpp in BYTES_PER_PARAM.items(): size_gib weight_bytes(params, bpp) print(f{model_name:18s} {fmt:10s} 约 {size_gib:10.2f} GiB)这段代码没有做任何复杂推演就是把一个容易被忽略的事实摆出来70B 量级模型即使用 INT8 量化单份权重也有约 65 GiB如果使用 BF16则接近 130 GiB。decode 阶段每生成一个 token理论上都要把这么大体量的权重从存储搬到计算单元一遍。实际场景中模型权重会有多级缓存并且当多个推理请求组成一个 batch 时权重读取会被分摊因此服务商可以通过增大 batch size 提高吞吐。但这不改变问题本质内存带宽和存储层级设计才是推理硬件能否高效工作的关键。3.3 从内存带宽推算推理吞吐上限假设一个硬件平台的内存带宽是 2 TB/s要运行一个 BF16 格式的 70B 模型权重体量约 130 GiB。那么单条请求的 decode 速度理论上限大约是2 TB/s ÷ 130 GiB ≈ 2,000 GiB/s ÷ 130 GiB ≈ 15.4 token/s这里还没有考虑 KV Cache、注意力计算、调度开销等额外成本。也就是说即使计算单元的 TFLOPs 高达天文数字如果内存带宽提不上去单流推理速度也会被死死压住。为了快速对比不同芯片的推理潜力可以继续用 Python 做一次粗略估算。注意这里的“带宽”需要替换成官方实测参数下面的代码只是演示评估方法。# decode_token_rate_estimate.py # 用途根据内存带宽和模型权重体量估算单流 decode 理论上限 # 免责声明真实系统受 batch、缓存、算子实现等因素影响本结果仅用于初步对比 def decode_token_rate(memory_bw_gibps: float, weight_gib: float) - float: return memory_bw_gibps / weight_gib NVIDIA_BW_SPEC_EXAMPLE 2000 # 单位 GiB/s仅为演示请按官方发布替换 CEREBRAS_SRAM_BW_EXAMPLE 8000 # 单位 GiB/s仅为演示请按官方发布替换 MODEL_WEIGHT_70B_BF16 130 # 单位 GiB约等于 70B * 2 Byte 后换算 for name, bw in [ (方案 A高算力低带宽, 2000), (方案 B更高内存带宽, 8000), ]: rate decode_token_rate(bw, MODEL_WEIGHT_70B_BF16) print(f{name}: 约 {rate:.1f} token/s)很多人看到“算力不如对手”时往往会担心但在 decode 场景下高带宽带来的收益可能比高算力更直观。LPX 这种专用推理处理器的价值恰恰在于它可以直接针对这个瓶颈做架构裁剪。4. 两条缓解“带宽墙”的路线WSE 的极端与 LPX 的“专门化”4.1 Cerebras WSE把存储和计算放得足够近Cerebras 应对带宽墙的思路很直接既然权重搬运慢那就把存储做得离计算足够近。WSE 通过晶圆级集成技术把巨大数量的计算核心和大容量片上 SRAM 放到同一颗芯片里。公开报道显示WSE-3 配备约 44 GB 的片上 SRAM这比绝大多数 GPU 的片上缓存大得多。SRAM 的速度远高于 HBM这确实有助于缓解权重搬运问题。但这条路线也有明显代价。晶圆级芯片的制造难度、良率、封装和散热问题都极其复杂最终产品往往需要定制服务器、特殊水冷方案部署形态和传统数据中心不兼容。另一个挑战是软件生态WSE 无法直接运行 CUDA 程序要发挥硬件性能需要投入大量工程力量做算子适配和工具链开发。从公开信息看Cerebras 的推理服务确实在一些模型上取得了让人印象深刻的成绩。但当 NVIDIA 这类公司下场做专用推理处理器时Cerebras 面对的将不只是“技术是否领先”的问题而是“客户是否愿意为一个新生态付出迁移成本”的问题。4.2 NVIDIA LPX用专用线性处理器重新定义推理单位关于 LPX 的详细硬件规格截至写作时公开信息仍然有限更完整的技术参数可能要等后续资料和实测数据。但从 NVIDIA 发布的架构理念和产品定位来看LPX 至少有两点值得关注。第一它不再把通用 GPU 当作 AI 推理的唯一答案。传统 GPU 的设计要兼顾图形、科学计算、通用并行等需求这些灵活性在 LLM 推理场景中会变成额外的芯片面积和功耗。LPX 如果只围绕“推理时最密集的矩阵和向量操作”来设计计算单元就可以把大量晶体管用在真正有价值的路径上。第二它的软件调度方式更像是面向大规模在线服务设计的而不是面向单一开发者的“显卡”。NVIDIA 生态中已经有很多推理优化工具LPX 大概率会延续这种体系通过标准的服务化接口对外提供能力底层可以调度多个线性处理器共同完成一个模型的推理请求。需要提醒的是LPX 目前还不能根据官方早期的性能数据直接判定为“已经超越谁”。新架构的成熟度、工具链完整性、真实负载下的表现都需要等更多资料甚至实物验证。4.3 竞争维度对比表为了让对比更直观下面用一张表格梳理两条路线的差异。由于 LPX 详细规格未完全公开表中更多描述的是“竞争逻辑”而不是精确参数。对比维度传统 NVIDIA GPU 路线Cerebras WSE 路线NVIDIA LPX 宣传方向设计哲学通用并行计算 Tensor Core晶圆级单芯片堆核心和片上存储面向推理的专用线性处理器核心卖点CUDA 生态成熟通用性好单芯片规模大存储距离近推理每瓦性能、每 Token 成本部署形态标准服务器即可使用需要定制机柜和水冷系统按 NVIDIA 数据中心体系规划软件生态CUDA支持广泛自有工具链与 CUDA 不兼容沿用 NVIDIA 软件体系迁移门槛较低典型适合场景训练 推理 科学计算超大模型训练/推理专用方案大规模 LLM 推理服务主要风险通用资源在低并发推理中闲置生态和部署门槛高新架构需要时间和实测验证这张表传递出的最重要信息是Cerebras 的 WSE 与 LPX 并不是同一个维度上的直接对手但它们都在争夺同一个客户心智——“如果你真的想把大模型推理成本降下来应该买什么设备”。5. LPX 的市场含义重新定义“买算力”的方式5.1 客户从“买卡”变成“买 Token 能力”过去采购 AI 算力惯例是先定型号、再按卡数下单。客户会说“我要 100 张 A100”或者“我要一个 8 卡 HGX 节点”。这种购买方式的支撑逻辑是GPU 是通用设备我买了它可以用来训练、做科学计算、跑各种负载未来需求变化还能复用。但当推理成为主要负载后客户真正需要购买的其实是“单位时间能处理多少 Token”以及“每百万 Token 的成本是多少”。算力指标退后内存带宽、实际服务吞吐、能效和运行稳定性成为更关键参数。LPX 如果真能把推理服务的单位成本降下来那客户就不需要再去关心它到底有多少个核心、主频多少。这种变化对 Cerebras 这种创业公司很残酷。它花了大量精力向市场解释“晶圆级芯片是多么先进”但当 NVIDIA 也拿出专用推理产品时客户会比价的方式不是看谁的芯片更具突破性而是看谁能在标准模型上跑出更低成本、更容易接入现有系统的结果。5.2 NVIDIA 的生态锁换产品线比换供应商更容易NVIDIA 最强的地方不只是硬件设计而是 CUDA 生态和整个数据中心软件栈。开发者写好的推理服务、调优好的算子、沉淀下来的监控告警体系都长在 NVIDIA 的软件体系上。如果 NVIDIA 推出 LPX老客户调整方案的成本远低于完全切换到一家新供应商的成本。恰恰因为这一点Cerebras 的回应才显得被动。它不是输在“芯片不够厉害”而是输在“客户切换供应商的成本极高”。社交平台上的发推无法解决这个结构性问题。6. Cerebras 更有效的应对方式不止是发推以下内容是基于公开竞争逻辑的技术策略推演不涉及任何内部消息只是给关注这场竞争的人提供一种分析视角。6.1 回到可控、可复现的第三方评测面对 LPX 的早期性能宣传Cerebras 最能建立信任的做法是发布一套可复现的第三方推理评测数据。测试模型要尽量贴近企业真实生产环境比如 Llama 3.1 70B、Qwen 2.5 72B 这类常见开源模型评测工具最好是行业公开使用的推理框架数据要包含不同并发下的吞吐、延迟曲线。这类评测比任何社交平台发言都更有说服力。客户并不需要一个“赢过 LPX”的结论他们需要的是能放进自己技术方案里评估的数据。6.2 把确定性延迟作为企业私有化卖点很多企业客户对公有云上的推理服务有顾虑核心原因就是性能不稳定GPU 共享、网络抖动、调度排队都会影响延迟。Cerebras 的一体化设备如果能提供更可预测、更稳定的延迟在金融、制造、企业私有化部署场景中是有差异化机会的。相比去和 NVIDIA 比拼全品类覆盖Cerebras 更适合聚焦“需要确定性延迟 愿意使用专用架构 对数据主权敏感”的客户。这类客户对“芯片革命”不一定感兴趣但很在意服务稳定性。6.3 不要把“方向差异”说成“技术碾压”在技术传播上Cerebras 需要避免一个陷阱把英伟达 LPX 的架构思路说成“抄袭”或“蹭热点”。因为 LPX 和大模型推理优化的整体方向本质上是行业共识。正确的表达方式是强调自己的方案在特定负载下的验证成绩而不是批评对方方向不对。一旦陷入方向之争讨论就会变成立场之争这对挑战者位置的公司没有好处。7. 开发者如何建立自己的芯片评估框架7.1 一句话识别营销话术新芯片发布时几乎所有官方宣传都带有选择性。普通开发者如果只看官方口径很容易把“特定条件下的最佳成绩”当成“所有场景下的平均表现”。下面是一张快速识别话术的对照表官方宣传口径你需要追问的问题“核心数是 XX 的 N 倍”单流解码时这些核心能被充分利用吗还是只能在极大 batch 下起作用“每瓦性能提升 X 倍”是否包含整机功耗、散热功耗对比的 batch size 是多少“训练速度是 A100 的 X 倍”是指单卡还是集群多卡扩展效率如何大模型下是否依然成立“推理吞吐提升 X 倍”用的什么模型什么精度什么并发是否包含前后处理时间“兼容 CUDA”是完全兼容还是需要大量迁移和适配这张表的核心不是否定厂商宣传而是提醒开发者任何脱离模型规模、batch size、内存带宽、功耗和数据精度来谈“性能翻倍”的说法都需要降低优先级。7.2 一个小型团队选型模板如果团队正在做推理基础设施选型可以先用一个 YAML 文件把硬性需求写清楚再分头收集候选平台的数据。这样讨论时不会只停留在“谁粉丝多”的层面。# hardware_eval_template.yaml # 用途团队推理硬件选型模板字段需要根据真实测试结果填写 workload: model_name: Llama-3.1-70B-Instruct precision: BF16 concurrency: 64 max_input_tokens: 4096 max_output_tokens: 2048 qps_target: 200 candidates: - name: candidate-a hardware_type: GPU mem_bw_gbps: 0 # 待填官方或实测内存带宽 decode_token_rate: 0 # 待填单流 decode 实测 sustained_qps: 0 # 待填目标并发下的真实 QPS power_per_node_w: 0 # 待填单节点整机功耗 software_migration_cost: low/medium/high notes: - name: candidate-b hardware_type: ASIC mem_bw_gbps:
