企业官网建设流程全解析

很多开始接触大模型的朋友，第一步是盯着显卡数显存，第二步是研究模型权重去哪下载。但我见过太多人在这两条路上走得很顺，最后却在"网络"上吃了暗亏：多机训练速度上不去、推理接口延迟高到没法用、集群一跑起来就报超时错误。这篇文章想带零基础的朋友弄明白一件事：大模型是怎么通过网络基础设施跑起来的，以及当你自己动手部署、训练、上线服务时，网络这块到底要关注什么。

先说结论：大模型不是"买几张显卡插上就能跑"这么简单。它本质上是典型的高性能计算任务，而高性能计算拼的从来不只是芯片，还有把成千上万块芯片连成一个整体的网络。显卡再快，如果数据送不过来，整个集群的实际效率都会断崖式下跌。我会从三个层面帮你拆开看：为什么大模型离不开网络、网络基础设施里到底有哪些组件、以及不同场景下你应该怎么选型、怎么排查问题。无论你是打算本地跑个开源模型玩一玩，还是团队要上推理服务，甚至准备搭一个小型训练集群，这篇文章都能给你一张清楚的地图。

1. 为什么大模型离不开口袋里的"网络"

1.1 先理解大模型天然是"分布式"的

不管是训练还是部署一个真正能用的模型，单张显卡几乎都不可能独立完成。以常见的 7B 参数模型为例，FP16 精度下光权重就有大约 14GB，勉强塞进一张 24GB 的消费级显卡。可到了 70B、上百B 的模型，单卡显存完全装不下，更别说训练时还要额外存放梯度、优化器状态和中间激活值。

既然一张卡放不下，就得把模型拆开，放到多张卡甚至多台服务器上同时算。这个过程叫分布式训练或分布式推理。问题也随之而来：多个计算单元各算各的之后，必须不断同步中间结果。训练时每算一步，所有 GPU 都要把各自的梯度汇总起来，取个平均值再更新参数，这一步通信叫做 AllReduce。模型越大、参与计算的卡越多，通信量就越恐怖。

你可以把它想象成一个几百人的施工队盖同一栋楼。每个小组手里只有一小块图纸，不能闷头干，必须每隔几分钟就对一次进度、交换一次材料。这个"对表"的频率越高、参与的小组越多，通信系统的压力就越大。没有一套强力的通信网络，几百个小组就会互相等待，整体进度还不如十个人慢慢干。

这也是为什么大模型和网络基础设施天然绑定在一起。模型参数量决定了你要用多少张卡，卡的规模决定了你必须在多快的网络上才能把效率喂饱。

1.2 训练、微调、推理对网络的需求完全不一样

很多初学者把"训练"和"推理"混为一谈，但两者对网络的诉求差别非常大。预训练属于极端吃带宽的场景，每一步迭代都要做全量梯度同步，模型越大、并行度越高，通信占整个训练时间的比例就越夸张。你要是用千兆以太网去拉二三十张卡做预训练，大概率 GPU 利用率不到 30%，时间全耗在等数据同步上。

微调的情况分两种。用 LoRA 这类参数高效微调方法时，真正被更新的参数很少，通信量比全量预训练低一个数量级，很多人甚至可以在单机上跑完。但如果你做的是全参微调，本质上跟小规模预训练没区别，网络需求一样高，该花在高速网络上的钱一分都省不下来。

推理则更看重"低延迟"而不是"绝对带宽"。用户在网页上问一句话，你的系统要在几百毫秒内返回答案。这时候网络链路里的每一跳、每一次跨机转发都会叠加延迟。多卡并行推理时，模型层被切到不同 GPU 上，算完一层要立刻把结果传给下一层所在的卡，这个张量并行的通信是同步阻塞的，网络慢了，响应时间直接肉眼可见地变长。

不过要注意，如果你只是本地部署一个小模型自己玩，比如用 ollama 跑 7B 或 14B 的模型，单机单卡就能搞定，跨机网络基本不是瓶颈。真正的网络压力是从"多机协同"那一刻才开始的。

2. 大模型网络基础设施的核心组件拆解

2.1 从机房到 GPU：一次完整的数据流动

