Neighbourhood Compute as Infrastructure
A distributed architecture for low-latency gaming, creative work, education and AI on inexpensive household receiver boxs.
Simplified Abstract
Today, families buy separate powerful computers even though those machines sit idle for most of the day. JB Compute proposes putting one powerful shared computer inside each neighbourhood instead. Homes connect to the neighbourhood computer over Ethernet through a small receiver box. The neighbourhood computer does all the heavy work; the receiver box sends keyboard, mouse or controller inputs to it and relays the resulting video feed back to the display. Because the computer is physically nearby, the experience can feel close to using a machine inside the house. The same infrastructure can serve gaming, education, architecture, video, AI and professional workloads. The system is fully executable using current-generation hardware and software, and can run over existing home and office Ethernet infrastructure without requiring any new networking standard.
Abstract: Modern cloud computing centralises powerful hardware but leaves interactive workloads constrained by distance, jitter and the economics of dedicating high-end devices to individual users. We propose a neighbourhood-scale compute layer: modular GPU nodes placed close to residential demand, connected over Ethernet, and accessed through inexpensive receiver boxs. The node runs the application; the receiver box sends input and decodes a live video stream. The result is high-end compute delivered as shared infrastructure rather than purchased as personal hardware.
1. System architecture
Keyboard, mouse and controller inputs travel upstream as small, latency-sensitive packets. The neighbourhood computer executes the application, renders each frame and encodes it. The resulting video and audio feed travels downstream to the receiver box, which decodes it and sends it to the display. The receiver box connects to the neighbourhood computer over Ethernet.
2. Reference node specification
| Layer | Reference specification | Design purpose |
|---|---|---|
| CPU | AMD EPYC / Threadripper Pro or Intel Xeon; high core count; PCIe lane density prioritised | VM hosting, game logic, orchestration, storage and network processing |
| Current NVIDIA option | RTX PRO 6000 Blackwell Server Edition; 96 GB GDDR7, PCIe 5.0, MIG, ninth-generation NVENC | High-density virtual workstations, graphics, AI and isolated GPU instances |
| Previous-generation NVIDIA option | L40S; 48 GB GDDR6 ECC, 91.6 FP32 TFLOPS, 3× NVENC / 3× NVDEC, vGPU support | Strong candidate for graphics-heavy production nodes and secondary-market procurement |
| Intel option | Data Center GPU Flex 170; 16 GB GDDR6, 150 W, AV1/H.265/H.264 hardware encode/decode | Media-dense workloads, VDI, cloud gaming and potential dedicated encode tier |
| Additional reuse pool | NVIDIA A40 / A10 / A5000 / T4-class hardware where economics justify | Lower-cost capacity for 1080p workloads, lighter graphics and mixed compute |
| Memory | 256 GB–1 TB ECC RAM, scaled to VM count | Concurrent isolated sessions without memory contention |
| Storage | 8–30 TB NVMe, mirrored where required | Local game/application library, VM images and hot user data |
| Networking | 10/25 GbE core; managed switch; Ethernet uplinks; 1/2.5 GbE household edge | Low-jitter local transport with sufficient aggregate downstream capacity |
| Virtualisation | KVM/QEMU + libvirt; NVIDIA vGPU/MIG or vendor SR-IOV where supported | Per-user isolation, GPU partitioning and failure containment |
| Streaming | Low-latency H.264/HEVC/AV1 pipeline; Sunshine/Moonlight-class stack initially; custom orchestration later | Input-to-photon delivery over commodity receiver boxs |
The relevant capacity metric is not “VMs per GPU” but ₹ per guaranteed concurrent 1080p60 session at p99. NVIDIA’s current Blackwell vGPU stack can expose multiple isolated or time-sliced virtual GPUs; Intel Flex is explicitly designed for VDI, media delivery and cloud-gaming workloads. Actual gaming density remains application-dependent and must be established empirically under mixed loads.
3. Deployment model
Atomic infrastructure unit
Deploy one self-contained node into a dense residential micro-market. Add GPUs as subscriber concurrency grows. If local demand declines, the node is physically redeployable. Expansion is replication, not centralisation.
Receiver box
The customer receives a small receiver box that connects to the home display and input devices. Its principal hardware requirement is reliable hardware video decode and low-latency networking—not workstation-class CPU or GPU performance.
Cloud relationship
Interactive latency terminates locally. Central cloud remains available for identity, billing, backups, model training, large renders, burst capacity and non-interactive batch workloads. Edge and cloud are complementary tiers.
Scaling control
Instrument GPU frame time, VRAM, encode latency, network RTT/jitter, decode time and dropped frames. Capacity is expanded before p95/p99 experience degrades. Each node is an independent P&L and failure domain.
4. Demand scope
The addressable problem is larger than gaming. Global housing stock was approximately 2.3 billion units in 2023 and is projected to exceed 3 billion by 2040. A credible long-run framing is therefore billions of people and more than two billion present-day households—not 3–5 billion current households. The service is most valuable wherever high-end personal hardware is expensive relative to household income, particularly in dense urban and peri-urban markets.
| Use case | Why neighbourhood compute matters |
|---|---|
| Console / PC gaming | Removes large upfront hardware purchase; provides predictable 1080p interactive graphics close to the user. |
| Architecture / CAD / 3D | Allows inexpensive laptops to access workstation-class rendering and modelling capability. |
| Education | Provides students with simulation, coding, creative and AI capability independent of receiver box quality. |
| AI inference | Shared local accelerators can serve voice, vision, language and multimodal interfaces with low interactive latency. |
| Video / creative work | Offloads GPU-intensive editing, effects, transcoding and rendering from thermally constrained personal machines. |
| SMB / professional desktops | Replaces infrequently utilised high-spec workstations with pooled capacity and inexpensive endpoints. |
| Public / community compute | Schools, libraries, housing communities and local institutions can expose advanced compute as shared infrastructure. |
5. Technical thesis and economic implication
Central cloud maximises pooling efficiency but cannot eliminate geography. Personal computing eliminates network dependence but duplicates expensive hardware across households. Neighbourhood compute occupies the missing layer: sufficiently local for interactive workloads, sufficiently shared for high utilisation, and modular enough to follow demand.
Node economics should therefore be managed like physical infrastructure: deploy only against measurable density, finance assets over multi-year lives, add accelerators incrementally, and redeploy hardware as demographics change. The strategic metric is utilisation-adjusted cost per reliable concurrent user. Improvements in GPU partitioning, hardware codecs, upscaling and scheduling directly increase the number of users served by the same physical node.
6. Initial validation programme
A first production-intent node should progress from 3 to 12 to 24 to 48 simultaneous independent sessions. Each stage should run mixed commercial workloads for sustained peak periods. The experiment should determine: (i) maximum service radius before p99 latency degrades; (ii) actual sessions per GPU by workload class; (iii) receiver box and Ethernet contribution to input-to-photon latency; (iv) reliability of VM/GPU isolation; and (v) all-in ₹ per guaranteed concurrent seat. Only after these measurements should a single hardware design be replicated geographically.