AI Compute Stack for Training and Inference | Dweve Core

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

Coding agent and operator assistance. Demo metrics are illustrative.

Terminal, search, lint, test, git, and more.

Remembers your codebase and team context.

Specialised agents collaborate across concerns.

Review diffs, request changes, final sign-off.

Replay any session bit-for-bit when something needs review.

Autonomous agents that write code and keep receipts

to handle network timeouts, 5xx responses, and idempotent-safe conditions. Pure helper, fully unit-tested.

Capability and determinism stated per cell

Direct operation on customer-controlled infrastructure

the definition and execution slowly disagree

Runs on ordinary computers, where supported

execution cell and replay contract recorded

Dweve Core is a complete AI compute stack for training and inference. Most AI platforms cover a slice and hand the rest to other vendors. Core keeps model authoring, training, inference, kernels, dispatch and deployment in one coherent system. On supported binary workloads, Core uses 96% less energy than a GPU stack.

Partial systems create permanent dependence

The definition and the execution slowly disagree.

Compression lives in someone else's tool.

New hardware, new serving system, new behaviour.

The vendor's roadmap becomes your roadmap.

No single system can explain the result.

Dependence persists because the computational space underneath is only partially covered.

Core keeps changes in numerical width, packing, hardware and deployment inside one implementation system. An algorithm does not become a different product because it moves from an x86 server to ARM, a GPU, a browser or a specialised target. The operation remains named, inspectable and owned throughout the move, and every path is registered rather than inferred from a format label.

The implementation registry spans more than 2,900 operations, 76 operation categories and 25 registered numerical format families. Each path is determined across nine dimensions: algorithm, datatype, width, packing, accumulator, backend, instruction set, dispatch policy and determinism mode. The representation contract keeps those numerical and physical choices attached to the operation. The visual below fixes most of those dimensions so a small representative slice remains readable. The count describes a registry of concrete cells and contracts, not a claim that a format label or broad capability badge alone explains an execution path.

Which path is chosen, under which contract.

The sample is small because the implementation registry is not.

A new width, packing, host, or contract arrives.

The machine picks the path for the new cell.

Which code ran, on which machine, stated.

The first inherited assumption Core removes is that one datatype should dominate everything.

The processor should be just as replaceable as the datatype.

Core does not treat one accelerator ecosystem as the definition of AI and everything else as a lesser port. Its operations have scalar reference implementations and target-specific paths across supported CPU, GPU, FPGA, browser, and deployment backends. The runtime selects an implementation according to the available machine and the policy attached to the work.

A modern x86 processor can use its vector instructions. ARM and Apple silicon can use their native paths. NVIDIA, AMD, and Apple GPUs can use their respective backends. Browser execution can use WebAssembly or WebGPU where appropriate. Deployment programmes can target specialised hardware. The processor is a destination for the operation. It is not the owner of the model.

x86 vectors, ARM and Apple silicon native paths.

NVIDIA, AMD, and Apple GPUs on their own backends.

WebAssembly or WebGPU where appropriate.

Specialised hardware for deployment programmes.

Broad target labels are cheap. Owning the real path is harder.

The datatype was unsupported, the target hardware changed, and the quantiser needed another runtime.

The serving stack could not replay the result. Procurement opened another supplier review.

You did not add one feature. You exposed another hole in the machine.

Hand-tuned means someone owns the result

A broad API is easy to advertise. Broad machine-level ownership is much harder. Core does not count an operation as covered merely because a generic implementation compiles on another target. The supported paths are implemented and tuned for their actual combination of operation, representation, packing, backend, and instruction set.

Binary matrix multiplication on AVX-512 is not treated as floating-point matrix multiplication with smaller values. Packed-bit operations use the bit instructions available to the machine. Integer and fixed-point operations use the correct accumulator and overflow behaviour. GPU paths use the execution structure of the target. Scalar implementations remain present as the reference and universal floor. That creates an accountable answer to a simple question: what code actually performed this operation on this machine? Core can name the path.

Bit instructions for bits, not scaled floats.

NEON kernels written for ARM's own vector architecture.

That ownership must continue beyond the kernel and across the entire model lifecycle.

One machine from definition to inference

Trained for the representation it will use.

Benchmarked and replayed in the same machine.

Once the lifecycle is coherent, variation can become a contract rather than an accident.

Core states the contract of the path that actually ran. Core Native binary, ternary, signed and unsigned integer, fixed-point, adaptive and exact paths are pure deterministic where covered, with no seed. Core Native floating, bfloat, block-scaled and microscaled paths use seeded replay. Optional Core on Kera makes supported paths in those floating families pure deterministic too.

A regulated low-bit, Q-format or adaptive workflow can demand bit-identical Core Native replay. A floating-family workflow can use a pinned seed and complete record under Core Native. Creative sampling remains a separate generation choice. A deployment that requires pure deterministic bfloat, block-scaled, microscaled or conventional floating execution can use Core on Kera and remove the seed. These are different declared contracts for the selected cell, not interchangeable marketing names for every repeated answer.

Binary, integer, Q, adaptive and exact paths. No seed.

Floating, bfloat, block-scaled and microscaled replay.

Supported floating-family paths, no seed required.

When behaviour changes, one system should still own the explanation.

When a production result changes in a fragmented stack, responsibility is distributed. The framework blames the exporter. The exporter blames the runtime. The runtime blames the kernel. The kernel blames the driver. The driver blames the hardware. Core brings those responsibilities inside one system.

The model definition, numerical choices, selected backend, dispatch path, determinism mode, and resulting execution record can be examined together. That does not mean every external dependency disappears. Data sources, applications, operating systems, and hardware still exist. It means the AI machine itself has one accountable boundary. A review can ask which implementation ran, on which supported target and under which replay contract, without stitching the answer together from several vendors’ internal systems.

The definition and its numerical choices.

Representation, width, accumulator, mode.

The selected path and the machine it ran on.

The record that lets the run be examined again.

Core keeps one AI machine, but it has two execution postures.

Either posture should let the deployment move without replacing the AI system.

The hardware can change without replacing the AI system

Infrastructure decisions should not force a model rewrite. Core keeps the model, operator surface, numerical design, and execution contract inside the same system while the deployment posture changes. The selected backend may differ. The organisation does not need to reconstruct the AI stack around it.

A licensed team may operate Core on organisation-controlled clusters or workstations. A regulated programme may require a fully isolated estate. A product may move part of its inference to the edge, while a browser application may need a local execution target. Core keeps those licensed operating postures inside one machine without claiming that every backend supports every cell. Core is not a managed-service product. The licence describes an operating posture and its supported scope, not a claim to every possible target or workload.

Licensed on organisation-controlled infrastructure.

Local execution where the product lives.

No external dependencies permitted, still Core.

For European organisations, control over the machine is part of control over the AI.

Core is designed and built in the Netherlands. It is licensed for direct operation on systems controlled by the customer, at supported local and edge targets, or in isolated environments where external dependencies are not permitted. With the Dweve managed service, you use Core through Fabric; direct operation requires the licence. European origin does not create compliance by itself; it creates control over the machine that performs the work.