💻 computer science

BlitzGS: City-Scale Gaussian Splatting at Lightning Speed

BlitzGS is a distributed 3D Gaussian Splatting framework that achieves lightning-fast, city-scale reconstruction by reducing active Gaussian workloads through index-parity-based system sharding, scheduled importance-scoring model pruning, and view-level LOD culling, thereby delivering an order-of-magnitude speedup over existing baselines while maintaining rendering quality.

Original authors: Zhongtao Wang, Huishan Au, Yilong Li, Mai Su, Haojie Jin, Yisong Chen, Meng Gai, Fei Zhu, Guoping Wang

Published 2026-05-14

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Zhongtao Wang, Huishan Au, Yilong Li, Mai Su, Haojie Jin, Yisong Chen, Meng Gai, Fei Zhu, Guoping Wang

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are trying to build a massive, hyper-realistic 3D model of an entire city using thousands of photos. In the world of computer graphics, this is done using millions of tiny, floating "clouds" (called Gaussians) that act like pixels in 3D space.

The problem with existing methods is like trying to paint a city mural by hiring a team of artists who are all told to paint every single brick on every single building for every single photo, even if that brick is hidden behind a wall or too far away to see. It's a massive waste of time and energy. The artists (the computer's graphics cards) get exhausted, and the process takes hours or even days.

BlitzGS is a new system that solves this by acting like a super-efficient city planner. Instead of making everyone paint everything, it uses three clever tricks to ensure the artists only paint what matters, right now.

Here is how it works, broken down into simple analogies:

1. The System Level: The "Zip Code" vs. The "Street Address"

The Old Way (Spatial Partitioning): Imagine dividing the city into four distinct neighborhoods (North, South, East, West) and giving one artist team to each. If a camera takes a photo that straddles the border between North and South, both teams have to stop, talk to each other, and figure out who paints the overlapping buildings. This causes traffic jams and wasted time.

The BlitzGS Way (Index Parity Sharding): Instead of dividing the city by location, BlitzGS divides the list of buildings by a simple rule: "If the building number is even, Team A paints it; if it's odd, Team B paints it."

The Result: Every team has a perfectly balanced mix of buildings from all over the city. When a photo is taken, the teams don't need to argue over borders. They just swap the specific buildings needed for that specific photo in one quick, organized exchange. It's like a perfectly choreographed dance where everyone knows their exact role without stepping on each other's toes.

2. The Model Level: The "Talent Scout"

The Problem: As the computer tries to learn the city, it keeps adding more and more "clouds" (Gaussians) to make the picture sharper. Eventually, it creates millions of redundant clouds—tiny, invisible duplicates that don't actually help the picture look better. They just clutter the workspace.

The BlitzGS Solution: BlitzGS hires a "Talent Scout" that periodically walks through the entire city model.

The Audit: The scout checks every single cloud to see: "Did you actually help paint a pixel in a photo? How much did you contribute?"
The Cut: Clouds that were just "hanging out" or were too blurry to matter get fired (pruned).
The Bonus: The scout also creates a "Reputation Score" for the remaining clouds. If a cloud is consistently helpful, the system tells the training process: "Focus your energy on making this cloud better, not on creating new ones."
The Result: The city model shrinks to its most essential, high-quality parts, making the whole process much lighter.

3. The View Level: The "Zoom Lens" and the "Reputation List"

The Problem: When you look at a city from a drone high in the sky, you don't need to see the tiny cracks in a brick on a building 10 miles away. Rendering those tiny details is a waste of computer power.

The BlitzGS Solution:

The Zoom Lens (LOD Gate): The system checks how far the camera is. If the camera is far away, it automatically hides the tiny, high-detail clouds and only shows the big, coarse ones. It's like switching from a high-definition microscope to a wide-angle lens instantly.
The Reputation List (Importance Mask): Using the data from the "Talent Scout," the system also knows which clouds are useless for this specific camera angle. If a cloud is hidden behind a building or contributes nothing to the current view, it is skipped entirely.

The Grand Result

By combining these three levels, BlitzGS turns a process that used to take hours (like 4 to 8 hours) into a process that takes tens of minutes (around 30 to 40 minutes).

Quality: It produces images just as sharp and detailed as the slow, old methods.
Speed: It is roughly 10 times faster.

In short, BlitzGS doesn't just make the artists work faster; it stops them from doing useless work in the first place. It ensures that every single calculation the computer makes is actually helping to build the picture, allowing us to create digital twins of entire cities at "lightning speed."

Technical Summary: BlitzGS: City-Scale Gaussian Splatting at Lightning Speed

Problem Statement

City-scale 3D reconstruction is critical for applications such as digital twins, aerial mapping, and simulation. However, scaling 3D Gaussian Splatting (3DGS) to city-level scenes remains computationally prohibitive. While existing methods utilize multi-GPU setups, they suffer from significant inefficiencies:

Redundant Workload: In any single training iteration, only a small fraction of the millions of Gaussians contribute meaningfully to the rendered loss. The majority incur redundant costs in storage, communication, and rasterization without aiding convergence.
Inefficient Partitioning: Spatial block partitioning, a common strategy, leads to cross-block visibility redundancy (where GPUs must process primitives outside their immediate region due to camera overlap) and imbalanced shard loads.
Slow Training: Despite advances in distributed training and hierarchical rendering, city-scale optimization typically requires several hours, creating a bottleneck where training speed often trades off against scene quality.

