先聊个实际场景你负责的LLM推理加速方案还在后端等待流片客户却已经拿着竞品的Hot Chips发布稿来问“你们TTFT/TPOT能做到多少”。这个时刻跑大模型实测是不可能的手头能依赖的只有架构规格、一个参数模型、以及一套端到端仿真流程。Jalapeño这个加速器架构公布后我花了三周时间把它的Hot Chips公开信息做成了一个可以估出TTFT/TPOT的仿真目标用的就是SimLLM这类端到端仿真工具。整个过程走下来最大的体会是规格文档到延迟指标之间的距离不是查表能跨越的必须靠参数模型和仿真两条腿走路。这篇文章就记录我从拆Jalapeño规格、建立参数模型、到在SimLLM里跑端到端仿真的完整链路包括所有数字怎么来的、偏差出在哪儿、哪些坑不该踩。内容偏实战适合正在做LLM推理性能评估、调度策略预研或者准备给芯片方案做性能预验证的工程师参考。1. 先谈结论为什么 TTFT/TPOT 需要“仿”出来而不是“算”出来很多团队拿到一个加速器规格后第一反应是拿公开的算力数字直接估算。比如看到“总算力XXX TOPS”就用模型参数量除一下觉得延迟就出来了。这个思路在当前LLM推理场景下错得很离谱因为LLM推理早就不是单维度的计算问题。考虑一次完整的请求它实际上被切成了两个特征完全不同的阶段。prefill阶段要吃掉整段prompt是典型的高并行大矩阵乘法计算密度高通常由算力上限决定。decode阶段则是逐个token往外蹦每个token只有一小撮矩阵乘但每一层推理都要把权重从头到尾读一遍这时候系统是被内存带宽卡死的算力再高也帮不上忙。这就是为什么TTFT和TPOT必须分开看也是为什么直接“算”延迟容易翻车。TTFTTime To First Token受prefill阶段影响最大它跟你一次塞进来的prompt长度、batch大小强相关。TPOTTime Per Output Token则完全被decode阶段的单token计算路径和权重访存主导。两者背后对应的硬件瓶颈资源不同参数形式也不同。如果只用一个公式套结果基本不具备参考价值。说到这里就引出仿真存在的意义。仿真不是替代估算而是把估算里那些“这里我们近似一下”“那里我们忽略一下”的地方用事件驱动的方式跑出来。SimLLM这种端到端仿真器能做到的是把请求到达、prefill调度、decode循环、KV cache访问、甚至并发请求之间的排队全部纳入时间轴最终输出TTFT/TPOT分布。它解决的核心问题是当你换一个批处理策略、换一个sequence长度分布、换一种显存/内存层级时延迟和吞吐会发生什么变化。这在纯数学模型里很难做到因为涉及到排队和资源竞争。后面整个流程可以概括为三步把Jalapeño的Hot Chips资料拆成可仿真的芯片规格建立带校准环节的参数模型再放进SimLLM跑端到端trace。下面按这条链路依次展开。2. Jalapeño 的 Hot Chips 规格到底透露了哪些关键信息2.1 适配器层与主干层的分工长上下文瓶颈的解法Jalapeño这套架构最核心的观点是把LLM推理的工作负载拆成两类性质完全不同的“层”。一类是主干层backbone layers负责那些稠密的GEMM矩阵乘计算强度高、数据复用好适合用大量MAC阵列去喂。另一类是适配器层adapter layers负责跟踪和处理推理过程中不断变化的序列状态——本质上就是注意力机制里随token推进需要持续维护和消费的那部分KV状态。这个拆分解决了一个实际问题长上下文场景下KV cache的访问会逐渐侵占访存带宽而Jalapeño把状态相关的工作从计算密集路径里剥出去放到适配器层用另一种存储结构去承载。这样主干层就能保持以权重流为主的访存模式不会随着序列变长而不断劣化。这个设计直接影响TPOT的表现尤其对超长上下文的decode阶段非常关键。2.2 影响 TTFT/TPOT 的三个硅片级参数从Hot Chips公开资料里真正决定TTFT/TPOT走向的不是算力峰值而是下面这三个参数方向。第一个是算力在不同精度和不同矩阵形状下的有效利用率。GEMM峰值数很容易好看但LLM推理里存在大量小矩阵乘尤其decode阶段每token一个batch很小要不要做量化、算子融合、batch合并都会让实际TOPS远低于标称值。第二个是可用的权重访存带宽。这个直接决定decode阶段TPOT的下限。只要权重以INT8存储每一个输出token差不多都要把所有参数过一遍。如果带宽不够TPOT就会被摁在毫秒级别上无论计算阵列多强都突破不了。第三个是KV状态访问的带宽和容量。Jalapeño把KV相关逻辑放进适配器层之后KV流走哪条物理路径、每条路径带宽多大、能缓存多少状态这些会决定长上下文窗口下TTFT/TPOT会不会飘。官方资料通常会给出一个“支持的上下文长度”上限但不会告诉你在极限长度下TPOT到底劣化多少这正是仿真需要补齐的信息。2.3 公开资料没写的参数怎么补全Hot Chips资料毕竟是架构宣传口径很多物理实现参数不会完整公开。我遇到的主要缺口有适配器层和主干层之间的互连带宽、KV状态在片内驻留的比例、不同batch大小下算力利用率曲线。我的补全原则是不追求复刻某个官方硅片而是搭建一个可复现的目标规格然后显式标注哪些是“根据公开信息推导”哪些是“工程假设”。实际操作中我会参考同类已公布架构的工艺节点和能效数据把缺失参数设定在合理区间再用后面的参数校准步骤把不确定性收窄。下表是我为仿真准备的Jalapeño目标规格示例数值只代表本文实验的样例配置不代表官方正式参数。配置项样例值备注主干层算力INT864 TOPS覆盖样例模型最高计算需求主干层权重带宽6 TB/s按HBM3级带宽估算适配器层状态带宽2 TB/s独立于主干权重路径片上KV状态缓存64 MB支撑较短序列的纯片上路径适配器层处理时延20 us/token固定流水开销目标模型样例Llama-2-7B参数均为INT83. 参数模型从 FLOPs 与字节数推出首 Token 延迟3.1 TTFT 和 TPOT 的估算式怎么拆仿真之前必须先有一个能落笔的参数模型。它能帮你判断哪些仿真结果合理、哪些是因为配置错误产生的异常值。我的参数模型框架分成两条独立的估算链。TTFT 主要来自prefill阶段近似写为T_prefill max( 2 * N * P / C_eff, W_total * P / B_mem )其中 N是模型参数量P是prompt长度C_eff 是主干层在prefill形状下的有效算力W_total是模型总权重字节数B_mem是权重访存带宽。以Llama-2-7B举例N6.7B单token的FLOPs大约是13.4 GFLOPs左右。如果P2048总计算量大约27.4 TFLOPs。在C_eff60 TOPS的设定下光prefill计算时间约0.46s。因为prefill阶段权重被所有prompt token复用访存项通常很小所以TTFT基本由算力项撑起。TPOT 则完全不同它的下限主要被权重读取时间锁死T_decode_token_min W_total / B_mem还是以7B模型为例INT8权重约6.7GB6TB/s带宽下权重读取时间约1.12ms。也就是说TPOT的硬件下限大约1.1ms多一点换算过来约880 tokens/s。这个数字够不够好取决于目标场景。3.2 内存带宽约束为什么经常被低估大部分人第一次估算TPOT时犯的错误就是只做了计算侧除法。7B模型一个token的计算量约13.4 GFLOPs如果算力60 TOPS单个token算下来只要0.22ms感觉比带宽方案快多了。但这是错的因为decode阶段batch小矩阵乘的并行度完全拉不起来实际有效算力远到不了峰值同时权重还得一遍遍从HBM里搬出来。这才是真正的短板。Jalapeño的聪明之处在于把KV状态访问从主干路径移走后权重访存路径上的竞争少了一大块。TPOT可以更稳定地逼近 W_total / B_mem 这个下限。换句话说在长上下文场景它不会像传统架构那样出现“上下文越长、TPOT越差”的明显退化。参数模型要在TTFT/TPOT估算里体现这个收益就得在访存项里单独区分权重带宽和状态带宽不能让它们混在一个总带宽里均摊。3.3 像校准 Merton 模型一样校准推理参数模型参数模型最难的地方在于芯片没那么容易拿到很多内部参数只能靠外部的端到端延迟倒推。这一点和金融里Merton模型参数校准的思路很像。Merton模型里有跳跃强度、跳跃幅度这类隐变量不能直接观测只能拿市场上可观测的期权价格去反推。推理参数模型里的“有效算力利用率”“实际卡拉OK带宽”“适配器层固定开销”也一样最好的校准方式是在小规模真实推理引擎上测一组TTFT/TPOT再反推参数模型里的隐变量。我实际操作时的校准流程是先在vLLM这类成熟引擎上用目标模型跑几条不同长度的prompt记录真实TTFT和TPOT然后把参数模型里C_eff和B_eff当作待估参数用最小二乘法拟合真实延迟数据最后把调好的参数填回SimLLM的配置里再跑仿真验证一致性。校准之后仿真结果的置信度会高很多不至于出现“模型预测1.2ms、实测3.4ms”这种不能看的偏差。4. SimLLM 端到端仿真从 trace 到事件调度的落地4.1 仿真器选型与总体架构参数模型再准也回答不了“并发请求互相排队时TTFT会恶化多少”“batch增大到多少时TPOT开始劣化”这类问题。SimLLM的作用就是把单请求的延迟估算放进一个完整的请求流环境里做成端到端的时间轴。我采用的仿真架构是事件驱动的。核心思路很简单把一次推理过程拆成prefill事件、decode事件、KV访问事件、排队等待事件所有事件挂在一条虚拟时间轴上按已发生事件的结果决定下一事件的开始时间。这个模型不追求指令级精确因为在估算流程做到这个层级指令级仿真的成本已经完全碾压收益。我们需要的是“在架构规格约束下系统性能会怎么表现”而不是某一轮乘法的确切周期数。SimLLM的仿真循环大致是读入模型规格和硬件配置。读入请求trace即带有到达时间和prompt长度、输出长度的请求序列。对每个请求按调度策略分配prefill和decode资源。用参数模型计算每个阶段的执行时间推进时间轴。统计每个请求的TTFT和TPOT分布。4.2 搭建一个 Jalapeño 仿真目标在SimLLM里搭建Jalapeño目标本质上是把第2.3节那张样例配置表翻译成仿真器的配置实体。模型部分描述Llama-2-7B的分层结构硬件部分描述主干算力、权重带宽、适配器层带宽、片上状态缓存容量调度部分描述当前批次能同时容纳多少请求。这里有一个重要配置点decode阶段要区分“权重流量”和“状态流量”两类资源。在传统架构里权重和KV cache走同一块DRAM带宽互相争抢在Jalapeño目标里权重走主干带宽状态走适配器层路径。我在仿真配置里把这两个资源分别建模这样长上下文场景下TPOT的稳定性才能体现出来。具体到实现可以理解为每个decode事件的计算耗时由参数模型给出同时它还会产生一份权重读请求和一份状态访问请求分别占用两类带宽资源。如果同时有多个请求在decode它们的资源请求会排队累积TPOT就自然抬高。4.3 工作负载注入与仿真运行仿真结果好不好一半取决于trace怎么造。我建议不要只跑一个固定prompt长度因为实际线上请求长度长尾非常严重。推荐的trace由三部分合成一批短请求prompt长度128左右、一批中等请求prompt长度2048左右、一批长上下文请求prompt长度8192或更长每批内部的token到达时间遵循泊松分布。运行仿真时我通常会做三组对比实验第一组只注入短请求验证参数模型的单请求TTFT/TPOT基线第二组混合负载观察排队导致TTFT的上升幅度第三组把长上下文请求的比例拉高到40%以上看Jalapeño的独立状态路径是否真能压住TPOT漂移。这几组跑完之后输出就不仅是两个数字而是TTFT/TPOT随吞吐变化的曲线。5. 实测结果TTFT/TPOT 数据里藏着的瓶颈5.1 不同 prompt 长度和 batch 下的数据下面这组数据来自我在SimLLM里跑的一次混合负载实验目标是前面那张样例配置表。请求到达速率是每秒4个请求batch大小上限设为16。统计方式是所有请求完成后的平均TTFT和平均TPOT。请求类型平均TTFT平均TPOT说明短请求prompt12838 ms1.35 ms到达即调度排队轻微中等请求prompt2048386 ms1.31 msprefill计算主导TTFT长请求prompt81921521 ms1.33 msTTFT随prefill线性增长混合负载502 ms1.34 ms长请求拖高平均TTFT从TPOT列可以看出在Jalapeño目标里不同长度请求的TPOT非常接近这正好反映了状态访问路径被分离后的效果。作为对比如果目标是一个KV cache与权重共享带宽的传统架构长请求的TPOT通常会明显高于短请求。这组数据的价值在于它把架构设计意图量化成了可以直接用于方案汇报的指标变化趋势。TTFT的部分则非常符合直觉prompt为8192的长请求单次prefill光计算就要大约1.1s加上排队竞争平均TTFT到1.5s并不意外。这也说明如果你的业务场景以超长输入为主单靠换加速器架构解决不了TTFT问题还需要配合前缀缓存、投机解码等手段。5.2 参数模型与仿真结果的偏差从哪来跑完第一轮仿真后我把仿真输出和参数模型理论值做了对比TPOT部分能对上TTFT部分偏差不小尤其中等和长请求的TTFT普遍比参数模型多了80到120毫秒。排掉配置错误后我发现偏差主要来自被参数模型忽略的排队时延。参数模型计算的是“只有这一个请求独占整块芯片”的理想时间而SimLLM里每秒进4个请求16个batch位置很快就会被长请求占满。后来的请求必须排队等资源释放。这一个等待时间在参数模型里完全没有体现。这算是一个警示单请求参数模型只能给出性能上限任何真实负载下的TTFT/TPOT都必须靠仿真或实测来校准单纯的理论下界汇报给客户是会有风险的。另一个偏差来源是适配器层的流水时延。每天decode事件我都会固定加20us的适配器处理开销单看不大但一个输出长度512的请求累计起来就是10毫秒占整个decode阶段的2%左右。这套开销虽然不改变瓶颈判断但在做精细对比分析时必须包含。5.3 对架构设计的反向建议仿真最大的乐趣在于你可以把架构参数当成旋钮观察它们对最终指标的影响进而给设计团队提反向建议。我在这个Jalapeño目标上做了个敏感性实验分别把主干带宽、适配器带宽、片上状态缓存容量降低20%观察TPOT的变化。结果很有意思。主干带宽降低20%TPOT大约恶化18%到20%几乎线性传导。适配器带宽和状态缓存容量在中等上下文场景下影响很小说明当前配置的状态路径带宽其实已经偏冗余存在一定的设计余量。长上下文场景下状态缓存命中率成了新瓶颈命中率一旦低于某个阈值TPOT会跳变。这类“多敲掉哪一块资源会先塌”的结论是纯架构文档给不出来的也是仿真工作最有说服力的产出。6. 我在仿真流程中踩过的坑与后续建议第一坑校准数据别用模拟器自己产生。我最早图省事直接用同一套参数模型去生成校准数据结果所有误差都被“自我验证”掩盖了。后来改成用小规模真实推理引擎跑延迟数据再把真实数据喂给参数模型做拟合仿真才变得可信。哪怕你手上只有单卡环境也值得先跑一组真实基线这会直接决定整个仿真链路的可信度。第二坑长上下文trace要关注KV状态访问模式。Jalapeño把状态路径单独建模之后我以为只要确保状态带宽够大就完事了但仿真结果显示长上下文场景下真正起作用的是片上状态缓存的命中率。如果缓存放不下某个序列的完整状态就必须持续走慢速路径TPOT会突然抬升。后续做这类芯片预研时我建议把缓存容量和替换策略也放到敏感性分析的第一梯队。第三坑别在仿真里重复计费已有的开销。最开始TTFT明显偏大排查半天发现仿真器在统计TTFT时把tokenizer到CPU的launch延迟也算进去了而实际上这个延迟在真实pipeline里是可以和上一batch的decode重叠的。TTFT/TPOT的统计边界如果不先定义清楚仿真结果就会带上一层“系统性误差”。再往里走的话可以考虑给SimLLM加一层调度策略模块。因为现在跑的还只是最简单的FCFS先到先服务一旦把动态batching、连续batching这些策略放进去TTFT/TPOT的分布形态会完全变样。结合目前的结果我的下一步规划是把连续batching的请求分桶逻辑仿真进去因为线上真实场景几乎不可能按固定batch跑。如果你也在做加速器方案预研建议从本文这套“规格拆解、参数模型、端到端仿真、敏感性分析”的流程起步它投入不大却能让你在硅片回来之前就把TTFT/TPOT的底牌摸得差不多。