大模型网络基础设施：从RDMA到CLOS架构的部署实践指南

1. 为什么说大模型的“体力”藏在网络里先搞清楚这堂课到底在讲什么我接触大模型这两三年有个非常直观的感受很多人把精力全砸在模型权重、训练代码、Prompt 调优上结果一到实际部署就露馅——要么多卡训练根本跑不动要么本地推理慢得像PPT翻页要么云端调用动不动超时。问题出在哪儿十次有八次出在网络基础设施上。这里说的网络基础设施不是家里那个 Wi-Fi 路由器而是承载大模型训练和推理任务的那一整张“通信大网”包括数据中心内部的交换机、网卡、通信协议也包括你本地部署时单机内的总线通信、多机之间的互联方式以及云上调用时的接入层设计。很多人一听“网络”就头大觉得那是运维工程师的事儿但今天这篇文章就是要把这件事掰开揉碎用最通俗的类比讲清楚让零基础的朋友也能看懂大模型为什么“离不开网络”、网络到底在哪些环节卡脖子、以及你自己动手实操时该怎么考虑网络问题。适合谁来读三类人最合适想入门大模型、但被各种“分布式训练”“推理加速”术语劝退的新手用 Ollama、vLLM 等工具做过本地部署、却总搞不懂“为什么换张网卡速度快了一截”的实践派以及准备在企业里做大模型应用落地、需要在方案里拍板网络选型的工程师。我要强调一个核心观点大模型的算力本质上是一个被网络“编织”起来的集体算力。没有一张匹配得上的网络GPU 再多也是各干各的跑不出理想效果。理解了这条主线后面所有技术细节都顺了。2. 从“人海战术”到“群体智能”为什么数百张GPU必须被编进同一张网好几年前做深度学习单张显卡就能搞定不少任务。为什么到了大模型时代单卡突然就不够用了因为大模型的参数量动辄几十亿、几百亿甚至上千亿。就算你有最顶级的 H100一张卡 80GB 显存也装不下一个 1750 亿参数的完整模型。更不要说训练阶段还需要同时保存梯度、优化器状态、中间激活值显存需求直接翻好几倍。于是大家想出了两条路模型并行和数据并行。模型并行就是把一个模型切成几块分别放在不同 GPU 上大家一起干活拼成一个完整模型数据并行则是每张卡都放一份完整模型但各自处理不同批次的数据再定期同步梯度。无论是哪种并行都离不开一件事搬数据。模型切在两张卡上前向传播算完第一层要把中间结果送到第二张卡上算第二层数据并行训练每算完一个 batch所有卡要把各自的梯度汇总起来求完平均再分发回去。这些“搬数据”的动作就是网络通信。通信越慢GPU 等待的时间就越长利用率就越低。我打个比方。一个人写一份 100 万字的报告能力再强也得写到天荒地老叫 100 个人来写每人分一万字看似可行但如果这 100 个人不坐在一起、没有通畅的对讲系统A 写的那一章必须等 B 写的前一章才能动笔那这个“协作”就变成了互相等待的灾难。大模型训练里的网络就是这 100 个人之间的“对讲系统”。系统好大家能无缝衔接效率无限接近 100 个人同时开写系统差大部分时间都耗在“等传话”上人再多也白搭。这也是业界为什么如此看重网络性能的根本原因。大模型的里程碑式进展从来不是“显卡变快了”这么简单而是**“显卡数量和网络带宽同时跟上了”**。你可以把算力理解成一支军队的战斗力GPU 是士兵网络是补给线和指挥链路。士兵再能打指挥链路断了、补给送不上照样溃败。2.1 一张 GPU 卡里的“隐形网络”单机内部也不能忽略总线聊网络很多人的第一反应是“网线、交换机”但在大模型的世界里网络概念的起点其实更近——就在一台服务器内部。一台 8 卡 GPU 服务器8 张卡之间的数据交换走的是 PCIe 总线或 NVLink 互联。NVLink 是英伟达搞的一种高速直连技术可以让同机内的 GPU 以极低延迟、极高带宽互相访问显存数据。这张卡能直接读另一张卡的数据读写速度可以达到每秒几百 GB 到上 TB。为什么单机内通信要在意因为大模型并行训练时最频繁的通信就发生在同一台机器的多张卡之间。假设你用一个 7B 参数的模型做数据并行训练每张卡上都有完整参数每轮同步梯度时7B 参数如果以 FP16 精度存储差不多 14GB 数据要在卡间传一遍。如果走 PCIe 3.0 x16单向带宽大概 16GB/s传一次就要接近 1 秒如果走 NVLink带宽翻几倍甚至十几倍时间立刻缩短到几百毫秒甚至更短。别小看这几百毫秒的差距训练一个模型要迭代成千上万次累积下来就是几小时甚至几天的差距。我之前帮朋友排查一台训练服务器的性能问题现象是 8 卡利用率始终只有 50%每跑几十秒就卡顿一下。查到最后发现是主板上 PCIe 通道分配不对两张卡被降到了 x4 速率卡间通信带宽直接掉了四分之三。这种问题不看网络相关的硬件拓扑光调软件永远发现不了。2.2 单机不够用跨节点通信才是“真正的网络工程”单机最多装 8 到 10 张 GPU再往上就得把多台服务器连起来组成集群。千亿级参数的模型往往需要几十台甚至上百台服务器协同工作。这时候通信就不再限于机箱内部而要跨越服务器、跨越机柜走真正的“网络链路”。跨节点通信的难点在于服务器之间的物理距离变远了信号要走更长的线缆、经过更多层的交换机延迟更高带宽也更容易成为瓶颈。如果把单机内的 NVLink 比作办公室里隔着工位喊一嗓子就能沟通那么跨节点通信就像两个不同城市的分公司之间打电话——信号要经过中继、转接总是慢半拍。为了把“慢半拍”降到最低行业的思路是“用专门的硬件和协议把数据搬得尽可能快”。这就是接下来要讲的数据中心内部网络。3. 训练中心的“高速公路网”数据中心内部怎么互联、用了什么协议走进一个现代大模型训练数据中心的机房你看到的场景和传统机房已经有了显著区别。一排排 GPU 服务器机柜旁边你会看到大批量的光模块、高速网线还有占据不小空间的交换机机柜。这些交换机并不是可有可无的“插线板”它们是整个集群的神经中枢。3.1 两层/三层网络拓扑CLOS 架构为什么成为事实标准传统数据中心常用一种“核心层—汇聚层—接入层”的三层树形结构。这种结构好理解但有个致命问题越往上走带宽越容易拥塞。就好比一个城市的道路系统支路很多但所有车都汇聚到几条主干道上早晚高峰必堵。现代大模型训练集群普遍改用CLOS 架构也叫 leaf-spine 架构叶脊架构。它把所有交换机分成两层底下是大量 leaf 交换机叶交换机直接连着服务器上面是一组 spine 交换机脊交换机只负责把不同 leaf 之间连起来。任何两台服务器之间的通信经过的跳数都是固定的——最多从 leaf 到 spine再到另一个 leaf。CLOS 架构的好处是带宽可以“横向扩展”。服务器多了就多加 leaf流量大了就多加 spine。东西向流量服务器之间的流量有了多条等价路径通过负载均衡算法分摊。对大模型训练这种“一台机器和所有其他机器都要频繁通信”的场景CLOS 几乎是最佳解。我做技术方案时判断一个数据中心网络设计是否合格第一个就看它是否采用了 leaf-spine 架构。如果还是传统三层组网基本可以直接判定这不是为高性能分布式训练准备的。3.2 InfiniBand 与 RoCEv2两条主赛道怎么选确定了拓扑还要选“路面材质”。目前主流的两种技术路线是InfiniBandIB和RoCEv2RDMA over Converged Ethernet version 2。InfiniBand 是一种专门为高性能计算设计的网络技术硬件和协议都是为“低延迟、高带宽、低丢包”量身定制的。它的交换机芯片、网卡到协议栈全链路都是为了一个目标服务——把数据以最低延迟送到目的地。可以说InfiniBand 就是为“较真”而生的代价是贵而且生态相对封闭。RoCEv2 走的是普通以太网的基础设施但在协议层实现了类似 InfiniBand 的 RDMA 能力也就是网卡可以直接读写远端服务器的内存数据不需要 CPU 参与一次次拷贝。成本比 IB 低不少而且能复用现有的以太网运维经验所以这两年越来越多的大模型训练集群开始用 RoCEv2。我个人的经验是如果是超大规模集群、追求极致性能、预算充足InfiniBand 依然是稳妥选择如果预算有限、规模中等RoCEv2 配合好的网卡和交换机性能也能做到非常接近 IB。别被“RDMA必须上IB”的迷思困住那是老黄历了。3.3 RDMA 到底突破在哪理解“内核旁路”就理解了一半说到 RDMA很多新手听得云里雾里。我用最朴实的话拆一遍。传统网络通信数据从网卡收进来要先经过操作系统内核内核再把它拷贝给应用程序。这个流程安全、通用但慢——因为数据被复制了好几遍每次拷贝都消耗 CPU 和内存带宽。RDMA 的“魔法”在于它允许应用程序的数据绕过操作系统内核直接从网卡搬到应用内存里反过来发送方应用的数据也可以直接从内存发给网卡。数据不需要反复拷贝CPU 也几乎不用参与传输过程。这就好比以前的信件要从总邮局层层分拣、转发现在邮递员直接把信塞到你手里中间站点全部跳过。在大模型训练中通信量巨大且频繁CPU 本来就要忙着计算、调度网络这一块如果能“自己搞定”对整体性能的帮助极其明显。这也是为什么我们常说“RDMA 是大模型训练网络基础设施的灵魂”。4. 推理侧的“服务网络”从网关到负载均衡Token 是怎么送到你手上的训练再快最终要落地还得靠推理。推理就是用户输入一句话模型生成一段回答的过程。这个过程对网络的要求和训练截然不同——训练追求“吞吐量”和“带宽”推理则更看重“延迟”和“稳定性”。我在做部署时最常遇到的困惑是模型明明很强为什么线上跑起来用户体验那么差回答这个问题得先拆解一次推理请求的网络旅程。4.1 一条 Prompt 的网络冒险从用户到 GPU 再到用户假设你打开一个聊天应用输入“帮我写一份季度总结”**第一跳你的设备到应用服务器。**走的是公网涉及 DNS 解析、TLS 握手、HTTP 请求传输。这一步延迟通常在几十到几百毫秒。**第二跳应用服务器到推理服务集群。**应用服务器拿到请求后要做一系列预处理比如检查是否登录、是否触发安全策略、拼接系统提示词然后转发给后端的推理服务。这一步通常发生在数据中心内部或同一云厂商的内网延迟较低但在高并发下可能出现排队。**第三跳推理服务内部。**这是最复杂的一层。推理服务要把请求分配给某个 GPU。分配逻辑有很多种最简单的轮询也有考虑当前 GPU 显存剩余、排队长度的智能负载均衡。第四跳GPU 计算 流式返回。模型开始逐字生成回复。注意大模型是“一个字一个字”生成的每生成一个字都要做一次前向推理。为了让用户不用等全部生成完才看到内容推理服务普遍采用流式传输SSE把生成好的部分边生成边推送给用户。一个资深工程师不会只看平均延迟更要看“首Token延迟”从发出请求到收到第一个字的耗时和“Token吞吐率”每秒能生成多少个字。这两个指标直接决定用户体验而它们背后的关键瓶颈之一恰恰是网络链路中每一跳的延迟。4.2 网关层到底做了什么为什么需要“排队”和“限流”很多人以为“网关无非是个反向代理”。但在大模型推理场景网关的职责远不止转发。最典型的是排队控制。推理服务不像 Web 服务那样可以无限水平扩展——GPU 资源是稀缺的一个 7B 模型在单张消费级显卡上可能每秒只能生成 20 到 50 个 Token。如果同时来 100 个请求总不能全部灌给 GPU 让它“亲嘴打嘟”于是网关要维护一个队列合理分配算力。然后是负载均衡。一个推理集群可能有多台 GPU 服务器有的卡闲着有的卡忙成狗。网关要实时感知每台服务器的资源状况把新请求分发给最空闲的那个。如果你自己搭建过 vLLM就会知道它内部对每个模型的并发度有精确控制网关选错目标请求就会排队到超时。最后是超时和重试策略。大模型推理耗时天然比普通 API 长一个长文本生成可能要几十秒远超普通接口的超时阈值。如果网关套用的是传统 HTTP 服务的超时配置比如 5 秒用户大概率只能看到“请求超时”。正确的做法是针对推理接口单独设计超时策略并且用流式响应告诉客户端“我还在生成别急”。4.3 KV Cache 与连续批处理如果不懂它们就对不起“网络”这笔账推理阶段还有一个非常影响网络/内存调度的机制KV Cache。大模型生成新 Token 时需要参考前面已经生成的内容。但如果每次都把整段历史重新算一遍计算量会爆炸。于是业界引入 KV Cache把已经算好的“上文状态”缓存起来生成下一个 Token 时直接查询缓存。K 和 V 分别代表注意力机制里的 Key 和 Value 向量。KV Cache 存在内存里一个长对话的 KV Cache 可能占据几百 MB 甚至几个 GB 显存。这直接影响了推理集群的调度策略——一台 GPU 能同时服务多少个用户往往不是看模型大小而是看 KV Cache 吃了多少显存。网络传输设计也要配套优化KV Cache 在集群内迁移、共享都要消耗带宽。有些新架构比如某些 MoE 模型的 expert 并行推理还需要在不同 GPU 之间实时交换中间状态网络的地位又回到和训练同等重要的位置。5. 自己动手部署时网络问题怎么算一张表带你做容量规划前面聊了不少理论现在讲点特别实际的如果你自己要部署大模型——可能是本地试玩、局域网内提供服务、或者在公司内部做 PoC——你该怎么估算网络需求我根据几百次部署经验整理了一张简化版规划表适合零基础参考部署场景模型规模关键网络瓶颈推荐最低配建议单机本地 Ollama 试玩7B-14B量化显卡显存、内存带宽无需特殊网络关注后端内存通道别放在机械硬盘上单机多卡推理张量并行70B 以上PCIe、NVLink至少 PCIe 4.0 x16跨卡通信频率极高注意主板拓扑小型局域网多机部署多模型、多人用万兆以太网10GbE 网卡交换机普通千兆网会严重拖累吞吐云上多节点推理集群大规模生产内网带宽、网关调度云厂商高性能计算实例关注跨可用区的费用和延迟公网对外提供服务任意规模公网带宽、CDN、TLS按峰值带宽预留 2-3 倍buffer流式接口务必压测长连接稳定性这张表看着简单但里面每一条都是踩过坑的。举个例子我见过有人在公司内网用一台普通服务器部署了 70B 模型的量化版同事反馈特别卡。我一看环境网卡是千兆交换机是老式百兆模型虽然装下了但每次请求加载 context 都要从磁盘经网线传几 GB 数据。问题根本不在模型计算而在网络传输。5.1 算一笔带宽账在线推理时到底会跑多少流量很多新手对“网络带宽”没有概念不知道 7B 模型一次请求会消耗多少流量。一个 7B 模型如果按 FP16 精度存储模型权重大约 14GB。推理时如果模型已经加载在显存里输入输出本身的数据量并不大——一个 1000 Token 的输入按每 Token 约 1KB 算也就 1MB 左右。真正吃流量的是“模型文件本身的分发”。如果你用 Ollama 在本地跑模型文件是一次性下载到本地的之后推理不再消耗模型文件的网络流量。但如果你的场景是“每次请求都把模型从共享存储拉过来”那就完全不同了——14GB 的模型文件走万兆网络也要 14 秒每次请求都这么拉体验必然崩溃。所以我的经验是推理服务部署时模型文件永远要本地化放在 GPU 服务器的本地 SSD 上或者至少挂在 NVMe 存储上。千万别搞“所有服务器共享一个 NFS跑模型时远程读权重”的方案。有人觉得省事实则是给自己挖坑。训练场景的带宽算法更粗暴模型越大、并行度越高、数据并行副本越多通信量就越大。简单估算公式可以粗略记为每轮同步的通信量 ≈ 模型参数大小 × 数据并行度。7B 参数的模型4 路数据并行每轮通信约 56GB。如果网络带宽只有 10GbE约 1.25GB/s那么每轮光通信就要 45 秒。这个数字会直接告诉你这里的配置不合格。5.2 延迟的真相为什么“带宽够大”不等于“不卡”带宽和延迟是网络的两个不同维度但很多人把二者混为一谈。带宽决定“能传多少”延迟决定“传得有多快开始、多快到达”。类比成快递带宽是高速公路上能并行跑多少辆车延迟是每辆车从发货地到收件地要花多少时间。大模型推理对延迟极其敏感因为每一步都需要拿到上一步的结果才能继续。在分布式推理比如张量并行中模型的不同部分分散在不同 GPU 上每一层的前向传播都要跨卡同步一次结果。如果卡间通信延迟是 1 毫秒而模型有 80 层那就意味着仅仅数据同步的额外开销就接近 80 毫秒再加上计算本身的时间生成一个 Token 可能就要几百毫秒。用户感受到的“一个字一个字蹦出来”多半就是这样来的。这也解释了为什么 NVLink 那么重要——它不只是带宽高延迟也更低。普通以太网即使上了 RDMA延迟依然比 NVLink 高一个数量级。所以业内有个说法能塞进一台机器的模型就尽量别拆成多台服务器。跨节点带来的不只是带宽下降还有延迟放大。6. 本地部署的几个“反常识”细节不是所有慢都怪显卡这一节我给所有在本地折腾过 Ollama 或 vLLM 的朋友分享几个亲测有效的排查经验。很多“卡”的问题根子在网络面。**第一件怪事模型在 PCIe 3.0 的老机器上推理速度远低于预期。**如果你只有一张显卡按理说推理数据不经过网络、只在显卡内部跑PCIe 影响应该不大。但我实测发现某些场景下影响极其明显——特别是处理超长上下文时模型输入 Token 数量巨大每次预填充prefill阶段都要把大量输入数据从 CPU 内存搬到 GPU 显存。PCIe 3.0 x16 的带宽约 16GB/sPCIe 4.0 x16 是 32GB/sPCIe 5.0 x16 是 64GB/s。输入数据一旦上 GB 级别PCIe 3.0 直接成为瓶颈。所以如果你的场景是“一次性喂给模型几万字”检查一下主板 PCIe 版本和插槽速率别只盯着显卡型号。**第二件怪事同一台机器用 Wi-Fi 远程访问比有线网络慢一半。**本地部署 Ollama 后很多人喜欢在笔记本上通过局域网远程访问。笔记本走 Wi-Fi 5 还是 Wi-Fi 6、信号强度多少会直接影响流式输出的体验。因为流式接口是长连接持续占用带宽Wi-Fi 信号不稳定时TCP 会自动降低发送窗口导致“字是一个一个挤出来”的错觉。解决办法很简单固定 IP 有线连接或至少让设备靠近路由器别让大模型替你背锅。**第三件怪事模型不是越大越好量化精度对显存和通信压力影响指数级。**以 70B 模型为例FP16 精度需要约 140GB 显存四张 4090 才能勉强塞下如果改成 4-bit 量化只需要约 35GB单张卡就能跑。量化不只是降低显存占用还减少了模型分发时的网络压力。多卡部署时量化模型因为权重更小KV Cache 也更小通信量能降低一半以上。所以看到别人“单卡跑 70B”的帖子第一反应不应该是“什么神仙显卡”而该是“他做了多狠的量化”。7. 训练集群的网络拓扑怎么理解从“八字还没一撇”到“看得懂拓扑图”最后聊一个进阶话题当你要接触真正的训练集群时怎么看懂一张网络拓扑图。别被满屏的交换机名字吓到。网络拓扑图的核心信息就四条这个集群有多少台 GPU 服务器每台服务器上几张卡服务器接入到哪个 leaf 交换机leaf 交换机之间通过哪些 spine 互联带宽多少拿一张常见拓扑举例一个 128 台 8 卡服务器的集群总共 1024 张 GPU。每台服务器配一张 400Gb/s 的网卡其实通常多张接入两台 leaf 交换机做冗余。32 台 leaf 交换机往上分别连接到 8 台 spine 交换机。每台 leaf 和每台 spine 之间都有一条 400Gb/s 链路这样任意两台 leaf 之间的理论最大带宽就是 8 × 400Gb/s。我的经验是你不需要记住每一个端口速率但要会看“收敛比”——也就是所有下行带宽总和与上行带宽总和的比值。如果下行每台 leaf 接了 16 台服务器 × 400Gb/s 6.4Tb/s上行只有 8 条 400Gb/s × 本来就稀疏的 spine 3.2Tb/s收敛比就是 2:1意味着发生全互联通信时流量最终会被压缩一半。大模型训练集群追求的是收敛比 1:1最好做到无阻塞。之所以强调这个是因为很多二手方案、供应商报价都会在拓扑图上做文章。学会看图你才能在做技术评审时一眼看出“这个方案到了真正训练负载下会不会堵车”。7.1 从一张故障排查记录看网络对训练的影响我再放一个真实案例帮你把前面所有知识串起来。某次训练任务现象是 loss 曲线平稳但训练速度只有预期的 60%GPU 利用率周期性掉到 20%。排查链路是这样的先用nvidia-smi看显卡功耗和利用率发现利用率呈现“锯齿状”每几分钟掉一次。看训练日志发现每个 step 里通信耗时占比超过 40%明显异常。用ibstatusInfiniBand 场景检查网卡速率发现多张卡的链路速率从 400Gb/s 降到了 100Gb/s。查交换机端口日志发现大量 CRC 错误和链路误码导致网卡自动协商降速。最终定位是某批光模块质量问题信号衰减严重换掉之后恢复满速训练速度立刻回到预期。这个案例告诉我们网络问题很多时候不是“带宽不够”而是“物理链路劣化”。光模块、网线、交换机端口任何一个环节信号质量下降都会触发降速或重传。大模型训练对网络质量极其敏感常规的“能 Ping 通就行”思维在这里完全不适用。7.2 云上部署把网络账单看懂省下的都是利润如果你用的是云厂商的 GPU 服务网络成本往往是一笔隐性支出。云上网络主要分三类公网带宽、内网带宽、跨可用区/跨地域流量费用。公网带宽就是你对外提供服务时用户访问的带宽按带宽峰值计费价格相对固定。内网带宽是指同地域不同实例之间的通信很多云厂商默认给一定额度但高性能模式要额外购买。最贵的是跨地域流量——比如你的 GPU 实例在广州API 网关在北京每次请求都要跨地域绕一圈流量按 GB 计价积少成多能吃掉一大块成本。我的建议是云上做大模型推理尽量做到“单地域闭环部署”模型服务、网关、应用服务器全部放在同一个地域甚至同一个可用区。宁可多花一点内网带宽的钱也不要让请求“出省”。跨地域传输一次长文生成可能达到几十 MB量一大账单会很吓人。8. 最后几个必须记牢的“常识”新手最容易犯的网络部署错误这一板块我直接上干货把那些我用真金白银换来的教训写成清单供大家避坑。**错误一模型文件放机械硬盘或远端共享存储推理时现场加载。**无论是 Ollama 还是 vLLM加载模型本质上是把权重文件读入显存。机械硬盘顺序读速度普遍不到 200MB/s一个 4GB 的模型要 20 秒以上SSD 能到 500MB/s-3GB/sNVMe SSD 更高。这还只是加载一次的代价。远端共享存储就更可怕加载一次 14GB 模型可能耗时几分钟。如果模型文件必须放共享存储请务必确保后端至少有万兆网络 足够高的 IOPS。**错误二信奉“千兆网够用了”。**对 Web 应用千兆网常常真的够用但对大模型推理和训练千兆网连入门门槛都没到。哪怕只是两台 4090 服务器组个小集群跑张量并行千兆网约 100MB/s传个激活值就要卡半天。至少上万兆网卡和交换机预算够可以上 25GbE。**错误三不做压力测试就上线。**我见过太多项目Demo 阶段很流畅一上生产就崩。原因就是没做过并发压力测试网关、网络带宽、GPU 显存任何一个环节超载都会表现为响应时间暴增。建议用压测工具比如 Locust、wrk模拟 10 个、50 个、100 个并发请求观察首 Token 延迟和吞吐量变化找到系统的拐点。**错误四分不清“我的网络瓶颈”和“模型本身慢”。**很多人在本地跑 70B 模型生成一个字要几秒就急着换更好的网卡。其实这是模型本身的计算量问题——消费级显卡的算力就那么多网络再好也改变不了每 Token 的生成速度。你应该先看 GPU 利用率如果利用率已经接近 100%问题在算力如果利用率只有 30% 且断断续续才轮到排查网络和存储。**错误五忽视路由器/交换机的 NAT 和防火墙规则。**局域网部署大模型服务时最常见的故障不是性能而是“能 Ping 通但连不上端口”。检查防火墙是否放行了目标端口、路由器是否做了端口转发、云平台安全组是否开放了入站规则。这些基础项排完再考虑调优。这五条“错误”犯一条都够你折腾半天。先记下来踩坑时能省不少时间。9. 从一个部署者的角度看网络基础设施值得每个大模型工程师认真对待写了这么多其实就想表达一件事大模型从科研到落地网络基础设施不是配角而是和算力、算法并列的主角之一。我自己这几年最大的体会是刚开始总以为“把模型调通”就是终点后来才发现真正决定系统上限的往往是那些不起眼的管道——数据怎么流动、模型怎么分发、请求怎么路由。你多懂一点网络部署方案就能多做一次正确的取舍你多踩一次网络的坑下一次架构设计就会多一个稳妥的选择。这条路没有捷径也不需要一上来就精通 InfiniBand 和 RDMA 的全部细节。建议从自己的实际项目出发先把你手头那个“慢”的部署环境盘一遍模型放哪了和程序之间的链路是什么交换机是千兆还是万兆显卡之间走的是 PCIe 还是 NVLink一步一步排查下来你已经比 80% 的“纯算法同学”懂部署了。最后分享一个小技巧部署大模型时养成先看三件事的习惯——GPU 利用率曲线、网络吞吐曲线、显存占用曲线。三者对比着看绝大多数性能瓶颈都会现行。别等用户反馈“好慢”才开始查主动监控这三个指标很多问题都能在爆发前被发现。