企业官网建设流程全解析

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-8x7B（MoE 模型的 expert 路由在长序列上分布不均）和一个内部微调的 Qwen-72B 模型（KV Cache 配置不合理）。

Token 生成速率：总体平均 45 tok/s，但不同模型差异极大。Llama-3-8B 在小 batch 下可达 82 tok/s，而 Qwen-72B 在 batch_size=16 时只能跑 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,240，ROI 有待优化

七月推理相关 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/MTok，Qwen-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 量化，降低长上下文下的延迟；第三，上线内容质量自动评估管线，把"可用"升级为"好用"的度量标准。服务质量的提升不是一朝一夕的事，靠的是每月一份这样的数据报告持续驱动。