Keras 3.2 宣称一套代码能在TensorFlow、JAX和PyTorch上跑。我们拿实际项目测了测，发现简单场景确实能通，但稍微复杂点，坑就开始冒出来了。
简单模型：出奇地一致
我们用Keras 3.2建了一个经典的三层卷积图像分类模型，在RTX 4090机器上，分别用三个后端在MNIST上训练20个epoch。结果：验证准确率都在99.1%到99.3%之间，训练时间差异在5%以内。Keras 3.2对内核做了重构，后端抽象层直接映射到各框架原生操作，所以简单模型跑起来很顺。你只需要设置一下KERAS_BACKEND环境变量，模型代码一行不用改。
迁移学习：兼容性断在自定义层
一上迁移学习，问题就来了。我们加载了keras.applications里的预训练ResNet50，想冻结前40层微调。TensorFlow和JAX后端正常，但到了PyTorch后端，出了两个问题。
第一，权重加载时，参数名映射有细微差异。比如TensorFlow的conv2d/kernel:0，在PyTorch里可能被解释成conv2d.weight。如果你的自定义层没严格遵守Keras的命名约定，权重就加载失败。我们测试了一个用keras.layers.Layer自定义的注意力层，内部用了self.add_weight，在PyTorch后端下，部分权重的梯度计算图断了，loss根本不动。
第二，性能开销明显。同样一个ResNet50，PyTorch后端的训练速度比原生的torchvision.models.resnet50慢了大约18%。Keras的抽象层在PyTorch后端下引入了额外的张量拷贝和计算图转换。简单模型感觉不明显，但模型一复杂，比如我们一个带动态形状循环的NLP模型，PyTorch后端甚至比TensorFlow后端还慢了35%。
模型部署：工具链断裂是最大坑
训练阶段的兼容问题还能调调代码，部署阶段的断裂就真是软肋了。
我们把用TensorFlow后端训练好的ResNet50转成TensorFlow Lite，很顺。但用PyTorch后端训练的同一个模型，想导出时，麻烦就来了。Keras 3.2的keras.export API能导出SavedModel格式，但后面的转换工具链——比如转成ONNX或TensorRT——基本走不通。
问题在于，PyTorch后端导出的SavedModel里面是Keras的操作符，不是纯粹的PyTorch算子。主流的tf2onnx这类工具根本解析不了。我们试了Keras自带的keras.saving.export_lib，它说能导出ONNX，但用我们的自定义层模型导出后，用ONNX Runtime一加载，就报一堆“算子不支持”的错误。
我们最后的实际做法是：如果最终要部署到云、边、端，还是用TensorFlow后端训练最省心，它的工具链最成熟。如果用了JAX或PyTorch后端训练，部署前得手动把权重迁回TensorFlow模型里，这等于又多干了一轮活。有个客户项目，我们就因此只把Keras 3.2用在原型验证，生产训练和部署还是走各框架原生的路子。
所以，什么时候用，什么时候不用？
Keras 3.2在这些场景下很好用：
- 快速跑想法：一个下午用三种框架对比一个算法的收敛速度或内存占用，能省很多重复写代码的时间。
- 教学和研究：学生可以专注学算法，不用纠结某个框架的API细节。
- 团队协作：团队里有人喜欢PyTorch，有人用TensorFlow，可以用Keras 3.2统一代码规范，降低协作成本。
但它不适合所有生产场景。如果你的模型有很多自定义操作，或者对训练速度有极致要求，或者需要直接部署为PyTorch的TorchScript，那还是坚持用原生框架更靠谱。这就像我们之前测端侧大模型一样，纸面参数好看，实际跑起来又是另一回事。
总之，Keras 3.2的“一处代码，处处运行”在2026年中期，只算部分兑现。它是个强大的实验平台，但不是生产环境的万能钥匙。选工具，得看具体要解决什么问题，就像国产AI芯片在垂类场景赚钱一样，合适比通用更重要。