# LLM 推理系统深度研究：从 KV 缓存到生产级基准测试

> 一个面向 ML 基础设施面试的研究级仓库，系统化地探索 LLM 服务中的 KV 缓存行为、调度策略和性能基准测试方法论。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-06-07T19:44:56.000Z
- 最近活动: 2026-06-07T19:52:49.759Z
- 热度: 141.9
- 关键词: LLM推理, KV缓存, 基准测试, 模型服务, 调度策略, 延迟优化, vLLM, Modal
- 页面链接: https://www.zingnex.cn/forum/thread/llm-kv-18423ea1
- Canonical: https://www.zingnex.cn/forum/thread/llm-kv-18423ea1
- Markdown 来源: ingested_event

---

## 原作者与来源

- 原作者/维护者：devinnicholson
- 来源平台：github
- 原始标题：llm-inference-benchmark
- 原始链接：https://github.com/devinnicholson/llm-inference-benchmark
- 来源发布时间/更新时间：2026-06-07T19:44:56Z

## 原作者与来源\n\n- **原作者/维护者**: devinnicholson\n- **来源平台**: GitHub\n- **原始标题**: llm-inference-benchmark\n- **原始链接**: https://github.com/devinnicholson/llm-inference-benchmark\n- **发布时间**: 2026-06-07\n\n## 项目定位与目标\n\n这是一个研究级的学习仓库，源自 568 Systems and Machine Learning 课程。项目的核心目标是构建一个能够在 ML 基础设施面试中"存活"的推理系统工件——包含清晰的工作负载定义、请求生命周期追踪、基准测试方法论、调度器实验、KV 缓存压力研究，以及与真实推理引擎的后端对比。\n\n与许多仅关注最终指标的基准测试工具不同，这个项目强调**理解测量模型本身**——在接入 PyTorch、vLLM、SGLang、TensorRT-LLM 或真实 GPU 之前，先通过简化的模拟器让测量模型变得明确。\n\n## 核心概念与术语\n\n项目建立了一套完整的推理系统词汇表，这是理解和优化 LLM 服务的基础：\n\n### 延迟指标\n\n- **TTFT (Time To First Token)**: 从请求到达到第一个输出令牌生成的时间\n- **TPOT (Time Per Output Token)**: 每个输出令牌的平均生成时间\n- **p95/p99 延迟**: 尾延迟指标，反映最坏情况下的用户体验\n- **端到端延迟**: 完整请求的处理时间\n\n### KV 缓存相关\n\n- **KV-cache footprint**: 每个请求在 KV 缓存中的内存占用估计\n- **Active KV-cache timeline**: 活跃 KV 缓存的时间线指标\n- **Memory pressure**: 内存压力，当 KV 缓存接近容量限制时的状态\n\n### 调度与批处理\n\n- **FIFO (First In First Out)**: 先进先出调度策略\n- **Shortest-cache**: 优先处理 KV 缓存占用小的请求\n- **Memory-aware-deadline**: 考虑内存限制和截止时间的调度策略\n\n## Week 1 工件：请求生命周期模拟器\n\n项目的第一阶段提供了一个有意简化的模拟器，其核心组件包括：\n\n### 工作负载模式定义\n\n```json\n{\n  \"requests\": [\n    {\n      \"prompt_tokens\": 128,\n      \"output_tokens\": 256,\n      \"arrival_time_ms\": 0\n    }\n  ],\n  \"pattern\": \"mixed_bursty\"\n}\n```\n\n工作负载定义包含输入/输出令牌数、到达时间等关键参数，支持生成确定性的突发工作负载。\n\n### 请求生命周期追踪\n\n模拟器将每个请求的生命周期分解为明确的阶段：\n\n1. **队列等待 (Queueing)**: 请求到达后等待处理的时间\n2. **分词 (Tokenization)**: 将输入文本转换为令牌\n3. **预填充 (Prefill)**: 处理输入提示并生成第一个 KV 缓存状态\n4. **解码 (Decode)**: 自回归生成输出令牌\n5. **流式传输 (Streaming)**: 将生成的令牌返回给客户端\n\n每个阶段都生成详细的追踪数据，便于后续分析和优化。\n\n### 运行示例\n\n```bash\n# 运行基础工作负载\npython3 scripts/replay_workload.py workloads/week01_mixed_requests.json \\\n  --model-config configs/models/llama-7b-gqa-fp16.json\n\n# 生成突发工作负载\npython3 scripts/generate_workload.py mixed_bursty \\\n  --requests 32 \\\n  --seed 568 \\\n  --output workloads/generated/mixed_bursty_32_seed568.json\n\n# 对比不同调度策略\npython3 scripts/replay_workload.py workloads/generated/mixed_bursty_32_seed568.json \\\n  --model-config configs/models/llama-7b-gqa-fp16.json \\\n  --max-concurrent-requests 4 \\\n  --scheduler-policy fifo\n\npython3 scripts/replay_workload.py workloads/generated/mixed_bursty_32_seed568.json \\\n  --model-config configs/models/llama-7b-gqa-fp16.json \\\n  --max-concurrent-requests 4 \\\n  --scheduler-policy shortest-cache\n```\n\n## 容量感知调度实验\n\n项目包含一个完整的容量扫描实验（experiment-001-capacity-sweep），探索在不同 KV 缓存容量限制下的系统行为：\n\n```bash\n# 运行容量扫描\npython3 scripts/run_sweep.py\n\n# 在受限 KV 缓存预算下运行\npython3 scripts/replay_workload.py workloads/generated/mixed_bursty_32_seed568.json \\\n  --model-config configs/models/llama-7b-gqa-fp16.json \\\n  --capacity-config configs/capacity/tight-1gb-kv.json \\\n  --max-concurrent-requests 4 \\\n  --scheduler-policy memory-aware-deadline\n```\n\n实验结果输出到 `results/experiment-001-capacity-sweep/`，包含 JSON 和 CSV 格式，便于进一步分析和可视化。\n\n## Modal 云端执行路径\n\n项目还集成了 Modal 平台，支持在云端 GPU 上运行实验：\n\n```bash\n# 基础 GPU 探测\nmodal run modal_app.py --mode gpu-probe\n\n# vLLM 推理基线\nmodal run modal_app.py --mode vllm-inference\n\n# vLLM 流式传输测试\nmodal run modal_app.py --mode vllm-streaming\n\n# 并发工作负载测试\nmodal run modal_app.py --mode vllm-concurrent\n\n# 并发/上下文扫描\nmodal run modal_app.py --mode vllm-sweep\n```\n\n这种混合本地-云端的架构让研究者可以在本地快速迭代，然后在真实 GPU 上验证结果。\n\n## 面试叙事：你能回答这些问题吗？\n\n项目文档强调，这个仓库应该能帮助你回答以下类型的面试问题：\n\n1. **请求从入口到最终令牌经历了什么？**\n   - 答案应涵盖队列、分词、预填充、解码、流式传输各阶段\n\n2. **你在优化哪个延迟指标：TTFT、TPOT、p95、p99 还是吞吐量？**\n   - 不同场景有不同的优化目标，需要权衡取舍\n\n3. **提示长度、输出长度和到达突发性如何改变队列行为？**\n   - 长提示增加预填充时间，长输出增加解码时间，突发性导致队列堆积\n\n4. **基准测试披露了什么信息，让别人可以复现？**\n   - 模型配置、工作负载定义、调度策略、容量限制等\n\n5. **微基准测试结果在端到端中出现在哪里，或在哪里消失了？**\n   - 理解测量与真实性能之间的关系\n\n## 研究焦点：KV 缓存行为\n\n项目文档明确将 KV 缓存行为作为核心研究焦点，这与当前 LLM 推理优化的前沿方向一致。KV 缓存是 Transformer 模型推理中的关键优化点，因为它避免了重复计算已处理的令牌。\n\n然而，KV 缓存也带来了挑战：\n- **内存占用**: 随着批次大小和序列长度增长，KV 缓存可能占用大量 GPU 内存\n- **碎片化**: 不同长度的序列导致内存碎片化\n- **驱逐策略**: 当缓存满时，需要决定哪些 KV 缓存可以丢弃\n\n项目的容量感知调度实验正是针对这些挑战的系统性探索。\n\n## 技术架构与代码组织\n\n```\nllm-inference-benchmark/\n├── configs/           # 模型和容量配置\n├── docs/             # 详细文档\n├── results/          # 实验结果\n├── scripts/          # 可执行脚本\n├── src/llmbench/     # 核心库代码\n├── tests/            # 单元测试\n├── workloads/        # 工作负载定义\n├── modal_app.py      # Modal 云端入口\n└── pyproject.toml    # 项目配置\n```\n\n这种清晰的组织方式反映了良好的软件工程实践，也让新贡献者能够快速上手。\n\n## 当前状态与路线图\n\n项目目前处于 Week 1 阶段，模拟器有意保持简单。这种渐进式的方法确保了在增加复杂性之前，基础概念已经牢固建立。\n\n未来的发展方向包括：\n- 集成真实推理后端（vLLM、SGLang、TensorRT-LLM）\n- Triton 内核优化\n- 分布式推理和放置策略\n- 基于追踪的工作负载真实感\n\n## 总结\n\n这个仓库代表了 ML 系统教育的一个优秀范例——它不仅教授概念，还提供了动手实验的完整环境。对于希望深入理解 LLM 推理系统的工程师和研究者来说，这是一个宝贵的资源。\n\n通过从模拟器开始，项目让学习者能够在没有昂贵 GPU 的情况下理解核心概念，然后逐步过渡到真实世界的复杂性。这种"从简单到复杂"的教学方法，加上对测量模型本身的关注，使其成为一个真正研究级的学习工具。