拓冰网站定制 
1. 从单卡到千卡先搞懂推理集群到底在解决什么问题这些年做大模型推理最常见的开场白是“我有一个H100跑一个70B模型怎么QPS只有几十”然后一问细节显存不够用、多卡通信绕、请求一多就超时问题全挤在一起。等真正把规模推到千卡你会发现单卡踩过的坑到了集群环境下全都会放大十倍百倍地还回来。所以聊大模型推理集群架构设计我得先给这件事定个调这不是“把N张卡拼起来跑模型”的工程题而是“在有限成本下让成百上千个并发请求以最低延迟、最高吞吐拿到推理结果”的资源调度题。核心关键词就两个——大模型、千卡中间牵引它们的分别是计算密度、网络拓扑和调度策略。我在实际做集群规划时通常会先把问题拆成三层单机推理的硬件上限在哪里多机通信的瓶颈是什么以及负载均衡策略能不能跟模型并行方式匹配起来。这三层互为约束脱离任何一层谈架构都是空谈。举个直观的例子。你在单卡上做推理H100的显存带宽是3.35TB/s左右算力是989 TFLOPSFP16看起来强悍。但70B模型哪怕是FP8量化光权重就得70GB单卡80GB显存勉强塞得下可KV Cache一上来显存立刻见底。这时候你被迫开启PagedAttention之类的显存复用机制把KV Cache按块管理才勉强让并发数上来。等到了千卡规模单卡的那点显存复用已经不重要了重要的是卡与卡之间的数据搬运速度和全局调度器的眼界——因为你面对的请求已经不是几十个而是每秒成百上千个每个请求还可能命中不同的模型副本。千卡集群真正的难点在于模型参数是切开的请求是随机到达的显存是分布式的任何一张卡的负载失衡都会造成整体性能塌方。负载均衡这个词在这种场景下不是Nginx轮询那种简单的概念而是贯穿了接入层、调度层、引擎层、通信层的系统工程。接下来我从单卡讲起一步步拆解到千卡负载均衡的完整架构把我踩过的坑、调过的参、推倒重来的方案都记录下来。2. 单卡推理的性能天花板TCO曲线与算力收益递减规律2.1 单卡推理的两个阶段为什么决定了架构走向在进入集群话题前有必要把单卡推理的真实面貌说透。大模型推理每个请求都要经历两个阶段prefill预填充和decode解码。Prefill阶段是并行计算密集型的一次处理用户输入的整段tokenGPU利用率很高decode阶段则是串行逐token生成的每一步都依赖前一步的结果GPU利用率往往只有个位数到百分之十几。这个差异对架构设计的影响是决定性的。PreFill吃的是算力FLOPSdecode吃的是显存带宽HBM bandwidth。你在单卡上做优化本质就是在两个阶段之间找平衡prefill太快会挤占decode的算力decode太慢会让首token延迟TTFT飙升。业界常说的PD分离Prefill/Decode分离就是针对这个矛盾演化出来的经典方案后面我会细讲。从单卡的实测数据看70B模型如果用FP8量化在单张H100上并发数大概能支撑到20到40路取决于输入长度decode速度大约在每秒1000到2000个token之间prefill的TTFT在小并发下可以压到500毫秒以内。听起来还行但一旦请求长度变长、并发数翻倍decode的显存带宽就会触顶——这就像一条单车道的高速路车多了必然堵跟路面算力好不好关系不大。2.2 为什么单卡规模继续叠加不划算每次做容量评估我都会画一条TCO曲线横轴是GPU数量纵轴是单位成本能扛住的QPS。单卡阶段曲线斜率很高加一张卡就有明显收益但到了8卡阶段因为NVLink域内通信效率高曲线仍然保持着不错的斜率一旦跨过单机8卡的边界需要走RDMA网络做跨机通信同样的QPS增量你需要付出的网络资源和调度成本会急剧上升。这里有个经典的“算力收益递减规律”你往集群里加卡算力是线性增长的但通信开销和调度开销是超线性增长的。千卡集群的每一千次推理请求都要经历“请求分发→多机协同prefill→跨机聚合KV Cache→逐token decode→结果汇聚”的完整链路任何一个环节的延迟都会累计到用户的TTFT和TPOT上。所以我在做架构设计时第一原则就是能用单卡解决的不扩大到多卡能用单机解决的不扩大到跨机能用一个GPU实例解决的不上推理集群。这句话看似废话但很多人一上来就规划千卡集群结果模型只有7B用一张4090就能跑得飞快纯粹是浪费预算。正确路线是先量化业务峰值QPS、平均输入输出长度、SLO要求比如P95 TTFT 2秒、P95 TPOT 50ms再倒推所需的GPU总算力和显存总量。3. 多卡并行与单机八卡张量并行、流水线并行和数据并行的取舍3.1 三种并行方式在推理场景的真实作用单卡塞不下模型或者吞吐不够时第一反应就是多卡。大模型训练里的经典三件套——张量并行TP、流水线并行PP、数据并行DP——到了推理场景优先级和用法完全不一样了。先看张量并行。TP是把一个Transformer层的权重按行或按列切开分到多张卡上每张卡只算自己那部分计算完再做AllReduce汇总。推理时TP的最大优势是显存扩容一个70B的模型切成4份每张卡只存17.5GB的权重给KV Cache留出大量空间。但TP也是通信最重的并行方式每过一个Transformer层就要做多次AllReduce通信量跟hidden size成正比。我在单机8卡NVLink环境下跑过70B模型TP8时通信开销还能接受NVLink双向带宽900GB/s但如果跨机做TP8那基本是在给自己挖坑。再看流水线并行。PP是把模型按层切成多段每张卡负责其中一段数据像流水线一样逐段流过。推理场景下PP用得很少原因很直接推理是低延迟敏感的在线服务流水线天然会增加端到端延迟而且PP的显存利用率不如TP灵活。除非模型大到单机8卡都塞不下比如超过1TB的模型像一些MOE大模型否则我不太推荐在推理链路里引入PP。最后是数据并行。DP最简单就是复制多份完整模型每份独立处理不同请求最后通过负载均衡把请求散开。DP是推理集群最基础的扩展手段因为它跟请求调度天然契合——每个GPU实例都是无状态的任何一个请求可以被任意副本处理。千卡集群里绝大部分扩展能力其实是靠DP加TP的组合打出来的单机内部TP4或TP8把模型切得快一点多机之间用DP把请求摊开。3.2 单机8卡的最佳实践配置与显存账拿一张真实账单来算。假设你拿到一台8卡H100服务器要服务70B FP8模型每张卡80GB HBM。权重占用约70GB如果TP8每卡权重只有8.75GB剩下71GB全给KV Cache和激活值。这看起来很美但别忘了TP8意味着每层都要跨卡通信实际算力利用率可能只有60%左右。我实测下来这种配置下并发数可以开到几百路QPS能做到1000以上前提是请求长度在1K token以内、输出长度在256 token左右。单机8卡的心得是TP维度优先解决“装得下”的问题DP维度解决“跑得快”的问题。如果你手里的模型权重量级不大比如7B模型单卡FP16也就14GB那么TP1、单卡部署用DP横向扩展实例数反而是最灵活、最省事的方案。因为单卡推理没有跨卡通信请求调度的颗粒度是“一张卡一个实例”千卡集群的负载均衡策略会简单很多。我见过不少团队一上来就TP8把一个14GB的7B模型切成8份结果每张卡的显存浪费严重还引入了一大堆通信延迟性能和成本双双拉胯。模型的体量决定并行策略这是一个朴素但极其重要的判断。4. 百卡千卡集群的网络设计与通信架构InfiniBand、RoCE与拓扑选型4.1 网络是千卡集群的第一瓶颈当你决定走向多机集群第一个要面对的事实是服务器间的通信带宽和延迟比GPU内部的NVLink差了两个数量级。NVLink域内是900GB/s起步而跨机走网卡主流方案是InfiniBand NDR单端口400Gbps约50GB/s或者RoCEv2同样跑在400Gbps上实际有效带宽还要打个折扣。千卡集群里最常见的通信模式有两种一种是AllReduce多卡同步梯度或中间激活值通信量很大常用于prefill阶段的TP并行另一种是All-to-All每张卡都要和其他卡交换数据这个模式在MOE模型的专家并行里简直是家常便饭——每个token要路由到不同的专家卡上然后再把结果收回来。所以网络拓扑的设计核心目标就是尽可能让频繁通信的GPU之间跳数少、带宽大。千卡集群的标准拓扑是两层胖树Spine-Leaf底层Leaf交换机连接计算节点上层Spine交换机负责跨Leaf的流量转发。设计时要特别注意“轨道优化”的概念——也就是让固定GPU槽位尽量连接到同一Leaf交换机下减少跨Leaf流量。否则你看起来是千卡集群实际有效通信带宽可能只有设计值的四成。4.2 IB和RoCE怎么选取决于你的运维基因选型问题上我一直坚持一个观点有钱、有专门的HPC运维团队选IB想省钱、团队熟悉TCP/IP生态选RoCEv2。IB的优势是丢了包有硬件级别的可靠传输机制拥塞控制也是出厂自带队列对QP管理成熟性能稳定基本不用怎么调优就能跑满带宽。缺点是贵而且交换机、网卡、线缆全是专有设备运维门槛高。RoCEv2是跑在以太网上的RDMA硬件成本低可以复用现成的数据中心网络但拥塞控制、可靠传输都得自己搞定。我在真实项目中遇到过RoCE网络一旦发生微突发拥塞PFC优先级流控触发后会把整个网络“卡死”所有流量大范围降速那种时刻你会怀疑人生。后来我们被迫引入了自适应路由和ECN显式拥塞通知把网络调稳了才敢继续加机器。千卡规模的网络设计我有一个可复用的计算公式集群总通信带宽 GPU卡数 × 单卡网络带宽 × 实际并发通信比例。比如1000张H100每卡配400Gbps网卡并发通信比例按30%估那么核心交换机层需要至少120Tbps的交换容量。再按每个Leaf交换机接入40台服务器320个400G端口你需要大约25台Leaf和6到8台Spine才能撑起这个规模。这个数字不是拍脑袋而是从“集中式拥塞点”反推出来的。5. 推理引擎选型与核心机制vLLM、PagedAttention与Continuous Batching5.1 为什么所有推理集群都绕不开vLLM到了引擎层现在的情况基本是vLLM一统天下再加上SGLang、TensorRT-LLM、Ollama轻量场景各自占据生态位。我个人的建议是生产环境首选vLLM需要RadixAttention做前缀复用时选SGLang对延迟极致敏感且批量固定时上TensorRT-LLM。vLLM能成为事实标准核心是它把两个事情做到了极致。第一个是PagedAttention——把KV Cache按固定大小分块通常每块16个token像操作系统虚拟内存一样按需分配彻底解决了显存碎片化和KV Cache预留过量的老问题。我之前测试过传统静态KV Cache方案下70B模型单卡并发只能开到16路切到PagedAttention之后直接翻了三倍多。第二个是Continuous Batching连续批处理也叫动态批处理。传统推理是一次性把一个batch的所有序列跑完短请求得等长请求跑完才释放资源效率很低。vLLM的做法是每个step迭代都重新组batch——先完成的请求立刻退出新的请求马上补进来。这个机制在混合长短请求的场景下能把GPU利用率拉高近一倍。我见过不少团队在选型时犹豫不决最后一通比较下来发现vLLM的生态最完整、社区最活跃、和K8s及各种调度框架的集成最成熟。这一点在千卡集群里很重要——你的推理引擎必须能被外部调度器精细控制而vLLM的--enable-prefix-caching、--max-num-seqs、--gpu-memory-utilization这些参数每一个都能直接影响集群规模下的吞吐表现。5.2 引擎级调优的几个关键参数一定得知道含义--tensor-parallel-sizeTP的卡数决定模型怎么切必须跟实际的GPU拓扑一致。--max-num-seqs单实例最大并发序列数这是吞吐和显存的安全阀。设大了容易OOM设小了GPU喂不饱。我的习惯是先按每GB可用显存大约支撑32路并发7B FP16模型经验值估算再用压测校正。--max-model-len最大序列长度直接影响KV Cache的预分配大小。这个值设太长显存会被空耗设太短长请求直接报错。--gpu-memory-utilizationGPU显存用于模型加KV Cache的百分比我一般设0.9到0.95剩下留给CUDA context和临时buffer。注意生产集群中这些参数必须在部署清单里锁定并规范化否则每个实例各调各的负载均衡就成了玄学——有的实例满载有的实例空转。6. 千卡负载均衡的核心设计全局调度、PD分离与MOE流量均衡6.1 千卡负载均衡为什么不能简单用轮询很多从Web后端转过来的人下意识会想用Nginx/ALB做轮询或者最小连接数调度。这套思路在无状态微服务里没问题但在大模型推理集群里会撞上一堵墙每个请求的算力消耗完全不一样。一个输入1K token、输出100 token的请求和一个输入10K token、输出4K token的请求对GPU算力和显存带宽的占用差了可能几十倍。如果只做连接数维度的均衡长请求必然堆积在某几张卡上其他卡闲得发慌。所以千卡推理的负载均衡必须从“连接均衡”升级到“算力感知均衡”或“显存感知均衡”。具体做法是在网关层实时采集每个推理实例的指标——当前排队的请求数、剩余可用显存、最近一分钟的QPS和延迟分位数——然后调度器根据这些指标做加权决策。权重可以是w 可用显存 × 空闲算力 / 当前排队长度或者用更工程化的方式把指标发到Prometheus由调度器通过gRPC拉取。但光有单元级别的负载均衡还不够。因为大模型推理请求的并发特征非常陡峭——比如早上10点上班高峰检索类请求瞬间涌进来输出还普遍偏长。这种突发模式下如果所有实例均匀扛负载很可能整体都被压垮。所以集群架构上还要预留弹性buffer池平时空闲时保持1.2倍冗余算力突发时通过K8s HPA快速拉起更多副本。注意副本拉起需要模型加载时间70B模型从冷启动到可服务可能要几分钟因此预热池机制几乎是必需品。6.2 PD分离为什么prefill和decode必须分开调度PD分离Prefill/Decode Disaggregation是这两年推理架构里最值得关注的方向之一。前面说过prefill吃算力、decode吃带宽两者混在同一个GPU实例上必然相互拖累。PD分离的思路是把集群里的GPU分成两组一组专门跑prefillP组一组专门跑decodeD组中间通过高速网络传递KV Cache。这样做的好处非常明显。P组的GPU可以全力以赴处理新请求把TTFT压到极低D组的GPU专心一意地做自回归生成吞吐量可以稳步提升。而且两组可以独立扩缩容——用户输入变长时扩容P组输出变长时扩容D组资源利用率比混合模式高很多。但实现PD分离的代价也很大KV Cache要从P组拷贝到D组。以70B模型为例一个10K token的请求对应KV Cache大约是1.5GB左右上千QPS意味着每秒要传TB级别的KV数据。这就又回到了网络设计问题——没有高速网络PD分离就是纸上谈兵。行业内SGLang、vLLM的PD分离方案如vLLM的--distributed-executor-backend配合disagg server在千卡网络上能跑得很好但在万兆以太网上就是灾难这是选型时必须权衡的。我自己实践中的建议是如果集群规模在100卡以内网络还是RoCE且延迟SLO比较宽松可以先不做PD分离用混合模式把并发和批处理调好同样可以做到不错的性价比。PD分离更适合规模大、SLO要求高的生产系统。6.3 MOE模型的负载均衡专家并行与Token分配的艺术千卡集群遇到MOE模型负载均衡的复杂度会再次上升。因为MOE模型的每个token只激活少量专家而这些专家分散在不同的GPU上请求的流量天然是All-to-All的。在这个场景下最容易出现的问题是热门专家被路由到同一张卡上导致某些卡负载爆表、其他卡空闲。训练阶段解决负载不均衡的经典手段是辅助损失Auxiliary Loss给每个专家加一个负载均衡约束让token尽量均匀分配。到了推理阶段这个约束已经固化在模型权重里了但推理请求的分布仍然可能不均衡——比如某个token序列特别长反复激活的都是同一组专家负责这些专家的GPU就会过载。我的处理办法是双层均衡第一层在调度器维度维护一张“专家卡负载表”记录每张卡当前承载的热门专家数量和队列深度第二层在请求路由维度当某组专家过载时调度器把新请求引导到有该专家副本的另一张卡上。这需要模型部署时做专家副本冗余——把热门专家复制到多张卡上让负载均衡有真正的选择空间。说实话MOE的推理负载均衡目前还没有统一开箱即用的方案各家都在“工程上打补丁”。我的建议是如果你要部署千卡级别的MOE模型一定要在压测阶段就引入“专家卡热度监控”否则线上一定会被不均匀流量打爆。6.4 全局调度器的分层设计千卡集群的负载均衡最终要落地成一套分层的调度体系。我习惯把它分成三层第一层是接入网关层负责请求解析、鉴权、协议转换然后基于最简单的策略比如一致性哈希把请求分到某个“路由单元”。第二层是路由调度层这里有全局视图。调度器维护每个推理实例的实时负载指标通过加权最少负载算法把请求发给最空闲的实例。关键点是这个调度器必须能感知请求的长度——通过HTTP头的content-length或者首包解析出输入token数再决定投递到哪个实例。这一步做的越精细集群的整体利用率就越高。第三层是引擎内部调度层即vLLM/SGLang的Continuous Batching、Prefix Caching等机制它们在单个GPU实例内部做细粒度的请求组织和显存分配。三层配合得当才能做到真正的“千卡一心”。注意这里每一层的调度延迟都应控制在个位数毫秒以内一旦调度器本身成为瓶颈集群再大也是白搭。我做过一次粗测路由调度层如果采用同步等待各实例上报状态每500ms一次在全负载情况下会增加约5ms的P99延迟而改成异步事件上报后这个开销降到了1ms以内。所以调度器的观测通道必须是异步、带缓存、可降级的。7. 推理集群的容器化与编排实践K8s、GPU虚拟化与自动扩缩容7.1 每个推理实例都应该是“肉鸡”而不是“宠物”千卡集群一旦跑起来GPU实例的故障率是不可忽略的。按照统计一张H100的年故障率大概在1%到2%之间千卡规模意味着平均每隔几周就可能有一张卡出问题。这不只是硬件坏还有可能是因为CUDA驱动升级、显存ECC错误、甚至机房温度过高导致的降频。所以架构上必须把每个推理实例做成无状态、可替换的。模型放在共享存储如Lustre、MinIO、S3兼容存储上每个Pod启动时拉取模型文件到本地NVMe加载到显存向注册中心上报健康状态然后对外服务。一旦显存OOM或者健康检查失败K8s自动杀掉Pod拉起一个新Pod。我见过最惨痛的教训是有人把模型直接打包进容器镜像模型14GB镜像20多GB每次滚动更新都要把所有节点重新拉一遍镜像光镜像分发就花了4个小时。正确的做法是用镜像只承载推理引擎和依赖库模型走独立的存储和缓存层。7.2 GPU共享与时间片切分千卡集群的“资源碎片”处理千卡集群最常见的问题是资源碎片化。比如某张卡显存80GB模型只需要40GB剩下40GB因为没部署另一个实例就浪费了。要解决碎片化主流有三种方案MIGMulti-Instance GPU、vGPU虚拟化、或者干脆用时间片共享。MIG是NVIDIA官方的硬隔离方案可以把一张H100切成多个实例。但MIG有个硬伤实例之间不共享显存带宽而且显存容量被硬性划分后可能不够放模型。我实际用下来MIG适合切出“小模型推理单元”这类场景对大模型推理的碎片化治理帮助不大。vGPU虚拟化则是用软件层把显存和算力做逻辑切分灵活性高但要额外付授权费而且有大约5%到10%的性能损耗。我自己在这个问题上的经验是尽量让每个GPU实例的显存需求与物理显存容量对齐。一个70B模型如果FP8量化是70GB那我就不硬塞进80GB单卡的实例里宁可少开并发也不强行并行切分。因为大模型推理对显存的访问频率极高任何虚拟化层带来的带宽损失都会被放大。7.3 自动扩缩容的正确姿势慢启动和预热池千卡集群的HPA配置第一原则是“预留时间”。从HPA触发到Pod变成Ready过程是这样的调度新Pod可能要等待GPU资源、拉取镜像、下载模型到本地缓存、加载模型到显存、编译CUDA Kernel、注册到服务发现——这一整套下来70B模型大概需要3到5分钟。而业务尖峰往往几十秒内就会涌进来。如果等HPA指标触发才扩容早就被压垮了。所以我的落地经验是维护一个预热池集群里始终有20%到30%的Pod已经完成模型加载处于待命状态。它们的CPU占用很低但显存已经被占据。当负载上升时调度器直接把请求切过去同时再通过HPA补建新Pod到预热池里。这个机制看起来是浪费了一部分显存但在千卡规模下它换来的稳定性远超省下的那点资源。K8s层面还有两个细节。一是要用nodeSelector或gpuType标签把不同型号的GPU分开调度别让A100和H100混跑在同一个服务下否则慢卡拖慢快卡。二是要配置PodDisruptionBudget防止集群升级时把所有副本同时杀掉。千卡集群的维护操作永远遵循“逐个节点滚动”的铁律。8. 推理过程全链路追踪与可观测性建设8.1 从“黑盒”到“白盒”关键指标到底看哪些千卡推理集群排障如果没有可观测性基本是瞎子摸象。我维护了一个统一的可观测性平台核心有四个层面的数据模型层指标TTFT首token延迟、TPOT每token生成时间、吞吐tokens/s、QPS。实例层指标GPU利用率、显存占用关键看KV Cache使用率、GPU温度、功耗、NVLink带宽。网络层指标IB/RoCE端口丢包率、重传率、ECN标记率、拥塞队列深度。调度器指标每个实例的队列深度、调度决策耗时、预热池剩余容量。这四层数据串起来能构成一条完整的请求链路。比如用户反馈“回答变慢了”你不能只看到整体P99涨了还得定位到是哪一层导致的——是路由层把请求发给了重负载实例还是网络拥塞导致KV Cache传输慢还是GPU降频了我的排障习惯是先看实例层再看网络层最后看调度器。实例层直接反映算力是否吃紧网络层往往容易被忽略但千卡集群的大多数莫名其妙的问题都出在网络上调度器指标则能暴露负载均衡策略本身的缺陷。8.2 链路追踪的落地方式推理请求的链路追踪比普通Web请求复杂得多因为一个请求会被多个GPU实例分段处理。业界常用的做法是给每个请求分配一个request_id在接入层注入然后每个处理节点都上报带有request_id的Span数据最后汇聚到Jaeger或SkyWalking。关键是要把Span的字段设计好请求输入长度、输出长度、模型路径、使用的TP组、KV Cache传输大小、各阶段耗时。有了这些数据你才能回答“为什么这个请求慢”的根源性问题。我在实践中还会加一个字段preempted标记这个请求是否被抢占过——因为vLLM在做显存不足时的抢占调度时会暂停部分请求这个事件如果不记录你会看到莫名其妙的TPOT尖刺。提示日志采集要避免同步阻塞。千卡集群每秒会产生海量日志一定要用异步队列缓冲比如Kafka或Loki的Promtail否则日志系统本身会成为性能瓶颈。9. 常见问题与故障排查实录千卡集群的典型翻车现场9.1 负载全都压在少数几张卡上现象集群里某些GPU利用率90%以上另一些不到20%整体QPS却上不去。 排查步骤第一看路由调度器的决策日志确认请求是不是被算法均匀分发第二看实例的健康状态上报确认是不是部分实例因为延迟高被动“降权”第三检查请求特征是不是长请求总是哈希到同一组实例。这个问题的根因往往出在一致性哈希的key设计上。如果你用用户ID做哈希某些大客户的长请求会集中打在同一组实例上。修正方案是把哈希key从“用户ID”改成“请求输入长度的分段随机数”让每个请求的调度权重与算力消耗挂钩。另外调度器的实例权重更新周期不能太长我建议把500ms的同步拉取改成事件驱动的异步推送让负载信号更灵敏。9.2 显存OOM千卡集群的“死亡重启”现象某张卡的vLLM实例突然OOMK8s将其重启然后同组的其他实例QPS瞬时上涨引发连锁OOM。 根因分析KV Cache的预估与实际偏差过大或者某个请求的输出长度远超预期把预留的缓冲显存打穿了。解决思路有三个层面。第一层在引擎参数上设置--max-num-seqs把单实例并发上限卡死宁可让请求排队也不让显存崩掉。第二层在网关层加“请求长度预检”超过阈值的请求直接拒绝或路由到专为大请求准备的实例组。第三层部署监控告警当KV Cache使用率达到85%时提前告警而不是等OOM才反应过来。9.3 网络拥塞导致全集群性能雪崩现象某次压测中所有实例的decode速度同时掉到正常值的一半GPU利用率却不高。 排查过程一看实例指标GPU利用率确实没打满再看网络指标RoCE端口ECN标记率超过5%PFC触发次数飙升。这就是典型的RoCE网络拥塞——某个Leaf交换机下的流量突发引发了全局的流控风暴。治本的办法是调整网络拓扑和流控策略开启ECN和自适应路由合理设置PFC阈值同时把大流量任务PD分离的KV Cache传输分散到不同Leaf下。如果条件允许在RoCE网络里给推理集群单独划分一个无损域避免和其他业务的流量互相干扰。9.4 冷启动太慢救不了突发流量现象日常流量平稳突然来一波营销活动流量HPA开始扩容但70B模型每个新Pod要5分钟才能Ready等Pod起来活动流量已经过去了。 解决维持预热池而且要把预热池的大小做成动态的。我常用的做法是绑定一个“预测式扩缩容”的定时任务根据历史流量曲线在预期高峰到来前20分钟提前扩容高峰过后再逐步回收。K8s的HPA只对“已经发生”的负载敏感而预测式扩缩容能对“即将发生”的负载做预判两者配合才能应对真实的生产高峰。9.5 一张速查表这些坑我帮你踩过了问题常见根因推荐解法单实例QPS上不去TP维度过大导致通信瓶颈根据模型体量优先DP扩展TP够用即可TTFT偏高prefill和decode混跑互相抢占引入PD分离或限制单实例并发长尾延迟严重个别实例负载不均调度器引入算力感知加权缩短上报周期显存频繁OOMKV Cache预留不足或请求过长设置max-num-seqs网关预检请求长度集群整体吞吐低网络拥塞触发PFC开启ECN、自适应路由优化拓扑扩容来不及模型加载时间过长维护预热池 预测式扩缩容10. 千卡集群的落地节奏与成本治理思路架构设计讲完最后说说实施路径。千卡集群不是一天建成的我的建议是分四步走。第一步单机验证阶段。先用一台8卡服务器把模型服务跑起来完成功能验证和基准压测拿到单机QPS、TTFT、显存占用的基线数据。这个阶段最重要的是把“单卡/单机能力边界”摸透否则后面所有容量规划都是空中楼阁。第二步小集群试运行阶段。用32到64张卡搭建一个小规模集群验证网络通信、调度器、负载均衡的可用性。这个阶段要特别关注跨机通信的稳定性和调度器的决策质量再把监控告警体系搭建完整。第三步规模扩展阶段。从小规模到千卡核心不是买卡而是反复压测找出瓶颈逐个击破。每加一批机器都要重新跑一遍全链路压测确认性能按预期线性扩展。第四步成本治理阶段。千卡集群的电力成本和采购成本都是天文数字优化空间也最大。比如FP8量化、KV Cache量化、动态批处理、SDN流量调度、空闲时回收GPU实例每一环都能省下可观的费用。很多团队在千卡规模下实际GPU利用率只有40%到50%如果能通过架构优化把它拉到70%以上相当于白拿了几百张卡的算力。我个人在实际操作中最大的体会是千卡集群的架构设计拼的不是某一项技术有多新而是每一项基础工作是否做到位——网络拓扑是否合理、调度器是否感知负载、实例是否可快速替换、监控是否覆盖全链路。这些听起来很朴素但在压力测试面前任何一个环节偷懒都会以非常难堪的方式暴露出来。最后再分享一个细节技巧千卡集群上线前一定先做一次“混沌演练”——随机拔掉一张卡的网线随机杀掉几个Pod再随机注入一次网络丢包。看着监控大屏上系统自己恢复稳定你才会对这套架构真正有信心。 大模型推理集群架构：从单卡到千卡的负载均衡实践
1. 从单卡到千卡先搞懂推理集群到底在解决什么问题这些年做大模型推理最常见的开场白是“我有一个H100跑一个70B模型怎么QPS只有几十”然后一问细节显存不够用、多卡通信绕、请求一多就超时问题全挤在一起。等真正把规模推到千卡你会发现单卡踩过的坑到了集群环境下全都会放大十倍百倍地还回来。所以聊大模型推理集群架构设计我得先给这件事定个调这不是“把N张卡拼起来跑模型”的工程题而是“在有限成本下让成百上千个并发请求以最低延迟、最高吞吐拿到推理结果”的资源调度题。核心关键词就两个——大模型、千卡中间牵引它们的分别是计算密度、网络拓扑和调度策略。我在实际做集群规划时通常会先把问题拆成三层单机推理的硬件上限在哪里多机通信的瓶颈是什么以及负载均衡策略能不能跟模型并行方式匹配起来。这三层互为约束脱离任何一层谈架构都是空谈。举个直观的例子。你在单卡上做推理H100的显存带宽是3.35TB/s左右算力是989 TFLOPSFP16看起来强悍。但70B模型哪怕是FP8量化光权重就得70GB单卡80GB显存勉强塞得下可KV Cache一上来显存立刻见底。这时候你被迫开启PagedAttention之类的显存复用机制把KV Cache按块管理才勉强让并发数上来。等到了千卡规模单卡的那点显存复用已经不重要了重要的是卡与卡之间的数据搬运速度和全局调度器的眼界——因为你面对的请求已经不是几十个而是每秒成百上千个每个请求还可能命中不同的模型副本。千卡集群真正的难点在于模型参数是切开的请求是随机到达的显存是分布式的任何一张卡的负载失衡都会造成整体性能塌方。负载均衡这个词在这种场景下不是Nginx轮询那种简单的概念而是贯穿了接入层、调度层、引擎层、通信层的系统工程。接下来我从单卡讲起一步步拆解到千卡负载均衡的完整架构把我踩过的坑、调过的参、推倒重来的方案都记录下来。2. 单卡推理的性能天花板TCO曲线与算力收益递减规律2.1 单卡推理的两个阶段为什么决定了架构走向在进入集群话题前有必要把单卡推理的真实面貌说透。大模型推理每个请求都要经历两个阶段prefill预填充和decode解码。Prefill阶段是并行计算密集型的一次处理用户输入的整段tokenGPU利用率很高decode阶段则是串行逐token生成的每一步都依赖前一步的结果GPU利用率往往只有个位数到百分之十几。这个差异对架构设计的影响是决定性的。PreFill吃的是算力FLOPSdecode吃的是显存带宽HBM bandwidth。你在单卡上做优化本质就是在两个阶段之间找平衡prefill太快会挤占decode的算力decode太慢会让首token延迟TTFT飙升。业界常说的PD分离Prefill/Decode分离就是针对这个矛盾演化出来的经典方案后面我会细讲。从单卡的实测数据看70B模型如果用FP8量化在单张H100上并发数大概能支撑到20到40路取决于输入长度decode速度大约在每秒1000到2000个token之间prefill的TTFT在小并发下可以压到500毫秒以内。听起来还行但一旦请求长度变长、并发数翻倍decode的显存带宽就会触顶——这就像一条单车道的高速路车多了必然堵跟路面算力好不好关系不大。2.2 为什么单卡规模继续叠加不划算每次做容量评估我都会画一条TCO曲线横轴是GPU数量纵轴是单位成本能扛住的QPS。单卡阶段曲线斜率很高加一张卡就有明显收益但到了8卡阶段因为NVLink域内通信效率高曲线仍然保持着不错的斜率一旦跨过单机8卡的边界需要走RDMA网络做跨机通信同样的QPS增量你需要付出的网络资源和调度成本会急剧上升。这里有个经典的“算力收益递减规律”你往集群里加卡算力是线性增长的但通信开销和调度开销是超线性增长的。千卡集群的每一千次推理请求都要经历“请求分发→多机协同prefill→跨机聚合KV Cache→逐token decode→结果汇聚”的完整链路任何一个环节的延迟都会累计到用户的TTFT和TPOT上。所以我在做架构设计时第一原则就是能用单卡解决的不扩大到多卡能用单机解决的不扩大到跨机能用一个GPU实例解决的不上推理集群。这句话看似废话但很多人一上来就规划千卡集群结果模型只有7B用一张4090就能跑得飞快纯粹是浪费预算。正确路线是先量化业务峰值QPS、平均输入输出长度、SLO要求比如P95 TTFT 2秒、P95 TPOT 50ms再倒推所需的GPU总算力和显存总量。3. 多卡并行与单机八卡张量并行、流水线并行和数据并行的取舍3.1 三种并行方式在推理场景的真实作用单卡塞不下模型或者吞吐不够时第一反应就是多卡。大模型训练里的经典三件套——张量并行TP、流水线并行PP、数据并行DP——到了推理场景优先级和用法完全不一样了。先看张量并行。TP是把一个Transformer层的权重按行或按列切开分到多张卡上每张卡只算自己那部分计算完再做AllReduce汇总。推理时TP的最大优势是显存扩容一个70B的模型切成4份每张卡只存17.5GB的权重给KV Cache留出大量空间。但TP也是通信最重的并行方式每过一个Transformer层就要做多次AllReduce通信量跟hidden size成正比。我在单机8卡NVLink环境下跑过70B模型TP8时通信开销还能接受NVLink双向带宽900GB/s但如果跨机做TP8那基本是在给自己挖坑。再看流水线并行。PP是把模型按层切成多段每张卡负责其中一段数据像流水线一样逐段流过。推理场景下PP用得很少原因很直接推理是低延迟敏感的在线服务流水线天然会增加端到端延迟而且PP的显存利用率不如TP灵活。除非模型大到单机8卡都塞不下比如超过1TB的模型像一些MOE大模型否则我不太推荐在推理链路里引入PP。最后是数据并行。DP最简单就是复制多份完整模型每份独立处理不同请求最后通过负载均衡把请求散开。DP是推理集群最基础的扩展手段因为它跟请求调度天然契合——每个GPU实例都是无状态的任何一个请求可以被任意副本处理。千卡集群里绝大部分扩展能力其实是靠DP加TP的组合打出来的单机内部TP4或TP8把模型切得快一点多机之间用DP把请求摊开。3.2 单机8卡的最佳实践配置与显存账拿一张真实账单来算。假设你拿到一台8卡H100服务器要服务70B FP8模型每张卡80GB HBM。权重占用约70GB如果TP8每卡权重只有8.75GB剩下71GB全给KV Cache和激活值。这看起来很美但别忘了TP8意味着每层都要跨卡通信实际算力利用率可能只有60%左右。我实测下来这种配置下并发数可以开到几百路QPS能做到1000以上前提是请求长度在1K token以内、输出长度在256 token左右。单机8卡的心得是TP维度优先解决“装得下”的问题DP维度解决“跑得快”的问题。如果你手里的模型权重量级不大比如7B模型单卡FP16也就14GB那么TP1、单卡部署用DP横向扩展实例数反而是最灵活、最省事的方案。因为单卡推理没有跨卡通信请求调度的颗粒度是“一张卡一个实例”千卡集群的负载均衡策略会简单很多。我见过不少团队一上来就TP8把一个14GB的7B模型切成8份结果每张卡的显存浪费严重还引入了一大堆通信延迟性能和成本双双拉胯。模型的体量决定并行策略这是一个朴素但极其重要的判断。4. 百卡千卡集群的网络设计与通信架构InfiniBand、RoCE与拓扑选型4.1 网络是千卡集群的第一瓶颈当你决定走向多机集群第一个要面对的事实是服务器间的通信带宽和延迟比GPU内部的NVLink差了两个数量级。NVLink域内是900GB/s起步而跨机走网卡主流方案是InfiniBand NDR单端口400Gbps约50GB/s或者RoCEv2同样跑在400Gbps上实际有效带宽还要打个折扣。千卡集群里最常见的通信模式有两种一种是AllReduce多卡同步梯度或中间激活值通信量很大常用于prefill阶段的TP并行另一种是All-to-All每张卡都要和其他卡交换数据这个模式在MOE模型的专家并行里简直是家常便饭——每个token要路由到不同的专家卡上然后再把结果收回来。所以网络拓扑的设计核心目标就是尽可能让频繁通信的GPU之间跳数少、带宽大。千卡集群的标准拓扑是两层胖树Spine-Leaf底层Leaf交换机连接计算节点上层Spine交换机负责跨Leaf的流量转发。设计时要特别注意“轨道优化”的概念——也就是让固定GPU槽位尽量连接到同一Leaf交换机下减少跨Leaf流量。否则你看起来是千卡集群实际有效通信带宽可能只有设计值的四成。4.2 IB和RoCE怎么选取决于你的运维基因选型问题上我一直坚持一个观点有钱、有专门的HPC运维团队选IB想省钱、团队熟悉TCP/IP生态选RoCEv2。IB的优势是丢了包有硬件级别的可靠传输机制拥塞控制也是出厂自带队列对QP管理成熟性能稳定基本不用怎么调优就能跑满带宽。缺点是贵而且交换机、网卡、线缆全是专有设备运维门槛高。RoCEv2是跑在以太网上的RDMA硬件成本低可以复用现成的数据中心网络但拥塞控制、可靠传输都得自己搞定。我在真实项目中遇到过RoCE网络一旦发生微突发拥塞PFC优先级流控触发后会把整个网络“卡死”所有流量大范围降速那种时刻你会怀疑人生。后来我们被迫引入了自适应路由和ECN显式拥塞通知把网络调稳了才敢继续加机器。千卡规模的网络设计我有一个可复用的计算公式集群总通信带宽 GPU卡数 × 单卡网络带宽 × 实际并发通信比例。比如1000张H100每卡配400Gbps网卡并发通信比例按30%估那么核心交换机层需要至少120Tbps的交换容量。再按每个Leaf交换机接入40台服务器320个400G端口你需要大约25台Leaf和6到8台Spine才能撑起这个规模。这个数字不是拍脑袋而是从“集中式拥塞点”反推出来的。5. 推理引擎选型与核心机制vLLM、PagedAttention与Continuous Batching5.1 为什么所有推理集群都绕不开vLLM到了引擎层现在的情况基本是vLLM一统天下再加上SGLang、TensorRT-LLM、Ollama轻量场景各自占据生态位。我个人的建议是生产环境首选vLLM需要RadixAttention做前缀复用时选SGLang对延迟极致敏感且批量固定时上TensorRT-LLM。vLLM能成为事实标准核心是它把两个事情做到了极致。第一个是PagedAttention——把KV Cache按固定大小分块通常每块16个token像操作系统虚拟内存一样按需分配彻底解决了显存碎片化和KV Cache预留过量的老问题。我之前测试过传统静态KV Cache方案下70B模型单卡并发只能开到16路切到PagedAttention之后直接翻了三倍多。第二个是Continuous Batching连续批处理也叫动态批处理。传统推理是一次性把一个batch的所有序列跑完短请求得等长请求跑完才释放资源效率很低。vLLM的做法是每个step迭代都重新组batch——先完成的请求立刻退出新的请求马上补进来。这个机制在混合长短请求的场景下能把GPU利用率拉高近一倍。我见过不少团队在选型时犹豫不决最后一通比较下来发现vLLM的生态最完整、社区最活跃、和K8s及各种调度框架的集成最成熟。这一点在千卡集群里很重要——你的推理引擎必须能被外部调度器精细控制而vLLM的--enable-prefix-caching、--max-num-seqs、--gpu-memory-utilization这些参数每一个都能直接影响集群规模下的吞吐表现。5.2 引擎级调优的几个关键参数一定得知道含义--tensor-parallel-sizeTP的卡数决定模型怎么切必须跟实际的GPU拓扑一致。--max-num-seqs单实例最大并发序列数这是吞吐和显存的安全阀。设大了容易OOM设小了GPU喂不饱。我的习惯是先按每GB可用显存大约支撑32路并发7B FP16模型经验值估算再用压测校正。--max-model-len最大序列长度直接影响KV Cache的预分配大小。这个值设太长显存会被空耗设太短长请求直接报错。--gpu-memory-utilizationGPU显存用于模型加KV Cache的百分比我一般设0.9到0.95剩下留给CUDA context和临时buffer。注意生产集群中这些参数必须在部署清单里锁定并规范化否则每个实例各调各的负载均衡就成了玄学——有的实例满载有的实例空转。6. 千卡负载均衡的核心设计全局调度、PD分离与MOE流量均衡6.1 千卡负载均衡为什么不能简单用轮询很多从Web后端转过来的人下意识会想用Nginx/ALB做轮询或者最小连接数调度。这套思路在无状态微服务里没问题但在大模型推理集群里会撞上一堵墙每个请求的算力消耗完全不一样。一个输入1K token、输出100 token的请求和一个输入10K token、输出4K token的请求对GPU算力和显存带宽的占用差了可能几十倍。如果只做连接数维度的均衡长请求必然堆积在某几张卡上其他卡闲得发慌。所以千卡推理的负载均衡必须从“连接均衡”升级到“算力感知均衡”或“显存感知均衡”。具体做法是在网关层实时采集每个推理实例的指标——当前排队的请求数、剩余可用显存、最近一分钟的QPS和延迟分位数——然后调度器根据这些指标做加权决策。权重可以是w 可用显存 × 空闲算力 / 当前排队长度或者用更工程化的方式把指标发到Prometheus由调度器通过gRPC拉取。但光有单元级别的负载均衡还不够。因为大模型推理请求的并发特征非常陡峭——比如早上10点上班高峰检索类请求瞬间涌进来输出还普遍偏长。这种突发模式下如果所有实例均匀扛负载很可能整体都被压垮。所以集群架构上还要预留弹性buffer池平时空闲时保持1.2倍冗余算力突发时通过K8s HPA快速拉起更多副本。注意副本拉起需要模型加载时间70B模型从冷启动到可服务可能要几分钟因此预热池机制几乎是必需品。6.2 PD分离为什么prefill和decode必须分开调度PD分离Prefill/Decode Disaggregation是这两年推理架构里最值得关注的方向之一。前面说过prefill吃算力、decode吃带宽两者混在同一个GPU实例上必然相互拖累。PD分离的思路是把集群里的GPU分成两组一组专门跑prefillP组一组专门跑decodeD组中间通过高速网络传递KV Cache。这样做的好处非常明显。P组的GPU可以全力以赴处理新请求把TTFT压到极低D组的GPU专心一意地做自回归生成吞吐量可以稳步提升。而且两组可以独立扩缩容——用户输入变长时扩容P组输出变长时扩容D组资源利用率比混合模式高很多。但实现PD分离的代价也很大KV Cache要从P组拷贝到D组。以70B模型为例一个10K token的请求对应KV Cache大约是1.5GB左右上千QPS意味着每秒要传TB级别的KV数据。这就又回到了网络设计问题——没有高速网络PD分离就是纸上谈兵。行业内SGLang、vLLM的PD分离方案如vLLM的--distributed-executor-backend配合disagg server在千卡网络上能跑得很好但在万兆以太网上就是灾难这是选型时必须权衡的。我自己实践中的建议是如果集群规模在100卡以内网络还是RoCE且延迟SLO比较宽松可以先不做PD分离用混合模式把并发和批处理调好同样可以做到不错的性价比。PD分离更适合规模大、SLO要求高的生产系统。6.3 MOE模型的负载均衡专家并行与Token分配的艺术千卡集群遇到MOE模型负载均衡的复杂度会再次上升。因为MOE模型的每个token只激活少量专家而这些专家分散在不同的GPU上请求的流量天然是All-to-All的。在这个场景下最容易出现的问题是热门专家被路由到同一张卡上导致某些卡负载爆表、其他卡空闲。训练阶段解决负载不均衡的经典手段是辅助损失Auxiliary Loss给每个专家加一个负载均衡约束让token尽量均匀分配。到了推理阶段这个约束已经固化在模型权重里了但推理请求的分布仍然可能不均衡——比如某个token序列特别长反复激活的都是同一组专家负责这些专家的GPU就会过载。我的处理办法是双层均衡第一层在调度器维度维护一张“专家卡负载表”记录每张卡当前承载的热门专家数量和队列深度第二层在请求路由维度当某组专家过载时调度器把新请求引导到有该专家副本的另一张卡上。这需要模型部署时做专家副本冗余——把热门专家复制到多张卡上让负载均衡有真正的选择空间。说实话MOE的推理负载均衡目前还没有统一开箱即用的方案各家都在“工程上打补丁”。我的建议是如果你要部署千卡级别的MOE模型一定要在压测阶段就引入“专家卡热度监控”否则线上一定会被不均匀流量打爆。6.4 全局调度器的分层设计千卡集群的负载均衡最终要落地成一套分层的调度体系。我习惯把它分成三层第一层是接入网关层负责请求解析、鉴权、协议转换然后基于最简单的策略比如一致性哈希把请求分到某个“路由单元”。第二层是路由调度层这里有全局视图。调度器维护每个推理实例的实时负载指标通过加权最少负载算法把请求发给最空闲的实例。关键点是这个调度器必须能感知请求的长度——通过HTTP头的content-length或者首包解析出输入token数再决定投递到哪个实例。这一步做的越精细集群的整体利用率就越高。第三层是引擎内部调度层即vLLM/SGLang的Continuous Batching、Prefix Caching等机制它们在单个GPU实例内部做细粒度的请求组织和显存分配。三层配合得当才能做到真正的“千卡一心”。注意这里每一层的调度延迟都应控制在个位数毫秒以内一旦调度器本身成为瓶颈集群再大也是白搭。我做过一次粗测路由调度层如果采用同步等待各实例上报状态每500ms一次在全负载情况下会增加约5ms的P99延迟而改成异步事件上报后这个开销降到了1ms以内。所以调度器的观测通道必须是异步、带缓存、可降级的。7. 推理集群的容器化与编排实践K8s、GPU虚拟化与自动扩缩容7.1 每个推理实例都应该是“肉鸡”而不是“宠物”千卡集群一旦跑起来GPU实例的故障率是不可忽略的。按照统计一张H100的年故障率大概在1%到2%之间千卡规模意味着平均每隔几周就可能有一张卡出问题。这不只是硬件坏还有可能是因为CUDA驱动升级、显存ECC错误、甚至机房温度过高导致的降频。所以架构上必须把每个推理实例做成无状态、可替换的。模型放在共享存储如Lustre、MinIO、S3兼容存储上每个Pod启动时拉取模型文件到本地NVMe加载到显存向注册中心上报健康状态然后对外服务。一旦显存OOM或者健康检查失败K8s自动杀掉Pod拉起一个新Pod。我见过最惨痛的教训是有人把模型直接打包进容器镜像模型14GB镜像20多GB每次滚动更新都要把所有节点重新拉一遍镜像光镜像分发就花了4个小时。正确的做法是用镜像只承载推理引擎和依赖库模型走独立的存储和缓存层。7.2 GPU共享与时间片切分千卡集群的“资源碎片”处理千卡集群最常见的问题是资源碎片化。比如某张卡显存80GB模型只需要40GB剩下40GB因为没部署另一个实例就浪费了。要解决碎片化主流有三种方案MIGMulti-Instance GPU、vGPU虚拟化、或者干脆用时间片共享。MIG是NVIDIA官方的硬隔离方案可以把一张H100切成多个实例。但MIG有个硬伤实例之间不共享显存带宽而且显存容量被硬性划分后可能不够放模型。我实际用下来MIG适合切出“小模型推理单元”这类场景对大模型推理的碎片化治理帮助不大。vGPU虚拟化则是用软件层把显存和算力做逻辑切分灵活性高但要额外付授权费而且有大约5%到10%的性能损耗。我自己在这个问题上的经验是尽量让每个GPU实例的显存需求与物理显存容量对齐。一个70B模型如果FP8量化是70GB那我就不硬塞进80GB单卡的实例里宁可少开并发也不强行并行切分。因为大模型推理对显存的访问频率极高任何虚拟化层带来的带宽损失都会被放大。7.3 自动扩缩容的正确姿势慢启动和预热池千卡集群的HPA配置第一原则是“预留时间”。从HPA触发到Pod变成Ready过程是这样的调度新Pod可能要等待GPU资源、拉取镜像、下载模型到本地缓存、加载模型到显存、编译CUDA Kernel、注册到服务发现——这一整套下来70B模型大概需要3到5分钟。而业务尖峰往往几十秒内就会涌进来。如果等HPA指标触发才扩容早就被压垮了。所以我的落地经验是维护一个预热池集群里始终有20%到30%的Pod已经完成模型加载处于待命状态。它们的CPU占用很低但显存已经被占据。当负载上升时调度器直接把请求切过去同时再通过HPA补建新Pod到预热池里。这个机制看起来是浪费了一部分显存但在千卡规模下它换来的稳定性远超省下的那点资源。K8s层面还有两个细节。一是要用nodeSelector或gpuType标签把不同型号的GPU分开调度别让A100和H100混跑在同一个服务下否则慢卡拖慢快卡。二是要配置PodDisruptionBudget防止集群升级时把所有副本同时杀掉。千卡集群的维护操作永远遵循“逐个节点滚动”的铁律。8. 推理过程全链路追踪与可观测性建设8.1 从“黑盒”到“白盒”关键指标到底看哪些千卡推理集群排障如果没有可观测性基本是瞎子摸象。我维护了一个统一的可观测性平台核心有四个层面的数据模型层指标TTFT首token延迟、TPOT每token生成时间、吞吐tokens/s、QPS。实例层指标GPU利用率、显存占用关键看KV Cache使用率、GPU温度、功耗、NVLink带宽。网络层指标IB/RoCE端口丢包率、重传率、ECN标记率、拥塞队列深度。调度器指标每个实例的队列深度、调度决策耗时、预热池剩余容量。这四层数据串起来能构成一条完整的请求链路。比如用户反馈“回答变慢了”你不能只看到整体P99涨了还得定位到是哪一层导致的——是路由层把请求发给了重负载实例还是网络拥塞导致KV Cache传输慢还是GPU降频了我的排障习惯是先看实例层再看网络层最后看调度器。实例层直接反映算力是否吃紧网络层往往容易被忽略但千卡集群的大多数莫名其妙的问题都出在网络上调度器指标则能暴露负载均衡策略本身的缺陷。8.2 链路追踪的落地方式推理请求的链路追踪比普通Web请求复杂得多因为一个请求会被多个GPU实例分段处理。业界常用的做法是给每个请求分配一个request_id在接入层注入然后每个处理节点都上报带有request_id的Span数据最后汇聚到Jaeger或SkyWalking。关键是要把Span的字段设计好请求输入长度、输出长度、模型路径、使用的TP组、KV Cache传输大小、各阶段耗时。有了这些数据你才能回答“为什么这个请求慢”的根源性问题。我在实践中还会加一个字段preempted标记这个请求是否被抢占过——因为vLLM在做显存不足时的抢占调度时会暂停部分请求这个事件如果不记录你会看到莫名其妙的TPOT尖刺。提示日志采集要避免同步阻塞。千卡集群每秒会产生海量日志一定要用异步队列缓冲比如Kafka或Loki的Promtail否则日志系统本身会成为性能瓶颈。9. 常见问题与故障排查实录千卡集群的典型翻车现场9.1 负载全都压在少数几张卡上现象集群里某些GPU利用率90%以上另一些不到20%整体QPS却上不去。 排查步骤第一看路由调度器的决策日志确认请求是不是被算法均匀分发第二看实例的健康状态上报确认是不是部分实例因为延迟高被动“降权”第三检查请求特征是不是长请求总是哈希到同一组实例。这个问题的根因往往出在一致性哈希的key设计上。如果你用用户ID做哈希某些大客户的长请求会集中打在同一组实例上。修正方案是把哈希key从“用户ID”改成“请求输入长度的分段随机数”让每个请求的调度权重与算力消耗挂钩。另外调度器的实例权重更新周期不能太长我建议把500ms的同步拉取改成事件驱动的异步推送让负载信号更灵敏。9.2 显存OOM千卡集群的“死亡重启”现象某张卡的vLLM实例突然OOMK8s将其重启然后同组的其他实例QPS瞬时上涨引发连锁OOM。 根因分析KV Cache的预估与实际偏差过大或者某个请求的输出长度远超预期把预留的缓冲显存打穿了。解决思路有三个层面。第一层在引擎参数上设置--max-num-seqs把单实例并发上限卡死宁可让请求排队也不让显存崩掉。第二层在网关层加“请求长度预检”超过阈值的请求直接拒绝或路由到专为大请求准备的实例组。第三层部署监控告警当KV Cache使用率达到85%时提前告警而不是等OOM才反应过来。9.3 网络拥塞导致全集群性能雪崩现象某次压测中所有实例的decode速度同时掉到正常值的一半GPU利用率却不高。 排查过程一看实例指标GPU利用率确实没打满再看网络指标RoCE端口ECN标记率超过5%PFC触发次数飙升。这就是典型的RoCE网络拥塞——某个Leaf交换机下的流量突发引发了全局的流控风暴。治本的办法是调整网络拓扑和流控策略开启ECN和自适应路由合理设置PFC阈值同时把大流量任务PD分离的KV Cache传输分散到不同Leaf下。如果条件允许在RoCE网络里给推理集群单独划分一个无损域避免和其他业务的流量互相干扰。9.4 冷启动太慢救不了突发流量现象日常流量平稳突然来一波营销活动流量HPA开始扩容但70B模型每个新Pod要5分钟才能Ready等Pod起来活动流量已经过去了。 解决维持预热池而且要把预热池的大小做成动态的。我常用的做法是绑定一个“预测式扩缩容”的定时任务根据历史流量曲线在预期高峰到来前20分钟提前扩容高峰过后再逐步回收。K8s的HPA只对“已经发生”的负载敏感而预测式扩缩容能对“即将发生”的负载做预判两者配合才能应对真实的生产高峰。9.5 一张速查表这些坑我帮你踩过了问题常见根因推荐解法单实例QPS上不去TP维度过大导致通信瓶颈根据模型体量优先DP扩展TP够用即可TTFT偏高prefill和decode混跑互相抢占引入PD分离或限制单实例并发长尾延迟严重个别实例负载不均调度器引入算力感知加权缩短上报周期显存频繁OOMKV Cache预留不足或请求过长设置max-num-seqs网关预检请求长度集群整体吞吐低网络拥塞触发PFC开启ECN、自适应路由优化拓扑扩容来不及模型加载时间过长维护预热池 预测式扩缩容10. 千卡集群的落地节奏与成本治理思路架构设计讲完最后说说实施路径。千卡集群不是一天建成的我的建议是分四步走。第一步单机验证阶段。先用一台8卡服务器把模型服务跑起来完成功能验证和基准压测拿到单机QPS、TTFT、显存占用的基线数据。这个阶段最重要的是把“单卡/单机能力边界”摸透否则后面所有容量规划都是空中楼阁。第二步小集群试运行阶段。用32到64张卡搭建一个小规模集群验证网络通信、调度器、负载均衡的可用性。这个阶段要特别关注跨机通信的稳定性和调度器的决策质量再把监控告警体系搭建完整。第三步规模扩展阶段。从小规模到千卡核心不是买卡而是反复压测找出瓶颈逐个击破。每加一批机器都要重新跑一遍全链路压测确认性能按预期线性扩展。第四步成本治理阶段。千卡集群的电力成本和采购成本都是天文数字优化空间也最大。比如FP8量化、KV Cache量化、动态批处理、SDN流量调度、空闲时回收GPU实例每一环都能省下可观的费用。很多团队在千卡规模下实际GPU利用率只有40%到50%如果能通过架构优化把它拉到70%以上相当于白拿了几百张卡的算力。我个人在实际操作中最大的体会是千卡集群的架构设计拼的不是某一项技术有多新而是每一项基础工作是否做到位——网络拓扑是否合理、调度器是否感知负载、实例是否可快速替换、监控是否覆盖全链路。这些听起来很朴素但在压力测试面前任何一个环节偷懒都会以非常难堪的方式暴露出来。最后再分享一个细节技巧千卡集群上线前一定先做一次“混沌演练”——随机拔掉一张卡的网线随机杀掉几个Pod再随机注入一次网络丢包。看着监控大屏上系统自己恢复稳定你才会对这套架构真正有信心。