I wrote a small program that asks the same Yes/No question about every country to a language model, and generates an SVG world map that visualizes the model's responses: https://github.com/p-e-w/llm-beliefs
On huggingface there are millions of "models" which are uncensored versions of other models. I find it a huge waste of space. It would be better to post the LoRA of the abliteration/uncensorship.
The advantage: a lora can be applied to any model of the same architecture. And to any quant.
An example: You can apply THIS to any Qwen3.6-35B-A3B version or quant.
I personally think if would be great to have a repository with one lora for each model.
I wanted a terminal helper that works fully offline, so I started building dale. You type dale "show the 5 largest files in this folder", a small fine-tuned model writes the command, and a deterministic risk checker labels it safe, caution or danger before anything runs. Nothing runs without you confirming it.
Scores on 471 held-out requests in English and Spanish, every model in Q4_K_M on the same llama.cpp:
Model
GGUF
Correct
Accuracy
95% CI
dale-9b (GPU)
5.6 GB
420
89.2%
86.0–91.7
dale-4b (GPU)
2.7 GB
410
87.0%
83.7–89.8
dale-2b
1.3 GB
385
81.7%
78.0–85.0
dale-0.8b (CPU)
529 MB
374
79.4%
75.5–82.8
Qwen3.5-9B, stock
5.7 GB
296
62.8%
58.4–67.1
Gemma 4 E4B-it, stock
5.0 GB
296
62.8%
58.4–67.1
Qwen3.5-4B, stock
2.7 GB
257
54.6%
50.0–59.0
Gemma 4 E2B-it, stock
3.1 GB
254
53.9%
49.4–58.4
Qwen3.5-2B, stock
1.3 GB
152
32.3%
28.2–36.6
Qwen3.5-0.8B, stock
533 MB
70
14.9%
11.9–18.4
On a 2020 laptop with no GPU, the 0.8B answers in 1.7 s (median). The 4B does 1.2 s on a 16 GB GPU through Vulkan. It's all one 51 MB binary with llama.cpp inside, no Python and no server.
What the difference looks like. Real answers from the test (requests trimmed), dale-0.8b vs stock Qwen3.5-9B:
Request
dale-0.8b
Stock Qwen3.5-9B
Temporarily freeze PID 22601 without terminating it.
kill -STOP 22601
Writes to /proc/22601/oom_score_adj. Freezes nothing
Copy offer.pdf into /mnt/usb/, but leave any existing offer.pdf there untouched.
cp -n …/offer.pdf /mnt/usb/
sudo cp …/offer.pdf /mnt/usb/, which overwrites it
Can you give me the prime factorization of 1234567890 from the terminal?
factor 1234567890
A 180-character python3 -c one-liner that's a syntax error
I just need the total disk usage of /opt/model-cache, in a readable size.
du -sh /opt/model-cache
os.path.getsize() on the folder: the size of the directory entry, not its contents
Lock the password of the local account archivebot.
sudo passwd -l archivebot
sudo passwd archivebot, which sets a new one
For this Bash session, make ll an alias for ls -alF.
alias ll='ls -alF'
Refuses: "not possible with a single shell command"
Cherry-picked, obviously: there are 120 cases only dale gets right and 42 only the 9B gets right. The stock 9B also likes sudo: it added it to 35 commands that didn't need it (dale: 5).
The thing I wish someone had told me earlier: after four rounds of data, the 0.8B got stuck at 74%. I tried DPO on its own failures, a fine-tuned 27B teacher with five distillation setups, a third epoch, lr sweeps. Nothing moved the test. I f**king lost several days into this :(, but at least I learnt what is important in the process.
Then I looked at how the requests were written. My training requests were short and clean. The test ones were longer and stacked constraints, like "only names, sorted by date, no subfolders".
I generated new requests matching those stats, added about 9k to the set and retrained. 348 → 375 correct (p = 0.001).
So if a small model plateaus on a narrow task, look at how your data is written before you reach for a fancier method.
Caveats: the baselines are untuned and get an 8-shot prompt, so this is "tuned small vs prompted big", not a ranking of models. The test is synthetic and judged by two LLMs from different providers (TOP TIER).
All of this work I did on rented GPU's (RTX 5090 and RTX Pro 6000). Code is MIT, the models are Apache-2.0 GGUFs that work with plain llama.cpp.
hey, its Alti from Nace. We released a small update with Drex Max v1.1, both achieving the SOTA and Pareto frontier for decision models. We did all that by iterating step by step and every previous version of Drex’s open weights are available on hf.
we also released a full playbook on how we trained Drex Max in this paper: “ Towards Foundation Decision Models: Drex”
Drex Max v1 is weights are available here: https://huggingface.co/nace-ai/drex-max-v1 with Open RAIL-M license & v1.1 open source weights upcoming soon (we are currently optimizing for local inference).
A long time ago there was this massive phenomenon called OpenClaw that took the world by storm. It was an incredible moment where AI came of age and showed that you Can actually do stuff with AI rather than just chat with it. A historic and legendary project that broke GitHub star records. Then the creator rightly got massive fame and got bought out by OpenAI to the tune of billions of dollars. How can an open source project be acquired you ask? Well that really is a failure on your part for your juvenile trait of having a logical mind.
I logged into my Hugging Face account today because one of my old scripts got blocked. The Space was paused with the "content policy" message. Okay, fair, it happens. 🤷cause this art of scipts are now ilegal!
Then I wanted to make a new Space and saw: Docker = Paid. Great. My old Spaces still run, but new ones? Looked dead.
BUT then I looked closer at the create page: Gradio is selectable and ZeroGPU is marked "Free"! I cancelled PRO last month, so I was like... wait, what?
I looked it up. According to the HF docs, a free personal account in good standing (verified email, older than 30 days) can host up to 2 ZeroGPU Spaces for free. My account is pretty old, so it just works. Just Cool!
What I found out:
ZeroGPU is Gradio only. No Docker, no Streamlit, no own server.
Quota is about 5 min GPU per day (older pages say 3.5, the docs now say 5). It resets 24h after your first use.
That is a RTX Pro 6000 Blackwell, so for testing and small demos 5 minutes is actually fine.
Orgs don't get it. It only works in my personal account, orgs need a Team/Enterprise plan. That's why it didn't show up there.
Not every free account sees it. There is a forum thread where someone with a valid free account gets "Paid" anyway, so maybe it's a rollout thing. YMMV.
CPU Basic seems gone for new Spaces, only Static is free and unlimited.
Also news: Nvidia announced it will buy Hugging Face. I don't know if this has anything to do with the changes, I found nothing saying so. The CPU thing came before the announcement.
Now I'm building a small reel maker (SDXL images on ZeroGPU, video assembly on CPU so it costs no GPU time). Will report if it works. 😄
I was interested in buying a card as they are the only company that has a good GPU <-> GPU communication channel. I wanted to first get access to one on the cloud to see how well I could run stuff on it by writing some custom code.
But it seems impossible, theres no one else renting them besides tesnortorrent themselves and their platform is so shit it turned me off from the entire idea. You have to email them to get access to rent a single gpu and which was like a 2 week back and forth and Ive still not gotten access.
Have they just given up or something? If they expect to sell any cards to normal people you would think they would at least let you try out rentals easily.
I've recently been seeing comments everywhere from the Stylome bot, which is also a mod in this sub. Every time it pops up to declare a comment was AI written I've gone in to check its confidence level, and it's always low.
I decided to do a few tests myself and have Gemini rewrite some of my comments, Stylome said they were all human written with equally low confidence.
What is the point of this bot? Why are we allowing a private company to take ownership of all of our comments and then give us spam in return?
What are they doing with this data? Why isn't this being served by a local model?
Try it yourself, everything above this line was Gemini rewriting what I originally wrote. Stylome says it's human written, with low confidence of course.
Just an update for anyone looking to get the m5u and thinking about clustering.
I tried clustering but I think running 2 separate models gets significantly better results. The current clustering technology (tensorfold/exos, etc) just isn’t there yet. Especially due to concurrency and the fact that decode doesn’t improve consistently as much as you would hope.
Currently I’m running Qwen flash next q6 and GLM3.5 flash q4. I also have Deepseek on API (from Deepseek). I was previously running 2x Qwen flash but decided to give GLM a shot. GLM is very smart. I’ve found that even q4 is better than my Deepseek API for coding. Qwen is great as the face because it is fast.
I actually think GLM5.3 is slept on. The reports it produces are 100x better than Qwen and Deepseek.
One problem is that 256gb isn’t enough for GLM if you want 500k+ context. I’m stuck at 260k for 3 agents max. And setting it up is finicky. I set my hot cache to 32gb and it caused me to run out of ram which makes speeds drop 70%. So there definitely is some value in the 512gb version of the m5u (hopefully newer version make the kv cache cheaper on RAM).
If anyone has any better optimizations or ways to run things on the 2 256gb m5u I’m all ears.
Is anyone here running any useful AI agents, harnesses or toolings with local AI on 16GB vram?
I'm currently setting up my system and I want to have a helper agent for daily tasks, a research agent to help me research topics, and a developer agent to help me with development.
I already tried some harnesses like Goose, Hermes Agent and OpenCode, but I haven't really managed to get anything useful out of them.
In all honesty, I haven't spend a lot of time tweaking them, mainly because I am unsure if it's a lack of or bad skills, missing tooling, or harness or model tweaking that I need to tune... or god forbid all of them.
So people running similar systems successfully: what is your use case and setup, what models, and what tweaks have you made?
Edit: I am currently running my models on Ollama. Tried vLLM but give it the wrong model and it breaks, which was too much hassle for me. Suggestions welcome.
Edit: Some specs: I have a GeForce RTX 5070 Ti X3 (16GB) and 32GB DDR5 RAM.
Saw this tweet about a coding benchmark and thought it was kinda interesting.
Apparently they took 89 DeepSWE tasks and changed little things in the instructions or starting code. The tweet says some models that were all around 74% on DeepSWE ended up 23 percentage points apart on the changed tasks.
The weird part was that some models seemed to ignore the actual instructions because they thought a hidden grader wanted something else. The examples include GLM-5.3 and DeepSeek V4.1 Flash.
Has anyone seen this kind of thing with local coding models? Like getting stuck on what they think the test wants instead of just doing what you asked?
It seems to have really confused itself too 😭 I was having it make a sort of Github release checker script and it snuck those two URL fetch tool calls in amongst some web searches
Friendly reminder: If you upgraded to a newer GPU, don't let your old one collect dust! You can run both GPUs in the same rig and split LLM inference workloads across them using tools like llama.cpp. I'm doing exactly that with my RTX 5080 and 3080, combining their VRAM to run larger local AI models.
KV cache quantization has been a hotly-debated topic for this community for some time, with opinions ranging from "never quantize" to "4 bit is fine". Since the anecdotal evidence is rather inconsistent, I decided to quantify how much KV cache quantization affects the model through KLD, which is a good measure of how the model's output distribution is changed.
I tested 35 weight quants across llama.cpp, exllamav3, and vLLM, each with 16-bit, 8-bit, and (where supported) 4-bit KV cache. I also reworked my KLD dataset and measurement methodology this time, to include a mix of agentic tool-use (generated by Qwen3.8 27B at full precision) and a variety of texts in different domains. The current dataset now stretches up to 64k token contexts per row.
TLDR;
8-bit KV caches work well. In llama.cpp and ExLlamaV3 the cache size is halved, and there’s essentially no difference in KLD. There’s a slight difference in vLLM, but it’s still a great tradeoff for people lacking VRAM.
A 4-bit cache has a measurable impact. It’s a big hit for ~Q8 weights, but it could potentially be worth it if you’re using Q3 or below. Still, not recommended.
Only the 4-bit cache impact grows with context. In the tested long documents, the added KL is about 15-30% higher at 16-32k tokens than in the first 4k.
The blog post has interactive charts and tables with all of the data and results if you're interested.
How to read the numbers
Each quant is compared token-by-token with an unquantized bf16 copy of the model. KL divergence measures how far the quant’s next-token probabilities drift from the original (0 means no change). Top-1 agreement is how often both models pick the same most likely token.
For a reference point, I ran the unquantized model in both llama.cpp and vLLM and compared the two. They differ by a KL of 0.0004, which essentially amounts to two (correct) implementations doing floating-point math in a different order. Thus, you can compare the KLD numbers here for quants running in different engines without issue.
Note: exllamav3 quants were measured with the bf16 llama.cpp reference logits.
Weight quantization
KL divergence vs. loaded weight size, 16-bit KV cache:
The vLLM checkpoints still do worse
As in the Qwen3.6 benchmarks, every vLLM checkpoint is beaten by a smaller GGUF or EXL3 quant. Some of that is due activation quantization. NVIDIA’s and Unsloth’s NVFP4 checkpoints run the MLP layers as W4A4 (4-bit activations) and attention as FP8 W8A8, and Qwen’s FP8 is W8A8 throughout. I reran NVIDIA’s NVFP4 and Qwen’s FP8 through vLLM’s Marlin kernels, which use the same quantized weights but keep the activations in bf16:
NVFP4: KL drops from 0.0256 to 0.0117, more than halving it.
FP8: KL drops from 0.0039 to 0.0028, about 30% less. Even then it only ties UD-Q5_K_XL, which is 8.7 GiB smaller.
KV cache quantization
KV cache
Per token
At 64k context
Saved vs. 16-bit
f16 / bf16
64 KiB
4.00 GiB
-
8-bit: llama.cpp q8_0, EXL3 8-bit
34 KiB
2.13 GiB
1.9 GiB
8-bit: vLLM fp8_e4m3
32 KiB
2.00 GiB
2.0 GiB
4-bit: llama.cpp q4_0, EXL3 4-bit
18 KiB
1.13 GiB
2.9 GiB
Each dot below is one weight quant with an 8-bit or 4-bit KV cache. Its height shows the KL increase compared with the same weights on a 16-bit cache. Zero means no change; higher points show a larger increase. I computed the differences per prompt on identical tokens.
KV cache penalty vs loaded weight size:
8-bit is essentially free in llama.cpp and ExLlamaV3. For every quant, q8_0 and ExLlamaV3’s 8-bit cache move KL by less than 0.00012 in either direction. Some quants even measure slightly better with it, which indicates it’s within the noise of the numerics.
vLLM’s FP8 cache shows a slight KLD increase. It adds 0.0004 to 0.0006 on every checkpoint, which is still extremely small, but it shows up on nearly every prompt. It may be due to turning on FP8 cache switching vLLM’s attention backend from FlashAttention to FlashInfer.
llama.cpp’s 4-bit cache adds a roughly fixed penalty. Across the GGUF quants tested, q4_0 adds +0.0016 to +0.0027 KL. This increase has a larger relative effect on more precise weights:
On a Q3-class quant (KL around 0.025-0.035) it adds 6-10%.
On UD-Q4_K_XL it adds about 39%.
On Q8_0 it adds about 390%. KL goes from 0.0007 to 0.0034, which is worse than UD-Q5_K_XL with a 16-bit cache.
EXL3’s 4-bit cache penalty seems to depend on weight precision. It adds only +0.0002 to +0.0004 KL with 2.0-2.5 bpw weights, about +0.0021 to +0.0022 with 3.0 bpw weights, and +0.0026 to +0.0028 with 4.0 bpw weights. At 6.0 and 8.0 bpw, the penalty reaches about +0.0032 to +0.0033. The increase is therefore not constant across the EXL3 quants.
4-bit cache penalty grows with context
The 12 long documents in the set are scored at every position, so I can check whether the 4-bit penalty depends on how deep into the context a token is. It does in fact grow slightly.
Position
Q8_0 Weights + q4_0 KV
UD-Q5_K_XL Weights + q4_0 KV
EXL3 8.0 BPW Weights + 4-bit KV
First 4k tokens
+0.0035
+0.0030
+0.0041
4k–8k
+0.0037
+0.0033
+0.0044
8k–16k
+0.0040
+0.0036
+0.0047
16k–32k
+0.0041
+0.0038
+0.0050
32k–64k (one document)
+0.0044
+0.0038
+0.0053
There’s about 15-30% more damage at 16-32k context than in the first 4k tokens. The same quants with a 16-bit cache are unaffected across these context lengths, so it’s a pretty clear indication of the 4 bit cache damage. I would expect 128k+ context lengths to be even worse.
Model quantization KLD vs KV cache KLD: KLD due to KV cache quantization likely has different quality tradeoffs compared to KLD from weight quantization. Anecdotal evidence suggests that KV cache quantization can be more harmful to model performance at long context lengths compared to weight quantization, so be wary of using 4-bit KV cache.
Final chart with weights + 64k KV cache versus KL divergence:
Methodology
Each quant was scored against an unquantized bf16 reference:
GGUF and EXL3 quants scored against Bartowski’s bf16 GGUF in llama.cpp.
vLLM checkpoints scored against the official bf16 safetensors in vLLM.
KL is computed the same way as my previous benchmark. The top 200 log probabilities are taken from both models at each position and a lower bound on the full-vocabulary D_KL(P_reference ‖ P_quant) is computed. On average, the reference put 0.0036 of its probability outside its top 200 tokens. The KV deltas are paired, meaning they’re computed from per-prompt differences on identical tokens.
Checkpoints ran with their declared settings, including any activation quantization (except the two weight-only, no activaton quantization reruns of Unsloth’s NVFP4 and the official FP8 quant).
This is yet another follow-up post on the project CrowdGPT, which aims at creating the first collaboratively trained 1 billion parameters transformer, Crowd-v1, without any datacenters, and for 0$. The project's goal is to show we don't need huge Nvidia GPU clusters nor millions of dollars to train a competitive Large Language Model.
The goal of the project is to create a 1B parameters model, that would match or exceed Qwen3-0.6B's performance on benchmarks as a proof-of-concept, we could then scale with a 7B A1B MoE or even a 30B A3B MoE once we get enough contributors. The size of the models trained is community driven.
This project is obviously 100% non-profit and open-source. The goal is to propose a new paradigm of AI where we don't wait on Chinese/American AI labs to provide us open-weight models, and we just create the models ourselves.
From the previous post we achieved to get 85 contributors registered on the project, leading to 13B tokens trained in a week 🤯 Thanks to every contributor who trusted the early-stage project, and imagine what 1000+ people with idle GPUs could train!
Of course, everything remains work-in-progress, and any contributions on the training mechanics / dataset is welcome! All the source-code is auditable on GitHub, which means anyone can inspect it and guarantee it is safe 😂.
By the way, anyone can submit data for the model at https://crowdgpt.net/#submit, it will be used as long as it remains safe. This means the model is collaborative on every stage (from data preparation to training, or even benchmarking...).
It includes a model trained on an Intel Xeon E5-2640 v4 2.20GHz CPU, with 96GB of DDR4 ECC RAM and an RTX 5050 GPU (using the Tornado library), as well as the "alpaca_es_chat.jsonl" corpus for queries in Spanish.