推理服务栈的分层
一条推理服务链路可以拆成五层：GPU 硬件层、驱动与 CUDA 运行时层、推理引擎层、网关层、应用层。分层不是为了好看，而是为了排障时能快速缩小范围：报错信息、命令行与指标分别属于哪一层，决定了下一步该看日志还是看配置。选型同样按层推进，避免同时改动多层导致问题无法归因。
五层与代表组件
| 硬件层 | GPU 与卡间互联，代表命令 nvidia-smi、拓扑查询 |
|---|---|
| 运行时层 | NVIDIA 驱动、CUDA 运行时、cuDNN 与 PyTorch |
| 引擎层 | vLLM、SGLang、TGI、llama.cpp 等推理框架 |
| 网关层 | Nginx 或 LiteLLM：鉴权、限流、负载均衡 |
| 应用层 | 对话前端、业务后端、检索增强管线 |
逐层确认顺序
逐层确认顺序
nvidia-smi # 1 硬件与驱动：卡在不在、显存够不够
python -c "import torch; print(torch.cuda.is_available())" # 2 运行时能否看到设备
curl http://127.0.0.1:8000/health # 3 引擎进程是否存活
curl http://127.0.0.1:8000/v1/models # 4 引擎接口与模型名是否正常
curl https://your-domain/v1/models # 5 网关转发是否通（换域名再验一次）每层看什么
| 层 | 主要观测手段 | 典型异常 |
|---|---|---|
| 硬件层 | 设备列表、显存占用、温度与降频原因 | 掉卡、显存被占用、持续降频 |
| 运行时层 | 框架能否识别设备、版本是否匹配 | 识别不到设备、库版本不兼容 |
| 引擎层 | 启动日志、健康端点、KV 水位与排队数 | 加载失败、显存不足、请求排队 |
| 网关层 | 访问日志、上游探活、超时与状态码分布 | 转发 502、流式被缓冲、超时 |
| 应用层 | 业务日志、请求编号串联的调用链 | 参数拼错、模板错配、上下文超长 |
分层排障的用法
- 先用本机地址验证引擎、再用域名验证网关：两条链路分开测，才能判断问题在哪一层
- 确认故障层之后再深入该层日志：同时改动多层会让因果无法判断
- 扩容与新版本上线按层核对：镜像、权重、启动参数与网关路由分别有记录
- 每个层留一个最小验证命令：值班时照着顺序执行，不依赖个人经验
- 容量问题自下而上算：先看显存与 KV 池，再看网关连接数，避免只盯一个指标
运行时层是最容易漏检的一层：设备识别失败时，引擎报错往往指向模型文件或显存，实际根因在驱动版本或容器透传。
网关层与引擎层要用不同入口验证：网关用域名、引擎用环回地址，同一台机器上两者表现不同能直接把范围缩到网关配置或后端服务。