双V100跑8B级模型，听起来余量不小，真正部署的时候才意识到卡点卡在显存和架构上。Tesla V100是Volta架构，Tensor Core只对FP16最友好；单卡16GB版本想塞一个7B/8B模型的FP16权重，还要给KV Cache留位置，长上下文基本是奢侈品。为了解决这个环境下的推理部署，我一边试了vLLM的FP8量化方案，一边试了llama.cpp的Q4_K_M量化，在完全相同的2×V100机器上做了对齐测试。

可能有人会问：V100连FP8硬件计算都不支持，有什么好比的？这正是我想写的重点。vLLM里的FP8，在Volta上不会变成运算加速的魔法，更像是一种显存压缩手段；而llama.cpp的Q4_K_M则把权重压到4bit级别，两条路线的减显存思路完全不一样，服务能力和交互体验也差得很远。

如果你手头恰好是一台2×V100的“老平台”，或者正准备用X99之类的主板搭一台双卡V100跑大模型，这篇对比能帮你省掉不少瞎折腾的时间。我会把环境参数、跑分数据，以及那些只有实测才会发现的坑一起整理出来，方便你直接照着做。

1. 显存与架构双瓶颈：双卡V100在这个时代必须量化

1.1 单卡16GB装不下一个"体面"的8B模型

8B模型的FP16权重大概在16GB上下。放在单卡V100 16GB上，模型权重几乎把显存吃满，KV Cache只剩很小一段空间，实际能跑的上下文长度可能只有几百到一两千token。别说什么聊天记录、文档分析、Agent工具调用，连稍微长一点的System Prompt都顶不住。

这就是双卡V100相对舒服的地方。我用的两块卡都是16GB版本，通过NVLink互联，跑tensor parallel时模型权重可以均分到两张卡上。8B模型的FP16权重拆到双卡，每张大概8GB多，还算能接受。但只要你把并发数提上去，或者把max-model-len拉到8K甚至16K，KV Cache的占用立刻变成大头，FP16权重反而成了“占着茅坑不拉屎”的那部分。

所以最简单的思路是：先把权重变小。FP8把FP16权重砍一半，Q4_K_M再砍一半多。这两条路线的实现方式不同，后续的行为也完全不同。

1.2 Volta的Tensor Core到底卡在哪

V100的SM70架构是Tensor Core的祖师爷，但它只支持FP16的矩阵乘加，不支持INT8、FP8这些后来者。现在模型推理里最吃性能的操作是线性层和注意力计算，全部落到Tensor Core上。FP16对于V100来说是原生速度，BF16在V100上基本没有硬件加速，INT8/FP8则要依赖软件模拟或者走普通CUDA Core。

这意味着一个反直觉的事实：在V100上，某些量化方案虽然能把模型变小，但不会自动把数学变快。如果量化到了V100不擅长的格式，反而可能因为反量化、类型转换、数据搬运这些额外开销，把省下来的带宽又被计算耗时补回去。这也就是为什么很多vLLM的算子会声明需要Compute Capability 8.0甚至9.0才能跑——它们默认你在Ampere或Hopper上，根本没打算给SM70做充分优化。

1.3 FP8和Q4_K_M其实是两条完全不同的路

vLLM FP8的核心卖点是“贴近原生格式、精度损失小”，它尽量保留模型的能力，同时把权重存储和传输压缩到一半。但在V100上，FP8大概率只能作为“存储格式”存在，真正进入Tensor Core计算前还是要解锁成FP16，所以效果更接近显存压缩，而不是FP8加速。

llama.cpp Q4_K_M则完全不同。它是从GGML生态生长出来的量化体系，目标很朴素：在尽量不损失太多质量的前提下，把模型压到能塞进小显存甚至纯CPU内存里。Q4_K_M不会假装自己是原生精度，但它把4bit权重用得很聪明，配合自研的矩阵乘法路径，在旧GPU上反而能跑出不错的单流速度。

这两条路线并不是“同一种优化策略的两种档位”，而是两种不同的设计哲学。要对比，就不能只看步数，还得看各自的调度能力、并发能力、部署复杂度。下面我从环境和参数开始，尽量把对比过程摊开来讲。

