Running MiniMax H3 Without a Big GPU: I Turned “Borrow a Colab Card, Give It Back When Done” Into a Public Repo

If water is not deep enough, it cannot float a large boat.
Pour a cup of water into a hollow in the floor and a mustard seed will sail on it; set the cup itself there and it sticks fast. The water is shallow and the boat is large.
—— Zhuangzi, “Free and Easy Wandering” (Warring States period); translation mine

This month I packaged my method for borrowing Google Colab GPUs to run the MiniMax H3 video model into a public repo, colab-gpu-runner: https://github.com/bockybocky/colab-gpu-runner . A single command on your own computer borrows a G4 with 96GB of video memory, turns one photo into a short clip with sound, upscales it 1.5×, fills it out to 48 frames per second, and hands the machine back when it is done. In my October 2026 runs, a 5-second clip took about 9–10 minutes from boot to release and used roughly 1.2 compute units. You need a paid Colab plan, since the free tier won’t hand out cards this size, and the setup suits people who make a few clips now and then. If you generate video all day, other routes will serve you better.

Why it exists: a friend wanted to try, and he has no big card

H3’s two-stage generation peaks at about 52GB of video memory. I mentioned that number in my earlier post on running MiniMax H3 in Colab. It is far beyond the 8GB or 12GB on a home card, and beyond the 24GB cards a lot of people rent in the cloud.

A friend read that post and wanted to try it himself. That is when I noticed my setup lived in several scripts with paths hardcoded to my own machine. So I cleaned it up, added docs and a check script, and published it. Below I make the best case I can for borrowing Colab cards to run H3, then switch sides and attack it.

For: no card to buy, no machine to babysit, the biggest card on one command

What it does is simple. On your computer you prepare a photo and one line describing the scene, and package them into a script meant to run in the cloud. The launcher borrows a GPU machine from Colab, installs ComfyUI (an open-source tool that wires models together as a node graph), downloads the models from Hugging Face, and runs three steps: MiniMax H3 generates a clip with audio, SeedVR2 upscales it 1.5×, and RIFE interpolates it from 24 to 48 frames per second. The results go to your own Google Drive, the machine is released, and your computer downloads the files and compares each one’s SHA-256 hash, so you know what arrived matches what was uploaded.

You get three videos: the raw generation, the upscaled version (768×1344 up to 1152×2016), and the 48 fps version. There is also a de-shine switch. By default it loads two add-ons that give skin a more matte look; pass --no-deoil when packaging if you don’t want them.

I see three real strengths.

First, your computer needs no GPU. The card is borrowed, and your machine only sends commands and receives files. An ordinary laptop is enough.

Second, the card is large, and the job checks it. On October 19, 2026 I ran the same test script on both: the G4 did about 423 TFLOPS of bf16 matrix multiplication against roughly 268 on an 80GB A100, so about 1.6× faster. The remote script reads the card’s memory before doing anything else and stops if it finds less than 75,000 MiB, so you never pay for half a run on a card that was never going to finish.

Third, the way files come back was fixed the hard way. Until October 20, 2026, results were base64-encoded, printed into the log, and stitched back together locally. For a three-clip job that added about 30 minutes, and the machine was billing the whole time. Once I switched to uploading to Drive and downloading afterward, that wait mostly disappeared.

Time and cost, measured on a G4 in October 2026: a 5-second clip takes about 9–10 minutes and 1.2 units; 10 seconds about 17.5 minutes and 2.1 units; 15 seconds about 24 minutes and 3.1–3.4 units. Downloading the models straight from Hugging Face takes about 3 minutes, much faster than the roughly 22 minutes it took when I copied them from Drive.

Which card to ask for

Go for the G4 first. Colab’s documentation doesn’t say what card the G4 actually is; the machine I got reported an RTX PRO 6000 Blackwell with 96GB.

Installing it, in order

The repo includes check_env.py. It only reads: it installs nothing, starts no machine, and costs nothing. Each item prints pass or fail, with a fix for anything that fails. I’d run it first:

python check_env.py

Then install in this order:

# 1. Install the Colab command line
uv tool install google-colab-cli

# 2. Install gog (a Google Drive command line; see github.com/openclaw/gogcli) and sign in with your own account

# 3. Log in to Colab (once): print a URL, open it on your phone, paste the code back
$PY = "$env:APPDATA\uv\tools\google-colab-cli\Scripts\python.exe"
& $PY colab_login.py url
& $PY colab_login.py code <auth-code>

# 4. Try a card first (about 1 minute)
colab run --gpu G4 g4_probe.py

