拉贾特·蒙加：TensorFlow

2015 年 11 月，Google 把内部最核心的机器学习系统连同大量工程积累一起放到了 GitHub 上。一家市值数千亿美元的公司，把自家最难被复制的技术免费送出去，当时在硅谷几乎找不到第二个案例。

推动这个决定的人之一是 Rajat Monga。他从 2011 年 Google Brain 成立时就在场，后来负责领导 TensorFlow 团队，把一套内部系统变成了今天这个横跨云端、手机、浏览器的生态。在这场对话里，他谈到了那个开源决策的完整逻辑、TensorFlow 2.0 背后的权衡，以及一个很多人好奇的问题：Google 到底图什么？

最初的目标只有一个：把算力堆上去，看效果会不会变好

Google Brain 成立的第一年，目标单纯得近乎朴素。Rajat 说，当时要验证的命题就是一句话：扩大算力、扩大数据规模，模型表现会不会随之提升。

这句话现在听起来像常识，2011 年可完全不是。深度学习的潜力还没被广泛认可，学术界有兴趣，但谈不上狂热。Google 手里同时握着两样别人没有的东西，超大规模通用算力和海量数据。Andrew Ng 和 Jeff Dean 想做的，就是把这两样东西跟深度学习的研究接上，看看会发生什么。

答案来得比预想快。Rajat 提到两个早期成果。语音识别是一块，团队跟 Google 语音研究组紧密合作，把神经网络塞进了实际系统。图像是另一块，就是那篇被大量引用的论文，用大规模无监督学习训练出能识别猫的网络。

第一年我们就拿到了一些早期的胜利，这总是好事。（Rajat Monga）

胜利之后是规模上的狂飙。从几十台机器到几百台，再到上千台。Rajat 说，他们甚至跑过规模达到一万台机器的训练任务。这些实验证明了一件事：在 Google 的体量下，深度学习不但跑得动，还会切实影响一批产品。

语音是第一个，图片是第二个，然后是相册，再往后是更多产品线。

到了 2014 年，外部环境也变了。学术界开始大规模讨论深度学习，热情和方向都在快速升温，虽然资源和数据仍然跟不上大公司。Rajat 说，团队意识到这件事不会只发生在 Google 内部。Google 也许暂时领先，但要做的事情太多，一家公司做不完。

开源那个决定，背后有一段 Hadoop 的教训

2014 年夏天，TensorFlow 的前身 DistBelief 开始重构。到当年年底，团队已经基本确定要走开源这条路，于是从一开始就按开源的假设去做设计。

Rajat 说这个想法最早来自 Jeff Dean，支撑它的逻辑有两层。

研究层面很直接。Google Brain 本身就是研究组织，研究成果要发表，要推动整个领域往前走。深度学习之所以发展这么快，很大程度上就是因为大家愿意分享。软件是研究的载体，软件自然也该分享。

工程层面的逻辑更值得说。Rajat 讲了一段很多人不知道的历史。Google 内部做过很多优秀系统，也发表过论文，但后续的故事往往是这样：有人拿着论文自己实现了一套，做得还行，然后这套东西就成了行业标准。Hadoop 是最典型的例子，它脱胎于 Google 发表的 GFS 和 MapReduce 论文，实现水平却远不如 Google 内部的版本。

结果就是一个尴尬的局面。Google 手里握着更好的技术，却不得不为别人实现的、质量差一截的系统提供兼容 API。

我们想，能不能做出更好的东西，真正帮到社区，同时也推动一个好的标准往前走。（Rajat Monga）

这个判断的分量在于它承认了一个残酷现实：在基础设施领域，赢家往往由使用人数决定，技术优劣排在后面。与其让一个更差的实现成为事实标准，不如自己把最好的实现拿出来，让它成为标准。

2015 年 11 月，TensorFlow 正式开源。这件事后来被很多人视为软件工程史上的一个分水岭：一家大公司主动把包含大量知识产权的核心项目开放出来，等于向全世界宣布，开放创新这条路走得通。

选择计算图的理由，和 PyTorch 逼出来的 Eager Execution

设计 TensorFlow 时，团队做过一个关键决定：用计算图表达模型。

