Independent and unofficial. The Test Fixture is not affiliated with, endorsed by, or operated by any model developer or platform mentioned here. LTX-2.3 and related marks belong to their respective owners.
A test bench is not a list of parts. It is a setup that produces the same result twice, or tells you why it didn’t.
Most “my setup” posts are shopping lists. That is fine for a build guide. It is not enough for a test report, because a parts list does not tell a reader which differences matter. The question is not what I own. The question is what a reader needs to know to judge whether my result could apply to their conditions.
So this post covers three things: the hardware I test on, the software stack that runs it, and the documentation system that keeps the two honest. The documentation is the part most people skip, and it is the part that makes the rest useful.
The test question behind this post
This is a bench description, not a controlled run, so there is no single test question. The working question is narrower:
What does a reader need to know about my setup to decide whether a result is relevant to them, and what do I need to record so that I can tell whether a change came from the model or from my own bench?
That question drives every choice below.
Hardware
This is the current bench. It will change, and when it does, the change gets a note at the bottom of this page. A bench description that silently drifts is worse than no bench description.
GPU: a single consumer GPU with 24 GB of VRAM. One card, not a multi-GPU rig. This matters: most of my readers run one card, and multi-GPU behavior is a different test problem.
CPU: a current desktop-class processor, enough cores to keep data loading from becoming the bottleneck. CPU model is recorded in the configuration block of each test, not assumed here.
System RAM: 64 GB. This is generous for single-GPU inference, and it is deliberate. If a test fails because the host ran out of memory, I want to know that quickly and not confuse it with a model failure.
Storage: NVMe for the OS, the runtime, and the active model files; a separate drive for outputs and test assets. Outputs are large, and mixing them with the runtime drive invites avoidable slowdowns that look like model problems.
Cooling and power: adequate, not exotic. Thermal throttling is a real variable in long video runs, so I record ambient conditions when a run is long enough for heat to matter.
Display and capture: a calibrated display for reviewing output, and a capture path that does not re-encode before I look at frames. If I judge quality through a lossy preview, I am testing the preview.
What is not on the bench: a second GPU, a workstation-class accelerator, or a rented cloud instance. Those are legitimate test conditions, and they are out of scope for now. I would rather say that clearly than imply coverage I do not have.
Software
Software versions are experimental variables, not footnotes. The same model file under a different runtime is not the same test.
The stack, recorded per test rather than assumed:
OS: a current Linux desktop distribution. Recorded per test.
GPU driver: recorded per test. Driver changes have moved results before, and I do not want to guess which change did it.
CUDA and PyTorch: recorded per test.
Inference framework: ComfyUI or an equivalent runner, with the exact version. “Latest” is not a version.
Custom nodes and extensions: named and versioned. A workflow screenshot with three nodes cropped out is not documentation.
Model files: exact identifier, version or commit, quantization, and a checksum where one is available. I do not distribute model files or installers without source, license, checksum, and legal-status documentation.
Generation parameters: sampler, scheduler, CFG, steps, resolution, frame count, FPS, motion and denoise settings. These live in the configuration block, not in a comment thread.
I keep a known-good environment snapshot for each model version I test. When a result changes, the first thing I check is whether the environment changed underneath it. That check has saved me from publishing a “model regression” that was really a dependency update.
Documentation
This is the part that turns a bench into a test fixture.
1. A configuration manifest per test. JSON or CSV, with the fields above. The manifest is the source of truth. The article summarizes it; the manifest is what a reader can actually inspect.
2. A run log. Number of runs, seeds, warm-up runs, discarded runs and why, render times as a distribution rather than a best case. If I discard a run, it goes in the log. Discarding runs quietly is how a test becomes a highlight reel.
3. A failure log with categories. Temporal flicker, identity drift, object deformation, camera instability, prompt contradiction, render failure, workflow-induced failure, and irreproducible success. The categories are stable across tests so I can compare failure patterns between versions instead of starting from zero each time.
4. Checksums and stable IDs. Model files, input assets, prompt files. A prompt without a stable ID is a quote, not a test input.
5. A paper notebook for anomalies. This is not nostalgia. The spreadsheet records what I decided to measure. The notebook catches what I noticed before I knew it was worth measuring: a fan ramp, a flicker in the preview, a render that felt slower than the clock said. The spreadsheet is not always where the evidence started. Later, those notes either become a field in the manifest or get marked as an unconfirmed observation.
6. A correction log. Publication date, update date, what changed, and why. If I cannot reproduce my own result later, that goes in the log too. Especially then.
What I publish, and what I do not
Published where legally and technically possible: prompt files with stable IDs, seed lists, configuration manifests, checksums, commands or workflow files, proxy videos for review, and a note on what was withheld and why.
Not published: model files or installers without source, license, checksum, and legal-status documentation; anything that would require a reader to run an unknown binary; anything behind a login, an account, or a “download portal.”
This site does not request passwords, API keys, verification codes, wallet details, recovery codes, or remote access. That is not a disclaimer buried at the bottom. It is a rule about what this bench is for.
Known limitations
The bench is single-GPU, single-machine, and desktop-class. It does not cover multi-GPU behavior, datacenter accelerators, or cloud runtime differences. It does not cover every quantization. It does not turn a small test set into a benchmark. It does not replace official documentation, and it is not official documentation.
It does produce conditions a reader can inspect, failures a reader can compare against their own, and conclusions that can be falsified. That is the point of the bench.
The configuration is part of the result. A successful sample is evidence. It is not a warranty.
If it can’t be reproduced, it’s a story—not a result.
Marcus Brennan is the editorial persona under which The Test Fixture publishes independent testing notes. The test records are real; the biographical details are narrative context, not professional credentials, certifications, or claims of affiliation.