AI Video Generation Glossary: I2V, CFG, Steps and LoRA With Our Real Settings

Terms are grouped by topic, and each group has a table with four columns.

Every video on this site is made in two stages:

1. Generate a start image with SDXL, with the face locked by PuLID
2. Hand that image to Wan 2.2 I2V, which turns it into a clip of about five seconds

Almost every term below lives somewhere in those two stages.

We use I2V because of faces. With text alone there is no reliable way to render the same character with the same face in every clip. So we lock the face in a still image first and let the video model focus on motion. The video inherits the start image's colours and look, which means most visual problems can be fixed at the image stage.

When we surveyed the landscape in July 2026, Wan's open weights stopped at 2.2; later versions were available only through an API. If you want to run on your own GPU, this combination is the realistic option.

In our pipeline the latent shows up twice: once when the start image is encoded into it, and once when the finished latent is decoded back into 81 frames. Sampling runs four steps in total. The high-noise model handles the first two and hands the latent over with its leftover noise intact; the low-noise model finishes the last two.

The most expensive ComfyUI lesson was not a setting. It was a change that never took effect. Right after we deployed a lower step count, the running process was not restarted and a stale cache was still being loaded, so the old step count kept running. The full story is in our write-up on cutting generation time.

• I2V: before fixing a visual problem in the video, ask whether the start image can fix it
• SDXL: measure raw generation time before cutting steps. Ours was 11 to 12 seconds at 30 steps
• ComfyUI: after any change, confirm it using the actual value printed in the log
• Latent: learn the word so you can tell "it failed during encode" apart from "it failed during decode"

PuLID only works on photographic faces. It relies on a face detector built for real faces, so it cannot find a face in an illustration. That is why our illustration tests used IPAdapter instead; the comparison is in our article on keeping a character's face consistent. The image encoder IPAdapter needs turned out to be the same one our video stage already uses, so no extra download was required.

We stop PuLID at 70% of the steps so the base model owns the late steps. Facial structure is settled early; skin and lighting detail is settled late.

PuLID also has an operational trap. Once, a startup script on the GPU server had silently stopped working, and ComfyUI came up without the face-detection library PuLID depends on. PuLID failed to load (generation was paused at the time, so nothing was published). "ComfyUI started" and "faces come out right" are different claims, so before resuming we now generate one real image and look at the face.

We also avoid motions that take the face off camera. Only the start image carries the locked face. If the character spins around, the face that comes back is one the video model redrew, and the identity drifts.

LoRAs are usually introduced as a way to teach a model a character. The ones in our production workflow are distillation LoRAs that let the video model work in four steps: one for the high-noise model and one for the low-noise model, each at strength 1.0. PuLID already handles faces, so we have not trained a character LoRA.

When we switched the base model files from 26.6GB to a 13.3GB format, the worry was that the LoRA would stop attaching. So we counted the matched layers before and after, confirmed it was 607 in both cases, and only then made the switch.

• PuLID: generate one image and check the face before resuming. Avoid spinning motions
• IPAdapter: test a spread of weights such as 0.5, 0.7 and 0.9
• LoRA: after swapping a base model, check that the LoRA still attaches to the same number of layers
• Seed: pin it for comparisons, randomise it in production. Without pinning you cannot tell a real speed-up from a lucky, simpler image

Steps and CFG multiply. Above CFG 1.0, every step runs twice: once with the prompt and once without. Our old setting, 8 steps at CFG 2.0, was 16 model passes. The current 4 steps at CFG 1.0 is 4.

Here is the measurement when we changed only CFG, from 2.0 to 1.0:

43% faster. But in that run a separate prompt bug was also present, so we could not judge quality fairly and held off on adopting it. We fixed the bug, re-measured with steps and shift included, and adopted the combined change after that.

"More steps means better quality" did not hold for a distilled model. The acceleration LoRA was built for four steps. Running eight was simply off the design point: twice the time, nothing gained.

The price of CFG 1.0 is that negative prompts no longer apply during the video stage. We accept that because negatives still apply when the start image is made, the video inherits that image's look, and every clip is reviewed by a person before publishing. In the production clips we checked right after rollout, we saw no harm from it.

Start from the sampler and scheduler pairing the model expects. Our image and video stages use different values because each follows its own model's standard setup. When we tested a separate illustration model, we gave it its own recommended Euler / normal / CFG 4.5 rather than reusing the photoreal settings, because that model breaks with them.

Later we had a chance to check the production settings of a comparable service. Its video settings, 720×1280 / 81 frames / 4 steps / CFG 1.0 / shift 5.0 / euler + simple, matched ours exactly. This is a standard configuration, not a quality-cutting special.

You may look for denoise in an I2V workflow and not find it. In ours, the start image is passed in as a condition, while the latent itself starts from noise. The split between the two models is set by step ranges ("from step 0 to 2", "from step 2 to 4"), not by denoise.

• Steps: if you use a distillation LoRA, start at the step count it was built for
• CFG: lowering it is fast but disables negatives. Make sure another safety net exists first
• Sampler / scheduler: start from the model's recommended pairing and do not mix without a reason
• Shift: change it alone, or you will never know what it did. We did not, and we still do not know
• Denoise: in I2V, this may not be the knob that controls how far the video drifts from the start image

81 frames at 16 fps is Wan 2.2's default, and we have not changed it. What we changed is what goes inside those five seconds. Clips with no change of action were rejected 44% of the time; clips with two changes, 62%. The more we packed in, the more we threw away. We now cap each clip at three actions.

Lower resolution makes many problems disappear. Encoding the start image into a latent normally takes a few seconds. Because VRAM is nearly full, it fails every time, retries with a slow tiled method, and takes 145 to 147 seconds as measured. Dropping to 640 would probably let the fast path fit, but we decided 150 seconds was not worth lower quality on every published clip.

