1. Draft at half the final resolution, 8 steps, distilled model at cfg 1.0.
2. Upscale the latent x2 with LTX's learned spatial upscaler (one pass, no sampling).
3. Refine for 3 steps at full size.

Then respect four rules: frame counts must be 8n+1, stage-1 sides must be multiples of 32, system RAM (not VRAM) is usually what kills long renders, and a widget with a wire plugged into it is ignored. Everything below was measured on one machine: an RTX 3080 with 20 GB of VRAM and 32 GB of system RAM, running ComfyUI 0.37.0. Where we didn't measure something, we say so.

Why three stages instead of one

The obvious way to get a 1280x720 clip is to ask for 1280x720 and let the sampler run. On a consumer card that is the slow way, and past a certain size it is the failing way.

The two-stage recipe splits the work:

• Stage 1 (draft) samples at half resolution, for example 640x352 for a 16:9 clip, with the distilled model's 8-step sigma schedule. This is where motion, composition and the soundtrack are decided, and it is cheap because the latent is a quarter of the area.
• The x2 upscale hands that latent to LTXVLatentUpsampler with the ltx-2.5-latent-spatial-upscaler-x2 model. This is a trained network, not bicubic resampling. It runs as a single forward pass, so it costs a fraction of a sampling step.
• Stage 2 (refine) runs 3 more sampling steps at full size to put back the fine detail the upscaler can't invent.

Measured on our 3080: a 5-second 1280x720 clip with audio, draft + upscale + refine, took 283.5 s of wall time from a cold start (model load included). 10 s and 15 s clips at 1280x720 also completed.

A practical workflow follows from this. Render stage 1 on its own first. A stage-1-only draft at 640x352 and 121 frames came out as a 0.52 MB file, against 4.6-6.9 MB for full runs. It's enough to judge whether a take is worth keeping. Draft small, pick the keeper, then run the full chain (or the upscale alone) on that one.

The size rules: 8n+1 frames and multiples of 32

LTX-2.5 generates 8n+1 frames. At 24 fps that gives:

Ask for any other number and the model snaps it, and the audio length can drift away from the picture. Pick from the table.

Sizes follow the same kind of rule. Stage-1 sides must be multiples of 32, and the final size is exactly 2x stage 1:

Note the 16:9 row: 720 is not a multiple of 64, so "720p" through a x2 upscaler lands on 1280x704.

Where the ceiling is on 20 GB

About 1.2 MP final is the working ceiling on our card (416x736 → 832x1472). We tried 2.0 MP (544x960 stage 1). ComfyUI spilled 9.5 GB to system RAM, each step took about 58 s (roughly 6x slower), and then ComfyUI crashed on the next model load.

The warning signs appear in the console before the crash. Look for loaded partially ... MB offloaded together with a jump in s/it. That means the model no longer fits and is being streamed. If you see it, lower the resolution before you touch anything else.

The RAM trap: it's usually not your VRAM

This one cost us the most time. On a card smaller than the model, the weights don't disappear; they move to system RAM. GGUF loaders keep the weights in system RAM and stream them to the GPU. That lowers VRAM use and raises RAM use, which is reported behaviour and consistent with our logs. So the number that decides whether a long render finishes is often free system RAM.

What we measured on a 32 GB machine:

• One 25-second (601-frame) clip with the refine pass took free RAM from 26.3 GB to 0.6 GB. That's about 25 GB for a single clip.
• Renders started with much less than ~20 GB free failed. Restarting ComfyUI gave back ~20 GB and took ~50 s.
• The failures didn't look like memory errors at first: hostbuf_file_reader_read failed and WinError 1450, while free RAM sat at 2.1-2.5 GB mid-render.
• The biggest variable was the web browser: 0.6 GB on a quiet night, 5.2 GB with many tabs open.

Rules of thumb that came out of it:

• Treat 32 GB of system RAM as the practical floor for these workflows.
• Close the browser (or most of its tabs) before a batch.
• Restart ComfyUI between long clips.
• Queue 2-3 jobs, not 10.
• Shrink input videos first. A video loader may decode every frame to float32 in RAM, and a 1080x1920, 60 fps, 24-second clip works out to roughly 34 GB decoded. Resize it to half the output size, the workflow's fps and the length you need with ffmpeg before it goes anywhere near ComfyUI.

If you see DefaultCPUAllocator: not enough memory, HostBuffer ... failed or WinError 1450, it's system RAM. Close apps, restart ComfyUI, shorten the clip. If you see Allocation on device ... would exceed allowed memory, it's VRAM. Lower the resolution first, then the frame count, then use a smaller quant.

Two launch flags we run with: --reserve-vram 1.5 keeps VRAM headroom for the desktop, and --disable-pinned-memory is a documented fix for pinned-memory failures. --lowvram is reported to cost 20-40% speed. We haven't measured it, so use it only if a render won't fit otherwise.

The linked-widget trap: numbers that do nothing

You open a workflow, change length on EmptyLTXVLatentVideo from 97 to 121, queue it, and get the same clip length as before. The workflow isn't broken.

In ComfyUI, a widget whose input has a wire plugged into it is ignored. The node still prints a number, but the value comes from whatever is on the other end of the wire. In a typical LTX graph, the size, length and FPS on EmptyLTXVLatentVideo, LTXVEmptyLatentAudio, LTXVConditioning and CreateVideo are all driven from primitives elsewhere. Editing the printed values changes nothing.

How to check any workflow:

1. Hover the input. If a link enters it, the widget is dead.
2. Or read the JSON. In the node's inputs list, an entry with "link": <number> is driven from elsewhere. Links are stored as [id, from_node, from_slot, to_node, to_slot, type]. Follow the link back to the source node and edit that one.
3. Expect indirection in shared workflows. The real control is sometimes several nodes away, for example a "seconds" value feeding a math node that computes the frame count.

The fix we settled on for our own graphs: put every live control (stage-1 width and height, frames, FPS) in one clearly coloured group of primitives, and never make anyone edit a downstream widget.

Settings that look like fixes but aren't

• The negative prompt. The distilled model runs at cfg 1.0, and at cfg 1.0 the negative branch cancels out, so the negative prompt has no effect. Leave it empty.
• Raising cfg. We tried video/audio cfg 3.0/7.0 on the distilled model. The look got markedly worse, and real cfg evaluates two branches every step, so it's slower too. Steer with the positive prompt and the seed instead.
• More steps. Doubling steps costs more than any other lever gives back. Draft small, pick the keeper, and spend the time there.
• "No zoom" in a static shot. If the camera moves when you asked for a locked shot, check the prompt for camera-move words, including negated ones like "no zoom". Describe the locked-off camera positively and delete every move word.

Three small gotchas:

• A run that "finishes" in 0.01 s is ComfyUI returning a cached result for an identical prompt. Change the seed.
• Edits to a workflow .json on disk don't show up in an open tab, because the tab restores its own copy of the graph. Load the file again.
• If values land in the wrong widgets after loading, a combo option name probably differs in your ComfyUI version and shifted later widgets by one. Re-select it and re-check the widgets below it.

Bonus: the learned upscaler works on video from any model

The x2 upscaler only accepts LTX latents, but you can get any clip into one. Decode to pixels, re-encode with LTX's own video VAE, upscale, decode. The model that produced the pixels stops mattering at the pixel boundary. That works for another model's output, an older render or camera footage. There are no sampler steps, which is why it's fast.

Measured: a 311-frame 480x864 clip went to 960x1728 in 80.1 s, with VRAM peaking around 17.9 GB. The upsampler runs without tiling, so a longer or larger clip may need chunking.

Watch out for one thing: 311 frames went in and 305 came out. The last 0.25 s was cut because LTX's VAE works on the same 8n+1 grid. Feed it 8n+1 frame counts (121, 241, 345...) or trim to one first. Also, the graph writes picture only, so copy the original audio back with ffmpeg (-c:a copy) rather than re-encoding it.

Try it

