D11 integer table serving (UORLUT01)

Status: ACTIVE. It is the end-of-pipeline contract: the finished model must ship as one integer artifact, and this engine runs it. The engine reproduces its reference answers exactly, and its zero-multiply audits are green. But no model built under today's rules has been exported through it yet, and the models it has served were not good enough. It is ACTIVE as the export boundary; no model built under today's rules has gone through it yet.

Labels used below: proof means derived from definitions or code, measurement means a recorded run, hypothesis means an untested idea. See docs/formal_vocabulary.md.

In plain words

This is how a finished model runs on an ordinary laptop or in a web browser using only whole numbers: adds, shifts and table look-ups. There is no decimal arithmetic and no multiply instruction. A trained model is exported to a compact file, mostly 4-bit numbers. A checker then reads the compiled program and counts machine instructions to prove that no multiply sneaks in. The engine reproduces its reference answers exactly, and the checks are green. But it has only served older models that fell short of their bars, and no model built under today's rules has been exported through it.

What it replaces in a transformer

The arithmetic. A transformer runs on large matrix multiplications. Here the same weights are read through tables, so every product is a table read and an add. This changes how a model is computed, not what it is. The engine does not make a weak model better, and, as the history below shows, it still reads every stored weight for every token.

Left, how a dot product needs no multiply. Middle, the engine is exact and the loss is in rounding the weights. Right, the audit counts instructions in the compiled program.

Its chapter in the project's history

