Rent a GPU. Run image and video AI. Keep your files safe.

3The whole system on one page

A generative image system is four parts that cooperate: an operator who writes the job, a controller that keeps permanent state, a rented GPU worker that does the computing, and a model that turns text into pixels. Only the controller needs to survive between sessions.

"Local" here means you run inference on a machine you operate instead of calling a hosted model API. That machine can be your own PC or a GPU rented by the hour. A rented host's administrator can still reach your data while it is processed, so running your own software does not by itself give privacy from the host. Section 17 returns to this.

The cast, with real examples

Products named in this guide illustrate each category. They are examples, not endorsements or a complete list.

The operator submits a job. The controller checks it, stages approved weights, and sends both to the worker. The worker computes and returns outputs. The controller verifies and archives them before the worker is destroyed.

The round trip: every part that goes out has a partner on the way back

A job is a round trip, and the second half mirrors the first. The same pairs of ideas appear on the way out and on the way back. Keeping the pairing in mind makes every later section easier, because a part's job on the return leg is almost always the reverse of its job on the outbound leg.

1. Send the job. The controller validates the job and stages approved weights on the worker. It checks each file's digest, for example with sha256sum, against the value recorded when you approved the file.

2. Encode the words. The tokenizer and text encoder turn your prompt into numbers. For Chroma1-HD that encoder is T5-XXL, for Qwen-Image 2.1 it is Qwen3-VL-8B, and for Wan 2.2 it is umt5-xxl.

3. Encode an image, if you brought one. In image editing or image-to-video, the VAE's encoder squeezes your input picture into a latent. Plain text-to-image skips this move.

4. Denoise. The denoiser starts from seeded noise and refines it, steered by the numbers from move 2. This is the expensive stage, and it is where a GPU's memory type and capacity matter (sections 4 and 11).

5. The loop ends. The final update leaves a clean latent. Still no picture exists.

6. Decode. The VAE's decoder, the partner of the encoder in move 3, turns the latent into pixels. In ComfyUI the same VAE file feeds both the VAEEncode and VAEDecode nodes, so the file used going in must be the file used coming out: ae.safetensors from FLUX for Chroma1-HD, the Qwen-Image 2.1 VAE for that model, a Wan VAE for Wan.

7. Review. You compare the image with your original words, the human counterpart of move 2. In Qwen-Image 2.1 editing, community encoder cards say the Qwen3-VL-8B encoder keeps its vision tower because version 2.1 needs it for editing, so that one model can appear on both sides of the journey.

8. Bring it back. A save node writes a PNG or MP4 on the worker. The controller copies it back through the same private connection that carried the job, then verifies its digest the way the weights were verified in move 1. Only then is it archived, and only after that is the worker destroyed.

Where each handoff usually fails

Start with one measurable goal. Produce a reproducible image of a ceramic teapot. Before touching hardware, write down four things: what an acceptable image looks like, the longest time you will wait, a cost ceiling, and what data you permit to leave your machine. Keep one official workflow working before you add adapters, editing, or video.

How to read the rest of this guide. Every later section is one stop on this round trip. When a part comes back into the story, a bracket reminds you of its first job, written like this: (outbound role: what it did on the way out). Real product names, such as GPUs, memory types, VAEs, and providers, appear at each technical mention so that every idea has something concrete attached to it.

4The layers, from silicon to saved file

Seven layers sit between your prompt and a saved image, and many first-time failures come from the lower layers, not from the model.

What the GPU layer is made of. The number that decides what fits is VRAM capacity. The memory type decides how fast the denoiser can read its weights at every step. Consumer and workstation cards use GDDR chips placed around the GPU. Data center cards such as the H100 use HBM, stacks of memory dies on the same package. HotHardware notes that HBM costs more than GDDR, which is why it stayed in data center cards, where AI work depends on memory bandwidth.

Chip makers can change between production runs and board partners, so treat the chip column as the supplier reported at launch, not a guarantee about the card you rent. Marketplace hosts such as Vast.ai rent cards from many board makers.

Debug from the bottom up. Confirm in this order: the GPU is visible (nvidia-smi), the framework can use it (torch.cuda.is_available() returns true), the model files load, the workflow runs, and an output file is saved. The first failing check is your problem; nothing above it can be trusted yet.

5Model anatomy: five parts that must match

A diffusion model is a bundle of five cooperating parts, and each part can only be swapped for one built for the same model family. A file named "VAE" or "CLIP" is not interchangeable just because of its label.

The first two parts run once per prompt. The denoiser and solver run at every sampling step, which is why they dominate run time. Memory is a separate question, because the text encoder can be the largest single file (section 11). The VAE decodes once at the end.