这个选择在当时几乎顺理成章。DistBelief 本身就有类似图的结构，只不过更接近一条直线，不像 TensorFlow 那样是通用图。更重要的原因在 Google 一直很在意的生产环境，即便在 DistBelief 时期，也有大量模型跑在实际业务里。

设计过程中，团队确实试过纯 Python 的方案，写起来简单得多。可问题立刻冒出来：没有图，分布式怎么部署？不同设备之间怎么调度？

这大概就是让天平倾斜的原因，最终我们选择了图。（Rajat Monga）

这个决定在随后几年带来了巨大成功，也带来了持续争议。计算图让 TensorFlow 在分布式训练和生产部署上占尽优势，但它的抽象方式跟普通程序员的思维方式差得很远，写起来别扭。PyTorch 走的是另一条路，从第一天起就明确只服务研究场景，不需要考虑生产部署，直接用动态图，代码写出来就是普通的 Python。

Rajat 对这场竞争的态度相当坦率。他说 PyTorch 团队有后发优势，能看到前人踩过的坑，也能专注在特定方向上把事情做到极致。这种竞争反过来促使 TensorFlow 团队重新审视那个被搁置过好几次的问题：要不要支持动态执行？

竞争很有意思。这是我们已经想过很多次的事情，某一天我们说，好吧，这件事看起来可以做好了，那就再试一次。（Rajat Monga）

2019 年发布的 TensorFlow 2.0，默认就是 Eager Execution。计算图还在，只不过藏到了后台，只在需要性能优化的时候才介入。Rajat 承认，如果 PyTorch 不在，这个转变可能会来得更晚。

把 Keras 拉进来，一次出人意料的整合

TensorFlow 壮大之后，一个来自外部的问题变得越来越尖锐：到底该用哪个 API？

当时 Google 内部同时存在好几个高层 API，社区还各自搭了封装。用户面对的局面极其混乱，一个模型可能在这个 API 里有、在那个里没有，选哪个全凭运气。Rajat 说，社区反复问同一个问题：我们该用哪一个？

2.0 的核心目标之一就是解决它：只能留一个。

最后被选中的是 Keras。这个决定当时相当出人意料，因为 Keras 原本是独立项目，作者 François Chollet 在加入 Google 之前就把它做了出来，最初的后端是 Theano，后来才加上 TensorFlow。从任何角度看，这都不像 Google 自家该优先推的东西。

整合的过程也很有意思。Chollet 加入 Google 后去了研究团队，继续做研究、写论文，同时利用晚上和周末维护 Keras。Rajat 说，他甚至是在 Chollet 入职好几个月之后，才知道这个人已经在 Google 了。

后来两边聊了聊，发现彼此想做的事情高度一致：让尽可能多的开发者轻松上手。于是 Chollet 转到 TensorFlow 团队，原计划只是协作一个季度，结果一待就是两年。

把两件本来可以对齐的事情放在一起，是很有意思的。（Rajat Monga）

这个决策的收益在后来的版本里非常明显。初学者和大多数企业用户拿到的体验是，用 Keras 在 TensorFlow 上做迁移学习，几行代码就能跑通，纠结 API 选择这件事从此消失了。

4100 万次下载背后的社区工程

访谈里提到一组数字：TensorFlow 当时被下载 4100 万次，累计约 5 万个提交、接近 1 万个 pull request、1800 名贡献者。

Rajat 说，他当年完全没想过能到这个量级。当时能想象的只是未来会有很多人做这件事，问题是怎样让别人做得起来。

增长真正开始显现是在开源之后。他意识到深度学习扩张的速度远超预期，而 TensorFlow 恰好站在了一个能承接这种扩张的位置上。

社区不会自己长出来。他提到几个关键动作，其中最重要的是文档。TensorFlow 刚发布时，文档质量比所有同类项目高出一大截，原因很简单：那些项目都是学术项目，作者根本没把文档当回事。

文档带来的效果是结构性的。深度学习从此不再只是研究者的玩具，一个完全没有机器学习背景的人，也能照着文档把东西跑起来，做出点有意思的东西。使用者基数由此发生了质变。

人们喜欢我们的文档，因为它比当时其他所有东西都好一大截，那些都是学术项目，没人会去想文档这件事。（Rajat Monga）

另一个动作是流程建设。Rajat 说，过去一年团队花了很多力气提升透明度，建立特别兴趣小组，让外部贡献者知道项目往哪走、怎么参与、提案流程是什么。这些事在只有两个开发者的项目里根本不用考虑，到了这个体量就绕不开。

