Blackhole Vector Compression
BHVC is my attempt to find a better way to store AI model weights. Instead of treating every weight as an isolated number, I am testing whether some of the structure can be stored once and reused.
The near-term target is simple to state and hard to earn: approach Q8-class storage while reconstructing exact BF16 or FP16 weights and keeping behavior near the FP32 reference.
Test whether common compression structure can be reused across tensors instead of repaid every time.
The immediate target is bit-for-bit BF16 or FP16 reconstruction, not an unproven FP32 claim.
Every archive has to decode on its own, count every byte, and survive quality gates.
The problem: models keep paying the full storage bill
Modern AI models are hard to run locally because the weights consume VRAM, system memory, and storage. FP32, FP16, BF16, Q8, and Q4 all help in different ways, but ordinary quantization still scales with the total number of weights.
Usually the bargain looks like this: smaller storage means less numerical precision, which can mean quality loss. The model may get cheaper, but every new layer, expert, or capability still adds another block of numbers that has to be stored.
The question: what if a model contains shared structure, and only the genuinely new information needs to be stored separately?
The BHVC idea
BHVC separates the storage question from the execution question. The long-term shape is:
shared structure
+ tensor-specific or capability-specific informationInstead of paying the whole compression cost again for every tensor, the project tests whether a common state can be paid once and reused. The black-hole language is metaphor: dense cores, event horizons, orbital prediction, ejection data, time dilation, recursive geometry. The names can be strange. The results still have to survive real tests.
What has actually been measured
BHVC has demonstrated a real shared-state effect on synthetic tensor families. A standalone BHVC tensor was larger than the scalar-int16 control because it carried the full shared-state cost alone. When multiple independent batches reused that same state, the combined package crossed over and became smaller than storing those batches independently with scalar int16.
BHVC package vs. 131,473 B scalar int16: 3,357 B smaller.
BHVC package vs. 525,896 B scalar int16: 77,380 B smaller.
Down from 76,385 B using deterministic zlib, with no reconstruction change.
All tested shared-state batches remained inside the current quality gates. This is the strongest result so far because it tests the central principle: common structure can be paid for once while additional tensors get cheaper.
Important boundary: this evidence is synthetic. BHVC has not yet demonstrated the same result on full real-model weight families.
The failures matter too
Removing the residual “ejection” data made the archive much smaller, but every partial reduction failed the current quality gates. The zero-ejection archive reached about 38,745 bytes for the test tensor, near a Q8-class footprint, but quality drifted badly.
TIDE, a predictive-geometry experiment using nearby reconstructed vectors to predict later vectors, improved several quality measures: MSE by roughly 50%, MAE by roughly 46%, plus better Top-1 agreement and Top-5 overlap. But its relationship metadata made the final archive larger and did not make the residual stream more compressible.
So TIDE is parked as a primary compression method. It may return later as a repair mechanism only if it lets another part of the codec use fewer bits without making the total file bigger.
The current target is 16-bit-native
I am now testing the 16-bit route directly: how much behavior changes when FP32 reference tensors become FP16 or BF16, whether the exact bitstreams compress well with ordinary lossless methods, and whether a shared-state codec can reconstruct them bit for bit.
The distinction matters. “Q8-class storage with exact BF16 reconstruction” is not the same claim as exact FP32 recovery. Exact FP32 archival recovery would need additional precision information.
How I keep the research honest
BHVC runs on a fast fail-or-promote loop. Each experiment asks one measurable question, creates a real serialized artifact, counts every byte, decodes without access to the source, and includes integrity and determinism checks.
- Frozen controls and negative controls where they apply
- Archive-only decoding, not hidden access to the original tensor
- Quality and rate reported separately
- Clear labels for bit-exact recovery, bounded recovery, functional equivalence, drift, and collapse
- Failed mechanisms stopped rather than endlessly patched into a story
Rule: no result is called “full precision” unless the exact recovered representation is named and proven.
Related to PlasticNode, but separate from it
BHVC researches how model information might be stored. PlasticNode researches how a custom AI model could grow and organize itself. HMS provides the harness, tools, memory, and governed working environment around that research.
There may be a future connection: PlasticNode could someday use BHVC-style work to store dormant or inherited capabilities more efficiently. That is not implemented. BHVC does not replace BQ8, Q8, or any PlasticNode format today.
The bigger question
The long-term question is not just whether one checkpoint can become smaller.
Can a growing AI store accumulated capabilities as compact inherited structure instead of becoming one endlessly larger file?
I think there may be something important here. I am testing it quickly, keeping the failures, and letting the evidence decide where the project goes.