From Script to Final Cut: How Much an AI Comic-Drama Really Installs ​

We · November 2026

This is the third article in the "AI Learning Environment" series. The first two answer the questions before enrollment and in week one: Check This Table Before Enrollment and Five Things That Stall Week One. This one enters the production phase: when a course asks you to hand in a finished piece of video, how much has to be stacked on one machine.

The numbers here come from the system requirements on each app's detail page, the hardware requirements written on our own workflow pages, and measured figures published by upstream projects, compiled in November 2026. They are a reference for judgment, not a promise: models update monthly, and the same clip differing several-fold between machines is normal. This article evaluates no course or institution and makes no claims about earnings.

1. First split "one finished piece" into six stops ​

The thing about comic-drama courses that most distorts judgment is this: it isn't one track, it's the minimum combination of six. A student enrolls in "AI comic-drama", but what has to run on the machine is six different programs, each with its own VRAM, disk and backend requirements. So "can this machine do comic-drama" can't be answered directly; it has to be taken apart first.

Taken apart, it's six stops:

Four things to settle first.

First, the editing step is barely covered here. Premiere, DaVinci and CapCut are closed-source, installed from their own sites; they're in neither our catalog nor our support scope. Their problem is a different kind: timelines and caches eat disk, export eats CPU and memory, but they don't eat the VRAM tier.

Second, the six thresholds aren't spread evenly. A clip's machine requirement is set by stop five, not by the sum of six — however light image and voice are, they don't pull the total down. The moment video enters, VRAM, RAM and disk all rise together.

Third, only two of the six stops justify buying a machine for them. Stop five, and (if the course trains character consistency) the back half of stop two. The value of the other four is being rerunnable on your own machine at any hour, not being fast.

Fourth, and this has to be said up front: this article discusses tools, not work. Install all six stops, pass each one's acceptance check, and what you own is a learning chain that runs end to end — you can see what each stage produces, hand material to the next one accurately, and tell whether a failure is a tool problem or a content problem. That chain is the shortest route for a beginner to understand comic-drama production, but it does not determine the quality of the finished cut. What still makes people watch a piece of video is the old list: script and narrative, the shot language of the storyboard, pacing and space, the emotion in performance and voice, sound design, and the choices made in the edit. That is the work of the course and of the person, not of the VRAM. So this article answers one question throughout — how far can this machine get along the six stops — and what you make once you get there depends on abilities outside the toolset. Specs are an entry ticket, not a passing grade, and mistaking them for a passing grade is the commonest illusion in this class of course.

2. Stop one: script and storyboard ​

This stop has almost no threshold, which is exactly why it gets handled carelessly.

Local chat model pages state memory rather than VRAM: a quantized 7–8B starts on 8GB of RAM, 13B wants 16GB, and larger goes to 32GB — because quantized weights reside mostly in memory. So the answer at this stop is "how much memory", not "is there a card", and a thin laptop walks it. Unified memory on Apple silicon is especially comfortable here; LM Studio simply writes M-series only on the macOS side and relies on unified memory to hold large models.

One thing to flag, which connects to the second article: this stop is the likeliest to look local while actually using the cloud. For some one-click video tools the official main path calls a cloud model to write the copy, an online interface to synthesize the voice, and an online asset library for the footage — the graphics card isn't the point. If your course uses tools like that, "I installed local software" and "my assets stayed on my machine" are two different claims, and it's worth confirming where the copy and footage went before you hand anything in.

Low-spec options: a smaller quantization tier (8B → 3B), a shorter context, or just do this stop in the cloud or on a phone. Storyboard quality depends on what you write, not on how big the model is, so the time saved here belongs to stop five.

3. Stop two: image, which sets the VRAM tier for the whole line ​

Image is the first real threshold in a comic-drama course, and the stop students underestimate in size most often.

