Infrastructure Inventory

The Sea Of Fate Hardware Stack

Before establishing the specific constraints of the project, it is essential to document the physical foundation of our network. As of early 2026, the Sea Of Fate infrastructure is a multi-node ecosystem designed to balance high-capacity archival storage with specialized processing. Given the current economic climate and the prohibitive cost of new hardware, this stack represents a "locked-in" baseline. Any future expansion, such as the acquisition of a 24GB workstation GPU, is contingent on the second-hand market stabilizing and significant shifts in disposable capital.

Pear (The Primary Vault & Hypervisor)

Pear is our main Proxmox host, built on a consumer-grade AM4 mATX motherboard. Despite its consumer origins, it has been pushed to its maximum potential to serve as the project's primary anchor.

• CPU: AMD Ryzen 9 5950X (16 Cores / 32 Threads), providing the multi-threaded horsepower required for ZFS management and concurrent service hosting.

• RAM: 128GB DDR4 (Maxed out), the most critical and strained resource on the host.

• GPU: NVIDIA 5060 Ti (16GB VRAM), a legacy asset utilized for isolated AI inference via PCIe passthrough.

• Networking: Dual-NIC configuration consisting of a built-in 1Gb/s port (dedicated to Proxmox Management at 192.168.1.111:8006) and a PCIe 2.5Gb/s card handling all tagged VLAN traffic.

• Primary Storage (Rpool): Mirrored 4TB Crucial M.2 SSDs, providing high-speed redundancy for the OS and virtual machine disks.

• Archival Storage: 3 x 16TB Seagate IronWolf drives in RaidZ1 (~32TB usable).

• The Scratch Disk: A 1TB SATA SSD. Originally intended as an L2ARC, it was repurposed as a Fastpool Scratch Disk after it was determined that the 10GB RAM overhead required for the L2ARC index was too high a price to pay. This disk now handles high-wear ingestion tasks to protect the lifespan of the Rpool and the mechanical drives.

Host 2: Kiwi (The Ingestion Specialist)

Acquired as a second-hand node to provide physical isolation for high-I/O zpools, Kiwi is built on an ITX AM4 platform.

• CPU: AMD Ryzen 5 series, sufficient for dedicated data transformation and Java-based processing.

• RAM: 64GB DDR4 (Maxed out).

• GPU: Small legacy GPU for POST/Video output (No passthrough configured).

• Networking: Built-in 2.5Gb/s wired NIC handling both the management interface (untagged) and guest VM VLANs (tagged). While a Wi-Fi NIC is present, it remains unused due to Proxmox management limitations.

• Storage: 3 x 14TB IronWolf drives, providing a secondary, isolated ZFS pool for volatile ingestion tasks like OpenAlex processing.

Host 3: Grape (The Production & Gaming Desktop)

The primary human interface node, running Windows 11 on an ATX AM4 platform.

• CPU: AMD Ryzen 9 (12 Cores).

• RAM: 96GB DDR4.

• GPU: NVIDIA 4080 Super, the most powerful compute asset in the network.

• Networking: Dual-NIC setup. The 1Gb/s onboard NIC handles general internet traffic and ISP router communication (192.168.1.25). A recently added PCIe 2.5Gb/s NIC is dedicated to the high-speed local backbone for communication with Pear and Kiwi.

Network Topology: The 2.5Gb/s Backbone

The interconnectivity of these three nodes is governed by a split-switch architecture designed to maximize internal throughput while maintaining security.

• The Internet/ISP Link: A 2.5Gb/s "dumb" switch interfaces with the ISP router on the 192.168.1.0/24 subnet.

• The Managed Backbone: A dedicated managed switch links the 2.5Gb/s NICs of all three hosts. This allows for high-speed data migration, such as streaming extracted OpenAlex data from Kiwi to Pear, without saturating the general internet gateway.

• Security: Pear hosts a pfSense firewall VM at 192.168.1.125, acting as the primary gatekeeper for the network's internal VLANs.

---

Resolving the Memory Bottleneck on Kiwi and Pear

The current hardware stack faces a definitive "Memory Death Delay" when handling the 1.9 TB ZIM archive and the OpenAlex Java extraction. By documenting the exact specifications of Pear (128GB RAM) and Kiwi (64GB RAM), we can now formalize the operational constraints that dictate the flow of data across the 2.5 Gb/s backbone.

• The ZFS ARC vs. JVM Conflict: On Pear, the 128GB of RAM is the frontline for all services. Because ZFS is configured on the 3x16TB IronWolf array, the Adaptive Replacement Cache (ARC) will naturally attempt to consume as much RAM as possible to mask the slow seek times of the mechanical drives. However, if we were to run the OpenAlex Java engine on Pear, the JVM's demand for large, contiguous memory blocks would clash with the ARC's slow eviction process. This is why Kiwi is essential; by utilizing Kiwi's 64GB of RAM exclusively for the ingestion and extraction phase, we protect Pear's 128GB pool for "Life Management" services and the eventual AI inference tasks.

