谈谈 AI 时代的组织结构

AI 时代，组织结构本身就是技术能力#

过去几十年，大企业已经发展出一套相当成熟的组织方式：按专业划分部门，按职责确定边界，通过接口协调合作，再用各自的指标衡量产出。计算团队负责计算，网络团队负责网络，存储团队负责存储。上层的算法团队提出需求，数据团队提供数据，Infra 团队交付基础设施。当技术路径相对稳定、问题可以提前拆解时，这种结构能够支持极大的业务规模。

但前沿 AI 研发有一个麻烦之处：大量关键问题在解决之前，根本无法被准确地拆分。

模型结构会改变通信模式，通信能力会影响并行策略，并行策略会影响显存占用和训练效率。数据的长度分布会改变计算负载，数据配比又会影响模型收敛。一个看起来属于算法的问题，最后可能需要通过调整通信实现解决；一个看起来属于存储的问题，也可能要通过改变数据组织方式才能解决。算法、数据和基础设施之间，存在大量相互影响的关系。

当技术问题需要整体求解，组织却要求每个部门只对自己的局部指标负责时，局部最优与整体最优之间的裂缝就出现了。

设想一次大规模训练的效率不理想。计算团队拿出报表，GPU 利用率并不低；网络团队检查链路，平均带宽和丢包率没有明显异常；存储团队完成测试，吞吐符合既定标准。每个团队都能证明自己交付了合格的服务，但模型完成一轮实验所需的时间仍然很长。

问题可能藏在这些报表的交界处。网络平均表现正常，少数节点的尾部延迟却可能拖住同步训练。存储系统的顺序读取吞吐很好，实际数据管线却存在大量小文件访问和预处理等待。GPU 很忙，也可能有相当一部分时间消耗在重复计算或低效的数据搬运上。部门指标提供了有用的信息，但只有把它们放回同一个训练过程，才能判断整个系统究竟发生了什么。

计算、网络和存储还会围绕同一个问题产生不同的合理诉求。为了提高资源利用率，调度系统可能倾向于把任务塞进零散的空闲 GPU，但分布式训练可能更需要拓扑合适的一组机器。为了降低存储成本，平台可能限制高性能存储的使用，但更快的 checkpoint 保存可以支持更高的保存频率，减少故障后的重算，更快的恢复则可以缩短停机时间。一个部门节省下来的成本，可能以更高的代价出现在另一个部门。

如果模型研究者只能把一个已经定型的方案交给 Infra 团队，再要求对方”尽量跑快一点”，很多优化机会在交接之前就已经丢失了。双方需要更早地共同判断：哪些算法选择值得基础设施为之改变，哪些系统约束应该反馈到模型设计中。

部门的边界 vs 知识的边界#

知识边界往往比部门边界更加顽固。也是我最近几年一直要全栈”人工”智能的原因，很多的优化其实都在知识的边界处。

部门边界至少是可见的，可以通过调整汇报关系、设立联合项目来改变。知识边界则经常隐藏在日常沟通里。算法研究者提出”需要更大的 batch”，Infra 工程师接到的是扩容需求，却未必知道背后是在验证什么训练假设。工程师反馈”这个方案通信开销太高”，研究者收到的是一个限制，却未必知道换一种数据布局或专家放置方式，就可能让方案重新可行。

双方都在认真工作，但传递过去的只是结论，支撑结论的假设和上下文没有过去。

工单擅长传递已经被定义清楚的问题。前沿研究却经常需要一群人坐下来，先弄清楚问题究竟是什么。一旦合作被压缩成”提需求、评估、排期、交付”，Infra 就容易成为被动接单的服务部门，算法团队也容易把现有平台的限制当成技术本身的限制。

例如一个通算融合的例子，大家都用过 DeepEP/MegaMoE 吧，或者更简单地说，MoE 模型的 EP 并行是不是真的需要 ScaleUP？ScaleOut 上为什么除了 DeepSeek 的团队没人想到用 IBGDA？而即便如此在低延迟场景下，RDMA 的语义为什么对 GPU 不友好？

然后做网络的人开始盲目地扩大 ScaleUP 的规模，NPO / CPO 不停地上，甚至要做一卡一专家，却从不考虑整个系统的 MTBF，传输协议也不考虑 GPU 本身的微架构……

这也是我一直强调知识边界的原因。当你完全能够控制 GPU 的微架构，充分理解网络传输上的限制，以及完全了解算法上的需求，一个更简单的方案就呈现出来了——当然涉密的原因我不会多说。

