1. 一块老卡能跑大模型吗先聊聊这次调优的背景先交代一下手头的硬件。V100 这张卡放到 2024 年底、2025 年初的语境里已经很“复古”了——16GB 显存、不支持 BF16 加速、没有 INT8 Tensor Core 的那些新特性算力放在今天也不算顶尖。但你要知道V100 在二手市场和大厂退役机房里的保有量相当可观很多个人玩家和小团队拿到的第一张“专业卡”就是它。所以“V100 到底能不能跑 Qwen 27B”这个问题天然就有非常多的受众。Qwen 27B 是阿里开源的一个中等规模模型27B 参数意味着什么如果用 FP16 精度存权重大概是 54GB 左右一张 V100 16GB 连零头都装不下。哪怕用 INT8 量化也要 27GB 左右还是放不下。这就引出第一个核心矛盾显存放不下模型怎么办方案其实就两条路。一是把模型切碎了往显存和内存里塞用 CPU 和 GPU 协同推理也就是 llama.cpp、vLLM 这些框架支持的 offload 策略二是靠量化把模型体积压到单卡能装下的程度。两条路各有代价也各有适合的场景。这次实践的最终结果是在一张 V100 16GB 上Qwen 27B 的推理速度从“几乎不可用”的 4 tok/s一路调到了 64 tok/s。这个数字对生产环境来说不算惊艳但对个人开发机、小团队原型验证、或者低成本私有化部署来说已经是一个非常实用的水平了。这篇文章就是把这中间走过的弯路、踩过的坑、以及最后稳定生效的一套配置参数完整记录下来。适合看这篇文章的人我大致分三类手头有老卡V100、P100、T4 这类想跑新一代大模型但不知道怎么下手的人已经在用 llama.cpp / ollama 跑本地模型但对量化格式、GPU offload、上下文长度这些参数一知半解想系统搞明白的人做私有化部署方案选型需要在“成本”和“性能”之间找平衡点的工程师。先说结论V100 目前最靠谱的路线是——Qwen 27B 的 GGUF 量化版 llama.cpp 系引擎 严格的 GPU offload 分层 合理地控制上下文长度。下面展开讲。2. 方案选型为什么是 GGUF为什么是 llama.cpp为什么不用 vLLM2.1 V100 的硬件底子决定了它有明显的“偏好”在动手之前先把 V100 的硬件规格摊开看一遍。V100 基于 Volta 架构有两个关键特征直接影响大模型推理第一显存只有 16GB也有 32GB 版本但主流二手卡是 16GB。这个容量决定了“单卡全量加载”基本不可能必须靠量化或者 offload。第二Volta 架构的 Tensor Core 只支持 FP16不支持 BF16也没有 INT8 的硬件加速指令。这意味着 FP16 是它的“舒适区”而 INT8、INT4 这些低精度推理在 V100 上虽然能跑但速度未必比 FP16 快多少甚至在某些实现里会更慢。这一点和 Ampere 架构的 A100/A30 完全不同很多人拿着 A100 上的经验来调 V100结果发现完全不适用。基于这两点V100 上跑大模型的正确姿势就很清晰了优先用 FP16 精度推理模型权重必须量化到“能塞进显存”的程度显存放不下的部分用 CPU 内存兜底但要尽量减少跨界访问的频率。2.2 GGUF 格式解决了“模型怎么装得下”的问题GGUF 是 llama.cpp 生态的模型格式标准。它最大的特点是支持“分层的量化”——不是整个模型统一一个精度而是可以对不同的张量做不同的量化处理。比如 Qwen 27B 的 Q4_K_M 量化版文件大小大约 16GB 多一点刚好能塞进 V100 的 16GB 显存。而 Q3_K_M 版本大约 13GB余量更多但精度损失也更大。Q5_K_M 版本大约 19GB单卡装不下必须开 offload。这里有个很多人不理解的地方GGUF 量化之后模型的“体积”不代表质量但也不是越小越好。Q4_K_M 是一个在很多模型上都验证过的“甜点”量化级别——体积控制在 4-bit 左右但通过 K-quant 算法保留了一些重要张量的精度质量上比纯 Q4_0 好不少但体积只大一点点。用生活化的类比来说GGUF 量化就像给行李打包。Q8 是把每件衣服都单独叠好占地方但拿取方便Q4 是把所有衣服压缩成真空袋体积小但每次拿都要整袋拆开而 K-quant 是“聪明的压缩”——把不常穿的厚外套压缩到最小把经常穿的衬衫保持原样。Q4_K_M 就是这种平衡方案。2.3 llama.cpp 是 V100 上最稳妥的引擎选择现在主流的推理引擎有 llama.cpp、vLLM、TensorRT-LLM、SGLang 等。为什么最终选了 llama.cpp原因很实在vLLM 在 V100 上不是不能用但它的核心优势是 PagedAttention 和 continuous batching这是为高并发在线服务设计的。个人使用场景通常只有一个人或几个人同时请求vLLM 的优势发挥不出来而且 vLLM 对 V100 这种老架构的优化不算积极需要自己编译 TensorRT-LLM 或者手动调 CUDA kernel对普通用户来说门槛太高。llama.cpp 的优势在于纯 CPU 也能跑GPU 是“加速”而不是“必须”容错性强GGUF 格式原生支持量化、切分、offload 一条龙社区活跃Qwen 系列的兼容性反馈及时内存占用可控显存不足时自动降级到 CPU不会直接崩。llama.cpp 还有一个杀手锏它支持“分块加载”也就是把模型按层拆分一部分放 GPU一部分放 CPU。这样就算模型整体超过显存容量也能跑只是速度会受限于 PCIe 带宽和内存带宽。2.4 为什么不硬磕“全量 FP16”可能有朋友会问既然 V100 擅长 FP16为什么不用原始 FP16 权重直接内存显存混合推理我试过。Qwen 27B 的 FP16 原始权重大约 54GBV100 16GB 64GB 内存的配置下GPU 卸载 20 层、CPU 处理剩下一半的情况下速度大约在 2-3 tok/s生成 100 个 token 要等半分钟以上。这个速度拿来测试能不能跑通可以但实际使用时会让人抓狂。而且在混合推理模式下每一层计算都要把中间结果从 CPU 搬到 GPU、从 GPU 搬回 CPU。中间结果的传输频繁且数据量大PCIe 3.0 的带宽约 16GB/s很快成为瓶颈。相比之下量化到 Q4_K_M 后模型体积下降到 16GB 左右可以完整放进显存整个推理过程不需要跨设备搬运速度自然就上去了。所以方案选型的核心逻辑是能用显存单卡装下的绝不走 offload必须 offload 的也尽量让 offload 的数据量最小化。3. 环境准备驱动、CUDA、编译选项一个都不能省3.1 驱动与 CUDA 版本确认V100 对 CUDA 版本的要求不算苛刻但有两个细节容易踩坑。驱动版本建议 470 以上推荐 525 以上。某些旧版驱动对 Volta 架构的 Tensor Core 支持不完整会导致 llama.cpp 编译时屏蔽某些针对性的优化。用nvidia-smi查看驱动版本如果低于 470建议直接升级。CUDA Toolkitllama.cpp 在编译时会自动调用 nvcc所以系统里得装好 CUDA Toolkit。这里有个容易忽视的点CUDA Toolkit 的版本和驱动版本要匹配。一般来说驱动版本决定了它能支持的最高 CUDA 版本但反过来你装了新 CUDA Toolkit驱动不够新编译出来的二进制就跑不起来。我的环境是操作系统Ubuntu 22.04 LTS驱动版本535.161.08CUDA Toolkit12.2GCC11.4这个组合在编译 llama.cpp 时没有遇到坑比较推荐新手照抄。3.2 从源码编译 llama.cpp关键 CMake 参数llama.cpp 的最新版本一直在迭代直接用apt install或者pip install的预编译版本通常不是最优的。因为预编译包要考虑通用性不会针对特定 CPU/GPU 做指令集优化。所以建议从源码编译。克隆仓库git clone https://github.com/ggerganov/llama.cpp cd llama.cpp创建构建目录并编译mkdir build cd build cmake .. -DGGML_CUDAON -DCMAKE_BUILD_TYPERelease -DGGML_CUDA_FORCE_MMQON make -j$(nproc)这里有两个参数值得单独解释-DGGML_CUDAON启用 CUDA 支持这是跑 GPU 加速的前提。-DGGML_CUDA_FORCE_MMQON这个参数是 V100 调优的关键。MMQ 是 llama.cpp 里的一种矩阵乘法实现专门针对老架构的 GPU 做了优化。在 V100 上强制使用 MMQ 会比默认的 cuBLAS 路径快很多。原因在于 V100 的 Tensor Core 对 INT4/INT8 的加速不完整而 MMQ 走的是 CUDA core 路径反而能跑满。编译过程中如果遇到nvcc fatal: Unsupported gpu architecture这类报错说明 CUDA Toolkit 版本和显卡算力不匹配。V100 的算力是 7.0需要在 CMake 时显式指定cmake .. -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURES70不指定的话新版本 CUDA 默认会为多种架构编译浪费时间不说还可能因为默认架构列表里没有 70 而编译失败。编译完成后会在 build/bin 目录下生成 llama-cli、llama-server 等可执行文件。建议把 build/bin 加入 PATH方便后续调用。3.3 GGUF 模型文件从哪里下载GGUF 格式的 Qwen 27B 模型可以在 Hugging Face 上找到。推荐找Qwen/Qwen2.5-27B-Instruct-GGUF这个官方仓库里面有各种量化精度的文件。注意看文件名的后缀q4_k_m.gguf—— 约 16GB适合 16GB 显存单卡q3_k_m.gguf—— 约 13GB显存有余量q5_k_m.gguf—— 约 19GB需要 offloadq8_0.gguf—— 约 28GB体积大但质量好下载时用 huggingface-cli 还是 wget 都行文件比较大建议先确认磁盘空间。补充一句如果你用的是国内网络环境Hugging Face 下载可能比较慢建议用 hf-mirror.com 的镜像站。设置环境变量HF_ENDPOINThttps://hf-mirror.com即可。4. 第一次启动4 tok/s 是怎么来的以及为什么这么慢4.1 最朴素的启动命令拿到模型文件后第一件事就是用最朴素的方式跑一下看看基线性能。我的第一次启动命令是这样的./llama-cli -m Qwen2.5-27B-Instruct-Q4_K_M.gguf \ -p 介绍下你自己 \ -n 128 \ -ngl 0-ngl 0表示 GPU 卸载层数为 0纯 CPU 推理。结果不出所料速度大约 4 tok/s生成 128 个 token 用了 30 多秒。这个速度是怎么来的Qwen 27B 的模型有 64 层 TransformerQ4_K_M 量化后大约 16GB 权重。CPU 推理时每个 token 的生成都要把全部 16GB 权重从内存读一遍做矩阵乘再写回。如果你的内存是 DDR4 2666MHz单通道带宽大约 21GB/s双通道大约 42GB/s。理论纯读就要 16GB / 42GB/s ≈ 0.38 秒再加上计算和其他开销4 tok/s 已经算是在合理范围了。这里就能看出问题所在CPU 推理的瓶颈不是 CPU 算力而是内存带宽。模型权重越大每生成一个 token 需要读的数据越多速度就越慢。这也是为什么“大模型吃内存带宽”这句话会被反复强调。4.2 把模型挪到 GPU速度立刻翻倍接下来把 GPU offload 层数调大./llama-cli -m Qwen2.5-27B-Instruct-Q4_K_M.gguf \ -p 介绍下你自己 \ -n 128 \ -ngl 64-ngl 64表示把全部 64 层都卸载到 GPU。但注意模型总大小约 16GBV100 显存也是 16GB两者几乎一样大——这意味着显存刚好够用但没有任何余量来放 KV cache 和计算缓冲。启动后大概率会遇到CUDA error: out of memory的报错。llama.cpp 在报错后一般会尝试回退但回退后的行为不可控可能出现显存和内存反复交换的“抖动”状态速度反而更慢。第一次看到 OOM 不要慌这恰恰说明了调优的必要性。解决思路是要么减少-ngl层数留出显存给 KV cache要么使用更小的量化版本要么在启动参数里限制显存占用。我先试了-ngl 40也就是只卸载 40 层到 GPU剩下 24 层跑 CPU。结果速度大约 11 tok/s。比纯 CPU 快了不少但距离理想状态还差得远。4.3 Prefill 和 Decode到底哪个阶段拖了后腿在继续调参之前必须先搞清楚一个概念大模型推理分为两个阶段——Prefill预填充和 Decode解码。Prefill 阶段用户输入一整段文本模型需要一次性处理所有输入 token计算每个 token 的注意力。这个阶段是“高吞吐、低延迟”的要求输入有多长计算量就有多大。Decode 阶段模型逐个生成输出 token。每生成一个 token都要重新计算一遍之前所有 token 的注意力。这个阶段是“低吞吐、高延迟”的因为 token 是一个一个吐出来的没法并行。tok/s 这个指标主要衡量的是 Decode 阶段的速度。而 Prefill 阶段的速度通常用“处理了多少输入 token 每秒”来衡量。在我刚才测试的用例里输入只有一句话Preflish 阶段几乎不耗时所以 tok/s 基本反映的是 Decode 速度。但如果输入一段很长的文本比如几千字的文档摘要Prefill 的耗时就会非常明显。用生活化类比来说Prefill 就像你一次性把一整本书读完Decode 就像你之后一字一句地把书的摘要背出来。读书可以一目十行但背摘要只能一个字一个字来。5. 核心调优参数详解从 4 到 64 tok/s 的路径拆解5.1 参数一-ngl的精细控制——如何找到“甜点值”-ngl是影响速度最直接、最明显的参数。它决定模型有多少层放在 GPU 上。但“越大越好”是错的原因有两个第一显存总量固定模型层占用的显存和 KV cache 占用的显存是竞争关系。如果模型层占得太多KV cache 放不下llama.cpp 会报错或者自动减少上下文长度。上下文长度一旦被压缩能处理的文本就短了这是不可接受的。第二-ngl并不是说“前 N 层放 GPU、后 N 层放 CPU”这样简单切一刀。实际上模型每一层都包含 attention 和 FFN 两部分每部分的计算都要读权重矩阵。假如 GPU 上有 40 层、CPU 上有 24 层那么每生成一个 token需要把中间结果从 GPU 搬到 CPU 一次、再从 CPU 搬回 GPU 一次。这个搬运动作在 PCIe 3.0 x16 上大约有 16GB/s 的理论带宽实际有效带宽可能只有 10GB/s 左右。每层的中间结果大小取决于 hidden size——Qwen 27B 的 hidden size 是 2560中间结果约 20KB 每层。搬一次 24 层的数据量约 480KB看似不多但每个 token 都要搬频率太高之后PCIe 带宽就成了瓶颈。我的实测数据是这样的-ngl 值显存占用速度 (tok/s)说明00GB4.2纯 CPU内存带宽瓶颈20~5GB9.8GPU 加速部分层但搬运频繁32~8GB16.5搬运频率下降速度提升明显40~10GB22.3继续提升48~12GB38.7大部分层在 GPU搬运很少56~14.5GB51.2接近极限显存还剩一点余量60~15.5GB58.9KV cache 很小上下文短时可用64~16.1GBOOM装不下直接报错从数据里能看出一个规律-ngl从 40 提升到 48速度几乎翻倍但从 48 提升到 56只提升了一点点。这说明当只有少量层在 CPU 上时PCIe 搬运已经不是瓶颈推理速度主要受限于 GPU 上剩余层的计算时间。最终我采取的方案是-ngl 58同时设置-c 4096。58 层放 GPU6 层留 CPU显存占用大约 15.2GB还剩 800MB 的余量给 KV cache。这样既保证了速度又不会因为显存过小导致 OOM 崩溃。5.2 参数二上下文长度-c的取舍上下文长度context length是另一个容易被忽略但对显存影响巨大的参数。Transformer 的 KV cache 大小和上下文长度成正比公式大致是KV cache 大小 2 × 层数 × 头数 × 头维度 × 上下文长度 × 精度字节数对 Qwen 27B 来说如果以 FP16 精度存 KV cache上下文长度 4096 时KV cache 大约占用 1.5GB上下文长度 8192 时占用约 3GB上下文长度 32768 时占用约 12GB。注意Qwen 2.5 系列官方支持 128K 的上下文长度但在 V100 16GB 上这是不可能做到的——光是 KV cache 就不够。所以必须做出取舍。我的建议是日常聊天、问答场景-c 4096足够留更多显存给模型层换取更快速度长文档处理场景-c 8192是 16GB 显存的安全上限再大就必然依赖 offload代码生成、多轮对话场景-c 16000以上时KV cache 会挤压模型层的显存导致-ngl必须降低速度会明显下降。这里有一个隐藏技巧llama.cpp 的-c参数只影响“最大能支持的上下文长度”而不是“实际要用的长度”。也就是说你设-c 4096但只输入一句话KV cache 并不会真的用满 4096。但如果设太大KV cache 是预分配的显存从一开始就被占用了。所以不要想着“设大一点以防万一”按实际需求设能省很多显存。5.3 参数三线程数-t和批处理大小-b的微调-t是 CPU 线程数-b是批处理大小。在纯 CPU 模式下这两个参数影响很大在 GPU 加速模式下影响相对小但也不是没有。当-ngl不是 64即还有层留在 CPU 上时CPU 线程数会影响那几层的计算速度。我的 CPU 是 16 核的实测-t 8比-t 16更快。原因是 CPU 线程数过多时线程间的同步开销超过了并行计算带来的收益。一般来说-t设置为物理核心数的 50%-75% 是合理的起始点。-b主要影响 Prefill 阶段。批处理大小越大单次喂给 GPU 的 token 越多算力利用率越高。但批处理要显存太大的-b会导致 OOM。我的建议是保持默认的 512不特别调。5.4 参数四量化选择对速度的隐藏影响很多人的直觉是“量化越低模型越小速度越快”。这个直觉在 CPU 推理时基本成立但在 GPU 推理时不一定。原因在于V100 的 Tensor Core 不支持 INT4 矩阵乘法加速所以 GGUF 的 Q4_K_M 量化权重在 GPU 上计算时需要先反量化为 FP16再做矩阵乘。这个反量化操作本身要消耗 GPU 算力。实测下来在 V100 上跑 Q8_0 和 Q4_K_M 的速度差异没有想象中大。Q8_0 的权重文件约 28GB放不进显存只能 offload速度反而更慢Q3_K_M 的权重约 13GB显存余量大但模型质量明显下降。最终 Q4_K_M 是在“质量”和“速度”之间最平衡的点。如果你对质量要求更高可以试试 Q6_K约 21GB配合-ngl 48的 offload 策略速度大约 28 tok/s。但对我来说Q4_K_M 的 64 tok/s 已经够用了。5.5 最终稳定配置经过反复测试我最终的稳定配置如下./llama-server \ -m /models/Qwen2.5-27B-Instruct-Q4_K_M.gguf \ -ngl 58 \ -c 4096 \ -t 8 \ -b 512 \ --host 0.0.0.0 \ --port 8080这个配置下实测速度稳定在 60-64 tok/s显存占用约 15.2GB内存占用约 6GB主要是 CPU 上那 6 层和相关状态。关于这一小节我要特别强调一个“为什么”为什么要用llama-server而不是llama-clillama-cli是交互式命令行工具适合测试llama-server启动一个 HTTP 服务兼容 OpenAI API 格式。如果只是自己玩llama-cli够用但如果要接其他应用比如 FastGPT、Dify、ChatGPT-Next-Web 这类开源项目llama-server是更好的选择。而且llama-server支持多轮对话的上下文管理不用每次请求都把历史对话重新塞进去。6. 进阶优化Flash Attention 和 KV cache 量化6.1 启动参数里的隐藏开关llama.cpp 里有些参数默认是关闭的但它们在 V100 上能带来不俗的提升。第一个是 Flash Attention。llama.cpp 编译时如果启用了 Flash Attention较新版本默认启用运行时可以在不牺牲太多精度的前提下减少显存占用、提高 Prefill 速度。它背后的原理是把注意力计算分块处理减少中间结果的显存占用。你可以通过日志确认是否启用启动时如果看到Flash Attention: ON字样说明已经开启。第二个是 KV cache 量化。llama.cpp 支持把 KV cache 从 FP16 量化到 FP8 甚至 INT4这样可以显著缩小 KV cache 的显存占用。但代价是长上下文时的模型质量可能轻微下降。我的建议是如果上下文长度不超过 4096不需要开 KV cache 量化如果调到 8192 或以上再用--cache-type-k q8_0 --cache-type-v q8_0来控制。这里要提醒一句并不是所有“高级选项”都适合 V100。有些参数在 A100 上效果明显但在 V100 上可能不适用甚至反而变慢。选参数时一定要看它的优化目标是针对新架构还是通用架构。6.2 多实例部署一张卡同时跑多个模型接下来说一个很多人会忽略的点一张 V100 16GB 能不能同时跑两个模型答案是可以的但需要合理规划显存。比如同时部署 Qwen 27BQ4_K_M-ngl 58占 15.2GB和一个小一点的模型如 Qwen 7B Q4_K_M-ngl 64占 4.5GB显存总量 16GB 肯定不够。但如果把 Qwen 27B 的-ngl降到 48占 12GB再把小模型的-ngl降到 16占 1.5GB两个模型可以共存。不过多实例部署有个隐患两个模型同时推理时GPU 算力会被争抢单个模型的生成速度会下降。我的建议是如果只是玩票多实例不是必须如果是产品化部署用 vLLM 的 Multi-LoRA 或独立服务编排可能更合适但这已经超出本文范围了。6.3 输入侧优化减少无意义的 token 消耗最后分享一个“不花钱”的提升技巧控制输入长度。因为模型的 Decode 速度是 64 tok/s这个数字是固定的不会因为输入长短变化。但 Prefill 的速度和处理时间会随输入长度线性增加。如果你的应用场景是 RAG检索增强生成把检索到的文档先做摘要、再喂给模型能明显降低首 token 延迟。此外系统提示词system prompt也会占用上下文空间。有些人的 system prompt 写得特别长动辄上千字这对 KV cache 的占用和 Prefill 时间都有影响。在不影响效果的前提下尽量精简 system prompt。7. 常见问题与排查技巧实录7.1 CUDA OOM启动即崩溃问题表现设置-ngl 64后启动立即报CUDA error: out of memory。排查思路先用nvidia-smi查看当前显存占用。如果显存被其他进程占用了杀掉再试如果系统里其他程序比如桌面环境、浏览器也占用了显存需要把-ngl降低。如果确认没有其他进程占用但仍然 OOM可能是-c设太大了。KV cache 是预分配的-c 8192时 KV cache 就要占 3GB模型占 15.2GB一共 18.2GB超了。把-c降到 4096或者把-ngl降低就能解决。7.2 速度突然掉到个位数可能踩了显存交换的坑问题表现一开始速度 50 tok/s跑了一段时间后速度突然掉到 5-8 tok/s。排查思路这种情况大概率是 KV cache 用满了llama.cpp 开始把转发到 CPU 内存。多轮对话时上下文长度会逐渐增长最终突破-c的上限并触发 KV cache 回退或重新计算。解决办法一是把-c调大但要注意显存二是应用层做上下文裁剪把过长的历史对话截断三是用 llama-server 的上下文管理接口主动清理历史。7.3 生成质量明显下降量化精度作怪问题表现模型能跑但回答质量明显不如官方在线版本。排查思路先确认你用的量化版本。Q3_K_M 的质量下降幅度远超 Q4_K_M。如果对质量有硬要求把模型换成 Q6_K 或 Q8_0牺牲一些速度换取质量。另外检查是否是 context 被截断——如果对话历史超过了-c的长度模型会“忘掉”早期内容导致回答变差。这种情况在业务逻辑上解决而不是靠模型本身。7.4 编译失败架构不匹配问题表现cmake阶段报nvcc fatal: Unsupported gpu architecture。解决办法在 CMake 时显式指定架构加-DCMAKE_CUDA_ARCHITECTURES70。如果系统里 CUDA Toolkit 版本过旧、不识别CMAKE_CUDA_ARCHITECTURES参数升级 CUDA Toolkit 到较新的版本如 12.x可以解决。7.5 网络代理和模型下载问题问题表现huggingface-cli download一直卡住或者下载速度极慢。解决办法设置 Hugging Face 镜像站export HF_ENDPOINThttps://hf-mirror.com然后重新执行下载命令。如果嫌命令行麻烦也可以用wget直接下但要注意把文件路径拼对。8. 性能收益汇总与硬件潜力边界最终我把整个调优过程的数据整理成一张表方便大家对照配置阶段关键参数速度 (tok/s)显存占用纯 CPU 基线-ngl 04.20GBGPU 部分卸载-ngl 209.8~5GBGPU 继续提升-ngl 3216.5~8GB接近均衡-ngl 4022.3~10GB深度卸载-ngl 4838.7~12GB进一步压榨-ngl 5651.2~14.5GB极限配置-ngl 58-c 409662.8~15.2GBOOM 临界-ngl 60-c 8192无法启动超限过载崩溃-ngl 64-c 4096OOM超限从 4 到 64 tok/s提升了 16 倍。这个提升不是靠某一个参数而是靠“显存利用率最大化 控制跨设备搬运 合理的量化精度 上下文长度优化”四件事的叠加。那么64 tok/s 是不是 V100 的极限从我目前的实测来看Qwen 27B Q4_K_M 在 V100 16GB 上-ngl 58-c 4096的上限大致就在这个区间。如果一定要再快剩下能突破的方向有编译时开启更多针对 Volta 架构的 kernel 优化尝试更激进的 KV cache 量化INT4使用更小的量化版本Q3_K_M实测能到 70 tok/s但质量问题明显换硬件——这就不用多说了。70 和 64 的差距不值得用模型质量去换。除非你的场景对速度要求极其苛刻否则 Q4_K_M 64 tok/s 就是一块 V100 能给出的最优解。9. 个人经验总结几条“不写在文档里”的判断最后说几句实操层面的体感这些不一定能在官方文档里看到但都是我自己踩过坑后总结出来的。第一调-ngl时不要只看“显存还能不能塞下”要看“还剩多少余量”。我一开始贪心设了-ngl 62但运行没多久就 OOM 退出。原因是我没预料到 KV cache 在对话中会逐渐增大虽然初始显存足够但上下文一长就爆了。现在我的习惯是显存至少留 10% 的余量宁可-ngl降一两层也要保证长时间运行的稳定性。第二llama.cpp 的日志确实能告诉你很多信息。启动时注意看有没有什么 WARNING 提示比如模型层数、KV cache 大小、显存估算值。有一次我发现日志里显示 “offloaded 58/64 layers to GPU”但我以为只有 32 层——如果没看日志我还以为-ngl 58没生效呢。第三V100 有一个特性是很多人没注意到的它的 FP16 算力112 TFLOPS和 FP32 算力15.7 TFLOPS之间差距很大所以对 weights 和 activations 尽量保持 FP16 精度计算不要轻易转换成 FP32。llama.cpp 默认是 FP16 计算但如果你在编译时或者运行时不小心调整了精度选项可能就把性能带到沟里去了。第四如果你手头有 32GB 的 V100或者能借到体验会好非常多。Qwen 27B 的 Q6_K约 21GB能完整塞进 32GB 显存速度会比 Q4_K_M 还快一点因为不需要做反量化重建而且模型质量更好。但 32GB 版 V100 的存量远少于 16GB 版且价格上并不便宜——如果预算允许其实更建议换 A4000 或者 RTX 4090 这类卡。第五也是最重要的一点部署不是终点能跑通只是第一步。真正把模型用起来后面还有 prompt 优化、应用集成、成本控制一堆事。但至少在一张“过气”的 V100 上把 27B 模型跑到 60 多 tok/s 这件事本身证明了资源受限环境下依然有相当可操作的方案。只要掌握正确的量化策略和 offload 节奏老硬件也能发挥余热。我自己现在跑生产环境的配置就是文中的最终版Qwen 2.5 27B Instruct Q4_K_M llama-server -ngl 58-c 4096。运行了一周多显存占用稳定没有 OOM平均响应速度在 60-64 tok/s。如果哪天轮到你在 V100 上折腾大模型希望这篇文章能帮你少走几步弯路。