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 秒的响应。下面是我们七月的延迟分布百分位端到端延迟推理耗时网络排队开销P50187ms142ms45msP90412ms348ms64msP95589ms501ms88msP99847ms726ms121msP99.91,823ms1,590ms233ms在 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。四、成本账最容易被忽略的那行数字GPU 推理月成本 ¥47,230这个数字包含三部分按量付费实例T4×8 A10×4¥28,400。这些是我们弹性伸缩池的常驻节点负载在 55%-70% 之间。预留实例A100×4¥14,500。负载长期在 80% 以上预留比按量便宜约 35%。GPU Spot 实例T4×8¥4,330。用于凌晨批量离线推理任务单价仅为按量的 25%-30%但随时可能被回收。做成本分析的时候我们算了一个关键指标每百万 token 推理成本。长文本场景平均 6000 token 输入 1200 token 输出约 ¥11.8短文本场景平均 800 token 输入 400 token 输出约 ¥3.2。差距接近 4 倍核心原因不是计算量——大输入 token 带来的主要是 KV Cache 膨胀和显存带宽压力。这意味着如果你的业务不做输入端的 token 预算管理靠堆 GPU 来解决问题只会越来越贵。五、总结七月的一组核心数字反映了服务稳定性的三个主要约束应用层的 prompt 调用规范需要建立明确的 token 上限约束推理层的请求路由和排队策略直接影响长尾延迟成本侧的 GPU 实例组合需要根据负载特征持续调优。八月的重点工作明确为三项在 API 网关层增加输入 token 硬限制和拒绝策略从源头解决 OOM 故障对 RAG 场景上线请求优先级队列将生产级请求与开发调试请求隔离启动 A100 集群的 GPU 显存碎片化监控为下一阶段的模型量化部署做准备。少说漂亮话。基础设施需要的是持续观测、持续调优、持续算账。资料说明本文中的协议、版本、性能、成本和行业趋势应以可核验的一手资料为准。未标注统计口径的比例、时间表和预测仅作工程讨论不应视为行业事实。可参考 0731 资料来源索引并在发布前将具体来源贴到对应断言之后。