First ever quantized GGUF of 1Covenant/Covenant-72B-Chat -- a 72.7 billion parameter model from the Bittensor/Templar network, fine-tuned for chat.
Quantized and published by the LITCOIN team. Nobody else has successfully quantized this model. If you're here, you're getting the only working GGUF in existence.
Downloads
File
Quant
Size
BPW
Notes
covenant-72b-q3_K_S.gguf
Q3_K_S
30.06 GB
3.55
Best for 32GB RAM + 12GB VRAM
Quick Start
Download the GGUF, run the server, open the browser. Three steps.
1. Get llama.cpp
Download the latest release for your OS from llama.cpp releases. You need llama-server and llama-quantize.
2. Download the GGUF
bash
1# Option A: huggingface-cli (recommended for large files)2pip install huggingface_hub
3huggingface-cli download litcoin/Covenant-72B-GGUF covenant-72b-q3_K_S.gguf --local-dir .45# Option B: Direct download (30 GB)6wget https://huggingface.co/litcoin/Covenant-72B-GGUF/resolve/main/covenant-72b-q3_K_S.gguf
1import requests
23r = requests.post("http://localhost:8080/v1/chat/completions", json={4"messages":[{"role":"user","content":"Write a Python function to sort a list."}],5"max_tokens":3006})7print(r.json()["choices"][0]["message"]["content"])
Covenant-72B uses the Gemma chat format. llama-server auto-detects this from the GGUF metadata.
<start_of_turn>user
Hello<end_of_turn>
<start_of_turn>model
Hi there<end_of_turn>
Mining on LITCOIN
This model can mine on the LITCOIN proof-of-research network, solving real scientific and computational problems from databases like Codeforces, Project Euler, Rosalind, HuggingFace, and ARC for token rewards.
bash
1# 1. Start the model server2llama-server -m covenant-72b-q3_K_S.gguf -ngl 30 -c 1024 -np 1 --host 0.0.0.0 --port 808034# 2. Download and run the LITCOIN miner5# Get the miner from https://litcoiin.xyz/litcoin_miner.py6# Set these in the CONFIG section:7# BANKR_API_KEY = "bk_YOUR_KEY"8# AI_BASE_URL = "http://localhost:8080/v1"9# AI_API_KEY = "ollama"10# MODEL = "covenant-72b"1112python litcoin_miner.py --relay
The --relay flag also registers you as a compute provider on the LITCOIN network. Other users can route inference requests through your model, burning LITCREDIT while you earn LITCOIN at 2x mining weight.
The original Covenant-72B-Chat model has a tokenizer bug that blocks every standard quantization path. No one else has published a working GGUF because of this. Here's what's broken and how we fixed it.
The Problem
The model's tokenizer contains 262,145 tokens (including <image_soft_token> at ID 262144), but the embedding matrix (token_embd.weight) has only 262,144 rows. This off-by-one mismatch causes llama.cpp to reject the model at load time:
Every quantization tool fails. Ollama can't load it. The standard convert_hf_to_gguf.py pipeline crashes or produces a broken GGUF.
What We Tried (And Why It Failed)
Attempt 1: Edit tokenizer JSON files. We wrote fix_vocab.py to remove token 262144 from tokenizer.json, tokenizer_config.json, and added_tokens.json. The JSON was clean, but convert_hf_to_gguf.py reads token data from the sentencepiece model internally, not from the JSON. The GGUF still came out with 262,145 tokenizer entries.
Attempt 2: Binary patch the GGUF. We tried patching the array length headers directly in the GGUF binary (replacing 262145 with 262144 in the metadata). This changed the array lengths but left orphaned token data in the file, corrupting the GGUF parser. The model wouldn't load at all -- key '<image_soft_token>' has invalid GGUF type 21.
Attempt 3: --override-kv flag. llama.cpp supports metadata overrides at runtime. We tried --override-kv llama.vocab_size=int:262144. This changes the reported vocab size in metadata, but the tokenizer arrays (tokenizer.ggml.tokens, tokenizer.ggml.scores, tokenizer.ggml.token_type) still have 262,145 entries. llama.cpp computes expected tensor dimensions from the actual tokenizer array length, not the metadata field. The shape mismatch persisted.
Attempt 4: Remove from model.vocab inside tokenizer.json. The extra token wasn't actually in model.vocab (max ID was 262143). It only existed in added_tokens. And rewriting the 33 MB tokenizer.json on Windows hit a cp1252 encoding error that corrupted the file mid-write. Had to re-download the tokenizer from HuggingFace.
The Fix That Worked
Patch convert_hf_to_gguf.py line ~1714. The converter has an assert that enforces len(tokens) == vocab.vocab_size. The sentencepiece tokenizer reports 262,145 tokens. Instead of asserting, we truncate the arrays to match the embedding matrix:
This caps the tokenizer arrays to 262,144 (matching config.json's vocab_size and the embedding matrix) BEFORE writing to the GGUF. The resulting file has perfectly matched dimensions. llama.cpp loads it cleanly.
Combined with fix_vocab.py (which cleans the JSON files the converter also reads), the full pipeline produces a working GGUF on the first try.
Full Reproduction Steps
If you want to quantize Covenant-72B yourself (different quant level, etc):
bash
1# 1. Download the model (~145 GB)2huggingface-cli download 1Covenant/Covenant-72B-Chat --local-dir Covenant-72B-Chat
34# 2. Fix the tokenizer JSON (removes <image_soft_token> from added_tokens)5python fix_vocab.py Covenant-72B-Chat
67# 3. Patch the converter (one line change at line ~1714)8python fix_converter.py
910# 4. Convert to f16 GGUF (~7 minutes, produces ~145 GB file)11python convert_hf_to_gguf.py Covenant-72B-Chat --outfile covenant-72b-f16.gguf --outtype f16
1213# 5. Quantize to your preferred level (~6 minutes for q3_K_S)14llama-quantize covenant-72b-f16.gguf covenant-72b-q3_K_S.gguf q3_K_S
1516# 6. Run17llama-server -m covenant-72b-q3_K_S.gguf -ngl 30 -c 1024 -np 1 --host 0.0.0.0 --port 8080
Available quant options (pick one for step 5):
Quant
Size
Quality
Use case
q2_K
~26 GB
Lower
Minimum viable, fits in 32 GB RAM
q3_K_S
~30 GB
Good
Best balance for 32 GB RAM + consumer GPU
q4_0
~39 GB
Better
Needs 48+ GB RAM
q4_K_M
~42 GB
Great
Needs 48+ GB RAM
q5_K_M
~50 GB
Excellent
Needs 64 GB RAM
Helper Scripts
fix_vocab.py -- Removes the phantom token from tokenizer JSON files:
python
1import json, sys, os
23model_dir = sys.argv[1]iflen(sys.argv)>1else"Covenant-72B-Chat"4bad_id =26214456# Fix tokenizer.json7tp = os.path.join(model_dir,"tokenizer.json")8withopen(tp,"r", encoding="utf-8")as f:9 t = json.load(f)10t["added_tokens"]=[tok for tok in t.get("added_tokens",[])if tok.get("id")!= bad_id]11withopen(tp,"w", encoding="utf-8")as f:12 json.dump(t, f, ensure_ascii=False)1314# Fix tokenizer_config.json15cp = os.path.join(model_dir,"tokenizer_config.json")16withopen(cp,"r", encoding="utf-8")as f:17 c = json.load(f)18ifstr(bad_id)in c.get("added_tokens_decoder",{}):19del c["added_tokens_decoder"][str(bad_id)]20withopen(cp,"w", encoding="utf-8")as f:21 json.dump(c, f, ensure_ascii=False, indent=2)2223print("Done. Vocab fixed.")
fix_converter.py -- Patches the assert in convert_hf_to_gguf.py:
python
1lines =open("convert_hf_to_gguf.py","r", encoding="utf-8").readlines()2for i, line inenumerate(lines):3if"assert len(tokens) == vocab.vocab_size"in line:4 lines[i]=' tokens = tokens[:self.hparams.get("vocab_size", len(tokens))]; scores = scores[:len(tokens)]; toktypes = toktypes[:len(tokens)] # truncate to embedding size\n'5print(f"Patched line {i+1}")6break7open("convert_hf_to_gguf.py","w", encoding="utf-8").writelines(lines)8print("Done. Converter patched.")
Note to the Templar Team
The root cause is that <image_soft_token> (ID 262144) exists in the tokenizer but has no corresponding row in the embedding matrix. The config.json correctly says vocab_size: 262144, but the sentencepiece model and added_tokens contain 262,145 entries. Removing the phantom token from the HuggingFace upload would fix this for everyone downstream.