V100跑27B大模型从4到64 tok/s：llama.cpp调优实录

说实话当同事把 Qwen 27B 的 GGUF 文件丢给我、让我用机房角落里那块 V100 跑起来的时候我第一反应是拒绝的。V100 是 2018 年的卡HBM2 显存没有 BF16 加速INT8/INT4 张量核心也指望不上怎么看都不是跑大模型的料。但现实问题摆在面前预算有限新卡迟迟批不下来而 V100 32GB 的显存又确实让人有点念想——27B 参数做 4bit 量化之后权重只有 15GB 左右32GB 好像真的装得下。结果大家应该猜到了第一版部署跑出来只有 4 tok/s。生成一句五六十个字的话要等十几秒别说给业务用自己调试都嫌闹心。后面我花了一周左右把模型从 Q8_0 换成 Q4_K_M把 offload 层数、KV cache 类型、上下文长度、batch size、编译参数一版一版调最后单流生成稳定在 60 到 64 tok/s。同一张卡、同一个模型纯靠部署和推理配置翻出了 16 倍的性能差距。这篇就是完整的调优实录希望能帮到手里有 V100、T4 这类老卡又想跑大模型的人。1. 项目概述与整体设计思路1.1 核心需求一张老卡能跑多大模型先算一笔显存账。27B 参数如果直接 FP16 加载权重就要 27×2 54GB这还没算 KV cache 和中间激活值。所以别指望原格式什么 40GB 显存的卡都不够用。要做部署第一步必须先压缩权重。4bit 量化之后权重体积大约 13.5GB 打底不同量化方案会再加一点 overhead。我用 GGUF 里的 Q4_K_M 档最终文件落在 15GB 左右。这时候 V100 32GB 就变得很香——权重吃 15GBKV cache 吃不到 2GBCUDA context 和计算缓冲再吃 1GB 多剩下的空间还够上下文拉长到 8K。说白了这个任务真正的难点不是“装不装得下”而是“装下之后能不能跑快”。V100 虽然老但它有 900GB/s 的显存带宽和 32GB 的大容量这两点恰好是推理部署最看重的。后面会看到只要把权重全部塞进显存这张老卡能爆发的速度相当可观。1.2 为什么最终选了 llama.cpp 作为主力框架部署大模型有很多条路我在 V100 上把主流方案基本都试了一遍。先说结论最后用的是 llama.cpp 的 llama-server。选它有三个原因。第一GGUF 量化格式在 4bit 下文件体积足够小显存账好算。第二它把显存使用拆得很细-ngl 控制 GPU 层数、-ctk/-ctv 控制 KV cache 精度、-fa 开关 flash attention适合在老卡上精打细算。第三它自带 OpenAI 兼容的 HTTP 接口接内部工具不用再写一层封装。vLLM 我也专门试过。连续批处理确实香但在 Volta 架构上当时很多算子编译不过要么退回老版本要么忍受各种警告折腾半天收益不明显。对小团队来说llama.cpp 的 --parallel 多槽位已经够用。这里放一张我当时做的方案对比省得大家再踩一遍方案V100 兼容性上手难度实测感受llama.cpp高源码编译指定 sm_70 即可低量化体系成熟显存控制精确transformers bitsandbytes一般4bit 在 Volta 上慢低能跑但速度拉胯vLLM一般部分算子需要新架构中并发调度好但 V100 上折腾ExLlamaV2支持但模型兼容性有限中速度快维护频率不如 llama.cpp所以我的建议很直接如果你手上的卡也是 V100 这种老架构优先考虑 GGUF llama.cpp先把链路跑通再去想更复杂的框架。1.3 性能目标与预期调优之前我给自己定了一个预期。单 token 生成这件事本质上就是把模型权重从显存搬到计算单元算一遍。27B 模型 Q4_K_M 量化后大约 15GBV100 32GB 的理论显存带宽是 900GB/s用 900 除以 15理想上限大概在 60 tok/s 左右。也就是说只要配置正确60 上下是一个合理的数字。后来实际跑出来的峰值 64、稳定 60跟这个估算对得上。这说明 V100 跑 27B 并不是不行关键是要用好它的带宽优势——量化、全 GPU、省显存就能逼近硬件极限。反过来如果这些配置没有做对比如权重大量在 CPU、量化档位太高跌到 4 tok/s 也是一点不奇怪。2. 部署步骤从零到能跑通2.1 环境准备与 llama.cpp 源码编译我这边系统是 Ubuntu 22.04驱动 535CUDA 12.2驱动自带不一定需要单独装。检查命令很简单nvidia-smi看到 Tesla V100 32GB 就行。然后装编译工具和依赖。sudo apt update sudo apt install -y build-essential cmake git git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURES70 -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j$(nproc)这里最关键的一个参数是 -DCMAKE_CUDA_ARCHITECTURES70。V100 的 compute capability 是 7.0如果你直接用官方提供的 release 二进制或者忘记指定这个参数让 cmake 去猜编译出来的内核可能不包含 sm_70轻则跑起来报错说找不到 kernel重则在你机器上以非常慢的通用内核在跑怎么调参数都没用。这个坑我吃过一次后面单独说。编译完之后可以用 llama-bench 快速验证 CUDA 是否真的生效./build/bin/llama-bench -m qwen27b-q4_k_m.gguf -ngl 99 -p 32 -n 128如果日志里能看到显存占用而且速度明显不是 CPU 那种个位数说明 CUDA 部分工作正常。顺便提醒一句如果服务器之前装过别的深度学习框架CUDA 版本可能很乱。我的建议是驱动版本尽量新一点535 以上CUDA 运行时不需要单独装llama.cpp 编译时只要保证 nvcc 能找到就行。2.2 模型获取与本地量化模型可以从 ModelScope 或 Hugging Face 上找 Qwen 27B 的开源仓库。注意我们这里需要的是原始 safetensors 格式而不是别人已经量化好的 GGUF因为我想自己控制量化档位。如果你懒得折腾直接下别人压好的 GGUF 也行但一定要确认量化类型和文件大小别下成 Q8 这种老大一个的文件。下载完先转 GGUF再量化。命令如下python3 convert_hf_to_gguf.py /data/models/Qwen27B \ --outfile qwen27b-f16.gguf --outtype f16 ./build/bin/llama-quantize qwen27b-f16.gguf qwen27b-q4_k_m.gguf Q4_K_M这里有个经验转换之前确认 Python 环境里有 torch 和 transformers版本别太老。转换过程会打印模型架构信息如果报 key 不匹配八成是原模型仓库里混了其他格式文件清理一下再转。量化档位的选择逻辑我列一个表方便对照档位27B 输出体积特点Q8_0约 28GB质量接近原版但 32GB V100 放完权重就没地方放 KV cacheQ5_K_M约 17-18GB质量更好显存 32GB 可全驻留Q4_K_M约 15GB体积/质量平衡这次的主力Q3_K_M约 12GB16GB V100 都得省着用质量有可见下降如果你手里的 V100 是 16GB 版本我的建议是别碰 27B老老实实跑 14B硬要上就得 Q3 量化和小上下文同时接受部分层 offload速度和效果都会打折扣。2.3 第一次启动显存、offload 与参数速查我一开始犯的错很有代表性。当时手上有一个 Q8_0 的 GGUF28GB32GB 显存理论上能塞下但塞完权重上下文就没了。于是我很保守地把 -ngl 设成了 20想着“让一部分层在 CPU另一部分在 GPU”。./build/bin/llama-server -m qwen27b-q8_0.gguf -ngl 20 -c 4096 --host 127.0.0.1 --port 8080结果就是 4 tok/s。为什么因为前 20 层在 GPU、剩下层在 CPU每一层生成完数据要在 PCIe 上来回搬CPU 推理本身的吞吐又低两头互相拖后腿。所以这才逼着我把量化档位换掉让权重足以整卡驻留。这里顺便把 llama-server 的常用启动参数解释一下后面调优都用得上参数作用-m模型路径-ngl放到 GPU 的层数-1 或 999 表示尽量全放-c上下文长度-ctk / -ctvK/V cache 的精度类型如 f16、q8_0-b / -ub最大 batch 和上限 batch-fa启用 flash attention--parallel并行槽位数用于多人同时请求记住一个排查套路看启动日志。llama.cpp 启动时会打印 offloaded 了多少层、KV cache 多大、总显存用了多少。如果 offloaded 层数不是模型全部层数说明显存不够机器把剩下的层放到了 CPU速度大概率不好看。3. 性能调优从 4 到 64 的完整路径3.1 第一板斧把层全部塞进 GPU调优的第一个动作是不跟显存较劲直接换 Q4_K_M。Q4_K_M 的 27B 文件大概 15GB32GB V100 放权重加 KV cache 都还有富余。于是 -ngl 直接拉满./build/bin/llama-server -m qwen27b-q4_k_m.gguf -ngl 99 -c 4096 --host 127.0.0.1 --port 8080启动日志里变成 “offloaded 62/62 layers to GPU” 这种话我心里就有底了。这个改动带来的提升是决定性的从 4 tok/s 直接跳到 40 多 tok/s。为什么 -ngl 影响这么大llama.cpp 在 CPU 推理时用的是指令集优化过的 GEMM但 27B 模型的权重按 4bit 算也有 15GBCPU 内存带宽通常在 50GB/s 上下光读权重就要 15/50 0.3 秒也就是 3 tok/s 左右加上 GPU 层和 CPU 层之间的数据同步4 tok/s 就是这么来的。让权重全放 GPU 后读一遍只要 15/900 ≈ 0.017 秒理论 60 tok/s。同样是读权重带宽差了一个数量级。3.2 第二板斧量化档位与速度/质量平衡第一轮换成 Q4_K_M 后其实已经进入正常可用区间了但我还想往 60 以上够一够。于是把量化档位、KV cache、批处理参数逐个过了一遍。先说量化档位的实测。同样一个模型我分别用 Q4_K_M、Q5_K_M、Q8_0 做了生成速度对比上下文 4096KV cache 均为 q8_0模型档位显存占用单流生成速度Q8_0全 GPU 勉强权重 28GB cache45-50 tok/sQ5_K_M约 17GB55-58 tok/sQ4_K_M约 15GB60-64 tok/s注意一个反直觉的点Q8_0 权重更大每次生成都要读更多字节所以即便全 GPU 也不如 Q4_K_M 快。这非常符合带宽瓶颈的模型。4bit 量化损失的精度在问答和代码生成这种场景下多数用户体感不出来只有做严格评测或者处理逻辑特别绕的长文时差距才会显现。另外补一句很多人会问的V100 没有 INT8/INT4 张量核心GGUF 的 4bit 权重是不是反而吃亏实测下来并没有。llama.cpp 的实现是把 4bit 权重压缩存储、计算时反量化成 FP16 再算。计算量没少但省的是显存带宽——而 decode 阶段恰恰是带宽瓶颈。所以 V100 这种老卡用 4bit 量化的收益甚至比新卡更明显。打个比方厨师计算单元没换但传菜通道显存带宽压力小了整体出菜速度自然快了。3.3 第三板斧KV cache 与上下文参数接下来把 KV cache 从默认的 FP16 换成 8bit。命令里加两个参数-ctk q8_0 -ctv q8_0KV cache 存的是生成过程中反复读取的历史 token 对应的 Key 和 Value占显存的大小大约正比于层数、KV 头数、上下文长度。粗略估算公式是2K 和 V× 层数 × KV 头数 × 头维度 × 精度字节数 × 序列长度。27B 这代模型基本都是 GQA 结构KV 头数不会太多4096 上下文、FP16 下大概 1GB 多。看起来不多但你把精度换成 q8_0 后直接少一半再把上下文开到 8192 也不至于爆显存。然后是 -c 和 batch。我最终把上下文从 4096 提到 8192batch 设为 1024./build/bin/llama-server -m qwen27b-q4_k_m.gguf \ -ngl 99 -c 8192 \ -ctk q8_0 -ctv q8_0 \ -b 1024 -ub 1024 \ --flash-attn \ --host 0.0.0.0 --port 8080batch 调大主要影响 prefill 阶段也就是一次性把用户提问读完的速度。对 decode 生成影响有限但配合 flash attention长上下文的处理流畅度会好不少。V100 上 --flash-attn 是可以用的实测它的主要收益在 prefilldecode 提升有但不算大头。如果你的上下文经常拉得很长这个参数值得开。3.4 第四板斧并发与持续吞吐最后聊一下并发。64 tok/s 是单路请求的数字也就是一个人用觉得流畅。如果接一个小团队几个人同时用llama-server 的并发槽位要开起来--parallel 4开并发之后总吞吐就不是简单的 64×4而是多个请求共享显存带宽。实测在我的配置下4 个槽位同时在线总生成速度能到 100 多 tok/s单个人体感速度可能会降到 20-40 tok/s但对于内部工具来说依然够用。这里要区分两个概念单流延迟和系统吞吐。单流 64 tok/s 代表响应质量好系统吞吐大于 100 tok/s 代表多人同时用不排队。调优时如果只盯着其中一项很容易误判。比如一开始我看很多人说 vLLM 吞吐高就去试 vLLM结果在 V100 上各种算子不兼容最后发现 llama.cpp 已经能满足需求。3.5 从 4 到 64 的关键配置对照表把整个调优过程整理成一张表方便直接抄作业阶段模型档位关键参数单流 tok/s说明初始保守版Q8_0-ngl 20, -c 40964权重没全进 GPUCPU 拖后腿换量化全GPUQ4_K_M-ngl 99, -c 409640权重全进 GPU质的飞跃KV cache 量化Q4_K_M追加 -ctk/-ctv q8_050显存余量变大稳定性提升调上下文和batchQ4_K_M-c 8192, -b 102455-60prefill 改善长文更流畅最终版Q4_K_M追加 --flash-attn60-64接近 V100 带宽上限并发版Q4_K_M追加 --parallel 4总吞吐 100多人场景说实话从 4 到 64 这个 16 倍的跨度没有一步是玄学每一步都是把资源重新分配了一遍。4. 踩坑记录与常见问题排查4.1 CUDA 架构不匹配 / 找不到 kernel最典型的问题llama.cpp 编译时没有指定架构跑起来直接报 “no kernel image available”或者不报错但速度异常。解决办法就是回到 cmake 那步加上 -DCMAKE_CUDA_ARCHITECTURES70。检查方法编译完看运行时的 device info 日志。我建议所有 V100 用户把这点刻在脑门上这是 4 tok/s 和 40 tok/s 的最底层差距之一。4.2 显存看着够却 OOM / 层被挤回 CPU有一次我把 -c 开到 16384结果启动日志显示只 offload 了 40 层速度掉回 10 多。一查KV cache 在 FP16 下吃掉了 6GB 显存把权重挤得放不下了。所以调参要同步看几件事权重大小、KV cache 大小、CUDA context 大小。别只看 nvidia-smi 里还剩多少显存llama.cpp 启动日志里会直接告诉你会用多少显存以它为准。4.3 prefill 与 decode 速度分不清误以为慢交互式 API 返回的 tokens/s 往往是 prefill 和 decode 混在一起的平均值。如果用户输入长、生成长这个均值会很难看。正确做法单独测解码阶段的 tok/sllama-bench 会给两个数字prompt eval 和 eval生成。我调优时只看后者。如果你接业务更该关注的是首 token 延迟和生成阶段 tok/s而不是一个笼统的平均。4.4 BF16 在 V100 上的兼容问题现在很多新模型的权重是 BF16 导出的。V100 的 FP16 支持没问题但 BF16 不是它的强项个别工具链会直接报错或者跑出奇怪结果。解决办法是在转 GGUF 时就强制转成 FP16也就是 convert 命令里的 --outtype f16。另外如果你的模型文件混着多个精度llama.cpp 新版一般能自动处理但保险起见还是让它统一为 f16。4.5 常见问题速查表症状可能原因解决办法启动报 no kernel image availableCUDA arch 没包含 sm_70重新用 -DCMAKE_CUDA_ARCHITECTURES70 编译速度个位数大量层在 CPU、Q8 权重过大换 Q4_K_M-ngl 99OOM 或层被挤回 CPUKV cache 太大、上下文过长开 -ctk/-ctv q8_0减小 -ctokens/s 显示偏低平均了 prefill 时间用 llama-bench 单独看 decode模型转换报 key 不匹配仓库里文件不纯清理模型目录确认 safetensors多人用卡顿--parallel 没开加 --parallel N5. 这套调优思路可以迁移到哪些场景5.1 从 V100 到其他老卡同样的方法论可以直接复制到 T4、P40、甚至 RTX 3090 这类显存带宽差异很大的卡上。核心就一句话显存带宽除以量化后的权重体积就是 decode 的理论上限。T4 16GB 带宽 320GB/s跑 14B Q48GB 权重理论 40 tok/sP40 24GB 没有 FP16 加速跑 16bit 权重反而慢用 4bit 量化更合适。所以老卡并不可怕可怕的是用错了参数。5.2 从 27B 到更大模型如果你想跑 70B 级别Q4 量化后权重 40GB 左右一张 48GB 或 80GB 的新卡能全驻留32GB V100 就得部分 offload速度会在 10-20 tok/s 徘徊。做法还是老一套量化、全 GPU、省 KV cache。进一步还能用 llama.cpp 的多卡 split把模型切到两张 V100 上。只是要记住多卡之间的互联带宽一般远低于单卡显存带宽扩展效率要实测后再决定。5.3 先别急着换硬件把软件参数榨干这次调优给我最大的体感是对存量硬件先把能省的显存全省下来把权重尽可能留在 GPU是提升推理速度性价比最高的路径。V100 这种卡虽然不支持新特性但容量和带宽依旧是它的强势项正好适合做开源模型推理。如果你的业务并发不高、响应时间要求不极端把一块 32GB V100 调好完全可以顶一阵新卡的活。最后分享两个这次下来最有用的习惯。第一个调参前把当前环境拍个快照驱动、CUDA、llama.cpp commit、模型量化档位、启动参数全部记下来。我中间有个版本从 60 掉回 40排查半天才发现是系统自动更新动了 CUDA 库重装 llama.cpp 之后才恢复。第二个学会看 llama-server 的 /metrics调优时 tok/s、KV cache 用量、并发队列这些指标比什么都直观。把每次调整都落到数字上才能从 4 到 64 这样的跨度里找到真正的原因而不是靠玄学和运气。