Papers
Topics
Authors
Recent
Search
2000 character limit reached

TideGS: Scalable Training of Over One Billion 3D Gaussian Splatting Primitives via Out-of-Core Optimization

Published 19 May 2026 in cs.CV and cs.PF | (2605.20150v1)

Abstract: Training 3D Gaussian Splatting (3DGS) at billion-primitive scale is fundamentally memory-bound: each Gaussian primitive carries a large attribute vector, and the aggregate parameter table quickly exceeds GPU capacity, limiting prior systems to tens of millions of Gaussians on commodity single-GPU hardware. We observe that 3DGS training is inherently sparse and trajectory-conditioned: each iteration activates only the Gaussians visible from the current camera batch, so GPU memory can serve as a working-set cache rather than a persistent parameter store. Building on this insight, we introduce TideGS, an out-of-core training framework that manages parameters across an SSD-CPU-GPU hierarchy via three synergistic techniques: block-virtualized geometry for SSD-aligned spatial locality, a hierarchical asynchronous pipeline to overlap I/O with computation, and trajectory-adaptive differential streaming that transfers only incremental working-set deltas between iterations. Experiments show that TideGS enables training with over one billion Gaussians on a single 24 GB GPU while achieving the best reconstruction quality among evaluated single-GPU baselines on large-scale scenes, scaling beyond prior out-of-core baselines (e.g., approximately 100M Gaussians) and standard in-memory training (e.g., approximately 11M Gaussians).

Summary

  • The paper presents TideGS, which trains over 1 billion 3D Gaussian splatting primitives on a single GPU by materializing only the dynamic working set during training.
  • It introduces a novel out-of-core framework using block virtualization, hierarchical asynchronous execution, and trajectory-adaptive differential streaming to overcome VRAM constraints.
  • Experiments demonstrate high reconstruction fidelity and competitive throughput, outperforming prior multi-GPU approaches in cost-effective, large-scale neural rendering.

TideGS: Out-of-Core Billion-Scale 3D Gaussian Splatting on a Single GPU

Overview and Motivation

TideGS presents a system for training over one billion 3D Gaussian Splatting (3DGS) primitives on a single commodity GPU (e.g., 24 GB VRAM), addressing the acute VRAM bottleneck inherent to the memory structure of 3DGS models. The central insight is that only a small, dynamic subset of Gaussians—those visible from a camera's viewpoint during each training iteration—undergo gradient updates, yielding strong sparsity and temporal locality. By virtualizing the parameter table across the SSD–CPU–GPU hierarchy and materializing only the currently active working set in GPU memory, TideGS sidesteps the VRAM limitations that confine prior approaches to 100\leq 100 million primitives.

Figure 1

Figure 1: TideGS enables city-scale 3DGS training on a single GPU by virtualizing the Gaussian parameter table across the SSD–CPU–GPU hierarchy and materializing only the trajectory-activated working set in VRAM.

The system integrates three synergistic strategies: block-virtualized geometry with spatial locality, a hierarchical asynchronous pipeline overlapping I/O with computation, and trajectory-adaptive differential streaming that reduces inter-tier data traffic. TideGS thus enables high-scale, high-fidelity novel view synthesis for city-scale neural rendering using commodity hardware.

Out-of-Core Pipeline and System Design

At its core, TideGS implements a multi-tier memory hierarchy for Gaussian parameter management and scheduling, depicted in the system pipeline:

Figure 2

Figure 2: The TideGS pipeline. (a) SSD-resident blocks are cached in CPU RAM and materialized in GPU VRAM as a working set. (b) Trajectory-adaptive differential streaming stages only incremental working-set deltas, minimizing transfer costs.

Block Virtualization and Visibility Filtering

TideGS partitions the entire parameter table into SSD-aligned spatial blocks, using Morton-ordering to align spatial locality with storage layout. Bounding spheres are constructed for each block, and a coarse CPU-side 6-plane frustum culling test selects blocks likely to be visible to the current camera batch. This reduces redundant data staging from SSD, since only relevant blocks are transferred up the memory hierarchy. Fine-grained per-Gaussian filtering is then performed on the GPU for exact visibility masking.

Figure 3

Figure 3: Block virtualization partitions Gaussians into SSD-aligned blocks, summarized by bounding spheres. Coarse CPU-side culling precedes finer GPU-level filtering for efficient visibility selection.

Hierarchical Asynchronous Execution

To hide I/O latency and saturate throughput, TideGS employs an asynchronous execution model:

  • SSD Layer: Employs log-structured append-only segments for efficient sequential writes and reduced SSD wear.
  • CPU Layer: Maintains a warm LRU cache, tracking dirty blocks and flushing updates only on eviction or explicit synchronization, thereby batching writes.
  • GPU Layer: Capacity-bounded VRAM residency allows rendering and backpropagation exclusively on the current working set, minimizing memory footprint.