数据团队与算法团队之间同样如此。数据团队可能按照交付规模、清洗进度和处理成本衡量工作，算法团队则围绕最终模型指标展开实验。如果双方缺少持续反馈，数据很容易变成一次性交付的原料。模型在哪些能力上表现薄弱，哪些样本真正有效，哪些清洗规则误删了有价值的内容，就很难形成连续的验证过程。

一个完整的改进过程应该能够从模型失败案例出发，形成数据假设、调整数据、开展对照实验，再把结论反馈给下一轮训练。如果这些环节分别属于几个团队，还拥有不同的排期和考核周期，一次本来可以快速推进的探索，就可能在交接中不断等待。

更棘手的是，组织有时要求先确定责任归属，才能投入排查资源。一次训练突然出现 loss 异常，原因可能来自数据变化、数值精度、算子实现或硬件故障。在证据不足时，任何单一团队都很难独立定位。但如果每个团队都要先看到”问题属于自己”的证明才愿意介入，排查就会陷入循环。AI 研发经常需要先联合诊断，才能知道问题应该由谁解决。

部门边界带来的影响还不止于执行效率。它会逐渐改变研究者愿意提出什么问题。

如果一个想法必须同时协调数据管线、训练框架和网络实现，才能完成最初的验证，而另一个想法只需要修改本部门的一小段代码，在相同的绩效周期里，后者自然更有吸引力。久而久之，人们会主动选择容易获得资源、容易交付、容易归属成果的研究方向。那些潜在价值很高、却需要跨越多个边界的想法，可能连第一次实验都没有获得。

这时，组织结构已经进入了技术路线本身。表面上看，公司拥有充分的研究自由；实际上，哪些方向容易被尝试，哪些方向会被提前放弃，已经被预算归属、接口限制和协作成本筛选了一遍。

所以挺认同翁家翌的观点：

现在 AI 竞赛拼的不是算法创新，而是工程能力和迭代速度。每家公司都有不同程度的 bug，谁修的 bug 多，谁的模型就训得更好。

其实真正藏在这背后的，就是大量的细节，而这些细节又隐藏在知识的边界里。而对管理层暴露出的又只是片面的部门边界，以为几次组织调整能够解决，但知识的壁垒并没有被打破。

聪明人的竞争#

我从小到大一直在各种试点班读书，非常能够理解什么是”高密度人才之间的竞争”，这会进一步放大组织的问题。

聪明人同样会响应激励。当晋升需要证明独立贡献、预算需要证明部门价值、管理者的影响力又与团队规模相关时，人们就会有动力建立自己的项目、维护自己的边界、强调自己对成果的所有权。

帮助另一个团队解决关键问题，对公司可能非常有价值，对个人却未必容易形成一份清晰的晋升材料。把自己的经验沉淀成公共工具，可以让很多人少走弯路，但贡献可能分散在别人的成果里。相比之下，重新建设一套带有明确团队标签的平台，反而更容易被识别和奖励。重复建设、信息保留和成果争夺，就可能成为一套评价体系下的理性选择。

技术能力越强的人，也越有能力为自己的选择提供完整而有说服力的解释。一场争论可以充满专业术语和技术细节，同时又深受资源分配和成果归属的影响。当承认另一个方案更好意味着自己的项目失去预算，技术判断就很难保持开放。

内部竞争可以帮助组织探索不同路线，但需要共享的评估标准、可以复现的实验结果，以及明确的资源调整机制。如果每个团队都维护自己的评测口径，对失败保持沉默，对成功选择性展示，公司就很难知道哪些方向值得继续投入。

人才密度能够转化为创新密度，依赖于一个具体条件：分享知识、暴露问题和帮助别人成功，必须对个人也是值得的。 其实我一直都在问自己一个问题：“如果全世界只剩下你一个人，是要钱还是要名？” 所以最近很多年我一直是一种人畜无害的状态，有些事情自己明白做成功了就行了，Credit 什么的无所谓，然后经常打着技术扶贫的旗号，分享知识给其它人——想起几年前的一篇文章《技术扶贫与公知》。

这里说个 RL 中的训练推理不一致的问题吧。

大模型的 RL 训练通常涉及两套系统：推理引擎负责生成回答，训练引擎根据回答及其奖励计算更新。即使使用同一份模型权重，两套引擎也可能因为计算精度、算子实现和批处理方式等差异，得到不同的概率分布。异步执行还可能让推理端使用落后的模型版本，进一步扩大差异。

