---
title: Multi-Probe Zero Collision Hash (MPZCH)
url: https://www.emergentmind.com/topics/multi-probe-zero-collision-hash-mpzch
type: topic
---

# Multi-Probe Zero Collision Hash (MPZCH)

Multi-Probe Zero Collision Hash (MPZCH) is a GPU-centered embedding indexing scheme for large-scale recommendation systems that replaces simple modulo hashing with multi-probe linear probing, explicit ID tracking, and eviction-driven slot recycling. In the formulation reported in “Multi-Probe Zero Collision Hash (MPZCH): Mitigating Embedding Collisions and Enhancing Model Freshness in Large-Scale Recommenders” [2602.17050], the method is designed to mitigate embedding collisions and stale embedding inheritance while preserving production-scale throughput and latency. The name combines two technical themes: “multi-probe,” in the sense of configurable repeated slot search, and “zero collision,” in the operational sense that, with reasonable table sizing and sufficiently large probe depth, no pair of distinct IDs is observed to share a slot in the reported deployments and benchmarks [2602.17050].

## 1. Problem formulation and motivation

MPZCH is situated in the standard recommender-system setting in which large, sparse categorical domains such as user IDs, post IDs, owner IDs, and other high-cardinality features are mapped into dense embedding tables. The core resource tension is that the ID space is unbounded and growing, whereas GPU and host memory are bounded and expensive. The common baseline is the hashing trick,
\[
\text{index}(id) = H(id) \bmod N_{\text{table}},
\]
which maps all IDs into a fixed table of \(N_{\text{table}}\) rows [2602.17050].

The central failure mode of modulo hashing is the embedding collision: if \(id_1 \neq id_2\) but \(H(id_1) \bmod N = H(id_2) \bmod N\), the two IDs share both the embedding vector and optimizer state. In the reported experiments with 150M unique user IDs, Sigrid Hash exhibits a collision rate of **36.8%** at table-size parity and **13.6%** even at a capacity ratio of **3.33×** (500M rows for 150M IDs) [2602.17050]. The paper attributes resulting quality degradation to representational conflation and gradient interference.

The second problem is freshness. Standard hash indexing has no notion of obsolescence or expiration: when a new ID lands in a slot previously associated with another ID, it inherits old embedding parameters and optimizer state. The MPZCH paper identifies this stale embedding inheritance as especially harmful for new items and long-tail entities, because a new ID must first “unlearn” unrelated prior state before converging to a useful representation [2602.17050].

This framing distinguishes MPZCH from earlier hashing work that addressed distributional balance or invertibility rather than embedding freshness. Multi-probe consistent hashing studies multiple candidate placements per key to improve peak-to-average node load, achieving a ratio of \(1 + \epsilon\) with \(1 + 1/\epsilon\) lookups per key [1505.00062]. Simple Set Sketching studies multi-location XOR placement and recovery under peeling thresholds in a linear sketching setting [2211.03683]. A plausible implication is that MPZCH inherits the broader systems intuition that repeated probing can convert a single-shot collision-prone mapping into a controllable search process, but its concrete mechanism is open-addressed linear probing with explicit identity state rather than ring selection or XOR decoding.

## 2. Core data structures and lookup semantics

MPZCH converts an embedding table from a pure hash-indexed array into a hash-table-like structure with explicit row ownership. The embedding weights remain standard, but two auxiliary tensors are introduced [2602.17050]:

1. An **identities tensor** \(\mathcal{I}\), with one entry per row, storing either the occupying ID or \(-1\) for an empty slot.
2. A **metadata tensor** \(\mathcal{M}\), typically storing an integer timestamp used by eviction policies such as TTL or LRU.

These tensors are row-wise co-sharded with the embedding table, so row \(i\) of \(\mathcal{I}\) and \(\mathcal{M}\) corresponds exactly to row \(i\) of the embedding weights on a given shard [2602.17050]. This co-location is operationally important because MPZCH updates identity, metadata, embedding reset, and optimizer reset in lockstep when a row is reclaimed.

The probing scheme starts from a base hash \(h = \text{Hash}(id)\), conceptually
\[
h_0(id) = H(id) \bmod N,
\]
and defines a linear probing window of depth \(P = \text{max\_probe}\):
\[
h_k(id) = (h_0(id) + k) \bmod N, \quad k = 0,1,\dots,P-1.
\]
For each incoming ID, MPZCH examines candidate slots in this window, seeking one of three outcomes: an exact match, an empty slot, or an evictable slot [2602.17050].

A decisive design element is the **two-pass probing** procedure. In the first pass, the kernel scans the probe window read-only to determine whether the ID already exists anywhere in the window. In the second pass, it performs mutation: if the ID is found, it refreshes metadata and returns the existing slot; if the ID is absent, it inserts into an empty slot or evicts an older entry according to policy. The paper identifies this two-pass structure as necessary to avoid duplicates and subtle consistency bugs that would arise if an earlier candidate slot were overwritten even though the same ID were already present later in the probe range [2602.17050].

