XUMI: Your Start to ML Model Management

XUMI Repositories

XUMI Framework XUMI Models

In the world of machine learning deployment the code is only half the battle. Packaging your model, managing its dependencies, ensuring it runs reliably with the right resources, and connecting it to a larger system (like Xavier's SPI) can be a complex challenge.

This is where XUMI (Xavier Universal Model Interface) steps in. Think of XUMI as a full-service toolkit that wraps your raw machine learning code in a clean, consistent, and ready-to-deploy package.

What is XUMI?

XUMI is an all-in-one platform — a CLI, a framework, and a runtime — that simplifies the entire life cycle of an SPI-compliant model.

Feature	What it does for you
CLI	The command-line interface. It's your single point of control for creating projects, running commands, managing files, and building deployment-ready containers.
Framework	It provides structure and rules (like the Manifest) for defining how your model works, what data it needs, and how it should execute. This ensures your model plugs easily into the larger Xavier infrastructure.
Runtime	The engine that actually runs your model once it's deployed. It handles connecting clients via modern protocols like HTTP and WebSockets, managing complex multi-step tasks (Workflows), and scaling model execution inside containers.

How XUMI Makes Your Life Easier

XUMI takes on the heavy lifting of infrastructure, letting you focus on the model code itself.

1. Goodbye Messy Setup, Hello Templates

Forget manually configuring folders, Dockerfiles, and boilerplate code. XUMI uses Templates to instantly scaffold a new project for common domains like text, image, audio, or multimodal models.

• Your Action: Use the model create command in the CLI.
• The Benefit: You get a fully structured project with the necessary files, manifest, and an example runtime implementation right out of the gate.

2. Standardized Configuration with Manifests

The Manifest is the most critical file in an XUMI project. It's a declarative file that tells the system everything about your model.

• V1 vs. V2: While V1 uses a simple initialize → predict → cleanup structure, the newer V2 Manifest introduces Commands and Workflows.
• Workflows (V2): This is great for multi-step ML pipelines (e.g., Pre-process Data → Run Model → Post-process Output). The XUMI WorkflowExecutor manages these steps, ensuring data is passed correctly between them.

3. Containerization is Not Scary Anymore

XUMI abstracts away the complexities of Docker, making container management accessible.

• Development Environments: Use the init-env command to set up an isolated development container for your project. This ensures your development environment perfectly matches your eventual deployment environment.
• Building: The model build command packages your model into a production-ready Docker image with the correct configuration for the runtime — including CUDA/GPU support, if needed.

4. Simple, Secure Authentication

Connecting your local development environment to remote Xavier services requires authentication. XUMI manages this with the auth command group.

• Secure Tokens: It uses the OAuth 2.0 Device Code Flow to authenticate you and then securely stores your access and refresh tokens using a system keyring (hidden from prying eyes) via its SecretStorage system.
• Your Action: Run auth login once to establish your secure session.

Getting Started: The Essential XUMI Commands

Focus on these five commands to start your first project:

Command	Purpose
auth login	Authenticate your environment with the Xavier infrastructure. (Do this first!)
model create	Scaffold a new project using a template (e.g., text, image).
model validate [path]	Run a check on your project's Manifest to ensure it adheres to all SPI rules before you try to build or run it.
model run [path]	Execute your model locally for testing. This is faster than building and running a full container every time you make a change.
model build [path] --tag [name]	Final step: packages your validated model into a tagged, deployable Docker image, ready to be pushed to the registry.

XUMI gives you the power of a standardized, containerized, and secure ML deployment pipeline without needing to be an infrastructure expert. Master the CLI, understand the Manifest, and you'll be deploying models in no time!

What's Next?

You've used the basic XUMI CLI commands to get a model container up and running. Great! But to truly master the platform — and to write cleaner, more powerful SPI-compliant models — you need to understand the how and the why behind its core systems: the Manifest, the Runtime, and the Containers.

1. The Core: SPI Manifest V2 and the Power of Workflows

The Manifest is the backbone of any XUMI project. It's the declarative contract between your model code and the Xavier infrastructure.

The Shift from V1 to V2

Feature	V1 Manifest	V2 Manifest (The Deep Dive)
Execution	Fixed lifecycle: initialize → predict → cleanup.	Command-based: Execution is defined by custom, named functions (@command).
Logic	Model logic is often monolithic, handled mostly within the predict function.	Workflow Orchestration: Allows chaining multiple commands together in a defined sequence using a WorkflowExecutor.
Data Flow	Simple inputs/outputs defined once for the main predict call.	Object Registry: Intermediate data objects are passed between commands using an in-memory ObjectRegistry. This enables complex pipelines where Command A’s output becomes Command B’s input.

Why this matters: V2 turns your model from a single-task script into a flexible, multi-step pipeline. For example, a single predict call could trigger a workflow: DownloadAsset → PreProcess → RunInference → UploadOutput.

2. The Engine: XUMI Runtime and Protocol

The Runtime is the piece of code that runs inside your deployed container, taking instructions from clients and executing your model logic.

XUMIRuntimeV2

This is the central orchestrator that loads your V2 Manifest. It is responsible for:

• Command Registration: Using the SPIDecorators (@command, @streaming_command) in your Python code to map function names to the command definitions in your manifest.
• Execution: Activating the WorkflowExecutor to run the defined sequence of commands.
• Protocol Handling: Communicating with external clients over a standardized protocol.

The Communication Protocol

XUMI’s runtime module defines a clear communication protocol, managing the flow of structured messages:

• TaskMessage: An incoming request from a client to run a task (e.g., call a command).
• ResponseMessage: The outgoing message containing the results, with support for streaming chunks.
• CapabilitiesMessage: Used by the server to advertise what commands and features the deployed model supports.

The Servers: Your model can be served using either the HTTPServer (for simple request/response) or the WebSocketServer (for low-latency, bidirectional, and streaming communication).

3. The Toolkit: Environment and Assets

Two complementary systems — Containers and Assets — manage the physical environment and resources your model needs to run.

Containerization (```docker``` Module)

The XUMI docker module handles the complexities of building a reliable model environment:

• Project Initialization: The init_env command sets up a fully configured development container. This ensures that the Python/CUDA versions and dependencies you develop with are exactly what you deploy with, preventing "it works on my machine" bugs.
• Image Building: The model build command uses configurations from your Manifest (like base image, Python version, and resource requirements) to dynamically generate and build a Docker image for deployment.

Asset Management (```asset``` Module)

This is XUMI’s file management system, crucial for handling large files like model weights and training data.

• Lifecycles: Every asset is assigned a lifecycle:
  • EPHEMERAL: Temporary file, expected to be short-lived.
  • TEMPORARY: Has a defined retention period (e.g., 30 days).
  • PERSISTENT: Intended to be permanent (e.g., the final model weights).
• Workspaces: The asset CLI allows you to create isolated namespaces (asset create-workspace) for different projects or teams, ensuring asset organization and security.

4. Your Code: Where to Deep Dive

To be a XUMI expert, you need to understand where your Python functions fit into the framework:

1. Read the ```runtime``` module: Focus on the XUMIRuntimeV2 and the protocol message definitions. Understanding what data structures are being sent and received is key to troubleshooting client issues.
2. Study the Decorators: Look at the SPIDecorators in the core.manifest module. Understanding how @command registers your function and how it expects inputs and outputs to be handled is the most important coding concept in XUMI.
3. Explore ```utils```: Learn how the CustomLogger works so you can write informative log messages that work correctly with the two-level verbosity (debug/debug_more) and the console Spinner for long-running processes.

By studying these core components, you'll move past simple CLI usage and gain the architectural knowledge needed to build and troubleshoot any complex, production-ready SPI model.