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

第一次创建大模型推理服务时，我看到一组配置：tp=2、pp=1，运行环境是 vllm ascend 0.23.0.post1，后面还跟着 --quantization ascend --max-num-seqs 1。

这些名字分别在管什么？为什么有了模型和计算卡，还需要一套推理软件？先从最容易绕晕的两个数字说起。

tp 2 和 pp 1 就是两张卡组成一个小组

先记住一句话：tp=2、pp=1，表示两张卡组成一个小组，共同运行一份模型。

模型回答问题需要经过很多层计算。可以把这些层想成一条加工线上的许多道工序。

tp 表示张量并行，英文是 tensor parallelism。 “张量”可以暂时理解成模型计算时使用的一大块数字。某道工序里的计算量很大时，可以把其中的大块计算拆给多张卡。

tp=2 就像两个人合做一道工序：卡 a 算一部分，卡 b 算另一部分，交换、汇合需要的结果，再继续后面的计算。

pp 表示流水线并行，英文是 pipeline parallelism。 它关心的是把模型的前后层分成几个阶段，由不同的小组接力。

pp=1 表示只有一个阶段。从前面的层到后面的层，都由同一组卡负责。

tp=2、pp=1

              同一个小组
输入问题 → [卡 a 和卡 b 合作完成各层计算] → 生成回答

这只是帮助理解的简化图。实际框架不会把每个操作都机械地一分为二，但“同一层分工”和“不同层接力”的区别可以这样记住。

换几个数字就容易分清了

最后一种情况可以画成：

输入 → [第一组：卡 a、卡 b，负责前面的层]
     → [第二组：卡 c、卡 d，负责后面的层] → 输出

在这里讨论的单个模型副本、只组合 tp 和 pp的情况下，卡数可以按 tp × pp 理解。部署多个副本，或者加入其他并行方式时，需要另算总资源。

tp=2 也不表示两张卡各自运行一份完整模型、分别回答一个用户。它们是在合作运行同一份模型；一个请求也可能需要两张卡一起算。支持哪些组合，还要看模型、推理框架和硬件。vllm 官方并行说明介绍了这些部署方式。

多卡的一个作用是分担模型存储和计算压力。它不保证两张卡一定比一张卡快一倍，因为卡之间还需要交换数据。

两个附加参数分别管什么

下面以已经准备好的、与昇腾量化实现兼容的 qwen w8a8 模型为例：

--quantization ascend --max-num-seqs 1

quantization ascend 选择匹配的量化实现

量化可以理解为：用更紧凑的数字表示方式保存权重、执行部分计算，减少内存和显存需求。

w8a8 中的 w 是 weights，指模型权重；a 是 activations，指计算过程中的激活值。两个 8 表示相应部分采用 8 位量化表示。可以把它想成使用更紧凑的刻度记录数字，不过实际转换并不是简单地删掉小数。

--quantization ascend 告诉推理引擎使用对应的昇腾量化实现。官方文档中，modelslim 生成的相应量化模型采用这一参数；其他工具生成的量化格式可能走不同路径。昇腾量化说明

它不会把任意原始模型现场自动变成 w8a8，也不是所有昇腾模型都必须加的参数。 要先确认模型文件的量化格式，再选择匹配的加载方式。量化还可能影响回答质量，需要结合实际任务验证。

max num seqs 1 限制同时参与计算的序列数

--max-num-seqs 1 的准确含义是：推理引擎每轮调度最多处理一条序列。对于一次请求生成一条回答的简单聊天场景，可以先理解为“同时计算一条，其他请求可能排队”。

比如小李和小王同时提问，服务可以接收到两个请求，但这个参数限制了计算时的并行处理规模。它不等于网站只能登录一个用户，也不等于服务一生只能回答一个问题。

初次调试设成 1，可以减少同时处理多条序列带来的资源压力。它与 tp=2 完全不冲突：两张卡可以一起为这一条序列计算。 具体定义见 vllm 调度参数。

上下文 显存利用率和数据类型

这几个参数常常一起出现：

token 是模型切分文字后的单位，不固定等于一个字或一个单词。假设完整输入已经占了 6000 个 token，在 8192 的总长度限制下，留给输出的空间最多约为 2192；实际还受请求的最大输出长度等设置限制。

