MEGA Hub

PLoRA: An NDP-Enhanced Pooled-Memory System for Cost-Efficient Multi-LoRA Serving

Authors

Do you know Zhongkai Yu?You can claim authorship or link another user.Do you know Ohm Rishabh Venkatachalam?You can claim authorship or link another user.Do you know Zheng Wang?You can claim authorship or link another user.Do you know Yikai Li?You can claim authorship or link another user.Do you know Yichen Lin?You can claim authorship or link another user.Do you know Zihao Yu?You can claim authorship or link another user.Do you know Yuke Wang?You can claim authorship or link another user.Do you know Liu Liu?You can claim authorship or link another user.Do you know Xulong Tang?You can claim authorship or link another user.Do you know Shuyi Pei?You can claim authorship or link another user.Do you know Yangwook Kang?You can claim authorship or link another user.Do you know Yufei Ding?You can claim authorship or link another user.

Abstract

Multi-LoRA serving is how one base model becomes thousands of specialized variants, one adapter per user, task, or agent, and the deployments can hold 1000-plus adapters. Serving them is hard because the workload inverts what GPUs provide: terabytes of memory against only tens of TFLOPS, and because every published system stages its adapters from CPU DRAM over PCIe, where each access pays a kernel stop and a host-run copy and capacity ends at the motherboard's DIMM slots. Meanwhile, memory-semantic fabrics such as CXL and NVLink are converging on pooled memory that an accelerator addresses with its own loads and stores, and near-data processing (NDP) can place compute beside the pooled data. How to serve multi-LoRA workloads on such hardware remains unexplored. This paper introduces PLoRA, an NDP-enhanced pooled-memory system for cost-efficient multi-LoRA serving. PLoRA keeps adapters and KV cache in the pool and returns only reduced results over the link, through a read-compute interface the GPU drives with its own loads and stores. Above this architecture, a GPU memory management system picks among four LoRA and two attention execution strategies for each adapter and caches the most performance-critical bytes in GPU memory, guided by a link-parameterized cost model. On one H100 serving 1000 adapters, PLoRA attains the lowest decode latency on every model and workload we measure, averaging 6.6x below a real-machine S-LoRA at under 3.4% added device area. The link itself stops mattering: throughput saturates at 32 GB/s on short contexts, a quarter of CXL 3.1, and the verdict survives scale: per-GPU demand falls from 7B to a modeled 1.2T deployment once adapter traffic shards with the tensor parallelism. The design runs unchanged from CXL-class to NVLink-class fabrics, and surplus bandwidth buys pooled capacity rather than speed.

Community

00