TFLite

Instalación

# LiteRT es el nombre actual que Google da a TensorFlow Lite. Ambos extras# instalan la misma toolchain y producen la misma salida .tflite.pip install "libreyolo[tflite]"

python -c "import sys; print(sys.version_info >= (3, 12))"

El extra trae onnx2tf para la conversión y ai-edge-litert para ejecutar el resultado, ambos detrás de un marcador de Python 3.12. En un intérprete más antiguo, la exportación lanza un ImportError que nombra el requisito de versión en lugar de fallar dentro del conversor.

libreyolo[litert] instala exactamente lo mismo. La cadena de formato litert es un alias de tflite, y el archivo de salida es un .tflite en cualquier caso.

Exportación

from libreyolo import LibreYOLO model = LibreYOLO("LibreYOLO9t.pt") # Escribe weights/LibreYOLO9t.tflite y weights/LibreYOLO9t.tflite.jsonpath = model.export(format="tflite", imgsz=640)print(path)

libreyolo export --model LibreYOLO9t.pt --format tflite --imgsz 640 # "litert" se acepta como alias y resuelve al mismo exportador.libreyolo export --model LibreYOLO9t.pt --format litert --imgsz 640

model.export(    format="tflite",    imgsz=640,        # int, o (alto, ancho)    batch=1,    simplify=True,    # onnxsim sobre el intermedio ONNX    output_path=None, # None escribe weights/<stem>.tflite    verbose=False,    # True muestra el log de onnx2tf) # dynamic=True lanza ValueError: el conversor necesita formas estáticas.# half=True e int8=True se rechazan antes del trazado.

La familia y la tarea se comprueban antes que nada, así que una combinación no soportada falla de inmediato con el error concreto del conversor o del runtime que la dejó fuera, no con un mensaje genérico. La conversión en sí es una llamada a onnx2tf como subproceso, en modo flatbuffer_direct, sobre un intermedio ONNX estático.

Los metadatos son un sidecar. weights/LibreYOLO9t.tflite.json lleva la familia, la tarea, los nombres de clase, el tamaño de entrada y el esquema de pose; el FlatBuffer en sí no tiene campo de metadatos de LibreYOLO, así que los dos archivos viajan juntos.

Ejecutar el artefacto

from libreyolo import LibreYOLO, SAMPLE_IMAGE model = LibreYOLO("weights/LibreYOLO9t.tflite")result = model.predict(SAMPLE_IMAGE)print(result.boxes.xyxy[:3])

import json import numpy as npfrom ai_edge_litert.interpreter import Interpreter interpreter = Interpreter(model_path="weights/LibreYOLO9t.tflite")interpreter.allocate_tensors()detail = interpreter.get_input_details()[0]print(detail["shape"], detail["dtype"])   # NHWC, no NCHW interpreter.set_tensor(detail["index"], np.zeros(detail["shape"], np.float32))interpreter.invoke()for output in interpreter.get_output_details():    print(output["name"], interpreter.get_tensor(output["index"]).shape) # Los nombres de clase, la tarea y el tamaño de entrada viven en el sidecar.meta = json.load(open("weights/LibreYOLO9t.tflite.json"))print(meta["model_family"], meta["task"], meta["names"]) # El preprocesado, la transposición de NCHW a NHWC y el postprocesado corren de tu cuenta.

LibreYOLO() despacha por el sufijo .tflite y devuelve el mismo objeto Results que el checkpoint. El backend lee el sidecar, transpone el blob NCHW a NHWC cuando el intérprete pide una entrada channels-last, aplica la escala de cuantización y el zero point del intérprete donde estén presentes, y transpone las salidas de vuelta al layout que espera el postprocesado de LibreYOLO.

El segundo snippet es la vía del runtime puro. El preprocesado, la transposición de layout, la decodificación, el NMS y el reescalado de coordenadas corren todos de tu cuenta ahí, y el detalle del layout es el que más fácil se pasa por alto: onnx2tf emite entradas channels-last, así que un blob con forma (1, 3, 640, 640) no encajará.

Restricciones

Solo formas estáticas. dynamic=True lanza ValueError antes del trazado, y el lienzo de exportación queda fijado en el valor al que se resolvió imgsz.

Solo FP32. half=True e int8=True se rechazan ambos durante la validación, así que hoy por hoy el despliegue cuantizado no es alcanzable desde este exportador.

La cobertura aquí es más estrecha que la de los formatos de grafo, y la decide la medición en lugar de la familia. Entre las combinaciones validadas están la detección con YOLO9, YOLOX y YOLO-NAS, la segmentación semántica con PIDNet, las cuatro familias de clasificación CNN, el embedding con DINOv2 y SigLIP2, la clasificación con SigLIP2, los bordes con TEED y DexiNed, y la restauración con Real-ESRGAN y SwinIR. SwinIR arrastra una salvedad extra: la paridad se mantiene cuando las dimensiones de origen coinciden exactamente con el lienzo de exportación, y los orígenes más pequeños se rellenan hasta el lienzo antes de que corra el transformer, lo que puede divergir de la inferencia nativa a tamaño variable.

Las entradas bloqueadas nombran el fallo exacto, y conviene leerlo antes de intentar un rodeo. Unos cuantos ejemplos: la detección con RF-DETR convierte en su lienzo nativo de 384 pero LiteRT no puede reservarlo porque STRIDED_SLICE recibe una entrada por encima del rango 5-D que soporta; PicoDet se rechaza porque un RESHAPE mapea 19.200 elementos de entrada a 9.600 de salida; D-FINE hace caer al conversor en el manejo de formas de GatherElements; RTMDet exporta y recarga con la paridad en crudo intacta, pero los boxes públicos bajan a 0,911 de IoU con 29,9 px de deriva de coordenadas.

Para la tabla completa de familias y tareas, consulta la matriz de exportación. Para una combinación concreta, incluida la cadena de motivo detrás de un bloqueo:

libreyolo formats --family yolo9 --task detect