Papers for

gpu system developers

Papers whose findings have a practical use for this group, as judged from the abstract. Open a paper to read what it means in practice.

Byzantine fault tolerance improves GPU shared memory reliability

Byzantine-linearizable Single-Writer Multi-Reader Register in the GPU-Inspired Shared Memory Model

Abstract: The construction of fault-tolerant atomic registers is a fundamental problem in distributed computing. GPUs, widely used in scientific computing and machine learning, face Byzantine thread behaviour, while their shared memory lacks access control, allowing any thread to modify shared objects. This raises the question of whether atomic register semantics can be maintained when any thread, including the designated writer, may behave Byzantine. We study this problem in the GPU-inspired shared-memory model of Georgiou et al. and present implementations of a Byzantine-linearizable single-writer multi-reader (SWMR) register. CAReg uses constant memory with a quantifiable probability of invalid reads, while SnapObject maintains a bounded window of authenticated writes, eliminating invalid reads and tolerating up to \(n-1\) Byzantine processes through lock-free and wait-free variants. Our results demonstrate how GPU phase-based, lock-step execution can partially compensate for the absence of access control.

Sat 10 OctDistributed, Parallel, and Cluster Computing
The gist
Shared memory in GPUs can face problems when some threads behave erratically or maliciously, potentially corrupting data. The authors studied how to keep a special kind of memory operation, called an atomic register, reliable even when some threads misbehave. They developed two methods that allow many threads to read and one to write safely, despite faults, using the general way GPUs run threads together. Their work helps make shared memory more trustworthy without extra access controls.
Open → 2610.14543v1

Quantization method preserves VAE-based policy control and speeds execution

LatentQuant: Preserving the Policy-Facing Latent Contract under NVFP4 VAE Quantization

Abstract: Recent world action models (WAMs) reuse pretrained video VAEs whose encoder latents directly condition downstream action policies. Quantization must therefore preserve not only reconstruction fidelity but also the policy-facing latent contract expected by the frozen policy. Direct NVFP4 leaves W4A4 quantization error uncompensated, whereas joint quantization-aware training (QAT) can recover reconstruction by moving this representation. On Wan2.1, joint QAT nearly matches FP32 VBench-7 (0.7403 versus 0.7409), yet LIBERO success collapses from 95.5% to 10.5%. Controlled decoder-only experiments show that activation quantize-dequantize operations alter the reconstruction signal and decoder Jacobian, redirecting the gradient returned to the encoder and inducing persistent latent drift. Based on this mechanism, we introduce LatentQuant, a two-stage NVFP4 QAT framework that first aligns the quantized encoder with its high-precision counterpart, then freezes it while adapting the decoder. Across Wan2.1 and Wan2.2, LatentQuant preserves near-baseline control and high reconstruction quality, achieving 95.75% success on LIBERO and 68.8% on RoboTwin. On NVIDIA B300 GPUs, NVFP4 execution achieves 1.17x-1.26x end-to-end VAE speedups over BF16 cuDNN.

Fri 2 OctArtificial Intelligence
The gist
Video models that help control robots rely on encoded information called latents, which must stay very accurate for the robot's control to work well. The authors found that typical ways of compressing these latents reduce reconstruction quality or cause the robot control to fail. They discovered the main problem is shifts in the latent signals during compression. To fix this, they made a two-step training process called LatentQuant that keeps the latent signals steady and maintains control quality. This method speeds up computation on certain GPUs while keeping robot tasks successful.
Open → 2610.03959v1

Entwine improves GPU tile computation and communication for faster results

Entwine: Coordinating Tiled Computation and Fine-Grained Communication across GPUs

Abstract: Modern high-performance GPU computations partition tensors into tiles to exploit data reuse and parallelism. Individual tile computations complete earlier than the full tensor computation, creating opportunities to overlap computation and communication. However, a mismatch between computation and communication progress can limit these opportunities. Communication stalls when no data is ready, and may lag when data arrives in bursts. Communication can also slow computation by consuming shared resources, offsetting the benefits of overlap. We present Entwine, which coordinates tile computation order, fine-grained communication, and SM resource allocation to minimize overall completion time. Entwine reorders tile computation to produce data for communication at a more regular pace. Entwine couples this schedule with fine-grained SM-based communication to process tile results with low latency and low overhead. Since the communication kernel also consumes SM resources, Entwine coordinates their allocation to balance communication progress against computation slowdown. Across representative tensor-parallel LLM workloads, Entwine achieves a geomean speedup of 1.232x (up to 1.433x) over cuBLAS+NCCL, and outperforms state-of-the-art overlap baselines by 3.1-9.8% in geomean. We will open-source our implementation upon publication.

Thu 10 SeptDistributed, Parallel, and Cluster ComputingHardware Architecture
The gist
Computers use GPUs to handle big mathematical tasks by splitting them into smaller parts called tiles. These tiles finish at different times, which can cause delays when passing data around between GPUs. The paper’s authors designed Entwine to better coordinate when and how these tiles are processed and communicated. By scheduling tile work more smoothly and controlling resource sharing, Entwine speeds up overall computation. Tests show it outperforms current leading methods on big language model tasks.
Open → 2609.11562v1