LiteRT 转换遇到不支持算子时怎么判断是否启用 Select TF Ops

我第一次把一个 TensorFlow SavedModel 往 LiteRT 转换时，最容易犯的判断错误就是：看到 “Some ops are not supported” 就立刻打开 SELECT_TF_OPS。这样确实可能让转换继续，但模型能不能在目标端运行，还取决于对应的 TensorFlow 算子运行库是否一起进入应用。对我来说，比较稳妥的办法是先做一个小型兼容性检查：确认错误边界，再比较替换算子与 Select TF Ops 的包体、平台和维护成本。

官方地址：https://developers.google.com/edge/litert/conversion/tensorflow/convert_tf

Select TF Ops 说明：https://developers.google.com/edge/litert/conversion/tensorflow/ops_select

先确认错误属于 LiteRT 内置算子覆盖边界

LiteRT 的内置算子库只覆盖 TensorFlow 算子的一部分。当转换器提示某些算子没有 native LiteRT implementation 时，通常表示模型图里出现了当前内置算子集合无法直接承载的 TensorFlow 运算。官方转换文档给出的方向是使用 TF op fallback，也就是把需要的 TensorFlow 算子保留在 LiteRT 模型中。

这里要先排除两个容易混淆的情况。第一，模型本来就使用了你自己定义的 TensorFlow 算子，这不是简单打开开关就能解决的兼容问题；第二，算子在 TensorFlow 中存在，但没有进入 LiteRT 的 allowlist，处理方式与真正未知的自定义算子不同。本文只继续讨论第一类里的“内置算子没有对应实现”路径，不进入自定义算子开发。

用一个小转换脚本保留两类算子

我会先把转换逻辑写成一个小而明确的脚本。TFLITE_BUILTINS 保留 LiteRT 内置算子，SELECT_TF_OPS 再允许需要的 TensorFlow 算子进入模型。两者一起设置的意义是：能用内置算子的部分继续走内置实现，确实缺少实现的部分才由 Select TF Ops 承接。

import tensorflow as tf
# 从 SavedModel 创建转换器；输入目录应替换成项目自己的模型目录。
converter = tf.lite.TFLiteConverter.from_saved_model("saved_model")
# 保留 LiteRT 内置算子，同时允许转换器保留部分 TensorFlow 算子。
converter.target_spec.supported_ops = [
    tf.lite.OpsSet.TFLITE_BUILTINS,
    tf.lite.OpsSet.SELECT_TF_OPS,
]
# 生成模型二进制；这里不改变量化和代表性数据等其他策略。
tflite_model = converter.convert()
# 用二进制方式保存，避免模型文件被文本处理链路破坏。
with open("converted_select_ops.tflite", "wb") as model_file:
    model_file.write(tflite_model)

这段配置只回答“转换时允许哪些算子集合”，没有替你决定目标端依赖。转换成功后，模型已经携带了对 Select TF Ops 的要求；下一步必须检查应用使用的 LiteRT runtime 是否包含那部分 TensorFlow 算子。

按模型体积和平台运行时判断是否值得启用

我通常把决策拆成两个问题：这个算子是否能在模型侧合理替换，以及目标平台是否愿意承担额外 runtime。若可以用等价的内置算子表达，而且替换不会破坏精度和模型结构，TFLITE_BUILTINS-only 模型更容易控制体积。若算子是模型不可替代的一部分，启用 Select TF Ops 的价值在于先保住转换路径，再配套运行库。

官方文档明确提醒，带 TensorFlow 算子的 LiteRT 模型需要引入核心 TensorFlow runtime 或对应的 select-TF-ops 库，这会增加解释器二进制体积。Android 可以按模型只构建所需算子，以减少不必要的体积；Python 侧则通常随 TensorFlow 包提供这类支持。也就是说，决定条件不是“开关能不能让转换通过”，而是“目标端是否能接受这份依赖”。

让 Android、iOS 与 Python 的依赖跟着模型走

模型文件和 runtime 必须成对记录。以 Android 为例，官方文档给出的思路是同时加入标准 LiteRT AAR 和包含 select TF ops 的依赖；如果体积是硬约束，再进一步按模型构建自定义 AAR。下面的依赖片段只是集成位置示意，版本号应由项目当前依赖管理统一决定，不要把示例里的 nightly 占位版本直接复制到生产项目。

dependencies {
    // 标准 LiteRT runtime，承载内置算子。
    implementation("org.tensorflow:tensorflow-lite:")
    // 只有模型使用 Select TF Ops 时才加入这份额外运行时。
    implementation("org.tensorflow:tensorflow-lite-select-tf-ops:")
}
android {
    defaultConfig {
        ndk {
            // 只保留产品真正支持的 ABI，避免把无关架构打进包体。
            abiFilters += listOf("armeabi-v7a", "arm64-v8a")
        }
    }
}

iOS 的思路类似：在 TensorFlowLiteSwift 或 TensorFlowLiteObjC 旁边加入 TensorFlowLiteSelectTfOps，并按官方说明配置额外的 linker flag。C/C++ 集成则需要链接 LiteRT Flex delegate 共享库。不要把 Android 的依赖名直接套到其他平台，平台的运行时入口不同，但判断原则一致：模型中声明了 Select TF Ops，就要让目标解释器能找到相应算子实现。

用一张兼容性清单完成验收

我会把下面这些字段放进模型发布记录。它们不是额外的线上验证，而是为了避免“转换成功、集成失败”的交付遗漏。

1. 记录转换器输入：SavedModel 位置、转换脚本和 supported_ops 设置。
2. 记录模型依赖：是否出现 Select TF Ops，以及具体涉及的 TensorFlow 算子集合。
3. 记录运行平台：Android、iOS、Python 或 C/C++，以及对应的 runtime 依赖名称。
4. 记录包体策略：是否使用按模型裁剪的库、ABI 范围和可接受的体积预算。
5. 记录回退方案：若目标端不接受额外 runtime，回到模型侧评估算子替换，而不是反复修改同一个转换开关。

如果只是想让转换器先通过，SELECT_TF_OPS 很方便；如果要把模型交给资源敏感的移动端，它就不是免费的兼容开关。我的判断顺序是：先确认确实是 LiteRT 内置覆盖边界，再比较算子能否替换，最后才把转换配置、runtime 和包体预算一起评估。

常见问题

启用 Select TF Ops 后是不是所有 TensorFlow 算子都能转换？

不是。它解决的是一部分 LiteRT 内置算子没有对应实现的情况；真正未知的自定义算子、allowlist 或模型本身的问题仍要单独处理。

转换成功但 Android 加载失败，最先看什么？

先看应用是否只引入了标准 LiteRT AAR，却没有带上模型需要的 select-TF-ops runtime。模型转换和目标端依赖是两个相连但不同的环节。

为了减小包体，能不能只保留 TFLITE_BUILTINS？

可以作为目标，但前提是模型中的不支持算子能够被合理替换，且替换后的精度、形状和功能满足需求。否则强制只用内置算子会把问题推回转换阶段。