Text encoders in common model families. The text encoder is the part most often mismatched, so name it for every model you use.

VAEs you will meet by name. The VAE is a matched encoder and decoder pair, shipped as one file. Use the file your model's official template names.

Solvers and schedules you will meet by name: Sampler names such as euler, euler ancestral ("Euler a"), and DPM++ 2M appear beside schedule names such as simple, sgm_uniform, and Karras. A published FLUX workflow uses euler with simple, and a Hyper-SD workflow uses ddim with sgm_uniform. Which pairing works depends on the model family, so start from the official template.

Three terms are often mixed up, and mixing them makes failures hard to describe:

A checkpoint stores learned numbers. A wrapper such as ComfyUI or Diffusers supplies the code that runs them. When something fails, say which layer you mean.

6How an image is made, and how it becomes a file

An image is built by starting from random noise in a compressed space and refining it many times, guided by your text, then decoding the result into pixels. The numbers below match the diagram.

1. Prompt. You supply text, a seed, dimensions, and sampling settings. An optional enhancer may rewrite the text first.
2. Tokenizer. Text becomes token IDs, often word fragments, drawn from that model's vocabulary.
3. Text encoder. Token IDs become contextual vectors. In context, "blue" can attach to "teapot" instead of standing alone.
4. Conditioning. The vectors, plus any masks the model needs, are packaged as conditioning. They are usually encoded once and reused at every step.
5. Seed and shape. The seed starts a pseudo-random generator that fills a latent of the right size with noise. Same seed, same settings, same environment gives the same start.
6. Noisy latent. A latent is a compact numerical stand-in for the image, not the pixels themselves.
7. Denoiser. At each step it receives the current latent, the noise level, and the conditioning, then predicts the update its training taught it. Attention layers let regions of the latent draw on relevant words, so an emerging teapot can use the features for "blue". Adherence is likely, not guaranteed. When guidance is on, it makes a second prediction without the prompt or with a negative prompt, and the update blends the two.
8. Solver. It turns the prediction and the scheduled step size into the next latent. Steps 6 to 8 repeat.
9. VAE decoder. After the last update, the matching VAE turns the latent into pixels.
10. Pixels. The decoded image exists only in memory until something saves it.
11. Save and review. A save node writes the file. You then check it against your acceptance rule, and the controller copies it off the worker and verifies it. In ComfyUI, SaveImage is an output node that writes to the output directory and PreviewImage only shows temporary previews, so the graph needs an output node you have actually connected.

The same journey, three real models.

What changes what. Changing the prompt changes the conditioning; it never retrains the model. The seed changes only the starting noise. A LoRA adapter, covered in section 9, changes some of the model's learned weights. They are three different routes into the same process.

7UNet, DiT, and how video adds time

The denoiser comes in two main designs, and the design decides which weights, conditioning, and memory behavior you get. Do not infer it from a loader's name.

A UNet gathers context by shrinking the latent, then rebuilds spatial detail by growing it again, with skip links carrying fine detail across. A DiT cuts the latent into patches and treats each patch as a token, the way a language model treats words, then runs transformer blocks over all of them. Multimodal DiTs let text tokens and image tokens interact directly.

Real cases. Chroma1-HD is an 8.9B-parameter model built on the FLUX.1-schnell transformer and licensed Apache 2.0. Its documented setup uses the T5-XXL text encoder and the FLUX VAE; do not add CLIP-L just because a related model uses it. Qwen-Image 2.1 is a 7B transformer conditioned by Qwen3-VL-8B.

SDXL uses a UNet of about 2.6B parameters. Stability AI describes Stable Diffusion 3 as a multimodal diffusion transformer (MMDiT). Chroma1-HD, Qwen-Image 2.1, and Wan 2.2 A14B are transformer designs, according to their model pages.

Video adds time. Video models add a time axis to the latent, so work grows with width, height, and frames together, and attention makes the growth steeper than linear. A still-image workflow that fits in memory proves nothing about video.

Wan 2.2 A14B illustrates a second twist. Its 14B workflows use two models, a high-noise expert for the early steps and a low-noise expert for the late steps, with a switch step you can set. The Wan team switches experts when the signal-to-noise ratio falls to half its starting minimum. These labels describe the sampling stage, not scene lighting. Community 4-step speed-up recipes exist for specific Wan 2.2 variants and load as extra LoRAs for both experts. Use a recipe only with the variant it documents; do not apply it to original weights on a guess.

8Open source: weights, licenses, and where files come from

"Open" in image AI means the trained weights are published so you can run them. It does not mean one blanket permission: every file carries its own license, and derivatives inherit the terms of what they came from.