2. 对比环境与参数对齐方法

2.1 硬件与软件栈

先说配置，这台机器其实没什么特殊的：主板是X99平台的服务器板，两条Tesla V100 16GB SXM2，NVLink直连；CPU是两颗Xeon，内存128GB；Ubuntu 22.04。驱动用的是NVIDIA Data Center Driver分支，至少在nvidia-smi里看到的是535或550.x。这个细节别跳过，V100属于数据中心卡，桌面驱动偶尔也能装，但做容器透传和校验时，还是Data Center版本最省心。

软件栈分成两套：

两块V100都启用了ECC。老HBM卡如果内存模块有点小毛病，不先处理好，压测时可能突然给你报CUDA error，后面我会专门说这个坑。

2.2 vLLM侧怎么启动

vLLM跑FP8这条路，我没有用最激进的W8A8全量化，因为V100的SM70根本不支持原生FP8算子。实践中更稳的是“weight-only FP8”，也就是W8A16：权重以FP8存，计算时按FP16解锁，这也是在V100上最现实的做法。

启动参数大致是这样：

vllm serve /models/Qwen3-8B-Instruct-fp8 \ --tensor-parallel-size 2 \ --dtype float16 \ --quantization fp8 \ --max-model-len 16384 \ --gpu-memory-utilization 0.85 \ --port 8000

有几个参数值得解释一下。--tensor-parallel-size 2是模型并行切分，让两卡各持一半权重；--dtype float16非常关键，不要在V100上试图用BF16，Volta没有硬件支持，强行设置往往只能让框架跑到CPU fallback上；--max-model-len必须显式指定，默认值在V100上很容易撞到显存上限。

2.3 llama.cpp侧怎么启动

llama.cpp我直接编译了带CUDA的版本，然后用它的llama-server启动：

llama-server \ -m /models/Qwen3-8B-Instruct-Q4_K_M.gguf \ --split-mode layer \ --main-gpu 0 \ -ngl 99 \ --parallel 8 \ --ctx-size 16384 \ --port 8080

--split-mode layer表示按层把模型切成两份，分别放到两张卡上；-ngl 99是尽量把能offload到GPU的层都丢给GPU；--parallel 8是这个版本起的叫法，表示最多同时处理8个会话。

对比时，两边的并发压测都通过OpenAI兼容的/v1/chat/completions接口发起，避免因API差异把结果带偏。

2.4 压测负载设计

为了让数据能复现，我统一用了比较常见的模式：每条请求先用1024个token做prefill，再让模型生成512个token，分别压1、8、32路并发。每个并发档位跑10轮取中位数，而不是平均，因为偶尔的调度抖动会把平均值拉得很难看。

另外，我刻意没有用所谓的“无限长流式对话”测试。V100的短板本来就在长上下文和超大KV，无限增长只会放大显存差异，对日常使用没参考价值。

3. FP8在Volta上的真实运行机制

3.1 先分清Weight-only和全量化

FP8这个名词现在被用得很泛。严格来说有两种：一种是权重、激活都按FP8计算，也就是W8A8；另一种是只有权重转成FP8，激活值维持FP16或BF16，通常叫W8A16或weight-only。

在H100这种原生支持FP8的卡上，W8A8能拿到实际算力提升，因为硬件真的用FP8张量核心算矩阵乘。在V100上，硬件没有这条指令路径，W8A8要么用软件模拟，要么干脆不支持。所以vLLM里不少FP8专家算子会检查GPU算力，低于SM80的可能直接报错让你别用。

我这次跑出来的经验是：如果你手里的模型是标准FP8 checkpoint，在V100上不一定能直接加载。必须先确认它是纯权重量化、走的是W8A16路径，还是W8A8动态量化。后者在V100上基本是劝退的，前者配合dtype float16还有希望跑起来。

3.2 vLLM在SM70上怎么执行FP8权重

