Can a Beginner Use Two Computers for an 11-Day AI Film?

You can use two computers. Three is not a hardware minimum—it's the optimal efficiency point. The source material states that one person with three computers finished in eleven days; that's a measured reference value, not a hard requirement. The core is that the entire system splits 1,029 shots into enumerable, re-runnable, replaceable records. More machines only speed things up, fewer machines only slow things down—the pipeline itself won't break just because you're one machine short.

Can one computer do it? Yes, but be mentally prepared for twenty-plus days. Based on experience, with 1,029 shots, each going through first-frame generation, last-frame generation, scene synthesis, and image-to-video, running the full sequence serially on a single machine takes roughly three times as long as with three machines. With three machines running in parallel, each handles about 343 shots, finishing in eleven days. If one machine runs start to finish, all 1,029 shots queue up, and a conservative estimate is twenty to twenty-five days. The reference numbers in the source are clear: three computers, eleven days. Scaling back from that, one machine running twenty-five days is not surprising. So one machine can do it, but your timeline stretches to nearly a month, with no major failures allowed along the way. If you just want to test the waters, run a few dozen shots on one machine to feel out the process, then decide whether to add more.

How much difference is there between two and three machines? Based on experience, two machines take about fifteen days; three take eleven—close to linear speedup. Why close but not fully linear? Because task distribution isn't perfectly uniform. Among the 1,029 shots, some are simple and some are complex, and complex shots take several times longer to generate video than simple ones. When three machines grab tasks, the fast ones grab more and the slow ones grab fewer, and total time depends on when the slowest machine finishes its last task. With two machines, theoretically each handles 515 shots, but if one machine gets all the complex shots and the other gets all the simple ones, total time gets pushed past fifteen days by the complex shots. The source says multi-machine parallelism is about grabbing tasks—that word "grabbing" is key. Machines don't split tasks evenly; whoever is free grabs the next pending task from the database. So essentially, the more machines, the more balanced the load, and the closer total time gets to the ideal value.

What needs to change for multi-machine parallelism? Nothing in the database schema. The entire CloudKude system's table design is built for multi-machine parallelism from the start—you don't need to adjust any table structure to add a machine. You just point the database connection to the same database and have both machines run tasks simultaneously. The source emphasizes that the essence of this design is breaking a film into enumerable, re-runnable, replaceable records, with database row locks and state machines naturally supporting multi-machine task grabbing. Specifically, each record in the `dbvideo_process` table has a state field that transitions from pending to in-progress to completed. When two machines run simultaneously, each queries for records in the pending state, and before starting generation, flips the state to in-progress. This prevents the other machine from grabbing the same task. That's the role of state machines plus row locks. So adding a machine just adds another parallel consumer—no table fields need changing.

What should beginners pay special attention to? CRTOR binds uid—don't mix accounts across machines. The source mentions that the large-model channel binds uid via CRTOR, meaning when you call the large model to generate images and videos, the account you use must be clearly specified in the config. If you configure one uid on machine A and another uid on machine B, the visual style generated by the two machines may differ, because different uids can correspond to different channels, quotas, or even model versions. Based on experience, the safer approach is: configure the same uid on both computers for higher style consistency. Some might ask whether the same uid will get rate-limited. In the CloudKude system, the large model is called externally, and rate limiting depends on your account quota, not on how many computers you use. So sharing one uid across two machines is the simplest way to ensure consistent visual style. Another thing to note: `atctoscene` has an idempotency lock and can't be re-run. This step must be executed once on the master machine so that after the storyboard table is generated, both machines can then run the subsequent image generation and video generation simultaneously. If you run `atctoscene` on both machines at the same time, it will trigger the idempotency lock and throw an error—don't ask how I know; it's written plainly in the source material.

Any counterexamples? Yes. Someone ran the same project on two computers, and the second computer immediately ran a wrong script upon startup, resetting the entire `dbvideo_process` table's states back to pending. This caused tasks that the first computer was actively generating to be grabbed and regenerated by the second computer. Both machines generated two videos of the same shot, wasting half the money and machine time. The root cause was failing to correctly understand the state machine semantics: when one machine is generating a certain shot, another machine should not modify that record's state. You only need to ensure that before a task starts, the state is flipped from pending to in-progress, and you don't manually reset states after tasks complete. Based on experience, the most common beginner mistake is seeing a shot fail, manually changing its state back to pending, and then another machine has already picked it up—two processes operating on the same record simultaneously, overwriting each other's results. The correct approach: confirm failure before changing state, confirm the other machine has grabbed the task after the change, then re-run.

So how should the two machines divide the work? No division needed—let them grab tasks on their own. You just start the same task execution program on each computer, and the program will automatically pull pending tasks from the database. One machine might be generating character images while the other generates scene images, with no interference. The same applies to three machines: more machines mean more competition, but each machine does its own thing with no manual coordination. The source says multi-machine parallelism is about grabbing tasks—that description is very accurate. You don't need to care which machine handles which shot; the database's locking mechanism guarantees each shot is processed exactly once by one machine. You just monitor overall progress: the number of rows in the `dbvideo_process` table with state completed divided by total rows is your completion percentage.

What computer specs should you buy? Based on experience, an ordinary consumer gaming laptop is enough—just needs to run Jimeng and a browser. The system doesn't demand high local compute, because the heavy lifting happens on the cloud API side; locally it's just sending requests, receiving results, and writing states. The source mentions drawrole is a Volcengine synchronous direct call, and Jimeng video generation also runs in the cloud. The local computer is more like a remote control—responsible for scheduling, not rendering. So any two computers will do, even one desktop and one laptop, as long as both can connect to the database and the Jimeng account. Based on experience, what actually affects speed is network bandwidth and your Jimeng API account quota, not the computer itself. Rather than agonizing over three machines versus two, first confirm whether your Jimeng account's generation quota is sufficient—quota shortage is the real bottleneck.

What's the next step you can take right now? Run ten storyboards on one machine and time it. From starting the tasks to all ten shots fully generated, record the total time. Then multiply the average time per shot by 1,029 to get the total time for the full film on a single machine. Divide that by two for an approximate ideal time for two machines in parallel. Based on experience, eleven shots of test data is already accurate enough, because per-shot time differences get averaged out over large numbers later. Use that estimate to decide whether to add a second machine—that's more useful than listening to anyone's gut feeling. Remember, three is a reference value, not the standard answer. Your project's actual progress depends only on how many completed records are in your database.