vLLM Inference: 高并发 LLM 推理服务系统
Published:
项目概述
基于 vLLM + FastAPI 构建的高并发 LLM 推理服务系统。项目的核心目标不是做一个”聊天机器人”，而是搭建一个生产级的 LLM 推理服务基础设施，重点解决高并发场景下的吞吐量和延迟优化问题。
系统实现了完整的推理服务栈：接收 HTTP 请求、动态合并请求为批次、调用 GPU 推理引擎执行生成、返回 OpenAI 兼容格式的响应。
核心模块
| 模块 | 功能 |
|---|---|
| Dynamic Batcher | 自研 Leader/Follower 模式的动态批处理器，自动合并请求提升吞吐 |
| Inference Engine | 封装 vLLM 的 LLM 类，负责模型加载和批量推理 |
| Streaming Handler | SSE 协议转换层，逐 token 推送生成内容 |
| OpenAI Compatible API | 完整实现 OpenAI Chat Completions API 格式 |
Dynamic Batching（Leader/Follower 模式）
这是项目最核心的创新点：
- Leader：第一个到达的请求自动成为 Leader，负责收集和处理整个 batch
- Follower：后续到达的请求通过
asyncio.Future挂起等待结果 - Batch Timeout：Leader 等待 100ms 时间窗口收集请求，然后一次性提交给 GPU
- 并发安全：使用
asyncio.Lock避免多个协程同时争抢 Leader 角色
实测效果：Batch size 从 1 到 16，吞吐量提升 15 倍（161 → 2385 tokens/s）。
OpenAI 兼容 API
完整实现了 OpenAI Chat Completions API 格式：
POST /v1/chat/completions— 对话补全（支持流式和非流式）POST /v1/completions— 文本续写GET /v1/models— 模型列表GET /health— 健康检查
支持直接使用 openai Python SDK 调用，无需修改客户端代码。
性能测试结果
Batch Size 对吞吐量的影响（Qwen2.5-0.5B, RTX 3060）：
| Batch Size | 吞吐量 (tokens/s) | 延迟 (s) |
|---|---|---|
| 1 | 161 | 1.239 |
| 4 | 773 | 0.204 |
| 16 | 2385 | 0.081 |
并发客户端测试：
| 并发数 | 吞吐量 (tokens/s) |
|---|---|
| 1 | 45 |
| 8 | 552 |
| 16 | 784 |
量化对比：GPTQ-Int4 量化后吞吐量与 FP16 基本持平，但显存占用更低。
项目亮点
自研 Dynamic Batching 的 Leader/Follower 模式。 不同于简单的定时批处理，用 asyncio.Future 实现请求间协调，避免后台定时任务的复杂性。
用有限 GPU 资源做出完整实验。 在 RTX 3060 Laptop（6GB 显存）上完成全部 benchmark，实验设计覆盖 batch size、context length、量化方式、并发客户端四个维度。
完整的工程化实践。 包含 Dockerfile 容器化部署、Pytest 单元测试、多个独立的 benchmark 脚本、Chrome Trace 性能可视化。
代码即文档。 每个文件都有详细的中文注释，解释”为什么这样做”而不仅仅是”做了什么”。