The core observation driving this work is that fast city-scale reconstruction requires minimizing the number of Gaussians entering the rendering pipeline at every stage: globally (removing redundant clones), locally (activating only useful scales per view), and systemically (balancing load without spatial waste).

Methodology

BlitzGS is a distributed 3DGS framework that reduces active Gaussian workload through three coupled levels of optimization:

1. System Level: Non-Spatial Primitive Sharding

Instead of partitioning the scene into spatial blocks, BlitzGS shards the global Gaussian model across $M$ GPUs based on index parity.

Mechanism: Each GPU holds a balanced, non-contiguous slice of the global Gaussian set (approximately $|G|/M$ primitives).
Distributed Rendering: During each render step, every GPU projects its local Gaussians. A single all-to-all exchange routes projected Gaussians to the GPUs owning the specific image tiles they land on.
Benefit: This eliminates the "boundary waste" inherent in spatial partitioning, where cameras straddling block boundaries force redundant processing. Both storage and per-step compute scale linearly with the GPU count.

2. Model Level: Scheduled Importance Scoring and Simplification

BlitzGS performs permanent population reduction by identifying and removing primitives that do not contribute meaningfully to the final view quality.

Importance Scoring: Scheduled passes (interleaved with training) sweep through all views using an instrumented rasterizer. For each Gaussian, it calculates a contribution density score ( $s_i$ ) based on the alpha-weighted contribution per pixel across all views, normalized by the projected area.
Pruning: Two passes are used:
1. Stochastic Sampling: Early in training, a fraction of the population is removed via importance-weighted sampling.
2. Deterministic Cut: Later in training, the lowest-scoring tail is pruned to reach a target population size.
Feedback Loops: The scoring pass generates two additional signals:
- Visibility Ratio ( $\phi_i$ ): Reweights density-control gradients (cloning/splitting) to favor primitives that consistently contribute across views, preventing the model from wasting capacity on redundant clones.
- Per-View Redundancy Mask: A bit-packed matrix indicating which Gaussians fall below the top 99% contribution mass for specific cameras, used to filter views.

3. View Level: Active Set Filtering

Before rendering, the active set for each camera is trimmed using two complementary mechanisms:

Distance-Based LOD Gate: Gaussians are assigned Level-of-Detail (LOD) labels inherited from the initial SfM voxelization. The renderer excludes Gaussians that are too fine (high LOD) for the current camera distance, preventing sub-pixel primitives from incurring rasterization costs.
Importance-Based Culling: The per-view redundancy mask generated in the model level is applied to skip Gaussians that have negligible cross-view contribution for the specific camera, further reducing the active set.

Key Contributions

Workload-Centric Insight: The paper proposes a unifying view of city-scale 3DGS acceleration, arguing that every component should be designed to ensure operations touch only the Gaussians that matter for the specific device, view, and training stage.
Three-Level Framework: A novel distributed framework that integrates:
- System-level index-parity sharding for balanced, non-spatial distribution.
- Model-level simplification that feeds back into density control to guide future growth.
- View-level filtering via LOD gates and importance masks.
Performance: The method achieves order-of-magnitude speedups in training time while maintaining rendering quality comparable to state-of-the-art baselines.

Experimental Results

The authors evaluated BlitzGS on standard large-scale aerial benchmarks (Mill-19, UrbanScene3D, MatrixCity) using 4 NVIDIA A6000 GPUs.

Training Speed: BlitzGS reduces training time from hours to tens of minutes. For example, on the Building scene, it achieves competitive PSNR (~23 dB) in 36 minutes, whereas baselines like CityGS-X and Momentum-GS require 4–6 hours to reach similar or lower plateaus.
Quality: BlitzGS matches or exceeds the PSNR, SSIM, and LPIPS scores of recent baselines (VastGaussian, CityGaussianV1/V2, HUG, CityGS-X) across real and synthetic datasets.
Scalability: Multi-GPU scaling tests (up to 8 GPUs) show near-linear speedup (3.5–3.6× at 8 GPUs) with stable PSNR, independent of the number of input images.
Ablation: Removing the importance scoring pass nearly doubles the Gaussian population and increases training time by ~30%, confirming the necessity of model-level simplification. The LOD gate and per-view masks provide additional, though slightly smaller, efficiency gains.

Significance and Claims

The paper claims that BlitzGS addresses the fundamental bottleneck of city-scale 3DGS: the wasted computational effort on non-contributing primitives. By shifting the focus from merely distributing the workload to actively reducing the active workload at the system, model, and view levels, BlitzGS enables city-scale reconstruction in minutes rather than hours.

The authors position this as a significant step toward practical deployment of 3DGS in time-sensitive applications like aerial surveying and digital twin creation. They acknowledge limitations, including the use of hard LOD masks (which can cause popping artifacts) and the assumption that the global Gaussian set fits within the aggregate memory of the available GPUs, noting that extremely large scenes exceeding this capacity may still require partition-based approaches.