TensorFlow 2.10+ 默认启用 MLIR 转换器，无需设置 EXPERIMENTAL_USE_MLIR；应避免 Anaconda 环境，量化需先动态再全整型，推理必须用 Interpreter.invoke() 并测 p99 延迟，且务必真机验证。
直接用 TFLite 转换器启用 MLIR 优化，别手动开开关
TensorFlow 2.10+ 已默认启用 MLIR-based 转换器，tf.lite.EXPERIMENTAL_USE_MLIR 这个 flag 不再需要设为 True，强行设置反而可能触发旧路径导致优化失效。验证方式很简单：
- 运行
print(tf.lite.TFLiteConverter.from_saved_model("xxx")._experimental_use_mlir)—— 输出None或True都正常，只要不报错就说明走的是新流水线 - 转换后模型体积明显缩小（比如 MobileNetV3 从 18MB → 4.3MB），且
tflite_model中包含更多 fused op（如CONV_2D_WITH_RELU）就是 MLIR 生效的信号 - 避免在 Anaconda 环境下转换：其自带的
libstdc++版本常与 MLIR 的 LLVM 后端冲突，推荐用python -m venv新建干净环境
量化必须分两步：先动态量化，再全整数量化
直接上 INT8 全量化容易失败或精度崩塌，尤其当模型含 BatchNorm、Softmax 或动态控制流时。正确顺序是：
- 第一步用
converter.optimizations = [tf.lite.Optimize.DEFAULT]做动态范围量化——它只量化权重，激活仍为 FP32，兼容性最强，能快速验证是否跑得通 - 第二步才加校准数据和类型约束：
converter.representative_dataset = representative_data_gen，并设converter.inference_input_type = tf.int8和converter.inference_output_type = tf.int8 -
representative_data_gen必须 yield 至少 100 个真实分布的样本，shape/dtype 严格匹配模型输入；如果只给 1 张图，校准参数会严重偏移，导致 p99 延迟飙升
推理时别调 model.predict()，用 Interpreter.invoke() 直接喂 tensor
在边缘设备上，Keras 的 predict() 会额外做数据 batching、回调触发、进度条渲染等，纯属冗余。TFLite 的 Interpreter 是零封装入口：
- 加载后必须调
interpreter.allocate_tensors()，否则invoke()会静默失败或返回全零结果 - 输入 tensor 要用
interpreter.set_tensor(input_index, input_data)显式赋值，不能靠 shape 自动 broadcast —— 边缘设备内存紧张，broadcast 会触发隐式 copy - 输出读取前务必先
interpreter.invoke()，再用interpreter.get_tensor(output_index)拿结果；漏掉invoke()是最常见“推理没反应”的原因
延迟抖动比平均延迟更致命，得测 p99 而不是 p50
边缘设备上一次卡顿（比如 200ms 延迟）可能直接导致视频丢帧或控制指令超时，所以不能只看平均值。实测必须覆盖真实负载：
立即学习“Python免费学习笔记（深入）”；
- 在目标设备（Jetson Nano / RK3588 / 骁龙芯片）上跑至少 100 次，用
time.perf_counter_ns()记录每次invoke()前后时间差 - 重点关注
np.percentile(latencies, 99)，如果 p99 是 p50 的 3 倍以上，大概率是内存带宽争用或 GIL 阻塞，此时需用py-spy抓 profile，而不是继续调模型 - 别信模拟器结果：Android Emulator 或 x86 上的 TFLite 解释器行为与真机差异极大，RK3588 的 NPU 加速、骁龙的 Hexagon delegate 都必须真机验证
