企业官网建设流程全解析

2026年开春，AI圈子里讨论最密集的一个词变了：不再是“又买了几千张卡”，而是“AI Infra”。这词听起来像基础设施玩家的黑话，但你只要真正跑过千卡训练或者在线上部署过大模型服务，就会明白它有多关键。AI Infra 的内核不是堆卡，而是让卡真正转起来的那一层：AI 原生网络、存储、调度、LLM Serving。尤其是 AI 原生网络和企业级 LLM Serving，这两块正成为拉开团队差距的分水岭。这篇文章我就围绕这两个方向，把我最近半年在真实项目中踩过的坑、验证过的方案、梳理出的判断标准一次性讲透。适合正在做大模型训练或推理基础设施的工程团队，也适合那些刚准备从单机实验走向集群部署的算法工程师参考。

1. AI Infra 全景：为什么“拼网络”比“堆卡”更决定下限

1.1 AI Infra 到底包含什么

AI Infra 这个概念外延很大，但如果从工作负载视角拆开，核心就四块：算力池、存储池、网络池、服务化层。算力池是 GPU 集群本身，存储池承担数据集、模型权重和 checkpoint 的读写，网络池负责把这堆计算资源连接成一个整体，而服务化层则把训练好的模型封装成稳定、高吞吐、低延迟的在线服务。很多人一上来就盯着算力池看，实际上后三者的配置水平，决定了集群在真实业务中的表现下限。

我见过一个很典型的案例：某个团队采购了同等规格的 GPU，A 队用默认配置直接开跑，B 队花了一周时间专门调网络和 serving 参数，结果在同样的训练任务上，B 队有效吞吐高出 A 队 30% 以上。这不是个别硬件差异，而是网络拥塞控制、数据加载管线、Serving 框架参数的综合结果。AI Infra 的价值不是让某一块硬件跑满，而是让所有环节的损耗降到最低。

这四块之间的关系有点像城市的交通系统：算力池就是各个功能片区，存储池是仓库和物流中心，网络池是道路与立交桥，服务化层是面向市民的办事窗口。道路设计不合理，片区再繁华也堵成一锅粥；窗口服务跟不上，再宽的马路也转化不成好体验。2026 年，分布式训练动辄千卡万卡，推理集群同时服务成百上千路并发请求，网络和服务化已经不是配菜，而是主菜。

1.2 AI 原生网络到底“原生”在哪

“AI 原生网络”这个词听起来像营销概念，但背后有实打实的技术内涵。传统企业网络处理的是南北向流量为主、偶发东西向流量的 Web 业务，特征是“尽力而为”：丢包了 TCP 重传就好，延迟偶发波动用户感知不明显。AI 负载则完全不同，分布式训练里，每个 step 都需要 GPU 之间做全局梯度同步，这涉及密集的 all-to-all 通信，任何一次丢包或拥塞都被无限放大：要么拖慢集合通信，要么直接触发超时导致训练中断。

AI 原生网络要解决的核心矛盾就是“无损、低时延、高吞吐”三者兼得。具体来说，它需要具备几个特征：一是无损传输，通过 RoCEv2 配合 PFC/ECN 机制避免丢包；二是确定性低时延，不能像传统网络那样频繁出现毫秒级抖动；三是故障感知与快速切换，交换机端口或者光模块出问题时，能快速重路由而不是让整个训练 job 挂掉；四是要与上层的调度器、通信库联动，比如拓扑感知调度，让通信量大的 job 尽量落在同一网络交换域内。

用一个生活类比来解释：传统网络像普通城市道路，车多了就堵，堵了就等，没有谁为某辆货车担保时间；AI 原生网络则更像专用的高速公路加智能红绿灯系统，为每一次通信预留带宽、控制拥塞，并且当某条车道出事故时，自动引导车流绕行而不让我们察觉。这种“原生”不是换一台更高端的交换机就能得到的，需要从网卡、交换机、通信库、调度器做端到端的协同设计。

2. AI 原生网络的架构设计与关键决策

2.1 拓扑与无损网络：RoCE 不是装完就能用的

先回答一个最基础的问题：AI 集群用 InfiniBand 还是 RoCEv2？如果预算充足、团队运维能力强，InfiniBand 当然更省心，它的无损机制是原生设计的。但现实中绝大多数企业会选 RoCEv2，因为可以复用现有以太网生态，成本相对可控。只是很多人以为“换上支持 RoCE 的网卡和交换机，开启 PFC，无损网络就搞定了”，这其实是个大坑。

