Can One GPU Run Matrix-Game 4.0? A Local Deploy SOP
A nine-step SOP for running Matrix-Game 4.0 locally on a single GPU, with every command and flag taken verbatim from the v4 subdirectory README (repository: github.com/SkyworkAI/Matrix-Game, file Matrix-Game-4/README.md). Step 1, align on requirements: model inference needs Linux, an NVIDIA GPU and Python 3.12 together, the reference A100 80 GB deployment uses PyTorch 2.12.0 / CUDA 13.2, and the repo ships a dedicated RTX 5090 runtime that does not auto-detect hardware, so the matching preset must be selected explicitly; the browser demo needs a Linux server that also builds the game and GStreamer pipeline while the Safari/Chrome client needs no GPU; standalone play and recording need macOS or Linux plus CMake, C++20, SDL2 and FFmpeg, with the legacy Windows entry retained but not validated for feature parity; and weights and assets are not shipped in the repo, so budget extra space for the Hugging Face Hub cache. Step 2, install inside the Matrix-Game-4/ subdirectory or everything after is wrong: git clone, cd Matrix-Game/Matrix-Game-4, python3.12 -m venv .venv and source .venv/bin/activate, then pip install torch==2.12.0 torchvision==0.27.0 --index-url https://download.pytorch.org/whl/cu132 as a matched pair, then pip install -e '.[inference,server,download,test]' with all four extras; FlashAttention is optional and only rtx5090-sage needs SageAttention while plain rtx5090 uses PyTorch SDPA. Step 3, downloads come as two manifests, game assets and model weights, pinned to revision 4419accdb7bb7881234c5914de8cd915266e0325 with --scene switchable across castle, racing and all, and one server process supporting only one scene model; the downloader verifies size and SHA256 against the manifests so interrupted runs can simply restart, shared T5/tokenizer and Wan VAE pull automatically from the official base, and matrix-game verify rechecks an installed scene. Step 4, offline rendering proves the model produces output: matrix-game render --scene ancient-egypt --input lowpoly.mp4 --resources resources --preset realtime --prompt-mode fixed --output outputs/egypt, where the input is a low-poly proxy stream rather than real footage and the output is rendered.mp4 plus a configuration report with FPS and frame count preserved; the three presets matter - realtime is for A100, RTX 5090 switches to rtx5090, and quality is slower yet is exactly the default when --preset is omitted. Step 5, play and record locally without loading a model: bash scripts/build_game.sh then bash scripts/play.sh --scene ancient-egypt, giving the two shooter scenes a 48 FPS, 2x simulation-time demo mode with F9 recording and Escape menu, and MATRIX_GAME_DATA_DIR overriding the default data directory; racing uses build_racing.sh with 1x simulation time, and the browser demo does not enable the shooters' 2x mode either, advancing 1/--fps seconds per captured frame. Step 6, the browser demo splits server and client: mediamtx configs/mediamtx.yml in one terminal and CUDA_VISIBLE_DEVICES=0 bash scripts/serve.sh --scene ancient-egypt --resources resources --preset realtime --fps 40 in another, then open http://127.0.0.1:8025/, with --reference-only testing controls, HUD, audio and transport without loading a model; --fps 40 is a capture cadence target, not a throughput or latency guarantee. Step 7, the two RTX 5090 presets: rtx5090 needs no extra installation while rtx5090-sage requires building SageAttention 2.2.0 with the supplied CUDA-graph patch and CUDA 13.2 at git checkout eb615cf6cf4d221338033340ee2de1c37fbdba4a; both reuse the same scene checkpoints and shared resources, converting DiT block linear weights to FP8 at load with activations quantized during inference while embeddings and the output head stay BF16, and startup warms kernels and captures CUDA graphs so the first launch is slower than steady state. Step 8, acceptance in two forms: a keypress producing a picture in the browser demo (officially about under 150 ms, not independently reproduced) or an offline render turning a low-poly video into a finer output, with the three performance accounts written side by side (official 480p 60 FPS, 83 FPS and 18.5 GiB; the project page panel still at 0; and the README's about 38-39 FPS on an A100 at 864 x 480), remembering that model throughput, pipeline throughput, presentation frame rate and end-to-end latency are four different things. Step 9, six pitfalls: one process supports one session and one scene model; it binds to loopback by default and must not be exposed to the internet, since the official statement calls it a trusted single-user demo rather than a public cloud-gaming service; --fps 40 is not a throughput guarantee; Windows is unvalidated; disk must accommodate the Hub cache; and VRAM splits into an A100 80 GB reference tier and an RTX 5090 consumer tier with the 5080 and 5070 still pending.