We published the text-to-video version of this recipe as a free workflow: comfyui-ltx-2.5-low-vram-workflow on GitHub (MIT). It includes the three-stage graph with the live controls grouped in green, a frame and size cheat-sheet inside the graph, and an installer that downloads the models from their publishers and checks each file's SHA-256. If you want image-to-video, the any-video upscaler and a settings guide with the numbers above, those are in the paid Low-VRAM AI Video Pack. (Disclosure: Kanto Labs makes it.)

A licence note before you publish anything. The LTX-2.x Community License is free for commercial use under $10M annual revenue, and published outputs must be disclosed as machine-generated. Read the licence itself; our summary isn't legal advice.

Checklist

• Three stages: half-res 8-step draft → learned x2 latent upscale → 3-step refine
• Frames are 8n+1 (121 = 5 s at 24 fps)
• Stage-1 sides are multiples of 32; final = exactly 2x
• Final size at or under ~1.2 MP on a 20 GB card (our measured ceiling)
• ≥ ~20 GB free system RAM before a long clip; browser closed; ComfyUI restarted between long clips
• Edited the primitive, not a linked widget
• cfg 1.0, empty negative, steering with the positive prompt and the seed
• Draft judged at stage 1 before paying for the full chain
• AI-generated outputs labelled where you publish them

This article was written with AI assistance and reviewed by Kanto Labs. Every number in it comes from our own renders on one RTX 3080 20 GB / 32 GB RAM machine unless it's marked as reported. We haven't tested cards with 4-16 GB of VRAM.

• To keep headings and tables, use pymupdf4llm.to_markdown("file.pdf"), but check that its AGPL licence suits you.
• For raw speed with correct word spacing, use pypdfium2 and add your own page markers.
• For a whole folder of mixed Office files, use Microsoft's MarkItDown, but verify the PDF output, because the PDF path can lose spaces.

Below is how we tested those claims, with the code we ran.

Why Markdown, and not plain text?

LLMs read Markdown well. # headings tell the model, and your chunker, where sections start. Tables survive as | a | b | rows instead of a soup of numbers. Page markers let an answer cite "page 7". Plain extract_text() output loses all three. That hurts retrieval, because a chunk that mixes the end of "Methods" with the start of "Results" embeds badly.

The test

The test file was one real, digitally created PDF: Attention Is All You Need (arXiv 1706.03762, 15 pages, 2.2 MB). We ran it on a normal Windows laptop with Python 3.13, using pymupdf4llm 1.28.2, markitdown 0.1.8 and pypdfium2 5.13.0.

pip install pymupdf4llm "markitdown[pdf]" pypdfium2
curl -L -o attention.pdf https://arxiv.org/pdf/1706.03762

import time, pymupdf4llm, pypdfium2 as pdfium
from markitdown import MarkItDown

t = time.time(); md1 = pymupdf4llm.to_markdown("attention.pdf"); t1 = time.time() - t
t = time.time(); md2 = MarkItDown().convert("attention.pdf").text_content; t2 = time.time() - t

t = time.time()
pdf = pdfium.PdfDocument("attention.pdf")
pages = []
for i, page in enumerate(pdf, start=1):
    text = page.get_textpage().get_text_range()
    pages.append(f"<!-- Page {i} -->\n{text}")
md3 = "\n\n".join(pages); t3 = time.time() - t

for name, md, secs in [("pymupdf4llm", md1, t1), ("markitdown", md2, t2), ("pypdfium2", md3, t3)]:
    heads = [l for l in md.splitlines() if l.startswith("#")]
    print(f"{name:12s} {secs:5.2f}s words={len(md.split()):5d} headings={len(heads)}")

Results:

The word count gives the problem away. The paper has about 6,000 words. MarkItDown's PDF path reported 2,802 because many lines came out glued together. That is one PDF, not a verdict on every file, but it is exactly the failure you want to catch before embedding 10,000 documents. MarkItDown remains excellent for DOCX, PPTX and XLSX. It is the PDF route that needs checking.

What each option is good at

