DEV Community: Aymen Naghmouchi

NeuronDump: look inside any local LLM, follow a token, and make it smaller

Aymen Naghmouchi — Sun, 25 Oct 2026 19:45:41 +0000

If you run models locally with Ollama or llama.cpp, you've probably downloaded a few gigabytes of GGUF and treated it as a black box. I wanted to open that box: see the layers, the attention heads, the vocabulary, the chat template, and then ask two simple questions: why did the model pick this token, and which parts does it not actually need?

So I built NeuronDump, a single Rust binary (MIT) with a CLI and a local web UI. It reads GGUF files directly, with nothing hard-coded per model, and everything (including the 3D engine) is bundled, so it works offline.

👉 Repo: https://github.com/aymen94/NeuronDump
👉 Docs & illustrated intro: https://aymen.xyz/NeuronDump/

What it does

Inspect: architecture, layers (including hybrid SSM/attention models), attention heads, the vocabulary decoded and classified, the chat template as a decision tree, and weight statistics.
Graph: the model as a 3D (or 2D) dataflow graph you can open from sections down to single attention heads, neuron buckets and MoE experts. WebGPU, with an automatic WebGL 2 fallback.
Follow a token: the logit lens per layer, attention heatmaps per head, the most active FFN neurons, and a breakdown of how much each layer and head pushed the chosen token against the runner-up.
Edit live: scale or zero any part, skip a layer, ban or boost tokens, steer, patch activations, change the template, and compare baseline vs edited, with undo / redo and snapshots.
Cut and see the impact: select any parts and instantly see the size saved, what gets disconnected, and whether llama.cpp still loads the file.
Sweep and slim: cut each layer (or head) in turn, rank them by damage, and write the least important ones out as a smaller GGUF plus an Ollama Modelfile.

The model graph

neurondump web --open

Here's qwen3.8:27b in the 3D city view. Every part is coloured by whether you can remove it: safe, risky, or breaks the model.

Click any block to see its size, quantization and importance, expand it into its children, or add it to the cut selection. Type a tensor name like blk.3.ffn_down and the graph opens to show it.

Follow one token through the model

This is the part I've been using the most. Pick a prompt and a token, and NeuronDump shows what every layer "thinks" the next token is.

Here's llama3.1:8b on "Peanut butter and". The final answer is " jelly" (0.74). But up to layer 29, the logit lens reads "and" as grammar ("and/or"). " PB" shows up from layer 22, and only the last two layers switch to food.

Below that are the attention heatmaps and the decision breakdown. Every layer mostly attends to <|begin_of_text|> (an attention sink), and in layer 30 a handful of heads decide it: " jelly" beats " banana" by 2.2 logits, with head 24 pushing for it and head 25 pushing against it.

The generation timeline does the same for each generated token, and the uncertain steps stand out by their entropy. On "The Mediterranean Sea is located between", llama3.1:8b hesitates twice (" three" vs " Europe", then " Europe" vs " Africa"), and clicking a later step shows " Africa" winning at 0.99, with the push per layer and the heads behind it.

From the CLI:

neurondump tokens llama3.2:1b "fn main() {" --chat     # tokens, template tokens, nearest tokens
neurondump journey llama3.2:1b --prompt "The name of the star that Earth orbits is"
neurondump generate llama3.2:1b --prompt "The name of the star that Earth orbits is" --steps 8 --explain

Change the model and see what happens

Every change runs in memory, next to the original: you get the text, top-k, KL divergence, perplexity, logit lens and decision breakdown for both. You can scale or zero a layer, block, head or single neuron, skip a layer, edit a token's embedding, ban or boost tokens, add a steering vector, patch activations from another prompt, or swap the system prompt and template.

Edits stack, with undo / redo / restore all, named snapshots, and a portable edits.json:

{
  "schema_version": 1,
  "model": "llama3.2:1b",
  "edits": [
    { "id": 1, "enabled": true, "label": "zero layer 7", "op": "zero", "target": "layer.7" },
    { "id": 2, "enabled": true, "op": "steer", "layer": 6, "a": "Dear Sir or Madam, I am writing to formally request", "b": "hey dude, just wanna ask", "strength": 4 }
  ]
}

