3D generation model

One image, a usable 3D mesh in ten seconds — self-hosting InstantMesh

TencentARC's feed-forward image-to-3D stack: Zero123++ fills in the views, an LRM regresses a triplane, FlexiCubes extracts the triangles. Here are the four official checkpoints, the real VRAM floor, and a deployment path that still works.

InstantMesh · self-hosted

InstantMesh came out of TencentARC in 2024 (arXiv 2404.07191), with code and weights under Apache-2.0. It is a different animal from the earlier SDS-optimisation approaches that spent tens of minutes iterating on every object: the whole pipeline is feed-forward. A fine-tuned Zero123++ v1.2 hallucinates 6 views at 320×320 from your single input image, a sparse-view LRM regresses those 6 views into a triplane in one shot, and FlexiCubes differentiably extracts triangles on a 128-resolution grid. There is no sampling loop in the reconstruction half at all, which is how the paper gets to its "within 10 seconds" number.

The official ckpts directory on Hugging Face totals 7.27GB: four reconstruction weights plus one multiview diffusion UNet. The reconstruction weights split into two branches. The mesh branch (instant_mesh_large.ckpt at 1.51GB, instant_mesh_base.ckpt at 1.25GB) runs FlexiCubes and can bake a 1024 texture directly. The NeRF branch (instant_nerf_large.ckpt, instant_nerf_base.ckpt) renders at 384 and pulls geometry out with Marching Cubes at resolution 256 — smoother surfaces, but one extra hop to get a textured asset. The large-versus-base split is spelled out in the configs: 16 transformer layers, triplane dim 80 and 128 samples per ray, against 12 layers, dim 40 and 96 samples per ray.

Two things to know before you try this on your own box. First, run.py only passes torch_dtype=torch.float16 to the diffusion pipeline — the reconstruction model is loaded with a plain model.to(device) and sits in fp32, and the rendering stage produces a single allocation in the 15GiB range. People have reported the literal "Tried to allocate 15.00 GiB" on a card with 14.58GiB available, which is why 16GB parts like the T4 and 4060 Ti cannot carry instant-mesh-large; 24GB is the working floor. Second, the repository's last commit lands in early 2025 and its dependencies are pinned hard — diffusers 0.20.2, transformers 4.34.1, gradio 3.41.2, PyTorch 2.1.0 on CUDA 12.1. Installing that into your daily driver is asking for a fight with whatever is already there. A clean per-second-billed GPU instance you spin up, use, and stop is genuinely the easier path.

01 —

Checkpoints and configs at a glance

Four reconstruction checkpoints plus one multiview UNet — the configs directory tells you everything you need to choose.

Version	Parameters	VRAM	Context	Notes
instant-mesh-large	16 transformer layers / dim 1024 / triplane dim 80 / 128 samples per ray	ckpt 1.51GB; reconstruction resident in fp32, peak single allocation around 15GiB during rendering — plan for 24GB	FlexiCubes grid_res 128, grid_scale 2.1, render 512, texture 1024	The default and the best-looking variant. This is the config in the README's own example command, and the one to use for real output.
instant-mesh-base	12 transformer layers / triplane dim 40 / 96 samples per ray	ckpt 1.25GB; also FlexiCubes, noticeably more headroom on a 24GB card than large	FlexiCubes grid_res 128, render 512, texture 1024	Roughly half the parameters but keeps the full direct-to-textured-mesh path. Pick it when throughput beats per-asset quality.
instant-nerf-large	16 transformer layers / triplane dim 80 / 128 samples per ray	ckpt 1.51GB; renders at 384 instead of the mesh branch's 512, so it is lighter	NeRF rendering + Marching Cubes 256, mesh_threshold 10.0	Smoother geometry transitions and nicer turntable videos, at the cost of losing the direct FlexiCubes texture-bake route.
instant-nerf-base	12 transformer layers / triplane dim 40 / 96 samples per ray	ckpt 1.25GB; the lightest of the four	NeRF rendering + Marching Cubes 256, render 384	The fastest way to prove your environment actually works. Do not ship production assets from it.
Zero123++ v1.2 custom UNet	sudo-ai/zero123plus-v1.2 with TencentARC's white-background fine-tuned UNet	diffusion_pytorch_model.bin 1.73GB, loaded in fp16 — this half is not your memory bottleneck	Emits 6 views at 320×320, 75 EulerAncestral steps by default, seed 42	The stock UNet was swapped specifically to get reliable white-background multiviews. It dominates wall-clock time, not VRAM.