Two cautions come straight from real repositories. First, a repack can rename internal tensors. A community note on Qwen-Image 2.1 warns that quantizing from the original Hugging Face layout produces keys ComfyUI never finds, so the model loads "successfully" and emits noise. Second, licenses can differ between look-alike files. FLUX.1-schnell is Apache 2.0 and FLUX.1-dev carries a non-commercial license. The FLUX VAE file ae.safetensors is published in the FLUX.1-schnell repository, and one third-party bundle card lists a re-hosted FLUX VAE under the dev license beside an Apache 2.0 Chroma model. Confirm which repository your copy came from, and check every component, not just the headline model.

Where files come from

Licenses you will meet by name

Before you download anything, answer four questions:

• Which base model is this derived from, and is that the base my workflow uses?
• What does each license allow for the files and for the images they produce?
• Which exact revision is it, and does a trusted digest exist to verify the download?
• Who published it, and is this the official repository or a copy?

9Adapters and training your own LoRA

A LoRA is a small add-on file that nudges a frozen base model. It is the practical way a hobbyist teaches an open model a style, a character, or a product without retraining the whole network.

The base weights W never change. A and B are two small matrices whose shared inner size, the rank, is low, and s is a scale set at load time or in training. Fewer trainable numbers mean less optimizer memory, but the base network's computation and activations still need a capable GPU.

How an adapter relates to the open base. It only works with the architecture it was trained for, on the modules it targets, through a loader that supports it. It also inherits the base license: a community adapter for Qwen-Image 2.1 states plainly that it carries the base model's non-commercial restriction, and that its outputs do too.

Two real adapters, side by side.

Notice the second row. Qwen3-VL-8B encoded prompts on the outbound journey in section 3. Here the same model family does a third job as a captioner, describing training images so the adapter learns to bind its style to a trigger phrase. Trainers you will meet include AI Toolkit and DiffSynth-Studio.

Whose likeness may you train on? Use a synthetic adult character, or an adult subject whose written permission covers training and distribution. Keep that evidence privately. Never embed real names or identifying metadata in an adapter you share.

1. Choose a trainer example that explicitly supports your exact base model. Record the trainer revision and license, and use a separate environment from inference.
2. Curate consistent images across views, poses, lighting, and settings. Remove duplicates and artifacts, and reserve held-out views and prompts.
3. Write accurate captions for what varies. Use a nonpersonal trigger word. Inspect the real training crops.
4. Run a short trial: loss stays finite, an adapter file is saved, and a sample image generates.
5. Train with periodic checkpoints, a bounded duration, and local logging only.
6. Compare each checkpoint with base-only output on fixed held-out prompts and seeds. Choose for identity, controllability, and low memorization, not by loss alone.
7. Reload the chosen adapter in a fresh environment, then archive it before the GPU is destroyed.

For scale: 32 images, batch size one, no accumulation, and 1,600 optimizer steps show each image about 50 times. Repeats and distributed training change that figure, so no universal step count exists.

If identity drifts, check in this order: adapter loaded without warnings, correct base, conditioning, strength. Then inspect the dataset. An outfit that keeps appearing signals confounding in the data. Repeated training frames signal memorization. Try an earlier checkpoint before retraining everything, and review results with human eyes, since similarity scores need calibration.

Trainer configuration formats change often. Adapt the example shipped with the revision you select instead of copying a configuration from a blog post.

10Compatibility: build a bill of materials first

Write a bill of materials before you download a single file. File names are clues, not proof of compatibility. For every item record the model family, task, exact revision, precision, loader, license, and a trusted digest. Include the application and any custom-node revisions.

The model details come from the Hugging Face model cards and repacks listed in the sources. Sampling recipes differ: one community note says the non-distilled Qwen-Image 2.1 looks good at roughly 20 to 30 steps and soft at few-step settings. Treat such notes as hints and follow the official template first.

How wrong parts fail. A wrong text encoder may fail on dimension errors or quietly weaken prompt adherence. A wrong VAE may fail outright or distort colors. An adapter may load only partly. Always read load warnings, and test against a known-good baseline before blaming the model.

Mismatches reported in the wild

• Adding CLIP-L to Chroma1-HD, which documents T5-XXL only.
• Decoding SDXL in fp16 with the original sdxl_vae, which can produce NaNs; sdxl-vae-fp16-fix exists for this.
• Quantizing the Qwen-Image 2.1 text encoder from its original Hugging Face layout; ComfyUI never finds the renamed keys and the model loads yet outputs noise.
• Running a ComfyUI build older than Qwen-Image 2.1 support, which one community card says merged after 14 September 2026.