如果按照传统部门职责来分配任务，推理团队会努力提高吞吐、降低延迟，使用量化和更高效的执行方式；训练系统团队会努力提高数值一致性和运行稳定性；算法团队则会调整重要性采样、裁剪和样本筛选等机制，尽量控制失配对训练的影响。对于 MoE，还可以通过记录和回放专家路由，减少两边执行路径的差异。

这些方法有各自的技术依据，有些还承担着失配处理之外的任务。但组织需要警惕一种状态：每个团队都在解决自己收到的问题，修正措施不断增加，对共同机制的理解却没有同步加深。

推理团队收到的问题是”怎样让生成更快”，训练团队收到的问题是”怎样让两边更一致”，算法团队收到的问题是”怎样让现有更新方式更稳定”。这些问题一旦被固化为各自的工作范围，就容易遗漏另一种追问：两套引擎不一致时，训练更新里到底多出了什么？

最后整个问题在一系列争吵中就变成了算法团队需要训推一致，然后 R3 这样的东西就做出来了……主流的算法基本上都延续着 On-policy 的路，却没人想到 Off-policy。

当然解决问题的答案简单到让人发指，最近一篇论文 Score Centering Stabilizes Off-policy Reinforcement Learning 基本上高中生或者大一的学生都会的一个公式。（后面这个话题会专门写一篇文章来详细分析。）

那么整个问题在哪？从组织角度看，企业里可能并不缺少懂这条等式的人，却缺少让这些知识与真实系统问题相遇的机会。它展示了一类组织风险：当问题跨越算法假设与系统实现时，局部修复可以不断有人负责，对共同假设的重新检查却可能长期无人负责。最值得讨论的，是组织有没有能力识别这种空缺，并把相应的人和资源组织起来。

领导者的 taste#

即使团队获得了跨越部门边界的自由，仍然有一个问题需要回答：团队会把获得的自由用来追问什么？面对训练不稳定，有人倾向于继续调整参数，有人希望增加一道校正，也有人会停下来检查梯度估计究竟建立在什么假设之上。这些选择都需要时间和资源，而组织无法同时尝试所有方向。核心领导者的 taste，就在这样的选择中开始发挥作用。

taste 可以理解为一种经过实践校准的判断力。它帮助领导者辨别哪些问题值得长期投入，哪些异常可能暴露了更基础的机制，哪些复杂性确实来自问题本身，哪些则来自过去决策的累积。在技术路线尚不清楚时，这种判断会影响团队最初把注意力放在哪里，也会影响什么样的人和想法能够获得支持。

这种 taste 最终需要变成资源安排。新增一道机制，除了当下的开发工作，还会增加之后的调参、排查和维护负担。已经投入很多人力的项目，同样可能需要缩减或结束。领导者需要帮助团队面对这种取舍，让过去的投入成为决策背景，同时把未来还能获得多少有效进展放在更重要的位置。

要作出这些判断，核心领导者需要保持足够的技术深度。深度的作用是提高问题和证据的质量，具体推导与实现仍应由最接近事实的人推进。然后在 AI 时代这样的技术深度是非常困难的，通常领导者又要面临在大量并不那么懂的领域被迫执行决策。

另一方面，选人的 taste 也会沿着同样的方向影响组织。除了专业深度，还需要识别一个人是否愿意理解相邻领域，能否把自己的判断解释给不同背景的同事，是否会主动修正已经投入精力的方案。一个研究者能够把算法假设和系统行为联系起来，就可能帮助几个团队重新定义问题。这种贡献未必对应一个独立模块，却可能改变整个项目的推进方式。

奖励机制必须能够看见这些贡献。找到原因后删除几层无效逻辑，证明一项昂贵实验没有继续开展的必要，把自己的经验变成其他团队可以复用的工具，都应该进入评价依据。如果组织主要奖励项目数量、代码规模和团队扩张，成员就会倾向于增加可以归属于自己的工作。对删减复杂性的认可，能让人们更愿意把注意力放在整个系统的实际改进上。

领导者也需要允许证据推翻自己的偏好。一个简洁解释可能遗漏真实的数值问题，一个看起来笨重的措施也可能在特定条件下不可替代。当研究者拿出反例时，资源和方向能否随之调整，比会上是否允许讨论更能说明问题。核心人物愿意公开修正判断，会降低其他人暴露错误的代价，让失败实验更容易成为共同知识。

