大模型推理部署方式与性能优化思路大模型部署的目标不只是让模型成功运行还要让它在真实请求下满足响应速度、生成速度和并发量的要求。增加 GPU 数量并不必然带来加速每张 GPU 都有独立的显存把任务拆开以后设备之间需要传输数据、同步结果有时通信的成本会超过节省的计算时间。因此大模型推理优化的基本思路是先确定限制性能的资源再选择对应的拆分方式最后用实际负载验证收益。一、大模型推理是如何进行的用户提交问题之后模型通常经历两个阶段**Prefill输入预处理**和Decode逐步生成。这两个阶段的计算方式不同决定了它们需要不同的优化方法。1. Prefill理解输入建立缓存Prefill 阶段会处理输入提示词中的 token通过模型各层计算中间表示并建立后续生成需要使用的KV Cache键值缓存。可以把 KV Cache 理解为模型为已经处理过的内容保存的一部分注意力计算结果。后续生成时能够复用这些结果避免每生成一个 token 都重新计算全部历史内容的键和值。这一阶段的过程大致是将输入文本转换为 token。在满足因果注意力约束的前提下批量处理输入中的多个 token。为各层建立输入对应的 KV Cache。根据输出结果选出第一个生成 token随后进入 Decode。Prefill 通常包含较大的矩阵运算。长提示词带来更多计算因此它往往显著影响用户等待第一段输出的时间。**首字延迟 TTFTTime 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 的耗时 TPOTTime per Output Token**用于衡量生成阶段的速度。TPOT 越低用户看到的输出通常越流畅。例如平均每个 token 用时 50 毫秒对应约 20 token/s用时 25 毫秒则对应约 40 token/s。3. 两个阶段的区别对比项PrefillDecode主要工作处理输入建立 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 上下文并行 PCPPCP 将长提示词的处理工作分给多个 GPU。由于一个位置的注意力仍可能依赖其他位置设备之间需要交换键和值或通过多轮通信合并计算结果。**解决的问题**长提示词的 Prefill 太慢首字延迟达不到要求。**关键取舍**只有输入足够长、节省的计算超过通信成本时才值得使用。对长短请求混合的服务可以根据实际测试将长请求送到启用 PCP 的工作组短请求保留在普通工作组。Decode 上下文并行 DCPDCP 将历史 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必要时测试 PCPPrefill 收益是否超过通信代价Decode 是否变慢TP2 下单请求生成速度不够定位访存、计算和通信占比再决定是否调整 TPTPOT 是否实际下降不能仅看 GPU 数量权重能放下但长上下文 KV 容量不足测试 DCP 或调整准入并发增加的容量是否值得额外的逐步合并开销模型必须使用全部四卡且两对卡之间连接较慢测试每阶段 TP2、两个 PP 阶段阶段是否均衡、请求量能否填满流水线这个例子的关键是同样四张卡用来加速一个请求还是用来同时服务更多请求应由测量结果决定。5. 每次优化都应遵守的经验一次优先解决一个已确认的瓶颈。每种新增并行方式都要对应明确的问题避免叠加复杂度后无法判断收益来源。使用满足要求的最小配置。TP 越大、并行轴越多通信和调度成本通常也越复杂。按真实请求分布测试。覆盖不同输入长度、输出长度和并发量不只测一个最大上下文或单个演示请求。同时观察容量、延迟和吞吐量。参数能放下不代表还能容纳目标并发的 KV Cache 和运行时缓冲区。观察尾部延迟。除平均值外还应看中位数、p95 等指标避免少量慢请求被平均值掩盖。确认一个阶段的收益没有伤害另一个阶段。Prefill 更快、Decode 更慢的配置未必更符合用户需求。四、总结大模型推理优化的本质是决定权重、输入计算、缓存和请求分别放在哪里并控制由此产生的通信成本。**首字延迟低**重点减少排队、重复输入工作和 Prefill 耗时根据输入长度评估 TP、PCP、缓存和分流。**单请求生成快**重点减少 Decode 每一步的读取、通信和同步成本谨慎扩大并行规模。**服务总吞吐量高**在单请求延迟达标后增加副本、改善批处理和路由并保证足够的 KV 容量。最好的部署方案是在实际模型、硬件和请求分布下用最简单的配置达到目标。更多 GPU、更多并行方式只有在测量证明有效时才值得采用。**参考来源**Avi ChawlaParallelism strategies for LLM inference, clearly explained。