# 深入理解vLLM推理优化：从HuggingFace基线到PagedAttention实战 > 一份详细的学习笔记，通过对比实验深入解析vLLM的推理优化原理，包括KV缓存问题、PagedAttention机制以及OpenAI兼容API服务器的搭建。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-05-29T08:09:16.000Z - 最近活动: 2026-05-29T08:21:48.990Z - 热度: 152.8 - 关键词: vLLM, LLM推理优化, PagedAttention, KV缓存, API服务, HuggingFace, 开源项目, 大语言模型, 推理加速 - 页面链接: https://www.zingnex.cn/forum/thread/vllm-huggingfacepagedattention - Canonical: https://www.zingnex.cn/forum/thread/vllm-huggingfacepagedattention - Markdown 来源: ingested_event --- ## 原作者与来源 - 原作者/维护者：YanfuOu - 来源平台：github - 原始标题：learn-vLLM-inference - 原始链接：https://github.com/YanfuOu/learn-vLLM-inference - 来源发布时间/更新时间：2026-05-29T08:09:16Z ## 原作者与来源\n\n- 原作者/维护者：YanfuOu\n- 来源平台：GitHub\n- 原始标题：learn-vLLM-inference\n- 原始链接：https://github.com/YanfuOu/learn-vLLM-inference\n- 来源发布时间/更新时间：2026-05-29T08:09:16Z\n\n## 引言：为什么需要vLLM？\n\n大语言模型（LLM）的推理性能优化是当前AI工程领域的热点话题。随着模型规模的增长和应用场景的扩展，如何在有限的硬件资源上高效地服务多个并发请求成为了一个关键挑战。\n\n本项目是一份优秀的学习笔记，作者通过实际的对比实验，深入浅出地解释了vLLM推理引擎的核心优化原理。从HuggingFace Transformers基线出发，逐步深入到KV缓存问题、PagedAttention机制，最终搭建OpenAI兼容的API服务器。整个过程清晰易懂，非常适合希望理解LLM推理底层原理的开发者。\n\n## 实验环境设置\n\n作者选择了一个非常接地气的实验环境：一台搭载Ryzen 7 7840HS处理器的笔记本电脑，没有独立GPU。这种选择恰恰证明了vLLM优化的普适性——即使在纯CPU环境下，这些优化技术依然有效。\n\n实验选用的模型是`HuggingFaceTB/SmolLM-135M`，这是一个仅有1.35亿参数的轻量级模型。选择小模型的原因很实际：在资源受限的环境下完成学习实验，同时保持实验的可复现性。\n\n环境搭建使用了Docker容器化方案，拉取vLLM官方提供的CPU专用镜像`vllm/vllm-openai-cpu:latest-x86_64`，确保实验环境的一致性和可移植性。\n\n## 第一部分：HuggingFace Transformers基线\n\n### 基线实验目标\n\n第一步是建立一个性能基线。使用HuggingFace Transformers库直接加载模型，测量单请求推理的性能指标。这个基线代表了传统的LLM推理方式，也是我们后续对比的参照点。\n\n### Tokenizer的作用\n\n实验首先强调了tokenizer的重要性。语言模型不能直接理解原始文本，tokenizer负责将人类可读的文本转换为模型可以处理的数值token。这些token代表词汇表中的词、子词或字符。\n\n理解tokenizer的工作原理对于调试模型输出、控制生成长度、优化提示工程都非常重要。不同的模型使用不同的tokenizer，即使相同的词汇也可能被切分成不同的token序列。\n\n### 基线性能指标\n\n在单请求场景下，基线系统取得了以下性能：\n\n```\ntokens_per_second = 49.62\ntotal_time = 2.0155秒\ngenerated_tokens = 100\n```\n\n关键观察：这是单请求性能，没有批处理。在多用户并发场景下，请求会排队处理，性能会进一步下降。这个基线帮助我们理解传统方法的局限性。\n\n## 第二部分：vLLM推理引擎对比\n\n### vLLM的核心优势\n\n使用相同的模型，切换到vLLM推理引擎后，性能有了明显提升：\n\n```\nTokens/sec: HuggingFace 49.8 vs vLLM 61.3\nTotal time: HuggingFace 1.00s vs vLLM 0.82s\nvLLM提速: 1.2倍\n```\n\n这个提升看似 modest，但背后的优化机制意义重大。vLLM作为专门的高性能LLM服务引擎，相比通用的Transformers库，在以下方面做了深度优化：\n\n- **更高效的KV缓存管理**\n- **PagedAttention内存管理机制**\n- **针对推理场景的专门优化**\n\n这些优化在单请求场景下效果有限，但在高并发服务场景下优势会指数级放大。\n\n## 第三部分：深入理解KV缓存问题\n\n### KV缓存的背景\n\n要理解vLLM的优化，必须先理解KV缓存的作用。在Transformer的自注意力机制中，每个token都会生成Key（K）和Value（V）向量，用于计算注意力权重。\n\n在生成过程中，模型需要反复：\n- 读取所有之前的token\n- 计算注意力\n- 生成一个新token\n- 存储中间状态\n- 重复这个过程\n\n如果每次都要重新计算所有token的K和V，那将极其缓慢。KV缓存的作用就是存储这些中间结果，避免重复计算。\n\n### 预填充与解码阶段\n\nLLM推理分为两个阶段：\n\n**预填充阶段（Prefill）**：模型首先处理整个输入提示，计算初始的K和V张量。这个阶段需要完整的矩阵运算，计算量较大但只执行一次。\n\n**解码阶段（Decode）**：生成回复时，模型从缓存中检索之前所有token的K/V对，只计算新token。这个阶段重复执行，直到生成结束。\n\n### 传统内存分配的浪费问题\n\n这里来到了核心问题。传统系统通常为每个请求预分配最坏情况下的连续内存块。假设最大序列长度为512个token，有5个并发请求：\n\n```\n请求1（短问题）：45/512使用，浪费91.2%\n请求2（中等段落）：128/512使用，浪费75.0%\n请求3（快速问候）：23/512使用，浪费95.5%\n请求4（长文档）：256/512使用，浪费50.0%\n请求5（代码片段）：67/512使用，浪费86.9%\n```\n\n计算一下：总共分配了2560个token槽位，实际只使用了519个，利用率仅20.3%，**浪费高达79.7%**。\n\n### 并发能力的损失\n\n这种浪费直接限制了系统的并发能力。假设有10000个内存槽位：\n\n- 理想情况下（无浪费）：可以服务约97个并发用户\n- 实际情况下（连续分配）：只能服务约19个并发用户\n- **差距：5.1倍**\n\n这正是vLLM的PagedAttention要解决的问题。\n\n## 第四部分：PagedAttention解决方案\n\n### 核心思想\n\nPagedAttention借鉴了操作系统虚拟内存和分页管理的思想。与其为每个请求分配一大块连续内存，不如将KV缓存分割成可复用的小页面（块）。\n\n传统方式：\n```\n[================================] 一大块连续内存\n```\n\nPagedAttention方式：\n```\n[block][block][block][block] 多个独立页面\n```\n\n每个页面存储一部分token的KV缓存。内存可以：\n- 动态分配\n- 复用\n- 高效共享\n- 自然压缩\n\n### 内存效率对比\n\n使用相同的5个请求场景，PagedAttention的表现：\n\n```\n方法 总分配槽位 实际使用 利用率\n------------------------------------------------\n连续分配 2560 519 20.3%\n分页 544 519 95.4%\n\n节省内存：2016个槽位（4.7倍减少）\n```\n\n### 并发能力提升\n\n内存效率的提升直接转化为并发能力的提升：\n\n```\n连续分配：19个并发用户\n分页分配：92个并发用户\n提升：4.8倍更多用户\n```\n\n这就是vLLM能够在相同硬件上服务更多请求的核心原因。PagedAttention不是魔法，而是更聪明的内存管理。\n\n## 第五部分：构建OpenAI兼容API服务器\n\n### 服务器架构设计\n\n最后一部分展示了如何将vLLM部署为HTTP API服务。架构包括：\n\n1. **服务器进程**：使用`vllm.entrypoints.openai.api_server`启动OpenAI兼容的API服务器\n2. **客户端进程**：使用OpenAI Python客户端库与服务器通信\n3. **异步处理**：服务器在后台持续运行，处理来自多个客户端的请求\n\n### 启动服务器\n\n```bash\npython -m vllm.entrypoints.openai.api_server \\ --model HuggingFaceTB/SmolLM-135M \\ --port 8000 \\ --max-model-len 128 \\ --enforce-eager\n```\n\n关键参数说明：\n- `--model`：指定要服务的模型\n- `--port`：API服务器监听的端口\n- `--max-model-len`：最大序列长度限制\n- `--enforce-eager`：禁用CUDA图优化（CPU环境需要）\n\n### 客户端调用\n\n```python\nclient = OpenAI(\n base_url="http://localhost:8000/v1",\n api_key="not-needed"\n)\n\nresponse = client.completions.create(\n model="HuggingFaceTB/SmolLM-135M",\n max_tokens=50,\n temperature=0.7,\n)\n```\n\n这种设计的美妙之处在于兼容性。任何使用OpenAI API的代码，只需修改`base_url`，就可以无缝切换到自托管的vLLM服务。\n\n### 性能实测\n\nAPI服务器的实际表现：\n\n```\n延迟：1.29秒\n提示token：7个\n生成token：50个\n```\n\n考虑到HTTP通信的开销，这个性能表现是合理的。在实际生产环境中，可以通过批处理、异步处理等技术进一步优化。\n\n## 关键洞察与最佳实践\n\n### 1. 优化是有层次的\n\n从基线到vLLM，从单请求到API服务，每个层次都有优化空间。理解底层原理有助于做出正确的架构决策。\n\n### 2. 内存管理是核心瓶颈\n\nLLM推理的性能瓶颈往往不是计算，而是内存。PagedAttention的成功证明了内存优化的重要性。\n\n### 3. 批处理是性能关键\n\n虽然本实验主要关注单请求性能，但在生产环境中，连续批处理（continuous batching）是提升吞吐量的关键技术。vLLM在这方面也有深度优化。\n\n### 4. 兼容性降低迁移成本\n\nOpenAI兼容API的设计大大降低了模型服务的接入门槛。这种标准化对于生态系统的健康发展至关重要。\n\n## 实际应用场景\n\n### 本地开发测试\n\n对于开发者来说，能够在本地笔记本上运行LLM服务非常实用。可以快速原型验证、调试提示词、测试应用逻辑，而无需依赖云服务。\n\n### 边缘部署\n\nvLLM的CPU优化使得在边缘设备上部署LLM成为可能。虽然性能不如GPU，但对于延迟要求不高的场景完全可用。\n\n### 私有数据场景\n\n对于处理敏感数据的应用，本地部署可以避免数据上传到第三方服务，满足合规要求。\n\n## 学习价值与延伸方向\n\n这份学习笔记的最大价值在于它的循序渐进。从基线到优化，从原理到实践，每一步都有清晰的解释和可复现的代码。\n\n对于希望深入学习的读者，可以延伸探索：\n\n- **连续批处理（Continuous Batching）**：进一步提升并发性能\n- **投机解码（Speculative Decoding）**：通过草稿模型加速生成\n- **量化技术**：INT8/INT4量化减少内存占用\n- **张量并行**：多GPU分布式推理\n- **前缀缓存**：共享系统提示的KV缓存\n\n## 结语\n\nvLLM代表了LLM推理优化领域的重要进展。通过PagedAttention等创新技术，它在保持兼容性的同时大幅提升了服务效率。这份学习笔记以清晰易懂的方式揭示了这些技术的原理，是学习LLM工程优化的优质资源。\n\n对于希望构建LLM服务的开发者来说，理解这些底层原理不仅有助于正确使用工具，更能在遇到问题时知道如何调优和排查。毕竟，最好的优化来自于对系统的深入理解。