REVIEW 3 major objections 5 minor 1 cited by
DeServe: Towards Affordable Offline LLM Inference via Decentralization
T0 review · 3 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash
Pith's one-line read DeServe claims that KV cache offloading plus microbatch scheduling lets decentralized, high-latency GPU fleets serve offline LLM workloads at 6.7x–12.6x the throughput of existing serving baselines.
desk verdict A real optimization idea with a consistent internal gain, but the headline 6.7-12.6x speedup is over-claimed because the vLLM baseline is not controlled. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The load-bearing mechanism is the pairing of a KV-cache offloading scheme with microbatch scheduling. DeServe splits GPU memory into one local page pool per microbatch plus two global page pools ($G_0$ and $G_1$) of size $M_G = W \times T_S$, sized by PCIe bandwidth $W$ and pipeline stage time $T_S$, and overlaps swapping out one microbatch's cache with prefetching another's while computation runs. The available GPU memory per microbatch becomes $M'_B = \frac{M_{KV} - 2M_G}{N_B} + M_G$, so even as the number of microbatches $N_B$ grows, each microbatch keeps a guaranteed memory floor. Microbatch scheduling then injects enough extra microbatches to fill the network-latency bubbles, converting idle time into useful computation.
What would settle it
Run DeServe (opt) and the vLLM pipeline-parallel baseline on identical hardware with the same model and workload at controlled latencies of 16, 32, 64, and 256 ms, using the same latency-simulation mechanism for both systems; if the throughput gap narrows to well below 6.7x when baseline engineering is equalized, the claimed advantage is an artifact of implementation rather than of KV cache offloading and microbatch scheduling.
Extended reading notes
Core claim
The paper argues that in a pipeline-parallel LLM served across machines linked by high-latency networks, throughput collapses for two reasons: each microbatch gets a small slice of GPU memory, capping batch size, and network latency leaves GPUs idle in bubbles between microbatch executions. DeServe's optimization is to swap KV cache between GPU and CPU through two global page pools while a microbatch runs, enlarging each microbatch's effective KV memory, and to add extra microbatches whose execution fills the latency bubbles. In real experiments across us-east-1 and us-west-4 at 58.4 ms latency, the optimized system sustains about 434 output tokens/s, versus 37.3 tokens/s for the vLLM pipeline-parallel baseline, an 11.6x gain; across simulated latencies from 16 to 256 ms, the gains over that baseline range from roughly 6.7x to 12.6x.
Load-bearing premise
The headline gain assumes that DeServe's measured throughput advantage comes from its two optimizations and not from the fact that its own codebase is simply faster than the baseline implementation it is compared against.
Editorial extensions
If this is right
- At 58.4 ms real inter-region latency, DeServe's optimized pipeline keeps output throughput near 434 tokens/s while the unoptimized pipeline falls to 138 tokens/s and the vLLM baseline to 37 tokens/s.
- Raising simulated latency from under 1 ms to 256 ms costs DeServe almost nothing (445.2 down to 442.9 tokens/s), so in the tested regime throughput stops being network-limited.
- Because KV offloading guarantees a per-microbatch memory floor, operators can increase pipeline depth to accommodate longer network delays without halving the batch size of every microbatch.
- At decentralized mining compute prices, a throughput of roughly 108 tokens/s already breaks even against typical Llama-70B inference pricing, and DeServe's optimized numbers exceed that threshold in every latency setting tested.
Reading between the lines
- The bubble-filling scheduling idea is not transformer-specific: any staged computation whose inter-stage transfer is slow relative to stage execution could add extra in-flight units to keep workers busy, so the technique may generalize to geo-distributed batch pipelines.
- The global page pool size is tied to PCIe bandwidth, meaning the effective cache hierarchy becomes GPU memory plus CPU memory; faster interconnects or disaggregated memory would shift the optimal trade-off between offload size and microbatch count.
- A direct comparison against a stronger optimized baseline, such as the same engine implementing chunked prefill or disaggregated serving, would separate the gains attributable to DeServe's two techniques from gains due to overall system engineering.
- The correctness-protection discussion stops short of a working implementation, so the economic story depends on whether optimistic or zero-knowledge arbitration can be made cheap enough to preserve the off-chain throughput advantage.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper presents DeServe, a decentralized offline LLM serving system that combines pipeline parallelism with KV-cache offloading to CPU memory and microbatch scheduling to hide network latency. Using a Llama 3 70B workload on eight GPUs, Table 4 reports output throughput for vLLM baselines from 89.1 tokens/s centrally to 36.1 tokens/s at 64 ms latency, while DeServe with optimizations reaches 434-458 tokens/s across latency settings; the abstract summarizes this as a 6.7x-12.6x improvement in high-latency environments. The paper also develops a cost model based on cloud, decentralized platform, and mining-style GPU prices, and sketches a blockchain-based framework for payment and inference-correctness arbitration.
Significance. If the optimization-specific gains are reproducible, the paper makes a useful contribution: KV-cache offloading with overlapped PCIe transfer and microbatch filling of latency bubbles is a sound and practical idea for decentralized serving, and the cross-region real-world experiment with simulated-latency validation is a strength. The code is released, which aids reproducibility. However, the headline claim is currently overstated because it is measured against a vLLM pipeline-parallelism baseline that DeServe's own unoptimized pipeline already outperforms by a factor of 2.2-3.7x. The incremental contribution of the proposed optimizations over DeServe (pp) is 2.5-3.4x in high-latency settings, which is still meaningful but not the advertised 6.7-12.6x. The paper needs a controlled baseline comparison and a clearer separation of end-to-end gains from optimization-specific gains.
major comments (3)
- [Table 4 and Abstract] The headline 6.7x-12.6x improvement is confounded by baseline implementation differences. In Table 4, DeServe (pp) — the authors' own pipeline without KV offloading or microbatch scheduling — already achieves 194.6 tokens/s centrally versus 89.1 for vLLM (pp), and 133.7 versus 36.1 at 64 ms, a 2.18-3.70x gap. The optimizations described in Section 4 add only 2.29x centrally and 2.51-3.42x at 16-64 ms over DeServe (pp). Therefore roughly half of the advertised ratio is an implementation-level difference (kernel choice, microbatch configuration, engine overhead), not the algorithmic contribution of KV-cache offloading and microbatch scheduling. The abstract and contribution list should either compare against a vLLM baseline configured with comparable kernels and microbatch settings, or the claim should be revised to report the optimization-specific gain separately from the end-to-end system gain.
- [Section 4.3 and Figure 2] The microbatch scheduling algorithm is under-specified. The text gives one illustrative example with network latency equal to half the stage time and says that adding two extra microbatches fills the bubbles, but there is no general rule, pseudocode, or formula for choosing the number of microbatches as a function of network latency, stage time, and available memory. Since microbatch scheduling is one of the two main contributions, the paper needs to state the scheduling policy precisely and explain how it is configured in the experiments. Without this, the results in Table 4 cannot be reproduced or unambiguously attributed to the proposed algorithm.
- [Section 5] Table 4 reports a single throughput number per configuration with no standard deviation, number of runs, or vLLM version and configuration details. The east-west (58.4 ms) and simulated 64 ms columns are close but not identical (434.1 vs 456.8), and without repeated trials it is unclear whether the 6.7-12.6x ratios are stable or whether the simulated-latency validation is within noise. Please report variance and the exact hardware, software, and vLLM configuration used for each baseline.
minor comments (5)
- [Figure 2] The caption for panel (c) reads 'Pipeline Parallelism In Centralized Environment' but the panel illustrates the decentralized setting with added microbatches; this appears to be a typo and should be corrected.
- [Section 5] The sentence 'The vLLM threw out an error during the benchmark' is informal; please describe the error and the vLLM version/config that produced it.
- [Section 4.2] Equation (2) defines MG as the product of PCIe bandwidth W and stage time TS, but no values of W or TS are given for the experimental setup, and no validation is shown that this sizing is sufficient to hide offload latency.
- [Section 3.3] The profit model assumes unified input/output pricing P = PI = PO; this simplification should be stated prominently in the text near Table 2, since different platforms charge different rates for input and output tokens.
- [Section 6] The correctness-protection framework is described at a high level with no implementation or evaluation; if it is intended as a contribution, at least a discussion of overhead or a reference implementation is needed, and otherwise it should be clearly marked as a system sketch.
Circularity Check
No significant circularity: DeServe's throughput and cost claims rest on external benchmarks and market prices, not on fitted parameters or self-citation.
full rationale
The paper's central claims are empirical measurements against an external serving-system baseline (vLLM) under stated latency conditions, and the reported 6.7x-12.6x figures come from Table 4 rather than from any parameter fitted to those same results. The KV-cache offloading memory formula (Equation 1) and the choice MG = W x TS (Equation 2) are design constructions stated from PCIe bandwidth and pipeline stage time, not fitted to the throughput data. The microbatch scheduling argument uses pipeline-bubble reasoning and is validated experimentally. The cost model in Section 3 uses publicly listed prices (GCP, RunPod, io.net, WhatToMine, Together.ai) and computes break-even throughput algebraically from revenue and cost; no claim is derived from the phenomenon it purports to explain. The skeptical concern about baseline fairness — that DeServe's own unoptimized pipeline already outperforms vLLM pipeline parallelism by 2.2x-3.7x, so part of the headline speedup may be an implementation-level gap rather than the proposed optimizations — is a legitimate experimental-validity and attribution concern, but it is not circularity: the comparison remains an external empirical benchmark and does not reduce to a fitted input or to a self-citation chain. Self-citations to prior work (e.g., TerraPipe, AlpaServe) are background references and are not load-bearing for DeServe's throughput or cost claims. No uniqueness theorem, ansatz, or renamed known result is invoked. The derivation chain is therefore self-contained with respect to the paper's own equations and inputs.
Assumptions & free parameters
assumptions (5)
- domain assumption Inter-layer (pipeline) parallelism is preferable to intra-layer (tensor) parallelism in high-latency networks because communication overhead is lower.
- domain assumption KV cache offloading can be overlapped with inference computation using PCIe full-duplex, so it adds no throughput penalty.
- domain assumption Same-region machines with code-injected latency accurately replicate real cross-region network behavior in terms of throughput impact.
- ad hoc to paper Adding microbatches to fill network-latency bubbles does not reduce per-microbatch batch size below a useful bound because KV cache offloading provides a guaranteed memory floor.
- domain assumption The static workload with average prompt and output length of 256 tokens is representative of offline LLM inference workloads.
Cite this review
Pith. "Pith review of DeServe: Towards Affordable Offline LLM Inference via Decentralization." pith.science (2026). https://pith.science/paper/FIRE6HC3
@misc{pith2026250114784,
author = {Pith},
title = {Pith review of: DeServe: Towards Affordable Offline LLM Inference via Decentralization},
year = {2026},
howpublished = {\url{https://pith.science/paper/FIRE6HC3}},
note = {Machine review of arXiv:2501.14784}
}
read the original abstract
The rapid growth of generative AI and its integration into everyday workflows have significantly increased the demand for large language model (LLM) inference services. While proprietary models remain popular, recent advancements in open-source LLMs have positioned them as strong contenders. However, deploying these models is often constrained by the high costs and limited availability of GPU resources. In response, this paper presents the design of a decentralized offline serving system for LLM inference. Utilizing idle GPU resources, our proposed system, DeServe, decentralizes access to LLMs at a lower cost. DeServe specifically addresses key challenges in optimizing serving throughput in high-latency network environments. Experiments demonstrate that DeServe achieves a 6.7x-12.6x improvement in throughput over existing serving system baselines in such conditions.
Figures
Forward citations
Cited by 1 Pith paper
-
Learning Decentralized LLM Collaboration with Multi-Agent Actor Critic
Multi-agent actor-critic methods with a centralized critic improve decentralized LLM collaboration over Monte Carlo baselines in long-horizon and sparse-reward settings.
Reference graph
Works this paper leans on
-
[3]
URL http:// arxiv.org/abs/2406.13511. arXiv:2406.13511. Chiang, W.-L., Zheng, L., Sheng, Y ., Angelopoulos, A. N., Li, T., Li, D., Zhang, H., Zhu, B., Jordan, M., Gonza- lez, J. E., et al. Chatbot arena: An open platform for evaluating llms by human preference. arXiv preprint arXiv:2403.04132,
-
[4]
Google cloud: Cloud computing services
Cloud, G. Google cloud: Cloud computing services. URL https://cloud.google.com/. Accessed: 2024- 10-31. Conway, K., So, C., Yu, X., and Wong, K. opml: Opti- mistic machine learning on blockchain. arXiv preprint arXiv:2401.17555,
arXiv 2024
-
[5]
Dubey, A., Jauhri, A., Pandey, A., Kadian, A., Al-Dahle, A., Letman, A., Mathur, A., Schelten, A., Yang, A., Fan, DeServe: Towards Affordable Offline LLM Inference via Decentralization A., et al. The llama 3 herd of models. arXiv preprint arXiv:2407.21783,
-
[6]
Great internet mersenne prime search
GIMPS. Great internet mersenne prime search. URL https://www.mersenne.org/. Accessed: 2024- 10-31. Graves, A. Generating sequences with recurrent neural networks. arXiv preprint arXiv:1308.0850,
arXiv 2024
-
[7]
ACM. ISBN 9798400705410. doi: 10.1145/3642970. 3655835. URL https://dl.acm.org/doi/10. 1145/3642970.3655835. Hu, C., Huang, H., Xu, L., Chen, X., Xu, J., Chen, S., Feng, H., Wang, C., Wang, S., Bao, Y ., Sun, N., and Shan, Y . Inference without Interference: Disaggregate LLM Inference for Mixed Downstream Workloads, Jan- uary
-
[8]
URL http://arxiv.org/abs/2401. 11181. arXiv:2401.11181. Huang, Y ., Cheng, Y ., Bapna, A., Firat, O., Chen, D., Chen, M., Lee, H., Ngiam, J., Le, Q. V ., Wu, Y ., et al. Gpipe: Efficient training of giant neural networks using pipeline parallelism. Advances in neural information processing systems, 32,
-
[10]
URL http://arxiv.org/abs/ 2407.12391. arXiv:2407.12391. Li, Z., Zhuang, S., Guo, S., Zhuo, D., Zhang, H., Song, D., and Stoica, I. Terapipe: Token-level pipeline parallelism for training large-scale language models. In Interna- tional Conference on Machine Learning , pp. 6543–6552. PMLR,
-
[11]
10 amazing real-world examples of how companies are using chatgpt in 2023,
Marr, B. 10 amazing real-world examples of how companies are using chatgpt in 2023,
work page 2023
Show all 22 references
-
[12]
Mei, Y ., Zhuang, Y ., Miao, X., Yang, J., Jia, Z., and Vinayak, R
URL https://www.forbes.com/ sites/bernardmarr/2023/05/30/ 10-amazing-real-world-examples-of-how-companies-are-using-chatgpt-in-2023 . Mei, Y ., Zhuang, Y ., Miao, X., Yang, J., Jia, Z., and Vinayak, R. Helix: Distributed Serving of Large Lan- guage Models via Max-Flow on Heter...
2023
-
[13]
URL http://arxiv.org/abs/2406. 01566. arXiv:2406.01566. Nakamoto, S. Bitcoin: A peer-to-peer electronic cash sys- tem. Satoshi Nakamoto,
-
[14]
URL http://arxiv.org/abs/2405. 20450. arXiv:2405.20450. OpenAI. Batch - openai api, a. URL https:// platform.openai.com/docs/guides/batch. Accessed: 2024-10-31. OpenAI. Pricing — openai, b. URL https://openai. com/api/pricing/. Accessed: 2024-10-31. Orth, T. What americans thi...
2024 arXiv
-
[15]
Runpod - the cloud built for ai
RunPod. Runpod - the cloud built for ai. URL https: //www.runpod.io/. Accessed: 2024-10-31. Shazeer, N., Cheng, Y ., Parmar, N., Tran, D., Vaswani, A., Koanantakool, P., Hawkins, P., Lee, H., Hong, M., Young, C., et al. Mesh-tensorflow: Deep learning for super- computers. Adva...
2024
-
[17]
arXiv:2403.01876
URL http://arxiv.org/abs/ 2403.01876. arXiv:2403.01876. Sun, H., Li, J., and Zhang, H. zkllm: Zero knowl- edge proofs for large language models. arXiv preprint arXiv:2404.16109,
-
[18]
URL http://arxiv.org/abs/2309. 01172. arXiv:2309.01172. Tang, Z., Kang, X., Yin, Y ., Pan, X., Wang, Y ., He, X., Wang, Q., Zeng, R., Zhao, K., Shi, S., Zhou, A. C., Li, B., He, B., and Chu, X. FusionLLM: A Decentralized LLM Training System on Geo-distributed GPUs with Adaptiv...
-
[19]
org/abs/2410.12707
URL http://arxiv. org/abs/2410.12707. arXiv:2410.12707. WhatToMine. Whattomine. URL https: //whattomine.com/. Accessed: 2024-10-31. Yang, Z., Yang, Y ., Zhao, C., Guo, Q., He, W., and Ji, W. PerLLM: Personalized Inference Scheduling with Edge-Cloud Collaboration for Diverse LL...
2024 arXiv
-
[20]
URL http://arxiv.org/abs/2405. 14636. arXiv:2405.14636. Ye, Z., Chen, L., Lai, R., Zhao, Y ., Zheng, S., Shao, J., Hou, B., Jin, H., Zuo, Y ., Yin, L., Chen, T., and Ceze, L. Accelerating Self-Attentions for LLM Serving with Flash- Infer. URL https://flashinfer.ai/2024/02/ 02/...
2024 arXiv
-
[22]
Agatha: Smart contract for dnn computation
Zheng, Z., Xie, P., Zhang, X., Chen, S., Chen, Y ., Guo, X., Sun, G., Sun, G., and Zhou, L. Agatha: Smart contract for dnn computation. arXiv preprint arXiv:2105.04919, 2021
2021 arXiv
-
[2018]
Megatron-lm: Training multi- billion parameter language models using model paral- lelism
DeServe: Towards Affordable Offline LLM Inference via Decentralization Shoeybi, M., Patwary, M., Puri, R., LeGresley, P., Casper, J., and Catanzaro, B. Megatron-lm: Training multi- billion parameter language models using model paral- lelism. arXiv preprint arXiv:1909.08053,
1909 arXiv
-
[2019]
io.net. io.net. URL https://io.net/. Accessed: 2024- 10-31. Kalodner, H., Goldfeder, S., Chen, X., Weinberg, S. M., and Felten, E. W. Arbitrum: Scalable, private smart contracts. In 27th USENIX Security Symposium (USENIX Security 18), pp. 1353–1370,
2024
-
[2022]
EdgeShard: Effi- cient LLM Inference via Collaborative Edge Computing, May 2024a
Zhang, M., Cao, J., Shen, X., and Cui, Z. EdgeShard: Effi- cient LLM Inference via Collaborative Edge Computing, May 2024a. URL http://arxiv.org/abs/2405. 14371. arXiv:2405.14371. Zhang, Y ., Wang, S., Liu, X., Tan, S., Popa, R. A., and Moallemi, C. C. Proof of sampling: A nas...
-
[2023]
org/abs/2209.01188
URL http://arxiv. org/abs/2209.01188. arXiv:2209.01188. Cheng, K., Hu, W., Wang, Z., Peng, H., Li, J., and Zhang, S. Slice-Level Scheduling for High Throughput and Load Balanced LLM Serving, June
-
[2024]
URL https://www.usenix.org/conference/ osdi24/presentation/agrawal
ISBN 978-1-939133-40-3. URL https://www.usenix.org/conference/ osdi24/presentation/agrawal. Anthropic. Pricing anthropic. URL https://www. anthropic.com/pricing#anthropic-api. Accessed: 2024-10-31. AWS. Amazon web services (aws), a. URL https:// aws.amazon.com/. Accessed: 2024...
2024
Reviewed August 10, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.