大模型推理：部署方式与性能优化思路

大模型部署的目标，不只是让模型成功运行，还要让它在真实请求下，满足响应速度、生成速度和并发量的要求。增加 GPU 数量并不必然带来加速：每张 GPU 都有独立的显存，把任务拆开以后，设备之间需要传输数据、同步结果，有时通信的成本会超过节省的计算时间。

因此，大模型推理优化的基本思路是：先确定限制性能的资源，再选择对应的拆分方式，最后用实际负载验证收益。

一、大模型推理是如何进行的？

用户提交问题之后，模型通常经历两个阶段：**Prefill（输入预处理）**和 Decode（逐步生成）。这两个阶段的计算方式不同，决定了它们需要不同的优化方法。

1. Prefill：理解输入，建立缓存

Prefill 阶段会处理输入提示词中的 token，通过模型各层计算中间表示，并建立后续生成需要使用的 KV Cache（键值缓存）。

可以把 KV Cache 理解为：模型为已经处理过的内容保存的一部分注意力计算结果。后续生成时能够复用这些结果，避免每生成一个 token 都重新计算全部历史内容的键和值。

这一阶段的过程大致是：

将输入文本转换为 token。
在满足因果注意力约束的前提下，批量处理输入中的多个 token。
为各层建立输入对应的 KV Cache。
根据输出结果选出第一个生成 token，随后进入 Decode。

Prefill 通常包含较大的矩阵运算。长提示词带来更多计算，因此它往往显著影响用户等待第一段输出的时间。

**首字延迟 TTFT（Time to First Token）**指从请求提交到收到第一个输出 token 的时间。中文里的"首字"是习惯说法，token 并不一定对应一个汉字。

需要注意，TTFT 不只包含 Prefill，也可能包含排队、请求调度、数据传输和首个 token 输出等开销。因此，首字慢不一定都是模型处理输入慢。

2. Decode：利用缓存，逐个生成

进入 Decode 后，模型利用已有的 KV Cache 和新生成的 token，继续预测下一个 token，并将新内容对应的键和值追加到缓存中。

这一阶段不断重复：

读取当前计算需要的模型权重和历史 KV Cache。
计算并选出下一个 token。
更新 KV Cache。
将生成结果作为下一步的条件，直到完成回答。

对于同一条普通自回归生成序列，后一个 token 依赖前一个 token，不能像输入阶段那样把未来所有 token 一次算完。Decode 每一步的计算通常较小，却需要持续读取权重和缓存；在常见负载下，显存访问和设备间通信容易成为限制因素，具体仍取决于模型、批量大小和上下文长度。

**每个输出 token 的耗时 TPOT（Time per Output Token）**用于衡量生成阶段的速度。TPOT 越低，用户看到的输出通常越流畅。例如，平均每个 token 用时 50 毫秒，对应约 20 token/s；用时 25 毫秒，则对应约 40 token/s。

3. 两个阶段的区别

对比项	Prefill	Decode
主要工作	处理输入，建立 KV Cache	利用缓存，逐步生成新 token
计算形态	同时处理多个输入 token，矩阵运算通常较大	每条序列逐步生成，单步运算通常较小
常见关注点	输入计算量、长序列注意力、排队时间	权重和缓存读取、每一步的通信与同步
主要体验指标	首字延迟 TTFT	每 token 耗时 TPOT、输出 token/s

缩短 Prefill 的方案，不一定能加快 Decode。 如果某种并行方式在每个生成步骤都增加同步，可能让首字更快出现，却让后续输出变慢。

二、大模型部署与性能优化的主要方式

推理服务常见的限制包括：模型参数占用的显存、KV Cache 占用的显存、GPU 计算时间，以及 GPU 之间的通信时间。不同并行方式拆分的是不同对象，因此解决的问题也不同。

1. 数据并行 DP：多套模型处理不同请求

数据并行让多个模型副本分别处理不同请求。每个副本拥有完整的模型、独立的调度器和 KV Cache；一个副本内部也可以使用多张 GPU。