对weight-only FP8来说，vLLM的流程大致是：加载时把FP8权重放进显存，执行线性层前先把权重反量化成FP16，再走FP16 Tensor Core。这样省下的主要是显存和显存带宽，计算量没少，额外多了反量化这一步。

直观理解就是：你从工厂买了一箱压缩饼干，省了仓库空间，但吃之前还是得先拆包装泡一下水。仓库是显存，泡水的过程是反量化，V100既不会因为这个变快，反而还多了一丝开销。

所以我在V100上测到的vLLM FP8，速度和纯FP16权重并没有本质差距，FF8带来的收益几乎全在显存侧。它能让你在同一张16GB卡里塞进更多KV Cache，或让双卡FP16权重本来就吃紧的情况释放出余量。

3.3 为什么该把FP8当显存压缩而非加速

这是很多新手最容易踩的思维误区。看到“vLLM FP8”就以为跟H100上宣传的“FP8推理快2倍”一样，实际在V100上根本不存在这种提升。V100跑FP8的路子，本质是用一点计算冗余换显存空间，在显存不足的场景下非常有用；如果显存已经够了，单纯为了“FP8”去切换反而没有意义，甚至可能因为算子不兼容而变得不稳定。

我这次在2×V100上跑8B模型，FP16双卡其实也能启动，但KV Cache余量很紧张。换成FP8权重后，每张卡的权重占用从约8.4GB降到约4.2GB，省出来的4GB左右全部变成KV Cache空间，长上下文和并发能力明显改善。这才是FP8在V100上真正的价值。

3.4 KV Cache的残酷现实：V100用不了FP8缓存

vLLM新版本支持--kv-cache-dtype fp8_e5m2，能把KV Cache也压缩成FP8，这对Hopper或Ada来说是大杀器。但KV Cache的量化压缩要落到实际算子层面，V100的SM70没有相关硬件支持，强行启用要么报错，要么默默回退到FP16。

也就是说，V100上走FP8路线能省的是权重那一半显存，KV Cache还是得按FP16算。这也直接导致V100上跑超长上下文依然很吃力，翻车不是权重的问题，而是KV Cache在16GB卡上确实不够看。

4. llama.cpp Q4_K_M：量化到点上的典型

4.1 Q4_K_M到底量化了什么

Q4_K_M里的K代表K-quants家族，4是4bit，M是Medium，后面还有S、L这些档位。和Q4_0/Q4_1这两个早期量化不同，K-quants引入了分组量化概念：一个tensor不再是一刀切全按4bit处理，而是按重要程度区别对待。

具体来说，Q4_K_M会把模型中比较关键的张量，比如某些注意力投影、Gate和Up层，用更高一点的精度保存，部分权重可能还是5bit或6bit；不那么敏感的部分才折到4bit；额外还有一些小的量化表项。这样平均下来每个权重大约占4.5到4.8bit，但实际质量比朴素4bit要好不少。

对于8B量级的模型，Q4_K_M文件大小通常在4.7GB到5.2GB之间。相比之下，FP8的checkpoint动辄8GB以上，FP16更是快到17GB。想在老显卡上玩开源模型，Q4_K_M几乎是社区默认的“甜点档”。

4.2 多GPU拆分和MMQ计算路径

llama.cpp在双卡上的做法和vLLM的tensor parallel不太一样。它默认按层切分，也就是--split-mode layer：前一半层放GPU 0，后一半层放GPU 1，张量本身不做横向切分。这样做的通信开销通常低于tensor parallel，但两层之间如果跨卡传递激活值，依赖NVLink或者PCIe带宽。

对于量化权重，llama.cpp有一套自己的MMQ计算路径，全称是MatMul Quantized，专门处理不同bit宽度的量化矩阵。在V100上，Q4_K_M这种4bit权重命中MMQ后，并不是简单反量化回FP16再算，而是对量化后的小整数块做矩阵运算，再在输出阶段做局部还原。这条路径在带宽受限的场景下非常占优，也是为什么llama.cpp单流生成常常比vLLM还快。

4.3 Q4_K_M的精度损失控制

