企业官网建设流程全解析

千卡集群这四个字，过去一提起来基本都跟训练绑在一起，跟“预训练”“超算”是近义词。但这次国内首个国产AI推理千卡集群落地，意味着我们把推理这条同样吃资源、更吃工程经验的路，也走到了千卡规模。我做过几年大模型推理平台建设，看到这个标题的第一反应是：好事，而且早该有人把这条路好好趟一遍。这篇内容不聊PPT，聊一聊真正落地的那些事：为什么推理集群比训练集群更考验工程能力，全栈用国产卡怎么把千卡规模稳定跑起来，以及那些只有上机跑过才会踩到的坑。

这个集群能解决什么问题，一句话可以讲清楚：当你的在线推理业务量大到单机放不下、并发高到单卡撑不住的时候，你需要一套能统一调度几百张、上千张算力卡的推理基础设施。它要保证用户请求在几十毫秒到几百毫秒内得到响应，要保证任意一张卡故障时不至于让整个平台瘫痪，还要保证几百个模型副本能共享资源、互不干扰。这篇文章适合正在建设大规模推理平台的团队参考，尤其是想在国产硬件上复现或评估类似方案的人。

1. 为什么是千卡推理集群，而不是继续堆单卡

1.1 单卡到千卡：不是算力的叠加，是系统复杂度的跃迁

单卡推理大家都熟：一个7B模型，一张主流加速卡就能跑，QPS几百，首token延迟几十毫秒，随便写个Python服务就能服务好。再往上走一点，模型超过单卡显存，用张量并行切到两张卡、四张卡，也能对付。几十卡的规模时，很多团队的做法是各部门自己圈资源，你跑你的、我跑我的，互不干扰。

但到了千卡，事情完全变了。我们不是在跑同一个模型，而是在运营一个资源池：池子里有多个模型、多个副本，请求先经过网关，再进队列，由调度器决定放到哪几个副本上，推理引擎内部还要做连续批处理、Prefix Cache复用，最后流式吐回结果。整套链路里的每一步都是一层排队，每一层排队都可能成为抖动源。这就像一个小饭馆和中央厨房的区别：小饭馆的掌勺能记住每桌菜，千卡集群是几百个订单一起来，厨工、灶台、配菜、配送全流水线化，复杂度不在炒菜本身，而在怎么保证订单不互相等、不串味。

所以千卡推理首先不是算力问题，是系统问题。单卡跑得好，不代表四卡接起来跑得好；四卡跑得好，不代表四百卡接起来还能稳定。在千卡规模下，稳定性、可观测性、容错能力这些“软指标”会取代峰值性能，成为第一矛盾。这也是我想强调的第一个观点：如果你只是在单卡或几卡上做推理优化，那你还没有真正进入千卡集群的世界。

1.2 国产方案走到推理这条赛道的底层逻辑

在训练领域，国产加速卡的生态短板是客观存在的。训练任务的特点是通信密集、算子不固定、框架占比高，需要反复调试集合通信库和算子库，这些沉淀需要时间。但推理不一样，推理的算子相对固定，计算图在模型导出后基本不再变化，这意味着很多优化可以在“编译期”完成。算子融合、量化、图优化，这些手段可以把硬件差异尽量屏蔽掉；再加上vLLM、SGLang这一层推理引擎本身就把很多硬件适配做了抽象，国产卡接入时可以复用大量现成逻辑。

所以国内首个千卡集群落在推理而不是训练，我并不意外。推理任务对生态缺失的容忍度更高，落地节奏更快，且在线业务的价值立竿见影。这不是能力不足才去选推理，是工程策略上先啃相对好啃的骨头，先把大规模可用这件事证明了，再回头补训练的短板。我们团队当时的判断也是这样：先让国产卡在推理场景里大规模跑起来，把集群调度、故障处理、性能调优这些通用能力沉淀下来，这套东西放在训练上同样能复用大部分。

2. 千卡推理集群的架构拆解与组件选型

2.1 集群拓扑：在线推理的流量模型和训练完全不一样

做训练集群的人习惯性会把网络做到极致，因为训练时AllReduce通信极其频繁，动辄几个Tbps的带宽瞬间打满，通信模式固定、可预测，网络规划的核心是“峰值带宽够不够”。但推理集群不是这个逻辑。

