MTGPU provides automatic account provisioning and built-in scheduling for native and containerized jobs across servers in any location. Scale from a single server to a cluster with a simple configuration—without a separate scheduler or directory service.
MTGPU Server
MTGPU turns existing workstations or cloud hosts into a multi-tenant cluster with a simple configuration. Installed in minutes, the cluster forms automatically, and user accounts are provisioned on first access without administrator setup. The built-in job scheduler handles native and containerized jobs and fails over on its own—no separate scheduling system to install and maintain. It scales from a single server to a cluster of thousands with the same setup and user experience. Add computers or shared storage as needed; users' file ownership carries over to every server, with no account or data migration.
One file per computer
MTGPU sets up and manages each computer from one configuration file. A few settings define how computers work individually and together:
CLUSTER_MODE and CLUSTER_IDDefine whether a server runs standalone or as a cluster member. Servers with the same cluster ID form a cluster automatically and elect a job scheduler among themselves. Jobs are dispatched to the best-fit member whether tenant homes are shared or independent.
TENANT_HOME_ROOTSpecifies the root directory for account homes. MTGPU provisions tenant accounts with unique UID/GIDs that are consistent across all servers, allowing seamless home-directory sharing.
Existing OS accounts and their home directories keep working without interruption.
CONTAINERS.enabledTurns on container workspaces. Companion settings select the workspace templates, images to pre-pull from a private registry, persistent cache volumes, network access, and the port-publishing policy—and whether users may bring their own images.
DATASETS_DIRECTORIES and PYTHON_INTERPRETERS publish datasets and Python environments read-only to every account. USER_DISK_LIMIT, JOB_RETENTION_DAYS, and TENANT_RETENTION_DAYS set the per-user disk quota and how long finished job records and inactive accounts are kept. MTGPU enforces the policy without administrator intervention.
Ready in minutes. The same configuration file can be copied to every computer, with minor edits where a host differs. Once installed, clusters form on their own, and authorized users can start working from anywhere on the Internet. There is nothing else to install or administer: no scheduling system such as Slurm or Kubernetes, and no directory service such as LDAP or NIS. MTGPU currently supports Linux and Windows WSL2.
Multi-tenant without the maze
Each authorized user receives a private, unprivileged OS account. New computers and shared storage can be added whenever the need arises, and users' file ownership carries over to every server automatically.
A single developer can install it on a workstation and work from anywhere on a laptop. A group of developers can pool their workstations into one cluster. Each host stays protected: teammates work in unprivileged tenant accounts with private home directories, and on Windows WSL hosts mtgpu-setup locks the computer's own drives away from tenants by default.
Interactive or for job execution
MTGPU runs rootless containers with Podman by default. Each container runs in a workspace under the user's own account identity, with the user's home directory and persistent cache volumes mounted. Compute resources are reserved when the workspace is created.
Create a workspace from an administrator-selected template, an image pre-pulled from a private registry, a public OCI image, an image saved from your own customized workspace, or a devcontainer.json with a standard Docker container specification.
MTGPU handles GPU visibility, mounts, and lifecycle—and publishes the ports you choose, so Jupyter, TensorBoard, or your own web UI is one click away.
Create a workspace by hand for interactive development: open a terminal inside it, or attach Microsoft's Dev Containers extension to it. A containerized job creates its workspace automatically from the job specification and removes it when the job finishes.
Terminals that survive disconnects
Every SSH terminal runs inside a tmux session on the GPU host that persists after you disconnect. AI coding sessions and agents running in tools such as Claude Code and Codex CLI keep working, as do training loops and interactive Python or debugger sessions.
mtgpu-setup on the GPU host; the clients attach to it automatically.Built-in cluster scheduling
Cluster job submission enables efficient resource sharing. The scheduler either runs the job immediately on an available node or queues it until one opens up. MTGPU runs both native and containerized jobs. A native job's commands execute in the user's home environment; a containerized job's commands execute inside the container, with the home directory and persistent cache volumes mounted. A job is specified in a file similar to a Slurm batch script: an optional container, the resources it needs—GPUs, CPUs, minimum VRAM and RAM—and the commands to run.
Three GPU reservation modes: exclusive, shared with a guaranteed VRAM fit, or shared with opportunistic overcommit. A job may reserve GPUs by type, such as nvidia:1, amd:2 or rtx4090:1, and pin itself to a server with server=<server name>.
CPU-only servers can join and take jobs that don't need GPUs.
Every node reports its measured GPU, VRAM, CPU, and RAM use. Each job is placed on the best node by measured free and committed capacity. When every suitable node is busy, the job waits in a priority-ordered queue; aging ensures lower-priority work eventually runs. Requests the cluster could never satisfy are rejected immediately.
Distributed training needs several GPU servers at once. A job file with nodes=N runs the same command on N members: each gets its rank and the rendezvous endpoint as environment variables for torchrun or any NCCL launcher, the group starts together or not at all, and one member failing stops the rest. For work that is independent per run, array= turns one file into many separate jobs, one per index, spread across whichever nodes have room.
Both directives work in native and containerized jobs.
Cluster members automatically elect the most capable of themselves as the scheduler and keep its queue replicated as it changes. If the scheduler node goes offline, another takes over and no job needs resubmitting.
The scheduler stays efficient as the cluster grows. In simulated load tests, one scheduler on a 2012 desktop CPU (AMD FX-8350), taken as the floor benchmark, kept up with a thousand members and thousands of tenant accounts with headroom to spare; current hardware raises that ceiling further.
Supports major GPU brands. MTGPU detects the GPUs in each machine automatically and supports NVIDIA, AMD, and Intel GPUs out of the box; other brands are configured and tested automatically, with little or no administrator involvement, as described in the user manual.
Works with either storage layout. With shared home storage, a user's home directory is the same on every computer, and the container image of a containerized job is archived once and retrieved from that same storage by whichever node runs it. With independent home storage, the scheduler streams the image to a node the first time a job runs there.
Multiple clusters. An administrator can run several clusters under one administrator account—for example one per team, site, or hardware generation—each with its own cluster ID and its own scheduler. Assign users to clusters with mtcode-admin: each user sees and submits jobs only to the clusters they have been granted, and a user can be granted more than one.
Compatible with existing tools. MTGPU doesn't wall off the machine: the external tools your workflow already relies on keep working alongside it, unchanged.
Install headlessly on a rented cloud GPU or VPS. MTGPU installs and runs entirely without a display, so an SSH terminal is all you need. Copy the package up with scp or download it inside the SSH session, then run mtgpu-setup install --yes for a fully unattended install that enables automatic start at boot.
Meet users where they work
Use MTGPU inside VS Code or from a terminal on Windows, macOS, or Linux. Both clients discover the same authorized servers and provide the same core access and workspace operations.
Discover servers, compare live usage, and create interactive workspaces. Then open an SSH terminal, or launch Microsoft's Remote - SSH or Dev Containers extension, and follow job status from the same panel. Install the extension in VS Code from the Visual Studio Marketplace.
Use a keyboard-driven terminal program with similar server discovery, live usage, SSH access, workspace management, and job status—without requiring VS Code. remotegpu-cli is included in the MTCode Portal package.
One view of every authorized server: hardware, live usage, SSH access, interactive workspaces, and job status.
Terminal tools for either client. On the SSH terminal, whether opened from VS Code or remotegpu-cli, users manage their workflow with mt-job, mt-container, mt-podman, and mt-python; on the server terminal, administrators monitor and manage servers and users with mtgpu-admin.
Connect a host, invite your team, and move from the first interactive experiment to a scheduled cluster job without changing platforms.
