FlexPipe：让LLM推理流水线在碎片化GPU集群中动态换挡

让LLM推理流水线在碎片化GPU集群中动态换挡——这个念头，是我在一次“深夜救火”时被逼出来的。当时集群里剩了三张规格不完全相同的计算卡，正好是上一个批处理作业释放出来的。线上一个7B模型的推理服务却按老配置要求“同规格四卡+全互连拓扑”，调度器在碎片里翻来覆去找不到合适组合，三张卡就那么白白空着。那晚我意识到：很多LLM推理流水线的性能问题，不是模型不行，而是没在碎片化GPU集群里动态换挡。

FlexPipe就是我们后来做的调度与执行层。它不改造推理模型本身，也不强制统一并行策略，而是让同一条LLM推理流水线能在一卡、两卡、四卡甚至“两卡一个拓扑、单卡另一个节点”的混合组合之间平滑切换。换句话说，它把“作业必须申请一整组同规格GPU”这件事，彻底改成了“资源与流水线不断协商挡位”。这篇文章会把FlexPipe背后的思路、挡位建模、切换链路和实测结果完整展开，也聊聊只有跑过真实碎片集群才会踩到的坑。适合正在做推理服务、平台调度，或者想把剩余GPU资源利用起来的同学。

1. 固定流水线在碎片化集群上为什么注定低效

1.1 调度器眼里的“剩卡”和推理作业眼里的“硬需求”是两套语言

调度器看资源的方式，和推理框架看资源的方式差别极大。调度器拿到的是显存大小、算力、卡间拓扑、NUMA归属，它会说：某个节点有三张可用卡，0号卡被其他作业占用了一部分显存，1号卡完全空闲，2号卡完全空闲，但1号和2号之间的互联带宽不错，0号和它们之间却隔了一道慢速互联。

推理作业的配置往往很“硬”。配置文件里写的是“申请4张同规格GPU、张量并行度4、卡间必须全互连”，如果做不到，就整个作业无法启动。这类硬约束一旦写进部署模板，调度器就只能做二选一的判断：要么找到一整组完全符合条件的卡，要么什么都不跑。碎片化集群的问题本质不是缺资源，而是资源以调度器无法理解的形式存在。

这种语义错配在在线推理场景里更明显。离线训练可以等资源，任务提交上去，队列排半小时无所谓。但推理服务有SLO，等不起。用户请求已经到网关，模型却还没分配好卡，那只能超时返回错误。很多平台同学抱怨“集群明明有卡，服务却一直起不来”，很大程度上不是调度算法不行，而是“作业必须固定并行度”这个前提，把大量可用碎片直接排除了。

1.2 固定并行度不仅浪费碎片，还让负载波动无解

LLM推理和离线训练还有一个本质区别：它不是单一计算形态。一次请求会先进入prefill阶段，对全部输入token做并行计算，这个阶段算力敏感；随后进入decode阶段，逐token生成输出，这个阶段对显存带宽和KV Cache容量更敏感。经典的流水线并行会把模型的不同层放到不同卡上，但如果请求形态变化剧烈，固定四卡流水线就会出现“prefill时四卡都很忙，decode时某些卡明显空闲”的情况。由于配置固定，空闲的卡不能借给别的服务，波峰波谷被叠成双重浪费。

FlexPipe的起点是把这个前提改掉：调度器不需要提供同规格四卡，只要告诉执行层“现在有几张卡、分别是什么规格、卡间拓扑如何、能维持多久”，执行层自己决定用哪个挡位。这样资源碎片和负载波动就不再是两件不可调和的矛盾，而成为需要动态平衡的两个变量。

2. FlexPipe的挡位建模：先算清楚每个挡位能跑多快

2.1 定义候选挡位：并行度不是越高越好

在FlexPipe里，“挡位”不只是并行度，而是包括并行策略、权重精度、批量大小、KV Cache承载策略的一组完整配置。以我们平时接触较多的7B模型为例，在碎片集群上预置了下面几种挡位。不要把这组数据当成通用基准，它的意义在于说明：不同挡位之间存在明显的吞吐与延迟差异，而最优解完全取决于当前资源组合。

