LTX 2.5 on One RTX PRO 6000: A 10-Second 1080p Video With Audio in 90 Seconds

On October 27, 2026 we launched the public LTX 2.5 Video Generation template on one NVIDIA RTX PRO 6000 Blackwell Server Edition (96 GB). We had Claude Opus 5.5 do the launch through the EcoHash GPU MCP server and write the prompts. Then we timed 24 renders across four output sizes and three clip lengths. Every render included a generated soundtrack.

Disclosure: EcoHash operates the platform and the template tested here. This is our own measurement on a standard on-demand instance from the public Console catalogue, not an independent review.

Results at a glance

Measurement (one RTX PRO 6000, warm server, 24 fps, audio on)	Result
Launch call → /health ready	3 min 10 s (instance running at 1 min 33 s; the rest is loading 72.9 GiB of weights)
First request after start (2 s, 768×512)	6.0 s
10 s clip at 1080p (1920×1088)	90.0 s (9.0× real time)
10 s clip at 720p (1280×704)	33.6 s (3.4× real time)
10 s clip at 480p (768×512)	14.8 s (1.5× real time)
10 s 1080p clips per GPU-hour, sequential	39
Same seed, same request	Byte-identical mp4 on every repeat

How long does LTX 2.5 take per clip on an RTX PRO 6000?

Mean wall time per clip, two runs each, measured from the client. The figure includes the two-stage diffusion, VAE decode, audio muxing and returning the file.

Output	Resolution	Clip	Runs	Wall time (mean)	× real time	Clips / GPU-hour
480p 3:2	768×512	2 s (49 frames)	2	5.1 s	2.5×	700
480p 3:2	768×512	5 s (121 frames)	2	8.9 s	1.8×	405
480p 3:2	768×512	10 s (241 frames)	2	14.8 s	1.5×	243
720p 16:9	1280×704	2 s (49 frames)	2	8.4 s	4.1×	427
720p 16:9	1280×704	5 s (121 frames)	2	16.9 s	3.4×	213
720p 16:9	1280×704	10 s (241 frames)	2	33.6 s	3.4×	107
1080p 16:9	1920×1088	2 s (49 frames)	2	16.8 s	8.2×	214
1080p 16:9	1920×1088	5 s (121 frames)	2	40.5 s	8.0×	88
1080p 16:9	1920×1088	10 s (241 frames)	2	90.0 s	9.0×	39
1080p 9:16	1088×1920	2 s (49 frames)	2	16.7 s	8.2×	215
1080p 9:16	1088×1920	5 s (121 frames)	2	41.8 s	8.3×	86
1080p 9:16	1088×1920	10 s (241 frames)	2	118–194 s*	11.8×	30

At 1080p, render time grows roughly in proportion to clip length: 16.8 s for 2 s of video, 40.5 s for 5 s and 90.0 s for 10 s. For 2 s and 5 s clips, portrait 1088×1920 matched landscape within 1.3 s. At 10 s, the faster portrait run took 118 s, 28 s slower than landscape.

* The two portrait 10 s runs took 118 s and 194 s. During the slower one, the GPU logged about 75 s at near-zero utilization while our SSH tunnel stopped answering /health. That points to transfer, not generation. The rate columns therefore use the 118 s run.

In the other eleven cells, two runs of the same request differed by at most 1.0 s. In all twelve, the two output files were byte-identical.

How fast does the LTX 2.5 template start?

Event	Time after launch_template
Instance running, SSH ready	1 min 33 s
/health returns {"status":"ready"}	≤ 3 min 10 s
First 2-second test clip returned	+ 6.0 s

You don't download or install anything. The template mounts the LTX 2.5 Diffusers weights read-only from shared storage and starts a FastAPI server on port 8000.

What does a clip cost on a rented RTX PRO 6000?

A GPU instance is billed per hour while it runs, not per clip, so the useful number is clips per GPU-hour. Multiply by the current RTX PRO 6000 hourly rate on the RTX PRO 6000 page to get a cost per clip.

Output	10 s clips per GPU-hour (sequential)
480p	243
720p	107
1080p	39

Two things move the real number:

• Idle time. The instance bills whether or not it is rendering. Our session was billed for 4 h 41 min, but the GPU log shows it was busy (≥ 10% utilization) for only 23 minutes. The rest was idle time while our client was disconnected. Terminate as soon as you are done.
• Retries. We kept 6 of 8 shots on the first take. Budget for at least one extra take per shot you intend to keep.

How do you run LTX 2.5 with Claude and the EcoHash GPU MCP?

1. Connect the EcoHash GPU MCP server to Claude (setup guide).
2. Launch. Ask Claude to start the "LTX 2.5 Video Generation" template. It calls list_templates, then quote_template, waits for your confirmation, then calls launch_template. Pass your SSH public key if you want a shell.
3. Wait for get_instance to report running, then poll GET /health until it returns ready.
4. Prompt. Have Claude write one prompt per shot in five parts: camera, subject, one action with a visible result, an ending, and the sound.
5. Render. Call POST /v1/video/generations with prompt, width, height, num_frames, fps and seed. The response holds the mp4 with audio as base64.
6. Terminate with terminate_instance once your files are saved locally, because the scratch disk is deleted with the instance.