The ComfyUI detail page states it plainly: minimum 16GB of RAM; 15GB of disk is enough to try a small text-to-image model, and 100GB or more is advised if you want to use more models; on Windows 10/11 CPU works but compatibility is poor, NVIDIA with 4GB+ VRAM is recommended; macOS 15 or later with an M-series chip required. Inside one comic-drama course those four sentences mean: installing is not the same as running at the number of models the course uses, and between "starts at 15GB" and "100GB or more" sits every weight accumulated across a semester.

At the model layer, what we write on workflow pages is finer than app level: Z-Image asks for more than 12GB of VRAM; the Qwen-Image tier starts at 12GB and only gets comfortable at 24GB; FLUX.2 klein 4B is written conservatively as starting at 12GB against upstream's roughly 13GB; klein 9B and dev are a different tier — the 9B's NVFP4 weights are about 29GB and dev at full precision approaches 90GB, which is unrealistic on an 8–12GB card. Both are called "image", and which model tier you pick moves the VRAM requirement by more than three times. The right question at this stop isn't "can my card make images", it's "the model the class uses — what does the workflow page state for VRAM".

Comic-drama adds a second trap here: character consistency. The same face in panel 1 and panel 20 doesn't come from a bigger card; it comes from training — taking the 20–30 images the course gives you and turning the character into a LoRA. The statement on that matches what the second article said about training: on Windows, upstream documentation gives 8GB as trainable and 10GB as advised, with 32GB of RAM and 20GB+ of disk; on Apple silicon we don't guarantee training will succeed. So many cases of "images come out, the assignment doesn't" are stuck right here.

Low-spec options: drop the tier, not the card — use a distilled/lightweight 4–8 step workflow for samples and reserve the large tier for final delivery; cut the number of characters rather than the number of shots, since several expressions on one character are easier to stabilize than one appearance each for five; and move the training step wholesale to the lab or the cloud, keeping only inference local — the single biggest time-saver at this stop.

4. Stop three: voice, the only stop with an official speed figure ​

Voice is a hard requirement for comic-drama and the friendliest line in this catalog: most voice apps come in a 4GB and an 8GB tier, and lite editions drop the bar once more.

The gap between original and lite should be read off the pages. The IndexTTS 2 detail page states NVIDIA with 8GB+ VRAM, 24GB+ of disk advised, and macOS 15 or later on M-series only; our own release announcement gave a more practical division — 24GB+ unified memory takes the original, 16GB takes the lite edition. The lite edition drops to 4GB (also 4GB for AMD and Intel Arc over Vulkan) and 10GB of disk, installs on a 16GB unified-memory Mac, and on an older Intel Mac runs CPU only at clearly reduced speed. Cheaper still is the Qwen3-TTS lite edition at a 2GB VRAM figure, with Intel Macs on the support list too.

This is also the only stop where we can quote a defensible runtime, because upstream papers publish a real-time factor: IndexTTS 2 measures about 0.326 in fp16 on a 4090, and 2.5 about 0.207 in bf16 on a 4090; GPT-SoVITS publishes 0.028 (4060 Ti), 0.014 (4090) and 0.526 on the CPU of an M4. That last number is the one a student should look at — it confirms that "CPU can produce audio" is true, and that "an order of magnitude slower than a discrete card" is equally true.

Our release announcement carries one more same-machine comparison, tested on an RTX 5060 Ti with 16GB of VRAM: one 159-second Chinese script took the original about 303 seconds (real-time factor 1.9) and the lite edition about 39 seconds (real-time factor 0.25). This is a relative gap measured on one machine, not a promise about yours — the 5060 Ti is a mid-tier card, and a machine with less VRAM and tighter memory slows both tiers, but the direction "lite is an order of magnitude faster than the original" reproduces. What it tells you is practical: at the voice stop, the lite edition buys more than half the disk. It buys whether the piece ships today.

Low-spec options: synthesize long text in segments and stitch them (one-shot generation waits longer and fails more); cut a small sample first to check line pacing, then re-render in batch at the end; when cloning a voice, check the dry source first — if the reference audio has background music in it, no amount of card can recover it.

5. Stop four: subtitles and transcription, the only stop that completes without a GPU ​