推理的流量模型是混合的。用户请求从入口进来，走的是控制面和路由层，流量不大但对延迟敏感；请求分配到某个副本后，如果模型做了张量并行，那么一次前向计算会在组内产生通信，组内几张卡要不断同步中间结果；而如果请求命中了Prefix Cache，可能只需要读显存，完全不需要通信。所以推理集群的网络不仅要大带宽，更要低时延和稳定：一次跨节点张量并行的通信，一跳就可能增加几十微秒，P99长尾会被拉长。

拓扑上我建议不要沿用传统三层大汇聚，尽量做Spine-Leaf两层，节点之间走ECMP均衡。更关键的一个实践是：尽量让同一个张量并行组落在同一台机器内。以八卡机为例，TP=8的模型就在一台机器内完成卡间通信，走NVLink或等效的高速互连，根本不经过网络；跨机的只有数据并行维度的流量和部分调度流量。这样网络压力比训练集群小一个量级，稳定性却高很多。我们当时128卡阶段就是这么做的，四机八卡，一个TP=8的组正好落在一台机器里，整集群跑得很稳；到千卡规模后，这个原则依然成立。

2.2 推理引擎适配与调度器选择

推理引擎这块，业界主流基本是三选一：vLLM生态最广、文档最多，出问题好查；SGLang的RadixAttention对前缀复用做得更极致，适合多轮对话和few-shot场景；Triton Inference Server更偏生产封装，适合做多模型管理。我们在国产卡上考察下来，vLLM的适配层相对最成熟，厂商提供的补丁和示例也最全，所以主线选了vLLM，SGLang作为对照测试，Triton留作特殊场景备用。

调度器层面，K8s基本是标准答案，没有太多悬念。Device Plugin负责把加速卡资源上报成可分配资源，K8s原生调度器就能把Pod调度到有卡的节点。到千卡规模后，原生调度器不够用了，需要用Scheduler Framework写插件，或者换成支持拓扑感知的调度器，让同一模型的副本尽量落在网络距离近的节点上，同时考虑反亲和，避免所有副本堆在同一台物理机——否则一台机器断电，整个模型就挂了。

这里有一条很重要的经验：千万不要用裸机脚本去管理千卡集群。有人觉得K8s太重、或有学习成本，想用Ansible加脚本把模型进程拉到各个机器上。开始几十张卡也许能撑，到千张卡时，“哪张卡在跑哪个模型”“哪张卡挂了影响哪些副本”这种问题会直接让运维崩溃。K8s的声明式管理、标签、污点容忍、滚动发布这些能力，在千卡规模下不是可选，是必需。

2.3 KV Cache与显存池：千卡推理的隐形瓶颈

很多人规划集群时只算模型权重占多少显存，这是最大的误区。推理时KV Cache才是显存消费的大头。所谓KV Cache，就是模型生成每个token时，需要把历史的Key和Value缓存下来，避免重复计算。多轮对话越长、并发请求越多，KV Cache占的显存越大，经常能占到单卡显存的30%到60%。

举个例子感受一下：一个7B模型，FP16权重约14GB；如果一张卡有80GB显存，扣掉权重和运行时开销，可能剩下约48GB给KV Cache。单token的KV大小视模型层数和头数而定，粗略按2KB到几KB算，这48GB大概能容纳几十万token的缓存。听起来很多，但一个高并发场景下几十个请求同时跑，每个请求又有几千token的上下文，很快就能吃掉一大半。

所以KV Cache管理直接决定集群能扛多少并发。PagedAttention已经是标配，它把KV Cache切成固定大小的块，按需分配，避免显存碎片；Prefix Cache更进一步，如果多个请求共享同一段前缀，比如系统提示词一样，就可以复用同一块缓存，命中时用户几乎感觉不到延迟。千卡规模下，显存池化这件事容易被低估：多个模型副本共享同一张卡时，没有统一显存池的话，碎片率可达20%到30%；引入显存池统一管理后，吞吐能提升10%以上。我们在容量规划时永远先算KV Cache，再倒推需要多少卡，这个顺序不能反。

3. 从零搭起国产推理千卡集群的完整操作路径

3.1 六步落地：从一条裸卡到千卡集群

