Export YOLO Models to LiteRT for Edge and Web Deployment

LiteRT (short for Lite Runtime) is Google's high-performance runtime for on-device AI. It is the next generation and the new name for TensorFlow Lite (TFLite), and it runs the same .tflite model format. With LiteRT, a single exported Ultralytics YOLO model deploys across mobile, embedded, edge, and the browser — covering everything that the older tflite and tfjs export formats handled separately, now under one umbrella.

The LiteRT export format optimizes your models for tasks like object detection, segmentation, pose estimation, and classification so they run fast and offline on a wide range of devices.

!!! tip "Run YOLO on Android with LiteRT today via the official Flutter plugin"

The official [Ultralytics YOLO Flutter plugin](https://github.com/ultralytics/yolo-flutter-app) runs LiteRT `.tflite` exports on Android out of the box — real-time camera inference, single-image prediction, GPU acceleration, and automatic model download for all seven YOLO26 tasks, including Depth. For Apple devices use the [CoreML export](coreml.md); for Qualcomm Snapdragon NPUs see the [Qualcomm QNN integration](qnn.md).

!!! important "Official mobile input sizes"

Export classification models at `imgsz=224`. Export detect, segment, semantic, depth, pose, and OBB models at
`imgsz=640`. This 224/640 standard is shared by the official LiteRT, CoreML, and QNN mobile assets.

!!! tip "Run YOLO on Web with LiteRT.js today via the official @ultralytics/yolo npm package"

The official [Ultralytics YOLO NPM package](https://www.npmjs.com/package/@ultralytics/yolo) runs LiteRT `.tflite` exports directly in the browser via [LiteRT.js](https://developers.google.com/edge/litert/web) no server or Python required — with real-time webcam inference, single-image prediction, and WebGPU acceleration (automatic CPU/WASM fallback) across all six YOLO26 tasks (detect, segment, pose, OBB, classify, semantic). On WebGPU it's often ~2× faster than ONNX Runtime Web.

```bash
npm i @ultralytics/yolo @litertjs/core
```

Why Should You Export to LiteRT?

LiteRT is an open-source framework designed for on-device inference, also known as edge computing. It gives developers the tools to execute trained models on mobile, embedded, and IoT devices, traditional computers, and — through LiteRT.js — directly in web browsers and Node.js.

One model format, every target:

• Mobile & Embedded: Android, iOS, embedded Linux, and microcontrollers (MCUs).
• Edge accelerators: Compatible with the Coral Edge TPU for further acceleration.
• Browser & Node.js: LiteRT.js runs the same .tflite model on the web with WebGPU/WASM acceleration — replacing the need for a separate TensorFlow.js export.

Key Features of LiteRT Models

• On-device Optimization: Reduces latency by processing data locally, enhances privacy by not transmitting personal data, and minimizes model size to save space.
• Multiple Platform Support: Runs on Android, iOS, embedded Linux, microcontrollers, and modern web browsers.
• Hardware Acceleration: Leverages XNNPACK on CPU, and GPU acceleration via OpenCL, Metal, and WebGPU. The GPU delegate runs in FP16 by default for additional speed.
• Quantization: Supports FP32, static INT8 (quantize=8, int8 weights + int8 activations), static INT16-activation (quantize="w8a16", int8 weights + int16 activations for higher accuracy), and dynamic INT8 (quantize="w8a32", int8 weights + FP32 activations, no calibration data needed) to compress models and speed up inference with minimal accuracy loss.
• Diverse Language Support: Compatible with Java/Kotlin, Swift, Objective-C, C++, Python, and JavaScript.

Measured Performance

Hardware: Xiaomi 17 with 12 GB LPDDR5X memory and Android 16 / API 36. Its 3 nm Snapdragon 8 Elite Gen 5 (SM8850) has an 8-core Qualcomm Oryon CPU (2 Prime cores up to 4.6 GHz and 6 Performance cores up to 3.62 GHz), Adreno GPU, and Hexagon NPU.

| Model | Task | size ^(pixels) | CPU ^{w8a32 LiteRT (ms)} | GPU ^{w8a32 LiteRT (ms)} | | ------------- | -------- | --------------------------- | -------------------------------------- | --------------------------------------- | | YOLO26n | Detect | 640 | 52.2 ^{1.8 / 48.1 / 2.4} | 15.8 ^{2.3 / 8.9 / 4.6} | | YOLO26n-seg | Segment | 640 | 73.4 ^{1.8 / 65.6 / 6.0} | 33.2 ^{1.8 / 23.8 / 7.6} | | YOLO26n-sem | Semantic | 640 | 61.2 ^{1.8 / 51.1 / 8.3} | 34.2 ^{1.8 / 24.0 / 8.3} | | YOLO26n-depth | Depth | 640 | 124.4 ^{1.9 / 115.1 / 7.4} | 23.0 ^{1.8 / 13.5 / 7.7} | | YOLO26n-cls | Classify | 224 | 4.4 ^{0.4 / 4.0 / 0.0} | 3.1 ^{0.8 / 2.1 / 0.2} | | YOLO26n-pose | Pose | 640 | 57.4 ^{1.8 / 53.8 / 1.8} | 16.6 ^{2.7 / 10.1 / 3.9} | | YOLO26n-obb | OBB | 640 | 50.3 ^{1.8 / 47.2 / 1.4} | 11.7 ^{1.8 / 7.8 / 2.0} |

• Speed values are single-image burst latencies — the mean of 15 runs after 3 warmup runs on bus.jpg, measured with the Ultralytics Flutter plugin 0.6.10 and the standardized v0.6.6 assets. CPU/GPU order alternated between tasks in one sequential sweep. Native logs confirmed that every CPU row used LiteRT CPU/XNNPACK and every GPU row delegated the complete graph to LiteRT OpenCL (LITERT_CL).
• The LiteRT export traces the PyTorch model directly, producing an NCHW .tflite with a float input — the GPU delegate compiles the whole graph (all seven tasks run on the Adreno GPU here), and w8a32 needs no calibration data. Consumers should read tensor shapes and signature names instead of assuming the legacy onnx2tf NHWC layout or Identity output names; pack RGB data directly as planar CHW or transpose it before inference. Semantic exports return NCHW logits and require a host-side class argmax. The official Android assets are hosted on the yolo-flutter-app v0.6.6 release, with the detailed benchmark record in the Flutter performance doc.
• The matching Snapdragon Hexagon NPU and LiteRT CPU/GPU numbers are in the Qualcomm QNN integration.
• Compare the Apple CPU/accelerator results in the CoreML integration.

The following device sweeps use the same standardized v0.6.6 assets.

Google Pixel 10

Hardware: Google Pixel 10 with 12 GB memory and Android 16 / API 36. Its 3 nm Google Tensor G5 has an 8-core CPU (1 Prime core up to 3.78 GHz, 5 Performance cores up to 3.05 GHz, and 2 Efficiency cores up to 2.25 GHz), PowerVR D-Series GPU, and Google TPU. Core clocks and the GPU driver name were read from the benchmark device because Google does not publish them in the linked specifications.

| Model | Task | size ^(pixels) | CPU ^{w8a32 LiteRT (ms)} | GPU ^{w8a32 LiteRT (ms)} | | ------------- | -------- | --------------------------- | --------------------------------------- | ---------------------------------------- | | YOLO26n | Detect | 640 | 53.3 ^{1.5 / 50.2 / 1.6} | 45.5 ^{3.8 / 37.7 / 4.0} | | YOLO26n-seg | Segment | 640 | 87.7 ^{1.8 / 78.5 / 7.5} | 50.9 ^{3.0 / 36.9 / 10.9} | | YOLO26n-sem | Semantic | 640 | 68.6 ^{1.5 / 59.0 / 8.0} | 71.6 ^{1.5 / 59.5 / 10.6} | | YOLO26n-depth | Depth | 640 | 120.3 ^{1.5 / 112.5 / 6.3} | 52.5 ^{2.0 / 37.5 / 13.0} | | YOLO26n-cls | Classify | 224 | 4.0 ^{0.3 / 3.4 / 0.2} | 17.6 ^{0.9 / 16.7 / 0.1} | | YOLO26n-pose | Pose | 640 | 59.7 ^{1.5 / 57.0 / 1.2} | 46.6 ^{3.8 / 39.2 / 3.5} | | YOLO26n-obb | OBB | 640 | 52.0 ^{1.5 / 48.9 / 1.7} | 45.5 ^{4.0 / 38.5 / 2.9} |

Benchmark: Mean of 15 predict() calls after 3 warmups on bus.jpg, using ultralytics_yolo 0.6.10 and the official v0.6.6 assets. CPU/GPU order alternates between tasks in one sequential sweep. Native logs confirmed that every CPU row used LiteRT CPU/XNNPACK and every GPU row delegated the complete graph to LiteRT OpenCL (LITERT_CL).

Samsung Galaxy S26

Hardware: Samsung Galaxy S26 (SM-S942B) with 12 GB memory and Android 16 / API 36. Its 2 nm Exynos 2600 has a 10-core Armv9.3 CPU (1 C1-Ultra core up to 3.8 GHz, 3 performance C1-Pro cores up to 3.26 GHz, and 6 efficiency C1-Pro cores up to 2.76 GHz), Xclipse 960 GPU, and Samsung NPU.

| Model | Task | size ^(pixels) | CPU ^{w8a32 LiteRT (ms)} | GPU ^{w8a32 LiteRT (ms)} | | ------------- | -------- | --------------------------- | -------------------------------------- | --------------------------------------- | | YOLO26n | Detect | 640 | 36.7 ^{1.3 / 33.8 / 1.7} | 16.4 ^{1.4 / 12.3 / 2.6} | | YOLO26n-seg | Segment | 640 | 54.6 ^{1.2 / 48.0 / 5.3} | 32.8 ^{1.3 / 24.5 / 7.0} | | YOLO26n-sem | Semantic | 640 | 47.8 ^{1.2 / 38.4 / 8.1} | 34.2 ^{1.3 / 24.9 / 8.0} | | YOLO26n-depth | Depth | 640 | 92.9 ^{1.2 / 84.8 / 6.9} | 33.5 ^{1.3 / 22.4 / 9.8} | | YOLO26n-cls | Classify | 224 | 2.7 ^{0.2 / 2.3 / 0.2} | 2.6 ^{0.2 / 2.4 / 0.0} | | YOLO26n-pose | Pose | 640 | 42.8 ^{1.3 / 40.5 / 1.0} | 18.4 ^{1.4 / 14.1 / 2.9} | | YOLO26n-obb | OBB | 640 | 37.5 ^{1.3 / 35.1 / 1.2} | 18.8 ^{2.5 / 14.6 / 1.8} |

Benchmark: Mean of 15 predict() calls after 3 warmups on bus.jpg, using ultralytics_yolo 0.6.10 and the official v0.6.6 assets. CPU/GPU order alternates between tasks in one sequential sweep. Native logs confirmed that every CPU row used LiteRT CPU/XNNPACK and every GPU row delegated the complete graph to LiteRT OpenCL (LITERT_CL).

Xiaomi 17T Pro

Hardware: Xiaomi 17T Pro (2602EPTC0G) with 12 GB LPDDR5X memory and Android 16 / API 36. Its 3 nm MediaTek Dimensity 9500 (MT6993) has an 8-core Armv9.3 CPU (1 C1-Ultra core up to 4.21 GHz, 3 C1-Premium cores up to 3.5 GHz, and 4 C1-Pro cores up to 2.7 GHz), Mali-G1 Ultra MC12 GPU, and MediaTek NPU 990.

| Model | Task | size ^(pixels) | CPU ^{w8a32 LiteRT (ms)} | GPU ^{w8a32 LiteRT (ms)} | | ------------- | -------- | --------------------------- | -------------------------------------- | ---------------------------------------- | | YOLO26n | Detect | 640 | 45.4 ^{1.3 / 42.1 / 2.0} | 26.6 ^{1.9 / 22.0 / 2.7} | | YOLO26n-seg | Segment | 640 | 126.2 ^{2.6 / 113.9 / 9.7} | 46.7 ^{2.6 / 33.3 / 10.8} | | YOLO26n-sem | Semantic | 640 | 117.9 ^{2.6 / 98.8 / 16.5} | 74.3 ^{2.6 / 54.7 / 17.0} | | YOLO26n-depth | Depth | 640 | 182.4 ^{2.5 / 167.6 / 12.3} | 47.8 ^{2.5 / 32.3 / 12.9} | | YOLO26n-cls | Classify | 224 | 6.2 ^{0.4 / 5.3 / 0.4} | 7.4 ^{0.4 / 6.9 / 0.1} | | YOLO26n-pose | Pose | 640 | 97.6 ^{2.5 / 93.3 / 1.8} | 28.6 ^{2.5 / 23.3 / 2.8} | | YOLO26n-obb | OBB | 640 | 91.5 ^{2.6 / 85.8 / 3.2} | 27.5 ^{2.7 / 21.8 / 2.9} |

Benchmark: Mean of 15 predict() calls after 3 warmups on bus.jpg, using ultralytics_yolo 0.6.10 and the official v0.6.6 assets. CPU/GPU order alternates between tasks in one sequential sweep. Native logs confirmed that every CPU row used LiteRT CPU/XNNPACK and every GPU row delegated the complete graph to LiteRT OpenCL (LITERT_CL).

Export to LiteRT: Converting Your YOLO Model

You can improve on-device execution efficiency and broaden deployment options by converting your models to the LiteRT format.

Installation

To install the required package, run:

!!! tip "Installation"

=== "CLI"

    ```bash
    # Install the required package for YOLO
    pip install ultralytics
    ```

For detailed instructions and best practices, check our Ultralytics Installation guide. If you encounter any difficulties, consult our Common Issues guide.

!!! note "Platform support"

LiteRT **export** is currently supported on **Linux x86_64** and **macOS**. The exported `.tflite` model itself runs on all LiteRT-supported platforms (mobile, embedded, edge, and the browser).

Usage

All Ultralytics YOLO models support export out of the box. The LiteRT format supports the Export, Predict, and Validate modes, so you can export a model, then load it to run inference or validate its accuracy locally.

!!! example "Export"

=== "Python"

    ```python
    from ultralytics import YOLO

    # Load a YOLO26 model
    model = YOLO("yolo26n.pt")

    # Export the model to LiteRT format
    model.export(format="litert", imgsz=640)  # use imgsz=224 for classification
    ```

=== "CLI"

    ```bash
    # Export a YOLO26n PyTorch model to LiteRT format
    yolo export model=yolo26n.pt format=litert imgsz=640 # use imgsz=224 for classification
    ```

!!! example "Quantized export"

=== "Python"

    ```python
    from ultralytics import YOLO

    model = YOLO("yolo26n.pt")

    # Dynamic INT8: int8 weights, FP32 activations - no calibration data needed
    model.export(format="litert", quantize="w8a32", imgsz=640)  # use imgsz=224 for classification

    # Static INT8: int8 weights + int8 activations - needs calibration data
    model.export(format="litert", quantize=8, data="coco8.yaml", imgsz=640)  # use 224 for classification

    # Static w8a16: int8 weights + int16 activations (higher accuracy) - needs calibration data
    model.export(format="litert", quantize="w8a16", data="coco8.yaml", imgsz=640)  # use 224 for classification
    ```

=== "CLI"

    ```bash
    # Dynamic INT8 (no calibration data needed)
    yolo export model=yolo26n.pt format=litert quantize=w8a32 imgsz=640

    # Static INT8 (needs calibration data)
    yolo export model=yolo26n.pt format=litert quantize=8 data=coco8.yaml imgsz=640

    # Static w8a16: int8 weights + int16 activations (needs calibration data)
    yolo export model=yolo26n.pt format=litert quantize=w8a16 data=coco8.yaml imgsz=640
    ```

!!! example "Predict"

=== "Python"

    ```python
    from ultralytics import YOLO

    # Load the exported LiteRT model
    model = YOLO("yolo26n.tflite")

    # Run inference
    results = model("https://ultralytics.com/images/bus.jpg")
    ```

=== "CLI"

    ```bash
    # Run inference with the exported LiteRT model
    yolo predict model=yolo26n.tflite source='https://ultralytics.com/images/bus.jpg'
    ```

!!! example "Validate"

=== "Python"

    ```python
    from ultralytics import YOLO

    # Load the exported LiteRT model
    model = YOLO("yolo26n.tflite")

    # Validate accuracy on the COCO8 dataset
    metrics = model.val(data="coco8.yaml")
    ```

=== "CLI"

    ```bash
    # Validate the exported LiteRT model
    yolo val model=yolo26n.tflite data=coco8.yaml
    ```

Export Arguments

!!! note "FP16 precision"

Unlike the legacy `tflite` export, LiteRT does not require a separate FP16 export. An FP32 `.tflite` model runs in **half precision at runtime** when using a GPU delegate (WebGPU, OpenCL, Metal) — this is the official LiteRT approach to FP16 inference.

For more details about the export process, visit the Ultralytics documentation page on exporting.

Deploying Exported YOLO LiteRT Models

After exporting your Ultralytics YOLO model to LiteRT, you can deploy it across platforms. The quickest way to verify it locally is the YOLO("yolo26n.tflite") method shown above. For deployment in other environments, see the following resources:

Mobile & Embedded

• Android: A quick-start guide for integrating LiteRT into Android applications.
• iOS: A guide for integrating and deploying LiteRT models in iOS applications.
• Embedded Linux & Raspberry Pi: Run LiteRT models on single-board computers, optionally accelerated with a Coral Edge TPU.
• Microcontrollers: Deploy on MCUs with only a few kilobytes of memory — the core runtime fits in roughly 16 KB on an Arm Cortex-M3.

Browser & Node.js (LiteRT.js)

• LiteRT.js overview: Run the same .tflite model directly in the browser with WebGPU/WASM acceleration, eliminating server-side computation and keeping data on the user's device.
• End-to-End Examples: Practical examples and tutorials for implementing LiteRT across mobile, edge, and web.

Summary

In this guide, we covered how to export Ultralytics YOLO models to the LiteRT format. By consolidating mobile/edge (formerly TFLite) and browser (formerly TF.js) deployment into a single .tflite model, LiteRT makes your YOLO models faster, smaller, and portable across virtually every on-device target.

For further details, visit the LiteRT official documentation.

Also, if you're curious about other Ultralytics YOLO integrations, check out our integration guide page for plenty of helpful resources.

FAQ

How do I export a YOLO model to LiteRT format?

Use the Ultralytics library to export a YOLO model to LiteRT (.tflite). First, install the package:

pip install ultralytics

Then export your model:

from ultralytics import YOLO

# Load a YOLO26 model
model = YOLO("yolo26n.pt")

# Export the model to LiteRT format
model.export(format="litert", imgsz=640)  # use imgsz=224 for classification

For CLI users:

yolo export model=yolo26n.pt format=litert imgsz=640 # use imgsz=224 for classification

For more details, visit the Ultralytics export guide.

What is the difference between LiteRT, TFLite, and TF.js?

LiteRT is the new name for TensorFlow Lite — same .tflite model format, same runtime lineage, rebranded by Google. In Ultralytics, the single litert export format now covers both use cases that previously required two separate formats:

• The old tflite format → mobile, embedded, and edge deployment.
• The old tfjs format → browser and Node.js deployment, now handled by LiteRT.js running the same .tflite file.

If you have an existing .tflite file, you can load it directly with YOLO("model.tflite") and it will run through the LiteRT backend.

Can I run YOLO LiteRT models on a Raspberry Pi?

Yes. Export your model to LiteRT format, then run it on a Raspberry Pi to improve inference speeds. For further optimization, consider a Coral Edge TPU. For detailed steps, refer to our Raspberry Pi deployment guide.

Can I run YOLO models in the browser with LiteRT?

Yes. LiteRT.js runs the same exported .tflite model directly in a web browser or Node.js application, with WebGPU/WASM acceleration. This replaces the previous TensorFlow.js workflow — there is no separate browser export, just deploy your LiteRT model with the LiteRT.js runtime.

Does LiteRT support FP16 (half-precision) inference?

Yes — at runtime. An FP32 LiteRT model automatically runs in FP16 when executed on a GPU delegate (WebGPU, OpenCL, or Metal), which is the official LiteRT approach. You therefore don't need a dedicated FP16 export; for further compression, use INT8 quantization with quantize=8.

How do I troubleshoot common issues during LiteRT export?

If you encounter errors while exporting YOLO models to LiteRT, common solutions include:

• Check platform: LiteRT export is supported on Linux x86_64 and macOS. Verify your environment matches.
• Check package compatibility: Ensure you're using a compatible version of Ultralytics. Refer to our installation guide.
• Quantization issues: When using INT8 quantization, make sure your dataset path is correctly specified in the data parameter.

For additional troubleshooting tips, visit our Common Issues guide.