企业官网建设流程全解析

1. 从单卡到千卡：先搞懂推理集群到底在解决什么问题

这些年做大模型推理，最常见的开场白是：“我有一个H100，跑一个70B模型，怎么QPS只有几十？”然后一问细节，显存不够用、多卡通信绕、请求一多就超时，问题全挤在一起。等真正把规模推到千卡，你会发现单卡踩过的坑，到了集群环境下全都会放大十倍百倍地还回来。

所以聊大模型推理集群架构设计，我得先给这件事定个调：这不是“把N张卡拼起来跑模型”的工程题，而是“在有限成本下，让成百上千个并发请求以最低延迟、最高吞吐拿到推理结果”的资源调度题。核心关键词就两个——大模型、千卡，中间牵引它们的分别是计算密度、网络拓扑和调度策略。

我在实际做集群规划时，通常会先把问题拆成三层：单机推理的硬件上限在哪里，多机通信的瓶颈是什么，以及负载均衡策略能不能跟模型并行方式匹配起来。这三层互为约束，脱离任何一层谈架构都是空谈。

举个直观的例子。你在单卡上做推理，H100的显存带宽是3.35TB/s左右，算力是989 TFLOPS（FP16），看起来强悍。但70B模型哪怕是FP8量化，光权重就得70GB，单卡80GB显存勉强塞得下，可KV Cache一上来，显存立刻见底。这时候你被迫开启PagedAttention之类的显存复用机制，把KV Cache按块管理，才勉强让并发数上来。等到了千卡规模，单卡的那点显存复用已经不重要了，重要的是卡与卡之间的数据搬运速度和全局调度器的眼界——因为你面对的请求已经不是几十个，而是每秒成百上千个，每个请求还可能命中不同的模型副本。

千卡集群真正的难点在于：模型参数是切开的，请求是随机到达的，显存是分布式的，任何一张卡的负载失衡都会造成整体性能塌方。负载均衡这个词，在这种场景下不是Nginx轮询那种简单的概念，而是贯穿了接入层、调度层、引擎层、通信层的系统工程。

接下来我从单卡讲起，一步步拆解到千卡负载均衡的完整架构，把我踩过的坑、调过的参、推倒重来的方案都记录下来。

2. 单卡推理的性能天花板：TCO曲线与算力收益递减规律

2.1 单卡推理的两个阶段为什么决定了架构走向

在进入集群话题前，有必要把单卡推理的真实面貌说透。大模型推理每个请求都要经历两个阶段：prefill（预填充）和decode（解码）。Prefill阶段是并行计算密集型的，一次处理用户输入的整段token，GPU利用率很高；decode阶段则是串行逐token生成的，每一步都依赖前一步的结果，GPU利用率往往只有个位数到百分之十几。

这个差异对架构设计的影响是决定性的。PreFill吃的是算力（FLOPS），decode吃的是显存带宽（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模型，TP=8时通信开销还能接受（NVLink双向带宽900GB/s），但如果跨机做TP=8，那基本是在给自己挖坑。

再看流水线并行。PP是把模型按层切成多段，每张卡负责其中一段，数据像流水线一样逐段流过。推理场景下PP用得很少，原因很直接：推理是低延迟敏感的在线服务，流水线天然会增加端到端延迟，而且PP的显存利用率不如TP灵活。除非模型大到单机8卡都塞不下（比如超过1TB的模型，像一些MOE大模型），否则我不太推荐在推理链路里引入PP。

最后是数据并行。DP最简单，就是复制多份完整模型，每份独立处理不同请求，最后通过负载均衡把请求散开。DP是推理集群最基础的扩展手段，因为它跟请求调度天然契合——每个GPU实例都是无状态的，任何一个请求可以被任意副本处理。千卡集群里绝大部分扩展能力，其实是靠DP加TP的组合打出来的：单机内部TP=4或TP=8把模型切得快一点，多机之间用DP把请求摊开。