例如，模型需要两张卡才能运行，服务器共有四张卡，就可以部署两个双卡副本，让两个副本同时服务用户。

**适用场景：**一个完整副本已经能运行，且单个请求的速度达标，但请求量超过了它的处理能力。
**主要收益：**提高并发和总吞吐量；在高负载下，也可能通过分散请求减少排队。
**主要代价：**重复存储模型，占用更多显存；通常不会直接加快单个请求的模型计算。

请求路由不能只看"轮到哪个副本"。还应关注队列长度、可用 KV 容量和是否已有可复用的前缀缓存，并为后续生成导致的缓存增长预留空间。

2. 张量并行 TP：多张卡合作计算同一层

张量并行将一层中的大型矩阵拆开，让多张 GPU 各自保存部分权重、计算部分结果，再通过通信合并。

**适用场景：**模型单卡放不下，或单次请求中的大矩阵计算成为瓶颈。
**主要收益：**降低每张卡存储部分权重的负担；计算量足够大时，有机会缩短计算时间。
**主要代价：**很多层都需要通信和同步，Prefill 和每一步 Decode 都会受影响。

TP 的规模越大，每张卡上的计算越小，但参与同步的设备越多。对长输入的大矩阵运算，这种拆分可能有效；对每步计算较小的 Decode，通信可能更快成为瓶颈。

实践上应从满足显存和延迟要求的最小 TP 规模开始，并尽量让组内 GPU 使用高速互联。模型形状、注意力头数和推理引擎也会限制可用的 TP 配置，不能任意拆分。

3. 流水线并行 PP：不同设备负责不同层

流水线并行按模型深度拆分：前一组 GPU 负责前面的层，后一组负责后面的层，阶段之间传递中间结果。

**适用场景：**模型需要跨多张卡或多个节点，且设备之间不适合承担 TP 的频繁层内通信。
**主要收益：**分散模型权重，通信主要发生在阶段边界。
**主要代价：**单个请求仍然需要依次经过所有阶段；请求不足或阶段不均衡时，部分 GPU 会空闲。

PP 通常需要足够多的独立请求或微批次，才能让多个阶段同时工作。划分阶段时应看实际耗时和显存使用，而不是简单平均分配层数。

因此，PP 更多是模型容量和硬件拓扑方面的选择，不应默认把它当成降低单请求延迟的方法。

4. 上下文并行 CP：拆分长序列相关的工作

上下文并行沿着序列位置拆分，主要分为两类。

Prefill 上下文并行 PCP

PCP 将长提示词的处理工作分给多个 GPU。由于一个位置的注意力仍可能依赖其他位置，设备之间需要交换键和值，或通过多轮通信合并计算结果。

**解决的问题：**长提示词的 Prefill 太慢，首字延迟达不到要求。
**关键取舍：**只有输入足够长、节省的计算超过通信成本时才值得使用。

对长短请求混合的服务，可以根据实际测试，将长请求送到启用 PCP 的工作组，短请求保留在普通工作组。

Decode 上下文并行 DCP

DCP 将历史 KV Cache 按序列位置分散到不同 GPU。每张卡计算自己负责的历史部分，再合并注意力结果。

**解决的问题：**长上下文的 KV Cache 太大，限制了可支持的上下文长度或并发量。
**关键取舍：**每一步生成都需要合并部分结果，可能增加 TPOT。

PCP 主要应对长输入计算，DCP 主要应对长历史缓存容量。 DCP 不应被直接理解为"让 token 生成更快"。

5. 专家并行 EP：将 MoE 专家分布到不同设备

专家并行适用于混合专家模型（MoE）。模型包含多个专家，每个 token 通常只使用其中一部分。EP 将不同专家的权重放到不同 GPU，运行时把 token 的中间表示发送给相应专家，再收回结果。

**适用场景：**MoE 模型的专家权重造成显存压力。
**主要收益：**分散专家权重的存储。
**主要代价：**专家路由产生跨卡通信；如果大量 token 集中到少数专家，最忙的设备会拖慢整个组。