Encoders are not all alike. Text encoders, vision encoders, VAE encoders, and captioning models do different jobs. A conditioning repack is not automatically a conversational vision-language model; captioning generally needs an instruction model, a processor, a tokenizer, and a compatible runtime.

11Formats, quantization, and the memory budget

Model weights need roughly 2 GB per billion parameters at 16-bit, half that at 8-bit, and a quarter at 4-bit. Everything the workflow keeps loaded at the same time must fit in GPU memory (VRAM), with room left for working memory.

The formula tracks real files. Community listings report Qwen-Image 2.1's 7B denoiser at about 14.2 GB in bf16 and Chroma1-HD at about 17.8 GB, close to the 14 and 17.8 the formula gives. The surprise is the text encoder: Qwen3-VL-8B is reported at about 17.5 GB in bf16, larger than the denoiser it feeds. Budget the whole stack, not the headline model. Real allocations also add overhead, so treat the formula as a floor.

What fits where, using real file sizes. These are weights only, before activations, using the community-reported sizes above plus the T5-XXL fp16 file (about 9.1 GB) and the FLUX VAE (about 0.3 GB) that one Chroma bundle lists.

All-resident is the worst case. The text encoder runs once, so supported offload can park it in system RAM after it has produced the conditioning (its outbound role from section 3) and then load the denoiser. A 24 GB RTX 4090 can therefore still run both models, at the cost of transfer time, or by using the smaller files below.

Real quantized files.

Four separate layers hide behind the word "format": the container (how tensors are stored), the numeric representation (the precision), the quantization scheme (how values are compressed), and runtime support (whether your software can use it). A file can be fine in the first three and still fail the fourth.

Order of attack when memory is short:

1. Start with the official supported precision.
2. Reduce batch size and image size.
3. Unload unrelated models.
4. Use supported offload.
5. Only then consider a quantized variant, and compare it with the original on the same fixed prompts and seeds, measuring quality, time, and peak memory.
6. Avoid converting already-quantized weights again. Record the original revision and every conversion step.

12The two-state control plane

Split every session into two states: a persistent state you protect, and a disposable state you can recreate. The rule that makes this work is that nothing only the worker holds is allowed to matter.

In this guide the persistent state lives on a controller, which can be a small always-on server, a home machine, or your laptop. It is cheap, and it should stay up between sessions. The disposable state lives on a rented GPU worker that exists for one session and is destroyed afterward. The GPU is the expensive part, so you want it alive only while it earns its keep.

Real controller options.

The job ledger can be as plain as a text or CSV log with one line per job and its state.

The job ledger is how the controller tracks work, so a crashed session is never a mystery.

Operating rules. Give every job an identifier and a deadline. Retry a bounded number of times. After a timeout, inspect the queue before resubmitting, because the first attempt may still be running. If you expose this as a service, accept validated inputs for a fixed list of workflows, never arbitrary graphs from the public.

13The GPU lifecycle: spin up, work, spin down

A rented GPU passes through four states, and only destroying it ends every charge. The states below follow Vast.ai's documentation; other providers use different words for the same ideas, so confirm them before you rely on this.

Where to rent, and how each provider works.

Hyperscalers such as AWS, Google Cloud, and Azure are the usual contrast. A May 2026 tracker put AWS at about $6.88 and Azure's ND H100 v5 at about $12.29 per H100 per hour on demand, and they charge for egress.

Hourly rates seen in October 2026. RunPod's column is from its own page, updated 27 August 2026. Lambda's is from trackers citing its page. Vast.ai prices change by host and by hour, so its column is a range from trackers, which disagree with each other by two to three times. Treat every cell as a snapshot, and check the live page before you rent.

Third-party numbers age fast. Earlier trackers listed an RTX 4090 at $0.34 on RunPod's Community Cloud and $0.69 on Secure Cloud. RunPod's own page now shows $0.89.

Which GPU for which job in this guide

Spin up

1. Choose the offer. Match GPU memory to your budget from section 11, the driver to your framework from section 4, and disk to your total need. On Vast, container disk is fixed at creation and cannot be resized, so estimate generously. Marketplace prices vary by host, and interruptible offers are often over 50% cheaper but can be taken away.
2. Create and load. The machine downloads your container image. With a cached image this takes about 30 seconds; with a large image on a slow host it can take hours. Check the host's network speed before you rent.
3. Connect and verify. SSH in and run nvidia-smi. If the GPU, driver, or disk is not what you paid for, destroy the instance and rent another.
4. Stage. Pull only the weights this session needs from the controller and verify their digests.

Work. Run jobs through the ledger from section 12. Copy outputs back as they finish instead of at the end.

Spin down, in this order

