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
The question for today
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.
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.
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.
Work it through
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.
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.
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.
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 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.
The living notebook
Explore the model
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.
- Hits / requests
- 0 / 16
- Hit rate
- 0%
- Address-stream period
- 16 addresses
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.
Pause & reason
Check your understanding
Your turn
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.
Keep the idea
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.