CUBELINUX · The Memory Dial: Local Frontier Inference and the Coordinate Substrate

1. Introduction

This paper exists because of a coincidence worth examining. A project called DwarfStar (DS4), written by the author of Redis, now runs DeepSeek V4 Flash — a 284-billion-parameter model — on a 128 GB machine. On paper that model needs roughly 568 GB stored conventionally. It should not fit. It runs anyway, at usable speed.

The mechanism is described by its author with a phrase that should sound familiar to anyone who has read §1 of the CUBELinux whitepaper:

RAM stops being a wall and just becomes a dial.

That is the same move CUBELinux makes for storage. The whitepaper's core claim is that a position in space resolves to bytes — that path, hostname and content hash are three namespaces bolted together, and that a single coordinate primitive dissolves the translation between them. Both projects are, at bottom, refusing to treat a resource as a binary boundary when it is actually a graded hierarchy.

The scope of this paper is narrow. We describe what DwarfStar does (§2), then set out the structural correspondence between its routing and the CZYX key (§3) — the central finding, and the reason this paper exists. We then ask what follows if a model's bit-level layout is expressed inside the coordinate space rather than beside it (§4), state plainly where the argument does not hold (§5), examine where this workload can run today including the NVIDIA Jetson Thor question (§6), and propose one bounded experiment (§7).

The central claim has two halves, and they deserve different confidence. The first is a structural observation that can be checked against published documentation: the mixture-of-experts router emits one byte per layer per token, and the CZYX key already reserves one byte for selecting among 256 disjoint entity types. The second half is inference from that observation — that expressing a model's layout within the coordinate space would let specific parts be called at specific times by coordinate resolution rather than by file offset — and that half is unmeasured.

2. What DwarfStar Does

2.1 Selective quantization

The standard escape hatch is quantization: store each weight in fewer bits. At 16 bits the model needs ~568 GB; at 8 bits, ~284 GB; at 2 bits, roughly 80 GB. But precision is not free. Below approximately three bits, quality historically falls off a cliff — because a transformer is deep, and a weight snapped into the wrong level produces a slightly wrong answer that feeds the next layer and compounds.

DwarfStar's insight is that you do not have to quantize everything equally. DeepSeek V4 is a mixture-of-experts model: 43 layers, each with a router in front of 256 experts, and only about 13 billion of the 284 billion parameters are active for any given token. That structure permits a split:

• Load-bearing weights — attention layers, routers, shared experts, output heads — stay at four bits. Every token flows through them, so damage there propagates everywhere.
• Routed experts — the bulk of the model — are crushed to roughly two bits. Each token only touches a handful, and they sit between high-precision layers, so the error never gets the chance to compound.

The result is a model around 81 GB, which fits the 128 GB target.

2.2 Calibration before quantization

The second layer is the difference between guessing and measuring. Before quantizing, the model is run over roughly 4,700 real prompts — about three million tokens, including code review, mathematics, agent tool calls and long documents — while recording which weight columns actually carry signal. Heavily used columns are protected at higher precision; rarely used ones absorb the error. The calibration set deliberately includes tool-calling traffic, because that is precisely where cheap quantization usually falls apart.

2.3 SSD streaming and the expert cache

The third mechanism reframes the memory hierarchy outright. Load-bearing weights stay resident in RAM. The full set of routed experts — on the order of eleven thousand — stays on SSD, inside the model file. A fixed pool of slots in RAM holds complete experts; when a token's router selects an expert that is not resident, the engine reads that single expert from SSD into a slot and evicts the least recently used.

Two details matter. First, expert usage follows a power law — some experts are simply popular — so the engine ships a pre-filled hot list and warms the cache at startup. Second, because of that, the amount of RAM no longer decides whether the model runs; it decides only how often you miss. The cliff becomes a slope.

DwarfStar also persists the KV session as a file that can be reopened with no reprocessing, and supports splitting a model across two machines by layer over a fast interconnect — 1.85× faster prefill, at the cost of roughly 19% on generation, since generation is one token at a time and the pipeline collapses into ping-pong.

2.4 Published figures