Crucially, data transfers up or down the hierarchy (SSD\toCPU\toGPU) are overlapped with GPU computation, using dedicated streams for each path.

Trajectory-Adaptive Differential Streaming

Standard 3DGS training often samples camera viewpoints randomly, yielding low temporal locality. TideGS instead traverses camera trajectories in a clustered/TSP order, ensuring high overlap among consecutive working sets. A residency scoring mechanism, combining access recency and predicted next-step usefulness, manages the limited GPU working set. Only the delta—the set-difference between successive resident sets—is staged or evicted (incremental streaming), making VRAM traffic scale with working-set change rather than model size.

Experimental Results and Performance Evaluation

Scalability and Memory Bottleneck

On a single 24 GB GPU, previous in-memory or host-offload baselines cap out at 11M (Native 3DGS), \sim50M (Naive Offload), or \sim100M (CLM) Gaussians before VRAM or rasterization buffer overflows. TideGS decouples VRAM usage from total model size, with memory scaling only in the working set size, enabling training with >1B\mathbf{>1B} Gaussians; the limiting factor becomes SSD/CPU capacity and bandwidth rather than GPU memory.

Overhead and Consistency

In the in-memory regime (scenes \leq10M–25M Gaussians), TideGS achieves throughput within 12% of Native 3DGS and matches reconstruction quality (PSNR gap <0.12<0.12 dB), confirming minimal architectural overhead when parameter virtualization is not required.

Large-Scale Out-of-Core Training

For MatrixCity (\sim102M, \sim1.1B Gaussians), TideGS alone remains feasible at billion-scale, maintaining high GPU utilization (43–50%) and keeping per-iteration bandwidth and latency competitive even when streaming working-set deltas from the SSD. At \to0B Gaussians, TideGS achieves 26.1 dB PSNR, exceeding lower-capacity baselines.

Figure 4

Figure 4: Quality scaling on MatrixCity—TideGS achieves the highest PSNR (26.1 dB) at the billion-primitive scale while previous methods fail with OOM.

Ablations and Impact of Core System Components

Disabling trajectory-adaptive differential streaming increases PCIe traffic by up to 8.5\to1; removing asynchronous overlap triples iteration latency. Breaking spatial locality drops cache hit rates from 95% to 42%, further inflating data traffic. These effects degrade efficiency but do not compromise final reconstruction quality, highlighting the orthogonality of the system designs to core optimization objectives.

Training with Dense Initialization

Fixed-size, dense-initialized training (without densification) achieves parity with adaptive densification on both indoor and outdoor scenes, showing that model scaling does not fundamentally depend on incremental primitive growth in this workflow.

Figure 5

Figure 5: Dense-initialized fixed-size training matches densified training on the Mip-NeRF 360 bicycle scene.

Figure 6

Figure 6: Dense-initialized fixed-size training matches densified training on the bonsai scene.

View Ordering and Convergence

Trajectory-based view ordering, while exploiting spatiotemporal locality for data reuse, leads to minimal quality degradation and comparable convergence curves relative to traditional randomly shuffled SGD.

Figure 7

Figure 7: Convergence comparisons for randomized shuffling versus trajectory-based ordering show negligible impact on reconstruction quality.

Comparison with Multi-GPU Approaches

Whereas distributed, in-memory multi-GPU systems such as Grendel-GS and RetinaGS offer improved wall-clock convergence, they impose high hardware and engineering costs with diminishing capacity-per-dollar efficiency. TideGS expands the upper bound of trainable capacity on a single node and fits scenarios where scalable training is needed within commodity hardware constraints.

Figure 8

Figure 8: Wall-clock time-to-convergence—TideGS achieves billion-scale capacity per node with modest single-node hardware cost.

Figure 9

Figure 9: Training-iteration-wise convergence—TideGS effectively amortizes I/O without losing optimization efficiency.

Implications and Future Directions

TideGS demonstrates that out-of-core hierarchical management of 3D point-based or splatting representations can facilitate orders-of-magnitude scaling on commodity hardware without sacrificing reconstruction quality or throughput. Methodologically, this approach motivates sparsity- and locality-aware optimization in other memory-bound architectures, including neural radiance fields, large-scale embedding tables, or geometric transformers. Practically, city-scale and world-scale neural rendering and mapping become feasible for cost-sensitive applications beyond well-resourced research labs.

Potential future developments include:

  • Integration of more complex optimizer-state streaming strategies for improved convergence in the high-churn regime.
  • Adaptation to general point-based or hybrid representations in neural graphics.
  • Closer coupling of differential streaming with task-aware active data selection for semi-supervised or online learning.

Conclusion

