Multi-Probe Zero Collision Hash (MPZCH)

• MPZCH is a GPU-centric embedding indexing scheme that employs configurable multi-probe linear probing to drastically reduce collision rates in recommendation systems.
• It replaces traditional modulo hashing with explicit identity tracking and eviction-driven slot recycling, effectively managing embedding freshness and avoiding stale parameter inheritance.
• Empirical results show zero collisions under tuned configurations, yielding improved model quality and efficient throughput in high-scale TorchRec deployments.

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” (Zhao et al., 19 Feb 2026), 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 (Zhao et al., 19 Feb 2026).

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 (Zhao et al., 19 Feb 2026).

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) (Zhao et al., 19 Feb 2026). 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 (Zhao et al., 19 Feb 2026).

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 (Appleton et al., 2015). Simple Set Sketching studies multi-location XOR placement and recovery under peeling thresholds in a linear sketching setting (Houen et al., 2022). 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 (Zhao et al., 19 Feb 2026):

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 $N_{\text{table}}$0 and $N_{\text{table}}$1 corresponds exactly to row $N_{\text{table}}$2 of the embedding weights on a given shard (Zhao et al., 19 Feb 2026). 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 $N_{\text{table}}$3, conceptually

$N_{\text{table}}$4

and defines a linear probing window of depth $N_{\text{table}}$5: $N_{\text{table}}$6 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 (Zhao et al., 19 Feb 2026).

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 (Zhao et al., 19 Feb 2026).

If no matching, empty, or evictable slot is found within the $N_{\text{table}}$7-slot search window, MPZCH falls back to the base slot $N_{\text{table}}$8. 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 (Zhao et al., 19 Feb 2026).

3. Probing policy, eviction, and embedding freshness

The principal control parameter in MPZCH is max_probe $N_{\text{table}}$9. Larger $id_1 \neq id_2$0 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 $id_1 \neq id_2$1 sharply reduces the collision rate, while GPU latency remains nearly invariant over the tested range $id_1 \neq id_2$2 (Zhao et al., 19 Feb 2026).

Eviction is integrated into the indexing mechanism rather than treated as an external cache-management layer. The paper details two policies (Zhao et al., 19 Feb 2026):

• TTL-based eviction: metadata stores an expiration time, typically $id_1 \neq id_2$3. 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 (Zhao et al., 19 Feb 2026).

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” (Zhao et al., 19 Feb 2026). 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 (Zhao et al., 19 Feb 2026).

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 $id_1 \neq id_2$4, 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 (Zhao et al., 19 Feb 2026).

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, $id_1 \neq id_2$5	0.0000%
300M / 2.0×	MPZCH, $id_1 \neq id_2$6	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 $id_1 \neq id_2$7 to 1.44% at $id_1 \neq id_2$8. At 1.33× capacity, the rate falls from 3.85% at $id_1 \neq id_2$9 to 0.2875% at $H(id_1) \bmod N = H(id_2) \bmod N$0, 0.0299% at $H(id_1) \bmod N = H(id_2) \bmod N$1, and 0.0000% for $H(id_1) \bmod N = H(id_2) \bmod N$2 (Zhao et al., 19 Feb 2026).

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 (Zhao et al., 19 Feb 2026). This operating point reflects the paper’s general configuration guideline: choose table capacity slightly larger than the expected number of active IDs and choose $H(id_1) \bmod N = H(id_2) \bmod N$3 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 (Zhao et al., 19 Feb 2026). 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 (Zhao et al., 19 Feb 2026). 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 (Zhao et al., 19 Feb 2026):

• 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 $H(id_1) \bmod N = H(id_2) \bmod N$4 to $H(id_1) \bmod N = H(id_2) \bmod N$5. 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 (Zhao et al., 19 Feb 2026). 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 (Zhao et al., 19 Feb 2026).

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 (Zhao et al., 19 Feb 2026). 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 (Zhao et al., 19 Feb 2026). 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 (Zhao et al., 19 Feb 2026). 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 (Zhao et al., 19 Feb 2026). 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 $H(id_1) \bmod N = H(id_2) \bmod N$6 node storage and $H(id_1) \bmod N = H(id_2) \bmod N$7 lookup time (Appleton et al., 2015). Simple Set Sketching uses three-way XOR placement and implicit checksums to recover sparse sets under a load threshold near $H(id_1) \bmod N = H(id_2) \bmod N$8 (Houen et al., 2022). 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 (Zhao et al., 19 Feb 2026).

Several limitations are stated directly. Achieving zero collisions requires tuning table capacity and $H(id_1) \bmod N = H(id_2) \bmod N$9 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 (Zhao et al., 19 Feb 2026).

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 (Zhao et al., 19 Feb 2026).