From the project's own documentation, on DGX Spark with fully-resident Flash Q2 at 4K context: roughly 19.5 tokens/s ordinary decode, rising to about 31 tokens/s with speculative decoding on a suitable prompt — and slower on unpredictable prose, which is the expected failure mode of speculation.

3. The Correspondence in the Key Layout

The resemblance between these two systems is not thematic. It is structural, and it sits in the fixed key.

DeepSeek V4 routes each token through 256 experts per layer. 256 is 2⁸ — so the routing decision is one byte. There is no packing and no translation: the router's output is a byte-wide selector.

Now consider the CZYX key, which the whitepaper pins at a fixed 24 bytes (§2.4), and read the fields literally:

The whitepaper describes the class field in these terms:

class = MEM | SES | PRJ | EDG (memory, session/thread, project-internal, association-edge). Disjoint subtrees, no cross-class collision.

An eight-bit field selecting one of 256 disjoint subtrees is an expert selector. CUBELinux already reserves, as a first-class component of its key, exactly the structure a mixture-of-experts router emits once per layer, per token. Four of the 256 class values are currently spent. The remaining 252 are free, and the mechanism — a byte naming a disjoint entity type — is the one this workload needs.

That is the correspondence worth stating plainly: the router produces a byte, and the key already reserves a byte for precisely that purpose. The fields align without shifting, which is what makes this structural rather than coincidental. A great many things come in 256s; byte values, quantization levels, table sizes. The claim here is narrower and checkable: that this particular 256 is already a named field in the key, and that the router's output drops into it unchanged.

The further similarities below are real, but they are consequences of the same underlying instinct rather than independent findings, and they carry less weight than the alignment above.

The Sessions parallel is the sharpest of these. DwarfStar's "reopen the file, resume instantly, zero reprocessing" is what the whitepaper's SES entity was designed for, and the whitepaper reports that session replay resolved to a single-span raw read in one seek — proven ideal on real hardware. Two projects, arrived at independently, concluded that a long conversation is a sequential structure to be replayed by prefix scan rather than rebuilt.

4. The Model as a Space, Not a Blob

§3 changes what can be proposed. The proposal is not "add a locality-preserving cache underneath the engine." It is: express the model's bit-level layout inside the coordinate space, so that calling a specific part at a specific time is a coordinate resolution rather than a file offset. The model stops being an opaque blob with a cache bolted alongside it and becomes an addressable space — and everything below is a consequence of that shift rather than an added mechanism.

All five of the following are hypotheses. None is measured, and §5 states where the argument fails.

4.1 Experts as classes — prefix-pinned hot sets

With one class value per expert, the popular experts of a layer occupy a contiguous class range. They can be pinned by prefix — the whitepaper's prefix aggregation — rather than tracked in an LRU list over anonymous identifiers. The hot list stops being metadata about the cache and becomes the coordinate structure itself.

Independently, "no cross-class collision" is precisely the isolation one wants between experts: a select in class 0x2A can never return a record from class 0x2B. That property is already guaranteed by the key layout rather than enforced by code above it.

4.2 The space selector namespaces models, versions and adapters

A 256-bit space selector means the base model, each fine-tune, and each adapter are distinct spaces with no possibility of collision and no path conventions to agree on. The whitepaper already reserves 0xFF… for association edges and 0xFE… for portal descriptors, so a discipline for reserved spaces exists to be extended rather than invented.

4.3 A Portal becomes a model grant

Because movement between spaces is never arithmetic but always an explicit Portal, access to a model space is a capability that can be handed out. Serving a model to a tenant becomes "here is a Portal" rather than "here is a file path and a firewall rule," which is a genuinely different authority story — capability by construction rather than policy bolted on. The caveat is recorded honestly in the whitepaper itself: portal enforcement is not yet built, so today this is a design property rather than a guarantee.

4.4 The Curve trait allows a different curve at each level

This is the most interesting consequence, and it follows directly from the layout being two-level. Across experts one wants Morton ordering, because the value lies in routing locality — co-routed experts landing near one another. Within an expert, weight access is row-sequential for a matrix multiply, where row-major is the natural order and Morton's interleaving would actively hurt.

