Built an 80M parameter causal transformer on consumer hardware (RTX 5070), trained on MOSES + ZINC-250k. Generated and filtered for QED ≥ 0.5, SA ≤ 4.0, MW ≤ 500. Top compound hits QED 0.947. 100% novel against MOSES, ZINC, and ChEMBL.

HuggingFace: https://huggingface.co/datasets/MKEChem/mke-novel-druglike-smiles

Happy to answer questions about the generation method.

https://askthedeclaration.com/

I would like to share my latest open source local LLM inference tool implemented in C#. It supports models like Gemma4, Qwen3.6 with multi-modal (image, vision, audio), reasoning and function tool. It can run on Windows/MacOS/Linux and fully leverage GPU's capability. The API is completely compatible with OpenAI and Ollama interface.

Really appreciated if you can try it and give me some feedback. If you like it, it will be a big thank you if you can star it. Thank you very much!

I spent the last few months building a new sparse fine-tuning method for MoE models called USAF.

The goal was simple: if your GPU can run inference on an MoE model, it should also be able to fine-tune it.

On my AMD RX 6750 XT (12 GB), I can fine-tune Qwen3-30B-A3B by training sparse expert weights and the router instead of adapters.

The project is completely open source under the Apache 2.0 license. I'm not trying to build a business, sell anything, or monetize it in any way—I just wanted to share something I built that I think is genuinely interesting.

GitHub: https://github.com/tsuyu122/usaf

