一、引言很多人在做 AI 推理服务时第一反应通常是模型能跑起来就行API 能返回结果就行页面能看到输出就行于是整个系统上线后对外可能只有一个接口POST /generate或者POST /chat表面上看服务已经“可用了”。但只要系统一进入真实环境很快就会出现几个非常现实的问题模型为什么突然变慢了GPU 到底有没有在工作当前并发有没有打满服务是不是已经卡死了Pod 为什么被重启了网关为什么判定它不可用这时候你会发现一个 AI 推理系统如果只有“业务接口”其实远远不够。它还必须有两类非常关键的接口/health/metrics这两个接口在很多项目初期经常被忽略但一旦系统进入多用户访问容器化部署K8s 编排压测联调生产环境运行它们就会从“可选项”变成必须项。本文就从工程视角出发讲清楚/health和/metrics分别是什么为什么 AI 推理服务一定要有它们它们在部署、监控、扩缩容和排障中到底起什么作用为什么完整 AI 系统还需要 Prometheus、Grafana 和 dcgm-exporter二、先说结论AI 推理系统不只是“能返回结果”还必须“能被系统理解”很多人做推理服务时只关注用户能不能拿到输出结果但从工程角度看这只是“业务可用”。一个真正可上线的服务还必须满足1. 业务可用请求能正常返回2. 系统可观测系统知道它现在运行得怎么样3. 平台可管理调度系统知道它是否健康、是否该重启、是否该扩容也就是说服务不只是给“人”调用的它还必须给“系统”调用。而/health和/metrics就是服务对“系统”说话的接口。三、什么是 /health1. 最简单理解/health的作用就是告诉外部系统我现在是不是“活着、能用、正常工作”。例如GET /health返回状态正常例如 status ok这看起来很简单但它的意义非常大。2. 它不是给用户看的而是给系统看的调用/health的通常不是用户而是K8s负载均衡器网关容器编排系统监控系统这些系统关心的问题只有一个这个服务现在还能不能接流量四、为什么 AI 推理服务特别需要 /health这是 AI 服务和普通 CRUD 服务最大的区别之一。因为 AI 推理服务的“挂掉”往往不是直接进程退出而是模型加载失败GPU 内存爆了推理线程卡死后端模型服务失联某个依赖组件不可用这时候服务进程可能还活着但它其实已经“不能用”了。也就是说ps看起来进程还在容器看起来也还在端口可能也还开着但实际上服务已经处于“假活着”状态。而/health的意义就是把这种“假活着”识别出来。五、/health 到底该检查什么一个真正有用的/health不应该只返回一句“ok”。它至少应该检查这些核心项1. 服务进程是否正常Web 服务是否正常运行API 线程是否还能响应2. 模型是否加载成功模型权重是否已就绪推理引擎是否可调用3. GPU 是否可用可选增强GPU 是否可见显存是否异常4. 依赖组件是否正常Redis 是否可连接向量库是否可访问模型服务是否在线一个更有工程意义的返回示例返回内容中通常可以包含服务状态模型是否加载成功GPU 是否可用依赖组件是否正常这时候它才真正变成可用于自动化判断的健康接口六、/health 在真实系统里是怎么被用起来的1. K8s 探针Probe这是最典型的用法。Kubernetes 在部署 AI 服务时通常会通过/health来判断这个 Pod 是否已经启动完成这个 Pod 是否还活着这个 Pod 是否应该被重启最常见的就是readiness probe就绪探针liveness probe存活探针2. 网关是否继续分发流量如果/health不通过网关或负载均衡器可以选择不再把请求打到这个实例上这非常重要因为不健康实例继续接流量只会把问题扩大。3. 自动重启与自动恢复如果服务已经卡死、失联或者异常系统可以基于/health结果自动执行重启容器剔除节点重新拉起服务这也是为什么/health 是自动恢复体系的一部分。七、什么是 /metrics如果说/health回答的是“我现在活着吗”那/metrics回答的就是“我现在运行得怎么样”1. 最简单理解/metrics的作用是暴露系统运行指标供监控系统采集。例如GET /metrics返回的通常不是普通业务数据而是一组监控指标例如request_countrequest_latencygpu_utilization这些指标会被 Prometheus 之类的监控系统抓取。八、为什么 AI 推理服务特别需要 /metrics因为 AI 推理系统和普通 Web 服务最大的不同是它的“性能瓶颈”往往不在 CPU而在 GPU、模型推理链路和请求堆积。所以如果没有/metrics你几乎不知道系统现在到底处于什么状态。九、AI 推理服务最应该暴露哪些指标一个 AI 推理服务的/metrics至少应该覆盖以下几类信息1. 请求类指标用于回答现在流量大不大请求多不多常见指标包括总请求数成功请求数失败请求数当前并发请求数QPS / TPS2. 延迟类指标用于回答系统现在慢不慢慢在哪里常见指标包括平均响应时间P50 / P95 / P99 延迟模型推理耗时前处理 / 后处理耗时3. GPU 类指标这是 AI 系统和普通系统最大的区别之一。用于回答GPU 到底有没有在干活是不是已经打满了常见指标包括GPU 利用率显存占用GPU 温度GPU 功耗GPU 进程状态4. 模型服务类指标用于回答模型本身的工作状态如何常见指标包括当前模型是否已加载模型切换次数推理队列长度当前 batch 大小Token 生成速率文本场景5. 依赖服务类指标用于回答问题是不是出在“模型之外”常见指标包括Redis 连接状态向量数据库响应时间后端模型服务响应时间下游服务错误率十、/metrics 在真实系统里有什么用1. 做实时监控面板这是最直观的用途。通过/metrics暴露的数据可以在监控平台上看到GPU 曲线请求量变化响应时间变化错误率趋势这就是很多 AI 平台“监控大盘”的数据来源。2. 做性能压测验证当你做 JMeter / Locust 压测时不能只看用户侧是否超时还必须看GPU 有没有打满响应时间怎么变化哪个阶段开始掉性能这些都依赖/metrics。3. 做扩缩容决策这是 AI 平台里特别关键的一点。系统什么时候该扩容不能只靠“感觉”。更合理的做法是基于GPU 利用率请求队列长度P95 延迟当前并发量来自动触发扩容。而这些判断依据本质上都来自/metrics4. 做故障定位如果服务变慢了问题可能出在GPU 打满模型卡住Redis 阻塞某个请求拖慢了队列如果没有指标你只能靠猜。有了/metrics你才能知道问题到底发生在链路的哪一层。十一、/health 和 /metrics 的区别到底是什么你可以这样记接口核心问题面向对象/health我还活着吗K8s / 网关 / 调度系统/metrics我现在运行得怎么样Prometheus / Grafana / 运维系统一句话记忆/health 解决“活不活”/metrics 解决“跑得好不好”。十二、只有 /metrics 还不够AI 系统还需要完整监控链很多人以为服务暴露了/metrics监控就完成了。其实不是。/metrics只是一个“指标出口”它本身不会存储数据也不会自动生成图表更不会主动告警。一个完整的 AI 监控体系通常还需要三类组件组件主要作用是否直接部署在推理服务里/metrics暴露服务自身指标是Prometheus定期抓取/metrics并存储时间序列数据否Grafana读取 Prometheus 数据并展示图表、仪表盘、告警否dcgm-exporter从 GPU 驱动层采集显卡利用率、显存、温度等指标否1. Prometheus指标采集与存储Prometheus 的作用是定期去抓取服务暴露出来的/metrics并把这些指标存成时间序列数据。它解决的是指标如何被持续采集指标如何被历史保存如何按时间维度查询性能变化2. Grafana可视化与告警Grafana 本身不采集指标它主要负责连接 Prometheus展示曲线图、柱状图、仪表盘配置阈值告警也就是说Prometheus 负责“存数据”Grafana 负责“看数据”。3. dcgm-exporterGPU 指标采集对于 AI 系统来说GPU 是核心资源。很多关键指标例如GPU 利用率显存占用温度功耗并不是应用自己通过/metrics暴露的而是通过专门的 GPU exporter 来采集。这时候就需要 dcgm-exporter。它的作用是从 NVIDIA 驱动层采集 GPU 指标再暴露给 Prometheus 抓取。十三、一个典型的 AI 监控链路是怎么工作的一个典型的 AI 推理监控链路通常如下AI 推理服务 → 暴露/metricsGPU 节点 → 部署 dcgm-exporterPrometheus → 定期抓取服务指标和 GPU 指标Grafana → 读取 Prometheus 数据并展示监控面板在工程实践中这几个组件通常会以独立容器方式部署推理服务容器负责模型推理与业务接口Prometheus 容器负责采集与存储指标Grafana 容器负责监控面板与告警dcgm-exporter 容器负责采集 GPU 指标这样做的好处是与业务服务解耦易于扩展易于维护适合容器化和 K8s 场景十四、部署方式上它们通常怎么接进系统1. 推理服务本身暴露两个基础接口最常见的做法是GET /healthGET /metrics其中/health给 K8s / 网关使用/metrics给 Prometheus 抓取2. Prometheus 配置抓取目标Prometheus 会通过配置文件指定哪些服务要抓抓取路径是什么抓取间隔是多少例如它会定时访问http://your-service/metricshttp://dcgm-exporter:9400/metrics这样它就能同时采到应用层指标GPU 层指标3. Grafana 连接 Prometheus 数据源Grafana 不直接抓服务它只需要接入 Prometheus配置 Dashboard展示图表 / 仪表盘 / 告警规则也就是说Prometheus 是“数据仓库”Grafana 是“观察窗口”。十五、如果没有这套链路会发生什么如果一个 AI 推理服务没有/health、/metrics和完整监控链通常会出现这些问题没有 /healthK8s 无法准确判断实例是否可用异常实例继续接流量自动恢复能力弱假活着实例难以发现没有 /metrics无法知道 GPU 是否真的在工作无法定位性能瓶颈无法支撑监控大盘无法做基于指标的扩缩容压测结果无法解释没有 Prometheus / Grafana / dcgm-exporter指标没有地方存GPU 指标看不见无法做可视化趋势分析无法做告警和容量规划也就是说系统不是“不能跑”而是“跑了也不可控”。而这在工程里几乎等于不能上线。十六、从工程角度看/health 和 /metrics 本质上是什么如果只从代码角度看它们可能只是两个很简单的 HTTP 路由GET /healthGET /metrics但从工程角度看它们本质上是AI 服务对外暴露的“可管理接口”也就是说它们不是为了“功能”而是为了运维监控调度自动恢复平台化运行十七、总结如果把整篇文章压缩成一句话一个 AI 推理系统只有业务接口是不够的它还必须能告诉平台我现在活着吗我现在跑得怎么样这也是为什么/health是服务生存能力的一部分/metrics是服务可观测能力的一部分Prometheus / Grafana / dcgm-exporter 是完整监控体系的一部分结语真正能上线的 AI 系统不只是“模型能返回结果”而是它能被监控、能被调度、能被恢复、能被扩展。而/health、/metrics以及完整监控链正是这一切的起点。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】