大厂们的窘境：AI 创新失速之谜

作者 陈仁苗

清华计算机系 CoAl 课题组博士生

过去几年，大模型成为科技行业最重要的技术浪潮之一。很多人天然认为，大公司拥有更多算力、数据、人才和资金，因此在大模型竞争中一定占据绝对优势。但在实际参与大型科技公司大模型研发之后，我反而感受到：在新的技术范式下，大公司并不一定总是更快、更强，甚至在某些关键环节上可能会被更小、更灵活的创业公司超越。

这背后的原因，不只是资源多少的问题，而是组织结构、研发流程、工具链、沟通方式和产品迭代机制的综合结果。

资源优势并不会自动变成创新速度。真正决定模型迭代快慢的，是有效实验数、反馈质量，以及组织内部摩擦的总成本。

一、内部工具链拖慢了研发速度

大模型研发高度依赖训练平台、数据处理平台、测试平台和部署平台。理论上，大公司拥有成熟的基础设施，应该能显著提升研发效率。但实际情况往往并不理想。

在一些大公司内部，研发人员必须使用统一的内部云训练平台。问题在于，这类平台虽然名义上是“标准化基础设施”，但实际使用体验可能非常差：bug 多、易用性差、文档不清晰、报错信息不友好，很多训练流程对新人极不友好。

01 平台摩擦

训练、测试、部署平台不好用，直接降低有效实验数。

02 权限摩擦

文档、数据和反馈被审批流程切开，研发难以形成完整判断。

03 部门摩擦

预训练、后训练、评测、infra、产品各自为战，闭环变慢。

04 决策延迟

一线痛点层层衰减，真正影响效率的问题很难快速进入决策。

这篇文章讨论的不是资源总量，而是资源在组织内部转化成实验、反馈和产品改进时被消耗掉的比例。

更严重的是，由于平台使用范围相对封闭，外部生态无法参与改进，内部需求反馈又未必能被及时重视，导致很多问题长期存在。使用者明知道工具不好用，却只能被迫适应。

久而久之，团队会形成一种“逆来顺受”的习惯：大家不再期待工具变好，而是默认研发本来就应该这么痛苦。

这会对研发效率造成非常直接的伤害。大模型研发本质上是一个高度实验驱动的过程，很多能力提升都来自不断试错。如果每一次训练、测试、排查、提交都要被繁琐流程和平台 bug 消耗大量时间，那么真实的创新速度就会被严重压缩。

在创业公司里，工具链未必一开始就更完善，但它可以更快被改造。谁遇到问题，谁就能直接推动修复；哪个流程拖慢效率，就可以直接重构。小团队不一定资源更多，但浪费更少。

二、权限和审批让很多事情变得低效

在大型组织中，权限管理和安全合规是必要的。但问题在于，很多权限和审批机制会被过度泛化，最终变成研发效率的阻碍。

实际研发中，很多很小的事情都需要申请权限，很多文档需要经过作者审批才能访问。某些材料确实应该严格管理，但也有不少内容本身并没有那么高的敏感等级，却仍然需要走审批流程。

对申请人来说，这会打断工作流；对审批人来说，也是一种持续负担。大模型研发尤其依赖上下文信息。模型为什么这样训练，数据为什么这样处理，评测为什么这样设计，线上用户为什么这样反馈，这些信息如果被割裂在不同权限和文档系统里，研发人员就很难形成完整判断。

创业公司在这方面通常更轻。它们当然也需要基本的信息安全，但由于组织规模较小、信任链条更短，知识流动更自然。一个人可以更快拿到需要的信息，也更容易理解问题全貌。

三、部门割裂让大模型变成流水线产品

大模型不是一个单点技术，而是预训练、后训练、数据、评测、推理、产品、用户反馈共同耦合出来的复杂系统。它不像传统软件那样，一个模块做好之后交给下一个模块就可以了。任何一个环节的变化，都可能影响最终模型体验。

但在大公司中，分工往往非常细。每个小组只知道自己负责的部分，对上下游了解有限。对于实习生或新人来说，这种感受会更明显：你可能只知道自己组在做什么，却很难知道整个大模型产品到底如何运转。

这种结构在传统工业化研发中是高效的，但在大模型时代可能反而低效。因为模型能力的提升经常需要跨环节判断：算法策略需要理解数据分布，后训练需要理解产品场景，评测需要理解真实用户体验，infra 也需要理解模型迭代节奏。

