一、推理服务和普通 web 服务不一样
它有三个特点：占显存、启动慢、容易被并发打穿。
这三个特点，普通部署文档都不会提。
二、三个必须调的参数
并发上限。
不设，结果就是显存爆满、请求一起挂。
设小了会排队，但不会崩。宁可排队。
单请求超时。
推理很慢。超时设不好，一个卡住的请求会占住一个工作线程。
队列长度。
队列满了就拒绝，不要无限堆。堆多了就是雪崩。
三、一个实际的坑
服务刚启动时，模型还在加载，这时进来的请求全部超时。
解法：启动后先跑一次假请求，等就绪再开流量。
四、部署层的四个习惯
这些思路在 BackendWiki 的 Docker 与 Linux 专题里都能找到对应：
- 用容器固定环境版本。
- 日志写到文件，不要只看控制台。
- 资源限制写死（CPU、内存上限）。
- 用进程守护，不要裸跑。
五、一个最小的健康检查
每五分钟跑一次短请求（一两个字）。
能回就健康，不回就告警。
不要用“端口能通”当健康标准，端口通不代表模型能回答。
六、成本上的一个提醒
显存只有那么多。
两个模型抢一张卡，结果两个都变慢。
要么排队，要么分卡，不要硬塞。
七、一个判断标准
服务好不好，不看峰值高，看“高峰过去了多久”。
队列能快速消化，说明容量合适。
八、一句总结
推理服务的核心不是模型，是排队。