3.2 单机8卡的最佳实践配置与显存账

拿一张真实账单来算。假设你拿到一台8卡H100服务器，要服务70B FP8模型，每张卡80GB HBM。权重占用约70GB，如果TP=8，每卡权重只有8.75GB，剩下71GB全给KV Cache和激活值。这看起来很美，但别忘了TP=8意味着每层都要跨卡通信，实际算力利用率可能只有60%左右。我实测下来，这种配置下并发数可以开到几百路，QPS能做到1000以上（前提是请求长度在1K token以内、输出长度在256 token左右）。

单机8卡的心得是：TP维度优先解决“装得下”的问题，DP维度解决“跑得快”的问题。如果你手里的模型权重量级不大（比如7B模型，单卡FP16也就14GB），那么TP=1、单卡部署，用DP横向扩展实例数，反而是最灵活、最省事的方案。因为单卡推理没有跨卡通信，请求调度的颗粒度是“一张卡一个实例”，千卡集群的负载均衡策略会简单很多。

我见过不少团队，一上来就TP=8把一个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 Batching

5.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-size：TP的卡数，决定模型怎么切，必须跟实际的GPU拓扑一致。
• --max-num-seqs：单实例最大并发序列数，这是吞吐和显存的安全阀。设大了容易OOM，设小了GPU喂不饱。我的习惯是先按每GB可用显存大约支撑32路并发（7B FP16模型经验值）估算，再用压测校正。
• --max-model-len：最大序列长度，直接影响KV Cache的预分配大小。这个值设太长，显存会被空耗；设太短，长请求直接报错。
• --gpu-memory-utilization：GPU显存用于模型加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分成两组，一组专门跑prefill（P组），一组专门跑decode（D组），中间通过高速网络传递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因为没部署另一个实例就浪费了。要解决碎片化，主流有三种方案：MIG（Multi-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实例突然OOM，K8s将其重启，然后同组的其他实例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 一张速查表：这些坑我帮你踩过了

10. 千卡集群的落地节奏与成本治理思路

架构设计讲完，最后说说实施路径。千卡集群不是一天建成的，我的建议是分四步走。

第一步，单机验证阶段。先用一台8卡服务器把模型服务跑起来，完成功能验证和基准压测，拿到单机QPS、TTFT、显存占用的基线数据。这个阶段最重要的是把“单卡/单机能力边界”摸透，否则后面所有容量规划都是空中楼阁。

第二步，小集群试运行阶段。用32到64张卡搭建一个小规模集群，验证网络通信、调度器、负载均衡的可用性。这个阶段要特别关注跨机通信的稳定性和调度器的决策质量，再把监控告警体系搭建完整。

第三步，规模扩展阶段。从小规模到千卡，核心不是买卡，而是反复压测，找出瓶颈，逐个击破。每加一批机器，都要重新跑一遍全链路压测，确认性能按预期线性扩展。

第四步，成本治理阶段。千卡集群的电力成本和采购成本都是天文数字，优化空间也最大。比如FP8量化、KV Cache量化、动态批处理、SDN流量调度、空闲时回收GPU实例，每一环都能省下可观的费用。很多团队在千卡规模下，实际GPU利用率只有40%到50%，如果能通过架构优化把它拉到70%以上，相当于白拿了几百张卡的算力。

我个人在实际操作中最大的体会是：千卡集群的架构设计，拼的不是某一项技术有多新，而是每一项基础工作是否做到位——网络拓扑是否合理、调度器是否感知负载、实例是否可快速替换、监控是否覆盖全链路。这些听起来很朴素，但在压力测试面前，任何一个环节偷懒都会以非常难堪的方式暴露出来。

最后再分享一个细节技巧：千卡集群上线前，一定先做一次“混沌演练”——随机拔掉一张卡的网线，随机杀掉几个Pod，再随机注入一次网络丢包。看着监控大屏上系统自己恢复稳定，你才会对这套架构真正有信心。