优化时要观察各设备的通信量、专家处理的 token 数和等待时间。平均 GPU 利用率或平均吞吐量，可能掩盖局部热点。

6. 混合并行与 Prefill/Decode 分离

实际部署可以组合多种方式，例如：

在高速互联的节点内部使用 TP。
模型确实需要跨节点时，测试跨节点 PP。
一个完整模型实例已经满足要求后，通过 DP 增加副本。
确认存在长上下文问题后，再评估 PCP 或 DCP。
对 MoE 模型，按专家权重和路由情况评估 EP。

另一种思路是 Prefill/Decode 分离：分别使用不同的工作池处理输入和生成，以适应两阶段不同的资源需求和扩容比例。

这种方式需要在工作池之间迁移 KV 状态，还会增加协调成本。它不能替代 TP、PP 等模型部署方式，也不保证自动降低延迟。只有隔离和独立扩容的收益超过状态传输成本时才有价值。

三、大模型部署与性能优化的实践思路

1. 先明确"快"指的是什么

优化之前，应区分三个目标：

目标	应重点观察的指标	含义
更快开始回答	TTFT	用户等待第一段输出的时间
单个回答输出更快	TPOT、单请求输出 token/s	用户看到文字持续生成的速度
同时服务更多用户	总输出 token/s、请求吞吐量、Goodput	整个服务在延迟要求内能完成多少工作

单请求 token/s 和服务器总 token/s 是不同指标。 多个副本可以提高服务器总吞吐量，却不一定让一个回答生成得更快。提高批量或并发，也可能增加总吞吐量，同时牺牲单请求延迟。

Goodput 指满足服务目标的有效处理量。若服务每秒处理很多 token，却让大量用户等待过久，这部分吞吐量未必符合业务要求。

2. 如果需要首字延迟低，大致怎么做？

首先把 TTFT 拆开看：时间花在排队，还是实际处理输入？

排队时间长：优先考虑调度和容量

如果低负载时首字很快，高负载时明显变慢，应先检查队列和副本容量。

在资源允许时增加 DP 副本，分担请求。
根据队列等待、可用 KV 空间和前缀缓存情况路由。
做好请求准入，预留生成阶段的 KV 空间，避免服务接入过多请求后拥塞。
观察长短请求混合时的表现，必要时测试分流是否能减少相互影响。

这些方法主要减少等待，不等同于加快一次 Prefill 计算。

Prefill 计算慢：针对输入计算优化

如果请求不需要排队，长输入仍然使首字迟迟不出现，则应重点检查 Prefill。

检查输入中是否存在可以省去的重复或无关内容，在满足任务质量的前提下减少输入长度。
对重复前缀，在引擎支持且满足缓存复用条件时，利用前缀缓存，并尽量将相关请求路由到持有缓存的副本。
对较大的矩阵计算，测试适当增加 TP 是否能获得净收益。
对特别长的提示词，按输入长度分组测试 PCP，找出收益开始超过通信成本的区间。
如果两个阶段的混合调度确实造成干扰，可以评估 Prefill/Decode 分离，同时计算 KV 迁移的成本。

其中，减少不必要输入是基于计算机制得出的实践建议；缓存、并行和分流是否有效，都应由具体引擎和真实负载验证。

首字优化的方向：先减少等待和可避免的输入工作，再用并行缩短必要的 Prefill 计算。

3. 如果需要每秒生成 token 更快，大致怎么做？

首先确定，是希望一个用户的回答输出更快 ，还是希望整台服务器每秒输出更多 token。

单个回答更快：降低 Decode 每一步的耗时

Decode 要反复执行，所以每层、每一步新增的一点通信开销都会累积。优化应重点关注权重和 KV 读取，以及跨卡同步。

