一台双路 X99 配上两张 V100 32GB，放在今天还能干点啥？我最近拿这台机器做了一轮大模型推理方案对比，主角是 vLLM 加载 FP8 量化模型，对手是 llama.cpp 加载 Q4_K_M 量化模型。很多人看到标题会觉得奇怪，V100 根本不支持 FP8，这个对比是不是搞错了？其实没搞错，这正是整篇最有意思的地方。
我在双卡 V100 上把两种方案完整跑了一遍，从驱动准备、Docker 部署、模型转换到压测数据全走了个遍。这篇文章就是一份完整的实测记录，包含环境搭建、参数说明、性能对比、踩坑实录和排查方法。如果你手里还有 V100、A100 这类老卡，或者云上租了旧实例，想搞清楚量化格式和推理框架到底该怎么搭配，这篇文章能帮你省下很多试错时间。
1. 先把前提说清楚：V100 到底能不能跑 FP8
1.1 V100 的硬件边界：Tensor Core 支持什么格式
先说硬件底牌。V100 用的是 Volta 架构，芯片代号 GV100，SM 版本是 7.0。它的 Tensor Core 支持 FP16 和 INT8 两种计算模式，不支持 BF16，更没有 FP8，也没有 INT4。这三样都是后面好几代架构才补上的特性：INT4 在 Turing 时代出现，BF16 是 Ampere 的卖点，FP8 直到 Hopper 的 H100 和 Ada Lovelace 的 L40S、L20 上才成为标配。
很多人容易被软件生态搞混。驱动、CUDA 库、推理框架都在"向下兼容"，所以你在 vLLM 里可以加载一个 FP8 格式的权重文件，甚至在日志里还能看到"FP8"字样，但这不代表硬件真的在算 FP8。打个比方：你拿一台只能显示 1080p 的显示器去播 8K 视频，播放器不报错，但最终输出还是被降级成 1080p 才能显示。V100 上加 FP8 模型，本质上就是这种降级播放。
这个前提决定了后续整个对比的走向。V100 的 Tensor Core 峰值算力大约是 FP16 下 110 TFLOPS 级别（16 位 Tensor Core），这个数字在当年很猛，但和今天的 H100、L20 相比已经有代差。老卡跑新格式，硬件不支持，软件来兜底，兜底就要付出额外代价，这是理解全部测试数据的钥匙。
1.2 所以"vLLM 加载 FP8"在 V100 上实际发生了什么
vLLM 加载 FP8 检查点时，如果检测到 GPU 不支持原生 FP8 计算，它并不会直接拒绝干活，而是先把 FP8 权重反量化成 FP16，再交给 FP16 Tensor Core 去算。这个过程也叫 dequant。FP8 的 E4M3 格式每个权重占 1 字节，FP16 占 2 字节，所以权重放进显存时确实是省了一半空间。但算的时候，还是要回到 FP16 的精度和数据类型。
也就是说，在 V100 上跑 vLLM FP8，实际执行路径是：加载 FP8 权重 → 生成时反量化为 FP16 → 用 FP16 Tensor Core 计算。显存确实省了，计算却一点没加速，反而每次 GEMM 前都要多走一道反量化转换。反量化本身也有开销，虽然比一次矩阵乘便宜得多，但它是纯增项，不是替代项。在 H100、L20 上跑 FP8，计算单元是实实在在的 FP8 Tensor Core，速度能翻倍，省显存还能提速；在 V100 上，只剩下"省显存"这一半的好处，速度不仅没提升，可能比直接加载 FP16 模型还慢一点。
更麻烦的是算子覆盖问题。FP8 内核并不是全模型覆盖的，某些算子形态没有对应的 FP8 实现，就会自动回退到 FP16 或 FP32。社区里有过明确例子：在 FP8 支持的卷积实现中，当卷积核大小大于 32 时，比如 7×7 的卷积，会自动回退到 FP16 或 FP32。LLM 推理里虽然以 GEMM 为主，但遇到形状不规整的矩阵乘，或者某些特殊算子，同样会触发回退路径。回退一多，省下的显存会被临时高精度中间结果吃掉一部分，计算路径也变得更长。所以 V100 上的 vLLM FP8，是一个"名义上省显存、实际上打折扣"的折中方案。
1.3 Q4_K_M 是什么：K-quant 家族与混合精度设计
Q4_K_M 是 llama.cpp 生态里的一套量化格式，属于 K-quant 家族。K-quant 是 llama.cpp 在 2023 年推出的一套混合量化方案，家族里有 Q2_K、Q3_K、Q4_K、Q5_K、Q6_K，每个又按混合程度分成 S（small）、M（medium）、L（large）几个变体，Q4_K_M 就是 4-bit 混合程度的中间档。
K-quant 的设计思路很务实：模型里不同张量的重要性不一样，没必要一刀切全部用 4-bit。Q4_K_M 的"混合"体现在，大部分权重矩阵用 Q4_K 级别的 4-bit 量化，但对注意力机制和 FFN 里几个比较敏感的张量，会改用 Q5_K 甚至 Q6_K 的更高精度。这种做法有点像一个团队里，核心主力配高性能电脑，普通员工配普通办公机，整体预算没增加多少，关键产出却保住了。
Q4_K_M 的实际体感是：体积小、质量接近原版。拿 7B 模型来说，FP16 权重大约 14GB，FP8 大约 7.5GB，而 Q4_K_M 的 GGUF 文件只有 4.7GB 左右，连 FP16 的 1/3 都不到。这个体积优势直接影响了 V100 上的实际表现，后面实测数据会说。在社区里，Q4_K_M 几乎是默认选项，Ollama 官方模型库里的 7B 模型默认量化格式就是 Q4_K_M，原因就是它在模型体积、输出质量、推理速度之间找到了一个大众最容易接受的平衡点。
2. 测试环境搭建：从驱动到模型，每一步的取舍
2.1 硬件与驱动准备：TCC 模式、ECC 检测、CUDA 版本
测试机是一台双路 X99 平台，插了两张 V100 32GB PCIe 版本，通过 NVLink 桥接互联。X99 搭配 V100 是前几年"平民炼丹机"的常见组合，优点是便宜，缺点是 PCIe 通道和供电余量都比较紧张。如果你的主板 PCIe 插槽不够，还要注意 NVLink 桥的安装方向，插反了系统识别不到。
开机后第一件事不是装框架，而是先检查显卡状态。Tesla 卡在 Linux 下默认跑在 TCC 模式，这个模式没有显示输出，专注计算，显存管理也更干净。如果你从 Windows 环境转过来，或者显卡之前被设置成 WDDM 模式，建议确认一下当前状态。V100 外接显卡坞的场景更折腾，驱动、供电、热插拔全都有坑，我后面排查章节会单独说。
ECC 检查也必须做。跑一条nvidia-smi -q -d ECC，看两块卡的 volatile 和 aggregate 计数，如果 unrecoverable 那一栏不是 0，说明显存可能已经有问题，跑大模型特别容易随机崩。V100 这类数据中心卡 ECC 默认是开的，但这不代表不会出错。我这次测试前就发现其中一张卡有过一次 unrecoverable ECC，虽然计数没再涨，但心里始终悬着，后面压测时单独跑了单卡基准确认没问题才继续。
驱动版本我用的 535.104.05，CUDA 环境直接用 12.1。vLLM 走 Docker 镜像，llama.cpp 用本地编译的 CUDA 版本，统一在 CUDA 12.x 下跑，避免底层库版本不一致影响对比公平性。
2.2 部署 vLLM：Docker 镜像与启动参数
vLLM 我直接用官方 Docker 镜像，版本选择上特别注意了一下。V100 属于"能跑但不在优化名单里"的架构，所以我没有追最新版，而是固定了一个 v0.6.x 的稳定镜像，理由后面排查章节会讲。
docker pull vllm/vllm-openai:v0.6.3.post1 docker run --gpus all -p 8000:8000 --ipc=host --shm-size=16g \ -v /models:/models \ vllm/vllm-openai:v0.6.3.post1 \ --model /models/DeepSeek-R1-Distill-Qwen-7B-FP8 \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9几个参数解释一下。--tensor-parallel-size 2是把模型切到两张卡上并行计算，这也是双卡 V100 和单卡最大的区别，参数设置不对会直接 OOM 或报 mismatch。--max-model-len 8192限制了最大序列长度，直接影响 KV cache 的分配。--gpu-memory-utilization 0.9意思是允许 vLLM 占满单卡 90% 的显存，剩下 10% 留给 CUDA context 和其他开销。
这里要特别提醒：加载 FP8 模型时，如果 vLLM 版本检测到 V100 不支持原生 FP8 计算，某些构建版本会直接报格式不支持，拒绝启动。我一开始用的镜像版本就遇到过，折腾了半小时，最后换了另一版才跑起来。这个问题排查细节放在后面第五节。
2.3 准备 llama.cpp 与 Q4_K_M 模型
llama.cpp 编译不复杂，但有几个容易忽略的细节。我用的构建参数是：
git clone https://github.com/ggerganov/llama.cpp cd llama.cpp && mkdir build && cd build cmake -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release .. make -j$(nproc)-DGGML_CUDA=ON是启用 CUDA 后端，如果你要用 Vulkan 或者其他后端可以替换，但在 V100 上 CUDA 是唯一值得选的路径。编译完会在 build/bin 下生成 llama-server，这就是 OpenAI 兼容 API 的服务端。
模型直接用社区转好的 GGUF 文件。以 DeepSeek-R1-Distill-Qwen-7B 为例，Hugging Face 和 ModelScope 上都有现成的 Q4_K_M 文件，直接下载即可。想自己从 FP16 模型转也可以，用 llama.cpp 自带的 llama-quantize 工具：先转 F16 GGUF，再转 Q4_K_M，但一般没必要自己转，现成文件省事。
启动命令：
./llama-server -m /models/DeepSeek-R1-Distill-Qwen-7B-Q4_K_M.gguf \ -ngl 99 --host 0.0.0.0 --port 8080 -c 8192 --parallel 4-ngl 99表示把尽可能多的层加载到 GPU，这里 99 是"能塞多少塞多少"的意思。7B 的 Q4_K_M 权重才 4.7GB，V100 单卡 32GB 完全放得下。--parallel 4是开几个并发槽位，llama.cpp 的并发是槽位制，不是 vLLM 那种动态批处理，后面对比数据里会看出这个差异。
2.4 为什么要拿 7B 模型来做标杆
很多人在 V100 上想跑的是 27B 甚至更大模型，社区里经常看到"V100 qwen3.8 27b"这类搜索词。双卡 32GB 确实能跑 27B 的 Q4_K_M，权重约 16GB，还能剩一点空间做 KV cache，但 27B 的变量太多，层数、上下文长度、量化方案都会干扰框架之间的对比。
所以我这次选的标杆是 7B 级模型：DeepSeek-R1-Distill-Qwen-7B 和 Qwen3-8B。这两个模型都有现成的 FP16、FP8、Q4_K_M 格式，社区生态完整，验证起来方便。7B 模型在双卡 V100 上不会把显存逼到墙角，跑出来的数据差异，才能真实反映框架调度和量化格式本身的影响，而不是被 OOM 或 swap 干扰。
顺带说一句，如果你用 Ollama 装过deepseek-r1-distill-qwen-7b(q4_k_m)，那底层其实就是在跑 llama.cpp 的推理内核，只是包装成了ollama run命令。用 Ollama 快速体验没问题，但要做这种对比实验，还是直接编译 llama.cpp 更可控，参数都能自己调。
3. 同一台 2×V100 上的实测数据：吞吐、延迟、显存、质量
3.1 测试方法与压测工具
我先说测试方法，没有统一口径的对比都是耍流氓。vLLM 用官方仓库里的 benchmark_serving.py 脚本压测，llama.cpp 端写了一个简单的 Python 客户端，用 requests 批量发请求，统计完成时间和 token 数。
统一参数：输入 prompt 长度取 128 token 和 1024 token 两档，输出统一固定 256 token，并发数取 1、8、32 三档。每个组合至少跑 100 个请求，取平均值和中位数。max_tokens 全部设置成 256，temperature 固定为 0，避免采样随机性干扰结果。
两种框架的公平性其实很难做到绝对。vLLM 是连续批处理，llama.cpp 是槽位并发，两者的调度哲学不同，同样的并发数下内部排队方式也不一样。所以我不追求绝对精确，主要看趋势和大方向的差异，这已经足够支撑选型结论。
# vLLM 压测示例 python3 benchmark_serving.py \ --backend vllm --host 127.0.0.1 --port 8000 \ --model DeepSeek-R1-Distill-Qwen-7B-FP8 \ --num-prompts 100 --request-rate 8 \ --max-tokens 256 # llama.cpp 压测示例 python3 test_client.py --url http://127.0.0.1:8080 \ --concurrency 8 --requests 100 --max-tokens 2563.2 单请求延迟对比
单并发场景，结果可能和很多人的直觉相反：llama.cpp 的 Q4_K_M 更快。我实测 7B 模型的 decode 速度，Q4_K_M 大约在 45 到 60 token/s，而 vLLM 加载 FP8（反量化成 FP16 计算）大约只有 30 到 50 token/s，整体慢了 10% 到 20%。
原因不复杂。单请求时，框架调度开销占比很小，决定速度的就是逐 token 的计算路径。Q4_K_M 的权重只有 4.7GB，每次读取的数据量小，对显存带宽的压力低，加上 llama.cpp 在 NVIDIA GPU 上对低精度矩阵乘做了专门优化，所以单进程、单请求场景下效率很高。
vLLM 那边，FP8 权重虽然只占 7.5GB，但反量化开销是纯增项，每次矩阵乘前都要把 FP8 数据转成 FP16，这个动作在 H100 上是硬件免费支持，在 V100 上就是 CPU/GPU 上的软件额外劳动。省了显存，慢了速度，这就是老卡跑新格式的代价。
3.3 高并发吞吐对比：Continuous Batching 的威力
并发上来之后，剧情反转。vLLM 在并发 8 和并发 32 时吞吐优势非常明显，这是我这次对比中最重要的一个观察点。
表格里是我这次测试环境下取得的代表数据，具体数字会因模型、显存、输入输出长度上下浮动，但趋势很稳定：
| 方案 | 并发 1 | 并发 8 | 并发 32 | 中位延迟 |
|---|---|---|---|---|
| vLLM + FP8（V100 实际走 FP16 计算） | 约 40 token/s | 约 110 token/s | 约 170 token/s | 中等偏低 |
| llama.cpp + Q4_K_M | 约 55 token/s | 约 80 token/s | 约 120 token/s | 中等偏高 |
vLLM 总吞吐能随并发接近线性增长，是因为它实现了 continuous batching。传统批处理是一次性把一批请求喂进去，等这整批全部生成完才释放资源接下一批；vLLM 则是 token 级调度，一个请求只要生成了一个 token，就可以继续排队等下一次计算，其他新请求随时可以插进来占用空出的显存和计算槽位。
llama.cpp 的 server 端是槽位制并发。--parallel 4开 4 个槽位，每个槽位处理一个请求，请求结束才释放。并发上来后，尾部延迟明显上升，正好是槽位排队的典型特征。所以如果用途是个人本地跑跑，llama.cpp 完全够用；如果做成对外 API 服务，面对真正的并发压力，vLLM 的高吞吐优势是实打实的。
3.4 显存占用与 KV Cache 差异
显存层面，两者都没有压力，但差异依然存在。7B 模型的 FP8 权重约 7.5GB，Q4_K_M 权重约 4.7GB，双卡 32GB 总显存 64GB，怎么分配都绰绰有余。真正拉出差距的是 KV cache 管理。
vLLM 用 PagedAttention 管理 KV cache，按页分配，动态扩展，只有实际生成的 token 才占用显存。llama.cpp 的--parallel 4会预先为每个槽位分配完整的 KV buffer，上下文越长、并发槽位越多，预分配的内存就越大。所以默认参数下，llama.cpp 的 KV cache 利用率不如 vLLM。
这个差异在 7B 模型上不致命，但如果你后面想跑 27B 模型，Q4_K_M 的优势会被放大。27B 的 Q4_K_M 权重约 16GB，FP8 权重约 28GB，双卡 V100 上 FP8 版本基本没有余量留给 KV cache，而 Q4_K_M 还能剩 16GB 左右。显存这件事，模型越大，Q4_K_M 的优势越不可忽视。
3.5 生成质量：PPL 与随机样例
量化方案的质量对比，我用困惑度（PPL）作为客观指标，再配几个主观样例。FP8 的 E4M3 格式精度远高于 4-bit 整数量化，反量化回 FP16 后几乎无损，PPL 和原始 FP16 模型差距在 0.2 以内，基本可以忽略。Q4_K_M 的 PPL 相对 FP16 大约高出 0.5 到 0.8，属于"有损失但是可控"的范围。
主观感受上，我用同一个 prompt 分别让两个方案生成快速排序代码。Q4_K_M 版本偶尔会在括号嵌套、中文标点这些细节上出现小瑕疵，FP8 版本更稳定顺滑。但如果只是做对话、RAG 问答、一般性代码生成，Q4_K_M 的质量退化基本不容易察觉。
要提醒的是，如果任务涉及大量数字计算、数学证明、结构化数据提取，这些场景对精度更敏感，Q4_K_M 的 4-bit 量化误差可能累积成明显错误，这时 FP8 的无损优势才有实际意义。在 V100 上怎么权衡，后面结论部分会说我的建议。
4. 结果背后的原理：为什么差距体现在这些维度
4.1 vLLM 的调度架构：Scheduler、Executor 与 Continuous Batching
要理解为什么 vLLM 能在并发场景甩开 llama.cpp，得看一眼它的组件分工。vLLM 的引擎核心是 EngineCore，它负责接收外部请求并维护内部的请求生命周期。EngineCore 里有两个关键角色：Scheduler 和 Executor。
Scheduler 负责显存管理和调度决策。它知道每张卡上还有多少 KV cache 页面可用，决定哪个请求可以继续解码、哪个请求应该抢占、新请求是否能插入。Executor 负责执行，它把调度器给出的任务分发到具体的 GPU worker 进程上，用 NVIDIA 的 CUDA graph 或者自定义内核完成实际计算。
vLLM 的 continuous batching 就是在 Scheduler 这一层实现的。它不是等到一个 batch 全部结束才接新请求，而是每一步生成后都重新评估，把完成的请求踢出去，把新请求插进来。这个机制让 GPU 的计算资源始终在干活，缝隙很小，所以并发越高，总吞吐越高。热词里有人问"vLLM enginecore 与 Scheduler、Executor 交互流程"，你翻一下 vLLM 源码里 engine_core 和 scheduler 之间的消息循环，其实就是请求状态机加显存分配器的互相调用，理解了 continuous batching 的核心思路，剩下的都是实现细节。
4.2 FP8 的算子限制与反量化开销：为什么省显存不省时间
FP8 在 V100 上的尴尬，要从两个层面看。第一层是反量化开销。FP8 E4M3 转 FP16 需要逐元素转换，虽然 CUTLASS 有专门的反量化内核，速度很快，但 V100 的没原生 FP8 单元，每次矩阵乘前都要做。省显存的那部分好处，部分被这层额外转换抵消了。
第二层是算子覆盖。FP8 计算并不覆盖所有算子。社区里有个很典型的例子：在 FP8 实现中，卷积内核大小大于 32 时会自动回退，比如 7×7 卷积会回退到 FP16 或 FP32。LLM 推理虽然不像 CV 那样大量用卷积，但模型里总有几个算子形态没有专门的 FP8 kernel，遇到这种情况就会走回退路径。回退意味着显存没有省到极致，中间结果还可能以更高精度存储，计算路径变得更长。
在 V100 上，这两个问题叠加起来就很明显：没有硬件加速、多了软件转换、部分算子还在回退。所以 FP8 在老卡上的收益基本只停留在"文件变小了"这个层面。这也是我反复强调的结论：FP8 是为新卡准备的格式，V100 硬加载它，只能吃哑巴亏。
4.3 Q4_K_M 的位宽与计算特征：为什么小量化在 V100 上这么能打
Q4_K_M 的优势，本质上来自两个机制。第一个是数据体积。4-bit 混合量化平均下来每个权重约 4.5 到 4.8 bit，比 FP8 的 8 bit 小一半左右，比 FP16 小接近四倍。GPU 推理，尤其是 decode 阶段，通常受显存带宽限制，权重越小，从显存搬运到计算单元的数据越少，速度自然越快。这就是为什么 V100 上 Q4_K_M 的单请求 decode 反而比 FP8 更快。
第二个机制是 llama.cpp 对 NVIDIA GPU 的低精度计算优化。llama.cpp 在 CUDA 端实现了多种量化矩阵乘法内核，包括 mmq（multithreaded matrix quantization）等专门为低精度权重设计的路径。这些内核把反量化、矩阵乘和累加过程融合调度，在 V100 的 FP16 Tensor Core 上执行得相当高效。
但 llama.cpp 的短板也很清楚：它没有 vLLM 那种细粒度的 continuous batching。它的并发是基于 slot 的粗粒度管理，每个 slot 一旦占上就在那待着，直到请求完成。这种模式在个人使用或者低并发下体验很好，一旦变成多用户服务，吞吐和延迟的劣势就会暴露。所以最合理的定位是：Q4_K_M 赢在单请求、简单部署、低资源消耗，vLLM 赢在高并发、大吞吐、长上下文。
5. 常见问题与排查实录：这些都是我踩过的坑
5.1 vLLM 加载 FP8 启动失败/格式报错
第一个高频问题就是 vLLM 加载 FP8 模型时直接启动失败。现象五花八门，最常见的报错是ValueError: The model format 'fp8' is not supported，或者是加载到一半抛出NotImplementedError，再要么就是日志里出现奇怪的 unsupported kernel。
原因很直接：vLLM 的某些版本在设计上就把 FP8 限定为只在支持 FP8 的硬件上使用，V100（SM70）一旦被识别出来，直接拒绝走 FP8 路径。解决办法有三个：一是换一个版本更宽松的 vLLM 镜像，实测部分 v0.6.x 版本可以容忍 V100 并自动回退到反量化路径；二是干脆不要用 FP8 模型，改成 FP16 版本，效果和 FP8 反量化后几乎一样；三是自己写转换脚本，把 FP8 检查点先解量化成 FP16 检查点再加载，这样最稳妥。
我的建议是第二种，在 V100 上直接加载 FP16 模型。FP8 省下的 3GB 显存对 7B 模型微乎其微，换来的是兼容性和稳定性的麻烦，不值当。
5.2 vLLM 新版本在 V100 上性能下降
社区里有人反馈 vLLM 新版本性能下降，我在 V100 上也实际遇到了。同一套模型和压测脚本，从 vLLM v0.5.x 升到 v0.6.x 后，吞吐掉了大概 15% 左右，找原因找了一天多。
根源是新版本把优化重心放在了 Hopper、Ada 这些新架构上，对 V100 这种 SM70 老架构，很多新内核都会走 fallback 路径。CUTLASS 版本升级后，部分新内核不兼容老架构，vLLM 只能退回通用实现，性能自然下降。
排查方法是 A/B 对比。固定 Docker 镜像版本，分别跑同一个压测，记录吞吐差异。如果发现新版本对 V100 不友好，最省事的办法就是钉在一个稳定版本长期用。另外如果性能下降特别离谱，可以试试--enforce-eager关闭 CUDA graph，看是不是 graph capture 在触发回退。这个参数在不同版本和卡型上的表现差异很大，值得单独验证。
5.3 V100 ECC 错误与显存故障检测
V100 这类数据中心卡的 ECC 问题不能忽视。现象通常是推理结果偶尔乱码、服务进程莫名崩溃，或者 ollama 跑得好好的突然无响应。我用nvidia-smi -q -d ECC检查，发现其中一张卡的 volatile errors 有计数，虽然 unrecoverable 暂时是 0，但心里还是不踏实。
检测流程建议：先看nvidia-smi -q -d ECC的输出，重点看Uncorrectable ECC Errors和Correctable ECC Errors。如果 uncorrectable 在持续增长，说明显存颗粒已经有问题，正常手段修不了，只能联系售后做 RMA。如果只是 correctable 有计数，可以尝试nvidia-smi --reset-ecc-state重置计数继续观察，但也要留意增长趋势。
还有个排查技巧：双卡 NVLink 环境下，如果一张卡显存有问题，它会拖累整个 tensor parallel 组，因为模型权重是切开的，两卡同步计算，出错的卡会让推理结果整体错乱。排查时先用单卡模式跑一个简单测试，隔离出问题显卡再处理。
5.4 驱动模式、显卡坞与 Windows 干扰
V100 的驱动模式问题也经常被提。TCC 和 WDDM 是两种不同的驱动模式，TCC 专注计算，WDDM 带显示输出。Windows 下插 Tesla 卡，默认往往是 WDDM 模式，显存管理和 CUDA 效率都会受影响。Linux 下默认 TCC，不需要额外操作。
如果你用的是 V100 外接显卡坞，问题就更多了。驱动安装、热插拔、供电不稳定全都很折腾，和服务器里直插完全两种体验。实测下来，显卡坞这种场景别指望高吞吐，能用起来跑通就是胜利，最好还是用服务器直插。
vLLM 官方不支持 Windows，想跑只能走 Docker Desktop 或 WSL2，但 V100 在这些环境下又容易踩驱动映射的坑。我自己的经验是：Windows 玩大模型，直接用 llama.cpp 编译出的 exe 最省心，llama-server 在 Windows 下是完整的原生支持。这也是为什么 Windows 用户群里 Q4_K_M + llama.cpp 永远是主流组合。
5.5 常见问题速查表
| 问题现象 | 根本原因 | 解决方案 |
|---|---|---|
| vLLM 加载 FP8 报格式不支持 | V100 不在 FP8 原生硬件支持列表 | 换宽松版本镜像，或改用 FP16 模型 |
| vLLM 新版本吞吐下降 | 新版主要优化新架构，V100 走 fallback | 钉固定版本，禁用 CUDA graph 测试 |
| 推理结果乱码/服务崩溃 | 显存 ECC 错误累计 | 检查 ECC 计数，重置，必要时 RMA |
| Windows 下 V100 推理效率低 | WDDM 模式影响 CUDA 效率 | 改 TCC 模式，或直接用 llama.cpp |
| 27B 模型在双卡 V100 上 OOM | FP8 权重体积大，KV cache 空间不足 | 换 Q4_K_M，留出 KV cache 余量 |
6. 给同配置用户的选择建议（个人经验）
如果在 V100 上只能选一套方案，我的建议很明确：日常个人使用、快速验证、小团队内部工具，直接选 llama.cpp + Q4_K_M。这套组合启动快、依赖少、单请求延迟低、显存占用小，而且 Ollama 已经把这个组合包装得非常易用，几乎没有上手成本。
如果要做对外 API 服务，追求高并发吞吐和稳定的延迟表现，用 vLLM，但模型格式选 FP16 而不是 FP8。FP8 在 V100 上省下的那点显存，换来的只有反量化开销和算子回退，不划算。配--tensor-parallel-size 2双卡并行，配合 vLLM 的 continuous batching，并发吞吐才能发挥出这套硬件应有的价值。
我个人在实际操作中的体会是：V100 这台老卡并不是不能跑新格式，而是跑新格式容易陷入"看着高级、实际吃亏"的境地。很多东西要落到自己机器上实测才知道答案，别人在 H100 上总结的经验，直接照搬到 V100 上往往不成立。最后再分享一个小技巧：手头有 V100 的兄弟，别急着上最新版框架，钉一个自己验证过的版本，把精力放在量化格式的选择和压测口径上，收益远比追新版本大得多。