为什么不全用张量并行？因为张量并行对卡间带宽极其敏感。每个transformer层的前向计算里都有大量all-reduce通信，如果卡间是慢速互联，通信时间会直接超过计算时间，挡位值再好看也没用。流水线并行对带宽要求低一些，但它的代价是单个请求要依次经过多张卡，整卡空闲时间更多，只有在批量足够大时效率才上来。

碎片集群里经常出现的组合是：两张高速互联的卡加一张独立卡。固定策略会让三张卡强行跑一个三路并行，结果高速互联的卡被慢速链路拖住，实际吞吐还不如“两张卡跑张量并行，另一张卡单跑”。FlexPipe会把这两种情况都建成独立挡位，执行时按实时资源状态选择。

2.2 挡位表怎么测：一小时实测胜过一天估算

挡位表不是写在配置文件里的静态数字，而是通过一个基准测量器跑出来的。我们做了个叫gear_bench的小工具，对每个候选挡位做固定压力测试：控制输入长度和输出长度，记录prefill吞吐、decode吞吐、p90延迟，以及从冷启动到Ready的时间。

这个做法可能看起来简单，但非常必要。曾经我们尝试用理论公式去估算不同并行度的吞吐，结果和实测差了将近一倍。原因是碎片集群里有太多理论模型覆盖不到的因素：共享带宽、CPU绑定、显存带宽竞争、持久化缓存命中率、NCCL通信调度波动。一小时实际测量能把这些因素全部吸收进挡位表，之后调度器只需要查表。

示意代码如下：

def measure_gear(model_id, parallel_plan, precision, batch_sizes): engine = build_engine(model_id, parallel_plan, precision) results = {} for bs in batch_sizes: trace = run_trace( engine, input_len=512, output_len=128, num_requests=200, batch_size=bs ) results[bs] = { "prefill_tput": trace.prefill_throughput, "decode_tput": trace.decode_throughput, "p90_latency": trace.p90_latency, "peak_memory": trace.peak_memory, } return results

这里有一条很实际的经验：不要只测“最优批量”，而是把批量从一个很小的值扫到显存允许的最大值。因为在线服务场景里，请求是持续到达的，预填充阶段可能需要小批量低延迟，解码阶段可能希望大批量高吞吐。挡位表里真正有用的不是一两个性能峰值，而是不同批量下的完整曲线。动态换挡时，FlexPipe会同时查“当前批量”和“目标批量”两行数据，避免换过去之后才发现性能不增反降。

3. 动态换挡的执行链路：状态冻结、拓扑迁移与流量切换

3.1 把权重迁移和KV Cache重分片分离

换挡和变速箱换挡一样，核心问题是“动起来的时候不能熄火”。LLM推理服务器从挡位1切到挡位2，需要解决两件事：模型权重重新分布到多张卡，以及请求过程中产生的KV Cache按新拓扑重分片。

权重迁移相对简单，因为它不是在线状态，只需要把已经加载的权重从显存里重新切分。可KV Cache是活跃请求的状态，不能随便丢。如果为了换挡把一个生成了300个token的请求断掉，用户感受到的就是服务中断。

FlexPipe把这两个动作分开了。第一步，把新流量切到新挡位实例，这个实例可以先做权重加载和预热；第二步，旧实例继续服务存量请求，等这批请求自然跑完，或者等到可接受的超时阈值；第三步，把仍然存活的存量请求的KV Cache按新拓扑做一次同步重分片，再迁移到新实例。这个过程被称为“优雅换挡”。

def switch_gear(from_gear, to_gear, live_requests): new_engine = warm_up(to_gear) switch_traffic(new_engine) deadline = now() + 30 while live_requests and now() < deadline: request = live_requests.popleft() if request.cache_size < migrate_threshold: request.shutdown("retry") else: new_engine.inherit_request(request, from_gear) live_requests.append(request) drain_and_release(from_gear)

把权重迁移和KV Cache重分片分开，最直接的好处是换挡对客户端的影响被限制在一个很小的窗口里。如果网络条件好，很多存量请求根本不会感知到自己被换到了另一组卡上。只有那些已经生成很长的请求，由于迁移代价大于重算代价，才选择让客户端重试。这个阈值怎么定？我们实践下来，生成token数少于64的请求直接迁移KV Cache通常不划算，因为重算一次prefill更快；生成token数大于256的请求则尽量迁移，因为重算一次会让用户等太久。

