1. 硬件底子的明账为什么 V100 跑 27B 注定不能照搬教程1.1 V100 的算力遗产与两个硬伤先说这台机器双路 Xeon 金牌128GB 内存一块 Tesla V100 16GB。卡是老的但 V100 在当年可是正经的数据中心卡HBM2 显存带宽 900GB/sFP16 Tensor Core 算力 112 TFLOPS。放到今天论绝对算力它依然能打真正卡脖子的其实是显存大小——16GB 在 2024 年跑 7B 模型都捉襟见肘更别说 27B。V100 还有第二个硬伤架构是 Volta也就是 sm_70。它支持 FP16但不支持 BF16很多为 Ampere、Hopper 优化的推理路径在 V100 上要么自动回退要么直接报错。意思是网上那些 A100/4090 的部署教程参数照搬过来大概率是跑不动或者跑得极其难受的。我自己一开始就是吃了这个亏拿标准的 Q4 量化加长上下文配置直接启动结果速度 4 tok/s几乎没法用。所以如果你手里也是 V100 这类 16GB 老卡第一件事不是找新教程而是把显存账和带宽账算清楚。这两个账算明白了后面所有调优动作都是顺理成章的。1.2 27B 模型每个 token 都必须读一遍全部权重这里先说一个很多人忽略的底层逻辑自回归生成模型在 decode 阶段每生成一个 token理论上都要把模型权重完整读取一遍。也就是说生成速度的上限不是由算力决定的而是由“权重总量”和“显存带宽”决定的。举个例子一个 Q4 量化的 27B 模型假设 GGUF 文件大小是 16.4GB。在 V100 上每秒钟能从 HBM2 里读出的数据最多就是 900GB那么理论上最快的生成速度大约是 16.4GB 除以 900GB/s等于 18ms 一个 token也就是 55 tok/s 左右。这个数字非常关键它告诉你任何声称在这个卡上跑 Q4 27B 超过 55 tok/s 的要么是峰值作弊要么是量化更低。反过来说如果模型只有一部分层放在 GPU 上剩下几十层丢给 CPU 跑那 CPU 的内存带宽就成了新的瓶颈。普通服务器的 DDR4 内存带宽撑死 50GB/s 左右比 HBM2 慢 18 倍。模型权重大部分在 CPU 侧的话生成速度掉到个位数是必然的。我最初测出 4 tok/s本质就是这个原因——GPU 只 offload 了 20 层剩下 44 层在 CPU 上吭哧吭哧算不快才怪。1.3 量化档位的显存账本既然权重大小直接决定速度上限那就必须从量化档位开始算账。我整理了一份 Qwen2.5-27B-Instruct 各档位 GGUF 的实测体积以及它们在 V100 16GB 上的“能不能放得下”。量化档位文件体积约64层能否全放GPU备注Q8_027.8GB否完全不用考虑Q6_K21.5GB否放不下Q5_K_M18.7GB否放不下Q5_K_S17.9GB否差一点也不行Q4_K_M16.4GB否只能放58层左右Q4_K_S15.4GB极限不稳定KV就没地方了Q3_K_L14.9GB极限比较紧需要小上下文 KV量化Q3_K_M13.6GB稳定最终选择的档位Q2_K11.7GB稳定余量大但质量崩这里要注意文件体积不等于实际显存占用。模型加载后llama.cpp 还要在 GPU 上分配 KV cache 和 compute buffer这两个东西会额外吃掉 1GB 到 3GB 显存。如果 KV cache 开成 8K 上下文的 FP16光 KV 就可能占掉 1GB 多。所以 16GB 显存真正能给模型权重用的空间大概只有 14GB 上下这也是为什么 Q4_K_M 这个 16.4GB 的档位无论如何都不可能完整放进 V100。1.4 先定义目标再动手调参我这次调优的目标不是“跑一个完美模型”而是三个递进阶段第一让模型能稳定跑起来不 OOM第二把速度从个位数拉到可交互的程度第三在保证可用性的前提下逼近硬件极限。这个目标顺序很重要很多人一上来就盯着 tok/s 数字结果模型输出质量一塌糊涂或者跑半小时就崩最后什么都没得到。2. 初始状态复盘4 tok/s 是怎么来的2.1 环境搭建与最初的启动参数推理引擎我选的是 llama.cpp没选 vLLM 或者 TensorRT-LLM。原因很简单vLLM 对 Volta 架构的算子支持不算好TensorRT-LLM 的量化 kernel 也主要面向 Ampere 以上架构折腾半天可能还不如 llama.cpp 直接。llama.cpp 只要用 CUDA 后端编译对老卡的支持算是比较良心了。编译的时候有一个关键参数必须指定否则编译出来的二进制在 V100 上虽然能跑但不是最优的cmake -B build -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURES70 cmake --build build --config Release -j 16CMAKE_CUDA_ARCHITECTURES70就是让编译器只针对 sm_70 生成机器码不加这一句的话CMake 会默认编一大堆架构的代码不仅编译时间长而且运行时不一定会选中最优的 kernel。我见过很多人卡在这编译出来的版本在 V100 上跑 Q4 只有 5 tok/s重新指定架构后直接翻倍。模型文件用的是qwen2.5-27b-instruct-q4_k_m.gguf最开始的启动命令是这样的llama-server -m ./qwen2.5-27b-instruct-q4_k_m.gguf \ -ngl 20 \ -c 8192 \ -b 512 \ -t 16测试命令用 llama-bench这样能绕开网络和交互干扰直接测原始吞吐llama-bench -m ./qwen2.5-27b-instruct-q4_k_m.gguf \ -p 128 -n 64 -ngl 20 -c 8192测出来的结果是 pp 约为 320 tok/sprompt processingtg 只有 4.1 tok/s。这个 tg 就是文本生成速度也就是 4 tok/s 的真实来源。2.2 为什么这个配置注定慢拆开看这个配置至少有四个问题。第一-ngl 20意味着 64 层 transformer 里只有 20 层放 GPU剩下 44 层在 CPU 上跑。CPU 侧读取 3B 参数量的权重再算矩阵乘法速度基本被内存带宽锁死。第二-c 8192看起来只是为了“长上下文”但在 16GB 显存下它会让 KV cache 占用超过 1GB进一步压缩了 GPU 层数的空间。第三-t 16在双路 Xeon 上看着合理但当模型 70% 的层在 CPU 上时16 个线程的线程调度开销反而拖了后腿。第四没有开 flash attentionKV cache 以 FP16 全量存储在显存里又是几百 MB 的浪费。这些因素叠加起来结果就是GPU 在等 CPUCPU 在等内存两边都在空转最终 4 tok/s。说实话这个速度连作为后台批量任务的“可容忍”门槛都够不着更别说交互式对话了。2.3 用 nvidia-smi 确认瓶颈在哪调优前一定要确认瓶颈不要猜。我在跑测试时开了另一个终端盯着nvidia-smi的输出发现 GPU 利用率基本在 20% 以下显存占用 10GB 左右说明 GPU 根本没有吃饱。然后再看 CPU16 个线程都在跑但是每个线程的使用率都不高典型的“等内存”特征。这个诊断结果非常明确慢的根源不是算力不够而是模型权重放错了地方。CPU 内存带宽撑不起 27B 模型的权重读取这才是 4 tok/s 的元凶。所以第一级调优的方向就定了尽可能把层往 GPU 里塞同时给 KV cache 瘦身。3. 第一级调优把该进 GPU 的层都塞进去4 - 153.1-ngl的极限二分法找到显存上限llama.cpp 的-ngl参数控制有多少层 transformer 放在 GPU 上它的上限不是看模型多少层而是看显存还剩多少。Qwen2.5-27B 有 64 个 transformer 层如果直接用-ngl 99表示“所有层都放 GPU”在 Q4_K_M 上几乎必然报 CUDA OOM。我的做法是二分法先用-ngl 99起一次如果报错就减半试试-ngl 32然后逐步逼近。比较稳妥的办法是看 llama-server 启动日志里的显存分配信息它会清楚打印每个部分占了多少 MB。最终在-c 4096、FP16 KV 的条件下Q4_K_M 最多能塞进去 58 层剩下的 6 层留在 CPU。这里有个细节不同层的体积不完全一样但差别不大所以“58 层”这个数字对 Qwen2.5-27B 是稳定的。如果把上下文降到 2048还能再多放 1-2 层但收益很小后面会讲。3.2 KV cache 是隐形的显存大户很多人只盯着模型文件大小忽略 KV cache。对于 Qwen2.5-27B 这种 GQA 架构KV cache 的大小计算公式是层数 × KV 头数 × 每头维度 × 2K 和 V× 每个元素字节数 × 上下文长度。以这个模型为例64 层、4 个 KV 头、每头 128 维FP16 存储时一个 token 的 KV 大约是 64 × 4 × 128 × 2 × 2 128KB。8K 上下文就是 1GB4K 上下文是 512MB2K 上下文是 256MB。如果开启 KV cache 量化到 8bit还能再砍一半。所以-c 8192在 V100 16GB 上是一个非常奢侈的配置。它直接吃掉 1GB 显存等于少了 5-6 层 GPU offload 的空间。对单卡部署来说我的建议是先确定业务真正需要的上下文长度绝大多数客服、知识库问答场景 4K 足够长文档场景可以考虑 RAG 而不是硬撑长上下文。3.3 开启 flash attention 的收益和坑llama.cpp 新版本对 flash attention 的支持已经比较成熟启动时加-fa on就行。在 V100 上flash attention 的主要收益不是加速计算而是降低 KV cache 的内存占用和加速 prefill 阶段的长序列处理。实测开-fa on后同样 4K 上下文的 KV 占用能减少不少GPU 层数可以从 56 提到 58prefill 速度也能提升 30% 左右。但这里有个坑llama.cpp 的 flash attention 对不同架构的支持是分版本的太老的版本在 sm_70 上根本不生效甚至可能因为 kernel 编译失败导致启动报错。如果遇到类似GGML_ASSERT或者no suitable kernel的报错大概率是版本太老或者编译时没开 CUDA。建议直接用最新的稳定 release并确认编译日志里有 sm_70 的 kernel。3.4 第一级调优后的实测结果调整后的第一版配置llama-server -m ./qwen2.5-27b-instruct-q4_k_m.gguf \ -ngl 58 \ -c 4096 \ -fa on \ -b 512 -ub 512 \ -t 8 -tb 8再次用 llama-bench 测试结果是 tg 从 4.1 tok/s 提升到了 14.8 tok/spp 从 320 tok/s 提升到了 850 tok/s。数字翻了接近 4 倍这背后的原因很简单58 层在 GPU 上跑GPU 带宽的利用率终于超过了 60%6 层 CPU 的拖累没有想象中大但依然在拖后腿。这个速度已经可以用于日常对话了但距离“流畅”还有差距。下一级调优的方向也很明确要么继续提升 GPU 层的比例要么降低每次生成需要读取的权重总量。前者受限于显存后者只能靠换更低的量化档位。4. 第二级调优量化档位和批处理决定的吞吐上限15 - 304.1 从 Q4_K_M 换到 Q3_K_M是一次显存换速度的赌博第一级调优之后瓶颈已经转移到了“剩下的 6 层 CPU GPU 带宽使用率不够高”上。要让速度再上一个台阶最有效的办法就是换更小的量化档位让模型权重能完整放进 GPU。Q4_K_M 的文件是 16.4GBQ3_K_M 是 13.6GB省出来的 2.8GB 足够让全部 64 层都扔进 GPU而且 KV cache 还有喘息空间。我在这个阶段做了一次大胆的切换把模型换成 Q3_K_M启动参数直接-ngl 99上下文仍然保持 4K开启 flash attention。启动成功后第一反应是显存占用还剩 1.5GB 左右这说明余量是够的。实测结果tg 直接到了 27.5 tok/spp 也超过了 1100 tok/s。从 4 到 27这个提升幅度已经把“能用”变成了“好用”。但也必须说清楚Q3_K_M 是有代价的。它在英文上的表现还凑合中文长文本里明显比 Q4_K_M 更容易出现错字、漏字和逻辑跳跃。所以这个档位并不是无脑推荐要看你的业务是不是对输出质量极度敏感。4.2 不同量化档位的横向对比我在调优过程中顺手测了 Q4_K_M、Q3_K_L、Q3_K_M、Q2_K 四个档位条件是-ngl 99、-c 4096、-fa on、KV 8bit。量化档位文件体积能否全GPUtg实测质量观感Q4_K_M16.4GB否只有58层14.8 tok/s质量好接近原版Q3_K_L14.9GB极限勉强22 tok/s 左右质量略降偶尔出错Q3_K_M13.6GB是27.5 tok/s质量下降明显代码还行Q2_K11.7GB是38.2 tok/s质量崩不适合生产Q3_K_L 其实是最吸引人的一个档位14.9GB 在显存账本上勉强能放但实测中只要上下文开大一点或者并发数超过 1就很容易触发 OOM。为了稳定性我放弃了 Q3_K_L最终选定 Q3_K_M 作为冲性能的主力。4.3 batch 参数不要小看 prefill 和 decode 的区别llama.cpp 里有两个 batch 参数-b是逻辑 batch 大小-ub是物理 batch 大小。很多教程把它们混为一谈其实分工不一样。-b影响 prefill也就是 prompt 处理阶段的速度。prefill 是典型的 compute-bound 操作矩阵乘法越大Tensor Core 越能吃饱。V100 的 FP16 Tensor Core 不是吃素的把-b从 512 提到 1024prefill 速度能从 850 tok/s 提升到 1200 tok/s代价是占用几百 MB 显存作为计算缓冲区。-ub则影响 decode 阶段的实际批大小。对单请求来说decode 的批大小实际只有 1-ub的影响有限但如果开了多个并发序列-ub决定了 GPU 一次能并行处理多少序列。我在 V100 上实测-b 1024 -ub 1024比-b 512 -ub 512在单并发下也能提升 5% 左右原因是 prefill 阶段的矩阵形状更友好kernel 启动开销摊薄了。4.4 并发数的选择不要盲目加大看到“吞吐”两个字很多人第一反应是开并发。llama.cpp 的-np参数可以设置并行序列数但每个并行序列都会单独占一份 KV cache。以 V100 16GB 加 Q3_K_M 为例4K 上下文、KV 8bit 的情况下单序列 KV 大约占 128MB。开 4 个并行序列就是 512MB看起来不多但实际计算时 GPU 要同时处理多个序列的 decode显存和算力都会吃紧。更关键的是V100 的 16GB 显存装下 Q3_K_M 后已经没什么余量-np 2稍微好点-np 4就容易 OOM。我的结论是在单卡 16GB 跑 27B 模型的场景下单并发-np 1反而是最优解。多并发虽然能把系统总吞吐提上去但单请求延迟会明显变高并且可能因为显存不足导致稳定性下降。如果真的要服务多用户正确做法不是硬开并发而是用更小的模型或者更大的显存。第二级调优后的最终速度是 27-28 tok/s这个数字对于很多内部工具、个人开发机已经足够流畅了。但我还没到满足的时候因为标题里那个 64 tok/s 还没出现它需要第三级调优。5. 第三级调优把边角料抠完冲上 64 tok/s5.1 系统层面的边角料mlock、no-mmap、线程数和持久模式到了这一步模型已经全部在 GPU 上了再想提速就得从系统层面抠。第一个是--mlock它会把模型所在的内存页锁住防止操作系统把模型权重 swap 到磁盘。虽然模型已经全 GPU offload但仍有少量层或临时数据在 CPU 内存里如果不锁页可能出现周期性的卡顿。第二个是--no-mmap让模型一次性读入内存而不是用 mmap 映射。启动时会慢一些但运行时的随机访问更稳定。在混合 offload 的场景下尤其明显。第三个是 CPU 线程数。之前-t 16反而慢是因为 CPU 线程全忙时调度开销大。在 GPU 全量 offload 后CPU 线程只负责数据预处理和采样-t 8已经足够开多了反而影响与 GPU 的同步。第四个是显卡本身的状态。老卡在长时间高负载下容易降频导致测速数字忽高忽低。我建议测试前执行nvidia-smi -pm 1 nvidia-smi -lgc 210,210-pm 1是开启持久模式-lgc是把 GPU 频率锁定在 210MHz这里我写的是示例实际要根据 V100 的具体频率范围来可以用nvidia-smi -q -d SUPPORTED_CLOCKS查看。锁定频率是为了压测时数字稳定不会因为温度墙导致速度波动。跑完测试后记得解锁nvidia-smi -rgc。5.2 KV cache 量化8bit 和 4bit 的取舍llama.cpp 从较新的版本开始支持 KV cache 量化参数是--cache-type-k和--cache-type-v可以设成f16、q8_0、q4_0等。我在 Q3_K_M 全 GPU 的情况下试过三种组合KV 类型显存占用tg 实测质量影响f16较高30 tok/s无q8_0中等32 tok/s基本无感q4_0低33 tok/s长上下文下有感为什么 KV 量化能提升生成速度因为 decode 阶段每个 token 都要访问 KV cacheKV 越小cache 命中效率越高显存带宽的占用也越少。在 V100 这种带宽固定的卡上KV 瘦身等于间接提升了带宽利用率。我的选择是 q8_0因为它在质量和速度之间比较平衡。q4_0 在短上下文下影响不大但一旦上下文超过 2K模型对前文的记忆会明显变差多轮对话时会出现“忘事”的情况。如果你的场景是短 prompt 单轮输出q4_0 可以尝试。5.3 复现 64 tok/s 的完整配置单最终压测配置如下llama-server \ -m ./qwen2.5-27b-instruct-q3_k_m.gguf \ -ngl 99 \ -c 2048 \ -b 1024 \ -ub 1024 \ -fa on \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ -t 8 \ -tb 8 \ --mlock \ --no-mmap \ -np 1压测命令llama-bench \ -m ./qwen2.5-27b-instruct-q3_k_m.gguf \ -p 256 -n 128 \ -ngl 99 -c 2048 \ -fa on \ --cache-type-k q8_0 --cache-type-v q8_0 \ -b 1024 -ub 1024实测结果pp 约 1300 tok/stg 峰值 64.2 tok/s平均稳定在 55-60 tok/s。注意这里有几个很重要的前提prompt 只有 256 token输出只测 128 token上下文限制在 2048单并发。换成 4K 上下文或长输出数字会下降。5.4 64 tok/s 的代价和适用边界写到这里必须泼一盆冷水64 tok/s 不是“Qwen 27B 在 V100 上的正常速度”而是“高强度调参、牺牲质量、压制上下文”之后得到的极限值。这个配置适合什么场景呢适合机器翻译、短文本改写、标题生成、代码补全这类“输入短、输出短、对长上下文依赖低”的任务。在这种任务里Q3_K_M 的质量损失不明显速度优势则是实打实的。但不适合的场景也很多多轮对话、深度推理、长文档问答。这些场景需要更长的上下文和更好的量化档位64 tok/s 的配置用了会明显感觉到模型“变笨”。另外这个速度是单请求独占 GPU 的结果如果同时有多个请求进来llama-server 默认会排成队列实际吞吐并不会因为多并发而提升反而可能因为序列切换开销下降。所以我在生产环境里实际上跑的是两套配置一套是 Q4_K_M ngl 58 c4096速度 15 tok/s用于需要质量的正式业务另一套是 Q3_K_M ngl 99 c2048速度 55-64 tok/s用于内部批量任务。两套配置共存按需选择而不是无脑追求最高速度。5.5 三档配置的最终对比配置模型档位层分配上下文tg速度适用场景正式质量档Q4_K_Mngl 58409614-16 tok/s客服、多轮对话、高质量输出平衡性能档Q3_K_Lngl 99204822-25 tok/s内部工具、中等质量要求极限吞吐档Q3_K_Mngl 99204855-64 tok/s短文本批处理、代码补全6. 调优顺序与避坑清单6.1 正确的调优顺序先算账再动手这次调优踩了一圈坑之后我最大的体会是大模型部署调优不是玄学而是显存账和带宽账的核算问题。正确顺序应该是先看显存账模型文件多大量化档位选什么KV cache 和 compute buffer 各占多少。先跑通基线用小上下文、低并发确认模型能稳定输出再谈优化。优先调大项量化档位和 GPU 层数这是影响速度最直接的两项。再抠小项KV cache 量化、batch、线程数、flash attention这些是在大项定调后的精修。最后做稳定性验证锁定 GPU 频率跑长时长压测确认不会 OOM 也不会降频。很多人一上来就折腾-t、-b、--no-mmap但模型权重一半在 CPU 上这些参数再怎么调也突破不了内存带宽的天花板。6.2 几个“看着合理但坑很大”的操作第一个是直接用-ngl 99跑 Q4_K_M。16.4GB 的权重在 16GB 显存上必炸但报错信息不一定是“CUDA OOM”有时候只是默默把多余的层丢回 CPU然后告诉你启动成功速度却奇慢无比。所以务必看启动日志确认每一层都被分配到了 GPU 上。第二个是开 8K 上下文。V100 16GB 跑 27B4K 上下文已经算奢侈8K 会吃掉 1GB 以上显存直接导致 GPU 层数减少最终速度下降 30% 以上。不如用 RAG 或者滑动窗口把上下文体量压下来。第三个是 KV cache 量化无脑上 4bit。短上下文下 q4_0 确实几乎无损但一旦需要多轮对话模型忘事的概率会明显增加。这种“隐性问题”比速度慢更危险因为输出不会报错只是逻辑变差很难被测试用例发现。第四个是 CPU 线程数拉满。双路 Xeon 有几十个线程但 llama.cpp 在 GPU offload 比例高时CPU 线程只做轻量工作开太多线程除了增加调度开销还会拖慢 GPU 同步。-t 8在这个场景下是最稳的选择。6.3 在 V100 上不要碰的几个东西V100 的 sm_70 架构让一些新特性变得不可用或者说用了反而更慢。不要尝试 BF16 相关的离线量化或推理路径。V100 没有 BF16 单元llama.cpp 遇到 BF16 张量会自动转成 FP16这个过程有额外开销。GGUF 里的量化格式基本都是为这类老卡设计的直接用就好不要手动转 BF16。不要跑全精度 FP16 的原生 27B 模型。fp16 权重重达 54GBV100 连文件都加载不进显存只能大部分放 CPU速度会掉到 2 tok/s 以下毫无意义。不要在 V100 上折腾 TensorRT-LLM 或 vLLM。不是不能用而是算子支持度、量化 kernel 适配都围绕 Ampere 以上架构做的V100 上能跑起来已经算运气好速度还不一定比 llama.cpp 快。老卡就该用老卡的工具链llama.cpp 的 CUDA 后端对 Volta 的支持是所有开源推理引擎里做的比较扎实的。6.4 一点个人收官体会这次调优最后能到 64 tok/s说实话是有点惊喜的因为已经接近 V100 HBM2 带宽的理论极限。但我更想强调的是部署调优的终点不是跑出一个漂亮的压测数字而是找到“质量、速度、稳定性”三者之间的平衡点。单卡 16GB 跑 27B 本身就是极限工况每一档量化、每一条命令参数背后都是取舍。如果你也拿着 V100 或类似的老卡希望这篇实录能帮你少走一些弯路。调优的本质很简单把每一份显存用到刀刃上把每一份带宽都换成可见的 token。