从零开始用 vLLM 搭建你的第一个 AI 推理服务——给 AI、微服务和 SRE 小白的实战指南如果你刚接触大模型AI想把它跑起来对外提供服务微服务又希望这个服务稳定、可监控、能扩容SRE/DevOps——那么这篇文章就是为你写的。我们会用一个真实的开源项目vLLM带你走完从模型文件到生产级服务的完整旅程。一、先搞清楚vLLM 到底是什么想象你开了一家智能问答餐厅顾客 用户发来的问题比如请写一首关于夏天的诗厨师 GPU负责计算答案菜谱记忆 模型参数几十亿到几千亿个数字正在做的菜 KV Cache模型推理时产生的中间记忆传统做法里每位顾客点完菜厨师都要独占一张大桌子显存来放食材。顾客少的时候没问题但人一多桌子不够用了很多位置空着却没法给别人用——显存浪费严重。vLLM 的核心创新PagedAttention就像是给餐厅引入了一套智能拼桌系统不再给每位顾客预留整张大桌而是把桌子切成很多小格子pages/block谁来谁领格子走人就回收多个顾客可以灵活共享空间结果同样的 GPU 显存能同时服务的顾客数量提升了好几倍。二、AI 小白篇5 分钟跑通第一个大模型2.1 安装不需要懂深度学习vLLM 的安装简单得不像一个 AI 项目bash# 推荐用 uv比 pip 快 uv pip install vllm # 或者传统方式 pip install vllm2.2 启动你的第一个 AI 服务假设你有一块 8GB 以上的 NVIDIA 显卡bashvllm serve Qwen/Qwen2.5-7B-Instruct \ --dtype half \ --max-model-len 4096看到Application startup complete就说明服务起来了2.3 测试一下打开另一个终端bashcurl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen/Qwen2.5-7B-Instruct, messages: [{role: user, content: 你好请介绍一下自己}] }如果返回了一段通顺的中文回答恭喜你——你已经部署了一个真正的 LLM 推理服务AI 知识点Qwen2.5-7B是一个 70 亿参数的开源中文大模型。参数越多模型越聪明但也越吃显存。7B 是性价比很高的入门选择。三、微服务小白篇把 vLLM 包装成正式服务单机跑起来只是第一步。在真实的公司里AI 模型通常以微服务的形式存在——独立部署、通过 API 通信、可以被多个业务系统调用。3.1 为什么需要微服务化想象你的公司有三个产品客服机器人文档摘要工具代码助手它们都用同一个大模型。如果每个产品自己加载一份模型显存直接爆炸。微服务的思路是模型只加载一次通过 API 供所有人调用。3.2 Docker 化部署微服务的标准姿势创建一个DockerfiledockerfileFROM vllm/vllm-openai:latest # 暴露 vLLM 默认端口 EXPOSE 8000 # 启动命令 CMD [--model, Qwen/Qwen2.5-7B-Instruct, \ --dtype, half, \ --max-model-len, 4096]构建并运行bashdocker build -t my-vllm-service . docker run --gpus all -p 8000:8000 my-vllm-service现在你的 AI 服务已经容器化了可以轻松地在任何有 Docker 的机器上运行用 Kubernetes 管理多实例通过负载均衡分发请求3.3 docker-compose一键启动完整环境创建docker-compose.ymlyamlversion: 3.8 services: vllm: image: vllm/vllm-openai:latest ports: - 8000:8000 environment: - CUDA_VISIBLE_DEVICES0 command: --model Qwen/Qwen2.5-7B-Instruct --dtype half --max-model-len 4096 deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu]启动bashdocker-compose up -d微服务知识点docker-compose让你用一份配置文件定义整个服务栈。后续还可以加上 Nginx反向代理、Redis缓存、Prometheus监控等组件。四、SRE / DevOps 小白篇让服务稳如老狗服务跑起来只是 20% 的工作。作为 SRE站点可靠性工程师你需要回答三个问题服务现在健康吗性能够不够用出问题怎么知道4.1 监控给服务装上仪表盘vLLM 内置了 Prometheus 指标暴露。添加监控只需要在启动时加上参数bashvllm serve Qwen/Qwen2.5-7B-Instruct \ --dtype half \ --prometheus-port 8001然后在docker-compose.yml里加上监控栈yamlservices: vllm: image: vllm/vllm-openai:latest ports: - 8000:8000 # API 端口 - 8001:8001 # 监控指标端口 command: --model Qwen/Qwen2.5-7B-Instruct --dtype half --prometheus-port 8001 prometheus: image: prom/prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml ports: - 9090:9090 grafana: image: grafana/grafana ports: - 3000:3000关键监控指标表格指标名含义SRE 关注点vllm:num_requests_running正在处理的请求数是否接近并发上限vllm:gpu_cache_usage_percGPU KV Cache 使用率接近 100% 说明显存不够了vllm:time_to_first_token首 token 延迟用户感知的响应速度vllm:time_per_output_token每个输出 token 的耗时生成速度是否达标4.2 日志出问题时有迹可循在容器环境里日志管理很重要。建议bash# 查看实时日志 docker logs -f container_id # 或者配置日志驱动直接发到 ELK/Loki docker run --log-driver fluentd ...vLLM 的日志会显示模型加载进度每次请求的输入/输出 token 数错误信息如 OOM、模型下载失败4.3 高可用单点故障怎么办对于小白来说先理解这些概念表格策略说明vLLM 支持情况多实例负载均衡同时跑 2-3 个 vLLM 实例前面加 Nginx✅ 完全支持健康检查自动剔除不健康的实例✅ 通过/health端点自动扩缩容请求多了自动加 GPU少了自动减⚠️ 需配合 K8s GPU 调度模型热更新不重启服务切换模型版本❌ 目前需重启一个简单的 Nginx 负载均衡配置nginxupstream vllm_backend { server vllm-1:8000; server vllm-2:8000; } server { listen 80; location /v1/ { proxy_pass http://vllm_backend; } }4.4 性能调优SRE 的必修课作为 SRE你需要了解几个调参旋钮bashvllm serve Qwen/Qwen2.5-7B-Instruct \ --dtype half \ # 精度half 省显存float 更准 --max-model-len 4096 \ # 最大上下文长度 --gpu-memory-utilization 0.9 \ # GPU 显存使用上限留 10% 余量 --max-num-seqs 256 \ # 最大并发请求数 --enable-prefix-caching \ # 开启前缀缓存重复 prompt 加速 --quantization awq # 如果显存不够启用 4bit 量化SRE 知识点gpu-memory-utilization是防止 OOM显存溢出的关键。不要设 1.0留一些 buffer 给 CUDA 运行时和突发请求。五、完整实战从 0 到 1 的 checklist如果你是跟着文章一步步做的现在你应该已经拥有[ ] 本地跑通了 vLLM能和 AI 对话[ ] 用 Docker 把服务容器化了[ ] 用 docker-compose 定义了可复现的部署[ ] 接入了 Prometheus Grafana 监控[ ] 理解了 PagedAttention、KV Cache、量化等核心概念六、给不同阶段读者的学习路径 如果你偏向 AI 方向精读 vLLM 的 PagedAttention 论文学习 CUDA 编程理解 kernel 优化尝试修改 vLLM 源码实现自定义调度策略 如果你偏向微服务/DevOps 方向学习 Kubernetes尝试用 K8s 部署 vLLM研究 vLLM 的分布式推理Tensor Parallelism Pipeline Parallelism搭建完整的 LLM 服务网关鉴权、限流、计费 如果你偏向 SRE 方向建立 LLM 服务的 SLI/SLO如P99 延迟 500ms可用性 99.9%设计告警规则GPU 利用率、请求错误率、队列堆积实现自动化运维自动扩缩容、模型版本灰度发布七、写在最后vLLM 是一个绝佳的交叉学科项目对AI 学习者它是理解 LLM 推理优化的最佳入口对后端/微服务开发者它是把 AI 能力产品化的标准工具对SRE/DevOps它是挑战 GPU 集群运维的真实战场你不需要一开始就把所有东西都搞懂。先跑起来再慢慢深入。记住先让服务工作再让它工作得好最后让它工作得可靠。有任何问题欢迎在 vLLM 的 GitHub Discussions 或社区论坛提问。祝你部署顺利参考链接vLLM GitHub: GitHub - vllm-project/vllm: A high-throughput and memory-efficient inference and serving engine for LLMs · GitHub官方文档: https://docs.vllm.aiPagedAttention 论文: [2309.06180] Efficient Memory Management for Large Language Model Serving with PagedAttention
从零开始用 vLLM 搭建你的第一个 AI 推理服务——给 AI、微服务和 SRE 小白的实战指南如果你刚接触大模型AI想把它跑起来对外提供服务微服务又希望这个服务稳定、可监控、能扩容SRE/DevOps——那么这篇文章就是为你写的。我们会用一个真实的开源项目vLLM带你走完从模型文件到生产级服务的完整旅程。一、先搞清楚vLLM 到底是什么想象你开了一家智能问答餐厅顾客 用户发来的问题比如请写一首关于夏天的诗厨师 GPU负责计算答案菜谱记忆 模型参数几十亿到几千亿个数字正在做的菜 KV Cache模型推理时产生的中间记忆传统做法里每位顾客点完菜厨师都要独占一张大桌子显存来放食材。顾客少的时候没问题但人一多桌子不够用了很多位置空着却没法给别人用——显存浪费严重。vLLM 的核心创新PagedAttention就像是给餐厅引入了一套智能拼桌系统不再给每位顾客预留整张大桌而是把桌子切成很多小格子pages/block谁来谁领格子走人就回收多个顾客可以灵活共享空间结果同样的 GPU 显存能同时服务的顾客数量提升了好几倍。二、AI 小白篇5 分钟跑通第一个大模型2.1 安装不需要懂深度学习vLLM 的安装简单得不像一个 AI 项目bash# 推荐用 uv比 pip 快 uv pip install vllm # 或者传统方式 pip install vllm2.2 启动你的第一个 AI 服务假设你有一块 8GB 以上的 NVIDIA 显卡bashvllm serve Qwen/Qwen2.5-7B-Instruct \ --dtype half \ --max-model-len 4096看到Application startup complete就说明服务起来了2.3 测试一下打开另一个终端bashcurl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen/Qwen2.5-7B-Instruct, messages: [{role: user, content: 你好请介绍一下自己}] }如果返回了一段通顺的中文回答恭喜你——你已经部署了一个真正的 LLM 推理服务AI 知识点Qwen2.5-7B是一个 70 亿参数的开源中文大模型。参数越多模型越聪明但也越吃显存。7B 是性价比很高的入门选择。三、微服务小白篇把 vLLM 包装成正式服务单机跑起来只是第一步。在真实的公司里AI 模型通常以微服务的形式存在——独立部署、通过 API 通信、可以被多个业务系统调用。3.1 为什么需要微服务化想象你的公司有三个产品客服机器人文档摘要工具代码助手它们都用同一个大模型。如果每个产品自己加载一份模型显存直接爆炸。微服务的思路是模型只加载一次通过 API 供所有人调用。3.2 Docker 化部署微服务的标准姿势创建一个DockerfiledockerfileFROM vllm/vllm-openai:latest # 暴露 vLLM 默认端口 EXPOSE 8000 # 启动命令 CMD [--model, Qwen/Qwen2.5-7B-Instruct, \ --dtype, half, \ --max-model-len, 4096]构建并运行bashdocker build -t my-vllm-service . docker run --gpus all -p 8000:8000 my-vllm-service现在你的 AI 服务已经容器化了可以轻松地在任何有 Docker 的机器上运行用 Kubernetes 管理多实例通过负载均衡分发请求3.3 docker-compose一键启动完整环境创建docker-compose.ymlyamlversion: 3.8 services: vllm: image: vllm/vllm-openai:latest ports: - 8000:8000 environment: - CUDA_VISIBLE_DEVICES0 command: --model Qwen/Qwen2.5-7B-Instruct --dtype half --max-model-len 4096 deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu]启动bashdocker-compose up -d微服务知识点docker-compose让你用一份配置文件定义整个服务栈。后续还可以加上 Nginx反向代理、Redis缓存、Prometheus监控等组件。四、SRE / DevOps 小白篇让服务稳如老狗服务跑起来只是 20% 的工作。作为 SRE站点可靠性工程师你需要回答三个问题服务现在健康吗性能够不够用出问题怎么知道4.1 监控给服务装上仪表盘vLLM 内置了 Prometheus 指标暴露。添加监控只需要在启动时加上参数bashvllm serve Qwen/Qwen2.5-7B-Instruct \ --dtype half \ --prometheus-port 8001然后在docker-compose.yml里加上监控栈yamlservices: vllm: image: vllm/vllm-openai:latest ports: - 8000:8000 # API 端口 - 8001:8001 # 监控指标端口 command: --model Qwen/Qwen2.5-7B-Instruct --dtype half --prometheus-port 8001 prometheus: image: prom/prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml ports: - 9090:9090 grafana: image: grafana/grafana ports: - 3000:3000关键监控指标表格指标名含义SRE 关注点vllm:num_requests_running正在处理的请求数是否接近并发上限vllm:gpu_cache_usage_percGPU KV Cache 使用率接近 100% 说明显存不够了vllm:time_to_first_token首 token 延迟用户感知的响应速度vllm:time_per_output_token每个输出 token 的耗时生成速度是否达标4.2 日志出问题时有迹可循在容器环境里日志管理很重要。建议bash# 查看实时日志 docker logs -f container_id # 或者配置日志驱动直接发到 ELK/Loki docker run --log-driver fluentd ...vLLM 的日志会显示模型加载进度每次请求的输入/输出 token 数错误信息如 OOM、模型下载失败4.3 高可用单点故障怎么办对于小白来说先理解这些概念表格策略说明vLLM 支持情况多实例负载均衡同时跑 2-3 个 vLLM 实例前面加 Nginx✅ 完全支持健康检查自动剔除不健康的实例✅ 通过/health端点自动扩缩容请求多了自动加 GPU少了自动减⚠️ 需配合 K8s GPU 调度模型热更新不重启服务切换模型版本❌ 目前需重启一个简单的 Nginx 负载均衡配置nginxupstream vllm_backend { server vllm-1:8000; server vllm-2:8000; } server { listen 80; location /v1/ { proxy_pass http://vllm_backend; } }4.4 性能调优SRE 的必修课作为 SRE你需要了解几个调参旋钮bashvllm serve Qwen/Qwen2.5-7B-Instruct \ --dtype half \ # 精度half 省显存float 更准 --max-model-len 4096 \ # 最大上下文长度 --gpu-memory-utilization 0.9 \ # GPU 显存使用上限留 10% 余量 --max-num-seqs 256 \ # 最大并发请求数 --enable-prefix-caching \ # 开启前缀缓存重复 prompt 加速 --quantization awq # 如果显存不够启用 4bit 量化SRE 知识点gpu-memory-utilization是防止 OOM显存溢出的关键。不要设 1.0留一些 buffer 给 CUDA 运行时和突发请求。五、完整实战从 0 到 1 的 checklist如果你是跟着文章一步步做的现在你应该已经拥有[ ] 本地跑通了 vLLM能和 AI 对话[ ] 用 Docker 把服务容器化了[ ] 用 docker-compose 定义了可复现的部署[ ] 接入了 Prometheus Grafana 监控[ ] 理解了 PagedAttention、KV Cache、量化等核心概念六、给不同阶段读者的学习路径 如果你偏向 AI 方向精读 vLLM 的 PagedAttention 论文学习 CUDA 编程理解 kernel 优化尝试修改 vLLM 源码实现自定义调度策略 如果你偏向微服务/DevOps 方向学习 Kubernetes尝试用 K8s 部署 vLLM研究 vLLM 的分布式推理Tensor Parallelism Pipeline Parallelism搭建完整的 LLM 服务网关鉴权、限流、计费 如果你偏向 SRE 方向建立 LLM 服务的 SLI/SLO如P99 延迟 500ms可用性 99.9%设计告警规则GPU 利用率、请求错误率、队列堆积实现自动化运维自动扩缩容、模型版本灰度发布七、写在最后vLLM 是一个绝佳的交叉学科项目对AI 学习者它是理解 LLM 推理优化的最佳入口对后端/微服务开发者它是把 AI 能力产品化的标准工具对SRE/DevOps它是挑战 GPU 集群运维的真实战场你不需要一开始就把所有东西都搞懂。先跑起来再慢慢深入。记住先让服务工作再让它工作得好最后让它工作得可靠。有任何问题欢迎在 vLLM 的 GitHub Discussions 或社区论坛提问。祝你部署顺利参考链接vLLM GitHub: GitHub - vllm-project/vllm: A high-throughput and memory-efficient inference and serving engine for LLMs · GitHub官方文档: https://docs.vllm.aiPagedAttention 论文: [2309.06180] Efficient Memory Management for Large Language Model Serving with PagedAttention