3.2 换挡触发条件：不能只看卡空闲，要看服务等级目标

很多人听到动态换挡，第一反应是“调度器发现卡空出来就换过去”。这个思路在稳定集群里勉强能用，在碎片集群里会灾难性地抖动。因为空闲卡的出现频率很高，如果每次都触发换挡，服务会一直处于迁移状态，吞吐不升反降。

FlexPipe真正用的触发信号不是“卡是否空闲”，而是服务等级目标是否面临风险。我们同时监控三类信号：请求队列积压深度、p99延迟是否逼近SLO、当前挡位的资源利用率是否长期过低。只有当这些指标同时满足条件，才允许发起换挡。伪代码是这样的：

def should_shift(state): queue_pressure = state.request_queue_depth / state.queue_capacity latency_pressure = state.p99_latency / state.latency_slo underutilized = state.gpu_utilization < 0.35 if queue_pressure > 0.7 and latency_pressure > 0.8: return "up", pick_best_gear(state) if underutilized and queue_pressure < 0.3 and latency_pressure < 0.5: return "down", pick_cheapest_gear(state) return "hold", None

重点在于“连续判定”。我们不会因为某一次采样超标就立刻换挡，而是要求指标连续五次采样都处于触发区间，才真正发起迁移。这样做的原因是碎片集群里的瞬时抖动非常多，某次网络打满或者另一租户抢带宽，都可能让延迟短暂升高，但过十秒钟就恢复。如果每次都换挡，系统会在几个挡位之间反复横跳。

3.3 调度算法：贪心加预演回退

当多个候选挡位都满足条件时，FlexPipe用的是一个带预演的贪心策略。它会先算每个候选挡位的收益，收益定义很简单：目标挡位在当前批量下的有效吞吐，减去当前挡位的有效吞吐，再扣除迁移成本和风险系数。风险系数来自拓扑差异性，比如从单卡换到双卡张量并行，因为要把权重切成两半并建立通信组，风险系数是0.2；如果从双卡换到四卡流水线，涉及跨节点迁移，风险系数会调高到0.5。

计算出得分最高的挡位后，还会做一次“预演”。预演不是在全部流量上做，而是在一组空闲实例上先起一个目标挡位，加载同一份权重，跑一小段真实流量，验证它的延迟和吞吐能达到挡位表里的预期值。如果预演失败，就自动回退到当前挡位，并把该组合加入一个短暂的失败黑名单。这个机制让我们少踩了很多次“挡位表看着没问题，换过去就崩”的坑。

4. 实测：当集群只剩“两种半”卡，FlexPipe把碎片变成可用吞吐

4.1 模拟集群与基线设定

为了验证FlexPipe的真实收益，我们搭了一套模拟集群：四张规格略有差异的卡，0号卡24GB显存，1号和2号卡在同一个节点且互联良好，3号卡在另一个节点但通过慢速链路接入。测试前，1号卡还被另一个任务占用了一半显存，所以在任何一个时间点，系统都无法拼出“同规格四卡全互连”的理想资源。

基线方案是传统的固定四卡流水线：必须等待1号卡完全释放，再等3号卡能满足拓扑要求，整个过程耗时约40分钟。这个方案在等待期间没有营收，调度器反复尝试申请资源，每次失败后都会把作业重新放回队列。

FlexPipe方案则不同。启动后不到2分钟，调度器识别出0号、1号、2号三张卡的实际可用情况：1号和2号之间互联良好，组成挡位2服务主流量；0号剩余显存较大，但与其他卡互联一般，组成挡位1服务低优先级请求。随后，当1号卡的占用任务结束，系统再动态把挡位2升级成挡位3。

4.2 关键结果：碎片利用率与延迟的取舍

提升不是来自模型本身的优化，而是来自“不让资源空转”。固定方案在等待期间完全无法服务，FlexPipe却先把三张可用卡变成两个独立挡位，立刻承担了流量。等资源条件变好后，再通过优雅换挡升级到更高挡位，整个过程中流量没有出现长时间中断。

