Introducing LUML: One Platform for Your Entire AI Lifecycle
Managing the AI lifecycle is fragmented. Experiment tracking lives in one tool, model registry in another, deployment in a third, and none of them talk to each other properly. Most of these tools also expect you to route your data through their servers.
This fragmentation creates real friction. Data scientists spend time stitching tools together instead of iterating on models. Engineers build custom glue code to move artifacts between systems. And when the conversation shifts from traditional ML to LLMs or AI agents, the tooling fractures even further, because most platforms were designed for one paradigm, not all three.
LUML is an open-source, cloud-agnostic AIOps platform built to fix this. It covers the full machine learning lifecycle in a single unified workflow: experiment tracking, model registry, deployment, and evaluation. It works the same way whether you're training a random forest, fine-tuning an LLM, or orchestrating a multi-step agent pipeline. And it does all of this without ever touching your data.
Your Data Stays Yours
That last point deserves emphasis, because it shapes everything about how LUML works.
Most platforms ask you to trust them with your data. LUML takes a different approach by separating the control plane from the data plane. When you upload a model or dataset, the file moves directly between your machine and your cloud storage. LUML issues the right credentials and coordinates the transfer, but the data itself never passes through LUML's servers. The same applies to inference: when you deploy a model, requests go straight from the client to your compute node. The platform is not in the data path at any point. The system is built this way by design, and there is no code path where your data touches LUML's infrastructure.
This architectural decision flows into how the platform organizes everything else. LUML structures resources around four concepts: Organizations serve as the top-level boundary, holding users, quotas, and storage configuration. Within an organization, Orbits act as project workspaces, each with its own collections of artifacts, compute nodes, secrets, and deployments. Think of an Orbit as everything related to a specific initiative: a recommendation engine, a document processing pipeline, a chatbot. Resources are isolated between Orbits, so teams work independently without stepping on each other.
The compute and storage layers follow the same philosophy of keeping things under your control. Satellites are compute nodes that you own and connect to the platform via a pairing key. They run on your infrastructure (a cloud VM, an on-premise server, even your laptop), announce their capabilities, and poll for tasks. Buckets are cloud storage backends attached at the organization level, providing a unified data space across all Orbits. LUML integrates with S3-compatible storage and Azure Blob Storage, and all file operations use client-side transfers. Organizations own resources, Orbits organize work, Satellites run compute, Buckets store data.
From Experiment to Production
With that foundation in place, let's walk through what it actually looks like to use LUML.
Most projects start with experimentation. LUML's experiment tracker handles both traditional ML and LLM workloads in the same interface. For conventional training runs, you log hyperparameters as static values and metrics as time-series data tied to training steps. You can attach models, datasets, configuration files, or any other artifact to an experiment.
For LLM workloads, the tracker integrates with OpenTelemetry to capture full execution traces. Every prompt, completion, tool call, and intermediate step is recorded as a span within a trace. The system automatically detects span types (chat, agent, tool, embedding, reranker) from OpenTelemetry attributes, giving you structured visibility into your LLM pipeline without manual tagging. You can run evaluations directly against these traces too: log input/output pairs with scores, link them to specific traces, and add human annotations at both the eval and span level. The result is a complete picture of what the model did, how it scored, and what a reviewer thought about the output.
Once you have a model worth keeping, it moves into the registry. Every artifact in LUML lives in a central registry, organized into Collections within an Orbit. The registry uses the .luml format, a self-contained package based on the open FNNX specification. A .luml file bundles everything needed to run a model: weights, inference code, environment specifications, and input/output schemas. This means a model in the registry carries its own contract. You know exactly what inputs it expects, what outputs it produces, and what environment it needs. The format is framework-agnostic, and schema validation happens at inference time, so mismatches are caught immediately.
Because everything is bundled into the .luml package, going from registry to production is a matter of a few clicks. You pick a model from the registry, choose which Satellite should run it, and LUML takes care of the rest: the Satellite pulls the package, sets up the environment, and starts serving requests. LUML handles secret injection so that sensitive configuration like API keys and credentials stays out of your model code, and caches authorization at the Satellite level to keep inference latency low. Since traffic flows directly from client to Satellite, the platform never becomes a bottleneck.
Two Ways to Work
That workflow describes the full programmatic path, but LUML also meets you where you are if you're not ready to write code.
Express Tasks let you build and evaluate models directly in the browser. Say you want to build a tabular classifier: you upload your dataset, pick a target column, and the system handles preprocessing, model selection, and evaluation automatically. You get an interactive dashboard with performance metrics, and the resulting model is saved to the registry in .luml format, ready for deployment. Or say you're working on an LLM workflow and want to optimize your prompts: Express Tasks include a visual builder where you design your workflow as a graph of connected nodes and define evaluation criteria. The system iterates on prompts using a teacher-student paradigm, where a larger model generates optimized prompts that a smaller model then uses. No SDK installation, no registration, no local setup required.
Get Started
LUML is open source, and there are two natural starting points depending on how you prefer to work. If you want to explore without any setup, try Express Tasks directly in the browser: run AutoML on a tabular dataset or build an LLM prompt workflow, no account needed. If you'd rather integrate LUML into your existing codebase, install the Python SDK and start tracking experiments locally.
Check the documentation to learn more, or explore the platform directly at app.luml.ai.
