# MiniMax H3 Max vs Fast H3: building a 24/7 channel now that video generates faster than it plays > In August 2026 the time it takes to produce a second of video dropped below the time it takes to watch one. That should make an always-on AI channel trivial, and it does, but not for the reason usually given and not by the method most people try first. ## The moment it flipped MiniMax released H3 on 31 July 2026. Hailuo 3.0, if you follow the consumer branding. It takes text, images, video and audio in one context and returns up to 15 seconds of 2K video with stereo sound generated in the same pass, and it shipped with open weights on day one. Good model. Not the thing that changed. What changed arrived four weeks later, twice in three days. On 26 August fal shipped **H3 Max**, a post-trained version of H3 tuned for prompt adherence and wired into fal's own inference stack: five seconds of 768p video in under three seconds, about 35 times the throughput of the official endpoint. On 28 August the Hao AI Lab at UCSD open-sourced **Fast H3**, a four-step distillation of the same base model that does 15 seconds in 15.5 on four B200s. You can download that one. The two teams spent the rest of the week arguing on X about who was faster. Not the useful question. The useful distinction sits underneath it: one of these models is fast and closed, one is fast and open, and the third is slow but does things neither of the others can. Pieter Levels built [Infinite Slop](https://infiniteslop.ai/) on H3 Max, an endless AI channel where the chat picks what airs next and the model tries to connect each clip to the one before it. 37,000 people watched. His summary of why it works is the sentence this article is about: > You can now generate AI video faster than you can watch it. If that holds, a 24/7 channel stops being a content problem and turns into a plumbing problem. One process generates, one broadcasts, the generator never falls behind, and you get television with no library behind it and nothing repeated in it. Nothing like that has existed before. It does hold. It is also the wrong thing to build for almost any channel you would actually want to run, and the arithmetic is not close. ## What the three-second figure measures "Under three seconds for a five-second clip" is a real number. It is also a *denoiser* number: it is what lands in `timings.inference` in the API response, and fal quotes about 2.5 seconds of it for a 5-second 768p generation. It describes the model. It does not describe the pipeline. Around that model sit three things that are not the model. Prompt expansion comes first. H3 Max rewrites your prompt before it generates anything, and the mode you pick decides how long that takes: `balanced` is about a second, `quality` is up to thirty. On a five-second clip that turns a three-second job into a thirty-three-second one, an eleven-fold swing with nothing to do with video, and it is easy to leave switched on by accident. Then the queue, because fal is queue-first: requests sit in `IN_QUEUE` until a runner frees up, and only `IN_PROGRESS` ones count against your concurrency limit. Then the file itself, several megabytes of MP4 on `v3b.fal.media` that has to be muxed, written and fetched. > **What we measured.** Running `minimax/h3-max` from our own tooling against the public API, a five-second 768p clip takes **60 to 120 seconds end to end**, per request, wall clock. Not three. About 2.5 seconds of that is the denoiser. The rest is queue, expansion, encode and transfer. Size your capacity on the number you can measure from outside. None of which is a knock on fal. Two and a half seconds of denoising for five seconds of 768p video with synchronised stereo is a remarkable thing to be able to buy, and the queue is what keeps it cheap. Treat it as a capacity-planning warning instead. Size a 24/7 channel on the three-second figure and you will come up short by a factor of thirty. ## Real throughput: what one slot gives you Call it 90 seconds end to end for a five-second clip. One concurrency slot then turns out five seconds of finished programming every 90, which works out to 0.056 times real time: about three minutes twenty per hour, or 80 minutes a day flat out. Now change the clip length and watch what happens. Ask for 15 seconds instead of 5. Same price per second. The denoising scales with duration, roughly 15 seconds of inference for a 15-second clip by fal's own figure, but the fixed overhead does not scale at all. Queue wait, prompt expansion and transfer cost the same either way. Spread that overhead across three times the output and the numbers move: | Clip length | fal inference | End to end, observed | Output per slot per day | Real-time factor | Cuts per broadcast hour | | --- | --- | --- | --- | --- | --- | | 5 s | ~2.5 s | ~90 s | ~80 min | 0.056× | 720 | | 10 s | ~10 s *(interpolated)* | ~120 s | ~2 h | 0.083× | 360 | | 15 s | ~15 s | ~150 s | ~2 h 24 min | 0.10× | 240 | > **Generate 15-second clips, not five-second ones.** Same price per second, about 1.8 times the daily output from the same slot, a third of the cuts. There is nothing to trade off here. Longer wins on every axis at once, and the only reason to ask for five seconds is if you want the jump-cut look. Concurrency is the other lever, and it is the one you buy rather than tune. fal hands out somewhere between 2 and 40 parallel `IN_PROGRESS` requests depending on how much you have spent, and anything over that limit queues instead of failing. At 15-second clips and 150 seconds a request, matching real time (24 hours of programming per 24 hours of clock) takes ten slots. With five-second clips it takes eighteen. So Levels is right. You can generate faster than you can watch. You just have to be near the top of fal's concurrency tiers to do it, and then the bill arrives. ## The bill for generating 24/7 live Billing is per generated second, so a day of continuous original programming is 86,400 billable seconds however you slice it into clips. At [fal's H3 Max list pricing](https://fal.ai/minimax-h3-max): | Resolution | Per second | Per broadcast hour | Per day, 24/7 original | Per year | | --- | --- | --- | --- | --- | | 480p | $0.05 | $180 | $4,320 | ~$1.58 M | | 768p | $0.08 | $288 | $6,912 | ~$2.52 M | | 2K *(H3, not Max)* | $0.13 | $468 | $11,232 | ~$4.10 M | Two and a half million dollars a year to originate one 768p channel nobody has watched twice. That is more than most real broadcast networks spend acquiring an entire schedule, and a network gets to re-air what it buys. > **Check the price before you plan around it.** fal ran H3 Max at half price from launch, $0.025/s at 480p and $0.04/s at 768p, until 1 September 2026. A promo is a reason to run experiments this week. It is not a reason to model a business, so every figure here uses list price. fal prices standard H3 on a different scale again ($0.06/s at 768p, $0.13/s at 2K, $0.16/s at 4K), and MiniMax's own API differs from both. Re-check the model page before you commit money to any of it. ## What a linear channel needs instead The "faster than you can watch it" framing carries an assumption it never states: that every second of broadcast needs a fresh second of generation. It does not, because a linear channel loops. That is what makes it linear. Sessions run in minutes, the audience turns over constantly, and nobody is sitting there at four in the morning keeping score of what already aired. Repetition is not a flaw in the format. It is the format. Every FAST channel on every connected TV platform works this way, and so did every music-video channel that ever existed. Accept that and generation stops being a running cost and becomes a capital one. You pay to produce a library once. Re-airing it is free. | Library | Generated seconds | Cost at 480p | Cost at 768p | Time to build, 1 slot | Cost to re-air | | --- | --- | --- | --- | --- | --- | | 15 min *(launch floor)* | 900 | $45 | $72 | ~2 h 30 | $0 | | 1 hour | 3,600 | $180 | $288 | ~10 h | $0 | | 2 hours | 7,200 | $360 | $576 | ~20 h | $0 | | 6 hours | 21,600 | $1,080 | $1,728 | ~2.5 days | $0 | One hour of 480p costs $180 and never runs out. That is the real price of putting a 24/7 AI channel on air. Add a refresh, say ten fresh minutes a day at 600 seconds and $30, and the channel is never quite the same twice while costing under a thousand dollars a month. | Architecture | Set-up | Per month | Concurrency needed | Viewer can tell? | | --- | --- | --- | --- | --- | | Generate live, 24/7 | $0 | $129,600 *(480p)* | 18 slots, sustained | No | | 1 h library + 10 min/day | $180 | $900 *(480p)* | 1 slot | No | | Library only, no refresh | $180 | $0 | None after build | Eventually | > **Live generation costs about 144 times as much for a difference nobody watching can see.** Spend that only when the generating is itself the show. Infinite Slop generates live because the chat steers what comes next, so the liveness is the product and fal covers the compute. A channel nobody is steering gets nothing back for the money. ## H3 vs H3 Max vs Fast H3 The naming is confusing, and getting it wrong costs you either money or a weekend. Three models, one base, three different bargains. **MiniMax H3** is the original: 33B parameters, omni-modal, open weights. The only one that reaches 2K and the only one with reference and editing endpoints. On its own, slow. **H3 Max** is fal's post-training of H3, co-optimised with fal's inference stack. Fastest, best-rated, and closed. It lives behind fal's API and nowhere else. It stops at 768p because MiniMax released the 768p weights and not the 2K ones, so there was nothing at 2K for fal to post-train. **Fast H3** is FastVideo's, out of the Hao AI Lab at UCSD with Nuva Lab and NVIDIA's FastGen team. A four-step DMD2 distillation that swaps H3's 49 transformer forward passes for 4 and adds 90% sparse attention, worth up to 14 times the base model's speed on Blackwell. Open weights, which makes it the fast one you can put on hardware you own. "Max" here means faster rather than bigger, which is backwards from the convention everywhere else and explains most of the confusion. | | MiniMax H3 | H3 Max (fal) | Fast H3 (FastVideo) | | --- | --- | --- | --- | | Who made it | MiniMax | fal, post-trained on H3 | Hao AI Lab / UCSD, distilled from H3 | | Resolution | 768p, 2K (4K on fal) | 480p, 768p | 768p | | Duration | 4 to 15 s | 5 to 15 s | 5.167 to 14.375 s | | Native stereo audio | Yes | Yes | Yes | | Reference inputs | 9 images, 3 videos, 3 audio | First frame, first-and-last frame | None, text-to-video only | | Editing endpoint | Yes | Not at launch | No | | Open weights | Yes | No, fal API only | Yes | | Self-host speed | 0.10× real time (4×B300) | n/a | 0.97× real time (4×B200) | | Quality | Baseline | Rated above base H3 | Below base H3: 45% preferred it or were neutral | | Price to use | $0.06/s 768p, $0.13/s 2K (fal) | $0.05/s 480p, $0.08/s 768p | Free, you supply the GPUs | Look at the price row. On fal, standard H3 at 768p is cheaper per second than H3 Max at 768p. The premium buys latency and prompt adherence, not pixels. > **For a channel the answer is almost always H3 Max.** Reach for standard H3 where the extra capability pays for itself: a 2K title sequence, a recurring character built from nine reference images, an edit against footage you already have. Reach for Fast H3 only if you have Blackwell hardware sitting idle and you are outside the excluded territories. Both conditions are covered below. ## Running it on your own hardware ### What you can install Two of the three. H3 and Fast H3 ship open weights. H3 Max does not: it is fal's post-training on fal's inference stack, so there is no checkpoint to download and no ComfyUI node, and no amount of hardware changes that. If what you want is the fastest H3 running on your own machine, the answer is Fast H3. ### Option A: MiniMax H3, the accessible one H3 is a 33B-parameter dense single-stream transformer, about 13B of which sits in AdaLN-related branches that never load at inference. Full precision comes to 123.6 GB. The community pruned the modulation weights, roughly 40% of the parameters, into an equivalent lookup table; with int8 quantisation on top, that cuts the working set by about two thirds. | File | Size | Needed for | | --- | --- | --- | | fl2va, pruned int8 | 20.97 GB | Text- and image-driven generation | | ref2va, pruned int8 | 20.97 GB | Reference-driven generation | | Text encoder, 4-bit AWQ | 15.69 GB | Every workflow | | Video VAE | 5.21 GB | Every workflow | | Audio VAE | 0.61 GB | Audio generation | | **One task, smallest** | **42.5 GB** | A working channel pipeline | | Both checkpoints | 63.4 GB | Text and reference workflows | | Full precision BF16 | ~135 GB | Research only | ### Hardware for MiniMax H3 | Tier | VRAM | Configuration | Verdict for a channel | | --- | --- | --- | --- | | Experimental | 8 to 12 GB | Heavy quantisation plus aggressive offload | Too slow to build a library | | Workable | 16 GB | Quantised, dynamic VRAM offload, 64 GB system RAM | Overnight builds only | | Practical | 24 to 32 GB | Single card, ComfyUI 0.30.0+ templates | The realistic home setup | | Two-GPU | 2 × 24 to 32 GB | vLLM `--enable-distributed-layerwise-offload` | Faster, more moving parts | | Reference | 4 × 80 GB | 4×B300 or GB200, vLLM 0.26+, Ulysses SP4 | What MiniMax benchmarks on | ComfyUI 0.30.0 and up has day-0 templates and dynamic VRAM offloading, and it is the easy path. vLLM 0.26.0 and up with `--omni` is the serving path. SGLang and diffusers both work. ``` # The minimum useful download: one task, quantised hf download MiniMaxAI/MiniMax-H3 \ --include "model_index.json" "FL2VA/*" \ --local-dir MiniMax-H3 # Serving it, on the 4x80 GB reference configuration CUDA_VISIBLE_DEVICES=0,1,2,3 \ VLLM_WORKER_MULTIPROC_METHOD=spawn \ vllm serve /path/to/MiniMax-H3 \ --omni --host 0.0.0.0 --port 8000 \ --trust-remote-code \ --num-gpus 4 --usp 4 --ring 1 \ --vae-patch-parallel-size 4 \ --vae-parallel-mode tile --vae-use-tiling ``` ### How fast plain H3 really is On the reference configuration, four B300s and roughly a quarter of a million dollars of hardware, MiniMax's published vLLM benchmarks look like this: | Workload | Output | Wall clock | Real-time factor | | --- | --- | --- | --- | | FL2VA | 8.7 s @ 1248×768 | 86.96 s | 0.10×, or 10× slower than real time | | Ref2VA | 15 s @ 1344×768 | 784.4 s | 0.019×, or 52× slower than real time | Ten to fifty times slower than real time, on hardware most people will never touch. One report puts the unoptimised base model at over 17 minutes for a five-second clip on a single RTX 5090, which is 0.005 times real time. Speed is not what self-hosting plain H3 buys you. It buys zero marginal cost per second, and it removes the rate limit, the queue and the per-clip bill. Once you have accepted that a channel loops, that is exactly the trade you want. A single 24 to 32 GB card grinding away overnight builds a library it will then re-air for years. Being slower than real time does not matter when you are not broadcasting what you are generating. ### Option B: Fast H3, the fast one you can download Fast H3 is what taking the speed problem seriously looks like. FastVideo distilled H3 down to four transformer forward passes instead of 49 using data-free DMD2, layered 90% sparse attention on top, and spent over a thousand B200 hours training it. The result is a 35B safetensors checkpoint that behaves like H3 and runs about 14 times faster on Blackwell. | Clip length @ 1344×768, 24 fps, with audio | 1 × B200 | 4 × B200 | Real-time factor, 4×B200 | | --- | --- | --- | --- | | 5 s | 16.2 s | 6.1 s | 0.82× | | 10 s | 31.1 s | 12.0 s | 0.83× | | 15 s | 47.2 s | 15.5 s | 0.97×, parity | Four B200s put you on the real-time line at 15-second clips. Eight cross it: FastVideo reports sub-real-time generation on 8×B200. Same claim fal makes for H3 Max, except on weights you own instead of an API you rent. It is also, again, an argument for 15-second clips over five-second ones. | Requirement | Fast H3 Preview v1 | | --- | --- | | Weights on disk | 147.9 GB: transformer 70.1, text encoder 66.7, video VAE 10.4, audio VAE 0.6 | | VRAM | Enough for a 33B transformer plus a Qwen3-VL text encoder, so realistically a multi-GPU node or one high-memory data-centre card | | GPU count | Must divide H3's 56 attention heads (1, 2, 4, 7, 8 and so on). 4×B200 is the tested default | | GPU family | Blackwell for the 14× figure, since the sparse-attention kernels target it | | Runtime | FastVideo's own VSA-H3 backend, not a drop-in ComfyUI checkpoint | | Tasks | Text-to-audio-video only. FL2VA and Ref2VA were not distilled | | Quality | Below base H3: 45% preferred Fast H3 or were neutral. Difficult motion, fine detail and some audio degrade | | Licence | `minimax-h3-community`, inherited verbatim, Excluded Territories and all | ``` # Fast H3 runs through FastVideo's stack, not ComfyUI python examples/inference/basic/basic_fasth3.py \ --model-path FastVideo/FastVideo-FastH3-4-step-Preview-v1-VSA-DataFree \ --prompt "your prompt" \ --no-warmup --repeats 1 ``` Before you commit a GPU budget, try it for free. FastVideo runs a Hugging Face ZeroGPU Space: an account, a prompt, and nothing to install. Because it is a hosted demo rather than local weights, it works from the excluded territories too. ### So which one do you install? | Your situation | Install | Why | | --- | --- | --- | | One 24 to 32 GB consumer card | MiniMax H3, ComfyUI | 42.5 GB download, works, slow. Build the library overnight | | A Blackwell node (4 to 8 × B200) | Fast H3 | Real-time parity at 15 s clips, zero marginal cost | | You want the best output | H3 Max, via fal | Cannot be installed at all | | You want reference images or 2K | MiniMax H3 | The only variant with Ref2VA and 2K | | You are in the EU, UK, US or Korea | None of them, locally | Use the hosted APIs. See below | > **The licence probably stops you, and it stops both open models.** The MiniMax H3 Community License defines its Applicable Territory as "worldwide, excluding the Excluded Territories", and those territories are the European Union, the United Kingdom, the Republic of Korea and the United States of America. In those four regions you are not licensed to use, modify, distribute or host the open weights, or their outputs, without separate written authorisation from MiniMax. Fast H3 inherits the licence word for word: its model card is tagged `minimax-h3-community` and points you at the territory terms. Distilling the model did not launder the restriction. Everywhere else, commercial use is free below $20 M in annual revenue as long as you display "Powered by MiniMax H3" on the product. > > This is a weights licence, not a service one. The hosted routes stay open everywhere, including in the four excluded regions: fal's API, MiniMax's own API, and FastVideo's Hugging Face Space. So if you are in the EU, the UK, Korea or the US, treat this whole section as background reading. You will use an API, and the model will be H3 Max. MiniMax does grant authorisation on request, citing "MiniMax H3 licensing", but that is a contract negotiation rather than a download. None of this is legal advice. Read the licence. ## The pipeline, end to end Five stages. Only the first is about AI. 1. Generate: submit prompts to `minimax/h3-max/text-to-video` through fal's queue, N at a time. 2. Collect: each finished job returns a direct, public, unauthenticated MP4 URL on `v3b.fal.media`. 3. Import: hand that URL straight to a channel, with nothing downloaded and nothing re-uploaded. 4. Transcode: every clip gets normalised onto one HLS ladder so the joins play. 5. Schedule: weights and rules turn a pile of clips into a 24-hour grid that repeats. The join between stage 2 and stage 3 is what makes this pleasant. fal returns a public URL and My TV Channel's `import_video_from_url` takes a public URL, so nothing touches your disk: ``` import asyncio, fal_client from mytv import client # your Bearer mytv_sk_... wrapper CHANNEL = 42 SLOTS = 4 # fal grants 2 to 40 by credit history PROMPTS = [ "A slow aerial push over a neon-lit rain-soaked Tokyo alley at night, " "steam rising, reflections in puddles, cinematic, ambient city hum", # ... one line per programme ] async def make_one(prompt, sem): async with sem: # respect the concurrency limit res = await fal_client.subscribe_async( "minimax/h3-max/text-to-video", arguments={ "prompt": prompt, "duration": 15, # 15, not 5. See above "resolution": "768P", "aspect_ratio": "16:9", "prompt_expansion_mode": "balanced", # "quality" costs ~30 s per clip }, ) # Public, unauthenticated, direct MP4: exactly what the importer wants. asset = client.import_video_from_url( channel_id=CHANNEL, url=res["video"]["url"], title=prompt[:60], tags=["ai", "night", "seq"], weight=5, ) return asset["id"] async def main(): sem = asyncio.Semaphore(SLOTS) await asyncio.gather(*(make_one(p, sem) for p in PROMPTS)) asyncio.run(main()) ``` Four constraints will shape whatever you build around that, and all four are cheaper to design for than to discover. The importer takes 20 queued imports per account, so pair that ceiling with your fal concurrency limit. There is no point feeding 40 fal slots into a 20-slot importer. Set each clip's weight the moment it reports ready, rather than at the end of the batch. A channel launches on its own the instant it crosses four ready assets and fifteen minutes, and the schedule gets built from whatever weights exist at that moment. Anything you set later is stored but never airs. Changing weights on a live channel does nothing until you regenerate. `schedule/regenerate.php` rebuilds the schedule, throttled to once per channel every five minutes. Retire clips rather than deleting them. Weight 0 pulls a clip out of rotation and keeps it available, while deleting cancels any running transcode and forces a regeneration. The whole loop runs unattended from an agent. Every call above exists as an [MCP tool](https://my-tv-channel.com/agents/), so "generate twenty new night-time clips, import them, weight the good ones and rebuild the schedule" is one instruction instead of a cron job you have to maintain. ## Four things that bite ### 1. The audio restarts every clip H3 generates its stereo per clip: its own score, its own foley, its own ambience, each one starting from silence and ending in silence. Cut five-second clips back to back and you get a fresh piece of music every five seconds, 720 times an hour. It is the most fatiguing thing about naively assembled AI channels, and it is self-inflicted. Three fixes, cheapest first. Generate 15-second clips so the restart lands a third as often. Prompt for ambience instead of score ("distant city hum", "wind across the ridge") so the seams stop being musical. Or tag clips by sonic register and use daypart rules so an ambient block runs as a block. ### 2. You cannot just concatenate the files Every clip is an independent encode with its own GOP structure, its own timestamps and sometimes its own dimensions. Stitch the MP4s together, point a player at the result, and you get a stream that stalls, or plays silent, or works in Safari and nowhere else. Getting a continuous stream out of discontinuous sources means normalising every clip onto a common HLS ladder and writing an `EXT-X-DISCONTINUITY` marker at each join. That is the entire job of vod2live. It is the least glamorous part of the stack and the reason the transcode stage exists instead of being optimised away. Pin resolution and aspect ratio at generation time for the same reason: a 9:16 clip in a 16:9 schedule is a pillarbox at best. ### 3. Continuity between clips is a prompt problem Nothing in the model carries state from one generation to the next. Every clip is a cold start, so a channel of independently prompted clips reads as a slideshow instead of a programme. Chain shots with the first-and-last-frame endpoint so each one starts on the previous one's final frame. Fix the `seed` to hold a look steady across a run. Tag ordered runs so they play in sequence rather than shuffled; on My TV Channel the `seqXX01`, `seqXX02` convention keeps a mini-series in order inside an otherwise weighted-random schedule. ### 4. A loop reads differently on a channel than in a feed The repeat interval that matters is not how long your library is. It is how long your library is divided by how long a viewer stays. An hour of content against a six-minute average session means a viewer sees about a tenth of the loop and never registers it as one. The same hour against a 40-minute session is obvious. Measure your session length before you decide how much library to buy. It is the only input that tells you whether $180 or $1,080 is the right number, and it is the one everybody guesses. ## The recipe, and what it costs Putting an always-on AI channel on air, at list price, with one fal concurrency slot: 1. Write 240 prompts across four or five visual themes. This is the real creative work and the only part you cannot automate. 2. Generate 15-second clips at 480p with `prompt_expansion_mode` set to `balanced`. 240 clips at 15 seconds is one hour. **$180.** 3. Import each result URL as it lands and set its weight straight away. The channel launches once it holds four ready clips and fifteen minutes of content, which is sixty 15-second clips, about two and a half hours in. It broadcasts while you build the rest. 4. Let it fill overnight. One slot delivers about 2 h 24 of finished video a day, so the full hour lands in roughly ten hours. 5. Refresh 40 clips a day, ten minutes of new material at **$30**. Weight-0 the oldest forty and regenerate the schedule once. The library turns over completely every six days. > **$180 to launch, $900 a month to keep it fresh, one concurrency slot.** Against $129,600 a month to generate the same channel live at the same resolution, for output a viewer cannot tell apart. The headline is true, and it is a real milestone: video generation crossed the real-time line in August 2026, twice in one week, once from a closed lab and once from an open one. It will not cross back. What follows from it is not that channels should generate themselves live. It is that originating a channel went from a production budget to a rounding error, and the hard part moved, the way it always does, from making the pictures to deciding what should be on at four in the afternoon. ## Point it at a real channel Everything in the pipeline above is an MCP tool or a REST call: create the channel, import each fal URL, weight it, schedule it, launch it. No app, no upload, nothing done by hand. [demo.my-tv-channel.com](https://demo.my-tv-channel.com) is broadcasting right now and was built entirely that way. [See the tools and connect](https://my-tv-channel.com/agents/) ## Related reading - [Run a TV channel from an AI agent](https://my-tv-channel.com/agents/): the 19 MCP tools and the REST API underneath them, with a worked path from nothing to broadcasting. - [MCP in media, video and streaming](https://my-tv-channel.com/mcp-media-video-streaming/): why every video MCP server on the market stops at the clip. - [Pause ads](https://my-tv-channel.com/pause-ads/): what to put on screen when a viewer pauses, and which of the widely-quoted statistics survive checking. - [Self-hosting HLS on a budget](https://my-tv-channel.com/self-host-broadcast/): what it costs to serve the stream once you have made it. ## Sources - [MiniMax H3: An Open Model Breaking the Boundaries Between Tasks and Modalities](https://www.minimax.io/blog/minimax-h3) (MiniMax Research) - [Introducing H3 Max by fal](https://blog.fal.ai/introducing-h3-max-by-fal/), on the post-training and the 35× throughput claim - [MiniMax H3 Max on fal](https://fal.ai/minimax-h3-max): pricing, resolutions, the under-three-seconds figure - [H3 Max text-to-video API reference](https://fal.ai/models/minimax/h3-max/text-to-video/api), for `prompt_expansion_mode` and the response shape - [Concurrency limits](https://fal.ai/docs/documentation/model-apis/concurrency-limits) (fal documentation) - [Video generation models](https://platform.minimax.io/docs/guides/video-generation): MiniMax API docs and pay-as-you-go pricing - [FastVideo FastH3 v1: Open-Weight 4-Step Sparse Distilled MiniMax H3](https://haoailab.com/blogs/fasth3-preview/) (Hao AI Lab at UCSD), for the B200 benchmark table - [FastVideo-FastH3-4-step-Preview-v1-VSA-DataFree](https://huggingface.co/FastVideo/FastVideo-FastH3-4-step-Preview-v1-VSA-DataFree): the model card, licence tag and run command - [hao-ai-lab/FastVideo](https://github.com/hao-ai-lab/FastVideo): the VSA-H3 backend Fast H3 needs - [MiniMax-H3 vLLM recipe](https://recipes.vllm.ai/MiniMaxAI/MiniMax-H3): the 4×B300 benchmarks and launch command - [MiniMax H3 Day-0 Support in ComfyUI](https://blog.comfy.org/p/minimax-h3-day-0-support-in-comfyui), on the 123.6 GB to 42.5 GB reduction - [MiniMax H3 Community License Agreement](https://huggingface.co/MiniMaxAI/MiniMax-H3/blob/main/LICENSE): the Excluded Territories clause - [Infinite Slop](https://infiniteslop.ai/) by @levelsio and fal - [37,000 people watched Infinite Slop](https://levels.io/37000-watched-infinite-slop) (Pieter Levels) Prices and performance figures were checked on 30 August 2026 and are list prices unless stated otherwise. End-to-end timings marked "observed" come from our own runs against the public fal API rather than a controlled benchmark. Vendors move all of these, so re-check the model page before you commit money to a plan.