RoCEv2 要真正跑出性能，至少需要同时处理好 PFC 和 ECN 的关系。PFC 的作用是当接收端 buffer 快满时，给发送端发暂停帧，从物理上避免丢包，但 PFC 是逐跳流控，一旦触发范围过大，会造成线头阻塞，也就是某一条流把整个队列堵死，其他流全部跟着遭殃。ECN 则是在交换机队列深度超过阈值时，给报文打上标记，接收端感知后通过 DCQCN 协议反馈给发送端，让发送端主动降速。

我的实践结论是：ECN 为主，PFC 作为最后兜底。让 ECN 标记阈值先介入，通过主动降速避免队列打满，这样既不会丢包，也不会出现 PFC 引发的连锁阻塞。具体配置时，要给不同优先级的队列设置差异化的 buffer 阈值，建议从交换机 buffer 的 20% 到 50% 之间开始调，观察 ECN 标记率和实际吞吐再做微调。这个参数没有标准答案，取决于交换机型号、流量模型和 RDMA 网卡实现。

2.2 集合通信优化与故障域设计

网络层再稳，如果集合通信库和网络拓扑不匹配，性能也会大打折扣。分布式训练里最常用的集合通信操作是 AllReduce，它的带宽利用率取决于通信算法怎么走：环状 AllReduce 适合中小规模集群，树状和分块式 AllReduce 适合大规模集群。更关键的是，通信路径要尽量短。英伟达的 NCCL 引入了拓扑感知能力，会自动识别 GPU 之间的 NVLink 连接、跨节点经过哪台交换机，从而选择最优的通信路径。

但在真实集群里，拓扑感知并不是总能生效。我遇到过一个情况：Kubernetes 调度 GPU 任务时没有把同一训练任务的所有 Pod 放在同一个网络 Pod 内，导致 NCCL 检测出的拓扑是跨 spine 通信。虽然也能跑，但 AllReduce 带宽比优化后低了接近一半。解决办法是让调度器感知网络拓扑，尽量把同一个 job 的节点分配在同一叶交换机下，跨叶通信实在躲不开时，至少保证路径数少且均衡。

故障域设计同样重要。千卡级训练，节点故障其实是常态，关键是故障的影响半径有多大。无状态的数据加载 worker 挂了可以自动重启，但 AllReduce 过程中任何一张卡掉线，整个 job 都可能崩溃。我们现在的做法是：控制每个训练任务的计算节点数为最少必需的规模，同时在作业调度层做“故障快速换卡”，而不是等用户手动介入。此外，把模型权重定期做轻量级 checkpoint 到分布式存储，恢复时间可以控制在分钟级而不是小时级。

2.3 可观测性：从丢包计数到集群健康度

AI 原生网络最容易被忽略的是可观测性。网络设备不像 GPU，跑慢了不一定报警，丢包也不会直接体现在 GPU 利用率上，很多人发现网络问题时已经严重影响业务了。我的建议是至少要采集四类信号：RoCE 拥塞窗口（发送端主动降速的幅度）、ECN 标记率（交换机队列压力的早期预警）、PFC 暂停帧计数（无损网络是否在“兜底”）、以及端到端的通信时延和吞吐曲线。

这些数据不只是给网络工程师看的，训练平台和推理平台都应该接入。举个例子，如果检测到某个节点的 ECN 标记率持续偏高，在用户还没察觉性能下降之前，就可以提前排查是不是某条链路流量不均或某台交换机 buffer 配置过小。我们后来做了一套很简单的健康度打分：把 GPU 利用率、通信时延、丢包率、ECN 标记率加权汇总成一个 0 到 100 的分值，低于阈值就触发自动巡检。这套体系比单纯盯着 GPU 利用率有效得多。

3. 企业级 LLM Serving 的关键指标与框架选择

3.1 Serving 不是“起一个模型接口”那么简单

很多团队从单机 PyTorch 代码迁到在线服务时，最初都以为写个 FastAPI 接口把模型包一层就行。等并发一上来就发现：显存爆了、首 token 延迟涨到几秒、吞吐低得离谱。企业级 LLM Serving 需要一套完整的组件来支撑高并发和低延迟：请求网关负责流量接入和负载均衡；推理引擎负责动态批处理、显存管理、量化计算；调度层负责把不同请求分配到合适的 GPU 实例；还有指标采集和弹性伸缩系统。

其中比较核心的机制是连续批处理（continuous batching），它把每一个 token 的生成当作独立的调度单元，而不是像传统批处理那样等整个序列生成完再释放显存。这样当一个请求的 decode 阶段还在等待生成时，另一个请求的 prefill 阶段就可以插入进来填充 GPU 算力。连续批处理对吞吐的提升非常明显，但它的实现复杂度也高，不同的 Serving 框架在这里拉开差距。

3.2 核心指标与 SLO：TTFT、TPOT 与吞吐

评价一个 LLM Serving 系统好不好，不能只看“整体吞吐高不高”，要看三个关键指标。

