V100跑Qwen 27B：从4到64 tok/s的调优实录

前阵子接了个内部需求把 Qwen 27B 部署成在线推理服务手里没有 A100 也没有 H100只有一台存量的 Tesla V100 32GB。刚把服务搭起来那会儿我整个人是懵的——单请求生成速度只有 4 tok/s输出一段 200 字的回复要等半分钟别说对外提供 API自己调试都嫌磨叽。后面花了一周时间从量化选型、推理框架切换到内核参数打磨做了三轮调优最终把稳定输出速度拉到了 64 tok/s峰值能到 70 上下。这篇东西不打算写成标准教程更像一份踩坑实录。如果你手里也是老一点的 N 卡比如 V100、P100甚至 T4并且想跑 20B 以上的开源模型这篇文章大概率能帮你省掉不少弯路。我尽量把每一步的“为什么”也讲清楚这样你换到别的模型、别的显卡也能照着思路自己推。1. 项目背景与整体设计思路1.1 为什么会有人用 V100 跑 27B 模型先说结论不是我们想用 V100是没得选。很多公司内部存量 GPU 服务器就是 V100 为主采购新卡流程长预算更紧张。V100 虽然老但 32GB 显存版本其实很能打HBM2 带宽 900GB/s比很多消费级卡的 GDDR6 强得多。真正的问题是它的 INT8/INT4 矩阵运算支持有限Tensor Core 一代只原生支持 FP16所以很多面向 Ampere 架构优化的量化推理方案在它身上并不一定能发挥全部性能。这也是为什么一开始用“无脑默认配置”跑起来只有 4 tok/s——不是模型太大跑不动而是我根本没让模型完整留在 GPU 里。Qwen 27B 的 FP16/BF16 权重大概是 54GB一张 32GB 的 V100 是装不下的。当时图省事用了device_mapauto让框架自动拆分它把一半权重丢到 CPU 内存里每个 token 生成都要通过 PCIe 把权重搬进搬出速度自然崩了。1.2 显存账本27B 模型到底需要多少显存在规划部署方案前先把账算清楚。以 Qwen2.5-27B-Instruct 为例模型结构是 27B 左右参数hidden size 比较大层数在 60 层上下。不同精度的权重大致如下精度单参数位宽理论权重体积实际情况BF16/FP1616 bit54GB无法放入 32GB V100INT88 bit27GB勉强放入 32GB但 KV cache 会很紧张INT4 (GPTQ/AWQ/GGUF Q4)4~5 bit14~16GB可以放入 32GB剩余给 KV cache 和激活除了权重还有 KV cache。每多一个 token 的上下文就需要为每一层保存 K 和 V 向量27B 模型的 KV cache 大概每 token 需要几十 KB。上下文开到 8192 token 时KV cache 可能吃掉 4~6GB 显存。所以部署时不能只看权重大小KV cache 和运行时开销都要一起算。这就是为什么最终路线必须走向量化。量化不仅是“为了塞进显存”更是为了让权重尽量全部驻留显存避免跨 PCIe 搬运。V100 的 HBM2 带宽很高但 PCIe 3.0 x16 只有 16GB/s 左右两者相差 50 倍以上。权重一旦放到 CPU 内存性能就是断崖式下跌。1.3 从 4 到 64 的三条主线整个调优过程大致分三个阶段第一阶段是把模型从 CPU 搬回 GPU用 GGUF 量化 llama.cpp 让速度到 20~30 tok/s第二阶段是换用 vLLM 的连续批处理和 PagedAttention让单流速度和并发吞吐明显提升第三阶段则是把 KV cache、上下文长度、kernel 选择这些细节逐项磨到极限最后稳定在 64 tok/s。如果你去网上搜“V100 Qwen 27B”会发现很多人卡在个位数 tok/s。核心原因基本就两种要么模型没有完全驻留 GPU要么用了不适合老卡的量化/推理方案。这篇文章就是围绕这两件事展开的。2. 第一版部署为什么只有 4 tok/s2.1 环境与软件栈先交代一下环境Ubuntu 20.04GPU 是 Tesla V100 32GB驱动版本 535.xxCUDA 用的是 11.8 容器Python 3.10。第一版部署我图省事直接用了 Hugging Face Transformers device_mapauto模型权重从 ModelScope 下载没有做任何额外处理。命令大概长这样from transformers import AutoModelForCausalLM, AutoTokenizer model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2.5-27B-Instruct, device_mapauto, torch_dtypetorch.float16, )就这么几行模型加载倒是成功了因为 Transformers 会自动把放不下的层放到 CPU 上。结果生成速度只有 4 tok/s显存占用却不低看nvidia-smi大概稳定在 25GB 左右但 GPU 利用率只有 30% 上下大量时间在等数据从 CPU 传过来。2.2 问题定位CPU offload 是罪魁祸首如果你也遇到过类似情况别急着换模型先看两层东西一是nvidia-smi里的 GPU 利用率二是进程里 PCIe 读写速率。我当时观察到一个明显特征每次生成一个 tokenGPU 显存占用会有微弱的波动这是因为某些层还在 CPU 内存里模型在 CPU 和 GPU 之间切换计算。这很好理解。生成一个 token 需要把模型的 54GB 权重全部过一遍GPU 里只放了 25GB那剩下 29GB 权重只能放 CPU。每算一个 token都要通过 PCIe 把这 29GB 搬到 GPU算完再回来。虽然 Transformers 有一定缓存机制但整体吞吐被 PCIe 带宽死死卡住。4 tok/s 其实已经很给面子了。2.3 为什么不能直接上 FP16有人可能会问能不能把 54GB 的 FP16 权重硬塞到 32GB 显存里不可能这属于物理限制。就算用max_memory参数强制分配也会直接 OOM。25GB 权重的 INT8 版本倒是能放但 V100 的 INT8 计算其实要靠软件模拟或者走某些非 Tensor Core 路径性能并不理想而且 KV cache 一开照样不够。所以我的结论很明确在人机交互级别使用 27B 模型INT4 量化几乎是唯一现实方案。FP16 模型适合 80GB 的 A100/H100不适合 V100。3. 第一次质变GGUF 量化加 llama.cpp3.1 为什么选 GGUF 而不是其他格式确定量化的方向后第一反应是试 bitsandbytes 的 4-bit 加载因为代码改动最小。结果踩了坑bitsandbytes 对 V100 这种老架构的 CUDA 支持不稳定安装后经常报算子不兼容速度反而不如 FP16 的一半。果断放弃。接着试了 GGUF。GGUF 是 llama.cpp 社区推动的模型格式最大的优势是量化方案成熟且支持把量化后的权重直接内存映射加载加载速度快还能把层全部推到 GPU 上跑。llama.cpp 的 CUDA 后端在 Volta 架构上是能用的至少矩阵计算走的是 FP16 的 cuBLAS/cuDNN比 CPU 强太多。3.2 量化档位怎么选Q4_K_M 的性价比当时从 Hugging Face 上找到了 Qwen2.5-27B-Instruct 的官方权重然后用 llama.cpp 的convert_hf_to_gguf.py转成 FP16 GGUF再用llama-quantize转不同量化档。这里提一下各档位的体积和体验量化档体积约质量备注Q4_014.8GB中速度最快质量略降Q4_K_M15.3GB较高我这个项目的最终选择Q5_K_M17.6GB高32GB V100 也能放质量更好Q6_K20.4GB很高显存占用偏高KV cache 会吃紧Q8_027GB接近无损基本不推荐在 27B 上搭配 32GB 卡实测下来 Q4_K_M 在速度和生成质量之间最平衡。27B 模型参数量大Q4 量化后依然保留了大量模型能力代码、逻辑推理、对话效果都能接受。如果最后生成的回答质量不满意我个人建议优先换 Q5_K_M而不是直接上 Q6_K因为后者显存压力会明显抬高。3.3 llama.cpp 服务启动与显存踩坑用 llama.cpp 起服务的方法很简单llama-server旧版本叫llama-server再早叫server一条命令搞定./llama-server \ -m models/qwen27b-Q4_K_M.gguf \ -ngl 99 \ -c 4096 \ --host 0.0.0.0 \ --port 8080这里-ngl 99表示把所有层都放到 GPU 上。这是最关键的参数如果-ngl只设 20 或 30一部分层留在 CPU速度会迅速掉到 10 tok/s 以下。我一开始嫌显存可能不够只设了 55结果速度只有 15 tok/s全部推到 GPU 后单流直接到了 24 tok/s 左右显存占用 15.8GB还有十几个 GB 的空闲。上下文长度我选了 4096。这里要解释一下-c参数直接决定 KV cache 占多少显存。Qwen 27B 的 KV cache 在 4096 上下文下大概占用 2~3GB32GB 显存完全够。如果你想开到 8192 甚至 16384KV cache 会暴涨到 5~10GB速度不一定掉但显存可能不够。如果出现 OOM第一件事就是把-c调小而不是去动量化档位。3.4 llama.cpp 跑起来后的瓶颈在哪GGUF llama.cpp 让速度从 4 涨到 24已经是很大的进步。但我很快发现一个问题单请求 24但并发一旦增加到 4 个请求整体吞吐并没有线性增长反而每个请求都掉到 15~18 tok/s。原因很简单llama.cpp 的批处理调度能力没有 vLLM 那种连续批处理机制对动态到达的请求做合并的效率不够高。另外我还注意到llama.cpp 在 V100 上对 Flash Attention 的支持很有限。--flash-attn参数在某些版本里能用但在 Volta 架构上会退回普通 attention反而多了一些兼容判断的开销。从我实测看开与不开差别不大如果遇到报错直接关掉即可。4. 第二次质变vLLM 加 GPTQ 量化4.1 为什么要切换到 vLLM到了这一步瓶颈已经不再是“权重放不下”而是推理引擎的调度效率。我想让服务在多个并发请求下依然保持高吞吐llama.cpp 的调度机制满足不了。vLLM 有 PagedAttention 和 continuous batching这两个特性对在线服务来说太重要了能让 GPU 在多个请求之间动态拼装 batch而不是等一个请求完全结束后才开始下一个。vLLM 要求 GPU 架构至少 7.0V100 计算能力正好是 7.0所以能装也能跑。不过要注意vLLM 默认加载的是 Hugging Face 格式的权重不能直接加载 GGUF 文件所以得把模型换成 GPTQ 量化格式。4.2 为什么选 GPTQ 而不是 AWQ在量化格式上主流有 GPTQ 和 AWQ 两种。vLLM 对两者都支持但我在 V100 上实测发现AWQ 有些 kernel 在 Volta 架构上会走到慢速 fallback 路径甚至会报不兼容。GPTQ 的兼容性好一些而且 Qwen2.5 官方直接提供了 GPTQ-Int4 版本省去了自己量化的时间。如果你用的是 Qwen 系列模型可以直接去 Hugging Face 或 ModelScope 下载Qwen2.5-27B-Instruct-GPTQ-Int4。没有现成的话用 AutoGPTQ 自己量化也不难脚本大致如下from transformers import AutoTokenizer from auto_gptq import AutoGPTQForCausalLM, BaseQuantizeConfig tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-27B-Instruct) quantize_config BaseQuantizeConfig( bits4, group_size128, desc_actTrue, ) model AutoGPTQForCausalLM.from_pretrained( Qwen/Qwen2.5-27B-Instruct, quantize_configquantize_config, device_mapauto, ) model.save_quantized(./models/Qwen2.5-27B-Instruct-GPTQ-Int4)需要注意group_size128是推荐配置量化粒度和推理速度比较平衡desc_actTrue能保留更好的激活值精度但会增加一点显存和计算开销。4.3 vLLM 启动命令与参数解析模型准备好后启动 vLLM 服务vllm serve ~/models/Qwen2.5-27B-Instruct-GPTQ-Int4 \ --gpu-memory-utilization 0.95 \ --max-model-len 4096 \ --tensor-parallel-size 1 \ --port 8000 \ --quantization gptq \ --enable-chunked-prefill逐个解释--gpu-memory-utilization 0.95让 vLLM 预分配 95% 的显存既放权重也放 KV cache。V100 32GB 下大约可用 30.4GBGPTQ-Int4 权重约 15GB剩下接近 15GB 给 KV cache。--max-model-len 4096限制最大上下文长度。这一步对 V100 非常关键如果默认开 8192 甚至更大KV cache 占掉大量显存batch 大小会被压缩吞吐反而下降。--quantization gptq显式指定量化方式vLLM 内部会加载对应的反量化 kernel。--enable-chunked-prefill把长输入的 prefill 阶段切分成小块避免某个大请求的 prefill 卡住后续请求的解码。启动之后用 OpenAI SDK 测一下from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) resp client.chat.completions.create( modelQwen2.5-27B-Instruct, messages[{role: user, content: 写一段 200 字的自我介绍}], max_tokens256, streamTrue, )单请求实测速度到了 42 tok/s 左右并发 4 个请求时总吞吐能到 65 tok/s。这已经接近最终目标了。4.4 连续批处理带来的“幻觉式腾飞”值得一提的是vLLM 的连续批处理会让“速度”在指标上显得很迷。你并发开 8 个请求每个请求的流式输出都有 40 多 tok/s但如果你用总吞吐除以请求数会发现每个请求其实被分摊了。这不代表变慢而是 GPU 的计算资源被动态分配到多个请求上。这一点在生产环境中很重要。如果只看单请求速度可能会得出“vLLM 不如 llama.cpp”的结论但如果看每秒总生成 token 数vLLM 在并发场景下会比 llama.cpp 高出一大截。这也是优化 tok/s 要走 vLLM 路线的核心理由。5. 向 64 tok/s 冲刺细节参数与显存极限5.1 显存带宽才是 27B 模型的生死线先做一道简单的算术题。V100 32GB 的 HBM2 带宽是 900GB/s。27B 模型量化成 INT4 后权重体积大约 14GB。生成阶段每个 token 都需要把全部权重读一遍做矩阵向量乘法所以理论极限大概是900GB/s ÷ 14GB ≈ 64 token/s这个计算非常粗糙没考虑 KV cache 读取、激活值、kernel 开销但它给了一个关键结论64 tok/s 基本是 V100 跑 27B INT4 模型的物理天花板。你能看到 64 这个数字不是玄学是带宽算出来的。所以我调优的终极目标不是“把代码写的更花哨”而是让实际生成的 decode 流程尽量逼近这个带宽极限。只要权重没有全部驻留显存或者读取路径上有任何 PCIe 中转都会立刻掉出这个上限。5.2 KV Cache 瘦身与上下文长度控制很多人在 V100 上跑大模型习惯性把--max-model-len设成 32768觉得越长越高级。但在 V100 上这等于自杀。上下文越长KV cache 占用越大留给 batch 和权重操作的空间越小。我最终把--max-model-len控制在 4096。如果你主要做短对话、短摘要甚至可以压到 2048。这样 KV cache 节省下来的显存会让 vLLM 能同时容纳更多请求整体吞吐会更高。如果你的场景确实需要长上下文那 16GB V100 基本不用考虑老老实实上 80GB 卡。还有一个细节是 vLLM 的 KV cache block size默认是 16一般不需要动。但如果你发现显存利用率不高可以试试--block-size 8对小请求更友好但大请求时 block 数量变多管理开销也会增加。实测在我这个场景下默认值就好。5.3 采样参数与内核级别的选择叶子节点上的优化也不能忽略。--max-tokens输出长度上限会影响服务端一次推理 session 的行为但不会直接影响每 token 的速度。不过如果设置过短比如 32每次请求频繁结束和重建批处理总吞吐反而下降。--ignore-eos千万不要在生产环境开。这个参数会让模型无视结束符把你本来 100 token 的生成硬生生拉到 max_tokens等于把一个 100 token 的请求变成 512 token吞吐自然崩。--temperature、top_p这类采样参数不影响推理速度但对用户体验影响很大。低 temperature 适合稳定输出高 temperature 适合创意生成部署时按场景配好就行。另外vLLM 在 V100 上默认会尝试 capture CUDA graph。如果捕获成功解码路径会快一些但有时在 Volta 上容易失败遇到报错就加--enforce-eager。不过 eager 模式少了 graph 优化速度会掉 3~5%所以能不开就不开。我最终没有用--enforce-eagerCUDA graph 捕获一次成功后面的稳定生成速度才有 64。5.4 不同阶段的实测数据对比为了更清晰我把几个阶段的关键指标整理成一张表阶段单请求速度4 并发总吞吐首 token 延迟显存占用Transformers device_mapauto4 tok/s约 6 tok/s1.2s25GBllama.cpp GGUF Q4_K_M24 tok/s约 32 tok/s0.4s15.8GBvLLM GPTQ-Int442 tok/s约 65 tok/s0.22s30.2GBvLLM 上下文/拆批/KV调优64 tok/s约 81 tok/s0.18s30.6GB可以看到最大的跳变出现在“Transformers - llama.cpp”原因就是权重从 CPU 全部搬到了 GPU。之后 vLLM 接棒把调度效率继续往上推。最后一轮调到 64其实就是在接近带宽极限的情况下把其它开销降到最低。5.5 最终生产配置参考放一下我最后落地的配置方便直接抄vllm serve ~/models/Qwen2.5-27B-Instruct-GPTQ-Int4 \ --gpu-memory-utilization 0.95 \ --max-model-len 4096 \ --tensor-parallel-size 1 \ --quantization gptq \ --enable-chunked-prefill \ --port 8000这个配置下我压测单请求流式输出稳定在 63~65 tok/s偶尔冲到 68。四个并发请求时整体吞吐在 80 tok/s 出头。V100 的温度稳定在 80 度左右风扇转速略高但还在安全范围。如果你手里的 V100 是 16GB 版本这套配置需要改一下--gpu-memory-utilization 0.9--max-model-len 2048并且要把量化档压缩到更小的 Q4_0 或 GPTQ-Int4 且 group_size 更小。16GB 显存跑 27B 非常勉强但短上下文下也不是完全不行只是并发能力会弱很多。6. 常见问题与避坑指南6.1 CUDA Out of Memory 怎么办如果你在启动 vLLM 或 llama.cpp 时直接报 CUDA OOM大概率不是 GPU 显存真的不够而是参数设置不合理。按顺序排查第一步把--max-model-len降到 2048第二步把--gpu-memory-utilization从 0.95 降到 0.88第三步考虑换更小的量化档比如从 Q5_K_M 换到 Q4_K_M。如果这三个都试完还 OOM那就不是调参问题是卡真的装不下。6.2 生成速度突然掉到 1 token/s这种情况最常见的原因是某个请求把上下文拉得特别长长上下文导致 KV cache 增大进而触发了某种 fallback 或者内存换页。另外如果你开了 CPU offload速度也会掉成这样。排查时先看nvidia-smi的 GPU 利用率如果利用率很低但显存占满了多半是 CPU-GPU 传输在拖后腿。6.3 V100 上算子不支持或者编译失败vLLM 在 V100 上最怕两件事一是装了太新的 flash-attn二是装了和 CUDA 版本不匹配的轮子。我建议直接装官方给的匹配 CUDA 11.8 的 vLLM 版本不要追新。遇到编译 flash-attn 失败时可以用环境变量禁用export VLLM_ATTENTION_BACKENDFLASH_ATTN如果还是不行换XFORMERS后端。6.4 量化后生成质量明显下降质量下降是量化模型绕不开的代价。Q4_K_M 或 GPTQ-Int4 在多数任务上表现不错但如果你做的是数学推理、代码生成这类对“精确数值”很敏感的任务会明显感觉到差距。处理方法有两个一个是把量化档升到 Q5_K_M质量更好另一个是在 prompt 层面对思维链做更严格的引导。6.5 显存看着还有剩余但服务加载失败记住一件事vLLM 的--gpu-memory-utilization是让服务预分配显存不是按需分配。如果你nvidia-smi看到还有 10GB 空闲但 vLLM 报告无法分配内存多半是因为预分配值设太高超出了 CUDA 实际可用的连续显存。这种时候调低--gpu-memory-utilization到 0.90 就行别纠结为什么“还有空间却用不上”。结尾一些真实体会回过头看这次调优最有价值的认知是在 V100 这种老卡上跑 27B 模型第一优先级永远是“让权重完整驻留显存”其次是“选一个有连续批处理的推理框架”最后才是各种花里胡哨的采样参数。网上很多人一上来就研究 prompt 优化、量化技巧结果模型权重有一半在 CPU 里什么技巧都没用。另外我真心建议如果你也要做类似的事先把显存带宽这个账算明白。一张 V100 32GB 是 900GB/s一张 4090 是 1008GB/s一张 3090 是 936GB/s。老卡和老卡之间差异不大差的是你有没有发挥出它该有的水平。只要权重放得下、带宽吃得满27B 模型在老卡上跑到 64 tok/s 绝对不是天方夜谭。希望这篇实录能帮你把手上那块“吃灰卡”重新变成能打的生产工具。