1. 为什么本地推理服务需要高吞吐引擎大模型本地部署这件事前两年大家关注的重点还是“能不能跑起来”——把权重下载下来装好依赖能对着命令行吐出一段通顺的话就算成功。但到了今年情况明显变了。越来越多的团队和个人开发者开始把本地模型接入到实际业务流里客服自动回复、文档批量摘要、代码补全、知识库问答甚至是一些需要持续跑批的离线任务。这时候“能跑”和“跑得好”之间的差距就暴露出来了。我最早用原生推理框架搭服务的时候单条请求响应还算能接受但只要并发一上来显存占用直接飙满吞吐量断崖式下跌延迟从几百毫秒涨到十几秒。后来换成带动态批处理能力的推理引擎同样的硬件吞吐量翻了六七倍显存反而更稳了。这个差距的核心就在于推理引擎有没有真正解决高并发场景下的显存管理和请求调度问题。vLLM 这个引擎之所以在本地部署圈子里被反复提起就是因为它把两个关键问题处理得比较到位一是用PagedAttention把 KV Cache 的显存碎片问题压下去二是用连续批处理让不同长度的请求能动态拼批不用等最长的那个请求结束才释放资源。这两点听起来是工程细节但实际效果非常直观——同样的显卡能同时服务的请求数上去了单位 token 的成本下来了。这篇文章面向的是已经有一定本地部署经验、想把推理服务从“玩具”升级到“能扛并发”的开发者。我会从整体设计思路讲起把核心机制拆开再给出一套可以直接复现的部署流程最后把我踩过的坑和排查经验整理出来。如果你现在正被并发上不去、显存爆掉、延迟抖动这些问题困扰下面的内容应该能帮你省不少时间。2. 推理引擎整体设计与核心思路拆解2.1 从“单请求独占”到“批处理共享”的思维转变传统推理框架的默认行为是一个请求进来分配一块显存把 KV Cache 按最大可能长度预留好等这个请求完全结束再释放。这种模式在单用户场景下没问题但一旦并发上来问题就很明显——每个请求都按最大长度占坑实际用到的可能只有十分之一剩下的全是浪费。更麻烦的是不同请求长度差异很大短的早就跑完了长的还在占着资源新请求进不来整体吞吐被拖死。vLLM 的思路是把显存管理从“按请求预留”改成“按需分页”。这个灵感来自操作系统的虚拟内存分页机制把 KV Cache 切成固定大小的块block每个请求按实际需要申请块块与块之间不需要连续。这样一来显存利用率大幅提升碎片问题也缓解了。你可以把它理解成停车场以前是每辆车不管大小都占一个固定大车位现在是按实际车型分配车位小车不浪费大车也能停进来。2.2 PagedAttention 到底解决了什么PagedAttention 是 vLLM 的核心机制但很多人第一次看介绍的时候容易把它当成一个“优化技巧”没意识到它其实是整个高吞吐能力的地基。简单说它把注意力计算中的 Key 和 Value 缓存按块管理每个块存储固定数量 token 的 KV 数据。请求在生成过程中需要新块的时候向引擎申请用完的块可以及时回收给其他请求复用。这个机制带来的直接好处有三个。第一显存浪费大幅降低。以前按最大长度预留现在按实际生成长度动态分配实测下来显存利用率能从三四成提到七八成。第二支持更大的批处理规模。因为显存省下来了同样一张卡能同时容纳更多请求的 KV Cache批处理规模自然上去。第三请求间可以共享块。比如多个请求用同一个系统提示词这部分 KV 可以共享不用每个请求都存一份对于固定前缀的场景比如统一的系统指令效果非常明显。注意PagedAttention 的块大小是一个需要根据场景调整的参数。块太小管理开销大块太大内部碎片多。后面实操部分我会给出具体的取值建议。2.3 连续批处理如何提升吞吐连续批处理解决的是另一个维度的效率问题。传统批处理是“静态”的凑一批请求一起跑等这批全部结束再跑下一批。问题是不同请求生成长度不一样短的早就完了但必须等长的那个结束整个批次才能释放。这期间短请求占用的资源白白浪费新请求也只能排队等着。连续批处理的逻辑是每个生成步骤结束后检查哪些请求已经完成把它们移出批次同时把排队中的新请求加进来。这样批次始终是“满”的没有资源空转。实际效果是在请求长度差异大的场景下吞吐量能比静态批处理高出好几倍。我做过一个对比测试同样混合短问答和长文生成两类请求静态批处理的 GPU 利用率大概在四成左右波动连续批处理能稳定在七成以上。2.4 为什么选 vLLM 而不是其他方案本地推理引擎的选择其实不少有偏轻量的有偏易用的也有偏极致性能的。vLLM 的定位比较清晰在吞吐量和部署复杂度之间取一个平衡点。它不像某些方案那样需要深度定制才能发挥性能也不像一些轻量方案那样并发一上来就撑不住。对于大多数想把本地模型接入业务流的团队来说这个平衡点是比较合适的。另外vLLM 对主流模型架构的支持比较全HuggingFace 上的模型基本能直接加载不需要太多转换工作。它的 API 也兼容常见的接口规范接入现有系统时改动量小。这些工程上的便利性在实际项目里往往比单纯的性能数字更重要。3. 核心细节解析与实操要点3.1 显存分配的关键参数怎么定部署 vLLM 时有几个参数直接决定服务能不能稳住我逐个说。gpu_memory_utilization这个参数控制引擎能占用多少比例的显存。默认是 0.9意思是留 10% 给系统和其他进程。这个值不是越高越好。如果你把模型权重、KV Cache、中间激活都算进去实际能用的显存比你想的紧张。我一般建议先设 0.85 到 0.9跑起来之后看显存监控如果还有余量再往上调。设太高容易在并发高峰时 OOM设太低则浪费显存批处理规模上不去。max_model_len是模型支持的最大上下文长度。这个值直接影响 KV Cache 的块数量和显存占用。很多人习惯直接设成模型标称的最大值比如 32K 或 128K但实际业务里可能根本用不到那么长。设得过大引擎会按这个长度预留管理结构浪费显存。我的做法是先统计实际请求的长度分布取一个覆盖 95% 请求的值再留一点余量。比如大部分请求在 4K 以内那就设 8K没必要开到 32K。block_size是 PagedAttention 的块大小默认 16。这个值影响显存碎片和管理开销的平衡。块小内部碎片少但块数量多管理开销大块大管理简单但每个请求最后一个块可能浪费较多。实测下来16 在大多数场景下是比较稳的选择。如果你的请求长度普遍很短比如都在 512 以内可以试试调到 8如果都是长文本32 也可以考虑。3.2 批处理相关的调度参数max_num_seqs控制同时处理的请求数上限。这个值不是越大越好它受显存和计算能力双重约束。设太大显存不够会触发抢占反而导致请求被反复换入换出延迟飙升。设太小吞吐上不去。我的经验是先按显存估算一个上限然后逐步加压测试找到延迟和吞吐的平衡点。max_num_batched_tokens是单个批次能处理的最大 token 数。这个参数和 max_num_seqs 配合使用共同决定批处理规模。对于长请求多的场景这个值要设大一些否则长请求会被频繁打断对于短请求多的场景可以设小一点让调度更灵活。实操心得这两个参数不要孤立地调。我一般固定一个调另一个观察吞吐和 P99 延迟的变化。通常先把 max_num_batched_tokens 设成 max_model_len 的两到三倍再根据实际表现微调 max_num_seqs。3.3 模型加载与量化选择模型加载方式直接影响启动速度和显存占用。vLLM 支持多种精度加载包括 FP16、BF16 以及各种量化格式。选择哪种取决于你的硬件和精度要求。如果显卡显存充足比如 24G 以上跑 7B 模型直接用 FP16 或 BF16 就行精度损失最小兼容性最好。如果显存紧张可以考虑量化版本。目前比较成熟的是 GPTQ 和 AWQ 两类4bit 量化能把显存占用降到 FP16 的三成左右精度损失在可接受范围内。但要注意量化模型的推理速度不一定比 FP16 快因为反量化本身有开销具体要看硬件和实现。还有一个容易被忽略的点是张量并行。如果你有多张卡可以用张量并行把模型切开放到多卡上这样单卡显存压力小能支持更大的模型或更大的批处理规模。但张量并行会引入卡间通信开销卡越多通信占比越高。一般 2 到 4 卡是比较划算的区间再多就要仔细评估了。3.4 请求调度的优先级与抢占vLLM 的调度器支持请求优先级这在混合负载场景下很有用。比如你同时有实时问答和离线批处理两类请求实时问答对延迟敏感离线批处理可以慢慢跑。这时候可以给实时请求设高优先级让它们在资源紧张时优先被调度。抢占机制是另一个需要理解的细节。当显存不够时调度器会把一些正在运行的请求换出腾出空间给新请求。被换出的请求之后会重新换入继续生成。这个机制保证了服务不会因为显存不足直接崩溃但代价是被抢占的请求延迟会变高。如果你的场景对延迟极其敏感就要通过参数控制尽量避免抢占发生比如适当降低 max_num_seqs。4. 实操过程与核心环节实现4.1 环境准备与依赖安装先说环境。我用的是一台带单张 24G 显存的机器系统是常见的 Linux 发行版Python 版本 3.10。vLLM 对 Python 版本有一定要求太老或太新都可能遇到依赖问题3.10 是比较稳的选择。安装方式我推荐用 pip 直接装预编译包省去编译时间。如果你需要特定版本或者要改源码再从源码编译。命令大致如下# 创建独立环境避免污染系统 Python python -m venv vllm-env source vllm-env/bin/activate # 安装 vLLM指定版本避免自动升级到不兼容的新版 pip install vllm0.4.2 # 验证安装 python -c import vllm; print(vllm.__version__)这里指定版本是个经验。vLLM 迭代很快不同版本之间 API 和默认参数可能有变化。生产环境一定要锁版本不要用 latest否则某天自动升级后行为变了排查起来很麻烦。注意安装过程中如果遇到 CUDA 相关的编译错误先确认显卡驱动和 CUDA 版本是否匹配。vLLM 对 CUDA 版本有要求版本不对会直接报错。可以用nvidia-smi看驱动支持的 CUDA 版本再对照 vLLM 的文档选择对应版本。4.2 启动服务的完整命令与参数说明环境好了之后启动服务。我一般先用命令行方式启动方便调试稳定之后再写成配置文件或容器化。python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name local-model \ --host 0.0.0.0 \ --port 8000 \ --gpu-memory-utilization 0.88 \ --max-model-len 8192 \ --max-num-seqs 64 \ --max-num-batched-tokens 16384 \ --block-size 16 \ --dtype auto \ --trust-remote-code逐个说这些参数的实际含义。--model指向模型权重目录可以是本地路径也可以是模型仓库标识。--served-model-name是服务对外暴露的模型名客户端调用时用这个名字。--host和--port是监听地址和端口设成 0.0.0.0 是为了让局域网内其他机器也能访问。--gpu-memory-utilization 0.88是我在 24G 卡上跑 7B 模型常用的值留出约 12% 给系统和中间激活。--max-model-len 8192是根据实际请求长度分布定的覆盖了绝大多数场景。--max-num-seqs 64和--max-num-batched-tokens 16384是配合使用的前者限制并发请求数后者限制单批 token 总量。--dtype auto让引擎自动选择精度一般会选 FP16 或 BF16。--trust-remote-code在加载一些自定义架构的模型时需要但要注意安全只对你信任的模型开启。启动后终端会打印模型加载进度和显存占用情况。看到类似 “Uvicorn running on http://0.0.0.0:8000” 的输出就说明服务起来了。4.3 用客户端验证服务是否正常服务起来之后先做基本验证。用 curl 发一个简单请求curl http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d { model: local-model, prompt: 用一句话解释什么是批处理, max_tokens: 64, temperature: 0.7 }如果返回正常的文本内容说明服务通了。接下来做并发测试这才是真正验证吞吐能力的地方。我一般用 Python 写一个简单的并发脚本import concurrent.futures import requests import time def send_request(idx): start time.time() resp requests.post( http://localhost:8000/v1/completions, json{ model: local-model, prompt: f这是第 {idx} 个测试请求请生成一段关于并发处理的说明。, max_tokens: 128, temperature: 0.7 } ) elapsed time.time() - start return idx, elapsed, resp.status_code # 并发 32 个请求 with concurrent.futures.ThreadPoolExecutor(max_workers32) as executor: futures [executor.submit(send_request, i) for i in range(32)] results [f.result() for f in concurrent.futures.as_completed(futures)] # 统计 latencies [r[1] for r in results] print(f请求数: {len(results)}) print(f平均延迟: {sum(latencies)/len(latencies):.2f}s) print(f最大延迟: {max(latencies):.2f}s) print(f最小延迟: {min(latencies):.2f}s)这个脚本能帮你快速了解服务在并发下的表现。重点看平均延迟和最大延迟的差距如果差距很大说明调度有问题可能需要调整批处理参数。4.4 压力测试与参数调优过程基本验证通过后进入调优阶段。我一般用逐步加压的方式从并发 8 开始逐步加到 16、32、64观察吞吐和延迟的变化曲线。第一次测试我用默认参数跑并发 32 时发现 P99 延迟明显高于 P50说明有请求被抢占或排队。查看日志发现显存接近上限触发了抢占。于是把max_num_seqs从默认值降到 48同时把gpu_memory_utilization从 0.9 降到 0.85给系统留更多余量。再测P99 延迟明显改善吞吐只下降了不到 5%。第二次测试我调整了block_size。原来用默认的 16改成 8 之后短请求的显存利用率有提升但管理开销增加整体吞吐变化不大。后来改回 16因为在这个场景下差异不明显默认值更省心。第三次测试我尝试开启enable_prefix_caching。这个功能对固定前缀的场景效果很好比如所有请求都带同一段系统提示词。开启后这部分 KV 只存一份多个请求共享显存占用下降吞吐有可见提升。但如果你的请求前缀各不相同这个功能收益不大反而增加管理开销。经过几轮调整最终稳定在一组参数上gpu_memory_utilization 0.85、max_model_len 8192、max_num_seqs 48、max_num_batched_tokens 12288、block_size 16。在这个配置下并发 32 时平均延迟控制在 2 秒以内P99 在 4 秒左右GPU 利用率稳定在七成以上。5. 常见问题与排查技巧实录5.1 启动就 OOM 怎么办这是最常见的问题尤其是第一次部署的时候。启动阶段 OOM 通常有几个原因。一是gpu_memory_utilization设太高模型权重加载完就没剩多少给 KV Cache 了。解决办法是降到 0.8 甚至 0.75 试试。二是max_model_len设太大引擎按这个长度预留管理结构显存不够。先降到 4096 或 2048确认能起来再往上调。三是模型本身太大单卡放不下这时候要考虑量化或者张量并行。还有一种情况是显存看起来够但启动时还是 OOM。这往往是因为系统或其他进程占了一部分显存nvidia-smi看到的空闲显存不等于可用显存。启动前先确认没有其他进程占着卡必要时用nvidia-smi查看并清理。5.2 并发上不去、吞吐低怎么排查如果服务能跑但并发一高就撑不住先看显存监控。显存满了会触发抢占请求被反复换入换出吞吐自然上不去。这时候要么降max_num_seqs要么降max_model_len要么换量化模型。如果显存没满但吞吐还是低看 GPU 利用率。利用率低说明计算资源没吃满可能是批处理规模太小。适当提高max_num_batched_tokens让每个批次处理更多 token。但要注意这个值太大也会导致单批计算时间过长延迟变高需要找平衡。还有一种容易被忽略的情况是请求长度分布太极端。如果大部分请求很短少数请求特别长长请求会拖慢整个批次。这时候可以考虑把长请求单独路由到另一个实例或者用优先级调度让短请求先走。5.3 延迟抖动大的原因分析延迟抖动大P99 远高于 P50通常和抢占、排队、批处理规模波动有关。先看日志里有没有抢占记录有的话说明显存紧张需要调整参数。再看请求到达是否均匀如果是一阵一阵的突发流量排队延迟会明显。这种情况可以考虑加一个请求队列平滑流量或者适当增加实例数做负载均衡。另一个原因是批处理规模波动。如果max_num_batched_tokens设得比较小批次经常凑不满计算效率低延迟也会波动。适当调大这个值让批次更稳定延迟抖动会改善。5.4 常见问题速查表问题现象可能原因排查方向解决建议启动 OOM显存预留不足查看 gpu_memory_utilization 和 max_model_len降低这两个参数或用量化模型并发上不去显存满触发抢占监控显存和抢占日志降 max_num_seqs或降 max_model_len吞吐低但显存没满批处理规模太小查看 GPU 利用率和批次大小提高 max_num_batched_tokens延迟抖动大抢占或排队查看 P99 延迟和抢占记录调整参数平滑流量或加实例长请求拖慢整体请求长度分布极端统计请求长度分布长短请求分离路由前缀缓存没效果请求前缀不固定检查请求前缀是否一致前缀不固定时关闭该功能5.5 几个容易踩的坑第一个坑是盲目追求大 batch。批处理规模大确实能提升吞吐但延迟也会上去。如果你的场景对延迟敏感不要一味加大 batch要在吞吐和延迟之间找平衡。我见过有人把max_num_seqs设到 256结果 P99 延迟飙到十几秒用户体验极差。第二个坑是忽略请求长度分布。不同业务的请求长度差异很大参数不能照搬。做在线问答的请求普遍短参数可以设得激进一些做长文生成的请求长参数要保守给长请求留足空间。第三个坑是不锁版本。前面提过vLLM 迭代快不同版本行为可能不同。生产环境一定要锁版本升级前先在测试环境验证。第四个坑是不做压测就上线。本地测试单条请求没问题不代表并发场景没问题。上线前一定要做压力测试摸清服务的容量边界留出余量。6. 服务化部署与长期维护建议6.1 从命令行到容器化命令行启动适合调试但长期运行建议容器化。容器化有几个好处环境隔离不会因为系统升级导致依赖冲突启动参数可以写成配置文件版本化管理配合编排工具可以做健康检查和自动重启。写 Dockerfile 的时候基础镜像选带 CUDA 的官方镜像把 vLLM 和依赖装进去模型权重可以挂载卷不用打进镜像。启动命令写成 entrypoint 脚本参数从环境变量读取方便不同环境用不同配置。注意容器里访问 GPU 需要配置运行时确保容器能识别到显卡。启动容器时加上--gpus all或者对应的运行时参数。6.2 监控指标该看哪些服务上线后监控是必须的。核心指标有几个GPU 利用率反映计算资源是否吃满显存占用反映是否有 OOM 风险请求延迟分布P50、P95、P99 都要看只看平均延迟会掩盖问题吞吐量每秒处理的 token 数或请求数抢占次数反映显存压力。这些指标可以用常见的监控系统采集vLLM 本身也暴露了一些指标接口可以对接。关键是设好告警阈值比如显存超过 90% 告警P99 延迟超过某个值告警抢占次数突增告警。6.3 扩容与负载均衡单实例撑不住的时候就要考虑扩容。最简单的方式是起多个实例前面加一个负载均衡。但要注意大模型推理实例的负载均衡和普通 Web 服务不太一样因为每个请求的处理时间差异很大简单的轮询可能导致某些实例过载。比较好的做法是根据实例的实时负载来路由比如看当前排队请求数或 GPU 利用率把新请求发给负载最低的实例。另外如果多个实例加载同一个模型显存是各自占用的扩容时要把这部分成本算进去。6.4 模型更新与版本管理模型更新是另一个需要规划的事情。新模型上线不能直接替换要先在测试环境验证效果和性能确认没问题再切流量。切换时最好支持灰度先切一小部分流量观察一段时间再全量。版本管理方面建议把模型版本和服务配置都纳入版本控制每次变更都有记录出问题能快速回滚。模型文件本身比较大可以用对象存储管理服务启动时拉取指定版本。7. 一些实测数据与个人体会最后分享一些实测数据供参考。在单张 24G 显存的卡上跑 7B 模型FP16 精度max_model_len设 8192max_num_seqs设 48实测并发 32 时短请求生成 64 token平均延迟约 1.2 秒长请求生成 512 token平均延迟约 6 秒整体吞吐约每秒 800 token。开启前缀缓存后固定前缀场景下吞吐能再提升一成多。如果换成 4bit 量化模型显存占用降到约三分之一max_num_seqs可以提到 96吞吐翻倍但生成质量会有轻微下降具体能不能接受要看业务场景。我个人在实际操作中的体会是vLLM 这套东西的上手门槛不算高但要把参数调好、把服务跑稳需要花时间做压测和观察。不要指望一套参数走天下不同模型、不同硬件、不同业务场景最优参数都不一样。最好的办法是建立一套自己的测试流程每次变更都跑一遍用数据说话。另外本地推理服务的稳定性很大程度上取决于你对显存的管理。显存是稀缺资源所有参数调整本质上都是在显存、吞吐、延迟三者之间找平衡。理解了这一点调参就不会盲目遇到问题也知道往哪个方向排查。这个内容后续还可以这样扩展如果你有多台机器可以研究一下分布式推理的部署方式如果对成本敏感可以对比不同量化方案的性价比如果业务对延迟要求极高可以研究投机解码等加速技术。这些方向我之后有机会再单独展开聊。
1. 为什么本地推理服务需要高吞吐引擎大模型本地部署这件事前两年大家关注的重点还是“能不能跑起来”——把权重下载下来装好依赖能对着命令行吐出一段通顺的话就算成功。但到了今年情况明显变了。越来越多的团队和个人开发者开始把本地模型接入到实际业务流里客服自动回复、文档批量摘要、代码补全、知识库问答甚至是一些需要持续跑批的离线任务。这时候“能跑”和“跑得好”之间的差距就暴露出来了。我最早用原生推理框架搭服务的时候单条请求响应还算能接受但只要并发一上来显存占用直接飙满吞吐量断崖式下跌延迟从几百毫秒涨到十几秒。后来换成带动态批处理能力的推理引擎同样的硬件吞吐量翻了六七倍显存反而更稳了。这个差距的核心就在于推理引擎有没有真正解决高并发场景下的显存管理和请求调度问题。vLLM 这个引擎之所以在本地部署圈子里被反复提起就是因为它把两个关键问题处理得比较到位一是用PagedAttention把 KV Cache 的显存碎片问题压下去二是用连续批处理让不同长度的请求能动态拼批不用等最长的那个请求结束才释放资源。这两点听起来是工程细节但实际效果非常直观——同样的显卡能同时服务的请求数上去了单位 token 的成本下来了。这篇文章面向的是已经有一定本地部署经验、想把推理服务从“玩具”升级到“能扛并发”的开发者。我会从整体设计思路讲起把核心机制拆开再给出一套可以直接复现的部署流程最后把我踩过的坑和排查经验整理出来。如果你现在正被并发上不去、显存爆掉、延迟抖动这些问题困扰下面的内容应该能帮你省不少时间。2. 推理引擎整体设计与核心思路拆解2.1 从“单请求独占”到“批处理共享”的思维转变传统推理框架的默认行为是一个请求进来分配一块显存把 KV Cache 按最大可能长度预留好等这个请求完全结束再释放。这种模式在单用户场景下没问题但一旦并发上来问题就很明显——每个请求都按最大长度占坑实际用到的可能只有十分之一剩下的全是浪费。更麻烦的是不同请求长度差异很大短的早就跑完了长的还在占着资源新请求进不来整体吞吐被拖死。vLLM 的思路是把显存管理从“按请求预留”改成“按需分页”。这个灵感来自操作系统的虚拟内存分页机制把 KV Cache 切成固定大小的块block每个请求按实际需要申请块块与块之间不需要连续。这样一来显存利用率大幅提升碎片问题也缓解了。你可以把它理解成停车场以前是每辆车不管大小都占一个固定大车位现在是按实际车型分配车位小车不浪费大车也能停进来。2.2 PagedAttention 到底解决了什么PagedAttention 是 vLLM 的核心机制但很多人第一次看介绍的时候容易把它当成一个“优化技巧”没意识到它其实是整个高吞吐能力的地基。简单说它把注意力计算中的 Key 和 Value 缓存按块管理每个块存储固定数量 token 的 KV 数据。请求在生成过程中需要新块的时候向引擎申请用完的块可以及时回收给其他请求复用。这个机制带来的直接好处有三个。第一显存浪费大幅降低。以前按最大长度预留现在按实际生成长度动态分配实测下来显存利用率能从三四成提到七八成。第二支持更大的批处理规模。因为显存省下来了同样一张卡能同时容纳更多请求的 KV Cache批处理规模自然上去。第三请求间可以共享块。比如多个请求用同一个系统提示词这部分 KV 可以共享不用每个请求都存一份对于固定前缀的场景比如统一的系统指令效果非常明显。注意PagedAttention 的块大小是一个需要根据场景调整的参数。块太小管理开销大块太大内部碎片多。后面实操部分我会给出具体的取值建议。2.3 连续批处理如何提升吞吐连续批处理解决的是另一个维度的效率问题。传统批处理是“静态”的凑一批请求一起跑等这批全部结束再跑下一批。问题是不同请求生成长度不一样短的早就完了但必须等长的那个结束整个批次才能释放。这期间短请求占用的资源白白浪费新请求也只能排队等着。连续批处理的逻辑是每个生成步骤结束后检查哪些请求已经完成把它们移出批次同时把排队中的新请求加进来。这样批次始终是“满”的没有资源空转。实际效果是在请求长度差异大的场景下吞吐量能比静态批处理高出好几倍。我做过一个对比测试同样混合短问答和长文生成两类请求静态批处理的 GPU 利用率大概在四成左右波动连续批处理能稳定在七成以上。2.4 为什么选 vLLM 而不是其他方案本地推理引擎的选择其实不少有偏轻量的有偏易用的也有偏极致性能的。vLLM 的定位比较清晰在吞吐量和部署复杂度之间取一个平衡点。它不像某些方案那样需要深度定制才能发挥性能也不像一些轻量方案那样并发一上来就撑不住。对于大多数想把本地模型接入业务流的团队来说这个平衡点是比较合适的。另外vLLM 对主流模型架构的支持比较全HuggingFace 上的模型基本能直接加载不需要太多转换工作。它的 API 也兼容常见的接口规范接入现有系统时改动量小。这些工程上的便利性在实际项目里往往比单纯的性能数字更重要。3. 核心细节解析与实操要点3.1 显存分配的关键参数怎么定部署 vLLM 时有几个参数直接决定服务能不能稳住我逐个说。gpu_memory_utilization这个参数控制引擎能占用多少比例的显存。默认是 0.9意思是留 10% 给系统和其他进程。这个值不是越高越好。如果你把模型权重、KV Cache、中间激活都算进去实际能用的显存比你想的紧张。我一般建议先设 0.85 到 0.9跑起来之后看显存监控如果还有余量再往上调。设太高容易在并发高峰时 OOM设太低则浪费显存批处理规模上不去。max_model_len是模型支持的最大上下文长度。这个值直接影响 KV Cache 的块数量和显存占用。很多人习惯直接设成模型标称的最大值比如 32K 或 128K但实际业务里可能根本用不到那么长。设得过大引擎会按这个长度预留管理结构浪费显存。我的做法是先统计实际请求的长度分布取一个覆盖 95% 请求的值再留一点余量。比如大部分请求在 4K 以内那就设 8K没必要开到 32K。block_size是 PagedAttention 的块大小默认 16。这个值影响显存碎片和管理开销的平衡。块小内部碎片少但块数量多管理开销大块大管理简单但每个请求最后一个块可能浪费较多。实测下来16 在大多数场景下是比较稳的选择。如果你的请求长度普遍很短比如都在 512 以内可以试试调到 8如果都是长文本32 也可以考虑。3.2 批处理相关的调度参数max_num_seqs控制同时处理的请求数上限。这个值不是越大越好它受显存和计算能力双重约束。设太大显存不够会触发抢占反而导致请求被反复换入换出延迟飙升。设太小吞吐上不去。我的经验是先按显存估算一个上限然后逐步加压测试找到延迟和吞吐的平衡点。max_num_batched_tokens是单个批次能处理的最大 token 数。这个参数和 max_num_seqs 配合使用共同决定批处理规模。对于长请求多的场景这个值要设大一些否则长请求会被频繁打断对于短请求多的场景可以设小一点让调度更灵活。实操心得这两个参数不要孤立地调。我一般固定一个调另一个观察吞吐和 P99 延迟的变化。通常先把 max_num_batched_tokens 设成 max_model_len 的两到三倍再根据实际表现微调 max_num_seqs。3.3 模型加载与量化选择模型加载方式直接影响启动速度和显存占用。vLLM 支持多种精度加载包括 FP16、BF16 以及各种量化格式。选择哪种取决于你的硬件和精度要求。如果显卡显存充足比如 24G 以上跑 7B 模型直接用 FP16 或 BF16 就行精度损失最小兼容性最好。如果显存紧张可以考虑量化版本。目前比较成熟的是 GPTQ 和 AWQ 两类4bit 量化能把显存占用降到 FP16 的三成左右精度损失在可接受范围内。但要注意量化模型的推理速度不一定比 FP16 快因为反量化本身有开销具体要看硬件和实现。还有一个容易被忽略的点是张量并行。如果你有多张卡可以用张量并行把模型切开放到多卡上这样单卡显存压力小能支持更大的模型或更大的批处理规模。但张量并行会引入卡间通信开销卡越多通信占比越高。一般 2 到 4 卡是比较划算的区间再多就要仔细评估了。3.4 请求调度的优先级与抢占vLLM 的调度器支持请求优先级这在混合负载场景下很有用。比如你同时有实时问答和离线批处理两类请求实时问答对延迟敏感离线批处理可以慢慢跑。这时候可以给实时请求设高优先级让它们在资源紧张时优先被调度。抢占机制是另一个需要理解的细节。当显存不够时调度器会把一些正在运行的请求换出腾出空间给新请求。被换出的请求之后会重新换入继续生成。这个机制保证了服务不会因为显存不足直接崩溃但代价是被抢占的请求延迟会变高。如果你的场景对延迟极其敏感就要通过参数控制尽量避免抢占发生比如适当降低 max_num_seqs。4. 实操过程与核心环节实现4.1 环境准备与依赖安装先说环境。我用的是一台带单张 24G 显存的机器系统是常见的 Linux 发行版Python 版本 3.10。vLLM 对 Python 版本有一定要求太老或太新都可能遇到依赖问题3.10 是比较稳的选择。安装方式我推荐用 pip 直接装预编译包省去编译时间。如果你需要特定版本或者要改源码再从源码编译。命令大致如下# 创建独立环境避免污染系统 Python python -m venv vllm-env source vllm-env/bin/activate # 安装 vLLM指定版本避免自动升级到不兼容的新版 pip install vllm0.4.2 # 验证安装 python -c import vllm; print(vllm.__version__)这里指定版本是个经验。vLLM 迭代很快不同版本之间 API 和默认参数可能有变化。生产环境一定要锁版本不要用 latest否则某天自动升级后行为变了排查起来很麻烦。注意安装过程中如果遇到 CUDA 相关的编译错误先确认显卡驱动和 CUDA 版本是否匹配。vLLM 对 CUDA 版本有要求版本不对会直接报错。可以用nvidia-smi看驱动支持的 CUDA 版本再对照 vLLM 的文档选择对应版本。4.2 启动服务的完整命令与参数说明环境好了之后启动服务。我一般先用命令行方式启动方便调试稳定之后再写成配置文件或容器化。python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name local-model \ --host 0.0.0.0 \ --port 8000 \ --gpu-memory-utilization 0.88 \ --max-model-len 8192 \ --max-num-seqs 64 \ --max-num-batched-tokens 16384 \ --block-size 16 \ --dtype auto \ --trust-remote-code逐个说这些参数的实际含义。--model指向模型权重目录可以是本地路径也可以是模型仓库标识。--served-model-name是服务对外暴露的模型名客户端调用时用这个名字。--host和--port是监听地址和端口设成 0.0.0.0 是为了让局域网内其他机器也能访问。--gpu-memory-utilization 0.88是我在 24G 卡上跑 7B 模型常用的值留出约 12% 给系统和中间激活。--max-model-len 8192是根据实际请求长度分布定的覆盖了绝大多数场景。--max-num-seqs 64和--max-num-batched-tokens 16384是配合使用的前者限制并发请求数后者限制单批 token 总量。--dtype auto让引擎自动选择精度一般会选 FP16 或 BF16。--trust-remote-code在加载一些自定义架构的模型时需要但要注意安全只对你信任的模型开启。启动后终端会打印模型加载进度和显存占用情况。看到类似 “Uvicorn running on http://0.0.0.0:8000” 的输出就说明服务起来了。4.3 用客户端验证服务是否正常服务起来之后先做基本验证。用 curl 发一个简单请求curl http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d { model: local-model, prompt: 用一句话解释什么是批处理, max_tokens: 64, temperature: 0.7 }如果返回正常的文本内容说明服务通了。接下来做并发测试这才是真正验证吞吐能力的地方。我一般用 Python 写一个简单的并发脚本import concurrent.futures import requests import time def send_request(idx): start time.time() resp requests.post( http://localhost:8000/v1/completions, json{ model: local-model, prompt: f这是第 {idx} 个测试请求请生成一段关于并发处理的说明。, max_tokens: 128, temperature: 0.7 } ) elapsed time.time() - start return idx, elapsed, resp.status_code # 并发 32 个请求 with concurrent.futures.ThreadPoolExecutor(max_workers32) as executor: futures [executor.submit(send_request, i) for i in range(32)] results [f.result() for f in concurrent.futures.as_completed(futures)] # 统计 latencies [r[1] for r in results] print(f请求数: {len(results)}) print(f平均延迟: {sum(latencies)/len(latencies):.2f}s) print(f最大延迟: {max(latencies):.2f}s) print(f最小延迟: {min(latencies):.2f}s)这个脚本能帮你快速了解服务在并发下的表现。重点看平均延迟和最大延迟的差距如果差距很大说明调度有问题可能需要调整批处理参数。4.4 压力测试与参数调优过程基本验证通过后进入调优阶段。我一般用逐步加压的方式从并发 8 开始逐步加到 16、32、64观察吞吐和延迟的变化曲线。第一次测试我用默认参数跑并发 32 时发现 P99 延迟明显高于 P50说明有请求被抢占或排队。查看日志发现显存接近上限触发了抢占。于是把max_num_seqs从默认值降到 48同时把gpu_memory_utilization从 0.9 降到 0.85给系统留更多余量。再测P99 延迟明显改善吞吐只下降了不到 5%。第二次测试我调整了block_size。原来用默认的 16改成 8 之后短请求的显存利用率有提升但管理开销增加整体吞吐变化不大。后来改回 16因为在这个场景下差异不明显默认值更省心。第三次测试我尝试开启enable_prefix_caching。这个功能对固定前缀的场景效果很好比如所有请求都带同一段系统提示词。开启后这部分 KV 只存一份多个请求共享显存占用下降吞吐有可见提升。但如果你的请求前缀各不相同这个功能收益不大反而增加管理开销。经过几轮调整最终稳定在一组参数上gpu_memory_utilization 0.85、max_model_len 8192、max_num_seqs 48、max_num_batched_tokens 12288、block_size 16。在这个配置下并发 32 时平均延迟控制在 2 秒以内P99 在 4 秒左右GPU 利用率稳定在七成以上。5. 常见问题与排查技巧实录5.1 启动就 OOM 怎么办这是最常见的问题尤其是第一次部署的时候。启动阶段 OOM 通常有几个原因。一是gpu_memory_utilization设太高模型权重加载完就没剩多少给 KV Cache 了。解决办法是降到 0.8 甚至 0.75 试试。二是max_model_len设太大引擎按这个长度预留管理结构显存不够。先降到 4096 或 2048确认能起来再往上调。三是模型本身太大单卡放不下这时候要考虑量化或者张量并行。还有一种情况是显存看起来够但启动时还是 OOM。这往往是因为系统或其他进程占了一部分显存nvidia-smi看到的空闲显存不等于可用显存。启动前先确认没有其他进程占着卡必要时用nvidia-smi查看并清理。5.2 并发上不去、吞吐低怎么排查如果服务能跑但并发一高就撑不住先看显存监控。显存满了会触发抢占请求被反复换入换出吞吐自然上不去。这时候要么降max_num_seqs要么降max_model_len要么换量化模型。如果显存没满但吞吐还是低看 GPU 利用率。利用率低说明计算资源没吃满可能是批处理规模太小。适当提高max_num_batched_tokens让每个批次处理更多 token。但要注意这个值太大也会导致单批计算时间过长延迟变高需要找平衡。还有一种容易被忽略的情况是请求长度分布太极端。如果大部分请求很短少数请求特别长长请求会拖慢整个批次。这时候可以考虑把长请求单独路由到另一个实例或者用优先级调度让短请求先走。5.3 延迟抖动大的原因分析延迟抖动大P99 远高于 P50通常和抢占、排队、批处理规模波动有关。先看日志里有没有抢占记录有的话说明显存紧张需要调整参数。再看请求到达是否均匀如果是一阵一阵的突发流量排队延迟会明显。这种情况可以考虑加一个请求队列平滑流量或者适当增加实例数做负载均衡。另一个原因是批处理规模波动。如果max_num_batched_tokens设得比较小批次经常凑不满计算效率低延迟也会波动。适当调大这个值让批次更稳定延迟抖动会改善。5.4 常见问题速查表问题现象可能原因排查方向解决建议启动 OOM显存预留不足查看 gpu_memory_utilization 和 max_model_len降低这两个参数或用量化模型并发上不去显存满触发抢占监控显存和抢占日志降 max_num_seqs或降 max_model_len吞吐低但显存没满批处理规模太小查看 GPU 利用率和批次大小提高 max_num_batched_tokens延迟抖动大抢占或排队查看 P99 延迟和抢占记录调整参数平滑流量或加实例长请求拖慢整体请求长度分布极端统计请求长度分布长短请求分离路由前缀缓存没效果请求前缀不固定检查请求前缀是否一致前缀不固定时关闭该功能5.5 几个容易踩的坑第一个坑是盲目追求大 batch。批处理规模大确实能提升吞吐但延迟也会上去。如果你的场景对延迟敏感不要一味加大 batch要在吞吐和延迟之间找平衡。我见过有人把max_num_seqs设到 256结果 P99 延迟飙到十几秒用户体验极差。第二个坑是忽略请求长度分布。不同业务的请求长度差异很大参数不能照搬。做在线问答的请求普遍短参数可以设得激进一些做长文生成的请求长参数要保守给长请求留足空间。第三个坑是不锁版本。前面提过vLLM 迭代快不同版本行为可能不同。生产环境一定要锁版本升级前先在测试环境验证。第四个坑是不做压测就上线。本地测试单条请求没问题不代表并发场景没问题。上线前一定要做压力测试摸清服务的容量边界留出余量。6. 服务化部署与长期维护建议6.1 从命令行到容器化命令行启动适合调试但长期运行建议容器化。容器化有几个好处环境隔离不会因为系统升级导致依赖冲突启动参数可以写成配置文件版本化管理配合编排工具可以做健康检查和自动重启。写 Dockerfile 的时候基础镜像选带 CUDA 的官方镜像把 vLLM 和依赖装进去模型权重可以挂载卷不用打进镜像。启动命令写成 entrypoint 脚本参数从环境变量读取方便不同环境用不同配置。注意容器里访问 GPU 需要配置运行时确保容器能识别到显卡。启动容器时加上--gpus all或者对应的运行时参数。6.2 监控指标该看哪些服务上线后监控是必须的。核心指标有几个GPU 利用率反映计算资源是否吃满显存占用反映是否有 OOM 风险请求延迟分布P50、P95、P99 都要看只看平均延迟会掩盖问题吞吐量每秒处理的 token 数或请求数抢占次数反映显存压力。这些指标可以用常见的监控系统采集vLLM 本身也暴露了一些指标接口可以对接。关键是设好告警阈值比如显存超过 90% 告警P99 延迟超过某个值告警抢占次数突增告警。6.3 扩容与负载均衡单实例撑不住的时候就要考虑扩容。最简单的方式是起多个实例前面加一个负载均衡。但要注意大模型推理实例的负载均衡和普通 Web 服务不太一样因为每个请求的处理时间差异很大简单的轮询可能导致某些实例过载。比较好的做法是根据实例的实时负载来路由比如看当前排队请求数或 GPU 利用率把新请求发给负载最低的实例。另外如果多个实例加载同一个模型显存是各自占用的扩容时要把这部分成本算进去。6.4 模型更新与版本管理模型更新是另一个需要规划的事情。新模型上线不能直接替换要先在测试环境验证效果和性能确认没问题再切流量。切换时最好支持灰度先切一小部分流量观察一段时间再全量。版本管理方面建议把模型版本和服务配置都纳入版本控制每次变更都有记录出问题能快速回滚。模型文件本身比较大可以用对象存储管理服务启动时拉取指定版本。7. 一些实测数据与个人体会最后分享一些实测数据供参考。在单张 24G 显存的卡上跑 7B 模型FP16 精度max_model_len设 8192max_num_seqs设 48实测并发 32 时短请求生成 64 token平均延迟约 1.2 秒长请求生成 512 token平均延迟约 6 秒整体吞吐约每秒 800 token。开启前缀缓存后固定前缀场景下吞吐能再提升一成多。如果换成 4bit 量化模型显存占用降到约三分之一max_num_seqs可以提到 96吞吐翻倍但生成质量会有轻微下降具体能不能接受要看业务场景。我个人在实际操作中的体会是vLLM 这套东西的上手门槛不算高但要把参数调好、把服务跑稳需要花时间做压测和观察。不要指望一套参数走天下不同模型、不同硬件、不同业务场景最优参数都不一样。最好的办法是建立一套自己的测试流程每次变更都跑一遍用数据说话。另外本地推理服务的稳定性很大程度上取决于你对显存的管理。显存是稀缺资源所有参数调整本质上都是在显存、吞吐、延迟三者之间找平衡。理解了这一点调参就不会盲目遇到问题也知道往哪个方向排查。这个内容后续还可以这样扩展如果你有多台机器可以研究一下分布式推理的部署方式如果对成本敏感可以对比不同量化方案的性价比如果业务对延迟要求极高可以研究投机解码等加速技术。这些方向我之后有机会再单独展开聊。