TideGS establishes a new paradigm for scalable 3DGS training by virtualizing the parameter table over hierarchical storage, tightly orchestrating data movement, and exploiting the inherent sparsity and locality of the rendering task. It is the first system to achieve billion-scale 3DGS optimization on a single commodity GPU with state-of-the-art reconstruction fidelity, offering a practical blueprint for future out-of-core neural scene representations.


Reference: "TideGS: Scalable Training of Over One Billion 3D Gaussian Splatting Primitives via Out-of-Core Optimization" (2605.20150)

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Explain it Like I'm 14

What is this paper about?

This paper is about making super‑detailed 3D scenes (like whole cities) easier to train and display on a single, regular graphics card. It focuses on a technique called 3D Gaussian Splatting, which represents a scene as millions (or even billions) of tiny, soft “blobs” that hold color and shape information. The problem: training so many blobs usually needs more memory than a single GPU has. The authors introduce TideGS, a system that smartly moves data between storage (SSD), computer memory (RAM), and the graphics card (GPU) so you only keep what you need in fast memory at the right time. This lets them train scenes with over one billion blobs on a single 24 GB GPU.

What are the goals of the paper?

  • Make it possible to train very large 3D scenes (city‑scale) on a single GPU, instead of needing a big, expensive multi‑GPU setup.
  • Keep training fast and high‑quality even when the whole scene can’t fit in GPU memory.
  • Use the fact that, at any moment, only the parts of the scene visible to the current camera are actually needed.

How did they do it? (Methods explained with simple ideas)

Think of building a huge 3D city as managing a giant library of “books” (the Gaussians/blobs). The GPU (your graphics card) is like a small desk with limited space (VRAM), your computer’s memory (RAM) is a rolling cart, and the SSD is the bookshelf. You can’t put all the books on your desk, so you:

  • Keep only the books you’re reading right now on the desk (GPU).
  • Keep a few more nearby on the cart (RAM).
  • Store everything else on the shelf (SSD).

To make this efficient, TideGS uses three big ideas:

  1. Block‑virtualized geometry (grouping nearby things into “boxes”)
  • Instead of handling every tiny blob one by one, they pack nearby blobs into boxes (“blocks”) that line up nicely with how SSDs read data.
  • Before each step, they do a quick, coarse check on the CPU: “Which boxes are even in front of the camera?” Only those boxes move up from SSD → RAM → GPU.
  • Analogy: If you’re looking down a street, you don’t fetch books about the other side of town.
  1. Hierarchical asynchronous pipeline (doing multiple tasks at once)
  • While the GPU is busy training on the current boxes, the system is already:
    • Reading the next boxes from SSD into RAM,
    • Sending needed boxes from RAM to GPU,
    • Saving updated boxes back from GPU → RAM → SSD in the background.
  • Analogy: While you read, a helper fetches the next books and returns the finished ones—no waiting.
  1. Trajectory‑adaptive differential streaming (only move what changed)
  • Cameras usually move smoothly (like walking down a street). That means much of what you need now is similar to what you needed a moment ago.
  • TideGS keeps overlapping boxes on the GPU and only streams in the differences for the next step, evicting boxes you won’t need soon.
  • Analogy: Don’t re‑carry a whole backpack every step—just swap in the few items you need next.

A few terms in everyday language:

  • GPU/VRAM: The fast but small “desk” where work happens.
  • CPU/RAM: The roomier “cart” near the desk.
  • SSD: The big but slower “bookshelf” in the back.
  • Out‑of‑core: Working with data that doesn’t fit on the desk, using the cart and shelf smartly.
  • Visibility: Only the blobs the camera can see matter for that step.

What did they find, and why is it important?

  • Trains over one billion Gaussians on a single 24 GB GPU:
    • Earlier single‑GPU methods hit memory walls much earlier: around ~11.5 million (standard in‑memory training) to ~100 million (best host‑offloading baseline).
    • TideGS breaks this limit by treating GPU memory like a cache and keeping most data on SSD/RAM.
  • Keeps quality high and overhead low:
    • When scenes are small enough to fit in memory, TideGS matches the quality of normal 3D Gaussian Splatting and adds less than ~15% training overhead.
    • On a large city‑scale dataset, increasing the number of blobs improves image quality. For example, at ~1.1 billion blobs TideGS reaches higher PSNR than baselines that can’t scale that far.
  • Moves much less data each step:
    • At ~102 million blobs, TideGS cuts transfer (PCIe) traffic about 4× compared to a strong baseline, making iterations faster.
    • Even at ~1.1 billion blobs, the GPU stays usefully busy because data loading is overlapped with computation.

Why this matters:

  • Better, more detailed 3D reconstructions (e.g., for virtual reality, maps, movies) without needing expensive multi‑GPU rigs.
  • Makes city‑scale training more accessible to researchers and developers with everyday hardware.

What’s the big picture?