要理解网络基础设施，先得搞清楚一条数据是怎么从存储盘跑到 GPU 显存里完成计算，再返回给用户的。我用一次模型训练来举例。

训练数据一般存在集中式存储里，比如分布式文件系统或对象存储。训练开始前，数据要经过存储网络传输到计算节点的内存，再通过服务器内部的 PCIe 总线写入 GPU 显存。GPU 开始算，算完的梯度通过显存、PCIe 传递到网卡，再由 RDMA 网络跨服务器传输到其他节点，汇总后再传回来。整个链路里有三段网络：存储网络负责喂数据，服务器内部总线负责把数据搬进显存，服务器间网络负责跨机通信。任何一环慢了，都会拖累全局。

很多初学者以为只要显卡够强就行，其实不然。我给一个朋友排过问题，他四张 A100 训练速度奇慢，查到最后是存储网络用的千兆，数据根本喂不进去。换到 25G 存储网络后，训练时间直接砍了一半。记住一个原则：在大规模训练系统里，所有环节都必须按照"峰值吞吐"来设计，任何一个低速瓶颈都会像饮水管上的一个细口子，把整条管道的流量限制住。

2.2 服务器内部也有"微型网络"：PCIe 与 NVLink

服务器内部的互连是最容易被忽略的部分。GPU 和 CPU 之间默认走 PCIe 总线，但普通 PCIe 4.0 x16 的理论带宽也就 32GB/s，而且它还是共享的，多块 GPU 同时读写就会争抢。做大规模并行训练时，GPU 之间要频繁交换数据，如果全走 PCIe，很快就会被卡死。

所以 NVIDIA 在高性能计算卡上引入了 NVLink 和 NVSwitch。NVLink 是一条 GPU 到 GPU 的高速直连通道，带宽远超 PCIe。8 张 A100 通过 NVSwitch 组成全互联拓扑之后，任意两张卡之间都能以极高的带宽直接通信，而不用绕道 CPU 或者 PCIe 总线。你可以把 NVLink 理解成服务器内部专门给 GPU 修的"高铁专线"，PCIe 则是普通公路。

这里有个现实问题：如果你只是单机四卡做推理或微调，NVLink 的有无和拓扑会直接影响性能。双卡 4090 的 NVLink 桥接器带宽有限，相比之下 A100/H100 的 NVSwitch 方案强得多。在选购设备或者租云主机时，别只看显存大小，一定问清楚卡间互连方式。

2.3 服务器之间的"高速公路"：RDMA、IB 与 RoCEv2

跨服务器通信才是大模型网络里真正精彩的部分。早期数据中心内部通信靠 TCP/IP 协议，但对大模型来说它有两个硬伤：一是协议栈处理要占用大量 CPU 资源，收发数据时 CPU 忙着打包拆包，没法专心做计算；二是延迟偏高，链路一旦拥堵，重传机制会雪上加霜。

于是 RDMA 技术成了高性能计算的事实标准。RDMA 的核心思路是让网卡绕过操作系统内核，直接从网卡内存读写另一台机器的内存，CPU 几乎不参与数据传输。用大白话说，传统 TCP 就像寄快递，每个包裹都要经过揽收、分拣、运输、派送多道人工环节；RDMA 则是两台机器内存之间开了条专线，数据直接点对点倒过去，不走中间环节。

RDMA 的落地有两种主流方案。InfiniBand（IB）是专用网络，从网卡、交换机到线缆全部专用设计，性能最好、最稳定，但价格也最贵。RoCEv2 则是把 RDMA 跑在普通以太网上，硬件成本低得多，但需要网络设备支持无损以太网特性，比如 PFC 流控和 ECN 显式拥塞通知，配置起来有不少门道。简单说，IB 是花钱买省心，RoCEv2 是省钱花心思。

在网卡速率上，40G/100G 已经是入门级，200G 是主流训练集群的标配，400G 正在快速普及。选择思路很简单：通信量越大，网卡速率要求越高。哪怕你现在只有两台服务器做实验，我也建议至少上 100G 的 RDMA 网卡，否则以后扩机器时还得全部返工。

2.4 数据中心网络拓扑：为什么 Spine-Leaf 成了标配

