openflukeOPEN-SOURCE GO AI ENGINE · v1.7.0
Welvet Go AI Engine · Welvet Golang AI Engine
Welvet is an open-source Welvet Go AI engine (Welvet Golang AI engine) for neural network training and local inference. Run and train on your own hardware with CPU, SIMD, WebGPU, NativeCPU, Vulkan, AMD ROCm, NVIDIA CUDA, Apple Metal, Apple MLX, and Qualcomm Windows NPU.
Go neural network training and inference
Welvet is a Golang machine learning engine: you define networks in Go, train them with multiple learning modes, and run inference locally. It is open source at github.com/openfluke/welvet, with a full feature book, recorded examples, and validation suites.
CPU, CUDA, ROCm, Metal, Vulkan and Qualcomm NPU support
Defaults stay portable Go CPU tiling, Plan 9 SIMD, and WebGPU. Optional accelerators cover NVIDIA CUDA, AMD ROCm, Apple Metal, forward-only Apple MLX, cross-vendor Vulkan, and Qualcomm Hexagon HTP on Windows ARM64 — so the same Go AI engine can target heterogeneous CPU, GPU and NPU hardware.
34 numerical types and quantization
Storage-truth dtypes and quants stay first-class in the engine instead of a separate QAT morph. That matters for Go deep learning workloads that need dense, low-precision, and mixed-precision paths without pretending every backend supports every type.
Cross-platform AI on Windows, Linux, macOS, iOS and Android
The Welvet library is the Go AI engine. The Welvet app (0.1.0, in development) is a separate cross-platform program for running and serving models on Linux, Windows, macOS, iOS and Android. Together they make on-device Go machine learning practical to explore.
Where Welvet sits among Go machine learning projects
If you are searching for a Golang AI engine, Go neural network framework, or open-source Go machine learning library with local train-and-run support, Welvet is that category of project: written in Go, focused on training and inference, documented with source and recorded results, and designed for heterogeneous hardware rather than a single cloud API.
NEW · WELVET APP 0.1.0+1 · v0.1 FOUNDATION
One app. Many devices. Many models.
Welvet is also becoming a cross-platform program for running and serving models on Linux, Windows, macOS, iOS and Android — with CUDA, Metal, Vulkan and related backends. Round 1 demos show working paths on real hardware; that is a baseline, not a claim of being fastest or best.
EXPLORATORY ARCHIVE
Training modes, dtypes, edge runs.
Cameral learning-rate sweeps, Test53 dense mode matrices, the volatile online Tide/Ocean soak, and Raspberry Pi 3B 1GB layer farms — catalogued with links to the original PDFs and JSON.
A model is the knowledge.
The Go engine makes it work.
An AI model stores patterns it has learned. To use those patterns, software has to load its numbers, perform calculations, and produce an answer. To learn, it also has to update those numbers.
Welvet builds that machinery as an open-source Go AI engine. The same work can run on ordinary CPU tiling, specialised SIMD instructions, WebGPU, optional NativeCPU through welvet.cpp, Qualcomm Hexagon HTP on Windows ARM64 via welvet.qnn, Apple Metal GPU sessions via nativemetal + welvet.metal, Apple MLX forward sessions via nativemlx + sibling welvet.mlx (new in v1.7), NVIDIA CUDA via nativecuda + welvet.cuda, AMD ROCm via nativerocm + sibling welvet.rocm, and cross-vendor Vulkan GPU sessions via nativevulkan + sibling welvet.vulkan on Linux.
This matters because the way an engine handles memory and calculation affects where intelligence can run, how much room it needs, and whether it can keep responding while it learns.
IN EVERYDAY TERMS
Give intelligence
room to work.
Run: use a model to produce an answer.
Train: adjust a model from experience.
Store: decide how its numbers fit into memory.
Measure: check what actually happens on the chosen hardware.
v1.7 EXPLAINER
Watch Welvet 1.7 — continuous on-device training.
A walkthrough of Welvet 1.7: storage-truth dtypes and quants (no QAT morph), multi-backend sessions, and continuous training on your own hardware.
DEEP RESEARCH · WELVET 1.7
Paper, feature book, slides, and audio.
The technical research paper, interactive architecture dashboard, feature book, slide deck, QAT-vs-Welvet infographic, and continuous on-device training audio briefing for v1.7.
v1.7.0 · APPLE MLX
Forward-only Apple MLX GPU via libmlx.
Opt-in BackendMLX / PreferMLX runs supported layers on the independent welvet.mlx library (1.0.0) through Go’s nativemlx binding. User-owned SyncToMLX / SyncFromMLX; Metal under the hood via Homebrew MLX. Forward-only — no TrainMSE / NormalBP on MLX. Caps reject unsupported layer×dtype. Defaults stay Go CPU / SIMD / WebGPU.
Needs Apple silicon macOS, cgo, shipped libwelvet_mlx.dylib, and Metal GPU. Sibling install: welvet.mlx/scripts/macos_install_go.sh. Validate with w2a go_v_mlx. Book chapters §110–113.
Apple MLX book chapters (§110–113).
Forward-only tour: SyncToMLX + BackendMLX forward, caps and dtype rejects, Dense prepare + Sequential, and suite pointers into go_v_mlx. No train / SyncToGo twin — that stays Metal §82–88.
Start at §110 → · Caps §111 → · Dense / Sequential §112 → · Suite pointers §113 → · welvet.mlx on GitHub ↗
v1.6.1 · VULKAN
Cross-vendor GPU sessions via Vulkan.
Opt-in nativevulkan.Mount runs layers on the independent welvet.vulkan library (0.79.1, ABI 1). Forward, train, explicit SyncToGo, JSON Go/C++/Vulkan routing, and ENTITY save/reload stay under your control. Defaults stay Go CPU / SIMD / WebGPU.
Mount and automatic JSON routing work on Linux x86_64 with a Vulkan 1.x-capable device + loader and installed libwelvet_vulkan. Pure-Vulkan contract: no silent host fallback labeled as Vulkan. Unsupported hosts soft-SKIP. Book chapters §103–109.
Vulkan book chapters (§103–109).
Same mounted-session tour as CUDA/ROCm/Metal: mount and forward, Mamba dtypes, all 29 training modes, SyncToGo + ENTITY, JSON placement, mixed Go/C++/Vulkan, and suite pointers into go_v_vulkan.
Start at §103 → · SyncToGo / ENTITY §106 → · Mixed Go/C++/Vulkan §108 → · Suite pointers §109 → · welvet.vulkan on GitHub ↗
v1.5 · AMD ROCm
GPU sessions on AMD hardware.
Opt-in nativerocm.Mount runs layers on the independent welvet.rocm library (0.79, ABI 1). Forward, train, explicit SyncToGo, JSON Go/C++/ROCm routing, and ENTITY save/reload stay under your control. Defaults stay Go CPU / SIMD / WebGPU.
Mount works on Linux x86_64 and Windows amd64 with HIP runtime and installed libwelvet_rocm. Automatic JSON routing is Linux amd64 today. Library build/load is validated; GPU compute remains untested until a ROCm-capable HSA device is available. Unsupported hosts soft-SKIP. Book chapters §96–102.
ROCm book chapters (§96–102).
Same mounted-session tour as CUDA/Metal: mount and forward, Mamba dtypes, all 29 training modes, SyncToGo + ENTITY, JSON placement, mixed Go/C++/ROCm, and suite pointers into go_v_rocm / rocm_smoke.
Start at §96 → · SyncToGo / ENTITY §99 → · Mixed Go/C++/ROCm §101 → · Suite pointers §102 → · welvet.rocm on GitHub ↗
v1.4 · NVIDIA CUDA
GPU sessions on NVIDIA hardware.
Opt-in nativecuda.Mount runs layers on the independent welvet.cuda library (0.79, ABI 1). Forward, train, explicit SyncToGo (pull trained weights back into Go), JSON Go/C++/CUDA routing, and ENTITY save/reload stay under your control. Defaults stay Go CPU / SIMD / WebGPU.
Mount works on Linux x86_64 and Windows amd64 with an NVIDIA driver/runtime and installed libwelvet_cuda. Automatic JSON routing is Linux amd64 today. Unsupported hosts soft-SKIP. Book chapters §89–95.
CUDA book chapters (§89–95).
Same mounted-session tour as Metal: mount and forward, Mamba dtypes, all 29 training modes, SyncToGo + ENTITY, JSON placement, mixed Go/C++/CUDA, and suite pointers. Train on CUDA, then SyncToGo() to update the Go/CPU stores before saving.
Start at §89 → · SyncToGo / ENTITY §92 → · Mixed Go/C++/CUDA §94 → · Suite pointers §95 → · Example snapshot →
v1.3 · APPLE METAL
GPU sessions on Apple silicon.
Opt-in nativemetal.Mount runs layers on the independent welvet.metal library (ABI 1). Forward, train, SyncToGo, JSON Go/C++/Metal routing, and parameter save/reload are explicit. Defaults stay Go CPU / SIMD / WebGPU.
Needs Apple silicon macOS, cgo, and the installed Metal dylib. Linux/Windows hosts keep ordinary CPU behaviour; unsupported examples print SKIP. This is Metal GPU acceleration, not Apple Neural Engine.
Captured Metal Mamba forwards.
From the labelled 2026-10-27 Mamba forward excerpt in book §88. These are numerical CPU/GPU comparisons on the supplied shapes, not model-prediction accuracy claims.
| 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× |
Full Metal RESULTS chapter → · Start at §82 → · Example snapshot →
v1.2 · QUALCOMM WINDOWS NPU
Hexagon HTP on Snapdragon X.
Opt-in BackendQNN routes Dense and friends through the sibling welvet.qnn DLL on Windows ARM64. Defaults stay Go CPU / SIMD / WebGPU. You sync and prepare explicitly: never a silent Prefer fallback.
Needs Snapdragon X (or similar) Windows ARM64, cgo, shipped libwelvet_qnn.dll, and Qualcomm QAIRT on PATH. Other platforms report unavailable and examples print SKIP.
Recorded NPU wins (large shapes).
From the published go_v_qnn matrix on Windows ARM64 · Snapdragon X. Numbers below are NPU DLL graphExecute vs Go f32 CPU on the same shapes (Dense prepare-once). Online layers still pay compose cost on the full Go→NPU call timer: see the book for honesty notes.
| Layer | dtype | Go f32 | NPU DLL | vs Go |
|---|---|---|---|---|
| Dense | u8 | 3.05ms | 164µs | NPU 95% |
| Dense | f32 | 3.05ms | 201µs | NPU 93% |
| CNN2 | i8 | 12.56ms | 763µs | NPU 94% |
| MHA | f16 | 4.51ms | 372µs | NPU 92% |
| LayerNorm | f16 | 6.82ms | 553µs | NPU 92% |
| Softmax | f16 | 4.31ms | 446µs | NPU 90% |
Full RESULTS chapter → · Example snapshot → · RESULTS.md on GitHub ↗
Different ways to calculate.
CPU tiling breaks a large task into manageable pieces. SIMD performs several calculations together. WebGPU makes compatible graphics hardware available for compute.
Explore the architecture →Apple MLX GPU.
v1.7 adds opt-in forward-only MLX via nativemlx + sibling welvet.mlx on Apple silicon. SyncToMLX, BackendMLX / PreferMLX, caps rejects; no train on MLX.
Vulkan GPU.
v1.6 adds opt-in Vulkan sessions via nativevulkan + sibling welvet.vulkan on Linux. Mount, train, SyncToGo, and mixed JSON routing stay explicit; no silent host fallback labeled as Vulkan.
AMD ROCm GPU.
v1.5 adds opt-in ROCm sessions via nativerocm + sibling welvet.rocm on Linux and Windows. Mount, train, SyncToGo, and mixed JSON routing stay explicit; GPU compute untested until HSA.
NVIDIA CUDA GPU.
v1.4 adds opt-in CUDA sessions via nativecuda + welvet.cuda on Linux and Windows. Mount, train, SyncToGo, and mixed JSON routing stay explicit.
Apple Metal GPU.
v1.3 adds opt-in Metal sessions via nativemetal + welvet.metal on Apple silicon. Mount, train, SyncToGo, and mixed JSON routing stay explicit.
Qualcomm Hexagon NPU.
v1.2 adds opt-in Hexagon HTP via nativeqnn + welvet.qnn on Windows ARM64. Dense prepare-once wins ~93–98% vs Go/native on DLL exec in the published matrix.
Optional native CPU path.
When you set BackendNativeCPU, FormatNone forward, NormalBP, and TrainMode updates can run through the welvet.cpp C ABI on linux/amd64. Defaults stay Go CPU tiled. Sync pending weights before writing .entity.
Different ways to learn.
Training modes investigate how a network receives feedback. Cameral systems explore multiple branches with different jobs, including learning, preserving knowledge, and sharing updates.
Explore cameral examples →Details you can inspect.
The documentation separates implemented features, recorded measurements, and future stubs. Results depend on the model, workload, backend, and hardware being tested.
How validation works →Paragon. Loom. Welvet.
Paragon and Loom were earlier engine designs in the same research journey. Welvet carries their lessons forward in a rewritten structure, with a shared calculation core and clearer boundaries between the engine, applications, and validation.
They belong to the story of Welvet. They are not separate new product directions competing with ALife: Becoming.
Start as simply as you like.
The overview is here to make the idea understandable. The book goes all the way into the implementation. The examples show specific features with source code and recorded outputs.