• The 2.5 Gb/s Synchronization: The managed switch linking the 2.5 Gb/s NICs on Pear, Kiwi, and Grape creates a dedicated "Data Highway." This is vital because the extraction of OpenAlex on Kiwi generates a massive amount of internal network traffic. If this were conducted over the standard 1 Gb/s ISP link, it would choke the internet access for the entire household. By using the 2.5 Gb/s backbone, we can stream the processed data from Kiwi to the Pear vault at roughly 280-300 MB/s, which matches the sequential write speed of the IronWolf RaidZ1 array, ensuring the drives are fed at their maximum efficiency without hitting the "random I/O" bottleneck.

Strategic Repurposing of the 1TB SATA SSD

The decision to pivot the 1TB SATA SSD from an L2ARC to a Fastpool Scratch Disk is a pivotal moment in the infrastructure's evolution. In the initial design, an L2ARC seemed logical to speed up the 32TB array. However, ZFS requires approximately 70 bytes of system RAM for every 8KB block stored in the L2ARC to maintain the index. For a 1TB SSD, this would have "stolen" nearly 10GB of RAM from Pear's 128GB pool just to manage the cache.

By reconfiguring this as a standalone "Fastpool," we eliminate that RAM tax entirely. The 1TB SSD now serves as a high-speed buffer for the 3x16TB IronWolf array. We can download volatile, high-wear data (like daily web scrapes or temporary Java build files) to this SSD, preserving the lifespan of our primary 4TB Crucial M.2 Rpool and preventing the mechanical drives from "thrashing" during the initial triage of new archives.

Hard Isolation: Protecting the Host from the AI Experiment

To ensure the long-term survival of the Sea Of Fate network, we enforce strict VM Isolation. Because Project Codex involves running experimental AI models and scripts often generated by other AIs (which, as noted, can produce insecure or resource-heavy code), we cannot risk these processes running on the host OS.

By keeping the Intelligence Engine inside a full Virtual Machine with PCIe passthrough of the 5060 Ti (and eventually the RTX 6000), we create a "Blast Shield." If an experimental model causes a kernel panic or a massive memory leak, only that specific VM will crash. The Proxmox host Pear, the ZFS storage pool, and the critical services like pfSense and Jellyfin remain untouched. This isolation is the only way to safely innovate within a resource-constrained environment where RAM is a rare and precious commodity.

 

Future Hardware Roadmap: The VRAM and Bandwidth Horizon

While the current infrastructure is locked into a high-performance 2026 baseline, we must maintain a strategic view of the hardware "ceiling" that currently limits our AI processing potential. The primary bottleneck in the Sea Of Fate network is not just the volume of VRAM, but the Memory Bandwidth and Bus Width required to shuttle massive archival datasets into the GPU cores without stalling the system.

The Strategic Pivot: 128-bit vs. 384-bit Architectures

Our current NVIDIA 5060 Ti is a highly efficient consumer card, but it is architecturally constrained by its 128-bit memory bus. In the context of Project Codex, this creates a "throughput throttle" when running high-context window queries across multiple terabytes of extracted ZIM data.

As we look toward future upgrades, our primary technical goal is to transition to a professional-grade workstation card—specifically targeting the Quadro RTX 6000 (24GB) or eventually the Quadro RTX 8000 (48GB). These cards feature a 384-bit memory bus, offering nearly triple the data-transfer velocity of consumer mid-range cards. This increased bandwidth is essential for:

• Reducing Inference Latency: Allowing the AI to "read" through thousands of Markdown files with significantly less wait time.

• Large Context Handling: Maintaining stability when the VRAM is fully saturated by a 70B parameter model.

• ECC Reliability: Professional cards provide Error Correction Code (ECC) memory, which is vital for long-running batch-processing jobs where a single bit-flip could corrupt an entire archival index.

Monitoring the Market Inflection Point

We acknowledge that the second-hand market for these cards remains highly volatile as of early 2026, driven by intense enterprise demand for AI inference clusters.

• The RTX 6000 Strategy: At a current secondary market price of roughly £700, this remains the most viable immediate "step up" should the 5060 Ti be sold to recoup costs.

• The RTX 8000 Strategy: While currently hovering between £1,900 and £2,400, we are monitoring for a price drop toward the £1,000 threshold. At that point, the 48GB buffer would become the definitive "Sovereign Anchor" for Pear, enabling us to run the most advanced "Pre-Wash" models entirely on-premises.

Until these price-performance curves align with our available capital, we continue to optimize our software and networking stack to squeeze every bit of utility out of our existing silicon. We are building for the hardware we have, while remaining ready to strike when the professional market eventually yields to consumer-level budgets.