ZawShiShawn/gestura-flux2-klein-4b-litert-tflite

Gestura FLUX.2 Klein 4B LiteRT/TFLite Android Runtime Integration Contract

Gestura on-device performance

The fastest measured generation times for this model package in Gestura are:

These are the fastest measurements observed in Gestura on the specified devices. They do not guarantee performance in other applications, runtimes, or devices.

On-Device Image Generation and Editing in Gestura

Download Gestura

Download Gestura on Google Play

This model repository does not contain the Gestura application source code or instructions for building or invoking Gestura. This document defines only the contract that third-party applications must follow to execute this model package.

1. Model identity

77978ac251ca6e34504b9f6638fd3e0314970071 is the baseline commit at which all 43 runtime payload files were first published together. Later commits only add or revise documentation such as README.md, LICENSE, and NOTICE. Applications must still validate the size and SHA-256 identity of every runtime file from the revision they download.

This public package did not fetch a separate Qwen repository or Qwen revision. The Qwen3-4B text-encoder weights and tokenizer assets come from the fixed files inside black-forest-labs/FLUX.2-klein-4B@e7b7dc27f91deacad38e78976d1f2b499d76a294. The public ke_enc*.tflite files are not the separate Qwen/Qwen3-4B-AWQ sidecar conversion variant.

This is a derivative LiteRT/TFLite Android runtime package for FLUX.2 [klein] 4B. It is not the original PyTorch/Diffusers checkpoint, a single directly invocable .tflite model, or an SDK.

Third-party applications must implement tokenization, tensor layout, image preprocessing and postprocessing, the four-step flow schedule, and orchestration across all graphs. Running only one graph cannot produce a complete image.

The model graphs use the LiteRT/TFLite format. Execution is not restricted to Google's official LiteRT API, but the runtime must fully implement the contract in Section 4, including SignatureDef, the required operations and data types, and external-weight resolution. A runtime that does not implement this contract cannot execute the package.

"Gestura" identifies this model package and its associated product. It does not mean that the application source code is included in the model repository.

1.1 Quantization formats

The public package converts the DiT weights directly from the official BF16 transformer checkpoint at the pinned revision. The Qwen text encoder and VAE are packaged under their respective conversion contracts. Components use the following storage formats:

W4A16 is the name of the DiT quantization profile. Only seven selected matrices are stored in 4-bit form. Activations use FP16 or FP32 paths according to the device runtime. W4A16 does not mean that every tensor in the package is INT4. The DiT W4, INT8, and FP16 payloads all come directly from the same official BF16 numerical source; earlier INT8 or INT2 intermediate artifacts were not used as the numerical source. Third parties must not requantize or rewrite any graph or sidecar, because doing so invalidates the file identities and numerical contract of the revision.

The three ke_enc*.tflite files contain embedded INT8 Qwen weights. The public package has no separate Qwen AWQ weight sidecar. qwen_embed_fp16.bin contains only the FP16 token-embedding table and does not contain encoder-layer weights.

1.2 Quantization quality boundaries

The DiT W4 conversion first applies stage-candidate thresholds, then uses a DiT trajectory with no W4 matrices, where all other heavy matrices are quantized directly from BF16 to INT8, as the final relative baseline:

The final gate also requires the W4-to-BF16 NRMSE to be no greater than the direct-BF16-INT8-to-BF16 baseline NRMSE multiplied by 1.15, plus 0.01. Cosine similarity must be no lower than that baseline's BF16-relative value minus 0.01. The public package passed candidate selection and the final tensor-space gate.

These values do not mean that the absolute W4-to-BF16 NRMSE must be below 0.05, and they do not prove perceptual image quality or complete runtime validation. Final packaging records keep device image-quality comparisons separate from full runtime validation. They also do not imply pixel-identical output for every prompt. Actual output remains affected by the seed, scheduler, runtime numerical path, and image preprocessing and postprocessing.

1.3 Public-package deduplication

Deduplication applies only to assets with identical content identity in the public package:

• —kc_*, kce_*, and kce2_* retain their family-specific graphs.
• —Identical stages across the three families share one weights/dit_* sidecar, so 24 denoising graphs require only eight external-weight files.
• —All three families share one text encoder, tokenizer, VAE, and set of host lookup assets.
• —Shared identity is determined by revision, relative path, file size, and SHA-256 together.
• —Graphs or weights with different content identities must not be merged merely because their filenames are similar.

2. Workflows

The model package contains three graph families:

Required rules:

• —Each request must select exactly one family.
• —Graphs from different families must not be chained or interchanged.
• —Single-image editing accepts only image 1.
• —Two-image editing distinguishes its conditioning images only as image 1 and image 2.
• —Image numbers are tensor-binding identities. They do not indicate reception or upload order, and they do not imply primary or reference roles.
• —Two-image editing must provide both image 1 and image 2.

3. Required files

The runtime payload contains 43 files:

8,690,686,201 bytes
approximately 8.69 GB (decimal)
approximately 8.09 GiB (binary)

.gitattributes is not part of the runtime payload and is not counted among the 43 files.

