做推理基础设施这段时间我问过自己最多的问题就是分布式推理网络到底应该怎么设计很多人以为把训练集群那套组网方案挪到推理场景就行结果上线不到一周就被P99延迟、节点间协同失衡、缓存命中率暴跌这些问题按在地上摩擦。事实上分布式推理网络不是多机跑一个模型那么简单它涉及推理集群组网、跨节点协同、请求路由、KV Cache一致性、可观测性等一系列工程问题。这篇文章不聊概念就按我实际搭建和调优一套推理集群的完整过程把从组网到协同的每个决策掰开来讲适合正在做AI基础设施、模型服务化、推理平台的同学参考。1. 为什么推理最终会变成一张网络而不是一组独立节点1.1 单机推理的账算下来就知道什么时候该拆我先算一笔账。假设业务上要部署一个70B参数的稠密模型用FP16精度加载单份模型权重就是70×2140GB显存。一块A100/H100 80GB根本塞不下退一步用INT8量化70GB还是贴着单卡上限。可推理不只是把权重装进显存就完事还有KV Cache、激活值、CUDA context这些都会吃掉显存。更关键的是在线服务的QPS不是固定的峰值可能是均值的5到10倍单机哪怕勉强能算也会在流量抖动的瞬间直接超时。所以把推理做成分布式网络第一个驱动力是显存和算力的物理上限第二个驱动力是业务对延迟的苛刻要求。在线推理场景里用户要的是发请求-拿结果这个闭环在几百毫秒内完成而不是像训练那样可以分批等几小时。这种交互模式决定了系统必须具备横向扩展能力流量大了加节点模型多了加副本某节点挂了把流量摘掉。单靠一台服务器无论如何都做不到这些事。1.2 推理网络和训练集群的核心区别方向不同我见过很多做训练出身的人上手推理服务时习惯性照搬训练集群的思路任务调度、数据并行、梯度同步。但推理和训练在工程目标上有本质区别。训练集群追求的是吞吐最大化任务可以排队、断点续跑推理服务追求的是延迟和稳定性每个请求都必须被及时响应而且请求之间存在冷热差异、长短文本差异、不同模型的优先级差异。此外推理集群里模型的加载和卸载是频繁发生的。今天我上线一个精调后的LoRA版本明天可能要下掉一个不再使用的底座模型。这种动态变化要求推理网络具备请求级别的路由能力让流量在模型实例之间动态分配。而训练集群通常把任务一次性绑定到一组固定节点上两者对组网和调度的要求完全不一样。理解了这个区别后面选型才不会走偏分布式推理网络本质上是一个以请求为中心的实时系统任何设计决策都应该先回答一个问题——这一个请求从进来到返回中间经过哪些节点每跳消耗多少时间。2. 推理集群组网的三层拆解接入、调度、执行2.1 执行层组网节点之间的互联方式决定了协同上限执行层就是真正跑模型推理的计算节点通常是一批搭载GPU的服务器。节点之间的网络拓扑直接决定跨节点协同的上限。这里最关键的一个选择是用普通的TCP以太网还是上RDMA/InfiniBand。刚开始图省事我也在普通千兆/万兆以太网上跑过张量并行。结果发现当模型被切分到多个GPU上每个token的生成过程都要做多次all-reduce通信网络延迟稍微抖动一下整个推理请求的生成速度就断崖式下跌。后来把节点间网络换成RDMA效果立竿见影端到端时延明显下降吞吐也稳定了。原因在于RDMA绕过内核协议栈kernel bypass让数据从GPU显存到对端GPU显存的路径大幅缩短而这正是多机张量并行最需要的。组网时必须为突发流量预留带宽余量不建议把节点间网络跑满。我踩过一个教训为了省机器让推理节点既承担计算又承担日志采集结果日志落盘占用大量网络IO模型通信的延迟被拉高。后来把日志和数据面网络做了物理隔离P99才恢复正常。执行层组网的原则是宁让链路闲置也不要让通信排队。2.2 接入层组网入口网关不能只是一个反向代理接入层是用户请求进入推理网络的第一道门。很多人把入口网关当成普通的Nginx或者负载均衡用这是分布式推理网络里最容易低估的一环。普通反向代理只关心把请求转发给一台健康的机器但推理网络里的网关必须知道哪个模型实例有空闲并发、哪个实例的显存还够、哪个实例加载的模型版本匹配当前请求。我实际使用的方案里接入层做了两层拆分最外层是无状态负载均衡负责TLS终止、基础限流、按节点健康状态摘流量内层是带有模型路由信息的网关负责任务分发到具体的推理实例。外层用标准的四层负载均衡就够了内层则必须能和调度层对话拿到实时的实例状态。一个小经验接入层的连接池一定要按推理实例的并发能力来设置不能无脑开大。模型推理是CPU/GPU密集型操作连接并发过高会导致请求排队。把网关到推理节点的最大并发数控制在实例可承受范围内然后把多余的请求放在网关层排队或快速失败比挤在GPU节点上排队要可控得多。2.3 调度层请求该往哪台机器送调度层是分布式推理网络的大脑它决定每个请求交给哪个执行节点。最简单的做法是轮询但推理场景下轮询几乎是错误示范因为不同模型的显存占用不同不同请求的文本长度不同轮询会导致热点节点和空闲节点并存。我采用的调度策略是两阶段决策。第一阶段按模型筛选节点只把请求路由到加载了目标模型的节点第二阶段按负载打分综合节点当前的GPU利用率、队列长度、KV Cache剩余空间等指标选得分最高的节点。负载打分每隔几百毫秒更新一次并且要设置一个亲和性优先的开关对同一个会话的连续请求尽量路由到同一台节点这是为了最大化前缀缓存命中率后面第4章会详细讲这个坑。3. 跨节点协同的真正难点一个请求从进入到返回的完整链路3.1 模型并行策略PreFill和Decode的性格不同协同方式也要不同大模型推理的请求处理分两个阶段PreFill预填充处理输入的Prompt和Decode逐步生成Token。细究起来这两个阶段对跨节点协同的要求完全不同。PreFill阶段计算密集一次要处理成百上千个Token的矩阵乘法适合把输入切块并行计算这时张量并行带来的加速非常明显节点间通信量大但次数相对少。Decode阶段是访存密集每次只生成一个Token计算量小但KV Cache读写频繁而且每个step都涉及一次all-reduce对通信延迟极其敏感。所以现在主流的方案是Prefill/Decode分离架构用一组节点专门处理PreFill另一组节点专门处理Decode中间通过KV Cache传输衔接。这样做的好处是两类节点的机型可以分别优化——PreFill节点配更强算力Decode节点配更大带宽。当然代价是跨节点协同链路更长需要把KV Cache高效地从PreFill节点传到Decode节点。如果你的业务主要是短文本对话混布也能接受如果是长文档问答、代码生成这类PreFill很重的场景分离架构的收益会更明显。3.2 KV Cache的跨节点一致性协同不只是在算上面说到KV Cache这是跨节点协同里最隐蔽的难点。Decode阶段每生成一个Token都要依赖之前所有Token的KV Cache。当PreFill和Decode拆分到不同节点或者请求被路由到另一个副本时KV Cache必须随之迁移或重建。这里能做的优化非常多。一个实用的做法是做前缀缓存把大量请求共享的System Prompt、Few-shot示例的Token序列提前计算好KV Cache存放在共享缓存里新请求进入时如果发现前缀匹配就直接复用缓存省掉一段PreFill算力。实测下来在客服问答这类固定Prompt的场景前缀缓存可以把首Token延迟降低40%以上。但前缀缓存的引入也带来一致性问题多个节点同时维护缓存怎么保证同一个前缀只有一份请求被路由到不同节点时缓存是否有效我的方案是让调度层维护一个前缀哈希表记录哪些节点存了哪些前缀的KV Cache调度时优先把请求送到缓存命中的节点。这个表和节点心跳一起更新虽然增加了一点调度开销但换来的收益非常可观。3.3 请求路由与模型放在哪的冲突谁能加载模型谁才能服务请求分布式推理网络里有一个天然的矛盾一个模型实例只能存在于一台机器的显存里但请求可能来自任意网关。如果请求被调度到没有加载目标模型的节点要么拒绝要么现场把模型从远端存储拉到本地再加载——后者动辄几十秒在线场景根本等不起。解决这个矛盾要靠模型放置策略。我实践下来最稳的方案是为高流量模型常驻多副本分布在多台机器上为低频模型只保留少量副本并开启冷启动预热机制在流量特征发生变化前提前将模型加载到指定节点。另外显存置换Model Swapping也是一条路线——同一台机器上多个模型按热度换入换出但频繁换入换出会带来显存碎片化问题第4章会专门讲这个坑。4. 真实压测中踩过的三个坑完整排查链路照着做能少走弯路4.1 节点间TCP重传导致P99延迟暴涨不是模型变慢了是网络在重传现象是压测时P99延迟突然从80ms跳到400ms以上而平均延迟没有明显变化。起初我怀疑是模型调度问题把模型日志和GPU指标翻了个遍利用率正常队列长度也正常。后来把监控细到节点间的TCP重传率才发现重传率在高峰期达到5%以上。抓包后进一步确认网卡环形缓冲区溢出导致内核丢弃数据包触发TCP重传。排查链路就是延迟监控→定位到节点间通信耗时增加→检查TCP重传率→抓包确认丢包位置→查看网卡队列/中断配置。解决方案是三管齐下调大网卡环形缓冲区大小、开启多队列并把中断绑定到不同CPU核心、把实时通信流量和日志流量在物理链路上隔离开。做完之后TCP重传率降到0.1%以下P99拉回到100ms以内。这个坑告诉我们跨节点协同的通信路径必须纳入监控纯看应用层指标很难发现网络问题。建议把TCP重传率、网卡丢包率、RDMA错误计数全部接入告警。4.2 路由漂移导致缓存命中率崩掉一致性哈希环的健康检查不能一刀切前缀缓存上线后缓存命中率一度高得喜人但某次发布新模型版本后命中率从80%掉到30%首Token延迟同步上涨。排查发现调度层在做节点摘除时一致性哈希环上的节点变动过于激进一次健康检查抖动就触发大量键重新映射把原本稳定的前缀缓存全部打散到别的节点。排查链路是命中率下降→检查路由日志→发现同一批请求被路由到不同节点→检查一致性哈希环→确认健康检查误判导致节点频繁上下线。修复方案有两个一是给健康检查增加连续失败N次才摘除的阈值避免单次抖动触发迁移二是给相同会话/相同前缀的请求增加sticky session亲和性让路由结果在会话生命周期内保持不变。从此我学到一个原则所有涉及映射关系的组件都必须设计成允许短暂延迟故障但不允许频繁变动。对在线推理来说一个偶尔超时的节点比一个不断触发路由重计算的节点更可信。4.3 显存碎片化导致新模型无法加载频繁换入换出的隐藏成本业务上线了LoRA动态适配功能后节点上频繁加载/卸载不同模型版本运行几天后出现显存还剩30GB但加载新模型报OOM的诡异现象。nvidia-smi看到的显存确实有剩余但都是碎片化的空洞无法分配出一块连续的大显存。排查链路是OOM报错→确认显存总量充足→检查内存碎片指标→复现频繁加载/卸载模型操作→确认碎片化累积。解决方案有三种一是定期重启节点释放显存碎片治标不治本二是在模型加载层做显存池化预先把显存分配成固定大小的块模型加载时按块申请减少碎片产生三是调整模型实例的常驻策略不在单节点上做过于频繁的换入换出而是通过跨节点的副本调度来应对冷热变化。这里我特别想强调显存池化虽然看起来牺牲了灵活性但它让显存分配变得可预测、可监控对于分布式推理网络的稳定性价值远大于那一点灵活性损失。5. 可观测性与成本分布式推理网络能不能跑长久看这两件事5.1 端到端时延拆解不要把账都赖在GPU头上分布式推理网络里一次请求的时间 网络传输耗时 网关路由耗时 调度决策耗时 排队耗时 PreFill耗时 Decode耗时 跨节点通信耗时 响应传输耗时。很多团队只看GPU利用率和端到端延迟结果找不到瓶颈。我搭建的可观测性体系分三层。第一层是基础设施指标节点CPU、内存、网络重传率、网卡丢包率、RDMA错误。第二层是推理引擎指标队列长度、Batch大小、PreFill/Decode耗时分布、KV Cache命中率、显存碎片率。第三层是业务链路追踪每个请求经过网关、调度、推理节点的完整时间戳用OpenTelemetry统一采集。第三层尤其重要没有链路追踪分布式环境下的时延问题几乎没法定位。详细拆解后我发现自己系统里最大的隐藏瓶颈不是GPU算力而是等待队列。流量高峰时请求在推理节点上排队的时间占了端到端时延的60%以上。解决方式不是加GPU而是优化批处理策略、做请求优先级分级——让短请求和长请求分开排队避免长请求把短请求堵死。5.2 算力利用率与网络成本的平衡集群不能只追求满载分布式推理网络投入最大的部分是GPU和网络带宽所以大家本能地想让集群尽可能满载。但推理场景下满载通常意味着延迟失控。我倾向于把集群的目标利用率设定在60%-70%之间留出余量应对流量毛刺和节点故障。网络成本方面RDMA设备、交换机、网卡的投入不是小数目但也不是每个场景都需要RDMA。如果模型并行度低、节点间通信不频繁万兆以太网加优化过的通信库也能撑住。我的选型标准是单次请求跨节点通信数据量大于1MB且频率高才值得上RDMA否则用好TCP的优化手段内核参数调优、多队列、IRQ绑定性价比更高。5.3 一套可以直接参考的组网与架构配置最后给出我在中等规模场景几十台GPU节点下验证过的稳定配置供参考接入层4层负载均衡TLS终结、基础限流 内部网关模型路由、会话亲和性调度层自研调度器或基于开源框架二次开发维护模型-节点映射、前缀缓存哈希表、节点负载评分执行层GPU节点分组PreFill节点和Decode节点按业务比例配置节点间用RDMA网络至少25Gbps起步路由与协同一致性哈希 两阶段负载打分 sticky session亲和性可观测性OpenTelemetry链路追踪 Prometheus指标 节点级网络监控这个配置不是银弹但适合大多数以在线对话、内容生成、代码辅助为主要场景的推理业务。如果业务是离线批量推理可以适当放大Batch提高吞吐优先于降低延迟如果业务是超长上下文问答建议进一步强化Prefill/Decode分离和KV Cache传输通道。说到最后我再分享一条个人的实操体会分布式推理网络最大的敌人不是单点故障而是无法解释的长尾延迟。只要还有5%的请求慢得莫名其妙就说明系统里藏着没被观测到的协同问题。每次调优我都先回答三个问题这个请求走了哪条路径每跳花了多久为什么会选这条路三问对齐大部分坑都能提前避开。这套方法论比任何具体工具都管用。