Gemini大战DeepSeek惨烈内幕CSDN

DeepMind的Gemini预训练负责人 Vlad Feinberg自曝研发内幕：5人团队为抢跑DeepSeek，在硅谷和巴黎双城倒班、40天几乎不眠不休死磕训练。他不认为人工智能会取代所有人的工作，原因在于，人类在组织里承担的一个关键角色，是构成一张信任网络。

Google DeepMind 的 Gemini 预训练主管 Vlad Feinberg，最近在一档播客里聊了聊他的日常。

在大众的想象中，顶尖实验室的研究员每天都在推导颠覆性的算法。但 Vlad 说，他职业生涯最重要的一笔奖金，是谷歌传奇人物 Jeff Dean 亲手发给他的——当时他刚入职 Google Brain，没有像当年同样在谷歌的 Transformer 作者们一样，去写那些能发到顶级会议上的第一作者论文，而是默默干了几天最脏的活：调整编译器和超参数，解决显存溢出，把一个叫 SFT 的微调任务塞进了一堆老旧的 TPU 卡里，这才让第一代 Bard 勉强跑通。

这种“干脏活”的工程体验，才是这轮大模型竞争最真实的样子。Gemini 2.0 出来的时候，外界都在赞叹它作为一个 MoE 模型有多神奇。但 Vlad 透露，背后其实只有 5 个人在顶着。

算力卡随时会挂，数据索引随时会断，为了不白白浪费几百万美元的算力费，他们只能在硅谷和巴黎两个大区之间 24 小时倒班，不眠不休地死磕了 40 天。甚至在 DeepSeek-V3 爆红、华尔街日报制作表格拉踩谷歌已经落后时，Vlad 也是哭笑不得——媒体为了制造爆款新闻，在表格里故意删掉了（elided）排名其实高居第一的 Gemini 2.0 Flash Thinking。

对于甚嚣尘上的“程序员要失业”的恐慌，这位主管给出了一个很干脆的观点：AI 永远无法被“吊销律师执照”，因为它不具备主体资格，无法承担法律责任，所以人类永远要为它的产出签字并背书。

他的组里有一个叫 Nate Lintz 的普通工程师，之前在搜索部门写后端基础架构，就是靠着在业务里帮大模型落地，解决最具体的推理开销，最终内部转岗到 DeepMind 成了技术支柱。

如果你也想去，Vlad 在他的博客里放了一个“硬核作业”（手写一个 Transformer 并手算 Scaling Laws 录成视频发给他），做完了他直接面你。以下是这次谈话里，他聊到的几个极其真实的行业细节：

法律大模型可以背下所有判例，但它不能代表你出庭，因为它无法被“吊销执照”。职业的底层逻辑是责任和信任的分配。因为 AI 无法承担法律后果，代码的终点永远需要一个具体的人来签字、背书并承担责任。这才是程序员不会被替代的终极底线。

写再牛逼的学术论文，都不如帮团队省下几张卡的显存。很多眼高手低的程序员在 AI 时代迷失在理论和框架中。但在研发一线，最容易拿奖金的能力，是那些不体面的“重体力活”——优化编译器、调试超参、在有限的芯片里榨出最后一丝算力。这种扎实的工程能力，才是跨越周期的硬通货。

写搜索基础架构的普通码农，也是能一步步逆袭进 DeepMind 的。团队核心成员 Nate Lintz 曾只是一个写后端搜索的普通工程师，他没有高大上的 AI 背景，但通过在组内帮产品落地 LLM，默默解决大模型在搜索业务里最头疼的推理和算力开销，在实战中摸清了底层架构，最终顺理成章地转岗进入 DeepMind 并主导了核心推理设计。

华尔街日报为了拉踩谷歌，在对比 DeepSeek 时故意在表格里删掉了排名第一的 Gemini 模型。当媒体为了制造“中国开源超越美国大厂”的新闻而兴奋时，他们有意隐去了当时在 LMSYS 榜单上高居榜首的 Gemini 2.0 Flash Thinking。真实的技术对决背后没有神话，只有 5 个工程师在硅谷和巴黎 24 小时倒班、死磕 40 天的硬撑。

你没法把研究和落地分成两种人

主持人：你写过一篇题为《如何进入前沿实验室工作》的文章。现在前沿实验室最需要的，到底是什么样的能力？也许我们可以先聊聊，这类工作的整体轮廓是什么。

