大模型这几年火得不行，但大多数人聊的都是“参数规模”“训练数据”“推理速度”，很少有人认真讲一件事：这么多 GPU 卡是怎么连成一片干活的？你本地跑个 Ollama 和公司里跑个千卡集群，背后差的到底是什么？
答案就是网络基础设施。我之前带团队做模型服务化的时候，第一次排障查了整整一个下午，最后发现瓶颈不在 GPU，不在显存，也不在调度器，而是两台机器之间的网卡协商带宽掉了一半。那一刻我才意识到，所谓的大模型能力，其实是算力、显存、存储、网络四张网织出来的，网络这条线往往是最隐蔽、也最容易被忽视的短板。
这篇文章专门写给零基础的读者。我会用大白话把这些概念讲清楚，不求让你马上能搭一个万卡集群，但至少看完之后，你能看懂厂商发布的“XX PFLOPS 算力集群”到底牛在哪儿，也能搞明白为什么本地部署大模型时 Ollama 电脑和公司服务器的路径选择完全不一样。
1. 先搞懂大模型为什么“吞网络”
很多新手有个误区，觉得大模型就是一块大硬盘，装一个文件就能跑。实际上，大模型不是一个文件，而是成千上万个 GPU 卡并行协作的结果。以训练为例，一张 H100 的显存是 80GB，但像 GPT-4 级别的模型，参数已经超过万亿，根本放不进单张卡。这时就得把模型切碎，分到几百几千张卡上。
这里有个关键概念叫张量并行。简单说，同一个计算矩阵被切成多块，分别放卡上，每算一步都要同步一次数据。同步就得靠网络传数据。如果你用千兆网卡，训练过程中大部分时间都在等网络，GPU 空转，电费照烧，进度条不动。
我做个生活化的类比。假设你要把一本 1000 页的书抄成 10 份，如果 10 个人各自独立抄，最后只有一本原书能分着看，其他 9 个人只能等。如果 10 个人分工，每人抄 100 页，但每抄完一页都要互相核对一次，那么核对的速度就决定了整个抄书的速度。这个“核对”的过程，在大模型里就是网络通信。
所以你看，大模型对网络的需求，本质上是对高带宽、低延迟、低丢包的极端追求。训练时每秒钟得传几十 GB 的数据，延迟多一个毫秒都可能让 GPU 老大哥们“排队等饭吃”。
推理阶段也一样。你问大模型一个问题，请求先到达 API 网关，再转发到推理服务器，如果模型太大单机放不下，还得通过网络分发到多个节点，最后结果再汇总回来。整个过程如果不顺畅，最直观的体感就是“打字回复特别慢，一个字一个字往外蹦”。
在了解具体设备之前，先记住一组结论，哪怕你还不知道 GPU、NVLink 是什么，也能建立正确的直觉框架：
- 单机内部的卡与卡通信，靠的是 PCIe 总线和 NVLink，速度快但距离短。
- 多机之间的通信，靠的是网卡（NIC）和交换机，速度取决于端口速率和网络拓扑。
- 你访问云上的大模型 API，走的是公网 Internet，延迟受物理距离和运营商线路影响。
- 本地部署大模型（比如 Ollama），网络要求其实不高，瓶颈在内存带宽和显存容量，而不是网卡。
这套框架能帮你判断很多问题。比如有人问“为什么大模型部署要用 A100 而不是普通游戏显卡”，答案一半在算力，另一半就在显存带宽和 NVLink 这类通信能力上。
2. 一张图看懂大模型网络的分层架构
要理解网络基础设施，最忌讳一上来就看一堆术语。我先给出一个分层拆解的视角，由近到远，一层层讲。
2.1 卡间互联层：NVLink 与 PCIe
最底层、速度最快的连接，是同一台服务器内部 GPU 卡之间的连接。英伟达目前主流做法是 NVLink，它可以理解成 GPU 之间的专用“高速公路”。NVLink 不是用普通的 PCIe 插槽，而是 GPU 上专门的金手指，通过桥接器或者背板直接对接。
以 A100 为例，NVLink 3.0 单向带宽 50GB/s，双向 100GB/s。到了 H100 的 NVLink 4.0，双向带宽飙到 900GB/s。这是什么概念？就是一块满血的 PCIe 4.0 x16 插槽（约 32GB/s 单向）完全不是它的对手。NVLink 的意义在于，卡与卡之间传显存数据几乎不用绕道 CPU 和内存，直接把显存数据从一个卡搬到另一个卡，传输延迟极低。
对你实际部署有什么用？如果你是在单台服务器里塞了 8 张卡，跑张量并行或者流水线并行，卡间通信是最大瓶颈。如果你买的服务器只有 PCIe 连接，没有 NVLink，那么 8 卡就像一个走廊很窄的合租房，人多了就堵。这也是为什么二手市场里带 NVLink 桥的主板比不带桥的贵一大截。
PCIe 则是更基础的连接方式，GPU 通过 PCIe 插槽连到 CPU，再通过 CPU 连到网卡。PCIe 的版本和通道数决定了数据传输上限。买服务器时一定要看是 PCIe 4.0 还是 5.0，通道数是 x16 还是 x8。很多号称“支持 8 卡”的服务器，实际每张卡只能跑 x8 甚至 x4 带宽，训练效率会大打折扣。
注意：NVLink 也有物理限制。它只支持同一台机器内部的 GPU 互联，不支持跨服务器。跨服务器的卡间通信，就必须走网络了。
2.2 机内网络层：网卡与 RDMA
单机内部通信再快，也只覆盖 8 张卡的能力。当参数规模超过单机上限，必须把多台服务器连成一个集群。这时每台机器都需要一个高性能网卡，常见的是 100Gbps、200Gbps 甚至 400Gbps 的以太网卡，或者 InfiniBand 网卡。
网卡收发数据的时候，CPU 负担很重，每个数据包都要中断 CPU，CPU 被频繁打扰后就没空算数了。为了解决这个问题，业界用了一种叫 RDMA 的技术。简单说，RDMA 允许网卡直接读写另一台机器的内存，不用经过双方的 CPU 和操作系统。就像两个人隔着墙递纸条，纸条不会经过中间人的手。
RDMA 又分两种主流实现：
- InfiniBand：专用网络，价格贵，延迟极低，丢包率极低，大模型训练首选。
- RoCEv2：跑在普通以太网上的 RDMA，便宜很多，但部署时对交换机丢包要求很高。
大模型训练集群普遍推荐用 InfiniBand，因为它有无损网络支持。以太网哪怕 99.99% 的包都能成功送达，剩下的 0.01% 丢包在万卡级训练里也会反复触发重传，造成“木桶效应”——整体速度被最慢的那一跳拖垮。
2.3 机间网络层：交换机与拓扑
多台服务器连起来，光靠网卡不够，还得有交换机把它们串到一起。交换机的选择直接决定了集群的扩展能力。
最经典的拓扑是Fat-Tree（胖树）。想象一棵倒过来的树，最下面是计算节点（也就是服务器），往上是叶子交换机、脊交换机、核心交换机。任何一台服务器到另一台服务器，都有多条路径可选。胖树的好处是带宽可以线性扩展，服务器越多，核心层带宽越大。
还有更先进的Torus（环装网）和Dragonfly（蜻蜓网），主要是为了在超大集群中减少跳数、降低延迟。这些拓扑对普通用户来说太遥远，但了解基本思路是有用的：拓扑越复杂，交换机数量和链路数量越多，管理难度和成本越高。
对大模型训练而言，通信模式有个显著特点叫All-to-All。简单说，每一轮梯度同步，所有机器要把自己的数据发给所有其他机器。这种模式很吃网络，网络拓扑如果不均匀，某些链路就会拥堵，形成“热点”。很多训练框架例如 Megatron-LM 或 DeepSpeed，会专门做拓扑感知的调度，目的就是为了尽量减少跨交换机通信。
2.4 数据中心出口层：前端网络与存储网络
前面说的都是“东西向流量”，也就是服务器之间横向互传。实际上还有另一类流量叫“南北向流量”，指的是用户请求进入数据中心，或者数据中心去访问外部对象存储。
这类流量对带宽的要求没有训练流量那么极端，但对稳定性和会话保持有要求。通常机房会单独搭建前端网络，跑标准 TCP/HTTP 协议，用常见的 25G/50G 网卡接到接入交换机上。训练网络和前端网络往往是物理隔离的，目的就是防止训练流量把用户请求挤崩。
还有一个常被忽略的是存储网络。大模型训练时，每过一段时间就要保存模型权重（checkpoint）。一个万亿参数的模型 FP16 存下来就是 2TB，如果几十个节点同时去写存储，存储网络带宽不够会导致训练暂停等待。所以大厂一般会用专有的并行文件系统，比如 Lustre 或 GPFS，搭配高性能网卡，确保 checkpoint 快速落盘。
这块对零基础读者来说可能有点超出，但记住一句话就行：大模型集群不是只有 GPU，还有一套存储网络和文件系统，它们同样决定训练能不能跑得动。
3. 为什么说网络是大模型规模化的“隐形瓶颈”
我在前面反复强调网络重要，但到底有多重要？举几个真实场景。
3.1 训练阶段的“卡顿”可能不是 GPU 问题
有一次我们内部测试一个 1750 亿参数的模型训练，观察到一个怪现象：每个 step 计算时间只占 60%，剩下 40% 时间都花在等待。监控面板上 GPU 利用率很低，但训练就是快不起来。
查了半天，发现是两台机器间的一根光模块故障，速率从 400Gbps 掉到 100Gbps。网络层的流控机制让整条链路的传输性能大幅下降。那根光模块不在告警范围，因为物理链路没断，只是光衰增大。后来换了光模块，训练速度立刻涨了近一倍。
类似的问题在千卡集群里非常常见。显卡本身不坏，网线也没断，但某个交换机端口丢包率高了，就会拖垮整轮训练。所以做大规模训练的人常说：GPU 是上限，网络是下限。网络不好，再强的 GPU 也发挥不出来。
3.2 推理阶段的“第一 token 延迟”与网络关系密切
做推理优化的人常挂嘴边一个指标叫Time To First Token（TTFT），也就是从发出请求到模型吐出第一个字符花了多久。这个指标不仅取决于模型算得快不快，还取决于请求从客户端到服务器的网络延迟。
如果用户在 A 地，服务器在英国，物理距离决定光速极限，再怎么优化也得绕地球半圈。所以大模型厂商会在多个区域部署边缘节点，目的就是把“最后一公里”的网络距离缩到最短。
这个思路对普通开发者也有启发。你如果自己部署 Ollama 做开发调试，建议把模型装在同一台电脑或者同一个局域网内，不要挂在内网穿透到很远的服务器上。那样每次交互网络延迟太高，体验会非常糟糕。
3.3 参数服务器架构中的网络压力
老一代分布式训练常用参数服务器（PS）架构：一批 Worker 负责计算，一批 Server 负责存参数和更新梯度。每个 Worker 每算完一个 batch，就要把梯度推到 Server，Server 再把最新参数拉回来。这种架构在模型规模不大时很稳定，但模型大了以后，服务器的网络带宽成了瓶颈。
现在大模型训练主流是全规约（All-Reduce）架构，不再单独设参数服务器，而是让所有 GPU 组成环网，梯度数据在环里转一圈就能完成求和。这种模式对网络拓扑的均衡性要求更高，但只要网络基础好，扩展性远超 PS 架构。
所以你会看到，大模型训练发展史其实很大程度就是网络通信结构的发展史：从集中式参数服务器，到去中心化的 All-Reduce，再到现在多模态时代的高带宽拥塞控制。每一步都在和网络较劲。
4. 从设备到协议：常用网络硬件与软件栈解析
这部分我按“硬件选型”和“软件配置”两个维度展开，给想要自己动手的读者一些参考。
4.1 硬件层面该看哪些参数
挑服务器和交换机的时候，重点看带宽和延迟。带宽单位是 Gbps（吉比特每秒），需要换算成 GB/s 才有直观感受。100Gbps 除以 8，就是 12.5GB/s。一个 80GB 的模型权重，在不考虑其他开销的情况下，通过 100Gbps 网卡传完需要约 6.4 秒。听起来还能接受，但训练过程中每秒钟要传好几轮梯度，这个量级就会变得非常紧张。
另一组参数是网络接口类型，SFP28、QSFP28、QSFP-DD。QSFP-DD 是目前 400G 以太网的主流接口。买之前一定要看光模块的支持列表，不同厂商的模块和交换机可能存在兼容问题。
再看网卡的 PCIe 通道数。一张 400G 网卡如果只插在 PCIe 4.0 x8 上，理论带宽只有约 16GB/s，远低于 400Gbps 的 50GB/s，直接变成瓶颈。所以在服务器里，400G 网卡通常要求 PCIe 5.0 x16 插槽，这个细节最容易踩坑。
4.2 软件层面要知道哪些组件
网络硬件装好后，软件栈决定了你能不能把性能发出来。
- NCCL（NVIDIA Collective Communications Library）：英伟达提供的多卡通信库，几乎所有大模型训练框架底层都调它。它支持 NVLink、PCIe、InfiniBand、RoCE 等多种后端。在实际使用中，设置
NCCL_DEBUG=INFO环境变量可以打印出通信初始化信息，非常管用。 - IB Verbs / libfabric：InfiniBand 的驱动接口。装驱动时，建议用
ibstat检查端口状态，用ib_write_bw测试点对点带宽。 - RDMA CM：管理 RDMA 连接的组件，负责建立连接、管理队列对。如果连接建不起来，多半是子网管理器（Subnet Manager）没配好。
- TCP 调优：即使你不需要 RDMA，也会依赖 TCP 做控制面流量。可以调的参数有 MTU、拥塞控制算法（比如 BBR）、缓冲区大小等，但这些优化空间远不如 RDMA 显著。
我遇到太多人买了 InfiniBand 网卡，驱动装了，IP 也配了，但训练速度还是很慢。一查才发现是没装子网管理器，或者子网管理器没有跑起来。InfiniBand 不像以太网有自协商机制，它是“无主不欢”的，必须有一个子网管理器来分配路径。这个细节不写进任何快速上手指南，但我踩过，所以必须提醒。
4.3 本地部署场景的网络需求
如果你只是在自己电脑上跑 Ollama、跑 llama.cpp，其实不需要 400G 网卡和 NVLink。这类工具设计出来就是单机运行，模型加载完后推理主要在本地完成，网络只负责下载模型和发送 API 请求。
但有一个容易被忽略的点：模型下载和加载时的网络问题。Ollama 默认从模型仓库拉取权重文件，一个 7B 模型约 4GB，70B 模型约 40GB。如果网速一般，下载过程会非常煎熬。后来我发现可以用环境变量OLLAMA_MODELS把模型仓库指向一个容量足够大的磁盘，避免装到系统盘把 C 盘挤爆。另一个设置是把OLLAMA_HOST改成0.0.0.0:11434，这样同一局域网内其他设备也能访问你的 Ollama 服务，相当于搭了一个小微推理服务器。这些操作我后面章节详述。
5. 从零到一：搭建一个最小可用的推理服务网络
理论讲太多容易晕。这里我以最本土化的场景为例，带你实操一遍：用一台普通的 Linux 服务器加上 Ollama，搭建一个能对外提供大模型 API 的最小部署，并且把网络配置梳理清楚。
5.1 机器准备与网络设计
假设你有一台 32 核 CPU、128GB 内存、单张 24GB 显存显卡的机器（比如 RTX 3090/4090）。对 7B 模型来说，这个配置足够跑 FP16 精度；如果想跑 70B，就得考虑量化版本或者多卡并行。
网络方面，建议把机器接在局域网内，固定 IP，例如 192.168.1.100。如果你希望外网也能访问，不建议直接暴露公网端口，更稳妥的做法是用内网穿透工具或者云上的反向代理。因为大模型 API 是没有鉴权机制的，直接把服务挂公网，任何人都能白嫖你的显卡，还可能被恶意刷流量。
安全提醒：Ollama 服务本身没有身份认证。如果必须暴露在外网，请在前面加一层网关，比如 Nginx，配 Basic Auth 或者用专用工具做 Token 校验。别问我怎么知道的，我见过太多人把 11434 端口裸奔在公网上，一天产生几百美元流量账单。
5.2 安装 Ollama 并验证服务
Ollama 的安装很简单，Linux 上执行一行脚本：
curl -fsSL https://ollama.com/install.sh | sh安装完成后，执行ollama serve启动服务。默认监听 127.0.0.1:11434，只允许本机访问。这时你用 RestClient 或浏览器打开http://127.0.0.1:11434，会返回Ollama is running的提示。
要拉取一个模型，比如千问 7B 的量化版：
ollama pull qwen2.5:7b拉取完成后，运行：
ollama run qwen2.5:7b直接在终端对话测试。确认能正常输出后，再用代码方式测一下 API 是否通：
curl http://127.0.0.1:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "你好，请介绍一下你自己", "stream": false }'如果能正常返回 JSON，说明本地推理链路已经通了。
5.3 开放局域网访问
要让同一局域网的其他设备访问这台机器的 Ollama，需要修改服务监听的地址。在 systemd 服务里设置环境变量：
sudo mkdir -p /etc/systemd/system/ollama.service.d sudo tee /etc/systemd/system/ollama.service.d/override.conf > /dev/null <<EOF [Service] Environment="OLLAMA_HOST=0.0.0.0:11434" EOF sudo systemctl daemon-reload sudo systemctl restart ollama改完后，在另一台电脑上用http://192.168.1.100:11434测试。如果访问不了，先检查防火墙：
sudo ufw allow 11434/tcp这个操作非常实用。很多人把 Ollama 装在主机上，想在笔记本上远程调用。如果不改监听地址，笔记本永远连不上。
5.4 配置 Nginx 反向代理与访问控制
如果你要在团队里分享这个 Ollama 服务，不想让所有人都知道 IP 和端口，也不想裸奔，可以用 Nginx 反代加一层密码保护。
安装 Nginx 后，在/etc/nginx/sites-available/ollama写入：
server { listen 80; server_name your-domain.com; auth_basic "Restricted Access"; auth_basic_user_file /etc/nginx/.htpasswd; location / { proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }创建密码文件：
sudo apt install apache2-utils sudo htpasswd -c /etc/nginx/.htpasswd yourusername然后启用配置并重载 Nginx。这样外部访问就是先过 Nginx 的认证，再到 Ollama，安全性和可管理性都提升一个档次。
5.5 用 Docker 部署时的网络资源配置
不少人喜欢用 Docker 跑 Ollama，比如：
docker run -d -v /ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollamaDocker 部署时，网络模式默认是 bridge，容器内端口映射到宿主机。需要注意的一点：如果容器内 Ollama 要访问外部对象存储或者模型仓库，需要确保宿主机能正常出网。还有，容器内显存映射是自动的，不需要自己配置 GPU，但前提是安装了 NVIDIA Container Toolkit。
如果你想给容器分配更多网络带宽，可以用--network host模式，让容器直接使用宿主机网络栈，减少一层 NAT 转发延迟。但 host 模式下端口管理会更麻烦，适合单机测试，不适合多服务并存。
6. 大模型网络的未来方向与个人学习路线建议
讲了这么多，回头看会发现：大模型的网络基础设施，本质上是一个“如何让更多 GPU 高效协同”的问题。解决这个问题的思路，正随着模型规模变大而不断演进。
6.1 超节点架构与液冷机房
大厂最新的方向，是从“几千台服务器松散连接”走向“超节点”。超节点可以理解为一个巨大的逻辑 GPU 系统，内部用超高带宽的光互连，外部再用传统网络连接多个超节点。这种架构下，单卡之间的通信延迟可以低到几微秒级别，训练万亿模型变得相对可控。
超节点对机房基础设施要求也变了。功率密度大增，风冷压不住，必须上液冷。液冷不仅给 GPU 降温，也给交换机和光模块降温。光模块对温度极其敏感，温度一高，信号完整性下降，误码率上升，网络质量直接崩盘。
所以你会看到，大模型网络建设早已不是纯 IT 问题，而是暖通、供电、网络、算力四维协同的系统工程。这个认知对你面试或者做规划都会有帮助。
6.2 从工程师视角怎么入门网络方向
如果你对这个方向感兴趣，我建议按这个顺序来：
- 先会单机跑模型，把显存、内存、CPU 的分配搞明白。
- 再用 NCCL 跑多卡训练，理解单机多卡的通信。
- 然后尝试双机训练，配置 RoCE 或 InfiniBand，跑通一个小规模集群。
- 最后学习网络拓扑设计和性能调优，比如看 NVIDIA 的 HPC 网络文档，了解 Fat-Tree 和 Dragonfly 的差异。
每一步都不需要一开始就啃论文。先从“跑通”开始，再逐步优化。很多概念比如 PFC、ECN、拥塞控制，等你真正在集群里遇到问题时再去查，印象会深刻得多。
工具方面，个人推荐掌握这几个：
ibstat和ib_write_bw：查 InfiniBand 状态和测带宽。perf和nvidia-smi：查 GPU 利用率和通信状态。ethtool -S：查网卡丢包和错误计数。tcpdump：抓包定位故障。
核心思路就一条：遇到性能问题，先用这些工具做“二分定位”，先确认是计算瓶颈还是网络瓶颈，再聚焦排查。不要一上来就怀疑模型代码，很多问题其实在网络配置。
6.3 最后几句实在话
大模型网络基础设施这个话题，门槛确实不低，涉及硬件、协议、操作系统、分布式系统多个层次。但它的底层逻辑并不复杂：无非就是在低成本的前提下，把数据尽量快地从一个计算单元搬到另一个计算单元。
我见过太多人花几十万买 GPU 服务器，结果网络买的是千兆网卡和低端交换机，训练性能惨不忍睹。也见过有人用几块钱的网线跑百G传输，结果误码率飙升、训练反复中断。网络这东西，看着不起眼，但它决定了大模型集群的上限。
如果你现在还是零基础，别慌。先跑通一个单机 Ollama，感受一下模型推理的完整流程。然后找两台机器，试着把模型加载到 A 机、从 B 机发请求，体会一次真正的“分布式调用”。从单机到多机，从局域网到跨机房，每一步踩过的坑，都是最好的教材。希望这篇文章能帮你少走一点弯路。
