两类端点别混用
推理服务暴露的端点大致分两类：一类是业务端点，例如列出模型的接口与对话补全接口，走鉴权与业务逻辑、会消耗算力；另一类是探针端点，例如 /health，只回答「进程还活着吗」，通常不鉴权也不触发推理。把两类分开用，是负载均衡与监控不误伤实例的前提。
基本信息
| 业务端点 | /v1/models、/v1/chat/completions |
|---|---|
| 探针端点 | /health（名称以实现为准） |
| 探针特点 | 轻量、通常不鉴权、不推理 |
| 探测频率 | 存活秒级、模型列表低频 |
| 鉴权 | 业务端点需要，探针通常不需要 |
典型使用场景
- 配置负载均衡的存活检查
- 写容器编排的存活与就绪探针
- 发布后确认模型是否真的加载成功
- 监控脚本判断实例能不能接流量
- 区分「进程活着」与「模型可用」两种状态
- 给监控设置分级：探针失败立即告警，模型列表异常按发布流程处理
两类请求分开用
两类请求分开用
curl -s http://127.0.0.1:8000/v1/models | head # 业务查询：看模型列表
curl -sf -o /dev/null http://127.0.0.1:8000/health # 探活：--fail 让非 2xx 直接失败
# 不要用业务接口做高频探活：繁忙时它会超时，实例会被误摘常用端点分工
| 端点 | 作用 | 使用频率 |
|---|---|---|
| /health | 进程存活 | 秒级高频 |
| /v1/models | 模型可用性 | 分钟级或发布后 |
| /v1/chat/completions | 真实业务 | 按实际流量 |
| /metrics | 指标暴露 | 秒到分钟级 |
探针端点通常不鉴权、不触发推理：放进负载均衡的存活检查里开销可控；反过来把业务接口当探针，实例越忙越容易被摘掉。
「进程活着」不等于「模型可用」：权重加载失败时进程可能仍在运行，发布后还要用一次真实推理请求确认，不能只信探针。
部分实现里模型列表是缓存的：更新权重后需要重启或触发热加载，列表才会变化，把列表没变直接当成加载失败是常见误判。
把探针路径写进部署模板：每个项目自己填容易填错，模板统一之后这类问题会少很多。