长上下文压测不能只看“最大支持多少令牌”。真正需要回答的是：输入变长后，首令牌延迟如何变化；并发增加后，KV缓存何时成为瓶颈；持续生成时，输出速度和尾延迟是否恶化。若把这些现象混成一个平均响应时间，往往无法定位问题，也无法指导硬件和架构选型。
先拆分请求生命周期
第一组指标应区分 Prefill 与 Decode。Prefill负责处理历史消息、长文档、图像信息和当前提示词，重点观察首令牌延迟、输入处理吞吐，以及延迟随上下文长度增长的曲线。Decode负责逐步生成内容，重点观察生成速度、端到端时延和不同并发下的P95、P99延迟。
这种拆分很关键：长文档问答可能主要受Prefill影响，而长答案生成、多轮工具调用则可能受Decode和KV缓存限制。只报告一个“平均每秒令牌数”，无法说明究竟是输入处理慢，还是持续生成能力不足。
把资源指标单独核算
第二组指标描述资源消耗，至少包括模型权重、激活计算、KV缓存、视觉处理和通信存储。MoE模型的总参数不等于每次推理实际参与计算的参数；激活参数更适合解释计算量，不能直接推导显存需求。权重驻留方式、量化方案、专家跨卡分布和推理引擎都会改变实际结果。
KV缓存则应按“每令牌缓存大小、上下文长度、并发请求数”观察，并记录缓存命中、淘汰、分层存储和恢复延迟。长上下文压测中，显存曲线比单次请求的显存峰值更有价值，因为并发增长可能使KV缓存近似线性累积。
用矩阵组织压测结论
压测变量不宜只设置一个“超长输入”。至少应交叉改变上下文长度、并发数、输出长度、缓存命中状态和图文输入规模，同时记录首令牌延迟、生成速度、端到端时延、显存占用、GPU利用率、通信开销和失败率。每个点都应保留P50、P95、P99，而不能只看平均值。
最终应形成三条曲线：上下文长度与延迟、并发数与吞吐、并发数与KV缓存占用。若长上下文下吞吐下降但显存尚有余量，瓶颈可能在Prefill计算或跨卡通信；若延迟在并发提升后突然恶化，则应优先检查KV缓存、排队和缓存淘汰策略。只有把性能、资源和稳定性分开测量，再观察它们的耦合关系，压测结果才真正能支持部署决策。