Statements here are strikingly consistent: transcription app pages generally read "Intel/AMD CPU usable, NVIDIA GPU recommended", and the macOS column usually reads "supports Intel and M-series chips". Disk sits in the 10–24GB band, with Whisper's large model file itself about 3GB.

It looks the least important and actually sets the rework count: if the dialogue, subtitle timing or timecode in a comic-drama is off by one frame, every later stop has to be redone. So what this stop deserves isn't a graphics card, it's proofreading time.

Low-spec options: generate the initial track with a small model (small/base) and fix it by hand; or hand the stop to an all-in-one translate-and-voice tool like pyVideoTrans, which covers this stop plus part of stop three — the catch is that final quality still needs a human pass.

6. Stop five: making it move — the dividing line of the whole pipeline ​

After four stops you already have a "moving picture with sound". Stop five decides whether it is a video. This is where the threshold jumps hardest, and where Windows and Mac diverge most.

There are genuinely two routes here; don't collapse them into one word.

Route A: build new shots, i.e. image-to-video. ComfyUI video workflows turn a static storyboard frame into a 3–5 second shot. Our three workflow tiers read like this: LTX-2's fp8 quantized tier needs an NVIDIA 30/40/50-series card with at least 16GB of VRAM; the fp4 tier needs Blackwell architecture (50-series) plus torch 2.8.0 or above; the distilled build advises 24GB. On the same line there is the Wan2.2 speech-driven video tier, which we tested on a 16GB RTX 5060 Ti, and whose page states for macOS that "support is still under testing". As for the omni-modal tier (MiniMax H3) text- and image-to-video, its hard requirements are covered under Route B — because in comic-drama that tier is used more often to "make a character speak" than to "build an empty shot".

Route B: make the character move. No new scenes; a character still image mouths words, turns its head and changes expression in time with audio. This line now splits clearly into two generations, a step apart in both requirements and result, and describing them together is the easiest way to make a student choose wrongly.

The previous generation is standalone driver apps: LivePortrait requires NVIDIA with 6GB+, LatentSync 6.5GB+, both around 13–14GB of disk, and both state M-series chips only on macOS; among head-and-shoulder solutions some are written purely by card generation — "NVIDIA RTX 30-series or newer only". Apple silicon runs them, but upstream's own statement is that it may be around 20 times slower than a 4090, and individual modes (LivePortrait's animal mode, say) don't support macOS. The value and the limit of this generation are both concrete: low threshold, fast install, small disk, and it lays the whole chain of "how audio becomes mouth shapes and head motion" open in front of you. But as deliverable it is 2025-generation quality — lip accuracy and expression naturalness have been overtaken by the new generation; fine for practice and for a passing assignment, noticeable as public-facing work.

The new generation, in our catalog, is the MiniMax H3 audio-driven digital-human workflow inside the same ComfyUI — a face-optimized, VRAM-optimized build on the omni-modal route, which is where dialogue and singing go, since both need lip, expression and body rhythm to change continuously. Our position: on the same audio, this tier's lip and expression continuity is clearly one step above the previous generation of drivers; it speaks and it sings — at the cost of every requirement rising together. Hard-coded on our workflow page: Windows only, requires NVIDIA RTX 20-series or newer, 32GB+ RAM advised, weights to be budgeted at the hundred-gigabyte level (about 108GB in full); and if you use its 4-step accelerated build there is one more hard requirement — the SageAttention version supports RTX 40- and 50-series or newer only, and PyTorch 2.10 or higher is mandatory.

One thing to say first: we have not yet written a specific VRAM figure for this tier into the workflow page, only the card generation and memory. So in the table below the H3 column cannot answer "does it run on 8GB" — not evasion; our own statement isn't complete, and we won't guess until it is.

How to pick between the two routes, once by machine and once by purpose:

This section draws conclusions only across NVIDIA tiers. The support surface on AMD and Intel Arc along this line, and how many stops Apple silicon actually reaches, belong to article seven of this series, "It Is Not NVIDIA or Nothing"; this article won't repeat that backend-by-backend list. What stays here is the pipeline judgment: which stop is worth running locally, which stop should move.

