Kubernetes + vLLM实测：单机部署千问2.5-72B推理服务，吞吐提升3倍
兄弟们，最近在搞大模型推理基础设施的选型，正好对vLLM做了一轮深度测试，分享下实战数据。先说结论：用vLLM（v0.6.0）部署Qwen2.5-72B（FP16），搭配Kubernetes的HPA弹性伸缩，单机4卡A100-80G上，吞吐量从原始的HuggingFace Transformers的8.5 token/s飙升到31.2 token/s，延迟从420ms降到95ms（输入长度512）。关键在于vLLM的PagedAttention和连续批处理，把显存利用率从52%拉到89%。
踩坑点：很多人直接上Deployment，但大模型推理有突发流量，建议用StatefulSet绑定GPU节点亲和性。另外，K8s的默认GPU调度器会留显存空洞，得配`nvidia.com/gpu.memory`资源限制，否则OOM频繁。我们改用了NVIDIA的MIG分区，把每块A100切成1g.10gb实例，跑轻量模型（7B-13B）时成本降了40%。
想干这行的，建议先跑通vLLM的OpenAI兼容API，再用Prometheus + Grafana监控token生成速度和队列深度。源码在GitHub的vllm-project/vllm，文档写得很详细，但注意别用老版本（<0.5.0），之前有个memory leak的bug修了。
不废话，直接上命令示例：
```bash
helm repo add vllm https://vllm-project.github.io/helm-charts
helm install qwen vllm/vllm --set model=Qwen/Qwen2.5-72B-Instruct --set gpu=4
```
有坑再问，评论区见。 老哥这个数据很实在！31.2 token/s确实香，PagedAttention把显存利用率拉满太关键了。我好奇你们StatefulSet绑GPU时，HPA怎么处理推理请求的排队和冷启动？ @楼上 冷启动确实疼，我们试过把prewarm脚本塞init container里，配合HPA的scale-down延迟，基本能扛住突发。不过排队还得靠外部队列，你那边用的啥调度策略？😅 @楼上，排队用Redis队列+自定义metric搞的，冷启动确实头疼，我们预加载了几个pod保底。不过你试过vLLM的continuous batching吗？配合HPA更顺滑 😏
页:
[1]