If no matching, empty, or evictable slot is found within the \(P\)-slot search window, MPZCH falls back to the base slot \(h\). This fallback is the only path by which collisions persist in the design. The paper emphasizes that, with suitable capacity and probe depth, this event becomes extremely rare or zero in the reported workloads [2602.17050].

## 3. Probing policy, eviction, and embedding freshness

The principal control parameter in MPZCH is **max\_probe** \(P\). Larger \(P\) increases the probability that a lookup will find an exact match, a free row, or a reclaimable stale row before fallback. In the empirical study, increasing \(P\) sharply reduces the collision rate, while GPU latency remains nearly invariant over the tested range \(P \in [8,512]\) [2602.17050].

Eviction is integrated into the indexing mechanism rather than treated as an external cache-management layer. The paper details two policies [2602.17050]:

- **TTL-based eviction**: metadata stores an expiration time, typically \(t_{\text{now}} + \Delta_{\text{TTL}}\). During insertion, an expired row in the probe window can be reclaimed.
- **LRU-based eviction**: metadata stores last-access time, and the least recently used row in the window can be selected for eviction.

Under TTL, reclamation is lazy: rows are evicted only when a new ID needs space in its probe window. This avoids global sweeps and confines overhead to active lookup paths. The reported deployment uses feature-specific TTLs, including **24 hours** for Post IDs and **72 hours** for Owner IDs in an HSTU-based video retrieval model [2602.17050].

What makes these policies significant for recommender training is not merely reclamation but **reset semantics**. When a new ID is assigned to a reclaimed row, both the embedding weights and the optimizer state are reset. The paper explicitly identifies this reset as the mechanism that prevents stale embedding inheritance and as “the primary driver of the freshness improvements observed in AB testing” [2602.17050]. This distinguishes MPZCH from standard modulo hashing, where unrelated IDs can be aliased onto one row with no lifecycle boundary between them.

A common misconception is to interpret MPZCH purely as a collision-reduction method. The reported design is equally a freshness-management method: obsolete IDs are retired, new IDs acquire clean rows, and the table is dynamically repurposed toward currently active content. This dual role is central to the method’s intended use in highly dynamic item spaces [2602.17050].

## 4. Collision behavior and the meaning of “zero collision”

The “zero collision” claim in MPZCH is empirical and workload-dependent rather than an unconditional analytical guarantee. The paper is explicit that zero collisions means that, for a concrete ID set and configuration \((N_{\text{table}}, P)\), no pair of distinct IDs ends up sharing a slot after probing; it does not claim a universal worst-case bound under arbitrary adversarial sequences [2602.17050].

The reported collision measurements for **150M unique user IDs** illustrate the operating regime in which the method is intended to function:

| Table size / capacity ratio | Configuration | Observed collision rate |
|---|---|---|
| 150M / 1.0× | Sigrid Hash | 36.8% |
| 200M / 1.33× | MPZCH, \(P=256\) | 0.0000% |
| 300M / 2.0× | MPZCH, \(P=64\) | 0.0000% |
| 500M / 3.33× | Sigrid Hash | 13.6% |

The same table in the paper also shows the effect of increasing probe depth at fixed capacity. At **1.0×** capacity, MPZCH reduces collisions from **12.1%** at \(P=8\) to **1.44%** at \(P=512\). At **1.33×** capacity, the rate falls from **3.85%** at \(P=8\) to **0.2875%** at \(P=32\), **0.0299%** at \(P=128\), and **0.0000%** for \(P \ge 256\) [2602.17050].

For production user embeddings, the authors report a deployment with **4B rows** for **3B monthly active users**, corresponding to capacity approximately **1.33×**, together with sufficiently large probe depth, and report zero collisions in production traffic [2602.17050]. This operating point reflects the paper’s general configuration guideline: choose table capacity slightly larger than the expected number of active IDs and choose \(P\) large enough that the probability of a completely unusable local probe window is negligible in practice.

The absence of a closed-form bound is a stated limitation. The paper relies on empirical evaluation rather than a formal collision theorem for arbitrary traffic distributions [2602.17050]. This point is important in interpreting the nomenclature: “zero collision” in MPZCH denotes an observed systems property under tuned sizing, not a proof that collisions are impossible.

## 5. Systems implementation, CUDA execution, and TorchRec integration

MPZCH is implemented as a high-performance CUDA kernel and integrated into TorchRec, specifically with `EmbeddingBagCollection` and `EmbeddingCollection` [2602.17050]. The target deployment model is distributed, row-wise sharded training in which each rank handles its local shard of embedding rows together with the corresponding identity and metadata tensors.

The kernel is designed for batch-parallel execution. Probing for different IDs is independent and therefore well matched to GPU execution. The paper emphasizes several properties of the implementation [2602.17050]:

