7 月全月 AI 服务运行报告：可用率、延迟和成本的最终数字-拓冰建站

7 月全月 AI 服务运行报告：可用率、延迟和成本的最终数字

一、一个月跑下来的真实感受：数字化不会说谎

七月跑完了，我们内部 AI 推理服务完成了 31 天不间断的数据采集。统计口径覆盖了 A/B 两条推理链路、三个 GPU 集群（T4×16、A10×8、A100×4）以及统一的 API 网关层日志。先说这三项最终数字：整体可用率 99.72%（以 5xx 状态码和超时合并计算）、P99 端到端延迟 847ms、全月 GPU 推理成本 ¥47,230。

这些数字出来之后，团队的讨论方向变了——不再是"模型能力够不够强"的争论，而是"这条链路能不能扛住下个月 2 倍流量增长"的工程审视。数据最大的价值在于，它把模糊的感觉变成了可追溯的决策依据。

从业务角度看，本月模型调用场景大致分布在三个方向：代码补全（32%）、文档摘要（28%）、内部 RAG 知识库问答（40%）。其中 RAG 问答是延迟波动最大的业务线，也是我们把 P99 压到 900ms 以下的主要攻坚对象。

二、可用率拆解：99.72% 不是一个好看的数字

下面这张图展示了七月的服务可用率构成：

99.72% 在行业里处在一个微妙的位置——比公有云 API 的 99.9% SLA 略低，但比大多数自建推理平台的早期阶段要好。真正的问题不在总体数字，而在故障分布。

GPU OOM 占故障总量的 34.6%，排第一位。深入排查后发现，这些 OOM 几乎全部发生在输入 token 超过 8000 的长文本场景中。我们的上下文窗口限制设了 4096，但上游业务的 prompt 拼接逻辑没有做严格校准，导致实际送到模型的 token 数频繁突破上限。这不是基础设施的锅，而是应用层调用规范缺失的后果。

模型服务超时占 40.4%，是最大的故障源。我们从 Prometheus 的推理队列长度指标中看出了规律：每天 10:00-11:30 和 14:30-16:00 两个时段，推理队列深度从常态的 2-3 飙到 12-15。业务侧的 RAG 问答在这个时段集中发起批量请求，而 GPU 推理本身就是不可重入的串行计算，排队是无法避免的。

三、延迟分析：P50 没意义，P99 才是工程真相

延迟是比可用率更值得盯的指标。看 P50 是一件自欺欺人的事——你的服务让一半用户感知不到延迟，另一半用户却在等一个 2.5 秒的响应。下面是我们七月的延迟分布：

百分位	端到端延迟	推理耗时	网络+排队开销
P50	187ms	142ms	45ms
P90	412ms	348ms	64ms
P95	589ms	501ms	88ms
P99	847ms	726ms	121ms
P99.9	1,823ms	1,590ms	233ms

在 P99 之下，我们做了两件事：

第一，引入了基于 token 长度的预判路由。请求进入推理网关后，根据输入 token 估算，将请求分发到不同的模型副本池。长文本（>3000 token）走 A100 池，短文本走 T4 池。这条规则上线后，P99 从 1,120ms 降到了 847ms，降幅约 24%。

第二，对 RAG 问答场景做了 Chat Template 层面的缓存优化。在 prompt 构造阶段，系统提示词（System Prompt）是固定的，但之前每次请求都重新编码。我们在推理框架层增加了 prompt cache，将系统提示词的 KV Cache 固定在一个 slot 中复用。短文本场景下，TTFT（首 token 时间）从 98ms 降到了 41ms。