简介这份2025年分布式推理网络DIN技术白皮书由中国移动研究院出品面向网络工程师、AI研究员、IT架构师和网络安全专家。资源为单个PDF压缩包仅1.37MB已有143人学习。白皮书从AI大模型的典型应用切入分析规模化部署对网络流量模式的影响针对基础设施能力不足、网络架构待完善和服务安全防护薄弱三大挑战系统提出DIN架构依托协议可编程、流量感知调度、确定性体验保障和安全防护能力给出算网一体安全推理、边云协同后训练、模型分层协同、大小模型协同、训推协同进化、PD分离协同等端边云协同模式。读者可掌握节点间互联质量保障、推理服务调度和推理安全防护等关键技术理解分布式推理网络如何支撑普惠AI落地并展望多Agent、具身智能和IoT与AI融合趋势。1. DIN是什么当单卡放不下模型时把推理请求拆出去算一张 A100 的 80G 显存装下 700B 模型装不下。把模型切成几十份塞进多卡甚至多机又带来通信开销和编排复杂度。很多团队卡在这一步模型并行做不动单机又跑不起来。分布式推理网络DIN给出的思路是把推理请求当作分发单元——请求拆出去、算完再汇回来而模型权重仍然可以完整落在每个执行节点上或按需分片加载。2025 年这份 DIN 技术白皮书讲的正是这套面向推理服务化的分发架构路由怎么选节点、调度怎么防倾斜、结果怎么对齐。它解决的不是训练问题而是推理服务化里延迟、吞吐和弹性的三角矛盾。适合正在做模型服务平台、推理网关或大模型应用后端的人读也适合想搞明白“多机推理到底怎么做”的架构师。2. DIN的架构骨架控制面与数据面分离的五个核心层白皮书里把推理网络分成五个层次接入层、路由层、调度层、执行层、可观测层。前两层偏网关语义中间两层是分发核心最后一层是整个系统的后悔药。很多人刚上手时只关注执行层的推理引擎结果网关和调度写得很薄一上线就暴露问题。先把这五个层次拆开讲清楚。2.1 路由层请求落到哪台机器轮询是最不靠谱的方案路由层干的事是回答一个问题这个请求该发给谁。看白皮书前我以为按轮询或者随机就够了实际做下来发现这是最容易翻车的地方。推理请求不像 Web 请求那么均匀同样的模型有的输入长、有的输入短生成长度差异能到几十倍。轮询策略会让短请求排在长请求后面P99 直接失控。路由决策一般看三个信号节点的实时延迟、节点的排队长度、节点的亲和性。实时延迟用滑动窗口的 EWMA指数加权移动平均来算最近 5 秒的延迟权重最大。排队长度看执行引擎的请求队列现在积压了多少。亲和性解决的是缓存命中问题同一个模型的请求尽量打到同一个节点让 KV cache 或模型权重驻留内存避免频繁换入换出。三种常见路由策略的取舍策略决策依据优势劣势最低延迟路由EWMA 延迟估计算法尾延迟表现好热点切换频繁缓存命中率低最少连接数当前在途请求数实现最简单没考虑请求体量差异亲和性哈希模型 ID / 用户 ID 哈希缓存命中率最高节点扩容时重映射有扰动我一般会把亲和性哈希作为主策略再叠加一个延迟惩罚因子。请求先算哈希落到候选节点组再从组里挑延迟最低的。这样既保住了缓存收益又避免某台机器被打成热点。2.2 调度层DIN切的是请求不是切开模型权重分布式推理常见的误解是把 DIN 和模型并行混为一谈。张量并行是把 transformer 的权重矩阵切到多张卡上每张卡算一部分通过 AllReduce 同步。流水线并行是把模型按层切段前一个阶段算完传给后一个阶段。这两种方式都属于“切开模型权重”的思路通信开销大而且对卡间互联带宽要求很高。DIN 走的是另一条路模型权重保持完整副本或按需分片加载到每个执行节点调度层只负责把请求分发到合适的副本上。这里的调度和负载均衡不同负载均衡默认所有节点能力一样而调度要感知每台机器的显存水位、GPU 利用率、正在执行的批大小然后决定“这个请求现在发过去是不是会挤爆显存”。调度层的关键参数是并发上限和批处理窗口。并发上限决定单个执行节点能同时处理多少个请求超过上限的请求在调度层排队而不是打到引擎层。批处理窗口决定调度层攒多久的请求再一次性下发窗口越大吞吐越高延迟也越高。白皮书里提到一个经验值批处理窗口不要超过目标 P99 延迟的五分之一。假设业务要求 P99 500ms批处理窗口就设在 100ms 以内否则排队等待的时间就把延迟预算吃光了。2.3 执行层推理引擎的幂等性和结果汇聚执行层是真正算模型的地方。DIN 对执行层有一个硬性要求幂等。同一个请求重试两次结果必须一致。大模型推理不像普通接口同样一个 prompt温度大于 0 时两次生成结果完全不一样。所以执行层要么支持请求 ID 去重要么在重试时明确语义——是重新生成一遍还是返回上一次的结果。结果汇聚有两种模式。第一种是同步汇聚适用于完整的推理响应所有分片或副本算完网关做结果合并再返回。第二种是流式汇聚适用于 token 流式输出谁先返回就先把 token 推给客户端等所有节点都完成后再补齐。DIN 的典型做法是混合使用短请求走同步长生成走流式。合并结果时还有一个坑如果多个节点同时算同一个请求来做容灾网关必须能区分“副本结果”和“不同请求的结果”否则会出现把两个不同生成结果拼接在一起的 Bug。2.4 可观测性黑匣子必须接上三根管道推理网络比单体服务难排查得多因为同一个请求经过了网关、调度器、执行节点三段路程。白皮书里最值得抄的是一张观测项清单三根管道必接。第一根是链路追踪每个请求从接入层就带上 trace ID贯穿路由、调度、执行全过程。第二根是节点健康探针不是简单的 TCP 探活而是发一个真实的推理探针请求测时延、测显存余量、测队列深度。第三根是队列水位观测调度层和执行层各自的排队长度要能实时看到。观测数据的落盘方式也得想好。我见过直接用关系型数据库存链路追踪数据的量一大就卡死。常见做法是时序数据库存指标、对象存储存 trace 采样。采样率按需调线上全量采样撑不住一般按 10% 采样排查特定问题时再临时调到 100%。3. 部署一个最小DIN集群从角色分工到服务注册读完白皮书架构部分下一步就是落地。这里给出一套最小可运行的部署路径三个节点就能把 DIN 跑起来后续再横向扩容。所有配置都按白皮书推荐的默认值来实际生产环境再微调。3.1 角色分工控制、执行、网关的拓扑设计最小集群至少需要三个角色网关节点负责接收外部请求控制节点负责路由决策和服务发现执行节点真实跑模型推理。生产环境里网关和控制节点通常会分开部署但最小集群可以把两者合并到一个节点上节省机器。节点职责分配表节点角色数量核心职责配置建议网关 / 控制1接入、路由决策、服务发现、健康检查CPU 8C / 内存 16G不需要 GPU执行节点2模型推理、批处理、结果上报按模型大小配 GPU显存至少能容纳模型权重配置中心1可复用存放节点元数据、版本号、路由策略三节点 etcd 或单机 Consul有人会问控制节点挂了怎么办。答案是网关节点上缓存一份路由表的本地副本控制节点恢复后增量同步。这样控制节点故障期间路由决策不中断只是新节点注册暂时不生效。这是白皮书里提到的降级策略我用下来觉得非常实用。3.2 服务注册与节点发现掉线是第一要处理的故障DIN 集群里的每个执行节点启动后要主动上报自己的信息包括 IP、端口、模型名称、版本号、显存总量、当前负载。网关通过这些信息构建路由表。注册信息用 JSON 格式上报示例{ node_id: exec-01-a1b2c3, group: prod-llm, models: [ { model_name: qwen2.5-72b, model_version: 2025.03.14, replicas: 2, gpu_total: 80, gpu_used: 45 } ], capabilities: [text-embedding, token-stream], health: { status: ready, queue_depth: 3, avg_latency_ms: 120 } }注册信息的 TTL 一般设 10 秒到 30 秒。节点每 5 秒续租一次如果网关超过 TTL 没收到续租就把该节点标记为不可用停止分发新请求。TTL 太短会导致网络抖动时节点被误摘除太长会导致故障发现太慢。生产环境我一般用 15 秒 TTL、5 秒续租间隔这是一个比较均衡的取值。这里还有个细节节点上报的gpu_used是动态值推理引擎的显存会随批大小变化。网关不能拿这个值做精确的容量判断只能做粗粒度的过滤。真正决定能不能接请求的是节点自身的排队深度和推理引擎的并发上限。3.3 健康检查与预热刚拉起的节点只能接十分之一的流量新节点注册完成后不能立刻接入全量流量。原因很简单模型权重加载需要时间显存里还没有缓存第一个请求会经历冷启动延迟可能比正常延迟慢 5 到 10 倍。DIN 的预热流程就是来解决这个问题的。推荐的四步预热流程节点启动加载模型权重到显存这个过程可能耗时 30 秒到几分钟取决于模型大小。节点自检执行一次完整推理确认输出形状正确、延迟在预期区间。预热请求网关发一批固定 prompt 的真实推理请求让节点的缓存生效同时拉起 GPU 的算力调度。放量接入先放 10% 流量观察 2 分钟确认 P99 延迟稳定后逐步增加比例每 30 秒增加 10%。这个预热流程很容易被跳过因为本地测试时模型的加载是同步的感觉不到冷启动有多严重。但线上流量是持续的节点刚注册就被灌满第一批请求的延迟会把 P99 拉到离谱的高度。白皮书里提到一个经验数据预热充分的节点和没预热的节点相比P99 延迟差距能到 3 倍以上。4. DIN部署避坑指南五个让推理集群翻车的经典场景架构和部署都说完了下面写踩坑记录。这些都是真实环境里反复出现的问题每条按现象、原因、解决三步写清楚。4.1 慢节点拖垮尾巴延迟P99 从 80ms 涨到 2s现象集群整体负载不高但 P99 延迟突然恶化而且持续恶化重启网关没有效果。原因某个执行节点的 GPU 因为散热或共享资源问题性能下降处理速度变慢。由于路由策略没有感知延迟变化仍然按亲和性哈希把大量请求发到这台慢节点。请求在慢节点堆积越堆越慢形成正反馈循环。解决在路由策略中加入延迟惩罚因子。网关每次收到执行节点的状态上报时计算一个 EWMA 延迟值超过集群中位延迟 2 倍以上的节点暂时从候选节点组中摘除。恢复条件是该节点的 EWMA 延迟连续 1 分钟低于中位延迟的 1.5 倍。我还会加一个最大连续服务时间限制超过 4 小时的节点主动轮换避免慢节点问题长期潜伏。4.2 幂等性没做好同一请求被算了两遍现象客户端收到超时后重试最终拿到两次不同的生成结果业务侧发现计费次数翻倍。原因执行层的推理引擎没有做请求 ID 去重。网关的超时重试机制重新发了一个新请求由于生成类模型的随机性两次结果完全不一样导致两个结果同时被计费。解决网关在请求头里注入全局唯一的请求 ID执行层用 Redis 或本地 LRU 缓存维护一份已处理请求表。相同请求 ID 再次到达时直接返回上一次的结果。注意缓存 TTL 要大于网关的最大重试窗口否则重试请求到达时缓存已经过期还是会重复执行。经验值是缓存 TTL 设为网关重试窗口的 2 倍。4.3 重试风暴压垮控制面所有节点同时失联现象执行节点集体报告与网关的连接超时集群短暂不可用随后恢复但恢复后又是一阵剧烈的抖动。原因客户端设置了固定的重试间隔比如 500ms。当一次网络抖动导致一批请求超时后所有客户端在同一时间点发起重试瞬间打满网关的线程池。网关处理不过来又导致新一轮超时形成重试风暴。解决重试策略改为指数退避加随机抖动。第一次重试等待 500ms第二次 1s第三次 2s每次叠加一个 0 到 100ms 的随机偏移。另外在网关侧做熔断保护单节点错误率超过 30% 时直接摘除节点而不是继续往上面堆请求。这个参数不能定死要按业务的容忍度来调。4.4 模型版本不一致A 节点和 B 节点推理结果对不上现象同一模型的两份副本返回结果不一致并且是持续性的不一致不是随机波动。原因模型热更新时一个节点的权重文件已经更新到新版本另一个节点还在跑旧版本。由于路由策略没有强制版本匹配同一个用户的请求可能被分到不同版本的节点上得到不同答案。解决路由决策强制加入模型版本校验。注册信息里的model_version作为分发依据网关只把请求发给与路由表中当前激活版本一致的节点。版本切换时不要全部节点同时更新按批次灰度每批节点更新完成后观察延迟和准确率再切下一批。这是白皮书里唯一明确建议“不要省”的流程。4.5 批处理窗口拍脑袋定吞吐和延迟互相伤害现象调大批处理窗口后吞吐确实涨了但 P99 延迟翻了不止一倍部分请求的超时率飙升。原因批处理窗口设得太大请求在调度层等待的时间超过了业务容忍极限。比如窗口设为 500ms但业务 P99 要求 800ms光排队等待就占掉了大部分预算推理本身的时间所剩无几。解决批处理窗口按照目标延迟预算反推。公式很简单窗口上限 目标 P99 延迟 × 20% - 推理预估耗时。比如目标 800ms推理本身预估 400ms那窗口最多设 160ms 减去 400ms 为负说明目标定得不现实要么换更强的推理硬件要么降低批大小。窗口设好后还要做一次压测验证确认 P99 达标后再定稿。5. 验证DIN收益压测两条关键曲线和一次故障注入部署完成后需要验证这套架构的真实收益。这里给出两条必做的压测曲线和一次必做的故障注入试验。5.1 吞吐-延迟曲线找到集群的拐点压测的目标不是测最大吞吐而是找到吞吐和延迟的交点。做法固定请求体大小和并发数从低并发开始逐步加压记录每个并发档位下的 OPS每秒请求数和 P99 延迟。画出两条曲线后找一个点在这个点之前吞吐增长明显而延迟增长平缓过了这个点每提升一点吞吐P99 延迟就跳升一次。这个点就是集群的推荐运行水位日常流量控制在这个点的 80% 附近。我做过一个 8 节点推理集群的压测单节点并发 4 时 P99 是 120ms并发 8 时是 150ms并发 16 时直接跳到 480ms。最终把推荐水位定在并发 6。很多人喜欢把机器压到极限追求硬件利用率但推理集群的核心指标是延迟稳定性不是 GPU 利用率。这个压测思路希望帮你在“省机器”和“保体验”之间找到自己的平衡点。5.2 故障注入单点宕机后看什么每次改完集群配置我都习惯做一次故障注入试验。方法很直接挑一个执行节点直接杀进程然后观察三个指标。网关发现节点失联要多久正常情况下应该在 TTL 内即 15 秒左右未完成的在途请求有多少被重试到其他节点重试后成功率和 P99 延迟有没有明显恶化。做过一次试验发现网关要 40 秒才把故障节点摘除原因是健康检查探针间隔设得太长和 TTL 不匹配。调整探针间隔到 5 秒、TTL 保持 15 秒后故障发现时间缩短到 10 秒以内。故障注入的价值就在这里它不是验证系统能不能扛住而是验证系统的故障发现能力到底有多快。慢节点、节点宕机、网络分区这三种故障都要分别测一遍场景不同对应的处理路径也不同。这套 DIN 部署方案我从最小集群搭到多组集群中间踩过版本不一致的坑、吃过重试风暴的亏后来养成一个习惯任何路由策略和调度参数改动先压测再灰度最后做一次故障注入收尾。希望帮到你。本文还有配套的精品资源点击获取