One confession is required: at this stop we cannot quote a runtime. Upstream publishes none, and our own measured figures aren't in the workflow pages yet, so this article will not invent seconds. What can be given is an order of magnitude: a 5-second shot does not render in 5 seconds — on a 16GB consumer card, waiting by the minute up to by the ten-minute for a single shot is normal. And in that wait what usually decides your time isn't the card; it's whether there's enough memory, whether the job spilled to disk, and whether that disk is an SSD — which is why the second article's third section insists that a video course must state memory and disk, not just GPU.

Low-spec options (this stop has the most, ordered by value):

1. Cut duration, not quality: 3–5 seconds per shot is already standard practice; don't generate fifteen seconds for the sake of "one continuous take";
2. Walk down the quantization tiers: fp8 → fp4 → distilled, which beats dropping resolution; if the architecture doesn't support fp4, fall back to fp8;
3. Retreat to the previous generation of drivers: roughly a third of the threshold of image-to-video or the new generation, and most shots in a comic-drama only ever need "talking" — get the chain working on the old generation first, then decide whether a few close-ups justify the new one; that order saves time, the reverse doesn't;
4. Reduce the number of shots: replace genuinely new shots with push, pull and pan moves on a still frame;
5. Move the entire stop to the lab or the cloud — this article's clearest recommendation: stop five is the only one of the six where grinding it out locally doesn't pay. Do the previous four stops locally and batch stop five in the lab, which is the most common sensible division among students.

7. Stop six: music, sound effects and assembly ​

This stop is bigger than it matters. Its disk statement comes in two kinds: the ACE-Step 1.5 detail page reads "10GB+ of disk advised, Windows needs NVIDIA with 8GB+ VRAM, macOS on M-series only", while the sound-effect-tagged Stable Audio 3 tier reads "31GB+ advised", with CPU usable on Windows and Intel and M-series both supported on macOS. Both "add a piece of music", and one eats VRAM while the other eats disk — worth reading both pages before choosing. Sound effects and BGM can also stay off the machine completely via a stock library, at the cost of needing traceable asset provenance.

For the assembly cell we list no app, because that's normally the editor's job. The one thing worth raising is export: final export consumes CPU, memory and sequential disk writes, not the GPU's VRAM tier. Many people read a slow export as "my card is no good" when the disk is actually full.

Low-spec options: one BGM for the whole piece plus a few effects, rather than scoring every shot; export a low-bitrate preview first to lock the pacing, then do one high-quality export at the end; if asset libraries live on a spinning disk, move the weights and intermediates to an SSD first and export speed returns to normal.

8. Add the six stops up: how far does this machine get ​

Now the title question can be answered. "How much does one comic-drama install" gives two completely different numbers when you add up the detail pages and workflow pages:

That three-to-four-fold gap in between comes entirely from accumulating models and from stop five. Reading the four machine classes against this table:

An 8GB-VRAM Windows desktop (the commonest tier of class one): the first four stops run at course pace; the mainstream large image tier starts to strain (that 12GB cell pushes back); stop five works only with previous-generation drivers or reduced-tier generation, and on the new-generation line at 8GB we give no conclusion. Conclusion: you can make comic-drama, but not the newest large-model shots the course shows.

Windows with 16–24GB of VRAM: the whole line runs locally, including image-to-video and audio-driven digital humans. This is the only class you can plan as a complete pipeline, at the cost of reserving disk at the 300GB level and not going below 32GB of RAM — the new generation's weights and intermediates are where that scale comes from.

An Apple-silicon Mac (16/24/32GB unified memory): stops one through four are comfortable, and voice and transcription have the widest support here. Stop five splits in two: drivers run but official figures say an order of magnitude slower, image-to-video support is stated on the page as "still under testing", and the omni-modal tier has no Mac path at all. Conclusion: a Mac is a good machine for cutting and handing in, not for producing shots at volume — when you need shots, move that stop to the lab.

