当拥塞控制遇到AI,是新瓶装老酒还是旧貌换新颜?

视频会议里一句话卡成几段，游戏操作总慢半拍，下载进度条迟迟不动。 很多时候，问题不在于“网速不够”，而是网络中出现了拥塞。

可以把网络想象成一套不断变化的交通系统： 数据包是一辆辆车，链路是一条条有限宽的道路，路由器是道路上的收费站和交叉口。车来得太少，道路没有被充分利用；车来得太多，入口处就会排起长队，等待时间变长，严重时还会丢包。

拥塞控制（Congestion Control，简称 CC）做的，就是根据网络状况调节发送速率： 什么时候应该加速，什么时候应该减速，怎样尽量把道路跑满，又不把道路堵死。

01

拥塞控制已经被研究了几十年。Cubic、BBR、Vegas 等经典算法，主要依靠人工设计的规则运行。规则的好处是清楚、稳定，也容易分析和排查； 但它的局限同样明显：一套规则通常是在一些典型场景中调出来的，换一种网络环境、换一条链路、换一种时延，原本有效的控制参数就可能不再合适。

现实网络的变化远比一张实验室参数表复杂。 带宽会变，时延会变，丢包会变，缓冲区和背景流量也会一起变化，不可能为所有组合都提前写好控制规则。这也是人工智能技术进入拥塞控制领域的原因：让算法从大量运行记录中学习，使它能够根据网络反馈灵活调整，而不是只执行一套固定规则。

把 AI 接进来，拥塞控制的问题能解决吗？ 一个智能拥塞控制算法在有限的测试场景里获得了更高吞吐量，只能说明它“在这张考卷上答得不错”，还不能说明它可以适应真实网络。它可能记住了训练环境中的熟悉模式，但换到新场景就失效；也可能平时平均成绩很高，却在某个极端条件下突然做出危险决策。与此同时，也带来许多新的问题：算法失常时，能不能及时恢复？和其它传统算法、智能算法同时在网络中存在时，会不会把带宽都抢走？模型推理的计算和通信开销是否可接受？它能不能在实时系统中稳定运行，部署成本是否足够低？

这些问题共同指向一个更根本的判断： AI+CC 不能只验证可行性，还需要系统地回答它是否具备泛化性、公平性、鲁棒性等能力，以及最终能否成为真实网络中的可靠组件。

首先，一个关于模型泛化能力的具象问题摆在面前： 如果模型能够记住更多网络变化，能不能在没有见过的新场景里也做出较好的判断？

02

这其实是在考验智能拥塞控制算法的泛化能力。

所谓泛化，可以简单理解为：算法在训练时见过一些道路，换到没有见过的道路上，是否还能做出相对可靠的判断。如果模型只熟悉某种带宽、时延和流量组合，那么它在这些场景里的表现可能很好；但真实网络一变化，它就可能不知道该怎样处理。

拥塞控制还有一个特点：决策不能只依据眼前。 刚刚提高发送速度，排队可能过一段时间才出现；刚刚降低发送速度，网络也可能不会立刻恢复。算法需要记住一段历史，理解自己的动作和后果之间的联系。

在 DTCC 中，我们尝试用 Transformer 来处理这种带有时间顺序的决策过程。 模型不只看当前的网络状态，还会综合历史状态、过去采取的动作，以及动作之后得到的反馈。这样的输入方式，有点像开车时不只看眼前的路，还会回看刚才几秒钟的行车记录，判断自己刚才踩油门或刹车带来了什么结果。

DTCC根据多种算法的运行轨迹离线训练，再在线输出控制动作。

DTCC 还把多种拥塞控制算法在不同网络环境中的运行轨迹放在一起训练。 表现好的经验可以帮助模型学习有效操作，表现不理想的经验也能提醒模型哪些路况和动作可能带来风险。对于变化更快、数据更难稳定收集的动态蜂窝网络，我们结合较丰富的有线网络数据和较少的动态网络数据，让模型先获得基础经验，再学习复杂场景中的变化。

