★ FEATURED ARTICLE 1. 为什么要在 2×V100 上做这场对比手里有两张 Tesla V100 32GB这是很多个人开发者和中小团队能摸到的“性价比算力天花板”。但 V100 是 Volta 架构计算能力 7.0它有个绕不开的硬伤原生不支持 FP8。FP8 的硬件加速是从 HopperH100和 Ada LovelaceRTX 40 系才开始大规模落地的V100 连 BF16 都是靠软件模拟的。所以当有人问“V100 上跑 vLLM 的 FP8 和 llama.cpp 的 Q4_K_M 到底谁快”时这个问题本身就带着一个陷阱——你得先搞清楚 FP8 在 V100 上究竟是怎么被执行的。我这次实测的目的很明确在同一台双 V100 机器上用同一套硬件、同一份模型权重来源分别跑 vLLM 的 FP8 量化和 llama.cpp 的 Q4_K_M 量化把吞吐、显存占用、首 token 延迟、生成质量四个维度拉出来对比。适合谁看手里有 V100 或者类似老架构卡、正在纠结推理框架选型、想搞清楚量化格式和硬件匹配关系的人。如果你只是想知道“哪个快”那答案会因场景而异但我会把背后的原因拆开讲清楚。先说结论方向免得你看到一半才发现方向不对在 V100 上FP8 并不是真正的 FP8 加速它更多是“存储格式的压缩”计算时会被反量化回 FP16 执行。而 llama.cpp 的 Q4_K_M 是 k-quant 系列里的中等偏上精度量化4-bit 权重配合精心设计的 scale 和 min 值分组在 CPU 和 GPU 上都有成熟的 dequant 内核。两者根本不在一个技术路线上直接比“谁快”意义有限真正有价值的是搞清楚什么场景该选谁。2. 先搞懂 FP8 和 Q4_K_M 到底在干什么2.1 FP8 的两种格式与 V100 的尴尬FP8 有两个主流变体E4M34 位指数、3 位尾数和E5M25 位指数、2 位尾数。E4M3 精度更高适合前向传播的权重和激活E5M2 动态范围更大适合梯度。vLLM 里做 FP8 量化推理时默认用的是 E4M3。关键问题来了V100 的 Tensor Core 只支持 FP16 输入。当你把权重存成 FP8计算时硬件没法直接吃这个格式必须先 dequant 成 FP16 再送进 Tensor Core。这意味着什么意味着你省下的是显存带宽和存储空间但计算路径上多了一步转换开销。在显存带宽不是瓶颈、计算是瓶颈的场景下FP8 在 V100 上甚至可能比纯 FP16 还慢。我实测时特意用nvidia-smi dmon盯了显存带宽利用率。跑 FP8 模型时显存读写量确实比 FP16 低了接近一半但 SM 利用率并没有同步提升因为 dequant 那步占用了额外的指令周期。这就是 Volta 跑 FP8 的真实状态——省显存不省算力。2.2 Q4_K_M 的 k-quant 设计哲学llama.cpp 的 Q4_K_M 属于 k-quant 量化家族M 代表 medium。它的核心思路是分块量化 超块缩放把权重按 256 个元素分成一个 super-block每个 super-block 里再分 8 个子块每个子块 32 个元素。每个子块有自己的 scale 和 min 值用 6-bit 存储super-block 层面还有一组全局 scale 和 min用 FP16 存储。这种设计的精妙之处在于它承认了权重分布的不均匀性。神经网络权重在不同通道、不同层的分布差异巨大一刀切的量化会毁掉精度。Q4_K_M 通过两级缩放让每个 32 元素的小块都能自适应调整量化区间代价是每个权重平均多出约 0.5 bit 的元数据开销。所以 Q4_K_M 的实际位宽不是 4 bit而是4.5 bit 左右。在 V100 上跑 llama.cpp 时dequant 内核是手写 CUDA 的针对 Volta 的指令集做过优化。我对比过 llama.cpp 的 CUDA dequant 和 vLLM 的 FP8 dequant前者在 V100 上的指令效率明显更高因为它是为消费级和老数据中心卡专门调过的。2.3 两者的本质差异把这两个放一起对比本质上是在比两种完全不同的压缩哲学维度vLLM FP8llama.cpp Q4_K_M量化粒度张量级或通道级32 元素子块级元数据开销极低每张量一个 scale较高每子块 scalemin硬件依赖需要 FP8 原生支持才快依赖 dequant 内核优化V100 上的计算路径FP8→FP16→TensorCoreQ4→FP16→TensorCore显存节省约 50%相对 FP16约 70%相对 FP16精度损失较小中等看懂这张表你就明白为什么不能简单说“FP8 比 Q4_K_M 好”或反过来。FP8 的精度保留更好但压缩率低Q4_K_M 压得更狠但靠精细的分块设计把精度损失控制在可接受范围。在 V100 上两者的计算路径都要经过 FP16 中转所以真正的差异在显存占用和 dequant 效率。3. 实测环境搭建与关键配置3.1 硬件与驱动基线测试平台是一台二手 X99 工作站配置如下CPUXeon E5-2680 v414 核 28 线程内存128GB DDR4 2400 ECCGPU2× Tesla V100 32GB PCIe无 NVLink存储NVMe SSD 2TB系统Ubuntu 22.04 LTS内核 5.15V100 的驱动是个坑。数据中心卡默认跑在TCC 模式Tesla Compute Cluster这个模式下 GPU 不能直接输出显示但计算任务更稳定。如果你之前把卡插在带显示输出的机器上可能被切到了 WDDM 模式性能会打折扣。检查命令nvidia-smi -q | grep -i compute mode要确保是Default或Exclusive_Process别是Prohibited。另外 V100 的 ECC 默认开启会吃掉约 6% 的显存和一点带宽。我测试时保持 ECC 开启因为生产环境一般不会关。如果你追求极限性能可以关掉 ECC但稳定性风险自负。驱动版本我用的 535.161.07CUDA 12.2。这个组合在 V100 上比较稳太新的驱动有时会引入奇怪的调度问题。3.2 vLLM 部署 FP8 模型vLLM 部署 FP8 模型有两种路径一是加载已经量化好的 FP8 权重二是加载 FP16 权重并在加载时动态量化。我选第一种因为动态量化会引入额外启动开销而且量化质量不如离线校准。用的镜像是vllm/vllm-openai:v0.27.1这个版本对 Volta 的兼容性经过验证。启动命令docker run --gpus all --shm-size16g \ -v /models:/models \ -p 8000:8000 \ vllm/vllm-openai:v0.27.1 \ --model /models/Qwen3-8B-FP8 \ --tensor-parallel-size 2 \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.90 \ --enforce-eager几个关键参数解释--tensor-parallel-size 2两张 V100 做张量并行。V100 没有 NVLink走 PCIe 通信TP 的 all-reduce 开销会比 NVLink 机器高不少但 8B 模型还能接受。--dtype float16这个必须显式指定。虽然权重是 FP8但计算 dtype 要设成 FP16否则 vLLM 可能尝试用不支持的路径。--enforce-eager关掉 CUDA Graph。V100 上 CUDA Graph 对 FP8 路径的支持不完善开着容易出诡异错误。代价是损失一点调度效率。--gpu-memory-utilization 0.90留 10% 显存给系统和其他进程V100 的显存管理比较保守设太高容易 OOM。启动后你会看到日志里有一行Using FP8 quantization但别高兴太早它不会告诉你 dequant 发生在哪。用nsys抓一下 kernel 就能看到fp8_to_fp16的转换 kernel 在反复执行。3.3 llama.cpp 部署 Q4_K_M 模型llama.cpp 我用的编译版本是 b3xxx具体 commit 号随版本滚动建议用最新的 release tag。编译时开启 CUDA 支持cmake -B build -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURES70 cmake --build build --config Release -jCMAKE_CUDA_ARCHITECTURES70是关键70 对应 Volta。如果你不指定编译出的内核可能不包含 Volta 的优化路径性能会差一截。启动 server./build/bin/llama-server \ -m /models/Qwen3-8B-Q4_K_M.gguf \ -ngl 99 \ -c 8192 \ -b 2048 \ -t 14 \ --host 0.0.0.0 --port 8001参数说明-ngl 99把所有层都放到 GPU。99 是“尽可能多”的意思llama.cpp 会自动分配到两张卡上。-c 8192上下文长度。-b 2048batch size影响 prompt 处理吞吐。-t 14CPU 线程数设成物理核数。llama.cpp 的多卡分配策略和 vLLM 不同它默认按层切分而不是张量并行。对 V100 这种没有 NVLink 的卡来说层切分的通信开销反而更小因为每层只需要传一次激活值不像 TP 那样每层都要 all-reduce。4. 四个维度的实测数据与解读4.1 吞吐对比谁在什么场景下更快我用同一个 prompt 集测试包含短 prompt50 token和长 prompt2000 token两组输出固定 256 token。测试工具是自写的 Python 脚本直接打 OpenAI 兼容接口。短 prompt 场景batch size 1指标vLLM FP8llama.cpp Q4_K_M首 token 延迟180ms95ms生成速度42 tok/s58 tok/s显存占用11.2GB6.8GBllama.cpp 在单请求低并发下明显更快。原因有两个一是它的 dequant 内核针对 Volta 优化得更彻底二是 vLLM 的调度器在 batch size 1 时开销占比高它的优势要在大 batch 下才体现。长 prompt 场景batch size 12000 token 输入指标vLLM FP8llama.cpp Q4_K_M首 token 延迟1.2s2.8s生成速度40 tok/s55 tok/s长 prompt 下 vLLM 反超了首 token 延迟因为它的PagedAttention对 KV cache 的管理更高效prefill 阶段的并行度更高。llama.cpp 的 prefill 是分块处理的长序列下优势不明显。高并发场景batch size 16指标vLLM FP8llama.cpp Q4_K_M总吞吐380 tok/s210 tok/s单请求平均延迟1.8s3.5s这是 vLLM 的主场。它的 continuous batching 和 PagedAttention 在高并发下把 GPU 利用率拉满而 llama.cpp 的 batching 策略相对保守16 并发时已经出现明显的排队。4.2 显存占用Q4_K_M 的压倒性优势显存这块没什么悬念。Q4_K_M 的 4.5 bit 实际位宽 vs FP8 的 8 bit理论上就差近一倍。实测vLLM FP8模型权重约 8.5GBKV cache 约 2.7GB8192 上下文总计 11.2GBllama.cpp Q4_K_M模型权重约 4.8GBKV cache 约 2.0GB总计 6.8GB在 32GB 的 V100 上这个差异决定了你能开多长的上下文、能跑多大的 batch。如果你要跑 32K 上下文FP8 的 KV cache 会膨胀到 10GB 以上加上权重就逼近单卡极限而 Q4_K_M 还能留出充足余量。注意vLLM 的 KV cache 默认是 FP16 存储如果你显存紧张可以开--kv-cache-dtype fp8但这在 V100 上同样会走 dequant 路径收益有限。4.3 首 token 延迟prefill 阶段的较量首 token 延迟直接决定用户的“第一印象”。在交互式场景下超过 500ms 就会感觉卡顿。短 prompt 下 llama.cpp 快一倍这跟它的架构有关llama.cpp 的 prefill 是同步执行的没有复杂的调度层请求进来直接算。vLLM 则要经过 scheduler、executor 的排队和批处理决策虽然单次开销不大但在 batch size 1 时这部分固定开销占比就显出来了。长 prompt 下 vLLM 反超因为 PagedAttention 在 prefill 时能更高效地利用显存带宽而且它的 attention kernel 对长序列做了专门优化。llama.cpp 的 flash attention 在 Volta 上支持有限长序列下会退化到普通 attention。4.4 生成质量量化损失的实测质量评估我用了两个方法一是跑标准 benchmarkMMLU 子集、GSM8K 子集二是人工对比同一批 prompt 的输出。测试集FP16 基线vLLM FP8llama.cpp Q4_K_MMMLU 子集72.3%71.8%70.1%GSM8K 子集68.5%67.9%65.2%人工评分1-54.54.44.1FP8 的精度损失确实更小MMLU 只掉了 0.5 个点GSM8K 掉 0.6 个点。Q4_K_M 掉得多一些MMLU 掉 2.2 个点GSM8K 掉 3.3 个点。数学推理对量化更敏感因为中间步骤的数值误差会累积。人工评分时我注意到一个现象Q4_K_M 在长文本生成时偶尔会出现重复和逻辑断裂尤其是在超过 500 token 的输出里。FP8 则基本没有这个问题。如果你做的是创意写作或需要长链推理的任务FP8 的稳定性更好。5. 踩过的坑与排查实录5.1 vLLM 在 V100 上的三个典型报错报错一RuntimeError: FP8 not supported on this device这个报错通常出现在你没显式指定--dtype float16的时候。vLLM 检测到权重是 FP8就尝试走原生 FP8 路径但 V100 的 compute capability 是 7.0不在支持列表里。解决办法就是强制指定计算 dtype 为 FP16让它走 dequant 路径。报错二CUDA error: an illegal memory access was encountered这个在开 CUDA Graph 时概率出现。V100 的 CUDA Graph 对动态 shape 的支持有缺陷FP8 路径下 shape 变化更频繁容易触发。加--enforce-eager关掉 Graph 就能解决。代价是吞吐掉约 8%但稳定性优先。报错三torch.cuda.OutOfMemoryError在加载阶段V100 的显存碎片化比较严重尤其是跑过其他任务之后。解决办法是加载前先nvidia-smi --gpu-reset重置 GPU或者把--gpu-memory-utilization降到 0.85。我实测 0.90 是稳定上限再高就容易在 KV cache 分配时炸。5.2 llama.cpp 的编译与运行陷阱陷阱一没指定 CUDA 架构默认编译会包含多个架构的 kernel但如果你机器上只有 V100编译一堆用不上的架构会拖慢编译速度而且可能选错 kernel。显式指定-DCMAKE_CUDA_ARCHITECTURES70能确保生成针对 Volta 优化的代码。陷阱二-ngl设太大导致层分配不均llama.cpp 的多卡分配是自动的但如果你两张卡显存不一样比如一张 32GB 一张 16GB它可能分配不均导致 OOM。解决办法是用--tensor-split手动指定比例比如--tensor-split 1,1表示平均分。陷阱三Q4_K_M 模型来源不一致GGUF 文件有很多来源不同来源的量化质量差异很大。有些是直接用 llama.cpp 的quantize工具生成的有些是第三方转的。建议自己用官方工具从 FP16 权重转命令./build/bin/llama-quantize \ /models/Qwen3-8B-FP16.gguf \ /models/Qwen3-8B-Q4_K_M.gguf \ Q4_K_M这样能确保量化参数是最优的。5.3 常见问题速查表现象可能原因解决办法vLLM 启动即 OOM显存碎片或利用率设太高重置 GPU降gpu-memory-utilizationFP8 模型速度反而慢dequant 开销大于带宽节省换 FP16 或改用 Q4_K_Mllama.cpp 多卡负载不均自动分配策略问题用--tensor-split手动指定生成结果重复量化精度不足换更高精度量化或 FP8首 token 延迟高prefill 未优化vLLM 开 chunked prefillllama.cpp 调大 batch长上下文 OOMKV cache 太大降上下文长度或开 KV cache 量化6. 选型建议什么场景用哪个6.1 选 vLLM FP8 的场景如果你的服务要面对高并发、多用户vLLM 的 continuous batching 和 PagedAttention 是刚需。FP8 在这里的价值是在有限显存下塞进更多并发——同样 32GBFP8 能比 FP16 多开约 40% 的 KV cache 空间。精度损失小适合对输出质量要求高的场景比如客服、知识问答、代码生成。但前提是你得接受 V100 上 FP8 不是真加速这个事实。它的优势在调度和显存管理不在单次计算速度。6.2 选 llama.cpp Q4_K_M 的场景单用户、低并发、显存紧张的场景llama.cpp 是更务实的选择。它的显存占用低到可以在单张 V100 上跑 32K 上下文的 8B 模型而 FP8 在同样条件下会非常勉强。首 token 延迟低交互体验好。另外如果你需要在边缘设备或混合 CPU/GPU 环境部署llama.cpp 的灵活性是 vLLM 比不了的。它可以在 GPU 层数不够时自动回退到 CPU虽然慢但能跑起来。6.3 一个折中方案我实际生产里用的是混合部署vLLM FP8 跑在线服务扛并发llama.cpp Q4_K_M 跑离线批处理和长上下文任务。两者共享同一份模型权重来源只是量化格式不同。这样既保证了在线服务的吞吐又利用了 Q4_K_M 的显存优势处理长文档。如果你只有两张 V100这个方案完全可行。vLLM 占一张卡llama.cpp 占另一张通过网关按任务类型路由。实测下来资源利用率比单跑一个框架高不少。7. 几个容易被忽略的细节V100 的 PCIe 带宽是瓶颈。两张 V100 PCIe 版本之间走 PCIe 3.0 x16理论带宽 16GB/s实际 all-reduce 效率只有 NVLink 机器的三分之一。所以 TP2 的扩展效率不是线性的8B 模型大概能到 1.6 倍再大就衰减明显。llama.cpp 的层切分反而受影响小因为通信量少。ECC 对性能的影响。我对比过开和关 ECC 的差异生成速度差约 4%显存可用量差约 6%。生产环境建议开着除非你在做 benchmark 追求极限数字。驱动版本别乱升。V100 已经是老卡了新驱动对它的优化投入在减少有时候新驱动反而引入回归。535 系列是我实测最稳的再新的 550 系列在某些 CUDA 版本下有调度问题。模型权重的来源要统一。我见过有人拿 A 来源的 FP8 和 B 来源的 Q4_K_M 对比结果差异巨大最后发现是量化校准集不同导致的。做对比实验时一定从同一份 FP16 权重出发分别用 vLLM 和 llama.cpp 的官方工具量化。温度控制。V100 是被动散热的数据中心卡在塔式机箱里容易过热降频。我加了个涡轮风扇转接罩把核心温度压在 75 度以下否则连续跑 10 分钟就会触发降频吞吐掉 15% 以上。这个细节很多人忽略但对你实测数据的可重复性影响很大。最后分享一个我常用的监控命令组合跑测试时开着能实时看到两张卡的利用率和温度watch -n 1 nvidia-smi --query-gpuindex,utilization.gpu,memory.used,temperature.gpu,clocks.sm --formatcsv如果clocks.sm掉到 1200MHz 以下说明在降频这时候的吞吐数据不可信得先解决散热再重测。
阅读完成 · 觉得有帮助？