We also considered "just encode with the tiled method from the start." But the tiled method is the slow part, so that would lock in 150 seconds permanently. The root cause is sharing the GPU with other workloads; it is the kind of waste that disappears on a dedicated GPU.

Decoding, on the other hand, is tiled from the start. Back when all 81 frames were decoded on the GPU at once, an out-of-memory warning was followed immediately by the whole ComfyUI process crashing. Tiled decode takes about 65 seconds and is 10 to 20% slower, but losing a clip to a crash costs more.

There is one inconsistency we have not fixed. Our start image is 832×1216 and our video is 720×1280, and those aspect ratios differ slightly. A mismatched image gets adjusted to fit at the video stage, so when we tested illustrations we generated the start image at 720×1280 directly. Our photoreal production path still uses 832×1216.

• Frames / fps: fewer actions per clip pass review more often. Cut the content before changing the length
• Resolution: lowering it fixes memory issues, at the cost of published quality
• VAE: use the log to separate encode time from decode time
• Tiled decode: if stability matters more than speed, turn it on before the first crash, not after
• Aspect ratio: match the start image to the video so your evaluations are not skewed by resizing

Text encoders in image models do not handle negation well. Write no wrinkles and the "no" is largely lost, while attention to wrinkles remains. Naming the thing you want to avoid in the positive prompt invites it.

In August 2026 we scanned our prompt text by machine. Character and wardrobe text contained 36 negations, and there were 55 self-contradictions where the positive asked for something the negative banned. None of them had been noticed when written.

The mirror ban had been there to stop reflections from producing extra faces. Name the actual concern, and you do not have to kill the whole scene.

Colour was the counter-intuitive one. To fight colour shifting mid-clip, we packed the video negative with colour and lighting words covering 12 colours. Colour drift got worse. Our guess is that attention concentrated on the idea of colour itself (this is an inference, not measured). We removed all of it, went back to a minimal negative, and now control colour at the start image stage.

Some negatives did work. Characters described with a film-photo mood sometimes produced black-and-white start images. Adding monochrome and related words to the negative keeps every image in colour.

Moles are banned outright in the negative. They appear at random positions and at low frequency, so a character would have a mole in one clip and not the next, and stop looking like the same person. Freckles are allowed: they appear as a dense pattern, which reproduces reliably.

• Prompt length: ten synonyms work no better than the one or two most representative words. We cleaned up our safety terms on that basis
• Negative prompt: do not try to fix a colour problem with colour words
• Negation: do not name what you want to avoid; describe what you want
• Contradictions: clashes between positive and negative are invisible to the eye. Check them by machine

In our August 2026 records, one video took about 9 minutes (504 to 572 seconds). Here is the time actually spent sampling next to model loading and related work:

Loading took more than twice as long as making the picture. Sampling was under a quarter of the whole clip. The remaining 90 to 158 seconds were not broken down in that record.

There is a structural reason loading is heavy. The image model and the two 14B video models cannot all sit in 32GB of VRAM at once, so for every clip we unload the image model after the start image and load the video models again.

When we measured a breakdown in June, loading was about 45 seconds, so this stage swings a lot. We have measured the same kind of swing for the start image: about 20 seconds when the GPU is free, 88 to 99 seconds when it is contended. We believe contention-driven reloading is the main cause, but we have not isolated it for the video stage (this is an inference).

fp8 is where we once wrote down something wrong. When we switched to the 13.3GB file format, we noted that memory pressure would ease. Measurements the next day proved that wrong: memory used by read-only mapped files can be discarded by the operating system when needed, so it was never the pressure point. The format change is justified by one thing only: computation was already running in fp8, so reading a file twice as large bought nothing.

OOM hit hardest on 26 August 2026. ComfyUI was killed four times in one day and 13 videos failed. The cause: ComfyUI did not know its memory limit. The real limit was 57GiB, but ComfyUI saw the whole machine's roughly 251GB, concluded there was plenty left, and kept piling models into RAM.

Things that looked like fixes but were not:

What we adopted is a planned restart. When unreclaimable memory passes a threshold, the worker stops taking new jobs, lets the running job finish, and then ComfyUI restarts.

Downtime is 141 seconds, far cheaper than a crash that throws away a clip of about 12 minutes.

The queue design failed twice before this. First, "restart when the queue is empty" never fired: the worker grabs the next job the instant one finishes, so the queue is never empty, and memory reached 46.6GiB without a restart. Now the worker pauses intake once the threshold is crossed, which guarantees a gap. Second, a threshold set too low restarts after every one or two clips, so it sits at 45GiB rather than 34GiB.

Batch size is one image per run. Requesting images one at a time pays for model loading each time; we measured that in our article on keeping a character's face consistent (96.5 seconds for the first image, 6.1 seconds for each after).

• Model loading: when two large models take turns on one GPU, loading can outweigh sampling
• fp8: the file format and the compute format are different things. Work out which one is doing the work
• VRAM: do not just check free space; find which stage runs out
• OOM: before calling a memory-free API, check whether it reduces RAM or adds to it
• Queue: "do X when idle" never happens on a queue that is never idle

Twenty-five terms, but the process for changing any of them is short.

1. Measure the breakdown by stage. Sampling can be under a quarter of the total
2. Change one thing at a time. Pin the seed, start image and prompt. We changed shift together with other values and still cannot separate its effect
3. Start at the model's design point. Four steps for a four-step distillation, the recommended sampler if there is one
4. Write down what you lose before you gain speed. CFG 1.0 costs you negative prompts
5. Confirm the change from the actual value in the log. Editing a setting and having it take effect are different things
6. Do not solve prompt problems by adding words. Check negations and contradictions by machine