A ComfyUI video workflow can finish one run at a reasonable pace and then crawl on the next few runs, even when the prompt looks unchanged. It is tempting to call that a model problem, roll back an update, or restart everything. Before changing the setup, establish what actually became slow. A render has several stages, and “the whole run took longer” does not tell you whether the delay began before sampling, during sampling, while loading a reference, or when writing the final file.
Save a known-good baseline while the workflow is behaving normally. Keep the workflow file, model and node versions, source media, frame size, duration, step count, and any acceleration settings together with one output. Record the time for each major stage if your console or workflow exposes it; otherwise note the time at start, first visible progress, sampling completion, and final export. The point is not to produce a universal benchmark. It is to compare your machine with itself using the same job. If a project changes resolution, reference video length, or model between runs, treat that as a new test rather than evidence of a mysterious slowdown.
When the problem appears, do one controlled rerun before opening a dozen settings. Use the saved inputs and check whether the same stage is slow again. Watch both GPU memory and system memory, but do not infer the cause from a single high number. A full memory meter may reflect expected loading, offloading, or another process. Also note whether the slowdown is steady from the first run or grows after repeated jobs. Those patterns suggest different next tests. If the output looks worse as well, log that separately; slower processing alone does not establish that memory use changed the image. Verify that the actual workflow and inputs match the baseline before interpreting visual drift.
Next isolate one variable at a time. Close unrelated GPU-heavy applications and rerun the identical job. If that changes the waiting period, record it. If not, compare a fresh application start with a later run in the same session. If only the later run slows, try a short pause between queued jobs and see whether the pattern changes. Then inspect the last known-good workflow against the current one: a changed sampler, missing acceleration component, longer reference clip, or added upscale stage can hide behind an unchanged text prompt. Make a copy before editing so the test itself does not erase the evidence.
If a restart restores speed, that is a useful observation, not a diagnosis. It tells you where to focus the next comparison: what was loaded, queued, or left running before the slowdown. If it does not restore speed, look at version changes, source files, and system load before blaming the last render. Keep two results side by side: a fixed-input timing log and a separate creative review of whether the clip is usable. A fast but broken output and a slow but usable output are different decisions for a production team.
For anyone running repeated AI video jobs locally, where does the time disappear first on your machine: waiting to start, sampling, decode, or export? What is the smallest test that let you reproduce the slowdown without rebuilding the whole setup?