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

手里这块 V100 16G是朋友从机房退役的库存卡拿到手我第一反应就是“捡到宝了”。结果真拿它跑 Qwen 27B 大模型时差点被 4 tok/s 的速度气到砸键盘——一个字一个字往外蹦后台请求队列慢到像是上世纪拨号上网。折腾完一个周末之后同一块卡同一个模型稳定跑到了 64 tok/s翻了 16 倍。这篇文章不是什么理论推演就是我把这块老显卡从“只能看不能用”调到“日常聊天完全流畅”的完整实录。内容比较适合手里有 V100 / P100 / T4 这类老卡、又想本地跑 27B 级别大模型的朋友关键是你不需要换硬件只靠部署方式、量化格式和几个参数的组合就能把性能榨出来。1. 先搞清楚瓶颈V100 跑 27B 为什么只有 4 tok/s1.1 先算一本显存账Qwen 27B 这个规模的模型FP16 权重体积大约在 54GB 左右。V100 16G 只有 16GB 显存所以第一步就排除了“直接上原版模型”这个选项量化是必须走的路。社区常用的 Q4_K_M 量化等级27B 模型文件大约 17GB看着接近 16GB 了但它还是比显存大。很多人就在这里踩了第一个坑认为 17GB 和 16GB 差不多强行让推理框架启动结果模型的一部分层被放到内存里跑另一部分层留在显存里跑。这一放速度就完蛋了。因为 GPU 在生成每个 token 时需要按顺序过完模型的所有层。如果其中一部分层在 CPU 上那么每一轮生成都得让 CPU 算完那几层再把中间结果通过 PCIe 传回显存。V100 的 PCIe 接口通常在 3.0 x16理论带宽约 16GB/s听起来不低但 CPU 上做量化权重的反量化、矩阵运算实际性能比 GPU 慢一到两个数量级。于是整个推理过程就像一条流水线上混进了两个“手工工位”其他环节再快也没用整体节奏被拖到 4 tok/s 是很正常的。除了权重显存里还要放 KV cache、CUDA context、临时激活值。KV cache 这块特别容易被忽视。如果部署时把上下文长度拉到 32KKV cache 会吃掉好几个 GB。显存总共就 16GB这里多占一点那里就少一点最后能放进 GPU 的模型层数更少CPU offload 的层数更多。很多人跑得慢不是模型的问题而是显存里塞了太多“辅助设施”把本该属于权重的位置挤掉了。1.2 4 tok/s 出现的典型场景我复盘了一下刚开始跑出 4 tok/s 时的环境其实配置很“典型”直接拿 Ollama 拉了一个 27B 的量化模型默认设置启动上下文长度没动内存 64GB 足够大系统没有 swap 压力。按理说这个组合能跑但速度就是惨不忍睹。原因在于 Ollama 这类封装工具为了“开箱即用”显存分配策略非常保守。它看到模型文件比显存大就默认只把一部分层放到 GPU。而由于 KV cache 默认分配得很大实际能放进 GPU 的层数比想象中还少。我用nvidia-smi看了一眼显存占用 13GB但其中一半以上是 KV cache 和框架缓存真正装载模型权重的显存空间很小于是大量层留在了 CPU 上。日志里显示 offload 到 GPU 的层数只有一半左右。这里要额外解释一个关键认知大模型生成 token 的过程其实绝大多数时间都在做“逐 token decode”也就是根据已经生成的上下文一次只预测下一个 token。这个阶段对显存的读取带宽要求极高对 GPU 算力的需求反而没有想象中大。所以只要模型权重没有完全放进显存哪怕 CPU 和 GPU 之间的传输只占一层整体速度也会被拖累得极其明显4 tok/s 就是这么来的。注意并不是显存占用高就代表模型在 GPU 上跑得快。要看“模型层是否完整在 GPU 里”重点看推理日志中的 offload 层数而不是单纯看nvidia-smi的显存占用数字。2. 部署方案选型为什么最终回到 llama.cpp2.1 Ollama、vLLM 的排除逻辑很多新手第一个想到的就是 Ollama因为它一条命令就能把模型跑起来。我承认 Ollama 在“快速体验”这个场景下无敌但到了需要精细控制显存分配时它就有点不太够用。Ollama 对显存的管理是黑盒策略虽然新版本可以通过环境变量做一些调整但能够控制的粒度仍然有限。我在调优过程中需要精确掌握“哪一层放 GPU、哪一层放 CPU、KV cache 占多大”Ollama 给不了这种级别的操控感。vLLM 又是另一个极端。vLLM 的目标是高并发服务所以它默认会为 KV cache 预留一整块显存池这在 A100 / H100 等大显存卡上很合理但在 16GB 的 V100 上就显得过于奢侈。用 vLLM 跑 27B 量化模型经常在启动阶段就提示显存不足即使勉强启动留给模型权重的空间也非常紧张。而且 vLLM 的部分算子对新架构做了深度优化Volta 架构V100 的 sm_70在新版本里的兼容性并不算好安装时就可能让你多掉几把头发。所以我的结论很直接单卡、低并发、要榨干性能老老实实用 llama.cpp 系列工具它才是老卡救星。llama.cpp 的好处首先是运行时开销极小对显存的利用是“按层精确控制”你可以通过参数明确告诉它“把能放的层全部放到 GPU”。其次它的量化体系是 GGUF 格式对 CPUGPU 混合推理处理得非常成熟。最方便的是它自带llama-server启动后就是标准 OpenAI 兼容接口日常开发完全够用。2.2 V100 老卡建议自己编译一次llama.cpp 官方提供了预编译包但我在 V100 上踩过预编译包的坑。因为预编译包经常为了兼容不同显卡把大量 CUDA kernel 都打进去反而在某些老架构上加载效率不高。更稳妥的做法是自己编译一次关键是设置好 CUDA 架构。git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURES70 cmake --build build --config Release -j 16这里的核心是-DCMAKE_CUDA_ARCHITECTURES70对应 V100 的 Volta 架构。不设置这个参数的话CMake 可能生成兼容多个架构的 fatbin编译时间变长不说运行时还可能加载到不适合的 kernel。如果照抄老教程可能会看到LLAMA_CUBLASON这种写法注意现在新版本已经改成GGML_CUDAON不要抄错。我用的 CUDA Toolkit 是 12.2编译过程中没有遇到难以解决的问题。如果你用的版本比较新出现了算子匹配报错建议退回 12.2 或 12.4老卡不需要追最新 CUDA。3. 从 4 到 64完整调参过程3.1 第一步换一个能全部进显存的量化格式Qwen 27B 无论 Qwen2.5 还是 Qwen3 系列显存账本都差不太多。社区默认推荐的 Q4_K_M 在这个场景下并不合适因为它 17GB 左右的大小刚好卡在 16GB 显存外面。调优的第一步就是把模型换成一个“能完整塞进显存”的量化版本。我实际对比过几种量化格式列成表大家看得更清楚量化格式约文件大小能否全放 V100 16G质量表现FP1654GB不能参考基准Q8_029GB不能接近无损Q5_K_M20GB不能很好但放不下Q4_K_M17GB边缘极易 OOM社区默认质量好Q4_K_S15.6GB可以质量略低于 K_M可接受Q4_015.1GB可以速度潜力高质量稍降IQ4_XS14.5GB可以余量充足质量稍降容量最小我最终选了 Q4_K_S。原因很简单它比 Q4_K_M 只小不到 2GB但就是这 2GB 决定了整个模型能否完整放进 V100。实际体验下来Q4_K_S 的回复质量在常规任务上肉眼几乎看不出和 Q4_K_M 的差距但推理速度却有本质区别。如果到手之后你发现显存还是紧张可以退回 Q4_0不过 Q4_0 的质量损失会更明显一些建议作为备选。注意下载量化模型时一定要确认它和模型原版的张量结构匹配社区里有些量化文件是个人转换的如果转换脚本有问题加载时会报张量名不匹配。选择官方仓库或高下载量的版本能省很多排查时间。3.2 第二步给 KV cache 腾地方权重换小了接下来要解决 KV cache 的问题。27B 模型默认支持很大的上下文但实际使用时往往用不到那么长。如果直接把上下文长度设成 32KKV cache 会以 FP16 格式占据 8GB 甚至更多显存这意味着哪怕权重只有 15.6GBKV cache 也会把显存撑爆模型层还是得往 CPU 上放。我的做法是先砍上下文。日常使用和开发测试8K 完全够用。如果只是做接口测试甚至可以压到 4K。这一步能把 KV cache 的显存压力降到一个很舒服的范围。接着再把 KV cache 本身量化掉。llama-server 提供了--cache-type-k和--cache-type-v参数可以分别把 key 和 value 缓存设为fp16、q8_0等格式。实测把这两个参数都设为q8_0KV cache 的显存占用直接减半而回答质量的损失几乎感受不到。很多大模型的 KV cache 量化实现已经比较成熟日常对话场景下完全可以直接开启。3.3 第三步完整启动命令与参数解释当权重和 KV cache 都瘦身完毕后启动命令就变得干净利落了。下面是我最终在用的./build/bin/llama-server \ -m models/qwen-27b-Q4_K_S.gguf \ -ngl 999 \ -c 8192 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ -b 2048 \ -ub 512 \ --threads 8 \ --host 0.0.0.0 \ --port 8080逐个说一下关键参数-ngl 999不是真的能放 999 层而是“能放多少放多少”llama.cpp 会从模型第一层开始一层一层往显存里填直到显存不够为止。在权重和 KV cache 都优化好之后这个参数能把所有层都塞进 GPU这是从 4 tok/s 到 60 tok/s 最关键的一步。启动时看到日志里出现类似offloaded 60/61 layers to GPU就说明全部层都进显卡了。-c 8192把上下文限制在 8K避免 KV cache 喧宾夺主。--cache-type-k q8_0 --cache-type-v q8_0量化 KV cache给显存留出更多余量。-b 2048和-ub 512是批处理参数对 Prefill用户输入处理阶段有一定影响对单用户场景影响不大保持这个值即可。--threads 8也是很多人误解的参数全 GPU 推理时它只影响 CPU 侧的调度开销不是越大越好设成 8 到 16 之间都行太大的话反而增加无谓的上下文切换开销。启动之后我在另一个终端里用nvidia-smi确认显存占用稳定在 15GB 左右日志中也没有出现 CPU offload 过多的警告这时候再测试速度已经能稳定跑到 64 tok/s 了。4. 实测数据与问题排查4.1 从 4 到 64 的调整记录我在调参过程中记录了每一轮关键配置下的实际数字整理成表方便参考阶段部署方案上下文/KV cachetg 速度显存占用说明初始Ollama 默认 27B默认 32KKV 大4 tok/s13GB但层只 offload 一半模型一半在 CPU速度崩盘尝试llama.cpp Q4_K_M32KKV 未量化启动 OOM-权重超出显存直接失败过渡llama.cpp Q4_K_S32KKV 未量化38 tok/s接近满层勉强放进去KV 挤到 CPU最终llama.cpp Q4_K_S8KKV 量化 q8_064 tok/s15.8G权重和 KV 全部在显存稳定第三行和第四行之间的差别就只差在“KV cache 从 FP16 变成 q8_0”和“上下文从 32K 降到 8K”这两步。很多人跑到 30 多 tok/s 就以为到头了其实 KV cache 省下来的显存足以让模型从“被迫 offload”变成“完全在 GPU 内”速度自然再上一个台阶。测试速度时我推荐直接用 llama.cpp 自带的llama-bench工具避免交互界面和网络开销干扰结果./build/bin/llama-bench -m models/qwen-27b-Q4_K_S.gguf -p 128 -n 64它会分别输出ppPrompt Processing也就是用户输入的处理速度和tgText Generation也就是生成速度两个指标。上面提到的 64 tok/s 指的是tg指标这才是日常对话中用户能感受到的“出字速度”。官方还提供了/metrics接口跑curl http://localhost:8080/metrics能看到推理耗时统计适合做长期监控。4.2 常见问题速查表我把调优过程中遇到的高频问题整理了一下方便后来者对照排查现象可能原因解决方案启动即显存不足CUDA OOM模型量化文件太大或上下文太长换 Q4_K_S / Q4_0把-c降到 4096开启 KV cache 量化速度卡在个位数 tok/s层未完全 offload大量计算在 CPU 上确认启动日志中的 offload 层数尽量让所有层进 GPU编译报错找不到 CUDACMake 没找到 CUDA Toolkit确认CUDA_HOME环境变量安装 CUDA 12.2 后重试预编译包运行慢包内包含大量兼容 kernel加载不合理自己编译并指定-DCMAKE_CUDA_ARCHITECTURES70GPU 利用率只有 20% 但速度正常decode 阶段本来就是带宽瓶颈不是算力瓶颈属于正常现象看 tok/s 而不是看利用率量化后回答质量明显下降Q4_0 等激进量化导致换回 Q4_K_S如果显存有冗余可以试 Q5_K_M需要牺牲速度还有一个细节很容易踩坑如果在 Windows 下用 WSL2 跑 CUDA 推理偶尔会出现显存识别不完整的问题这类问题排查起来非常消耗时间。我的经验是这种老卡调优最好直接在 Linux 裸机上做少一层虚拟化就少一堆玄学问题。如果你只有 Windows 环境建议优先用 WSL2 配合最新版 NVIDIA 驱动如果仍然异常可以尝试 Docker 容器但不要在一个方案上死磕太久。5. 再往下挖一层64 tok/s 为什么接近 V100 天花板5.1 decode 阶段真正的瓶颈是带宽很多人以为大模型跑得快不快取决于 GPU 算力FLOPS实际在“单个用户逐 token 生成”的场景下算力往往不是首要瓶颈。生成一个 token 时模型需要把所有权重从显存/HBM 中读取一遍。这个操作的成本直接和显存带宽挂钩。V100 16G 的 HBM2 显存带宽大约在 900GB/s 左右。我们当前用的 Q4_K_S 权重约 15.6GB理论上每秒最多能读取约 57 次完整权重也就是峰值大约 57 tok/s。实测能跑到 64虽然略高于这个粗略估算但考虑到读取过程中的缓存复用、算子优化和 KV cache 量化带来的带宽节省这个成绩已经很接近上限了。换句话说同样这块卡再往后调参能提升的空间非常有限64 tok/s 已经是 V100 在这个模型规模下的“舒适区尽头”。理解这一点对后续决策非常关键。如果你觉得速度还不够那问题已经不是“参数没调好”而是硬件本身的物理极限。这时候再去折腾量化精度、线程数、批处理大小收益会很低。继续压榨的方向只剩两种要么换带宽更高的卡A100、4090、L40S 这类要么在算法层面做文章。5.2 还想更快可以试试这些方向如果暂时不打算换卡可以考虑投机采样Speculative Decoding。思路是先用一个小模型快速草拟多个候选 token再由大模型一次性验证。因为验证阶段的矩阵是并行的整体生成速度能进一步提升。不过投机采样需要额外加载一个 draft 模型V100 的 16GB 显存空间是否够用就见仁见智了需要实测。另外一个方向是降低对话上下文。很多场景根本用不到 8K 上下文如果能压到 2K 或 4KKV cache 占用还能再降一点虽然对词生成速度影响不大但可以给显存留出更多缓冲避免长期运行时的碎片问题。再就是尝试不同版本的 llama.cpp新版在算子层面偶尔会有优化但老卡架构决定了大方向版本间的差异通常不会超过 10%。如果后续你打算把这套服务开放给团队里多个人用V100 单卡做并发会有些吃力。我自己的建议是保持 llama.cpp 的服务形态先顶着真正上量再考虑多卡推理或者换成支持大显存的设备。老卡的调优本质上是在“硬件上限”和“使用体验”之间找到最佳平衡点而不是追求无休止的更快。最后再分享一个我踩过几次的教训改配置后一定要先用llama-bench跑一轮基准测试再接入业务环境。我最早几次就是改完参数直接接客户端结果发现速度没提升又要回头排查是哪一项导致的问题。先跑基准再开服务能让你每一次调整都有明确的数据反馈不会在“感觉变快了”和“好像又没区别”之间反复折腾。