再来举个例子吧，RDMA over Ethernet 这事，当年为了硬件简单选择了 Lossless 的方案，在 HPC 的年代似乎完全正确，数据量小到几乎没有什么拥塞和丢包。

而到了 AI 时代，一切都变了……当年被认为笨重的 iWARP 却逐渐成为最终的答案。RoCE 为了多路径，逐渐地都开始使用了 DDP，为了可靠性又逐渐地加上 SACK，拥塞控制也逐渐改为 Window based，不停地做加法，最后实质上和 iWARP 的区别无非就是一个 IP 协议号了。（详细内容可以看看《“漫”谈 RDMA 现代化》。）

团队的问题#

随着团队扩大，这些判断还需要逐渐变成可以讨论和传递的依据。记录重要决策依赖的假设，明确什么证据会触发调整，培养能够独立负责问题的人，都能减少对个人在场的依赖。

具体到组织设计，一个重要起点是围绕研究目标配置稳定合作的算法、数据和 Infra 成员。例如改善长上下文训练效率、提高某类推理能力，或降低满足既定质量要求的推理成本。团队从目标和假设开始共同工作，拥有必要的实验额度和技术修改权限，并由明确的负责人协调质量、时间和成本之间的取舍。

专业部门仍然承担人才培养、技术标准和长期基础设施建设的职责。网络、存储和训练稳定性都需要持续的专业积累，让所有人负责所有事情也会稀释这种能力。需要调整的是关键问题上的合作方式和决策权限，让团队能够在必要时共同修改跨越专业边界的实现。

联合项目必须有清楚的决策权，避免每一步都重新回到多个部门争取支持。成员在项目上的时间投入、资源额度和评价依据也需要事先明确。只有责任而没有资源调动能力的项目负责人，很容易变成会议协调员；同时背负几套冲突目标的成员，也很难持续投入共同的问题。

组织还需要有意识地培养能够跨越知识边界的人。理解模型训练的系统工程师、理解硬件约束的算法研究者、能够通过模型评估判断数据价值的数据工程师，都能减少关键上下文在交接中的损失。Anthropic 在介绍其可解释性团队时[2]，就描述过成员在研究和工程之间切换的工作方式，并强调跨领域工程能力与团队之间的紧密协作。这个案例展示了一种具体的工作方式。

结语#

对大企业而言，AI 时代的变化还涉及既有业务的优先级。成熟产品需要稳定性、可预测的成本和清晰的交付承诺，前沿研究则需要承担更多不确定性。两者都合理，但需要不同的预算节奏和评价方式。如果探索项目始终用成熟业务的季度回报标准证明自己，组织就更容易选择可快速交付的改进，并持续压缩基础创新的空间。

公司的规模并不决定这些问题是否存在。小公司同样可能出现信息垄断、决策集中和关键人物过载。大公司也完全可能通过明确目标、调整权限和改变激励，建立高效的研究团队。值得观察的是，一个关键问题出现后，相关的人能否及时看到证据，能否共同判断，能否调动资源把判断变成实验。

当 AI 工具进一步提高代码编写、数据处理和实验分析的速度，这些组织能力可能变得更加重要。如果个人执行任务越来越快，获取上下文和作出跨团队决策的速度却没有变化，等待与协调就会占据越来越大的比例。更多产出会汇集到相同的决策瓶颈前，暴露出原来被执行成本掩盖的问题。

所以，讨论 AI 时代的组织结构，最终需要落到一些非常具体的事情上：一个研究员发现异常之后，能直接找到谁；一个跨领域的想法，多久能得到第一次验证；一次失败，能否帮助所有相关团队少走弯路；一个人帮助别人取得突破，能否同样获得认可；核心领导者提出的判断，能否被新的证据改变。

资金可以买到机器，薪酬可以吸引人才。组织需要进一步创造条件，让这些人能够理解彼此的工作、修正共同的判断，把分散的专业能力变成持续积累的集体知识。当最有价值的问题不断出现在部门交界处，组织就必须让知识、资源和决策能够及时跨过这些边界。 核心领导者的 taste，则需要让更多人获得独立作出可靠判断的能力。在这个意义上，组织结构本身，已经成为 AI 技术能力的一部分。

参考资料#

[1] 梁文锋访谈：https://finance.sina.com.cn/roll/2024-07-22/doc-inceypaf4744158.shtml

[2] Anthropic 关于可解释性研究工程的介绍：https://www.anthropic.com/research/engineering-challenges-interpretability