Resolution is not a memory calculation

Making Hi3D v1.0 downloadable changes access for a team that wants to refine geometry on its own machines. A hardware budget still separates downloading the files from producing the most detailed output. The full 1536³ ladder has been validated on a NVIDIA H20 graphics processor with 96 GB of memory. Peak memory and feasibility on smaller cards have not been established. That number describes a validated environment, not a minimum memory requirement. Treating the two as equivalent could lead either to reserving unnecessary capacity or to planning a configuration that cannot run.[1]

Nor does 1536³ describe a dense tensor held in memory. It is the effective resolution of a sparse extraction grid. The system starts with an image and a coarse mesh, refines the mesh and revoxelizes it to provide support for another pass. A 512³ request uses one pass, 1024³ uses two and 1536³ uses three. That structure prevents the headline resolution from becoming a simple fixed memory calculation. The space occupied by intermediate representations is part of the hardware boundary within which the complete job must run.[1]

Offloading weights leaves other costs

The repository offers sequential CPU offload. It can reduce the amount of model weight resident on the GPU, but does not eliminate the memory cost of decoded features. Offload is also different from CPU inference: there is no CPU inference path and no fallback implementation for the required attention kernel. Selecting hardware from weight size alone is therefore an incomplete capacity calculation. Intermediate data generated during execution must fit as well.[1]

A smaller card might be sufficient; the disclosure does not rule that out. It does not supply measurements establishing that possibility either. If intermediate representations dominate the peak, moving weights may provide limited relief. If weight residency dominates, offload could free substantially more room. These are alternative explanations of the capacity constraint. Hi3D’s stated validation scope cannot determine which dominates on a smaller card. Neither a universal memory floor inferred from the H20 result nor a cheap-hardware guarantee inferred from offload is justified.[1]

The boundary of a completed job

How the limit appears to the operator matters too. When a request cannot reach the specified resolution, the pipeline raises an error instead of silently returning a less detailed mesh. A run that fails to meet a 1536³ request is therefore not counted as success under the same label. The trade-off is that an undersized configuration can stop without producing the requested usable result. Loading a model and completing its required output represent different service levels.[1]

Output scope also belongs in capacity planning. Hi3D produces geometry, without textures, materials or vertex colors. Hidden surfaces are plausible completions, and severe structural errors in the coarse mesh can persist. Higher resolution therefore does not mean the downstream production work is finished. The concrete gain for self-hosted use is downloadable inference code and weights. Which smaller card can complete the most detailed job, and at what peak memory, remains a separate capacity question.[1]