advanced24 min studyLesson 826 in Engineering

Own, cache and update distributed embedding rows explicitly

Separate trainable ID tables from feature-based embedding generation and account for optimizer state.

On this page

What you’ll understand

  • Compute embedding and optimizer-state storage under a declared format.
  • Trace an embedding lookup and sparse gradient back to its owner.
  • Explain how cache and ownership versions affect training or serving semantics.

A trainable embedding table assigns a parameter vector to a node identifier. It differs from an inductive encoder that computes a vector from available features and neighborhoods. A large table can require sharding across machines, with remote lookups and sparse updates for the rows a batch touches. Correctness then depends on ownership, identity and version rules as well as on the neural-network loss.

Parameter tables and generated representations have different costs

For N rows of dimension d stored at b bytes per element, raw embedding payload is Ndb bytes. Optimizers can add full-sized state arrays, and a gradient buffer, master copy or checkpoint staging can increase memory further. Sparse updates mean only touched rows are updated; they do not necessarily mean the entire table or all optimizer state can be omitted from resident or backing storage. State precisely which arrays and data types a capacity estimate includes.

DGL 2.3.1 DistEmbedding exposes trainable sharded embeddings and distributed sparse optimizers. Its documented update path differs from using an ordinary framework optimizer on a local dense parameter table. More generally, a feature-based GNN can also use a learned ID embedding as one input, mixing transductive and inductive behavior. An unseen node may then lack its own trained row even if the rest of the encoder accepts new features. Define initialization and fallback behavior instead of assuming distributed storage creates inductive generalization.

Mtable=Nd (bw+b1+b2)bytesM_{\rm table}=Nd\,(b_w+b_1+b_2)\quad\text{bytes}
This example includes an embedding weight array and two full-shaped optimizer arrays at b_w, b_1 and b_2 bytes per element. It excludes gradients, master copies, metadata, replicas and workspaces; not every optimizer has exactly these states.↔ Scroll wide equations horizontally.

Ownership and sparse updates need a consistency policy

Map each global row to an owner using a versioned partition policy. A worker fetches needed rows, computes contributions and routes sparse gradients to the designated update path. If a row appears several times, combine compatible contributions without losing multiplicity. Concurrent workers can produce updates from different read versions, so the system must choose synchronous, asynchronous or bounded-staleness semantics. The ownership map alone does not make a distributed training step equivalent to a sequential optimizer step.

A read cache can store an immutable serving snapshot cheaply, but caching mutable training parameters can change the algorithm unless invalidation or allowed staleness is explicit. Include model or table epoch, node namespace and row identity in the interpretation of a cached vector. During ownership migration, fence updates so an old owner cannot keep applying writes after a new owner takes over. Checkpoints should capture embedding shards, optimizer state and routing metadata under one documented recovery boundary.

Mremote=r d bwbytesM_{\rm remote}=r\,d\,b_w\quad\text{bytes}
r is the number of distinct remote weight rows actually fetched once in the measured batch. This counts response vector payload only; requests, gradients, metadata, cache validation, retries and optimizer traffic are additional.↔ Scroll wide equations horizontally.

A hit is useful only for the requested version

Measure remote rows, cache hits by accepted version, bytes, update contention and stale-read rejection separately. A high hit rate can be harmful if the cached table epoch is wrong for the model weights. Serving precomputed graph representations has an additional dependency problem: even an unchanged node ID can need a new vector when neighbors or features change. Keep generated-representation freshness distinct from raw parameter-row caching. A rollback restores a compatible table and encoder snapshot rather than mixing whichever shards happen to be newest.

The cache lab isolates capacity-driven reuse without version semantics. Reset and set both C=3 and s=4; predict sixteen initial misses because the four-address cycle exceeds capacity. Separately Reset and set both C=4 and s=4; predict four misses and twelve hits. Requests are (i·s) mod 16 and N=min(4096,16+floor(2t)); Step adds one request until the cap. The toy stores only abstract addresses, so its hits provide no evidence about embedding freshness, optimizer ordering or a distributed owner’s consistency.