如果每个人都只是流水线上的一颗螺丝钉，那么整个系统就很难快速形成反馈闭环。大模型作为一个完整产物，参与者需要对其他环节有基本认知，才能更好地优化最终效果。

创业公司在这里有明显优势。由于人少，一个人往往需要同时理解多个环节，甚至直接参与多个环节。这种“被迫全栈”虽然辛苦，但会带来更强的系统感。研发、产品、评测、数据之间的距离越短，模型迭代越快。

四、资源很多，但未必用在真正创新的地方

外界通常认为大公司资源充足。但在内部视角下，资源并不总是流向最需要探索的地方。

大量算力和工程资源往往会优先保障对外服务的模型、已有业务和确定性更高的项目。而真正研究“如何提升模型能力”的算法策略团队，未必能获得足够多的实验资源。

这会产生一个很现实的问题：大模型研发需要大量尝试。很多方向只有跑了实验才知道有没有用。但如果资源不足，能试的方向就少；如果每次实验还可能因为平台 bug、数据问题或流程问题失败，那有效实验数量会进一步减少。

最终，团队看起来拥有大公司级别的资源，实际上用于高风险探索和快速迭代的资源并不充裕。

创业公司反而可能更愿意把有限资源押在关键创新上。它们没有太多历史业务需要维护，也没有过多内部资源竞争。只要判断一个方向重要，就可以集中资源快速尝试。资源总量可能不如大公司，但资源使用更聚焦。

五、层级结构削弱信息传递和决策速度

在复杂组织里，职级和层级不可避免。但对于大模型这种快速变化的方向，过长的沟通链条会带来明显问题。

一线研发人员最接近具体 bug、实验失败、工具痛点和真实效率损耗。但这些信息未必能准确传递到高层。中间层级越多，信息损耗越严重。很多问题在一线看来非常具体、非常痛苦，但到管理层那里可能只变成一句抽象的“平台体验有待提升”。

这有点像一个没有足够残差连接的深层神经网络：底层信号很难直接传到高层，梯度在中间逐渐衰减。

最后，高层可能并不知道真实研发体验是什么样的，一线也很难直接推动结构性改变。

创业公司更像一个残差连接更多的网络。创始人、核心工程师、产品负责人之间可以直接沟通，问题暴露更快，决策路径更短。很多事情不需要层层汇报，只要判断对产品和研发效率有价值，就可以立刻改。

六、大公司还要保护旧业务，而创业公司只需要面向未来

大公司并不是不能创新，而是它们创新时经常要同时照顾原有业务、既有用户、品牌风险、组织惯性和商业模式。

这会让大公司在面对颠覆式技术时天然保守。因为真正激进的创新，往往会影响已有产品形态，甚至冲击原有商业利益。对于大公司来说，一个新东西不只是“能不能做”，还要考虑“会不会伤害现有业务”。

创业公司没有这个包袱。它们没有庞大的旧业务需要保护，也没有复杂的内部利益平衡。它们可以直接围绕新技术重新设计产品、组织和商业模式。

大模型时代尤其如此。研发和产品之间的距离越来越短，技术本身就是产品体验的一部分。过去可能是研发先发明一个东西，产品再拿去包装和销售；但现在，模型能力、交互方式、用户反馈、数据闭环和产品体验几乎是同步演化的。

这要求组织具备非常高频的跨部门协同能力。大厂传统的部门墙和流程化协作，在这种情况下会变成明显劣势。

七、小公司在大模型时代的核心优势

综合来看，创业公司在大模型竞争中并不只是“船小好调头”这么简单，而是具备几类结构性优势。

结语：大模型竞争不是单纯的资源竞赛

大模型时代的竞争，表面上看是算力、数据和人才的竞争，但更深层看，是组织效率、反馈速度和系统协同能力的竞争。

大公司当然拥有强大的资源基础，但这些资源如果被复杂流程、低效工具、部门墙、权限系统和层级结构消耗，就很难完全转化为创新速度。相反，创业公司虽然资源有限，但如果能做到组织扁平、目标聚焦、研发产品深度耦合，就可能在特定方向上跑得更快。

这也是为什么在今天的大模型浪潮中，小公司并非只能跟随大公司。恰恰相反，越是技术和产品高度耦合、越是需要快速试错和持续迭代的领域，创业公司越可能拥有独特优势。

未来的大模型竞争，不一定属于资源最多的组织，而更可能属于反馈最快、协同最好、最能把技术直接转化为产品体验的组织。