cubelinux/cubelinux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Activity

whitepaper: publish post 4 (The Memory Dial - local frontier inference)

Browse Source 
- add whitepaper/cubelinux-local-frontier-inference.html: fourth blog post. Examines
  DwarfStar (DS4), which runs a 284B-parameter model on 128GB of consumer memory via
  selective quantization, calibration and SSD expert streaming. Maps what its
  reframing ("RAM stops being a wall and just becomes a dial") genuinely shares with
  the CZYX coordinate substrate - the one-seek record fetch, locality-preserving
  ordering, prefix-scan session replay, explicit edges between spaces - and states
  plainly where the resemblance fails: the compression is quantization, not
  addressing, and the hot path belongs to raw block reads rather than the durable
  store. Also covers the Jetson AGX Thor sm_110 vs supported sm_121 mismatch and
  proposes one bounded experiment (expert placement by co-activation) with a stated
  pass/fail.
- update whitepaper/cubelinux-whitepapers.html: listing now shows four drafts.
This commit is contained in:
luulu
2026-09-12 20:37:00 -04:00
parent 29aff12940
commit cf865390d3
2 changed files with 309 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
whitepaper/cubelinux-local-frontier-inference.html
+291
View File
@@ -0,0 +1,291 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
<title>CUBELinux — The Memory Dial: Local Frontier Inference and the Coordinate Substrate</title>
<meta name="description" content="An architectural note on DwarfStar running a 284B model on 128 GB, and what that reframing of memory — RAM as a dial, not a wall — shares with the CZYX coordinate substrate.">
<style>
:root{
--gold:#d8af68; --gold-hi:#fff9b1; --cyan:#39d7ff; --bg:#0c0f14;
--panel:#141a22; --panel2:#1b232e; --ink:#e8eaeb; --muted:#8a97a6;
--ok:#5ee0a0; --line:#26303c; --warn:#e8a040;
}
*{box-sizing:border-box}
html,body{margin:0;height:100%}
body{
background:radial-gradient(1200px 600px at 80% -10%, #15212e 0%, var(--bg) 55%);
color:var(--ink); font:15px/1.55 -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Helvetica,Arial,sans-serif;
-webkit-tap-highlight-color:transparent;
}
.wrap{max-width:780px;margin:0 auto;padding:18px 16px 40px}
header{margin-bottom:18px;border-bottom:1px solid var(--line);padding-bottom:14px}
.logo{width:36px;height:36px;border-radius:10px;background:linear-gradient(135deg,var(--gold),var(--cyan));box-shadow:0 0 20px rgba(57,215,255,.3);flex-shrink:0}
h1{font-size:20px;margin:8px 0 2px;font-weight:700;letter-spacing:.2px}
h1 span{color:var(--cyan)}
.meta{color:var(--muted);font-size:12px;margin-top:4px}
.meta b{color:var(--ink);font-weight:600}
h2{
font-size:14px;margin:24px 0 6px;padding-bottom:4px;border-bottom:1px solid var(--line);
color:var(--gold);letter-spacing:.4px;text-transform:uppercase;font-weight:700;
}
h3{font-size:13.5px;margin:14px 0 4px;color:var(--cyan)}
p{margin:6px 0}
ul,ol{margin:6px 0 6px 18px;padding:0}
li{margin:2px 0}
blockquote{
border-left:3px solid var(--gold);margin:10px 0;padding:4px 12px;
background:var(--panel);border-radius:0 8px 8px 0;color:var(--ink);
}
code{
background:var(--panel2);border:1px solid var(--line);border-radius:5px;
padding:1px 5px;font-family:ui-monospace,SFMono-Regular,Menlo,monospace;font-size:13px;
color:var(--cyan);
}
pre{
background:var(--panel);border:1px solid var(--line);border-radius:10px;
padding:10px 12px;overflow-x:auto;font-family:ui-monospace,SFMono-Regular,Menlo,monospace;
font-size:12.5px;line-height:1.45;margin:8px 0;
}
table{border-collapse:collapse;width:100%;margin:8px 0;font-size:13px}
th,td{border:1px solid var(--line);padding:5px 8px;text-align:left}
th{background:var(--panel2);color:var(--gold);font-weight:600}
tr:nth-child(even){background:var(--panel)}
.note{background:var(--panel);border:1px solid var(--line);border-left:3px solid var(--warn);border-radius:8px;padding:8px 12px;margin:10px 0;color:var(--ink)}
.note b{color:var(--warn)}
.pill{display:inline-block;background:var(--panel2);border:1px solid var(--line);border-radius:10px;padding:1px 8px;font-size:11px;color:var(--muted);margin-right:4px}
.pill.core{background:rgba(94,224,160,.12);border-color:var(--ok);color:var(--ok)}
.pill.opt{background:var(--panel2);border-color:var(--line);color:var(--muted)}
footer{margin-top:32px;padding-top:12px;border-top:1px solid var(--line);color:var(--muted);font-size:12px}
.diagram{background:var(--panel);border:1px solid var(--line);border-radius:10px;padding:10px 12px;margin:8px 0;font-family:ui-monospace,SFMono-Regular,Menlo,monospace;font-size:12.5px;line-height:1.4}
.diagram .layer{padding:2px 0;border-bottom:1px dashed var(--line)}
.diagram .layer:last-child{border-bottom:none}
.diagram .arrow{color:var(--cyan);text-align:center;padding:2px 0}
</style>
<!-- Open Graph / Twitter / canonical (site prep) -->
<meta property="og:type" content="website">
<meta property="og:title" content="CUBELinux — The Memory Dial: Local Frontier Inference and the Coordinate Substrate">
<meta property="og:description" content="An architectural note on DwarfStar running a 284B model on 128 GB, and what that reframing of memory — RAM as a dial, not a wall — shares with the CZYX coordinate substrate.">
<meta property="og:url" content="https://cubelinux.com/cubelinux-local-frontier-inference.html">
<meta property="og:image" content="https://cubelinux.com/images/logo-header@2x.png">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="CUBELinux — The Memory Dial: Local Frontier Inference and the Coordinate Substrate">
<meta name="twitter:description" content="An architectural note on DwarfStar running a 284B model on 128 GB, and what that reframing of memory — RAM as a dial, not a wall — shares with the CZYX coordinate substrate.">
<meta name="twitter:image" content="https://cubelinux.com/images/logo-header@2x.png">
<link rel="canonical" href="https://cubelinux.com/cubelinux-local-frontier-inference.html">
</head>
<body>
<div class="wrap">
<header>
<div class="logo"></div>
<h1>CUBELINUX <span>·</span> The Memory Dial: Local Frontier Inference and the Coordinate Substrate</h1>
<div class="meta"><b>Preliminary Draft — CUBELinux Project</b> — 2026-09-12. Architectural note, not implementation.</div>
</header>
<div class="note"><b>Status.</b> This is an observation piece, not a built system. It examines an external project — DwarfStar (DS4) — that runs a 284-billion-parameter model on 128&nbsp;GB of consumer memory, and asks what its reframing of memory shares with the CZYX coordinate substrate, where that similarity is real, and where it is only superficial. Nothing here changes the CUBELinux design. One section proposes a bounded experiment; it has not been run.</div>
<h2 id="intro">1. Introduction</h2>
<p>This paper exists because of a coincidence worth examining. A project called <strong>DwarfStar</strong> (DS4), written by the author of Redis, now runs <strong>DeepSeek V4 Flash — a 284-billion-parameter model — on a 128&nbsp;GB machine</strong>. On paper that model needs roughly 568&nbsp;GB stored conventionally. It should not fit. It runs anyway, at usable speed.</p>
<p>The mechanism is described by its author with a phrase that should sound familiar to anyone who has read §1 of the CUBELinux whitepaper:</p>
<blockquote>RAM stops being a wall and just becomes a dial.</blockquote>
<p>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.</p>
<p>The scope of this paper is narrow. We describe what DwarfStar does (§2), map it precisely against the CZYX substrate (§3), identify four places where the coordinate model might genuinely contribute (§4), state plainly where it does not (§5), examine where this workload can run today including the NVIDIA Jetson Thor question (§6), and propose one bounded experiment that would settle the central hypothesis (§7). The central claim is deliberately modest: <strong>the resemblance is real at the level of mechanism, and CUBELinux is not the missing piece that makes local frontier inference possible — but one specific idea in the coordinate model may be worth measuring.</strong></p>
<h2 id="ds4">2. What DwarfStar Does</h2>
<h3>2.1 Selective quantization</h3>
<p>The standard escape hatch is quantization: store each weight in fewer bits. At 16 bits the model needs ~568&nbsp;GB; at 8 bits, ~284&nbsp;GB; at 2 bits, roughly 80&nbsp;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.</p>
<p>DwarfStar's insight is that <strong>you do not have to quantize everything equally</strong>. DeepSeek V4 is a mixture-of-experts model: 43 layers, each with a router in front of 256 experts, and only about 13&nbsp;billion of the 284&nbsp;billion parameters are active for any given token. That structure permits a split:</p>
<ul>
<li><strong>Load-bearing weights</strong> — attention layers, routers, shared experts, output heads — stay at four bits. Every token flows through them, so damage there propagates everywhere.</li>
<li><strong>Routed experts</strong> — 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.</li>
</ul>
<p>The result is a model around 81&nbsp;GB, which fits the 128&nbsp;GB target.</p>
<h3>2.2 Calibration before quantization</h3>
<p>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.</p>
<h3>2.3 SSD streaming and the expert cache</h3>
<p>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.</p>
<div class="diagram">
<div class="layer">┌──────────────────────── RAM ────────────────────────┐</div>
<div class="layer">│ load-bearing weights (attention / router / shared) │ ← resident, always</div>
<div class="layer">│ expert cache: N slots, each one complete expert │ ← LRU eviction</div>
<div class="layer">└──────────────────────┬──────────────────────────────┘</div>
<div class="layer arrow">│ miss → read ONE expert</div>
<div class="layer">┌──────────────────────▼──────────────────────────────┐</div>
<div class="layer">│ SSD: ~11,000 routed experts, inside the model file │</div>
<div class="layer">└─────────────────────────────────────────────────────┘</div>
</div>
<p>Two details matter. First, expert usage follows a <strong>power law</strong> — 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.</p>
<p>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.</p>
<h3>2.4 Published figures</h3>
<p>From the project's own documentation, on DGX Spark with fully-resident Flash Q2 at 4K context: roughly <strong>19.5 tokens/s</strong> ordinary decode, rising to about <strong>31 tokens/s</strong> with speculative decoding on a suitable prompt — and <em>slower</em> on unpredictable prose, which is the expected failure mode of speculation.</p>
<h2 id="convergence">3. The Convergence</h2>
<p>Set side by side, the two systems attack the same shape of problem with recognisably similar machinery.</p>
<table>
<tr><th>DwarfStar</th><th>CZYX / CUBELinux</th></tr>
<tr>
<td>"RAM stops being a wall and just becomes a dial"</td>
<td>"A position in space resolves to bytes" — dissolves the path / hostname / inode translation layers</td>
</tr>
<tr>
<td>Expert cache: fetch <strong>one expert with one seek</strong> from SSD, evict LRU</td>
<td><code>cube-store-raw</code>: <code>no_std</code>, allocation-free, zero-copy <code>parse_header</code> + <code>iter_records</code>; whitepaper §4.5 — <em>"single-span raw read (1 seek) on the hot path"</em></td>
</tr>
<tr>
<td>Power-law expert popularity; pre-filled hot list warms the cache</td>
<td>Morton/Hilbert locality-preserving ordering; prefix aggregation; hot-coordinate clustering</td>
</tr>
<tr>
<td>Session saved as a file; reopen to resume with <strong>zero reprocessing</strong></td>
<td>§4.2 Sessions — leaf = <code>(thread_id:40, seq:80)</code>; <em>"Replay a thread = prefix scan on seq = single-span raw read, 1 seek (proven ideal). Append = write at head."</em></td>
</tr>
<tr>
<td>Model split across two machines by layer</td>
<td>Spaces, with explicit <strong>Portals</strong> as the only legal cross-space movement</td>
</tr>
<tr>
<td>Calibration importance map as a separate artefact</td>
<td>Null-space metadata — the tag <em>is</em> the record, so no second structure to drift</td>
</tr>
</table>
<p>The Sessions parallel is the sharpest. 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 — <em>proven ideal</em> on real hardware. Two projects, arrived at independently, both concluded that a long conversation is a sequential structure that should be replayed by prefix scan rather than rebuilt.</p>
<h2 id="contribute">4. Where the Coordinate Model Could Contribute</h2>
<p>Everything in this section is a hypothesis. None of it is measured.</p>
<h3>4.1 Expert placement by co-activation</h3>
<p>This is the one that might matter. In DwarfStar, expert identifiers are arbitrary, so a cache miss is effectively a random read from SSD. CUBELinux's entire contribution is that a curve turns spatial locality into a one-dimensional ordering — nearby points produce nearby keys, and a contiguous region becomes a single seek.</p>
<p>If expert identifiers were assigned <strong>coordinates derived from co-activation</strong> — experts that tend to fire together placed near each other — then the hot set would occupy contiguous ranges of the curve rather than scattered positions. A hot-path load would become a <strong>prefix scan</strong> instead of N independent seeks. That is a real, testable difference between random access and sequential access, and it is precisely the property the Curve trait exists to provide.</p>
<h3>4.2 The session as a first-class record</h3>
<p>DwarfStar persists a session as a file. CUBELinux would persist it as an <em>addressable record</em> — one that can be associated with other records, walked by edge, and diffed. That is what the <code>cubetrace</code> layer was built for, and it converts a conversation from an opaque blob into something with lineage.</p>
<h3>4.3 Multi-machine splits as spaces and Portals</h3>
<p>A model split across two machines by layer is formally two spaces joined by a cross-space edge. The whitepaper's model — that movement between spaces is never arithmetic but always an explicit Portal — describes this arrangement exactly, and would make the reachability and authority story explicit rather than implicit in a configuration file.</p>
<h3>4.4 Metadata at the same coordinate</h3>
<p>Under the Null-space model, the calibration importance map, the quantization provenance and the weights themselves are one record addressed by one coordinate. They cannot drift apart, because there is no separate structure to synchronise. Whether that is worth anything operationally is an open question; the whitepaper's argument for it is correctness, not speed.</p>
<h2 id="limits">5. Where It Does Not Apply</h2>
<p>Honesty here matters more than enthusiasm.</p>
<ul>
<li><strong>The headline win is quantization.</strong> DwarfStar's 568&nbsp;GB to 81&nbsp;GB compression comes from selective quantization and calibration. CUBELinux does not compress anything. It has no bearing on that result.</li>
<li><strong>CUBELinux is a storage substrate, not an inference engine.</strong> 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.</li>
<li><strong>The hot path is not where the durable store belongs.</strong> 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&nbsp;µ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 <code>no_std</code>, allocation-free raw reader belongs anywhere near this workload.</li>
<li><strong>Weights are not coordinate-addressed.</strong> They are addressed by expert index. Introducing a 256-bit space selector into that path adds cost and buys nothing.</li>
<li><strong>The clustering hypothesis is untested.</strong> That co-activated experts would cluster usefully under Morton ordering is plausible and unmeasured. It could easily be false — expert activation may be too diffuse, or the working set too small, for span length to matter.</li>
</ul>
<div class="note"><b>The temptation to resist.</b> The easy paper to write here is "CUBELinux for local AI inference." That paper would be wrong. The honest connection runs through the <code>no_std</code> boundary — <code>cube-core</code> and <code>cube-store-raw</code> are the crates written for targets without an operating system, and that is the world this workload also lives in. It does not run through the daemon, the FUSE view, or the durable store.</div>
<h2 id="hardware">6. Where This Runs Today — and the Jetson Thor Question</h2>
<h3>6.1 Supported targets</h3>
<p>DwarfStar's documentation names three backends:</p>
<table>
<tr><th>Backend</th><th>Targets</th><th>Notes</th></tr>
<tr><td><strong>Metal</strong></td><td>Apple Silicon, 96&nbsp;GB or more</td><td>The primary target. Smaller machines use SSD streaming.</td></tr>
<tr><td><strong>CUDA</strong></td><td>DGX Spark (GB10); Ada Lovelace including L40S; multi-GPU</td><td>Spark is the stated goal. The Spark build selects <code>sm_121</code> and enables Blackwell-specific kernels.</td></tr>
<tr><td><strong>ROCm</strong></td><td>Strix Halo systems, e.g. Framework Desktop</td><td></td></tr>
</table>
<p>Notably, Ada is supported even though it predates Blackwell, because — in the project's own words — the kernels <em>"do not require Blackwell's native FP4 instructions."</em> That single sentence is what makes the Jetson question interesting.</p>
<h3>6.2 The Thor mismatch</h3>
<p>The NVIDIA Jetson AGX Thor has <strong>128&nbsp;GB of unified memory</strong> and a Blackwell-family GPU. On memory alone it lands inside the target envelope. But one detail disqualifies it as a drop-in:</p>
<table>
<tr><th></th><th>DGX Spark (supported)</th><th>Jetson AGX Thor</th></tr>
<tr><td>Compute capability</td><td><code>sm_121</code></td><td><code>sm_110</code></td></tr>
<tr><td>Family</td><td>Blackwell</td><td>Blackwell</td></tr>
<tr><td>CUDA toolkit</td><td>driver + toolkit</td><td>CUDA 13.0 (JetPack 7.x)</td></tr>
<tr><td>Architecture</td><td>x86</td><td>aarch64</td></tr>
<tr><td>Unified memory</td><td>128&nbsp;GB</td><td>128&nbsp;GB (carved from a shared pool)</td></tr>
</table>
<p>Both are Blackwell, but they are different compute capabilities. DwarfStar's Spark target hardcodes <code>sm_121</code>. Thor is <code>sm_110</code>.</p>
<p>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 <strong>deliberately excluded for SM110</strong>, 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 <code>sm_110</code> to its CUDA 13.0 build targets — so the tooling is arriving.</p>
<h3>6.3 Why it is not a drop-in</h3>
<ol>
<li>The Blackwell-specific kernels enabled by the Spark target are written for <code>sm_121</code> and must compile for <code>sm_110</code> — or be replaced with a fallback.</li>
<li>Thor's 128&nbsp;GB is <strong>unified with the operating system</strong>, with GPU memory carved out via power/clock configuration. DGX Spark's 128&nbsp;GB is available to CUDA. The usable figure on Thor must be confirmed, not assumed.</li>
<li>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.</li>
</ol>
<h2 id="test">7. A Bounded Test Plan</h2>
<p>Two questions are worth settling, and both are cheap relative to the value of the answer.</p>
<h3>7.1 Does the clustering hypothesis hold?</h3>
<p>This does not require inference hardware at all — only activation traces, which the quantization calibration already produces.</p>
<ol>
<li>Obtain per-token expert activation traces from a representative prompt set.</li>
<li>Compute a co-activation affinity between experts.</li>
<li>Assign each expert a coordinate on a Morton curve ordered by that affinity, and likewise for a Hilbert curve.</li>
<li>Measure two quantities against the arbitrary-identifier baseline: <strong>mean contiguous span length</strong> per token's expert set, and <strong>seeks per token</strong> under a fixed-size cache.</li>
</ol>
<p><strong>Pass:</strong> a material reduction in seeks per token at equal cache size. <strong>Fail:</strong> span lengths remain effectively random — which would show that expert co-activation is too diffuse for a locality-preserving curve to help. A negative result here is genuinely useful, because it closes a line of inquiry rather than leaving it as folklore.</p>
<h3>7.2 Does it compile for <code>sm_110</code>?</h3>
<p>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 <code>sm_121</code>-only. Building for <code>sm_110</code> 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.</p>
<h2 id="conclusion">8. Conclusion</h2>
<p>Two projects, built independently for different purposes, arrived at the same architectural instinct: <strong>stop treating a scarce resource as a binary boundary.</strong> 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.</p>
<p>The resemblance is real at the level of mechanism — the one-seek fetch, the locality-preserving ordering, the prefix-scan replay of a session, the explicit edge between spaces. It is <em>not</em> a claim that CUBELinux enables any of this. The compression is quantization; the engine is bespoke; the hot path belongs to raw block reads, not to a durable daemon. CUBELinux's honest connection to this workload runs through its <code>no_std</code> crates and nothing else.</p>
<p>What remains genuinely open is one idea: that if expert placement were derived from co-activation rather than assigned arbitrarily, the hot set would occupy contiguous ranges and a stream of random reads would become a prefix scan. That is a measurable claim, the measurement is cheap, and it should be run before anyone repeats it as though it were established.</p>
<p>Future work: run the clustering bench of §7.1 and publish the result either way; establish whether <code>sm_110</code> 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.</p>
<footer>
<p>CUBELinux — The Memory Dial: Local Frontier Inference and the Coordinate Substrate · Preliminary Draft · 2026-09-12</p>
<p style="margin-top:6px"><a href="/spec.php" style="color:var(--cyan)">Sign up for the CUBELinux Newsletter →</a> — get update summaries as they happen.</p>
<p style="margin-top:6px"><span class="pill opt">ARCHITECTURAL NOTE</span> Not implemented · <span class="pill core">ORIGINAL WORK</span> CUBELinux project</p>
</footer>
</div>
</body>
</html>
whitepaper/cubelinux-whitepapers.html
+18 -3
View File
@@ -74,10 +74,10 @@
<header>
<div class="logo"></div>
<h1>CUBELINUX <span>·</span> Whitepapers</h1>
<div class="meta"><b>Three drafts — two posted 2026-08-25, one posted 2026-09-09.</b> Pick one to read in full — each is a standalone HTML page.</div>
<div class="meta"><b>Four drafts — two posted 2026-08-25, one 2026-09-09, one 2026-09-12.</b> Pick one to read in full — each is a standalone HTML page.</div>
</header>
<div class="note"><b>About these drafts.</b> The whitepaper documents the design, verified on-disk state, and completed kernel build of the CUBELinux coordinate-addressed OS. The addendum is a separate, clearly-labeled <em>preliminary exploration</em> of how state-spanning neural networks might one day layer on top of the CZYX filesystem — nothing in it is built or committed. The ESP32 integration proposal is likewise a <em>preliminary exploration</em> of carrying the coordinate substrate onto microcontrollers, and is likewise not built.</div>
<div class="note"><b>About these drafts.</b> The whitepaper documents the design, verified on-disk state, and completed kernel build of the CUBELinux coordinate-addressed OS. The addendum is a separate, clearly-labeled <em>preliminary exploration</em> of how state-spanning neural networks might one day layer on top of the CZYX filesystem — nothing in it is built or committed. The ESP32 integration proposal is likewise a <em>preliminary exploration</em> of carrying the coordinate substrate onto microcontrollers, and is likewise not built. The local-inference note is an <em>architectural observation</em> on an external project, DwarfStar, and where the coordinate model may or may not contribute to it.
<div class="note" style="border-left-color:var(--cyan)"><b>CUBELinux Newsletter.</b> Get update summaries as they happen — new builds, verified milestones, and project progress. <br><a class="read" style="display:inline-block;margin-top:8px;color:var(--cyan)" href="/spec.php">Sign up for the newsletter →</a></div>
@@ -131,8 +131,23 @@
</footer>
</article>
<article>
<h3>The Memory Dial: Local Frontier Inference and the Coordinate Substrate</h3>
<div class="date">Preliminary draft · 2026-09-12</div>
<p>An architectural observation on DwarfStar (DS4), which runs a 284-billion-parameter model on 128&nbsp;GB of consumer memory by quantizing only the routed experts, protecting the load-bearing weights, and streaming experts from SSD through a power-law cache. Examines what its reframing — <em>RAM stops being a wall and just becomes a dial</em> — genuinely shares with the CZYX coordinate substrate: the one-seek record fetch, the locality-preserving ordering, prefix-scan session replay, and explicit edges between spaces. States plainly where the resemblance fails (the compression is quantization, not addressing; the hot path belongs to raw block reads, not the durable store), examines why the Jetson AGX Thor is <code>sm_110</code> against the supported <code>sm_121</code>, and proposes one bounded experiment — placing experts by co-activation so the hot set becomes a contiguous span — with a stated pass/fail.</p>
<footer>
<div class="tags">
<span class="pill optional">architectural note</span>
<span class="pill explored">external project review</span>
<span class="pill standard">not implemented</span>
<span class="pill original">original work</span>
</div>
<a class="read optional" href="cubelinux-local-frontier-inference.html">Read the note →</a>
</footer>
</article>
<footer>
<p>CUBELinux — Whitepapers · Posted 2026-08-25 · updated 2026-09-09 · <a href="/" style="color:var(--cyan)">Back to CUBELinux.com</a></p>
<p>CUBELinux — Whitepapers · Posted 2026-08-25 · updated 2026-09-12 · <a href="/" style="color:var(--cyan)">Back to CUBELinux.com</a></p>
</footer>
</div>