LiteRT.js Moves the TFLite Runtime Into the Browser

Google shipped LiteRT.js on July 9, and the interesting part is not another wrapper around browser ML. It is the LiteRT runtime itself exposed to JavaScript. If you already have a .tflitemodel, the browser path is no longer “rewrite the model for TensorFlow.js kernels”. It is load the same LiteRT artifact and choose an accelerator.

The package is @litertjs/core. You serve its Wasm files, call loadLiteRt(), then load and compile a model:

import { loadLiteRt, loadAndCompile, Tensor } from '@litertjs/core';

await loadLiteRt('/wasm/');

const model = await loadAndCompile('/models/resnet.tflite', {
  accelerator: 'webgpu',
});

The accelerator can be wasm, webgpu, or webnn. CPU runs through XNNPACK mapped to WebAssembly. GPU runs through WebGPU. NPU support is the bet: WebNN is still experimental in Chrome and Edge, but LiteRT.js is already shaped around it. Unsupported ops on the accelerated paths fall back to CPU.

That is a different tradeoff from the usual WebML stack. Transformers.js is great when the model you need already exists as ONNX on Hugging Face. WebLLM is built for autoregressive text generation. LiteRT.js is aimed at the large pile of edge models that already live in LiteRT: vision, audio, embeddings, classifiers, and eventually more generative workloads.

The conversion path matters. Google’s docs point PyTorch users at litert_torch: load a PyTorch model, pass sample inputs, export a .tflite file. For existing TensorFlow.js apps, the pitch is narrower and more practical: keep the surrounding TensorFlow.js preprocessing and postprocessing, replace the model execution with LiteRT.js, and use the @litertjs/tfjs-interop package at the boundary.

Google claims up to 3x speedups over other web runtimes across classical vision and audio models, and 5-60x moving from CPU to GPU or NPU on its benchmark machine, a 2024 MacBook Pro with M4 Apple Silicon. Treat those as directional, not portable. Browser drivers, thermal limits, model ops, and whether WebNN exists on the user’s machine will decide the real number.

The code shape is also lower-level than a task API. You create typed arrays, wrap them inTensor, run the model, then move outputs back from the accelerator if you need CPU data. That is exactly why it belongs beside ONNX Runtime Web, Transformers.js, and WebLLM rather than replacing them.

What changes today: if your model source of truth is .tflite, the browser is now a first-class LiteRT target. Use it for the models where the LiteRT toolchain is already the best path. Keep WebLLM for chat. Keep Transformers.js for ready-made ONNX pipelines. The useful browser AI stack is getting more specific, not more unified.