1. Stop accepting new jobs.
2. Let running jobs finish writing.
3. Copy outputs, adapters, checkpoints, and manifests to the controller.
4. Verify: compare file lists, sizes, and digests, and reopen representative files.
5. Make any second backup you require.
6. Remove transient data and revoke tokens and keys used on the worker.
7. Destroy the instance.
8. Confirm in the provider's console that it shows as destroyed and no storage is still billing.

Three traps, all from provider documentation

• Stopped is not free. A stopped Vast instance keeps your data and keeps billing for its disk, often at a higher storage rate than while running. Only destroying ends it.
• Running out of credit does not clean up. When the balance hits zero, Vast stops your instances but does not destroy them, and storage keeps billing, even at a negative balance. If no payment method is on file, instances and data are scheduled for deletion. Do not treat an empty balance as your shutdown plan.
• You cannot count on a restart. A stopped instance that tries to restart can sit waiting for its GPU, because another renter may have taken it. Treat "stop and resume tomorrow" as unreliable and copy your data off.

Also, a closed SSH port does not prove the machine is destroyed. Look at the provider's authoritative state. Ordinary deletion gives no proof of physical erasure, which matters for sensitive data (section 17).

14Lab D: your first private workflow on a rented GPU

The goal is one official template that renders "a ceramic teapot on a plain studio table, soft side lighting", with the image, seed, workflow, component list, and runtime saved. You need a bill of materials from Lab B, approved weights on your controller, a funded provider account, and an SSH key pair. Commands are for Linux and Bash.

1. Rent and verify. Choose an offer that meets your memory, driver, and disk plan. Record the offer, driver version, and hourly price. SSH in and run nvidia-smi. If it does not match what you chose, destroy it and pick another.

2. Build the environment. Take the repository and a full commit hash from ComfyUI's official installation documentation; they are your inputs, not values this guide supplies.

mkdir -p ai-lab/{models,manifests,archive}
cd ai-lab
read -r -p 'Reviewed ComfyUI Git source: ' COMFY_SOURCE
read -r -p 'Reviewed full commit: ' COMFY_COMMIT
git clone "$COMFY_SOURCE" ComfyUI
cd ComfyUI
git checkout --detach "$COMFY_COMMIT"
python3 -m venv ../inference-env
source ../inference-env/bin/activate
python -m pip install --upgrade pip
# Install the officially supported GPU framework build here.
python -m pip install -r requirements.txt
python -m pip check
python -m pip freeze > ../manifests/packages.txt

Keep separate environments for inference, training, and any quality-check tools. Resolve package conflicts instead of deleting framework requirements to make an error go away.

3. Prove the GPU does real math. A version string is not proof.

import torch
assert torch.cuda.is_available()
print(torch.__version__, torch.version.cuda)
print(torch.cuda.get_device_capability())
x = torch.ones((256, 256), device='cuda')
y = x @ x
torch.cuda.synchronize()
assert y[0, 0].item() == 256

4. Place and verify the model files. Put only the files your template requires in its expected folders, pinned to the revisions in your bill of materials. Verify bytes against trusted digests with sha256sum -c. Download gated models on the controller where practical, and do not leave long-lived tokens on a disposable worker.

5. Start ComfyUI privately and tunnel to it. gpu-worker is an SSH alias you configure from your provider's connection details.

# On the GPU worker, inside the active inference environment:
python main.py --listen 127.0.0.1 --port 8188

# On your workstation, in a separate terminal:
ssh -N -L localhost:8188:localhost:8188 gpu-worker

Open http://localhost:8188 in your own browser. ComfyUI's documented default is to listen on 127.0.0.1 only, so the flag above makes the default explicit. Passing --listen with no address would open it to all interfaces. Treat custom nodes as executable software: review them and pin their revisions.

Choosing how to connect. The SSH tunnel above works anywhere. Two mesh-VPN options make repeat sessions easier.

Tailscale's documentation covers auth keys, ephemeral nodes, tags, and installing through cloud-init, which is how a disposable worker joins and later disappears on its own. Tailscale's server setup guide gives the tailscale up flags used below, and its Azure App Service guide shows the userspace-networking and SOCKS5 flags used where no TUN device exists. A SaladCloud guide describes Tailscale on GPU containers.

# On the worker, using a tagged, ephemeral auth key you created in the admin console:
# Install Tailscale first, following its documentation for your operating system
tailscale up --auth-key="$TS_AUTHKEY" --ssh --hostname=gpu-worker

# If the container has no TUN device, run the daemon in userspace mode first:
#   tailscaled --tun=userspace-networking --socks5-server=localhost:1055 &

# On your workstation, once both are on the tailnet, reuse the same tunnel idea:
ssh -N -L localhost:8188:localhost:8188 gpu-worker