• July to August. The first multiplier-free runtime came from the compiled-graph approach (r4g1-graph). Its contract said only serving must avoid multiplies and allocation (#157).
• 25 September. Learned attention, recurrence and rotation from two 1.68-million-parameter models ran with integer arithmetic and tables, and the standalone integer library reproduced the saved distributions (#1397).
• 26 to 29 September. An interim "D10" engine allowed multiplies and a softmax table. On 27 September the owner replaced it: D11 made multiplier-free, transformer-free serving the one contract for every lab (#1443). A first energy test found table emulation of every product used about 4.3 times more energy than float (#1449).
• 8 October. The first chat model was trained, exported and served end to end (#1893). On 10 October three 29-million-parameter models served at 1.20 to 1.24 bits per byte, and four softmax-free serving reads missed their bar.
• 12 to 13 October. The bans on softmax and matrix multiplication moved the older multiplier-allowing engines out of every build (D29).
• 18 October. D37 made the integer export the boundary: training may use float, serving may not. The native zero-multiply audit went green (#2655) and a contributor-built WebAssembly runtime followed (#2654).
• Next. Export one discrete model through the container and measure the export gap (milestone M4).

Under the charter, serving this artifact on client devices (CPU, browser WebAssembly, Apple silicon) is the product and is allowed.

How it works

Export. Training is offline and may use float. For serving the weights go into a UORLUT01 container. Weights are 4-bit codes in groups of 32. Each group has a one-byte scale (a 4-bit mantissa and a 4-bit exponent). A few small integer tables cover the nonlinear steps (square root, decay rates, SiLU, arcosh, exp).

One projection (definition). For a weight matrix \(W\) and an integer activation vector \(x\), the output is \(y_i=\sum_j w_{ij}x_j\), where each weight is a group scale times a 4-bit code, \(w_{ij}=s_g\,q_{ij}\) with \(s_g=m\,2^{e}\). The engine does not multiply \(q_{ij}\) by \(x_j\). For each activation it builds a 16-entry table \(T_j[q]=q\,x_j\), which needs only additions to fill, and then reads \(T_j[q_{ij}]\) for each weight. Four output rows are blocked to reuse the table. The scale \(s_g\) is applied by shifts and adds.

Products of two runtime values. A score, a gate or a value mix needs a true product of two numbers known only at run time. The engine builds a table of the sixteen multiples of one operand by repeated addition, reads it at each base-16 digit of the other operand, and sums the reads with shifts: \(ab=\sum_k 16^k\,T_a[d_k(b)]\), exact by the definition of base-16 digits (proof; stack_mul_u64 and stack_mul_u128 in kernels.rs). The quarter-square identity would also be allowed, but the serving engine does not use it. Normalisation uses an integer square root or a table. Sampling is integer min-p.

Session state. A conversation's state is saved and restored byte-for-byte (the UR4SESS1 format).

The five rules (D11). R1: no floating point and no maths library. R2: no multiply or divide instruction. R3: dense per-token access to a learned store is interim, not the end state (D5). R4: no transformer backbone. R5: energy is claimed only when measured.

The audit. The release binary is disassembled, and the multiply, divide and float instructions are counted over the serving symbols, natively and in WebAssembly. The audit proves absence of those instructions. It says nothing about model quality, and the SIMD kernels in the WebAssembly build are unintegrated fixtures that the 7-of-7 audit never exercises (record).

Geometry, as exact finite tables. The 120-element icosian group's Cayley table (about 14 KiB), a 1,025-entry arcosh table for Lorentz read scores, icosian-pair weights and the Q30 Hopf observation are stored as tables. The current integer crate selects typed H4 geometry and checked integer arithmetic for the discrete model's own export (native_geometry.rs).

Rule check.

What has been tried

"Gap" means served minus float score. "Bits per byte" (BPB) is the model's loss on a held-out chat stream, lower is better; the milestone bar is at most 0.90. The D10 engine is the older engine that allowed multiplies. A "D11 minus D10" loss of 0.0 therefore means the multiplier-free engine reproduces the older one exactly.

Reading these honestly. Two things are true at once. The engine is exact: every windowed comparison matched its reference to within about 1e-6 bits per byte (exactly, on the 64-window D11-minus-D10 checks), and the audits count zero forbidden instructions. And the models it served were weak, and it is not yet fast. The loss between float and integer is weight rounding, about 0.009 bits per byte on matched positions, not the engine. Table-based products on a dense model cost more energy and time than float. A dense model streamed through tables is still dense, which is why the project's sparsity rule asks for selected, addressed reads instead.

What has never been tested

• Serving a model built under today's rules (discrete or lawful float) through the container. Its export gap is unmeasured.
• Hardware-counter measurement of memory traffic per token (D5-a) and of parameters touched per token (D5-b). Milestone M5 has not run.
• Whole-system energy per token with a validated sampler. The only earlier figures (5.7 and 21.0 millijoules per token) came from a truncated capture.
• Integer serving of a product-key or other addressed memory read. The kernel is not built.
• A comparison with the SIMD kernels on the serving hot path.
• Free-running generation speed. The 184.58 tokens/s figure was input-driven forward throughput.

What stays frozen, and what would restore it

This mechanism is active, so nothing here needs reopening. Two sub-parts are held:

1. The D10 engine and its SIMD crate stay frozen, non-mission comparators. They return only if an owner decision restores a serving tier that allows multipliers, which D11 withdrew.
2. Serving of product-key or addressed memory needs an integer read kernel. The exporter refuses it today.

Open questions. What is the export gap of a discrete or allowed float model through the container, and does UORLUT01 need a new schema for table-native models? How many of the 30.2 million parameters touched per token can selected reads remove before tokens per second move, given that arithmetic count was not time? Are the audit scripts, which are Python, to be ported to Rust and run in CI?

Also known as

UORLUT01; the D11 integer engine; the D10 LUT engine (superseded); uor-r4-lut; uor-r4-stack and uor-chat; multiplier-free serving; the zero-mul audit; serving-wasm; the LUT-4 shortlist (retracted).

Code

• kernels.rs: table kernels, blocked product tables, radix-16 multiples-table products (stack_mul_u64, stack_mul_u128). session.rs: the per-token step and exact session state.
• format.rs: the container and its schemas. flock.rs: integer flock rank selection.
• simd.rs: WebAssembly SIMD fixtures, not on the hot path. wasm_serve.rs: browser and Node entry points. session_codec.rs: the exact session snapshot.
• native_geometry.rs: integer geometry for the discrete model's export. uor-r4-stack.rs: the command-line program the audit checks.
• audit_zero_matmul_serving.py and audit_zero_matmul_wasm.py: the native and WebAssembly instruction audits (existing Python scripts).
• uor-r4-lut: container metadata only, with the dense engines excluded. preserved D10 engine and uor-r4-simd: frozen. stack_export.rs: the old exporter, compiled out.
• Evidence: served stacks, protocol pin, port design.

Related mechanisms

geometric-stack: the float model this engine exported and served; the engine is exact and the stack's quality is the limit. flock-read: the softmax-free read that schema 3 can serve; trained arms missed the bar. exact-memory: addressed memory the engine cannot yet serve. spin-weights: icosian-pair weights that make table serving of quaternion maps exact. ternary-xor: the multiplier-free arithmetic substrate. r4g1-graph: the earlier frozen table runtime with the same no-multiply rule. discrete-learning: the live model whose integer export is the next thing this must carry.