ZipCCL: Efficient Lossless Data Compression of Communication Collectives for Accelerating LLM Training
Abstract: Communication has emerged as a critical bottleneck in the distributed training of LLMs. While numerous approaches have been proposed to reduce communication overhead, the potential of lossless compression has remained largely underexplored since compression and decompression typically consume larger overheads than the benefits of reduced communication traffic. We observe that the communication data, including activations, gradients and parameters, during training often follows a near-Gaussian distribution, which is a key feature for data compression. Thus, we introduce ZipCCL, a lossless compressed communication library of collectives for LLM training. ZipCCL is equipped with our novel techniques: (1) theoretically grounded exponent coding that exploits the Gaussian distribution of LLM tensors to accelerate compression without expensive online statistics, (2) GPU-optimized compression and decompression kernels that carefully design memory access patterns and pipeline using communication-aware data layout, and (3) adaptive communication strategies that dynamically switch collective operations based on workload patterns and system characteristics. Evaluated on a 64-GPU cluster using both mixture-of-experts and dense transformer models, ZipCCL reduces communication time by up to 1.35$\times$ and achieves end-to-end training speedups of up to 1.18$\times$ without any impact on model quality.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What this paper is about (in simple terms)
Training giant AI LLMs needs lots of computers (GPUs) working together. These GPUs constantly “talk” to each other by sending huge amounts of numbers back and forth. That talking time can slow everything down.
This paper introduces a new software library (called ZipCCL) that “zips” those numbers without losing any information, so the same exact numbers come out on the other side. Because the messages are smaller, GPUs spend less time talking and more time learning, which speeds up training.
What questions the researchers asked
- Can we speed up LLM training by shrinking the data GPUs send each other, without losing any accuracy?
- Is there a clever way to compress these numbers super fast (on GPUs) so that the time spent compressing and decompressing doesn’t cancel out the benefits?
- Can we plug this compression directly into the common “group chat” operations GPUs use (like All-to-All and All-Gather) so it’s easy to adopt?
How they did it (with friendly explanations)
Think of each GPU as a student in a study group. After every step of learning, the students swap notes. If the notes are huge, passing them around takes a long time. ZipCCL works like a super fast, lossless zip tool made just for the kind of notes LLMs use.
Key ideas behind ZipCCL:
- They noticed a pattern in the numbers:
- The numbers sent around during training usually follow a bell curve (near-Gaussian). In the computer format commonly used (BF16), each number has a “size label” (called the exponent) and “fine details” (called the mantissa and sign).
- Most numbers have just a few common “size labels.” That means there’s redundancy we can compress.
- A smart way to compress exactly (lossless):
- Instead of compressing the entire number, ZipCCL keeps the fine details as is, but stores the “size label” using only a few bits if it’s one of the very common labels.
- If a rare “size label” shows up, they mark it and store it separately. This way, every number can be perfectly reconstructed.
- Super fast GPU code:
- They wrote custom GPU kernels that:
- Read and write memory in patterns GPUs like (so it’s fast and efficient).
- Split the compressed data into parts that are always the same size (“static”) and parts that vary (“dynamic”), which helps schedule communication better.
- Use pipelines and fast on-chip memory so compression/decompression happens quickly and doesn’t waste time.
- Smarter group communication:
- Training uses “collectives,” which are like group-chat rules for GPUs:
- All-Gather: everyone shares their piece so all end up with the whole.
- All-to-All: everyone sends specific pieces to everyone else.
- Reduce-Scatter: combine pieces (like summing) and split the result back out.
- ZipCCL adds compression directly inside these group chats, so users can swap it in without changing their training code.
- For All-to-All in Mixture-of-Experts (MoE) models, they send the fixed-size “static” part first so faster GPUs can start earlier, helping hide slowdowns from uneven workloads.
- For Reduce-Scatter, they sometimes replace it with “compressed All-to-All + local summing,” and include an automatic switch to choose the faster option based on the machine and data.
What they found and why it matters
- Faster communication:
- ZipCCL cut communication time by up to 1.35× in tests (meaning the time spent sending data was reduced).
- Faster overall training:
- Even when including all compute and overhead, training got up to about 1.16–1.18× faster on real LLMs and real GPU clusters.
- No quality loss:
- Because the compression is lossless, the model learns just as well as before.
- Better than general-purpose GPU compressors:
- Compared to a popular GPU compression library (DietGPU), ZipCCL was much faster in both raw compression speed and end-to-end training. General tools didn’t fit the unique needs of LLM training and actually slowed things down.
Why this is important:
- Communication is a big bottleneck in modern LLM training. Reducing it speeds up training without risking accuracy.
- Because it’s a “drop-in” replacement for standard communication libraries, teams can get speedups without rewriting their training code.
- Faster training means lower costs and quicker iteration when building and improving large AI models.
How they tested it
- They ran ZipCCL on clusters with up to 64 GPUs.
- They tested on different model types:
- MoE models (like DeepSeek-V3 and Qwen3-MoE), which use heavy All-to-All communication.
- A dense model (Llama3-8B) using FSDP, which relies on All-Gather and Reduce-Scatter.
- Results showed consistent speedups in communication and overall training time.
What this means going forward
- Lossless, distribution-aware compression can make large-scale AI training faster without changing model quality.
- As models grow and run on more GPUs, the communication problem gets worse—so tools like ZipCCL become even more valuable.
- This approach opens the door to smarter, specialized compression for AI workloads, helping researchers train bigger, better models more efficiently.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
Below is a consolidated list of what remains missing, uncertain, or unexplored in the paper, framed to guide follow‑up research.
- Robustness of the “near‑Gaussian” assumption:
- Lack of systematic quantification of exponent distributions across model types (decoder‑only vs. encoder‑decoder), layers (embeddings, attention, MLP), tensor types (activations, gradients, parameters), and training phases (warm‑up, mid, late).
- No analysis for distributions that deviate from Gaussian/log‑normal (e.g., heavy‑tailed, mixture distributions, ReLU/activation sparsity, outlier features), and how these affect coverage of top‑k exponents and net compression ratio.
- Adaptivity over training:
- Unclear how often σ (standard deviation) should be recomputed, how quickly exponent distributions drift, and what the amortized overhead is for tracking σ online.
- No policy for when and how to update the top‑k exponent set over time, or thresholds to trigger updates.
- Consistency of exponent mappings across workers:
- The receiver must know the sender’s top‑7 exponent mapping; the paper does not specify how this mapping is synchronized (e.g., transmitted per‑chunk, per‑layer, or globally) or quantify its overhead.
- If different workers compute different σ for the same layer at the same step (e.g., due to sharding), how is determinism ensured without extra metadata?
- Fail‑safe and fallback behavior:
- No mechanism is specified to detect and automatically disable compression when compressibility is low or negative (e.g., non‑Gaussian tensors), nor to choose k adaptively to avoid expansion.
- No latency/throughput break‑even analysis that yields a runtime decision rule per message size and compression ratio for All‑Gather/All‑to‑All (analogous to the RS switcher).
- Precision and format coverage:
- The method is tuned for BF16; it does not characterize applicability and gains for FP16 (5‑bit exponent), FP32, or FP8 formats (with different exponent/mantissa layouts).
- Many training stacks increasingly use FP8 for activations/gradients on H100/H800; the feasibility and expected gains for FP8 remain untested.
- Mantissa and sign redundancy:
- Only the exponent is compressed; potential additional (lossless) gains from simple mantissa bit‑plane coding, run‑length encoding, or entropy coding are unexplored, including trade‑offs between extra compute and added compression.
- Treatment of zeros and structured sparsity:
- No specialized handling of exact zeros (common from dropout, ReLU, masked tokens) or block sparsity in activations/gradients that could yield higher compression and lower metadata overhead.
- Metadata and collective overheads:
- While size exchange is claimed negligible, the scalability of extra All‑Gather/All‑to‑All metadata (O(world_size) integers per call) is not quantified for large world sizes (hundreds to thousands of GPUs).
- Impact of additional small collectives on startup latency and congestion in tightly scheduled pipelines is not measured.
- Compute–communication overlap and SM contention:
- Compression/decompression runs on the GPU; the paper does not measure contention with training kernels or quantify how much overlap is preserved or lost in realistic overlap schedules.
- No analysis of whether communication‑side kernels starve compute kernels or vice versa under different stream priorities and scheduler policies.
- Memory footprint and fragmentation:
- Extra buffers for sign/mantissa arrays, three 1‑bit exponent planes, zero‑point lists, and prefix‑sum metadata increase peak memory; the paper does not quantify memory overhead or its impact on FSDP headroom and out‑of‑memory rates.
- Error propagation and reliability:
- Bit flips in compressed exponent bitplanes may have larger numerical impact than in uncompressed BF16; no error detection (e.g., CRC) or mitigation strategy is discussed.
- Interaction with GPU ECC and network reliability features is not evaluated.
- Portability and hardware coverage:
- Kernels are optimized for NVIDIA (Ampere) with cp.async; portability to Hopper/Ada (with FP8/TMA), older GPUs lacking cp.async, and to AMD ROCm is not addressed.
- Performance on diverse interconnects (NVLink vs. PCIe vs. IB at higher link rates) and NIC offload features is only partially explored (A6000 200 Gb/s and H800 400 Gb/s).
- Scalability and topology:
- Results are limited to up to 64 GPUs (plus a 16‑GPU H800 run); behavior at hundreds/thousands of GPUs and in hierarchical/heterogeneous topologies (e.g., multi‑rack, multi‑tier) is unknown.
- Interactions with NCCL algorithm choices (ring vs. tree vs. CollNet) and topology‑aware scheduling are not examined.
- All‑Reduce support:
- Although All‑Reduce = Reduce‑Scatter + All‑Gather, a directly “zipped” All‑Reduce path is neither implemented nor evaluated; potential benefits and pitfalls remain unclear.
- Adaptive Reduce‑Scatter switcher:
- The linear cost model lacks a description of how α, β, and compression factor e are profiled and updated at runtime under load variability and congestion.
- No evaluation of per‑layer/per‑iteration switching, stability under noise, or the overhead of frequent re‑decisions; limited evidence that the switcher ever selects the compressed path beneficially.
- MoE imbalance handling:
- The static/dynamic split heuristic is motivated but lacks a formal model for when it helps (as a function of expert skew, world size, and message size), or guidance on how to choose the split point.
- No ablation on sensitivity to gating distributions or varying levels of imbalance.
- Interaction with existing overlap/scheduling systems:
- How zipped collectives interact with pipeline/ZeRO/FSDP schedulers (e.g., gradient bucketization, param prefetching) is unquantified; potential disruptions to carefully tuned overlap are not discussed.
- Workload coverage and realism:
- Evaluation uses micro‑batch size 1 and reduced MoE layer counts (due to memory limits); representativeness for production‑scale runs (larger batches, longer sequences, deeper networks) is not shown.
- Limited model diversity (e.g., vision‑language, speech, encoder‑decoder) and training regimes (pretraining vs. finetuning) leaves generality uncertain.
- Break‑even vs. message size:
- While kernel microbenchmarks are shown, there is no thorough analysis of cutoffs where compression helps/hurts as a function of per‑collective message size and world size.
- Receiver‑side determinism and end‑to‑end correctness:
- Although lossless, the paper does not provide explicit bitwise‑equality verification across devices/architectures or address potential endianness/packing issues in mixed environments.
- Combining with lossy compression:
- Potential hybrid designs (e.g., lossless exponent coding plus low‑bit mantissa quantization for aggressive bandwidth cuts) and their convergence effects are not explored.
- Software availability and integration details:
- Details about API compatibility with NCCL features (group semantics, stream ordering, communicators), as well as open‑source availability and reproducibility, are not provided.
- Inference and checkpointing use cases:
- The approach is motivated by training collectives; applicability to inference serving (e.g., KV cache exchange), optimizer state sharding, or checkpoint/restore paths is not assessed.
Practical Applications
Immediate Applications
Below are concrete, deployable use cases that can leverage the paper’s lossless compressed collectives and GPU-optimized kernels today, along with expected sectors, potential tools/workflows, and feasibility notes.
- Sector: Software/AI Infrastructure (Industry, Academia)
- Use case: Faster LLM pretraining and finetuning on existing NVIDIA GPU clusters by replacing NCCL collectives in Megatron-LM, DeepSpeed, TorchTitan, or PyTorch FSDP with the paper’s NCCL-compatible “zipped” collectives (
zipcclAllGather,zipcclAlltoAll,zipcclReduceScatter). - Tools/products/workflows:
- A drop-in collective library linked into training stacks (Megatron-LM, TorchTitan).
- Enablement flags to toggle compressed collectives per operator (A2A, AG, RS) and per layer.
- Adaptive switcher activated at init to choose decomposed RS (All-to-All + local reduce) vs native RS based on profile.
- Assumptions/dependencies:
- NVIDIA GPUs with CUDA and BF16 training (Ampere+ recommended due to cp.async availability).
- Communication is a bottleneck (e.g., MoE All-to-All, FSDP All-Gather).
- LLM tensors exhibit near-Gaussian/log-normal behavior so exponents are concentrated (observed in practice).
- Stable integration and CI to ensure bit-exactness across large runs.
- Use case: Faster LLM pretraining and finetuning on existing NVIDIA GPU clusters by replacing NCCL collectives in Megatron-LM, DeepSpeed, TorchTitan, or PyTorch FSDP with the paper’s NCCL-compatible “zipped” collectives (
- Sector: Cloud AI Training Services
- Use case: Offer “compressed-collective” training tiers that reduce time-to-train and cost-per-token, particularly for MoE and FSDP-heavy jobs; charge by effective throughput.
- Tools/products/workflows:
- Cluster images with the compressed collective library pre-installed.
- Auto-profiling at job launch to decide where to enable zipped RS and A2A.
- Billing/telemetry reports exposing communication speedups and energy savings per run.
- Assumptions/dependencies:
- Cloud clusters with significant All-to-All or All-Gather traffic.
- Multi-tenant operational readiness (isolation, reliability) for the new collectives.
- Compatibility with job schedulers and containerized environments.
- Sector: Model Labs and Enterprise ML (On-Prem)
- Use case: Shorten iteration cycles for hyperparameter sweeps and ablation studies by accelerating communication-bound stages; improve throughput on commodity 100–200 Gb/s networks.
- Tools/products/workflows:
- Integration into existing training harnesses and launchers.
- Pre-run calibration to record compression ratios over warmup steps.
- Monitoring dashboards that surface compressed vs raw traffic, per-collective timing.
- Assumptions/dependencies:
- Training stacks use BF16 for communication tensors.
- Network links are not already over-provisioned (else gains diminish).
- Sector: MoE Systems (Research and Production)
- Use case: Reduce straggler effects in MoE by exploiting the “static/dynamic” split for zipped All-to-All to overlap early communication among fast experts with late-starting workers.
- Tools/products/workflows:
- MoE extensions that default to the “static-part-first” transfer scheme.
- Per-step gating imbalance metrics to validate overlap benefits.
- Assumptions/dependencies:
- Observable expert-load imbalance.
- Sufficient volume in the “static” portion to meaningfully absorb variance.
- Sector: Distributed Inference Serving (LLM Inference)
- Use case: Reduce cross-GPU All-Gather/Reduce-Scatter latency in tensor-parallel inference (e.g., KV-cache sharding, pipeline/tensor parallelism during serving).
- Tools/products/workflows:
- Integrations with vLLM, TensorRT-LLM, FasterTransformer, custom inference backends using NCCL.
- Toggle compressed collectives for inference-time AG/RS paths.
- Assumptions/dependencies:
- Activations during inference maintain exponent concentration similar to training.
- Decompression overhead doesn’t outweigh savings for small batch/short sequence regimes.
- Sector: Federated/Geo-Distributed Training
- Use case: Lower WAN or inter-DC bandwidth for gradient/state exchange using zipped Reduce-Scatter (decomposed) and All-Gather for layers that remain in BF16 during communication.
- Tools/products/workflows:
- Compression-aware collective endpoints combined with secure channels (TLS/IPsec/IB crypto).
- Cost model deciding compression pre- or post-encryption.
- Assumptions/dependencies:
- BF16 gradients/activations used in the communication path.
- Additional latency from security layers doesn’t negate gains; encryption offload preferable.
- Sector: Sustainability/Operations (Policy within Organizations)
- Use case: Reduce energy-per-training-run and network utilization; include lossless compressed collectives in “Green AI” best practices and procurement guidelines.
- Tools/products/workflows:
- Reporting of energy/CO2 savings tied to communication reduction.
- Internal policies encouraging use of lossless communication compression where applicable.
- Assumptions/dependencies:
- Accurate telemetry for energy and bandwidth.
- Organizational appetite for operational change and validation.
- Sector: Education and Academic Research
- Use case: Teach and study communication-efficient distributed training by providing students and researchers with a working, NCCL-compatible lossless compression baseline plus kernels optimized for GPU memory hierarchies.
- Tools/products/workflows:
- Course labs comparing NCCL vs compressed collectives on small clusters.
- Research prototypes extending the exponent-coding approach.
- Assumptions/dependencies:
- Access to NVIDIA GPUs and standard LLM training stacks.
Long-Term Applications
These opportunities extend or generalize the paper’s ideas and likely require further research, hardware co-design, or broader ecosystem adoption.
- Sector: Hardware/Networking (Semiconductor, Cloud Providers)
- Use case: NIC/DPU/NVLink/NVSwitch offload for exponent-aware lossless compression, reducing GPU SM cycles and PCIe/NVLink traffic.
- Tools/products/workflows:
- Firmware or silicon blocks implementing fast exponent coding/decoding and “static/dynamic” split protocol.
- Driver-level APIs exposing “compressed collectives” natively.
- Assumptions/dependencies:
- Vendor interest and standardization across NCCL/UCX/RDMA stacks.
- Hardware/firmware changes and validation at scale.
- Sector: ML Frameworks and Compilers
- Use case: First-class support for compressed collectives in PyTorch/XLA/JAX, with auto-tuning and per-layer decisions driven by live compression ratios and cluster profiles.
- Tools/products/workflows:
- Compiler passes that insert compressed collectives based on operator graph and tensor statistics.
- Runtime policies that toggle compression for small tensors or latency-sensitive phases.
- Assumptions/dependencies:
- Robust, low-overhead online ratio estimation.
- Consistent behavior across heterogeneous clusters and workloads.
- Sector: Training Algorithms and Formats
- Use case: Generalize lossless exponent compression beyond BF16 to FP16, FP8, bfloat8, and mixed-precision schemes; co-design with quantization or light-weight lossy compression under strict convergence guarantees.
- Tools/products/workflows:
- Extended lookup/encoding tables for new formats.
- Hybrid compression policies (lossless for sensitive tensors, bounded-lossy for others).
- Assumptions/dependencies:
- Availability and stability of next-gen numeric formats in hardware/software.
- Proofs or empirical studies on convergence/accuracy safety.
- Sector: Cross-Vendor and Cross-Stack Support
- Use case: Port to AMD ROCm (RCCL), Intel GPUs, and CPU collectives; standardize “zipped” collective APIs across communication libraries.
- Tools/products/workflows:
- ROCm-compatible kernels exploiting LDS and xGMI interconnects.
- UCX/oneCCL plugins and standard API proposals.
- Assumptions/dependencies:
- Equivalent low-level memory and async copy primitives on non-NVIDIA platforms.
- Vendor buy-in and open standards processes.
- Sector: Distributed Inference at Scale
- Use case: End-to-end compression-aware inference serving for multi-node LLMs with large KV-caches, sequence parallelism, and retrieval-augmented pipelines.
- Tools/products/workflows:
- Compression-aware schedulers that adapt to batch size, sequence length, and cache reuse.
- Integration with sharded KV stores and cross-node cache prefetch/eviction policies.
- Assumptions/dependencies:
- Demonstrated exponent concentration in inference activations at production scales.
- Tuning for latency-critical paths to avoid tail latency regressions.
- Sector: Scientific/HPC Workloads
- Use case: Apply distribution-aware lossless compression to scientific workloads whose intermediates approximate Gaussian/log-normal patterns (e.g., some simulators, signal processing), reducing collective traffic in MPI/NCCL hybrids.
- Tools/products/workflows:
- Profilers to detect exponent distributions and trigger compression in relevant phases.
- HPC libraries offering zipped collectives for FP formats of interest.
- Assumptions/dependencies:
- Target workloads must exhibit exponent concentration similar to LLM tensors.
- Many HPC apps use FP32/FP64 with different distributions; effectiveness must be validated.
- Sector: Privacy/Security
- Use case: Co-design with encryption/compliance frameworks to compress before encrypting (or vice versa) without compromising security; standardize metadata handling for compressed collectives over secure links.
- Tools/products/workflows:
- Compression-in-transit pipelines that integrate with TLS, QUIC, or IB crypto offload.
- Formal verification that metadata exchange doesn’t introduce side channels.
- Assumptions/dependencies:
- Secure channel performance must keep pace; ordering and framing across collectives must be robust.
- Compliance approvals for modified transport behavior.
- Sector: Policy and Governance
- Use case: Establish best-practice guidelines and benchmarks for “communication efficiency” in AI training; include lossless compression as a recognized method to reduce energy and cost.
- Tools/products/workflows:
- Community benchmarks reporting communication intensity and compression gains.
- Procurement requirements encouraging compressed-collective support in AI infrastructure.
- Assumptions/dependencies:
- Consensus across academia/industry consortia.
- Transparent, reproducible measurement methodologies.
- Sector: Systems Research and Scheduling
- Use case: Co-design training schedules and expert placement with compression-aware collectives to maximize “static-part-first” overlap; broader integration with pipeline and tensor parallel schedulers.
- Tools/products/workflows:
- Schedulers that befriend gating/load metrics to initiate early static transfers.
- Topology- and workload-aware partitioners that amplify compression benefits.
- Assumptions/dependencies:
- Predictable load variance and stable gating behavior.
- Accurate online models of communication/compression interplay.
Notes on feasibility across all applications:
- Core dependency: near-Gaussian/log-normal behavior of training tensors and use of BF16 (or compatible formats) to achieve significant exponent concentration; without this, compression ratios and speedups may be smaller.
- Benefit sensitivity: Most pronounced where network is a bottleneck; minimal where interconnect is over-provisioned or tensors are small.
- Hardware scope: Current kernels assume NVIDIA CUDA features (e.g., cp.async); performance and portability to other architectures require engineering effort.
- Correctness: The method is lossless by design, preserving convergence/accuracy, which eases deployment relative to lossy methods but requires thorough validation in production pipelines.
Glossary
- Adaptive switcher: A mechanism that profiles hardware and workload to choose between alternative collective implementations for best performance. "To make an adaptive choice, we introduce an adaptive switcher."
- All-Gather: A collective operation where all processes gather each other's data so every process ends up with the concatenated result. "The AllâGather operation collects distinct data blocks from each process and concatenates them"
- All-Reduce: A collective that reduces values (e.g., sums) across processes and distributes the reduced result back to all of them. "The All-Reduce collective operation is fundamental in distributed deep learning"
- All-to-All: A collective where each process sends distinct data to every other process and receives distinct data from them. "The All-to-All collective enables each process in a group to send distinct data to every other process"
- ANS: Asymmetric Numeral Systems, an entropy coding method used in lossless compression. "entropy coding (e.g., Huffman~\cite{huffman2007method}, ANS~\cite{duda2015use})"
- Asynchronous Copy Engine: A GPU hardware path for non-blocking memory transfers used to overlap data movement and computation. "we utilize the Asynchronous Copy Engine via cp.async instructions"
- Bank conflicts: Performance-degrading events when multiple threads in a warp access the same shared memory bank simultaneously. "accesses to the same bank cause bank conflicts and serialization."
- BFloat16 (BF16): A 16-bit floating-point format with 1 sign bit, 8 exponent bits, and 7 mantissa bits, offering large dynamic range. "the most commonly used floatingâpoint format is BFloat16 (BF16)"
- Bisection bandwidth: The minimum bandwidth needed to partition a network into two equal halves; a measure of network capacity. "on networks with high bisection bandwidth"
- Coalesced memory accesses: Memory operations where adjacent threads access adjacent addresses, maximizing bandwidth efficiency. "which allows the hardware to perform vectorized and coalesced memory accesses and stores"
- Column-major data layout: An arrangement where consecutive elements of a column are contiguous in memory, used here to reduce shared-memory bank conflicts. "we design a columnâmajor data layout"
- Communication collectives: Standardized multi-process communication patterns (e.g., All-Reduce, All-Gather) used for synchronization and data exchange. "Communication collectives~\cite{nccl} are essential primitives"
- cp.async: An NVIDIA GPU instruction for asynchronous copying from global to shared memory, reducing register pressure and latency. "via cp.async instructions"
- Data Parallelism (DP): A training paradigm where model replicas process different data shards and synchronize gradients. "Data Parallelism (DP)~\cite{DBLP:dean2012large}"
- DietGPU: A general-purpose GPU-based lossless compression library used as a baseline. "General-purpose GPU compressors like DietGPU~\cite{dietgpu} and nvCOMP~\cite{NVIDIA_nvcomp_2025}"
- Entropy coding: Compression techniques that encode data based on symbol probabilities to reduce average code length. "By leveraging data redundancy and entropy coding (e.g., Huffman~\cite{huffman2007method}, ANS~\cite{duda2015use})"
- Expert Parallelism (EP): Parallelism strategy tailored for MoE models, distributing experts across devices and routing tokens accordingly. "Expert Parallelism (EP)~\cite{DBLP:Shazeer2017outrageously, hwang2023tutel}"
- Exponent coding: A compression technique that remaps frequently occurring exponents to shorter codes to reduce storage. "We propose a theoretically grounded exponent coding technique (\S\ref{sec:top7})"
- Fully Sharded Data Parallelism (FSDP): A strategy that shards parameters, gradients, and optimizer states across devices to reduce memory usage. "Fully Sharded Data Parallelism (FSDP)~\cite{zhao2023pytorchfsdp}"
- Gating function: The component in MoE models that selects which experts process each token. "based on the gating function's decisions"
- Gaussian distribution: A bell-shaped probability distribution; many training tensors are observed to be near-Gaussian. "follows a nearâGaussian distribution"
- Huffman: A classic variable-length entropy coding algorithm used for lossless compression. "entropy coding (e.g., Huffman~\cite{huffman2007method}, ANS~\cite{duda2015use})"
- Layer Normalization: A normalization technique that stabilizes training and affects tensor distributions. "Driven by the extensive use of Layer Normalization"
- LDG.128: An NVIDIA GPU vectorized load instruction variant used for aligned, wide loads to improve throughput. "using vectorized loads (e.g., \"LDG.128\")"
- Load/Store Units (LSU): GPU pipeline units responsible for memory load/store operations, decoupled from compute for pipelining. "We decouple the Load/Store Units (LSU) from the Arithmetic Logic Unit (ALU)"
- Log-normal distribution: A distribution where the logarithm of the variable is normally distributed; observed for some LLM tensors. "Gaussian or log-normal distributions"
- Megatron-LM: A large-scale LLM training system/framework used as a baseline. "including Megatron-LM~\cite{narayanan2021efficient} and TorchTitan~\cite{liang2025torchtitan}"
- Mixture-of-Experts (MoE): A model architecture that routes inputs to a subset of specialized expert networks. "Mixture-of-Experts (MoE) model"
- NCCL: NVIDIA Collective Communications Library providing high-performance multi-GPU collectives. "We implement \modelname{} as a library of collectives atop NCCL"
- nvCOMP: NVIDIA’s GPU compression library referenced as a baseline. "and nvCOMP~\cite{NVIDIA_nvcomp_2025}"
- Pipeline Parallelism (PP): A strategy that partitions model layers across devices and pipelines microbatches through them. "Pipeline Parallelism (PP)~\cite{narayanan2021efficient}"
- Reduce-Scatter: A collective that reduces data across processes and scatters distinct reduced chunks to each process. "ReduceâScatter performs an elementâwise reduction (e.g., sum) over a tensor distributed across all processes"
- Register File (RF): The set of processor registers; bypassing RF during copies can reduce pressure and stalls. "this approach bypasses the Register File (RF), significantly reducing register pressure"
- Tensor Memory Accelerator (TMA): Hardware support for efficient tensor memory movement; absence is noted in optimization discussion. "even in the absence of a hardware Tensor Memory Accelerator (TMA)"
- Tensor Parallelism (TP): A method that partitions individual weight matrices across devices and synchronizes partial results. "Tensor Parallelism (TP)~\cite{DBLP:dean2012large,narayanan2021efficient}"
- Topology-aware operations: Communication strategies that exploit the physical network topology to optimize performance. "topology-aware operations, optimizing collectives based on specific network hardware properties"
- TorchTitan: An LLM training system/framework used for FSDP experiments and baselines. "and TorchTitan~\cite{liang2025torchtitan}"
- Warp-level prefix sum: An intra-warp scan operation used to compute running totals for indexing and compaction. "computing a warpâlevel prefix sum"
- Zero-point: A marker/code indicating that an exponent falls outside the set of compressed frequent exponents and is stored separately. "an additional ``zeroâpoint'' flag"
Collections
Sign up for free to add this paper to one or more collections.