TideGS shows a practical way to train massive 3D scenes on a single GPU by:

  • Treating fast GPU memory as a temporary workspace,
  • Organizing scene data into smart, SSD‑friendly blocks,
  • Fetching only what the camera needs right now,
  • And overlapping loading with computation so the GPU doesn’t sit idle.

This approach could inspire similar “out‑of‑core” designs for other big machine‑learning tasks where the full model doesn’t fit in GPU memory. It brings high‑quality, city‑scale 3D modeling within reach for many more people and applications.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

The paper leaves several aspects missing or underexplored that future work could address:

  • Optimizer state persistence vs. cold restarts:
    • Quantify how discarding Adam moments on eviction affects convergence speed, stability, and final quality across datasets and scales.
    • Explore alternatives (e.g., storing/streaming compressed moments, low-rank/quantized moments, or stateful SSD-resident moments) and measure the traffic/quality trade-offs.
  • Dynamic model growth (densification/pruning):
    • Specify how out-of-core allocation handles adding/removing Gaussians (owner-block assignment, index updates, fragmentation, rebalancing).
    • Evaluate the impact of dynamic topology changes on block locality, culling precision, cache churn, and SSD write patterns.
    • Assess whether periodic reblocking or compaction is required as centers move or new points are inserted.
  • Sensitivity to block design:
    • Systematically sweep block size BB and study its effects on SSD alignment, culling tightness, cache hit rates, PCIe/SSD traffic, and VRAM use.
    • Compare Morton ordering to alternative spatial structures (e.g., octrees, k-d trees, Hilbert curves) and bounding volumes (AABBs vs. spheres) for culling precision and streaming efficiency.
  • Trajectory dependence and worst-case access patterns:
    • Measure robustness when camera order is random, contains teleports, or consists of multi-agent, non-smooth trajectories (beyond the TSP-ordered assumption).
    • Characterize worst-case resident/working-set churn, PCIe/SSD bandwidth spikes, and throughput degradation under adversarial or highly dynamic viewpoints.
    • Develop and evaluate predictive/learned prefetchers versus the current recency/next-step heuristic.
  • Resident-set scheduling:
    • Detail and analyze the “CameraBalancedTop-C” policy (fairness across cameras, coverage guarantees, complexity).
    • Study hyperparameter sensitivity (e.g., mixing weight λ\lambda) and provide guidance or adaptive tuning strategies.
    • Explore alternative policies (e.g., utility-aware, reinforcement learning-based, or lookahead schedulers) with formal guarantees or bounds.
  • Rasterization-side VRAM buffers:
    • Quantify the remaining VRAM footprint and buffer scaling with It|\mathcal{I}_t| under worst-case visibility (e.g., very wide-FOV or omnidirectional rigs).
    • Provide memory planning for bounded worst-case It|\mathcal{I}_t| to avoid rare-but-fatal OOM events and characterize graceful degradation strategies.
  • SSD write path and durability:
    • Measure write amplification, patch-segment growth, GC/compaction costs, and their impact on iteration time and SSD endurance (TBW) over long runs.
    • Define crash-consistency and recovery semantics (index persistence, atomicity, checksum/CRC, partial write handling), and benchmark restart overheads.
    • Compare append-only log design against alternatives (e.g., CoW B-trees, LSM variants) for throughput vs. maintenance overhead.
  • Hardware generalization:
    • Benchmark across GPUs (VRAM sizes, architectures), interconnects (PCIe Gen3/4/5, NVLink), and storage (consumer vs. enterprise NVMe, multi-SSD RAID, networked storage).
    • Evaluate NUMA effects, filesystem differences, and OS cache interactions; quantify sensitivity to page sizes and I/O scheduling.
    • Assess benefits of GPUDirect Storage or direct NVMe→GPU DMA to bypass CPU copies.
  • Precision and compression:
    • Investigate mixed-precision/quantized parameter and optimizer states (fp16/bf16/int8) and lossless/lossy SSD-side compression to reduce bandwidth and storage footprint.
    • Quantify the impact of quantization on rendering fidelity and convergence.
  • Bounding-volume maintenance:
    • Specify update frequency and cost for refreshing block bounds as centers move; quantify the resulting culling conservativeness and its effect on extra transfers.
    • Explore tighter, incremental, or learned bounds to reduce overfetch without frequent recomputation.
  • Scalability to scenes with high visible fractions:
    • Evaluate performance on settings where a large fraction of Gaussians is visible per iteration (e.g., aerial panoramas, fisheye rigs), including throughput and cache behavior.
    • Identify fallback strategies when Kt|\mathcal{K}_t| or It|\mathcal{I}_t| regularly approaches VRAM limits.
  • Interaction with different parameterizations:
    • Test other appearance models (higher-degree SH, learned features) and geometry encodings; characterize how DD affects I/O and caching trade-offs.
    • Validate that conclusions hold beyond the degree-3 SH, D=59D{=}59 setup.
  • Quality–capacity–time trade-offs:
    • Provide scaling laws relating PSNR/SSIM/LPIPS improvements to the number of Gaussians and total training time, including diminishing returns at very high NN.
    • Examine whether bigger models require proportionally longer training or different schedules to realize quality gains.
  • Inference-time streaming:
    • Extend and evaluate the out-of-core pipeline for real-time inference/rendering at scale (latency, stutter, cache policies, prefetching from predicted camera paths).
  • Broader dataset coverage:
    • Validate on diverse scene types (indoor, dynamic, non-textured, varying lighting), larger/denser city datasets, and different capture rigs.
    • Report failures or degradation modes to guide applicability boundaries.
  • Prefetch accuracy and penalties:
    • Quantify prefetch miss penalties, pipeline stalls due to late data, and the effectiveness of lookahead depth; propose adaptive prefetch windows.
  • System overhead transparency:
    • Break down CPU-side computation (visibility tests, index lookups, cache management) and its contribution to iteration time across scales.
  • Multi-GPU or distributed extensions:
    • Design and evaluate how TideGS interacts with multi-GPU data/model parallelism and shared/networked storage; address consistency, sharding, and cross-GPU residency coordination.
  • Index and metadata scaling:
    • Report memory and update costs of the per-block index as KK grows (to >1B primitives), including serialization format, caching, and lookup latency.
  • Reproducibility and fault-injection:
    • Provide results under induced I/O errors, SSD throttling, or power failures to assess robustness and recovery behavior in practical deployments.

