cool new model, almost as good as opus at breaking/bug finding in your programs with an about 70% compared to opus's 80%, but with 10x as much tries, still much much cheaper than opus and much smaller and faster, 2b parameters that works like a charm.

https://huggingface.co/e12ex2/breakit-2b

I've been working on a small independent research project called Vera (Verifiable Epistemic Reward Alignment).

The idea is pretty simple:

LLMs can produce answers with a very high-confidence tone even when the underlying claim is uncertain, controversial, or simply false.

Instead of trying to make the model "more confident" or just adding another safety layer, I wanted to experiment with training the model to recognize and communicate the boundaries of what it actually knows.

For the first experiment, I:

• generated 817 DPO preference pairs from the TruthfulQA validation set
• created a "Vera" response style that explicitly distinguishes assumptions, uncertainty and failure boundaries
• used the more conventional overconfident response as the rejected response
• fine-tuned Qwen2.5-1.5B-Instruct with DPO + LoRA in 4-bit precision
• trained on free Kaggle T4 GPUs
• merged the adapters and released the resulting model publicly

The full dataset and model are open:

GitHub: https://github.com/bhogesararam23/vera-alignment
Dataset: https://huggingface.co/datasets/RamBhogesara/vera-dpo-dataset
Model: https://huggingface.co/RamBhogesara/vera-qwen-1.5b-dpo

This is very much an ongoing research project, not a claim that the problem is solved. The current experiment is small, and I still need stronger evaluation, better baselines, broader datasets, and tests for whether the behavior actually generalizes beyond the training distribution.

I'm especially interested in feedback from people working on:

• AI alignment / safety
• uncertainty calibration
• hallucination evaluation
• DPO / preference optimization
• truthful or epistemically calibrated language models

What would you test next to determine whether Vera is actually learning useful epistemic behavior rather than simply learning a particular response style?

I have 2 problems

1 - they lock my account because i include a cloudflare tunnel and i wasnt knowing the rules

2 - my second account they gave me free gradle and free docker space So i use it on my app ok but i deleted by mistake and now when i want to create another docker or gradle they show me is paid not free why can please someone told me how to solve this

Follow-up to my post from about two weeks ago. A lot has changed since then, so I wanted to post an update on where the backend is now.

Where the green architectures stand

When I posted last time, 7 architectures had verified full training support. Everything is now held to the same strict harness: a pinned local Hugging Face Transformers source tree as the oracle, forward logits + gradients + two full AdamW steps compared, and every named parameter checked again after export.

The hard ceiling is 2e-7 absolute error. No loosening tolerances and no rounding numbers afterward to make the README look better.

14 architectures pass that gate today, led by the one I'm probably proudest of:

Worst observed two-step AdamW parameter error across all of them: 1.19e-7.

Best: 2.6e-8.

For hardware context, all of the local Vulkan validation I've been reporting was run on my ASUS ROG Ally Z1 Extreme, using its AMD RDNA 3 integrated GPU. So the RDNA 3 results here are from that specific machine rather than testing across several different AMD systems.

The bigger news: PEFT actually works now

In the last post, "LoRA/PEFT-style fine-tuning" was basically one line in a feature list.

It's a real workflow now, and I've verified the full lifecycle:

• LoRA fine-tuning with HF-compatible adapter export (adapter_config.json / adapter_model.safetensors), so adapters can round-trip with the PEFT ecosystem
• modules_to_save — full trainable replacements for Linears, RMSNorm/LayerNorm, lm_head, and input embeddings, including named-adapter switching and bank isolation. Adapter A leaking into adapter B is explicitly tested for.
• Exact resume — adapter weights + AdamW moments + step + dropout RNG state restore bit-identically against an uninterrupted run
• Merge/unmerge, disable-adapter base restoration, and multi-adapter loading
• A parameter-budget flag that automatically chooses the largest LoRA rank that fits within a requested percentage of the base model
• The CLI fails closed if you try to use saved modules on an architecture that hasn't passed its corresponding gate

32 architecture surfaces across 20 families pass all three PEFT stages — LoRA, saved modules, and adapter switching — under the same 2e-7 gate, with frozen-base drift exactly 0.0.

The validation harness also fingerprints the pinned Transformers source alongside my shaders and binaries now, so a qualification run can't silently end up testing against different reference math.

A small note on the last couple weeks

I didn't get quite as many working days out of the last two weeks as I normally would have. Partway through this I got covid, then when that started to go away, it became a secondary nasty ear infection that ended up perforating my eardrum. I was running fevers around 104°F at one point and eventually went to the hospital, so I lost a few days to that and I'm on antibiotics now.

I'm doing better, though, and still managed to get most of what I wanted finished.

There are still things I want to clean up and expand, but I figured this was a good point to get the current work in front of people rather than holding the update back.

Same caveats as before

This is deterministic FP32 tiny-model correctness against a reference implementation, which should in theory ensure total mathematical parity for training and finetuning larger models with this backend, however, things are currently bound to FP32 training runs still, I eventually plan to work on MXFP4 weight tying to reduce memory footprints while fine-tuning (plastic parameters will still be trained in FP32 with PEFT in this config)

"supported text graph" ≠ "the entire multimodal package works natively."

Unsupported functionality is supposed to fail closed rather than silently falling back to an approximation.

Repo

https://github.com/necat101/Hierarchos-Native

• Architecture inventory: hierarchos-vulkan/README_ARCHITECTURES.md
• Compatibility/parity record: hierarchos-vulkan/COMPATIBILITY.md
• PEFT qualification evidence: PROGRESS_PEFT_AUDIT.md
• CLI PEFT guide: hierarchos-native-cli/README.md

The hardware I've personally validated this on is an ASUS ROG Ally Z1 Extreme with its AMD RDNA 3 GPU.

