什么是 vLLM？
vLLM 是执行受支持语言、多模态、Embedding、Scoring 等模型工作负载的开源 Library 与 Server Runtime。它组合请求调度器、分页 KV Cache 管理、优化模型执行和版本化服务 Frontend。它可能在合适负载上改善容量或吞吐，但不保证更低延迟、完整 API 等价、模型质量、安全租户隔离或生产就绪。
快速了解
| 全称 | vLLM 大模型推理与服务引擎 |
|---|---|
| 规范文档 | 官方规范 |
工作原理
vLLM 把模型执行与应用职责分开。身份认证、请求路由、Policy、输出评测和 SLO 仍由外围系统负责。它在系统领域最知名的贡献是 PagedAttention：按 Block 分配 KV Cache 状态，不要求为每条 Sequence 预留一段连续空间，从而减少碎片，并在受支持的解码模式中共享缓存。SOSP 2023 论文相对 FasterTransformer 与 Orca 报告的吞吐提升只属于被测模型和负载，不是当前 vLLM 相对所有当前 Runtime 的固定倍数。
当前项目把分页 KV Cache 与连续请求调度结合，并提供 Chunked Prefill、Prefix Caching、Speculative Decoding、Quantization、Structured Output、部分 Tool / Reasoning Parser、多模态执行和多种 Parallelism。支持范围随 vLLM Release、模型架构、Artifact、Quantization、Attention Backend、Accelerator、Kernel 与 Frontend 改变。部署契约应固定 Engine 或 Image Digest、Model 与 Tokenizer Revision、Chat Template、Generation Default、Quantization、Context Limit、Parallel Topology、Plugin、Parser 和所有影响行为的 Flag。
HTTP Server 实现文档列出的 OpenAI-compatible 等 Endpoint，不表示与托管 Provider 在所有行为上等价。Endpoint 是否存在、忽略或扩展的 Parameter、Chat Template 要求、Streaming Event、Structured Output、Usage Field、Tool-call Parsing、Error Class 与 Cancellation 都要针对选定模型和版本测试。模型输出仍是不可信数据；即使 Server 生成了符合 Schema 的 Tool Argument，也不代表操作已经授权或执行。
容量取决于工作负载分布。分页分配和连续调度可以减少浪费或提高整体吞吐，但长 Prompt、长 Output、大 n、多模态输入、Beam / Parallel Sampling、Preemption、Cache Pressure、通信和慢客户端都会改变排队与尾延迟。基准应固定 Artifact 与硬件，覆盖代表性输入输出长度、Arrival Rate、Burstiness、Concurrency、Warmup 和 SLO。除 Tokens/s 外，还应报告通过质量门禁的 Goodput、TTFT、TPOT 或 ITL、E2E Latency、Queue Time、Preemption、KV Cache 使用、Error 与 Cost。
跨 GPU 或节点扩展会引入拓扑和信任边界。Tensor、Pipeline、Data、Expert 与 Context Parallelism 的内存、通信、Kernel 和故障权衡不同。vLLM 官方安全指南明确说明，节点间及 PyTorch Distributed 通信默认不安全，只应运行在隔离可信网络；内置 API Key 也不会保护同一 Server 上的所有 Endpoint。生产部署因此还需要 Reverse Proxy 或 Gateway、TLS、Endpoint Allowlist、Authentication、对象级 Authorization、请求与媒体限制、Network Segmentation、Egress Control、Rate / Spend Limit、Artifact Provenance、补丁和可验证回滚。
运营证据必须绑定部署的 Engine Revision，因为 Metric Name 与语义遵循版本淘汰周期。应监测 Request Outcome、Waiting / Running Request、Queue、Prefill、Decode、TTFT、TPOT、ITL、E2E Latency、Token Count、Preemption、Cache Usage、Corrupted Request、Worker Health 与 Dependency Failure。运行时指标不能证明答案正确或符合 Policy，还需独立执行任务、安全、Structured Output、Tool Use 与模型质量评测。
主要特点
- 服务运行时而非模型 — 执行受支持制品，但不提供应用真值、授权或产品策略
- 分页 KV Cache 管理 — 按 Block 分配序列状态，减少碎片并支持特定共享方式
- 连续调度 — 动态调度变化中的请求集合，而不是等待固定 Batch 全部完成
- 版本化能力矩阵 — 模型、量化、Kernel、硬件、Parser、API 与并行支持随 Release 变化
- 多种执行路径 — 离线推理、在线服务、分布式执行和专用模型任务具有不同契约
- 可观测但不负责完整运营 — 暴露 Engine Metric，SLO、安全、扩缩容、事故响应与回滚仍由系统负责
常见用途
- 在应用自有认证与 Policy 边界后服务固定的开放权重模型
- 代表性基准证明调度与分页 KV Cache 对批量或在线推理有价值的场景
- 在同一版本化负载上比较 Quantization、Parallelism、Prefix Cache 或 Speculative Decoding
- 暴露经过测试的 Completion、Chat、Embedding、Score、Rerank、Transcription 等受支持 Endpoint
- 完成拓扑、通信、恢复与安全测试后跨可信 Accelerator 或 Node 扩展模型
- 收集 Queue、Prefill、Decode、Latency、Token、Cache 与 Preemption 信号进行容量管理
示例
Loading code...常见问题
vLLM 是语言模型吗？
不是。vLLM 是推理与服务引擎。模型、Tokenizer、Template、Adapter、Quantization、Parser 与 Policy 需要单独选择，它们共同决定行为和质量。
vLLM 一定能提高吞吐或降低延迟吗？
不一定。分页 Cache 与连续调度针对显存浪费和整体服务效率，但结果取决于模型、制品、硬件、输入输出分布、到达负载、并发、启用功能和 SLO。应在精确部署上比较通过质量门禁的 Goodput 与尾延迟。
vLLM Server 与 OpenAI API 完全兼容吗？
不存在通用等价保证。vLLM 会记录受支持 Endpoint、扩展字段、Template、Parser 与限制。必须针对固定版本测试 Parameter、Streaming、Cancellation、Error、Usage、Structured Output、Tool Call 与模型行为。
--api-key 能让 vLLM 部署达到生产安全要求吗？
不能。当前官方指南说明 API Key 不覆盖全部 Endpoint，而且分布式通信默认不安全。仍需隔离网络、防火墙、Reverse Proxy 或 Gateway、TLS、Endpoint Allowlist、Authorization、请求限制、制品控制、监控与补丁管理。
团队应该怎样评测 vLLM？
固定 Engine、Model Artifact、Tokenizer、Template、Quantization、Hardware、Topology 与 Flag，重放代表性的 Arrival Rate、Burstiness、输入输出长度、Concurrency 与功能组合。报告任务质量、Goodput、TTFT、TPOT 或 ITL、E2E 与 Queue Latency、Throughput、Error、Preemption、Cache Usage 与 Cost。