Practical Applications

Practical Applications of TideGS (from findings, methods, and innovations)

Below we translate TideGS’s contributions—out-of-core SSD–CPU–GPU training, block-virtualized geometry with spatial locality, hierarchical async pipelines, and trajectory-adaptive differential streaming—into actionable use cases. We group them by deployability and note sector links, workflows/products that could emerge, and key assumptions/dependencies.

Immediate Applications

  • City-scale digital twins on commodity hardware
    • Sectors: geospatial, smart cities, AEC, government
    • What’s enabled: Single-workstation training of city-scale 3DGS assets (>1B Gaussians) from aerial/street imagery, suitable for visualization, planning, and stakeholder engagement.
    • Tools/workflows: TideGS-based CLI pipeline; preprocessing with Morton sorting; trajectory-ordered (TSP-style) camera scheduling; SSD-backed training; export to web viewers or engines (e.g., Unity/Unreal).
    • Assumptions/dependencies: NVMe SSD (≈3 GB/s), 24 GB GPU class, calibrated imagery/poses, scene sparsity and trajectory locality, acceptable privacy redaction handled upstream.
  • HD mapping backdrops for autonomous driving simulation
    • Sectors: automotive, robotics, simulation
    • What’s enabled: Photorealistic large-scale backdrops for driving simulators (e.g., CARLA, NVIDIA DRIVE Sim), trained on single-GPU workstations from fleet or dashcam data.
    • Tools/workflows: Integrate TideGS-trained radiance fields for rendering static environments; use log-structured SSD scene store for quick scene swaps; camera-path-aware data loader.
    • Assumptions/dependencies: Static scene dominance (dynamic actors filtered); localization/pose accuracy; simulator integration for real-time splatting.
  • Drone-based site capture for construction and infrastructure
    • Sectors: AEC, utilities, surveying
    • What’s enabled: Rapid conversion of long corridor or large job-site captures into photorealistic 3DGS, run on on-site laptops/workstations.
    • Tools/workflows: Drone imagery → pose estimation (e.g., COLMAP) → TideGS training (SSD-tier, differential streaming) → viewer for progress tracking.
    • Assumptions/dependencies: Sufficient SSD capacity; reliable camera calibration; handling of repetitive textures and reflective surfaces.
  • Location scouting, virtual sets, and open-world environments
    • Sectors: media/VFX, gaming
    • What’s enabled: Turn large outdoor captures into production-ready photorealistic sets without GPU clusters; enable iterative updates at low cost.
    • Tools/products: TideGS training packaged as DCC plugin; export to real-time engines; block-based asset versioning (SSD patch segments).
    • Assumptions/dependencies: Existing 3DGS viewers/renderers in DCC/engines; content rights and on-set capture permissions.
  • Municipal GIS teams democratizing 3D models
    • Sectors: public sector, policy
    • What’s enabled: City departments build/maintain 3D city models on commodity workstations—reducing reliance on cloud GPU clusters and cost barriers.
    • Tools/workflows: On-prem pipelines; standardized SSD-based scene archives; periodic checkpoints via log-structured compaction.
    • Assumptions/dependencies: Procurement of NVMe-equipped workstations; data governance/privacy workflows; staff training.
  • Academic labs scaling scene representations without multi-GPU
    • Sectors: academia, research
    • What’s enabled: Training and study of very large scene representations on a single GPU to evaluate scaling laws, densification strategies, and rendering kernels.
    • Tools/workflows: Open-source TideGS repo; ablation-friendly configs (block size, cache budgets, overlap on/off); metrics for PCIe/SSD traffic.
    • Assumptions/dependencies: Repro-friendly OS/driver configs; datasets with long trajectories (e.g., MatrixCity, Mip-NeRF 360 derivatives).
  • Systems pattern for out-of-core sparse training
    • Sectors: software systems/ML infra
    • What’s enabled: Adopt TideGS’s trio—SSD-aligned blocked storage, async cross-tier pipelining, and set-difference streaming—for other sparse, access-local workloads (e.g., point clouds, large surfel maps).
    • Tools/workflows: Reusable PyTorch module for SSD-backed parameter tables; CPU write-back caches with dirty tracking; prefetch schedulers.
    • Assumptions/dependencies: Strong sparsity and temporal locality; tolerance to cold-restart optimizer states.
  • Cultural heritage and large-scale asset digitization
    • Sectors: museums, NGOs, tourism
    • What’s enabled: Regional-scale photorealistic reconstructions from archival/drone imagery on modest hardware.
    • Tools/workflows: TideGS + archival pose recovery; SSD scene archives; public-facing web viewers.
    • Assumptions/dependencies: Legal capture and publishing rights; stable long camera paths for high reuse.
  • Rapid disaster assessment from aerial surveys
    • Sectors: emergency response, insurance
    • What’s enabled: Fast generation of large-area photorealistic models post-event on field-deployable workstations.
    • Tools/workflows: Drone imagery → poses → TideGS one-pass training; incremental SSD patch segments for updates.
    • Assumptions/dependencies: Data transfer/logistics; time-to-first-visual constraints; partially dynamic scenes may reduce fidelity.
  • Cost- and energy-aware procurement and sustainability practices
    • Sectors: policy, enterprise IT
    • What’s enabled: Replace multi-GPU clusters with single NVMe-equipped workstations for large-scene training; lower embodied and operational carbon.
    • Tools/workflows: ROI calculators factoring reduced GPU count; procurement templates specifying NVMe throughput/capacity instead of cluster GPUs.
    • Assumptions/dependencies: Throughput needs compatible with single-GPU training times; SSD endurance considerations.

