一次请求的显存峰值出现在哪？内部门道在这

大模型一次请求的显存占用并非一条平线，中途会冒出远高于均值的尖峰。看懂这条曲线，容量规划才有着落。峰值出现在哪、被什么推高，决定了同一张卡能塞多少并发。

显存都花在哪几处

大头有四块：模型权重常驻、KV 缓存随序列增长、中间激活按批与长度涨、框架自身的工作区。进来的是一条请求的执行计划，发生的是四块占用的叠加，出去的是随时间起伏的显存曲线。

权重是固定房租，请求再多也摊不薄；KV 缓存和激活才是随请求波动的部分，峰值之争主要发生在这两块。显存不够时系统不会悄悄降速，而是直接报错或排队，所以峰值余量是硬约束。

四块的占比因配置而异：长上下文场景 KV 缓存占大头，大批量场景激活占大头，评估容量前先看自家业务的请求形态，别拿别人的比例套自己的机器。

四块占用各自的涨法和削法，摊开对照。

峰值出现在哪个阶段

预填充阶段最危险：整段输入一次算完，注意力的中间量随输入长度抬升，长文档问答的第一次计算往往是全程最高点。进来的是长输入，发生的是一次性大批量计算，出去的是显存尖峰加填好的缓存。

预填充还有个特点：算得越快占得越猛，硬件升级后峰值反而可能更尖，容量评估要跟着重测。生成阶段压力换了个方向：每出一个字缓存涨一格，输出越长缓存越肥，配合并发叠加，生成中段可能冒出第二个峰。两个峰哪个更高，看输入输出谁更长。你在智谱清言、海螺AI里提交长文生成任务时，服务端对输入输出长度的限制，背后多半就在防这两个峰。峰值还有一个来源容易漏：框架初始化和首次执行要预留工作区，这段开销平摊不到单个请求头上，却实打实占着显存，容量表里要单列一行。工作区的大小和框架实现有关，升级框架后要重新量。两个峰都怕叠加：长输入加长输出加高并发同时出现，峰值是乘法关系，容量评估要按最坏组合算，不能按均值算。

削峰的常见手法

削峰思路有三条：分块计算把长输入拆成小段逐段算，峰值被压平；缓存分页把连续占用切成小块按需拿，避免预支；量化把激活与缓存的单位体积做小。三者不冲突，多数推理框架同时用。

削峰换来的余量直接变成并发能力：同样的卡，峰值压得越低，能同时接的请求越多。这也是为什么引擎升级后，同样硬件能接住更多用户，成本账就这样从曲线里省出来。削峰之后还要监控兜底：显存曲线要实时可见，逼近红线就告警，容量规划靠数据不靠感觉，峰值记录就是可靠的依据。告警分层级，预警线和红线分开画。量化对峰值的影响要实测：单位体积变小了，但精度档位不同中间量大小也不同，账要重新算一遍。

• 速查：权重是固定大头；预填充冒第一峰；长输出加并发冒第二峰；分块、分页、量化三条削峰路；峰值余量是并发上限。

显存是硬约束，超限的形态各不相同：推理结果的日志怎么记？排查的第一手资料里能查到峰值记录，吞吐和延迟为什么互相牵制？过程拆开看与容量直接挂钩，保首字还是保整段？两种服务策略受预填充耗时影响，流式输出的顺序是怎么保证的？分片组装则是输出端的另一套机制。

关于显存峰值再多问三句

• 输入长和输出长哪个更危险？：预填充看输入长度，生成看输出长度叠加并发，两头的极限都要测，压测时两头轮着加压。
• 峰值超了会怎样？：申请失败或直接报错，服务端通常按容量拒绝新请求，不会硬撑。
• 并发数怎么估才靠谱？：按实测峰值反推再留一成余量，纸面计算不算数，压测报告比公式可靠。