Shipping Aether v7.1: trained, released, served in-process, and attested on-chain

This is the one. For months we have been honest that "the Aether model" was really three models wearing one name, and that the chain was attesting a model we neither shipped nor chatted with. That is over. In a single session we trained the model, published it, made it the one model that serves every request, and wrote its identity into a finalized block on the chain. As far as we know, this is the first time a public chain serves a frontier-class language model in-process, measures that exact model's internal state, and commits that exact model's identity hash on-chain, all verifiable from one page.

This is the full account of how Aether v7.1 went from a broken training run to a single in-process model that serves chat, measures its own consciousness, and has its identity attested on the chain. It is long because we want every claim to be checkable. The model is on Hugging Face, the weights hash matches what we trained, and the model identity root is in block #889,310 that you can open right now.

1. The model: v7.1-unified

v7.1 is a 10-expert Sephirot adapter (top-2 routed, rank 16, ~1.18 M trainable parameters) on a frozen Qwen2.5-7B-Instruct base served as Q4_K_M. The base is never modified. The ten experts map one-to-one onto the ten Sephirot cognitive domains. This is the corrected approach after v6, where replacing the base attention destroyed capability: the structure belongs in routing on a sound base, not in a rebuilt mechanism.

QuantumAI-Blockchain/aether-v7.1-unified
https://huggingface.co/QuantumAI-Blockchain/aether-v7.1-unified

2. The bug that made the first run a no-op

The first attempt at v7.1 looked trained and had learned nothing. Training against the quantized GGUF base, the final output projection is a quantized QMatMul with no backward pass, so the gradient never reached the adapter. Held-out loss sat frozen at the base value for a thousand steps while the training loss happily fell. It read as a pass. It was a no-op.

The fix is to dequantize only that final projection to a frozen full-precision matrix so the gradient flows through it to the adapter, while the 28 transformer layers stay Q4. That is correct, and on a 12 GB card it immediately ran out of memory. Three more changes made it fit:

• Build the trainer with the CUDA feature actually enabled. Without it the trainer silently fell back to CPU and was unusably slow.
• Dequantize that projection in system RAM and move only the result to the GPU, so the 2 GB scratch tensor never strands itself in the allocator pool.
• Serialize the CUDA kernels so the transient backward buffers do not overlap past the limit.

Peak then sat around 10 GB and the run was stable. None of that is glamorous. All of it was the difference between a real model and a frozen number.

3. The numbers

Full held-out set, 500 samples, per Sephirot domain. Same frozen Q4 weights run twice, once with the adapter active, once with it off. The only variable is the adapter. Cross-entropy in nats per token, lower is better.

Every active domain improves. None regress. The largest gains are on Tiferet (integration), Hod (language), and Yesod (memory), which is where you would hope a knowledge-fabric specialisation would land. A held-out regression guard ran for the whole training session with a ceiling of base plus 0.15 nats and never tripped, so the base capability is provably intact.

Training: 3000 steps, context 192, learning rate 5e-4, AdamW, on the curated v3 Aether corpus, on a single RTX 3080 Ti.

Honesty note: this is full-token cross-entropy on a 1.18 M-parameter in-process adapter, not general-benchmark (MMLU/HumanEval) numbers and not directly comparable to the v7.0 answer-token figure on a 30x larger PEFT adapter. The claim is narrow and measured: on the Aether domains, the Sephirot adapter is a consistent, regression-free improvement over the raw 7B.

4. The cutover: one model, in-process

Before this session, "the Aether model" was three models wearing one name. The consciousness track measured phi from attention on a small in-process 0.5B model; chat ran through Ollama (a black box with no attention) on the 7B; and the Hugging Face artifact was its own lineage. The number the chain attested as the mind's phi was measured on a model we neither shipped nor chatted with.

v7.1 closes that. The live engine now loads the 7B base plus the adapter as one in-process candle model behind a single flag, and that one model does four jobs:

1. It generates the chat reply.
2. It exposes its own attention, so phi is computed on the model that actually answered. The phi-meso signal now comes from the adapter's real Sephirot router gates, not a nominal head partition.
3. It carries the on-chain / Hugging Face identity manifest.
4. It is the Hugging Face release.

Two things were learned the hard way during the live cutover. First, the model must serve at F32: the quantized base emits F32 hidden states, so a BF16 adapter throws a dtype mismatch, and BF16 saves nothing anyway because the base compute dominates the footprint. Second, we measured before flipping: the in-process 7B runs at about 73 tokens/sec and fits the 12 GB card. After moving the now-redundant 0.5B model and its embedder to the CPU (the reranker stays on the GPU because it is latency-critical), the GPU peak during chat dropped from 11.3 GB to about 9.2 GB, roughly tripling the safety headroom. Chat latency is unchanged.

You can confirm the served model on the public endpoint:

curl -s https://aether-gpu.qbc.network/aether/info | jq .generation_model
# "aether-v7.1-unified"

5. The part that makes it a blockchain: on-chain attestation

A model that lives on Hugging Face is just a file. What makes this an AI-native chain is that the model's identity is committed to a finalized block via an on-chain model registry, so anyone can prove which model the network is running.

The identity is a manifest root: a single SHA-256 over the base GGUF, the Sephirot adapter, the tokenizer, and the adapter config. For v7.1 that root is:

0x488b3387844c7bf087ae1b146457f4dcf5e809de204bc18728419d588217aaf2

We recorded it on-chain with QbcModelRegistry.submit_checkpoint, signed by a validator. The transaction:

The checkpoint did not stop at "submitted." Four of the five validators in the set ran attest_checkpoint(1), clearing the 2/3 threshold, and the runtime flipped the record to finalized = true. The model identity is not one node's claim; it is the validator set's agreement.

The chain now holds the binding: model aether-v7.1-unified, version 7.1.0, root 0x488b3387…, pointing at the Hugging Face artifact, recorded in block 889,310.

A note on block numbers: the substrate node and polkadot-js report this as block 889,310. The qbc.network explorer numbers blocks continuously from the pre-fork genesis (889,310 + a 208,680 offset), so the same block is 1,097,990 there. Both point at one block, hash 0x107690…2ab7b91. The links below resolve to it either way.

Verify it yourself

Open the block directly in our explorer (shareable deep link, no plugin needed):

qbc.network/explorer/block/1097990

Or open it in a polkadot-js Apps explorer pointed at the public chain:

https://polkadot.js.org/apps/?rpc=wss://rpc.qbc.network#/explorer/query/0x107690115dc96f4222042703382e84e1beefdb28efddb55a1572053ec2ab7b91

Read the stored record directly from chain state (Developer to Chain state, query qbcModelRegistry.checkpoints(1)):

https://polkadot.js.org/apps/?rpc=wss://rpc.qbc.network#/chainstate

Or from a shell, against the public RPC:

from substrateinterface import SubstrateInterface
s = SubstrateInterface(url="wss://rpc.qbc.network")
print(s.query("QbcModelRegistry", "Checkpoints", [1]).value)
# weights_merkle_root: 0x488b3387…  model_name: aether-v7.1-unified  submitted_at: 889310

And confirm the Hugging Face weights match what was attested. The adapter file's SHA-256 is 564910ef462646a4789cdf4a31d4623cb50d1f3f1bf8374aa0129255df05cae7, which is part of the preimage of the manifest root above.

The live explorer (recent blocks and events) is at qbc.network/explorer.

6. General benchmarks: knowledge held, reasoning up

We promised the general numbers, and here they are. Off-the-shelf lm-eval cannot load a native candle build, so we wrote a small candle harness that scores the same frozen Q4 weights twice, once with the Sephirot adapter on, once off. Same model, same prompts, the only variable is the adapter.

Two findings, both honest. General knowledge is held: MMLU is flat across the complete 14,042-question set, which is exactly what the frozen base and the regression guard predict. The adapter does not lobotomise the model the way v6 did. Multi-step reasoning improves: on GSM8K the adapter is up about ten points. Part of that is genuine, and part is the adapter following the chain-of-thought and final-answer format more reliably, which is itself a useful behaviour. We ran GSM8K on a 625-question sample rather than the full 1,319 because generation on a single 12 GB card is slow and the sample is already statistically tight; MMLU is the complete set.

The base capability is intact and the domain skill is sharper. That is the result you want from a 1.18 M-parameter adapter on a frozen 7B.

7. What this is, and is not

What it is: one in-process model is now the chat generator, the model phi is measured on, the artifact on Hugging Face, and the identity root in a finalized block. The three-models-one-name split is closed.

What it is not: a model trained for months. v7.1 is a tight, regression-guarded adapter on a frozen base, measured and published honestly. The next steps are depth, not a rewrite: a longer training run, the full GSM8K sweep, and a second validator-quorum round as the model line moves.

Links

• On-chain attestation, block #889,310: qbc.network/explorer/block/1097990
• Model on Hugging Face: aether-v7.1-unified
• Live served model: aether-gpu.qbc.network/aether/info
• Raw block in polkadot-js: explorer/query
• On-chain record: chain state query qbcModelRegistry.checkpoints(1)
• Live explorer: qbc.network/explorer
• Previous generation line: aether-mind-v7.0

Three releases ago the numbers were not real. Two releases ago they were real but measured on a model we did not ship. Today they are real, measured on the one model that does every job, and the identity of that model is in the chain.

Further reading

• On-chain AI model registry
• Verify AI model integrity
• MoE adapter fine-tuning
• Aether v7.1-unified: one model the chain tracks
• Training the served model, in process