还有一个容易被忽视的飞轮：有人在 TensorFlow 上实现了一个新架构，效果不错，放到 GitHub 上，别人拿去改，又做出新东西。这种自发的正反馈，才是社区能自我繁殖的根本原因。

企业要稳定，研究者要自由

Rajat 把用户分成截然不同的两类，这两类人的需求几乎对立。

研究者要灵活性，要能表达各种疯狂的想法，要跟得上每周都在变的新架构。企业要的东西相反：稳定、简单、能一直跑下去。

他举了一个很具体的例子。现在还有很多人在用三年前、四年前的模型。Inception 已经好几岁了，照样有大量的人在用，而且他们觉得挺好。这些人不需要最后那一点性能提升，他们要的是东西能稳定工作。

有很多人在用那些模型，他们没问题，他们不需要最后那一点性能或质量，他们要的是稳定，是能直接用的东西。（Rajat Monga）

这解释了 TensorFlow 为什么在学术界被 PyTorch 追赶的同时，在企业市场依然稳固。真正跑在生产环境里的系统，换代周期比论文慢得多。

不过 Rajat 也纠正了一个常见误解。很多人以为深度学习最主流的应用是拿 ResNet 做迁移学习，那确实是最容易演示的场景，幻灯片上很好看。企业真正在做的事情朴素得多：他们有结构化数据，想做预测，以前用线性回归、逻辑回归、梯度提升树，现在换成深度学习，效果可能确实更好，但远没有那么炫。

他还提到一个更前置的问题。很多传统行业的公司来问他怎么用机器学习，聊到最后发现根本问题在别处：数据没整理好，流程没数字化。他的建议通常是先把最基本的东西跑通，再谈优化。

我经常跟人说，别一上来就想着最新最花哨的模型，先把最基础的东西做出来，然后再改进。（Rajat Monga）

2.0 的野心：清理 API 只是表面，拆解内核才是重点

2.0 对外最直观的变化是 API 变干净了，Eager Execution 成了默认，Keras 成了推荐入口。Rajat 说，这些清理带来的真正好处藏在后台。

过去用计算图，性能可以很好，前提是你花时间调。现在 API 收敛了，绝大多数人会用同样的方式写代码，团队就能针对这条主路径做深度优化，很多性能直接开箱即得，单机和分布式都是如此。

另一件更重要也更难的事，是拆解那个庞大的单体系统。

TensorFlow 的核心仓库里塞着执行引擎、CPU/GPU 后端、分布式调度，全部编译成一个库，彼此之间没有清晰接口。这种设计在早期算优势，跑得快，改起来方便。到了第四个年头，它变成了负担。

TensorFlow 一开始是个非常单体的系统，某种程度上现在还是。核心部分依然很大、很单体。怎么用更清晰的接口把它拆开，是我们扩展规模的关键挑战之一。（Rajat Monga）

拆解的目标是让外部组织更独立地参与进来。硬件厂商想接入自己的芯片，像 IBM 这样的公司想在特定方向做优化，自动驾驶公司有自己的集群和网络方案。目前这些事也能做，只是很别扭。有了干净的接口，各方就能各自演进，整个生态的扩展性会完全不同。

Rajat 用一个很形象的比喻形容这件事的难度：车还在跑的时候换发动机。

兼容性是债，也是一份承诺

4100 万次下载背后，是全世界无数跑在生产环境里的系统。这些系统一跑就是好几年，不会因为框架升级就停下来。这意味着任何破坏性改动都要付出真实代价。

Rajat 承认这笔账很重。他把这件事看成一次权衡：短期看，兼容性会拖慢某些事情；长期看，它带来的整体价值要大得多。因为这不只关乎昨天那个人写的代码，更关乎明天那个人愿不愿意进来。一个承诺不随便破坏你代码的框架，本身就是一种吸引力。

他自己在设计新东西时，用的是另一套方法。

做新东西的时候，你要先在脑子里用一张白纸去设计，然后再想办法让其他所有东西也能跑起来。如果你设计的时候不敢想白纸，你永远到不了一个好地方。（Rajat Monga）

先理想化地设计，再回来处理兼容。一开始就让历史包袱把设计压扁，顺序就反了，而顺序一反，好东西就出不来。

