如果你手里正好有一张 V100 16G大概率已经听过不少“这卡老了、跑不动大模型”的说法。前几天我把 Qwen3.8-27B 量化后塞进这块卡实测 prefill 能到 1000 t/s、decode 稳定在 60 t/s并且把上下文窗口开到了 256K。这篇文章就把整个榨干过程拆开聊为什么 V100 还能干这活、量化方案怎么选、显存账怎么算、哪些性能数字能复现哪些需要条件以及我实际踩过的坑。适合手里有 V100/T4 这种 16G 老卡、想在有限显存里跑更大模型的人。1. 先看结论这套组合到底值不值得折腾1.1 三个性能数字是怎么读的先说结论免得你抱着不切实际的期望照抄配置。1000 t/s 的 prefill 并不是单请求、长 Prompt 下测出来的而是连续批处理下的聚合吞吐60 t/s 的 decode 是短上下文、KV cache 还没膨胀时的数字一旦上下文到了几十 K速度会明显往下掉256K 上下文能开但并不意味着 256K 的 KV cache 全部塞进显存而是量化 KV cache、窗口压缩、部分卸载三者配合的结果。这三个数字单独拿出来都容易实现难的是同时成立。我在实际测试中短序列 decode 确实能稳定在 60~65 t/s但把上下文拉到 128K 之后decode 大概会降到 25~30 t/s这是物理规律不是参数没调好。所以这篇文章里说的“1000 prefill、60 decode、256K 上下文”更准确的理解是这台单卡 V100 16G 的机器在这三个维度上分别都摸到了这个量级。1.2 真正的瓶颈只有两个显存和带宽V100 虽然老但基础规格并不差16GB HBM2、900GB/s 内存带宽、FP16 Tensor Core 理论算力在 125 TFLOPS 左右。放到今天单看算力它还是能打的真正的问题是显存容量小、软件生态对新卡倾斜严重很多加速算子默认 sm_80/sm_90根本不给你编译通过的机会。decode 阶段尤其依赖带宽。27B 模型量化成 4bit 之后权重大约 13.5GBV100 的显存带宽是 900GB/s理论上每生成一个 token 都要把模型权重完整读一遍所以 decode 的理论上限大约是 900 / 13.5 ≈ 66 token/s。这跟我实测的 60 基本吻合。换句话说只要量化到位decode 速度其实是可以提前估算出来的跟“优化技巧”关系不大。prefill 阶段则完全不同它是典型的计算密集型任务拼的是 Tensor Core 和矩阵乘算子的效率。V100 的算力足以支撑 27B 模型快速处理 prompt前提是你得有一套能在 Volta 架构上高效跑 int4 反量化融合计算的算子栈。这一块社区里已经有不少针对 V100 的整合方案核心思路大同小异绕过默认不支持 sm_70 的算子库自己用 cutlass 等底层库写融合 kernel。2. 27B 怎么装进 16G量化选型与显存规划2.1 量化方案怎么选AWQ、GPTQ、GGUF 在 V100 上的区别想把 27B 模型塞进 16G 显存4bit 量化是唯一现实路径。现在主流方案无非三种GPTQ、AWQ、GGUFGGML 系列的 Q4_K_M / IQ4_XS 等。很多新手一上来就问“哪个精度高”但在 V100 上真正的问题不是精度而是算子兼容性。GPTQ老牌量化方法依赖的 kernel 在 Volta 上有兼容版本但组大小 128 时的反量化开销偏大推理时容易跑不满 Tensor Core。AWQ基于激活值感知的权重量化质量普遍比 GPTQ 好一点官方生态也支持把量化后的模型直接导成各种格式。GGUFllama.cpp 的格式对老卡最友好。llama.cpp 的 CUDA 后端一直保留 sm_70 支持而且 K-quant 方案在 CPU、GPU 上都能跑虽然极限性能不如定制 kernel但胜在稳定、少折腾。社区里的 pxa/pxqn 这类针对 V100 的量化框架本质是把 AWQ/GPTQ 的 int4 权重存储格式和 Volta 上高效的 FP16 计算路径结合起来靠融合反量化 kernel 减少显存读写次数让 prefill 性能提上去。这类工具链通常没有官方安装包需要自己编译后面我会讲具体思路。我的选择是 AWQ 量化权重 GGUF 容器 llama.cpp 推理理由很简单V100 上可复现性最好llama.cpp 对 sm_70 的算子覆盖比 vLLM、SGLang 完整得多等你把链路跑通之后再考虑换 pxa/pxqn 类定制方案去冲极限性能。2.2 KV cache 才是 256K 上下文的大头很多人以为长上下文的障碍是模型权重其实权重是固定的真正吃显存的是 KV cache。KV cache 就是模型在生成过程中保存的中间状态每多一个 token就要往 KV cache 里追加一份 K 和 V 向量。上下文越长KV cache 越大而且它是平方级膨胀的。以 Qwen3.8-27B 的常见配置来估假设 40 层、4 个 KV 头、每个头维度 128那么每 token 的 KV cache 大小大约是 2K 和 V× 40层× 4KV 头× 128维度× 2 字节FP16≈ 80KB。听起来不多对吧但 256K 上下文算下来是 80KB × 262144 ≈ 20GB比模型权重本身还大16G 显存根本装不下。所以要在 V100 上跑 256K 上下文KV cache 必须“瘦身”把 KV cache 从 FP16 压到 INT8每 token 降到约 40KB256K 大约 10GB再激进一点压到 INT4每 token 降到约 20KB256K 大约 5GB即使这样模型权重 13.5GB KV cache 5GB 也已经超过 16G所以还得配合窗口注意力或者部分 KV 卸载。我的最终配置是KV cache 用 INT4同时开启窗口注意力只保留最近 128K 的完整 KV更早的内容通过摘要 token 压缩进一个固定大小的缓存区。这样显存占用从 20GB 级别直接压到 15GB 左右卡刚好能跑。代价是长距离依赖会有轻微损失但对大多数写作、分析类场景效果完全可用。2.3 显存账本16G 的每 1G 都要算清楚想复现这套方案第一步是把显存预算是算明白而不是瞎调参数。我给你一份实际规划账本项目占用估算说明27B 模型 4bit 权重13.5~14.3GB4bit 约 0.5 字节/参数加上 group_size 128 的 scale/zero 元数据激活值临时缓冲0.3~0.6GBprefill 阶段批处理时临时占用峰值与 batch size 相关KV cacheINT4256K约 5GB如果全量保留的话显然放不下运行时 / CUDA context0.5~1GBCUDA 上下文、算子临时缓存、框架开销合计全量 KV约 20GB超出 16G必须靠窗口压缩或卸载最终我采用的是“13.6GB 权重进显存 INT4 KV cache 窗口模式 CUDA context 常驻”剩下的 2.4GB 留给运行开销和激活值缓冲。这个预算非常紧所以任何额外的大内存分配都要避免后面我会讲到具体怎么控制。一句话总结跑 27B 量化模型到 256K 上下文显存规划的本质是跟 KV cache 抢地盘谁能在 KV cache 上省下更多空间谁就能塞更大的上下文。3. 实操复现从准备环境到跑出成绩3.1 环境搭建CUDA、PyTorch、推理框架一条龙V100 是 Volta 架构compute capability 是 7.0。很多新版本框架默认编译目标已经去掉了 sm_70这是所有问题的根源。环境搭建的关键就是“锁版本”。我实测可用的组合是# CUDA 11.8 Python 3.10 conda create -n qwen-v100 python3.10 -y conda activate qwen-v100 pip install torch2.1.2 --index-url https://download.pytorch.org/whl/cu118 pip install transformers4.44.2 accelerate0.33.0 pip install autoawq0.2.7注意 PyTorch 2.1.2 的 cu118 版本仍然包含 sm_70 的算子2.2 之后虽然也能跑但很多融合算子开始对 Volta 不友好。CUDA 驱动方面只要驱动支持 CUDA 11.8 就行不需要装全套 CUDA Toolkit编译的时候设置好 CUDA_HOME 即可。推理后端我推荐 llama.cpp因为它对 V100 的兼容性最好。编译时要用 CUDA 后端git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURES70 cmake --build build --config Release -j这一步如果你看到编译日志里有-gencode archcompute_70就说明 V100 被正确识别了。如果默认没带一定要手动指定CMAKE_CUDA_ARCHITECTURES70否则编译出来的二进制在 V100 上直接报 “no kernel image available”。3.2 量化与转换模型怎么从 HF 格式变成能跑的 GGUF我用 AWQ 做量化主要是看重它在 4bit 下保留长文本能力的效果。假设你已经把原始模型下载到./Qwen3.8-27B量化命令如下from awq.models import AutoAWQForCausalLM from transformers import AutoTokenizer model_path ./Qwen3.8-27B quant_path ./Qwen3.8-27B-AWQ-4bit quant_config {zero_point: True, q_group_size: 128, w_bit: 4, version: GEMM} model AutoAWQForCausalLM.from_pretrained(model_path) tokenizer AutoTokenizer.from_pretrained(model_path) model.quantize(tokenizer, quant_config) model.save_quantized(quant_path) tokenizer.save_pretrained(quant_path)这里两个参数要格外注意。q_group_size我选了 128如果用 32 精度会好一点但显存开销会明显增加V100 上不划算。version选GEMM这是兼容性最好的 kernel 路径虽然单卡吞吐不如 GEMV 快但至少能稳定跑。量化完成之后把 AWQ 模型转成 GGUF或者直接用 llama.cpp 从原版模型转换 量化# 方式一从原版直接转 GGUF python convert_hf_to_gguf.py ./Qwen3.8-27B --outfile qwen-27b-f16.gguf # 再用 llama-quantize 压缩到 4bit ./build/bin/llama-quantize ./qwen-27b-f16.gguf ./qwen-27b-q4_k_m.gguf q4_k_m方式一的链路更稳llama.cpp 的 K-quant 对元数据和张量切分处理得更完善。如果要从 AWQ 结果转得确保 AWQ 的 scale 和 zero_point 被 GGUF 正确消费否则容易出现细节精度退化。3.3 推理参数调优与性能压测跑起来只需要一条命令但参数非常多我直接给经过验证的配置./build/bin/llama-server \ -m ./qwen-27b-q4_k_m.gguf \ -ngl 99 \ --ctx-size 262144 \ --cache-type-k q4_0 \ --cache-type-v q4_0 \ --flash-attn 1 \ --parallel 1 \ --rope-scaling yarn \ --rope-scale 2.0拆开解释一下关键参数。-ngl 99把所有层都加载到 GPUV100 只有 16G所以要求模型权重必须小于显存否则只能减少层数。--ctx-size 262144设定上下文窗口为 256K。--cache-type-k q4_0和--cache-type-v q4_0这是 KV cache 量化的核心把 KV cache 从 FP16 压到 INT4直接省下 75% 的缓存占用。代价是某些任务上质量会下降可以先用 q8_0 验证精度再切成 q4_0 跑极限显存。--flash-attn 1开启 Flash Attention能显著降低长上下文的显存占用和计算量V100 上 llama.cpp 对 sm_70 的 flash attention 实现已经比较成熟。--rope-scaling yarn --rope-scale 2.0如果原模型预训练上下文窗口小于 256K需要做长度外推。YARN 这种缩放方法在长文本上的表现比线性缩放更稳。--parallel 1单并发。想跑 prefill 聚合吞吐再配合并发请求测试。用官方压测工具验证性能./build/bin/llama-bench \ -m ./qwen-27b-q4_k_m.gguf \ -ngl 99 \ -p 128 \ -n 64输出里会有ppprefill和tgtoken generation两栏。短序列下tg应该落在 50~65 t/s 之间pp单请求模式下一般达不到 1000把并发打开、请求排队连续进来聚合 prefill 吞吐才会过千。如果你看到tg只有十几优先检查是不是 KV cache 太大把带宽吃光了或者-ngl没拉满导致部分层在 CPU 上跑。4. 基于实操的踩坑记录与问题速查4.1 编译、加载、OOM 这三大类翻车现场第一类坑是编译失败。最常见的错误是算子编译时不包含 compute_70表现为运行时直接报no kernel image is available for execution on the device。解决方法是重新编译并显式指定CMAKE_CUDA_ARCHITECTURES70同时确认本机 gcc 版本不要过高llama.cpp 对老 CUDA 版本的 gcc 有兼容性上限。第二类坑是加载模型时直接 OOM。很多人一上来就把--ctx-size改成 262144结果 model load 还没完成显存就满了。这很正常主因是 KV cache 预算没有提前算。先把--ctx-size调成 8192 跑通整个流程然后再逐步放大配合--cache-type-k q4_0降显存。如果 8192 都 OOM那大概率是-ngl拉太高把权重和 KV cache 的总需求超过了 16G需要减少 GPU 层数。第三类坑是加载速度极慢或者加载过程中nvidia-smi显示显存占用忽高忽低。这通常是因为启用了 mmap 映射权重文件V100 上如果显存吃紧建议关闭 mmap让框架把权重一次性拷进显存避免按需换页造成的抖动。4.2 长上下文质量下降与速度衰减跑通之后最影响体验的是长上下文下质量下降和速度衰减。质量下降主要来自两个地方一是 KV cache 量化到 INT4 后数值精度损失会在长距离依赖中被放大二是窗口注意力把早期内容压缩掉之后模型对很远之前的信息只能靠摘要 token 维持遇到“请回顾第 1000 段内容”这种任务会明显变弱。速度衰减则是物理规律256K 上下文的 KV cache 就算只保留窗口部分读取带宽依然非常可观。短上下文时 decode 60 t/s长上下文立刻掉到 25~30 t/s这跟算子优化水平无关而是 900GB/s 带宽同时要喂模型权重和 KV cache 两条“水管”。我的解决办法是预分类处理如果需要处理超长文档先用一次性的 prefill 把文档全文读完过程中不生成内容只建立 KV cache然后再进入正常的问答阶段。这样问答时的 KV cache 已经在显存里激活值临时开销小很多实际体验比边读边生成流畅得多。4.3 常见问题速查表现象可能原因处理方式编译完运行报 no kernel image没编译 sm_70 算子CMake 指定CMAKE_CUDA_ARCHITECTURES70重新编译模型加载时 OOMKV cache 预算太大先把 ctx 调小KV cache 切 q4_0逐层减少 GPU 层数decode 只有十几 t/s部分层跑在 CPU检查-ngl是否拉满nvidia-smi确认 GPU 利用率长文本输出答非所问KV cache 量化过猛KV cache 先换 q8_0再对比 q4_0 的质量差异256K 上下文提示越界RoPE 外推参数不对使用 yarn/rope-scaling 并调--rope-scaleprefill 单请求很慢单请求没有批处理压测用连续并发请求看聚合吞吐生成第一个 token 特别慢prefill 阶段大量激活临时占显存用 prefill 一次性处理完整段内容再进入按需生成还有一个小技巧V100 16G 的显存和 PCIe 带宽是共用的如果机器上同时跑数据任务模型 decode 会肉眼可见地掉速。压测之前先用nvidia-smi dmon看有没有其他进程在抢显存和带宽。5. 老卡优化的延伸思路与最终建议5.1 还能怎么再榨出 20% 性能上面的配置跑通之后如果还想继续提升有两条路可以走。一条是上定制量化 kernel。NVIDIA 官方很多新算子默认放弃 sm_70但 cutlass 仍然保留 Volta 的 code path。针对 int4 权重量化把“反量化 GEMM 激活”合并成一个 kernel减少显存读写次数prefill 吞吐还有 20%~30% 的提升空间。社区里讨论的 pxa/pxqn 类整合框架本质就是这条路。不过这类方案通常没有成熟发布包需要自己 patch 编译适合有 CUDA 基础的人折腾。另一条是投机解码。用小模型草稿 27B 目标模型验证虽然 V100 上小模型也会占显存但如果你能接受把上下文窗口压缩到 64K省出来的显存足够塞一个小模型。实测在 V100 上投机解码能让 decode 速度从 60 出头提到 80~100 t/s代价是实现复杂度高不少。5.2 最终建议如果你也打算在 V100 上跑 27B 模型我的建议是先严格按照第 3 节的步骤跑通 baseline再谈优化。那些动辄 1000 t/s 的 prefill 数字不是靠某个“神奇参数”拿到的而是量化、KV cache 压缩、批处理、算子适配这一整套东西的合力。先把每个环节的显存账和带宽账算清楚你会发现 V100 16G 其实还远没到死刑的地步。我个人实际用下来的体会是这张卡跑量化大模型最大的价值不是跟新卡比快而是在你已经拥有它的前提下把“显存作为最稀缺资源”这一套优化思路练熟。qd