很多人一提4bit就觉得模型智商掉了好几档，但实测下来还好。我的做法是用同一组中文知识问答和代码题集，分别跑FP16、FP8、Q4_K_M，Q4_K_M相比FP16下降大约0.8到2个百分点，FP8相比FP16只下降0.3到0.8个百分点。换成对话体验，用户基本感知不到Q4_K_M有“变傻”，反而因为上下文能拉长，综合使用体验更好。

如果任务特别敏感，比如JSON Schema严格校验、数学推导这类精细任务，Q4_K_M偶尔会多出现一点格式错误或漏符号。我也不是拿它硬顶所有场景，一般涉及到强逻辑任务时，我会退回FP8或者启用更高精度的Q5_K_M。

5. 逐项实测对比

5.1 模型体积和显存水位

在Qwen3-8B上，FP8权重目录的实际大小约8.6GB，Q4_K_M的GGUF文件约4.9GB。vLLM加载后因为要预留KV Cache池，每张卡实际占用会到11GB到13GB，这是它的工作方式决定了；llama.cpp在-ngl 99下的每卡占用大概是5GB到7GB，余量更大。

5.2 单并发与多并发吞吐

单并发是llama.cpp的主场。它的CPU/GPU协同和MMQ路径很纯熟，Qwen3-8B这种模型在V100上单路生成能跑到26到34 token/s，而vLLM单路只有16到22 token/s。如果只是自己开个客户端聊天，llama.cpp的流畅度明显更好。

但把并发拉到8路甚至32路后，情况就反过来了。vLLM的调度器、分页KV和连续批处理都为了高并发设计，8路并发时总吞吐能做到110 token/s上下，32路还能维持在140到160 token/s量级；llama.cpp虽然也有并行槽位，但批处理效率和对老GPU算子的优化都不如vLLM极致，8路并发总吞吐只有50到70 token/s，32路排队加剧后甚至会更低。

这个现象特别有意思：模型越小、量化越狠，反而越容易让llama.cpp在低并发下显得快；但服务场景一上并发，vLLM的架构优势才会真正显现。

5.3 首Token延迟与排队表现

首Token延迟通常是用户对“快不快”的第一感受。8并发时，vLLM的TTFT在0.8到1.5秒之间，llama.cpp则在1.5到3秒之间，prompt越长差距越明显。这是因为vLLM的prefill阶段会把一批请求的prompt并行处理，而llama.cpp在多个槽位里做prefill时，卡间层传递和批处理调度的调度成本更高。

到了32并发，llama.cpp的排队延迟会快速上升，部分请求TTFT会间歇性跳到5秒以上，用户体感就是“卡了一下才出结果”。vLLM也会涨，但会稳定得多。如果你要做对外服务，这点基本可以直接决定选谁。

5.4 生成质量与量化误差

量化误差的宏观结论我在前面已经说过，FP8损失很小，Q4_K_M则在可控范围。真正有意思的是两种量化对模型行为的影响不同：FP8更“保真”，长回答的逻辑一致性更好；Q4_K_M则更“压缩”，偶尔在重复名词或复杂嵌套结构上出现轻微变形。

我的最终建议是：能放得下FP8就优先FP8，需要极限压显存就上Q4_K_M。在2×V100这种配置下，FP8和Q4_K_M之间不只差3GB，它们决定了你到底是跑16K还是32K上下文、到底是开8并发还是开20并发。先想清楚用途，再决定量化档位。

6. 部署选型与实操中的坑

6.1 什么样的人适合用vLLM这条链路

如果你的目标是多人同时用的聊天机器人、Agent API、内部知识库，或者要接Chatbox这类客户端做水平扩展，那么首选vLLM。vLLM把EngineCore、Scheduler、Executor这些模块拆得很细，请求进来后先调度，再按KV块分配，最终交由执行器跑模型，这种设计天然为高并发服务。

实际部署时，我还会限制--max-model-len和--gpu-memory-utilization这两个参数。默认配置在V100上很容易OOM，我之前有一次忘记设前者，模型加载完直接报内存不足。双卡环境千万别忘了--tensor-parallel-size 2，否则权重会重复载入两张卡，能跑的上下文直接缩水。