Vlad：现在前沿实验室需要的能力，其实覆盖范围非常广。大语言模型这种东西，和研究、和产品之间的关系，比过去的机器学习要紧密得多，所以它会牵动很多完全不同的方向。我写那篇文章，并不是想开一份面面俱到的清单，而是想提出几个比较具体、可操作的方向，说明实验室会在哪些能力上有很强的需求。

我重点写的是内核开发和底层工程，也就是怎样在真实运行环境中提升大语言模型的执行效率。我看到这类能力，在几乎所有前沿实验室，以及实验室内部很多项目里，需求都非常强。所以这是一个特别值得单独点出来的方向。更具体一点说，每当我们做研究项目，需要修改神经网络架构，或者重新思考服务方式，比如怎样把键值缓存做得更好，类似这样的事情，整个技术栈上的人都必须有能力把这些新方法高效地实现出来。

而所有这些变化的核心循环，本质上都是在制造能够在大规模场景下运行的软件系统：它要有高吞吐、低延迟。这其实是一类非常基础的工作，和传统后端工程的思维是紧密相连的。所以我觉得，这对很多人来说都是一个非常开放、非常值得专攻的方向。

主持人：我有些朋友在 OpenAI 和 Anthropic 工作，他们跟我说，那边会区分偏应用的组织 and 偏研究的组织。我想知道 Google DeepMind 里是不是也有类似区分？如果有的话，你能不能讲讲这两者的差别？

Vlad：我们内部确实有不同的重点方向。比如在 Google DeepMind，就有团队专门研究怎样用 Gemini 这样的语言模型，更好地改进搜索结果。从某种意义上讲，这可以算是语言模型的一种应用化方向。

但我其实不太愿意把这种区分画得特别死，因为把模型整合进真实产品，本身就需要很多非常硬核的研究工作。就拿我刚才说的那个例子来说，为了让模型真正服务搜索，你得投入大量精力，确保模型回答的是事实，能引用来源，能给出非常精确、非常有依据的答案。

你还得评估这些来源本身的质量，确保它不是讽刺、不是玩笑、不是不可靠的信息。我觉得这恰恰说明，即便是在非常面向产品、非常“应用化”的人工智能方向里，你其实仍然是在做研究。

当然，另一方面，也确实存在那种更经典意义上的语言模型研究团队，比如做预训练、做后训练。这些在 Google DeepMind 内部依然是比较独立的团队，目标就是打造业内最先进的模型。

也就是更纯粹意义上的研究。不过我还是要补一句：我们做的“纯研究”之所以有意义，前提是它最后能被真正实现出来。所以我们既要负责把模型交付出来，确保训练稳定推进，某种程度上像训练任务的运维工程师一样，盯着整个训练过程别出问题；同时我们也要负责提出训练这些模型的方法配方。

这两个角色根本分不开，必须同时承担。所以我觉得，你当然可以把研究和应用看成一条连续的光谱，但在今天这个时代，不管你站在哪一侧，最后都得能在这条光谱上自由切换。

主持人：我注意到还有另一条光谱，就是软件工程师到纯人工智能研究员。你怎么看这条光谱？软件工程和人工智能研究之间，到底差别在哪？

Vlad：如果从我自己的经历出发，我会说，我们做的很多事情，以及我们提出的很多新方法，它们真正的基础其实是基础设施层面的投入。

我可以稍后更详细讲讲我团队在做什么，但先拿“蒸馏”举个例子。所谓蒸馏，本质上是一种知识迁移方式。你可以把它理解成：教师模型先在底层数据上提炼出某种统计信息，再把这些信息传给学生模型，让学生模型比完全没见过这些额外信息时表现得更好。

但如果你说的是一个超大语言模型，而且处理的是数万亿级别的词元，这背后对应的计算投入就是极其惊人的，可能是数百万、数千万美元的算力成本。

这就意味着，你必须认真思考怎么把整个系统优化到极致。因为你做的每一个操作，都会被放大到极其巨大的规模：每一秒都重要，每一个字节的存储都重要。

而这里面很大一部分工作，说到底就是非常传统的软件工程。尤其是蒸馏基础设施，到现在大概已经经历了三到四代演化。每一代里，我们都会退后一步，重新审视当前在蒸馏研究中到底用了哪些方法，再从整体上想：我们的基础设施该怎样扩展，才能支持更广泛的研究。

而且确实有几个很明确的节点：你一旦重新思考蒸馏系统的设计方式，蒸馏方法的研究速度就会明显加快。