从满足显存需求的较小 TP 规模开始，实际比较不同规模下的 TPOT。
将频繁通信安排在高速互联的 GPU 之间，尽量避免让单个请求频繁依赖较慢的跨节点连接。
为目标上下文长度和并发量保留足够的 KV 空间，并观察上下文增长后 TPOT 的变化。
仅在 KV 容量确实受限时评估 DCP，不能把它默认当成生成加速方案。
不要期望增加 DP 副本或 PP 阶段，直接加快一个请求的逐 token 计算。
同时检查并发和调度设置，防止追求总吞吐量时让单请求每一步等待更久。

如果 Prefill 与 Decode 的资源竞争已被测量证实，也可以测试两阶段分离，但需要同时验证首字延迟和生成速度，避免改善一个指标却恶化另一个。

单请求生成优化的方向：减少每一步的访存、通信和等待开销，让关键路径尽可能短。

整个服务输出更多：提高有效并发

如果单请求速度已经达标，目标是承接更多请求，则重点转向总容量和调度效率。

用 DP 增加完整副本，让更多请求独立运行。
通过连续批处理等调度方式，让设备持续有工作可做。
根据权重和 KV 显存预算控制并发，避免容量耗尽。
使用 PP 时，保证有足够的独立工作填充流水线，并平衡各阶段。
对 MoE 模型，检查专家负载不均是否限制吞吐量。

最终应比较的是满足 TTFT 和 TPOT 要求时的吞吐量，而不是不设延迟限制的峰值 token/s。

4. 一个四卡部署的选择示例

假设服务器有四张 GPU，模型至少需要两张卡才能运行。

测量到的问题	可以优先测试的方案	需要验证的结果
TP2 已达到单请求延迟目标，但高峰排队长	两个 TP2 副本，即 DP2 × TP2	排队时间、尾部 TTFT 和有效吞吐量是否改善
TP2 下长输入的计算仍然过慢	对比 TP4；必要时测试 PCP	Prefill 收益是否超过通信代价，Decode 是否变慢
TP2 下单请求生成速度不够	定位访存、计算和通信占比，再决定是否调整 TP	TPOT 是否实际下降，不能仅看 GPU 数量
权重能放下，但长上下文 KV 容量不足	测试 DCP 或调整准入并发	增加的容量是否值得额外的逐步合并开销
模型必须使用全部四卡，且两对卡之间连接较慢	测试每阶段 TP2、两个 PP 阶段	阶段是否均衡、请求量能否填满流水线

这个例子的关键是：同样四张卡，用来加速一个请求，还是用来同时服务更多请求，应由测量结果决定。

5. 每次优化都应遵守的经验

一次优先解决一个已确认的瓶颈。 每种新增并行方式都要对应明确的问题，避免叠加复杂度后无法判断收益来源。
使用满足要求的最小配置。 TP 越大、并行轴越多，通信和调度成本通常也越复杂。
按真实请求分布测试。 覆盖不同输入长度、输出长度和并发量，不只测一个最大上下文或单个演示请求。
同时观察容量、延迟和吞吐量。 参数能放下，不代表还能容纳目标并发的 KV Cache 和运行时缓冲区。
观察尾部延迟。 除平均值外，还应看中位数、p95 等指标，避免少量慢请求被平均值掩盖。
确认一个阶段的收益没有伤害另一个阶段。 Prefill 更快、Decode 更慢的配置，未必更符合用户需求。

四、总结

大模型推理优化的本质，是决定权重、输入计算、缓存和请求分别放在哪里，并控制由此产生的通信成本。

**首字延迟低：**重点减少排队、重复输入工作和 Prefill 耗时；根据输入长度评估 TP、PCP、缓存和分流。
**单请求生成快：**重点减少 Decode 每一步的读取、通信和同步成本，谨慎扩大并行规模。
**服务总吞吐量高：**在单请求延迟达标后，增加副本、改善批处理和路由，并保证足够的 KV 容量。

最好的部署方案，是在实际模型、硬件和请求分布下，用最简单的配置达到目标。更多 GPU、更多并行方式，只有在测量证明有效时才值得采用。

**参考来源：**Avi Chawla，Parallelism strategies for LLM inference, clearly explained。