第一步是单卡验证。别一上来就铺集群，先拿一张国产卡，装好厂商驱动和加速库，跑一个标准模型，确认推理引擎能正常起来、结果正确性没问题。这一步的重点是记录基线：单卡的吞吐、延迟、功耗、温度。后面所有集群指标都要跟这个基线对比，一旦发现集群跑得还不如单卡，说明协同开销出了问题。

第二步是多卡通信压测。使用集合通信测试工具测AllReduce和AllGather的带宽与时延，跟理论峰值对比。比如单机八卡，如果AllReduce带宽利用率低于70%，大概率是PCIe拓扑、NUMA亲和或驱动配置有问题。这一步很磨人，但必须做扎实，因为千卡集群的物理网络质量完全取决于这一步测试的认真程度。

第三步是容器镜像打包。把厂商运行库、推理引擎、模型配置、启动脚本全部锁定版本，打进镜像。这里我吃过亏：最初图方便，直接把环境装在物理机上，结果因为驱动版本不一致，换节点后行为完全不同。容器化的另一个好处是可以配合K8s做滚动更新，新版本镜像先灰度一个副本，没问题再全量推。

第四步是K8s集群与Device Plugin部署。配置厂商设备资源名，比如某厂商的资源名是厂商名字加卡型号，然后写一个测试Pod验证它能请求到指定数量的加速卡。这个阶段别急着上生产，先跑一遍完整的Pod生命周期：调度、分配、启动、销毁、再调度。

第五步是模型切分与加载。根据单卡显存和模型体积决定张量并行度，设置好权重加载路径，确认推理引擎能正确加载切分后的模型。如果同时部署LoRA，还要验证多LoRA的切换和显存占用。

第六步是全链路压测与灰度。先用离线脚本压一个TP组，再扩大到整个集群。重点指标是TTFT（首token延迟）、TPOT（每个输出token的延迟）、吞吐和错误率。灰度时先接入5%的线上流量，观察监控无异常，再逐步放量到100%。

3.2 三个最容易忽略又致命的参数

排在最前面的是推理引擎的并发参数，比如max_num_seqs和max_num_batched_tokens。这两个参数一个控制最多同时处理多少请求，一个控制一次前向最多处理多少token。设小了浪费并发能力，设大了可能瞬间把显存打爆。我的经验是拿压测结果画一条曲线，找到吞吐与延迟的拐点，而不是拍脑袋填一个值。

第二个容易忽略的是张量并行度。很多人的直觉是TP越大越好，其实不是。TP确实是卡间通信最密集的模式，TP=8比TP=4的吞吐通常有提升，但跨节点TP会让延迟变得很难看。更合理的原则是：单卡显存放得下权重时优先不做TP，必须做时，首选单机内的TP=8，尽量不跨机。算TP度有个简单公式：模型权重大小除以单卡可用显存，向上取整到2的幂，再验证KV Cache余量够不够。

第三个是锁页内存（Pinned Memory）配置。推理引擎的输入输出传输通常需要锁页内存作为中转，默认值经常被低估。现象是：卡利用率看着不低，但吞吐就是上不去，CPU反而一直有异常占用。我们在一个早期版本里把这个值从默认的1GB调到8GB后，吞吐直接提升了快15%。这种参数文档里不会醒目标注，只能靠实测发现。

3.3 监控告警：没有实时指标就没法运维

千卡集群不建监控体系等于裸奔。我把监控分成四层：硬件层、运行层、引擎层、业务层。硬件层用DCGM采集每张卡的温度、功耗、显存ECC错误、PCIe链路速率；运行层看容器CPU、内存、网络；引擎层看vLLM或SGLang暴露的指标，比如gpu_cache_usage_perc、request_queue、tokens_per_second；业务层才是一线用户感知的TTFT、TPOT、错误码。

技术栈没有悬念：Prometheus加Grafana，用DCGM Exporter做硬件采集，引擎指标通过Prometheus接口暴露出来。下面是一个我们当时监控面板里比较关键的行，供参考：

告警阈值切忌照抄别人的，每个业务响应时间要求不同。我们最初把P95 TTFT阈值设为1秒，后来业务方说首字超过800毫秒用户就走，被迫改成500毫秒。监控只是第一步，日志也要集中收集并保留至少七天，每次发布前把镜像哈希、模型版本、参数配置记录下来，出了问题才能快速定位是哪个变更引起的。