有一个细节值得注意：FlexPipe的吞吐并没有因为“碎片化利用”而降低多少。原因是它选择把高速互联的卡组成张量并行组，避免慢速链路拖累主要请求，而慢速链路单独跑一些离线或者低优先级请求。这比强行把三张卡绑在一起跑三路并行要快得多。我们做过对照实验，如果强制三卡并行，吞吐反而只有260 tokens/s，因为慢速互联的通信开销把优势吃掉了。

4.3 实测中的三个坑

第一个坑：拓扑感知不能只看“是否同节点”。模拟集群里1号和2号卡本来互联良好，但测试期间另一个租户在这两张卡之间打满带宽，导致换挡前探测到的有效带宽只有原来的40%。结果挡位2启动后不但没有达到表里的1500 tokens/s，反而比单卡还慢。我们后来在每次换挡前增加了一次10毫秒的实时带宽探测，并把探测结果存到挡位选择器里，作为通信代价的修正系数。

第二个坑：KV Cache迁移时要处理“隐性断点”。一开始我们采用优雅换挡，让旧实例继续服务存量请求，但某个请求的KV Cache分布在新旧两组卡上，切换后新实例无法直接继续生成。折腾了几次之后，我们调整了策略：如果请求的生成token数超过256，先把KV Cache按目标拓扑重新分片，再一次性迁移；如果少于64，则直接让客户端重试。这个阈值要按实际集群带宽调整，不要照抄。

第三个坑：冷却期一定要比迁移时间长。我们最开始把冷却期设成60秒，结果一次换挡还没彻底完成，新的触发信号又来了，系统立刻准备下一次换挡，造成严重的震荡。后来把所有挡位切换都加了180秒冷却期，并且用历史记录做防抖，一旦某个挡位在最近十分钟内失败过两次，就直接忽略它。这个规则非常暴力，但在碎片集群里很管用。

5. 进阶玩法：挡位不一定只有并行度

5.1 把批量大小、投机解码和缓存策略都做成“挡”变量

FlexPipe做到后面，我们发现“挡位”这个概念完全可以超出并行度本身。批量大小是一个天然的可换挡变量：请求少时用单请求小批量，保持低延迟；请求多时切换到大批量，换取高吞吐。投机解码的长度也可以做成挡位变量：当目标模型和服务模型都空闲时，使用更激进的投机长度；当集群负载升高时，动态缩短投机长度，减少无效推理。

更实用的扩展是把KV Cache的持久化策略纳入换挡。碎片集群里经常出现一张卡显存大但算力一般，另一张卡算力强但显存较小。FlexPipe可以让显存大的卡承担更多KV Cache旁路存储，算力强的卡专注计算。这样“挡位”从并行配置扩展到了“存储和计算分离”的组合，资源的利用维度又多了一层。

5.2 在没有私有调度器的环境下自建适配层

很多人以为做动态换挡必须掌控整套集群调度器。其实不需要。FlexPipe在设计上只依赖一个很朴素的接口：能查询当前可用卡列表，能在确定节点上启动新实例。我们在一套通用容器调度环境里做过适配，方式是增加一个辅助Pod，定期扫描节点资源状态，把结果写进共享配置中心，FlexPipe再从中读取候选资源。这样既有通用调度器的资源隔离能力，又有FlexPipe自己的换挡决策能力。

适配层的价值还在于可观测性。每次换挡都会留下记录：时间、当前挡位、目标挡位、触发原因、迁移耗时、迁移后的性能表现。这些记录在普通推理框架里是完全没有的，但对排查线上问题非常重要。我们可以很清楚地看到，某次p99延迟升高到底是模型变慢，还是后台资源竞争导致换挡失败。

最后再分享一个经验：挡位表一定要做成可配置的，不要硬编码。FlexPipe运行一个季度之后，我们发现不同业务模型的“最优挡位”差异非常大，有的模型适合单卡INT8，有的必须用FP16保持精度，有的在四卡流水线下有明显加速，有的则因为通信开销几乎无提升。把挡位表放到配置中心之后，新增模型只需要跑一次gear_bench就能上线，后面所有决策都变得非常轻量。碎片化GPU集群不会消失，真正需要学会的，是让推理流水线在资源不那么完美的时候，仍然能找到最合适的那一挡。