第一个指标是 TTFT，首 token 时延。用户发出请求到看到第一个 token 生成出来的时间。这个指标决定了交互的“第一印象”，在线聊天场景下，如果 TTFT 超过 2 秒，用户明显会觉得卡顿。第二个指标是 TPOT，每 token 生成时间，也就是 decode 阶段的单 token 延迟。它决定了生成速度，体验好的服务要控制在 40ms 到 100ms 以内。第三个指标是吞吐，单位是 tokens/s，衡量整个系统每秒能生成的 token 总量，直接关联成本效率。

这三个指标是互相制约的关系。盲目提升吞吐，可能牺牲 TTFT 和 TPOT。我给一个比较实用的 SLO 设计思路：先定义在线业务容忍的 P95 TTFT 和 TPOT，然后反推单实例最大并发数，再根据总请求量规划 GPU 数量。举个例子，对于 200 路并发的客服机器人，允许 P95 TTFT 为 1.5 秒、TPOT 为 50ms，那么单张 A100 大约能支撑 20 到 30 路并发，整个集群至少需要 8 到 10 张卡才能稳得住。先定 SLO，再谈优化，否则后面所有调优都会失去方向。

3.3 Serving 框架选型对比：vLLM、TensorRT-LLM 与 SGLang

2026 年主流的开源 Serving 框架主要就几个：vLLM、TensorRT-LLM、SGLang。它们是同一类东西，但设计取向差异很大。

vLLM 最大的优势是生态成熟、上手快。它的 PagedAttention 机制把显存利用率提得很高，连续批处理实现也稳定，还支持 OpenAI 兼容接口，社区贡献了大量模型适配，基本主流的开源模型都能直接跑。适合大多数团队的默认选择。

TensorRT-LLM 强在极致延迟优化和量化支持。它由 NVIDIA 主导，对自家 GPU 的特性挖得最深，配合 FP8/INT4 量化能明显降低单 token 延迟。但代价是编译和部署流程复杂，模型需要做 engine 构建，动态形状处理也有不少坑。适合对延迟和吞吐要求极高、且愿意投入工程精力的团队。

SGLang 的杀手锏是 RadixAttention，它自动缓存请求中的公共前缀，在多轮对话、few-shot 提示词复用的场景下，可以跳过重复的 prefill 计算，大幅降低 TTFT 和显存占用。如果你的业务大量存在相似前缀，这套机制能带来意想不到的收益。

选型没有绝对最优，我的建议是：默认用 vLLM，跑通全部功能；如果量化需求重，再评估 TensorRT-LLM；如果业务前缀复用特征明显，考虑 SGLang。有时候同一集群里按业务类型混合用两个框架，也是一个务实的方案。

4. 从网络到 Serving 的协同优化：PD 分离、缓存与弹性调度

4.1 PD 分离架构与流量模型变化

传统上，LLM 推理把 prefill（处理输入并生成第一个 token）和 decode（逐 token 生成）放在同一个 GPU 上完成。这种做法实现简单，但存在天然的资源错配：prefill 是计算密集型，特别消耗算力和显存带宽；decode 是访存密集型，主要瓶颈是显存带宽和 KV cache 的读写。两者混跑时，prefill 的突发计算会拖慢 decode 期间的 token 生成，导致用户体感变差。

PD 分离就是把 prefill 和 decode 拆到不同的 GPU 实例上，这也是 2026 年大规模 LLM Serving 的主流架构。prefill 实例专门负责快速吸收请求并生成完整的 KV cache，decode 实例负责持续的 token 生成。这个架构带来的直接收益是：TTFT 更稳定，TPOT 不再被突发 prefill 干扰，调度也更灵活。但代价是网络中需要传输 KV cache 数据，从 prefill 节点迁移到 decode 节点。

这就回到网络了。KV cache 的传输量不是个小数目。粗略估算一下，8K 上下文、每层 hidden size 为 8192、40 层的模型，单个请求的 KV cache 大小在 8 × 8192 × 40 × 2（K 和 V）再乘以精度字节数，大约是 2GB 级别的数据。如果一批并发请求同时从 prefill 节点涌向 decode 节点，瞬间的流量会非常高。所以规划网络的带宽时，不能只按 token 吞吐算，要考虑 KV cache 迁移的峰值。

4.2 KV cache、前缀缓存与长上下文的工程解法

KV cache 不仅是 PD 分离的传输负担，也是显存消耗的大头。长上下文场景下，比如一次处理 128K token 的文档分析，KV cache 可能占掉数 GB 显存，直接挤占 batch size 的空间。工程上常见的解法有几个方向。