pymupdf4llm (built on PyMuPDF). It rebuilds headings from font sizes and outputs Markdown tables and bold/italic. Of the three, it gives the most "LLM-shaped" output. One cleanup tip: headings can come out wrapped in bold (## **1 Introduction**), so strip the * characters if you store headings as metadata. Licence: PyMuPDF is AGPL-3.0, with a commercial licence available. Check that it fits a closed-source product before you ship it.

pypdfium2 (Chrome's PDF engine, Apache/BSD). It is by far the fastest and gets word spacing right. It gives you plain text per page. That is often enough for RAG if you add page markers and split by size. There are no headings, so chunks lose section context.

MarkItDown (Microsoft, MIT). It is one API for PDF, Word, PowerPoint, Excel, HTML, EPUB and more. It is very convenient for mixed folders. Spot-check its PDF output as shown above.

Heavier options. If your PDFs are scans, or have complex multi-column layouts, look at layout-model tools such as Docling or Marker. They add OCR and layout detection, but they are much slower and usually want a GPU. None of the three libraries above does OCR: an image-only scan gives you empty text.

A quality check worth automating

Before you embed anything, flag documents whose output looks broken:

def looks_broken(md: str) -> bool:
    words = md.split()
    if len(words) < 50:                          # empty or image-only PDF
        return True
    avg = sum(map(len, words)) / len(words)
    return avg > 10                              # glued words push the average up

English prose averages 5-6 characters per "word" by this count. On our test, pymupdf4llm scored 5.8 and pypdfium2 scored 5.5. The MarkItDown output scored 12.5. Send flagged files to a different converter, or to OCR.

Doing it for thousands of files, in any format

Running this yourself means managing downloads, timeouts, format detection, and a converter per file type. If your documents are URLs (S3 links, a CMS export, arXiv, a customer's shared folder), our PDF & Document to Markdown Apify actor does the whole step. (Disclosure: Kanto Labs makes it.)

• It converts PDFs with PDFium (the engine that won on spacing above) and marks every page with <!-- Page N -->.
• It converts DOCX, PPTX, XLSX/XLS, EPUB, HTML, CSV, JSON, IPYNB, MSG and ZIP through MarkItDown.
• It detects the file type from the bytes, so links without an extension still work.
• It returns the page count, word count and a SHA-256 hash (useful for de-duplication).
• It can optionally split the text into RAG chunks of the size you choose, each with its headingPath.

curl -X POST "https://api.apify.com/v2/acts/kantolabs~document-to-markdown/run-sync-get-dataset-items?token=$APIFY_TOKEN&maxTotalChargeUsd=10" \
  -H "Content-Type: application/json" \
  -d '{"documentUrls": ["https://arxiv.org/pdf/1706.03762"], "chunkSize": 1500, "chunkOverlap": 150}'

On the same paper, a cloud run downloaded and converted the file in 277 ms and returned 15 pages, 6,177 words and page-marked Markdown.

What it costs. $4 per 1,000 converted documents ($0.004 each), the same price for a 1-page memo and a 300-page manual, with platform compute included. Converting a 2,000-PDF research archive costs $8. Files that fail are not charged: download errors, files that are too large, unsupported types, and scanned PDFs with no text layer all come back with a reason in error.

What it will not do: OCR. If most of your files are scans or phone photos, use an OCR tool.

Use it from an AI assistant

Add the actor to Claude Desktop, Cursor or VS Code through Apify's MCP server:

{
  "mcpServers": {
    "apify": { "url": "https://mcp.apify.com?tools=kantolabs/document-to-markdown" }
  }
}

Sign in once with OAuth, or send an Authorization: Bearer <APIFY_TOKEN> header. Then ask, for example, "convert these three report PDFs to Markdown and summarise the risks section". The assistant passes the links to the actor and reads the Markdown back. Agents with no Apify account can pay per run through Apify's x402 support, using a prepaid token bought with USDC on Base (minimum $1).

Summary

This tutorial was drafted with AI assistance and reviewed by the Kanto Labs team; every code sample was run before publishing.