The whitepaper disqualifies row-major for offset region reads — the 79 MB blow-up that makes it unsafe for non-X-aligned rectangular queries. But that objection concerns region queries, not sequential row traversal, which is a different access shape. Since the Curve trait swaps implementations by type parameter, Morton at the expert level together with row-major within it is expressible with what exists today — each curve applied where its strength actually lies. Whether the two-level scheme wins is a measurement, not an argument.

4.5 The session as a record, and metadata at the same coordinate

DwarfStar persists a session as a file. Under the coordinate model it becomes an addressable record — associated with other records, walked by edge, diffed — which is what the cubetrace layer was built for, and which converts a conversation from an opaque blob into something carrying lineage.

Likewise, under the Null-space model the calibration importance map, the quantization provenance and the weights themselves become one record addressed by one coordinate. They cannot drift apart, because there is no second structure to synchronise. The whitepaper's argument for that is correctness rather than speed, and it applies here unchanged.

5. Where It Does Not Apply

Honesty here matters more than enthusiasm.

• The headline win is quantization. DwarfStar's 568 GB to 81 GB compression comes from selective quantization and calibration. CUBELinux does not compress anything. It has no bearing on that result.
• CUBELinux is a storage substrate, not an inference engine. DwarfStar is a deliberately narrow native engine — self-contained C, shipping its own custom model files, built for a specific family of models. A coordinate layer would sit beneath such an engine; it would not replace one.
• The hot path is not where the durable store belongs. This workload needs gigabytes per second off NVMe with minimal latency. CUBELinux's durable store is a write-ahead log with group-commit fsync, checkpoints and a JSON snapshot; the whitepaper itself records roughly 10–13 µs mean per-command daemon latency and notes that the in-memory path was faster per-op, with durability as a deliberate exchange. Only the no_std, allocation-free raw reader belongs anywhere near this workload.
• Today's engines do not address weights this way. The correspondence in §3 is an observation about two layouts, not a claim that either system currently uses it. DwarfStar addresses weights by expert index through a file offset; nothing in it consumes a coordinate. The proposal in §4 requires a layout change, not a configuration change — and any such change must not put the 256-bit space selector on the per-fetch hot path. The selector belongs at the model and version level; the per-expert decision is one byte, and should stay one byte.
• Whether the routing pattern has locality is untested. §3 establishes where an expert can live. It says nothing about whether co-routed experts would actually land near one another, and if routing is effectively uniform across the 256 classes then contiguous layout buys nothing at all. This is the question §7.1 exists to answer, and it could easily come back negative.

6. Where This Runs Today — and the Jetson Thor Question

6.1 Supported targets

DwarfStar's documentation names three backends:

Notably, Ada is supported even though it predates Blackwell, because — in the project's own words — the kernels "do not require Blackwell's native FP4 instructions." That single sentence is what makes the Jetson question interesting.

6.2 The Thor mismatch

The NVIDIA Jetson AGX Thor has 128 GB of unified memory and a Blackwell-family GPU. On memory alone it lands inside the target envelope. But one detail disqualifies it as a drop-in:

Both are Blackwell, but they are different compute capabilities. DwarfStar's Spark target hardcodes sm_121. Thor is sm_110.

There is precedent that this matters in practice: in an independent Thor port of a similar CUDA kernel project, Flash-Attention 2 was found to be gated to SM80/86/89/120 and deliberately excluded for SM110, with Thor routed to a cuBLAS-decomposed attention path instead. Some Blackwell kernel paths do not map onto Thor. Against that, the wider ecosystem is actively working the target — vLLM has added sm_110 to its CUDA 13.0 build targets — so the tooling is arriving.

6.3 Why it is not a drop-in

1. The Blackwell-specific kernels enabled by the Spark target are written for sm_121 and must compile for sm_110 — or be replaced with a fallback.
2. Thor's 128 GB is unified with the operating system, with GPU memory carved out via power/clock configuration. DGX Spark's 128 GB is available to CUDA. The usable figure on Thor must be confirmed, not assumed.
3. Independent reports on SM110 suggest the FP4 path is immature — one measurement puts NVFP4 decode roughly an order of magnitude below the memory-bandwidth roof on Thor. Since generation in this design is bandwidth-bound, an immature FP4 path would cost exactly the performance that makes the exercise worthwhile.

