Andrew DeLisa

I've open-sourced the trainer I've been using to build tiny language models from scratch, together with the 95M base model I trained with it.

The trainer runs on Deno (https://deno.com, cross-platform), trains on WebGPU, and it writes GGUF directly. No Python/PyTorch. The weights live in a GGUF file from the first step to the last, so every checkpoint is already something llama.cpp can load.

The model is Felladrin/Minueza-3-95M-Base: 94.7M parameters, 1.95B tokens seen, 8192 context.

And here’s the repository on GitHub: https://github.com/felladrin/gguf-trainer

Here on Hugging Face, I published the optimizer state next to the weights, so you can continue the pretraining instead of starting over.

Or start your own from nothing: deno run -A cli.ts demo trains a tiny one end to end in under a minute.

And the docs are written for coding agents, so you can point your agent of choice at the GitHub repo and have it drive the whole pipeline.

36 replies

replied to aiqualitylab's post 15 days ago

https://huggingface.co/ayan4m1/Qwen3.5-4B-E2E-Tests-GGUF

published a model 15 days ago

ayan4m1/Qwen2.5-Coder-14B-E2E-Tests

Text Generation • 15B • Updated 12 days ago • 711

updated a model 15 days ago

ayan4m1/Qwen3.5-4B-E2E-Tests-GGUF

Image-Text-to-Text • 4B • Updated 15 days ago • 347

replied to aiqualitylab's post 15 days ago

Gotcha, will let you know when I have something to share, thanks!

replied to aiqualitylab's post 15 days ago

I'm training now but looking at the dataset, it seems to be missing the page content, so I'm wondering how it's supposed to work without tool calls. How does the inference engine know what the page looks like?

published a model 16 days ago

ayan4m1/Qwen3.5-4B-E2E-Tests-GGUF

Image-Text-to-Text • 4B • Updated 15 days ago • 347

replied to aiqualitylab's post 16 days ago

I might try training one of the larger coder models against your dataset, I'm interested to see what it can do with a little more reasoning ability. Thanks for the work!

reacted to SeaWolf-AI's post with 👍 18 days ago

Post

3310

AX-Ray: Safety Diagnostics for AI/AX Models

AI models can no longer be evaluated only by capability scores. As models move into public services, enterprise workflows, scientific research, and administrative decision support, we need a second layer of evaluation: whether the model behaves safely, structurally, and consistently under real deployment conditions.

VIDRAFT AX-Ray is a public AI/AX safety diagnostic initiative powered by FINAL-Bench Diagnostics. AX-Ray evaluates models across a structured guideline framework, including model-level safety, AX deployment readiness, and agent/service operation risks. The public diagnostic catalog contains 117 diagnostic items, mapped to legal, regulatory, ethical, and religious-law governance contexts so that safety review can be discussed in a form closer to real institutional responsibility.

A central finding of AX-Ray is causal leakage: a structural defect where information that should not influence an earlier reasoning state appears to affect model behavior. AX-Ray presents a public case of diagnosing, reproducing, and demonstrating causal leakage in two general-purpose public models. This matters because such defects are not exposed by ordinary benchmark scores. A model can appear capable while still carrying hidden safety or integrity risks.

Explore the live leaderboard, diagnostic reports, and public dataset here:

- AX-Ray Space: FINAL-Bench/AX-RAY
- AX-Ray Dataset: FINAL-Bench/AX-RAY
- Technical Article: https://huggingface.co/blog/FINAL-Bench/ax-ray

AX-Ray is intended as a practical guideline for moving AI evaluation beyond “how smart is the model?” toward “can this model be trusted, governed, and deployed safely?”

2 replies

reacted to OppaAI's post with 😔 about 1 month ago

Post

1092

After a month of interacting with my AI Waifu, I noticed a few issues in the system; so I decided to spend this week revisiting the systems implemented in Phase 1.0, 1.5 and 2.0, and try to make them to be more like production-grade as much as possible:

1) Memory Degradation - recalled memories are not as good as in the beginning, causing AI Waifu to be more chaotic as she hallucinates over contaminated memories like a bad vicious cycle.
So I transformed the original stateless sqlite-vec vector store to be a simple entity co-mention graph. And even make a studio to visualize the memories stored inside the vector db.

Just by looking at the graph, I saw a couple issues:
a) After 1.5 months of interactions, there should be only one month of pinned memory (in green) over 1.5 months of active memory (in purple). How come pinned memory is in majority over active ones?
I suppose the forgetting curve I had set too aggressive and memory half-life and shelf life too short, active memory got decayed way before monthly consolidation and got lost forever.
b) I saw she memorized me into 3 different entities: my username, my nickname and my Github user ID (leaked into pinned memory, presumbly during nightly dreaming process). 3B small param LLM has hard time to correlation 3 different entities into single person, I may have to harden into one.

2) RAM burst during voice input - for some reason the tensor calculation of SileroVAD of the voice input uses PyTorch, and that's the only place in the whole codebase using torch after removing it from TTS synthesization. By switching to SileroVAD-onnx integrated in the ASR sherpa-onnx, the RAM usage drops at least 0.5GB (after shaving off ~1GB from TTS) by completely remove PyTorch dependencies.

3) Introduced a better Wake Word system using Livekit-Wake word instead of using ASR to do the wake word activation to save computation. Optional features like Speak Verification, Barge-in sensitivity, etc, need to find the optimum settings.