★ FEATURED ARTICLE 一台双路 X99 配上两张 V100 32GB放在今天还能干点啥我最近拿这台机器做了一轮大模型推理方案对比主角是 vLLM 加载 FP8 量化模型对手是 llama.cpp 加载 Q4_K_M 量化模型。很多人看到标题会觉得奇怪V100 根本不支持 FP8这个对比是不是搞错了其实没搞错这正是整篇最有意思的地方。我在双卡 V100 上把两种方案完整跑了一遍从驱动准备、Docker 部署、模型转换到压测数据全走了个遍。这篇文章就是一份完整的实测记录包含环境搭建、参数说明、性能对比、踩坑实录和排查方法。如果你手里还有 V100、A100 这类老卡或者云上租了旧实例想搞清楚量化格式和推理框架到底该怎么搭配这篇文章能帮你省下很多试错时间。1. 先把前提说清楚V100 到底能不能跑 FP81.1 V100 的硬件边界Tensor Core 支持什么格式先说硬件底牌。V100 用的是 Volta 架构芯片代号 GV100SM 版本是 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每个又按混合程度分成 Ssmall、Mmedium、Llarge几个变体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 权重大约 14GBFP8 大约 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.05CUDA 环境直接用 12.1。vLLM 走 Docker 镜像llama.cpp 用本地编译的 CUDA 版本统一在 CUDA 12.x 下跑避免底层库版本不一致影响对比公平性。2.2 部署 vLLMDocker 镜像与启动参数vLLM 我直接用官方 Docker 镜像版本选择上特别注意了一下。V100 属于能跑但不在优化名单里的架构所以我没有追最新版而是固定了一个 v0.6.x 的稳定镜像理由后面排查章节会讲。docker pull vllm/vllm-openai:v0.6.3.post1 docker run --gpus all -p 8000:8000 --ipchost --shm-size16g \ -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_CUDAON -DCMAKE_BUILD_TYPERelease .. make -j$(nproc)-DGGML_CUDAON是启用 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.7GBV100 单卡 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 全部设置成 256temperature 固定为 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 FP8V100 实际走 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.5GBQ4_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 权重约 16GBFP8 权重约 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 端实现了多种量化矩阵乘法内核包括 mmqmultithreaded 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 的硬件上使用V100SM70一旦被识别出来直接拒绝走 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 计数重置必要时 RMAWindows 下 V100 推理效率低WDDM 模式影响 CUDA 效率改 TCC 模式或直接用 llama.cpp27B 模型在双卡 V100 上 OOMFP8 权重体积大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 的兄弟别急着上最新版框架钉一个自己验证过的版本把精力放在量化格式的选择和压测口径上收益远比追新版本大得多。
阅读完成 · 觉得有帮助？