有了高速网卡还不够，一堆服务器之间怎么连接同样是门学问。传统的园区网络是三层架构，流量先汇聚再上核心，适合"员工访问服务器"这种南北向流量。但大模型训练主要是服务器与服务器之间的东西向流量，流量大且突发性强，传统架构里上层交换机很容易成为瓶颈。

现在主流数据中心普遍采用 Spine-Leaf（脊叶）两层架构。Leaf 交换机接服务器，Spine 交换机负责把不同 Leaf 连接起来，任意两台服务器之间最多经过一台 Leaf 加一台 Spine，路径短、延迟可控，而且扩容非常方便：加服务器就加 Leaf，加 Leaf 就加 Spine。

用公司组织架构来类比的话，传统三层像是所有部门汇报都要先到总监，再汇总到副总，最后到总经理，层级多、效率低。Spine-Leaf 则像扁平化组织，每个项目经理都能直接找到对接人，横向协作极其顺畅。大模型训练是典型的高并发横向协作场景，所以网络架构也得跟着扁平化。

3. 从零基础视角，读懂大模型部署对网络的要求

3.1 个人本地部署：网络其实没那么难

如果你只是用 ollama 这类工具在本地跑模型，恭喜你，网络这块基本不需要操心。ollama 已经把部署流程简化成了下载安装、拉取模型、本地启动三步。我自己经常在 4090 上跑 7B 和 14B 模型做测试，推理速度几十 token 每秒，瓶颈完全在显卡算力，网络参与感几乎为零。

但有两个细节还是值得提一下。第一，模型文件动辄几十 GB，首次下载非常依赖带宽。我见过有人用默认源拉 70B 模型，结果一等就是大半天。解决办法是先确认源的连通性，或者找一台带宽好的机器把模型文件下好，再通过 U 盘或局域网直接拷贝。第二，ollama 启动后会监听本机的 11434 端口，如果你想在局域网内另一台电脑上调用这个推理服务，需要把地址从 127.0.0.1 改成 0.0.0.0。这种情况下网络就开始参与系统了，但走的还是普通 TCP，只要不跨公网，千兆局域网完全够用。

个人场景下，真正容易踩的坑反而是服务器内部环境而不是跨机网络。比如驱动没装好导致 NVLink 不工作，比如 BIOS 里没打开大页内存导致性能下降。这些属于系统调优问题，跟网络基础设施关系不大。

3.2 团队级推理服务：先算好吞吐再谈网络

当你的模型要面向多个用户提供在线服务时，情况就复杂了。用户请求从公网进来，先经过域名解析、负载均衡、API 网关，再转发到推理节点，最后返回结果。这个链路中每一环都有网络参与。

我建议团队在上线前先做一个粗算：假设你有 100 个并发用户，每个请求平均返回 500 token，那你一秒钟要输出多少 token？如果要求 1000 token/s 的吞吐，显卡推理能力是否能跟上，出口带宽是否够用？很多小团队只盯着显卡，结果用户一多，带宽先被撑爆，接口超时率直线上升。

服务端网络选型上，一般建议用 Nginx 或云负载均衡做流量入口，后面挂多个推理实例。推理引擎上，vLLM 这类工具自带 continuous batching 机制，可以显著提高吞吐，但多实例之间如果要做缓存共享或负载均衡，同样需要内网通信。实测下来，团队级部署最常被忽视的是内网带宽。多台推理节点之间如果走千兆，而模型比较大需要分片加载，那加载一次权重就得等半天，线上变更一次版本非常痛苦。

3.3 多机多卡训练与推理：真正的网络压力测试

当单台服务器塞不下模型，或者你想加快训练速度时，就必须跨机。以 70B 模型推理为例，FP16 权重约 140GB，理论需要两块 80GB 显存，但实际加载 KV Cache、中间激活值之后，起码要四到八张卡。一张 8 卡 A100/H100 的服务器能塞下，可要是更大规模的模型，比如 175B 甚至更高，单机放不下，就得拆到多台服务器上。

