Certified GGUF Quantization Ladders & Empirical Benchmarks
How Omega Factory evaluates, verifies, and publishes 3-rung post-training GGUF quantization ladders (Q8_0, Q4_K_M, Q2_K) across state-of-the-art Mixture-of-Experts (MoE) and Dense architectures. Every checkpoint is benchmarked on held-out reasoning splits (ARC-MC, GSM8K, MATH-500) with item-level McNemar answer-flip diagnostics and cryptographic SHA-256 provenance markers—compatible out of the box with Ollama and llama.cpp.
- • Qwen3-Coder-Next (79.6B MoE / 3.14B Active): Our
Q4_K_Mrung (48.49 GB, -70% smaller than the 159.46 GB BF16 baseline) scores 97.0% ARC-MC (+0.5 pp), 95.5% GSM8K (0.0 pp, only 2 broke / 2 fixed), and 61.0% MATH-500 (-0.5 pp). Even atQ2_K(29.27 GB, -82% compression), its 512-expert hybrid Gated DeltaNet backbone retains 96.5% ARC-MC and 91.5% GSM8K. - • Muse Glimmer 30B Dense & IBM Granite 4.2 30B Dense: Muse Glimmer 30B
Q4_K_M(16.94 GB, -72% smaller) achieves 96.0% ARC-MC (+0.5 pp), 93.0% GSM8K, and 62.0% MATH-500. Granite 4.2 30BQ8_0(31.11 GB) achieves 0.0 pp net delta across all three benchmarks (92.0% ARC-MC, 94.0% GSM8K, 54.5% MATH-500). - • Gemma 4 31B Dense & Gemma 4 26B-A4B MoE: Gemma 4 31B
Q4_K_M(18.69 GB, -70% compression) improves GSM8K to 87.5% (+1.5 pp) and ARC-MC to 94.5% (+9.5 pp) while exposing a critical 2-bit (Q2_K) multi-step math failure mode documented below. - • LiquidAI LFM2.5-24B-A2B MoE, Qwen3-30B-A3B MoE & Qwen3.8-27B Dense: Full 3-rung precision ladders with 14–16 GB
Q4_K_Mcheckpoints ready for single-GPU 24 GB consumer workstations.
- Certified Releases
- 8 Models4 MoE · 4 Dense
- Immutable Artifacts
- 24 GGUFsQ8_0 · Q4_K_M · Q2_K
- Holdout Evaluations
- 32 MatricesN=200 · Seed 42 · Greedy
- McNemar Diagnostics
- 72 Flip RowsPer-item Broke vs Fixed
The 3-Rung Certified GGUF Precision Ladder
Instead of publishing dozens of unverified quantization shards with unknown accuracy degradation, Omega Factory standardizes every public release around a strict 3-rung post-training quantization (PTQ) ladder (Q8_0, Q4_K_M, Q2_K) benchmarked directly against the unquantized FP16 or BF16 reference weights. We do not train on evaluation holdouts, ensuring zero benchmark contamination across all published checkpoints.
Near-Lossless Reference Rung
8-bit round-to-nearest block quantization with 32 weights per FP16 scale factor (w = q × block_scale). Matches unquantized FP16/BF16 within statistical noise on every evaluated model, achieving 0.0 pp ARC-MC net delta on 7 of 8 releases (+10.0 pp on the 8th) and zero broken ARC-MC answers on 6 of 8 catalog releases.
Production Pareto Sweet Spot
4-bit k-quant mixed precision using 256-weight super-blocks with 6-bit sub-block scales/mins while preserving critical attention & down-projection tensors at higher bit widths. Delivers the highest accuracy-per-gigabyte efficiency and binds our canonical OMEGA_VERIFIED_PUBLIC_MODEL_V1 release marker.
Constrained Edge & Sparse MoE Rung
Extreme 2-bit k-quant super-block compression with 4-bit group scales. Highly effective on fine-grained sparse MoE architectures (Qwen3-Coder-Next, Qwen3-30B-A3B), but exhibits sharp multi-step math degradation on dense architectures (see Section 4).
Cross-Model GGUF Accuracy & Compression Matrix
Every row below is rendered directly from our checked-in evaluation catalog (N=200 deterministic holdout questions per benchmark, seed 42, greedy argmax decoding). Filter by precision rung (Q4_K_M, Q8_0, Q2_K), architecture type (MoE vs Dense), or search by model family.
58.0 GB · 1.00x
ARC-MC
94.5%
GSM8K
59.0%
MATH-500
23.0%
29.05 GB · 0.50x (-50%)
ARC-MC
94.5%
0.0 pp
GSM8K
63.5%
+4.5 pp
MATH-500
22.0%
-1.0 pp
16.81 GB · 0.29x (-71%)
ARC-MC
95.0%
+0.5 pp
GSM8K
33.5%
-25.5 pp
MATH-500
17.5%
-5.5 pp
10.86 GB · 0.19x (-81%)
ARC-MC
93.0%
-1.5 pp
GSM8K
86.0%
+27.0 pp
MATH-500
10.0%
-13.0 pp
48.0 GB · 1.00x
ARC-MC
93.5%
GSM8K
92.5%
MATH-500
49.5%
24.77 GB · 0.52x (-48%)
ARC-MC
93.5%
0.0 pp
GSM8K
94.0%
+1.5 pp
MATH-500
48.5%
-1.0 pp
14.16 GB · 0.29x (-71%)
ARC-MC
93.0%
-0.5 pp
GSM8K
94.0%
+1.5 pp
MATH-500
48.0%
-1.5 pp
8.62 GB · 0.18x (-82%)
ARC-MC
86.5%
-7.0 pp
GSM8K
87.5%
-5.0 pp
MATH-500
38.5%
-11.0 pp
50.5 GB · 1.00x
ARC-MC
92.0%
GSM8K
73.0%
MATH-500
36.5%
26.86 GB · 0.53x (-47%)
ARC-MC
92.0%
0.0 pp
GSM8K
70.5%
-2.5 pp
MATH-500
32.5%
-4.0 pp
16.80 GB · 0.33x (-67%)
ARC-MC
92.5%
+0.5 pp
GSM8K
66.0%
-7.0 pp
MATH-500
23.0%
-13.5 pp
10.58 GB · 0.21x (-79%)
ARC-MC
82.0%
-10.0 pp
GSM8K
4.5%
-68.5 pp
MATH-500
7.5%
-29.0 pp
61.4 GB · 1.00x
ARC-MC
85.0%
GSM8K
86.0%
MATH-500
36.5%
32.64 GB · 0.53x (-47%)
ARC-MC
95.0%
+10.0 pp
GSM8K
84.5%
-1.5 pp
MATH-500
37.0%
+0.5 pp
18.69 GB · 0.30x (-70%)
ARC-MC
94.5%
+9.5 pp
GSM8K
87.5%
+1.5 pp
MATH-500
35.5%
-1.0 pp
11.92 GB · 0.19x (-81%)
ARC-MC
91.0%
+6.0 pp
GSM8K
2.0%
-84.0 pp
MATH-500
6.0%
-30.5 pp
59.55 GB · 1.00x
ARC-MC
95.5%
GSM8K
95.5%
MATH-500
65.0%
29.61 GB · 0.50x (-50%)
ARC-MC
95.5%
0.0 pp
GSM8K
95.5%
0.0 pp
MATH-500
64.0%
-1.0 pp
16.94 GB · 0.28x (-72%)
ARC-MC
96.0%
+0.5 pp
GSM8K
93.0%
-2.5 pp
MATH-500
62.0%
-3.0 pp
10.69 GB · 0.18x (-82%)
ARC-MC
92.0%
-3.5 pp
GSM8K
74.0%
-21.5 pp
MATH-500
32.0%
-33.0 pp
58.56 GB · 1.00x
ARC-MC
92.0%
GSM8K
94.0%
MATH-500
54.5%
31.11 GB · 0.53x (-47%)
ARC-MC
92.0%
0.0 pp
GSM8K
94.0%
0.0 pp
MATH-500
54.5%
0.0 pp
17.72 GB · 0.30x (-70%)
ARC-MC
91.0%
-1.0 pp
GSM8K
92.5%
-1.5 pp
MATH-500
54.5%
0.0 pp
10.86 GB · 0.19x (-81%)
ARC-MC
86.5%
-5.5 pp
GSM8K
68.0%
-26.0 pp
MATH-500
38.0%
-16.5 pp
47.96 GB · 1.00x
ARC-MC
88.0%
GSM8K
78.5%
MATH-500
58.5%
25.49 GB · 0.53x (-47%)
ARC-MC
88.0%
0.0 pp
GSM8K
77.0%
-1.5 pp
MATH-500
54.5%
-4.0 pp
14.53 GB · 0.30x (-70%)
ARC-MC
89.0%
+1.0 pp
GSM8K
78.5%
0.0 pp
MATH-500
50.5%
-8.0 pp
8.81 GB · 0.18x (-82%)
ARC-MC
70.5%
-17.5 pp
GSM8K
54.5%
-24.0 pp
MATH-500
37.5%
-21.0 pp
159.46 GB · 1.00x
ARC-MC
96.5%
GSM8K
95.5%
MATH-500
61.5%
84.81 GB · 0.53x (-47%)
ARC-MC
96.5%
0.0 pp
GSM8K
95.5%
0.0 pp
MATH-500
62.5%
+1.0 pp
48.49 GB · 0.30x (-70%)
ARC-MC
97.0%
+0.5 pp
GSM8K
95.5%
0.0 pp
MATH-500
61.0%
-0.5 pp
29.27 GB · 0.18x (-82%)
ARC-MC
96.5%
0.0 pp
GSM8K
91.5%
-4.0 pp
MATH-500
48.0%
-13.5 pp
Why Aggregate Accuracy & Perplexity Are Not Enough: Item-Level McNemar Flips
As highlighted in the research literature “Accuracy is Not All You Need” (arXiv:2407.09141) and “Which Quantization Should I Use?” (arXiv:2601.14277), evaluating quantized LLMs solely by aggregate accuracy or WikiText perplexity is fundamentally flawed:
The Zero-Net-Delta Illusion (Error Cancellation)
When weights are quantized, some prompts that the FP16/BF16 base model answered correctly flip to incorrect (Flips Broke: Base ✓ → Quant ✗), while other prompts near the decision boundary flip from incorrect to correct (Flips Fixed: Base ✗ → Quant ✓). In aggregate metrics, these opposite flips cancel out!
Example: Granite 4.2 30B (Q4_K_M) scores 54.5% (109/200) on MATH-500 vs 54.5% (109/200) BF16 Base — a 0.0 pp net delta. Yet McNemar tracking reveals 16 broke and 16 fixed (32/200 items = 16.0% behavioral discordance).
Paired Contingency & Exact Identity Verification
Instead of independent averages, Omega Factory evaluates every GGUF rung on the exact same paired items i ∈ {1..200} under deterministic greedy decoding (seed 42) and enforces two algebraic invariants in CI:
When 2-Bit (Q2_K) Breaks Down: Agentic, Coding & Multi-Step Math Workloads
Across our 8 certified model ladders, comparing ARC-MC (single-step multiple-choice science reasoning) against GSM8K and MATH-500 (multi-step chain-of-thought generation) exposes three critical engineering rules for production deployment:
1. Multiple-Choice Accuracy (ARC-MC) Masks Autoregressive Collapse in Dense 2-Bit Models
Critical Production WarningSingle-token multiple-choice evaluation only requires the correct option token (A/B/C/D) to remain the argmax over 4 logits. Multi-step math and agentic tool-calling, however, require generating hundreds of coherent reasoning tokens without a single syntax or arithmetic derailment.
Gemma 4 31B Dense (Q2_K · 11.92 GB)
- • ARC-MC: 91.0% (+6.0 pp vs FP16) — looks healthy!
- • GSM8K: 2.0% (-84.0 pp · 168/200 broke)
- • MATH-500: 6.0% (-30.5 pp · 61/200 broke)
Gemma 4 26B-A4B MoE (Q2_K · 10.58 GB)
- • ARC-MC: 82.0% (-10.0 pp vs FP16)
- • GSM8K: 4.5% (-68.5 pp · 138/200 broke)
- • MATH-500: 7.5% (-29.0 pp · 60/200 broke)
2. High-Granularity Sparse MoE Architectures Survive Extreme Compression Significantly Better
MoE Structural AdvantageWhen total capacity is distributed across many fine-grained routed experts (such as Qwen3-Coder-Next with 512 routed + 1 shared experts and only 3.14B active parameters per token, or Qwen3-30B-A3B with 3.3B active parameters), individual expert quantization noise averages out across top-k routing:
Qwen3-Coder-Next MoE (Q2_K · 29.27 GB · -82%)
- • ARC-MC: 96.5% (0.0 pp vs 159.5 GB BF16)
- • GSM8K: 91.5% (-4.0 pp · 183/200 correct)
- • MATH-500: 48.0% (-13.5 pp · 96/200 correct)
Qwen3-30B-A3B MoE (Q2_K · 8.62 GB · -82%)
- • ARC-MC: 86.5% (-7.0 pp vs 48.0 GB FP16)
- • GSM8K: 87.5% (-5.0 pp · 175/200 correct)
- • MATH-500: 38.5% (-11.0 pp · 77/200 correct)
3. Non-Monotonic Reasoning Trajectories in Vision-Language Dense Backbones (Qwen3.8-27B)
Quantization does not always degrade accuracy monotonically. In Qwen3.8-27B GGUF, greedy decoding on GSM8K shifts from 59.0% (FP16 Base) and 63.5% (Q8_0, +4.5 pp) down to 33.5% at Q4_K_M (-25.5 pp) due to verbosity/stopping-token boundary shifts under 4-bit block scales, while Q2_K (10.86 GB) reaches 86.0% (+27.0 pp, 69 fixed vs 15 broke) as quantization noise suppresses verbose over-thinking loops on grade-school arithmetic—even as harder competition math (MATH-500) follows the expected monotonic curve (23.0% FP16 → 22.0% Q8_0 → 17.5% Q4_K_M → 10.0% Q2_K). This proves why every single quantization rung must be empirically tested across multiple task complexity tiers rather than extrapolated from perplexity.
VRAM & Hardware Selection Guide (12 GB to 96 GB+)
Use this hardware matrix to match your local GPU VRAM or Apple Silicon Unified Memory capacity to the optimal certified Omega Factory GGUF checkpoint. Remember to reserve 2.0–4.5 GB of headroom above the raw GGUF disk size for the KV cache (-c 16384) and CUDA/Metal compute buffers.
RTX 4070 / 4070 Ti / 4080, Mac M-Series 16–24 GB
RTX 3090 / 4090, Mac M-Pro/Max 32–36 GB
RTX 5090 (32 GB), Dual RTX 3090/4090, RTX 6000 Ada, Mac 64 GB
Q8_0 rungs (24.77–32.64 GB)Dual/Quad Workstation GPUs, H100/A100 80GB, Mac Studio M-Ultra
-ngl 99)Running Certified GGUFs with Ollama, llama.cpp & Python
Select any certified model and quantization rung below to generate exact, copy-pasteable CLI commands for Ollama, llama-server (OpenAI-compatible API), llama-cli, MoE CPU expert offloading, and pinned-revision Python downloads.
Stream directly from the Omega-Factory Hugging Face repository:
ollama run hf.co/Omega-Factory/Qwen3-Coder-Next-GGUF:Q4_K_MServe an OpenAI-compatible `/v1/chat/completions` endpoint with Flash Attention:
llama-server -hf Omega-Factory/Qwen3-Coder-Next-GGUF -m Qwen3-Coder-Next.q4_k_m.gguf --host 127.0.0.1 --port 8080 --ctx-size 16384 --n-gpu-layers 99 -fa onRun interactive terminal chat with full GPU layer offload (`-ngl 99`):
llama-cli -hf Omega-Factory/Qwen3-Coder-Next-GGUF -m Qwen3-Coder-Next.q4_k_m.gguf --ctx-size 16384 --n-gpu-layers 99 --temp 0.6 --min-p 0.01 -cnvKeep attention & shared layers in VRAM while offloading routed FFN experts to system RAM:
llama-cli -hf Omega-Factory/Qwen3-Coder-Next-GGUF -m Qwen3-Coder-Next.q4_k_m.gguf --ctx-size 16384 --n-gpu-layers 99 -ot ".ffn_.*_exps.=CPU" --threads 16 --temp 0.6import os
os.environ["HF_HUB_ENABLE_HF_TRANSFER"] = "1"
from huggingface_hub import hf_hub_download
path = hf_hub_download(
repo_id="Omega-Factory/Qwen3-Coder-Next-GGUF",
filename="Qwen3-Coder-Next.q4_k_m.gguf",
revision="9a9112af264ac5baef1b73dea5fc89b5ca632fb3",
)
print("Downloaded:", path)
# Linux / macOS
echo "c6a4c85791cf23606278e3131a0d723d3f720c75d51f4624d99a33e7cff1d6db Qwen3-Coder-Next.q4_k_m.gguf" | sha256sum --check
# Windows PowerShell 7+
(Get-FileHash .\Qwen3-Coder-Next.q4_k_m.gguf -Algorithm SHA256).Hash.ToLower() -eq "c6a4c85791cf23606278e3131a0d723d3f720c75d51f4624d99a33e7cff1d6db"Cryptographic Provenance & SHA-256 Release Attestation
Unverified weight repositories on public hubs can silently mutate when files are re-uploaded. Every Omega Factory release enforces a strict fail-closed cryptographic contract (OMEGA_VERIFIED_PUBLIC_MODEL_V1) binding the recommended GGUF file's SHA-256 digest, the 40-character Hugging Face Git commit SHA, and the checked-in catalog SHA-256 (d853e89023b5b037…).
qwen3.8-27b-gguf-v1
qwen3-30b-a3b-gguf-v1
gemma-4-26b-a4b-gguf-v1
gemma-4-31b-gguf-v1
muse-glimmer-30b-gguf-v1
granite-4.2-30b-gguf-v1
lfm2.5-24b-a2b-gguf-v1
qwen3-coder-next-gguf-v1
Foundational Architecture & Quantization Literature
All public releases and evaluation protocols in the Omega Factory catalog are grounded in peer-reviewed and foundational arXiv literature, indexed via Schema.org ScholarlyArticle citations for Google Dataset Search.
Accuracy is Not All You Need: Measuring Answer Flips in Compressed Large Language Models
Empirical Compression & Discordance Study
Demonstrates that aggregate benchmark accuracy masks high rates of item-level answer flips under quantization and layer pruning, establishing flip discordance and KL divergence as essential post-training evaluation metrics.
Qwen3 Technical Report
Qwen Team, Alibaba Group
Introduces the Qwen3 foundation model suite across dense and Mixture-of-Experts (MoE) architectures, featuring unified thinking/non-thinking modes, dynamic reasoning budgets, and high-efficiency token routing.
Which Quantization Should I Use? A Unified Evaluation of llama.cpp Quantization
Empirical GGUF Research Study
Comprehensive empirical analysis of llama.cpp GGUF quantization schemes (Q8_0, Q4_K_M, Q2_K) across reasoning benchmarks, memory footprints, and CPU/GPU throughput.
Qwen2.5 Technical Report
Qwen Team, Alibaba Group
Foundational architecture, attention mechanisms, and pretraining scale underlying the predecessor Qwen2.5 dense models.
Gemma 4 Technical Report
Gemma Team, Google DeepMind
Presents the Gemma 4 open-weight model family, introducing multimodal dense and MoE architectures, native thinking reasoning traces, and unified encoder-free audio and image processing.
Gemma: Open Models Based on Gemini Research and Technology
Gemma Team, Google DeepMind
Foundational architecture, safety evaluations, and training methodology derived from Google Gemini research and technology.
DFlash: Block Diffusion for Flash Speculative Decoding
Jian Chen, Yesheng Liang, Zhijian Liu
Speculative decoding framework using lightweight block diffusion for parallel token drafting, achieving over 6x lossless acceleration and integrated into Muse Glimmer's native speculative architecture.
Perception Encoder: The best visual embeddings are not at the output of the network
Daniel Bolya, Po-Yao Huang, Peize Sun, et al.
State-of-the-art vision perception encoder (ViT-G/14, ~1.8B parameters) powering Muse Glimmer's multimodal interleaved image and text understanding.
Granite Code Models: A Family of Open Foundation Models for Code Intelligence
IBM Research Granite Team
Introduces IBM Granite decoder-only foundation models trained on 116 programming languages with rigorous data governance, enterprise safety compliance, and tool calling.
LFM2 Technical Report
Liquid AI
Introduces Liquid Foundation Models (LFM2), a hardware-aware hybrid architecture combining gated short convolutions with grouped-query attention and sparse mixture-of-experts routing for fast, low-memory on-device inference.
Gated Delta Networks: Improving Mamba2 with Delta Rule
Songlin Yang, Jan Kautz, Ali Hatamizadeh
Introduces Gated DeltaNet linear attention combining gating and delta-update memory rules, forming the 3:1 hybrid Gated DeltaNet + Gated Attention backbone of Qwen3-Coder-Next.
Frequently Asked Questions on GGUF Quantization
Which GGUF quantization should I use: Q8_0, Q4_K_M, or Q2_K?
For 90% of local and production deployments, Q4_K_M is the recommended sweet spot: it reduces model disk and memory footprint by 67%–72% compared to FP16/BF16 while preserving near-baseline accuracy across science (ARC-MC) and mathematical reasoning (GSM8K, MATH-500). Choose Q8_0 (~47%–50% compression) when you have 32–96 GB of VRAM/Unified Memory and require virtually zero item-level discordance on complex coding or formal math. Reserve Q2_K (~79%–82% compression) strictly for memory-constrained edge hardware or high-granularity MoE architectures (such as Qwen3-Coder-Next or Qwen3-30B-A3B) where sparse routing preserves reasoning better than dense 2-bit quantization.
Why does Omega Factory report McNemar discordance flips instead of only perplexity or aggregate accuracy?
As demonstrated in 'Accuracy is Not All You Need' (arXiv:2407.09141), aggregate benchmark scores and corpus perplexity can hide substantial behavioral drift because questions that break under quantization (Base ✓ → Quant ✗) and questions that stochastically flip from wrong to right (Base ✗ → Quant ✓) cancel each other out in the mean. For example, Granite 4.2 30B Q4_K_M achieves 54.5% on MATH-500 — an exact 0.0 pp net delta against its BF16 baseline — yet item-level McNemar tracking over N=200 holdout prompts reveals 16 broken answers and 16 fixed answers (16.0% total discordance). Publishing both Flips Broke and Flips Fixed exposes the true trajectory stability of every GGUF rung.
Why shouldn't 2-bit (Q2_K) GGUFs be used uncritically for agentic tool calling and math?
Multiple-choice benchmarks like ARC-MC evaluate single-token log-probability ranking, which remains resilient even under extreme 2-bit quantization. However, multi-step autoregressive generation (such as GSM8K, MATH-500, and structured JSON tool calling) compounds quantization noise across hundreds of generated tokens. On dense models like Gemma 4 31B Dense, Q2_K retains 91.0% on ARC-MC (+6.0 pp) while collapsing on GSM8K from 86.0% to 2.0% (-84.0 pp, with 168/200 answers broken). Always inspect multi-step generative benchmarks (GSM8K and MATH-500) before deploying extreme low-bit quants in agentic pipelines.
How do I run Omega Factory GGUF models directly from Hugging Face with Ollama or llama.cpp?
All Omega Factory repositories use standard GGUF v3 metadata compatible with direct Hugging Face streaming. With Ollama, run `ollama run hf.co/Omega-Factory/<Repo-Name>:Q4_K_M`. With llama.cpp, run `llama-cli -hf Omega-Factory/<Repo-Name> -m <filename.gguf> -ngl 99 -c 16384` or launch an OpenAI-compatible HTTP server via `llama-server -hf Omega-Factory/<Repo-Name> -m <filename.gguf> --port 8080 -ngl 99`.
How can I run an 80B MoE model like Qwen3-Coder-Next on a single 24 GB GPU?
Qwen3-Coder-Next has 79.6B total parameters (48.49 GB in Q4_K_M) but activates only 3.14B parameters per token across its 512 routed + 1 shared experts. Using llama.cpp's tensor override flag (`-ot ".ffn_.*_exps.=CPU"`), you can keep all shared attention layers, router gates, and KV cache on your 24 GB GPU while streaming sparse FFN expert weights from dual-channel DDR5 system RAM—preserving Q4_K_M reasoning quality (97.0% ARC-MC, 95.5% GSM8K, 61.0% MATH-500) without dropping to ultra-low bit widths.
How do I verify the cryptographic integrity and provenance of a downloaded GGUF file?
Every Omega Factory release binds its artifacts to an immutable 40-character Hugging Face Git commit SHA and a 64-character SHA-256 digest in our checked-in catalog (`src/data/public-model-catalog.json`). Run `sha256sum <filename.gguf>` on Linux/macOS or `Get-FileHash <filename.gguf> -Algorithm SHA256` in PowerShell and compare the output against the pinned SHA-256 hash and `OMEGA_VERIFIED_PUBLIC_MODEL_V1` release marker on the model's detail page.
Production Model Optimization
Need a custom precision ladder or private model compression?
Explore all 8 public certified GGUF releases in our catalog, or partner with Omega Factory to compress, prune, and verify your proprietary checkpoints against your internal domain holdouts.
Docs bound to Catalog public_model_catalog_v1 · generated 2026-10-14T08:00:00Z · sha256 d853e89023b5b0378c96b28cf519639e2b0bb9b774d171f1fe1e0dbcc48b68f8