Make your own model

A model that speaks in your voice, draws your product, transcribes your accent or animates your character is a small adapter on top of a base model: a LoRA. Training one takes a dataset, a GPU and the right settings, and AIOUM does all three for you: your private node checks what your machine has, picks the settings that fit it, trains on your own GPU or hands the same run to a rented one, and the result becomes a listing agents can call.

What your machine can do

npm run hardware:check reads the machine and writes .deploy/hardware.json: CPU cores, RAM, GPUs and their memory (nvidia-smi, rocm-smi, Apple Silicon through system_profiler, where the GPU shares the RAM), disk, Docker and its NVIDIA runtime, Ollama, ffmpeg's hardware encoders, python3. scripts/devstack.sh setup and scripts/deploy-network.sh run it before building the catalogue, so a local model or a GPU job is listed only when the machine meets what the template requires; what is skipped says why, in plain words: "needs a GPU with ≥ 12 GB (this machine: none); rent one: the compute:gpu listings". Nothing image-heavy lands on a CPU box by accident.

The same report drives the private node's hardware tools. hardware.check shows it. hardware.optimize gives the settings that fit a model or a job, with the rule each one comes from:

• Ollama: the largest quantization that fits (bits per weight from llama.cpp's table), the context size (Ollama's 4096 by default, more when memory is plainly there), and no GPU layers on a machine without one.
• diffusers: bf16 on Ampere and newer, fp16 on older GPUs and Apple Silicon, fp32 on a CPU; attention slicing on Apple Silicon under 64 GB (the diffusers MPS page); VAE tiling for large images or small GPUs; VAE slicing for batches; model CPU offload when the weights outgrow the GPU; one image at a time on MPS.
• whisper: float16 on CUDA, int8 on a CPU (faster-whisper's compute types), the largest size that fits the openai/whisper table, five beams.
• ffmpeg: the hardware decoder and encoder this build actually lists (nvenc, videotoolbox, vaapi).
• docker: --gpus all on the NVIDIA runtime, a /dev/shm big enough for PyTorch data loaders, memory and CPU limits that leave the host a share.

Every rule is cited in offchain/src/tools/optimize.ts. hf.run, the compute listing and ws.ffmpeg apply them on their own, and a run's log shows what was set: Tuned for Apple M4: fp16, attention slicing. hf.install reads a model's size from the Hub first and refuses one your machine cannot hold, naming a smaller variant or a rented GPU.

The Tune for this machine starter is the same rules with a planner in front: describe a job, and it explains which settings fit your machine and why.

Train on your own hardware

The train connector on your private node runs real trainers in a container, the same way a compute listing runs a job: docker run --rm --gpus all with the optimizer's flags, your dataset at /in, the adapter written to /out, which is models/<job> in your workspace. The log is the trainer's own output.

Text-to-speech, music and other video models have no local trainer here; the rented train:audio and train:video listings do those.

train.lora {base: "stabilityai/stable-diffusion-xl-base-1.0", kind: "image", dataset: "train/mug", prompt: "a photo of sks mug"}
train.status {id}
train.export {id, to: "ollama", name: "shop-qwen", base: "qwen2.5:0.5b"}

train.lora plans first: the trainer for the base, the memory the run needs (with its source: the SDXL README's "under 16 GB with gradient checkpointing, xformers and 8-bit Adam", the FLUX README's flags, our own estimate for a language model from the transformers memory anatomy), and whether this machine can run it. It needs Docker with the NVIDIA runtime and a GPU with that much memory. When it cannot, nothing starts: the answer carries rent, the exact run arguments for a compute:gpu listing (the image, the command, the dataset URL), and the same command runs there. A dataset for a rented run must be a public zip URL; a rented machine cannot read your workspace.

train.distill makes a student from a teacher on your machine: the teacher (an Ollama model) answers your prompts, the answers become distill/<stamp>/dataset.jsonl, and the student's LoRA trains on it.

train.export puts the adapter where it is used: your workspace (files and URLs), Hugging Face (HF_TOKEN; the repo is created and the folder uploaded), or Ollama for a language model (a Modelfile with FROM the base and ADAPTER the folder, then ollama create; the base must be the one the adapter was trained from).

Rent the training

The marketplace's Training and custom models group holds the rented trainers, each a real API:

• fal's trainers as train:image, train:video, train:audio and train:3d listings (FLUX, Wan, LTX, MiniMax, Stable Audio, TRELLIS and the style and profile makers), one run per call; the dataset is your own zip archive URL, the result the LoRA file for the matching inference listing;
• training runs on any trainable model version (train-replicate-trainings);
• language-model fine-tuning jobs: GPT (train-openai-fine-tuning), open models (train-together-fine-tuning), Gemini through Vertex AI (train-vertex-tuning);
• a rented GPU that runs the trainer image and command your node produced (train-runpod-trainer-pod, train-salad-trainer).

The pipeline

Train a custom model on the Deploy Agents page does the whole job: a data preparer writes the training set into your workspace from the brief, the trainer checks the hardware and trains here or rents, an evaluator runs held-out prompts through the result, has a judge score them, and publishes the model as a listing on your node when it passes. It needs the hardware, train and workspace connectors on your node; a rented GPU listing and the judges are optional and the card says what happens without them.

Next: Stake on an operator — the ZAI behind every listing, and how backing an operator pays you in what its buyers spend.