vLLM 生产落地案例
五、生产落地案例
案例一：把单机 transformers 服务换成 vLLM，扛住白天高峰
业务背景：一个内部 AI 助手，最初用 transformers + FastAPI 部署在一台 2 卡机器上。白天高峰期并发一上来，延迟飙升，部分请求超时；显存利用率看似不高，但吞吐上不去。
怎么用：换成 vLLM 的 OpenAI 兼容服务，开张量并行到 2 卡，开启前缀缓存（系统提示与检索片段在所有请求里高度相同，前缀复用收益显著），客户端代码只改 base_url 与 model。上线前用压测脚本从低并发逐步加到目标并发，观察吞吐曲线，找到延迟开始明显上升的拐点，按拐点往下留余量设并发上限。
关键配置：gpu-memory-utilization 不要顶到 1.0，留出激活值与碎片空间；max-model-len 按真实业务长度设，不要图省事设成模型最大长度；max-num-seqs 按压测拐点设。
效果指标：同样的硬件下并发承载能力明显提升（提高幅度取决于请求长度分布与前缀复用率，以自家压测数据为准）；尾延迟明显收敛，超时告警大幅减少。
踩过的坑：一是一开始把 max-model-len 设到模型上限，KV cache 被少数长请求吃光，短请求集体排队，改小以后整体吞吐反而上升；二是容器里 /dev/shm 没调大，张量并行初始化随机卡死，排查了很久；三是客户端没做重试与超时，服务端一次抢占式重启就让整批请求全失败。
案例二：一张卡跑多个 LoRA 适配器，替代多套服务
业务背景：一个 SaaS 产品为不同行业客户提供定制模型，早期做法是每个客户一套服务、一块卡，资源利用率低、运维成本高。
怎么用：用一个基座模型 + 多个 LoRA 适配器的方式部署，服务启动时注册所有适配器，客户端在请求里指定用哪一个。基座的 KV cache 与权重共用，只有适配器部分随请求切换。
关键配置：按最大的适配器秩设置 max-lora-rank；限制适配器数量以避免显存超限；对每个适配器做小流量回归测试，确认挂载后输出与单独部署一致。
效果指标：单卡承载的客户数量提升（具体取决于适配器大小与 max-lora-rank 的设置）；部署与升级从「按客户各来一次」变成「一次升级全量生效」。
踩过的坑：一是不同客户请求混在同一批，前缀缓存没有收益，后来对同一客户的请求做路由分组；二是适配器秩设置小于实际，加载时报错或效果异常；三是没有做请求级的适配器鉴权，理论上客户可以指定别人的适配器名，补了服务端校验。
