# Supported Model Formats for LiteRT-LM: Conversion Requirements Explained

> Explore LiteRT-LM supported model formats including tflite, task, and litertlm. Understand conversion requirements for efficient on-device deployment. Turn your models into production-ready litertlm files.

- Repository: [google-ai-edge/LiteRT-LM](https://github.com/google-ai-edge/LiteRT-LM)
- Tags: architecture
- Published: 2026-04-06

---

**LiteRT-LM supports three on-device model containers—`.tflite`, `.task`, and `.litertlm`—with the bundled `.litertlm` format serving as the production-ready standard that packages model weights, tokenizers, and metadata into a single self-describing file.**

The `google-ai-edge/LiteRT-LM` repository provides a runtime for on-device large language model inference, accepting multiple input formats through automatic detection logic. Understanding the supported model formats and conversion requirements ensures seamless deployment across Android, iOS, desktop, and IoT environments.

## LiteRT-LM Model Formats Overview

LiteRT-LM recognizes three distinct file formats, each identified by filename suffix or magic header signature.

### TensorFlow Lite (.tflite)

The `.tflite` format represents directly exported TensorFlow Lite models. The runtime detects these files via the `TFL3` magic header or `.tflite` filename extension. While functional, raw TFLite files require external tokenizers and metadata to run within LiteRT-LM.

### MediaPipe Task (.task)

MediaPipe Task files use the `.task` extension and are detected by the `PK` ZIP magic header. These containers are packaged by the MediaPipe Task builder and contain task-specific configurations alongside the underlying model.

### LiteRT-LM Bundle (.litertlm)

The `.litertlm` format is the canonical, self-describing bundle designed for production deployment. It packages the TFLite model, tokenizers, LLM metadata, and optional backend constraints into a single file beginning with the `LITERTLM` magic header. This format eliminates external dependencies and enables version-safe, backend-aware execution.

## How LiteRT-LM Detects Model Formats

Format detection occurs through the `FileFormat` enum defined in [`runtime/executor/executor_settings_base.h`](https://github.com/google-ai-edge/LiteRT-LM/blob/main/runtime/executor/executor_settings_base.h):

```cpp
// runtime/executor/executor_settings_base.h (lines 94-103)
enum class FileFormat {
  // .tflite file format.
  TFLITE,
  // .task file format.
  TASK,
  // .litertlm file format.
  LITERT_LM,
};

```

The runtime inspects files using logic in `runtime/util/file_format_util.cc`. The `GetFileFormatFromPath()` function checks filename suffixes, while `GetFileFormatFromFileContents()` validates magic headers:

```cpp
// runtime/util/file_format_util.cc (lines 52-60)
absl::StatusOr<FileFormat> GetFileFormatFromPath(absl::string_view model_path) {
  if (absl::EndsWith(model_path, ".tflite")) return FileFormat::TFLITE;
  else if (absl::EndsWith(model_path, ".task")) return FileFormat::TASK;
  else if (absl::EndsWith(model_path, ".litertlm")) return FileFormat::LITERT_LM;
  return absl::InvalidArgumentError("Unsupported or unknown file format.");
}

absl::StatusOr<FileFormat> GetFileFormatFromFileContents(absl::string_view contents) {
  absl::string_view header = contents.substr(0, kMaxMagicSignatureLength);
  if (absl::StrContains(header, "TFL3")) return FileFormat::TFLITE;
  else if (absl::StrContains(header, "PK")) return FileFormat::TASK;
  else if (absl::StartsWith(header, "LITERTLM")) return FileFormat::LITERT_LM;
  return absl::InvalidArgumentError("Unsupported or unknown file format.");
}

```

When loading a `.litertlm` bundle, the runtime extracts individual sections using the FlatBuffers schema defined under `schema/core`, passing the TFLite sub-model to the appropriate executor (CPU, GPU, or NPU).

## Converting Models to .litertlm Format

Conversion to the bundled format is performed by the **LiteRT-LM Builder** Python API, which validates requirements and constructs the self-contained package.

### Conversion Requirements

Successful bundle creation requires satisfying these constraints:

- **Valid TFLite model**: Must exist at the specified path and be recognized as a valid `.tflite` file
- **Model type specification**: Must provide a `TfLiteModelType` enum value (e.g., `PREFILL_DECODE`, `EMBEDDER`)
- **Tokenizer**: Exactly one tokenizer—either SentencePiece (`.model`) or Hugging Face ([`tokenizer.json`](https://github.com/google-ai-edge/LiteRT-LM/blob/main/tokenizer.json))
- **LLM metadata**: Binary or text-proto file describing input/output specifications
- **Optional backend constraint**: Must be one of `"cpu"`, `"gpu"`, `"npu"`, or `"gpu_artisan"` if specified
- **Reserved metadata keys**: The builder prohibits overriding `model_type` and `backend_constraint` keys in `additional_metadata`

### Building a Bundle with Python

The `LitertLmFileBuilder` class in [`schema/py/litertlm_builder.py`](https://github.com/google-ai-edge/LiteRT-LM/blob/main/schema/py/litertlm_builder.py) orchestrates the conversion:

```python
from litert_lm.schema.py import litertlm_builder

# Initialize builder

builder = litertlm_builder.LitertLmFileBuilder()

# Add TFLite model with optional backend constraint

builder.add_tflite_model(
    tflite_model_path="model.tflite",
    model_type=litertlm_builder.TfLiteModelType.PREFILL_DECODE,
    backend_constraint="gpu"  # optional: cpu, gpu, npu, gpu_artisan

)

# Add tokenizer (SentencePiece or HuggingFace)

builder.add_sentencepiece_tokenizer(sp_tokenizer_path="tokenizer.model")

# OR: builder.add_hf_tokenizer(hf_tokenizer_path="tokenizer.json")

# Add LLM metadata

builder.add_llm_metadata(llm_metadata_path="metadata.pb")

# Write bundle

with open("model.litertlm", "wb") as f:
    builder.build(f)

```

The `add_tflite_model()` method validates file existence and backend constraints before merging mandatory metadata with user-supplied entries:

```python

# schema/py/litertlm_builder.py (lines 47-61)

def add_tflite_model(self, tflite_model_path, model_type,
                     backend_constraint=None, additional_metadata=None):
    """Adds a tflite model to the litertlm file."""
    if not litertlm_core.path_exists(tflite_model_path):
        raise FileNotFoundError(f"Tflite model file not found: {tflite_model_path}")
    metadata = [Metadata(key="model_type", value=model_type.value, dtype=DType.STRING)]
    if backend_constraint:
        _validate_backend_constraints(backend_constraint)
        metadata.append(Metadata(key="backend_constraint",
                                value=backend_constraint.lower(),
                                dtype=DType.STRING))
    # ... metadata merging logic ...

```

## Running Models in Different Formats

### Executing a .litertlm Bundle via CLI

```bash
litert-lm run \
    --from-huggingface-repo=litert-community/gemma-4-E2B-it-litert-lm \
    gemma-4-E2B-it.litertlm \
    --prompt="What is the capital of France?"

```

The CLI automatically detects the `.litertlm` format and extracts bundled tokenizers and metadata.

### Loading a Plain .tflite Model via Python

```python
import litert_lm

# Direct TFLite loading (requires external tokenizer/metadata)

engine = litert_lm.Engine(model_path="model.tflite", backend="cpu")
response = engine.run("Hello world")
print(response.text)

```

## Summary

- **LiteRT-LM accepts three formats**: `.tflite`, `.task`, and `.litertlm`, detected via filename suffix or magic headers (`TFL3`, `PK`, `LITERTLM`)
- **Production deployments should use `.litertlm`**: This bundle format packages model weights, tokenizers, LLM metadata, and optional backend constraints into a single, version-checked file
- **Conversion requires**: Valid TFLite model, specified model type, exactly one tokenizer, LLM metadata, and optional validated backend constraints (`cpu`, `gpu`, `npu`, `gpu_artisan`)
- **Builder implementation**: The `LitertLmFileBuilder` class in [`schema/py/litertlm_builder.py`](https://github.com/google-ai-edge/LiteRT-LM/blob/main/schema/py/litertlm_builder.py) validates inputs and writes the `LITERTLM` magic header with FlatBuffers schema metadata

## Frequently Asked Questions

### What is the difference between .tflite and .litertlm formats?

A `.tflite` file contains only the model weights and operations, requiring external tokenizers and metadata configuration at runtime. The `.litertlm` format bundles the TFLite model, tokenizers, and LLM metadata into a single file with a `LITERTLM` magic header and FlatBuffers schema, enabling self-describing deployment without external dependencies.

### How does LiteRT-LM detect the model format at runtime?

The runtime uses the `FileFormat` enum defined in [`runtime/executor/executor_settings_base.h`](https://github.com/google-ai-edge/LiteRT-LM/blob/main/runtime/executor/executor_settings_base.h) and detection logic in `runtime/util/file_format_util.cc`. It first checks filename suffixes (`.tflite`, `.task`, `.litertlm`), then inspects file contents for magic headers (`TFL3` for TFLite, `PK` for MediaPipe Task, `LITERTLM` for bundles).

### Can I convert an existing MediaPipe Task model to .litertlm?

Yes, extract the TFLite model from the `.task` file (which is a ZIP archive with `PK` magic header), then use the `LitertLmFileBuilder` to package it with appropriate tokenizers and metadata into a `.litertlm` bundle. The builder accepts any valid TFLite file regardless of its original packaging.

### What backend constraints are supported when converting models?

The builder validates backend constraints in `add_tflite_model()` against the allowed set: `"cpu"`, `"gpu"`, `"npu"`, and `"gpu_artisan"`. These constraints inform the runtime executor whether to execute on CPU, GPU, NPU, or specialized GPU artisan hardware. If specified, the constraint is stored as metadata in the bundle and respected during inference.