FervorCreative AI
Live Latest 08.09.26 · morning 50 tools tracked 65 workflows indexed 111 topics Hot: MiniMax H3, ComfyUI, Foundry

A 33B video-plus-audio model reached three different consumer machines in one window through three incompatible hand-written runtimes, so the hardware question for creators is no longer whether you have a datacenter card but which port matches the box on your desk.

MiniMax H3LTX-2.5FLUX.2 Kleinh3.cPaitonLongLive-LoRAvideo-genlocal-creative-aiopen-weightsimage-gencreative-workflowscomfyui

Creative AI Briefing: Tuesday, September 8, 2026

Write seven prompts into a JSON file, run one shell script, and thirty-six seconds of continuous video comes out the other end on two RTX 5070 Tis, with generated audio that you will have to fix at the seams. The pipeline that does it went up this morning. It is one of three ways MiniMax H3 reached consumer hardware inside 48 hours, and no two of them share a line of code: one is a patched vLLM fork sharded across a pair of 16 GB Blackwell cards, one is a from-scratch C and Metal implementation on a Mac, one is a SwiftUI app that shells out to both. The reference implementation is now the path almost nobody takes.

New models

MiniMax H3 on two 16 GB cards landed at 05:47 UTC this morning as pottokao/minimax-h3-2x16gb, and it is a complete shipped system rather than a checkpoint. The DiT is mixed NVFP4 (W4A4 on attention and fc1, W4A16 on fc2), tensor-parallel-sharded to roughly 6.7 GB per card. The Qwen3-VL-32B text encoder is a separate W4A16-NVFP4 quantization, abliterated, about 15 GB, also split across both cards. Two distilled tiers ship side by side: turbo4p at four steps, roughly 73 seconds per five-second segment, and turbo8p at eight steps for about double the denoise time. Output is 1344×768 with audio. The step count is pinned by the checkpoint, so other values are rejected rather than silently accepted.

The honesty is in the memory section, and it is the first thing you should read. Idle host footprint is 13.6 GB, but the generation working set peaks between roughly 40 and 58 GB because the text encoder reload, the DiT and the VAE decode stack up. On a 48 GB host it stays resident. On 32 GB you must provision 16 to 26 GB of swap, and the card states that 8 GB was tested and gets OOM-killed with exit code -9 mid-generation. Below 32 GB is unsupported. There is a copy-paste fallocate block for the swap file, which tells you the author hit this himself.

One environment flag deserves calling out because getting it wrong produces a failure that looks like a bad model rather than a bad config. MINIMAX_H3_TE_EMBED_DEQUANT defaults to 1 and dequantizes the FP8 embed_tokens at scale 0.002145. Without it, the card says, every prompt collapses to the same output. That is the worst shape a bug can take: it still renders, it just stops listening to you. Weights are baked into the repo at about 51 GB, the Docker image is roughly 62 GB, and the kernels are sm120, so this is Blackwell or nothing (weights and pipeline).

LTX-2.5 arrived as a complete MLX pack for Apple Silicon at 03:07 UTC, and the framing on the card is the useful part: "You do not need to distill anything." notapalindrome/ltx25-mlx bundles the distilled 8-step DiT at CFG 1, the full dev DiT, the 450-step distilled LoRA so the dev two-stage path does not need a second gated download, the Gemma 4 12B text encoder with its connector, the DiffVAE and conv VAE, the audio VAE and vocoder, both latent ×2 upscalers, and an optional duration predictor. The provenance section is explicit that this is re-serialization of Lightricks weights under the LTX-2.x Community License, following the layout of mlx-community/ltx-2.5-mlx, with no retraining (pack).

The runtime that consumes it is dgrauet/ltx-2-mlx (109 stars), and the front end is LTX Video Generator for Mac (400 stars, MIT), a native SwiftUI app whose current build lists LTX-2, 2.3, 2.5 and MiniMax H3 in one model picker with a local REST API on port 8420. Read the disk column before you get excited: the app catalogs this pack at roughly 110 GB with the dev LoRA, against about 22 GB for the LTX-2.3 distilled Q4 default and about 144 GB for H3 at BF16. Minimum 32 GB RAM, 64 GB or more recommended.

