What does adding tf.lite.OpsSet.SELECT_TF_OPS to a TFLite conversion cost you?

## Why conversion refuses in the first place TensorFlow has thousands of operators. TFLite implements a few hundred, chosen because they are what inference models actually need and because every kernel is code that must be compiled into a mobile app. When the converter hits an op with no built-in equivalent and no lowering, it raises an error naming the op and pointing at the Select TF ops escape hatch. The ops that trigger this cluster in predictable places: text and string processing, ragged or sparse tensors, data-pipeline ops that leaked into the serving signature, control flow with dynamic trip counts, some RNG ops, and newer or exotic layers that have not been given a TFLite kernel. ## What the flag does ``` converter.target_spec.supported_ops = [ tf.lite.OpsSet.TFLITE_BUILTINS, tf.lite.OpsSet.SELECT_TF_OPS, ] ``` List both. `TFLITE_BUILTINS` keeps the built-in kernels preferred, and `SELECT_TF_OPS` permits the remainder to be emitted as TensorFlow ops embedded in the FlatBuffer. Conversion now succeeds. ## The four costs **Binary size.** Those ops are not implemented in the TFLite runtime, so the app has to ship the Select TF ops runtime library that hosts real TensorFlow kernels. That is a large dependency — tens of megabytes of added download size in the default configuration, against a built-in-only runtime measured in single-digit megabytes. On consumer mobile apps, download size is a business metric, and this alone kills the option in many teams. Selective builds that include only the kernels your model uses can claw much of it back, at the cost of a custom build step in your release pipeline. **CPU only.** The Select TF ops kernels run on the CPU. Any accelerator you were counting on cannot execute them. **Graph fragmentation.** This is the one candidates miss. If your unsupported op sits in the middle of the network, the graph splits into a supported prefix, a CPU-only middle, and a supported suffix. Each seam is a synchronization point and a tensor copy between the accelerator's memory and the CPU's. A model that was 5 ms end to end on an accelerator can become dramatically slower once it is cut in three, and the cause is not the op's own cost but the round trips around it. **Quantization.** Select TF ops generally have no int8 path, so they stay float. If you were converting with a representative dataset targeting an integer-only device, the presence of a float island can mean the model is rejected outright. ## What to do instead Before reaching for the flag, ask why the op is there. *Is it preprocessing?* String splitting, tokenization, image decoding and normalization frequently end up inside the exported signature because they were part of the training graph. Move them into application code. This is the single most common real fix and it costs nothing at run time. *Is it a shape problem?* Ops that only appear because a dimension is dynamic often vanish once you export with a fixed `input_signature`, letting the converter constant-fold the surrounding logic. *Is it one layer?* Rewriting a custom layer in terms of supported primitives is often a half-day of work and permanently removes the dependency. *Is it genuinely unavoidable?* Then you have two paths. `SELECT_TF_OPS` gets you running today. Alternatively `converter.allow_custom_ops = True` lets the op through as a custom op with no kernel attached, and you supply a hand-written implementation registered with the runtime — far more work, but it keeps the small runtime and lets you write an accelerator-friendly kernel. ## How to talk about it in an interview The weak answer is "add SELECT_TF_OPS and it works." The strong answer names the tradeoff and then says what you would measure: which ops actually forced it (the converter error tells you), whether they are in the hot path or at the edges, what the binary size delta is against your app's budget, and what the on-device latency looks like with and without. Then it presents the flag as a deliberate, temporary choice with an owner and a follow-up, rather than a fix.