Keep ComfyUI bound to localhost and forward the port over the tailnet, rather than listening on the Tailscale address. In your access control list, allow only your controller and laptop to reach the worker tag on the ports you need, and expire the worker's key when the session ends.

6. Render the baseline. Load one official template, keep its default recipe, enter the teapot prompt, and run it. Save the image, seed, workflow file, component inventory, runtime, and environment record.

7. Prove it reloads. Reopen the saved image and reload the saved graph.

If downloads stall: the Hugging Face Hub now runs entirely on its Xet storage backend, and the old HF_HUB_ENABLE_HF_TRANSFER setting is deprecated. Disabling Xet with HF_HUB_DISABLE_XET=1 is a diagnostic, not a standard setup step; Hugging Face asks users who need it to file an issue.

15Read and debug the workflow graph

A workflow is a program, so debug it like one: start at the Save node and trace backward through decoded pixels, sampled latents, the modified model, the conditioning, and the starting latent. Nothing counts that is not on a path leading back from Save.

Change one variable at a time, and keep the official recipe as your control.

Strong guidance can introduce artifacts, and negative prompts only matter when the active conditioning path actually uses them.

Real node names and settings. In ComfyUI the parts from section 5 appear as nodes. CLIPLoader loads a text encoder (with the type set to qwen_image for Qwen3-VL-8B), UNETLoader loads a denoiser, KSampler runs the loop from section 6, VAELoader and VAEDecode perform the decode (the return partner of any encode move), LoraLoaderModelOnly applies an adapter, ModelSamplingSD3 sets the sampling shift, and SaveImage writes the file. Wan 2.2 community notes suggest a shift of 1 for still images. Real starting values from model pages: Chroma1-HD at 28 steps with guidance 4.0 in one bundle's example; Qwen-Image 2.1 around 20 to 40 steps, with guidance optional; Wan 2.2 at 4 steps when both LightX2V LoRAs are loaded. Treat these as starting points and change one at a time.

Two graph formats. A UI export holds layout and widget values. An API export holds executable nodes and named inputs. Prefer the application's supported API export for automation. Hand-converting one to the other breaks on node identifiers, widget order, dropdown values, and UI-only notes.

Talking to the server. The /object_info route describes every node's schema. Posting to /prompt returns either a queued job identifier or validation errors. Track completion through history or events, then inspect the saved output. Submission is not delivery. Use deadlines, bounded retries, and job identifiers, and after a timeout check the queue before you resubmit.

16Add short video

Generate video only from a still you have already accepted, and keep the first clip to one object and one modest motion, such as a slow turn with a fixed camera. Defects in the starting image become moving defects, and every extra frame multiplies the cost.

Use the exact official task and variant template. Wan 2.2's 14B image-to-video models use two experts and the umt5-xxl text encoder. The separate 5B model is a single dense model with a high-compression VAE, so do not mix files between them. Keep the supported dimensions, frame constraints, VAE, expert switch, and sampling recipe. As one real data point, a community tutorial reports about 26 minutes on an RTX 4090 for a higher-quality Wan 2.2 first-last-frame workflow that does not use the speed-up LoRAs. Plan your rental time on a figure like that, not on the fastest recipe.

A real Wan 2.2 14B image-to-video file list, from a community tutorial, shows what a bill of materials for video looks like:

Tools around the clip: ffprobe and ffmpeg to inspect and convert files, and frame-interpolation models such as RIFE or FILM to add in-between frames; both are repackaged for ComfyUI. For automated quality checks, a local vision-language model such as Qwen3-VL-8B-Instruct can flag defects, with the limits described below. Its model family is also the text encoder behind Qwen-Image 2.1, so the family that read your prompt on the way out can review the result on the way back.

Frames, rate, and duration. Playback duration is frames divided by frame rate. For 81 frames at 16 frames per second, that is about 5.06 seconds of playback, or exactly 5 seconds from first frame to last, because 80 intervals divided by 16 is 5.

There is no universal 81-frame limit across every variant and engine. Use documented lengths or a supported continuation method, then inspect for drift at the seams.

ffprobe -v error -select_streams v:0 \
  -show_entries stream=width,height,avg_frame_rate,nb_frames \
  -show_entries format=duration -of json clip.mp4

Some containers omit the frame count; if so, count decoded frames. Check real file properties instead of assuming your requested settings were honored.

Five acceptance gates. Define the hard failures before you render.

1. Technical completion: the file exists, decodes, and has the expected size and length.
2. Visual structure: no melting shapes, flicker, or broken anatomy.
3. Brief compliance: it does what you asked.
4. Provenance and permissions: you hold the rights to every input and to what you publish.
5. Operational completion: archived, verified, and the GPU destroyed.