Image

FLUX.2 Klein 4B got a compiled runtime for AMD RDNA4, which matters because Radeon owners have spent two years reading benchmarks they cannot reproduce. EliovpAI/FLUX.2-klein-4B-Paiton-RDNA4 went up September 7 as a one-command ComfyUI package: clone a tagged branch, run launch.sh, open localhost:8188, and the included workflow is already loaded with a Paiton-or-stock toggle in it.

The numbers, measured September 7 with two warmups and two runs across three fixed prompts on a Radeon AI PRO R9700: mean 1.054 seconds per 1024-square four-step image against 1.258 stock, a 16.2 percent latency reduction. Peak Torch allocation falls from 19.3 to 12.9 GiB, a 33.4 percent drop, with the complete text encoder, transformer and VAE resident on the GPU and no CPU offload. Through the ComfyUI workflow with transport and file writing included, the average is 1.406 seconds.

What makes this card trustworthy is what it refuses to claim. It states outright that "sub-second generation and a 20% latency reduction are not claimed," that "12.9 GiB is peak tensor allocation, not total GPU usage," that only the R9700 at that one fixed profile is qualified, and that three prompts do not establish quality equivalence. The retained comparison pairs measure RGB SSIM at 0.975, 0.974 and 0.859, and the card names the third one as the outlier, pointing at masonry, shelves and lettering in a bookshop scene. It also discloses a licensing problem in its own dependency chain: the upstream community quantization "declares Apache 2.0 but retains a contradictory non-commercial link and does not pin the exact pre-quantization source revision." Original Black Forest Labs weights are Apache 2.0 and are downloaded from upstream rather than redistributed (release).

Video

Three LongLive LoRAs shipped as a controlled ablation, which is rarer and more useful than another checkpoint. Perflow-Shuai published iteration 1500 from the same 16-GPU non-autoregressive run at three different training guidance scales, RGS 0, 1 and 3, all at 11:30 UTC on September 7, all Apache 2.0 over Wan-AI/Wan2.2-TI2V-5B. Rank and alpha are 128, the generator LoRA is 600 FP32 tensors and 322,437,120 parameters, and inference is four steps with no CFG at guidance scale 1.0. The card is careful about a distinction people get wrong: real_guidance_scale is a training setting, not an inference one. Provenance includes the source checkpoint SHA-256 and a note that the training-only critic LoRA, optimizer and per-rank RNG state are deliberately not published, with the honest addendum that the recorded Git commit alone is not claimed to reconstruct the snapshot (RGS 3, RGS 1, RGS 0).

Smaller and immediately usable: vpakarinen/natural-face-speech-h3-lora appeared September 7 under Apache 2.0, targeting full face-muscle dynamics with clear English speech at 720×1280, weight 0.4 to 0.8, steps 15 to 30 (weights). The community fine-tune with the most traction in this window is WarmBloodAban/Minimax-h3_Singularity, created September 5 and now at 157 likes and 58,060 downloads, with a LoRA-form sibling posted at 01:02 UTC this morning.

Yesterday's tracker keeps moving: OpenVDN/vdn-minimax-h3 reads 366 stars on a cache-busted check this morning, against 328 yesterday, 291 on September 6 and 261 on September 5.

The mirror problem is not improving. Bare MiniMax-H3 re-uploads appeared under xiaogongshou (September 5), wudingdeet (September 3) and star08 (September 2), none of them releases. The CH522 account posted twelve near-identical LoRAs against the same base collection between 22:02 UTC on September 7 and 01:35 this morning. Sort by creation date and you are mostly reading uploads, not work.

Audio and music

The audio story this window is a problem rather than a product, and it is worth naming because it will bite anyone chaining segments. The 2x16gb long-video pipeline states it plainly: each first-last segment generates its own audio track, so concatenation produces an audible discontinuity at every boundary. Video is continuous because adjacent segments share a keyframe. Audio is not, because nothing conditions segment N+1's soundtrack on segment N's. The suggested workarounds are to render one continuous audio track separately and mux it over the stitched video, or to crossfade roughly 0.1 seconds at each seam. Joint audio conditioning across segments is listed as roadmap, not shipped.

