How Slab works

Slab runs models on the device. Your app ships Slab and one or more model files (.slab). Each model file holds the weights plus everything Slab needs to run the model: its inputs and outputs, how to prepare images, labels, and the model author's preferred backend and precision.

The five objects

The flow

1. Set up once. Create a Config, point it at your models and a cache folder, and attach your runtime license. Every model needs a license. On Android, bind Slab to your app once at startup.
2. Open a session per model. Slab reads the model file, picks a backend (see below), loads the weights and prepares the model for the device. Prepared models are cached, so the next open is faster. You can ask Slab to warm the model up during open, so the first real run is fast.
3. Run. Put an image or tensors in an Input, run the session, and read the Output. Inputs and Outputs are reused from run to run.
4. Close. Free the session when the model is no longer needed. You can also unload a session's weights to save memory and reload them later.

You can inspect a model before opening it: its inputs and outputs, its estimated memory, and whether a given backend can run it. Inspecting does not load the weights.

Images in, results out

• Decode once. A Frame decodes an image file, or wraps pixels you already have, such as camera frames. Cropping a Frame creates a view with no pixel copy.
• One image, many models. Pass the same Frame to several sessions. Each session resizes, orders colors and normalizes the image the way its own model expects, using settings stored in the model file. You can override any of these settings per session.
• Results ready to use. Besides raw tensors, an Output can rank classes with their labels, decode detection boxes and landmarks back to the original image's coordinates, normalize and compare embeddings, and turn an image-shaped output back into a Frame.

Text generation

Language and vision-language models use the same objects. You put a prompt, a chat history and optional images into the Input, along with sampling settings (temperature, top-p, stop words, a JSON schema for structured answers). Then:

• Start processes the prompt.
• Next produces one piece of text per call. Your app calls it in a loop on its own thread. There are no callbacks.
• Stop by leaving the loop or cancelling from any thread. The session keeps the conversation, so a follow-up turn reuses the earlier context. Reset clears it.

Backends and precision

Each device has up to three backends: CPU, GPU and NPU. By default (AUTO), Slab uses the model's preferred backend when the device can run it. Otherwise it takes the first backend, in the order NPU → GPU → CPU, that the device has and that supports the whole model. You can also request a backend. In that case Slab either uses it or reports why it can't.

Precision (f32, f16, int8, ...) is set per backend by the model author. Slab never lowers precision on its own.

Every run reports which backend it used and how long it took.

Errors

Every call reports success or failure. On failure, the object that failed (Session, Frame or Config) holds an error code and a readable message, for example the operations a backend cannot run, or why a license was rejected.

Threads

• One operation at a time per session. Separate sessions run in parallel on different threads.
• A loaded Frame can be shared by sessions on different threads.
• Each thread uses its own Input and Output.
• Cancelling is safe from any thread.

Protected models

A model file can be encrypted. Your app supplies the unlock key, or a license token that Slab checks on the device. Protected models run on the CPU and GPU; weights are decrypted only while they are needed (on the GPU, into GPU-only memory).

Languages

Slab is native code with a plain C interface: only numbers, pointers and opaque handles, never structs. Swift, Kotlin/Java, Flutter (Dart) and React Native can call it directly. C+ apps use Slab's own API, which frees objects automatically.