Can I buy this exact H3 build from Y in the US?

Not under MiniMax H3's current community license. It excludes the United States and European Union. Y can design the same two-lane outcome with a commercially permitted video backend, or support H3 only after separate written authorization is verified.

Does this prove a one-million-token workload under load?

No. The source configured a 1,048,576-token context window and reported the matching KV capacity, but its benchmark used short prompts and short outputs. A Y acceptance test would include retrieval and latency runs at 64K, 256K, 512K and 1M input lengths.

Why publish a recipe that is not ready to sell?

Because it shows the density these machines can reach and, just as importantly, the work between an exciting experiment and a dependable product. The evidence grade and availability gate keep those two things separate.

Y Recipe 001 · source-audited

One agent endpoint. Two video lanes.

Two DGX Sparks run DeepSeek V4 Flash across both nodes while each box also renders video with audio. Here is the exact topology, the source-reported operating envelope, what survived our audit and how Y OS would make it deployable.

Source-auditedNot yet Y-reproduced

A spectacular experiment. Not a product configuration yet.

The repository is an MIT-licensed orchestration experiment, not a model release. Its results come from one source-run sweep. Y audited the code and raw files at commit e9d31d7, but has not repeated them on controlled hardware.

US / EU availability

The exact H3 configuration is license-blocked.

MiniMax H3's community license excludes the United States and European Union. Y cannot run, host or ship it there without written authorization. The deployable Y OS version must use an authorized or commercially permitted video backend.

Read the model license

The topology

One distributed agent service spans both nodes. Two independent video services each live inside one node's remaining unified memory.

Node A · head

121 GiB

DeepSeek shard · rank 0
Agent API · port 8888
Video lane A · ComfyUI

200G RoCE

Node B · worker

121 GiB

DeepSeek shard · rank 1
Headless agent worker
Video lane B · ComfyUI

Spans both nodes · tensor parallel 2

DeepSeek V4 Flash 0731 · 1,048,576-token configured context

What the source reports

Aggregate generation throughput in tokens per second. The C6 headline uses a deterministic counting prompt designed to show a speculative-decoding ceiling, not normal prose speed.

Concurrency	Agent only	+ 1 render	+ 2 renders
C1	88.87	40.98	28.48
C2	149.37	68.38	50.99
C3	199.47	88.19	66.74
C4	214.90	97.19	73.44
C5	203.93	92.14	74.25
C6	285.95	130.77	100.79

28:31–28:54

wall time per 15.08s 480p clip

1.329s

highest raw TTFT with two renders

1 sweep

per condition · no variance reported

These are source-reported observations, not Y measurements. The raw files contradict the source's “always under one second” TTFT summary, use different served-model names between conditions and include no repeated trials. We publish the raw maximum and treat the table as an anecdotal baseline.

The 121 GiB memory puzzle

Per node, as reported by the source. The values nearly fill the usable pool before a render begins.

The important discovery is not a new quant. It is load order. Start the agent service first and the adaptive video stack evicts components to fit the remaining headroom. Reverse the order and the agent model may not load.

DS4 weights · half-share79.51 GiB

KV cache10.28 GiB

Activations + CUDA graphs5.2 GiB

OS + container overhead10 GiB

Headroom for video16 GiB

How the source runs it

The useful operating logic, separated from the source's unsafe and unpinned deployment defaults.

01
Qualify the pair
Two GB10 nodes, about 121 GiB usable unified memory each, the model files on both boxes and a working 200G RoCE fabric. This exact profile is not a one-box build.
02
Start the agent worker, then the head
DeepSeek V4 Flash is sharded tensor-parallel across both nodes. The source waits for roughly 79.51 GiB of weights and a 1,473,052-token KV pool before continuing.
03
Only then start each video lane
Load order is the trick. The agent service takes about 105 GiB per node first; each adaptive video runtime must then work inside the remaining 16–18 GiB.
04
Queue, observe and prove recovery
Run fixed workloads through the agent API while both render queues are active, record raw telemetry, verify artifacts, stop video before any agent restart, then prove full throughput returns.

Open this Y Recipe on GitHub Inspect the original MIT repository Inspect the DeepSeek model card

Reproduction with H3 is only lawful in an applicable territory or with separate written authorization.

What our audit caught

This is why a Y Recipe is more than reposting an impressive thread.

Workflow mismatch

Both reference-to-video examples load the FL2VA checkpoint. ComfyUI's official reference workflow calls for the separate Ref2VA checkpoint.

Reproducibility gap

The runtime image, ComfyUI commit, model revisions and hashes are not pinned. The exact measured environment cannot be rebuilt from this repository alone.

Security gap

Privileged containers, host networking and unauthenticated APIs on 0.0.0.0 are lab defaults, not a configuration we would ship to a customer.

Compare the official ComfyUI R2V template

Which Y Computer can run it?

Exact compatibility means the full stack and operating behavior, not merely enough aggregate memory on a spec sheet.

Two matched GB10 systems

Architecture match

The only direct target for this topology. It still needs a lawful video backend, pinned runtime and a fresh Y benchmark.

Y Computer Max 192

Promising · unverified

Two 96GB CUDA GPUs can hold the model shares, but discrete PCIe memory behaves differently from GB10 unified memory.

Y Computer Max 96

Different profile

Strong for video or a smaller agent model. One 96GB GPU does not safely hold this full tensor-parallel factory.

Y Mini 128 / Pro 64

Not compatible today

These are separate ROCm tracks. The CUDA and NVFP4 artifacts in this source build do not transfer as-is.

The Y OS version

Keep the outcome. Remove the science project.

Y OS turns the topology into a supportable customer profile, using a video backend licensed for the deployment territory.

License gate

Resolve the customer territory first, then select a model backend that can legally be run, supported and shown there.

Machine doctor

Check architecture, usable memory, disk, fabric, drivers, container runtime, model hashes, ports and thermals before installation.

Pinned build

Lock model revisions, container digests, ComfyUI graphs, runtime patches and a complete third-party notice manifest.

Safe lifecycle

Encode the worker-head-video start order, readiness gates, health checks, recovery path and automatic rollback.

Private endpoints

Replace public unauthenticated ports with least-privilege containers, authenticated TLS and a private management boundary.

Acceptance benchmark

Repeat the real workload, publish raw results, validate every output and hand over a benchmark tied to the customer's exact machines.

Build the legal equivalent See what Y OS manages

Questions, answered straight

Can I buy this exact H3 build from Y in the US?: Not under MiniMax H3's current community license. It excludes the United States and European Union. Y can design the same two-lane outcome with a commercially permitted video backend, or support H3 only after separate written authorization is verified.
Does this prove a one-million-token workload under load?: No. The source configured a 1,048,576-token context window and reported the matching KV capacity, but its benchmark used short prompts and short outputs. A Y acceptance test would include retrieval and latency runs at 64K, 256K, 512K and 1M input lengths.
Why publish a recipe that is not ready to sell?: Because it shows the density these machines can reach and, just as importantly, the work between an exciting experiment and a dependable product. The evidence grade and availability gate keep those two things separate.