一是前缀缓存。多轮对话里，每轮请求都带有之前的历史消息，这些消息对应的 KV cache 其实是可以复用的。SGLang 的 RadixAttention 就是把共享前缀做成树状缓存，新请求只需要计算新增的那一小部分。在客服和 Agent 类场景中，前缀缓存的收益非常明显，有时能把 TTFT 降低一半以上。

二是 KV cache 分层存储。把热点请求的 KV cache 放在 GPU 内部的高带宽显存中，冷门前缀放到 CPU 内存甚至 SSD 上，配合调度器做预取。这套思路类似传统的缓存体系，但落到推理场景里需要处理显存和 CPU 内存之间的带宽瓶颈。

三是请求亲和性调度。如果调度器能把共用同一前缀的请求调度到同一个 decode 实例上，前缀缓存命中率会大幅上升。这要求网关或调度器感知每个实例上已经缓存的 KV 前缀，而不是简单做轮询或随机分发。实施起来有一定复杂度，但在高并发 Agent 场景回报很高。

4.3 弹性调度与成本控制

企业做推理服务，成本压力始终在。弹性调度的目标很简单：流量低时把算力缩下来，流量高时及时扩出去。但在 GPU 集群里，“弹性”比普通容器要难得多，因为 GPU 资源冷启动时间长，模型加载到显存需要几十秒到几分钟，缩容也不是简单删 Pod 就完事。

我的经验是两个层面同时抓。一个是预测式扩缩容：根据历史流量曲线，在晚高峰之前就把推理实例扩容好，提前预热模型；在低谷期用 CronJob 或自定义控制器把多余的实例回收，拆给训练任务。另一个是训练与推理混部时要注意隔离。训练任务里的 AllReduce 是突发的、海量的通信，推理任务里的 PD 分离流量是持续的、时延敏感的，两者必须放在不同的网络租户或 QoS 队列里，否则训练在跑数据同步时会直接把推理的尾延迟打崩。

我们做过的验证是：给推理流量单独划分一个网络切片，设置更高的优先级并限制带宽上限，即使集群同时跑着千卡训练，推理 P95 TTFT 依然稳定。这个优先级配置，在网络设备上只是几行 QoS 命令，但对业务稳定的价值巨大。

5. 常见问题与排查实录

5.1 问题速查表：现象、可能原因与检查点

5.2 实战案例：TTFT 突增不一定是 GPU 的问题

我们曾经遇到一个很典型的排障经历。线上客服机器人的 P95 TTFT 从平时的 500ms 突增到 2.5s，一开始所有人的第一反应都是 GPU 资源不够，准备临时扩容。但我打开指标看了一眼，GPU 利用率并不高，反而是请求队列的深度一直在涨。继续查，发现导致排队的原因不是算力，而是 prefill 实例处理得慢。

进一步排查发现，当时集群里还有另一个业务在做批量离线批量推理任务，把大量短小请求打到了同一组 prefill 实例上，批量离线任务的请求和线上实时请求混在一起，每个实时请求的前置排队时间被拉长了。把离线任务迁到独立实例后，TTFT 立刻恢复到正常水平。这件事给我的教训是：推理服务的问题，先看排队，再看算力，最后才看网络，排查顺序弄反了会浪费大量时间。

5.3 实战案例：ECN 标记率为什么能拖垮训练

另一个印象深刻的案例是千卡训练集群性能只有平时的 70%。所有 GPU 利用率都很高，NCCL 的 AllReduce 带宽却明显低于预期。起初怀疑是网线或光模块有问题，花了半天排查物理层一无所获。后来从交换机的 Telemetry 数据里看到，某个 spine 交换机对应端口的 ECN 标记率持续高达 8% 以上，触发 DCQCN 持续降速。

问题根源是当时批量调度了一批训练 job，多个 job 的通信流量都集中经过同一台 spine 交换机，且流量是突发的，交换机 buffer 根本兜不住。我们调整了作业调度策略，把多个大 job 分散到不同的网络域，同时调大了交换机的动态 buffer 阈值。第二天训练性能就恢复了。这类问题的教训是：网络拥塞并不总是表现为丢包，也可能是“标记后降速”，这种隐性性能杀手，必须靠 ECN 指标才能捕捉到。

我个人这两年做 AI Infra 最深的体会是：这个方向的复杂度不在单个组件，而在端到端的协同。网络、存储、调度、Serving 每一层都有大量参数，任何一个环节不匹配，都会让整个集群的表现大打折扣。建议刚开始搭建的同学，不要急着把集群规模拉得太大，先拿一个小规模集群（比如 16 到 32 卡），把 RoCE 无损参数调稳、把 Serving 的指标监控接好、把训练和推理的网络隔离做好，跑熟之后再往大规模扩展。如果你已经在大集群上踩过坑，欢迎交流各自是怎么定位和排除隐性瓶颈的。