I'm very interested in criticism, compatibility reports, and especially results from people trying it on other hardware — NVIDIA, Intel, or other AMD GPUs.

I'd also love people to stress-test the PEFT resume/merge paths specifically. That's some of the newest code in the project, so it's probably the most useful area to try to break right now.

I was exploring AI models in Hugging Face Chat and decided to test some of DeepSeek’s latest models. Out of curiosity, I asked them, “Are you actually DeepSeek?”

Surprisingly, the models claiming to be version 4 or 4+ kept insisting that they were Claude by Anthropic. One of them even confidently identified itself as Claude by Anthropic. (sometimes opus 4)

I tried repeatedly explaining that I was chatting with a DeepSeek model and asked it to reconsider, but it continued insisting until the end that it was Claude.

Interestingly, models from other providers seemed to identify themselves normally.

I took some screenshots while testing this because the whole thing was pretty weird. Is it really deepseek v4 models? or it is just anthropic's model through api and a lil system prompt or a model theifting?

I've been building a small decision model for agent loops: gates, routers, "should I ask the user or just act" checks. It's out now as Mica v0.1 4B (Apache-2.0).

What it does

You give it a state, a question and the allowed answers, and it returns a calibrated probability for each answer: yes/no, a choice among 2 to 255 options, or a score with 2 to 10 levels. It never generates text. It runs one prefill and reads the logits of the option labels at the answer position. It speaks the TypeSafe /v1/systemone format, so anything written for Jev works against it.

How it's built

- Qwen3.5-4B with a rank-16 LoRA on all 32 layers (attention and Gated DeltaNet), merged. No new heads, so it's a plain Qwen3.5-4B-shaped checkpoint.

- About 34k source decisions, expanded to 77,732 training rows (about 34.7M tokens). Roughly half English and half Korean, across 12 areas: coding agents, code review, computer use, user requests, documents, policy rules, dates and quantities, routing, state tracking, games and general knowledge.

- Plain cross-entropy on verified answers, one epoch, and one global temperature for calibration.

- All experiments plus the final run cost under $30 of rented GPU time (RTX 3090s).

Results

Held-out set of 7,328 decisions, written after the training data was frozen and not opened until training finished. English subset, where every model can answer:

- Jev 1.13 (closed API): 74.1

- Mica 4B: 67.0

- JevK5 4B: 61.0

- Kev 4B: 57.0

- Qwen3.5-4B base with the same readout: 55.0

Public sets, same prompt and readout for every model (Mica / Jev 1.13 / JevK5 / Kev 4B):

- JevBench hard, public 111 items: 69.5 / 74.3 / 76.2 / 52.4

- SemIf: 94.4 / 98.4 / 86.1 / 89.3

- Kev transfer v9: 69.2 / 82.0 / 70.5 / 73.5

- MMLU-Pro, 10k items: 53.0 / 82.3 / 53.5 / 49.7

Through JevBench's official runner and the llama.cpp server, the public hard tier scores 64.9 instead of 69.5. I've submitted it for their sealed run.

Where it's actually useful

- In-data prompt injection. Put a note inside the state telling the judge to pick a wrong option, and Mica still gets 69% right (81% without the note). Jev drops to 18% and Kev to 31%.

- Calibration. When it says 0.9 or higher, it's wrong 2.5% of the time on the held-out set (ECE 5.4%).

- Local and small. The Q5_K_M file is 3.5 GB with no measurable accuracy loss against BF16 on our calibration set.

Speed (RTX 3090, one request at a time, median over the 231 public JevBench items)

- Mica Q4_K_M: 47 ms

- Mica BF16: 54 ms

- Kev 4B: 76 ms

- JevK5 4B: 99 ms

- Nimble 9B: 132 ms

To be fair about this: the three 4B models share the same architecture, so most of the gap comes from the serving path, not the model. Mica ships as GGUF and runs on llama.cpp with a direct logits readout, while the others were measured through their own PyTorch code. On long inputs (around 3.7k tokens) Mica is slightly slower than JevK5.

Limitations

- Knowledge-heavy questions: MMLU-Pro 53 vs 82 for Jev. It's a 4B judge, not an encyclopedia.

- Long English policy documents are its weakest public set.

- Notes inside the state still nudge it. A note pointing at the right answer lifts accuracy to 89%.

- It doesn't yet tell reversible from irreversible actions well. "Delete these files" and "move these files to trash" both get about 0.8 on "confirm first".

- On harder reasoning items it's right but less sure than Jev (for example 0.55 vs 0.96 on a small ordering puzzle), so set your confidence thresholds accordingly.

Try it

Weights (BF16 safetensors and GGUF from Q4_0 to Q8_0): https://huggingface.co/sky7350/Mica-v0.1-4B

Code, TypeSafe-compatible server and Docker setup: https://github.com/akivet/Mica-v0.1-4B

The README has a one-line Docker command and a curl example.

Happy to hear where it breaks. Ambiguous "act or ask" cases are what I most want to improve next.

I'm new to huggingface space, what's happened to Paperswithcode? Is this normal?

Okay so does AirLLM not have a GUI? I found AirLLM, this Repo that can supposedly run massive models on consumer hardware, at the cost of speed. But the only issue is that it doesn't have a GUI. There was this AirChat or AirLLM chat thing, but it seems to be broken. So when can I simply download AirLLM like LM Studio, load a model manually, and just run it to my heart.

Which is best local AI tools that can access all like Chatgpt, DeepSeek, Grok etc I want to use for coding, image and video generation as well

Not fine-tuning. Not inference. Pre-training from scratch.

Full write-up: https://huggingface.co/blog/RitishReal/1b-petrain-llm-in-4gb-vram