Long-Term Applications

  • Continuous, city-scale, lifelong 3D maps with incremental updates
    • Sectors: smart cities, autonomous mobility, digital twins
    • What could emerge: TideGS-like out-of-core online trainers that ingest streaming images/LiDAR and update scene blocks in-place; near-real-time map refresh.
    • Dependencies: Online densification/pruning; robust dynamic-object handling; background compaction; scheduler for block-level consistency.
  • On-robot or edge out-of-core mapping for field robotics
    • Sectors: robotics, defense, agriculture, mining
    • What could emerge: Robots with NVMe SSDs and modest GPUs building photorealistic maps on-board using differential streaming and block caches.
    • Dependencies: Ruggedized SSDs; power and thermal budgets; robust performance under non-smooth trajectories.
  • Generalized “out-of-core tensor optimizer” for sparse ML models
    • Sectors: recommender systems, ads/e-commerce, NLP infra
    • What could emerge: A library applying block virtualization and set-difference streaming to massive embedding tables or MoE experts; SSD-tier optimizer states with smart residency.
    • Dependencies: Proven sparsity/temporal locality; optimizer-state persistence policies; PCIe/NVMe contention management in production.
  • Internet-scale, tiled 3DGS streaming for web/AR
    • Sectors: software, XR, CDNs
    • What could emerge: A CDN-backed “TiledGS” format where viewers stream Morton-ordered blocks on demand; WebGPU/WebGL splatting with LOD control.
    • Dependencies: Standardized block formats; adaptive streaming protocols; client GPU capabilities; bandwidth variability handling.
  • Physics- and analytics-augmented digital twins
    • Sectors: urban planning, telecom, energy
    • What could emerge: Hybrid pipelines blending photorealistic 3DGS with analytical overlays (solar, RF, noise) for planning at district or city scale.
    • Dependencies: Semantic layers and calibration; coupling radiance-based assets with physics engines; validation for decision-making.
  • Medical imaging at population or full-body time-series scales
    • Sectors: healthcare, biomedical research
    • What could emerge: Adapt out-of-core training to volumetric radiance or scatter representations for very large CT/MRI cohorts or 4D sequences on single GPUs.
    • Dependencies: Representation suitability for medical data; regulatory/PHI constraints; evaluation on clinical metrics.
  • Large-scale cultural/archaeological region modeling
    • Sectors: heritage, academia
    • What could emerge: Country- or region-scale photorealistic models assembled over months with block-versioned SSD stores and periodic compaction.
    • Dependencies: Coordinated capture programs; standardized storage and metadata; sustainability and archiving strategies.
  • Privacy-aware city model training pipelines
    • Sectors: policy, compliance, public sector IT
    • What could emerge: Integrated redaction/anonymization stages (e.g., face/license plate suppression) baked into block read/write paths and checkpoints.
    • Dependencies: Reliable detection/redaction; governance frameworks; community consent.
  • Hybrid SLAM + 3DGS workflows for AR navigation and wayfinding
    • Sectors: mobile, XR
    • What could emerge: Server-side TideGS training with client-side localization; streaming resident blocks to mobile devices for AR overlays.
    • Dependencies: Low-latency streaming; efficient on-device rendering; robust relocalization.
  • Energy- and cost-aware ML systems policy
    • Sectors: policy, sustainability
    • What could emerge: Best-practice standards endorsing out-of-core, single-GPU training where applicable; reporting frameworks capturing SSD/GPU trade-offs.
    • Dependencies: Transparent energy accounting; vendor-agnostic benchmarks; SSD lifetime management.

