Idol-GGUF

This is a mixed-precision, eight-bit quantization of Idol by SperiD Labs. Eligible Idol denoiser, octree decoder, Gaussian decoder, and background-remover matrices use eight-bit Q8_0 blocks; remaining tensors retain other precisions. The model takes one image and reconstructs a three-dimensional Gaussian point cloud.

The file Idol-Q8_0.gguf contains all four Idol components; the image encoders are separate. Its Secure Hash Algorithm 256-bit (SHA-256) digest is 1f6875979bac8c8aecacf0c698662b7c63ff54ae1b6d7c06755297a05607e983. It was exported from upstream revision 2731c2291fc65a797c5cb627a5e5526fc1490902. Of its tensors, 422 use Q8_0, 125 use float16, 1,076 use float32, and 67 use int64. The denoiser's eligible block matrices use covariance-calibrated Q8_0 codes; other eligible matrices use Q8_0 rounding.

Use idol.cpp for the supported runtime; its project source is available under Apache License 2.0. Idol's original-precision image encoders are separate: DINOv3 and the variational autoencoder from FLUX.2-dev. Access requires accepting their respective terms and authenticating with Hugging Face. Their weights and licenses are separate from Idol's Apache 2.0 license.

Idol itself accepts images, not text. A separately configured image generator can supply the input image. One tested local configuration uses Iris-3B with Qwen3-VL-4B for text encoding; both are Apache 2.0 licensed and are downloaded separately. The tested files are Sakura-Iris-3B-Q4_K_M-3.14GiB.gguf and Qwen3VL-4B-Instruct-Q4_K_M.gguf. The interface displays the configured filenames; an external image service reports its own model identity. These labels are not independent verification of the weights. ComfyUI-GGUF compatibility has not been established.

The original Idol project also demonstrates Iris-3B images as inputs. Whether Idol was trained on Iris-generated images is not established by that project page.

The original unmodified model card is included as UPSTREAM_README.md; the original model, use conditions, and research are also described at speridlabs/idol.

RTX 4090 observations

Individual Windows runs used an NVIDIA GeForce RTX 4090 with 24,564 MiB of physical graphics memory, PyTorch 2.10.0 with CUDA 12.8, and triton-windows 3.5.0.post21. Image-to-3D requests used 50 denoising steps, seed 42, 262,144 Gaussian points, and fused kernels. The resident rows also used batched guidance and optimized attention; staged rows disabled both. Warm requests followed a one-step warmup. Operating-system caches could be warm.

Workload	Idol and image encoders	Time	Peak PyTorch GPU allocation	Peak host working set
Fresh process, lamp / axolotl	Original Idol / original encoders	37.0 / 36.0 s	4.76 GB	~6.43 GB
Fresh process, lamp / axolotl	Idol Q8 / original encoders	34.6 / 34.6 s	4.39 GB	~6.73 GB
Warm resident, lamp / axolotl	Original Idol / original encoders	25.12 / 25.12 s	5.36 GB	~6.07 GB
Warm resident, lamp / axolotl	Idol Q8 / original encoders	28.05 / 27.38 s	4.73 GB	~6.72 GB
Warm staged, axolotl	Idol Q8 / original encoders	33.28 s	3.51 GB	6.72 GB
Warm staged, axolotl	Idol Q8 / third-party DINOv3 Q4 and original FLUX.2 autoencoder	30.92 s	2.31 GB	5.42 GB

GB means one billion bytes; MiB means 1,048,576 bytes. PyTorch allocated memory excludes its unused reserved memory, the graphics context, the separately run Iris generator, and other processes. The table does not establish minimum required graphics memory or a distribution of latency. Image generation and Idol run sequentially, so their separate memory peaks must not simply be added. The image-model runner's configured 16 GiB limit is a budget, not a measured peak.

Two separate end-to-end browser prompt trials using Iris-3B Q4, Qwen3-VL-4B Q4, Idol Q8, and original encoders measured the following on the same shared RTX 4090 workstation:

Trial	Browser launch to result	Peak total-device GPU use	Pre-request device use	Peak process-tree working-set sum	Peak process-tree private commit
1	100.16 s	12.85 GB	5.57–5.76 GB	7.43 GB	11.17 GB
2	72.74 s	13.12 GB	5.56 GB	6.87 GB	11.96 GB

