Overview
The system is implemented end-to-end and evaluated on common GPUs and workloads; gains depend on CPU memory bandwidth and workload shape, and integration into mature stacks (e.g., vLLM) remains future work.
Citations1
Evidence Strength0.80
Confidence0.80
Risk Signals12
Trust Signals
Findings with numeric evidence: 4/4
Findings with evidence refs: 4/4
Results with explicit delta: 3/3
Reproducibility
Status: Partial assets available
Open source: Partial
At A Glance
Cost impact: 80%
Production readiness: 70%
Novelty: 60%
Why It Matters For Business
NEO lets you squeeze more online throughput from existing GPU servers by using the host CPU, lowering per-token serving cost where GPU memory is the bottleneck.
Who Should Care
Summary TLDR
NEO is a systems design that offloads only the decoding attention and corresponding KV cache to the host CPU while keeping model weights on the GPU. It uses asymmetric GPU–CPU pipelining and a load-aware scheduler to balance work across devices, increasing effective GPU batch sizes and overall token throughput without changing model accuracy or average latency. On tested workloads and hardware, NEO improves throughput from modest (≈10–30%) on high-end GPUs to multiple-times on memory-limited GPUs (up to ~7.5× on T4-like cases), with larger CPU memory bandwidth giving larger gains.
Problem Statement
GPUs have limited memory so the KV cache and per-request state restrict batch size and waste GPU compute. Existing offloading either hurts latency or overloads CPUs. How to offload parts of inference to the host CPU to increase GPU batch size and throughput for online (low-latency) serving while keeping latency and accuracy unchanged?
Main Contribution
Design of asymmetric GPU–CPU pipelining: partial offload of decoding attention+KV cache to keep both devices busy.
Load-aware scheduler that dynamically assigns requests per iteration to balance CPU/GPU busy time and maximize throughput.
Key Findings
NEO raises throughput significantly on memory-limited GPUs.
CPU memory bandwidth controls offload benefit more than CPU cores.
Results
| Metric | Value | Baseline | Delta | Split / Dataset | Evidence | Evidence Ref |
|---|---|---|---|---|---|---|
| relative throughput vs GPU-only | up to 7.5× (T4), 26% (A10G), 14% (H100) | GPU-only inference (SwiftLLM / vLLM-like) | up to 7.5× / +26% / +14% | various workloads (AC, OSC, synthetic) | Abstract; §5.4 Figure 9 | §5.4 |
| throughput gain with larger CPU bandwidth | up to 79.3% (A10G, larger g5 instances) | same GPU, smaller CPU bandwidth instances | +79.3% | synthetic / AC workload | §5.5 Figure 10a | §5.5 |
What To Try In 7 Days
Measure if GPU memory limits batch size on your workloads (track KV-cache footprint).
Run a small NEO prototype on one GPU server: enable CPU offload for decoding attention only.
Compare throughput/latency vs current GPU-only stack and try a higher-memory-bandwidth host instance if CPU-bound.
Agent Features
Memory
Frameworks
Optimization Features
Infra Optimization
System Optimization
Inference Optimization
Reproducibility
Risks & Boundaries
Limitations
Benefits depend heavily on host CPU memory bandwidth; low-bandwidth CPUs limit gains.
Scheduler relies on offline profiling; profiling inaccuracies can cause suboptimal scheduling.
When Not To Use
If your GPU has enough memory to achieve large batch sizes and already saturates GPU compute.
When host CPU memory bandwidth is low relative to workload demand.
Failure Modes
CPU becomes the bottleneck (memory bandwidth or compute) and reduces throughput.
Excessive PCIe transfer if offloading policy causes repeated swapping.