算力最多，进展最慢：字节大模型困于赛马制

文 | Tech商业 在互联网的黄金十年里，字节跳动是被奉为神明的组织机器。凭借“App工厂”模式、扁平化的敏捷开发以及极度内卷的“赛马机制”，它硬生生在腾讯和阿里的夹击下，跑出了抖音这样的全球级巨无霸。 但当这家公司带着最耀眼的资金、最顶级的算力和最庞大的人才库，杀入大模型时代时，过去的“神兵利器”，却成了刺向自己最深的软肋。 近日，X平台上围绕字节Seed团队的一场讨论，扯下了大模型狂欢背后最残酷的组织遮羞布。爆料者直言不讳地指出：Seed拥有很好的人才和很多的算力，但LLM（大语言模型）的进展却不够快；答案不是技术限制，而是组织问题——字节的赛马机制，根本不匹配大模型的研发。 配合着此前公开报道中字节Seed团队训练“投毒”事件当事人的自述，以及评论区关于“大模型重工业流水线”的讨论，一个极其荒诞的现实浮出水面：在大模型这个人类历史上最复杂的系统工程面前，字节引以为傲的“赛马”，跑不出通向AGI的火箭。 图自推特 当“赛马”撞上“重工业” 大厂的高管们往往有一个致命的路径依赖：他们以为大模型只是另一个更复杂的App，只要投入足够多的团队，让他们互相竞争、内部PK，就能跑出最强的模型。 这是移动互联网时代留下的思想钢印。 正如评论区一位从业者一针见血地总结：“大模型预训练，本质上是类似精密重工业的流水线工程。从分词过滤、数据配比，到千卡/万卡拓扑的通信调优，每个环节必须严丝合缝、全局协同。” 在这个重工业体系里，容不得半点各自为战。你需要一个高度集权的指挥部，统一调度上万张GPU，统一清洗几十万亿的Token，统一对齐底层的Infra（基础设施）架构。哪怕是一个细微的数据配比错误，或者千卡集群中的一根网线松动，都可能导致长达数月、耗资数千万的训练彻底崩溃。 而“赛马机制”的核心是什么？是小步快跑、是资源隔离、是团队内卷、是胜者为王。 把移动互联网的赛马机制，强行套用在需要全局协同的超大集群研发上，直接导致的结果，就是把本该集中力量办大事的“超级算力池”，拆碎成了各自为战的“资源孤岛”。 爆料中提到，在字节内部，资源囤积成了常态。那些已经抢到算力的团队，即便算力闲置，也宁愿烂在手里，绝不愿意共享给其他团队。大家都在防备着隔壁团队跑出比自己更好的成绩，信息不透明，沟通充满戒备，甚至互相藏匿关键的代码与数据。 这并非字节一家的绝症。爆料者顺带提及硅谷巨头也有类似问题：在谷歌内部，研发Gemini的团队抱怨缺卡，而赚钱的广告团队却握着大把GPU，外界并不知道他们到底在拿这些算力干什么。需要说明的是，这一关于谷歌内部算力分配的具体说法目前仅见于爆料转述，尚无独立信源交叉印证；但它指向的部门墙与本位主义，确实是大模型时代昂贵的沉没成本。 洗了半年的数据，谁来背OKR？ 大模型的研发不仅需要“大”，更需要“静”。它不像写前端代码那样能立刻看到炫酷的UI反馈，它需要大量枯燥的数据清洗和繁琐的通信调优。 而在大厂极度内卷的KPI/OKR体系下，这种“安静”是不被允许的。 爆料中描绘了研发人员极其真实的痛点：做LLM并不需要那么多灵光一闪的“天才时刻”。真正的工作，是稳稳当当地把数据和环境弄对，是死磕Infra的效率。但这帮由顶级天才组成的研发人员，骨子里是渴望创新、渴望带项目的。 “加上每几个月考核一次的OKR，我这半年全都在清洗脏数据，年底的OKR怎么写？”这是一个死结。 在现有的考核体系下，洗数据、排雷、调优通信，这些真正决定大模型下限的“脏活累活”，是无法转化为漂亮的汇报PPT和顶会论文的。如果员工为了完成OKR，去做了最出彩、最容易发论文的架构创新，那些脏活谁来干？ 没人干，那模型就会吃下有毒的数据，最终酿成灾难。 此前在圈内引发震动的字节Seed团队训练“投毒”事件，正是这种极端内卷与组织割裂的产物。作为最直接的受害者，前员工ShoufaChen在回忆中极其痛苦地描述了那段长达数月的排查、对峙与质疑。在长达几个月的时间里，团队每天面对的是模型表现的诡异崩溃，是对彼此工作失误的相互指责。 公开报道显示，这并非简单的技术Bug，而是一名前实习生在训练环境中实施的系统性破坏：篡改底层代码、随机终止训练进程、埋设后门，并把故障伪装成随机事故。当团队之间为了抢夺资源而互相防备，当研究员为了保住自己的项目而隐瞒真实的数据故障，大模型这个庞然大物，就会在不知不觉中走向崩溃。大厂的OKR体系，原本是为了激发人的潜能，最终却逼出了人性中最短视、最自私的一面。 缺失的“Research Group” 更有意思的是另一条评论：“字节拥有最多的资源，但没有一个真正的Research group（研究团队）。” 这家公司过去几年在技术博客上的输出非常华丽，发表了不少优秀的Infra框架和底层算法。但如果仔细看，他们的技术产出与实际得到的算力投入，似乎呈现着