02 —

Which GPU to rent

InstantMesh's memory curve is driven by fp32 reconstruction and 512-resolution rendering. Start at the 24GB line.

Get the pipeline working, generate single meshes, evaluate quality
RTX 3090 24GB$0.193/GPU-hr
24GB is the minimum that clears instant-mesh-large's 15GiB allocation, and the 3090 is the cheapest card on our list that clears it.
Batch production, a long-running Gradio app, or baking 1024 textures with --export_texmap
RTX 4090 24GB$0.540/GPU-hr
Almost all wall-clock time goes into Zero123++'s 75 diffusion steps. Ada's fp16 throughput is a tier above Ampere, and at batch scale that is whole hours saved.
Splitting app.py across two GPUs, or running several workers on one card
RTX A6000 48GB$0.817/GPU-hr
app.py automatically puts diffusion on device0 and reconstruction on device1 when it sees two GPUs; 48GB on one card instead lets several processes each hold their own fp32 reconstruction model.
Reproducing the two-stage training run, or fine-tuning the multiview UNet via zero123plus-finetune.yaml
H100 SXM 80GB$3.582/GPU-hr
The paper used 8× H800 for both stages with a stage-1 batch size of 48. Eight H100s is the closest rentable equivalent, and NexGPU nodes go up to 14 GPUs.

03 —

Four steps to a running pipeline

The dependency pins are strict — copying this sequence beats assembling your own.

01
Start an instance on a CUDA 12.1 image with a full toolchain
Pick a PyTorch development image, not a runtime-only one. nvdiffrast JIT-compiles CUDA extensions on first use, and without nvcc it will fail at your first inference rather than at install time. SSH in and clone.
```
git clone https://github.com/TencentARC/InstantMesh.git && cd InstantMesh
```
02
Install the pinned environment — this is where most attempts die
requirements.txt pins diffusers to 0.20.2, transformers to 4.34.1 and gradio to 3.41.2; bumping any of them breaks the custom pipeline. nvdiffrast installs straight from NVlabs' git and needs ninja. The good news: the code uses dr.RasterizeCudaContext, not a GL context, so no OpenGL or EGL is required and headless servers are fine.
```
pip install torch==2.1.0 torchvision==0.16.0 --index-url https://download.pytorch.org/whl/cu121 && pip install xformers==0.0.22.post7 ninja && pip install -r requirements.txt
```
03
Generate your first mesh from the command line
The first run pulls 7.27GB of weights from Hugging Face, and rembg downloads its u2net matting model on top. Point HF_HOME at a mounted volume so a restarted instance does not re-download everything. --export_texmap runs xatlas UV unwrapping, which the README explicitly flags as slow — leave it off while you are still evaluating.
```
export HF_HOME=/workspace/hf && python run.py configs/instant-mesh-large.yaml examples/hatsune_miku.png --save_video --export_texmap
```
04
Bring up Gradio for interactive use, and tune down if memory is tight
app.py grabs two GPUs automatically to split the pipeline; with one card, pin it with CUDA_VISIBLE_DEVICES. Gradio OOMs more readily than the CLI because it defaults to 75 steps and renders a live turntable preview. Dropping diffusion_steps to 30 and skipping --save_video pulls the peak down noticeably.
```
CUDA_VISIBLE_DEVICES=0 python app.py
```

What a real run costs