所以这其实是一种非常典型的投入：你可能花四个月时间重写蒸馏基础设施，最后换来的，是对蒸馏缩放规律的全新认识，而这种认识又会反过来转化成非常强的模型表现。

所以它真的要求你跨越整个技术栈去工作。我几乎无法想象，如果没有这些蒸馏基础设施层面的投入，我们能做出 Flash 3.0 那样的结果。归根到底，这些东西一开始都来自一份非常老派的设计文档：你得想清楚，生成教师统计信息时，什么样的抽象才是对的；这些信息该存进什么样的存储系统；在这种规模下，跨多个数据中心读写数据时，底层该如何支撑。

这些其实都是非常经典的分布式系统问题，不是吗？

研究不是一条直线，它更像在雾里走图

主持人：对，我也是这个意思。听起来在现在这种计算规模下，确实有很多软件工程、后端基础设施类的问题。但我还是觉得，在那条光谱上的某个位置，应该会出现一个真正的跃迁——需要一些全新的能力。比如说，你把一个普通后端工程师直接丢去改模型架构，这显然和做基础设施又不是一个量级的跳跃。

你怎么看这个区别？

Vlad：对，我觉得确实有这样一个分界点。研究这件事，本质上是一种高风险、高回报的活动。我们常会说一个词，叫“研究品味”，也就是一种高层次的直觉：在一个项目里，你面对很多不同的里程碑和可能路径时，到底应该沿着哪条路往前走。

从某种意义上说，软件工程项目也可以被看成类似的一张有向图：你有一堆中间产物要完成，最终才能到达目标。

但软件工程里的这张图，整体上更接近确定性的。你先搭一个服务，再搭另一个服务，再搭第三个服务；先把存储层搞定，再处理上层功能。你大体可以稳定地一路往前推进。

研究就不是这样。研究里的这张图是带随机性的。因为其中一些节点——比如某个研究想法，或者到达最终目标所必需的某个环节——并不保证能成功。

我觉得这要求一种思维方式上的转变。而这种转变需要时间去学，也需要一些专门培养出来的能力。这就是很多人在博士阶段逐渐建立起来的那种东西。

如果要我用一句比较简洁的话来概括，我会想到 Jacob Steinhardt 教授的一篇非常出色的文章。我很喜欢用他的框架来理解自己做的研究：研究是一种马尔可夫决策过程。

所谓马尔可夫决策过程，指的是：在一个研究项目里，不同里程碑之间存在一张带有随机性的依赖图。你可能必须先拿到某种结果，或者先证明某种结论，才能到达后面的目标。

类似地，在一个机器学习研究项目里，你可能得先把某种特征方案跑通，之后才有机会获得某种图像识别准确率，图上的节点和路径都会不断展开。

这是一种高度不确定的探索活动：某些方法可能有效，也可能无效；而一种方法一旦有效，又会为你打开一组新的可能性。

在软件工程里，你也许可以把所有通往目标的路径都列出来，然后问：最短路径是什么？

但研究里，这种方法并不最优。因为一旦图上的边不再可靠，有些节点甚至你还根本不知道——也许它们是隐藏的——那你处理问题的方式就必须改变。

具体来说，你必须同时考虑不同研究方向的成功率和时间投入，还得事先对这些概率做出估计。

而这和给一个软件项目写设计方案，是完全不同的一种思维活动。你得培养出一种直觉：在你还没真正做一件事之前，先判断它成功的可能性有多大。

很多人把这种能力和“研究品味”联系起来，我觉得这是对的。因为你如果想真正穿行于这种研究过程里，这种判断力就是必须建立起来的核心能力。

主持人：听起来你的意思是，研究里有更多的不确定性。我还是想更具体一点去理解这种工作的性质。如果你把一个后端工程师扔进一个做研究的团队里，具体会在哪些地方出现明显短板？

Vlad：我第一个想到的，就是你是否具备足够的研究背景，足够理解自己所处的研究版图。

研究工作很大程度上要求你有一种很谦逊的心态：你得承认，在你之前，这个方向已经有了大量投入；而在你真正了解这个主题上全人类目前最前沿的积累之前，你大概率不可能继续把这个前沿往前推。

所以，在某个具体方向上建立扎实的已有工作认识，并真正做好相关文献梳理，可能就是很多人最先会卡住的地方。你得有能力沿着一个主题的引用脉络一路追下去，知道该读什么、怎么读。

因为你根本没时间把所有论文都读完，所以你必须培养一种判断力：哪些论文最值得读？在不阅读全文的情况下，怎么判断一篇论文到底值不值得投入时间？