从 5 月份开始，大概花了四个月时间在淘天的网络组做端到端拥塞控制优化。说是做拥塞控制的优化，其实是训练一个模型动态选择合适的拥塞，本质上是一次 CCS 方向的科研。之前一直没怎么经历过完整的科研流程，这次经历算是弥补了此前缺少的毒打。

AI4System

现在主流的 AI4System 无非两条路：

  • 用 LLM 的生成能力做赛博劳工
  • 训练一个感知机做浅层分类

前者在前两年还以代码生成为主，画了很多饼：基于 LLM 的测试框架生成、用 LLM 生成一堆领域内算法做排列组合……但现在都 2025 年了，大家对 LLM 能生成出来个啥多少都有点 B 数，故事就很难吹下去；现在反而更多是往 Agent 这个原本大伙都不太看好的、看似没啥技术含量的方向发展。记得在 2024 年上半年，大家都对 Agent 嗤之以鼻的时候，jyy 就在 OS 课上非常坚定地认为这是个合理的方向，在此给 jyy 的精确预判跪了。

后者就很有意思，在我看来多少有点 AI4Sci 那种蹭流量的意思在了。一方面，系统里确实存在大量的分类任务适合上 ML：这些任务现在的算法大多基于经验设计的规则系统，且存在多种帕累托最优的算法导致不能盯着某个指标说谁更好；另一方面，ML 对某些系统关键组件的开销又实在太大，很难做好开销和精度之间的 tradeoff。这导致近些年做出来的 AI4System 工作有不少在浑水摸鱼，CCS 领域比较有代表性的有：NetLLM（大炮打蚊子，又重效果又差，很不 System）、AliCCS（本身是一个很好的工作，但跟 ML 关系不大）、Floo（复现不出来，怀疑美化过数据）。

用 AI（尤其是 LLM）去作为感知机代替一些经验组件，在我看来目前是得不偿失的。很多基于经验的规则已经把指标优化到极致，打着「通用性」的旗号上 AI 在大多数场景里会退化到只能做长尾优化；必须选择一个非常合理合适的场景，AI 可能才会有很大用处。但话又说回来，这不是与「通用性」相违背吗？一边局限在一个特定的业务场景、一个特定的决策组件上做实验，一边倚靠 AI 模型的能力大谈泛化性能，是不是有点没必要。

以目前的算力价格，想让 ML 全量接管某个 System 组件几乎是不可能的。即使是用 Qwen3 0.6B 这样轻量化的模型，在淘宝内只接入某个大部分人听都没听说过的页面流量的 CC，一张 T4 都不太打的住。这样一算，做这件事的经济收益是绝对的负数；更不要谈接入 GPU 算力所带来的架构更改和部署问题了。反而是 AliCCS 那样：主体部分还是经典算法、做一个轻量到可以本机部署的 ML 去高频决策才能保证落地。

总体上看，我对 AI4System 的前景还不是那么乐观；Agent 或许是一个 Promising 的方向，但我们能做的工作目前看上来还非常有限。让跟 AI 的人继续吃肉，我去 System4AI 喝汤好了。

端到端的拥塞控制

由于我的主要课题是训练 AI 选择一个 CC，通过这段时间的推导和实验，对一些经典的四层端到端 CC 建立了基础的认识；此处推荐知乎上的 anonymous 皮鞋哥，对理解 CC 很有帮助。

个人理解下来，端到端拥塞控制的主要难点有三方面：

  • 你无法精确地测量到网络环境，但建模时的假设都依赖精准测量
  • 你无法实时地获取测量参数，至少有一个 RTT 的延迟；断网时直到网络恢复前你都不知道发生了什么
  • 你无法保证别人的策略不会挤掉你的生存空间

对于第一点，很多算法都过于乐观地预估了信息的精确性。我遇到的一个例子是 Copa：在单机 Mahimahi 的模拟环境里，Copa 的性能断档式吊打 BBR/Cubic/Vegas 等一众 CC，但是部署到生产环境里甚至比 BBR 略差。RTT 的一阶导这种高阶信息在生产环境中变数太大，极有可能受到背景流和弱网波动的影响，导致 Copa 始终无法收敛到一个合适的带宽；更何况背景流里的大量 Cubic 在弱网环境里本身就不太稳定，导致收敛目标值也一直在变化。如果没有专线环境，那你就得假设你的信息是二手的、有噪音的信息，不要试图捕捉他的高频特征。

第二点在数据中心拥塞控制领域内已经被用各种方式试图解决了，从 TCP-ECN 到 RoCEv2 都在尝试将拥塞控制转为拥塞避免：如果我能够保证每一跳都不会发生排队，以跳为单位管理拥塞，那显然比端到端的拥塞控制要灵活、敏捷得多。但很可惜，对于正常的生产环境而言，你没有专线保证数据包出 CDN 后一路跑到客户端的链路上都部署和你相符的 FC 算法。对大部分公司而言，FC 还只能在内网机房部署，搭配多路径可以平摊内网链路压力；公网环境的不可控还是需要对外业务采用端到端 CC。

第三点非常有趣：“你永远不能仅凭 BBR 的吞吐更高就说 BBR 比 CUBIC 更好”。当背景流全是 Cubic，你打一个 BBR 上去，看起来效果很好；代价是其余所有 Cubic 流都在变差。公网带宽只有这么多，在 CC 上继续雕花就是在零和博弈里把对手干掉；同时公平性又保证了所有人都卷完之后又回到老样子；然后大家继续研究怎么把这个 CC 给干掉。一个好的拥塞避免策略应该是拓展系统的能力边界，比如减少 inflight（BBR），比如快速收敛 （AIMD），比如预防拥塞（DCQCN）；而不是利用别的 CC 的弱点抢占他的资源，导致看上去很有优势。

以上只是一些个人感想，不构成分享，欢迎吵架。