vLLM部署指南：昇腾910B-A2上Embedding/Reranker跑不了的真相

“昇腾910B-A2服务器上不能通过vllm启动embedding向量和reranker模型吗”——这是我在搜索后台经常看到的真实问题，也是很多团队第一次接触 vLLM 时的典型卡壳现场。

表面上，这是一个“安装失败”或“算子不支持”的问题。但往深一层看，它真正暴露的是很多人对 vLLM 的定位理解偏差：以为它是一个“能启动大模型的通用工具”，装完就能把各种模型都丢进去跑。实际上，vLLM 天生是奔着文本生成模型的高吞吐服务化去设计的。 Embedding、Reranker 这类非自回归模型，并不天然在它的舒适区里。

这篇文章不打算复述官方文档，而是从我看到的高频问题出发，把 vLLM 的适用边界、部署流程、关键参数和工程化路径一起捋清楚。尤其是，当“Inferact vLLM creators are hiring”这样的标题出现在社区里时，我更想聊一个问题：为什么一个推理框架的创作者会需要长期招人？答案其实就藏在这类框架的复杂度里。

1. 先搞清楚 vLLM 到底解决哪一类问题

1.1 不要把它当成一个“启动大模型的万能命令”

很多教程会告诉你，安装 vLLM 之后，一行命令就能启动一个 OpenAI 兼容的服务：

这句话没有错，但它让很多新手产生了一个误会：凡是模型，都能用 vLLM 启动；凡是显存问题，都能被 vLLM 解决。

真实情况要偏技术得多。vLLM 最大的贡献，是解决了自回归式 LLM 在推理服务阶段的显存管理和调度效率问题。它把 PagedAttention、Continuous Batching 这类底层的调度机制，做成了开箱即用能力，让同一块 GPU 上能容纳更多并发请求，吞吐量也明显好于直接用 Hugging Face Transformers 写推理脚本。

这套机制有效的前提是：目标模型是“逐 token 自回归生成”的大语言模型。只有这类模型的推理过程，才能从显存分页、连续批处理、KV Cache 复用里获得巨大收益。

所以，vLLM 真正解决的是：高并发文本生成场景下的吞吐和显存效率问题。

1.2 它适合的场景，都有明显共性

如果你的业务属于下面这几类，vLLM 的价值会非常明显：

• 对话机器人、智能助手服务，需要同时服务大量用户；
• 内容生成类 API，需要把模型部署成标准化的 HTTP 服务；
• Agent 应用，在一次任务里多次调用 LLM，需要低调度开销；
• 离线批量生成，需要尽可能吃满 GPU 算力，缩短整体耗时。

这些场景都有一个共性：请求多、并发高、生成的是文本。vLLM 的连续批处理，本质上就是让 GPU 在“排队干活”的效率上接近极限。它对短请求、长请求混跑的场景尤其友好，因为调度器可以在 token 级别做切换。

相比早期“一个请求占满整卡”的做法，vLLM 把单卡利用率提升了一个量级。这也是它能在开源社区快速获得认可的核心原因。

1.3 但也有它不合适的地方：embedding、reranker 和一切非自回归模型

搜索引擎里那些关于“昇腾 910B-A2 上跑不了 embedding/reranker”的问题，正好撞上了这个边界。

Embedding 模型的任务，是把文本编码成向量；Reranker 模型的任务，是给查询和候选文档对打分。它们不是逐 token 生成文本，而是基于 encoder 模型做一次前向计算。显存分页和 KV Cache 的收益非常有限，连续批处理的调度逻辑也未必能直接套用。

vLLM 对这类模型的支持，取决于模型结构是否在它的支持列表里。即使支持，性能和稳定性也不一定比专用于向量推理的引擎更好。

判断方法很简单：如果你的模型输出是文本序列，vLLM 大概率适用；如果输出是向量或分数，先确认官方支持的模型列表，再决定是否使用。

2. 昇腾 9