Open weights are not an open licence: four checks, using Hi3D

On 23 October 2026, Hi3D announced the open-source release of Hi3D V1.0, the image-to-3D model previously called Sparc3D. According to the announcement carried by PR Newswire and the model card, the source code is on GitHub at hi3d-official/Hi3Dv1.0, the weights are on Hugging Face under the same name, and generation is also offered free on the vendor's own site.

That is the news, and plenty of sites will cover it. For anyone who self-hosts, the more useful question is not whether it is free. The useful question is what exactly they made free, and Hi3D happens to be a clean example of how to answer it.

What this open source AI 3D model actually does

Hi3D V1.0 takes two inputs: an image and a coarse 3D mesh. It returns high-resolution geometry. In other words, it refines a rough shape into a detailed one, guided by the picture. It does not start from nothing.

The vendor reports that training data grew from about 500,000 to two million curated 3D assets, that the effective sparse grid goes up to 1536³, and that the model achieved "the highest multi-view fidelity and detail richness scores in the reported evaluation". The vendor also reports a 90% slicing success rate. These are the vendor's own numbers, not independent results, and I have not run the model myself.

The workload is very different from a chat model. An LLM streams tokens, and you can often squeeze it onto modest hardware with quantisation and patience. A 3D pipeline like this works on a volume. For scale, a dense 1536³ grid would hold about 3.6 billion cells, which is why the model uses a sparse one. Even so, the job is bound by GPU memory and by specific GPU kernels, not by how fast you can push tokens.

I made the same point about language models in memory decides what runs, not the price tag. With 3D it matters even more, because there is far less room to trade speed for memory.

The licence clause: read it before you build

The first check is the licence, by name. Hi3D V1.0 ships under the Hi3D Open License Agreement Version 1.0. It is not an OSI-approved open-source licence. That alone does not make it bad, but it means you cannot assume the rules you know from Apache-2.0 or MIT.

Here is what the licence says, in plain terms:

• Commercial use is permitted.
• A product or service that exceeds 200,000 monthly active users or reaches USD 1,000,000 in monthly revenue must notify the licensor and apply for a separate written licence within 60 days.
• Commercial integrations must display "Powered by Hi3D 1.0" with a link.
• According to the model card, standalone outputs (an output containing no Hi3D materials or model derivatives) do not by themselves trigger those branding and scale obligations.

That is my summary. The Agreement itself controls, so read the full text before you rely on any of this.

For a small operator, this is usually fine. If you run a print shop, a small studio or an internal tool, you are nowhere near 200,000 monthly users, and a branding line is a small cost. Under Apache-2.0 or MIT, though, there is no user count, no revenue trigger and no branding requirement. You keep the notices, and that is mostly it.

The difference shows up when a product grows. Cross one of those thresholds and you are on a 60-day clock to apply for a written licence whose terms you cannot see today. That belongs in your planning from day one, the same way I described in what a licence means for your exit plan. If your business case only works at scale, you need an answer for what happens at the threshold.

Reproducibility: an inference-only release

The second check is whether you can reproduce the numbers. Hi3D V1.0 is inference only. Training code, the evaluation harness, the benchmark splits and the comparison meshes are not included. The model card says plainly that the repository alone cannot reproduce the paper's comparative tables.

This is common, and it is worth naming. Downloadable weights let you run the model. They do not let you verify the claims that made you interested in the first place. The fidelity scores and the 90% slicing figure stay vendor-reported, because nobody outside can re-run the same evaluation on the same splits.

For a hobby project, that may not matter. For a paid workflow, it does. If you are choosing between two models for client work, the comparison tables are the evidence you would normally use, and here you cannot check them. The practical fix is to build your own small test set from the kind of inputs you actually get, run every candidate on it, and judge the output yourself.

Inference-only also means you cannot retrain or properly fine-tune from the release alone. If your inputs are unusual, you are relying on the vendor's training choices.

The hardware question: what the reference build needs

The third check is hardware, and here the model card is unusually direct. The reference implementation requires:

• Linux
• Python 3.10
• An NVIDIA GPU with compute capability 8.0 or newer (Ampere generation onward)
• A CUDA toolkit in the 12.0 to 12.5 range
• flash-attn, with no fallback attention path

The card also states: "There is no CPU inference path." If your GPU is older than Ampere, or you have no NVIDIA card at all, the reference build is not for you.

Before you download anything, two commands will tell you where you stand:

nvidia-smi --query-gpu=name,compute_cap,memory.total --format=csv
nvcc --version

The first shows your card, its compute capability and its memory. The second shows your CUDA toolkit version. If compute capability is below 8.0 or the toolkit is outside 12.0 to 12.5, you have work to do before you start.

Memory is the harder question. The 1536³ setting was validated on one GPU: a 96 GB NVIDIA H20. The card says peak memory and feasibility on smaller cards "have not been established". So nobody is promising that a 24 GB consumer card can run the top setting. It might work at lower settings, but that is not documented, and I would not plan a project around it.

Then there is the community. A port called mlx-community/Hi3Dv1.0-mlx appeared the same day, 23 October 2026, and runs the model on Apple silicon. That matters for Mac users, whose unified memory can be large. Be clear about what it is, though. It is inference only, it installs from source for now, and it is a community project, not the vendor's reference build. Treat it the way I treated community builds in the earlier post on running an open-weights model on your own hardware: useful, worth testing, and something to compare against the reference before you trust it.

What it does not do

The fourth check is the one people skip: what the model does not do. Hi3D V1.0 outputs geometry only. There are no textures, no materials and no vertex colours. It runs at batch size one. And according to the model card, severe structural errors in the input coarse mesh can persist into the output.

That last point deserves attention. Because the model refines a coarse mesh, the quality of that mesh carries through. A broken input is likely to give you a detailed, broken output.

So this is a step in a pipeline, not a one-click asset machine. You still need something to produce the coarse mesh, and something after it for texturing, cleanup or slicing. If you wanted finished, textured assets, note that the vendor's commercial V3.0 model, with 2048³ voxel resolution and up to 8K textures, is not part of this release and remains a paid product.

The four-check routine

The next time an "open source AI" release lands, run these four checks before you clone anything. They take about ten minutes with the model card open.

1. Licence, by name. Is it OSI-approved, or a vendor licence with scale triggers and branding rules? Note the thresholds and the deadlines.
2. Reproducibility. Are training code and the evaluation harness included, or is it inference only? If inference only, plan your own test set.
3. Hardware. What does the reference build require, what GPU was it validated on, and what do community ports actually change?
4. Scope. What does the output leave out, and what will you need before and after it?

If all four answers fit your situation, you have a tool you can build on. If not, you have a demo you can look at, which is fine, as long as you know which one it is.

If you would rather have someone size the hardware and harden the pipeline for you, see the services page. Fiverr: hiteshsaini459 · Upwork: hiteshsaini25