That is the current ceiling on every long-form native-audio video workflow, not just this one. Anyone selling you a two-minute AI-generated scene with continuous sound is either muxing separately or hoping you do not listen at the joins.

Open and local

The through-line is that the interesting artifact stopped being a checkpoint and became a runtime. Star totals are cache-busted shields.io reads taken September 8.

  • antirez/h3.c: a from-scratch C and Metal implementation of MiniMax H3 for Apple Silicon, documenting every speed setting with the measurement it cost (2.6k) (repo)
  • james-see/ltx-video-mac: MIT SwiftUI front end that puts LTX-2, 2.3, 2.5 and H3 behind one model picker and a localhost REST API (400) (repo)
  • dgrauet/ltx-2-mlx: the MLX runtime the LTX-2.5 pack is built for, distilled 8-step and dev two-stage (109) (repo)
  • OpenVDN/vdn-minimax-h3: hybrid-attention MiniMax H3 with all four training stages open, still climbing (366) (repo)
  • ostris/ai-toolkit: still the trainer behind most community H3 and Wan LoRAs, including this window's crop (12k) (repo)
  • Eliovp-BV/paiton-vllm-plugin: the ROCm container stack behind the RDNA4 FLUX.2 release, with the launch script and full model guide (0) (repo)

Creative workflows

1. Generate a 36-second continuous shot on two consumer GPUs using a keyframe storyboard. Pipeline at pottokao/minimax-h3-2x16gb. Files: pipeline/story_long.sh, pipeline/prompts.json, serve_turbo4p.sh.

The steps. Clone with git lfs install first, because the weights are in the repo. Provision swap before anything else if you are on 32 GB: sudo fallocate -l 24G /swapfile, mkswap, swapon, then add it to fstab. Build with bash build.sh or install the bundled pre-patched engine with pip install -e engine/vllm-omni. Start the four-step server. Edit pipeline/prompts.json as a list whose first entry is a montage prompt describing the whole action and whose remaining entries are the segments. Run STEPS=4 bash pipeline/story_long.sh.

How it works. Chaining first-last segments naively drifts, because each one pins only its opening frame and the character degrades over a few hops. This pipeline generates one short "fast-forward" clip of the entire action first, samples N keyframes out of it in a single pass so they are mutually consistent, then runs true first-last generation between each adjacent pair with both endpoints pinned. Neighbouring segments share a boundary frame, so the stitch is continuous by construction rather than by luck. The text encoder batch-encodes every prompt once, caches the embeddings and unloads, which is why there is no per-segment 15 GB reload. Seeds are reproducible as montage equals SEED, segment N equals SEED+N.

Why it is good. The published example is seven segments at four steps: a 107-second montage plus seven 73-second segments, about 619 seconds of compute for 36 seconds of finished video, with character identity holding head to tail. That is roughly seventeen seconds of compute per second of output, on hardware costing a fraction of a single datacenter card, with no per-generation billing and nothing leaving the machine.

Where it breaks. Audio is discontinuous at every seam and the fix is not shipped. Blackwell sm120 only. The 4/8-step distilled plus W4A4 plus 768p combination has a fidelity ceiling the card states directly. Sixty gigabytes of disk before you generate anything. And the text encoder is an abliterated quantization of Qwen3-VL-32B, which is a different object from the model MiniMax shipped and should be treated as such when you are reasoning about what conditions your output.

2. Tune the speed-quality dial on a Mac with measurements instead of vibes. Runtime at antirez/h3.c. Requires FFmpeg and FFprobe on PATH plus a local MiniMax-H3 snapshot.

