Welvet: a Go AI engine that trains and runs on your hardware, from Raspberry Pi to CUDA, Metal, Vulkan, ROCm, MLX, and Qualcomm NPU

Round 1 demos on Linux, Windows, macOS, iOS, and Android. These are working paths on real hardware, not a claim that anything is fastest or best.

I built Welvet because I wanted a Go engine that can actually train and run neural nets on my own machines, not just ship tensors off to somewhere else.

Source is at github.com/openfluke/welvet. There's a product page at openfluke.com/welvet and a feature book at openfluke.github.io/welvet.

This is a walkthrough of v1.7: backends, training modes, storage, and some of the messier runs (Macs, cheap VMs, ~1GB Raspberry Pi 3Bs).

What it does

Roughly four jobs:

• Run: load weights, compute, get an answer
• Train: update those weights from experience
• Store: keep dtypes and quants as they are (no fake float32 master copy)
• Measure: check what the chosen hardware actually did

Defaults are portable Go: CPU tiling, Plan 9 SIMD, and WebGPU. Extra accelerators are opt-in mounts. No silent "Prefer" path that pretends GPU/NPU work happened when it didn't.

Snapshot (v1.7)

Paragon and Loom were earlier engines in the same project line. Welvet is the rewrite. They're history, not competing products.

Where it can run

Unsupported hosts soft-SKIP. Caps reject unsupported layer×dtype instead of lying.

Defaults

1. Go CPU tiled (BackendCPUTiled): full layer set, 34 dtypes, 20 quants, train modes
2. Plan 9 SIMD (BackendSIMD): Dense + Softmax/SiLU fused paths on amd64/arm64
3. WebGPU (BackendWebGPU): Dense/MHA/CNN/norms and friends on compatible GPUs

NativeCPU

BackendNativeCPU + SyncToNative can push FormatNone forward, NormalBP, and TrainMode updates through sibling welvet.cpp on linux/amd64. Sync pending weights before writing .entity.

Optional accelerators

Mixed Go/C++/GPU JSON routing exists on the mount backends. Automatic routing is Linux amd64 today. You own sync and placement.

Dtypes and quants stay real in storage. Not a QAT morph that quietly becomes float32 underneath.

Some published timings

Same shapes, honest timers from the book / matrices. Not "peak marketing" numbers.

Metal, Mamba forwards (book §88):

Qualcomm NPU, large shapes (go_v_qnn on Snapdragon X; DLL graphExecute vs Go f32 CPU):

Online layers still pay compose cost on the full Go→NPU call. The book calls that out on purpose.

Where it can train

Training lives in the Go runtime (forward, backward, step, TrainMode). You're not exporting to another framework to learn.

29 training modes

Not just SGD/backprop. See §67 TrainMode.

Modes include StepBP, Tween*, TweenSplit, HeadProxy, Linear, FastProxy, Sparse, Alt, cameral BranchModes, and more. On the big Tide boards, non-SGD modes beat matched SGD on Acc about 97–98% of the time. SGD still wins some individual boards. It's a baseline, not the religion.

Cameral

Cameral stacks sibling branches that share an input, merge, and can train under different rules. CamSync averages cam weights (and same-shape cross-layer pairs). Useful when you want learn / keep / share jobs running together under load.

Lucy

Lucy scores whether a net can keep serving while it learns:

Lucy Score ≈ Throughput × Availability × Acc (scaled)

That's what drove the Tide/Ocean runs: cameral×LR sweeps, Test53 mode farms, volatile cloud soaks, Pi 1GB layer farms.

Train support by backend

Layers and the Dense core

Most transformer/CNN FLOPs are weights × activations, so Welvet keeps one Dense stack as the shared MatVec kernel (FormatNone×34 + 20 quants × CPU/SIMD/WebGPU). Layers that are mostly GEMV reuse it.

Layers include Dense, MHA (RoPE / GQA), SwiGLU, RMSNorm, LayerNorm, Embedding, Softmax, Sequential, Residual, CNN1–3, RNN/LSTM, SeqMix, GDN, Mamba, ConvT 1–3, Soft K-Means, Parallel, Metacognition.

Also: volumetric grids, ENTITY save/reload, HF helpers, tokenizer/sampling, DNA/evolution/tween, telemetry.

Runs on ugly hardware

Catalogue: openfluke.com/welvet/experiments

Four experiment waves (cameral LR, Test53 modes, volatile Linode soak, Pi 3B ~1GB farm) finished 90,334 Tide model cells.

1. Cameral × LR: does width and LR matter under Lucy live-fit?
2. Test53: dense × all 29 modes × storage types × aggressive LRs; Ocean compares cam1 vs cam3
3. Volatile online: cheap VMs, restarts, crowded dashboards. Checkpoint resume mattered. Cells stayed storage-truth (no silent float32 "rescue")
4. Pi 3B / 1GB: 22 layer sprints. Dense/CNN/norms were fast; MHA/LSTM/Mamba still finished. One dense champ hit Lucy Score ~16344 on fp4 tween_chain with >100k outputs/sec. CNN1 hit ~94% hard Acc on a Lucy champ. Mode-vs-SGD Acc beat-rates ~97–98%

I'm not claiming SOTA. The point is live-fit on honest storage, from Macs to $5 VMs to 1GB Pis, with artefacts you can open.

Welvet app (separate, still early)

The library is the Go engine. The Welvet app (0.1.0+1) is a different thing: run and serve models on Linux, Windows, macOS, iOS, and Android.

• openfluke.com/welvet/app
• openfluke.com/welvet/models
• Round 1 demos on CUDA/Metal/Vulkan-class stacks
• 15 models in the public matrix right now
• "Working" means it runs. Not that it's fast or best yet.

Not language-only. Detection, tracking, classification, depth, segmentation, pose, audio, etc. are in the mix.

Validation / family repos

Engine code stays in welvet/. Proof and wrappers live elsewhere, mainly w2a (Go↔native parity for cpp/cuda/metal/vulkan/rocm/mlx/qnn), plus C ABI, Python ctypes, and TypeScript/WASM.

Sibling engines: welvet.cpp, welvet.cuda, welvet.metal, welvet.vulkan, welvet.rocm, welvet.mlx, welvet.qnn.

Hard rules: no silent fallbacks, no hardcoded float32 tensors, storage-truth train, fail closed if a sibling binary is missing.

Links

If you write Go and want train+infer in-process, or you care about dtype honesty and learn-while-serve on edge boxes, give it a look.

1. openfluke.com/welvet
2. Feature book
3. github.com/openfluke/welvet
4. Experiments

I'm Samuel Watson / OpenFluke, Australia. Forks and harsh readings of the scorecard are welcome. The docs try to keep implemented features, recorded measurements, and stubs clearly separated.