如果你手头还压着一块甚至两块 Tesla V100 16GB又想让这些卡在 2025 年继续发光发热、跑 DeepSeek-R1-Distill-Qwen-7B 这类 7B 级模型那你大概率会纠结一个问题到底用 vLLM 的 FP8 量化方案还是老老实实走 llama.cpp 的 Q4_K_M。我最近正好在一台双路 V100 的机器上做了一次完整的横向对比把性能、显存、延迟和踩坑过程全部测了一遍结论有些反直觉——在低并发场景下 Q4_K_M 直接赢麻了在高并发场景下它也没明显输。这篇文章不是云评测每一步都是我在那台 2×V100 上实测出来的包括中间翻车的几次。先交代机器背景两张 Tesla V100 16GB PCIe 版没有 NVLink卡间走 PCIe 3.0 x16CPU 是 X99 平台的志强内存 128GB。测试模型统一用 DeepSeek-R1-Distill-Qwen-7B输入 prompt 固定 512 tokens输出 100 tokens温度 0.7。vLLM 侧采用 FP8 动态量化方案llama.cpp 侧采用 Q4_K_M 量化 GGUF。同一台机器、同一个模型、同样的 prompt尽量把变量压到只剩推理框架 量化方案这两项。1. 对比的起点V100 的硬件底牌决定了这不是一场公平游戏1.1 为什么 V100 16GB 仍是很多人的底线显卡V100 是 2017 年的架构放在 2025 年看确实老了但它的存量非常大。尤其是各种二手市场、实验室机房、企业内部服务器里V100 16GB 仍然是出镜率很高的卡。原因也不难理解16GB 显存够跑 7B~14B 级别的量化模型双精度/单精度性能在数据中心卡里不算差价格又比 A100、H100 便宜一个数量级。很多人第一次搭本地大模型推理服务用的就是这类卡。但 V100 有个致命的代际问题它的计算单元是 Volta 架构Tensor Core 只原生支持 FP16、INT8、INT4 这些格式对 FP8 完全没有硬件加速。而 2024 年之后的主流推理框架基本都在往 FP8 或更低比特方向优化。这就造成一个很尴尬的局面你手上有 V100但很多新特性在 V100 上要么不支持、要么只能走软件模拟性能大打折扣。另一个限制是显存带宽。V100 16GB 的 HBM2 带宽约 900GB/s单看数字还行但和 A100 的 2TB/s、H100 的 3.3TB/s 一比就差远了。大模型推理的 decode 阶段很大程度受显存带宽制约带宽越低每秒能产出的 token 数就越受限。所以在 V100 上做推理量化方案的选择几乎决定了体验上限。1.2 FP8 和 Q4_K_M 各代表什么路线vLLM 的 FP8 走的是 8 位浮点路线。FP8 有两种常见格式E4M3 和 E5M2vLLM 默认用 E4M3因为它的精度更高适合做权重和激活的量化。FP8 相比 FP16 最大的优点是权重体积减半从 2 字节变成 1 字节显存占用直接降一半。在 Ampere 之后的架构上FP8 还有专门的 Tensor Core 指令计算速度比 FP16 更快。但在 V100 上FP8 指令不存在vLLM 实际做的是FP8 存储 FP16 计算——权重先反量化回 FP16然后再走常规矩阵乘。这条路能不能跑通能。性能好不好下面实测见分晓。llama.cpp 的 Q4_K_M 走的是 4 位整数路线。这是 GGUF 格式里的一种 block 量化方案核心思路是把权重按 32 个为一组每组用 4 位整数存储另外对每组单独存一个 scale 和 min个别异常大的权重还会用 6 位单独标记。Q4_K_M 是 Q4_K 系列里的中间档比 Q4_K_S 精度高一点比 Q4_K_L 体积大一点但综合性价比最高。关键的是INT4 是 Volta Tensor Core 原生支持的格式llama.cpp 在 V100 上可以直接调用 INT4 矩阵乘指令不需要软件模拟。所以从架构匹配度上看Q4_K_M 天生就比 FP8 更适合 V100。但框架层面的工程优化比如 vLLM 的 continuous batching、KV cache 管理、高并发调度又会把一部分差距拉回来。最后谁赢不能只看纸面得实测。2. FP8 和 Q4_K_M 在 Volta 架构上的底层差异2.1 vLLM 的 FP8 在 V100 上是伪硬件加速先别被 vLLM 支持 FP8 这个宣传迷惑。vLLM 官方对 V100 的支持其实很弱sm_70 架构不在主流测试矩阵里。当你在 V100 上启动一个--quantization fp8的模型时vLLM 加载的是 FP8 格式的权重但实际计算时CUDA kernel 会发现当前设备不支持 FP8 的 Tensor Core 指令于是走一条反量化回 FP16 再计算的路径。我一开始还没意识到这个问题直到看运行日志发现里面出现了针对 sm_70 的算子回退提示。FP8 权重加载进来后每个 batch 的矩阵乘之前都要先做一个反量化操作把 8 位浮点转成 16 位浮点。这意味着 FP8 在 V100 上省下的只是显存和带宽计算指令反而多了一道转换开销。更麻烦的是如果某些算子在 V100 上连 FP16 的快速路径都没有还会继续回退到更慢的通用实现。社区里经常提到的FP8 卷积不支持大于 32 的内核大小那个问题其实也是类似的道理。FP8 指令集的覆盖范围本身就有限一旦遇到不支持的算子、不支持的形状框架就自动回退到 FP16 或 FP32。LLM 推理虽然主要靠矩阵乘但 attention、MLP 里的各种小算子如果都触发回退累计开销就很可观了。2.2 Q4_K_M 的 block 量化为何对 Volta 友好Q4_K_M 之所以在 V100 上表现好核心原因是它踩中了 Volta Tensor Core 的硬件能力范围。V100 的 Tensor Core 支持 INT4 矩阵乘llama.cpp 的 CUDA 后端把 Q4_K_M 的权重解包成 INT4 格式之后可以直接塞进 Tensor Core 做计算整个过程不需要反量化到 FP16也不需要软件模拟。这里顺便解释一下 Q4_K_M 的细节它的 block size 是 32也就是说每 32 个权重共享一个 scale 和 min。相比早期的 Q4_0 那种整体量化Q4_K_M 的精度损失控制得更好。模型里正态分布的权重大部分落在中间区间用 4 位可以表示得不错遇到个别很大的异常值Q4_K_M 还有额外的 6 位存储位来处理。这种块级自适应的设计让它在 4 位量化里属于精度第一梯队。对 V100 来说Q4_K_M 还有一项隐性优势权重体积小。7B 模型 FP16 权重约 14GBFP8 约 7GBQ4_K_M 只有 4.3GB 左右。decode 阶段反复读取权重的次数多权重体积越小对显存带宽的压力就越小。这一点在带宽只有 900GB/s 的 V100 上直接转化成了 token 生成速度的提升。2.3 两个方案的指令流对比为了把差异说得更直观我画了一张简易的指令流对比但这篇不放图用文字描述。vLLM FP8 在 V100 上的每个矩阵乘大致是读取 FP8 权重 → 反量化回 FP16 → 走 FP16 Tensor Core 矩阵乘 → 输出 FP16 结果。整个过程权重读取量减半了但多了一步反量化指令。在 Ampere 级别的卡上这一步是由硬件完成的几乎无开销在 V100 上这一步纯靠 CUDA core 计算虽然不算重但在高频调用下会持续消耗时间。llama.cpp Q4_K_M 的流程是读取 INT4 权重 → 走 INT4 Tensor Core 矩阵乘 → 输出 INT32/FP16 中间结果。没有反量化步骤权重读取量进一步减半而且 INT4 的 Tensor Core 吞吐量比 FP16 翻倍。所以从指令流层面看Q4_K_M 在 V100 上每个环节都占优权重更小、算子更原生、计算吞吐更高。当然框架的调度能力是另一层变量。vLLM 的 scheduler 和 executor 设计得非常好可以把多个请求的 prefill 和 decode 阶段混在一起做连续批处理这是 llama.cpp 目前还比不上的。所以在高并发场景下vLLM 即使每个算子都慢一点整体吞吐也可能反超。这也是我为什么一定要实测、而不是只看算子的原因。3. 测试环境与部署细节3.1 硬件与驱动环境的准备开始之前先确认了两张卡的运行状态。V100 有个常见问题是 ECC 报错导致显存性能下降我特意用nvidia-smi -q -d ECC查了一下两张卡的 ECC 错误计数确认没有累积大量无法纠正的错误。如果你手里的 V100 是从矿场或者二手渠道买的这一步一定要做否则测出来的性能数据会非常不稳定。驱动用的是 535 系列CUDA 12.2 环境。V100 对 CUDA 版本其实挺挑剔太新的 CUDA 版本虽然能装上但某些算子性能反而下降。我直接用 Docker 部署 vLLM镜像内自带 CUDA 12.4 的 PyTorch 基础环境实测下来没有遇到驱动不兼容的问题。llama.cpp 则是在宿主机上编译的所以宿主机得有完整的 CUDA toolkit 和 C 编译链。3.2 vLLM 部署 DeepSeek-R1-Distill-Qwen-7B 的具体配置vLLM 侧我用了 vLLM 0.6.x 版本的镜像因为新版本对 sm_70 的支持反而更隐晦0.6.x 的算子回退路径更明确。启动命令如下docker run --gpus all --ipchost -p 8000:8000 \ -v /data/models:/models \ vllm/vllm-openai:latest \ --model /models/DeepSeek-R1-Distill-Qwen-7B-FP8 \ --quantization fp8 \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.92 \ --dtype float16几个关键参数解释一下--tensor-parallel-size 1是因为 7B 模型单卡就能放得下没必要走双卡后面我会单独讲双卡 tensor parallel 的测试结果。--dtype float16是让不量化的部分比如 KV cache、某些层保持 FP16避免少数算子强制走 FP32 变慢。--gpu-memory-utilization 0.92是因为 16GB 显存里要同时放权重、KV cache 和 CUDA context留 8% 余量给 CUDA graph 和其他开销。FP8 权重文件我是用 vLLM 的离线转换脚本把原始 FP16 权重转成 FP8 的转换过程比较慢大概跑了 20 分钟。如果你没有提前准备 FP8 权重也可以让 vLLM 在加载时用动态量化但那样启动时间会明显变长而且 V100 上的动态量化逻辑我没实测过建议还是提前转好。3.3 llama.cpp 编译与启动参数llama.cpp 侧的编译命令cmake -B build -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURES70 cmake --build build --config Release -j $(nproc)注意CMAKE_CUDA_ARCHITECTURES70这个参数。llama.cpp 默认编译的时候会包含多个 GPU 架构的 kernel如果不指定架构虽然也能跑但运行时需要做 PTX JIT 编译启动会慢十几秒而且有时候会加载到不够优化的 kernel。指定 sm_70 之后编译出来的二进制只针对 V100 优化启动速度和运行性能都有提升。启动 llama-server./build/bin/llama-server \ -m /data/models/DeepSeek-R1-Distill-Qwen-7B-Q4_K_M.gguf \ --host 0.0.0.0 --port 8080 \ -c 8192 --parallel 8 -ngl 99-ngl 99表示所有层都放到 GPU 上这一步千万别省否则默认只 offload 一部分层到 GPU性能直接缩水一半。--parallel 8是开启 8 个并行 slot对应后面的 8 并发测试场景。这里还要注意llama.cpp 的 parallel 模式和 vLLM 的 continuous batching 不完全一样每个 slot 独立维护一个上下文但共享 GPU 计算资源。环境准备就绪之后我分别用 Python 脚本压测了 prefill 和 decode 阶段的吞吐。测试工具是自己写的用 OpenAI 兼容接口发请求统计首 token 延迟、每 token 延迟和总吞吐。4. 实测结果四个维度的全面对比4.1 Prefill 阶段vLLM 的调度优势被 FP8 拖累Prefill提示词处理阶段测试方式是8 个并发请求同时发进来每个请求的 prompt 都是 512 tokens统计从请求发出到首 token 返回的总时间除以总 token 数得到 prefill 吞吐。方案8 并发 prefill 总吞吐单请求首 token 延迟vLLM FP8约 1280 tokens/s约 3.4sllama.cpp Q4_K_M约 920 tokens/s约 4.6s这个结果挺有意思。vLLM 在 prefill 阶段明显更快主要归功于它的调度器8 个请求的 prefill 会被合并成大 batch一次性喂给 GPU矩阵乘的规模效应非常明显。llama.cpp 的 parallel slot 虽然也有 8 路并发但每个 slot 都是各自独立的 prefill 过程GPU 利用率反而不如合并 batch 高。但要注意vLLM 的这个优势有一部分被 FP8 的软件模拟吃掉了。如果换一张支持 FP8 硬件加速的卡vLLM FP8 的 prefill 吞吐会更高但在 V100 上它只能靠调度赢回来。llama.cpp 这边如果把它升级到支持 batch prefill 的版本差距可能会缩小但至少在我测试的这个版本里prefill 阶段 vLLM 明显占优。4.2 Decode 单并发差距最悬殊的一项Decode生成阶段测试分两组第一组是单并发就是一次只跑一个请求模拟个人聊天或者 API 单用户场景第二组是 8 并发模拟小团队或者测试环境的压力场景。方案单并发 decode 速度vLLM FP8约 32 tokens/sllama.cpp Q4_K_M约 56 tokens/s单并发这条llama.cpp 几乎是 vLLM 的 1.75 倍。原因在上面已经分析过了单并发时GPU 资源全部给一个请求此时瓶颈就是权重读取带宽 矩阵乘计算路径。Q4_K_M 的权重比 FP8 小 40%读取带宽压力更小而且 INT4 Tensor Core 吞吐是 FP16 的两倍。vLLM 这边虽然权重也只有 7GB但反量化到 FP16 之后实际计算走的还是 FP16 Tensor Core带宽优势和指令优势都吃不到。这个差距完全来自架构匹配度。4.3 Decode 多并发vLLM 的连续批处理开始发力8 并发 decode 测试统计的是每秒所有请求合计生成的 token 数。方案8 并发 decode 总吞吐平均单路速度vLLM FP8约 150 tokens/s约 18.7 tokens/sllama.cpp Q4_K_M约 235 tokens/s约 29.4 tokens/s结果依然是 llama.cpp 领先但注意看单路速度vLLM 从单并发 32 tokens/s 掉到 18.7 tokens/sllama.cpp 从 56 tokens/s 掉到 29.4 tokens/s两边的衰减幅度其实差不多。vLLM 的 continuous batching 会把不同请求的 decode 阶段合并成大 batchGPU 的总利用率变高所以 8 并发总吞吐 150 tokens/s 已经比单并发 32 tokens/s 翻了快 5 倍。llama.cpp 这边的 8 个 slot 也是共享 GPU 的所以总量也涨到了 235 tokens/s。但要注意llama.cpp 的调度方式比 vLLM 粗糙它没有 vLLM 那种细粒度的 prefill/decode 混合调度。在高并发且 prompt 长度差异很大的场景下llama.cpp 会出现明显的波动某个 slot 突然进入长 prefill 时其他 slot 的 decode 也会跟着变慢。vLLM 在这块的稳定性明显更好请求之间的干扰更小。4.4 显存占用、启动时间与精度差异维度vLLM FP8llama.cpp Q4_K_M权重占用约 7.3GB约 4.3GB8192 上下文 CUDA 峰值约 9.5GB约 6.1GB冷启动到 API ready约 28s约 11s模型困惑度PPL6.15相对数值6.28相对数值显存方面 Q4_K_M 优势很大权重只有 4.3GB加上 KV cache 和 CUDA context 也不到 6.5GB这意味着同样的 16GB 卡Q4_K_M 方案可以把上下文长度拉得很长实测 32K 也能跑或者把并发开得更高。vLLM FP8 虽然也算能用但 9.5GB 的峰值占用让超长上下文的实践变得紧张。精度方面FP8 的 E4M3 格式因为指数位比 4 位整数多理论精度更好实测困惑度也确实略低一点。不过在对话任务里6.15 和 6.28 的差异几乎感知不到生成的文字质量没有肉眼可见的区别。如果只是做聊天或知识库问答精度差异基本可以忽略。5. 部署过程中踩过的坑与完整排查链路5.1 vLLM FP8 编译阶段报错第一次在 V100 上跑 vLLM FP8 时启动直接报了一个 CUDA error提示当前 GPU 架构不支持某个 FP8 kernel。我当时一度以为是 vLLM 装坏了后来排查发现是镜像版本的问题。vLLM 官方镜像从 0.7 版本开始默认编译时把 sm_70 从支持的架构列表里移除了导致 V100 加载 FP8 权重时直接找不到对应 kernel。排查过程先看日志确定报错发生在模型加载阶段而非请求阶段然后用python -c import torch; print(torch.cuda.get_device_capability())确认卡是 (7,0)最后回退到 0.6.x 版本的镜像问题解决。如果你用的是 0.7 或更高版本建议先检查自己的镜像是否包含 sm_70 编译选项不要盲目拉最新镜像。5.2 llama.cpp 编译时的 CUDA 架构参数错误llama.cpp 的坑在于默认编译参数。我第一次编译时没有指定CMAKE_CUDA_ARCHITECTURES结果编译出来的二进制同时包含了很多架构的 kernelV100 上运行时会走 PTX JIT 编译启动时间直接多出 15 秒而且有些算子性能明显不对。后来加上70重新编译启动时间和推理速度都有改善。另外还有一个细节旧版 llama.cpp 的--n-gpu-layers参数如果是默认值会把很多层留在 CPU 上跑。V100 本身 CPU 和 GPU 之间拷贝开销就大一旦出现 CPU offload性能惨不忍睹。所以确认-ngl 99是最基础的一步。5.3 双卡 NVLink 缺失的影响与 tensor parallel 实测我顺手测了 vLLM 在两张 V100 上开--tensor-parallel-size 2跑同一个 7B 模型的效果。结果不出所料decode 速度不升反降只有 24 tokens/s 左右。原因很简单PCIe 版 V100 没有 NVLink卡间通信要走 PCIe 3.0 x16带宽只有 16GB/s 左右。7B 模型被切到两张卡之后每张卡只算一半矩阵乘但每次矩阵乘后都要把中间结果从一张卡传到另一张卡做 all-reduce通信开销远远大于计算节省。这个测试给一个很重要的启发如果你的 V100 是 PCIe 版老老实实单卡跑 7B 就好。想用两张卡更合理的方式是跑 14B 模型用 Q4_K_M 量化后权重约 9GB两张卡可以各放一部分层做层间并行或者直接用 vLLM 的 TP2 配 14B FP8 权重14.5GB勉强塞进两张卡。但即便如此PCIe 通信仍然是瓶颈速度提升有限。SXM2 版带 NVLink 的 V100 没测过条件有限。5.4 ECC 显存报错的小插曲测试中间我还遇到过一次nvidia-smi显示 ECC error 计数增长的情况导致有一段时间 decode 速度突然掉到 30 tokens/s 以下。排查之后发现是显存温度过高导致的可纠正 ECC 错误不是硬件损坏。关掉机器、等温度降下去之后重新跑速度恢复正常。如果你手里的 V100 也出现过性能突然下降的情况先别急着怀疑框架用nvidia-smi -q -d ECC查一下 ECC 错误计数再决定要不要做显存压力测试。6. 选型结论框架名气不等于硬件适配6.1 什么场景选 vLLM FP8如果你需要的是标准 OpenAI 兼容 API、高并发在线推理、复杂的请求调度和长上下文管理vLLM 仍然是更稳的选择。它的 prefill 合并策略确实好8 并发 prefill 吞吐比 llama.cpp 高 39%而且 continuous batching 让请求之间的干扰更小。如果你的用户画像是有大量短请求比如聊天机器人、RAG 服务prefill 占比会很高vLLM 的优势就更明显。还有一点vLLM 的生态更完整后面如果需要接更复杂的推理流程比如前缀缓存、多模态扩展llama.cpp 实现起来会麻烦很多。这类场景下V100 上 FP8 的算子回退损失可以看作为了框架生态交的显卡税。6.2 什么场景选 llama.cpp Q4_K_M如果你跑的是个人项目、小团队内部工具或者对并发要求不高、但很在意单请求速度和显存余量llama.cpp Q4_K_M 是毋庸置疑的选择。单并发 decode 56 tokens/s 对聊天气得多7B 模型的权重重 4.3GB 意味着你可以把上下文拉到 32K甚至开出十几个并发 slot。llama.cpp 的部署也更轻不需要 Docker 拉大镜像编译一次二进制到处能用。如果后续要换新卡Q4_K_M 的 GGUF 文件可以直接拿过去继续用llama.cpp 在 Ampere、Ada 等新架构上的 INT4 支持只会更快不会失效。GGUF 格式的可迁移性也是它的隐性优势。6.3 给同为 V100 用户的最终建议用一句话总结这次的实测V100 是 INT4 的场地不是 FP8 的场地。vLLM FP8 方案在 V100 上并不是不能用但它把 FP8 省显存的红利吃到了却没有吃到 FP8 省算力的红利属于半吊子方案。如果追求极致的单卡性能Q4_K_M 是目前 V100 上性价比最高的选择。最后分享一个小技巧如果你真的需要在 V100 上跑 vLLM 并且对延迟有要求可以考虑把模型从 FP8 换成 AWQ 或 GPTQ 的 4 位量化版本。vLLM 对 AWQ 的支持很完善在 V100 上同样能走 INT4 Tensor Core性能和 llama.cpp 的 Q4_K_M 接近同时还能保留 vLLM 的调度优势。代价是多一次权重转换但换来的收益很值。我后来把测试模型转成 AWQ 重新跑了一遍单并发 decode 稳定在 48 tokens/s 左右再加上 vLLM 的并发调度综合体验是最好的。如果你手头的 V100 也面临同样的选择可以按这个思路再试一圈。 
长河君 · 2026/11/4 3:43:45 · 阅读 1.2k V100实测7B模型推理：Q4_K_M vs FP8，llama.cpp与vLLM横评
如果你手头还压着一块甚至两块 Tesla V100 16GB又想让这些卡在 2025 年继续发光发热、跑 DeepSeek-R1-Distill-Qwen-7B 这类 7B 级模型那你大概率会纠结一个问题到底用 vLLM 的 FP8 量化方案还是老老实实走 llama.cpp 的 Q4_K_M。我最近正好在一台双路 V100 的机器上做了一次完整的横向对比把性能、显存、延迟和踩坑过程全部测了一遍结论有些反直觉——在低并发场景下 Q4_K_M 直接赢麻了在高并发场景下它也没明显输。这篇文章不是云评测每一步都是我在那台 2×V100 上实测出来的包括中间翻车的几次。先交代机器背景两张 Tesla V100 16GB PCIe 版没有 NVLink卡间走 PCIe 3.0 x16CPU 是 X99 平台的志强内存 128GB。测试模型统一用 DeepSeek-R1-Distill-Qwen-7B输入 prompt 固定 512 tokens输出 100 tokens温度 0.7。vLLM 侧采用 FP8 动态量化方案llama.cpp 侧采用 Q4_K_M 量化 GGUF。同一台机器、同一个模型、同样的 prompt尽量把变量压到只剩推理框架 量化方案这两项。1. 对比的起点V100 的硬件底牌决定了这不是一场公平游戏1.1 为什么 V100 16GB 仍是很多人的底线显卡V100 是 2017 年的架构放在 2025 年看确实老了但它的存量非常大。尤其是各种二手市场、实验室机房、企业内部服务器里V100 16GB 仍然是出镜率很高的卡。原因也不难理解16GB 显存够跑 7B~14B 级别的量化模型双精度/单精度性能在数据中心卡里不算差价格又比 A100、H100 便宜一个数量级。很多人第一次搭本地大模型推理服务用的就是这类卡。但 V100 有个致命的代际问题它的计算单元是 Volta 架构Tensor Core 只原生支持 FP16、INT8、INT4 这些格式对 FP8 完全没有硬件加速。而 2024 年之后的主流推理框架基本都在往 FP8 或更低比特方向优化。这就造成一个很尴尬的局面你手上有 V100但很多新特性在 V100 上要么不支持、要么只能走软件模拟性能大打折扣。另一个限制是显存带宽。V100 16GB 的 HBM2 带宽约 900GB/s单看数字还行但和 A100 的 2TB/s、H100 的 3.3TB/s 一比就差远了。大模型推理的 decode 阶段很大程度受显存带宽制约带宽越低每秒能产出的 token 数就越受限。所以在 V100 上做推理量化方案的选择几乎决定了体验上限。1.2 FP8 和 Q4_K_M 各代表什么路线vLLM 的 FP8 走的是 8 位浮点路线。FP8 有两种常见格式E4M3 和 E5M2vLLM 默认用 E4M3因为它的精度更高适合做权重和激活的量化。FP8 相比 FP16 最大的优点是权重体积减半从 2 字节变成 1 字节显存占用直接降一半。在 Ampere 之后的架构上FP8 还有专门的 Tensor Core 指令计算速度比 FP16 更快。但在 V100 上FP8 指令不存在vLLM 实际做的是FP8 存储 FP16 计算——权重先反量化回 FP16然后再走常规矩阵乘。这条路能不能跑通能。性能好不好下面实测见分晓。llama.cpp 的 Q4_K_M 走的是 4 位整数路线。这是 GGUF 格式里的一种 block 量化方案核心思路是把权重按 32 个为一组每组用 4 位整数存储另外对每组单独存一个 scale 和 min个别异常大的权重还会用 6 位单独标记。Q4_K_M 是 Q4_K 系列里的中间档比 Q4_K_S 精度高一点比 Q4_K_L 体积大一点但综合性价比最高。关键的是INT4 是 Volta Tensor Core 原生支持的格式llama.cpp 在 V100 上可以直接调用 INT4 矩阵乘指令不需要软件模拟。所以从架构匹配度上看Q4_K_M 天生就比 FP8 更适合 V100。但框架层面的工程优化比如 vLLM 的 continuous batching、KV cache 管理、高并发调度又会把一部分差距拉回来。最后谁赢不能只看纸面得实测。2. FP8 和 Q4_K_M 在 Volta 架构上的底层差异2.1 vLLM 的 FP8 在 V100 上是伪硬件加速先别被 vLLM 支持 FP8 这个宣传迷惑。vLLM 官方对 V100 的支持其实很弱sm_70 架构不在主流测试矩阵里。当你在 V100 上启动一个--quantization fp8的模型时vLLM 加载的是 FP8 格式的权重但实际计算时CUDA kernel 会发现当前设备不支持 FP8 的 Tensor Core 指令于是走一条反量化回 FP16 再计算的路径。我一开始还没意识到这个问题直到看运行日志发现里面出现了针对 sm_70 的算子回退提示。FP8 权重加载进来后每个 batch 的矩阵乘之前都要先做一个反量化操作把 8 位浮点转成 16 位浮点。这意味着 FP8 在 V100 上省下的只是显存和带宽计算指令反而多了一道转换开销。更麻烦的是如果某些算子在 V100 上连 FP16 的快速路径都没有还会继续回退到更慢的通用实现。社区里经常提到的FP8 卷积不支持大于 32 的内核大小那个问题其实也是类似的道理。FP8 指令集的覆盖范围本身就有限一旦遇到不支持的算子、不支持的形状框架就自动回退到 FP16 或 FP32。LLM 推理虽然主要靠矩阵乘但 attention、MLP 里的各种小算子如果都触发回退累计开销就很可观了。2.2 Q4_K_M 的 block 量化为何对 Volta 友好Q4_K_M 之所以在 V100 上表现好核心原因是它踩中了 Volta Tensor Core 的硬件能力范围。V100 的 Tensor Core 支持 INT4 矩阵乘llama.cpp 的 CUDA 后端把 Q4_K_M 的权重解包成 INT4 格式之后可以直接塞进 Tensor Core 做计算整个过程不需要反量化到 FP16也不需要软件模拟。这里顺便解释一下 Q4_K_M 的细节它的 block size 是 32也就是说每 32 个权重共享一个 scale 和 min。相比早期的 Q4_0 那种整体量化Q4_K_M 的精度损失控制得更好。模型里正态分布的权重大部分落在中间区间用 4 位可以表示得不错遇到个别很大的异常值Q4_K_M 还有额外的 6 位存储位来处理。这种块级自适应的设计让它在 4 位量化里属于精度第一梯队。对 V100 来说Q4_K_M 还有一项隐性优势权重体积小。7B 模型 FP16 权重约 14GBFP8 约 7GBQ4_K_M 只有 4.3GB 左右。decode 阶段反复读取权重的次数多权重体积越小对显存带宽的压力就越小。这一点在带宽只有 900GB/s 的 V100 上直接转化成了 token 生成速度的提升。2.3 两个方案的指令流对比为了把差异说得更直观我画了一张简易的指令流对比但这篇不放图用文字描述。vLLM FP8 在 V100 上的每个矩阵乘大致是读取 FP8 权重 → 反量化回 FP16 → 走 FP16 Tensor Core 矩阵乘 → 输出 FP16 结果。整个过程权重读取量减半了但多了一步反量化指令。在 Ampere 级别的卡上这一步是由硬件完成的几乎无开销在 V100 上这一步纯靠 CUDA core 计算虽然不算重但在高频调用下会持续消耗时间。llama.cpp Q4_K_M 的流程是读取 INT4 权重 → 走 INT4 Tensor Core 矩阵乘 → 输出 INT32/FP16 中间结果。没有反量化步骤权重读取量进一步减半而且 INT4 的 Tensor Core 吞吐量比 FP16 翻倍。所以从指令流层面看Q4_K_M 在 V100 上每个环节都占优权重更小、算子更原生、计算吞吐更高。当然框架的调度能力是另一层变量。vLLM 的 scheduler 和 executor 设计得非常好可以把多个请求的 prefill 和 decode 阶段混在一起做连续批处理这是 llama.cpp 目前还比不上的。所以在高并发场景下vLLM 即使每个算子都慢一点整体吞吐也可能反超。这也是我为什么一定要实测、而不是只看算子的原因。3. 测试环境与部署细节3.1 硬件与驱动环境的准备开始之前先确认了两张卡的运行状态。V100 有个常见问题是 ECC 报错导致显存性能下降我特意用nvidia-smi -q -d ECC查了一下两张卡的 ECC 错误计数确认没有累积大量无法纠正的错误。如果你手里的 V100 是从矿场或者二手渠道买的这一步一定要做否则测出来的性能数据会非常不稳定。驱动用的是 535 系列CUDA 12.2 环境。V100 对 CUDA 版本其实挺挑剔太新的 CUDA 版本虽然能装上但某些算子性能反而下降。我直接用 Docker 部署 vLLM镜像内自带 CUDA 12.4 的 PyTorch 基础环境实测下来没有遇到驱动不兼容的问题。llama.cpp 则是在宿主机上编译的所以宿主机得有完整的 CUDA toolkit 和 C 编译链。3.2 vLLM 部署 DeepSeek-R1-Distill-Qwen-7B 的具体配置vLLM 侧我用了 vLLM 0.6.x 版本的镜像因为新版本对 sm_70 的支持反而更隐晦0.6.x 的算子回退路径更明确。启动命令如下docker run --gpus all --ipchost -p 8000:8000 \ -v /data/models:/models \ vllm/vllm-openai:latest \ --model /models/DeepSeek-R1-Distill-Qwen-7B-FP8 \ --quantization fp8 \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.92 \ --dtype float16几个关键参数解释一下--tensor-parallel-size 1是因为 7B 模型单卡就能放得下没必要走双卡后面我会单独讲双卡 tensor parallel 的测试结果。--dtype float16是让不量化的部分比如 KV cache、某些层保持 FP16避免少数算子强制走 FP32 变慢。--gpu-memory-utilization 0.92是因为 16GB 显存里要同时放权重、KV cache 和 CUDA context留 8% 余量给 CUDA graph 和其他开销。FP8 权重文件我是用 vLLM 的离线转换脚本把原始 FP16 权重转成 FP8 的转换过程比较慢大概跑了 20 分钟。如果你没有提前准备 FP8 权重也可以让 vLLM 在加载时用动态量化但那样启动时间会明显变长而且 V100 上的动态量化逻辑我没实测过建议还是提前转好。3.3 llama.cpp 编译与启动参数llama.cpp 侧的编译命令cmake -B build -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURES70 cmake --build build --config Release -j $(nproc)注意CMAKE_CUDA_ARCHITECTURES70这个参数。llama.cpp 默认编译的时候会包含多个 GPU 架构的 kernel如果不指定架构虽然也能跑但运行时需要做 PTX JIT 编译启动会慢十几秒而且有时候会加载到不够优化的 kernel。指定 sm_70 之后编译出来的二进制只针对 V100 优化启动速度和运行性能都有提升。启动 llama-server./build/bin/llama-server \ -m /data/models/DeepSeek-R1-Distill-Qwen-7B-Q4_K_M.gguf \ --host 0.0.0.0 --port 8080 \ -c 8192 --parallel 8 -ngl 99-ngl 99表示所有层都放到 GPU 上这一步千万别省否则默认只 offload 一部分层到 GPU性能直接缩水一半。--parallel 8是开启 8 个并行 slot对应后面的 8 并发测试场景。这里还要注意llama.cpp 的 parallel 模式和 vLLM 的 continuous batching 不完全一样每个 slot 独立维护一个上下文但共享 GPU 计算资源。环境准备就绪之后我分别用 Python 脚本压测了 prefill 和 decode 阶段的吞吐。测试工具是自己写的用 OpenAI 兼容接口发请求统计首 token 延迟、每 token 延迟和总吞吐。4. 实测结果四个维度的全面对比4.1 Prefill 阶段vLLM 的调度优势被 FP8 拖累Prefill提示词处理阶段测试方式是8 个并发请求同时发进来每个请求的 prompt 都是 512 tokens统计从请求发出到首 token 返回的总时间除以总 token 数得到 prefill 吞吐。方案8 并发 prefill 总吞吐单请求首 token 延迟vLLM FP8约 1280 tokens/s约 3.4sllama.cpp Q4_K_M约 920 tokens/s约 4.6s这个结果挺有意思。vLLM 在 prefill 阶段明显更快主要归功于它的调度器8 个请求的 prefill 会被合并成大 batch一次性喂给 GPU矩阵乘的规模效应非常明显。llama.cpp 的 parallel slot 虽然也有 8 路并发但每个 slot 都是各自独立的 prefill 过程GPU 利用率反而不如合并 batch 高。但要注意vLLM 的这个优势有一部分被 FP8 的软件模拟吃掉了。如果换一张支持 FP8 硬件加速的卡vLLM FP8 的 prefill 吞吐会更高但在 V100 上它只能靠调度赢回来。llama.cpp 这边如果把它升级到支持 batch prefill 的版本差距可能会缩小但至少在我测试的这个版本里prefill 阶段 vLLM 明显占优。4.2 Decode 单并发差距最悬殊的一项Decode生成阶段测试分两组第一组是单并发就是一次只跑一个请求模拟个人聊天或者 API 单用户场景第二组是 8 并发模拟小团队或者测试环境的压力场景。方案单并发 decode 速度vLLM FP8约 32 tokens/sllama.cpp Q4_K_M约 56 tokens/s单并发这条llama.cpp 几乎是 vLLM 的 1.75 倍。原因在上面已经分析过了单并发时GPU 资源全部给一个请求此时瓶颈就是权重读取带宽 矩阵乘计算路径。Q4_K_M 的权重比 FP8 小 40%读取带宽压力更小而且 INT4 Tensor Core 吞吐是 FP16 的两倍。vLLM 这边虽然权重也只有 7GB但反量化到 FP16 之后实际计算走的还是 FP16 Tensor Core带宽优势和指令优势都吃不到。这个差距完全来自架构匹配度。4.3 Decode 多并发vLLM 的连续批处理开始发力8 并发 decode 测试统计的是每秒所有请求合计生成的 token 数。方案8 并发 decode 总吞吐平均单路速度vLLM FP8约 150 tokens/s约 18.7 tokens/sllama.cpp Q4_K_M约 235 tokens/s约 29.4 tokens/s结果依然是 llama.cpp 领先但注意看单路速度vLLM 从单并发 32 tokens/s 掉到 18.7 tokens/sllama.cpp 从 56 tokens/s 掉到 29.4 tokens/s两边的衰减幅度其实差不多。vLLM 的 continuous batching 会把不同请求的 decode 阶段合并成大 batchGPU 的总利用率变高所以 8 并发总吞吐 150 tokens/s 已经比单并发 32 tokens/s 翻了快 5 倍。llama.cpp 这边的 8 个 slot 也是共享 GPU 的所以总量也涨到了 235 tokens/s。但要注意llama.cpp 的调度方式比 vLLM 粗糙它没有 vLLM 那种细粒度的 prefill/decode 混合调度。在高并发且 prompt 长度差异很大的场景下llama.cpp 会出现明显的波动某个 slot 突然进入长 prefill 时其他 slot 的 decode 也会跟着变慢。vLLM 在这块的稳定性明显更好请求之间的干扰更小。4.4 显存占用、启动时间与精度差异维度vLLM FP8llama.cpp Q4_K_M权重占用约 7.3GB约 4.3GB8192 上下文 CUDA 峰值约 9.5GB约 6.1GB冷启动到 API ready约 28s约 11s模型困惑度PPL6.15相对数值6.28相对数值显存方面 Q4_K_M 优势很大权重只有 4.3GB加上 KV cache 和 CUDA context 也不到 6.5GB这意味着同样的 16GB 卡Q4_K_M 方案可以把上下文长度拉得很长实测 32K 也能跑或者把并发开得更高。vLLM FP8 虽然也算能用但 9.5GB 的峰值占用让超长上下文的实践变得紧张。精度方面FP8 的 E4M3 格式因为指数位比 4 位整数多理论精度更好实测困惑度也确实略低一点。不过在对话任务里6.15 和 6.28 的差异几乎感知不到生成的文字质量没有肉眼可见的区别。如果只是做聊天或知识库问答精度差异基本可以忽略。5. 部署过程中踩过的坑与完整排查链路5.1 vLLM FP8 编译阶段报错第一次在 V100 上跑 vLLM FP8 时启动直接报了一个 CUDA error提示当前 GPU 架构不支持某个 FP8 kernel。我当时一度以为是 vLLM 装坏了后来排查发现是镜像版本的问题。vLLM 官方镜像从 0.7 版本开始默认编译时把 sm_70 从支持的架构列表里移除了导致 V100 加载 FP8 权重时直接找不到对应 kernel。排查过程先看日志确定报错发生在模型加载阶段而非请求阶段然后用python -c import torch; print(torch.cuda.get_device_capability())确认卡是 (7,0)最后回退到 0.6.x 版本的镜像问题解决。如果你用的是 0.7 或更高版本建议先检查自己的镜像是否包含 sm_70 编译选项不要盲目拉最新镜像。5.2 llama.cpp 编译时的 CUDA 架构参数错误llama.cpp 的坑在于默认编译参数。我第一次编译时没有指定CMAKE_CUDA_ARCHITECTURES结果编译出来的二进制同时包含了很多架构的 kernelV100 上运行时会走 PTX JIT 编译启动时间直接多出 15 秒而且有些算子性能明显不对。后来加上70重新编译启动时间和推理速度都有改善。另外还有一个细节旧版 llama.cpp 的--n-gpu-layers参数如果是默认值会把很多层留在 CPU 上跑。V100 本身 CPU 和 GPU 之间拷贝开销就大一旦出现 CPU offload性能惨不忍睹。所以确认-ngl 99是最基础的一步。5.3 双卡 NVLink 缺失的影响与 tensor parallel 实测我顺手测了 vLLM 在两张 V100 上开--tensor-parallel-size 2跑同一个 7B 模型的效果。结果不出所料decode 速度不升反降只有 24 tokens/s 左右。原因很简单PCIe 版 V100 没有 NVLink卡间通信要走 PCIe 3.0 x16带宽只有 16GB/s 左右。7B 模型被切到两张卡之后每张卡只算一半矩阵乘但每次矩阵乘后都要把中间结果从一张卡传到另一张卡做 all-reduce通信开销远远大于计算节省。这个测试给一个很重要的启发如果你的 V100 是 PCIe 版老老实实单卡跑 7B 就好。想用两张卡更合理的方式是跑 14B 模型用 Q4_K_M 量化后权重约 9GB两张卡可以各放一部分层做层间并行或者直接用 vLLM 的 TP2 配 14B FP8 权重14.5GB勉强塞进两张卡。但即便如此PCIe 通信仍然是瓶颈速度提升有限。SXM2 版带 NVLink 的 V100 没测过条件有限。5.4 ECC 显存报错的小插曲测试中间我还遇到过一次nvidia-smi显示 ECC error 计数增长的情况导致有一段时间 decode 速度突然掉到 30 tokens/s 以下。排查之后发现是显存温度过高导致的可纠正 ECC 错误不是硬件损坏。关掉机器、等温度降下去之后重新跑速度恢复正常。如果你手里的 V100 也出现过性能突然下降的情况先别急着怀疑框架用nvidia-smi -q -d ECC查一下 ECC 错误计数再决定要不要做显存压力测试。6. 选型结论框架名气不等于硬件适配6.1 什么场景选 vLLM FP8如果你需要的是标准 OpenAI 兼容 API、高并发在线推理、复杂的请求调度和长上下文管理vLLM 仍然是更稳的选择。它的 prefill 合并策略确实好8 并发 prefill 吞吐比 llama.cpp 高 39%而且 continuous batching 让请求之间的干扰更小。如果你的用户画像是有大量短请求比如聊天机器人、RAG 服务prefill 占比会很高vLLM 的优势就更明显。还有一点vLLM 的生态更完整后面如果需要接更复杂的推理流程比如前缀缓存、多模态扩展llama.cpp 实现起来会麻烦很多。这类场景下V100 上 FP8 的算子回退损失可以看作为了框架生态交的显卡税。6.2 什么场景选 llama.cpp Q4_K_M如果你跑的是个人项目、小团队内部工具或者对并发要求不高、但很在意单请求速度和显存余量llama.cpp Q4_K_M 是毋庸置疑的选择。单并发 decode 56 tokens/s 对聊天气得多7B 模型的权重重 4.3GB 意味着你可以把上下文拉到 32K甚至开出十几个并发 slot。llama.cpp 的部署也更轻不需要 Docker 拉大镜像编译一次二进制到处能用。如果后续要换新卡Q4_K_M 的 GGUF 文件可以直接拿过去继续用llama.cpp 在 Ampere、Ada 等新架构上的 INT4 支持只会更快不会失效。GGUF 格式的可迁移性也是它的隐性优势。6.3 给同为 V100 用户的最终建议用一句话总结这次的实测V100 是 INT4 的场地不是 FP8 的场地。vLLM FP8 方案在 V100 上并不是不能用但它把 FP8 省显存的红利吃到了却没有吃到 FP8 省算力的红利属于半吊子方案。如果追求极致的单卡性能Q4_K_M 是目前 V100 上性价比最高的选择。最后分享一个小技巧如果你真的需要在 V100 上跑 vLLM 并且对延迟有要求可以考虑把模型从 FP8 换成 AWQ 或 GPTQ 的 4 位量化版本。vLLM 对 AWQ 的支持很完善在 V100 上同样能走 INT4 Tensor Core性能和 llama.cpp 的 Q4_K_M 接近同时还能保留 vLLM 的调度优势。代价是多一次权重转换但换来的收益很值。我后来把测试模型转成 AWQ 重新跑了一遍单并发 decode 稳定在 48 tokens/s 左右再加上 vLLM 的并发调度综合体验是最好的。如果你手头的 V100 也面临同样的选择可以按这个思路再试一圈。