直接结论：该算子未注册CPU实现，TensorFlow不会自动降级；应查get_registered_kernels_for_op()确认CPU kernel缺失，再用原生TF/NumPy替代、禁用XLA或补全C++ CPU kernel注册。
TensorFlow算子报错“OpKernel not found for CPU”怎么办
直接结论：这不是“不支持CPU回退”，而是该算子根本没注册 CPU 实现，TensorFlow 不会自动降级到 CPU —— 它连 fallback 机制都不触发，直接报错终止。常见于自定义 OP、较新版本新增算子（如 tf.raw_ops.StringNGrams）、或启用了 XLA_JIT 但未禁用时强制绑定设备。
检查算子是否真有 CPU 实现
别猜，查源码或运行时注册表。最可靠方式是用 tf.test.is_built_with_cuda() 辅助判断当前 build 是否包含 CPU kernel，再结合 tf.python.framework.test_util.get_registered_kernels_for_op() 查注册情况：
import tensorflow as tf
from tensorflow.python.framework import test_util
kernels = test_util.get_registered_kernels_for_op("StringNGrams")
print([k.device_type for k in kernels]) # 输出可能只有 ['GPU']，没有 'CPU'
如果输出里不含 CPU，说明该 OP 确实没实现 CPU 版本。此时强行指定 with tf.device('/CPU:0'): 会直接失败，不是配置问题，是硬缺失。
绕过缺失 CPU 算子的三种实操路径
根据场景选最轻量的解法，别一上来就重写 OP：
立即学习“Python免费学习笔记（深入）”；
- 用等价的纯 Python / NumPy / TF 原生组合替代：比如
tf.raw_ops.StringNGrams可用tf.strings.unicode_split+tf.data.Dataset.window模拟，虽慢但可跑通 CPU - 临时关闭 XLA：如果错误出现在启用
tf.function(jit_compile=True)后，去掉jit_compile或设为False，XLA 会跳过未注册 kernel 的算子，让 TF 走默认执行路径（可能含 CPU fallback） - 强制走 eager 模式验证：在出错前加
tf.config.run_functions_eagerly(True)，eager 下部分 OP 会退到 host-side 实现（如字符串处理），能快速定位是否为 graph 构建期绑定导致
自定义 OP 补 CPU kernel 的关键点
如果你自己写了 tf.RegisteredGradient 或用 tf.load_op_library() 加载了 .so，却只编译了 GPU 版本，那必须补全 CPU 注册：
- 在 C++ kernel 实现中，确保同时注册了
REGISTER_KERNEL_BUILDER(Name("MyOp").Device(DEVICE_CPU), MyOpCPUKernel) - 构建时不能漏掉
-Dtensorflow_BUILD_SHARED_LIB=ON和 CPU 相关 flag，bazel 编译需显式包含//tensorflow/core:cpu_base - Python 加载后，仍要用前面提到的
get_registered_kernels_for_op验证 CPU kernel 是否可见——很多“编译成功但不生效”的问题，根源是动态库加载顺序或 symbol 冲突
真正卡住的往往不是怎么写 kernel，而是构建环境没把 CPU target 编进去，或者加载时被旧版本 .so 覆盖。先确认 ls -l 看你 load 的 .so 文件修改时间，再查 nm -D your_op.so | grep MyOp 是否导出了 CPU 符号。