DTCC在不同网络环境下的吞吐量与时延表现。图中为归一化指标，不代表实际网速。

在 660 种有线网络场景的比较中，一组 DTCC 配置进入“优胜范围”的比例为 54.70%，Sage 为 37.42%。 这里的“优胜范围”并不是说 DTCC 在所有场景中都拿到第一名，而是指综合考虑吞吐量和时延后，得分达到该场景最高分 90% 以上。

这个结果说明，利用更长的历史信息和更丰富的运行经验，确实有助于模型在更多场景中取得较好的表现。但真实网络的变化仍然太多，单个模型即使训练得更充分，也很难把所有路况都覆盖。既然一个模型的经验总有边界，能不能把不同算法在不同场景中积累下来的经验都保留下来，在需要时相互补位？

03

一个驾驶员不可能熟悉所有道路，解决办法未必是让他无限增加训练时间，也可以让车队里拥有不同经验的驾驶员：有人擅长高速路，有人熟悉拥堵路段，有人更重视平稳和安全。遇到不同道路时，系统可以根据需要调用更合适的方法。

这启发了我们构建集成拥塞控制平面 ICCP（Integrated Congestion Control Plane）。 它把传统拥塞控制算法和智能拥塞控制算法都纳入一个统一的算法库，通过共同接口接入协议栈和运行系统。传统算法不是需要被 AI 替代的“旧经验”，它们在许多场景里积累的稳定做法，同样是智能算法可以参考的宝贵知识。

ICCP 的价值不只是把算法放在一起保存，更在于把算法的接入、状态采集、控制执行和模型推理组织起来。 不同连接可以使用不同的拥塞控制方法，新的定制算法也可以通过统一接口加入进来。这样，当某个场景下现有算法都不理想时，系统不必重新改造整套协议栈，就能更方便地接入新的解决方案。

需要说明的是，当前 ICCP 的重点是提供统一的集成与运行底座。 根据实时网络条件自动选择并切换最优算法，是在此基础上的进一步方向。算法库的意义，正是为这种持续积累经验、比较方法和逐步实现智能调度提供基础。

ICCP的三层组织方式：协议栈负责采集与执行，算法库负责管理不同拥塞控制逻辑，独立的智能决策服务负责模型推理。

算法本身做出好判断，还要有系统及时执行这个判断。 以三条连接同时运行 DTCC 的实验为例，在 48 Mbps 链路上，同步 CCP 方案的平均总吞吐量为 11.94 Mbps，ICCP 的异步、批量推理方案达到 44.56 Mbps。这是特定测试条件下的结果，并不意味着在所有网络中都能获得相同提升；它说明的是，模型的能力和部署方式同样重要。

如果每条连接都单独等待模型完成推理，多个连接一多，等待和调度开销就会成为新的瓶颈。 ICCP 通过异步处理和批量推理，让多个连接能够共享模型，同时保留各自的历史状态。对智能拥塞控制来说，这些系统层面的设计，决定了一个算法能不能从论文里的实验代码走向实时运行环境。

相同DTCC算法在不同部署方式下的多连接吞吐量对比。

算法库让我们不必把所有希望都寄托在一个模型上。 不同场景可以积累、调用不同算法的经验，从而进一步缓解单个智能算法泛化能力有限的问题。但问题并没有到此结束：即使多种算法在更多场景中表现不错，平均分不错，最坏的时刻又会怎样？

04

泛化关注的是算法在多个场景中的整体表现，可以理解为希望“平均分”更好。 但平均分好，不代表算法在最坏情况下也可靠。

一套固定测试集像一张统一考卷，适合比较不同算法，却未必能对算法进行全面的测试。 算法可能在大多数场景中得分很高，却在某类链路上突然降低利用率，或者让排队时延在很短时间内飙升。对网络用户来说，一次突然卡顿就足以影响体验。

