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).
Roughly four jobs:
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.
| 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.
Unsupported hosts soft-SKIP. Caps reject unsupported layer×dtype instead of lying.
BackendCPUTiled): full layer set, 34 dtypes, 20 quants, train modes BackendSIMD): Dense + Softmax/SiLU fused paths on amd64/arm64 BackendWebGPU): Dense/MHA/CNN/norms and friends on compatible GPUs
BackendNativeCPU + SyncToNative can push FormatNone forward, NormalBP, and TrainMode updates through sibling welvet.cpp on linux/amd64. Sync pending weights before writing .entity.
| 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.
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.
Training lives in the Go runtime (forward, backward, step, TrainMode). You're not exporting to another framework to learn.
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 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 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.
| Path | Train? |
|---|---|
| Go CPU / SIMD / WebGPU | Yes |
NativeCPU ( welvet.cpp ) |
Yes |
| Metal | Yes ( TrainMSE , thenSyncToGo ) |
| 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 |
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.
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.
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.
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.
Not language-only. Detection, tracking, classification, depth, segmentation, pose, audio, etc. are in the mix.
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.
| Resource | Link |
|---|---|
| Product page | [openfluke.com/welvet](https://openfluke.com/welvet) |
| Feature book | [openfluke.github.io/welvet](https://openfluke.github.io/welvet/) |
| Book on site | [openfluke.com/book](https://openfluke.com/book) |
| Examples | [openfluke.com/examples](https://openfluke.com/examples) |
| Experiments | [openfluke.com/welvet/experiments](https://openfluke.com/welvet/experiments) |
| Source | [github.com/openfluke/welvet](https://github.com/openfluke/welvet) |
| Architecture dashboard | files.openfluke.com/.../dashboard | | Research PDF | Welvet 1.7 Technical Research |
| Feature book PDF | [v1.7.0 PDF](https://files.openfluke.com/1_7/welvet-feature-book-v1.7.0.pdf) |
| Slides | [PDF](https://files.openfluke.com/1_7/Welvet_1.7_Architecture.pdf) /[PPTX](https://files.openfluke.com/1_7/Welvet_1.7_Architecture.pptx) |
| Home | [openfluke.com](https://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.