Test several prompts on fixed seeds and keep permitted failures as evidence, not only winners. A local vision-language model can flag defects but can also miss or invent them, and without a reference it cannot confirm identity. Even with a reference, calibrate against human review. Keep its dependencies in their own environment and budget its memory.

Report accepted work, not raw speed. Track attempted and accepted counts, warm and cold run time, peak memory, and total cost. A workflow making 60 samples an hour at 30% acceptance yields 18 accepted per hour; one making 36 an hour at 75% yields 27.

17Security: what is protected, where, and when

Three protections cover three situations. A tunnel protects data in motion, encrypted storage protects data at rest, and neither protects data being processed on a machine whose administrator you do not control.

Access. Use key authentication and a dedicated controller account with narrow permissions. Before you change a firewall or SSH setting, open a second session so a mistake cannot lock you out. If you use a mesh VPN, it still needs least-privilege access rules, and retired devices should be removed from it.

How much to trust the host. Match the hardware to the sensitivity of your data before you rent.

Key-based SSH login is the baseline for access. ssh-keygen creates a key pair; see your OpenSSH manual for key types. On a mesh VPN, Tailscale's access control lists restrict which devices may reach which ports (its role on the outbound journey was carrying the job, in section 14; on the return journey it carries your files back).

Credentials. Prefer gated downloads on the controller, or short-lived credentials on the worker. Interactive login may still save a token to disk; for the Hugging Face Hub the default location is under the Hugging Face home folder, so know where it is and who can read it. Keep credentials out of logs, prompts, screenshots, public manifests, and diagnostics. If one leaks, revoke it. Deleting the text does not un-leak it.

The encrypted archive. An archive must actually be mounted before you write to it. A directory can exist over an unmounted volume, and copying into it silently puts plaintext on the underlying disk. Check the mount source, capacity, and permissions first:

mountpoint -q ~/ai-lab/archive || { echo 'archive not mounted'; exit 1; }
findmnt --target ~/ai-lab/archive

Setting up encryption involves destructive storage operations. Follow the documented procedure for your tool, on a verified target, with a backup in hand.

LUKS through cryptsetup on Linux is the tool this guide assumes. The cryptsetup manual also lists limited support for opening VeraCrypt, TrueCrypt, and BitLocker volumes, which helps if an archive was created elsewhere.

Delivery: copy, then verify, then delete. Pull only the files the session needs. Bring outputs, adapters, required checkpoints, and manifests into a staging folder on the verified archive. Stop writes. Compare relative file lists, sizes, and cryptographic digests, and reopen representative files. Make a second copy where you require one. Only then remove worker copies, scoped to that one job.

# On the worker, after writes have stopped:
(cd outputs && find . -type f -print0 | sort -z | xargs -0 sha256sum) > outputs.sha256

# On the controller, after copying outputs/ and outputs.sha256 into staging:
cd ~/ai-lab/archive/job-001/outputs && sha256sum -c ../outputs.sha256

Retirement. In cloud storage the physical media is abstracted away from you, which is why NIST revised its media sanitization guidance (SP 800-88 Rev. 2, September 2025) to cover cloud and virtual storage. Ordinary deletion therefore gives you no proof of physical erasure. If that matters for your data, choose different hardware instead of trusting a delete button.

Publishing what you made. Share a curated derivative, not the working folder. Audit text, code, captions, images, filenames, metadata, and archive members. Exclude personal identities, addresses, account values, private paths, secrets, source prompts, and anything private. Check the visible pixels as well as the metadata, and scan the actual final file formats, not only the source document. Pattern scans help, but they cannot guarantee complete de-identification.

18Cost, throughput, and session budgeting

Budget the whole session, not the hourly rate. The expensive mistakes are idle time and an instance that is stopped but never destroyed.

The chart assumes a hypothetical 1.20 units per hour for the GPU and 0.05 per hour for disk, a 2-hour session, and then three behaviors: leave the machine running, stop it and forget it, or destroy it. A real provider's numbers differ, and a stopped instance's disk may bill at a higher rate than a running one, but the shape holds: only the third line stops.

The same arithmetic at real rates. These use the October 2026 rates from section 13, which are snapshots.

The last row is the argument for a controller. Keeping the weights cache on a disk you already own removes a monthly charge, and the gap between running and idle storage on a rented volume shows why an idle rental is expensive.

What a session costs. Include setup, transfer, generation, retries, quality checks, idle time, storage, and egress. A worked example in hypothetical units: 100 minutes at 1.20 per hour costs 2.00. Add 0.40 for storage and transfer and the session costs 2.40. If it produced twelve accepted results, each cost 0.20. Cost per accepted result, not cost per hour, is the number that tells you whether a workflow is good.

