是否尝试过在自己的 GPU 上托管大型语言模型，却感觉像是养了一个非常饥饿的电子宠物？你需要不断地给它提供 VRAM，小心地调整内核，而当你最终向它寻求答案时……它会对着你闪烁五秒钟，然后溜之大吉。这就是我使用“原生” LLM 服务器度过的周末。然后我安装了 vLLM。
剧透一下：vLLM 是一个开源引擎，它让 LLM 推理感觉就像是你把三轮车换成了 Tesla。这篇 vLLM 评测深入探讨了它是什么，它如何从你的硬件预算中榨取更多 tokens，它的优势、劣势，以及哪些人应该将它加入购物车、集群，或者“以后再说”的列表中。
用通俗易懂的语言（以及更少的 GPU 泪水）来解释，vLLM 是什么？
vLLM 是一个用于大型语言模型的开源推理和服务引擎。可以把它想象成集空中交通管制员、行李搬运工和廉价航空公司于一身的角色——它负责调度请求，将 tokens 打包到 GPU 内存中，并高效起飞，而不会留下空座位 (VRAM)。它将你熟悉的模型——、、、、、——封装在熟悉的 API 之后（ 风格， 兼容），然后通过巧妙的内存技巧和调度来增强它们的功能。
如果你尝试过使用简单的循环，甚至是通用的服务框架来运行 LLM，你可能已经遇到了最大的速度杀手：浪费的内存。vLLM 的标志性动作是 ，这是一个动态内存管理器，它将键/值注意力缓存视为操作系统中的页面。翻译一下：它不是给每个对话都在 VRAM 中提供一个私人顶层公寓，而是将顶层公寓变成一个联合办公空间。可以容纳更多的人（请求）。每个人打字速度都更快。
这篇 vLLM 评测适合哪些人？
- 希望获得低延迟聊天和高吞吐量批处理作业的 AI 应用开发团队。
- 正在寻找商业 LLM 终端的开源替代方案的基础设施人员。
- 试图通过自托管来降低 token 成本的初创公司实用主义者。
如果你属于“我只是想要一个提示框和氛围”的类型，你可能更喜欢托管 API。如果你属于“我想要 10 倍的吞吐量，而不需要 10 倍的预算”的类型，请继续阅读。
vLLM 的主要特性（以及你应该关心的原因）
- ：用于注意力 KV 缓存的内存分页。这是 vLLM 可以在不丢帧的情况下处理大量请求的原因。
- （持续批处理）：新的请求加入到正在进行的批处理中，因此 GPU 始终保持繁忙状态，并且延迟保持在合理范围内。
- 兼容的 API：将其插入为 构建的工具和 SDK，只需进行最少的代码更改。
- Tensor/量化支持：、 和流行的量化权重（如 、，如果适用），因此你可以将更大的大脑装入更小的 GPU 中。
- 多 GPU 和分布式服务：当你的单个 开始发热时，可以横向扩展。
- 流式传输 tokens：用户看到单词像好莱坞黑客场景一样打出来，这在某种程度上让一切感觉更快。
- /适配器支持（取决于模型）：如果你在同一基本模型上提供微调变体，这将非常有用。
快速设置的故事（又名：我能以多快的速度获得第一个 token？）
- 通过 pip 安装 vLLM。无需召唤仪式：
pip install vllm
- 将其指向 Hugging Face 上的模型或你的本地权重。
在我对消费级 GPU 和带有数据中心卡的 workstation 进行的测试中，time-to-first-token 感觉明显比 stock transformers server 设置更快，尤其是在负载下。当多个用户（或你自己的批处理作业）涌入服务器时，奇迹就会出现——vLLM 可以让 GPU 保持满负荷运行。
基准测试、延迟和真实世界的氛围
以下是在 vLLM 评测中脱颖而出的内容：
- 吞吐量：通过持续批处理，vLLM 每秒可以处理多个请求，而不会将你的 GPU 变成一个只会打印省略号的空间加热器。你向它抛出的并发请求越多（在合理的范围内），它就越能发挥作用。
- 延迟：Time-to-first-token 具有竞争力，有时甚至优于我尝试过的其他开源服务器——尤其是在启用流式传输并且提示词为中短长度时。
- 长输出：持续生成是稳定的。对于非常长的生成，你需要调整 max_tokens、beam 设置（如果必须）和温度，以保持 VRAM 的舒适度。
- 混合工作负载：它非常擅长同时处理聊天、工具使用提示和轻量级批处理评分。就像一家餐厅，既提供煎饼，又提供泰式炒河粉，而不会让任何人中毒。
你的数字将取决于 GPU 等级、量化、序列长度和模型选择。但模式是一致的：随着并发性的增加，vLLM 会领先。
vLLM 相对于其他 LLM 服务器的优势
- 如果你的首要任务是以最小的延迟下降为大量交互式用户提供服务，那么 vLLM 的调度程序和 是非常出色的。
- 如果你需要 兼容的终端来插入现有应用程序，那么它是即插即用型的。
- 如果你正在进行成本优化，你通常可以降级到稍微小一点的 GPU 等级，或者从相同的硬件中挤出更多的 req/sec。各地的 CFO 们都精神起来了。
vLLM 可能让你感到沮丧的地方（它不是魔法粉尘）
- 模型兼容性不是通用的。大多数流行的开放权重运行良好，但奇异的架构或前沿的量化格式可能需要调整，或者可能尚不支持。
- 内存仍然是物理学的范畴。 有所帮助，但在具有 100 个并发用户的 6GB GPU 上运行 7B 模型仍然是情景喜剧，而不是服务器。
- 高级多租户和 guardrails 可能需要与其他工具配对或编写粘合代码。
- 更新速度很快。对于功能来说，这是一个优点，如果你想要停滞的稳定性，这是一个缺点。
vLLM 与常见的竞争对手（友好的对决）
- ：TGI 经过精心打磨，在企业中很受欢迎。vLLM 通常在吞吐量方面略胜一筹，这得益于动态批处理和 ，尤其是在聊天工作负载方面。TGI 具有强大的 集成和可靠的生产人体工程学。选择 vLLM 以获得原始服务速度和类似 的 API；如果你深入研究 HF 工具并想要他们的 ops 模式，请选择 TGI。
- ：许多都非常适合实验。vLLM 通常在并发性和内存效率方面获胜。如果你正在构建一个具有高峰流量的消费者应用程序，vLLM 的调度有助于缩短尾部。
- ：你可以手工制作一个出色的服务器，但 vLLM 打包了你无论如何都要构建的技巧——而且你无需维护一个小城市的内核。
深入探讨：为什么 很重要
将模型的注意力思考空间想象成一个巨大的白板。每次对话都会在上面绘制。大多数服务器都会分配一个完整的区域——即使对话只有两个涂鸦和一个笑脸。 将该白板分成便利贴，并将它们移入移出。更多的人可以同时绘画，更少的间隙，更少的空间浪费。这就是为什么当真实世界——又名许多用户询问随机内容——出现时，vLLM 能够保持性能。
开发者体验：舒适还是复杂？
- API 舒适度：你将获得模仿 的 REST 终端。带上你现有的客户端、提示模板和记录器。
- 配置：合理的默认值，带有大量用于批处理大小、张量并行性、量化和调度程序旋钮的标志。
- 可观察性：指标终端、日志和 hooks 都在那里，尽管你可能会添加自己的跟踪。
- 可扩展性：对 tokenizers、适配器和后端的插件式支持正在改进。如果你喜欢在午夜阅读代码，那么该存储库是活跃且平易近人的。
成本计算：vLLM 如何改变 GPU 账单
- 更好的利用率 = 更少的空闲周期。如果你按小时（云）付费或分摊（本地部署），vLLM 的吞吐量提升会转化为每美元更多的 tokens。
- 量化收益：在支持的情况下运行 可以缩小 VRAM footprint，并让你降低 GPU 等级——或在每张卡上容纳更多的并发作业。
- 横向扩展：当你确实需要更多资源时，vLLM 可以在多个 GPU 和节点上工作。你可以线性增长，而无需将你的架构扔进搅拌机中。
经验法则：如果你的服务有超过少数的并发用户，或者你以波浪形式运行批处理作业，那么 vLLM 的效率会很快得到回报。如果你只是测试提示词，那么它是一个锦上添花的功能。
真实世界的场景：vLLM 在哪里能发挥作用
- 具有大量并发用户的聊天助手：客户支持、内部 IT 帮助，或者在午夜前五分钟帮助学生集思广益撰写论文的应用程序。
- 内容生成管道：博客大纲、电子邮件草稿、代码注释——并行生成，而无需像 DMV 那样的队列。
- 工具驱动的代理：当你的模型暂停以进行工具调用时，vLLM 的批处理可使 GPU 忙于处理其他请求。
- 系统：vLLM 可以很好地充当生成层，而你的检索器可以在其他地方进行书虫工作。
vLLM 设置技巧（以有趣的方式学到的）
- 从你实际计划提供的模型开始。不要对一个小的 3B 模型进行基准测试，然后部署一个 70B 模型，并想知道为什么你的 GPU 会尖叫。
- 调整最大上下文长度。过度调整上下文会炸毁 VRAM；正确调整大小可保持高并发性。
- 启用流式传输。用户会感到更快的响应速度，并且你可以尽早刷新 UI tokens。
- 使用真实的流量模式进行测试。高峰？稳定？混合？vLLM 的调度程序会根据形状以不同的方式发光。
- 记录所有内容。延迟 p50、p95、token 吞吐量和 OOM 事件会告诉你下一步在哪里进行压缩。
安全和治理：带上你自己的成人裤子
vLLM 是一个服务引擎，而不是道德指南针。如果你需要审核、PII 清理、速率限制、租户隔离或审计跟踪——请在网关或应用程序层上添加这些内容。好消息是： 兼容的界面使你可以更轻松地换入你喜欢的策略和中间件。
细则：本 vLLM 评测中的兼容性和注意事项
- 并非每个模型架构或量化权重都是即插即用的。查看文档和社区问题。支持的速度很快，但新颖性总是超过稳定性。
- CPU 回退？vLLM 在 GPU 上最快乐。你可以在 CPU 上进行实验，但这就像穿着滑雪靴参加马拉松比赛。
- 多 GPU 分片功能强大，但需要仔细配置。测试故障转移和热启动，尤其是在生产 SLA 中。
快速入门：心理检查清单
- 硬件：GPU，具有足够的 VRAM 用于你的目标模型 + 并发 headroom。
- 模型：选择一个受支持的系列（、、、、），并确认 tokenizer/量化兼容性。
- 服务：运行 vLLM 并启用 API，流式传输响应，合理设置上下文和 max_tokens。
- 规模：添加 GPU 或节点。使用网关进行路由、速率限制和身份验证。如果使用云，请考虑自动缩放。
- 成本：测量每秒的 tokens、并发性和平均输出长度。每次更改后重新运行。
值得注意的是：Sider.AI 在此图中扮演的角色
提醒一下，构建者们：如果你正在尝试选择模型，比较不同提示词的速度，并且通常不想在迭代时失去理智，那么 Sider.AI 可以成为一个极好的理智检查工具。你可以跨不同的后端起草、测试和完善提示词，然后在需要自托管以降低成本或进行控制时转移到 vLLM。将 Sider.AI 视为你的维修站人员——然后将 vLLM 视为赛道开放时你驾驶的赛车。 现在谁应该选择 vLLM？
- 是：用户群不断增长的初创公司、为多个团队提供服务的内部平台、从付费 API 转向自托管的产品团队。
- 也许：探索选项的独立开发者。如果你的流量很小，那么托管 API 现在可能更简单（也更便宜）。
- 暂不：在服务层需要统包合规性和隔离的高度监管组织。你首先需要围绕它设置更多的护栏。
vLLM 的优缺点（不加糖）
优点
- 通过 PagedAttention 实现强大的内存效率
缺点
- 在 GPU 上效果最佳；CPU 使用主要用于科学实验
本次 vLLM 评测的结论
vLLM 是一个罕见的开源项目，它既具有学术智能，又具有生产实用性。如果你认真地想大规模运行 LLM，而又不想启动一个兼作桑拿浴室的 GPU 场，那么它应该在你的候选名单中——可能在顶部。它不是提供模型的唯一方法，但就目前而言，它是最快、最灵活、对开发者最友好的方法之一。
换句话说：如果你当前的设置让用户等待的时间太长，以至于他们会重新考虑自己的人生选择，那么 vLLM 将帮助你在他们能够做到之前发布答案。这就是重点，不是吗？
行动计划：本周让你的 LLM 更快
- 第 1 天：使用你的目标模型启动 vLLM。打开流式传输。使用你的真实提示词来点击它。
- 第 2 天：调整上下文窗口和批处理设置。尝试支持的量化以适应更多的请求。
- 第 3 天：添加网关和日志。测量 p95 延迟和每美元的 tokens。
- 第 4-5 天：将 Canary 推送到真实用户。如果需要，可以横向扩展。用一些冒泡的东西庆祝一下（苏打水也算）。
当你的老板问你如何在不增加成本的情况下将吞吐量翻倍时，只需说两个词：“paged attention”。然后将此 vLLM 评测交给他们，并享受他们像你计划好的那样点头。
常见问题解答
Q1：vLLM 适合小型团队还是大型企业？
两者都适合。如果你要从托管 API 迁移到自托管以降低成本，vLLM 的 OpenAI 兼容终端使切换变得容易。对于大型团队，当流量激增时，吞吐量和并发优势会显现出来。
Q2：哪些模型在 vLLM 上运行效果最佳？
流行的开放模型（如 Llama、Mistral、Mixtral、Qwen、Gemma 和 Phi）是经过充分验证的途径。检查量化变体的兼容性说明——大多数常见格式都可以使用，但奇异的组合可能需要进行调整。
Q3：我需要多少 GPU 才能运行 vLLM？
将 VRAM 与你的模型大小和上下文窗口相匹配，然后添加用于并发的 headroom。单个高内存 GPU 可以很好地服务于 7B–13B 模型；更大的模型或繁重的流量可以从多 GPU 设置中受益。
Q4：vLLM 是降低延迟还是仅仅提高吞吐量？
两者兼而有之，具体取决于工作负载。持续批处理提高了 GPU 利用率，从而提高了吞吐量，而流式传输和高效调度有助于聊天应用程序中的 time-to-first-token 和尾部延迟。
Q5：vLLM 与 Text Generation Inference (TGI) 相比如何？
在吞吐量方面，vLLM 通常凭借 PagedAttention 和动态批处理优于 TGI，尤其是在交互式聊天方面。TGI 倾向于 Hugging Face 集成和企业 polish——你的堆栈和优先级应该决定。
