从Rubin CPX看推理预填充芯片：prefill阶段的设计与验证

最近一条关于“英伟达重启推理预填充芯片 Rubin CPX 项目设计大幅调整”的消息让不少做 AI 基础设施、GPU 集群和大模型推理的同学开始重新审视一个原本只出现在论文和框架源码里的概念prefill。过去我们在部署大模型服务时只会笼统地说“推理负载很重、显存不够、算力吃紧”。但拆开看生成式推理其实包含两个性格完全不同的阶段预填充阶段和自回归解码阶段。它们对算力、显存带宽、KV Cache 管理乃至网络拓扑的要求并不一致。如果芯片在定义阶段就针对预填充重新做资源划分和互连设计那软件层需要考虑的调度策略、性能基准和故障排查方式也要跟着调整。这篇文章会把话题拆开讲清楚先解释为什么“推理预填充芯片”可以作为一个独立产品方向存在再看 Rubin CPX 这类项目在芯片层面“大幅调整”通常意味着哪些设计取舍然后落脚到做推理平台的开发者如何用可复现的思路去验证算力、显存和时延而不是只围绕传闻转圈。对于底层芯片的最终参数目前公开可考的信息仍然有限文中提到的工程方法和监控路径是用来帮你判断真实产品发布后它该跑在哪类场景、该怎么测、怎么排错。1. 为什么推理要单独拆出“预填充”这个阶段1.1 大模型生成的每一轮请求都包含两种计算形态以典型的 LLM 推理请求为例客户端输入一段 prompt模型需要先完成一次并行计算把整段输入的历史信息编码成中间状态这段过程生成第一个输出 token。之后模型进入逐 token 解码状态每生成一个 token都要重复读取当前的 KV Cache并根据上一个输出 token 继续解码。前一段在推理术语中通常叫 prefill后一段叫 decode。为什么前一段和后一段不能简单看成“一个很长的计算过程”因为它们的计算特征完全不同。Prefill 阶段输入序列可以被切成多个 batch 维度并行处理GPU 或专用 AI 加速器此时可以把利用率拉得很高矩阵乘法是主要操作计算密度远高于访存压力。而 decode 阶段输出长度是串行的每一步计算都高度依赖上一个 token 的结果无法在 token 维度上直接并行大多数时候瓶颈出在显存带宽和 KV Cache 访问延迟上。如果模型服务不做任何调度优化把 prefill 和 decode 混在同一个实例里慢请求会拖住快速解码GPU 利用率和用户时延都会受影响。在工程上业界已经普遍接受“PD 分离”的做法预填充阶段用一批实例专门处理长 prompt把生成的 KV Cache 传给解码实例继续输出。这样预填充实例可以按高计算吞吐设计解码实例可以按高显存带宽设计调度器再负责流转。标题里说的“推理预填充芯片”本质上就是面向 PD 分离架构中“预处理那一段”的专用加速产品方向。1.2 prefill 阶段对芯片提出的是“高算力浓度 大 KV Cache 承载”双重要求如果只谈矩阵乘法普通人会以为 prefill 芯片只需要堆算力。但实际推理服务不可能只算不存。一次长文档问答的输入可能达到几万甚至十几万 token模型每计算一层都需要把输入序列对应的 K 矩阵和 V 矩阵展开并缓存到显存里。这个缓存在后续 decode 阶段还要复用到最后一个 token 生成完毕。因此芯片的设计者不能只考虑 FP8 或 FP16 的稠密计算峰值还要回答一个很现实的问题一个物理卡上能同时容纳多长的输入序列、多少个并发请求KV Cache 能不能在片内高速存储与主存之间平滑换入换出。这也解释了为什么设计“大幅调整”会牵一发动全身。提高计算能力可以靠增加计算核心、拉高频率或更新制程。但要让 KV Cache 放得下就必须同时调整 HBM 容量、片内 SRAM 容量、存储控制器策略和互联带宽。只加大计算部件而显存没有跟上prefill 在高并发场景下还是会因为内存瓶颈把吞吐拉低。1.3 从 Rubin 到 CPX 的命名关键不是产品名而是产品切法Ampere 时代之后英伟达数据中心的加速卡产品线越来越像一套覆盖训练、推理、网络、CPU 的系统族。Hopper、Blackwell 之后进入 Rubin 架构属于正常的产品演进。而 Rubin CPX 如果被独立描述成“推理预填充芯片”说明它不是在现有 GPU 上做一个小改款而是在架构图里被单独划出了一类加速器。产品切得越细越说明推理负载已经从“AI 应用的附属环节”变成了可以左右硬件定义的核心场景。这里有一个容易混淆的地方CPX 并不等于 CPU也不是“前一代 GPU 改名”。从行业惯例看CPX 更像“Compute Precision/Processing Complex”一类的加速组件核心目标是把 prefill 需要的计算、存储和互联能力集中在一个封装或一个计算节点里。普通软件开发者接触不到它的寄存器级配置但接触得到它的运行时抽象层、驱动接口或上层框架暴露出来的显存与队列管理能力。因此后面讨论技术细节时不要总盯着“哪张卡更厉害”而要看“它能不能让 prefill 阶段的吞吐、时延和显存占用变得可预期”。2. 一次“设计大幅调整”在芯片工程里意味着什么2.1 芯片阶段的设计调整远不止“改一版参数”这么简单任何高性能计算芯片从需求定义到量产回片都要经过长期的架构评估、寄存器传输级实现、物理设计、仿真验证、流片与测试。所谓“重启项目”通常不是因为上层想换一个宣传名而是架构团队重新评估后认为原本的产品定义无法满足真实负载返工范围涉及多个层级产品与系统架构层算力、显存、带宽、功耗、价格的目标值需要重新平衡。微架构层计算单元数量、张量核或加速器的排布、不同精度的支持方式要改。缓存与存储层L2 Cache 大小、HBM 通道数、SRAM 与外部存储之间的数据通路会调整。板卡与系统集成层散热方案、电源供电、与主机之间的 PCIe/C2C 链路带宽也随之变化。在大多数行业中“设计重启”是成本极高的决定。只有产品团队确信现有方案在成本、性能或系统适配度上无法满足目标场景才会在尚未量产前推倒一部分设计。因此消息里最关键的不是“重启”这个动作而是背后提到的“设计大幅调整”真正调整了什么。2.2 prefill 负载最容易逼着设计团队改掉哪些既有假设第一个容易调整的是“计算与存储的比例”。如果一款加速芯片最初是按训练场景定义就会把计算峰值设计得很高、显存带宽按训练梯度流的模式优化。但 prefill 场景多了一个长期驻留的 KV Cache同一块物理卡如果 cache 占用过高能同时跑的 batch 大小就会下降。设计团队要么把容量做大要么把计算和存储拆成独立的层次否则无法支撑单请求数万 token 的输入。第二个容易调整的是“互联带宽”。PD 分离架构要求 prefill 芯片把产出的 KV Cache 通过网络搬运给 decode 实例。如果片间互联带宽不足KV Cache 的转移时延会直接加到用户可感知的首 token 时延上。第三个调整点是“软件自动化的粒度”。芯片如果为 prefill 做了很特殊的控制流编译器、推理引擎、Kernel 库都得更深地适配不是拿通用 CUDA 代码重新编译一遍就能发挥效果。可以这样理解架构师在设计芯片时要同时回答四个问题算一次矩阵乘法要多久一批 KV Cache 要放在哪里算完的结果怎么交给下一段计算整套流程在极端请求下会不会失控。任何一处的答案被真实负载否定设计就要返工。联想我们日常调优一个推荐系统只提高单机 QPS 往往没用下游存储、网络拉取和超时策略会共同锁死瓶颈。2.3 当前公开信息有限技术判断要守住可验证边界从公开渠道来看现阶段的信息更多是行业推测和早期爆料而不是官方产品手册。写工程博客时一个很重要的习惯是把“传闻中的调整方向”和“可验证的技术机制”分开。我们可以分析一款为 prefill 定制的加速芯片需要具备什么特征但不应该把具体数值当作已经量产的规格来引用。评估这类产品时最可靠的信息来源是厂商发布的产品白皮书和架构文档。官方驱动与推理框架的 release note。第三方基准测试结果比如 MLPerf 推理项目。自己团队在测试平台上跑出的真实吞吐与时延曲线。在更底层的信息补齐前建议把讨论聚焦在机制与工程设计方法上。这样即便项目最终没有按传闻方向落地你得到的分析思路和验证手段也不会过时。3. 面向 prefill 调优时服务器系统该怎么拆开看3.1 训练、prefill、decode 三类负载的资源画像对比这里不引入具体的未发布产品而是用通用 AI 服务器视角画出三类负载的轮廓帮助判断某一块加速芯片到底适合放在哪个位置。假设模型是稠密 Transformer 架构下表可以在需求评审时当作讨论框架维度训练PrefillDecode主要瓶颈多卡并行通信与算力算力、HBM 容量、片间搬运显存带宽、KV Cache 访问延迟计算并行度极高数据/张量/流水并行可在序列与 batch 维度并行Token 间依赖串行窗口内并行存储热点梯度、优化器状态、中间激活输入 token 的 K/V 中间结果已生成历史对应的 KV Cache时延敏感维度训练吞吐单步时间稳定首 token 前整段处理时间每 token 平均生成时间典型系统痛点通信拥塞、负载不均长 prompt 容易 OOM、计算空转并发升高时显存带宽被抢从这个表可以看出把推理拆成专门芯片时prefill 和 decode 对“高算力”的需求方向并不完全一样。prefill 更接近训练的前向过程但它并不需要考虑反向传播与梯度同步因此可以把更多晶体管预算转向长序列的中间状态管理。decode 则更像一个访存密集型程序单次矩阵规模小依赖快速读取已缓存内容。所以当一款产品名称里带上“推理预填充”这几个字读者对它应该抱有的预期是它在 prefill 计算吞吐、长序列承载能力和 KV Cache 管理上一定做了明显取舍而不是全能型替代。3.2 prefill 服务的关键子模块调度器、缓存管理器和传输层从软件系统角度看prefill 芯片是否好用除了硬件流片质量还要看几个配套模块能不能配合。第一是调度器。PD 分离后调度器负责把长 prompt 请求路由给 prefill 实例再根据 KV Cache 的分布决定后续输出任务交给哪个 decode 实例。这里的关键参数不是单一队列深度而是每个实例的“当前 KV 吞吐压力”和“剩余 buffer 容量”。第二是缓存管理器。KV Cache 不能无限放大缓存管理器需要维护空闲块列表、引用计数和淘汰策略必要时把冷数据换出到主存或远端。所谓“大幅重新设计”很多时候就是在缓存管理指令上做了更高效的异步操作让计算单元不用空等着缓存写入完成。第三是传输层。KV Cache 的体积往往比输入文本本身大几个数量级因此 prefill 结果从计算芯粒传输到解码芯粒的时间不能忽略。芯片如果支持 RDMA、NVLink 或 C2C 一类的紧耦合传输数据搬运延迟会显著下降。如果你维护的是一个普通的 GPU 推理服务没有专用芯片那么这些模块仍然存在只是被 vLLM、SGLang、Triton 等框架抽象了。理解这些模块能帮助你判断新硬件接入后应该由哪层软件负责导出 KV Cache以及出现性能回退时先查哪个组件。3.3 一个模拟 prefill 资源效果的最小实验思路在没有真实 Rubin CPX 硬件时仍然可以量化理解“prefill 到底吃了什么”。以 PyTorch 为例可以单独生成一个 batch 的长序列输入只运行模型的前向过程到 logits 计算结束并记录显存和时延这样就能大致摸清本机 prefill 的资源边界。下面是一段用于基准测试的示意代码实际项目需要按模型路径和 tokenizer 调整。import time import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_name Qwen/Qwen2.5-7B-Instruct tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name, torch_dtypetorch.float16).cuda() model.eval() prompt 技术博客写作需要结构清晰、内容具体。 * 2000 inputs tokenizer(prompt, return_tensorspt).to(cuda) # 清空缓存统计基线 torch.cuda.reset_peak_memory_stats() torch.cuda.synchronize() start time.perf_counter() with torch.no_grad(): outputs model(**inputs, use_cacheTrue) torch.cuda.synchronize() elapsed time.perf_counter() - start peak_memory torch.cuda.max_memory_allocated() / 1024**3 print(finput_tokens: {inputs[input_ids].shape[1]}) print(fprefill_time_seconds: {elapsed:.3f}) print(fpeak_memory_gib: {peak_memory:.2f})这段代码的重点不是测出一个“标准答案”而是建立一套可以在多台机器上重复运行的 baseline。记录输入 token 数、耗时和峰值显存后再改 batch size 或 prompt 长度就能画出一条显存增长曲线。真实 prefill 芯片发布后同样的脚本可以作为最粗粒度的对照实验同样的模型和输入长度观察耗时与显存变化。注意不要在生成环境里直接拿生产模型做长 prompt 压测。先用一个单独的推理池或容器环境验证脚本本身稳定再逐步加大输入长度避免把在线服务打满。4. 拿到新芯片后如何在软件层做系统性验证4.1 从“能跑通”到“可量化”你需要建立三层验证路径芯片工程师回片之后要上电测试软件开发者拿到新硬件之后同样有验证路径。最浅的一层是跑通一个 demo能够启动模型并输出文本。这一层只能证明驱动、框架和模型兼容性没有大的问题不能证明硬件在 prefill 场景有优势。第二层是基准回归。固定模型、固定输入长度、固定 batch size重复跑推理若干次对比不同硬件的平均吞吐和 P95/P99 时延。第三层是系统压测。加入多路请求、长 token 输入、KV Cache 超限和网络传输等情形观察整个推理系统在边缘情况下会不会崩溃或性能断崖。很多团队拿到新开发板或新计算卡时只做了第一层然后就把“能生成文本”误当成“性能符合预期”。一段有质量的验证记录至少应包含模型版本、精度、并发数、请求长度分布、KV Cache 策略、硬件的频率与功耗模式、驱动与框架版本。少了这些信息任何结论都无法被复现。4.2 收集 prefill 阶段关键指标时按这个清单记录无论是用 NVIDIA 系列硬件还是未来其他推理加速卡你都应该形成一套固定采集指标。其中几个与 prefill 阶段关系最密切的指标如下指标名称含义推荐判断方式Prefill 总耗时从输入完整进入引擎到首 token 可生成的时间观察 P95避免只看平均Prefill 吞吐单位时间内处理的输入 token 数token/s按序列长度分段统计KV Cache 峰值占用单请求或并发请求下缓存占用峰值对照次数的显存容量显存带宽利用率实际访问带宽与理论带宽的比值结合 NCU 或类似性能分析工具计算单元利用率SM 或加速核心繁忙占比长时间低于阈值说明调度或存储瓶颈片间传输耗时KV Cache 从 prefill 实例传给 decode 实例的耗时与模型计算耗时分开记录功耗与结温高负载下是否接近热节流阈值观察时钟频率是否被压制不同厂家的性能工具不同NVIDIA 场景下可以用 nsys 与 ncu 分别做系统级和内核级分析。命令示例可以这样拆# 系统级分析看总体时间线、CPU/GPU 交互、显存复制 nsys profile --tracecuda,nvtx,osrt -o prefill_profile ./run_prefill_bench.py # 内核级分析挑重点 kernel 计算与访存指标 ncu --set full --kernel-name regex:matmul -o prefill_kernel ./run_prefill_bench.py跑完后重点看两部分时间线里是否存在大段 GPU 空闲以及 matmul 类 kernel 的“计算吞吐”和“显存吞吐”是否达到该硬件的可用峰值。如果计算利用率很高但整体耗时仍然很长说明 batch 大小或序列长度已经让总线成为瓶颈。4.3 用 PD 分离视角做端到端对照如果团队已经有 PD 分离服务那么验证 “prefill 优化” 的最好做法不是单测某一阶段而是做端到端对照固定并发场景分别记录关闭 PD 分离、开启 PD 分离且 prefill 跑在通用卡、开启 PD 分离且 prefill 跑在新加速硬件三种情况下的端到端时延。这样可以把“调度开销”“传输开销”“prefill 计算开销”分开。端到端观察时推荐画这样一组时间分支请求进入时间到 prefill 调度完成时间——观察调度器排队。Prefill 计算开始到 KV Cache 导出完成——观察计算与存储能力。KV Cache 导出完成到 decode 实例开始解码——观察网络与缓存管理器。Decode 首 token完成后到全部 token 完成——观察 decode 是否被打断。有些问题单看平均时延不明显需要通过长尾区间观察。比如 P99 时延高通常是某一次 KV Cache 换入换出发生碰撞而不是稳定负载普遍变慢。只优化 prefill 芯片矩阵计算能力而不处理缓存管理长尾问题依然存在。5. 常见问题与排错路径从压测现象倒推瓶颈层级5.1 现象一显存 OOM请求在 prefill 早期反复失败典型错误日志CUDA out of memory. Tried to allocate 512.00 MiB. GPU memory occupied: 39.45 GiB of 40.00 GiB.可能的原因不是某块芯片“显存太小”而是 KV Cache 分配策略过于粗放或者 prefill 与 decode 没有隔离导致解码阶段的活动 KV Cache 占满了空间。此时直接加大硬件容量往往会掩盖问题应该先确认推理引擎有没有开启 paged attention 或类似分页缓存机制batch 内请求的 max_length 是否设置得过大。排查路径查看当前服务日志中记录的 KV Cache block 数量和空闲 block 数量。分析单请求 prefill 峰值内存与实际 batch 内存的关系。调小 batch 或限制单请求最长输入确认 OOM 是否随之消失。在推理框架配置里打开显存利用率上限配置比如 vLLM 的 gpu-memory-utilization 参数。如果是专用 prefill 芯片还要额外看 KV Cache 是否被显式分配到独立存储分区。若框架没有正确识别新的存储层次依然把所有数据塞进同一个地址空间就可能触发非预期 OOM。5.2 现象二性能跑不到标称值平均吞吐明显低于预期可能有多层原因。最常见的是 warmup 不充分。推理框架在首次运行时需要完成算子选择、CUDA graph 捕获或 kernel 编译第一轮调用不能代表稳态性能。其次是小矩阵调度开销。Prefill 阶段虽然整体计算规模大但 transformer 层里的 attention 计算可能被切得很碎。如果 kernel 启动开销偏高则提升 batch 后吞吐不会线性增长。排查路径先跑 20 到 50 轮 warmup丢弃前几轮数据再统计。比较实际请求 batch 与芯片设计偏好 batch。若设计目标是高并发请求单请求低 batch 测出的结果自然偏低。使用性能分析工具确认是否出现大量 kernel launch 间隙比如 GPU 空闲超过 30%。观察 CPU 侧是否有 queue 和显存拷贝阻塞。在很多项目中prefill 加速芯片的“标称值”是在特定序列长度、特定精度和特定 batch 形状下取得的而不是对任何输入形状都有效。复现标称值之前需要先还原官方 benchmark 的输入条件再逐步替换成自己的业务负载。5.3 现象三首 token 时延已经很低但总输出稳定后显卡功耗过热此现象在 PD 分离架构中经常是 decode 阶段的显存高占用持续拉高温度而不是 prefill 阶段本身不行。如果 prefill 芯片与 decode 芯片在同一个机箱内、共用散热风道任何一阶段的高热都会互相影响。需要区分清楚散热瓶颈位置。排查路径分开记录两个阶段的平均功率与累计时长。检查系统散热日志是否出现过 power cap 或 throttle 事件。查看运行时时钟频率是否低于 request 基准频率。如果是高密度机箱需要考虑业务层削峰避免多个长文档请求集中打击同一散热域。不少初做推理集群的团队会把“单点最高性能”和“稳定持续性能”混为一谈。散热和功耗达到上限后芯片会主动降频这是可接受的保护机制而不是故障。生产调度应按照“长期稳定功耗预算”配置并发而不是按“瞬时极限功率”配置否则会出现频繁降频。5.4 现象四开启 KV Cache 导出或跨节点传输后总时延反而变高PD 分离并不是在所有场景下都更快。对于短 prompt、低并发系统内传输结果的额外开销可能超过 prefill 单独加速带来的收益。这里的核心判断依据是请求规模太小、KV Cache 太小不值得多一跳传输。排查路径对比同一请求在“不分离”和“已分离”时的总耗时。把 KV Cache 传输耗时单独拆出来统计按字节数和实测带宽倒推是否异常。确认传输层使用的是否是稳定协议和足够队列深度。小请求频繁触发握手时会放大等待时间。业务层给请求分组长文档请求走 PD 分离短请求留在普通解码实例。只有请求输入长度均值较长、token 浓度够高时把 prefill 切出来才值得。若线上交互以短 prompt 为主prefill 加速方案的优势会被传输层蚕食。5.5 常见坑汇总表坑点错误表现根因建议处理方式拿第一轮推理作性能结论首次耗时极高算子编译和 warmup 未完成丢弃前几轮只统计稳定段全局混跑 prefill 与 decode显存互相竞争长尾上升缺少资源隔离或 PD 分离按 token 长度路由请求不对齐输入长度分布测试结果不可复现不同长度下吞吐差异大固定长度区间并记录请求分布KV Cache 不做分页管理峰值显存浪费、OOM静态预留过多或过少开启 paged management 机制忽略功率与散热预算性能偶发下降降频保护被触发按长期功耗预算分配并发跨阶段传输不计入总耗时端到端收益被高估分析口径只算了计算时间从前端请求到全部输出结束统一计时6. 在传闻与产品之间你的团队现在该做什么6.1 把“下一代推理硬件”纳入规划时先迁移负载画像不必等待新的 prefill 加速芯片正式发布才开始准备工作。所有决定现在就可以开始做把生产推理请求按 prompt 长度、输出长度、并发批次分段统计。找出当前集群中哪些请求的 KV Cache 容量最大、最耗显存。评估现有框架是否支持 PD 分离不是靠概念而是拿真实负载做切换演练。建立一个可重复的 prefill 基准脚本固定模型与长度记录多轮性能。只要这些原始数据保存下来未来无论拿到 Rubin CPX 还是其他同类硬件都能快速做对比不需要从零开始培训环境。6.2 从系统层面吸收“芯片重启”带来的启发这次传闻对普通开发者最有价值的启发不是说哪家厂商的路线图变来变去而是提示我们推理负载内部已经足够分化到影响芯片设计。任何跑大模型推理的团队都可以反问自己的服务架构你的 prefill 和 decode 是否在同一批实例里无序争抢资源你的模型服务适合整体混跑还是应该按阶段拆分你的测试方案能不能衡量长 prompt 下 KV Cache 对吞吐的侵蚀你的监控告警是否仔细区分了 prefill 阶段和 decode 阶段的失败这些问题不一定需要回答得多么宏大只要能把真实测量数据沉淀下来当身边同事再问“新的推理芯片值不值得试用”时你就能给出更有依据的判断。6.3 后续可以持续跟踪的技术方向在真实产品落地前适合持续关注的是 PD 分离调度器优化、KV Cache 无损量化、长上下文下显存扩展方案以及不同互联协议下的 KV Cache 传输标准。对做中间件和推理平台的团队来说比芯片本身更重要的是运行时如何暴露细粒度的性能数据让上层调度能感知“某块加速模块现在剩余的 prefill 容量还有多少”。如果未来出现了大量异构的推理组件统一管理和调度会成为比单卡算力更稀缺的能力。一个朴素的建议是无论公开消息怎么更新都坚持把“别人定义的性能”还原成“自己场景中的性能”。到真实硬件可测的那一天用同样的 batch 长度、同样的 prompt 分布、同样的 KV Cache 策略跑一轮可复现的对比比任何流出的规格表都更有说服力。