LEo的网络日志
返回

从模型文件到推理服务：一篇文章认识 vllm

有了大模型文件和计算卡，下一步怎样让网页或其他程序向模型提问？在昇腾 npu 上部署 qwen 的实践中，我们用到了 vllm 和 vllm ascend：前者负责加载模型、调度推理和提供接口，后者将 vllm 与昇腾软件栈连接起来。

这篇文章暂时离开具体的集群配置，先弄清 vllm 是什么、为什么需要它，以及一个模型服务从启动到被调用经历了什么。文中的命令是帮助理解流程的示例，本文没有对它们进行实际部署验证；运行前请按设备、模型和版本核对官方文档。

1 模型文件为什么还需要推理服务

模型文件里有权重、配置和 tokenizer 等内容。它们像一份已经准备好的能力，但应用不能直接对着权重文件发送 http 请求并得到回答。

中间还需要软件来读取模型，把问题转换成模型能处理的输入，在计算设备上执行推理，再把结果转换成文字。多个用户同时提问时，还需要管理请求、分配计算和显存。

用户或应用 → http 请求 → vllm 推理服务 → 模型 + 计算设备
用户或应用 ← 生成的回答 ←──────────────────────┘

你可以自己编写程序加载模型并生成回答。用户和请求逐渐增多时，要同时处理调度、内存利用和服务接口就会复杂得多。vllm 提供了这些常见能力，让我们把更多精力放在模型选择和业务应用上。

2 vllm 是什么

vllm 是一个用于大模型推理和服务的开源框架。推理是使用已经训练好的模型处理输入、得到输出的过程，例如让模型根据问题生成回答。

几个容易混淆的角色可以这样区分：

角色主要职责
模型提供已经训练好的权重、配置等，决定可完成的任务和输出特点
vllm加载模型、管理推理请求和计算资源，也可以提供服务接口
gpu 或 npu执行模型推理所需的计算
vllm ascend将 vllm 与昇腾 npu 软件栈连接起来的适配插件
kubernetes在集群中安排容器、分配设备资源并管理工作负载
业务应用发送问题、接收结果，并实现面向用户的功能

vllm 本身不是某个具体模型，也不是用来训练模型的完整平台。它可以独立运行；使用 kubernetes 时，kubernetes 帮助管理运行 vllm 的容器，两者各管一部分。

3 它帮助解决哪些问题

多个人同时提问，怎样安排计算

大模型通常不是一次算出整段回答，而是逐步生成 token。token 可以暂时理解为模型处理文字时使用的片段；它不一定等于一个字或一个单词。

假设甲需要一段长回答，乙只需要一句话。如果总要等甲完整结束才开始处理乙，乙可能等待很久。vllm 使用连续批处理等调度方式，在生成过程中让新请求加入、已完成的请求退出，以便更灵活地利用计算资源。

这有助于提高多请求场景的吞吐量，但实际延迟和吞吐量仍取决于模型、设备、请求长度和配置。并发越大也不一定越好：资源不足时，排队和响应时间都可能增加。

对话过程中的显存怎样使用

生成回答时，模型会保留前面 token 的部分计算结果，称为 kv cache。它可以避免每生成一个新 token 都从头重复计算，但随着上下文变长、并发请求增加，也会占用越来越多的显存。

vllm 使用 pagedattention 等机制管理 kv cache。可以把它想成把缓存分成较小的块，再按需管理，而不是一开始就为每个请求预留一整段连续空间。这样有助于减少浪费，也便于管理不同长度的请求。这个比喻只说明基本思路，具体实现可参考 pagedattention 设计说明。

显存仍然是有限的。模型权重、上下文长度、并发数量和其他运行开销都会影响是否放得下；pagedattention 不能让显存无限增长。

应用怎样访问模型

vllm 可以启动 http 服务，提供与部分 OpenAI 接口格式兼容的接口。应用使用对应的请求格式和服务地址，就可以调用部署的模型；支持的接口、参数和模型能力仍需查阅接口文档。

接口格式兼容不意味着使用了 OpenAI 的模型，也不意味着所有接口和参数都完全一致。

4 它还能做什么

5 怎样部署和调用

先看最小流程：准备兼容的运行环境和模型 → 启动 vllm → 确认模型加载完成 → 发送请求并检查回答。

一台机器上的最小示例

下面使用官方快速入门中的 Qwen/Qwen2.5-1.5B-Instruct 作为示例。假设已经有一台可用的 Linux 主机、兼容的 NVIDIA GPU 和驱动，并按 vllm 安装文档安装了与设备匹配的 vllm。运行时需要能下载模型，或者将模型名称替换为已经准备好的本地模型目录；也要检查模型许可、磁盘空间和显存。

vllm serve Qwen/Qwen2.5-1.5B-Instruct --host 127.0.0.1 --port 8000

首次启动可能需要下载模型，等待日志显示服务已启动且模型加载完成。另开一个终端，在同一台机器上发送请求：

curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "Qwen/Qwen2.5-1.5B-Instruct",
    "messages": [{"role": "user", "content": "你好，请介绍一下你自己。"}],
    "max_tokens": 100
  }'

如果启动时改用了本地模型目录，请以服务实际提供的模型名填写 model，可通过 GET /v1/models 查看。请求成功后，检查返回的 choices 中是否有实际生成的内容；只看到进程启动或端口监听，还不能证明模型回答正常。

这个示例只监听本机地址，便于学习。对外提供服务前，还要按环境配置网络、访问控制、资源限制和监控。不要仅凭 --api-key 就认为所有端点均已受保护；具体限制和防护方式以官方接口文档为准。

容器和 kubernetes 中如何理解

容器部署时，镜像提供运行环境，模型可以预先下载并挂载进容器，计算设备则需要通过对应的容器运行时提供。选用与硬件、驱动、模型和 vllm 版本兼容的镜像后，仍然要完成启动和实际请求验证。

放到 kubernetes 中时，还需要根据集群配置申请设备、挂载模型存储、配置工作负载和服务入口。kubernetes 可以帮助调度和管理容器，但不会替你保证模型适配、显存足够或回答正确。

昇腾环境还需要匹配 vllm ascend、驱动和相关软件版本，不能把上面的 NVIDIA 示例直接当作昇腾安装命令。具体步骤参考 vllm ascend 文档和模型对应的教程。今天记录的 qwen 与昇腾 kubernetes 实践目前仍是草稿，其中展示了双卡、模型挂载和普通用户权限问题；等该实践发布后，再补充站内链接。

6 应用可以拿它做什么

一个常见用途是给应用提供内部问答接口：网页把用户问题发给 vllm，vllm 调用生成模型，再把回答交回网页。代码助手、文本摘要和内容分类也可以采用类似思路，最终效果仍取决于模型与提示设计。

知识库问答通常还会增加检索步骤：先把文档转成向量并建立索引，收到问题后检索相关片段，再把片段和问题交给生成模型组织回答。embedding 模型负责向量表示，生成模型负责生成文本；vllm 可以在受支持的组合中提供相应模型服务，但它不会自动替你完成整个知识库系统。

7 使用时还要注意什么

从模型文件到应用可用的接口，vllm 负责的是中间的推理执行和服务这一段。弄清这条边界，再看设备、容器和集群的配置，就更容易定位每个环节的问题。

上一篇
从 tp 和 pp 到 vllm ascend 看懂大模型推理配置