neurondump edit llama3.2:1b --apply edits.json --prompt "The name of the star that Earth orbits is"   # baseline vs edited
neurondump edit llama3.2:1b --apply edits.json --bake llama-edited.gguf --no-compare

Bake writes the edits into a new GGUF (plus a Modelfile). The original file is never touched.

Cut, sweep, slim

Slimming is a two-step process: analyze first, then apply a plan you can review.

neurondump analyze llama3.2:1b --out plan.json
neurondump slim llama3.2:1b --plan plan.json --only vocab --out small.gguf

The plan is a plain JSON file, so you can inspect or edit it before anything gets written. --only lets you restrict what gets cut (here, just the vocabulary).

Or let it measure which layers matter:

neurondump ablate llama3.2:1b --cut layer.7 --static                # direct impact on the file
neurondump ablate llama3.2:1b --cut layer.7 --prompt "The name of the star that Earth orbits is"   # simulated impact
neurondump sweep llama3.2:1b --corpus texts.txt --save-plan plan.json --top 2
neurondump slim llama3.2:1b --plan plan.json --out llama-14.gguf

Some things it showed me

DeepSeek-R1 8B is Qwen3 8B with every weight slightly changed. It has the same neurons in the same places, including one neuron in layer 6 that makes the internal state about 33× larger. Cut that layer and both models produce noise.
On llama3.2:1b, cutting the last layer made the model more confident on one prompt, even though, apart from the first two layers, no layer hurts perplexity on real text more.
DeepSeek's chat template emits tool-call markers that aren't in its vocabulary, so each one gets split into 11 ordinary tokens.
llama3.1:8b knows the answer before it says it. On "The name of the star that Earth orbits is", " Sun" is the top prediction from layer 21 to 26, then the last layers switch to " called", so it writes "…is called the Sun" instead of answering in one word.

Install

Prebuilt Windows and Linux binaries are on the releases page, with everything included (CLI, web UI, and running models). Unzip (or untar) and run neurondump list.

Or build from source (Rust 1.88+):

git clone https://github.com/aymen94/NeuronDump
cd NeuronDump
cargo install --path crates/neurondump --features trace
neurondump list

Leave out --features trace if you only want the static tools (inspect, graph, impact, slim, tokens, bake) and don't need to run models.

Run neurondump with no arguments to choose between the interactive CLI and the web UI.

Limits

It's early, and it has been tested mostly on Windows with Ollama models.

Inference is CPU-only, with no KV cache, and all weights are loaded into RAM (an 8B Q4_K model needs about 5 GB).
Running models (journey, timeline, simulation, live edits) covers the llama, qwen2/3, gemma (1–3), phi3 and bert families. MoE and hybrid models (like Qwen 3.5 / 3.8) get static analysis, static impact and bake only for now.
Run-time-only edits (ban, boost, steering, patching) can't be baked into a GGUF.
Zeroing heads or neurons keeps the file loadable but doesn't shrink it.

Known gaps are listed in the limitations page and in TEST.md. If you try it on a model I haven't, I'd love to hear what you find: https://github.com/aymen94/NeuronDump/issues

WAMR3D: A Native WebAssembly 3D Engine with a three.js-Style API and Its Own WebGPU Renderer

Aymen Naghmouchi — Wed, 14 Oct 2026 21:06:55 +0000

If you have ever shipped a three.js scene with thousands of animated objects, you know where the frame budget goes: JavaScript object updates, matrix math, and the cost of handing draw calls to the GPU. WAMR3D is a new open-source attempt at that problem. It moves the scene graph, transforms, culling, and draw ordering into a Rust core compiled to WebAssembly, pairs it with a WebGPU renderer written from scratch, and keeps an API that reads like three.js.

Here is what it is, what it measures, and where it still falls short.

Website: wamr3d.org
npm: wamr3d
GitHub: aymen94/wamr3d

What is WAMR3D?

