导语：如果把 TensorFlow 近几个版本的发布说明连起来读，会发现一条清晰的主线——这个曾经以“大而全”著称的框架，正在系统性地做减法。从移除 TensorRT 依赖，到停止发布 libtensorflow，再到把 LiteRT 的 API 逐步迁出主仓库，TensorFlow 正在重新划定自己的边界。

一、2.15：一次被依赖项绊倒的发布

2023 年 12 月，TensorFlow 团队发布了一个并不寻常的版本号：TensorFlow 2.15.0.post1。这不是一次功能更新，而是一个热修复。

问题的根源在于依赖管理。TensorFlow 2.15.0 的 Python 包在发布时请求了 tensorrt 相关包，除非用户事先安装或提供额外的安装标志，否则这些包无法被找到。这直接影响了所有通过 pip install tensorflow[and-cuda] 安装 TensorFlow 2.15 并同时安装 NVIDIA CUDA 依赖项的用户。

后果因安装方式而异：部分用户可能实际装上了 TensorFlow 2.14 而非 2.15，另一些用户则会直接收到安装错误。

修复方案是发布 Linux x86_64 平台的 2.15.0.post1，从 tensorflow[and-cuda] 安装方法中移除 tensorrt Python 包依赖项。官方特别说明，只要系统上已安装 TensorRT，对 TensorRT 的支持不受影响。

这里有一个容易被忽略的细节：版本固定策略会影响修复的生效。根据 Python 的版本规范规则，tensorflow[and-cuda]==2.15.0 不会安装这个修复版本。官方建议在 Linux 平台上使用 ==2.15.0.post1 指定确切版本，或使用 ==2.15.* 这类模糊版本规范来获取最新兼容版本。

这次事件暴露的问题很典型：一个推理优化库的 Python 包依赖，足以让整个安装流程失效。而它也为后续版本中 TensorRT 的彻底退场埋下了伏笔。

二、2.17：CUDA 内核的取舍与 TensorRT 的告别

2024 年 7 月发布的 TensorFlow 2.17，把“取舍”二字写得更明白了。

CUDA 内核的加减法。 TensorFlow 二进制发行版开始附带针对计算能力 8.9 的 GPU 的专用 CUDA 内核，这提升了 Ada 代 GPU（如 NVIDIA RTX 40 系列、L4 和 L40）上的性能。与此同时，为了控制 Python wheel 的体积，团队决定不再附带针对计算能力 5.0 的 CUDA 内核。

这意味着预编译 Python 包所支持的最旧 NVIDIA GPU 代际，从此前的 Maxwell 上移到了 Pascal（计算能力 6.0）。对于仍在使用 Maxwell 的用户，官方给出了两条路：继续使用 TensorFlow 2.16，或者从源代码编译——前提是所使用的 CUDA 版本仍支持 Maxwell GPU。

TensorRT 支持的终止。 更值得关注的是，官方明确宣布：从 TensorFlow 2.18 开始将放弃对 TensorRT 的支持，TensorFlow 2.17 是最后一个包含它的版本。

结合 2.15 的安装事故来看，这条路线并不意外。当一个可选依赖项持续制造安装摩擦，而它带来的收益又可以通过其他路径（例如直接使用 TensorRT 或转向其他推理栈）获得时，把它从主发行版中剥离就成了合理选择。

Numpy 2.0 的预告。 2.17 的发布说明还提前打了招呼：即将发布的 TensorFlow 2.18 将包含对 Numpy 2.0 的支持，而这可能会破坏 TensorFlow API 使用的一些边缘情况。这种“提前一个版本预警”的做法，对于依赖 TensorFlow 的生产系统来说，是安排升级窗口的重要信号。

三、2.19：LiteRT 的独立与 libtensorflow 的退场

时间来到 2025 年 3 月，TensorFlow 2.19 的发布说明延续了同一条主线，但动作更加具体。

LiteRT 的 C++ API 调整。 公共常量 tflite::Interpreter::kTensorsReservedCapacity 和 tflite::Interpreter::kTensorsCapacityHeadroom 从 constexpr 编译时常量改为 const 引用。官方给出的理由很直接：这是为了在 Play services 中为 TFLite 提供更好的 API 兼容性，同时保留在未来更改这些常量值的实现灵活性。