Cross-Cutting Assumptions and Dependencies

  • Hardware: NVMe SSDs with high sequential throughput (≈3 GB/s), sufficient SSD capacity (hundreds of GBs to TBs), and 24 GB–class GPUs; adequate CPU DRAM for a warm cache (e.g., 16–64 GB).
  • Workload properties: Strong visibility sparsity and temporal locality across camera trajectories; scenes predominantly static; accurate camera poses.
  • Software/runtime: CUDA-enabled rendering and backpropagation; OS/filesystem support for large sequential I/O; tolerance for optimizer-state cold restarts on evicted blocks.
  • Performance trade-offs: Single-GPU training time may be longer than multi-GPU baselines; SSD endurance and compaction policies must be managed for long-running projects.
  • Governance: Large-scale, photorealistic reconstructions may require privacy redaction and data use approvals before deployment or public release.

Glossary

  • 3D Gaussian Splatting (3DGS): A scene representation that models geometry and appearance using many Gaussian primitives optimized for fast, rasterization-based rendering. "3D Gaussian Splatting (3DGS) has emerged as a strong representation for novel view synthesis"
  • Adam moments: The first and second moment estimates maintained by the Adam optimizer for each parameter, used to adapt learning rates during training. "optimizer states (e.g., Adam moments)"
  • anisotropic Gaussians: Gaussian primitives with direction-dependent covariance used to capture oriented, elongated features in 3D. "By representing a scene as a collection of anisotropic Gaussians with learned appearance parameters"
  • Backprojection: The process of projecting depth pixels from images into 3D space to form a point cloud or initialize primitives. "We backproject RGB-D observations from the MatrixCity BigCity/Aerial training split (51{,}623 images) into a colored point cloud"
  • bounding sphere: A spherical bounding volume summarizing the extent of a block of Gaussians for fast visibility tests. "summarize each block with a bounding sphere"
  • block-virtualized geometry: Packing spatially coherent Gaussians into storage-aligned blocks to virtualize parameters and enable efficient out-of-core access. "block-virtualized geometry for SSD-aligned spatial locality"
  • camera-balanced Top-CC policy: A residency selection strategy that allocates VRAM slots across cameras first, then fills remaining slots by global scores. "We therefore use a camera-balanced Top-CC policy"
  • capacity-bounded resident set: The subset of blocks or parameters materialized in VRAM at any iteration, constrained by a fixed memory budget. "TideGS maintains a capacity-bounded resident set Rt\mathcal{R}_t"
  • cold-cache: A measurement condition where previously cached pages are evicted so SSD reads reflect true storage performance. "cold-cache SSD bandwidth measurements"
  • cold restart: Reinitializing optimizer state (e.g., moments) when a block is re-admitted to VRAM after eviction. "(cold restart on re-admission)"
  • densification and pruning: Training-time procedures that add (densify) or remove (prune) primitives to adapt model capacity. "we disable densification and pruning in all settings"
  • D2H transfer: Device-to-host copy from GPU memory to CPU memory, e.g., when evicting blocks from VRAM. "D2H transfer of evicted blocks"
  • dirty blocks: Blocks whose parameters have been updated and need to be written back to persistent storage. "Dirty blocks are flushed to SSD patch segments"
  • embedding-table training: Sparse optimization where only a small subset of parameters (like embeddings) are touched per iteration. "resembles sparse embedding-table training"
  • frustum culling: Discarding objects outside the camera’s view frustum to avoid unnecessary processing. "improving the precision of CPU-side frustum culling"
  • global radix sort: A GPU sorting primitive used in rasterization pipelines, which can become memory-intensive at scale. "the global radix sort and auxiliary buffers exceed available VRAM"
  • H2D transfer: Host-to-device copy from CPU memory to GPU memory, typically to stage blocks for computation. "host-to-device (H2D) stream"
  • hierarchical asynchronous pipeline: An execution design that overlaps SSD I/O, CPU-GPU transfers, and GPU compute across a storage-memory hierarchy. "a hierarchical asynchronous pipeline to overlap I/O with computation"
  • log-structured append-only segments: A storage layout where updates are appended sequentially rather than overwritten in place, improving SSD write throughput. "organizes SSD storage as log-structured append-only segments"
  • LPIPS: A perceptual similarity metric used to evaluate image reconstruction quality. "PSNR, SSIM, and LPIPS"
  • LRU cache: A cache that evicts the least-recently used items first, applied here to manage blocks in CPU memory. "We maintain an LRU cache over blocks together with a per-block dirty bit"
  • Morton sorting: Ordering points by Morton (Z-order) codes to preserve spatial locality in linear storage. "we Morton-sort Gaussians by the codes of their centers before blocking"
  • novel view synthesis: Rendering images from unseen viewpoints of a scene based on learned representations. "novel view synthesis"
  • NVMe SSD: A high-performance solid-state drive interfaced via PCIe, used as the out-of-core backing store. "NVMe SSD (PCIe Gen4~×\times4; measured I/O speed 3.3~GB/s)"
  • OS page caching: The operating system’s mechanism for caching disk pages in DRAM, which can confound I/O measurements. "OS page caching can affect repeated SSD-backed measurements"
  • out-of-core training: Training where the full model state lives outside GPU memory, streaming only needed subsets each iteration. "an out-of-core training framework that manages parameters across an SSD--CPU--GPU hierarchy"
  • patch segments: Append-only files holding updated versions of blocks, referenced via an index for the latest version. "updated blocks are written sequentially into patch segments"
  • PCIe: The interconnect used for transfers between CPU and GPU (and NVMe), a potential throughput and latency bottleneck. "PCIe transfers"
  • PSNR: Peak Signal-to-Noise Ratio, an image fidelity metric for reconstruction quality. "PSNR, SSIM, and LPIPS"
  • rasterization-based rendering pipeline: A graphics pipeline that projects primitives to screen space and rasterizes them for efficient rendering. "an efficient rasterization-based rendering pipeline"
  • rasterization buffers: GPU memory buffers required by the rasterizer, which can dominate VRAM usage at large model sizes. "the bottleneck shifts to VRAM-intensive rasterization buffers at large NN"
  • resident set: The subset of blocks currently materialized in GPU memory for computation. "maintains a capacity-bounded resident set Rt\mathcal{R}_t"
  • RGB-D: Color plus depth images used to reconstruct or initialize 3D geometry. "We backproject RGB-D observations"
  • Set-difference streaming: A policy that keeps resident overlap and transfers only incoming and evicted differences between iterations. "Set-difference streaming."
  • spherical harmonics (SH): A basis for representing view-dependent appearance; 3DGS often uses degree-3 SH coefficients. "degree-3 SH parameterization"
  • spatiotemporal locality: Coherence across space and time (e.g., neighboring views) that enables reuse of data and reduces streaming. "leverages spatiotemporal locality"
  • SSD--CPU--GPU hierarchy: A multi-tier memory/storage stack where the full model resides on SSD, with CPU and GPU acting as caches. "across an SSD--CPU--GPU hierarchy"
  • temporal locality: Reuse of data across nearby time steps (iterations), reducing the need to re-fetch the same blocks. "temporal locality (similar active sets across adjacent iterations)"
  • trajectory-adaptive differential streaming: Streaming only the incremental changes in the working set by exploiting the camera trajectory’s coherence. "trajectory-adaptive differential streaming that transfers only incremental working-set deltas between iterations"
  • TSP-ordered (no-shuffle) camera sequence: Ordering cameras along a traveling-salesman-like path to maximize overlap between successive views. "a clustered TSP-ordered (no-shuffle) camera sequence"
  • visibility-induced sparse updates: The phenomenon that only Gaussians visible from the current views receive gradients, yielding sparse per-iteration access. "Visibility-induced sparse updates."
  • VRAM wall: The scalability limit imposed by GPU memory capacity when all parameters and states must fit in VRAM. "scales beyond the VRAM wall"
  • working-set cache: Treating GPU memory as a cache for only the currently needed parameters rather than storing the entire model. "GPU memory can serve as a working-set cache rather than a persistent parameter store"
  • working-set deltas: The incremental changes in the set of blocks needed between consecutive iterations. "working-set deltas"
  • write-back: A policy where modified data are written to persistent storage upon eviction rather than immediately. "write-back policy"

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Tweets

Sign up for free to view the 6 tweets with 152 likes about this paper.