A minimal request:

curl -s http://localhost:8000/v1/video/generations \
  -H "Content-Type: application/json" \
  -d '{"prompt":"Doorbell camera footage at night on Halloween ... Audio: crinkling candy wrappers, distant crickets. No music, no speech.",
       "width":1920,"height":1088,"num_frames":241,"fps":24,"seed":20261027}' \
  | python3 -c "import sys,json,base64;open('out.mp4','wb').write(base64.b64decode(json.load(sys.stdin)['data'][0]['b64_mp4']))"

Width and height are rounded to multiples of 32, so 1080 becomes 1088. num_frames is rounded to 8k+1, and 241 frames at 24 fps is about 10 seconds. The server runs the distilled two-stage schedule (8 + 3 sigmas, unguided). It accepts num_inference_steps and guidance_scale but ignores them.

Which prompt structure worked best?

We gave Claude a one-line brief: a Halloween-week variant of the "caught on a doorbell camera" format, with eight 16:9 shots. We asked for each prompt in five parts:

[camera / footage type], [time + place]. [one subject doing one thing].
[one action with a visible result]. [ending: freeze or look into the lens].
Audio: [2–3 concrete sounds]. No music, no speech.

Claude then checked every prompt against four questions before we rendered anything:

1. Is something happening in the first second?
2. Is there only one action?
3. Is there an ending?
4. Can you hear the sound?

The camera phrase, such as "doorbell security camera footage" or "handheld phone video", did more for realism than any quality adjective.

What did LTX 2.5 get wrong?

We rendered eight 1080p shots, at 5 s or 8 s each, from Claude's prompts. On the first take we kept six. The misses are worth knowing before you write prompts:

• Objects vanish instead of falling. We asked for a black cat to push a jack-o'-lantern off a railing. The cat never touched it, and the pumpkin simply disappeared.
• Readable text is gibberish. A hand-lettered sign beside a candy bowl came out as invented words.
• Words are taken literally. "A great horned owl" produced an owl with actual horns.
• Counts drift. We asked for five costumed raccoons and got four.

What worked well: fisheye "doorbell camera" framing, night-vision grain, animal fur and motion, and sound that matched the action, such as wrappers crinkling and a plastic bowl clattering.

Does the network path change the timing?

Yes, so measure where you render. Called from inside the instance (localhost:8000), an 8 s 1080p shot took 63.7–64.5 s and a 5 s 1080p shot took 36.3–36.9 s. Through our SSH tunnel, an earlier 8 s shot took 329 s, almost all of it transfer. The platform's public service URL returned 502 for requests that ran longer than about a minute. For long renders, run the request on the instance and copy the files back afterwards.

Test environment

• GPU: 1 × NVIDIA RTX PRO 6000 Blackwell Server Edition, 96 GB, driver 580.105.08
• Template: EcoHash public template "LTX 2.5 Video Generation" (image vllm/vllm-omni:v0.27.0rc1), Atlanta region
• Pipeline: Diffusers LTX2Pipeline, distilled DiT, two-stage 8 + 3 sigma schedule, guidance 1.0, audio on
• Timing matrix: sequential requests through an SSH tunnel, client-side wall clock. Opening shots: sequential requests from inside the instance.
• Prompt for the timing matrix: a fixed Halloween porch scene, seed 20261027, 24 fps
• Date: October 27, 2026

Limitations

• This is one GPU, one prompt for the timing matrix and two runs per cell. Other prompts may vary slightly in time; content does not change the step count.
• We did not test concurrent requests. The server holds a GPU lock and queues them.
• We did not test image-to-video timing, longer clips beyond 241 frames, or other runtimes.
• Clip quality is judged by eye. We report what we kept, not a quality score.
• LTX 2.5 is distributed under the LTX-2 Community License. Check its terms for your use case before you publish commercially.

FAQ

Can one RTX PRO 6000 render 1080p LTX 2.5 video? Yes. A 10-second 1920×1088 clip with audio rendered in 90.0 s on a single 96 GB RTX PRO 6000. We used no CPU offload and no quantization flags.

Does LTX 2.5 generate sound? Yes. Every render in this test came back with an AAC soundtrack generated alongside the frames. Describe the sounds in an Audio: sentence in the prompt.

Is the output reproducible? In our test it was. Repeating a request with the same seed produced byte-identical files in every one of the 12 size and length pairs.

How long until the template is usable? In our test, /health reported ready 3 min 10 s after the launch call. The first short render returned 6 s later.

Do I need to download the model? No. The template mounts the weights from shared storage. You pay only for the GPU time you run.

---

Disclosure: I work on EcoHash. This post was originally published on the EcoHash blog.