因此，我们进一步探索对抗性评估： 由测试端主动生成扰动流量，调整突发流量的时机、持续时间和强度，尝试把被测智能算法推到更接近边界的位置。这里的“对抗”发生在受控实验中，目的不是破坏网络，而是提前发现算法最脆弱的地方。

它的作用机制可以沿着一条简单的链路来理解：扰动流量和被测流量共享同一条瓶颈链路，扰动端通过调整自己的发送行为，间接改变瓶颈处的排队、可用带宽和拥塞程度。被测流量的 RL 控制器并不会直接“看到”扰动端的动作，却会从反馈中感受到这些变化，例如往返时延、排队时延、吞吐率和丢包情况的变化。经过特定时序的扰动，这些观测可能把被测者策略推入训练经验之外的异常状态，使它难以及时做出高效的拥塞控制决策。

缓冲区大小会影响这种作用方式。在浅缓冲链路中，扰动流量更容易直接改变队列和链路利用率；在深缓冲链路中，短时扰动较难填满队列，却可能在某些关键时刻造成反馈突变，让被测算法骤然进入近乎不可用的低效状态。由此看来，算法的最坏情况不只取决于队列是否被填满，也取决于扰动是否击中了策略决策的脆弱边界。

Orca算法受到扰动流量影响的两组示例：左图为48 Mbps、20 ms、1 BDP场景，右图为48 Mbps、80 ms、4 BDP场景。黑色线代表扰动流量占有下剩余链路带宽。

对抗性评估由此把测试重点从平均表现推进到能力边界。 算法的薄弱环节往往藏在固定考题之外；只有主动制造困难条件，观察它如何失常、能否恢复，才能更接近真实网络中的可靠性问题。

前面我们已经分别讨论了泛化性、鲁棒性等，但仅有这些评估维度，仍然不足以回答一个算法能否进入真实网络。不同算法即使测量相同的吞吐量、时延或恢复能力，如果使用了不同的协议接口、应用流量和状态采集方式，最后的成绩也可能混入系统实现的影响。

因此，我们进一步设想一个开放的智能拥塞控制算法评估系统。它不仅要统一网络环境和评价指标，还要把统一推进到更细的层面：让算法尽可能在相同的协议栈、接口、状态采集和执行机制下运行。就像几辆车在同一道路上比赛，除了统一道路和计分方式，也要尽量统一车辆仪表和与道路系统交互的规则，这样比较结果才更接近算法策略本身。

05

在这样的考场里，我们目前可以继续追问：

- 在没有见过的新场景中，算法还能不能保持较好的表现？

- 遇到突发变化甚至恶劣条件时，最坏情况是什么，失常后能不能恢复？

- 多个智能算法共存，或者智能算法与传统算法共存时，资源分配是否公平？

- 模型推理和通信开销有多大，能不能满足实时系统的要求？

- 不同算法是否在同一套环境、同一套接口和相近的系统条件下接受比较？

这些问题是当前探索的起点，并不意味着评估维度已经穷尽。 随着智能拥塞控制进入更复杂的网络和更真实的系统，还可能需要进一步考察可解释性、可监控性、安全性、能源消耗和异常追责等问题。评估体系也应随着算法和应用场景的发展持续补充。

也正因为考题还会变化，我们需要一个能够持续接入算法、扩展评估维度、记录运行结果的系统。 这也是我们希望在 ICCP 集成算法库的基础上继续构建统一评估系统的原因：它既比较吞吐量和时延，也关注泛化性、鲁棒性、公平性、开销和可部署性等。

从设计上看，这个“考场”可以概括为三大部分：

场景配置。 设置瓶颈链路的带宽、时延、缓冲区和动态变化方式，并生成持续、突发或周期变化的应用层流量。

算法接入与编排。 系统尽可能兼容已有的多种传统与智能算法，使它们能够在同一套系统和协议环境下运行；新算法只需适配 ICCP 算法库的统一接口，即可较方便地接入和部署。系统还可以配置单条或多条连接，以及同构或异构的算法组合。