这是一个典型的“为兼容性牺牲一点编译期优化”的决策。对于在 Android 生态中通过 Play services 分发模型的开发者来说，这类调整的实际影响可能比表面看起来更大。

tflite casting 支持 bfloat16。 tfl.Cast 算子现在在运行时内核中支持 bfloat16。bfloat16 在保持与 float32 相同指数范围的前提下压缩了尾数位，在推理场景中常被用来平衡精度与内存占用。

tf.lite.Interpreter 的迁移倒计时。 2.19 中，tf.lite.Interpreter 会给出弃用警告，并重定向到新位置 ai_edge_litert.interpreter。官方明确表示，该 API 将在 TF 2.20 中删除。这意味着留给开发者迁移的时间只有一个版本周期。

libtensorflow 停止发布。 官方已停止发布 libtensorflow 软件包，但仍可从 PyPI 包中解包获取。对于依赖预编译 C/C++ 库的团队，这需要重新评估获取方式。

Keras 的独立发布节奏。 值得注意的是，从 Keras 3.0 开始，关于新的多后端 Keras 的发布更新将在 keras.io 上发布，而非跟随 TensorFlow 的发布说明。这实际上是把 Keras 从 TensorFlow 的版本叙事中进一步分离出来。

四、趋势判断：TensorFlow 正在重新划定边界

把 2.15、2.17、2.19 三个版本放在一起看，可以归纳出几条清晰的趋势。需要说明的是，以下判断基于现有素材，不涉及素材之外的版本信息。

第一，主发行版持续瘦身。 从移除 tensorrt Python 包依赖，到放弃 TensorRT 支持，再到停止发布 libtensorflow，TensorFlow 的 Python wheel 和发行包正在剥离那些“可选但沉重”的组件。核心逻辑是控制体积、降低安装失败率。

第二，硬件支持基线在上移。 放弃计算能力 5.0 的 CUDA 内核，把最旧支持代际推到 Pascal，这是一个明确的信号：维护老硬件的成本已经超过了收益。使用较老 GPU 的团队需要提前规划，要么锁定旧版本，要么从源码编译。

第三，LiteRT（原 TFLite）在走向独立。 从 C++ API 的兼容性调整，到 tf.lite.Interpreter 迁移至 ai_edge_litert.interpreter 并设定 2.20 的删除期限，端侧推理这条线正在从 TensorFlow 主仓库中逐步独立出来。这与 Keras 3.0 之后在 keras.io 独立发布更新的做法如出一辙。

第四，破坏性变更的预告期在拉长。 Numpy 2.0 在 2.17 就被预告，tf.lite.Interpreter 的删除在 2.19 就明确了 2.20 的时间点。对于生产环境而言，这种提前量是好事，但也意味着升级不再是“装上新版本就行”，而需要主动跟踪每个版本的弃用清单。

五、给工程团队的实操建议

基于上述素材，以下几点值得在升级规划中优先考虑：

• 固定版本时注意规范写法。 2.15 的教训表明，==2.15.0 和 ==2.15.* 可能带来完全不同的安装结果。在 requirements 文件中明确使用 .post1 或模糊版本规范，取决于团队对补丁版本的接受度。
• 检查 TensorRT 依赖路径。 如果当前流程依赖 TensorFlow 内置的 TensorRT 支持，2.17 是最后一个可用版本。需要评估是锁定 2.17，还是改为直接调用 TensorRT。
• 尽快迁移 tf.lite.Interpreter。 2.20 将删除该 API，迁移目标是 ai_edge_litert.interpreter。虽然 2.19 只是给出弃用警告，但一个版本周期的窗口并不宽裕。
• 评估 libtensorflow 的替代获取方式。 官方已停止发布该软件包，但仍可从 PyPI 包中解包获取。依赖它的构建流程需要确认这条路径是否可持续。
• 关注 Numpy 2.0 的边缘情况。 官方已提示可能破坏部分 API 的边缘情况，建议在测试环境中提前验证。

结语

TensorFlow 2.15 到 2.19 的发布说明，读起来不像一份功能清单，更像一份边界声明。这个框架正在明确哪些事情由自己负责，哪些交给 Keras、LiteRT 或外部库。对于使用者来说，这意味着升级决策需要更细致地审视依赖关系，而不只是看版本号。做减法的框架，往往要求使用者做更多的功课。

生成标记：本文由 ITPUB 文章生成平台基于已选素材整理生成。