Hardware Readiness Registry

Single source of truth for the physical compute resources the Koder Stack relies on today, versus those that remain conceptually planned but inactive pending acquisition / procurement / sponsorship.

This is the hardware-axis companion to registries/target-readiness.md (which covers the OS/platform axis). A target can be active while still being gated on a specific hardware class — e.g. Linux is active but Linux with hardware GL for benchmarks is not.

Components, runbooks, and release engineering consult this registry to decide which experiments / benchmarks / production tiers can be exercised on the existing hardware vs which must be deferred. Flipping a row from inactive → active is owner-ratified and must surface every consumer-side gate in the same commit (the registry §"How to flip" procedure mirrors target-readiness.md).

This complements (does not replace):

  • meta/context/infrastructure/servers.md — per-host inventory (CPURAMdisk/NIC, current OS, role)
  • policies/heavy-work-isolation.kmd — where heavy work runs (s.khost1, never laptop)
  • policies/self-hosted-first.kmd G5 — critical-path readiness gate
  • registries/perf-baseline.md — measured perf numbers per host class

Status values

Status Meaning
active Hardware exists in the DC and is integrated (driver, runtime, scheduler). Workloads can land.
shared Hardware exists in the DC but is contended (single device serving multiple consumers). New workloads must consider contention.
active-laptop-carve-out Hardware exists ONLY on the owner laptop, not in the DC. Workloads that fail on DC hardware AND fit the laptop's capacity can run there per policies/heavy-work-isolation.kmd §R9. When the DC acquires equivalent hardware, the workload reroutes back automatically.
inactive Hardware does not exist on the Koder network or is not provisioned. Workloads gated on it stay deferred.
acquired-pending-integration Hardware purchased but not yet wired (drivers, runtime, IOMMU, scheduler) — transient state.

Registry

Compute / CPU

Class Status Where Notes
cpu-server-class active s.khost1 (koder-host-1) — Intel/AMD multi-socket, 128+ GB RAM Primary compute substrate. Hosts every dev-* VM + production LXCs (id, hub, flow, ai*, kdb, jet).
cpu-laptop active rpm32510943 (owner laptop) Excluded from heavy work per policies/heavy-work-isolation.kmd. Used for orchestration, local UI demos, and the Claude Code session itself.

GPU

Class Status Where Notes
gpu-datacenter-headless (Tesla T4 16 GB) shared s.khost1 — exposed to LXCs airuntime and aivoice via NVIDIA Container Toolkit 1.19.0 (device gpu + nvidia.runtime=true) sharing the same UUID. Sufficient for inference workloads currently shipped (whisper, llama-cpp). FP16/INT8 compute fine. Drivers: nvidia-driver 550.163.01 + cuda-toolkit 12.4 since 2026-05-06 (KSTACK-121 fase 1). Limitations: no display output (Matrox MGA G200eH3 is the BMC VGA, not consumer GL); marginal for graphics benchmarks (Chrome WebGL → SwiftShader fallback historically); 16 GB VRAM caps larger models.
gpu-consumer-laptop (RTX 4070 Mobile 8 GB, Ada Lovelace) active-laptop-carve-out Owner laptop (rpm32510943) — NVIDIA driver 595.71.05, OpenGL 4.6, direct rendering. Also Intel UHD 770 iGPU available. The only consumer-class GPU on the Koder network as of 2026-05-28. The DC has no consumer GPU. Workloads that require hardware GL on a real display server route here per policies/heavy-work-isolation.kmd §R9 carve-out. 8 GB VRAM caps high-end AI workloads (SDXL borderline, BGE-large marginal, RTX 4090 reference workloads only partially feasible).
gpu-consumer (RTX 4090 / 3090 / A6000 / equivalent — ≥24 GB VRAM, display capable, gaming-class throughput) inactive — Gating: procurement of a dedicated DC-class consumer GPU. Needed for (a) AI workloads where 8 GB VRAM of the laptop is insufficient (BGE-large, SDXL, AudioCraft, training runners), (b) graphics workloads that can't tolerate the laptop's intermittent availability, and (c) display-equipped iteration of Wayland/CEF render paths in long-running form. Owner decision pending on whether to buy or to sponsor a colocated bare-metal benchmark host.
gpu-consumer-passthrough-vm (consumer GPU + VFIO + dev-linux-kruze with real display server) inactive — Gating: gpu-consumer first. Cascades on the row above. Needs IOMMU group isolation of the consumer GPU + dev-linux-kruze rebuilt with Xorggnome-shell to provide a real GL context to ChromeCEF. Estimated effort post-acquisition: ~1 day VM rebuild + ~2-3h VFIO config.

Storage

Class Status Where Notes
nvme-local active s.khost1 host + LXC volumes Primary storage tier.
slow-bulk shared Google Drive (rpm32510@gmail.com:BACKUP/k-backup/) Backup target only — never a build/serve substrate.

Network

Class Status Where Notes
lan-eveo-dc active EVEO DC 177.93.107.3 → 10.0.1.0/24 All s.khost1 LXCsVMs. Subject to ISPDC uplink dependency (see project_eveo_dc_outage_2026-05-25 memory).
lan-laptop active Brazilian ISP at owner residence Used for Claude Code sessions + VPN into EVEO.

Hardware Apple (MaciPhoneiPad)

