Introducing ML Model Support in Texera

Three new features that let you bring a trained model to Texera: models as a first-class resource, mounting a model into your computing unit, and custom images for the environment it runs in.
The Models page in the Texera dashboard, showing model cards

Feature Introduction · Apache Texera

Texera now supports machine-learning models. A model is a resource of its own, alongside workflows and datasets: it has an owner, a history of versions, a file tree, an access list, and a page other people can find.

Three features arrive together, because running a model takes all three: somewhere to keep it, a way for your code to reach it, and an environment able to load it.

Models

Upload a model, keep versions of it, share it with collaborators and publish it to the Hub.

Mounting

A Python UDF names a model version and reads it from a local folder. Files load lazily, so only the bytes your code reads are transferred.

Custom Images

An administrator registers extra computing-unit environments for models with heavier requirements.

01 Models in Texera

Models live under Your Work → Models. You give a model a name and, if you like, record which framework trained it and how the weights are stored. Those are labels for people and for tools to read later.

A version can be a single file or a whole folder, since models arrive both ways — one checkpoint, or weights alongside a config file, a tokenizer and several shards. Upload files or folders, up to 2 GB per file by default, and commit them together as one version.

Creating a model, uploading its files, and committing them as a version.

A model's page showing its description, public and downloadable tags, version count and the path to its latest version file

The model card: what the model is, and what a workflow needs in order to run it.

Once committed, a version never changes. That is what makes a workflow reproducible: it names a version, and that version means the same files a year later.

Key Capabilities

  • Create a model and upload its files, singly or as a folder, from the browser
  • Commit a set of files as an immutable version, and keep a history of versions
  • Share a model with named collaborators, at read or write access
  • Publish a model to the Texera Hub, separately from whether it can be downloaded
  • Search and browse published models alongside workflows and datasets

Publishing and downloading are deliberately separate, so you can let people find and use a model without handing out the weights. Published models appear on the Hub and in search, and you can give one a cover image.

02 Mounting a Model into Your Computing Unit

There is no "load model" step to configure. A Python UDF declares that one of its parameters names a model:

class ProcessTableOperator(UDFTableOperator):

    @overrides
    def open(self):
        import joblib, os

        model_dir = self.UiParameter("MODEL", AttributeType.STRING,
                                     value=Resource.MODEL).value
        self.model = joblib.load(os.path.join(model_dir, "iris_rf.joblib"))

Texera reads that declaration and shows a model browser in the operator's property panel instead of a text box. You pick a model and a version there. When the workflow runs, the UDF receives a plain local folder path and reads files out of it like any other folder.

A Python UDF open in the editor, with the UiParameter line highlighted, beside the property panel showing a MODEL parameter whose value is the model version iris-species-rf v1

The highlighted line in the script produces the MODEL parameter on the right, whose value is a model version rather than typed text.

Nothing is downloaded. The version is mounted into the machine running your code, and a file's contents only travel when your code actually reads them. Load one shard of a 40 GB model and you transfer one shard.

The design question underneath is who performs the mount. Mounting needs privileges, and the pod running a user's code should hold as few as possible. So a small separate program on each machine performs it and hands the finished read-only folder back, leaving that pod unprivileged. Before any of it happens, Texera confirms you may use that computing unit and may read that model, so a mount cannot reach something you could not already open.

Diagram: a workflow runs, the computing unit asks Access Control for a mount, the Texera Mounter runs GeeseFS against the file service, and the files appear in the pod

The mount is performed outside the pod that runs your code, then handed in read-only.

The same mechanism carries datasets, since both are stored the same way — write Resource.DATASET instead.

03 Custom Images for Computing Units

Getting the weights to your code is half the job. The other half is code that can load them. The penguin model above needs xgboost, which the stock image does not carry; at the far end, something like AlphaFold 3 wants a particular Python version, tools that do not come from pip, and a compile step.

An administrator can therefore register extra computing-unit environments. They paste a link to a published image, Texera checks it is a valid Texera computing-unit image and pins the exact version, and it appears as a dropdown when someone creates a computing unit. Pick one and your unit runs that environment; the choice applies to that unit alone and is fixed for its lifetime.

Registering an image, and watching it validate before anyone can select it.

The Create Computing Unit dialog with an Image dropdown listing Default and Python ML (xgboost)

Choosing an environment when creating a computing unit.

Two details make this safe to leave switched on. The version is pinned when the image is registered, so its contents cannot be swapped out afterwards. And because these images come from outside the project, a unit started from one runs with reduced permissions. Registered images are also pulled onto each machine ahead of time, so starting a unit from one does not wait on a download.

04 End to End

Creating a computing unit, naming a model version from a UDF, running the workflow, and reading the output.

Where This Goes Next

Next is agreeing a standard layout for a model, so Texera can load one without being told how — and on top of that, an operator that runs a model over a table with no code at all. Development happens on GitHub, and design discussion there and on dev@texera.apache.org.

Read the design on issue #6494

If you have a model and a Texera deployment, turn it on and tell us where it falls short.