The GPU figure covers the entire device, including other applications. Process working sets can count shared pages more than once; private commit includes allocations that may be paged out. Sampling was requested every 0.25 seconds, with observed maximum gaps of 0.31 and 0.34 seconds. Browser launch and page loading are included, while server startup is excluded. The measurement record contains settings, artifact hashes, and limitations. These two runs do not establish a minimum memory requirement or latency distribution.

The third-party DINOv3 Q4 file was tested at revision 7fbb86b66bbb1dd483c94c179d35c969c76467e6; its SHA-256 is cf80ee6e3c2d4044b3214c0ccde5e416cb999b799f35b699f4edaa4059d83d71. It is an experimental compatibility result, not a quality recommendation: for the axolotl image and matched staged settings, its latent differed by 34.17% in relative Euclidean norm from the same Idol Q8 run using the original DINOv3 encoder. One image and seed are insufficient to establish general behavior. The FLUX.2 autoencoder remained at original precision, and its separate terms apply.

A locally built Dockerfile image, using cached intermediate stages, loaded the released Q8 file and original encoders and served one 50-step image-to-3D request in 58.29 seconds including loading. It generated 262,144 finite points and an 80,660-triangle mesh. PyTorch reported 3.51 GB peak allocated graphics memory, excluding the graphics context and other processes. The test record identifies the tested image and scope; this observation is not a latency distribution. Prompt generation and an empty-cache build were not tested by that receipt.

The final release tree was also built as a Docker image and tested with the documented server download path. From an empty Idol cache it downloaded and checked the released file, then produced 262,144 finite Gaussian points in one 50-step image request (74.88 seconds on the shared workstation). Separately gated encoder weights came from an existing read-only cache; intermediate image layers may have been cached. The release verification receipt records exact artifact identities and exclusions.

Mesh fidelity against original Idol

The idol.cpp browser extracts an untextured mesh and compares it with an uploaded reference. A fixed challenge cohort of 32 selected household objects and three matched seeds produced 96 original-versus-eight-bit comparisons, using original-precision encoders, 50 steps and 262,144 Gaussians. The comparison measures agreement with original Idol, not ground-truth 3D accuracy.

Measurement	Mean	Median	Worst observed
Mean mesh distance / original bounding-box diagonal	0.124%	0.089%	1.715%
Mesh F1 within 0.1% of diagonal	68.49%	71.51%	5.24%
Mesh F1 within 0.5% of diagonal	96.74%	98.92%	24.78%
Approximate-view foreground color error	2.22%	1.68%	28.59%
Approximate-view silhouette intersection over union	98.63%	99.38%	64.70%

F1 is the harmonic mean of surface precision and recall within the stated distance. The worst case was Lego Friends Mia at seed 2026. The selected cohort is not a random sample; smoothing and component filtering may hide mesh defects, and approximate views are not upstream rendering. Original-model variation across seeds is context, not an allowance to subtract from quantization error. See the full evaluation and evidence.

A post-hoc probe of the worst case found 1.715% mean mesh distance on the fused replay, 1.395% when reusing the original prepared image, and 0.0378% when the eight-bit decoders were given the original latent. These interventions are conditional and apply to one selected case; they do not prove a general cause. Details and limitations are in the evaluation.

Evaluation limits

The original model used dense operations and the eight-bit artifact used fused packed operations; differences cannot be attributed solely to weights. The cohort is a fidelity study, not an evaluation against aligned ground-truth geometry or a population-wide quality guarantee.

In the 32-object fidelity run, the median of 64 subsequent model-resident calls was 25.57 seconds with original weights and 28.82 seconds with eight-bit weights; median peak PyTorch allocation was 5.37 GB and 4.72 GB respectively. Model loading was excluded, execution order was fixed, and the workstation was shared. These observations do not establish a speed saving or a causal explanation. See the runtime observations.

In two separate fresh-process, load-inclusive requests, the candidate took 34.6 seconds for each image; original-weight requests took 37.0 and 36.0 seconds. The candidate's peak PyTorch graphics allocation was 4.39 GB versus 4.76 GB for the original. Operating-system caches could be warm, these were individual runs, and their timing difference does not establish causation. The candidate did not consistently outperform the original in warm requests. Image generation is additional to these timings.

The Apache License 2.0 for the original Idol model is included as LICENSE.