简介《2025分发式推理网络DIN技术白皮书》面向网络工程师、AI研究员、IT架构师与网络安全专家聚焦AI大模型爆发对网络流量模式的重构以及集中式部署带来的三大挑战系统给出中国移动提出的DIN架构方案。压缩包内含1个PDF文件大小1.37MB可直接阅读完整白皮书正文便于归档与检索。全文围绕基础设施能力不足、网络架构待完善、服务防护薄弱等问题展开详细讲解算网一体安全推理、边云协同后训练、模型分层协同、大小模型协同、训推协同进化、PD分离协同等端边云分布式协同模式并覆盖节点间互联质量保障、推理服务调度、推理安全防护等关键设计。读者可据此理解从集中式大模型部署走向分布式推理网络的落地路径把握多Agent、具身智能、IoT与AI融合等未来方向。目前已有142人学习浏览适合需要研判AI网络演进趋势并参与相关方案设计的专业人士。1. DeepSeek-R1 并发冲击与 DIN 的解题思路2025 年 1 月 20 日深度求索发布 DeepSeek-R1 之后行业里出现了一个此前少有人预判的现象一个开源权重模型的日活用户数在一个月内从 100 万冲到 3000 万API 调用成本压到 GPT-4-Turbo 的近百分之一推理速度还提升了约 4 倍。随之而来的不是庆祝而是服务器资源被瞬时打满、网页与 API 频繁返回繁忙提示以及针对推理服务的密集网络攻击。这个事件把 AI 推理从中心化集中部署的舒适区里拉了出来——单点智算集群再大也扛不住亿级用户的并发访问。中国移动在《分布式推理网络DIN技术白皮书》中给出的应对思路是把推理从单机单池变成端边网算一张网用运营商网络的协议可编程与流量感知调度能力重新组织 AI 推理的流量路径、计算位置和安全边界。对网络工程师、AI 研究员、IT 架构师和网络安全从业者来说DIN 不只是又一个架构名词它直接关系到推理服务怎么调度、算力池怎么互联、故障和安全事件怎么处置。2. 从集中式推理到端边云协同DIN 架构与协同模式选型2.1 集中式部署的瓶颈与 DIN 的架构起点大模型推理服务早期普遍采用中心化智算集群请求通过负载均衡分发到 GPU 节点。这套模式在模型迭代期和千人级并发场景下问题不大但当 DAU 达到千万级、每个用户一次请求又涉及多轮 Token 生成时瓶颈会同时在三个层面暴露出来。第一是算力维度。单集群的 GPU 总量决定并发上限扩容周期通常以月计无法适应推理需求的爆发式增长。第二是网络维度。用户集中在某一区域时大量请求要跨骨干网到达中心节点南北向流量激增复杂推理任务还会在通算、智算、存储之间形成高频流水线调用对时延的要求远比传统 Web 服务苛刻。第三是安全维度。集中式部署将攻击面也集中了针对 API 入口的拒绝服务攻击可以直接打垮整个推理服务。DIN 的架构出发点是用网络把分散在中心、边缘、端侧的算力组织起来形成一张推理资源池。与传统 CDN 缓存静态内容不同DIN 缓存和调度的对象是模型副本、KV Cache 以及推理任务的执行位置。这张网的核心能力来自运营商网络的三个存量优势协议可编程如 SRv6、Segment Routing、流量感知调度、确定性体验保障。2.2 六种端边云协同模式与选型对照白皮书把 DIN 的协同模式归纳为六种覆盖了从训练侧到推理侧、从大模型到小模型、从中心到边缘的多种组合。实际项目选型时可以先按业务诉求做初步映射。协同模式协同对象典型场景关键收益算网一体安全推理算力 网络 安全ToB 敏感数据推理数据不出域端到端加密边云协同后训练边缘增量数据 云端基座模型垂直行业微调、持续学习减少中心训练压力数据就近处理模型分层协同大模型 小模型分层部署服务大厅与终端场景降低单次推理成本提升响应速度大小模型协同云端大模型 端侧小模型移动端助手、IoT 设备先小模型兜底复杂请求再上大模型训推协同进化训练集群 推理集群模型高频迭代场景训练数据回流推理反馈闭环PD 分离协同Prefill 节点 Decode 节点长上下文、高并发对话降低首 Token 时延提高算力利用率PD 分离协同在工程上最值得注意。Prefill 阶段计算密集Decode 阶段访存密集两者对 GPU 资源的需求特征完全不同。把两者拆到不同的节点池可以让 Prefill 节点专门处理高吞吐的输入计算Decode 节点专注于 KV Cache 读写和逐 Token 生成两者通过高性能网络连接。DIN 架构中 PD 分离不只是资源池拆分还依赖网络层对两类流量做差异化调度这就引出后面要讲的微流级流控与细粒度切片。2.3 与现有 MEC 架构的差异很多团队已经部署过移动边缘计算MEC平台DIN 和它的区别主要在调度层级。MEC 通常将应用整体下沉到边缘节点调度粒度是应用实例。DIN 的调度粒度是推理请求和模型切分单元一个请求可以拆成多个阶段在不同节点执行比如 Prefill 在中心、Decode 在边缘或者小模型在端侧完成意图识别后再将复杂请求转发给中心大模型。这意味着 DIN 的控制面需要实时感知全网推理节点的负载、网络时延和带宽状态再根据请求的时延敏感度、数据隐私级别和模型大小做联合决策。3. 节点间互联质量保障微流级流控、细粒度切片与推理业务识别3.1 推理流量特征与普通互联网流量的差异传统互联网流量主要来自网页浏览、视频、文件传输特征是大象流占比高、时延容忍度较强。推理流量完全不同一次大模型对话请求会分裂成大量的小报文每个 Token 的生成都有严格的时延预算而且 PD 分离架构下 Prefill 与 Decode 之间是实时流式交互任何微小的抖动都会直接反映到用户体验上——表现为打字机输出卡顿。白皮书将节点间互联质量的保障拆成三个层次微流级流控处理毫秒级突发层次化细粒度切片处理业务优先级隔离推理业务识别则负责告诉网络这条流是什么类型、该走什么队列。3.2 微流级流控的令牌桶实现微流级流控的思路是不同于传统五元组流而是对推理应用流如同一个用户在一次对话中的所有 Token 流做更细粒度的速率控制。常见做法是采用令牌桶算法对关键推理流设置合理的突发大小和平均速率避免单个用户的突发请求排空队列影响其他用户。import time import threading class TokenBucket: def __init__(self, rate, burst_token250): self.rate rate # 令牌产生速率单位条/秒 self.burst_token burst_token # 桶容量用来吸收短时突发 self.tokens burst_token self.lock threading.Lock() self.last_time time.time() def _refill(self): now time.time() delta now - self.last_time self.tokens min(self.burst_token, self.tokens delta * self.rate) self.last_time now def try_acquire(self, num_tokens1): with self.lock: self._refill() if self.tokens num_tokens: self.tokens - num_tokens return True return False这段代码维护一个每秒按 rate 增长令牌的桶burst_token 决定最大突发能力。在 DIN 网元上rate 可以根据推理节点上报的容量动态调整当业务方调用try_acquire失败时网元会把请求标记为降级触发排队或走备用路径。实际部署时不要把 burst_token 设得过大否则瞬时积压会冲垮下游 GPU 的连续批处理队列。3.3 层次化细粒度切片白皮书强调的细粒度切片不同于 5G 网络的大粒度行业切片它要求在一个物理网络内为不同推理业务划分出不同优先级的逻辑通道每个切片拥有独立的带宽、时延和调度权重。高优先级切片承载 PD 分离后的 Prefill-Decode 实时流量中优先级切片承载端到端大模型推理请求低优先级切片承载模型分发、日志回传、后训练数据上传层次化体现在网络切片 队列切片叠加先按业务类型划出网络切片再在切片内部按 Token 流、控制流、数据流分别设置调度队列。此时微流级流控令牌桶的 rate 要和切片带宽配置联动否则切片内部的高优先级队列也会因流量整形不当而丢包。3.4 推理业务识别让网络看懂流的内容网络层要做精细调度前提是能识别流里承载的是哪种推理业务。传统 DPI 只能识别协议类型而 DIN 场景需要识别得更细比如是否为流式生成、首 Token 请求还是多轮续写、模型尺寸是大是小。实现推理业务识别时我通常会引入一组轻量模型离线训练在线对报文特征做分类分类结果用于映射调度优先级。from sklearn.ensemble import RandomForestClassifier features [ packet_size_mean, # 报文平均长度流式生成普遍偏短 inter_arrival_std, # 到达间隔标准差流式生成比较平稳 flow_duration_ms, # 流持续时间 direction_ratio, # 上行/下行字节比 tcp_window_mean # 平均窗口反映应用层缓存策略 ] clf RandomForestClassifier(n_estimators128, max_depth16) # 训练数据来自线上推理网关抓包标签为 prefill / decode / control / data # clf.fit(X_train, y_train) def classify_flow(feature_vector): prob clf.predict_proba([feature_vector])[0] if max(prob) 0.7: return unclassified # 低置信度流不要乱调度走默认队列 return clf.classes_[prob.argmax()]分类结果做软判决置信度低于 0.7 的流统一走默认队列宁可排在普通优先级也不要把关键队列的资源浪费在误判流量上。特征工程里inter_arrival_std是区分流式 Token 与批量数据最有效的指标之一。4. 推理服务调度的实现PD 分离协同与核心参数4.1 调度器的决策目标DIN 的推理服务调度不是简单的负载均衡它需要在全网范围内同时优化三个目标降低首 Token 时延TTFT、提高每 GPU 卡的 Token 生成吞吐ITL、控制端到端推理成本。这三个目标在资源有限时是相互制约的——把请求调度到负载最低的节点不一定时延最短因为网络路径可能更长调度到网络最近的节点也可能导致热点 GPU 排队严重。因此DIN 调度器采用多目标评分机制每个候选节点被分配一个综合得分得分由算力可用度、网络路径质量、数据合规约束、模型副本状态四部分组成。4.2 PD 分离下的调度逻辑PD 分离之后调度的对象从一个请求变成了一个请求的两个阶段。常见做法是 Prefill 承载节点按长序列计算能力排序Decode 承载节点按剩余 KV Cache 容量排序两者通过控制面消息关联。以下代码展示了一个简化的决策函数def schedule_request(req, node_registry): node_registry: list of dict, each with keys: node_id, gpu_free, kvcache_free, net_delay_ms, has_model # 阶段1选择 Prefill 节点优先考虑 GPU 显存和模型副本 prefill_candidates [ n for n in node_registry if n[has_model] and n[gpu_free] req.prefill_gpu_required ] if not prefill_candidates: return None, no_prefill_capacity prefill_node min( prefill_candidates, keylambda n: 0.6 * n[net_delay_ms] / 100 0.4 * (1 - n[gpu_free] / n[gpu_total]) ) # 阶段2选择 Decode 节点KV Cache 余量是最关键约束 decode_candidates [ n for n in node_registry if n[node_id] ! prefill_node[node_id] and n[kvcache_free] req.estimated_decode_tokens * req.kvcache_per_token ] if not decode_candidates: return None, no_decode_kvcache decode_node max(decode_candidates, keylambda n: n[kvcache_free]) return { prefill_node: prefill_node[node_id], decode_node: decode_node[node_id], }, okschedule_request先保证 Prefill 节点具备足够的 GPU 显存和模型副本再以网络时延和算力闲置率加权决定具体节点Decode 节点的选择则完全以 KV Cache 余量为准因为 Decode 阶段每生成一个 Token 都要读写 KV Cache容量不足会直接触发上下文换出比网络时延影响更严重。注意这里的kvcache_per_token需要根据模型的层数、头数和精度计算不同模型差异可达数倍。4.3 核心参数配置参考调度器上线后需要重点观测与调整的参数如下参数默认建议影响prefill_gpu_required模型全量加载显存 12% 余量设置过低会导致 Prefill 阶段频繁 OOMkvcache_reserve_ratio0.15预留安全水位防止长上下文突发写入net_delay_weight0.6网络权重过高会把请求都压在中心节点dispatch_interval_ms500控制面轮询周期过短增加网元负担local_queue_max8单节点排队上限触发背压扩散4.4 调度链路观测指标调度器跑起来之后光看 CPU 和网络监控不够建议直接对推理服务做端到端观测。用 Prometheus 表达式可以快速定位是调度问题还是节点性能问题# 推理请求排队时长按调度器实例聚合 histogram_quantile(0.95, sum by (le) (rate(mistral_request_queue_duration_seconds_bucket[5m])) ) # PD 分离后 Prefill 完成到 Decode 启动的间隔 avg(inference_pd_handoff_delay_seconds) by (prefill_node, decode_node)pd_handoff_delay是 PD 分离架构独有的关键指标它反映 Prefill 节点把中间计算结果传给 Decode 节点所花的时间。一旦这个值持续超过 50ms说明节点间网络保障不到位要回溯到上一章的切片与流控配置去排查。5. 模型推理安全防护PHYSec、拒绝服务防护与轻量化 APT 监测5.1 推理服务安全的特殊性推理安全与传统 Web 安全最大的不同在于攻击不仅影响服务的可用性还可能直接窃取模型参数、训练数据或用户的私有上下文。中心化部署时安全边界是清晰的所有防护都加在入口网关即可DIN 把推理能力分布到边缘节点后数据在节点间流转任何一段链路都可能成为窃听点。白皮书提出的安全体系沿着链路加密、流量清洗、行为监测三个层级展开。5.2 以太网相干 PHYSec 技术PHYSec 是白皮书里比较独特的一项技术它在物理层对以太网相干光模块的比特流做加密。相比 IPsec 或 MACsecPHYSec 不修改报文头不增加封装开销加密过程对上层协议完全透明因此不会引入额外的帧间隙和处理时延。这一特性使其非常适合承载 PD 分离节点间的高频实时数据交换。在实验室环境中没有相干光模块也可以用 MACsec 验证类似的链路层加密效果# 创建 MACsec 安全通道模拟 PHYSec 的应用层效果 ip link add macsec0 link eth1 type macsec cipher aes-256-gcm ip macsec add macsec0 tx sa 0 pn 1 on key 01 00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff ip macsec add macsec0 rx sa 0 pn 1 on key 02 00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff ip link set macsec0 up配置中cipher aes-256-gcm使用 GCM 模式同时提供加密和完整性校验pn是包序号用于抗重放。PHYSec 的实际价值在于把这项工作下推到物理层网络设备 CPU 完全不参与加解密加密带来的时延几乎为零。5.3 拒绝服务流量防护DIN 场景下 DDoS 防护的难点在于区分真实推理请求洪峰和攻击流量。DeepSeek-R1 事件显示业务正常增长带来的流量也能打垮服务器更不用说叠加攻击流量。防护组件建议部署在中心入口和边缘节点两级边缘优先做本地丢弃中心负责全局牵引。一般会用基线学习来动态判断流量异常。一个可落地的方案是采用 EWMA 模型跟踪每个模型服务的请求速率基线class EWMARequestRate: def __init__(self, alpha0.05, threshold_ratio5.0): self.alpha alpha self.baseline None self.threshold_ratio threshold_ratio def observe(self, current_rps, now_ts): normalized current_rps if self.baseline is None: self.baseline normalized else: self.baseline self.alpha * normalized (1 - self.alpha) * self.baseline alert False if self.baseline 0: ratio normalized / self.baseline if ratio self.threshold_ratio: alert True return alert, self.baselinealpha0.05的平滑系数让基线缓慢跟踪正常业务波动不会因为短期高峰如活动促销而误报threshold_ratio5意味着当前请求速率达到基线的 5 倍才触发告警。实际部署时建议结合 Token 消耗速率一起判断因为攻击流量通常不消耗 Token单位请求的 Token 成本远低于正常推理。5.4 轻量化 APT 监测中心机房的完整 APT 检测平台移到边缘节点是不可行的因为边缘节点的算力非常有限还要满足实时推理的算力预算。轻量化 APT 监测的思路是用小模型把网络行为浓缩成摘要仅在行为异常时回传中心做检测。白皮书给出的方向是在边缘网元上做特征采集包括异常的外部连接频次、DNS 请求的熵值变化、模型加载接口的访问模式突变等。我建议在此基础上增加一个简单的统计检测统计边缘推理网关的连接建立速率与失败率二者同步飙升往往是扫描或暴力尝试的前兆。注意不要在边缘节点跑重型的流量回放和沙箱分析否则推理任务会和安全任务抢 GPU导致业务质量下降。6. 验证方法与排错从 INT 观测到调度抖动排查DIN 项目推进中最常见的两个问题一是调度链路通了但首 Token 时延不稳定二是安全清洗误伤正常推理请求。建议按以下顺序做验证与排错。先用带内网络遥测INT确认报文在多跳转发中的实际排队时延。INT 数据可以通过独立遥测包导出也可以直接读取网元计数器做汇总# eth1 出向队列丢包与延迟每 10 秒采样一次 ethtool -S eth1 | egrep tx_queue_[0-9]_dropped|tx_queue_[0-9]_bytes某个队列的 dropped 持续增长说明微流级流控的速率参数设置过低切片的带宽配置与实际流量模型不匹配优先调大该队列对应切片的保证带宽再回看 burst_token 的配置。其次是 PD 分离的pd_handoff_delay如果频繁抖动抓包查看 Prefill 到 Decode 的 TCP 流窗口。如果窗口频繁收窄大概率是节点间往返时延过大或中间链路出现了拥塞。此时不要急着增加带宽先确认是否所有 Prefill 节点都调到了高优先级切片很多情况下是配置漏掉了一组网元。安全功能验证要避免用生产流量测试。建议单独拉一条测试链路先用脚本构造与正常业务形态一致的低速请求再叠加异常流量源逐步调大速率观察 EWMA 模型是否在预期间隔内触发告警。确认无误后再将安全策略灰度切流到 10% 的推理流量观察一周比较识别准确率与误杀率。实际上线时我会把安全组件的 CPU 配额限制在节点总 CPU 的 10% 以内超过就触发降级保证安全组件本身不会成为新的瓶颈。最后要记住一条经验DIN 的问题很少单独出现在算力或网络上多数故障是调度器把请求送到了一个网络指标很好但模型副本版本过旧或 KV Cache 水位异常的节点。排错时把推理服务的日志、调度器的决策记录、网络设备的流日志三者拉到同一时间轴才能定位到真正的根因。本文还有配套的精品资源点击获取