The steps. make -j8, then ./h3 --info -d ./MiniMax-H3 to check layout and print the selected Metal device without mapping weights. Start at the validated balanced preset: 512×512, 22 frames, --steps 20 --layers 45 --reuse 2 --profile. When you need a fast look, drop to --steps 4 --layers 50 --reuse 1. When something is wrong and you need an oracle, go to --steps 50 --layers 50 --reuse 1. Change one control at a time. If you are tight on memory, add --ssd-streaming.

How it works. Four independent dials, each documented with what it costs. Denoising passes is literal: --steps N runs exactly N. Whole-denoiser reuse evaluates the first and last pass plus every requested interval and extrapolates the rest, so 20 steps at --reuse 2 is 11 fresh model evaluations. Layer thinning ranks the checkpoint's own AdaLN gates while protecting the first and final blocks, and it drops resident weights as well as compute. The internal canvas runs the model and VAE smaller, then upscales the RGB frames. SSD streaming keeps two DiT blocks in memory and reads the next off disk while the GPU works the current one, which took tracked DiT storage from about 36.5 GiB to 2.0 GiB at 512 square with byte-identical output, at the cost of 84 percent more time.

Why it is good. Every tradeoff comes with a number. The four-pass path measured 0.556 full-video SSIM against a 29-pass reference on the fox test and 0.547 on an independent surfer test, at 3.5 seconds of denoise on an M5 Max versus 26.4 for the reference. Token reduction took a 512-square profile from 16.69 to 12.60 seconds. On M5 the default int8 MLP path took a fixed 50-layer 19-transition render from 36.30 to 25.80 seconds and cut peak tensor storage from 36.4 to 25.9 GiB, with int8 QKV taking it to 19.32. Nothing here is a marketing multiple; it is all the same prompt, seed and shape on both sides.

Where it breaks. The docs name a specific poisoned combination: do not add --token-reduction to both --layers 40 and --reuse 3, which produced chromatic ringing, outlines and ghosted limbs despite acceptable latent norms. SSD streaming cannot be combined with --use-int8-row-fc2. Frames snap upward to 5+17n, so --frames 23 becomes 39 and --seconds 10 becomes 243 frames at 10.125 seconds. Native 128 square is unsupported and 256 square is a composition preview, not a final render. The clean end-to-end reference renders quoted in the card ran on a 128 GB M5 Max at roughly 40.1 GB peak physical footprint.

Worth testing

  • The Paiton ComfyUI package, if you have an RDNA4 Radeon and have been assuming local diffusion was a CUDA-only sport. One clone and one script, and the workflow ships with a stock-versus-Paiton toggle so you can A/B it yourself with a fixed seed. Tradeoff: only the R9700 at 1024-square four-step is qualified, and the first image compiles for several minutes (release).
  • The three LongLive RGS checkpoints, run back to back on the same prompts and seeds. Published ablations you can actually execute are rare enough to be worth an evening. Tradeoff: they are literal iteration-1500 training checkpoints, not polished releases, and the critic LoRA and optimizer state are withheld so you cannot resume them (RGS 3).
  • The LTX Video Generator Mac app at its LTX-2.3 Distilled Q4 default before you commit to anything larger. It is the cheapest way to find out whether local video on your machine is usable at all. Tradeoff: the default pack is about 22 GB and 32 GB of RAM is the floor; the LTX-2.5 pack this briefing leads with is roughly 110 GB (app).
  • h3.c's interactive session, which keeps prompt conditioning, the prepared DiT and the decoder resident so re-rolling a seed skips the load. Tradeoff: you need the full H3 snapshot on disk first, and the --show preview adds roughly 10 GiB of temporary residency (repo).

What actually matters from today's signal

The porting story I have been tracking for a week just changed shape. Last week it was conversions: someone takes a model, re-serializes it for a different runtime, writes down what broke. This window produced something harder. h3.c is not a conversion, it is a reimplementation, in C, against Metal, by one person, with its own sampler schedule search and its own fused kernels and its own measured disagreements with the reference. The 2x16gb release is not a quantization, it is a patched inference engine plus a quantization plus a multi-stage generation pipeline shipped as one artifact. The Paiton release is a compiled runtime with a private compiler that is not included and not needed. Three people looked at the same problem and built three different machines.