Include optimizer arrays before dividing across owners

A table has 100,000 nodes and 64 embedding elements per row. Weights and two full-sized optimizer moment arrays each use four bytes per element. Divide equally across four owners. Exclude gradients, master copies, replicas and metadata, and use decimal MB.

  1. The weight table contains 100,000×64=6,400,000 elements. At four bytes per element it uses 25,600,000 bytes, or 25.6 decimal MB.

  2. Each optimizer array has the same element count and precision, adding another 25.6 MB. Weights plus two arrays total 76.8 MB before every explicitly excluded allocation.

  3. An exactly balanced four-way shard uses 76.8/4=19.2 MB per owner for these arrays. A cache or serving replica would add storage; it does not reduce the authoritative shard’s optimizer obligations automatically.

The result

The declared training arrays require three times the raw weight payload. Sharding divides their ownership under perfect balance, while the actual memory and communication peak still depends on updates, caches and workspaces.

Explore the model

Interactive lab

Interactive lab · cache

Capacity hits do not establish version correctness

Reset → set C=3 and s=4 → predict misses 16, hits 0. Separately Reset → set C=4 and s=4 → predict misses 4, hits 12. The sixteen-address LRU stream starts empty and caps at 4096 requests.

Capacity hits do not establish version correctnessA fully associative LRU cache starts empty and requests address (i·s) mod 16. Hits move an address to the newest position; misses evict the oldest when full. Playback starts with 16 requests and adds two per second, capped at 4096 explicitly simulated requests. This toy stream is not a processor-cache benchmark. Current readings: Hits / requests: 0 / 16; Hit rate: 0%; Address-stream period: 16 addresses. All parameters are adjustable with the labeled controls below.Fully associative LRU cache after 16 deterministic requests: 0 hits and 16 misses.Most recent 16 requestsaddress = i × 3 mod 160M3M6M9M12M15M2M5M8M11M14M1M4M7M10M13MCurrent cache order · oldest → newest471013Latest address 13 · miss: inserted as newestToy address stream · period 16 · starts empty
Cached addressMiss / evictionMost recent request
Hits / requests
0 / 16
Hit rate
0%
Address-stream period
16 addresses
t = 0 s

A fully associative LRU cache starts empty and requests address (i·s) mod 16. Hits move an address to the newest position; misses evict the oldest when full. Playback starts with 16 requests and adds two per second, capped at 4096 explicitly simulated requests. This toy stream is not a processor-cache benchmark. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.

Look forThese abstract addresses have no values, epochs or owners. The lab demonstrates reuse only, leaving embedding consistency and accepted-version validation to the system design.

Check your understanding

What does sparse updating of a distributed embedding table imply?

Try it yourself

A 2,000-row table has dimension 32 and three four-byte arrays as above, divided equally across four owners. Compute array bytes per owner. If a batch fetches 20 distinct remote weight rows, compute their response payload only.

Take a moment to make a prediction or work it out on paper. Open a hint when you need one.

Give me a hint

Count all three arrays for ownership memory, but only weight elements for the separately specified lookup payload.

Compare with the solution

Total array bytes are 2,000×32×12=768,000, so each owner stores 192,000 bytes under perfect balance. One weight row is 32×4=128 bytes; twenty remote rows carry 2,560 response bytes. This lookup count excludes sparse gradients, request headers, validation and any repeated network transfers.

Take it with you

  • Trainable ID tables are different from generated inductive representations.
  • Sparse updates do not eliminate optimizer-state and ownership requirements.
  • Cached vectors require an explicit accepted-version and consistency policy.

Read further

Original sources and deeper explanations to follow at your own pace.

Optional progress, saved in this browser when available. Revisit any lesson at any time.

Lesson not marked complete.