0.85 管的是显存，不是“芯片计算速度开到 85%”。它也不保证监控中的实际占用恰好是 85%，不能据此把剩余部分无条件分给其他程序。auto 则不是自动把任意模型量化成 w8a8。vllm 引擎参数说明

有了模型和 npu 为什么还需要 vllm ascend

可以先借用“播放视频”的例子，把几个角色分开：

模型并不是预先录好的答案，这个类比只用于区分“文件、软件和硬件”。有了模型文件和芯片，还需要程序把模型加载起来，组织计算并返回结果。

vllm 是大模型推理和服务软件。vllm ascend 是社区维护的昇腾硬件适配插件，让 vllm 能通过昇腾的软件栈使用 npu。项目官方介绍

例如，用户问：“请介绍一下北京。”

1. vllm 服务接收问题，使用已经加载的 qwen 模型进行推理。
2. vllm ascend 配合底层昇腾软件，将相关计算交给 npu。
3. npu 执行计算，模型逐步生成内容，服务把文字返回给用户。

如果配置 tp=2，这套软件还要组织两张 npu 共同完成相关计算。

vllm ascend 插件和镜像有什么区别

按官方提供的 vllm 昇腾适配方案，让 vllm 使用昇腾 npu，需要配套的 vllm ascend 插件。它与 vllm 搭配工作；单独一个插件并不构成完整推理服务。

vllm：加载模型、组织推理、提供服务
  ＋
vllm ascend：对接昇腾计算能力
  ＋
cann 等配套软件和宿主机驱动：连接实际硬件

当我们说“下载 vllm ascend 镜像”，说的是一套打包好的运行环境。镜像通常已经包含 vllm、ascend 插件和相关用户态依赖，方便一起部署；宿主机仍然需要匹配的驱动和可用设备。官方安装说明

所以，在平台里选择一个叫作“vllm ascend”的运行时预设，通常是在选择背后已配好的镜像和启动配置。具体包含什么，由该平台的预设决定。

这不表示昇腾运行大模型只有这一种软件方案。这里讨论的是选择 vllm 作为推理引擎时，怎样接上昇腾硬件。

0.23.0.post1 是版本号 不是芯片型号

0.23.0.post1 是 vllm ascend 的软件版本。其中 post1 表示在 0.23.0 正式版之后发布的一个补丁版本。

官方兼容表把 vllm ascend 0.23.0.post1 与 vllm 0.23.0、cann 9.1.0 等组件列为一组配套版本。理解时把它看成一套需要相互兼容的软件组合，不要把其中一个组件随意换成“最新”。官方版本与兼容表

vllm ascend 面向多种昇腾产品，但同一个镜像不能据此视为通用包。以这个版本的官方镜像为例：

这些是产品系列示例，不是完整支持清单。选择时要核对具体设备、服务器的 arm64 或 amd64 架构、驱动和配套软件，以及目标模型支持情况。不能只看到“昇腾”或“910”几个字就判断兼容。官方硬件与镜像对应说明

把这些配置放回同一个例子

假设准备运行一份兼容的 qwen w8a8 模型，阅读下面的配置：

运行环境：匹配设备的 vllm ascend 镜像
模型：已经准备好的 qwen w8a8 模型文件
卡数：2
tp：2
pp：1
上下文长度：8192
显存利用率：0.85
数据类型：auto
附加参数：--quantization ascend --max-num-seqs 1

把它翻译成日常语言就是：

用这套支持昇腾的软件加载已经量化好的模型，让两张卡组成一个小组合作计算。一次调度最多处理一条序列，每条序列的输入与输出受 8192 个 token 的总长度限制，并按设定比例规划显存预算。

这是一组帮助理解参数的示例，不是任意模型都能直接套用的配置。两张卡也不是所有 qwen 模型的最低要求。

如果把服务交给 kubernetes，kubernetes 负责安排工作负载和分配已注册的设备，容器中的 vllm 与 ascend 插件负责实际推理。使用管理平台创建服务，则是在这些能力之上增加页面、权限和资源管理；页面选择了模型和卡数，最终仍需要生成正确的运行配置。

排查问题时，可以先在 kubernetes 上验证同一组模型、镜像和参数，确认真实回答正常，再到平台页面对照验证。这样更容易分清：问题出在模型与推理环境，还是页面填写及配置传递。验收时既要看设备是否被实际使用，也要发送真实请求检查结果，不能只看服务显示“运行中”。