For a creator the consequence is that the hardware question changed. It used to be "can I afford the card this needs," and the answer for a 33B video-plus-audio model was no. Now it is "which port matches what I already own," and there are three live answers: a pair of mid-range Blackwell cards, an Apple Silicon Mac with enough unified memory, or an RDNA4 Radeon for the image half. None of these paths is the one the model's publisher documented. All of them are free.

The counter-signal is that this is a fragmentation, not a consolidation, and fragmentation has a bill. Three runtimes means three sets of flags, three sets of failure modes, and no shared ground when something goes wrong. A --reuse 3 artifact on the Mac has no analogue in the vLLM fork. The one flag that silently destroys prompt conditioning in the two-GPU build exists nowhere else. And the abliterated text encoder in that same build is a substituted component, not a compressed one, which is a category of change these cards tend to mention once and move past. What keeps this batch worth trusting is the same thing as last week: every one of these authors wrote down the combination that ruins the output. The 2x16gb card tells you 8 GB of swap gets you killed. The Paiton card tells you three prompts prove nothing. h3.c tells you exactly which two flags not to combine. Hold the next release you read to that line, because a runtime that only documents its wins has not told you the thing you need.


Source access notes: All Hugging Face dates are API createdAt values in UTC, never listing "Updated" timestamps. Star counts are cache-busted shields.io JSON reads taken September 8. GitHub raw README fetches used raw.githubusercontent.com with cache busting. Blocked or unusable sources this run: blog.comfy.org remains a JavaScript wall behind a Substack subscribe gate; the GitHub REST API (api.github.com) returned empty responses for both repository metadata and the latest-release endpoint, so no GitHub release dates are asserted anywhere in this briefing and the Mac app is described only by its current README and by the HF pack it points at, which is dated. civitai.com and midjourney.com/updates were not reachable in a usable form and no claims rest on them. Bucket A was quiet on creative work: OpenAI's window was GPT-6 Astra, an alignment essay and a security post; Adobe's most recent items are a Times Square marketing story (September 4) and a Premiere Emmy award (September 3); ElevenLabs' most recent post is a chief revenue officer hire (September 2). One item was found and deliberately excluded: jayseanbrambila/minimax-h3-prompt-workflow-toolkit (September 7, Apache 2.0) is a prompt guide whose every link is a UTM-tagged referral to an unaffiliated third-party generation site, and its own disclaimer confirms it is not connected to MiniMax; it is marketing, not a workflow release. OzzyGT/krea2_reference_blocks (September 8, Apache 2.0, modular-diffusers reference-image blocks over Krea-2-Turbo) has frontmatter but no README body yet, so it is noted here and not described. The "Writing" section is omitted because nothing qualified. Base models referenced as substrate rather than news: MiniMax H3, LTX-2.5, Wan 2.2 TI2V-5B and FLUX.2 Klein 4B, the last of which the Paiton card dates to January 15, 2026.

An adversarial fact-check subagent ran against this draft and re-pulled every load-bearing figure from primary sources. It caught two substantive problems, both fixed above. First, an arithmetic error: the published 619 seconds of compute for a 36-second clip was described as "a ten-to-one ratio," when the correct figure from the briefing's own numbers is roughly seventeen seconds of compute per second of output. Second, an unsupported superlative calling the h3.c documentation "the single best" in its category, with no comparison performed; that line now describes what the documentation actually does. The pass also flagged that the opening sentence paired "continuous video" with "synchronized audio" without the seam caveat that arrives two sections later, so the lede now carries the caveat, and that the account behind the twelve-LoRA batch was unnamed, so it is now identified as CH522. An unverifiable claim that the Krea 2 blocks came from a Diffusers maintainer has been removed. Every other figure, date, quotation, memory table, benchmark and star count in this briefing survived the pass unchanged, verbatim against the live sources, including all thirteen h3.c measurement claims, the complete pottokao memory and swap table with its exit code -9 finding, the entire Paiton benchmark block with its three disclaimers, and the three mirror creation dates.