7 月模型服务质量月报延迟、可用率和成本三线看板一、为什么单独拉一份模型服务质量报告后端服务的 SLA 管理已经很成熟了四九可用率、P99 延迟、QPS 峰值各有一套监控方案。但模型推理服务不同——它的服务质量维度不是简单的请求-响应模型。模型服务的质量还涉及首 Token 延迟TTFT、Token 生成速率TPS、上下文窗口利用率和预热时间等多个专属指标。七月平台上运行的在线模型从 18 个增长到 26 个总推理请求量从日均 320 万增长到 480 万。当规模翻倍时如果还按传统微服务的思路做监控一定会漏掉关键质量信号。这份月报把七月模型服务的质量数据摊开来用数据说明哪些指标在恶化、成本花在哪里、八月的优化方向在哪里。二、质量全貌三个维度的交叉透视2.1 延迟七月有三个波动值得关注首 Token 延迟P50 稳定在 170-190ms 区间符合 SLA 要求200ms。但 P99 从六月的 380ms 上升到七月的 520ms增幅 37%。深入分析后发现P99 恶化集中在三个模型上CodeLlama-34B上下文窗口从 4K 扩展到 16K 导致 prefill 阶段变长、Mixtral-8x7BMoE 模型的 expert 路由在长序列上分布不均和一个内部微调的 Qwen-72B 模型KV Cache 配置不合理。Token 生成速率总体平均 45 tok/s但不同模型差异极大。Llama-3-8B 在小 batch 下可达 82 tok/s而 Qwen-72B 在 batch_size16 时只能跑 28 tok/s。生成速率的瓶颈集中在显存带宽而非计算能力这也解释了为什么简单增加 GPU 数量不一定能线性提升吞吐。端到端延迟P50 1.2s、P99 3.8s。如果用户上下文包含 2000 个 Token 的 system prompt实际可用的生成延迟空间会被进一步压缩。七月有 3 次用户投诉回答太慢排查后都是因为 system prompt 超长导致 prefill 时间占据了端到端延迟的 40%。2.2 可用率差了 0.2 个九根因明确七月整体可用率 99.7%距离 99.9% 的目标差了 0.2 个百分点。这 0.2% 对应的停机时间是约 89 分钟。拆解到具体原因模型加载失败38 分钟三次模型部署因 PVC 配额不足导致权重文件下载中断加上重试时间合计 38 分钟。根因是模型体积从平均 15GB 增长到 40GB而 PVC 默认配额 50GB 未随之调整。GPU 节点故障31 分钟两次 GPU 内存 ECC 错误导致节点被标记为不可调度。故障检测依赖云厂商的健康检查周期 5 分钟加上节点驱逐时间单次故障的影响窗口约 15 分钟。调度超时20 分钟高峰期 GPU 池被训练任务占满推理 Pod 在 Pending 状态等了 20 分钟才调度成功。2.3 成本日均 $1,240ROI 有待优化七月推理相关 GPU 成本日均 $1,240推理请求单价约 $0.0032/千次。闲置 GPU 占比 18%其中约一半是预留的缓冲容量合理另一半是因为模型版本更新后旧实例未及时回收不合理。最贵的三个模型是 Qwen-72B$380/天占 31%、CodeLlama-34B$210/天占 17%和 Mixtral-8x7B$190/天占 15%。这三个模型合计消耗了 63% 的 GPU 预算但 QPS 占比仅 25%。换句话说28% 的预算花在了低频大模型上。三、监控看板的关键指标设计七月我们对看板做了三项改进让服务质量问题更快暴露TTFT 按上下文长度分桶同一个模型在 1K Token 和 8K Token 的上下文下TTFT 可能差 3-5 倍。将 TTFT 按上下文长度分成 1K/2K/4K/8K/16K 五个桶直接暴露了长上下文下的延迟恶化。TPS 与并发数交叉监控单独看 TPS 没有意义。TPS 45 tok/s 在并发 10 时是正常的在并发 50 时就说明显存带宽成瓶颈。把 TPS 和并发数做 XY 散点图能直观判断当前瓶颈在计算还是显存。每 Token 成本追踪从每天花多少钱细化到每百万 Token 花多少钱。这个指标和模型选择直接挂钩Llama-3-8B 约 $0.15/MTokQwen-72B 约 $2.10/MTok前者成本是后者的 1/14。四、尚未达标的质量领域三个明确的盲区生成质量监控目前所有指标衡量的是是否返回了结果但不是结果是否可用。对于幻觉率、格式遵从率和重复率这些内容质量指标七月还没有建立自动评估管线。多轮对话的上下文累积延迟P99 看的是单次请求但多轮对话中每轮请求共享 KV Cache 的状态后续轮次的延迟特征和首轮完全不同。七月的数据无法区分这两种场景。模型间切换的用户体验当请求被路由到不同模型的热备实例时模型加载的冷启动延迟没有纳入 SLA 计算。五、总结七月模型服务在可用率上未达标99.7% vs 目标 99.9%主要拖累来自模型加载失败和 GPU 节点故障。延迟层面P99 首 Token 延迟上升 37% 是八月需要重点优化的方向长上下文和大模型的 KV Cache 配置是主因。成本层面三个大模型消耗了 63% 预算但仅贡献 25% 的 QPS建议八月评估是否用更小模型替代低频大模型场景。八月优先级排序第一修复 PVC 配额策略将模型权重存储从 PVC 迁移到共享式对象存储加速缓存消除模型加载失败的根因第二对 Qwen-72B 和 CodeLlama-34B 做 KV Cache 量化降低长上下文下的延迟第三上线内容质量自动评估管线把可用升级为好用的度量标准。服务质量的提升不是一朝一夕的事靠的是每月一份这样的数据报告持续驱动。
7 月模型服务质量月报延迟、可用率和成本三线看板一、为什么单独拉一份模型服务质量报告后端服务的 SLA 管理已经很成熟了四九可用率、P99 延迟、QPS 峰值各有一套监控方案。但模型推理服务不同——它的服务质量维度不是简单的请求-响应模型。模型服务的质量还涉及首 Token 延迟TTFT、Token 生成速率TPS、上下文窗口利用率和预热时间等多个专属指标。七月平台上运行的在线模型从 18 个增长到 26 个总推理请求量从日均 320 万增长到 480 万。当规模翻倍时如果还按传统微服务的思路做监控一定会漏掉关键质量信号。这份月报把七月模型服务的质量数据摊开来用数据说明哪些指标在恶化、成本花在哪里、八月的优化方向在哪里。二、质量全貌三个维度的交叉透视2.1 延迟七月有三个波动值得关注首 Token 延迟P50 稳定在 170-190ms 区间符合 SLA 要求200ms。但 P99 从六月的 380ms 上升到七月的 520ms增幅 37%。深入分析后发现P99 恶化集中在三个模型上CodeLlama-34B上下文窗口从 4K 扩展到 16K 导致 prefill 阶段变长、Mixtral-8x7BMoE 模型的 expert 路由在长序列上分布不均和一个内部微调的 Qwen-72B 模型KV Cache 配置不合理。Token 生成速率总体平均 45 tok/s但不同模型差异极大。Llama-3-8B 在小 batch 下可达 82 tok/s而 Qwen-72B 在 batch_size16 时只能跑 28 tok/s。生成速率的瓶颈集中在显存带宽而非计算能力这也解释了为什么简单增加 GPU 数量不一定能线性提升吞吐。端到端延迟P50 1.2s、P99 3.8s。如果用户上下文包含 2000 个 Token 的 system prompt实际可用的生成延迟空间会被进一步压缩。七月有 3 次用户投诉回答太慢排查后都是因为 system prompt 超长导致 prefill 时间占据了端到端延迟的 40%。2.2 可用率差了 0.2 个九根因明确七月整体可用率 99.7%距离 99.9% 的目标差了 0.2 个百分点。这 0.2% 对应的停机时间是约 89 分钟。拆解到具体原因模型加载失败38 分钟三次模型部署因 PVC 配额不足导致权重文件下载中断加上重试时间合计 38 分钟。根因是模型体积从平均 15GB 增长到 40GB而 PVC 默认配额 50GB 未随之调整。GPU 节点故障31 分钟两次 GPU 内存 ECC 错误导致节点被标记为不可调度。故障检测依赖云厂商的健康检查周期 5 分钟加上节点驱逐时间单次故障的影响窗口约 15 分钟。调度超时20 分钟高峰期 GPU 池被训练任务占满推理 Pod 在 Pending 状态等了 20 分钟才调度成功。2.3 成本日均 $1,240ROI 有待优化七月推理相关 GPU 成本日均 $1,240推理请求单价约 $0.0032/千次。闲置 GPU 占比 18%其中约一半是预留的缓冲容量合理另一半是因为模型版本更新后旧实例未及时回收不合理。最贵的三个模型是 Qwen-72B$380/天占 31%、CodeLlama-34B$210/天占 17%和 Mixtral-8x7B$190/天占 15%。这三个模型合计消耗了 63% 的 GPU 预算但 QPS 占比仅 25%。换句话说28% 的预算花在了低频大模型上。三、监控看板的关键指标设计七月我们对看板做了三项改进让服务质量问题更快暴露TTFT 按上下文长度分桶同一个模型在 1K Token 和 8K Token 的上下文下TTFT 可能差 3-5 倍。将 TTFT 按上下文长度分成 1K/2K/4K/8K/16K 五个桶直接暴露了长上下文下的延迟恶化。TPS 与并发数交叉监控单独看 TPS 没有意义。TPS 45 tok/s 在并发 10 时是正常的在并发 50 时就说明显存带宽成瓶颈。把 TPS 和并发数做 XY 散点图能直观判断当前瓶颈在计算还是显存。每 Token 成本追踪从每天花多少钱细化到每百万 Token 花多少钱。这个指标和模型选择直接挂钩Llama-3-8B 约 $0.15/MTokQwen-72B 约 $2.10/MTok前者成本是后者的 1/14。四、尚未达标的质量领域三个明确的盲区生成质量监控目前所有指标衡量的是是否返回了结果但不是结果是否可用。对于幻觉率、格式遵从率和重复率这些内容质量指标七月还没有建立自动评估管线。多轮对话的上下文累积延迟P99 看的是单次请求但多轮对话中每轮请求共享 KV Cache 的状态后续轮次的延迟特征和首轮完全不同。七月的数据无法区分这两种场景。模型间切换的用户体验当请求被路由到不同模型的热备实例时模型加载的冷启动延迟没有纳入 SLA 计算。五、总结七月模型服务在可用率上未达标99.7% vs 目标 99.9%主要拖累来自模型加载失败和 GPU 节点故障。延迟层面P99 首 Token 延迟上升 37% 是八月需要重点优化的方向长上下文和大模型的 KV Cache 配置是主因。成本层面三个大模型消耗了 63% 预算但仅贡献 25% 的 QPS建议八月评估是否用更小模型替代低频大模型场景。八月优先级排序第一修复 PVC 配额策略将模型权重存储从 PVC 迁移到共享式对象存储加速缓存消除模型加载失败的根因第二对 Qwen-72B 和 CodeLlama-34B 做 KV Cache 量化降低长上下文下的延迟第三上线内容质量自动评估管线把可用升级为好用的度量标准。服务质量的提升不是一朝一夕的事靠的是每月一份这样的数据报告持续驱动。
双梁正问题 【 torch 实战】（Python代码实现）)