状态监控与评估。 持续采集吞吐量、时延、丢包、队列状态、链路利用率、恢复过程和推理开销等信息，进一步计算性能、泛化性、鲁棒性、公平性和可部署性指标。

在这个设计下，评估系统更像一套可以反复配置的实验装置：改变网络条件和应用流量，替换或组合不同算法，再从统一采集的状态中观察它们的表现。

在这样的统一平台上，所有算法不必追求同一个答案。 不同算法可以有不同的设计目标，但应该在清楚的测试条件和公开的评价维度下比较，尽量区分算法本身的提升与数据、平台、接口或部署方式带来的差异。

从这个角度看，这套系统更像智能拥塞控制的长期试验场： 算法库提供不同的“驾驶员”，统一平台提供相同的“车辆和道路”，测试则观察它们在日常和困难路况下的表现。测试中发现的问题，可以反过来成为下一轮训练和算法改进的依据。

由此，算法创新、压力测试和系统部署被串联进同一个过程， 形成了一个从算法到系统的可信闭环：算法可以比较，风险可以找到边界，公平性可以受到约束，安全性可以得到验证，部署可以有依据，出了问题也能够追溯和改进。

06

回到文章开头的问题：经典的拥塞控制引入 AI 之后，究竟发生了什么？ 把一个新模型装进 CC，就像给一辆旧车加装了自动驾驶系统。它也许能在熟悉的道路上跑得更快，却未必能在陌生道路、突然拥堵和突发情况时依然稳稳前进。

如果这些老问题仍然存在，模型虽然换了，拥塞控制仍可能只是换了包装，成为“新瓶装老酒”。

AI+CC 能否带来真正的变化，还要看这辆“新车”能不能经得起更长、更复杂的路试。 它需要走出训练场景，在压力和扰动下保持稳定，与其他算法公平共行，并以可接受的开销部署到实时系统中。

路试的意义不只是给算法打分。 更重要的是暴露它的短板，把问题带回模型、系统和部署环节，经过分析、改进和重新验证持续推进。前面的探索只是搭起了一段试验道路；当这些暴露出的边界和风险能够被系统地纳入研究与反馈，AI+CC 才有机会真正改变 CC 的旧有面貌，走向“新颜”。

如果把视野再放宽到整个网络，AI+CC 或许只是一个切口。 未来面对路由、资源调度等问题，也许同样可以从业务目标出发，把变化的环境和现实约束纳入决策，再让算法经历测试、上线和持续反馈。这样的思路能否延伸到更广泛的 AI+Net 场景，还需要交给更多问题和更长时间来回答。

07

技术创新从来不只有创造更强单点组件这一条道路。承认个体的有限，搭建释放多元个体潜能的系统，同样是至关重要的创新。网络的拥塞，既发生在数据包穿行的链路之上，也会发生在 AI 模型的计算队列之中，更横亘于学术理想走向工程现实的壁垒之间。

AI 可以教会系统读懂瞬息万变的数字路况，但技术真正的使命，从来不是寄希望某个天才模型一劳永逸地解决世间所有难题。“知人者智，自知者明”，对网络研究而言，“知人” 是善用 AI 之智，挖掘数据之中潜藏的网络规律；“自知” 则是清醒看见工具本身的局限，不被技术热潮裹挟，坚守网络研究的本源初心。

放眼更大的数字世界，这一道理早已超越拥塞控制本身：一切人工智能赋能基础设施的变革，成败往往不在于模型有多么炫目，而在于能否把先进的智能，安放于稳健的系统底座之上。不迷信单点突破，不追逐表面的浮华，以 “术” 精进能力，以 “道” 锚定方向，让技术的光芒穿过仿真实验室的象牙塔，真正落到亿万用户真实的网络体验之中 —— 这才是 AI 与网络融合，真正意义上的“旧貌换新颜”。