Take the RTX 3090 24GB at $0.193/GPU-hr. Budget half an hour for the install, nvdiffrast's first compile and the 7.27GB weight pull, then run three hours of batch generation: 3.5 hours × $0.193 = $0.68. The same 3.5 hours on an RTX 4090 24GB is 3.5 × $0.540 = $1.89, and what the difference buys is a genuinely shorter 75-step diffusion stage. Want it faster still? Drop --diffusion_steps from the default 75 to 30. The xatlas unwrap in --export_texmap really is slow, but slow is cheap under per-second billing: five extra minutes on the 3090 is 0.193 ÷ 60 × 5 ≈ $0.016. If you want to keep the weights and outputs around, a 20GB volume at $0.414/GB-month works out to $8.28 per month — compute billing stops the moment the instance stops, storage continues until you destroy the volume. To actually reproduce the paper's training, eight H100 SXM 80GB is 8 × $3.582 = $28.66 per hour, still metered per second, so you stop when the run stops.

04 —

FAQ

What is the minimum VRAM for InstantMesh? Will a 16GB card work?

Not for instant-mesh-large. The reconstruction model stays resident in fp32 and the rendering stage produces a single allocation in the 15GiB range — users have posted the exact "Tried to allocate 15.00 GiB" error on a card with 14.58GiB free, and others report the config sitting around 16GB overall. Plan for 24GB. The nerf-base variant is considerably lighter but is not what you want for real output. NexGPU's RTX 3090 24GB is $0.193/GPU-hr billed per second, so testing it properly costs less than the time you would spend guessing.

Why does the Gradio app.py run out of memory when the CLI run.py does not?

Different peaks. app.py defaults to 75 diffusion steps and renders a live turntable video, with both the diffusion and reconstruction weights on one card; run.py without --save_video is far lighter. One user hit OOM in Gradio on a 24GB 4090 and then ran the identical image through the CLI without trouble. If you need an interactive service, give app.py two GPUs so it splits diffusion onto device0 and reconstruction onto device1, or take a single NexGPU RTX A6000 48GB at $0.817/GPU-hr and stop worrying about the peak.

Is InstantMesh still worth using, or have Hunyuan3D and TRELLIS replaced it?

Straight answer: the InstantMesh repo's last commit is from early 2025, and newer models have raised the quality ceiling. Hunyuan3D-2.1 pairs a 3.0B shape DiT with a 1.3B texture model and documents 6GB for shape generation, 16GB for shape plus texture; TRELLIS image-large is 1.2B under MIT and asks for at least 16GB. InstantMesh still wins on three counts: Apache-2.0 with no commercial strings, a reconstruction stage with zero sampling steps so batch throughput is very high, and a 1.5GB checkpoint — which keeps it useful for dataset bootstrapping and bulk base-mesh generation. On NexGPU you can put all three on one machine and one volume and A/B them, instead of renting two boxes to settle an argument.

nvdiffrast will not install, or the first inference hangs. What now?

nvdiffrast is installed from NVlabs' git source and only JIT-compiles its CUDA extensions on first call, so it needs ninja plus an nvcc that matches your PyTorch build (CUDA 12.1). A runtime-only image has no nvcc and will blow up long after you thought installation succeeded. The good news is that InstantMesh uses dr.RasterizeCudaContext rather than a GL context, so no OpenGL or EGL is needed and headless servers are perfectly fine. NexGPU's PyTorch development images — among 2,000+ prebuilt options — ship the full toolchain, which makes this problem disappear at image-selection time.

Why is --export_texmap so slow, and what happens without it?

The slowness is xatlas UV unwrapping, which the README itself calls out, at a default texture_resolution of 1024. Without --export_texmap you get an .obj with per-vertex colours: geometry is correct, but many DCC tools do not display vertex colours, so it arrives in Blender or UE as a grey blob. The practical workflow is to skip it during evaluation and bake textures only for the assets you keep. Under NexGPU's per-second billing those extra minutes are close to a rounding error.

What format is the output, and can I drop it straight into Blender or Unreal?

By default an .obj with vertex colours. Add --export_texmap and you also get the mtl and texture map, which is the version you can hand to a DCC tool directly; add --save_video and you get a turntable clip for fast triage. You can also pass --view 4 to drop from 6 input views to 4, or nudge the camera with --scale and --distance. NexGPU instances give you SSH, Jupyter, a web terminal, a REST API and a CLI, so pulling assets off the volume or wiring the whole thing into your own pipeline is straightforward — and support is bilingual over Telegram with no ticket queue.

Start building on NexGPU

Enterprise R&D team or solo developer — either way, your first job can be running in minutes.