The LinkedIn Feed retrieval layer selects, within 120 ms, the handful of posts each member sees from hundreds of millions of candidates. This split-second decision shapes what over a billion professionals read and engage with every day. Ideally we would run the full ranking model over the entire corpus, but at the scale of modern recommender systems, that is infeasible, which is why retrieval exists as a distinct, lightweight stage that narrows the corpus before ranking.

At LinkedIn we built a modern GPU Retrieval-as-Ranking engine: instead of a lightweight approximate step, it scores candidates with a full deep learning recommendation model (DLRM) directly at the retrieval stage. Running on GPUs let us scale to O(10⁷) parameters and helped achieve a 2.5% increase in Content Time Spent in online A/B tests.

For Suggested content, where the candidate pool is every post on LinkedIn, a member's affinity to the post's topic was the strongest signal, and LLM embeddings that capture post semantics were a natural fit. However, for in-network content (posts generated by a member's connections), LLMs could not effectively capture the affinity between the viewer and the content creator, an important signal for this use case. Combining the semantic understanding of LLM embeddings with explicit edge features inside a DLRM was key to the success of in-network retrieval.

We will introduce our GPU Retrieval-as-Ranking inference stack and how we scaled it to an index of over one billion documents through a sharded setup. We will dive deep into the design choices behind the serving infrastructure, how edge features are joined to documents at runtime, and the optimizations that let us scale large models in the retrieval stage to production.

Main Takeaways:

1. How a single retrieval model, a DLRM that fuses LLM embeddings (post semantics) with graph edge features (viewer-to-author affinity), captures signals that complement each other at the retrieval layer.
2. Building efficient GPU-powered retrievers capable of running inference on a large volume of documents with DLRMs at strict latency budgets.
3. Keeping the GPU-resident document index fresh and scaling to over 1 billion documents with a maximum staleness target of a couple of minutes.
4. A reusable serving pattern that generalizes beyond LinkedIn scale: when a lightweight retrieval step is bottlenecked by a signal it cannot represent, moving a full model onto GPUs at the retrieval stage can outperform adding another ranking layer.