说实话看到“V100 跑 27B 大模型”这个组合大多数人的第一反应是“别闹了”。V100 是 2017 年的卡16GB 显存、不支持 BF16、第一代 Tensor Core放在今天连入门级消费卡都算不上。但我偏偏就是不信邪把 Qwen 27B 塞进去之后第一次实测只有 4 tok/s慢到让人想把卡直接挂二手平台。后来花了一个周末梳理整条推理链路从量化格式、推理引擎、编译参数到 KV Cache 精算一点一点把速度拉了上去短上下文场景下峰值能摸到 64 tok/s日常长文本也能保持在 50 tok/s 以上。这篇文章不是理论科普是我自己在 V100 上做 Qwen 27B 部署调优的完整记录。结论先放在这老卡跑大模型瓶颈从来不是算力而是显存带宽和容量之间的博弈。你能不能在 16GB 显存里塞下尽可能多的模型层能不能让每一层都在 GPU 上完成计算直接决定了你是 4 tok/s 还是 64 tok/s。1. V100 和 27B 模型这对组合为什么值得调1.1 V100 的“死穴”和“甜点”先说 V100 的短板避免有人被二手价格冲昏头脑。V100 发布于 Volta 架构时代计算能力 7.0这意味着它不支持 BF16 运算。现在很多新推理框架、新量化 Kernel 都默认走 BF16 或者依赖 Ampere 之后的特性拿过来直接在 V100 上跑要么报错要么悄悄回退到兼容路径性能根本发挥不出来。但 V100 有一个被严重低估的优点HBM2 显存带宽高达 900GB/s。这个数字到今天依然能打。推理阶段的生成速度尤其是自回归解码本质上是“每个 Token 都要把整个模型权重从显存里读一遍”所以显存带宽几乎直接决定了生成速度的物理上限。V100 的算力确实老了但它的带宽底子还在只要模型体积压得足够小、全部塞进显存它依然是一台单机推理小钢炮。1.2 27B 模型的显存账本27B 参数是什么概念我先把不同精度的体积列出来这是后面所有决策的基础。按 27B 参数规模估算存储格式典型体积16GB 显存是否能全放FP16约 54GB不可能INT8约 27GB不可能Q6_K约 21GB不可能Q5_K_M约 18GB不可能Q4_K_M约 16.8GB差一点放不下Q4_K_S约 15.8GB很勉强IQ4_XS约 14.5GB可以Q4_0约 14.2GB可以注意V100 标称 16GB 显存实际可用大概只有 15.5GB 到 15.7GB因为驱动和显示输出还要占掉一部分。所以 Q4_K_M 这种“看起来能装”的格式其实就差那一口气而这一口气在推理性能上的表现是断崖式的。1.3 64 tok/s 的物理极限在哪先算一笔账你就知道 64 tok/s 是什么概念。假设我们把模型压到 14GB 左右V100 的 900GB/s 带宽理论上每秒最多读取 900GB ÷ 14GB ≈ 64 次也就是 64 个 Token。这还没算 KV Cache 读取和激活值传输的损耗所以 64 tok/s 基本已经摸到这张卡的天花板了。我当时看到这个数字就知道调优目标不是“越快到 64 越好”而是“尽量逼近 64”。一旦理解了这条物理规律后面所有选择的逻辑都很清晰量化格式要选体积够小且能与显存完全匹配的推理引擎要能把每一层都扔进 GPU 的编译参数要针对 Volta 架构做专门优化。没有这个前提调参就变成瞎试。2. 基线 4 tok/s 复盘瓶颈卡在哪一层2.1 最初的部署方式我一开始偷懒直接用了 Ollama 拉模型命令很简单ollama run qwen2.5:27bOllama 会自动下载一个 GGUF 格式的模型默认量化等级大致相当于 Q4_K_M体积 16.8GB。它内部也有 GPU offload 的逻辑理论上能自动决定多少层放到显卡、多少层留在 CPU。听起来很美好但现实很骨感。第一次跑测试 Prompt速度只有 4 tok/s。我当时以为是模型质量问题后来用nvidia-smi一看GPU 利用率低得可怜显存占用 14.1GB而且 CPU 多个核心直接拉满。这明显是模型没有完全放进显存一部分层在 CPU 上跑。2.2 定位瓶颈的排查过程我把 Ollama 换成了 llama.cpp 原生命令行才看到关键日志。llama.cpp 加载模型时会输出类似这样的信息llm_load_tensors: offloading 48 layers to GPU llm_load_tensors: offloaded 48/64 layers to GPU只有 48 层进了显卡剩下 16 层留在 CPU。这意味着每生成一个 Token模型都要在 GPU 和 CPU 之间来回接力而且 CPU 算 27B 模型的速度本身就只有几个 Token 每秒整个链条就被最慢的一环拖死了。排查方法也分享给你。首先看显存如果模型体重 KV Cache 明显小于显存容量说明 offload 层数不够其次看 CPU 占用如果 CPU 满载而 GPU 空闲说明大量计算发生在 CPU最后就是看 llama.cpp 日志里的offloaded x/y layers直接告诉你答案。2.3 能跑不等于跑得动这次基线测试让我真正理解了“能跑”和“跑得动”的区别。Ollama 确实把这个模型“跑起来”了但 4 tok/s 的体验生成一句 20 个字的回复要 5 秒完全不可用。问题不在于 Ollama 本身而在于小显存场景下任何“自动决策”都可能选到最差的路径——16.8GB 的模型放不进 16GB 的显存自动 offload 策略就会把一部分层丢给 CPU性能瞬间崩盘。所以调优的第一步不是换引擎而是先把模型体积压到“能全量放进显存”的范围。这一步做对了后面才会有效果。3. 量化选型与显存精算决定速度上限的那一步3.1 量化格式实测对比量化是这次调优里最核心的一步。很多人以为量化只是省显存实际上它同时决定了你的模型能不能全部放进 GPU以及每一轮能分配多少上下文空间。我把几个候选格式都下载下来用同一段 Prompt、固定随机种子做了实测量化格式文件体积全量进 GPU 后显存余量生成速度短上下文质量体感Q4_K_M16.8GB不能全进12~15 tok/s最好Q4_K_S15.8GB仅剩约 0.2GB35~40 tok/s好IQ4_XS14.5GB约 0.8GB45~55 tok/s好Q4_014.2GB约 1.0GB峰值可达 60~64 tok/s可以接受这里有个反直觉的地方Q4_K_M 质量最好但因为它比显存可用空间多出 1GB 左右反而只能取得 12~15 tok/s 的成绩远不如体积更小的 IQ4_XS。质量再好速度慢到用不了等于白搭。3.2 KV Cache 与上下文长度的取舍模型权重之外KV Cache 是第二块显存消耗大户。KV Cache 的大小可以估算每个 Token 大约需要 2K 和 V 两个矩阵× 层数 × KV 头数 × head_dim × 2 字节。27B 级模型按 64 层、8 个 KV 头、head_dim 128 来算每个 Token 大约占用 256KB。2048 Token 上下文就是 512MB4096 就是 1GB8192 就要吃掉 2GB。所以在 16GB 显存里上下文长度不是一个随便调的参数而是和量化格式紧密绑定。我一开始天真地设了-c 8192结果 KV Cache 直接吃掉 2GB模型被迫从 Q4_K_S 降级到 IQ4_XS甚至部分层又要 offload 回 CPU速度反而掉下来。最终我把上下文控制在 2048。日常做单轮问答、代码片段生成、文档摘要完全够用而且 KV Cache 只占 512MB 左右留给模型权重的余量更充足。3.3 我为什么最终没有选 Q4_K_M这是我踩过最大的坑。Q4_K_M 在量化质量排行榜上口碑很好很多人推荐但它 16.8GB 的体积对 16GB 显存来说就是“差一点”。为了“质量更好”我强行用 Q4_K_M 并 offload 部分层到 CPU结果速度和全量 GPU 的 IQ4_XS 差了 3 倍以上。我的教训是小显存卡选量化格式第一优先级永远是“能不能全量进 GPU”而不是“谁的困惑度最低”。哪怕 IQ4_XS 的生成质量比 Q4_K_M 差一点点但速度从 12 tok/s 到 50 tok/s 的体验提升远大于那一点质量差异。真要追求质量不如换一个更大的显存卡。4. 引擎迁移与编译参数llama.cpp 在 V100 上的正确玩法4.1 从 Ollama 到源码编译 llama.cpp把量化格式换成 IQ4_XS 之后速度已经能到 45 tok/s 左右但离目标 64 tok/s 还有一段距离。这时问题出在推理引擎上。Ollama 虽然内置了 llama.cpp但它是预编译的二进制编译时没有针对 V100 的 sm_70 架构做专门优化很多 Kernel 只能走通用兼容路径。我直接下载 llama.cpp 源码在本地重新编译。这一步看着简单实际上对老卡提升非常明显因为你能控制架构参数、矩阵乘实现方式甚至选择性的开启或关闭某些特性。4.2 V100 专属编译参数编译命令如下cmake -B build \ -DLLAMA_CUDAON \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_CUDA_ARCHITECTURES70 \ -DLLAMA_CUDA_FORCE_MMQON cmake --build build -j --config Release这里两个参数很关键CMAKE_CUDA_ARCHITECTURES70明确告诉编译器只生成 V100 对应的机器码。如果不指定llama.cpp 会默认编译一大堆架构不仅编译慢还可能因为通用代码路径而损失性能。LLAMA_CUDA_FORCE_MMQON强制使用 MMQ 模式的矩阵乘法而不是走第一代 Tensor Core 的 MMA 路径。V100 的 Tensor Core 是初代产品实际计算效率并不高反而因为数据布局转换开销拖慢速度。MMQ 模式在我的实测下生成速度提升了约 15% 到 20%。4.3 运行时参数该省的省该关的关编译完成后我用 llama.cpp 的原生命令行开始了一次系统性的参数调整。最终运行的命令大致是这样./build/bin/llama-cli \ -m ./models/qwen2.5-27b-instruct-iq4_xs.gguf \ -ngl 99 \ -c 2048 \ -b 2048 \ -t 8 \ --temp 0.7 \ --top-p 0.8 \ --seed 42逐个解释为什么这么配-ngl 99把所有能 offload 的层全部放进 GPU99 表示“尽量全放”。这是拼命争取全量 GPU 推理的关键。配合 IQ4_XS模型 64 层全部进显存。-c 2048如前面所说控制 KV Cache 大小给模型权重留足显存余量。-b 2048Batch Size 设为 2048主要影响 Prefill 阶段也就是首 Token 生成前的整段 Prompt 处理能明显降低首 Token 延迟但对 Decode 阶段影响不大。-t 8CPU 线程数。全量 GPU offload 后CPU 只负责少量调度和采样8 线程足够。线程开太多反而增加调度开销。--temp 0.7 --top-p 0.8采样参数。调优过程中我固定了随机种子和采样参数保证所有对比都在同一条件下进行否则测试结果会被随机性污染。这里特别提醒一下我尝试开--flash-attn但在 V100 上不仅没有提升甚至出现了显存占用上升和偶尔卡顿。原因很简单Flash Attention 的主要优化目标是最新架构Volta 上的 Kernel 路径并不成熟有时候还会回退到更慢的实现。对我的场景来说关闭它反而更稳速度也能维持在理想区间。4.4 从 4 到 64 的完整推进过程我把整个调优过程的中间态整理成一个表方便你对照自己的部署卡在哪一步阶段部署方式生成速度基线Ollama Q4_K_M部分层 offload CPU4 tok/s换量化llama.cpp Q4_K_M最后 5 层仍在 CPU12~15 tok/s全量进 GPUllama.cpp Q4_K_S35~40 tok/s编译优化加上 sm_70 编译参数 MMQ 模式45~52 tok/s极限测试llama.cpp IQ4_XS/Q4_0短上下文峰值 60~64 tok/s看到这个递进过程你应该能明白64 tok/s 不是靠某一个神奇参数而是把“量化体积、显存容量、引擎优化、上下文长度”四件事同时做对的结果。任何一环掉链子最终速度都会被拖到 10 tok/s 以内。5. 预填充、投机采样与 ExLlamaV2还能再快一点吗5.1 Prefill 和 Decode 要分开看大模型推理有两个速度指标Prefill 速度和 Decode 速度。Prefill 是处理你输入的 Prompt 的速度Decode 是逐 Token 生成回复的速度。很多人调优只看一个“tok/s”容易被误导。实际上llama.cpp 的测速输出会分成两行prompt eval time 512 tokens, 0.8s (640 tok/s) eval time 128 tokens, 2.0s (64 tok/s)第一行是 Prefill第二行是 Decode。标题里的 64 tok/s 指的就是 Decode 速度这也是对话体验中最直观的“打字速度”。Prefill 速度在 V100 上通常能达到 600~1000 tok/s主要受算力和 Batch Size 影响和 Decode 的优化方向完全不同。调优时建议把两段指标分开记录否则你会出现“明明 Prefill 很快但整体体验还是很慢”的错觉。5.2 投机采样在 16GB 显存上是否可行理论上投机采样Speculative Decoding可以通过一个小草稿模型先预测多个 Token再用大模型验证达到“看起来更快”的效果。但这个方案在 16GB 显存上非常尴尬草稿模型至少要占 1~2GB 显存这会直接压缩主模型的可用空间迫使你降低量化等级或者牺牲上下文长度。我在 V100 上做过尝试结论是得不偿失。27B 级模型在 4-bit 量化下已经是显存占用的极限再塞一个草稿模型主模型质量和速度都会受损。除非你用的是 32GB 显存版本否则不建议在 16GB 卡上碰投机采样。5.3 ExLlamaV2 的备选方案我另外测试了 ExLlamaV2 引擎搭配 EXL2 格式。EXL2 的 4.0bpw 量化体积和 IQ4_XS 差不多但 ExLlamaV2 在 Volta 架构上有自己的 Kernel 实现某些场景下生成速度确实能逼近甚至略微超过 llama.cpp。不过它的生态没有 llama.cpp 丰富长上下文支持、API 稳定性、模型下载便利度都不如 GGUF 体系而且对某些老卡驱动版本比较挑剔。我的结论是如果你把一张 V100 当作纯实验玩具可以折腾 ExLlamaV2如果你想要一个稳定、可复现、能持续用下去的部署方案llama.cpp 仍然是更省心的选择。5.4 采样参数对体验的影响最后一个小点速度上去之后采样参数就变成了体验的主要影响因素。V100 的 64 tok/s 已经接近人眼阅读速度所以我把--temp调到 0.7--top-p调到 0.8让输出在“多样性”和“稳定性”之间平衡。温度太高容易输出跑偏太低又显得机械。这个不是性能问题但直接决定你能不能真正用起来。6. 最终方案、实测数据与踩坑记录6.1 最终配置一览经过整轮调优我最终保留了两套配置。日常使用用 IQ4_XS追求极限速度测试用 Q4_0。日常配置./build/bin/llama-server \ -m ./models/qwen2.5-27b-instruct-iq4_xs.gguf \ -ngl 99 \ -c 2048 \ -b 2048 \ -t 8 \ --temp 0.7 \ --top-p 0.8 \ --host 127.0.0.1 \ --port 8080这套配置下生成速度日常保持在 45~55 tok/s短上下文峰值能到 60 左右显存占用约 15.2GB剩余空间还能支撑一些临时激活值。极限测试配置./build/bin/llama-cli \ -m ./models/qwen2.5-27b-instruct-q4_0.gguf \ -ngl 99 \ -c 1024 \ -b 2048 \ -t 8 \ --temp 0.7 \ --seed 42把上下文压到 1024 之后显存余量更多生成速度峰值能摸到 64 tok/s。但实际使用中 1024 上下文太短所以这套配置只用来验证这张卡的极限。6.2 踩坑清单这次调优踩了不少坑列出来给你避雷别直接信任自动 offloadOllama 和部分框架的自动层分配策略对老卡非常不友好模型体积和显存容量接近时它们倾向于把一部分层放到 CPU结果就是速度断崖。手动指定-ngl永远更可控。别贪心上下文长度16GB 显存是硬约束上下文每翻一倍KV Cache 就多占几百 MB。我最后宁可牺牲上下文换全量 GPU 推理也不要 8192 上下文但速度只有 10 tok/s。别开 flash-attn在 V100 上收益为负属于新特性在老架构上的典型坑。别在加载阶段省内存如果模型文件在机械硬盘上加载会非常慢。建议先拷到 NVMe SSD 或直接用内存盘否则第一次启动会等到怀疑人生。注意散热和功耗V100 满载功耗 250W 到 300W我有一张卡跑高负载时温度接近 80 度核心降频导致速度从 60 掉到 50。后来把机箱风道重新理了一遍速度才稳定下来。6.3 这套方法论能不能迁移到其他卡能。我把这次调优的思路总结成一套通用流程先查显存带宽算出该卡的理论速度上限再对照模型量化体积表选出能“全量进显存 KV Cache 够用”的最小可行量化最后针对 GPU 架构做编译优化并在运行时逐个验证关键参数。这套流程对 T4、P40、A2 这些同样显存不大、架构偏老的卡完全适用。核心原则只有一句话先让所有计算发生在 GPU 上再谈算得快不快。否则再新的推理框架、再强的算法优化都救不回来“部分层在 CPU”的硬伤。我把这张 V100 折腾到能跑 27B 模型之后最大的感触是老卡不是不能用而是你得摸清它的脾气。V100 没有 BF16、Tensor Core 又是初代所有针对新架构的优化它都吃不上但只要抓住“显存带宽是瓶颈”这个本质把模型体积和显存容量精确匹配它照样能把 27B 模型跑到接近物理极限的速度。如果你手上也有一张吃灰的老卡或者正在纠结 16GB 显存能不能部署大模型我建议先别急着换卡按这篇文章的路径试一轮。跑通之后再回头看你会对“推理性能到底受什么约束”这件事有完全不同的理解。至于要不要继续上 32GB 显存、换更大模型那就是另一个故事了。
说实话看到“V100 跑 27B 大模型”这个组合大多数人的第一反应是“别闹了”。V100 是 2017 年的卡16GB 显存、不支持 BF16、第一代 Tensor Core放在今天连入门级消费卡都算不上。但我偏偏就是不信邪把 Qwen 27B 塞进去之后第一次实测只有 4 tok/s慢到让人想把卡直接挂二手平台。后来花了一个周末梳理整条推理链路从量化格式、推理引擎、编译参数到 KV Cache 精算一点一点把速度拉了上去短上下文场景下峰值能摸到 64 tok/s日常长文本也能保持在 50 tok/s 以上。这篇文章不是理论科普是我自己在 V100 上做 Qwen 27B 部署调优的完整记录。结论先放在这老卡跑大模型瓶颈从来不是算力而是显存带宽和容量之间的博弈。你能不能在 16GB 显存里塞下尽可能多的模型层能不能让每一层都在 GPU 上完成计算直接决定了你是 4 tok/s 还是 64 tok/s。1. V100 和 27B 模型这对组合为什么值得调1.1 V100 的“死穴”和“甜点”先说 V100 的短板避免有人被二手价格冲昏头脑。V100 发布于 Volta 架构时代计算能力 7.0这意味着它不支持 BF16 运算。现在很多新推理框架、新量化 Kernel 都默认走 BF16 或者依赖 Ampere 之后的特性拿过来直接在 V100 上跑要么报错要么悄悄回退到兼容路径性能根本发挥不出来。但 V100 有一个被严重低估的优点HBM2 显存带宽高达 900GB/s。这个数字到今天依然能打。推理阶段的生成速度尤其是自回归解码本质上是“每个 Token 都要把整个模型权重从显存里读一遍”所以显存带宽几乎直接决定了生成速度的物理上限。V100 的算力确实老了但它的带宽底子还在只要模型体积压得足够小、全部塞进显存它依然是一台单机推理小钢炮。1.2 27B 模型的显存账本27B 参数是什么概念我先把不同精度的体积列出来这是后面所有决策的基础。按 27B 参数规模估算存储格式典型体积16GB 显存是否能全放FP16约 54GB不可能INT8约 27GB不可能Q6_K约 21GB不可能Q5_K_M约 18GB不可能Q4_K_M约 16.8GB差一点放不下Q4_K_S约 15.8GB很勉强IQ4_XS约 14.5GB可以Q4_0约 14.2GB可以注意V100 标称 16GB 显存实际可用大概只有 15.5GB 到 15.7GB因为驱动和显示输出还要占掉一部分。所以 Q4_K_M 这种“看起来能装”的格式其实就差那一口气而这一口气在推理性能上的表现是断崖式的。1.3 64 tok/s 的物理极限在哪先算一笔账你就知道 64 tok/s 是什么概念。假设我们把模型压到 14GB 左右V100 的 900GB/s 带宽理论上每秒最多读取 900GB ÷ 14GB ≈ 64 次也就是 64 个 Token。这还没算 KV Cache 读取和激活值传输的损耗所以 64 tok/s 基本已经摸到这张卡的天花板了。我当时看到这个数字就知道调优目标不是“越快到 64 越好”而是“尽量逼近 64”。一旦理解了这条物理规律后面所有选择的逻辑都很清晰量化格式要选体积够小且能与显存完全匹配的推理引擎要能把每一层都扔进 GPU 的编译参数要针对 Volta 架构做专门优化。没有这个前提调参就变成瞎试。2. 基线 4 tok/s 复盘瓶颈卡在哪一层2.1 最初的部署方式我一开始偷懒直接用了 Ollama 拉模型命令很简单ollama run qwen2.5:27bOllama 会自动下载一个 GGUF 格式的模型默认量化等级大致相当于 Q4_K_M体积 16.8GB。它内部也有 GPU offload 的逻辑理论上能自动决定多少层放到显卡、多少层留在 CPU。听起来很美好但现实很骨感。第一次跑测试 Prompt速度只有 4 tok/s。我当时以为是模型质量问题后来用nvidia-smi一看GPU 利用率低得可怜显存占用 14.1GB而且 CPU 多个核心直接拉满。这明显是模型没有完全放进显存一部分层在 CPU 上跑。2.2 定位瓶颈的排查过程我把 Ollama 换成了 llama.cpp 原生命令行才看到关键日志。llama.cpp 加载模型时会输出类似这样的信息llm_load_tensors: offloading 48 layers to GPU llm_load_tensors: offloaded 48/64 layers to GPU只有 48 层进了显卡剩下 16 层留在 CPU。这意味着每生成一个 Token模型都要在 GPU 和 CPU 之间来回接力而且 CPU 算 27B 模型的速度本身就只有几个 Token 每秒整个链条就被最慢的一环拖死了。排查方法也分享给你。首先看显存如果模型体重 KV Cache 明显小于显存容量说明 offload 层数不够其次看 CPU 占用如果 CPU 满载而 GPU 空闲说明大量计算发生在 CPU最后就是看 llama.cpp 日志里的offloaded x/y layers直接告诉你答案。2.3 能跑不等于跑得动这次基线测试让我真正理解了“能跑”和“跑得动”的区别。Ollama 确实把这个模型“跑起来”了但 4 tok/s 的体验生成一句 20 个字的回复要 5 秒完全不可用。问题不在于 Ollama 本身而在于小显存场景下任何“自动决策”都可能选到最差的路径——16.8GB 的模型放不进 16GB 的显存自动 offload 策略就会把一部分层丢给 CPU性能瞬间崩盘。所以调优的第一步不是换引擎而是先把模型体积压到“能全量放进显存”的范围。这一步做对了后面才会有效果。3. 量化选型与显存精算决定速度上限的那一步3.1 量化格式实测对比量化是这次调优里最核心的一步。很多人以为量化只是省显存实际上它同时决定了你的模型能不能全部放进 GPU以及每一轮能分配多少上下文空间。我把几个候选格式都下载下来用同一段 Prompt、固定随机种子做了实测量化格式文件体积全量进 GPU 后显存余量生成速度短上下文质量体感Q4_K_M16.8GB不能全进12~15 tok/s最好Q4_K_S15.8GB仅剩约 0.2GB35~40 tok/s好IQ4_XS14.5GB约 0.8GB45~55 tok/s好Q4_014.2GB约 1.0GB峰值可达 60~64 tok/s可以接受这里有个反直觉的地方Q4_K_M 质量最好但因为它比显存可用空间多出 1GB 左右反而只能取得 12~15 tok/s 的成绩远不如体积更小的 IQ4_XS。质量再好速度慢到用不了等于白搭。3.2 KV Cache 与上下文长度的取舍模型权重之外KV Cache 是第二块显存消耗大户。KV Cache 的大小可以估算每个 Token 大约需要 2K 和 V 两个矩阵× 层数 × KV 头数 × head_dim × 2 字节。27B 级模型按 64 层、8 个 KV 头、head_dim 128 来算每个 Token 大约占用 256KB。2048 Token 上下文就是 512MB4096 就是 1GB8192 就要吃掉 2GB。所以在 16GB 显存里上下文长度不是一个随便调的参数而是和量化格式紧密绑定。我一开始天真地设了-c 8192结果 KV Cache 直接吃掉 2GB模型被迫从 Q4_K_S 降级到 IQ4_XS甚至部分层又要 offload 回 CPU速度反而掉下来。最终我把上下文控制在 2048。日常做单轮问答、代码片段生成、文档摘要完全够用而且 KV Cache 只占 512MB 左右留给模型权重的余量更充足。3.3 我为什么最终没有选 Q4_K_M这是我踩过最大的坑。Q4_K_M 在量化质量排行榜上口碑很好很多人推荐但它 16.8GB 的体积对 16GB 显存来说就是“差一点”。为了“质量更好”我强行用 Q4_K_M 并 offload 部分层到 CPU结果速度和全量 GPU 的 IQ4_XS 差了 3 倍以上。我的教训是小显存卡选量化格式第一优先级永远是“能不能全量进 GPU”而不是“谁的困惑度最低”。哪怕 IQ4_XS 的生成质量比 Q4_K_M 差一点点但速度从 12 tok/s 到 50 tok/s 的体验提升远大于那一点质量差异。真要追求质量不如换一个更大的显存卡。4. 引擎迁移与编译参数llama.cpp 在 V100 上的正确玩法4.1 从 Ollama 到源码编译 llama.cpp把量化格式换成 IQ4_XS 之后速度已经能到 45 tok/s 左右但离目标 64 tok/s 还有一段距离。这时问题出在推理引擎上。Ollama 虽然内置了 llama.cpp但它是预编译的二进制编译时没有针对 V100 的 sm_70 架构做专门优化很多 Kernel 只能走通用兼容路径。我直接下载 llama.cpp 源码在本地重新编译。这一步看着简单实际上对老卡提升非常明显因为你能控制架构参数、矩阵乘实现方式甚至选择性的开启或关闭某些特性。4.2 V100 专属编译参数编译命令如下cmake -B build \ -DLLAMA_CUDAON \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_CUDA_ARCHITECTURES70 \ -DLLAMA_CUDA_FORCE_MMQON cmake --build build -j --config Release这里两个参数很关键CMAKE_CUDA_ARCHITECTURES70明确告诉编译器只生成 V100 对应的机器码。如果不指定llama.cpp 会默认编译一大堆架构不仅编译慢还可能因为通用代码路径而损失性能。LLAMA_CUDA_FORCE_MMQON强制使用 MMQ 模式的矩阵乘法而不是走第一代 Tensor Core 的 MMA 路径。V100 的 Tensor Core 是初代产品实际计算效率并不高反而因为数据布局转换开销拖慢速度。MMQ 模式在我的实测下生成速度提升了约 15% 到 20%。4.3 运行时参数该省的省该关的关编译完成后我用 llama.cpp 的原生命令行开始了一次系统性的参数调整。最终运行的命令大致是这样./build/bin/llama-cli \ -m ./models/qwen2.5-27b-instruct-iq4_xs.gguf \ -ngl 99 \ -c 2048 \ -b 2048 \ -t 8 \ --temp 0.7 \ --top-p 0.8 \ --seed 42逐个解释为什么这么配-ngl 99把所有能 offload 的层全部放进 GPU99 表示“尽量全放”。这是拼命争取全量 GPU 推理的关键。配合 IQ4_XS模型 64 层全部进显存。-c 2048如前面所说控制 KV Cache 大小给模型权重留足显存余量。-b 2048Batch Size 设为 2048主要影响 Prefill 阶段也就是首 Token 生成前的整段 Prompt 处理能明显降低首 Token 延迟但对 Decode 阶段影响不大。-t 8CPU 线程数。全量 GPU offload 后CPU 只负责少量调度和采样8 线程足够。线程开太多反而增加调度开销。--temp 0.7 --top-p 0.8采样参数。调优过程中我固定了随机种子和采样参数保证所有对比都在同一条件下进行否则测试结果会被随机性污染。这里特别提醒一下我尝试开--flash-attn但在 V100 上不仅没有提升甚至出现了显存占用上升和偶尔卡顿。原因很简单Flash Attention 的主要优化目标是最新架构Volta 上的 Kernel 路径并不成熟有时候还会回退到更慢的实现。对我的场景来说关闭它反而更稳速度也能维持在理想区间。4.4 从 4 到 64 的完整推进过程我把整个调优过程的中间态整理成一个表方便你对照自己的部署卡在哪一步阶段部署方式生成速度基线Ollama Q4_K_M部分层 offload CPU4 tok/s换量化llama.cpp Q4_K_M最后 5 层仍在 CPU12~15 tok/s全量进 GPUllama.cpp Q4_K_S35~40 tok/s编译优化加上 sm_70 编译参数 MMQ 模式45~52 tok/s极限测试llama.cpp IQ4_XS/Q4_0短上下文峰值 60~64 tok/s看到这个递进过程你应该能明白64 tok/s 不是靠某一个神奇参数而是把“量化体积、显存容量、引擎优化、上下文长度”四件事同时做对的结果。任何一环掉链子最终速度都会被拖到 10 tok/s 以内。5. 预填充、投机采样与 ExLlamaV2还能再快一点吗5.1 Prefill 和 Decode 要分开看大模型推理有两个速度指标Prefill 速度和 Decode 速度。Prefill 是处理你输入的 Prompt 的速度Decode 是逐 Token 生成回复的速度。很多人调优只看一个“tok/s”容易被误导。实际上llama.cpp 的测速输出会分成两行prompt eval time 512 tokens, 0.8s (640 tok/s) eval time 128 tokens, 2.0s (64 tok/s)第一行是 Prefill第二行是 Decode。标题里的 64 tok/s 指的就是 Decode 速度这也是对话体验中最直观的“打字速度”。Prefill 速度在 V100 上通常能达到 600~1000 tok/s主要受算力和 Batch Size 影响和 Decode 的优化方向完全不同。调优时建议把两段指标分开记录否则你会出现“明明 Prefill 很快但整体体验还是很慢”的错觉。5.2 投机采样在 16GB 显存上是否可行理论上投机采样Speculative Decoding可以通过一个小草稿模型先预测多个 Token再用大模型验证达到“看起来更快”的效果。但这个方案在 16GB 显存上非常尴尬草稿模型至少要占 1~2GB 显存这会直接压缩主模型的可用空间迫使你降低量化等级或者牺牲上下文长度。我在 V100 上做过尝试结论是得不偿失。27B 级模型在 4-bit 量化下已经是显存占用的极限再塞一个草稿模型主模型质量和速度都会受损。除非你用的是 32GB 显存版本否则不建议在 16GB 卡上碰投机采样。5.3 ExLlamaV2 的备选方案我另外测试了 ExLlamaV2 引擎搭配 EXL2 格式。EXL2 的 4.0bpw 量化体积和 IQ4_XS 差不多但 ExLlamaV2 在 Volta 架构上有自己的 Kernel 实现某些场景下生成速度确实能逼近甚至略微超过 llama.cpp。不过它的生态没有 llama.cpp 丰富长上下文支持、API 稳定性、模型下载便利度都不如 GGUF 体系而且对某些老卡驱动版本比较挑剔。我的结论是如果你把一张 V100 当作纯实验玩具可以折腾 ExLlamaV2如果你想要一个稳定、可复现、能持续用下去的部署方案llama.cpp 仍然是更省心的选择。5.4 采样参数对体验的影响最后一个小点速度上去之后采样参数就变成了体验的主要影响因素。V100 的 64 tok/s 已经接近人眼阅读速度所以我把--temp调到 0.7--top-p调到 0.8让输出在“多样性”和“稳定性”之间平衡。温度太高容易输出跑偏太低又显得机械。这个不是性能问题但直接决定你能不能真正用起来。6. 最终方案、实测数据与踩坑记录6.1 最终配置一览经过整轮调优我最终保留了两套配置。日常使用用 IQ4_XS追求极限速度测试用 Q4_0。日常配置./build/bin/llama-server \ -m ./models/qwen2.5-27b-instruct-iq4_xs.gguf \ -ngl 99 \ -c 2048 \ -b 2048 \ -t 8 \ --temp 0.7 \ --top-p 0.8 \ --host 127.0.0.1 \ --port 8080这套配置下生成速度日常保持在 45~55 tok/s短上下文峰值能到 60 左右显存占用约 15.2GB剩余空间还能支撑一些临时激活值。极限测试配置./build/bin/llama-cli \ -m ./models/qwen2.5-27b-instruct-q4_0.gguf \ -ngl 99 \ -c 1024 \ -b 2048 \ -t 8 \ --temp 0.7 \ --seed 42把上下文压到 1024 之后显存余量更多生成速度峰值能摸到 64 tok/s。但实际使用中 1024 上下文太短所以这套配置只用来验证这张卡的极限。6.2 踩坑清单这次调优踩了不少坑列出来给你避雷别直接信任自动 offloadOllama 和部分框架的自动层分配策略对老卡非常不友好模型体积和显存容量接近时它们倾向于把一部分层放到 CPU结果就是速度断崖。手动指定-ngl永远更可控。别贪心上下文长度16GB 显存是硬约束上下文每翻一倍KV Cache 就多占几百 MB。我最后宁可牺牲上下文换全量 GPU 推理也不要 8192 上下文但速度只有 10 tok/s。别开 flash-attn在 V100 上收益为负属于新特性在老架构上的典型坑。别在加载阶段省内存如果模型文件在机械硬盘上加载会非常慢。建议先拷到 NVMe SSD 或直接用内存盘否则第一次启动会等到怀疑人生。注意散热和功耗V100 满载功耗 250W 到 300W我有一张卡跑高负载时温度接近 80 度核心降频导致速度从 60 掉到 50。后来把机箱风道重新理了一遍速度才稳定下来。6.3 这套方法论能不能迁移到其他卡能。我把这次调优的思路总结成一套通用流程先查显存带宽算出该卡的理论速度上限再对照模型量化体积表选出能“全量进显存 KV Cache 够用”的最小可行量化最后针对 GPU 架构做编译优化并在运行时逐个验证关键参数。这套流程对 T4、P40、A2 这些同样显存不大、架构偏老的卡完全适用。核心原则只有一句话先让所有计算发生在 GPU 上再谈算得快不快。否则再新的推理框架、再强的算法优化都救不回来“部分层在 CPU”的硬伤。我把这张 V100 折腾到能跑 27B 模型之后最大的感触是老卡不是不能用而是你得摸清它的脾气。V100 没有 BF16、Tensor Core 又是初代所有针对新架构的优化它都吃不上但只要抓住“显存带宽是瓶颈”这个本质把模型体积和显存容量精确匹配它照样能把 27B 模型跑到接近物理极限的速度。如果你手上也有一张吃灰的老卡或者正在纠结 16GB 显存能不能部署大模型我建议先别急着换卡按这篇文章的路径试一轮。跑通之后再回头看你会对“推理性能到底受什么约束”这件事有完全不同的理解。至于要不要继续上 32GB 显存、换更大模型那就是另一个故事了。