WAMR3D is a WebAssembly 3D rendering engine with a Rust core and a separate WebGPU renderer. It is not a wrapper around three.js. It is also not a finished replacement for it. The project is young, and the README says so directly.

Three parts make it up:

A native core in WebAssembly. The scene graph, world matrices, frustum culling, draw ordering, and raycasting run inside a Wasm module.
Its own WebGPU renderer. Meshes, lines, points, sprites, and instanced meshes. Basic, Lambert, and standard materials. Colour textures, fog, up to 16 lights, PCF shadows, tone mapping, render targets, and 4× MSAA.
A three.js-style object API under wamr3d/compat, plus a lower-level batched API for large scenes.

The license is MIT. There are no runtime dependencies, and the Wasm module is about 488 KiB.

Why a native core matters for three.js developers

In most three.js apps, scene state lives in JavaScript objects. Every position.set(), rotation.y +=, and matrix update is JavaScript work, and the garbage collector eventually gets involved.

WAMR3D takes a different approach:

The scene lives in engine memory. Objects are created and destroyed explicitly in WebAssembly, so the engine itself adds no GC pauses.
Generational handles. A handle to a destroyed object can never silently point at a different object.
Zero-copy geometry. You can read and write vertex attributes through typed-array views directly over engine memory.
Batched sync. In the object API, position, rotation, and scale stay in JavaScript, and every change is sent to the engine in a single batch per frame.

The result is that WAMR3D wins when you batch work, and loses when you make many tiny calls. The project documents both.

Measured performance

These are the numbers from the repo's benchmark record, recorded on 2026-10-14 in headless Chrome on Windows x64 with an RTX 2070 SUPER. They are medians from a single run per resolution on one machine. Treat them as a starting point, and measure your own scene.

10,000 separate animated meshes at 1920×1080:

Engine	fps	Draw submission (CPU)
WAMR3D, batched API	60.0	12.2 ms
WAMR3D, object API	60.0	12.3 ms
three.js WebGPU	9.5	100.5 ms
three.js WebGL	33.7	23.7 ms

50,000 instanced bodies, scene update on the CPU: 12.0 ms for WAMR3D's batched API, against 39.1 ms for three.js WebGPU and 39.7 ms for three.js WebGL.

Put simply: in this showcase, WAMR3D spends roughly 8× less CPU time on draw submission than three.js WebGPU, and about 1.9× less than three.js WebGL. The frame rate caps at 60 because the showcase has a display limit.

The project also publishes the other side of the picture. Calls that do very little work, such as a single vector operation or one property at a time, measured 1.3× to 3.8× slower than three.js, because crossing into WebAssembly has a fixed cost. GPU time is not measured separately; it only shows up in the frame rate.

If you want to check these yourself, the showcase page runs all four renderers live: wamr3d.org/examples/showcase.

Same results as three.js, checked by tests

Speed means nothing if the output is wrong. WAMR3D replays over 7,600 reference cases generated from the three.js r186 source against the Rust code. Individual operations agree to about one part in a million. All 23 renderer test cases are compared pixel by pixel against stored three.js images.

The repo also includes 643 Rust tests covering unit, parity, and allocation behaviour, plus a visual parity page that shows each WAMR3D render next to the three.js image and the pixel difference.

Get started in two minutes

npm install wamr3d

Change the import, initialize once, and switch to the WebGPU renderer:

- import * as THREE from 'three';
+ import * as THREE from 'wamr3d/compat';
+ await THREE.init();

- const renderer = new THREE.WebGLRenderer( { antialias: true } );
+ const renderer = new THREE.WebGPURenderer( { antialias: true } );
+ await renderer.init();

A complete example:

import * as WAMR3D from 'wamr3d/compat';

await WAMR3D.init();

const scene = new WAMR3D.Scene();
const camera = new WAMR3D.PerspectiveCamera(50, innerWidth / innerHeight, 0.1, 100);
camera.position.set(3, 2, 5);
camera.lookAt(0, 0, 0);

const cube = new WAMR3D.Mesh(
  new WAMR3D.BoxGeometry(),
  new WAMR3D.MeshLambertMaterial({ color: 0x4f8cff })
);
scene.add(cube, new WAMR3D.DirectionalLight(0xffffff, 2));