# 5. Package the job, then run a smoke test that skips generation and only checks Drive upload/download
python film/build_remote_job.py --image start.png --prompt "a woman smiles and waves at the camera" --out-dir ./job
pwsh film/run_g4.ps1 -Root ./job -GoogleAccount <your-google-account> -SmokeTest

# 6. The real run
pwsh film/run_g4.ps1 -Root ./job -GoogleAccount <your-google-account>

Two things the instructions won’t tell you.

The Colab command line officially supports only Linux and macOS; its own page says Windows is not supported. I installed it with uv on Windows and it works, but if a future release breaks on Windows, nobody owes you a fix. The tool itself needs Python 3.12 or newer, which uv brings along on its own; that’s separate from the 3.10 the repo’s scripts need.

The other one: it installs and then can’t be found. uv puts colab in .local/bin under your user folder, and that folder often isn’t on the system path. On October 27, 2026, while writing the check script, I ran it on my own laptop and the very first line said it couldn’t find the colab command, even though I had installed it. I had just removed the hardcoded paths for the public version, and the first person to trip over that was me. The check script and launcher now look in that folder themselves. If typing colab by hand does nothing, look there before you reinstall.

Five ways to get a GPU, side by side

Every number here is one I measured or wrote about in earlier posts. Cells I haven’t measured say so.

The vast and RunPod details are in my vast rental notes and the rent-or-buy post.

Against: when you borrow, someone else writes the rules

Now the other side, argued as hard as I can.

Everything hangs on one Google account. The card comes from Colab, the outputs land in the same account’s Drive, and the login tokens sit there too. If that account is ever suspended or its permissions revoked, the whole route goes down at once, and there is no second provider to switch to.

The billing unit can change, and the rules aren’t published. Colab’s FAQ says plainly that the GPU types on offer, usage limits, idle timeouts, and maximum machine lifetime all change over time and aren’t disclosed. The pricing page only shows up after you sign in. My “about 1.2 units” is an October reading and may not hold next month.

A machine left running keeps billing. If the local process watching the job dies, the cloud machine doesn’t shut itself down. The launcher checks for leftover machines on the way out, but if your computer crashes or loses its connection, that cleanup step never runs.

You may not get a card. G4 and A100 depend on what’s free at the moment, and landing a 40GB A100 means getting rejected and starting over. On the day you’re racing a deadline and nothing is available, you wait.

The model licenses need reading line by line. MiniMax H3’s community license (the August 2, 2026 version) is royalty-free, but the EU, the UK, South Korea, and the US are outside its territory; products with more than $20 million in yearly revenue need separate written permission; commercial products must prominently display “MiniMax H3” in their interface; and you may not use the model or its outputs to improve any other AI model. The two de-shine add-ons follow H3’s license. SeedVR2 and the latent upscaler are Apache-2.0, and the frame interpolation add-on is MIT. The repo’s own code is MIT, but complying with the model licenses is on you.

Your data goes to the cloud. Your starting photo is packed into the script and sent to the remote machine, and the launcher passes your Drive refresh token and OAuth client secret into that machine as environment variables so it can upload the results. None of that is written into the script or the logs, and the machine is released when the job ends. Still, while it runs, those things sit on a computer that isn’t yours.

Last, every run starts cold. Each time you borrow a card, ComfyUI gets reinstalled and every model downloaded again, about 3 minutes spent before any real work. If you want to tweak settings and watch results as you go, starting from zero every time gets old fast.

Which side holds up: how often you run it, and what you feed it

Both sides are right. Three conditions decide between them.

Frequency. If you make a few clips now and then, the case for wins: no card to buy, no machine to maintain, around 1.2 units per clip, far cheaper than buying a 96GB card. If you run it heavily every day, the shifting rules and cold starts will keep biting, and renting a machine that can keep persistent storage, or seriously pricing out a card of your own, is the steadier path.

Content. With your own photos and no commercial plans, the privacy and licensing risks stay manageable. If you’ll use other people’s faces, take paid work, or live in an excluded territory, read the license before you start.

Tolerance for borrowing itself. For urgent work that can’t wait, don’t make a borrowed card your only route.

Who it suits: people who want to run large video models, don’t own a big card, already have or are willing to get a paid Colab plan, and make clips occasionally. Who it doesn’t: people on the free tier only (no cards this size there), people who need to tweak and watch in real time, and people uneasy about their photos going to the cloud.

If you’re in the first group, the repo is here: https://github.com/bockybocky/colab-gpu-runner . Run check_env.py first, then the smoke test, and only then a real generation. That order will save you a fair amount of money.

Raw Markdown