Cross-references registries/target-readiness.md rows macos and ios, both inactive. The hardware gating is the same physical Mac acquisition.

Stack-wide tickets gated on consumer GPU

Tickets are split by which hardware row covers them.

Covered by gpu-consumer-laptop carve-out (heavy-work-isolation.kmd §R9)

Workloads that fit the laptop's RTX 4070 Mobile (8 GB VRAM, hardware GL, real display server) AND fail on Tesla T4 headless. Each row here is a documented exception to §R1 of the heavy-work-isolation policy. Commit messages that exercise these workloads MUST reference this section.

Ticket Component Why DC fails Why laptop fits What lands
kruze#181 (fase 2) products/horizontal/kruze/app/desktop Tesla T4 has no display output (Matrox BMC VGA only); Chrome WebGL falls back to SwiftShader/llvmpipe → JetStream 3 + MotionMark time out >1h. RTX 4070 + display server → real OpenGL 4.6 → standard graphics harnesses complete. JetStream 3 + MotionMark scores Chrome vs Kruze (3 repeats median) → registries/perf-baseline.md.
kroma#026 engines/sdk/kroma s.khost1 has only llvmpipe (software Vulkan); the first Vello render is shader-compile-bound (seconds–10s), so real GPU frame-time is unmeasurable there. RTX 4070 (NVIDIA Vulkan) runs the Vello compute pipeline natively. Bench is OFFSCREEN (render-to-texture, no display server) → even lighter than kruze#181 (no PSR/window). Real-GPU cold first-frame + warm steady-state render for the Kroma terminal (RFC-019 §4.2 feel gate) → registries/perf-baseline.md. Done 2026-06-24: cold 41 ms, warm 831 µs (~1,200 fps).

Gated on gpu-consumer (DC procurement)

Workloads that exceed the laptop's 8 GB VRAM, need to run for long periods without contending with owner's interactive use, or otherwise require a DC-class consumer GPU.

Ticket Component Why laptop doesn't cover What flips when gpu-consumer activates
embed#011 services/ai/embed Explicit "RTX 4090 or equivalent" requirement; BGE-large likely exceeds 8 GB at production batch sizes; needs to run as a persistent service, not as one-shot on laptop. BGE-large p50 < 50 ms / batch=64 < 200 ms latency targets become measurable. LXC s.embed.gpu can be provisioned.
imaging#004 services/ai/imaging "24 GB GPU" stated requirement for SDXL with LoRAs/ControlNet headroom; 8 GB borderline for base SDXL even without extras; persistent service shape. txt2img 1024×1024 → < 8s (steps=30) baseline reachable. Self-hosted-first G1 (parity) achievable for imaging.
synth#005 services/ai/synth "RTX 4090 baseline" for AudioCraft music/SFX; MusicGen-large > 8 GB; persistent service shape. AudioCraft (MusicGen + AudioGen) becomes deployable.
training#005 services/ai/training Fine-tuning runners need real GPU + sustained throughput; even small models would contend with owner's interactive use indefinitely. Axolotl + Unsloth runners exercise real training.

Cascading row: kruze#199 (Accelerated OSR) is BLOCKED by upstream CEF 130 not exposing a Linux OnAcceleratedPaint backend — not by hardware. Listed in target-readiness.md-style upstream gating, not here.

How to flip a hardware class from inactive to active

  1. Owner procures the hardware (purchase / lease / colocate sponsorship).

    For consumer GPU specifically: identify card class (RTX 4090 / 3090 / A6000 / equivalent), PSU headroom on s.khost1, physical PCIe slot availability.

  2. Physical install + firmware update on s.khost1 (or the dedicated host).
  3. Driver + runtime integration:
    • For NVIDIA consumer cards: install proprietary driver + verify it

      coexists with the existing Tesla T4 driver (nvidia-driver already handles multi-GPU; should be drop-in).

    • For passthrough use: enable IOMMU isolation, blacklist host

      binding, configure VFIO.

  4. Flip this row's Status to active; move the gating condition to a

    "Historical gates" note at the bottom.

  5. In the same commit that flips the row:
    • Provision the dependent LXC/VM (s.embed.gpu, s.imaging.sdxl,

      dev-linux-kruze-gl, etc.).

    • Register entries in meta/context/infrastructure/servers.md.
    • Move each gated ticket from "deferred" to actively scheduled in its

      backlog.

  6. The grep hardware-readiness.md across the monorepo surfaces every

    gated site so the flip day has a closed punch-list.

How to mark gpu-consumer as inactive again (regression)

Unlikely (you don't typically un-buy a GPU). Listed for completeness: hardware loss (theft, failure, lease termination) → re-flip the row, re-defer dependent tickets, document the regression.

Cross-references

  • registries/target-readiness.md — OS/platform-axis sibling (macOS+iOS inactive on the same procurement model)
  • meta/context/infrastructure/servers.md — per-host hardware inventory + mnemonics
  • policies/heavy-work-isolation.kmd — where heavy work executes
  • policies/self-hosted-first.kmd §G5 — critical-path readiness for self-hosted components (overlaps when a self-hosted component requires GPU to match an external)
  • registries/perf-baseline.md — measured numbers per host class
  • registries/koder-id-auth-coverage.md — surface conformance grid (descriptive; hardware-readiness does not affect surface definitions)