我们先把话说透凡是跑过大模型推理的都知道单卡推理有多憋屈。一张 A100 80G 显卡跑一个 7B 模型Batch Size 拉满也就勉强到一千 tokens/s 出头换成功耗和成本一算贵得让人肉疼。更别提千亿参数模型单卡连权重都塞不下。这也是为什么“大模型推理集群”这六个字最近一年几乎成了所有 AI 基础设施团队的必修课——从单卡推理到千卡负载均衡中间隔着的不是简单的机器堆叠而是一整套关于显存、带宽、调度、容错和成本控制的系统工程。这篇内容既是一份架构笔记也是一份实操复盘。我以自己落地过的生产环境集群为例从单卡性能基线讲起逐步拆解到千卡规模下的负载均衡设计把每一步的关键参数、选型逻辑和踩坑记录全部摊开。不管你是刚入门的算法工程师还是要独立搭推理集群的运维负责人或者只是想搞清楚公司里那套神秘的“推理平台”到底在做什么这篇内容都能给你一个足够清晰的参考框架。1. 为什么单卡推理撑不起生产环境1.1 单卡推理的性能瓶颈到底卡在哪先给出一个很多人容易忽略的结论大模型推理的性能瓶颈大多数时候不是算力而是显存带宽。Transformer 结构的推理过程是典型的访存密集型场景。以 decoder-only 架构为例每一次生成 token 都要读取全部模型权重参与计算。假设一个 27B 参数的模型用 FP16 存储权重体积大约是 54GB。在单张 A100 80G 上权重占据了显存的大半壁江山留给 KV Cache 和中间激活值的空间相当有限。而每次前向计算需要完整读一遍这 54GB 数据如果显存带宽是 2TB/s那么理论上单次前向推理的最快时间就是 54GB 除以 2TB/s约等于 27ms——也就是说无论你的 GPU 算力多强单卡跑这个模型的理论极限也就 37 tokens/s 左右。算力在这里几乎帮不上忙。A100 的 FP16 算力约 312 TFLOPS生成一个 token 的计算量可能只有几个 GFLOPs算力利用率经常连 10% 都达不到。这个现象用一个生活类比就很好理解你家里水管显存带宽只能同时流过这么多水权重数据无论你请多少工人算力单元在旁边等着接水整体流速都被水管粗细锁死了。1.2 从 P40 到 A100 的实测数据对比很多人喜欢拿 P40 这种“老矿卡”来炼丹跑推理我在早期的实验环境里也干过这事。P40 的显存带宽只有 346GB/s跑一个 7B 模型FP16 权重约 14GB理论上限就是 25 tokens/s 左右。我当时的实测值大概在 15-18 tokens/s扣掉 KV Cache 读写和中间激活的带宽消耗实际值只有理论值的六七成。换到 A100 之后7B 模型单卡推理速度能跑到 80-120 tokens/s但注意这仍然受限于带宽而不是算力。顺便说一个很多新手会踩的坑别被厂商标注的“xxx tokens/s”吓到这个数字通常是在极小的 Batch Size 下测得的单流延迟指标生产环境中你需要的是吞吐量也就是 Batch Size 拉大之后的整体输出速度两者差距可能超过一个数量级。1.3 单卡到多卡显存容量和带宽的双重困境单卡推理撑不起生产环境根本原因有两个维度。第一个是显存容量不够27B 模型单卡放得下但 KV Cache 空间太小并发一高就 OOM70B 模型单卡干脆放不下必须做权重切分。第二个是带宽扩展的本质矛盾——多卡并行时卡间通信会挤占原本就紧张的显存带宽资源如果不做合理的并行策略设计加再多卡性能也不升反降。这就引出了大模型推理集群的第一个设计决策点在多卡环境下到底选择哪种并行方式进行模型切分这直接决定了后续整个集群的通信拓扑、调度粒度和容错方案。2. 多卡推理的并行策略选型2.1 张量并行、流水线并行和数据并行怎么选多卡推理的并行策略主要有三种我实际应用中的选择逻辑如下。张量并行TP是把一个算子的参数矩阵按行或列切分到多张卡上。比如 27B 模型的注意力层 QKV 矩阵原本是一整块大矩阵乘切成 4 份之后4 张卡各算一部分最后通过 All-Reduce 汇总结果。TP 的通信量非常大每层前向计算都要做多次 All-Reduce对卡间带宽的要求极高一般只适用于 NVLink 域内。我实测下来A100 的 NVLink 带宽约 600GB/sTP 规模超过 4-8 张卡时通信开销会显著侵蚀计算收益所以 TP 的典型规模是单机 4 卡或 8 卡。流水线并行PP是按层切分。每一张卡负责模型的一部分层数据像流水线一样依次经过各卡。PP 的通信量远小于 TP只需要在卡间传递 activation显存压力也小但存在流水线气泡的问题——某些卡在某段时间可能处于闲置状态。PP 适合模型大到单张卡放不下的场景典型的切分方式是 8 层一段按层数均匀切分。数据并行DP就简单多了每张卡都放一份完整模型只切分输入数据。DP 的缺点是显存浪费严重——每张卡都完整加载一份权重25B 模型用 4 卡 DP 要占 4 倍显存。但在某些场景下它反而是最优解因为它的通信量最小甚至几乎没有而且天然支持弹性伸缩。三者可以组合使用比如 4 路 TP 乘以 2 路 PP 再乘以 2 路 DP组成 16 卡的计算组。组合顺序有讲究我习惯的优先级是 TP 先做、PP 其次、DP 最后因为通信量越大的并行策略越要放在 NVLink 域内做。2.2 连续批处理让 GPU 永远在忙解决并发问题的核心机制是连续批处理。传统批处理要等一批请求全部结束后才能处理下一批GPU 会在等待中空转。连续批处理则允许模型在 token 级别做动态调度——某个请求生成了第 5 个 token另一个请求刚进来准备生成第 1 个 token两者可以同时在当前 batch 里计算前一个请求终止或结束时新请求立刻插入空位。这背后的工程实现依赖 PagedAttention 这类显存管理技术。让我解释得更清楚一点推理时候选中的 KV Cache 不再是一整块连续显存而是切成固定大小的块比如每个 16 token 大小的块通过块表管理像操作系统虚拟内存一样灵活分配。这样一来显存利用率能从传统方式的 60% 提升到 90% 以上batch size 可以做得很大而不用担心 OOM吞吐量自然显著提升。2.3 推理引擎的调度基础FIFO 到迭代级调度单机推理引擎的调度器本质上回答一个问题下一个 forward step 跑哪些请求最简单的策略是 FIFO先来先服务实现简单但问题很多——一个长请求会霸占 GPU后面的短请求全部排队等死平均响应时间惨不忍睹。于是有了基于迭代级别的调度策略每个 forward step 都重新审视这个 request 集合优先排出那些接近完成的请求或者根据预估的剩余时间做优先级调整。这一步是后续集群负载均衡的根基。你只有理解了请求粒度上的调度逻辑才能理解为什么集群调度器能做一些跨节点的请求搬运和负载调整——核心原则都一样就是确保 GPU 利用率永远饱和同时保证延迟满足 SLA。3. 从单机到集群架构设计的核心拆解3.1 为什么不能用裸 GPU 组个网就算集群先给一个结论把一堆 GPU 用 InfiniBand 或 RoCE 网卡连起来只能叫“GPU 资源池”离“推理集群”还差得远。推理集群需要具备四个核心能力统一接入各种模型通过 API 网关暴露同名服务、弹性扩缩流量高峰期自动扩容低峰期缩容回收、负载均衡同一个模型的多个副本之间摊平流量避免热点、故障转移某张卡或某个节点挂了流量自动切走。这四个能力缺一个生产环境就会出问题。一个典型的单模型推理服务架构从上到下拆解为接入层API 网关、调度层模型路由 实例管理、推理层GPU 实例组。接入层负责鉴权、限流和请求分发调度层维护一张实时路由表记录每个模型副本的健康状态和负载情况推理层就是真正跑模型的 GPU 节点。用 Nginx 做接入层的反向代理是可行的但当集群规模到千卡级别调度层就不只是一个负载均衡器那么简单了——它还需要感知模型状态、设备拓扑、队列水位甚至要能协调 prefill 阶段和 decode 阶段的资源分配。3.2 资源池化把 GPU 从物理设备变成逻辑资源千卡集群如果还按照“每台机器装几个模型”这种传统方式管理那运维复杂度会指数级上升。资源池化的思路是把所有 GPU 纳入一个统一资源池按需分配、按量计费。这个设计思路的核心是一个轻量级调度器。每个推理实例从调度器申请 GPU 资源调度器根据请求的 QoS 等级、模型种类、预估负载决定分配哪几张卡。资源池化带来的最大好处是弹性业务高峰期可以给某个热门模型分配 100 张卡低峰期回收 80 张剩下的卡去跑离线批处理任务。我见过不少团队在早期图省事直接用一个静态配置文件管理 GPU 实例和模型副本的映射关系流量一上来就手忙脚乱地改配置重启服务。这种做法的最大问题在于调度决策没有考虑卡间拓扑。两张分配在不同机柜上的卡即便调度器认为“已分配”实际通信延迟也完全不同。资源池化如果做不好拓扑感知分布式推理的性能会非常不稳定加卡不加性能的事故就跟着来了。3.3 PD 分离为什么 prefill 和 decode 必须分开部署这是当前大模型推理集群设计里最值得讲的一个架构决策。我会先用最直观的方式解释这个概念。一次完整的大模型响应分为两个阶段prefill预填充阶段把用户的 prompt 一次性算完生成第一个 token它是一个密集计算型任务对算力要求极高decode解码阶段一步一步生成后续 token每一步只需要读取权重并算一个小向量访存密集型对带宽要求高。把这两个阶段放在同一批 GPU 上跑会造成资源割裂prefill 阶段 GPU 算力跑满但显存带宽闲置decode 阶段显存带宽跑满但算力明显浪费。而且两种阶段的持续时间差异巨大——prefill 可能只需要几百毫秒decode 却可能持续几十秒混在一起时调度器很难做出最优决策。PD 分离的核心思想就是专门用一部分 GPU 处理 prefill另一部分 GPU 处理 decode中间通过队列和通信协议衔接。在千卡集群里做 PD 分离之后prefill 实例和 decode 实例的比例要根据业务特征动态调整这个比例没有固定最优值我们线上通常按 1:4 到 1:8 之间浮动调节。PD 分离同时解决了另一个问题显存分配。prefill 阶段需要为每个请求分配大量的 KV Cache 空间decode 阶段每个请求只占用极少 KV Cache这两类请求混在一起时显存配额非常难定。分开之后各自按需分配OOM 问题大幅减少。3.4 推理路由的建模从“请求分配到实例”到“token 级别调度”负载均衡的复杂度在集群规模上去之后会急剧上升因为调度单位不再是“请求”而是“token”。举个实际例子某个模型部署了 4 个副本每个副本配置相同。前 3 个副本正在处理各自的请求队列第 4 个副本此时空闲。假设新来了一个长请求需要生成 1000 个 token它的 prefill 处理时间是 1 秒decode 时间是 50 秒。如果按照“每个请求分配到负载最低的副本”这种调度逻辑这个长请求会被分到第 4 个空闲副本上。第 4 个副本接下来 50 秒都被占满而前 3 个副本还剩很多空闲算力整个集群的吞吐利用率就出现了裂痕。这也是为什么现代推理调度器普遍采用两层调度模型先做请求级别的预分配然后在每次 forward step 做 token 级别的再平衡。这种设计的思想是不要把一个请求绑定死在某张卡上而是在 KV Cache 支持的前提下允许请求的 decode 阶段在不同实例上继续推进。这就需要集群的 KV Cache 能跨节点访问或者至少在节点组内支持迁移技术复杂度又上了一个台阶。如果暂时做不到 token 级别的迁移调度一个务实的折中方案是在请求级别根据 prompt 长度和预估输出长度做加权路由让长请求和短请求均匀打散到各副本上。我实测下来这个方案可以把集群的平均 GPU 利用率从 45% 提升到 70% 以上。4. 千卡负载均衡的关键机制4.1 权重感知的负载均衡策略千卡规模下的负载均衡不能只看请求数量必须看“权重”。这里有几个关键指标活跃连接数正在处理的请求数量预估负载请求的 prompt 长度和 expected output lengthKV Cache 占用率显存中被缓存占用的比例GPU 算力利用率当前 forward step 的算力消耗百分比权重感知策略的基本逻辑是每个实例定期上报一个多维度的负载向量调度器汇总后计算全局负载矩阵然后用最大-最小公平分配算法将新请求分配给负载最小的实例。用最大-最小公平分配算法的地方说明一下它的核心思想是最大化最小用户的资源量。放在请求调度的语境下就是优先照顾“最少被照顾”的实例让各副本的负载差距尽量小。这种策略比简单的轮询或最少连接数策略更适合大模型推理场景因为它能感知到每个请求的真实成本而不是默认所有请求都一样重。4.2 慢节点检测与流量摘除千卡集群里GPU 异构和性能漂移是常态。同一型号的 GPU因为散热、功耗墙、PCIe 通道等差异实际推理速度可能差 20% 以上。慢节点如果不处理会造成两个后果一是请求被分配到慢节点上响应时间超时二是慢节点逐渐堆积大量请求最后拖垮整个服务的 P99 延迟。我采用的方案是每个推理实例每隔 5 秒上报一次最近 10 个请求的平均处理时长调度器端维护一张实例状态表。当某个实例的平均处理时长超过集群均值的 2 倍时调度器启动“流量摘除”流程——新请求不再分配给它已有请求在其上继续排空。同时触发实例重启或迁移流程。但这里注意慢节点检测的频率过高会导致误判过低则会导致问题扩大化。5 秒探活间隔是我实测比较合适的区间。另外建议把探活请求设计成真正的推理请求而不是简单的 ping 包因为 GPU 算力异常有时并不会影响网络响应只有实测推理速度才能反映真实状态。4.3 通信拓扑感知的调度分配千卡集群的组网方式通常是每个机柜内部用 NVLink 连接 8 张卡机柜之间用 InfiniBand 或 RoCE 互联。这个拓扑结构直接影响数据并行通信的延迟和带宽。调度器在分配资源时应该感知通信拓扑。同一个模型的所有 TP 实例必须分配在同一机柜内——因为 TP 的通信量极大跨机柜的通信带宽远低于机柜内部会造成严重的性能瓶颈。PP 实例可以放在同一机柜也可以跨机柜但最好保持在相邻机柜内。DP 实例则完全无限制可以任意分发。这个策略花费的调度计算量微乎其微但收益非常明显。我之前遇到过的情况是某个团队没有做拓扑感知把一个 8 路 TP 的模型分到了跨 3 个机柜的 8 台机器上结果模型推理速度比单机 8 卡慢了两倍多排查了很久最后发现是跨机柜通信瓶颈导致——这种问题在拓扑感知调度下根本不会出现。4.4 端到端请求跟踪与容量规划千卡集群如果缺少端到端的请求追踪排查问题和容量规划会非常艰难。建议每个请求从进入接入层开始就生成一个全局唯一的 trace ID贯穿整个生命周期。这样当你看到一个 P99 延迟飙升的告警时可以快速定位到是哪个环节的问题是调度器排队时间过长还是某个 GPU 实例处理速度下降还是网络传输环节出现丢包和重传。容量规划方面根据历史的请求流量曲线就可以用简单的线性回归或时间序列算法预测未来一段时间的流量趋势提前扩容或缩容。5. 从单卡推理到千卡负载均衡的实操记录5.1 第一阶段单节点多卡建立性能基线我的建议是不要一上来就想着一步到位搭千卡集群先在一台 8 卡 A100 机器上建立基线。这个阶段的核心工作有四项压测单卡推理的吞吐上限测试 TP8 时多卡并行带来的加速比确认通信开销是否在合理范围验证连续批处理引擎的并发能力找到 batch size 的合理上限设定好 P99 延迟和吞吐的目标值。以 7B 模型为例单卡 A100 的实测吞吐约 80-120 tokens/sTP8 时理论上应该能到 800-1000 tokens/s 左右但实际因为通信开销一般落在 600-800 tokens/s。这个阶段的数据会成为后续扩容时的决策依据——你要清楚地知道扩容到 2 台机器的性能预期应该是什么水平如果达不到问题出在哪。5.2 第二阶段从多机到组网解决 GPU 通信瓶颈把 GPU 从单机扩展到了跨机时第一个会踩的坑是 NCCL 通信。NCCL 默认可能走 TCP socket 通信性能极差。需要在 /etc/nccl.conf 中显式指定使用 InfiniBand/RoCE 通信并开启 GPUDirect RDMA。开启 RDMA 前后的性能差距可以高达 20-50 倍这一点必须检查确认。另一个关键步骤是网络拓扑感知的 NCCL 配置。NCCL 支持通过 NCCL_TOPO_DUMP_FILE 导出检测到的拓扑结构你要确认每台机器的网卡和 GPU 的对应关系避免出现 GPU 和网卡跨 NUMA 节点通信的情况——跨 NUMA 会增加一倍的内存拷贝延迟。5.3 第三阶段集群调度器的工程实现这一阶段我建议直接基于 Kubernetes 做资源编排而不需要从零写调度器。K8s 的 scheduler 支持自定义扩展点可以通过 extender 机制注入拓扑感知和负载感知的调度策略。一些配置参考给每个 GPU 节点打上标签如 gpu-type、topology-rack、gpu-index然后通过 nodeSelector 和 topologySpreadConstraints 控制 Pod 的分布。在 K8s 上跑推理实例时建议每个 Pod 绑定 8 张卡对应一个 TP8 实例而不是 1 卡 1 Pod这样可以避免多 Pod 之间共享显存和通信域导致的不确定性。5.4 第四阶段流量治理与容量预估接入层建议用支持 gRPC 和流式响应的网关因为 LLM 推理天然是流式的传统 HTTP 长连接 SSE 的方式也可以但要确认网关不会因为响应时间过长而断开连接。容量估算有个简单公式可以参考单实例吞吐量 × 实例数 × 冗余系数建议 1.2-1.5≥ 峰值流量。假设单实例吞吐为 800 tokens/s业务峰值流量为 5000 tokens/s那么实例数最少为 7 个考虑冗余后建议 10-12 个实例。实际运营中我发现大多数故障不是算力不够而是没做流控。当流量洪峰到达时接入层直接放行所有请求调度器排队时间迅速飙升P99 延迟从 200ms 涨到 5 秒用户体验直接崩塌。建议接入层根据模型副本的实时负载动态调整并发限制超出容量的请求直接返回 429配合客户端指数退避重试这一条在线上极为关键。6. 千卡集群的五大经典故障与排查思路6.1 KV Cache 显存碎片化导致的 OOM现象是 GPU 显存看起来还有很多空闲但新请求进来就 OOM。原因是 KV Cache 分配和释放的粒度不一致导致显存碎片化。排查思路启用 PagedAttention 的显存管理机制并且定期执行显存整理。如果用的是较老版本的推理引擎可以直接迁移到 vLLM 等支持 PagedAttention 的引擎上这个问题的发生频率会大幅度下降。6.2 部分 GPU 的算力利用率异常偏高给一个真实例子训练好的模型上线之后某张 GPU 的利用率始终在 95% 以上其他 GPU 只有 40%。这种情况大概率是负载不均不是硬件故障。排查步骤查看该 GPU 对应实例的活跃连接数确认是不是有少数长请求占据了资源用 trace ID 追踪请求的时间分布确认是否存在集中热点检查调度器的权重感知逻辑是否正确——比如所有长请求都被哈希到了同一个实例上。6.3 跨机通信导致的推理性能骤降现象是 TP8 的模型在实际推理时吞吐极差明显不符合预期。排查思路优先确认 NCCL 是否走了 RDMA确认网络拓扑感知是否正确。我碰到过一个最隐蔽的问题某台机器的固件升级后NVLink 的 link speed 从 600GB/s 降到了 200GB/s导致 TP8 的通信瓶颈放大。排查方法是定期跑 NCCL 的 all-reduce 基准测试对比历史数据一旦发现带宽明显下降立刻检查固件和驱动版本。6.4 推理引擎的 Backpressure 机制失效当推理引擎的处理速度跟不上请求输入速度时必须有一个 backpressure 机制让上游感知到压力。很多团队在自研引擎时只关注了单机吞吐忽略了这层设计导致请求无限堆积在内存队列里最终整个进程 OOM 崩溃。建议在调度器层维护每个实例的队列深度阈值超过阈值时主动从路由表中摘除该实例让请求去其他实例避免击穿。6.5 模型热更新时的服务中断模型需要定期更新权重如果直接重启服务会中断所有正在进行的请求。我的方案是滚动更新先启动一个带着新权重的实例加入路由表但不接收新流量等存量请求排空后再把新流量切换过去。步骤可以分为实例启动准备、登记路由但标记为 drain、旧实例排空与摘除、新实例开始接收流量。7. 从千卡到万卡乃至云端最后一步扩展方向走到这一步你已经能支撑千卡规模的推理集群了。再往下扩展核心会变成两个问题。第一个是全局调度的高可用。调度器本身不能是单点需要做主备切换或完全去中心化的调度。K8s 的 controller 模式在这方面有天然优势但需要合理设计资源锁和状态同步机制。第二个是混合云弹性。本地集群的 GPU 毕竟有限流量洪峰到来时可以临时向云厂商租用一批 GPU 节点加入集群统一调度。混合云架构下最关键的不是网络打通而是模型的镜像分发和缓存——一个大模型权重动辄几十 GB在云上节点首次拉起时就需要拉取镜像这个时间可能长达 10 分钟超出很多业务的容忍范围。后续我计划把 PD 分离、混合云调度和日志追踪这三块内容分别展开写细每一块单独拆出来都足够水一整篇。如果在座的各位已经在自己的集群上调过千卡规模也欢迎多交流你们遇到的瓶颈和方案这套东西演进的速度非常快每周都有新思路冒出来。