- **Two-pass in-kernel execution**: first pass is read-only discovery; second pass performs writes.
- **Linear probing over contiguous rows**: this favors cache locality and memory coalescing.
- **Local-only shard operations**: no cross-rank synchronization is required for per-ID probing, insertion, or eviction.
- **Returned per-ID outputs**: each lookup yields a row index and an `evicted` flag, which higher-level TorchRec logic uses to reset weights and optimizer state when necessary.

The reported latency data show that the scheme is viable at production scale. For the MPZCH hash kernel, **HBM / CUDA batched latency** remains at approximately **0.80–0.90 ms** across \(P = 8\) to \(P = 512\). **HBM / CUDA non-batched latency** is approximately **14.5–14.7 ms**. **UVM Managed batched latency** is approximately **4.4 ms**, while **CPU / DRAM non-batched latency** is **94–103 ms** [2602.17050]. The paper therefore characterizes MPZCH as GPU-native: batched GPU execution keeps overhead modest even at high probe depth, whereas non-batched CPU execution is substantially slower.

The memory overhead derives mainly from the auxiliary tensors: roughly one identity scalar and one metadata scalar per embedding row. The paper characterizes this as acceptable relative to typical embedding dimensionalities, especially given the quality gains and the ability to maintain bounded table size via eviction [2602.17050].

Inference-time behavior is deliberately simplified. During publishing, the **identities tensor** is included in the model snapshot, while the **metadata tensor** is omitted because eviction and freshness management are training-only concerns. Inference uses a frozen, read-only mapping with deterministic slot resolution against the published identity tensor [2602.17050]. This separation preserves lookup semantics while confining lifecycle management to training.

## 6. Empirical effects, prior context, and limitations

The reported online and offline outcomes position MPZCH as both an indexing method and a model-quality intervention. In a **Video Late-Stage Ranking** model serving approximately **3B monthly active users**, deployment of MPZCH for user embeddings yielded **Normalized Entropy (NE) improvements on 14 out of 17 tasks**, with the remaining three neutral. Reported gains include **+0.38% NE** for Share, **+0.12% NE** for Video View Duration, **+0.12% NE** for Video View Percentage 100%, and **+0.09% NE** for Skip [2602.17050]. The paper attributes these improvements to the elimination of user collisions and the resulting reduction in representational interference.

For item embeddings in an HSTU-based video retrieval model, the principal effect is freshness. With TTL-managed Post ID and Owner ID tables, the deployment reports **0.83% more impressions for new videos** posted within **48 hours** [2602.17050]. Additional qualitative analyses using t-SNE and similarity metrics show tighter clustering for videos from the same creator and smoother learning trajectories under MPZCH than under standard hash indexing. Table 5 reports intra-creator similarity moving from **0.66% to 0.91%** for same-day evaluation and from **0.62% to 0.77%** overall [2602.17050]. The paper interprets this as evidence that creator-related signals are retained more coherently when new items do not inherit stale embeddings and do not collide with unrelated entities.

Within the broader hashing literature, MPZCH occupies a specific niche. Multi-probe consistent hashing uses multiple key probes to approximate perfectly balanced assignment with \(O(n)\) node storage and \(O(1/\epsilon)\) lookup time [1505.00062]. Simple Set Sketching uses three-way XOR placement and implicit checksums to recover sparse sets under a load threshold near \(0.81\) [2211.03683]. These earlier works establish that repeated probing or multi-location placement can substitute for heavier replication or explicit per-bucket metadata. MPZCH applies a related high-level idea to embedding-table indexing, but its mechanism is not ring-based consistent hashing and not a linear sketch: it is an explicit-ID, open-addressed, eviction-aware hash table specialized for GPU-based embedding systems [2602.17050].

Several limitations are stated directly. Achieving zero collisions requires tuning table capacity and \(P\) to the active-cardinality regime. TTL and LRU policies require feature-specific tuning; overly aggressive TTL induces churn and relearning, while conservative TTL preserves stale rows. Popularity distributions can shift over time, so fixed sizing and static policy choices may become suboptimal. Freshness management occurs during training, whereas inference uses frozen snapshots and therefore depends on sufficiently frequent publishing or sparse delta updates. Finally, the paper does **not** provide analytical guarantees for collision rates under arbitrary distributions and does **not** absolutely rule out collisions for worst-case adversarial ID sequences [2602.17050].

Taken together, these properties define MPZCH as a specialized recommender-systems indexer rather than a universal collision-free hashing theorem. Its contribution lies in showing that explicit identity state, bounded multi-probe linear search, and reset-on-eviction semantics can jointly mitigate two distinct sources of embedding noise—collisions and stale inheritance—while remaining compatible with high-throughput TorchRec training and deployment pipelines [2602.17050].

Source: https://www.emergentmind.com/topics/multi-probe-zero-collision-hash-mpzch