这时候张量并行会带来频繁的跨机通信。模型每一层的计算都被切分到不同 GPU 上，层与层之间必须同步传输激活值和梯度。我实测过一个 13B 模型用 4 台双卡机器做张量并行推理，跨机通信如果走千兆，生成速度慢到无法接受；换成 100G RDMA 之后，速度提升了近十倍。网络瞬间从配角变成了主角。

训练场景更不用说了。DeepSpeed、Megatron-LM 这类框架做多机训练时，数据并行、流水线并行、张量并行叠加在一起，通信模式极其复杂。跨机带宽不足时，显存的利用率再高，整体训练速度也上不去。判断网络是否拖后腿最简单的方法，是在训练时同时看 GPU 利用率和网卡吞吐。如果 GPU 利用率波动大、网卡一直打满，那瓶颈就在网络。

4. 网络基础设施怎么选：给零基础的一份落地清单

4.1 先分清场景再谈配置

很多朋友上来就问"我该买 IB 还是 RoCEv2？该上 100G 还是 200G？"这类问题脱离场景毫无意义。我习惯把网络选型分成三档。

个人学习场景，单机甚至双机就够，跨机网络不重要，重点把显卡和 NVLink 搞清楚。小团队做推理服务，两三台 4 卡或 8 卡服务器加一台负载均衡，内网建议至少 25G 起步，有条件直接上 100G。正式训练集群，8 卡节点起步，节点间至少 100G，强烈建议直接规划 RoCEv2 或 IB，存储网络也要同步升级，否则数据喂不进去。

这里要说一个很现实的判断标准：菜量决定锅的大小。你做的模型多大、训练多频繁、用户量多少，直接决定了网络这套"锅"要买多大。别看着别人上 400G 就眼红，大部分团队连 100G 的三成带宽都用不满。

4.2 成本和性能的平衡：IB 还是 RoCEv2

这是网络选型里绕不开的争论。IB 的优势是稳定、开箱即用，生态对 RDMA 支持最好，缺点就是贵。一套 IB 交换机加网卡的价格往往是以太网方案的两到三倍。RoCEv2 的优势是能跑在现有以太网设备上，成本低很多，缺点是调优门槛高，PFC、ECN、缓存水位这些参数配不好，性能会大幅下降甚至频繁丢包。

以我自己经验来看，如果你只是搭两三台机器做实验，RoCEv2 完全够用，性价比极高。但如果是二三十台以上的正式训练集群，我倾向于推荐 IB，尤其是团队里没有专职网络工程师的情况下。IB 的高价其实是在买一份"确定性"，让你可以把精力集中在模型本身而不是网络调优上。

带宽选型方面，建议不要盲目追高。40G 是比较老的起点，新部署建议直接 100G，200G 看预算，400G 一般只有大规模训练集群才真正需要。网卡速率上去之后，交换机、线缆、光模块都要配套升级，整体成本算下来差别很大。

4.3 云平台与自建机房怎么选

对零基础的朋友来说，我的建议非常明确：优先用云平台，尤其是云厂商提供的高性能计算实例。云平台最大的优势是免运维，RDMA 网络在租用 HPC 集群时已经帮你调好了，你只需要按需购买算力，用完释放，不需要操心交换机配置、布线、散热这些琐事。而且现在主流云厂商都提供多机 RDMA 集群，可以按小时租，对学习和中小团队非常友好。

自建机房适合哪些人？数据敏感、长期大规模训练、业务稳定且对成本有明确预期。但自建意味着你要自己搞定机房、电力、散热、网络设备、运维人员，投入非常大。我在一个创业团队里见过他们为了"数据不出门"硬着头皮自建，结果运维成本远超预期，最后还是迁回了云。说句实在话，除非你的团队已经到几十人规模，否则不建议一上来就自建。

用云时要注意一个细节：普通云服务器默认走的是共享网络，多租户环境下性能抖动很厉害。要跑多机训练，一定要选带 RDMA 的高性能计算实例，并且让所有节点放在同一集群内，否则跨集群通信会走公网或低速链路，性能惨不忍睹。

5. 实际操作中常见的网络问题排查

5.1 训练时"卡住不动"：先查显卡还是先查网络

分布式训练常见的故障是"跑着跑着突然不动了"，很多人第一反应是看显存、看驱动，其实很多时候问题在网络。我建议按顺序排查。