Size four resources separately: GPU memory, system RAM, disk, and bandwidth. Disk must cover environments, temporary downloads, training checkpoints, and outputs. Bandwidth can dominate short jobs: moving 30 GB at a sustained 20 MB per second takes about 25 minutes before overhead, and that time bills if the GPU is already running.

Set four limits before you start: a maximum duration, a cost allowance, a cutoff after which no new jobs begin, and a cleanup deadline. Reserve time to archive, because an abrupt shutdown timer can destroy training progress that was not copied back. If a session produces nothing, record zero accepted outputs. Hiding failures corrupts the next estimate.

19Troubleshooting, capstone, glossary, and sources

When something breaks, find the symptom, run the first check, and take the controlled action. Change one thing at a time, and keep one known-good environment and graph to roll back to.

After any package or extension change, rerun the GPU arithmetic and the baseline render. When you stop a process, use its exact process ID, since a broad pattern can match your own shell.

Real messages worth searching for. A "driver too old" message can mean a CUDA 12.x driver is running software built for CUDA 13.x. CUDA_ERROR_UNSUPPORTED_PTX_VERSION, error 222, was observed in one project's notes when a driver in the 580 range met compiled instructions from a newer toolkit than it understands. NaN or black images from an SDXL decode point to the fp16 VAE problem fixed by sdxl-vae-fp16-fix. A model that loads but outputs noise points to a mismatched or renamed-key file, as with a Qwen-Image 2.1 encoder quantized from the original layout.

Capstone. Another operator should be able to reproduce your still and your short clip, understand every component, recover required artifacts after an interruption, and confirm that cleanup happened. Hand over the component inventory, environment revisions, workflow, seeds and settings, acceptance results, cost, archive evidence, and the final resource state.

Glossary

What was verified, and what was not

Checked on 23 October 2026 against the pages named below. For the Vast.ai, NVIDIA, and Hugging Face items I read the official documentation pages as returned by search, not a full download of each. The model facts rest on model cards, Comfy-Org's repack, and community pages, since I did not open every primary repository. Later passes added sources and removed claims I could not source. No live deployment, training, or benchmark was run for this guide.

Added in the examples revision

Not verified in this guide: the memory chip makers for the RTX 6000 Ada and RTX PRO 6000 Blackwell, which I could not find; the RTX 5090's Samsung chips, which are reported but not officially confirmed; trainer configuration formats, which change often; and every Vast.ai and Lambda price, which came through trackers and will have moved. The Qwen-Image 2.1 license is described from reports of its LICENSE file, so read the file itself before relying on it.

Second verification pass. I removed or reworded claims I could not source: named VPS vendors and a single-board computer model, archive tools other than cryptsetup, SwarmUI, the SD3 and HunyuanVideo VAE rows, general-knowledge notes on encoders and interpolation tools, an unsourced SSH key type, a GPU-for-speed recommendation, and a claim that one card suffices for LoRA training. I also corrected the ComfyUI listen flag and the FLUX VAE license note.

Full-book audit. A final pass read every section and checked the remaining claims. The format table in section 11 and the memory methods it names rest on the sources below.

Background reading named in Version 2, not re-verified: the Latent Diffusion Models, Diffusion Transformer, Flow Matching, and LoRA papers, which I did not re-read.

AConnection options, and other setups and workflows

A. SSH tunnel, WireGuard, and Tailscale compared

Choose by who must reach whom, and how often the worker changes. For one session, an SSH tunnel is enough. For a fixed controller you manage yourself, plain WireGuard is a good fit. For repeat sessions across several devices and disposable workers, Tailscale removes the most manual work.

WireGuard's own description is useful here. It aims to be as easy to configure as SSH, authenticates peers by public key, and can roam between IP addresses. Its default UDP port is 51820. Tailscale builds on that protocol and adds the coordination, naming, and policy layer. In every case, keep ComfyUI bound to 127.0.0.1 and forward its port, as in section 14.

B. Other setups and workflows

C. A one-page session sheet

1. Before renting: bill of materials complete, digests recorded, cost ceiling and duration set (sections 10 and 18).
2. Rent: pick the GPU by memory need (sections 4, 11, 13), confirm the driver with nvidia-smi.
3. Connect: SSH tunnel, or join the worker to your tailnet with an ephemeral, tagged key (section 14).
4. Stage: copy only the needed weights and verify digests.
5. Run: one job at a time through the ledger; copy outputs back as they finish.
6. Close: verify the archive, remove tokens, destroy the instance, and confirm the console shows no remaining storage (sections 13 and 17).