7. A Bounded Test Plan

Two questions are worth settling, and both are cheap relative to the value of the answer.

7.1 Does the routing pattern have locality at all?

§3 establishes where an expert can live. It does not establish that the routing pattern has locality to exploit. If a token's per-layer expert selections are effectively uniform across all 256 classes, then contiguous layout buys nothing and a fetch remains 256 scattered reads — the alignment in the key would be real but useless.

This experiment requires no inference hardware. It needs only activation traces, which the quantization calibration already produces in the course of doing its own work.

1. Obtain per-token expert activation traces from a representative prompt set — the same kind of corpus DwarfStar already uses for calibration.
2. Build the co-occurrence matrix over the 256 classes, per layer and across layers.
3. Assign class values so that frequently co-routed experts occupy adjacent class values; separately, assign leaf coordinates ordered by co-activation over Morton and Hilbert curves.
4. Measure two quantities against the arbitrary-identifier baseline: mean contiguous run length within a token's expert set, and seeks per token at a fixed cache budget.

Pass: co-routed experts cluster into runs, so prefix pinning and one-seek spans become available at no structural cost — the layout already provides the mechanism. Fail: run lengths remain effectively random, showing that mixture-of-experts routing is too diffuse for ordering to help at all.

A negative result is genuinely valuable here, and should be published as readily as a positive one. It would close the line of inquiry rather than leaving the intuition to circulate as folklore — which is the failure mode this paper is trying to avoid.

7.2 Does it compile for sm_110?

Before anyone commits weeks to a Thor port, answer the cheap question: does the CUDA source build for the target at all? The generic CUDA path already supports a non-Blackwell architecture, which suggests the kernels are not intrinsically sm_121-only. Building for sm_110 and running the project's own evaluation suite would establish in days whether the remaining work is a build flag, a handful of kernel fallbacks, or a rewrite.

8. Conclusion

Two projects, built independently for different purposes, arrived at the same architectural instinct: stop treating a scarce resource as a binary boundary. DwarfStar says RAM is not a wall but a cache size, and demonstrates it by running a 284-billion-parameter model on consumer hardware. CUBELinux says storage is not a path tree but a coordinate space, and demonstrates it with a kernel that has been built, installed and booted.

But the similarity this paper began from is sharper than a shared instinct, and it is worth restating precisely. A mixture-of-experts router emits one byte per layer per token to select among 256 experts. The CZYX key already reserves one byte to select among 256 disjoint entity classes. The fields align without shifting. Where an expert can live is therefore not left to a cache to decide at runtime — it is a property of the address.

What follows from that is a hypothesis rather than a result. If a model's layout is expressed inside the coordinate space, then calling specific parts at specific times becomes coordinate resolution: hot experts pinned by prefix rather than tracked in an LRU list, model versions separated by space selector, access expressed as a Portal, and — most interestingly — a different curve chosen at each level of the hierarchy, Morton across experts where routing locality pays and row-major within an expert where traversal does.

What does not follow should be said as clearly. CUBELinux does not compress anything; the 568 GB to 81 GB result is quantization, and this paper contributes nothing to it. CUBELinux is not an inference engine, and the hot path of this workload belongs to raw block reads rather than to a durable daemon with a write-ahead log. Its honest connection runs through the no_std crates and the key layout, and nowhere else.

One question remains genuinely open, and it is the one that decides whether the alignment is useful or merely elegant: does the routing pattern have locality? If co-routed experts cluster, the key layout already provides the mechanism to exploit it and no new structure is needed. If they do not, the correspondence is a curiosity. That is measurable, the measurement is cheap, it requires no inference hardware, and it should be run and published either way before anyone repeats the intuition as though it were established.

Future work: run the class-ordering bench of §7.1 and publish the result whichever way it falls; establish whether sm_110 is a build flag or a port; and revisit the relationship between session persistence and the SES entity, now that an external project has independently converged on the same design.