先跑nvidia-smi看 GPU 利用率和显存占用。如果利用率在 0 和 100 之间反复横跳，说明 GPU 在等待数据，这时候八成是通信卡住了。再看网卡状态，IB 卡用ibstatus，以太网卡用ethtool，确认链路是否 up、速率是否正常。然后用iperf3在节点间打流测试带宽，判断物理链路是否达标。

如果怀疑是 NCCL 本身的通信问题，训练日志里通常会有NCCL timeout之类的报错。这时候可以去查两台机器之间的连通性，ping只能确认通不通，真正要看的是延迟和丢包。mtr这类工具能显示每一跳的路由质量，能帮你定位是哪一段链路出了问题。

5.2 推理延迟高：是模型问题还是网络问题

线上推理服务变慢，往往模型和网络都有嫌疑。我用一个简单方法拆解：用curl -w查看请求各阶段的耗时分布，重点看 TCP 连接时间和首字节时间。如果 TCP 连接时间都很长，那问题在网络链路或负载均衡；如果连接很快但首字节很久才返回，那瓶颈大概率在模型推理本身。

拿到耗时数据后，还可以进一步确认：直接 SSH 到推理节点本地执行一次请求，如果本地响应很快而远程很慢，那问题基本出在网络链路或网关层。如果本地也慢，那就老老实实优化模型推理吧。

针对网络链路本身，ping测的是 ICMP 延迟，只能做初步参考。真正要看的是 TCP 延迟和丢包率，可以用tcpping或iperf3的双向测试。跨地域部署时，延迟会明显升高，这种属于物理极限，只能通过把服务部署到离用户更近的地方解决。

5.3 千兆局域网传输模型文件的真实耗时

很多人对千兆以太网有误解，觉得"千兆"很快。其实千兆网卡的理论速率是 1000Mbps，换算下来约 125MB/s，实际传输还要扣除协议开销，通常只能跑到 110MB/s 左右。

假设你要在服务器之间传一个 20GB 的模型权重文件，用千兆网传大约需要 3 分钟。听起来不慢，但如果你每次训练都要加载权重、每隔一段时间同步一次检查点，这 3 分钟就会反复出现，累积起来非常可观。更别提如果模型到了 100GB 以上，一次传输就是 15 分钟起步。

我的建议是：多机场景下，模型文件分发优先用rsync增量同步或直接放到共享存储里，避免每台机器各自从公网拉取。内部传输尽量走高速内网，实在不行也要保证存储节点和计算节点在同一网络域内，避免跨公网传输。

5.4 RoCE 网络丢包、抖动的坑

最后专门说一下 RoCE 网络最常见的坑：丢包。对传统 TCP 来说，千分之一的丢包率可能感知不明显，但 RDMA 不一样。RoCE 依赖无损网络，交换机一旦丢包，网卡会触发重传，重传风暴会迅速放大问题，最后导致训练任务挂起。

我踩过一次很深的坑：四台机器用 RoCEv2 连训练，跑一会儿就卡死，查了很久发现是交换机缓存太小，突发流量一来就丢包。后来换了一台带更大缓存的交换机，问题彻底消失。这里的关键点是：RoCE 网络必须开启 PFC 流控和 ECN 拥塞标记，而且交换机的 buffer 要够大，否则再高的网卡速率也是白搭。

零基础朋友如果要对 RoCE 排障，建议先看几个指标：网卡丢包计数、PFC 暂停帧计数、ECN 标记计数。任何一个数值持续增长，都说明网络在亚健康状态。如果没有专职网络工程师，我的建议很简单：优先选 IB，或者直接买云上已经调好的 RDMA 集群。

我在实际项目里最大的体会是：大模型这套东西，显卡决定性能上限，网络决定性能下限。上限高但下限低，最终跑出来的效果一样很难看。对零基础的朋友，我的建议很简单，先别急着上高大上的方案。先用单机本地部署跑通一个小模型，感受一下整个流程；再尝试单机多卡，理解并行计算和卡间通信；最后再上多机，这时候你自然会明白网络基础设施的价值。每一步的亲身体验，都比看十篇理论文章有用得多。