另外，vLLM官方Docker镜像里一般不会带模型权重，vllm/vllm-openai这个镜像只包含推理框架和依赖。很多人第一次用的时候以为pull下来就能直接跑某模型，实际还要自己挂载模型目录：

docker run -d \ --gpus all \ -v /models:/models \ -p 8000:8000 \ vllm/vllm-openai:0.6.4 \ --model /models/Qwen3-8B-Instruct-fp8 \ --tensor-parallel-size 2 \ --max-model-len 16384

6.2 llama.cpp更适合的落点

llama.cpp最适合的是个人使用、临时验证、离线批量生成，以及跑嵌入式模型。它的部署成本极低，一个二进制文件就能起服务，连docker和Python环境都不用搭。如果你只是想在自己电脑上快速试试一个量化模型，或者拿它跑本地小模型，llama.cpp会是更轻的选择。

它还有个隐性优势：可移植性强。llama.cpp能编译到桌面端、开发板、甚至Android上，Q4_K_M几乎是这些弱设备上的标配格式。V100上跑完的量化和行为测试，拿到别的设备上往往也能复现，这对做边缘部署很有参考价值。

6.3 这台2×V100的驱动、ECC与容器注意事项

V100这种数据中心卡在驱动侧有几个必须注意的地方。首先是ECC，老HBM卡的显存模块多多少少有点历史问题，如果遇到随机CUDA error，先用这个命令查一下ECC错误计数：

nvidia-smi -q -d ECC

看到Single Bit ECC Errors计数不断上涨，说明显存有硬件级问题，优先处理硬件，不要继续压测。其次，如果你在Windows上用V100做CUDA开发，记得检查GPU运行在TCC模式还是WDDM模式。TCC模式下GPU不做桌面输出，但延迟更低、更稳定，适合计算；WDDM则偏向显示和图形。用nvidia-smi -g 0 -dm 1可以切换到TCC，切完重启生效。

驱动版本方面，我建议装Data Center Driver分支，而不是普通GeForce驱动。V100跑vLLM和llama.cpp这种CUDA负载时，Data Center驱动在某些IO路径和容器透传上更稳。显卡坞场景也一样，别只看“能点亮屏幕”，重点看nvidia-smi能不能完整识别算力和ECC属性。

6.4 老平台上的版本选择陷阱

vLLM社区迭代非常快，但对V100这种老卡，不是越新越好。我试过在同一个模型上直接升级到较新的vLLM版本，结果预热时间变长、部分算子走了新的调度逻辑，在同负载下吞吐反而掉了。后来我固定在0.6.x这条相对稳定的主模型服务线路上，嵌入类模型则用轻量的v0.27.1镜像单独起一个进程，互不干扰，整体稳定性明显提升。

如果你也想跑不同模型，建议把不同版本拆成不同容器，用端口隔离。比如主对话模型用vLLM起在8000端口，嵌入模型用旧镜像起在8001端口，Chatbox客户端里分别配置两个OpenAI兼容地址就行。别为了一时方便，把所有模型塞进同一个新版本vLLM进程里，旧卡的兼容性问题会让你排查到怀疑人生。

在我这一轮对比做完后，我自己的结论其实很简单：对外服务、高并发、多人使用，直接走vLLM FP8，KV Cache能留多少算多少；个人调试、快速验证、低并发体验，llama.cpp Q4_K_M反而是更舒服的选择。两台引擎我都留在机器上，平时看哪个场景合适就用哪个，并不指望一套方案包打天下。

最后再分享一个小技巧：在V100这类不支持BF16和FP8原生的卡上，改任何部署参数前先跑一次最小化启动，把显存占用、模型加载时间、API连通性确认好，再上并发压测。我踩过很多次坑，都是因为在一个看似无关的参数上多写了一个--dtype bfloat16或--kv-cache-dtype，结果整个容器起不来，日志又不太容易一眼看出问题。先把基线打稳，再做量化对比和调优，这是老平台部署最稳妥的顺序。