谷歌「抛弃」TensorFlow，是壮士断腕还是自毁长城？一场框架霸权的内部战争

谷歌「抛弃」TensorFlow是壮士断腕还是自毁长城一场框架霸权的内部战争【免费下载链接】tensorflowAn Open Source Machine Learning Framework for Everyone项目地址: https://gitcode.com/GitHub_Trending/te/tensorflow2019 年PyTorch 在顶会论文中的使用率刚刚反超 TensorFlow而到了 2023 年谷歌 Brain 与 DeepMind 合并后的第一件事不是加码 TensorFlow而是把研究重心全面押注到 JAX 上。一时间「谷歌自己抛弃了 TensorFlow」成为 36 氪、51CTO 等科技媒体的高频标题。但如果我们打开这个仓库本身——TF 2.23.0 的 master 分支——会发现事情远非「弃疗」那么简单TensorFlow 非但没有停摆反而在 Keras 3、XLA 与 TFLite 的棋盘上完成了一次隐蔽的「自我肢解」。谷歌抛弃的究竟是 TensorFlow还是 TensorFlow 曾经独占的「框架霸权」这篇文章将用仓库源码逐条拆解这场权力更迭的真实路径。一、导火索当「研究」与「产品」在同一个框架内分道扬镳先看一个反直觉的事实这个正在被舆论宣判「垂危」的仓库仍保持着活跃的版本迭代。tf_version.bzl 中明确定义了TF_VERSION 2.23.0同时维护着从 3.10 到 3.14 的六套 Python 依赖锁文件requirements_lock_3_10.txt至requirements_lock_3_14_freethreaded.txt。这说明谷歌并没有关停 TensorFlow 的发布流水线——它关停的是「一个框架包打天下」的旧叙事。真正的转折点藏在发布日志里。翻看 RELEASE.md 的版本演进可以清晰看到谷歌的「拆家」时间线2.16 起Keras 3.0 成为默认版本。日志原文写道「Keras 3.0 will be the default Keras version. You may need to update your script to use Keras 3.0.」——Keras 从此不再内嵌于 TensorFlow而是成为支持 PyTorch、JAX 等多后端的独立框架同一版本tf.estimator API 被彻底移除「The tf.estimator API is removed」一个时代的高层接口被直接归档2.22 起TensorBoard 不再随包默认安装「The TensorBoard dependency is no longer included by default」tf.summary与tf.keras.callbacks.TensorBoard需要用户单独pip install tensorboard。这三刀砍向同一个方向把曾经「全家桶」式的 TensorFlow拆成可独立演进、可独立消亡的模块。Keras 去 TF 化等于把最接近用户的接口层让渡给一个中立的多后端框架TensorBoard 剥离等于放弃了对可视化生态的绑定。谷歌正在主动把「护城河」抽干。二、动机解剖算力、研究还是组织惯性外界常把「谷歌抛弃 TensorFlow」归因于 JAX 在科研圈的流行但代码层面给出了更立体的答案。第一层动机是组织层面的合并后的 Google DeepMind 需要「一个研究栈」。Brain 与 DeepMind 合并前前者主推 TensorFlow后者长期依赖 JAX 做 AlphaFold、AlphaTensor 等前沿研究。合并后「一司两栈」的研发浪费必须被终结而 JAX 凭借函数式 API、jit/vmap/grad的天然组合性胜出。这与其说是技术选择不如说是组织惯性的一次清算——正如 README.md 所描述的TensorFlow 的出身是「Google Brain 内部用于研究机器学习的框架」而今天它被迫让位于更「数学原生」的后辈。第二层动机是架构层面的编译器层的「去 TF 化」。仓库内 third_party/xla/docs/architecture.md 记录了一段关键历史「Before the OpenXLA project was created, XLA was developed inside the TensorFlow project」——XLA 编译器曾经是 TensorFlow 的私生子如今却成为 OpenXLA 生态的公共底座同时服务 PyTorch、TensorFlow 与 JAX 三个前端。也就是说谷歌真正押注的从来不是某个「框架」而是「编译层 硬件层」这个更底层的控制点。谁掌握 XLA谁就掌握所有框架的算力调度这才是「算力霸权」的真正含义。第三层动机是产品层面的研究归 JAX部署归 TensorFlow。谷歌没有把部署市场也交给 JAX反而在 TensorFlow 里不断强化 JAX 的「下游收容」能力——这一点下文详述。研究工具与工程工具分离是谷歌给自己安排的「双轨制」。三、「抛弃」的另一面源码里的三条退路如果只看到「剥离」会得出谷歌自毁长城的结论但仓库源码显示谷歌同时在做三件「反向加固」的事TensorFlow 正从「训练框架」转型为「部署与转换的中转站」。其一TFLite 成为 JAX 模型的落地出口。tensorflow/lite/g3doc/examples/jax_conversion/overview.md 的标题就是「JAX models with TensorFlow Lite」官方给出的完整路径是用 JAX 训练 → 通过 Orbax Export 导出 → 转成 TensorFlow SavedModel → 再用TFLiteConverter转成移动端模型。代码示例直观展示了这条链路from orbax.export import JaxModule import tensorflow as tf import jax.numpy as jnp def model_fn(_, x): return jnp.sin(jnp.cos(x)) jax_module JaxModule({}, model_fn, input_polymorphic_shapeb, ...) tf.saved_model.save( jax_module, /some/directory, signaturesjax_module.methods[JaxModule.DEFAULT_METHOD_KEY] .get_concrete_function(tf.TensorSpec(shape(None,), dtypetf.float32)) ) converter tf.lite.TFLiteConverter.from_saved_model(/some/directory) tflite_model converter.convert()注意这里的关键设计SavedModel 成为 JAX 与 TFLite 之间的通用中间格式。JAX 越流行TensorFlow 的序列化与部署生态就越有价值——谷歌把「竞争」巧妙地变成了「上下游」。其二tf.lite从 2.12 起就内置了experimental_from_jax直转接口见 RELEASE.md 的 2.12 发布记录「Add experimental APIexperimental_from_jaxto support conversion from Jax models to TensorFlow Lite」。这甚至不需要先走 SavedModelJAX 模型可以直接被 TFLite 消费。其三基础设施层面 TensorFlow 与 JAX 共享 CI 容器。ci/official/containers/ml_build/README.md 写明这是「WIP ML Build Docker container for ML repositories (Tensorflow, JAX and XLA)」并强调引入 hermetic CUDA/Python 后容器可跨多个 ML 仓库复用。也就是说在谷歌的工程体系里TF 与 JAX 早已不是对手而是共用一套构建管线的「同门师兄弟」。这张图可以帮助理解谷歌真正的押注方向——编译器与硬件层才是新的权力中枢四、巨头「自我革命」的得与失站在谷歌的资产负债表上看这场换轨得失其实非常清晰。得一是终结了「一司两栈」的内耗研究力量统一到 JAX工程力量继续沉淀在 TensorFlow 的部署链路二是将竞争从「框架对框架」升维到「编译器 硬件对框架」用 XLA 同时钳制 PyTorch 与 JAX 两个前端三是把 Keras 从 TF 的附属品改造成多后端接口层相当于在 PyTorch 阵营内部也插进了一根谷歌的触角——PyTorch 用户通过 Keras 3 写代码最终仍可能流回 TF Serving / TFLite 的部署栈。失代价同样昂贵。最直接的是版本碎片化引发的社区信任危机——Keras 2 与 Keras 3 的 API 差异、TF_USE_LEGACY_KERAS1这类环境变量逃生舱、TensorBoard 需要单独安装……每一次「优雅解耦」都在给存量用户制造迁移成本。CSDN 上大量「TensorFlow 深度学习框架详解」「一文读懂 TensorFlow」类教程至今仍停留在 Session、静态计算图的旧叙事里侧面印证了社区知识体系已经严重滞后于仓库的演进速度。当生态的知识水位追不上代码的变化框架的「易学性」口碑就会持续失血——这正是 PyTorch 过去几年在学术界与新手市场攻城略地的原因。五、对维护者与贡献者的真实影响这场权力更迭对 TensorFlow 社区最实质的冲击体现在「贡献者的价值锚点」上。从 CONTRIBUTING.md 描述的流程看外部贡献者的 PR 会经过标签审查、指派 reviewer、Kokoro CI、然后通过「copybara」同步进谷歌内部代码库——这是一套为「巨头主导型」开源项目设计的流程其潜台词是核心路线图永远由谷歌内部团队定调社区贡献者负责的是边缘模块。当谷歌把研究重心移向 JAX外部贡献者会敏锐地感知到「投入 TensorFlow 的政治资本正在贬值」从而转向 PyTorch 或 JAX 社区。更结构性的变化是贡献面的收窄Keras 拆分后模型层贡献流向独立的 keras 仓库XLA 抽离后编译层贡献流向 OpenXLA留在 TensorFlow 仓库里的核心工作只剩tensorflow/core运行时、tensorflow/lite移动端与tensorflow/pythonAPI 胶水等工程模块。贡献者的「英雄叙事」从「训练出 SOTA 模型」转向「优化推理引擎」——对工程师而言这意味着更明确但也更狭窄的职业赛道。真正的风险在于如果研究界彻底倒向 JAXTensorFlow 仓库将失去「前沿问题驱动」的活水只剩部署工程这一条腿。六、终局推演框架霸权的下一种形态把时间轴拉长这场「内部战争」的终局大概率不是「JAX 杀死 TensorFlow」而是三层分工的稳态研究层JAX 主导。函数式 API、自动微分、大规模并行计算天然匹配前沿研究的需求谷歌会持续投入部署层TensorFlow含 TFLite / TF Serving / TF.js继续垄断生产环境的存量市场。SavedModel 中间格式 experimental_from_jax的存在使 JAX 的繁荣反而成为 TFLite 的流量入口地基层XLA / OpenXLA 成为真正的战略资产。当所有框架都要编译到 StableHLO 与 XLA 指令谷歌就掌握了与 NVIDIA、AMD 等硬件厂商博弈的筹码——这才是「抛弃 TensorFlow」背后真正的算力棋局。对开发者而言这场更迭的实用启示有三第一选型不必再「二选一」JAX 训练 TF 部署的混合链路已经被官方文档与 API 正式支持是当前性价比最高的组合第二序列化标准比框架本身更长寿SavedModel 正在扮演当年 ONNX 想扮演的角色值得作为资产沉淀的锚点第三关注编译层胜过关注 API 层XLA 的演进速度决定了所有框架的性能天花板这个仓库里 third_party/xla 目录的体量数千个源文件本身就是答案。谷歌没有自毁长城——它只是亲手拆掉了旧长城的砖去修了一座横跨所有框架的新要塞。至于这是壮士断腕还是饮鸩止渴最终裁决权不在谷歌手里而在每一个用脚投票的研究者与工程师手里。【免费下载链接】tensorflowAn Open Source Machine Learning Framework for Everyone项目地址: https://gitcode.com/GitHub_Trending/te/tensorflow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考