4. 千卡集群运维中的典型问题与排查方法

4.1 单卡故障如何拖垮整个集群

千卡集群上最典型的故障，不是整卡烧毁，而是一张卡“亚健康”。比如某张卡的HBM出现UE错误，ECC报错后驱动可能自动降低频率或者重试，表面上看卡还在工作，但速度已经慢了一半。如果这张卡恰好在一个TP组里，那就是灾难：因为张量并行是同步阻塞的，整个组都要等这张慢卡算完，P99延迟飙升。

我们遇到过一次：某个模型实例所有请求的P95 TTFT突然翻了三倍，监控看整机利用率不高，最后定位到是TP组里一张卡反复出现ECC错误，驱动在做内存重映射。排查过程是大海捞针，因为单看整机指标都正常。后来我们把DCGM的ECC计数器单独加了告警，一有增量就自动隔离节点，调度器再把这个模型的其他副本调度到健康节点上，问题才算根治。

架构上能做的规避也很明确：健康检查加自动驱逐，让坏卡节点的Pod自动迁移；同时配置分片拓扑，让同一TP组尽量落在一台机器，扩大故障域；再配合反亲和策略让同一模型的副本分散在不同物理机，避免一台物理机宕机导致模型全军覆没。

4.2 通信抖动与集群拥塞的排查

另一个高发问题是通信抖动。现象是偶发性超时，推理引擎日志里出现集体通信超时，重试后又能恢复正常。这种问题在训练集群很常见，推理集群也不少见，因为跨节点TP组里的一个请求在一次前向过程中就会发起多次集合通信，高并发时消息总量并不小。

我们遇到过一次典型拥塞：某段时间接近整点，大批量离线任务启动，瞬间把网络打满，在线推理请求的延迟立刻飙升。排查过程很直接——看网卡丢包计数和重传率，发现核心交换机在高峰时段buffer丢弃明显增加。解决办法是把在线推理和离线任务的网络做了QoS分级，给在线流量留出专用队列；同时降低跨节点TP的比例，把原本TP=16跨两台的配置改回TP=8单机内完成，网络敏感度立刻下降。

这里还踩过一个小坑：NCCL（以及国产卡的对应集合通信库）默认会尝试自动检测网络拓扑，某些加速特性在大规模下反而会引入不稳定。遇到反复抖动时，尝试关闭部分自动优化，比如固定通信路径，或者关掉某些加速开关，很多时候能换来稳定。

4.3 推理稳定性与精度异常的速查表

千卡集群上出问题不像单机那样容易复现，很多是概率性的。我把我们遇到过的问题整理成了一张速查表，排查时先对现象再查原因，效率会高很多：

这张表挂在团队wiki上，新来的同事遇到类似问题先查表，能省掉大量重复排查的时间。

5. 写在最后的几点体会

千卡集群的难点从来不在“上线那一刻”，而在“跑三个月之后还能不能稳住”。我们第一次做连续压测时，前三天一切正常，第四天开始有个别卡性能衰减，查到最后是机房散热策略导致局部温度偏高，卡的降频策略被触发了。所以长稳测试不是可选项，而是必选项，最好在真实负载下跑满一周以上。

另外强烈建议把故障注入演练纳入日常。定期人为杀掉一个Pod、隔离一张卡、模拟一次网络抖动，看整个集群能不能自动恢复。第一次做的时候你会发现很多意外：调度器可能把副本重新排到同一台机器上，某个模型的请求可能因为没有可调度副本而全部超时。这些都要在演练中暴露，而不是等线上故障时再痛苦。

最后分享一个我们每次做容量评估都在用的公式，简单但有效：预期QPS乘以平均输出token数，再乘以单token的KV Cache大小，得到KV Cache总需求；然后根据每卡可用于KV Cache的显存，倒推出需要的卡数。这里再一并考虑权重占用的显存、并行度带来的开销，以及20%到30%的容量冗余。这个公式帮我们在多次扩容中避免了拍脑袋决策。

国产推理千卡集群这条路上，可参考的公开经验确实不多，很多坑只能自己踩。希望这篇内容能让你少走一些弯路，也欢迎在实践中遇到相似问题的朋友多交流。