大模型推理服务对网络的新要求：从链路到部署的全面解析

1. 先把“推理网络”这个概念掰开揉碎最近不少人跑来问我“大模型推理服务对网络到底有什么新要求”说实话这个问题如果放在两年前问大部分做后端的人第一反应是“不就是带宽大一点、延迟低一点嘛”。但等你真的把 vLLM、TGI、SGLang 这类推理框架部署起来开几十路并发再叠上多机分布式推理你会发现网络早就不是“加点带宽”就能糊弄过去的事了。1.1 这个词到底指什么先别搞混我翻了翻社区里的讨论发现“推理网络”在不同场景下其实指两件事。第一层意思是指“支撑大模型推理服务的网络架构”也就是从用户发起请求到请求被分发到推理实例再到推理实例内部多张 GPU 卡之间交换数据最后把结果返回给用户的整条链路。第二层意思是“推理服务本身作为一个有状态的分布式应用它对外呈现出的网络调用关系”比如客户端和推理服务之间、推理服务和向量数据库之间、推理服务和对象存储之间这些连接组合起来也像一个网。这两层意思其实是一体两面。前者是从基础设施视角看网络后者是从应用架构视角看网络。我在这篇文章里主要把两层都讲透因为实际排障的时候你会发现很多问题恰恰出在“你以为网络没问题但实际上问题就藏在链路中间某个环节”。1.2 推理服务本质上是一整套链路问题为什么会突然聊推理网络底层原因是大模型的推理过程和传统 Web 服务的请求处理模型差别太大了。传统 Web 服务处理一个请求平均耗时可能几十毫秒网络开销在总耗时里占比很小。但大模型推理一次请求从用户输入 prompt 到模型输出完整回答动不动就是几秒到几十秒而且输出是流式的一坨一坨 token 往外面蹦。这中间网络承担的角色就变了它不再只是一个“把请求丢过去、把响应拿回来”的通道而是直接影响用户体验、吞吐上限和服务稳定性的核心变量。举个例子一次对话请求如果模型需要输出 1000 个 token以每秒钟输出 30 个 token 的速度计算整个响应会持续 30 多秒。这 30 多秒里客户端和服务器之间始终保持着一条活跃连接数据在持续流动。一旦网络抖动、丢包重传你看到的不是一次请求变慢而是整个对话窗口里每隔几秒卡一下体感非常糟糕。这个问题在传统短连接服务里是几乎不存在的。1.3 为什么现在各大厂商都在单独谈“推理网络”之前大家聊大模型更多聚焦在训练阶段因为训练是最烧钱的一张 H100 一小时的成本都能顶上普通服务器一天。但到了 2025 年这个节点大模型应用进入大规模落地阶段推理成本逐渐成为关注焦点推理服务要接住海量用户请求网络瓶颈就暴露出来了。你去看 vLLM 社区里那些 issue大量问题都和网络有关分布式推理多卡通信超时、NCCL 初始化失败、返回速度忽快忽慢、首字延迟居高不下根源往往都在网络层。再加上现在本地部署工具越来越普及像 Ollama、vLLM、SGLang 这些项目很多人是在自己电脑上玩模型文件几个 GB 到几十个 GB跑起来之后问题不大。但一旦想做成一个真正的服务让几十上百人同时访问那网络环节就必须认真设计。我写这篇文章就是想用尽量通俗的方式把推理服务对网络的“新要求”拆成一个个具体可感知的点。2. 从一次完整的推理请求看网络的四个关键段我一直觉得理解一个技术问题最好的方式是沿着一次真实请求走一遍。下面这个分析同样适用于你自己本地部署的 Ollama 服务只不过本机来回走的是回环接口网络结构被“压扁”了而已。2.1 用户到入口网关公网链路与网关分发用户通过浏览器、App 或者 API 客户端发起请求首先走的是公网链路然后到达你服务的入口网关。这一段网络的主要特点是“不可控”公网质量取决于用户自己的运营商、你购买的带宽、CDN 节点分布等等。网关要处理的事情包括 TLS 终止、鉴权、限流、路由分发。这里有一个很容易被忽略的点大模型服务的请求体往往比传统请求大得多。如果你做了一个文档问答应用用户可能一次性粘贴几千字的上下文这一个请求就有几十 KB 甚至几百 KB。公网上行带宽如果不够请求还没到服务器光上传 prompt 就已经卡了好几秒。我见过不少团队在压测时发现 QPS 上不去最后查出来是网关所在机器的公网入口带宽被打满了和 GPU 一毛钱关系都没有。2.2 网关到推理实例容器网络与负载均衡请求通过网关之后需要被转发到后端的推理实例。这一段通常跑在数据中心内部网络里可能是 K8s 集群的 Overlay 网络也可能是虚拟机直连的 VPC 网络。负载均衡器需要决定把请求发给哪个副本同时还要考虑推理实例的当前负载情况。问题在于传统负载均衡大多只关注“连接数”或者“CPU 使用率”但推理服务最关键的指标是“当前正在排队的请求数”和“显存剩余量”。如果一个实例已经积压了 20 个请求而另一个实例空闲负载均衡还傻乎乎地按轮询分发那前一个实例的请求排队时间会迅速拉长。现在稍微成熟一点的推理服务中间件都会通过自定义的健康检查和负载上报接口把实例的队列深度同步给网关让网关做“最少请求数”路由。这一层网络协议本身不复杂但应用层对路由策略的需求确实被大模型应用改变了。2.3 推理实例内部多卡并行与高速互联请求真正到达推理实例之后如果模型很大单张 GPU 放不下就需要多张 GPU 协同工作。这时候模型会被切分成不同的并行策略比如张量并行Tensor Parallelism、流水线并行Pipeline Parallelism或者两者结合。张量并行对网络的要求最苛刻因为每一层计算完都要做 AllReduce 通信把多张卡上的计算结果同步一遍通信数据量极大。这就是为什么 NVIDIA 要在服务器内部搞 NVLink因为 NVLink 的带宽是 PCIe 的好几倍而且延迟极低。一个 70B 参数的模型如果用 8 张卡做张量并行每个 Transformer 层的计算过程里都会产生巨量的小包通信网络稍有延迟整卡利用率就会断崖式下降。如果你的机器只有 PCIe 互联跑小模型还好跑大模型做张量并行性能会很难看。2.4 推理侧数据访问模型存储、向量库与外部工具最后一环经常被遗忘。推理服务除了算 Transformer 之外还要做很多周边的事情从对象存储加载模型权重、把用户 query 向量化之后去向量数据库里检索、通过函数调用/工具调用去请求外部 API。这些请求同样走网络而且它们的延迟直接叠加在推理总耗时上。我举个例子你部署一个 RAG 应用用户问一个问题推理服务先要把这个问题转成向量然后去 Milvus 或者 pgvector 里查相关文档再把检索结果拼进 prompt最后交给大模型生成回答。如果向量库查询要走公网或者跨可用区网络往返可能就要几十毫秒。这个几十毫秒平时感觉不大但叠加在每轮对话上用户会觉得“机器人反应慢了”。所以生产环境中我一般建议把向量数据库、对象存储和推理服务尽量放在同一个可用区甚至同一个 VPC 网段里就是为了把这部分网络延迟降到最低。3. 大模型推理服务到底给网络提了哪些新要求前面那条链路走完大家应该已经感受到推理服务对网络的要求绝不是“带宽大点就行”一句话能概括的。下面我按具体的维度逐一拆解每一条都是在实际部署中会被反复踩到的点。3.1 高带宽模型权重和中间激活都要“搬得快”先算一笔账。一个 7B 参数的模型用 FP16 精度存储权重文件大概 14GB。一个 70B 参数的模型FP16 下就是 140GB。假设你要在 8 张 GPU 上加载这个 70B 模型平均每张卡要分到 17.5GB 权重。这些数据必须从磁盘或者远端存储搬进显存。如果走的是 25GbE 网络理论带宽也就 3GB/s 左右实际传输打八折加载 140GB 权重需要将近一分钟。如果走的是 100GbE 网络理论带宽 12.5GB/s实际约 10GB/s加载时间能缩减到十五秒左右。有人可能会说模型加载是启动时才做一次慢点无所谓。但实际生产里模型要频繁发布新版本要灰度升级要弹性扩容启动时间每多一分钟成本都在往上翻。更关键的是推理过程中还有中间激活值的通信分布式推理时每层计算完都要同步这部分数据量比权重更夸张。所以对大模型推理集群而言内部网络带宽从 25G 升到 100G、200G 甚至 400G不是炫技是刚需。3.2 低延迟首字延迟和网络 RTT 强相关大模型对话体验里有个核心指标叫 TTFTTime To First Token也就是用户发出请求到收到第一个 token 的时间。这个指标直接决定用户觉得“这个 AI 反应快不快”。TTFT 由三部分组成请求传输时间、排队等待时间、模型 Prefill 计算时间。网络延迟直接影响第一部分。如果你把推理服务部署在离用户很远的机房网络 RTT 有 100 毫秒那么用户每次输入一条消息光传输就要 100 毫秒再算上 Prefill 时间TTFT 很容易突破一秒大关。这就是为什么现在很多 AI 应用要把推理节点部署在离用户最近的边缘节点甚至一个省份放好几个节点。本质上就是在用网络距离换体验。这里有个容易混淆的概念就是在流式输出的 Decode 阶段网络 RTT 同样重要。因为解码过程是“客户端等一个 token、服务端发一个 token”的模式虽然 token 可以批量攒着发但每次交互都有网络往返开销。如果网络 RTT 太大用户能看到的就是打字机效果一顿一顿的明明 GPU 计算速度很快输出却像挤牙膏。3.3 长连接与高并发连接数和并发能力是两回事传统 Web 接口往往是“请求—响应”就断开连接生命周期很短。但大模型推理普遍采用流式输出客户端通过 SSE 或者 WebSocket 保持一条长连接持续接收 token。这意味着每个在线用户都会长期占用一条连接。假设你有 1 万个日活用户高峰时段同时有 500 人正在和 AI 对话那网关和推理服务之间就至少维持着 500 条活跃长连接。如果每条连接占用一个线程传统线程池模型直接被打爆。所以推理服务框架普遍采用异步非阻塞 IO 模型才扛得住这种连接规模。网络层面你要保证网关的并发连接数上限足够高TCP 参数调得合理否则会出现大量 TIME_WAIT 或者连接拒绝。另外很多推理框架支持请求排队机制比如 vLLM 有 Continuous Batching同一个推理实例可以同时处理多个请求但这种机制下新进来一个用户并不是立刻占用一条独立连接而是复用同一个模型实例的通信通道。这会让“在线用户数”和“实际并发推理数”变成两个完全不同的数字。网络规划的时候不能只看并发推理数还要看连接保持数。3.4 对丢包和抖动近乎零容忍传统 Web 服务对丢包有一定容忍度TCP 重传一下顶多慢几百毫秒用户经常感知不到。但大模型推理对网络抖动极其敏感尤其是流式输出的时候。一旦发生丢包TCP 会触发拥塞控制降低发送速率然后重传丢失的数据包。这一过程如果发生在输出阶段用户看到的就是生成内容“卡住”了几秒钟然后突然蹦出一大段。更严重的是多机分布式推理场景。NCCL 这类集合通信库对网络丢包几乎是零容忍一旦某个通信原语超时整个推理任务可能直接崩溃。我在实际运维中见过太多次 NCCL timeout 报错查来查去最后发现是交换机上某个端口的 CRC 错误太多导致偶尔丢包。所以推理集群内部网络一定要做丢包监控尤其要关注网卡报错、交换机丢包计数这些底层指标。3.5 弹性扩缩容扩容要快缩容要稳大模型应用有个特点就是流量波峰波谷特别明显。白天上班时间用户多深夜用户少。如果一直保持满规格部署成本根本扛不住。所以现在推理服务普遍要做弹性伸缩根据请求量自动增减 Pod。这里给网络带来的新问题是新启动的推理实例需要快速拉取模型权重这个过程极其消耗带宽。如果同一时间扩容了 10 个 Pod每个 Pod 都要从模型仓库拉几十 GB 的权重瞬间就能把存储网络的带宽打满。我见过不少团队扩容时模型加载特别慢最后发现是对象存储的出口带宽被占满所有实例都在排队等下载。解法也很直接一个是提前把模型权重放在推理节点本地磁盘上避免每次从远端拉取另一个是把模型仓库和推理集群放到同一网络平面并且给模型下载配置独立的带宽保障。缩容的时候同样要注意正在处理请求的实例要等当前请求结束再销毁这要求网络层负载均衡的摘流逻辑必须支持优雅下线否则就会出现“响应刚生成一半连接被断开”的问题。3.6 算力网络协同让网络感知推理状态前几年大家都在谈“算力网络”这个概念偏宏大但放到推理服务里其实很具体网络交换机、负载均衡器、容器调度器能不能感知到推理服务的状态从而做出更聪明的决策。举个例子一个推理 Pod 如果显存已经满了它其实不具备再接收新请求的能力但网络层的健康检查只看 TCP 端口通不通根本不知道显存满没满。这时候请求仍然会被转发过来然后在应用层被拒绝或者排队。要解决这个问题推理服务需要实现自定义的就绪探针把“显存余量”“队列深度”上报给 K8sK8s 再根据这些信息决定哪些 Pod 可以接流量。这个过程本质上是把“网络流量调度”和“推力状态”打通让网络不再是“傻管道”而是能感知业务状态的智能调度层。4. 不同部署形态下的网络选型和参数参考大模型推理服务可以部署在完全不同的环境里网络要求和配置方法差别很大。我按部署形态分了几类大家可以对照自己的情况看。4.1 单机本地部署回环接口没你想的那么简单很多人入门都用 Ollama 在本地 Mac 或者 Windows 电脑上跑模型。这种场景下客户端和服务端都在同一台机器上网络走的是 loopback 回环接口理论延迟微乎其微带宽很高几乎不会成为瓶颈。但有一点要注意本地跑模型时响应速度的瓶颈几乎全在 GPU 或者内存带宽上不是在网络上。如果你发现 Ollama 在本地响应还是很慢别急着怀疑网络先看是不是模型太大导致内存和显存交换频繁。比如一个 8G 显存的卡跑 7B 量化模型可能没问题但跑 13B 模型就会有一部分权重溢出到内存每一层计算都要通过 PCIe 在显存和内存之间搬运数据这时候 PCIe 带宽就成了隐性瓶颈而不是网卡。另外本地部署有一点容易被忽略Ollama 默认会在 localhost 上开端口监听如果你希望局域网内其他设备也能访问需要设置 OLLAMA_HOST 环境变量为 0.0.0.0。改完之后手机、平板、另一台电脑就能通过局域网访问你机器上的模型服务了。这时候网络就从回环变成了真实局域网带宽一般够用但如果你用的是老旧路由器或者 WiFi 信号差体验依然会打折扣。4.2 单机多卡NVLink 与 PCIe 怎么选当单张显卡放不下模型时就要用多卡并行。这里首先遇到的问题是卡间互联方式选择。NVIDIA 的卡支持 NVLink 和 PCIe 两种互联方式NVLink 带宽高、延迟低但如果你的卡不支持 NVLink或者只是普通消费级显卡那就只能走 PCIe。我在测试中跑过 7B 模型用两张卡做张量并行NVLink 互联和 PCIe 互联的吞吐差距非常明显。NVLink 下模型推理吞吐可以跑到 PCIe 互联的两倍以上因为张量并行每层都要做 AllReduce通信开销占了大头。所以如果你要跑分布式推理优先考虑支持 NVLink 的卡比如 A100、H100、A800、H800 这些。如果是消费级卡能做张量并行的并行度也尽量控制在 2 到 4 张卡以内超过之后通信开销会吃掉计算收益甚至出现负优化。4.3 多机分布式RoCE 还是 InfiniBand当模型大到单机 8 卡都放不下比如千亿级参数模型就必须上多机分布式了。这时候机器之间的网络互联方案通常有两种RoCERDMA over Converged Ethernet和 InfiniBand。InfiniBand 性能最好延迟极低带宽稳定但价格昂贵而且需要专用交换机和网卡。RoCE 可以跑在普通以太网交换机上成本低很多但对网络质量要求很高需要开启 PFC 流控和 ECN 显式拥塞通知否则丢包一多性能会断崖式下降。这里给一个实操建议如果预算有限选 RoCE一定要把数据中心网络的 PFC 和 ECN 配置好而且不要和普通业务流量混跑。最好单独划一个推理集群专用的网络平面毕竟 RDMA 流量对拥塞极其敏感一旦被其他流量挤兑NCCL 通信性能会变得不可控。4.4 K8s 部署Service、Ingress 与拓扑感知调度生产环境里大多会用 K8s 部署推理服务。网络层面涉及的东西更多Pod 之间的 Service 发现、Ingress 入口、NodePort 对外暴露、网络策略限制等等。这里我特别想提一下拓扑感知调度。大模型推理经常是多卡多机协同如果 K8s 把同一个推理服务的 Pod 调度到了不同机架、甚至不同交换机下的节点上网络延迟和带宽都会受影响。所以调度器需要感知节点的网络拓扑尽量把需要频繁通信的 Pod 调度到同一个交换机下。K8s 原生提供 Topology Manager 和拓扑感知路由功能可以满足部分需求但更精细的控制往往需要配合厂商定制的调度器。对于小规模部署一个比较土但有效的办法是给节点打 label然后通过 nodeAffinity 把推理 Pod 固定到同一批节点上减少跨交换机通信。5. 排障实录推理服务网络问题的常见坑这一节我打算多写点实操内容因为网上讲推理框架的教程已经很多了但真正教你怎么排网络故障的文章很少。以下都是我实际碰到过或者帮助别人排查过的问题。5.1 现象一首字延迟极高但 CPU 和 GPU 都不忙有次我帮朋友排查一个部署在云上的推理服务现象是用户反馈“打字机效果很流畅但第一句话等得特别久”。看监控GPU 利用率不高CPU 也不高推理实例的 load 很低。最先怀疑的是 Prefill 计算慢但看指标发现 Prefill 毫秒级就完成了。最后排查到网络才发现网关和推理实例不在同一个可用区网络 RTT 有 30 毫秒再加上公网链路客户端到服务端的 RTT 超过 100 毫秒。每次请求都要经过客户端到网关、网关到推理实例两段网络TTFT 自然被拖得很高。解决办法是调整部署架构把网关和推理实例放到同一个可用区同时给公网入口配了国内节点加速。改完之后 RTT 降到了 10 毫秒以内TTFT 掉了将近 200 毫秒。这个案例说明首字延迟高的排查顺序应该是客户端网络 RTT → 网关转发耗时 → 排队耗时 → Prefill 耗时而不是一上来就盯着模型框架调参。5.2 现象二并发一高就大量请求超时另一个常见场景是压测时并发从 50 往 100 升请求就开始大量超时但 GPU 利用率并不饱和。查了推理框架日志发现请求根本没到推理实例全被网关拦下来了。再看网关日志发现连接数已经达到上限大量新连接在 SYN 队列里排队最终超时。这里涉及两个容易被忽略的参数操作系统的 somaxconn 和 tcp_max_syn_backlog。如果这两个值不够大高并发下连接建立就会失败。另外如果你用了 Nginx 做网关worker_connections 和 keepalive 参数也要调大。大模型推理是长连接场景连接保持时间远比普通接口长所以连接数上限一定要预留出足够余量。还有一个细节是有些云负载均衡器默认并发连接数上限很低开通后没有单独调整。如果你的服务突然遇到大流量第一件事是先确认云 LB 的规格和配额是否够用别傻傻地调了半天应用结果瓶颈在入口。5.3 现象三多机推理 NCCL 反复超时多机推理报 NCCL timeout 是最让人头疼的问题之一因为它隐藏在网络深处日志提示又很模糊。我之前遇到过一个案例两台机器做分布式推理NCCL 初始化成功但跑到第三个迭代就报超时。看两台机器之间的 ping 延迟正常iptables 也没有拦截。最后用了 ethtool -S 检查网卡统计信息发现接收端有大量 CRC 错误和 dropped 计数才定位到是网线或者光模块问题换了一根线后故障消失。如果遇到 NCCL 超时我建议排查顺序是先看网卡有没有报错再看交换机端口有没有丢包然后看 NCCL 通信走的是哪个网卡、是不是走了慢速管理口。特别要注意很多服务器有多块网卡NCCL 默认可能走了 IPMI 管理口或者 1G 板载口导致通信带宽严重不足这种问题光看延迟是发现不了的必须用 ib_write_bw 或类似工具测真实带宽。5.4 现象四服务间调用偶发失败日志显示 connection reset推理服务不是孤立的它要调用向量库、外部 API、鉴权服务。这些内部调用偶尔会出现 connection reset 或者 timeout而且概率不高大概 1% 左右。这种偶发问题最坑因为复现率低很难定位。我的经验是优先检查连接池配置。推理服务通常用 gRPC 或者 HTTP/2 做内部通信连接池如果空闲超时时间设置不当服务端已经断开了空闲连接客户端还在复用就会报 connection reset。解决方案是开启连接池的心跳检测或者把空闲超时时间调小。另一个可能原因是服务端在滚动发布旧 Pod 被销毁瞬间负载均衡还没把连接摘干净请求打到了正在终止的 Pod 上。解决方法是配置 Pod 的 preStop 钩子让 Pod 在退出前等待几秒给负载均衡一个摘流时间。5.5 网络排查工具和思路速览整理几个我平时用得比较顺手的工具和命令方便大家排查时直接用ping / mtr先确认网络通不通、延迟高不高。iperf3实测两台机器之间的 TCP 带宽。ethtool -S看网卡统计重点看 CRC 错误、dropped、errors。ss -s看系统 socket 状态统计 TIME_WAIT、ESTABLISHED 数量。netstat -s看 TCP 层重传率、丢包率。tcpdump抓包分析确定是连接建立失败、还是传输中断。ip -s link查看网卡收发流量和错误计数。排查思路总体来说就是从链路两端出发先确认“通不通”“快不快”“稳不稳”再逐段缩小范围。不要一上来就抓包那样只会淹没在海量数据里。6. 给入门者的一些个人建议做了这么久的大模型服务部署我自己最大的体会是很多问题看起来是“模型的问题”“代码的问题”但追到根上常常是网络的问题。尤其是当你开始涉及多机分布式推理的时候网络就不再是一个可以事后补救的环节而是一个必须在设计之初就认真规划的前置条件。如果你的项目还处在本地玩的阶段可以暂时不考虑这么多先把 Ollama、vLLM 跑起来再说。但一旦你想把服务真正开放给别人用或者想跑更大的模型那么请一定提前做三件事画清楚你的网络拓扑确认每一段的带宽和延迟都在你可接受的范围内然后把监控做起来。尤其是网卡错误、TCP 重传、连接数这些底层指标一定要有历史数据不然出了问题你都无从下手。最后再分享一个小技巧我每次部署完推理服务第一件事不是急着压测接口而是先跑一遍端到端的链路检测从客户端到网关、从网关到推理实例、从推理实例到依赖服务每一段都确认一下延迟和带宽。这个习惯帮我规避了至少一半的“疑难杂症”。如果大家在实际部署中遇到网络相关的怪问题建议也先走一遍链路检测往往会有意想不到的收获。