TL;DR
前几日发生过几个技术讨论, 讨论到该不该做的时候, 都谈到这事算不算“屎上雕花”:
同事A: 我们在讨论一些可靠传输和ScaleUP的事情, 具体的内容涉密就不多说了, 大致就是省这么点收益也不大到底做不做? 朋友B: 讨论 BPO 和 Score centering 的时候, 是不是抄了一下 SC 就好了, 我认为可能需要更细致的讨论在 Sparse Attn / MoE 的情况下, 以及超长程的 Agent Trajectory 在 Off-policy 下可能会经历多段不同的 Rollout Model 产生的 Logits, 以及 token level 和 chunk level 的 credit 如何处理等细节问题. 朋友C: 在讨论一些 Attention 相关的 KV 设计, 起因是 Seed 一篇讨论 DeepSeek 的 CSA 一类的 Chunkwise Compression 的处理, 是否要引入 Context Aware Chunking. 朋友D: 新的一些 GPU 架构的讨论, 关于数据依赖如何处理的问题, 也涉密不能多说.
到了 AI 时代需要考虑的东西更多, 底层的技术原理本身大家差异都不大, 而各种细节的 tradeoff 堆叠在一起便会产生巨大的差异. 因此技术决策上有了很多工程细节的东西需要处理, 是“屎上雕花”还是“精雕细琢”很多技术管理层的领导无法在第一时间分辨, 用于决策的汇报材料中的技术细节也因为层层汇报信息逐渐压缩, 变成了简单的“功能”有无, 或者局部的 benchmark 优劣. 最终技术领导的认知能力和细节的把控能力成为成败的关键.
因此想拿几个小事为引子, 来谈谈“雕花”的艺术.
1. 谈谈芯片架构
最近看到CUDA 13.4 增加一个 Locality Domains[1] 的功能. 实质上就是一些 NUMA aware 的内存分配. 其实当 L2 Cache 被划分为两个Partition 的时候已经有很明显的内存访问延迟差距了. 当然我能理解 NV 为了维持统一的内存访问这个简单的编程接口和生态的初衷, 在 Blackwell 这一代上也勉强能够维持住, 但在 Rubin 上随着 HBM 的带宽加的更大以及 cross die 的 NV-HBI 带宽以及延迟的约束, 走向 NUMA Aware 的路径已经是必然趋势了.
按照传统的决策路径来看, 例如在早先的一些 AMD 卡上, 考虑到 L2 的架构写代码确实很烦, 如果能够继续维持 UMA 不感知 L2 Partition 确实是一个更优的选择. 对于 NV 的 Blackwell 是不是要做 NUMA Aware, 当然也有一些办法可以弄, 例如根据内存地址逆向出一个Hash函数来做一些 Location aware 的 malloc 或者 Swizzle的处理, 但是整体来看收益并没有多大. 那么即便做了或许也是属于“屎上雕花”.
但是在 Rubin 这一类的卡上, 这个能力就要暴露出来了, 虽然你还可以和以前一样使用 UMA 的编程方式, 但是为了极致的性能收益在算子中引入这些能力便成了“精雕细琢”.
进一步展开这个问题, 如果你要设计一颗新的 GPU, 那么你是否还需要维持 UMA 或者所谓的 CUDA 生态兼容? VLIW 是否值得再去看看? 历史上 VLIW 的失败案例数不胜数, 并且如果从传统的芯片设计工程师的角度来看可能还会继续维持 SIMT 这类的编程接口, 但是这些决策在 AI 时代或许应该有些改变了. 当然很多涉密的内容就不展开了.
这件事想说的是“屎上雕花”还是“精雕细琢" 可能还需要在更长的时间维度上去看, 并结合整体系统的变化和约束, 并且不要被过往的经验人为的封锁住一些探索的空间.
2. 谈谈互联
其实对于任何一个搞互联的人, 通常最简化的模型就是: 带宽多大/延迟多大/每秒消息数能做到多少. 很多产品设计的指标和决策都陷入到这种 micro-benchmark 中. 但是实际上业务要什么? 前段时间我们某个模型线上推理把 PD 分离从 TCP 换成 eRDMA, 其它什么都没有改, 线上的实际 TTFT 降低了40%. 而同等的另外某知名的网卡延迟更低/每秒消息数更高, 但实际的收益只有 10%. 延迟降低40% 也就等同于 tpm 性能提升了接近 1.6 倍, 这个收益是非常巨大的.
原因很简单, 在线业务中 TCP 和 RDMA 混跑时的拥塞控制和长尾延迟抑制上. 传统的 RDMA 为了片面的追求高消息速率和超低延迟, 在可靠传输和拥塞控制上都有大量的简化. 而当你把这些细节日积月累的打磨干净后, 出现了显著的性能提升. 但是你如果单看任何一个细节, 仿佛都是在“屎上雕花”, 至少从 microbenchmark 的角度, 或者一些单从网络指标的角度看都是些很微乎其微的收益.
另一个涉及 KVCache 服务的业务, 由于资源调度的限制需要跨 AZ, 某家跨 AZ 还专门搞了一个名词 Scale-Across, 但基本上处于不可用的状态, 被迫回退到 TCP 上处理. 前几天也是一个非常简单的修改, 跨AZ场景下, eRDMA整体在 KVCache 业务上的延迟比 TCP 下降了 50%.
其实很多时候, 我们在做一些设计时很容易陷入到 microbenchmark driven 的工作模式中, 不光是互联的芯片, 在 GPU/XPU 上也是这样, 因为领导开发布会的时候基本只谈 算力FLOPS/ HBM带宽/互联规模等 microbenchmark, 这也是国内这些年很多加速器架构和编程生态非常割裂的原因. 以前也写过一篇文章《谈谈芯片设计的一些取舍》 就不多展开了.
这件事想说的是“屎上雕花”还是“精雕细琢" 不要以 microbenchmark 来评估, 更多的是站在整个系统 E2E 的视角进行分析.
3. 谈谈算法
做量化交易也快15年了, 大概10多年前做自己的量化交易系统的时候, 由于国内几个交易所的网络都是我设计的, 并且很多券商的高频交易相关的设备也是... 但是如果我自己去搞高频, 大概率会被入刑. 因此整个量化算法设计初衷就变成了一个中低频的策略. 算法本身是很简单的一个原则: 多因子模型涉及大量的拟合回归以及频繁的策略调整和模型迭代. 这个时候也有大量的“屎上雕花”还是“精雕细琢”的决策. 最后其实还是要回归到一个很简单的逻辑上来, 首先衡量整个市场的结构, 赚稳定的钱并且把策略容量作为更重要的算法设计需求. 当然具体的策略我不会多说, 我只想说整个算法本身 10 多年了完全没改至今还能有稳定的收益.
这一部分我想说的是, 无论是当年的量化交易算法, 还是如今的一些 Transformer 相关的模型结构. 更多的要从底层的逻辑考虑, 老老实实的把数据质量提高, 然后整体模型结构上尽量维持第一性原理去设计, 例如在讨论 Looped Transformer 和 Recursive Transformer时, 去抓住最核心的对一个 Attn block 本身的 Q/K/V 的处理上来看. 而不是这里加个 bias 那里加个 conv. 对于 Linear 和 Sparse Attn 的处理也应该如此, 首先从最底层的原理上分析 的State是否真的可行. 以及从数学上推导如果不做 Context aware 的压缩, KV容量的下界是什么? 另外 Chunkwise Compression vs Context aware Compression 该如何取舍.
是“屎上雕花”还是“精雕细琢”或许是从你搭建整个架构的最开始的地方开始就有了定论.
4. 谈谈 RL
过去的很多追求训推一致以及一些 cliff 的处理和 KL 的处理, 每一个在过去的一段时间内都会显得挺有效的, 至少模型训出来了, 效果也还不错. 但是这些处理的技巧是“屎上雕花”还是“精雕细琢”?
一直欠读者一份详细的关于 BPO 和 Score Centering 的详细分析报告, 这两个工作本身是非常简单有效的, 但是对于整个 RL 后训练的处理上, 其实也要回归到一个最底层的逻辑. 为了训练能够更好的 Scale, 特别是大量 rollout 的时间成本和算力成本压力下, Off-policy 更好的利用数据是一个必然的选择, 另一方面面对相对稀疏的 reward, token-level credits 如何处理? 当我接受 Async 的训练时, 例如一个耗时数百个小时的 Agent Trajectory 很有可能在整个 RL 的过程中 Rollout 的模型被 update 了多次, 这些问题处理不处理? 还是一个简单的 IS 就够了?
值得注意的是, 当前 Pre-Train 和 Post-Train 实际上还是有很多割裂的地方, model-arch 上针对后训练场景的一些 specific design 是“屎上雕花”还是“精雕细琢” 也是一个开放性的问题.
其实当前后训练不停的在处理很多训练稳定性相关的问题, 把整个算法越加越重, 是否在模型结构上对 token-level credits 做一些设计就能更好的解决问题? 这是我最近在思考的, 但似乎并没有很好的答案. 或者一些答案本身也是“屎上雕花”.
一些所谓的“大道至简”的东西或许只能靠运气... 这也让我想到 RDMA 这些年工业界对多路径和拥塞控制的处理上, 反反复复尝试了好几年都还没彻底解决... 多路径的算法上, 依赖交换机 packet-spray 把交换机的功能越加越多, 并且在一些链路失效的时候还有整体的集群稳定性风险, 拥塞控制上, 先认为丢包是一个小概率事件做 Lossless 就认为好像是大道至简了, 但如今在 大规模 ScaleOut稳定性上和Scale-Across 的拥塞处理上都遇到了大量的问题, 然后进一步又用特殊的网络拓扑解决. 网卡上 DPA 加完了再加 PSA, 然后还要加一些 Ethernet Switch 的IP 越加越重, SACK也加回来了, 然后 Window based CC 也有人开始加了, 最后发现和 TCP 就差一个端口号了. 但是当你用 TCP 的时候又陷入了 ToE 的邪路, 各种无法 Scale, SACK 这些长尾延迟无法控制等一系列问题又逐渐出来了... 摊手...
这一段想谈论的是, 对于“屎上雕花”还是“精雕细琢”, 或许你需要更广的知识面去探索更多的可能性后才能判断, 最后有可能运气好的到一个“大道至简”的答案. 其中的差别是“精雕细琢”是在某个领域或者周围的相关领域进行更广泛更深度的覆盖后作出的选择. 而“屎上雕花”则是一知半解的去堆砌了一些看上去能用的东西, 过段时间又拉一坨...
5. 结语
前段时间看到 OpenAI 放出一大堆数学证明, 有一些还在数学界工作的朋友开始哀嚎了.... 接下来的十几年, 或许要改变人的学习方式了……更广泛的视野和更好的提问将进一步拉开人与人的差距. 就像数学, 证明本身已经不是太大的瓶颈了, 更多的是去开荒, 找到荒地才是数学家更该做的事情…… 对于其它行业来说, 或许也是如此, 例如 AI Infra 这一侧冲击其实更大, 很多体力活基本上都不用干了. 验证一个想法的成本变得非常低廉...
欢迎大家进入一个新的蛮荒时代...如何区分“屎上雕花”还是“精雕细琢"的一些技术上的 taste 变得更加重要.
Locality Domain: https://docs.nvidia.com/cuda/cuda-programming-guide/04-special-topics/locality-domains.html