TensorFlow 这几个版本的发布说明连起来读，主线不是加功能，而是拆东西。tensorrt 依赖被拿掉，libtensorflow 不再单独发，tf.lite.Interpreter 被限期搬走。边界正在重画。
2.15 那次热修复：一个 Python 包拖垮整条安装链
2023 年 12 月，TensorFlow 发了个不常见的版本号：2.15.0.post1。不是功能更新，是救火。
起因是 2.15.0 的 Python 包在元数据里引用了 tensorrt 相关包。用户没预装、也没加额外安装标志时，这些包解析不到。受影响最直接的是那批执行 pip install tensorflow[and-cuda] 并同时装 NVIDIA CUDA 依赖的人。
故障表现分两种：有人实际落到 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 不会去装 post1。Linux 上要么写 ==2.15.0.post1 钉死，要么写 ==2.15.* 这类模糊约束去拿最新兼容版。
对生产团队来说，这不是小事。requirements.txt 里一个等号后面少个 .post1，CI 里跑出来的可能就是另一套 TensorFlow。
安装验证可以这样查：
输出里带 .post1 才算拿到修复版。这不只是 2.15 的问题，任何带 post 修复的 Python 包都有同样的固定版本陷阱。
2.17 的两件事：CUDA 内核加加减减，TensorRT 被判出局
2024 年 7 月的 2.17 把取舍写得更直白。
加的是计算能力 8.9 的专用 CUDA 内核，Ada 代 GPU（RTX 40 系列、L4、L40）能吃到性能提升。减的是计算能力 5.0 的内核，理由是控制 Python wheel 体积。
预编译包支持的最旧 NVIDIA 代际，因此从 Maxwell 上移到 Pascal（计算能力 6.0）。还在用 Maxwell 的只有两条路：留在 2.16，或者从源码编译——前提是手上的 CUDA 版本还认 Maxwell。
另一条更值得关注：官方明确说，TensorFlow 2.18 起不再支持 TensorRT，2.17 是最后一个带它的版本。
把 2.15 的安装事故和这条声明放一起看，逻辑很顺。一个可选依赖持续制造安装摩擦，收益又能通过直接调 TensorRT 或换推理栈拿到，从主发行版剥离就是迟早的事。
2.17 还提前打了招呼：2.18 会带 NumPy 2.0 支持，可能破坏 TensorFlow API 的一些边缘情况。提前一个版本预警，对跑生产系统的人来说就是排升级窗口的信号。
2.19：LiteRT 拆分加速，libtensorflow 退场
2025 年 3 月的 2.19 还在同一条线上，动作更碎。
LiteRT 的 C++ API 动了两个常量。tflite::Interpreter::kTensorsReservedCapacity 和 tflite::Interpreter::kTensorsCapacityHeadroom 从 constexpr 编译时常量改成 const 引用。官方理由是给 Play services 里的 TFLite 争取更好的 API 兼容性，同时保留将来改这些常量值的余地。
这是典型拿一点编译期优化换兼容性的做法。对在 Android 上通过 Play services 分发模型的人来说，影响可能比字面看着大。
tfl.Cast 算子现在运行时内核支持 bfloat16。bfloat16 保住和 float32 一致的指数范围、压掉尾数位，推理场景里常用来平衡精度和内存。
tf.lite.Interpreter 进入倒计时：2.19 里给弃用警告并重定向到 ai_edge_litert.interpreter，2.20 直接删。迁移窗口只有一个版本周期。
libtensorflow 也停止发布了。还能从 PyPI 包里解包拿到，但依赖预编译 C/C++ 库的团队得重新想获取方式。
Keras 同样在脱钩。Keras 3.0 起，多后端 Keras 的发布更新写在 keras.io，不再跟 TensorFlow 发布说明走。
边界重画的四条线
把 2.15、2.17、2.19 摞一起看，能理出几条。
主发行版持续瘦身。去掉 tensorrt Python 包依赖、放弃 TensorRT 支持、停发 libtensorflow，目标就两个：压体积、降安装失败率。
硬件支持基线在上移。砍掉计算能力 5.0 的 CUDA 内核，最旧支持代际推到 Pascal。老硬件的维护开销早就超过回报了，用旧 GPU 的团队要么锁版本要么源码编译。
LiteRT 在走向独立。C++ API 调兼容性，tf.lite.Interpreter 迁到 ai_edge_litert.interpreter 并定死 2.20 删除，端侧推理这条线正从主库往外抽。跟 Keras 3.0 之后独立发布是一个路子。
破坏性改动的预告期在拉长。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 就是最后一班车。往上走之前，先确认能不能直接调 TensorRT 或换推理栈。
硬件代际要盘一遍。手上有 Maxwell 的，2.16 是终点，或者走源码编译。这一步建议在升级 2.17 之前做完，别等 CI 挂了再回头查。
端侧代码要提前迁。tf.lite.Interpreter 在 2.19 就会刷弃用警告，2.20 删。现在就换成 ai_edge_litert.interpreter，一个版本周期听着够，实际排期往往不够。
libtensorflow 的获取方式要重评。虽然还能从 PyPI 解包，但依赖预编译库的流水线最好现在就试一遍解包路径，确认构建脚本不受影响。
Keras 的发布渠道要跟对。多后端 Keras 的更新看 keras.io，别在 TensorFlow 发布说明里找，容易漏。
这些动作都不是新功能，全是拆依赖、换路径、锁版本。TensorFlow 在收窄自己的范围，跟着走的项目也得同步收窄预期。