const renderer = new WAMR3D.WebGPURenderer({ antialias: true });
await renderer.init();
renderer.setSize(innerWidth, innerHeight);
document.body.appendChild(renderer.domElement);

renderer.setAnimationLoop((time) => {
  cube.rotation.y = time / 1000;
  renderer.render(scene, camera);
});

scene.add, position.set, rotation.y +=, lookAt, and raycasting work as written for the classes WAMR3D supports. The project's migration guide lists exactly which classes exist and what to watch for.

Requirements: a browser with WebGPU (current Chrome or Edge), served over HTTP rather than file://. Node.js 18 or newer can run the math and scene graph without a renderer.

Batching for large scenes

When your scene grows past a few hundred objects, the batched API is where the gains come from. Handles and calls like setRotations update thousands of objects in one crossing into WebAssembly. You read world matrices through typed-array views without copying them.

The low-level API is also exported directly from wamr3d:

import { init, World } from 'wamr3d';

await init();

const world = new World();
const scene = world.createObject();
const arm = world.createObject();
const hand = world.createObject();
world.add(scene, arm);
world.add(arm, hand);

world.setPosition(arm, 10, 0, 0);
world.setRotation(arm, 0, 0, Math.PI / 2, 'XYZ');
world.setPosition(hand, 1, 0, 0);

world.updateMatrixWorld(scene, false);
console.log(world.matrixWorld(hand)); // Float32Array(16), column-major

Two details to know: matrices are column-major, and the low-level API has no default arguments, so rotation order and similar parameters are always written out.

What is not there yet

This section matters most, so here it is in full. From the project's own status page, the following are not available yet:

Environment reflections (not connected to scene.environment or envMap)
Point-light shadows and area lights
Post-processing and scene background textures
Most loaders, animation, audio, and controls (the exception is TextureLoader)
Shadow modes other than PCF
A WebGL fallback

It has also been verified only in Node.js v24 and headless Chrome. Firefox, Safari, and bundler setups have not been tried yet.

For those features, keep three.js for now.

Who this is for

WAMR3D is a good fit if you:

Have a three.js scene with many objects, and the bottleneck is JavaScript updates or draw submission
Are experimenting with WebGPU and want a renderer that is not a thin wrapper
Care about deterministic, checked behaviour, and want to see the parity tests
Want to contribute to a Rust and WebAssembly graphics engine

It is probably not the right choice yet if you depend on post-processing, environment maps, loaders, animation, or Firefox and Safari support.

Try it, measure it, tell me what breaks

The fastest way to judge WAMR3D is to run it on your own scene:

Live demos: WebGPU renderer, showcase, side-by-side comparison
Migration guide: MIGRATION.md
Status and benchmarks: STATUS.md
Design decisions: DECISIONS.md

The project has one star and no forks so far, so early feedback will shape it a lot. Issues, benchmark results from other GPUs, and reports from Firefox or Safari are all useful. If you find a case where it is slower than three.js, please open an issue. The project explicitly values those results.

Star it on GitHub, and try npm install wamr3d on a scene you already know.

WAMR3D is an independent project, not affiliated with three.js. It is inspired by three.js and credits it throughout the repository.

OpenAPI to WebMCP in One Command

Aymen Naghmouchi — Mon, 12 Oct 2026 19:47:43 +0000

🚀 Introducing openapi-to-webmcp

I built openapi-to-webmcp, an open-source tool to generate WebMCP browser tools from OpenAPI specifications.

📄 Supports JSON and YAML specifications
⚡ JavaScript by default, with TypeScript support
🌐 Browser ES module available via CDN
🛠️ CLI and programmatic API

Quick start

npx openapi-to-webmcp openapi.yaml

The package also provides a browser entry point for generating WebMCP modules from a normalized API object, without bundling the Node.js YAML parser.

📦 npm: https://www.npmjs.com/package/openapi-to-webmcp

💻 GitHub: https://github.com/aymen94/openapi-to-webmcp

Feedback and contributions are welcome😎!