An older Intel Mac, or a thin laptop with no discrete GPU: stops one and four complete fine, stop three has a 2GB tier to fall back on, stop two is small-models only, and stop five basically has to move. This class suits learning the method and does not suit delivering work, and that should be said clearly before enrollment.

One last line that goes beyond the table: all four tiers above complete part of the six stops, and no spec writes your script for you. What is genuinely scarce in comic-drama is narrative, shot language, pacing, performance and sound design — those belong to the course and to you; this table's only job is to fill the "tool" cell accurately.

9. Install in order, and accept each stop once ​

The most expensive mistake in a pipeline-type course is installing all six apps at once: when something fails you don't know which stop, and the rework is six times over. Installing stop by stop and running one minimal sample per stop is the week-one method applied here.

The recommended order and acceptance checks:

1. Install stop one first (local chat) and generate one 200-character storyboard — the lightest stop, useful to confirm the machine is basically working;
2. Stop two, ComfyUI: render one 512×512 on the bundled small model, then switch to the workflow the course specifies. If it reports a missing node, add that node by name — don't install thirty at once;
3. Stop three, voice: get ten seconds of Chinese to speak, then export the reference audio the course asks for. Being able to produce audio and being able to produce it today are two different things, and this is where you choose original or lite for your machine;
4. Stop four, transcription: produce a subtitle track from one minute of audio and check the timecode;
5. Install stop five last, and install only one workflow first: generate 3 seconds from a single still, confirm it renders and time it once — that figure becomes the scheduling basis for the whole piece;
6. Stop six, music: generate a 30-second BGM and export one low-bitrate cut, confirming the chain really runs from script to finished piece.

The order itself isn't inevitable, but one lesson is worth writing down: put stop five last and use its single-run time to work backwards into your assignment schedule. The waits at stops one through four can't ruin an assignment; the wait at stop five can.

Three general reductions that apply to all six stops:

• Drop the tier, not the card: within one stop, moving from a large model to a distilled or quantized tier costs far less than buying a machine;
• Cut quantity, not quality: fewer shots, fewer characters, fewer music cues — rather than degrading every shot into mush;
• Move training up front, off-machine: LoRA and voice cloning write files, so they go to the lab or the cloud, leaving inference local — the stop with the highest failure cost is the one least suited to being endured on an untested machine.

10. Our view ​

First, on a machine "comic-drama" is not one track; it's an ordered line. Asking about specs by track yields a table; asking by pipeline yields a list — and only the list lets someone compute their disk and their rework count before enrolling. It's also why we'd rather write requirements onto workflow pages than state one vague threshold for a piece of software.

Second, stop five should be openly described as "this one doesn't have to happen on your machine". The usual practice today is promising the entire pipeline locally, and the result is students stalling at stop five and queueing in the support channel. Saying clearly which stop is worth local time and which can borrow a machine is far more responsible than promising that everything runs. The by-step table in section six of the second article is most useful at this stop.

Third, what the six stops consume isn't VRAM; it's disk and time. Across the applications we've compiled, VRAM figures cluster in the 4GB and 8GB tiers, so the threshold looks modest. What actually defeats people is models accumulating into the hundreds of gigabytes, and a ten-minute wait for a three-second shot. Neither has a solution as simple as "buy a better card" — only tier reduction, quantity reduction and a correct division of labor.

Making one piece from start to finish tests whether this machine can go six rounds without an incident. If any one of the six stops jams, all the work is still on the drive and none of it can be handed in. So the next article moves to the institution's side of the desk: how to explain this whole chain of thresholds clearly in one pre-enrollment conversation.

Disclaimer: The configuration statements in this article come from the system requirements on each app's detail page, the hardware-requirement copy on our workflow pages, and upstream projects' public documentation, compiled by us in November 2026. The combined disk and VRAM figures are order-of-magnitude estimates obtained by adding those published statements together, not measurements of any specific device. Model and software versions update monthly and requirements may change; nothing here guarantees that any app will run, deliver, or finish on time on your device. This article evaluates no training institution or course and makes no earnings or monetization claims.