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

Samuel Watson — Thu, 12 Nov 2026 23:06:53 +0000

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)

Area	What you get
Language	Open-source Go AI / ML engine
Core	Train + local inference
Numbers	34 storage dtypes, 20 quant formats, storage-truth (no QAT morph)
Training	29 named training modes, including cameral / multi-branch
Defaults	Go CPU tiled, Plan 9 SIMD, WebGPU
Optional CPU	NativeCPU via `welvet.cpp` C ABI
NVIDIA	CUDA sessions (train + `SyncToGo`)
AMD	ROCm sessions (library validated; GPU compute needs HSA)
Apple	Metal train/run, MLX forward-only
Vulkan	Linux x86_64 train + `SyncToGo`
Qualcomm	Hexagon HTP on Windows ARM64 (Snapdragon X)
Other	Layer packages, spatial grids, MoE / cameral parallelism
Platforms	Linux, Windows, macOS (app also targets iOS and Android)
Docs	Book chapters, examples, `w2a` validation

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

Go CPU tiled (BackendCPUTiled): full layer set, 34 dtypes, 20 quants, train modes
Plan 9 SIMD (BackendSIMD): Dense + Softmax/SiLU fused paths on amd64/arm64
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

Backend	Sibling	Hosts	Forward	Train	Notes
Apple Metal	`welvet.metal` / `nativemetal.Mount`	Apple silicon macOS	Yes	Yes	Explicit `SyncToGo`. Not Apple Neural Engine. Book §82–88
Apple MLX	`welvet.mlx` / `nativemlx`	Apple silicon macOS	Yes	No	Forward-only. Book §110–113
NVIDIA CUDA	`welvet.cuda` / `nativecuda.Mount`	Linux x86_64, Windows amd64	Yes	Yes	Two weight copies until `SyncToGo()`. Book §89–95
AMD ROCm	`welvet.rocm` / `nativerocm.Mount`	Linux x86_64, Windows amd64	Yes (API)	Yes (API)	Library validated; GPU compute untested until HSA. Book §96–102
Vulkan	`welvet.vulkan` / `nativevulkan.Mount`	Linux x86_64	Yes	Yes	No silent host fallback labeled as Vulkan. Book §103–109
Qualcomm Hexagon HTP	`welvet.qnn` / `BackendQNN`	Windows ARM64 (Snapdragon X)	Yes	n/a	Explicit sync/prepare. Never Prefer default. Book §79–81

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):

dtype	Go	Metal	Metal/Go
float64	89.3ms	29.0ms	3.1×
float32	69.0ms	29.0ms	2.4×
float16	190.5ms	28.9ms	6.6×
bfloat16	149.4ms	29.0ms	5.1×
fp8e4m3	265.9ms	29.2ms	9.1×

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

Layer	dtype	Go f32	NPU DLL	vs Go
Dense	u8	3.05ms	164µs	~95% faster
Dense	f32	3.05ms	201µs	~93% faster
CNN2	i8	12.56ms	763µs	~94% faster
MHA	f16	4.51ms	372µs	~92% faster

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

Path	Train?
Go CPU / SIMD / WebGPU	Yes
NativeCPU (`welvet.cpp`)	Yes
Metal	Yes (`TrainMSE`, then `SyncToGo`)
CUDA	Yes (train on GPU, `SyncToGo` before save)
Vulkan	Yes
ROCm	API yes; GPU compute pending HSA
MLX	No (forward-only)
QNN	Forward / prepare-exec; see book caps

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.

Cameral × LR: does width and LR matter under Lucy live-fit?
Test53: dense × all 29 modes × storage types × aggressive LRs; Ocean compares cam1 vs cam3
Volatile online: cheap VMs, restarts, crowded dashboards. Checkpoint resume mattered. Cells stayed storage-truth (no silent float32 "rescue")
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

Resource	Link
Product page	openfluke.com/welvet
Feature book	openfluke.github.io/welvet
Book on site	openfluke.com/book
Examples	openfluke.com/examples
Experiments	openfluke.com/welvet/experiments
Source	github.com/openfluke/welvet
Architecture dashboard	files.openfluke.com/.../dashboard
Research PDF	Welvet 1.7 Technical Research
Feature book PDF	v1.7.0 PDF
Slides	PDF / PPTX
Home	openfluke.com

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.

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.

DEV Community: Samuel Watson