团队、超级明星与招聘

TensorFlow 的体量已经到了一个人做不了决策的程度。Rajat 说，早期设计方向他参与得比较深，现在生态里推各自领域的人太多，比如 Martin Wicke 长期负责开源相关的工作。靠一个 BDFL 式的角色来管理这个规模，已经不现实。

聊到团队，他的判断标准很清晰。第一条是凝聚力，一个人再强，能做的事情也有限，团队产出要大于个体之和。第二条是动机，一个人是不是真的在乎自己在做的东西。

就算是最初级的工程师，如果他对自己要做的事情没有动力，那不管他多聪明，都很难做得好。（Rajat Monga）

招聘里也有体现。Google 的面试流程除了考察技术能力，还有专门评估文化契合度的环节。TensorFlow 这种快速迭代的项目，需要能适应快节奏的人；项目逐渐成熟之后，又需要愿意为质量较真的人。这两种特质有时候会冲突，找到平衡点本身就是筛选的一部分。

关于超级明星，他的态度很明确：可以很强，但必须能和团队协作。如果不合适，再大的个人价值也成问题。

搜索广告那几年，学到的是边界

在接手 TensorFlow 之前，Rajat 在 Google 的搜索广告团队待过。他把这个业务理解为搜索的延伸：目标是把世界上的信息变得可获取，商品和服务也属于信息。

他提到一个细节。广告系统在展示前会设一条质量门槛，达不到就不展示，哪怕这样会损失收入。这套机制背后的逻辑是，广告只有在真正对用户有价值的时候才该出现。

他对广告行业的问题也看得很清楚。一个网站反复弹窗挡住内容，用户当然烦。他希望在打扰和有用之间找到平衡，因为内容和服务本身要靠变现维持。

关于未来，他不认为互联网会全面转向付费。广告模式会长期存在，但过去几年确实有越来越多人愿意为价值付费：Netflix、YouTube 订阅、新闻网站的付费墙。他自己也能感受到这种变化，包括自己的付费习惯。他期待的是一种混合模型，先免费试用，再为更深的价值付费。

给初学者的路径，和给从业者的判断

访谈最后，Rajat 给初学者的建议非常朴素：打开官网，点进教程和指南，直接进 Colab，不需要安装任何东西，浏览器里就能跑。

背后是云带来的结构性变化。课堂和学生面对的最大门槛从来都是环境配置，算力排在后面。Colab 把这一步彻底抹掉了。免费额度当然有限，用完就得付费，这套逻辑跟前面聊的付费订阅遵循同样的规则。

至于硬件，他的观察是个人设备的算力一直在涨，今天手机的算力可能是当年第一台台式机的若干倍。云端负责起步和探索，本地设备负责日常和隐私敏感的场景，两条路会同时存在。

整场对话下来，有一条线索贯穿始终。TensorFlow 每一次重大选择，几乎都不是技术最优解，约束条件下的权衡才决定了方向。选计算图，因为放不下生产部署；选 Keras，因为生态需要一个统一入口；保留兼容性，因为几千万次下载背后是真实的业务系统；拆解单体架构，因为生态需要更多人参与。

这些决定的共同点是，它们都在为别人把事跑起来让路，技术本身的优雅反而排在后面。

• 刚开始接触深度学习，别急着搭环境。开一个 Colab notebook，用 Keras 加载预训练模型做一次迁移学习，先把从数据到预测的完整流程跑通，比读十篇综述有用。
• 做企业落地时，先检查数据本身有没有结构化和数字化。很多项目卡住的地方是数据没就位，跟算法选型关系不大。
• 选框架前先想清楚自己的场景偏向研究还是生产。要频繁试新架构、写得顺手，就看动态图优先的方案；要长期稳定运行、需要分布式和成熟的 serving 链路，就看生态完整度。
• 带技术团队时，除了考察硬技能，专门留时间判断对方对这件事有没有真实兴趣。技能可以补，动机补不了。
• 维护有外部用户的开源项目，尽早把文档和贡献流程做起来。文档在早期是成本最低、回报最高的投入，它决定你的用户基数能不能发生质变。
• 设计新版本时，先在纸上按理想状态设计，再回头处理兼容。顺序反过来，好设计永远出不来。