The relative directory structure must remain exactly as follows:

flux2-klein-4b/
├── kc_prep.tflite
├── kc_double0.tflite
├── kc_double1.tflite
├── kc_single0.tflite
├── kc_single1.tflite
├── kc_single2.tflite
├── kc_single3.tflite
├── kc_final.tflite
├── kce_prep.tflite
├── kce_double0.tflite
├── kce_double1.tflite
├── kce_single0.tflite
├── kce_single1.tflite
├── kce_single2.tflite
├── kce_single3.tflite
├── kce_final.tflite
├── kce2_prep.tflite
├── kce2_double0.tflite
├── kce2_double1.tflite
├── kce2_single0.tflite
├── kce2_single1.tflite
├── kce2_single2.tflite
├── kce2_single3.tflite
├── kce2_final.tflite
├── ke_enc0.tflite
├── ke_enc1.tflite
├── ke_enc2.tflite
├── kv_vae_enc.tflite
├── kv_vae.tflite
├── host/
│   └── time_guidance_embed_bf16.bin
├── tokenizer/
│   ├── qwen_embed_fp16.bin
│   ├── qwen_merges.txt
│   ├── qwen_special.txt
│   ├── qwen_vocab.txt
│   └── tokenizer_fixture.txt
└── weights/
    ├── dit_prep_...bin
    ├── dit_double0_...bin
    ├── dit_double1_...bin
    ├── dit_single0_...bin
    ├── dit_single1_...bin
    ├── dit_single2_...bin
    ├── dit_single3_...bin
    └── dit_final_...bin

File contract:

• —All 43 payload files are required.
• —weights/*.bin files are required external-weight sidecars used while executing the graphs; they are not standalone models.
• —Identical stages across the three families share the corresponding dit_* sidecar.
• —Graphs, sidecars, tokenizer files, and host assets must come from the same revision.
• —Files and directories must not be renamed or flattened.
• —Applications must validate the fixed relative path, file size, and SHA-256 of every file.
• —Comparing file size alone is not a complete integrity check.

4. LiteRT/TFLite runtime contract

The runtime must support:

1. 1.Loading TFLite/LiteRT graphs.
2. 2.Enumerating and invoking SignatureDef entries by name.
3. 3.Reading the name, shape, and data type of every input and output tensor.
4. 4.Resolving graph external-buffer and external-weight references.
5. 5.Binding the correct regions of weights/*.bin to each graph.
6. 6.Executing all data types and operations used by the model.
7. 7.Passing complete tensors between stages.
8. 8.Stopping generation and reporting an error when shape, type, weight binding, or execution fails.

A general org.tensorflow.lite.Interpreter without an external-weight resolver cannot directly execute this package. The runtime must provide SetWeightLoader, SetExternalWeightScopedFile, or equivalent functionality. Exact API names depend on the LiteRT build.

The external-weight resolver must locate sidecar data using the logical name, offset, and length stored in graph metadata. It must not use fuzzy filename searches or assume that an entire sidecar belongs to one tensor.

5. Geometry and tensor contract

5.1 Output geometry

The package currently contains the following output sizes:

256x256
512x512
512x384
384x512
480x320
320x480
512x288
288x512

Width and height must each be between 256 and 512 pixels and divisible by 32. The application must confirm that all required graphs expose a signature for the requested geometry.

Denoising-graph signature names use this format:

geometry_{WIDTH}x{HEIGHT}_text_512

Applications must still enumerate the actual SignatureDef entries and must not rely only on constructing the expected signature name.

5.2 Primary shapes

For output dimensions W × H:

Before passing any tensor to a graph, the application must validate its element count, shape, data type, and finite state. It must not hide incompatible tensors by truncating or zero-padding them.

6. Text-processing contract

6.1 Tokenizer

The tokenizer uses Qwen2 byte-level BPE:

• —qwen_vocab.txt: token vocabulary.
• —qwen_merges.txt: BPE merge rules.
• —qwen_special.txt: special tokens.
• —tokenizer_fixture.txt: implementation-conformance fixture.
• —qwen_embed_fp16.bin: token-embedding table.

Required constants:

Prompts longer than 512 model tokens must be truncated. Shorter prompts must be padded with a correct attention mask. Character count must not be used as token count.

The prompt must use this exact chat template:

<|im_start|>user
{prompt}<|im_end|>
<|im_start|>assistant
<think>

</think>

Line breaks and special tokens are part of the contract. A tokenizer implementation must pass tokenizer_fixture.txt before running the model.

6.2 Three-stage text encoder

The execution order is fixed:

ke_enc0.tflite
→ ke_enc1.tflite
→ ke_enc2.tflite

Required procedure:

1. 1.Produce 512 token IDs and an attention mask.
2. 2.Read the 2,560-dimensional row for each token from the FP16 embedding table.
3. 3.Construct the text rotary-position tensor.
4. 4.Run all three encoder stages in the fixed order.
5. 5.Read the three conditioning taps using signature tensor names.
6. 6.Compose the 7,680-dimensional prompt conditioning per token according to the model contract.
7. 7.Validate output shapes and finite state.

Do not use only the last-stage output, and do not infer tensor semantics from input or output indices.

7. Image and latent contract

7.1 Conditioning-image encoding

Single-image and two-image workflows must:

1. 1.Transform input images to the target geometry using a fixed rule.
2. 2.Convert them to RGB.
3. 3.Arrange planar tensors according to the kv_vae_enc.tflite signature.
4. 4.Normalize channel values to [-1, 1].
5. 5.Run the VAE encoder to obtain a [1, 32, H/8, W/8] latent.
6. 6.Patchify and pack it into width-128 tokens according to the transformer contract.

Family tensor bindings are:

Text-to-image: noisy/output latent
Single-image editing: noisy/output latent, image 1 latent
Two-image editing: noisy/output latent, image 1 latent, image 2 latent

Image temporal positions are fixed: noisy/output = 0, image 1 = 10, and image 2 = 20. Image numbers must not be inferred from file ordering or arrival order.

7.2 Initial latent

• —Text-to-image must initialize the noisy latent with Gaussian noise derived from the seed.
• —Image editing must construct the initial latent according to the FLUX.2 Klein flow scheduler and initStrength.
• —initStrength must be within 0.0..1.0.
• —Reproducing a seed requires the same RNG, Gaussian transform, floating-point types, and complete input conditions.

7.3 VAE decoding

After four denoising steps:

1. 1.Unpack the width-128 latent into the VAE latent layout.
2. 2.Apply the model-required latent normalization or denormalization.
3. 3.Invoke kv_vae.tflite.
4. 4.Map the [-1, 1] output to the RGB pixel range.
5. 5.Reject output containing NaN or Infinity.
6. 6.Convert the valid RGB buffer to the application's image format.

8. Four-step denoising contract

Each family contains eight stages in a fixed order:

prep
→ double0
→ double1
→ single0
→ single1
→ single2
→ single3
→ final

Text-to-image uses kc_*, single-image editing uses kce_*, and two-image editing uses kce2_*.

Each denoising step must:

1. 1.Use the current timestep and host/time_guidance_embed_bf16.bin to construct the 3,072-dimensional time/guidance embedding.
2. 2.Construct rotary-position tensors for text and image tokens.
3. 3.Prepare the noisy latent, prompt conditioning, and the image conditions for the selected family.
4. 4.Execute the eight stages in the fixed order.
5. 5.Pass stage inputs and outputs by signature tensor name.
6. 6.Read the noisy/output latent velocity from the final output.
7. 7.Apply an Euler update using the FLUX.2 Klein four-step shifted-flow scheduler.
8. 8.Send the latent to the VAE decoder after the fourth step.

Only the noisy/output latent may be updated at each step. Image 1 and image 2 latents must remain unchanged throughout all four steps.

This document does not define application performance implementations or device-specific tuning.

9. Limitations and use conditions

• —Model output is not fact, evidence, or professional advice.
• —The model may fail to follow prompts completely.
• —The model may generate incorrect, distorted, or misspelled image content.
• —The model may reproduce or amplify biases present in training data.
• —The model must not be used for unlawful activity, fraud, harassment, harm to minors, non-consensual intimate imagery, or other infringement of rights.
• —Deployers must confirm the rights and lawful basis for using faces, trademarks, copyrighted works, and personal data in model inputs.

Pinned upstream model version:

https://huggingface.co/black-forest-labs/FLUX.2-klein-4B/tree/e7b7dc27f91deacad38e78976d1f2b499d76a294

10. License and attribution

This package is distributed under the Apache License 2.0. A separate personal license from the converter is not required. The converter may add a copyright notice, but it must not replace upstream licensing or attribution.

The model repository contains:

1. 1.Root LICENSE: the complete, unmodified English text of the Apache License 2.0.
2. 2.Root NOTICE: applicable Black Forest Labs and Qwen/Alibaba Cloud attribution, conversion details, and trademark statements. The pinned FLUX upstream revision does not itself contain a separate NOTICE file; this file preserves applicable attribution and trademark information from the upstream model card and documents changes made for this derivative package.
3. 3.A statement that this is a derivative LiteRT/TFLite Android runtime package, not an official Black Forest Labs Android release.
4. 4.A record that the upstream model was converted into LiteRT/TFLite graphs, external-weight sidecars, and supporting runtime assets.
5. 5.No use of Black Forest Labs or FLUX trademarks that implies sponsorship, certification, or partnership.
6. 6.A clear distinction between the model assets and the Gestura application source code, which is not included in this repository.

Attribution statement:

Based on FLUX.2 [klein] 4B by Black Forest Labs, licensed under the
Apache License 2.0. This repository contains a converted LiteRT/TFLite
Android runtime package associated with Gestura and is not an official
Black Forest Labs Android release. Its text encoder uses the Qwen3-4B
architecture and tokenizer assets by Qwen/Alibaba Cloud as distributed inside
the pinned FLUX upstream revision; no separate Qwen repository or revision was
fetched for this public package. Gestura application source code is not included.