周报要解决的问题
推理服务的容量风险很少以单点数字暴露，而是连续几周慢慢逼近上限：并发缓步上涨、首字延迟的分位值悄悄抬升、显存水位一个月内从六成爬到九成。周报的作用就是把这条趋势固定在一张表上，用同一套口径连续观测，让扩容决策提前到告警之前发生。口径一旦确定就不要频繁改，否则趋势线本身失去可比性。
基本信息
| 适用对象 | 自建或托管的大模型推理服务 |
|---|---|
| 统计周期 | 自然周，固定周一到周日 |
| 数据来源 | 监控系统的并发与延迟分位、引擎自身的显存指标、发布记录 |
| 产出频率 | 每周一次，异常周追加说明 |
| 责任人 | 值班负责人汇总，容量负责人确认动作 |
典型使用场景
- 扩容决策：连续两周关键指标逼近阈值时就启动采购或上线流程
- 发布复盘：把引擎升级、参数调整与指标拐点放在同一时间轴上对照
- 成本核对：并发上涨而资源未跟上时，提前发现单位请求成本抬升
- 向上汇报：用一张固定的表替代零散截图，趋势与结论一目了然
- 跨团队对齐：把口径写死在模板里，避免各方各说各的并发与延迟
周报字段示意
周报字段示意
周次 | 峰值并发 | 首字延迟P95 | 单token延迟P95 | KV峰值水位 | 错误率 | 变更事件
W40 | 78 | 720ms | 38ms | 71% | 0.2% | -
W41 | 96 | 850ms | 42ms | 88% | 0.4% | 引擎升级 v3
W42 | 104 | 910ms | 45ms | 93% | 0.3% | 新增业务线接入指标口径与触发线
| 指标 | 口径说明 | 观察要点 |
|---|---|---|
| 峰值并发 | 单位时间内同时处于生成中的请求数 | 连续两周涨幅超过一成需评估扩容 |
| 首字延迟 P95 | 从请求到首字节返回的时间分位 | 抬升通常先于错误率变化，是最早的预警信号 |
| 单 token 延迟 P95 | 解码阶段每个 token 的平均耗时 | 明显上升可能是显存碎片或批处理效率下降 |
| KV 峰值水位 | 显存中缓存占用相对可用容量的水位 | 长期高于九成时排队与超时风险显著上升 |
| 错误率 | 失败请求占比 | 按错误类型拆分，区分超时、限流与服务端异常 |
评审盯变化量而不是绝对值：某个错误类型突然翻倍，通常对应一次发布、一个新接入方或一次配置改动，顺着变更记录能快速定位。
周报要落到动作：每期结尾写明维持现状、提前扩容或调整参数，并指定负责人与期限，否则数据看完就归档，下一次仍然是被动救火。