The bet: BRIGHT is a retrieval benchmark where finding the right doc usually takes a few hops of reasoning, not just semantic overlap. Most embedders do a single forward pass. I wanted to see if a depth-recurrent architecture, one that loops over its own hidden state, would fit that better, so I built an embedder on HRM (Sapient's Hierarchical Reasoning Model). As far as I can tell it's the first time HRM's been used for retrieval.

The recurrence helped on the reasoning side, which was the whole bet. When I dialed the recurrence down at eval on pony (one of the BRIGHT domains), accuracy dropped with every loop I removed. Where it hit a wall was knowledge: the base was pretrained on a deliberately thin slice of text (Sapient built HRM-Text for pretraining efficiency, not breadth), so it's weak on knowledge-heavy domains. The part I find coolest: at 0.6B, the reasoning is coming from the architecture, not from scale.

Details:

• ~0.6B params, trained on one 3060 Ti (8GB).
• Recipe's deliberately boring: mean-pool + L2, bidirectional (LLM2Vec style), contrastive InfoNCE. Only the backbone is unusual. Same recipe as RakanEmbed4B.

Numbers (BRIGHT, mean nDCG@10, 12 domains):

• original: 18.1
• query rewriting: 34.3
• merged: 33.7

Weights are Apache-2.0 and the full BRIGHT eval harness is in the repo.

Open questions / discussion:

• Would a massively pretrained HRM push this further? The ceiling here looks like knowledge, not reasoning, so a broadly-pretrained base might lift it a lot. I don't have the compute to try that myself.
• Would other recurrent architectures show the same effect, or is something specific to HRM doing the work?

Model: https://huggingface.co/viventhraa96/HRM-Embed-0.6b

Code: https://github.com/okaybroda/hrm-embed

Full credits to Sapient Inc for open sourcing the code and the architecture for this work.

Hey everyone,

Wanted to share a project I've been working on: copywriter-gemma4-31b, a fine-tune of Gemma aimed specifically at copywriting tasks — headlines, product descriptions, ad copy, CTAs, and short marketing emails. Link: https://huggingface.co/akwin123/copywriter-gemma4-31b
GGUF:
https://huggingface.co/models?other=base_model:quantized:akwin123/copywriter-gemma4-31b

Why I built this

Most general-purpose LLMs are decent at copywriting but tend to default to generic, safe phrasing ("Elevate your experience," "Unlock the potential of..."). I wanted something smaller and cheaper to run that leans into punchier, more direct commercial writing without needing a huge model or heavy prompting gymnastics every time.

Training approach

• Base model: Gemma 4 - 31B
• Method: QLoRA
• Data size: 93k (high quality)
• Scored +290 points more than base model as per https://eqbench.com/

What worked

• Style transfer was strong for short-form copy (headlines, CTAs) — noticeably punchier than base Gemma
• Held up reasonably well on product categories it wasn't explicitly trained on
• Inference is fast/cheap enough to run on [hardware], which was the whole point

Example output

Prompt: "Write a headline for a noise-cancelling headphone brand targeting remote workers"

Base Gemma: "Experience premium sound quality with our advanced noise-cancelling technology."

Fine-tuned: "Silence the chaos. Work like you're the only one in the room."

(Your mileage may vary obviously — cherry-picked example, not a guarantee.)

Open questions for the community

• Anyone else fine-tuned small models for narrow commercial writing tasks? Curious how you handled the "generic tone" problem.
• Is LoRA generally sufficient for style transfer like this, or does full fine-tuning meaningfully help for domain-specific voice?
• Any recommended eval methods for copywriting quality beyond just vibes/manual review?

Happy to share more details on the dataset curation process or answer questions about the setup if it's useful to anyone attempting something similar.

We are excited to introduce MultiHashFormer, our new framework for vocabulary efficient language modelling.

Inspired by chaotic dynamic memory systems with distributed state spaces, we replace the traditional embedding matrix with a modular hashing interface.

👉 Each token is represented as a unique hash signature, a short sequence of discrete hash IDs, generated by multiple independent hash functions.

👉 A Hash Encoder compresses this ID signature into a single latent vector for processing by a Transformer decoder.

👉 A Hash Decoder generates the hash signature of the next token, which is then mapped back to text.

✅ Using 4 hash functions and 16,000 buckets per function, our model theoretically supports an upper bound of 16000^4 (approx. 65 quadrillion) unique signatures, i.e., vocabulary entries, with a constant memory footprint!

✅ MultiHashFormer consistently outperforms standard Transformer LMs across multiple benchmarks in 1B and 3B scales, pre-trained from scratch on 100B tokens (we know...we're compute poor, if you're interested in scaling further, please reach out).

✅ It can effectively handle multilingual vocabulary expansion with a constant parameter footprint without any architectural modifications or additional parameters!

Paper: https://arxiv.org/abs/2606.28057
HuggingFace: https://huggingface.co/papers/2606.28057

I trained a 12B with one goal: prose that doesn't fall into the usual LLM tics. Sharing it here since this crowd will put it through real use.

• Model Name: Ozan-v1-12B
• Model URL: Ozan-v1-12B (full precision) · GGUF quants (Q4–Q8)
• Model Author: arbazsiddiqui (me — I made this)
• What's Different/Better: It's built and measured for low slop. The over-used tells like "barely above a whisper," "a testament to," the reflexive "not just X, but Y." On the EQ-Bench Creative Writing v3 slop metric it's the lowest-slop runnable 12B I tested (slop 5.30 over 96 stories), with the cleanest repetition of the field, so it holds up over long, multi-turn writing instead of drifting into purple mush. It writes ~1000-word turns naturally, native Mistral [INST], and it'll handle mature themes. Best judged by reading: there are 3 full unedited samples (with prompts) on the model card.
• Backend: koboldcpp (GGUF). Also runs on llama.cpp / Ollama / LM Studio. I run Q5_K_M for a good size/quality balance (Q4_K_M is the lighter default; Q6_K/Q8_0 if you have the VRAM).
• Settings (SillyTavern):
  • Instruct + Context template: Mistral (native [INST] … [/INST])
  • Temperature: 0.7
  • Min-P: 0.1
  • DRY: multiplier 0.8 / base 1.75 / allowed-length 2 (keeps long outputs clean — recommended on)
  • No special system prompt needed; no length-forcing needed.

How it was made (open): SFT on curated low-slop prose, then a Gutenberg anti-slop DPO pass. Full pipeline + the before/after numbers are open (Apache-2.0): github.com/arbazsiddiqui/Ozan

Honest caveats: "slop" is one axis of quality, not the whole story; it's a 12B, so it's lighter on emotional depth and surprise than bigger models. Read the samples and judge for yourself.

Feedback very welcome, this is my first time training any lora or finetuning, please let me know what can be/have been improved 🙏

Built a 135M dense looped LLM from scratch. Spent 2 weeks debugging Parcae's LTI stability mechanisms across 5 ablations. None of them beat the naive baseline at this scale. Trained for real anyway. SFT'd it. Shipped it. Here's the full honest story.

What I built

A 135M parameter looped transformer trained from scratch on FineWeb (4.6B tokens), inspired by the Parcae paper (arXiv:2604.12946 — "Scaling Laws For Stable Looped Language Models").

• 🤗 Base model: huggingface.co/harims95/LoopLM-135M-naive
• 🤗 SFT model: huggingface.co/harims95/LoopLM-135M-naive-sft
• 📂 Code: github.com/harims95/LoopLM
• 💰 Total cost: ~$51 (Modal H100s + free Lightning H200)

Architecture

Input → [Embedding] → [Prelude: 4 blocks] → e (injection)
     → [Loop block × T loops, T~Poisson(μ=6)] → [Coda: 2 blocks] → logits

• d_model 1024, GQA 16/8 heads, RoPE, QK-norm, SwiGLU FFN 2816
• Update rule: h_{t+1} = block(h + e) (naive) or with LTI stability (Parcae)
• Muon + AdamW optimizers, truncated BPTT (μ_bwd=3), bf16
• Trained on 2× H100 on Modal, ~3 hours wall clock

The Parcae investigation (the interesting part)

The paper claims LTI stability constraints on the recurrent state dramatically improve looped LM training. I tried to reproduce it. Here's what actually happened:

Ablation	Description	Val loss
1. Naive looped	h = block(h + e)	3.84
2. + A matrix	LTI decay constraint	3.84 (tied)
3. + Input norm v1	Wrong arch flow	Diverged
4. + LTI before block	Fixed arch, B=identity	Worse
5. + B→AdamW, init=0.447	Matched official repo	Dramatically worse

Every single "fix" — bringing my implementation closer to the official Parcae code — made things worse. After consulting:

• The paper's Appendix Q (optimizer routing)
• Official sandyresearch/parcae repo (injection.py)
• Two rounds of ChatGPT + Gemini debugging sessions

My conclusion: Parcae's stability improvements are a large-scale phenomenon. The paper's 1.3B model trains for 170k+ steps before stability mechanisms kick in. At 135M / 17.5k steps, naive looped is competitive enough that the extra complexity hurts more than it helps.

Comparison with sibling MoE

My brother built HobbyLM — a 500M MoE on the same infrastructure. For apples-to-apples comparison, I ran naive looped 135M on the same FineWeb data:

Model	Architecture	Tokens	Val loss
LoopLM-135M (mine)	Dense looped	4.6B	3.95
HobbyLM-130M MoE (bro)	Sparse MoE	10B	3.30

Dense looped loses to MoE at this scale/budget. Sparse MoE is more sample-efficient. Not surprising but now I have the data to confirm it.

SFT results (bonus)

Fine-tuned on Alpaca 52k using Lightning AI's free H200. Took 6 minutes (bf16 on H200 is insane).

Before SFT:

>

After SFT:

>

Improvement in format, not in facts. At 135M / 4.6B tokens, SFT teaches format, not knowledge. The model still hallucinates — that's a base model capacity problem, not a fine-tuning problem.

What I learned

On Parcae: Small-scale reproductions of large-scale papers are dangerous. The paper's key contribution (stability at 170k+ steps) is invisible at hobby budgets. Naive looped is a legitimate architecture for anyone training sub-1B models.

On MoE vs looped: At matched parameter count and token budget, MoE wins on sample efficiency. Looped models need more tokens to show their advantage, or need to be much bigger to amortize the loop cost.

On debugging: When 3 independent LLMs (me, ChatGPT 5.5, Gemini) all agree on a fix and it makes things worse — the paper's regime assumption is probably wrong, not your code.

On SFT: H200 on Lightning AI is free (2 hours/month) and runs 6 minutes of SFT for free. Use it. Colab Free disconnects at 3 hours. Don't use it for long jobs.

On honest publishing: val 3.95 is not impressive. The architecture exploration is. Shipping anyway with full documentation of what failed is more valuable than hiding failures.

Stack

• Training: Modal (H100s), Lightning AI (H200 for SFT)
• Framework: PyTorch, HuggingFace Transformers
• Optimizer: Muon (matrices) + AdamW (rest)
• Data: FineWeb via kjj0/fineweb10B-gpt2 shards
• Infra forked from: github.com/harishsg993010/HobbyLM (my brother's 500M MoE project)

Happy to answer questions about any part of this. The code is fully open, reproducible, and documented.

Hi everyone!

I’m one of the people working on Clark Air, and we just released an Apache-2.0 compressed version of Sana 1.6B on Hugging Face.

It’s not meant to be a polished “best model ever” announcement.

It’s more of a research/artifact release: we compressed the Sana 1.6B transformer into a packed ternary format.

The packed artifact is 374 MB, compared with about 3.21 GB for the FP16 transformer. 8x compression with almost no loss in quality to FP16.

And I love state of the art quality of the generated artifact - way better than native Int4 quant.

Look at these 1bit puppies

https://huggingface.co/clark-labs/clark-air-sana-1.6b-1.58bit

I’ve open-sourced the method behind a battery state-of-health model that, somewhat annoyingly for my own priors, beats a published deep net on a standard benchmark using only tree ensembles on CPU.

The idea. Instead of feeding raw cycling curves to an RNN/transformer, I fold every measurement into a 9-class “harmonic” space (HIN(k) = 1 + ((k−1) mod 9)), score pairwise interactions through a fixed 9×9 compatibility matrix, and aggregate into a 557-dim descriptor (Chi histograms, Markov transitions, a Miller-sequence multi-scale calculus, entropy). Then ExtraTrees + XGBoost.

Result (MIT–Stanford–TRI / Severson et al., Nature Energy 2019, 144 cells, 5-fold CV, 30% observation window ≈ 45 cycles):

|Model |MAE |RMSE |PCC |R² |

|This method |**0.0114**|**0.0200**|0.884|0.747|

|Attentive NeuralODE (Li 2021) |0.012 |0.020 |0.900|0.810|

|RF (Microsoft BatteryML, ICLR’24)|0.2459 |0.3140 |0.610|0.269|

Wins MAE/RMSE; still behind the NeuralODE on PCC/Spearman/R² (it’s not a clean sweep). 21.6× lower MAE than BatteryML’s strongest sklearn baseline, with a shorter window.

Honest limitations. On the materials track (Matbench mp_e_form) the same descriptor gets 0.1513 eV/atom — beats the classic RF+Magpie baseline but is well behind modern GNNs (CGCNN/CHGNet). The bundled demo is synthetic (a signal check, not the benchmark). No trained weights are shipped — you train your own (seconds, CPU). License is CC-BY-NC-4.0 and the method is patent-pending, so it’s “open to read/run/research,” not OSI-open — flagging that up front.

Repo (method, demo, tests, docs): https://huggingface.co/williamTLmiller/batterymhm

pip install "git+https://huggingface.co/williamTLmiller/batterymhm"

python demo.py

I’m genuinely curious about: is the win mostly the modular fold-map representation, or just that trees beat small-data deep nets on ~144 cells? I’d love for people to (a) try the descriptor on other sequence/tabular tasks, or (b) find their own way past 0.0114. Challenge thread is in the repo’s Community tab.

Sharing a small solo project in case it's useful to anyone doing domain-specific fine-tunes in non-English languages.

I trained a Portuguese (PT-BR) model on the complete works of Allan Kardec — the 19th-century codifier of Spiritism. The whole corpus is public domain (he died in 1869), which made it a clean dataset to work with for a religious/philosophical domain.

Setup:

- Base: Llama 3.1 8B Instruct

- Method: QLoRA (4-bit) via Unsloth, on a single T4

- Data: ~4,896 Q&A pairs in ShareGPT format, built from the full works

- Format: GGUF Q4_K_M for Ollama / llama.cpp, plus the safetensors adapter

The goal was a study assistant that cites its source (book, chapter, question) instead of just asserting things. It's a research/replication artifact, not a product — Apache-2.0, and the dataset is public too.

Honest limitations: it's an 8B, so specific citations (question numbers, chapters) can still be wrong — the concept tends to be right, the exact reference not always. I treat it as a study aid, not a source of truth.

To my surprise it's been downloaded a fair bit by people I'll never meet, which is the fun part of releasing open weights.

Models + dataset: huggingface.co/ia-espirita

Happy to answer anything about the data prep or training — and if anyone's done domain fine-tunes on niche public-domain corpora, I'd love to hear what worked for you.

https://iaespirita.com.br/noticias/modelos-riv-ai-1260-downloads-hugging-face

First of all, I'm stoked to announce we just passed 10 million downloads on HF! (counted only on my own account, no duplicates/quants/finetunes)

BUT: After 1+ month non-stop working on Gemma4 (by far the hardest model I've uncensored), the Gemma4-26B-A4B Uncensored Balanced RC is up!

https://huggingface.co/HauhauCS/Gemma4-26B-A4B-Uncensored-HauhauCS-Balanced

GenRM Defeated! 0/465 refusals*.

Balanced = light reasoning preamble on the absolute edgiest stuff before delivering the full answer. No personality changes/alterations or any of that. This is the ORIGINAL Gemma4-26B-A4B-it, just uncensored. Aggressive variant (no preamble, direct mode) is in the pipeline as a follow-up.

This legitimately took me over 1 month of non-stop work. Targeting 0 refusals in any kind of regular use, and that's what I'm seeing in testing (automated and manual) — as always with my Balanced releases, a handful of edge-case prompts still deflect on first try but follow through on a re-ask (on extreme, non-RP scenarios). If you hit one Balanced won't get past, the Aggressive variant is coming once I figure out how to maintain lossless/near-lossless quality for it.

• Balanced: will reason through edgy requests, occasionally attach a short safety framing, then deliver the full answer. Output is complete, nothing held back, but it can talk itself into it first. Recommended default — 99%+ of users will be happy here. Best for creative writing, RP, emotional intelligence. Normally I'd also say "agentic coding/tool use" however in my in-depth testing, Qwen3.6 has been net superior on such tasks.

• Aggressive (separate release, WIP): strips the self-reasoning preamble and gives direct answers to any DEEPLY censored topics.

  From my own testing: no looping, sampling stays stable across re-runs, long-context coherence holds. For agentic coding/tool-use Qwen3.6 is still net superior.

  Use Gemma4 for creative writing, RP, emotional intelligence, etc.

  To disable thinking: edit the jinja template or pass {"enable_thinking": false} as a chat-template kwarg.

  What's included:

  - Q8_K_P, Q6_K_P, Q5_K_P, Q5_K_M, Q4_K_P, Q4_K_M, IQ4_XS, Q3_K_P, Q3_K_M, IQ3_M, Q2_K_P, IQ2_M

  - mmproj for vision support

  - All quants generated with imatrix

  K_P recap (for anyone who missed the prior releases): custom quants that use model-specific analysis to preserve quality where it matters most. Each model gets its own optimized profile.

  Effectively 1-2 quant levels of quality uplift at ~5-15% larger file size. Fully compatible with llama.cpp, LM Studio, anything that reads GGUF (heads up, as always, Ollama can be more difficult to get going).

  Quick specs:

  - 25.2B total / 3.8B active (MoE: 128 routed experts, top-8 + 1 shared)

  - 30 layers, hybrid attention: 5× sliding-window (1024) + 1× full global, repeating

  - Hidden 2816, head_dim 256 SWA / 512 full, 16 heads, 8 KV heads

  - 262K native context

  - p-RoPE

  - Multimodal (text + image via mmproj)

  Sampling params (Google's recommendations, make sure to use these ):

temp=1.0, top_p=0.95, top_k=64

Notes:

- Use --jinja flag with llama.cpp

- Place images before text in prompts for vision

- K_P quants may show as "?" in LM Studio's quant column — purely cosmetic, model loads and runs fine

- HF's hardware-compatibility widget also doesn't recognize K_P, so click "View +X variants" or go to Files and versions to see all downloads

All my models: HuggingFace-HauhauCS

Discord link is in the HF repo and it contains updates, roadmap, projects, or just chat.

As always, hope everyone enjoys the release!

* = Tested with both automated and manual refusal benchmarks/prompts which resulted in none found. Based on Discord feedback I may further update the release.

## What My Project Does

Mistikguard is a small Python library designed to reduce memory fabrication in LLM-based applications. It provides:

- Provenance tracking for facts (`confirmed` vs `inferred`)

- A write gate that blocks contradictions of confirmed facts and self-narration

- Support for correction tombstones, so once a user corrects something, it is not silently reintroduced

- An optional grounding audit that detects memory claims in responses and validates them against stored memory

The core functionality works with almost zero external dependencies.

## Target Audience

This library is intended for **Python developers** who are building applications with long-term memory using LLMs. This includes:

- People building AI companions

- Developers creating autonomous agents

- Anyone working on RAG or memory-heavy LLM systems

It is a **library**, not a full application. It is meant to be integrated into other projects. It is currently in an early stage (v0.1) and is more suitable for personal projects and experimentation than large production systems without additional safeguards.

## Comparison

Unlike most memory systems that blindly store model output, Mistikguard actively tries to protect memory integrity by:

- Distinguishing between user-stated facts and model-generated inferences

- Preventing certain types of invalid writes through a deterministic gate

- Making user corrections more persistent using tombstones

It is lighter and more focused than full agent frameworks (such as LangChain or LlamaIndex memory modules) while being more structured than simple in-memory dictionaries or basic vector stores.

GitHub: https://github.com/obscuraknight/mistikguard